|
|||
Omschrijving:
Bij een op maat gesneden ontwikkelaanpak hoort een zogenaamde Single Point Of Definition (SPOD): één plek waar we de uitgangspunten en resultaten in samenhang brengen en houden. Requirements staan hierbij centraal als startpunt én eindpunt van een project en als bindmiddel tijdens het project. Waarom projecten mislukken
Resultaten van projecten sluiten in de praktijk vaak niet aan op de verwachtingen van de klanten. Te duur, te laat, niet wat we wilden, het is dagelijkse praktijk. Oorzaken van dit soort problemen zijn veelal gerelateerd aan onduidelijkheid over de behoeften van de stakeholders en over de mate waarin daarin wordt voorzien. In onderzoeken naar het falen van projecten worden meestal requirements-gerelateerde problemen als hoofdoorzaak aangeduid. Zie hieronder de resultaten van het onderzoek van het Chaos Report van The Standish Group. In alle bescheidenheid stellen we dat de aanpak in dit webboek veel van dat soort problemen voorkomt.  Figuur: Chaos Report van The Standish Group Single Point of Definition
Om problemen als hierboven geschetst te voorkomen, is naast een op maat gesneden ontwikkelaanpak een zogenaamde Single Point Of Definition (SPOD) vereist. Een SPOD is simpel gezegd één plek waar de uitgangspunten en resultaten in samenhang worden gebracht en gehouden. Zo wordt voorkomen dat er ruis op ruis ontstaat als de resultaten van de ene fase over de muur worden gegooid naar de volgende fase. En dat wat ooit bedacht is door veranderende inzichten achterhaald raakt.
SPOD: requirements centraal
Een SPOD hebben we als volgt gevisualiseerd:
Rondom zien we de aspecten van de bedrijfsvoering, ofwel de kolommen van het raamwerk: product, proces, etcetera. Centraal staan de requirements, en wel om twee redenen. 1. Requirements definiëren we als de behoeften van alle stakeholders en daarmee het startpunt van een project. Ze zijn de reden waarom het project in het leven is geroepen; ze definiëren het eindresultaat van het project. Ze vormen de basis voor de ontwerpen: die moeten voldoen aan de requirements. De high level requirements waar het project mee start worden steeds verder uitgedetailleerd tot ze voldoende specifiek zijn om te dienen als uitgangspunt voor de ontwerpen.
 2. Daarnaast zijn requirements het bindmiddel in het raamwerk. Requirements veranderen voortdurend door o.a. ontwerpbeslissingen.
