Deel 5 Ontwikkelstrategieën

5 Rapid prototyping

Rapid prototyping lost het probleem van de late betrokkenheid van de klant op door eerst een prototype te maken alvorens aan de defi nitieve projectcyclus te beginnen. Dat werd in de requirementsanalyse ook al toegelicht. Op basis van het prototype kan de klant vereisten bepalen en feedback geven aan de leverancier van het product. Een prototype kan op twee manieren worden voorzien:

– ‘Throw-away’: het prototype dient alleen om de klant te tonen hoe de uiteindelijke applicatie er zou kunnen uitzien. Het is niet de bedoeling dat dit prototype deel uitmaakt van de uiteindelijke oplossing.

– ‘Light implementation’: het prototype bevat al een deel van de uiteindelijke oplossing en zal gebruikt worden als basis voor de verdere implementatie.

Het rapid prototyping-model heeft zeer veel overeenkomsten met het waterfall-model, de verschillende fases verlopen nog altijd sequentieel, maar voor de aanvang van het uiteindelijke project zal men al een kleine projectcyclus doorlopen om het prototype te bouwen. Daarna gebruikt de businessanalist dat prototype als leidraad voor de workshops met de eindgebruikers. Omdat er al een visuele voorstelling is van het eindproduct, is het eenvoudiger om de vereisten van de klant vast te leggen en de verwachtingen van de eindgebruikers in lijn te krijgen.

Het voordeel van rapid prototyping is duidelijk: de klant krijgt al vroeg in het proces een inzicht in wat er zal worden opgeleverd. Het is echter nog altijd wachten op de uiteindelijke testfase alvorens de klant een afgewerkt product te zien zal krijgen. Er blijft dus nog altijd het risico op hoge kosten als het eindproduct toch niet voldoet aan de eisen van de klant. Dat risico wordt sterk verminderd door het aanbieden van een prototype maar zal niet helemaal verdwijnen. Daarnaast kost een prototype bouwen ook tijd en geld, en dat is niet op elk project een haalbare kaart. Het al dan niet gebruiken van een prototype is dus een afweging die het projectmanagement moet maken tussen de kosten van een prototype en de vermindering van het risico op problemen tijdens het testen. Prototyping wordt bijvoorbeeld dikwijls gebruikt bij de implementatie van een standaardsoftware waar er al demo’s ter beschikking zijn en de kost van het prototype dus zeer beperkt is.

6

Incrementeel ontwikkelen

Om een antwoord te kunnen bieden aan de stijgende complexiteit in softwareontwikkeling, werd in de jaren 80 meer en meer gebruik gemaakt van incrementeel ontwikkelen. Die ontwikkelstrategie gaat uit van het idee dat softwareontwikkeling beter beheersbaar is als het volledige product wordt opgedeeld in kleinere stukjes. Bij incrementeel ontwikkelen deelt men dus de analyse, de ontwikkeling en het testen op voor verschillende groepjes van functionaliteiten. Het concept en het volledige ontwerp worden echter wel vooraf volledig op punt gesteld. De eerste release bevat meestal de basisfunctionaliteiten en de volgende releases bouwen daarop verder. In het incrementeel model is het opdelen in kleinere delen soms ook een interne operatie, vooral bedoeld om het ontwikkelingsproces eenvoudiger te maken. Veelal wordt er nog altijd enkel een volledig afgewerkt product aan de klant gepresenteerd.

Concept

Ontwerp

Analyse, ontwikkeling en test in verschillende releases:

Release 1

Release 2

Release 3

Incrementeel ontwikkelen speelt dus vooral in op het beheersen van de verhoogde complexiteit in hedendaagse softwareprojecten, maar soms is het contact met de klant nog altijd beperkt tot de ontwerp- en testfase. Er is mogelijkheid tot feedback tussen de verschillende fases binnen een release, maar er is dan nog te weinig feedback mogelijk voor de klanten. Als na elke release ook acceptatietesten worden uitgevoerd en de volgende releases rekening houden met de uitkomsten van de vorige releases, geeft het incrementeel model de mogelijkheid om de feedback van de klant snel mee te nemen en het risico later in het project sterk te verminderen. Op die manier kan er zeer flexibel omgegaan worden met veranderende vereisten en invloeden van buitenaf.

7 Iteratief ontwikkelen

Bij het iteratieve model gaat men niet enkel de ontwikkeling van de software (inclusief analyse en testen) opdelen, maar wordt het volledige project opgedeeld in kleinere delen. Er wordt dus altijd een nieuw volledig deelprojectje uitgewerkt (één iteratie) waarbij de eindgebruikers van begin tot einde betrokken worden bij het project. In de eerste iteratie zal er een basisoplossing worden opgeleverd.

