Project levenscyclus
Project Lifecycle
De projectlevenscyclus bestaat uit zes fasen, gescheiden door vijf beslismomenten (gates). Elke gate markeert een gecontroleerde overgang naar de volgende fase: van initiatief en eisen, via ontwerp, realisatie en validatie, tot een stabiele en beheerde oplossing. De gates zijn risicogestuurd: projecten die binnen de architectuurkaders (guardrails) blijven, stromen grotendeels automatisch door. Alleen afwijkingen of uitzonderingen worden expliciet beoordeeld, waardoor architectuursturing en projectgovernance elkaar op de juiste momenten versterken.
Beschrijving
De projectlevenscyclus beschrijft hoe de architectuur van een oplossing (de solution-architectuur) binnen een project tot stand komt: van het eerste idee tot een werkende en gevalideerde oplossing. Het proces bestaat uit zes opeenvolgende fasen. Elke fase levert een concreet resultaat op. Pas wanneer dit resultaat is beoordeeld en goedgekeurd bij een gate, start de volgende fase.
De fasen volgen elkaar bewust op. Eerst bepalen we de richting en de eisen, daarna werken we het ontwerp uit, bouwen we de oplossing, valideren we deze en nemen we haar in gebruik. Zo ontstaat stap voor stap een oplossing waarvan de kwaliteit en samenhang aantoonbaar zijn.
Reikwijdte
Deze levenscyclus richt zich uitsluitend op de architectuur binnen een project. Ze beschrijft welke architectuuractiviteiten in elke fase plaatsvinden, welke resultaten worden opgeleverd en wanneer deze gereed zijn om naar de volgende fase te gaan.
Projectmanagement valt buiten de scope van deze levenscyclus. Zaken zoals planning, budget, risicomanagement, teamsturing en voortgangsbewaking blijven onderdeel van de gebruikte projectmanagementmethode, zoals PRINCE2 of PMI/PMBOK.
Toepassingsgebied
Deze projectlevenscyclus is bedoeld voor projecten waarin een bestaand softwaresysteem wordt aangeschaft, geconfigureerd of uitgebreid, zoals de selectie, inrichting en implementatie van een standaardsoftwarepakket (COTS).
Bij dit type projecten blijft de solution-architectuur bewust op een hoger abstractieniveau dan bij softwareontwikkeling. De architectuur beschrijft de gewenste inrichting van de oplossing, de plaats van het pakket binnen het applicatielandschap, de benodigde integraties en de belangrijkste architectuur- en kwaliteitskeuzes. De interne werking van het pakket wordt daarbij niet verder uitgewerkt.
Ook het programma van eisen blijft op een hoger abstractieniveau. Het beschrijft welke functionaliteit en kwaliteitseisen het pakket moet ondersteunen, maar bevat niet de gedetailleerde requirements die nodig zijn om software te ontwikkelen. Omdat de oplossingsruimte grotendeels wordt bepaald door de mogelijkheden van het gekozen pakket, is de kans op wijzigingen tijdens het project relatief klein. Daardoor sluit een sequentiële aanpak met formele besluitmomenten (gates) goed aan op dit type implementatietraject.
Voor projecten waarin nieuwe software wordt ontwikkeld of bestaande software ingrijpend wordt aangepast, is een andere projectlevenscyclus beter geschikt. In dergelijke projecten wordt de solution-architectuur veel verder uitgewerkt en vormen gedetailleerde requirements de basis voor de ontwikkeling. Nieuwe inzichten tijdens het project leiden daarbij vaker tot wijzigingen in ontwerp en implementatie, waardoor een meer iteratieve ontwikkelaanpak beter past.
Opbouw van de fasen
Elke fase bestaat uit drie onderdelen:
- Activiteiten – het werk dat in de fase wordt uitgevoerd, inclusief de gebruikte input en de opgeleverde resultaten.
- Status – de voortgang van de architectuur, bijvoorbeeld van een eerste richting via een uitgewerkt ontwerp naar een bewezen oplossing.
- Gate – het formele beslismoment waarop wordt vastgesteld of de fase succesvol is afgerond en de volgende fase kan starten.
Niet iedere fase heeft een eigen gate. Zo vormen de ontwerp- en implementatiefase één logisch geheel en worden deze gezamenlijk afgesloten met Gate 3: System Usable.
Relatie met projectmanagement
De projectlevenscyclus sluit aan op de projectbesturing via de gates. Iedere gate verwijst naar de practice Architectuursturing, waarin wordt gewerkt met vooraf vastgestelde guardrails, zoals architectuurprincipes en de paved road. Zolang een project binnen deze kaders blijft, kunnen beslissingen zonder aanvullende beoordeling worden genomen.
Alleen wanneer een project bewust afwijkt van de afgesproken kaders (off-road) of een belangrijke, onomkeerbare architectuurbeslissing neemt, is een expliciete beoordeling nodig. Een gate controleert daarom niet het hele project opnieuw, maar toetst of dergelijke uitzonderingen correct zijn beoordeeld en goedgekeurd.
Wanneer een afwijking uitsluitend gevolgen heeft voor de architectuur, vindt de besluitvorming plaats binnen Architectuursturing, bijvoorbeeld door de Architectuursponsor of het Architectuurforum. Heeft de afwijking ook invloed op planning, budget, scope of risico's, dan wordt de besluitvorming gedeeld met de projectgovernance, zoals de Stuurgroep (PRINCE2) of de Sponsor (PMI/PMBOK). De wijze waarop dat gezamenlijke besluit tot stand komt, wordt bepaald door de gebruikte projectmanagementmethode en valt buiten deze levenscyclus.
De fasen in deze levenscyclus zijn daarom geen directe vertaling van PRINCE2-stages of PMI-processen, maar sluiten er functioneel op aan.
Fasen en activiteiten
In de eerste fase wordt de basis gelegd voor het vervolg van het traject. Voordat inhoudelijke keuzes worden gemaakt, moet duidelijk zijn waarom het traject wordt gestart, welk doel het heeft, wat de gewenste resultaten zijn en welke belanghebbenden daarbij betrokken zijn.
Het doel van deze fase is om de context te begrijpen, de uitgangspunten vast te stellen en een gezamenlijke visie op de gewenste oplossing of verandering te formuleren. Daarbij wordt aangesloten op de geldende organisatiekaders, beleidsuitgangspunten en eerder genomen besluiten.
Aan het einde van deze fase is er een gedeeld beeld van de opgave, de scope, de belangrijkste stakeholders en de richting waarin het traject zich moet ontwikkelen. Deze visie vormt het fundament voor alle volgende fasen en wordt formeel vastgesteld voordat het traject verdergaat.
In deze fase worden de behoeften van de organisatie, gebruikers en andere stakeholders vertaald naar functionele en niet-functionele requirements. Als uitgangspunt worden de functionele requirements beschreven in de vorm van use cases. Elke use case beschrijft een concreet gebruiksdoel, de betrokken actoren en de interactie met de oplossing, zodat duidelijk wordt welke functionaliteit de oplossing moet bieden en in welke context deze wordt gebruikt. Naast de functionele requirements worden ook de niet-functionele requirements beschreven zoals kwaliteitseisen en overige randvoorwaarden.
Het doel van deze fase is om een complete, consistente en begrijpelijke set requirements op te leveren die de basis vormt voor de analyse- en ontwerpfase. Door de functionele requirements als use cases te beschrijven, ontstaat een gedeeld begrip van het gewenste gebruik van de oplossing en kunnen de architectuurbepalende requirements in de volgende fase worden geanalyseerd en vertaald naar een passend ontwerp.
Aan het einde van deze fase zijn de requirements formeel vastgesteld en vormen zij de input voor de analyse- en ontwerpfase.
In deze fase worden de verzamelde wensen, eisen en randvoorwaarden geanalyseerd en wordt vastgesteld welke daarvan bepalend zijn voor de verdere uitwerking van de oplossing. Niet iedere eis heeft dezelfde impact; de nadruk ligt op de eisen en uitgangspunten die richting geven aan de architectuur- en ontwerpkeuzes in het vervolg van het traject. Deze eisen worden geselecteerd, geprioriteerd en afgestemd met de betrokken stakeholders, zodat een helder en gedragen kader ontstaat waarbinnen de oplossing wordt ontworpen en gerealiseerd.
Vervolgens wordt de gekozen oplossingsrichting uitgewerkt tot een volledig, samenhangend en realiseerbaar ontwerp. Op basis van de vastgestelde eisen en uitgangspunten worden de architectuur, structuur en technische keuzes verder uitgewerkt, zodat duidelijk is hoe de oplossing zal worden gerealiseerd. Alle belangrijke ontwerpbeslissingen worden daarbij vastgelegd en onderbouwd, zodat de realisatie gecontroleerd en consistent kan plaatsvinden.
Aan het einde van deze fase zijn zowel de leidende eisen en uitgangspunten als het volledige ontwerp formeel vastgesteld. Daarmee is een eenduidig toetsingskader beschikbaar voor de realisatie en de daaropvolgende validatie, en is de oplossing gereed om in de volgende fase te worden gerealiseerd.
In deze fase wordt het ontwerp daadwerkelijk gerealiseerd. De oplossing wordt gebouwd, geconfigureerd of ingericht volgens het vastgestelde ontwerp. Tijdens de uitvoering wordt bewaakt dat de realisatie blijft voldoen aan de gemaakte afspraken, ontwerpkeuzes en geldende kaders.
Het doel van deze fase is om de oplossing gecontroleerd te realiseren en de belangrijkste ontwerpkeuzes in de praktijk te verifiëren. Waar nodig worden risico's vooraf verminderd door bijvoorbeeld een proefopstelling, prototype of andere vorm van validatie.
Aan het einde van deze fase is de oplossing gerealiseerd en is aangetoond dat de belangrijkste technische en architectonische keuzes uitvoerbaar zijn. Daarmee is de oplossing gereed voor de integrale validatie in de volgende fase.
In deze fase wordt vastgesteld of de gerealiseerde oplossing als geheel voldoet aan de gestelde eisen, de afgesproken uitgangspunten en de beoogde doelstellingen. De verschillende onderdelen functioneren niet alleen afzonderlijk, maar vormen samen een samenhangende en werkende oplossing.
Het doel van deze fase is om aan te tonen dat de oplossing gereed is voor ingebruikname. Door middel van integrale validatie en acceptatie wordt vastgesteld dat de oplossing voldoet aan de kwaliteitscriteria en geschikt is voor de beoogde bedrijfsvoering.
Aan het einde van deze fase is de oplossing als geheel gevalideerd en formeel geaccepteerd. Daarmee kan de volgende fase, waarin de oplossing in productie wordt genomen en wordt overgedragen aan de beheerorganisatie, worden gestart.