Hierdoor ontstaat een zeer dynamisch spel: requirements veranderen dus per definitie gedurende het project. Tijdens de ontwerpfase zullen door ontwerpbeslissingen de requirements (‘gebaselined’ of niet) veranderen. En in de realisatiefase, testfase en implementatiefase kan dit vanzelfsprekend ook nog gebeuren. Bovendien zitten de stakeholders ook niet stil in de tussentijd; ook hun behoeften veranderen gedurende de looptijd van het project.
Wijzigingen en aanvullingen komen dus van boven en van onder. En aan het eind van het project moet het project hebben voorzien in die gewijzigde behoeften. Dus moet er getest zijn op basis van de requirements, en moet er geïmplementeerd zijn op basis van de requirements. Daarom moeten requirements centraal en in samenhang met de ontwerpen worden gemanaged.
Processen rondom een SPOD
De hoofdprocessen rondom een SPOD zijn: 1. Projectarchitectuur management 2. Requirements management 3. Configuration management 4. Change management Als onderdeel van de ontwikkelaanpak beschouwen we: 1. Requirements development / integrale analyse 2. Integraal ontwerp: product, PAGO, besturing Op de hoofdprocessen rondom de SPOD gaan we hieronder in. Projectarchitectuur management • Het ontwikkelen van een projectarchitectuur obv de enterprise architectuur (ontwerp op hoofdlijnen op alle kolommen / alle bladeren van de bloem) • Inhoudelijk regie op de ontwikkelingen in het project • Het assisteren, faciliteren en meewerken aan projectproducten die een directe relatie met de projectarchitectuur hebben • Het toetsen van projectproducten op compliance aan de projectarchitectuur Requirements management • Het (laten) administreren van de requirements zelf (vanuit requirements development) • Het kwalitatief toetsen van requirements (SMART-ness) • Het administreren van traceability tussen de requirements, d.w.z. het leggen van relevante links tussen high level business requirements en ondergelegen requirements, tot aan bv systeemspecificaties. Dit is een uiterst belangrijke verantwoordelijkheid van requirements management. Een waarschuwing is hier zelfs op z’n plaats: requirements onderling koppelen en requirements koppelen aan ontwerpen is arbeidsintensief en overtraceability is een gevaar: dat is de ongewenste situatie waarin ‘alles met alles’ in samenhang is gebracht, waardoor de impactanalyse van de kleinste requirement change leidt tot onnodig veel uitzoekwerk. Het leggen en onderhouden van traces vereist ervaring. • Versiemanagement & change management op individuele requirements • Baselining (bevriezen van sets van requirements als gemeenschappelijke basis) • Status tracking van requirements in de vervolgfases • Het bewaken van compleetheid en consistentie (te beginnen met definities, thesaurus) • Het verzorgen en faciliteren van impactanalyses van changes • Het verzorgen van rapportages over bv voortgang versus de requirements Configuration management Versiemanagement op alle specialist products, in samenhang met de requirements management administratie. In de meeste projecten vormen de procesontwerpen de kern. Voor deze projecten stellen wij dus voor om de requirements administratie te koppelen aan de procesmodellen. In welke mate en in wel detail is afhankelijk van de situatie (zie verder). Change management Changes op bovenliggende requirements of onderliggende (proces)ontwerpen worden centraal gemanaged volgens een project change management proces. Voor deze processen zijn specifieke kennis, vaardigheden en middelen nodig. Vooral requirements management staat nog in de kinderschoenen. Bovendien zijn het arbeidsintensieve processen. Toch zien we de laatste jaren steeds meer ontwikkelingen in de goede richting. Zo ontstaat er steeds betere tooling op de markt. Requirements administratie
De kern van de SPOD, de centrale administratie voor eisen en ontwerp, zijn de requirements aan het project. Er zijn vele en uitgebreide definities van het woord requirement, maar wij gebruiken: requirements zijn de behoeften van alle stakeholders. Met behoeften omvatten we eisen, wensen én verwachtingen. Met stakeholders omvatten alle belanghebbenden: sponsor, eigenaar, gebruikers, leveranciers, operationeel beheerders, functioneel beheerders, technisch beheerders, infrastructuur en natuurlijk, zeer relevant voor dit webboek: architectuur Om alle behoeften van alle stakeholders in samenhang te kunnen brengen is het zaak één centrale administratie van de requirements te voeren. In die requirementsdatabase worden: • alle requirements • van alle stakeholders - sponsor, gebruikers, leveranciers, beheerders, architectuur • van alle typen - business req´s, user req´s, non-functional req´s, systeemreq´s, security req´s • van alle niveaus - van high level requirements t/m detailspecificaties • in samenhang - traceability • vastgelegd - standaard, templates, SMART-ness • geprioriteerd - MoSCoW (must, should, could, would like to have) • bijgehouden - version control, change control • en gevolgd - status tracking Requirements moeten dus van hoog tot laag in samenhang vastgelegd worden, waardoor een zogenaamde requirements tree ontstaat. Het is noodzakelijk hierin structuur aan te brengen, en verschillende typen requirements vast te stellen voor het specificieke project. Heel verschillende typen requirements zijn bijvoorbeeld: business requirements, architectuurprincipes, user requirements, functionele specificaties. Een opdrachtgever is in de functionele specificaties niet geinteresseerd en een functioneel ontwerper kan niets met de business requirements zoals ze bij de start van een project door de klant zijn opgesteld. Verschillende typen requirements hebben dan ook verschillende eigenaren. Er zijn vele typen requirements en het nut van groeperen en structureren is het kunnen besturen van het requirements development en het requirements management proces. Een waarschuwing is echter op z’n plaats:verlies niet te veel tijd aan discussies over van welk type een requirement is. Bij het structureren helpt een model. Sogeti hanteert voor zijn dienst Requirements Lifecycle Management het volgende bruikbare model in een piramidevorm. Daarmee benadrukt men de samenhang van verschillende typen requirements op verschillende niveaus, maar ook de omvang van sets requirements die zullen ontstaan: veel meer specificaties versus slechts enkele top-requirements.  Figuur: Requirements structuur volgens Sogeti Reageer op dit artikel
Nog geen reacties op dit artikel.
Nog geen bijlagen op dit artikel.
|
||
|
©2008 Webboek Bedrijfsvoering All rights reserved.
|
