Systeemontwikkeling als proces

Veel analisten nemen deel in een project waarin een nieuw informatiesysteem wordt ontwikkeld. Dit product komt natuurlijk niet vanzelf tot stand; hieraan ligt een proces ten grondslag. In deze blog kijken we naar het proces van systeemontwikkeling. De business analist met een procesbril op (zie blog 'De brillen van de business analist') kijkt niet alleen naar de primaire bedrijfsprocessen, maar kan ook een belangrijke bijdrage leveren aan de totstandkoming en verbetering van systeemontwikkelingsprocessen. Een kwalitatief hoogwaardig SO-proces is namelijk een belangrijke voorwaarde voor een kwalitatief hoogwaardig software product (doch niet de enige). In de meeste organisaties zijn dit secundaire processen (en dus geen core business), maar voor bedrijven die software bouwen en op de markt brengen is dit uiteraard wel het geval. In beide gevallen kan een efficiënt systeemontwikkelings-proces zeer veel geld besparen. In deze blog kijken we naar de bekendste methoden en frameworks voor systeemontwikkeling.

 

CMM(I)

Het Capability Maturity Model (CMM) is een model dat het niveau van het software-ontwikkelingsproces aangeeft. Het model onderscheidt vijf levels (niveaus):

1. Initial: het systeemontwikkelingsproces is chaotisch en ad hoc. Problemen worden pas opgelost als ze zich voordoen. Dit is het niveau dat iedere organisatie aankan.
2. Repeatable is het niveau waarbij de organisatie zover geprofessionaliseerd is (bijvoorbeeld door het invoeren van projectmanagement) dat bij het ontwikkelproces gebruik wordt gemaakt van de kennis die eerder is opgedaan. Beslissingen worden dus genomen op basis van ervaring.
3. Defined is het niveau waarbij de belangrijkste systeemontwikkelingsprocessen zijn gestandaardiseerd (over projecten heen).
4. Managed is het niveau waarbij de kwaliteit van het ontwikkelproces wordt gemeten zodat het kan worden bijgestuurd.
5. Optimizing is het niveau waarbij het ontwikkelproces als een geoliede machine loopt en er alleen maar sprake is van verfijning (de puntjes op de i).

 

Het zal duidelijk zijn dat een project dat gebruikt maakt van een vorm van standaardisatie efficiënter (en plezieriger!) verloopt en producten oplevert van een hogere kwaliteit dan systeemontwikkelingsactiviteiten op level 1. Daarbij weet de ene medewerker niet van de andere wat hij/zij aan het doen is en wat en wanneer er iets wordt opgeleverd. De weg is chaotisch en de kwaliteit van het product is meestal ver onder de maat.

 

Door ervaring in het gebruik is gebleken dat CMM niet alleen een handig hulpmiddel is voor het in kaart brengen en controleren van de volwassenheid van systeemontwikkelingsprocessen maar eigenlijk op alle processen kan worden toegepast. Dit heeft geleid tot het CMMI (met de ‘I’ van Integrated). Meer in een volgende blog over CMMI. In deze blog concentreren we ons uitsluitend op het proces van systeemontwikkeling (CMM dus).

 

De bekendste methodieken en frameworks op een rijtje

Maar hoe kun je CMM(I) als hulpmiddel gebruiken om efficiënter en effectiever te werken? De eerste belangrijke stap is standaardiseren. Door standaardisatie weet je wat je organisatie doet m.b.t. systeemontwikkeling en kun je als het goed is ook bepalen waar eventuele verbeteringen moeten plaatsvinden. Het is echter onzinnig om zelf een nieuw systeemontwikkelingsproces te bedenken. Er worden immers al decennia lang informatiesystemen ontwikkeld en er zijn dan ook diverse standaards in de vorm van frameworks en methodieken ontwikkeld. Het toepassen van standaards zorgt ervoor dat je hoger op de CMM-ladder terechtkomt. Met andere woorden: jouw processen voor systeemontwikkeling worden effectiever en efficiënter. In deze blog passeert een aantal veel gebruikte methodieken en frameworks de revue en in de volgende blogs kijken we wat we hiervan als analist kunnen meenemen in de praktijk.

 

1. Watervalaanpak

De waterval aanpak is het best te vergelijken met een estafette waarin activiteiten sequentieel worden uitgevoerd: in de eerste fase worden alle requirements in kaart gebracht en geanalyseerd, gevolgd door een ontwerpfase waarin functionele/technische ontwerpen worden opgesteld. Dit vormt de basis voor de programmeur die de programmeercode oplevert die tot slot wordt getest door een tester.

 

 

