Software laten herbouwen

Is de huidige software van jouw organisatie verouderd? Wordt het doorontwikkelen van de software daardoor moeilijk of voldoet de huidige programmeertaal niet meer aan de wensen? Het laten herbouwen van software kan een goede optie zijn. Maar wanneer is het slim om software te laten herbouwen? We nemen je mee door de overwegingen en mogelijkheden, om zo een beter beeld te schetsen.

Wanneer moet je software laten herbouwen?

Over het algemeen wordt het herbouwen van software veel toegepast wanneer het huidige platform is verouderd en niet meer aan toekomstige wensen voldoet. Dan kan onderhouden en updaten van software erg moeilijk worden. Systemen worden traag en crashen regelmatig. Dit gaat ten koste van de tevredenheid van medewerkers én zorgt ervoor dat de werkzaamheden aanzienlijk meer tijd kosten. In deze situatie kan slechte of verouderde software de groei van het hele bedrijf remmen. Bij een crash kunnen bedrijfsprocessen volledig stil komen te liggen en ook hackgevoeligheid ligt op de loer, met alle kostbare gevolgen van dien.

Daarnaast kan er sprake zijn van een vendor lock-in. Hierbij zit je vast aan je huidige software partner waardoor je moeilijk kunt overstappen. Dit kan bijvoorbeeld gebeuren wanneer je vastzit aan bepaalde rechten of een onbekende programmeertaal waar vrijwel niemand mee werkt. Bij ontevredenheid over je huidige software partner zit je dan vast. Het herbouwen van de software kan dan uitkomst bieden. Daarnaast adviseren we altijd om bij een nieuwe software partner altijd goed te kijken naar de rechten en of de programmeertaal gangbaar is.

Welke opties zijn er?

Refactoring of herbouwen

Wanneer software flink verouderd is, dan heb je vaak de keuze uit refactoring van software of het volledig herbouwen van software.

Bij het herbouwen wordt de software volledig opnieuw opgebouwd tot een goed werkende applicatie in een up-to-date omgeving. De code wordt dus volledig nieuw geschreven zodat er weer een goede, stevige basis staat. Bij refactoring wordt bestaande software geüpdatet op cruciale punten. De software wordt dus niet volledig herschreven, maar wordt aangepast en verbeterd waar nodig.

Welke optie het beste voor jou is, is afhankelijk van de situatie. Is software lang niet geüpdatet, maar is de basis nog wel goed en voldoet de programmeertaal nog aan alle wensen? Dan kan refactoring van de code een prima oplossing zijn om de software weer up-to-date te krijgen. De doorlooptijd van refactoring is over het algemeen korter dan van herbouwen.

Is de programmeertaal verouderd, waardoor doorontwikkelen erg moeilijk wordt? Of is naast de werking van de software ook het uiterlijk niet meer naar wens? Dan is het herbouwen van de software de beste en meest duurzame oplossing. Het blijven oplappen van oude software wordt anders onderaan de streep duurder.

Nieuwe features toevoegen

Om concurrerend in de markt te blijven, is het belangrijk om constant nieuwe ontwikkelingen in de gaten te houden. Welke nieuwe mogelijkheden zijn er om de klant nog beter te bedienen. Heb je voor jouw verouderde software ook wensen om nieuwe features toe te voegen? Zorg dan dat je deze nieuwe wensen goed in kaart brengt. Dit is namelijk ook van belangrijk voor de keuze om jouw software te refactoren of te herbouwen.

Nieuwe features kunnen vanzelfsprekend direct in het herbouw-proces worden meegenomen of in een later stadium worden toegevoegd op het moment dat de herbouwde software live staat. Dit is mede afhankelijk van de gewenste doorlooptijd en het budget.

Hoe gaat software herbouwen in zijn werk?

Inventarisatie
De probleem- of doelstelling wordt in kaart gebracht. Waar loop je nu tegen aan? Of wat is je doel? Op basis daarvan bepalen we de beste aanpak voor jouw project. Op basis van het gevormde beeld maken we een eerste functionele uitwerking, een architectuurvoorstel en een globale inschatting van de benodigde tijd om de oplossing te realiseren.