Belangrijk daarbij is dat de opgeleverde oplossing een volledig werkende oplossing is en dus geen deeloplossing. Op basis van de ervaringen met de eerste oplossing, voegt men in de tweede iteratie dan nieuwe functionaliteiten toe en verbetert en verfijnt men bestaande functionaliteiten. Men voert een bepaald aantal iteraties uit om uiteindelijk tot een compleet eindproduct te komen. Die manier van softwareontwikkeling zorgt voor een minimalisering van het risico dat de klant uiteindelijk niet tevreden is met het opgeleverde product, gezien de klant altijd de mogelijkheid heeft om in te grijpen tijdens het proces. Daarnaast gaat dit model ook zeer goed om met complexiteit omdat het de mogelijkheid geeft flexibel te reageren op wijzigingen.

Iteratief ontwikkelen heeft nog een aantal voordelen:

– De leverancier levert na elke iteratie een bruikbaar product op. Niet alleen neemt daarvoor het vertrouwen van de eindgebruikers in het product toe, er is ook altijd de mogelijkheid om na elke iteratie te stoppen en toch resultaat te hebben van het project. Dat kan vooral in budgetonzekere tijden een groot pluspunt betekenen.

– Het risico op faling van het project wordt beperkt. Niet enkel beperken we het risico op ontevredenheid bij de klant maar ook het risico op fouten en problemen in de integratie wordt verkleind omdat er veel sneller getest wordt. Bovendien zal men door te werken met kleinere groepen van functionaliteiten minder integratieproblemen ondervinden. Doordat er altijd kleine delen functionaliteit worden ontwikkeld, zal het gemakkelijker te identificeren zijn waar de impact van veranderingen speelt en waar integratie noodzakelijk is.

Iteratief werken is beter voor het projectteam. Door de complexiteit van de oplossing te verminderen, kan het projectteam met meer focus werken aan wat op een bepaald moment deel uitmaakt van de iteratie. Daardoor kent het team over het algemeen ook een betere leercurve. Bovendien zorgt de verhoogde communicatie met de klant ervoor dat er sneller feedback komt op het geleverde werk en wordt er vermeden dat de ontwikkelaars grote delen opnieuw moeten doen.

De kwaliteit van de oplossing gaat omhoog omdat er meer validatiemomenten zijn met de klant. Testen is immers een van de manieren om kwaliteit te waarborgen. Als men meer testmomenten invoert, zal de kwaliteit ook automatisch verhogen.

Een nadeel van iteratief werken is dat er vooraf geen afgelijnde afspraken kunnen worden gemaakt over wat er op het einde van het project zal worden opgeleverd. Aangezien er bij elke iteratie vereisten kunnen bijkomen of wijzigen, is het niet eenvoudig een sluitend budget vast te stellen. Er zal bij aanvang van het project dus enkel een initiële scope worden vastgesteld. Daarom is er ook een reëel risico op scope creep als de verwachtingen van de eindgebruikers niet voldoende worden beheerd door de projectmanager. Het is eveneens niet altijd eenvoudig voor projectmanagers om dat type van projecten te beheren door de grote dynamiek die er heerst. Het is dus zeker aan te raden een projectmanager aan te stellen met ervaring in iteratief ontwikkelen. Om scope creep te vermijden is het belangrijk dat er tijdens de initiatiefase toch voldoende aandacht wordt besteed aan de vereisten van de klant. Hoewel die met elke iteratie kunnen worden aangepast, is het voor verschillende redenen wel belangrijk dat er duidelijk wordt bepaald wat de verwachtingen van de klant zijn. Zonder duidelijk concept is het zeer moeilijk om een budget vast te stellen, de juiste mensen vrij te maken en te garanderen dat de opgeleverde oplossing uiteindelijk voldoet aan de business requirements. Het is dus niet wenselijk om een iteratieve aanpak te kiezen om het voortraject te kunnen vermijden, integendeel. Bij een iteratieve aanpak is het voortraject minstens even belangrijk.

Er bestaan verschillende methodologieën om een project iteratief aan te pakken. De meest bekende methodes zijn Rational Unified Proces (RUP), SCRUM en KANBAN. Al die methodologieën worden aanzien als een variant op het agile ontwikkelen en zullen we meer in detail bespreken in het hoofdstuk ‘Welke agile manieren van werken zijn er? #agile’.

8 Continuous delivery

Hoewel continuous delivery meer is dan alleen een ontwikkelstrategie (het is eerder een end-to-endaanpak voor het opleveren van software), wordt het toch in dit hoofdstuk besproken omdat het een belangrijke aanvulling is op iteratief ontwikkelen. Continuous delivery is een gevestigde waarde geworden in het softwarelandschap en blijft aan populariteit winnen door een aantal factoren:

– Klanten verwachten alsmaar snellere updates van digitale producten: of het nu gaat om bug fixes of nieuwe functionaliteit, het is niet meer van deze tijd dat een klant daar weken op moet wachten. De klanten kunnen zowel interne als externe klanten zijn.

