Aorta lifecycle-model

Het Aorta lifecycle-model is een software ontwikkelmethode volgens de watervalmethode, maar na elke cyclus vindt een terugkoppeling naar de klant plaats.

Geschiedenis

In de jaren tachtig en negentig zijn er veel lifecycle-modellen geïntroduceerd. Wat deze modellen met elkaar gemeen hebben is dat zij een kortere ontwikkelingcyclus kennen. Bij strikte hantering van het 'waterfall'-model ziet de klant pas tegen de tijd van het opleveren wat de uiteindelijke applicatie geworden is. Bij gebruik van de andere lifecycle modellen worden er meerdere cycli ontwikkeld, waarbij de klant een terugkoppeling krijgt na elke cyclus. Eventuele fouten worden op deze manier eerder ontdekt en de klant kan direct aangeven hoe hij het wel wil hebben. Ook is het belangrijk goed te controleren of elke cyclus wordt afgesloten zonder fouten. Wanneer een fout wordt geconstateerd in een volgende cyclus kost het veel geld om de fout te herstellen. Elke voorgaande cyclus zal moeten worden herhaald, om eventuele nieuwe fouten te voorkomen.

De fasen

Het Aorta lifecycle-model bevat negen stappen om tot het uiteindelijk model te komen. Er wordt begonnen met de Oriëntatiefase. In de oriëntatiefase is globaal in kaart gebracht wat de wensen van de gebruiker van de applicatie zijn. Hierna komt de planningsfase. In de planningsfase wordt een projectplan opgesteld voor de rest van het project. Na deze twee fasen begint het concrete werk, bestaande uit een vijftal essentiële fasen. In het onderstaande model zijn deze fasen weergegeven met daarbij hun belangrijkste eindproduct. De begin letters van deze verschillende fasen vormen het woord 'Aorta'. Dit is het kloppende hart van een project.

Het AORTA lifecycle-model

Ten slotte worden nog de twee laatste fasen onderscheiden. In de evaluatiefase wordt teruggekeken op het project om de ervaringen in kaart te brengen en daarna komt de laatste fase, de onderhoudsfase. In deze laatste fase wordt onderhoud gepleegd op de geleverde applicatie. Hierin is vaak onderscheid te maken in een garantieperiode en een onderhoudsperiode.

Voordelen

• Wanneer in het begin van het project fouten worden ontdekt, kost het minder inspanning (en dus tijd en geld) om deze fout te herstellen. Bij het watervalmodel wil men alle fasen eerst goed afsluiten voordat men verdergaat met de volgende fase. Men gaat ervan uit dat de fasen altijd goed zijn voordat men verdergaat met een volgende fase.
• Bij het watervalmodel legt men de nadruk op documentatie. In de nieuwere software ontwikkelings methoden maakt men minder documentatie. Dit heeft tot gevolg dat als er nieuwe mensen in het project opgenomen worden en er mensen weggaan het lastig is om de kennis over te dragen. Dit nadeel heeft de watervalmethode niet.
• Het is een duidelijke en simpele methode. Het is erg duidelijk wanneer bepaalde fasen afgelopen zijn.
• Men kan in deze methode gebruikmaken van mijlpalen.
• De watervalmethode is erg bekend. Veel mensen hebben er ervaring mee, dus kunnen er gemakkelijk mee gaan werken.

Nadelen

Er zijn een aantal nadelen van deze manier om software te ontwikkelen.

• Veel software projecten zijn afhankelijk van externe factoren. De opdrachtgever is een heel belangrijke externe factor. Vaak zullen de requirements gedurende de loop van het project wijzigen, omdat de opdrachtgever iets anders wil. Het is dus een nadeel dat de watervalmethode ervan uitgaat dat de requirements niet veranderen tijdens het project. Wanneer in de bouwfase een requirement verandert, moeten een heel aantal fases opnieuw gemaakt worden.
• Het is erg moeilijk om de benodigde tijd en de kosten te schatten. De fasen zijn erg groot, het is daarom erg lastig om in te schatten hoeveel elke fase kost.
• In een aantal nieuwe methoden zijn bijna alle aspecten van een software ontwikkelingstraject opgenomen. Je kan denken aan planningstechnieken, project management methoden en hoe de projectorganisatie ingericht moet worden.
• Bij veel software projecten werken verschillende mensen aan de verschillende fasen van het project. Bijvoorbeeld: de ontwerpers en de bouwers. Ze hebben allemaal een andere kijk op het project: zo kijken ontwerpers anders tegen het project aan dan de bouwers. Omgekeerd zullen de bouwers ook vaak anders tegen het ontwerp van de ontwerpers aankijken dan de ontwerpers zelf. Vaak is het zo dat het ontwerp weer aangepast zal moeten worden. Hier is de watervalmethode niet voor gemaakt.
• Binnen het project zijn de verschillende teamleden vaak gespecialiseerd. Het ene teamlid zal zich alleen in de eerste fase bezighouden met het ontwerpen, terwijl de bouwers alleen in bouwfase helpen aan het bouwen van het project. Dit kan leiden tot verspilling van verschillende bronnen. De belangrijkste bron is wel de tijd. Een voorbeeld: de ontwerpers zijn bezig met het perfectioneren van het ontwerp. De bouwers kunnen in principe al beginnen met bouwen, maar omdat ze werken met het watervalmodel moeten ze wachten totdat de eerste fase is afgesloten. Dit een typisch voorbeeld van tijdsverspilling.
• Wanneer frequent gedeelten van het software product worden opgeleverd geeft dit de klant vertrouwen, maar ook het software ontwikkelingsteam.
• Het testen gebeurt pas in een van de laatste fasen van het project. Bij veel andere software-ontwikkelingsmethoden wordt er getest zodra er één bepaald deelproduct klaar is en ook wordt er op het laatst een integratietest gedaan.

Bronnen

Software Engineering van ambacht naar professie, H. Sassenburg (2002), ISBN 9072194640 | 9789072194640