Deze aanpak kent een belangrijk nadeel en dat is dat men ervan uit gaat dat alle requirements op voorhand in kaart gebracht kunnen worden (ook wel aangeduid met de term Big Requirements Up Front of BRUF). In de afgelopen decennia is echter gebleken dat dit in de meeste gevallen onmogelijk is. Zeker in projecten die een jaar of langer duren en waar weinig tussentijdse interactie met de business is gevoerd, blijkt dat het uiteindelijke product niet (meer) voldoet aan de aanvankelijk opgestelde eisen (requirements).

 

Een van de oorzaken hiervan is dat de meeste stakeholders niet op voorhand kunnen verwoorden wat ze precies willen hebben (zie ook IKIWISI verder in deze blog). Gevolg is dat veel requirements pas aan het licht komen als er werkende software wordt opgeleverd en dan is het te laat. In een waterval-aanpak is er namelijk pas terugkoppeling naar de business als het uiteindelijke product maanden later is gebouwd.

 

Een andere oorzaak is dat in veel situaties is gebleken dat requirements vaak nog wijzigen naarmate het project vordert. Aangezien ieder project uniek is, blijkt telkens weer dat alle partijen die betrokken zijn in het project (zowel opdrachtnemer als opdrachtgever) moeten groeien in de materie. Je zou dus kunnen stellen dat ieder project een leertraject is.

 

2. Iteratief incrementeel

Veel beter dan de waterval-aanpak is de iteratief incrementele aanpak. Incrementeel betekent dat je gaandeweg in een project steeds meer functionaliteit toevoegt aan het product, dat wil zeggen: je brengt een eerste deel van de requirements in kaart, bouwt dit en laat het zien aan de stakeholders. Iteratief betekent herhalend: het in kaart brengen van requirements, het bouwen ervan en het uitrollen van functionaliteit vindt dus niet eenmalig plaats zoals in de waterval aanpak, maar herhaaldelijk. In de tweede iteratie voeg je nieuwe functionaiteit toe die je weer bouwt en voortlegt aan de stakeholders, etc. Na een aantal iteraties is een product ontstaan dat aansluit bij de requirements van de stakeholders.

 

Het bekendste iteratief incrementele framework is het Unified Process (UP) dat diverse varianten kent waaronder het Rational Unified Process (afgekort met RUP), Open UP, Agile UP, etc.. UP onderscheidt 4 fasen: Inception – Elaboration – Construction en Transition (weergegeven als kolommen in de onderstaande figuur). Iedere fase heeft een mijlpaal. Aan het eind van een fase dient hieraan voldaan te zijn om aan de volgende fase te kunnen beginnen. In een notendop zijn de mijlpalen per fase:

• Na Inception zijn alle stakeholders in kaart gebracht, plus hun behoeften. Daarnaast is de scope van het nieuwe product afgebakend, zijn de product features bekend en is er consensus tussen de stakeholders m.b.t. de productscope.
• Na Elaboration is er een stabiele software architectuur bedacht en gebouwd (in werkende code).
• Na Construction is het product (potentieel) operationeel.
• Na Transition is het product gereed voor de eindgebruiker en kan worden overgegaan op beheer.

 

 RUP framework

 

De categorieën van werkzaamheden worden aangeduid als Disciplines. RUP onderscheidt 9 Disciplines: Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management en Environment. De werkzaamheden van de analist worden in de figuur weergegeven met de disciplines ‘Business Modeling’ en ‘Requirements’, deze starten in de Inception-fase en eindigen pas in de laatste fase (Transition). De inspanning van iedere Discipline wordt weergegeven door middel van grafiekje: een hoge amplitude betekent veel inspanning en een lage amplitude weinig inspanning. Je kunt dit vergelijken met de grafiekjes in de krant die de hoogteverschillen in de bergetappes van de Tour de France weergeven. Zoals je kunt zien heeft de analist in de Inception-fase het meeste werk.

 

Opmerking: met ‘Analysis & Design’ wordt het ontwikkelen van de software architectuur plus technisch ontwerpen bedoeld, dit mag niet met business analyse-werkzaamheden worden verward).

 

Voor iedere discipline bestaat workflow waarin wordt aangegeven wat iemand met een bepaalde rol doet. Deze workflow is echter beschrijvend en niet voorschrijvend van aard. Dit wil zeggen dat je de processen op maat kunt maken voor je eigen organisatie (sommige elementen zullen wel werken in jouw organisatie en sommige niet, die kun je dan aanpassen).

 