Omdat IT alsmaar een groter aandeel heeft in de business, wordt er meer en meer naar IT gekeken om te besparen. Softwareontwikkeling moet dus efficiënter, kwaliteitsvoller en productiever zijn dan ooit tevoren.

– IT-processen worden kritischer voor de business, fouten zijn dus alsmaar moeilijker te verantwoorden en lange periodes van onbeschikbaarheid worden niet meer aanvaard.

Om daar een antwoord op te kunnen bieden, werken meer en meer bedrijven volgens de methode van continuous delivery. Daarbij verloopt het hele proces van specificatie tot operations in zeer korte cycli, zodat werkende software meerdere keren per maand, per week of zelfs per dag in productie kan worden opgeleverd. Hoe vaak software gereleased wordt, is dan afhankelijk van de mate waarin continuous delivery in de organisatie is geïmplementeerd en uiteraard ook van de mate waarin de business vragende partij is voor een bepaalde frequentie van releases.

Een belangrijke eigenschap van continuous delivery is de samenstelling van multidisciplinaire teams die samen eindverantwoordelijkheid dragen voor de software die uiteindelijk in productie terechtkomt. In een traditionele opzet bestaat er een team eindgebruikers, een team ontwikkelaars, een team testers en een operationsteam dat zorgt voor de release en het onderhoud na de release. Het nadeel van die aanpak is dat elk team een eigen agenda heeft: developers willen nieuwe software ontwikkelen en zijn dus van nature gericht op verandering, een operationsteam streeft echter naar stabiliteit en ziet dus liefst zo weinig mogelijk verandering. Het samenbrengen van alle verantwoordelijkheden in één team zorgt er echter voor dat elk teamlid gaat nadenken over de impact van zijn beslissingen op het eindproduct en op de andere teamleden. Een stuk software zal moeten voldoen aan alle vereisten van de business, zal volledig getest moeten zijn en zal nadien ook vlot onderhoudbaar moeten zijn. Dat zorgt voor een betere en stabielere software met minder fouten en dus minder kosten.

Deel 5 Ontwikkelstrategieën

De grote aanvulling op het iteratief ontwikkelen is dus dat alle rollen in één team worden betrokken. Bij iteratief ontwikkelen kun je wel heel snel functionaliteit tonen aan de business en feedback verzamelen, maar als het testen en releasen vervolgens veel extra tijd kost, neemt de oplevering van software alsnog te veel tijd in beslag. Continous delivery is dus werken volgens de iteratieve principes maar aangevuld met (automatisch) testen en het betrekken van operations van bij het begin.

Figuur 6 Continuous delivery.

De figuur geeft een cyclus weer in continuous delivery. Om de cycli kort te houden is het ook noodzakelijk om de functionaliteit in elke cyclus beperkt te houden. Daarbij is het belangrijk om enkel functionaliteiten toe te voegen die echt waarde toevoegen aan de business. Een functionaliteit die slechts zelden wordt gebruikt, voegt misschien niet voldoende waarde toe en wordt daarom beter niet opgenomen in de release. Op die manier zal de kost van softwareontwikkeling ook worden verminderd. Er wordt immers enkel software opgeleverd die ook daadwerkelijk waarde toevoegt.

Een laatste kenmerk is de invoering van automatisatie waar mogelijk. Bij continuous delivery worden tools ingezet om het schrijven van testscenario’s, het uitvoeren van testen, het uitvoeren van de build en het releasen (deployment) automatisch te laten verlopen. Automatisatie betekent immers tijdswinst en de eliminatie van menselijke fouten waardoor de kosten opnieuw verlagen en de kwaliteit verhoogt.

Samengevat heeft continuous delivery dus drie belangrijke voordelen:

1 Kosten zullen verlagen en kwaliteit verhoogt omdat fouten worden opgespoord nog voor de software in productie wordt gezet. Als een fout toch in productie terechtkomt, kan ze sneller worden rechtgezet door de korte releasecycli. Daarnaast zorgt ook de kritische selectie van de functionaliteiten voor minder kosten doordat er enkel functionaliteiten worden gereleased die echt waarde toevoegen.

2 Productiviteit van softwareontwikkeling gaat omhoog. Niet alleen zal er veel sneller werkende software kunnen worden opgeleverd, het doorlopen van het hele proces wordt ook alsmaar efficiënter. Omdat de cyclus nu meerdere keren per maand, week of dag wordt doorlopen, geraken alle actoren en processen beter op elkaar afgestemd. Door herhaling wordt er immers verbetering bereikt.

Hoofdstuk 17 Moeten de projectfases elkaar strikt opvolgen? #waterfallvsiteratief

3 Door de snellere doorlooptijd van softwareontwikkeling kan er veel sneller worden ingespeeld op de vragen van de business (klanten). Door de sterke betrokkenheid van de business bij het hele proces is het dus mogelijk sneller software op te leveren die volledig beantwoordt aan de vraag. Er kan dus een hogere graad van customer service worden geleverd.