Projectstart
Om te kunnen starten met het project bepalen we samen onder andere de planning, team-samenstelling, manier van samenwerken en overleggen en andere kaders en randvoorwaarden. We zetten alles helder en duidelijk uiteen, zodat alle neuzen dezelfde kant op staan.

Manier van samenwerken
Binnen Covadis is er niet een gestandaardiseerde werkwijze. Per project wordt samen met de opdrachtgever bepaald wat de beste aanpak voor het betreffende project is. Dit is onder andere afhankelijk van zaken als:

Hoe duidelijk zijn de requirements bij aanvang?
Hoe waarschijnlijk is het dat de requirements tijdens het project worden bijgesteld?
Is het een lang of kortlopend project?
Zijn er afhankelijkheden van derden?

Dit zorgt per project altijd weer voor een unieke manier van werken. Het houdt in dat we voor bestaande methodes op zoek gaan naar hoe de wijze van werken past bij het project en de opdrachtgever. Over het algemeen hanteren we een agile aanpak omdat wij daarmee onze opdrachtgevers het beste kunnen bedienen. In de kern komt dat erop neer dat we werken aan oplossingen die op dit moment de grootste meerwaarde kunnen leveren aan de opdrachtgever en de eindgebruikers. Dat we snel kunnen mee-veranderen indien dat noodzakelijk is en niet halsstarrig een projectplan volgen dat ‘lang geleden’ is opgesteld toen de wereld er nog anders uitzag. Door te werken met vaste overleg- en contactmomenten wordt gezamenlijk de backlog aan werkzaamheden beheerd en bewaakt.

Sprints

Binnen deze agile aanpak werken wij doorgaans met ‘sprints’ van 2 weken. We kiezen voor sprints van 2 weken om zo zeer snel resultaten zichtbaar te maken en we daarbij snel feedback vanuit alle stakeholders kunnen ontvangen. Deze feedback wordt vaak opgehaald tijdens de sprintreview die aan het eind van een sprint gepland staat. Hierin zal doormiddel van een demonstratie getoond worden wat er de afgelopen sprint gerealiseerd is

Refinements

Tijdens de sprint worden de requirements voor de volgende sprint(s) uitgewerkt tijdens refinementsessies. Hierbij is een bijdrage vanuit de opdrachtgever wenselijk om als domeindeskundige voor de requirements op te treden. We stellen hierbij dus niet een allesomvattend functioneel ontwerp op bij de start van het project, maar werken de requirements gedurende het project verder uit.

Sprintreview

Het einde van de sprint sluiten we af met een sprintreview. Deze zal bestaan uit een demonstratie waarin we bekijken wat er de afgelopen sprint gerealiseerd is en wat niet. Dit is tevens het moment om feedback te verzamelen en op basis hiervan eventueel het plan voor de volgende sprint bij te stellen.

Releases

Het opleveren van werkende software is de beste indicatie van voortgang. Daarom leveren we bij voorkeur elke sprint een nieuwe versie van de werkende software op.

Dit kunnen we!

Covadis heeft met meer dan 15 jaar ervaring al heel wat mooie projecten mogen doen. Aan ervaring dus zeker geen gebrek! Zo hebben we de volgende software al herbouwd of doorontwikkeld:

Slimme facturatiemodule voor NieuweStroom
NieuweStroom is een energieleverancier met een geheel eigen werkwijze. Door de grote groei die de energieleverancier doormaakte, was een nieuwe facturatiemodule nodig. Door deze slimme module kunnen ze nu met hetzelfde aantal medewerkers meer klanten bedienen.

Migratie en herbouw voor Concrefy
Voor deze marktleider op het gebied van onderzoek naar beton, asfalt en wapeningsstaal hebben we 2 verouderde systemen samengevoegd tot één state-of-the-art online omgeving die zorgt voor flink meer efficiëntie.

Plan een vrijblijvend adviesgesprek

Vind je het zelf lastig om in te schatten of bijvoorbeeld de programmeertaal nog voldoet aan de wensen? Of ben je benieuwd wat de beste optie is? Neem gerust contact op met onze adviseur Chiel. Hij neemt graag de mogelijkheden met je door. Daarnaast krijg je indien gewenst een passende urenindicatie, zodat je precies weet waar je aan toe bent.

Contactformulier