Het belangrijkste verschil tussen (R)UP en de watervalaanpak is dat niet alle requirements in de eerste fase in kaart worden gebracht. Hetzelfde geldt voor de andere disciplines: zij zijn niet geconcentreerd in 1 fase (zoals bij waterval) maar worden gedurende het gehele project parallel aan elkaar uitgevoerd. Programmeren (weergegeven met de Discipline ‘Implementation’, verwar dit a.u.b. niet met de Construction-fase. In deze fase vinden wel veel bouwwerkzaamheden plaats maar er zijn niet uitsluitend bouwwerkzaamheden zoals in een watervalproject!) vindt bijvoorbeeld al plaats in de eerste fase van het project. Voorwaarde hierbij is natuurlijk wel dat de requirements gedetailleerd genoeg zijn. Er is dus nog wel volgtijdelijkheid - je zal eerst in kaart moeten brengen wat er moet komen voordat je kunt bouwen - maar de vele ‘watervalletjes’ zijn veel kleiner.

 

De discipline Business Modeling kan het best vergeleken worden met wat in eerdere blogs is aangeduid met Proces analyse (de analyse van de bedrijfsprocessen). De analist brengt eerst bedrijfsprocessen plus business objecten in kaart en zorgt er vervolgens voor dat de requirements aansluiten bij de gewenste situatie. In een latere blog meer over bedrijfsprocesanalyse.

 

Inception

Hoewel de analist gedurende het gehele project requirements in kaart brengt, is de aard van de analysewerkzaamheden in de eerste fase wel anders dan in de daaropvolgende fasen. In de Inception-fase is de Requirements-discipline vooral gericht op het vinden van de juiste stakeholders plus het op hoofdlijnen in kaart brengen van Needs (stakeholder requirements) en Features (high level system requirements).

 

Op basis van de featurelijst weten alle stakeholders over welke kenmerken het product gaat beschikken zodat duidelijkheid kan ontstaan met betrekking tot het te bouwen product. Met andere woorden: er ontstaat een gezamenlijk perspectief van het product onder de stakeholders (zie de blog 'Perceptie'). De features worden uitgewerkt in een use case model dat de productscope afbakent. Op basis hiervan kan een globale inschatting worden gedaan van de inspanning die het gaat kosten om het product te ontwikkelen. Deze tijdinschatting kan vervolgens worden vertaald in een kosteninschatting die weer de basis is van de business case.

 

In de vervolgfasen (Elaboration en Construction) worden de use cases in detail uitgewerkt als use case specificaties (ook wel use case beschrijvingen of scenarios genoemd).

 

3. Agile

De iteratief incrementele aanpakken zijn de laatste jaren ingehaald door agile aanpakken. Agile betekent ‘wendbaar’ en agile aanpakken zijn vaak niet meer dan een handvol principes en practices. Tot de meest gebruikte agile methodieken en frameworks behoren eXtreme Programming (XP), Dynamic System Development Method (DSDM), Scrum, Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe), Lean Software Development, Kanban, en Disciplined Agile Delivery (DAD).

 

IKIWISI

Zo’n beetje iedereen die tegenwoordig actief is op het gebied van systeemontwikkeling heeft reeds ervaring opgedaan of maakt momenteel de overstap naar agile. Met name Scrum is erg populair. Voordat we verder inzoomen op Scrum, wordt eerst beschreven waarom agile systeemontwikkeling zo populair is geworden. In mijn ogen heeft dit sterk te maken met het IKIWISI-effect.

 

De meeste mensen die ik vraag wat WYSIWYG betekent weten het antwoord wel: ‘What You See Is What You Get’: je modelleert iets en de gebruiker weet wat ie krijgt. Het is een heel belangrijk acroniem in systeemontwikkelingsprojecten. Maar als ik in trainingen vraag wat de betekenis is van IKIWISI krijg ik eigenlijk nooit een antwoord. En dat is vreemd want dit acronym is minstens zo belangrijk als WYSIWYG. IKIWISI staat voor I Know It When I See It. Hiermee wordt bedoeld dat de meeste - zo niet alle - stakeholders grote moeite hebben om vooraf aan te geven wat ze precies willen hebben. Dit betekent niet dat ze helemaal niet weten wat ze willen, maar dat ze met name over de details nog niet hebben nagedacht. En dit is op zich niet vreemd. Denk maar aan de blog 'Perceptie' waarin een olifant als ‘product’ wordt gebouwd. Men weet dat het een middel moet zijn om bomen te vervoeren maar hoe het dier er precies uit gaat zien weet niemand.

 

