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.

Er kan ook 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.

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.

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:

1. Hoe duidelijk zijn de requirements bij aanvang?
2. Hoe waarschijnlijk is het dat de requirements tijdens het project worden bijgesteld?
3. Is het een lang of kortlopend project?
4. 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.

Covadis heeft met meer dan 17 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: