Projectfasering
De projectfases bestaan uit zes fasen, gescheiden door vier 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. De fasering is dan ook geen directe vertaling van PRINCE2-stages of PMI-processen, maar sluit er functioneel op aan. Hetzelfde geldt voor business analyse, informatie-analyse en requirements engineering: het opstellen van de volledige requirementsset is geen architectuuractiviteit en valt buiten deze werkwijze. De werkwijze gebruikt het resultaat als input om de architectuurbepalende eisen te selecteren.
De scope van de gates en het behalen van een status moet daarom worden gelezen vanuit het perspectief van architectuur en architectuursturing, de activiteiten dragen bij aan het behalen van een status voor het deel van de architectuur.
Toepassingsgebied
Deze projectlevenscyclus is bedoeld voor projecten waarin een bestaand softwaresysteem wordt aangeschaft, geconfigureerd of uitgebreid, zoals de selectie, inrichting en implementatie van standaardsoftware (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 softwaresysteem binnen het applicatielandschap, de benodigde integraties en de belangrijkste architectuur- en kwaliteitskeuzes. De interne werking van het softwaresysteem wordt daarbij niet verder uitgewerkt.
Ook het programma van eisen blijft op een hoger abstractieniveau. Het beschrijft welke functionaliteit en kwaliteitseisen het softwaresysteem 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 softwaresysteem, 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.
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 het gewenste systeem 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. Het high-level design is daarbij geen op zichzelf staand architectuurdocument, maar onderdeel van een breder besluitvormingsdocument voor het traject als geheel. Ook het identificeren en betrekken van stakeholders, en het stakeholdermanagement dat daarop volgt, is geen specifiek architectuuronderdeel: dat geldt voor het volledige project, niet alleen voor de architectuur.
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.