Paradigmaverschuiving

Dit verklaart ook de populariteit van agile projecten: vaak weten stakeholders pas wat ze willen als ze iets werkends zien: IKIWISI! Door het IKIWISI-effect is een ware paradigma-verschuiving ontstaan: een van de belangrijkste verschillen tussen de traditionele aanpakken (waterval en iteratief incrementeel) en agile aanpakken is het uitgangspunt van een al dan niet fixed scope. Waar traditionele aanpakken er nog vanuit gaan dat de scope vaststaat en dat kosten en tijd daaruit worden afgeleid (het linker plaatje), gaan Agile aanpakken uit van het time-box-principe waarbij zowel kosten als tijd vaststaan en dat de productscope hiervan afgeleid dient te worden (het rechter plaatje). Dit betekent dat je binnen de beschikbare hoeveelheid tijd en geld een bepaalde hoeveelheid software kunt opleveren van een (liefst) hoge kwaliteit. De exacte hoeveelheid hangt uiteraard voor een groot deel af van de snelheid van het ontwikkelteam.

 

 

Agile Manifesto

In februari 2001 kwamen 17 vooraanstaande software engineers bijeen in Utah om verschillende lichtgewicht softwareontwikkelmethodieken te bespreken. Dit leidde tot de publicatie van het Manifesto for Agile Software Development, waarin hun gemeenschappelijke ervaringen met betrekking tot systeemontwikkeling uiteen werden gezet. Ze stelden:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Hoewel ze het belang inzagen van de tweede punten, stelden ze dat de eerstgenoemde punten kritiek zijn voor succes.

 

Scrum

Van alle agile methoden en frameworks is Scrum momenteel de meest populaire. In mijn ogen heeft dit te maken met het feit dat Scrum in theorie bijzonder eenvoudig is. The Scrum Guide beslaat welgeteld 16 pagina’s!

 

Scrum Framework

 

Bij Scrum zitten de leden van het ontwikkelteam meestal in één ruimte, zodat er makkelijk kan worden gecommuniceerd (zie het Agile Manifesto). Het team wordt begeleid door een Scrum Master, die zorgt dat het team zich aan de spelregels van Scrum houdt en kan doorwerken. De Scrum Master is geen manager van het team (zoals een project manager in een PRINCE2-project) maar een facilitator. De Product Owner is de ‘opdrachtgever’: voor hem/haar (en voor de stakeholders namens wie de PO spreekt) wordt het product gemaakt. Hij of zij is ook degene die aangeeft wat er gemaakt moet worden en wanneer. Meestal worden hiervoor user stories gebruikt, die op een product backlog worden gezet. De product backlog is een door de Product Owner samengestelde lijst die wordt gesorteerd op prioriteit. De user stories (of epics) met de hoogste prioriteit staan bovenaan. Deze worden opgenomen in de sprint backlog, een lijst met requirements en taken voor de volgende sprint. Een sprint is een iteratie van 1 dag tot uiterlijk 4 weken waarbinnen de user stories door het ontwikkelteam omgezet in werkende software (inclusief documentatie).

 

Aan het einde van elke sprint is er een "Sprint Review“ (of demo) waarin het product aan de Product Owner plus stakeholders wordt getoond. Daarna volgt nog een Sprint Retrospective waarin het team probeert lessen te trekken uit de afgelopen sprint, zodat men steeds beter wordt.  

 

Geen estafette maar een schaatsteam

Waar de watervalaanpak met een estafette kan worden vergeleken, zo kan een agile-team worden vergeleken met een schaatsteam waarin de teamleden (met verschillende specialismes waaronder: analist, UX designer, bouwer, tester, etc.) tegelijkertijd actief zijn.

 

 

Samenvatting

In deze blog zagen we dat analisten een belangrijke bijdrage kunnen leveren in de totstandkoming van een efficiënt systeemontwikkelingsproces. Het is belangrijk dat iedere analist zich realiseert dat standaardisatie een belangrijke rol speelt om hoger op de CMM-ladder te komen. Door standaardisatie kunnen verbeteringen optreden van het ontwikkelproces hetgeen weer leidt tot kwalitatief hogere softwareproducten. Tegenwoordig zijn de meest gebruike standaards en frameworks agile van aard, maar er zijn ook lessen te leren vanuit de meer traditionele aanpakken zoals RUP. Meer hierover in een volgende blog.