Module 6 - Systeemontwikkeling
Informatica
Aanbevolen voor jou
Reacties
Preview tekst
Informatica Module 6 Paragraaf 3
3 De drie stappen van systeemontwikkeling
- stap A: de eerste aanzet en de wens om te automatiseren;
- stap B: de realisatie van het nieuwe informatiesysteem;
- stap C: gebruik en beheer van het nieuwe informatiesysteem. In stap A ben je vooral bezig met het analyseren van de bestaande situatie, het vastleggen hoe dat beter kan en daar een plan (het informatieplan) voor opstellen. Ook denk je na over de gevolgen van de geplande veranderingen. In stap B werk en voer je het plan verder uit. Je gaat nu het te ontwikkelen systeem daadwerkelijk bouwen. Maar daarmee eindigt het traject nog niet. In stap C wordt het systeem in stand worden gehouden en door de gebruikers optimaal gebruikt. Stap C stopt eigenlijk pas als het systeem niet meer gebruikt wordt.
3 Stap A: de eerste aanzet
In stap A wordt vanuit een initiatief om tot verbetering van het informatiesysteem te komen, nagedacht over het gewenste resultaat en over het ontwerp.
3.2 Het informatieplan
Uitgaande van het informatiebeleid maak je allerlei concrete plannen, die uitmonden in het informatieplan. Daarin staat wat je wilt doen om de problemen in de informatievoorziening op te lossen. In een schema ziet dat er zo uit:
Informatieplannen zijn afgeleid van het informatiebeleid.
Voorbeeld De directie van het café-restaurant heeft geconstateerd dat het bestaande informatiesysteem niet goed functioneert. Vervolgens is er nagedacht over de verbetering van het systeem. De directie heeft iets aan haar informatiebeleid toegevoegd, namelijk het denken over de informatiestromen in haar organisatie.
Een informatieplan houdt zoals gezegd niet automatisch in dat er nieuwe hard- of software wordt aangeschaft. Een informatieplan kan bijvoorbeeld ook betekenen:
- een technische wijziging aan de telefooninstallatie, waardoor de informatie-uitwisseling binnen een bedrijf verbeterd wordt;
- verandering van de organisatiestructuur om andere vormen van overleg tussen verschillende leden van de organisatie mogelijk te maken.
Voorbeeld Het plan van het café-restaurant is het veranderen van de procedures en het inschakelen van apparatuur.
3.2 De gevolgen van een systeemontwikkeltraject
Het is al vaker gezegd dat een systeemontwikkelingsproject grote gevolgen heeft voor de organisatie. Een bedrijf moet hier expliciet rekening mee houden als het een project gaat opzetten.
We kunnen de gevolgen onderverdelen in: organisatorische gevolgen (met daaraan gekoppeld: sociale gevolgen); financiële gevolgen; technische gevolgen.
Organisatorische gevolgen De invoering van een nieuw informatiesysteem heeft vaak tot gevolg dat functies veranderen of zelfs verdwijnen. Voor de betrokken medewerkers betekent dit dat hun baan anders wordt of zelfs vervalt. Dit roept vaak weerstand op, vandaar dat een goede begeleiding van de toekomstige gebruikers van het systeem essentieel is voor het slagen van het project.
Voorbeeld De manager van het café-restaurant heeft waarschijnlijk minder medewerkers nodig als hij de smartphone-app invoert. Want de serveersters zijn dan veel minder tijd kwijt aan het heen en weer lopen en aan het opstellen van rekeningen. Als er medewerkers worden ontslagen, is er niet alleen sprake van organisatorische, maar ook van sociale gevolgen.
Financiële gevolgen Voor het ontwikkelen van een nieuw informatiesysteem zijn altijd extra uitgaven nodig. Vaak is er nieuwe of extra hardware nodig en bijna altijd moet er software worden aangeschaft of ontwikkeld. In de praktijk moet er een budget voor een project worden vastgesteld. Hiervan kunnen alle onkosten, zoals personeelskosten en hard- en software, worden betaald. Dit betekent dat er voor de start van elk project een kosten-batenanalyse moet worden gemaakt. Op basis hiervan kan een opdrachtgever beslissen of het project moet worden uitgevoerd. Dit kostenplaatje moet zorgvuldig worden bepaald. Immers, wanneer je een te laag bedrag opgeeft, krijg je in een later stadium een budgetoverschrijding en kom je zelf in de problemen. Wanneer je een te hoog bedrag opgeeft, loop je het risico dat het project niet wordt uitgevoerd.
Technische gevolgen Ook de technische gevolgen moeten vooraf worden onderzocht. Vaak moeten er voor het nieuwe informatiesysteem aanpassingen aan de bestaande infrastructuur gemaakt worden. Denk aan uitbreiding van het computernetwerk of een nieuwe telefooncentrale. Zulke
maar ook naar zaken als het budget, de tijdsbesteding en de kwaliteit van het project als geheel. Zo kun je steeds in de gaten houden of het project in al die opzichten nog op schema loopt. En als blijkt dat dit niet zo is, dan kun je het project bijstellen. Op die manier voorkom je een herhaling van moeilijkheden of fouten, of de gevolgen ervan. Bovendien kun je aan de hand van het rapport per fase beoordelen of je de doelstellingen die je in het plan van aanpak geformuleerd had, hebt gehaald.
3.3 Bewaak en verbeter het project
Je toetst voor het evaluatierapport dus of je je doelstellingen gehaald hebt en je evalueert de fasen. Als blijkt dat zaken beter kunnen, dan doe je daarvoor aanbevelingen. Deze aanbevelingen kun je gebruiken in de volgende fase van het project. Als je de aanbevelingen volgt, zal het project verbeteren. Je bewaakt op deze manier dus het verloop van je project.
3.3 Verdeel de rollen
Dat het project wordt uitgevoerd volgens de gemaakte afspraken en binnen de gestelde grenzen - met andere woorden: volgens het projectplan - is de verantwoordelijkheid van de stuurgroep en de projectgroep. Zie paragraaf 2.4 van deze module.
Een projectleider kiezen Er zijn verschillende mogelijkheden bij het kiezen van de projectleider: Als het project grotendeels betrekking heeft op de werkzaamheden van één bepaalde afdeling (de overige afdelingen zijn er slechts zijdelings of niet bij betrokken), dan wordt meestal het hoofd van die afdeling de projectleider. Als verschillende afdelingen afhankelijk zijn van het projectresultaatdan moet de projectleider iemand zijn die objectief tegenover alle partijen staat en die voldoende ervaring heeft in het leiden van een automatiseringsproject. Dit stelt behoorlijk zware eisen aan de projectleider. Vaak wordt er dan een projectleider van buiten het bedrijf ingehuurd.
3.3 Beslis of het project doorgaat
Voorbeeld Het plan van het café-restaurant is het veranderen van de procedures en het inschakelen van apparatuur.
In de verschillende fasen moet steeds besloten worden of het project moet stoppen of doorgaan. De opdrachtgever of stuurgroep doet dit in overleg met de projectleider. Het is niet de deskundige op automatiseringsgebied die beslist of de ontwikkeling verder gaat. Wel levert hij belangrijke informatie om een beslissing mogelijk te maken. Meestal gebeurt dit in de vorm van rapporten. Als het besluit in de voorafgaande fasen steeds positief is, dan vindt op een bepaald moment de realisatie plaats. Het informatiesysteem wordt dan (gedeeltelijk) geautomatiseerd: de software wordt geschreven en eventuele hardware wordt ontwikkeld. De realisatie noem je ook wel de daadwerkelijke bouw van het informatiesysteem.
3.3 Kies de juiste methode
Kies de juiste methode Aandachtspunten Om een informatiesysteem te ontwikkelen dat voldoet aan de wensen, op tijd klaar is en
binnen de geraamde kosten blijft, is het noodzakelijk om aandacht te besteden aan:
- de methode
- de technieken
- het gereedschap
- de operationele standaarden. Een van de belangrijkste zaken bij systeemontwikkeling is het kiezen van een goede methode. Net als bij het bouwen van een schip moet je bij systeemontwikkeling eerst onderzoeken wat er precies moet gebeuren voordat je kunt gaan programmeren. Je moet bepalen welke werkzaamheden allemaal uitgevoerd moeten worden, welke hulpmiddelen je nodig hebt en wat de juiste volgorde is waarin de werkzaamheden moeten worden uitgevoerd. Bij elkaar noem je dit de methode.
Voorbeeld Als je een schip gaat bouwen, dan moet je de vorm en indeling bepalen. Maar voordat je daadwerkelijk kunt gaan bouwen, moet je de bouwwijze vaststellen. Je kunt er bijvoorbeeld voor kiezen om het schip 'met de hand' te bouwen, zoals in Kampen bij de reconstructie van een kogge is gebeurd. Meer informatie vind je op kamper-kogge.
Systeemontwikkelingsmethoden Er zijn verschillende systeemontwikkelingsmethoden, waaronder SDM en PRINCE2 en Scrum. Deze hebben betrekking op het gehele traject van systeemontwikkeling. Informatieanalyse Daarnaast zijn er verschillende methoden waarmee de fase van de informatieanalyse kan worden uitgevoerd. Hiertoe behoren:
- FCO-IM
- ERM
- UML (zie hoofdstuk 3 van module 7). Schematechnieken Elke methode is gebaseerd op speciale schematechnieken. Bij vrijwel iedere methode wordt gebruik gemaakt van specifieke diagrammen. FCO-IM is een methode waarmee je een informatiemodel kunt maken. Op grond van dit model kan dan automatisch een ERM worden gegenereerd. ERM is een manier waarop je grafisch de relaties tussen entiteiten kunt weergeven. Hierdoor kun je de juiste tabellen in een database maken. Dit kan in sommige CASE-tools ook weer geautomatiseerd. UML geeft structuur en schematechnieken voor het ontwerpen van objectgeoriënteerde systemen. Voordat je met ontwerpen begint, moet je eerst zorgvuldig bepalen welke methode voor het te ontwikkelen informatiesysteem het meest geschikt is.
3.3 Kies de juiste techniek
We maken onderscheid tussen methode en techniek. De methode geeft aan wát je doet en in welke volgorde, terwijl een techniek aangeeft hóe je het doet.
Voorbeeld Bij het bouwen van een schip geeft de methode aan dat je de romp bouwt van staalplaten, terwijl je als techniek kiest om die platen aan elkaar te bevestigen met een bepaalde lastechniek.
Een voorbeeldscherm van een CASE-tool.
3.3 Maak afspraken over de uitvoering
Als eenmaal de methode, de technieken en het gereedschap zijn bepaald, zullen degenen die bij het systeemontwikkelingsproject betrokken zijn ook afspraken moeten maken over hoe ze gezamenlijk met deze zaken omgaan. Deze afspraken hebben bijvoorbeeld betrekking op: de scherm-layout die gehanteerd moet worden; de coding conventions: afspraken over bijvoorbeeld commentaar en naamgeving; de versienummering. Alle afspraken over de technieken en andere werkzaamheden noemen we operationele standaarden.
3 Stap C: gebruik en beheer van het informatiesysteem
Als je op internet zoekt op risico en gevaar van achterhaalde technologie dan vind je in Computable een voorbeeld uit de praktijk.
3.4 De invoering van het informatiesysteem
Als de automatisering voltooid is, zullen de automatiseerders hun taak als beëindigd beschouwen. De organisatie gaat het systeem geleidelijk overnemen en we gaan over naar stap C: het gebruik en beheer van het systeem. Kortom, de invoering van het systeem moet worden geregeld. De organisatie is vanaf deze stap helemaal zelf verantwoordelijk voor het systeem: de ontwikkeling is afgerond en de acceptatietest is uitgevoerd. Als je ergens voor verantwoordelijk bent, dan zul je niet alleen alle mogelijkheden van het systeem moeten kennen, maar ook moeten leren omgaan met de onvolkomenheden ervan. Waar nodig zal het systeem aangepast moeten worden. Er zal waarschijnlijk een training nodig zijn voor de gebruikers van het nieuwe systeem. Zij moeten leren hoe het nieuwe systeem werkt, hoe de apparatuur bediend moet worden en wat de verdere consequenties zijn van de invoering van het systeem. Meestal wordt er een garantieperiode afgesproken: fouten die in die periode aan het licht komen worden kosteloos hersteld. Verder is het heel belangrijk dat ook op de lange termijn ondersteuning moet worden verleend. Vaak is het zo dat bij een update van het besturingssysteem ook een update van de software voor het informatiesysteem moet plaatsvinden. Wanneer op software geen support meer gegeven wordt, kan het ook een gevaar gaan opleveren voor de veiligheid van andere programma’s.
Voorbeeld In ons voorbeeld van het Scheveningse café-restaurant moet de bediening met een smartphone-app en een nieuw afrekensysteem gaan werken. Dit betekent dat het moeilijker wordt om aan speciale wensen van de klant te voldoen. Als een uitsmijter standaard met spiegeleieren wordt geserveerd en de klant vraagt of de dooiers doorgeprikt kunnen worden, is het lastig, of zelfs onmogelijk, om dit in het systeem in te voeren. Vóór de komst van de app kon de serveerster gewoon een aantekening op het bestelbriefje maken.
3.4 Drie categorieën van systeembeheer
Het beheren van systemen is een vak apart. In grote organisaties zijn meerdere systeembeheerders werkzaam, die allemaal hun eigen taak hebben. In paragraaf 2 van module 5 worden de verschillende functies besproken. HIERNA HEB IK PARAGRAAF 2 VAN MODULE 5 INGEVOEGD
2 Functies met betrekking tot netwerken
Bij het beheren van computersystemen, en in het bijzonder netwerken, kunnen we verschillende taken onderscheiden. Deze taken zijn toegewezen aan bepaalde functies. Bij kleine bedrijven zijn deze functies vaak verenigd in één persoon, bij grote bedrijven zie je meestal een team van beheerders.
Systeembeheerder De systeembeheerder zorgt voor de bestanden op de server, de printers, systeemprogramma’s enzovoort. De beveiliging van de server is een belangrijk onderdeel van dit werk. Immers, onbevoegden mogen geen toegang tot gegevens op de server hebben! De systeembeheerder zorgt ervoor dat er gebruikersnamen worden aangemaakt op het netwerk en dat gebruikers in een groep worden geplaatst. Aan zo’n groep kent hij of zij bepaalde rechten toe. Systeembeheerders zijn ook verantwoordelijk voor een goede back- up.
Applicatiebeheerder De applicatiebeheerder is verantwoordelijk voor het installeren van gebruikersapplicaties. De gebruikers moeten normaal hun werk kunnen doen.
Netwerkbeheerder De netwerkbeheerder verzorgt de implementatie en het beheer van alle faciliteiten in het netwerk. Daaronder vallen netwerkkaarten, bekabeling, bridges, routers enzovoort. De netwerkbeheerder houdt ook de performance van het netwerk in de gaten, die onder andere samenhangt met het aantal pc’s dat gebruik moet maken van een server.
3.4 Het beheer als volwaardige activiteit
Beheer is niet iets wat je er zomaar even naast doet. Het is een volwaardige activiteit waarmee, afhankelijk van de grootte van een bedrijf, diverse mensen zich bezighouden en waarvoor beleidgeformuleerd moet worden. Dit betekent ook dat je je steeds opnieuw moet afvragen of het systeem wel voldoet. Het antwoord op deze vraag kan aanleiding zijn om een nieuw onderzoek te starten. Het kan zelfs betekenen dat de systeemontwikkelaars opnieuw moeten worden ingeschakeld.
Proces 1. Opstarten van een project Dit is de voorbereiding van een project. Er wordt gekeken wat de bedoeling van het project is, of het zinvol is het project te beginnen, en er wordt informatie verzameld die nuttig is voor het project. Proces 2. Beginnen van een project In deze fase worden beslissingen genomen over hoe het project zal worden uitgevoerd. Er worden afspraken gemaakt over onder andere operationele standaarden en te gebruiken methoden en technieken, en de business case wordt verder uitgewerkt. Proces 3. Sturen van een project Dit proces loopt gedurende de hele looptijd van het project. Het bevat alle evaluatie en bijsturingsactiviteiten die in de loop van het project plaatsvinden. Proces 4. Beheersen van een fase In dit proces worden de werkzaamheden voor het project toegewezen aan degenen die ze uit moeten voeren. Ook worden de werkzaamheden gemonitord en wordt er rapport uitgebracht aan de stuurgroep die het project stuurt, zodat het project in goede banen geleid kan worden. Proces 5. Managen van een faseovergang Dit zijn de activiteiten die nodig zijn om een fase af te sluiten, de stuurgroep de informatie te geven om de fase te evalueren, en te zorgen dat aan de volgende fase kan worden begonnen. Proces 6. Managen van een productoplevering In dit proces wordt met de uitvoerenden afgesproken wie wat moet gaan doen en hoe dat wordt opgeleverd. Ook het uitvoeren van het werk valt onder dit proces. Proces 7. Afsluiten van een project Aan het einde van het project moet het gemaakte project worden opgeleverd en geëvalueerd. Als het project voortijdig wordt beëindigd, worden in dit proces die zaken veiliggesteld die voor de toekomst bruikbaar zijn.
Het procesmodel van PRINCE2.
3.5 De zeven principes
De zeven principes van PRINCE2 zijn in feite de basiseisen waaraan een project moet voldoen om volgens de PRINCE2-methode te kunnen worden uitgevoerd.
Principe 1. Voortdurende businessrechtvaardiging Hiermee wordt bedoeld dat er niet alleen in het begin, maar gedurende het hele project een reden moet zijn om het project uit te voeren. Door dit constant in de gaten te houden wordt voorkomen dat een project doorloopt terwijl het niet (meer) nodig is. Principe 2. Leren van ervaringen Het projectteam wordt geacht te leren van zijn ervaringen. Aan het begin van het
project wordt gekeken naar dingen die geleerd kunnen worden van ervaringen uit eerdere projecten, en tijdens iedere fase van het project wordt bijgehouden wat er tijdens die fase geleerd wordt. Zo kan het team, en de individuele leden, de opgedane kennis en ervaring meenemen naar de volgende fasen van het project en naar volgende projecten. Principe 3. Duidelijke rollen en verantwoordelijkheden Om een project goed te laten slagen moet het altijd duidelijk zijn wie waarvoor verantwoordelijk is. Dat klinkt voor de hand liggend, maar in de praktijk gebeurt het maar al te vaak dat iets niet gebeurt omdat iedereen denkt dat iemand anders het wel zal doen. In PRINCE2 wordt duidelijk vastgelegd wie welke rol heeft en wie welke verantwoordelijkheid draagt, zodat daar nooit verwarring over kan ontstaan. Principe 4. Managen per fase Een project is vaak veel te groot om in één keer alles te kunnen overzien. Daarom wordt ieder project in PRINCE2 opgeknipt in fasen. Aan het begin van de fase wordt gekeken wat de bedoeling is, en aan het einde wordt gekeken hoe dat uitgevoerd is. Daardoor kan het project waar nodig worden bijgestuurd. Principe 5. Managen bij uitzondering Iedereen draagt de verantwoordelijkheid voor zijn of haar rol in het geheel. Het management grijpt pas in nadat de verantwoordelijke(n) van eventuele problemen zelf (onderling) hebben geprobeerd om het op te lossen. Het ingrijpen van het management gebeurt dus alleen bij uitzondering. Principe 6. Productgericht In een PRINCE2-project staat het product centraal. Dit betekent dat het erom gaat wat er geleverd wordt, en of dat aan de kwaliteitseisen voldoet. Hoe het doel bereikt wordt is van ondergeschikt belang. Principe 7. Aanpassen aan de projectomgeving Omdat ieder project anders is, is de ideale manier om het te managen ook voor ieder project anders. Binnen PRINCE2 is het de bedoeling dat steeds naar de specifieke behoeften van een project wordt gekeken en dat de methode daaraan wordt aangepast. De enige eis daarbij is dat altijd voldaan moet zijn aan deze zeven principes.
3 De methode Scrum
Scrum is een handige methode bij systeemontwikkeling. Dit zijn belangrijke aspecten bij scrum:
3.6 Systeemontwikkeling is een moeilijk proces
Softwareontwikkeling is vaak een moeilijk proces. Dit geldt voor nieuwe software maar ook het aanpassen van bestaande software is vaak lastig. Zo komt het regelmatig voor dat mensen meer functionaliteiten in software willen terwijl die software nog maar net is aangeschaft. Het gevolg is dat de software aangepast moet worden. Soms is het zelfs nodig dat er compleet nieuwe software geschreven moet worden. Het gebeurt ook nogal eens dat de ontwikkeling van een programma duurder uitvalt of dat het programma te laat wordt opgeleverd. Daarom moet zo'n proces goed aangepakt worden.
Problemen die je kunt tegenkomen
Door in periodes van drie weken te werken, kunnen de wensen steeds bijgesteld worden. Bijvoorbeeld omdat de wensen van de klant veranderd zijn of omdat de klant beter inzicht heeft gekregen in wat hij wil. Scrum is gebaseerd op Agile Dit uitgangspunt, flexibiliteit, en het uitgangspunt 'alle relevante mensen bij het proces betrekken' zijn typische uitgangspunten van Agile, ook een systeemontwikkelmethode. 'Agile' betekent 'lenig', 'levendig'. Agile en Scrum zijn heel anders dan de starre watervalmethode. De uitgangspunten van Agile zijn opgeschreven in het Agile Manifesto.
Wat Scrum en rugby gemeen hebben In Wales is rugby een populaire sport. Net zo populair als voetbal in Nederland. Wanneer er bij rugby een fout gemaakt is, wordt het spel soms hervat met een scrum: twee groepen spelers staan dan voorovergebogen tegenover elkaar en proberen de bal te pakken. Om dat voor elkaar te krijgen, is het belangrijk dat het team samenwerkt en gebruikmaakt van de kwaliteiten van alle teamleden. Daarom heeft een lange speler een andere plaats dan een korte speler, en een zware speler heeft ook weer zijn eigen plaats. Net als bij rugby is het bij systeemontwikkeling belangrijk dat het team goed samenwerkt en de kwaliteiten van de teamleden goed worden ingezet. Bij rugby en bij Scrum staan deze voorwaarden centraal.
3.6 Team samenstellen
Bij scrum werk je in een team. Zo'n team moet aan een aantal eisen voldoen:
- Multidisciplinair Bij systeemontwikkeling moeten er verschillende dingen gedaan worden zoals analyseren, ontwikkelen, documenteren, programmeren, ontwerpen en testen. Daarom moet een scrumteam alle relevante diciplines bevatten bijvoorbeeld programmeurs, grafisch ontwerpers, interface ontwerpers en testers. Kortom, het moet een multidisciplinair team zijn.
- Ongeveer zeven personen Meestal bestaat een scrumteam uit ongeveer zeven personen. Er kunnen ook iets meer of minder personen in het team zitten, maar let er op dat er niet te veel of te weinig mensen in het team zitten. Tussen de vijf en negen is mooi.
- Scrummaster en product owner Een van de teamleden heeft de rol van scrummaster en één heeft de rol van product owner. De scrummaster zorgt ervoor dat alles goed kan verlopen en de product owner vertegenwoordigt de belangen van de betrokkenen.
- Met z'n allen in dezelfde ruimte De teamleden werken met z'n allen in dezelfde ruimte. Op die manier is er veel gelegenheid om elkaar te spreken. Tijdens het werk maar ook bij de koffie. Samen verantwoordelijk Je bent in een scrumteam met z'n allen, dus samen, verantwoordelijk voor het resultaat. Het team maakt zelf zijn planning en de teamleden 'beloven' elkaar dat ze zich ervoor inzetten om die planning te halen. Verder is het niet de manager die het werk verdeelt, maar de teamleden zelf. Ook houden ze elkaar op de hoogte van de voortgang. Dit gaat zelfs zo ver dat, wanneer je een dag vrij wilt hebben, je dat niet aan je manager vraagt maar aan het team. Het is namelijk belangrijk dat de planning gehaald wordt en daarvoor is het hele team verantwoordelijk.
3.6 Scrummaster en product owner
Om het proces goed te laten verlopen, is het belangrijk dat er in het team een scrummaster en een product owner zijn.
De scrummaster zorgt ervoor dat alles goed kan verlopen Een van de teamleden heeft de rol van scrummaster. Dat is heel wat anders dan een projectmanager. Als scrummaster ben je vooral bezig met het faciliteren van het team. Je zorgt ervoor dat alles goed kan verlopen. Een scrummaster is als smeerolie in een motor: hij of zij zorgt ervoor dat alles soepel draait. Wanneer een deelproduct niet op tijd gereed of onvolledig is, is het hele team verantwoordelijk en niet alleen de scrummaster. De scrummaster zorgt ervoor dat het team zich aan de spelregels van scrum houdt. De product owner vertegenwoordigt de belangen van de betrokkenen Een team is aan het werk voor een klant. Het is belangrijk dat het team iets maakt waar de klant wat aan heeft. De product owner vertegenwoordigt de belangen van de klant en van andere betrokkenen. Het is misschien een beetje vreemd, maar de manager van het softwareontwikkelbedrijf is ook een belanghebbende. Die manager kan niet zomaar een opdracht aan het team geven zoals in een bedrijf gebruikelijk is. Wanneer hij wil dat het team aan iets werkt, zal hij de product owner ervan moeten overtuigen. Dus uitleggen waarom het belangrijk is.
De product owner onderhoudt ook intensief contact met de klant. Hij zorgt ervoor dat hij precies kan inschatten wat de klant nodig heeft. Hij is, als het goed is, constant beschikbaar voor zowel het team als de klant. Hij levert het team de informatie die nodig is om een goed product te maken. Hij heeft kennis van het bedrijf en kan bepalen waaraan het bedrijf het meest behoefte heeft. Hierdoor krijgen de producten een maximale waarde.
De product owner is dus iemand die belangrijke beslissingen neemt. Hij geeft aan waaraan het bedrijf behoefte heeft en is daarom verantwoordelijk voor wat er geprogrammeerd wordt. Als het goed is, kan hij dus heel goed luisteren en de behoeften inschatten.
3.6 Product backlog
De product owner verzamelt bij het bedrijf de requirements (eisen) voor het product. Deze zet hij in een lijst, de product backlog. Dit is geen statische lijst; telkens komen er nieuwe items bij of veranderen er items. De product owner zorgt ervoor dat wat het hardst nodig is en wat het snelst een werkend product kan opleveren, bovenaan de product backlog komt te staan. Je begrijpt dat hij dit alleen maar goed kan doen als hij het bedrijf en het product door en door kent. De items op de lijst zijn zo gedetailleerd mogelijk. De product backlog is gegroepeerd: items die bij elkaar horen, staan ook bij elkaar. Er zijn functionele requirements. Die benoemen de functionaliteiten in de software. Er zijn ook niet-functionele requirements. Denk bijvoorbeeld aan de snelheid waarmee iets werkt in een programma of de grootte van de kans is dat er een fout optreedt. Het is belangrijk dat deze in de product backlog zo helder mogelijk worden weergegeven. De items die bovenaan de lijst staan, moeten voor het team concreet en helder zijn. De items die verderop in de product backlog staan, hoeven nog niet concreet beschreven te
Het hele team is het erover eens dat het mogelijk is om dat in de komende drie weken klaar te krijgen. De product owner geeft aan het bedrijf door welk stuk software er over drie weken klaar zal zijn. En het team gaat ervoor om dat waar te maken. We noemen dat commitment. Vervolgens gaan de teamleden aan het werk. Iemand pakt een memobriefje uit het 'To do'-vak en plakt dat in het vak 'Doing'. Telkens als een work-item gereed is, wordt het memoblaadje naar het vak 'Done' verplaatst. Je ziet zo al snel vorderingen.
- Daily Scrum Elke dag is er een korte bijeenkomst van maximaal 15 minuten, de daily Scrum. Deze begint precies op tijd. Plaats van bijeenkomst is het scrumboard. Een team is helemaal op elkaar ingespeeld. Soms bedenken teams grappige straffen voor te laat komen. Bijvoorbeeld een aantal push-ups, tien euro in de pot of de hele dag koffie halen voor het team. De daily Scrum is een stand-up meeting. De naam zegt het al: iedereen staat (voor het scrumboard). Dat is om duidelijk te maken dat het niet lang gaat duren. Het is ook een actieve houding. Hangen over de leuning van een stoel is uit den boze teamlid moet drie vragen beantwoorden: Wat heb ik bereikt? Wat ga ik bereiken? Wat blokkeert me? Als antwoord op de eerste vraag vertel je welke work-items je af hebt gekregen of waar je nog aan bezig bent en hoe dat is gegaan de tweede vraag 'Wat ga ik bereiken?' vertel je welke work-items je voor de volgende stand-up meeting wil gaan doen. De laatste vraag, 'Wat blokkeert me?' is ook heel belangrijk. Hier heb je namelijk de mogelijkheid om problemen te noemen die je ziet aankomen. Misschien is er een kans dat de sprint niet op tijd gereed kan zijn of misschien heeft een teamlid een probleem waar hij geen oplossing voor heeft al die vragen kunnen de andere teamleden inspelen. Vooral bij de laatste vraag kunnen de teamleden wat voor elkaar betekenen. Misschien weet niemand direct een oplossing maar misschien bedenkt iemand daarna een oplossing. Door deze manier van werken wordt transparant waarmee iedereen bezig is. Omdat iedereen aan hetzelfde product werkt, is dat erg waardevol. Luieren valt natuurlijk ook direct op. Het kan wel eens tegenzitten maar dat moet niet telkens het geval zijn. Dan kun je verwachten dat daar kritiek op komt. Die kritiek komt dan van je medeteamleden, niet van je manager. Want je bent als team verantwoordelijk voor het resultaat. Samen zijn jullie overeengekomen de klus te klaren.
3.6 Het product is klaar
Als de drie weken bijna voorbij zijn komen er nog twee bijeenkomsten. Hiermee wordt deze fase helemaal afgesloten:
- de sprint review
- de retrospective.
Sprint review Aan het einde van de drie weken is de sprint backlog leeg en het product klaar. Het team is daar trots op. Je laat dat aan elkaar zien tijdens een speciale bijeenkomst, de sprint review. Een sprint review is altijd feestelijk. Vaak is er een traktatie en iedereen kan even opgelucht ademhalen. Met elkaar heeft het team de klus geklaard! De product owner kan het product
aan het bedrijf laten zien. Het is belangrijk wat het bedrijf van het product vindt. De product owner zorgt ervoor dat alle reacties van het bedrijf bij het team bekend worden zodat daarop ingespeeld kan worden. Uiteraard in een nieuwe sprint.
Retrospective Na de sprint review is er nog één bijeenkomst voordat de sprint afgesloten kan worden, de retrospective. Tijdens deze bijeenkomst kijk je met het hele team naar zaken die goed liepen en naar zaken die niet goed liepen. Voor beide zijn er acties nodig. Het zal duidelijk zijn dat er voor zaken die niet goed gingen, verbeteracties opgesteld moeten worden. Maar ook voor zaken die wel goed liepen moeten er acties opgesteld worden. Want je wilt dat de zaken die goed liepen, goed blijven verlopen. In een volgende sprint zullen de geformuleerde acties aan de orde komen. Er is op internet heel veel informatie te vinden over deze manier van werken. Op dit ogenblik wordt Scrum veel gebruikt. Dat heeft aan de ene kant te maken met het succes ervan. Aan de andere kant spreekt het ontwikkelaars erg aan om zelf de regie te hebben over hun werk. Dat past gewoon goed bij hen. Bij grote projecten werken meerdere scrumteams samen. Dan zijn er weer andere werkvormen nodig. Wanneer je meer wilt weten over Scrum is het boekje 'De kracht van Scrum' een aanrader. Scrum kun je ook bij andere, niet-ICT-projecten inzetten. Bijvoorbeeld als je met een paar medeleerlingen een werkstuk moet maken. Probeer het maar!
Module 6 - Systeemontwikkeling
Vak: Informatica
- Ontdek meer van:
![22625-2022-Winter-model-answer-paper[Msbte study resources] (1) (1)](https://d20ohkaloyme4g.cloudfront.net/img/document_thumbnails/8a359224b637e5ea13b558ae9d924aae/thumb_300_212.png)