Kwaliteitswaarborging in het software ontwikkelproces: meegroeien van de methodologie

Doctoraalscriptie Medische Informatiekunde AMC / Universiteit van Amsterdam

Kwaliteitswaarborging in het software ontwikkelproces: meegroeien van de methodologie

Student: Laura Marras E-mail: [email protected] Collegekaartnummer: 0210536

Stageplaats: Research & Development Pharmeon BV Hettenheuvelweg 14 1101 BN Amsterdam

Stageperiode: November 2005 – Juni 2006

Stagebegeleider: O. Rossman Research & Development [email protected]

Stagedocent: F. Wiesman Klinische Informatiekunde [email protected]

II

Inhoudsopgave

Inhoudsopgave Inhoudsopgave Samenvatting Abstract Voorwoord Hoofdstuk 1 Inleiding 1.1 Stage 1.2 Context 1.3 Probleemstelling en onderzoeksvragen 1.4 Opzet scriptie Hoofdstuk 2 Bedrijfsanalyse 2.1 Algehele analyse 2.2 Bedrijfsprocessen 2.3 Capability Maturity Model 2.4 Projectenanalyse 2.5 Knelpuntenanalyse 2.6 Conclusies Hoofdstuk 3 Mogelijke oplossingen 3.1 Software methoden 3.2 Onderzoeksmethode 3.3 Resultaten 3.3.1 Extreme Programming 3.3.2 Scrum 3.3.3 Dynamic Systems Development Method 3.3.4 Feature Driven Development 3.4 Tools 3.5 Vergelijking van methoden Hoofdstuk 4 Oplossing voor Pharmeon 4.1 Software ontwikkelmethode 4.2 Planning 4.3 Software ontwikkelproces Hoofdstuk 5 Implementatietraject HerhaalRecepten 5.1 Pilot 5.2 Resultaten 5.3 Advies 5.4 Implementatietraject Hoofdstuk 6 Conclusies en discussie 6.1 Onderzoeksvragen 6.2 Aanbevelingen 6.3 Discussie Literatuurlijst Bijlagen Bijlage A Procedure Development Task aanmaken Bijlage B Vragen interview pilot-apotheken Bijlage C Procedure domeinnaam aanvragen Bijlage D Procedure pop account aanmaken Bijlage E Procedure onderhouden van de website Bijlage F Procedure Planning categorie toewijzen

III IV V VI 1 1 1 2 3 5 5 7 11 12 15 17 19 19 20 21 21 25 27 31 33 34 39 39 43 45 49 49 50 51 52 55 55 57 57 58 61 62 63 64 65 66 67

III

Samenvatting

Samenvatting Dit onderzoek is uitgevoerd bij Pharmeon BV te Amsterdam. Pharmeon is een klein full-service bedrijf dat websites ontwikkelt voor medisch zorgverleners. Op de Research & Development afdeling van Pharmeon worden webapplicaties ontwikkeld. De software ontwikkelmethode die gebruikt wordt voldoet niet meer aan de hoge kwaliteitseisen die aan webapplicaties worden gesteld en is niet geschikt voor een dynamische omgeving. Pharmeon werkte volgens een first in first out principe waarbij geen planning werd gemaakt en elke taak werd uitgevoerd zodra er tijd voor was. Het doel van dit onderzoek was om meer structuur aan te brengen in de bedrijfsprocessen zodat het software ontwikkelproces bij Pharmeon met goed resultaat wordt doorlopen. Het onderzoek richtte zich op drie onderdelen: (1) software ontwikkelmethode, (2) planning en (3) implementatie. Methoden De toegepaste software ontwikkelmethode is in kaart gebracht door de medewerkers van Pharmeon te interviewen en hun manier van werken te observeren. De bestaande situatie werd tegenover de ideale situatie uit de literatuur gezet en vergeleken. Daarna kon worden gezocht naar beschikbare oplossingen uit de literatuur voor de knelpunten. Op de oplossingen heeft een selectie plaatsgevonden. De oplossingen zijn met elkaar vergeleken op vier fronten: de fasen van de software levenscyclus, ondersteuning van project management activiteiten, voldoende ondersteuning en organisatie geschiktheid. Voor de planning bestond al een eerste opzet. De belangrijkste informatie werd verzameld in een view, maar dit was nog niet klaar voor gebruik. Voordat een planning kon worden gemaakt, zijn de taken eerst geanalyseerd en is een categorisatie gemaakt die de taken onderverdeelt. Voor de implementatie is gekeken naar het project HerhaalRecepten dat liep tijdens de onderzoeksperiode. Na de eerste fase van het project is er een pilot uitgevoerd met vijf apotheken. Voor dit onderzoek is de implementatie van de applicatie HerhaalRecepten in de pilot-fase geëvalueerd met behulp van een telefonisch interview. Hieruit kwamen verschillende problemen en aanbevelingen naar voren die samen met bevindingen uit de literatuur zijn gebruikt voor het schrijven van een implementatie advies voor de tweede fase van het project HerhaalRecepten. Resultaten De resulterende knelpunten waren: (1) slechte communicatie, (2) weinig documentatie, (3) geen uitgebreide testen en (4) geen planning. Alle knelpunten hebben te maken met de manier van software ontwikkelen bij Pharmeon. Uit de literatuur bleek dat de best toepasbare software ontwikkelmethode bij Pharmeon een combinatie van Extreme Programming en Scrum is. Beide behoren tot de Agile aanpak van software development welke staat voor snelle software ontwikkeling bij projecten waarbij men openstaat voor veranderende eisen. De planning is in gebruik genomen en wordt gebruikt voor het wekelijks plannen van projecten en taken. De categorisering heeft geleid tot een efficiënte planning en een toename van het aantal op tijd voltooide taken. Het implementatie advies dat opgesteld is, is van toepassing op het project HerhaalRecepten na voltooing van de tweede fase. Het advies noemt de factoren importance of IS security, relative advantage en compatibility op als belangrijke factoren bij de implementatie van HerhaalRecepten. Conclusies Als Pharmeon kiest voor een combinatie van Extreme Programming en Scrum, gevolgd door een implementatietraject zoals beschreven in het implementatie advies zal het software ontwikkelproces gestructureerder en controleerbaarder zijn, wat bij zal dragen aan de kwaliteit van het resultaat. De planning is tijdens de stage met succes ingevoerd op de Research & Development afdeling.

IV

Abstract

Abstract This research has been carried out at Pharmeon BV in Amsterdam. Pharmeon is a small company that builds websites for health care providers. The Research & Development department of Pharmeon is occupied with the development of web applications. The software development process which was used did not measure up to the high quality requirements that are set to web applications and was not appropriate for use in a dynamic environment. Pharmeon worked according to a first in first out principle where every task was executed as soon as there was time. The goal of this research was to bring more structure into the business processes such that the software development process at Pharmeon will be successfully completed. The research consisted of three parts: (1) software development process, (2) planning and (3) implementation. Methods The software development process used was assessed by interviewing the employees of Pharmeon and observing their work routine. The existing situation was compared to the ideal situation described in literature. Next practical solutions to the bottlenecks were identified from literature. A selection was made on the solutions found. They were compared on four points: the phases of the software development life-cycle, support of project management activities, concrete guidance and situation appropriateness. For the planning a first design already existed. The most important information was collected in one view but it was not yet ready for use. Before a planning could be made, the tasks were analyzed and categorized which led to a subdivision of the tasks. For the implementation one of the active projects at Pharmeon called HerhaalRecepten was used as case study. After the first phase of this project a pilot was executed with five pharmacies. For this research the implementation of the web application HerhaalRecepten in the pilot phase was evaluated by interviewing users at the pharmacies involved. The resulting problems and recommendations together with findings from literature were used to write an implementation advice for the second phase of the project HerhaalRecepten. Results The resulting bottlenecks were: (1) inefficient communication, (2) insufficient documentation, (3) no extensive testing and (4) no planning. The bottlenecks are all relating to the way of developing software at Pharmeon. From the literature the best applicable software development method for Pharmeon appeared to be a combination of Extreme Programming and Scrum. Both belong to the Agile development of software which stands for quick software development in projects with changing requirements. The planning was put into use and is used for a week-to-week planning of projects and tasks. The categorisation has led to an efficiënt planning and a growth of the number of on-time completed projects. The implementation advice that was compiled is applicable to the project HerhaalRecepten after completion of the second phase. The advice deems the following factors as important for the implementation of HerhaalRecepten: importance of IS security, relative advantage and compatibility. Conclusions If Pharmeon decides to go for the combination of Extreme Programming and Scrum, followed by the implementation as described in the implementation advice, the software development process will become more structured and controlled which will contribute to the quality of the end result. During the research period the planning was successfully deployed at the Pharmeon Research & Development department.

V

Voorwoord

Voorwoord Deze scriptie is geschreven ter afsluiting van de doctoraalstage van de opleiding Medische Informatiekunde. De doctoraalstage is uitgevoerd op de afdeling Research & Development van Pharmeon te Amsterdam. Deze stage was het begin van de kwaliteitsbewaking bij Pharmeon die moest zorgen voor goede afronding van processen. Kwaliteit speelt een steeds grotere rol bij het aantrekken van nieuwe klanten en het behouden van de bestaande klanten. Ook bij de groei van een bedrijf zou kwaliteit niet uit het oog verloren mogen worden. Met deze scriptie is een goede start gemaakt met de standaardisatie van de processen bij Pharmeon. Dit onderzoek had niet tot stand kunnen komen zonder de hulp van mijn stagebegeleider dhr. O. Rossman en de medewerking van alle geinterviewden bij Pharmeon. Daarnaast wil ik dr. F. Wiesman bedanken voor zijn begeleiding en zijn aanbevelingen die essentieel zijn geweest bij het schrijven van deze scriptie.

Bedankt voor alle hulp. Laura Marras

VI

VII

Hoofdstuk 1 Inleiding

Hoofdstuk 1 Inleiding Deze scriptie is geschreven in het kader van de wetenschappelijke stage van de opleiding Medische Informatiekunde. Hierin wordt een probleem dat betrekking heeft op informatie in de gezondheidszorg besproken en zal er een oplossing op dat probleem worden voorgesteld. Tijdens de wetenschappelijke stage wordt er gebruik gemaakt van onderzoeksmethoden en technieken die in de opleiding Medische Informatiekunde aan bod zijn gekomen en in wetenschappelijke literatuur beschreven zijn.

1.1 Stage De wetenschappelijke stage is uitgevoerd bij Pharmeon BV te Amsterdam. Pharmeon is een fullservice internet bedrijf gespecialiseerd in het verlenen van internetdiensten aan de gezondheidszorg. Met deze diensten speelt Pharmeon in op de groeiende vraag van consumenten naar betrouwbare online informatie over gezondheid en helpt zorgaanbieders deze aan te bieden. De service die Pharmeon onder andere aanbiedt, is de bouw en update van praktijkwebsites voor zorgaanbieders zoals apothekers, dierenartsen, huisartsen en tandartsen. Zo’n website bevat onder meer informatie over de praktijk en specialisaties, patiëntenfolders, herhaalrecepten, links naar gezondheidsgerelateerde websites en uitgebreide backoffice services. Ook is er de mogelijkheid om een eigen design te laten maken, promotiemateriaal af te laten drukken en extra services te kopen. Deze extra services zijn onder andere: relevante informatie over aandoeningen en behandelingsmogelijkheden, nieuwsberichten, reisadvies, online pilservice, medische encyclopedie en binnenkort de koppeling met het apothekerssysteem: HerhaalRecepten. Pharmeon is opgericht in 2000 en bestond toen uit 3 medewerkers. Nu telt het bedrijf bijna 20 medewerkers. Naast de directie kent Pharmeon twee afdelingen: de Customer Services en de Research & Development afdeling.

1.2 Context De Research & Development afdeling is in de loop der jaren gegroeid van één programmeur tot zes. Daardoor zijn de software ontwikkelmethoden en de procedures die toen golden, nu niet meer van toepassing. In plaats van één persoon werken nu één of meerdere personen aan een project en dus moeten de software ontwikkelmethoden en de procedures aangepast worden aan de nieuwe manier van werken. Niet alleen is het aantal klanten en aanvragen meegegroeid, maar ook de complexiteit van de webapplicaties neemt toe. Het software ontwikkelproces, zoals dat werd doorlopen, is niet meer toepasbaar op de huidige situatie, zonder dat de webapplicaties die afgeleverd worden in kwaliteit afnemen. Op de Research & Development afdeling worden er dagelijks kleine aanpassingen gemaakt aan bestaande webapplicaties en aan nieuwe webapplicaties gebouwd. Deze webapplicaties worden op de testserver steekproefsgewijs getest op de werking en functionaliteit door de programmeur. Er wordt technische documentatie gemaakt en wanneer alles goed is, wordt de webapplicatie afgeleverd aan de klant. In dit software ontwikkelproces, zoals het was, moesten twee belangrijke stappen verbeterd worden, namelijk het testen en documenteren. Er werd te weinig aandacht besteed aan het kwaliteitsaspect van het software ontwikkelproces doordat er geen uitgebreide testen werden uitgevoerd en naslag- of gebruikersdocumentatie van de webapplicaties niet gemaakt werd. Ook het opzetten en documenteren van procedures is bij Pharmeon tot op dit moment niet aan de orde geweest. Het niet uitvoerig testen en het gebrek aan procedures en documentatie zorgden samen voor ongestandaardiseerde processen en gebrek aan kwaliteit van de webapplicaties. Een van de lopende projecten is HerhaalRecepten. In dit project wordt de webapplicatie Herhaalrecepten gemaakt, deze webapplicatie wordt via internet aangeboden aan patiënten.

1


In de eerste fase van het project HerhaalRecepten is volgens het nu nog gebruikte software ontwikkelproces gewerkt. Dit betekent dat er geen gebruikersdocumentatie is en het software ontwikkelproces dus niet van begin tot eind is doorlopen. Hierdoor is het de vraag of de implementatie van de HerhaalRecepten in de ‘proefapotheken’ gegaan is zoals je zou verwachten, zodat het gebruik gestimuleerd wordt en zal aanslaan bij zowel de apothekers als de patiënten.

1.3 Probleemstelling en onderzoeksvragen Hieronder worden de probleemstelling en onderzoeksvragen besproken. Per onderzoeksvraag is beschreven met welke methoden en technieken de vraag beantwoord is. Probleemstelling Hoe kunnen de bedrijfsprocessen van Pharmeon BV geoptimaliseerd worden, zodat het software ontwikkelproces met goed resultaat wordt doorlopen? Onderzoeksvragen 1. Welke bedrijfsprocessen spelen zich af binnen Pharmeon? 2. Welke knelpunten zijn er? 3. Wat voor type projecten worden er uitgevoerd? 4. Welke mogelijke oplossingen zijn er voor de knelpunten? 5. Wat is de beste oplossing voor Pharmeon? 6. Welk implementatietraject zou gevolgd moeten worden HerhaalRecepten een succes in apotheken te maken?

om

van

het

project

Aanpak/methoden/technieken Welke bedrijfsprocessen spelen zich af binnen Pharmeon? Als eerst zijn de bedrijfsprocessen die zich afspelen op de Research & Development afdeling geanalyseerd. Hiervoor is meegelopen op de afdeling, interviews gehouden en literatuur bestudeerd. De bedrijfsprocessen zijn daarna in kaart gebracht met behulp van Unified Modeling Language en besproken met de medewerkers van Pharmeon. Welke knelpunten zijn er? Na de analyse en het in kaart brengen van de bedrijfsprocessen werden de mogelijke knelpunten in de processen zichtbaar. Door middel van het interviewen van de medewerkers en de modellen uit de analyse werden de knelpunten duidelijk. Daarnaast heeft een inventarisatie van de problemen die binnenkomen bij de Customer Services geholpen om de knelpunten naar type in te delen. Wat voor type projecten worden er uitgevoerd? De al lopende projecten en de projecten die tijdens de eerste drie maanden van de onderzoeksperiode begonnen zijn, zijn bestudeerd. Hierbij zijn de kenmerken van de projecten (onder andere doorlooptijd, budget, tijd, team, taken) onderzocht. Het resultaat is een gedetailleerde omschrijving van de projecten. Welke oplossingen zijn er? Op basis van de knelpunten die gevonden waren tijdens de analyse van de bedrijfsprocessen is in de Software Engineering literatuur gezocht naar bestaande oplossingen voor de knelpunten. De mogelijke oplossingen zijn met elkaar vergeleken op onder andere resultaat, benodigde tijd en complexiteit. Wat is de beste oplossing voor Pharmeon? Uit de mogelijke bestaande oplossingen zijn de oplossingen die bruikbaar zijn binnen Pharmeon nader onderzocht. De oplossingen moesten passen in de manier van werken bij Pharmeon en bij

2


het type projecten dat uitgevoerd wordt. Rekening houdend met factoren als tijd en medewerkers zijn één of meerdere oplossingen gekozen en onderdeel gemaakt van de werkroutine. Afhankelijk van de complexiteit en de benodigde tijd zijn de gekozen oplossingen uitgevoerd, zodat de nieuwe manier van werken aan het eind van het onderzoek geëvalueerd kon worden. Welk implementatietraject zou gevolgd moeten worden om van het project HerhaalRecepten een succes in apotheken te maken? Nadat de ontwikkeling van de webapplicatie Herhaalrecepten is gevolgd, is na afloop van de pilot contact opgenomen met de ‘proefapotheken’. Tijdens het contact is een telefonisch interview afgenomen. Hierin werd gevraagd naar de manier van werken met HerhaalRecepten en de ervaringen van de patiënten. Uit de afgenomen interviews zijn verbeterpunten naar voren gekomen voor de webapplicatie HerhaalRecepten, die meegenomen konden worden in de verdere ontwikkeling. Op basis van de verbeterpunten en de literatuur is een implementatie advies geschreven voor het project HerhaalRecepten. In het advies is beschreven welke methoden kunnen gebruikt worden om het implementie succes te vergroten.

1.4 Opzet scriptie De scriptie bestaat uit zes hoofdstukken waarin achtereenvolgens het volgende wordt besproken. In hoofdstuk 1 is een introductie gegeven op de stageperiode, het bedrijf waar de stage is gelopen, Pharmeon, en de daarbij horende probleemstelling en onderzoeksvragen. Hierin is getracht een goed beeld te geven van de uitgevoerde stage. In hoofdstuk 2 wordt de bedrijfsanalyse besproken, waarin een algehele analyse, een knelpuntenanalyse en een analyse van de projecten worden besproken. Deze analyses zijn gericht op het leren kennen van het bedrijf en de processen om daarna oplossingen op de gevonden knelpunten te kunnen aanbieden. De onderzoeksvragen 1 t/m 3 zullen in hoofdstuk 2 aan bod komen. Hoofdstuk 3 zal de mogelijke oplossingen op de in hoofdstuk 2 gevonden knelpunten bevatten, hiermee wordt onderzoeksvraag 4 beantwoord en in hoofdstuk 4 zal onderzoeksvraag 5 behandeld worden die de meest geschikte oplossingen voor Pharmeon bespreekt en motiveert. Deze oplossingen kunnen indien nodig aangepast zijn aan de omgeving van Pharmeon. Hoofdstuk 5 dient als een advies voor Pharmeon, waarin een implementatietraject zal worden voorgesteld om de webapplicatie HerhaalRecepten tot een succes te maken in de apotheken. Het advies bevat het antwoord op onderzoeksvraag 6. Ten slotte zal in hoofdstuk 6 een conclusie worden getrokken met betrekking tot de gevonden oplossingen voor Pharmeon en het hoofdstuk zal eindigen met een discussie over de aanpak van het onderzoek en resultaten.

3

4

Hoofdstuk 2 Bedrijfsanalyse

Hoofdstuk 2 Bedrijfsanalyse De bedrijfsanalyse bestaat uit een analyse van het bedrijf Pharmeon: de bestaande situatie wordt in kaart gebracht en de belangrijkste ontwikkelingen worden in beeld gebracht. De volgende onderwerpen komen aan bod: bedrijfsstrategie, missie, toekomstvisie en (jaar)plannen. Het doel van de bedrijfsanalyse is een bepaald gebied of enkele aspecten uit de bedrijfsvoering te analyseren om vervolgens de eventuele knelpunten te kunnen signaleren. Aan de hand van de bedrijfsanalyse kunnen er aanbevelingen worden gedaan ten aanzien van de wijze waarop bepaalde punten verbeterd of knelpunten kunnen worden vermeden in de toekomst. De bedrijfsanalyse bij Pharmeon is opgedeeld in twee delen. In paragraaf 2.1 en 2.2 wordt het bedrijf als geheel bekeken. Er wordt niet in details getreden, maar globaal omschreven. Het eerste deel van de bedrijfsanalyse is nodig om tot een weloverwogen keuze te komen voor een oplossing(en) die de knelpunten bij Pharmeon moet aanpakken. De analyse is gebaseerd op een visiedocument [1] en observaties van de medewerkers en hun manier van werken. In paragraaf 2.3, 2.4 en 2.5 worden drie aspecten nader bekeken. Dit zijn het Capability Maturity Model niveau, de projecten die Pharmeon heeft uitgevoerd en de knelpunten die gesignaleerd waren in de bedrijfsanalyse en die bevestigd zijn door de medewerkers van Pharmeon. Hiervoor zijn bestaande documentatie en interviews gebruikt. Dit deel van de bedrijfsanalyse is essentieel om de knelpunten bij Pharmeon te kunnen identificeren.

2.1 Algehele analyse Pharmeon BV is opgericht in 2000 door mensen uit de farmaceutische industrie en de IT branche. De originele doelgroep was de farmaceutische industrie en dan voornamelijk de groothandels. Pharmeon is begonnen tijdens de internethype en moesten een weg proberen te vinden om te overleven. Hierdoor hebben zij zich gericht op eerstelijns medisch zorgverleners. Nu in 2006 is Pharmeon uitgegroeid tot een klein bedrijf met circa 20 medewerkers. Het aantal klanten is gegroeid en ook het aantal websites dat Pharmeon onderhoudt, is inmiddels gegroeid tot meer dan 1000. Het bedrijf is nog steeds groeiende en probeert nu een weg te vinden om zich tot een succesvol middelgroot bedrijf te ontwikkelen. Figuur 2.1 laat de groeicurve zien van de afgelopen vijf jaar.

400 350

Groei in %

300 250 200 150 100 50 0 2001

2002

2003

2004

2005

Jaar Figuur 2.1 Groei van Pharmeon in procenten per jaar ten opzichte van het vorig jaar

5


Pharmeon is een platte organisate waarbinnen twee afdelingen bestaan: Customer Services en Research & Development. De Directie zit samen met haar medewerkers op de afdeling waarvan zij deel uitmaken. De afdeling Customer Services bestaat eind 2005 uit circa 12 medewerkers waaronder 1 een commercieel directeur, 1 account manager en 10 commercieel medewerkers (waarvan 5 stagiaires). Op de Research & Development afdeling werken circa 9 medewerkers, van stagiair tot technisch directeur. Aan het begin van de onderzoeksperiode waren dat: 3 programmeurs waarvan 1 ook ontwerper is, 1 programmeur/systeembeheerder, 1 technisch ontwerper, 3 stagiaires en een technisch directeur. De Directie bestaat uit de commercieel directeur en de technisch directeur. Pharmeon heeft een jong team met een gemiddelde leeftijd van 25. Voor een overzicht van alle medewerkers van Pharmeon zie figuur 2.2.

Figuur 2.2 Organigram van Pharmeon

Het visiedocument beschrijft de volgende eigenschappen van Pharmeon als volgt. Pharmeon kenmerkt zich door van de volgende eigenschappen: kleine, informele organisatie flexibel agressieve sales opportunistisch af en toe missen van de finishing touch Het doel dat de directie heeft bij het oprichten van het bedrijf is: Voor elke bedrijfstak waar Pharmeon in zit, de eerste keus ‘standaard’ website provider zijn. De missie is kort maar duidelijk: De voordelen van internet binnen bereik brengen van niet-IT gerelateerde ‘winkelbezitters’. Dit moet bereikt worden door middel van de volgende bedrijfsstrategie: Pharmeon wilde de grootste standaard website leverancier zijn. Dit kon bereikt worden door meer te bieden dan de concurrentie, door: de websites te voorzien van gepaste informatie snel en nauwkeurig reageren op opkomende eisen vanuit de branche het aanbieden van services aan de website beheerders 6


Ook de taken van Pharmeon worden in het visiedocument beschreven. De taken die op de afdeling Customer Services van Pharmeon worden vervuld zijn: Business development o Kansen zoeken o Initiëren van contacten o Afsluiten van contracten met bedrijven waarmee wordt samengewerkt o Voorstellen van nieuwe functionaliteiten / aanpassing van bestaande functionaliteiten

PS/IS 1 o o o o o

Sales & Marketing Afsluiten van contracten met klanten Communiceren van nieuwe functionaliteit naar de klant Verkopen van nieuwe services aan de klant Tevreden houden van de klant Voorstellen van nieuwe functionaliteiten / aanpassing functionaliteiten

van

bestaande

Community Sales & Marketing o Marketing o Verkopen o Communiceren van nieuwe functionaliteit naar de leden van een community (klantengroep) o Verkopen van nieuwe functionaliteit of het promoten van nieuwe kosteloze functionaliteit onder de community-leden

De taken die de afdelingen Customer Services en Research & Development in samenwerking uitvoeren zijn: IT Pre Sales o Analyseren van de draagwijdte van een taak en de verwachte kosten o Evalueren van de kosten van een nieuwe functionaliteit o Bespreken van het prijsbeleid voor nieuwe functionaliteiten met de commerciële afdeling

Post sales services and support (Customer Support) o Ondersteunen van website gebruik o Verkopen van nieuwe functionaliteit of het promoten van nieuwe kosteloze functionaliteit onder de community-leden. o Voorstellen van nieuwe functionaliteiten / aanpassing van bestaande functionaliteiten o Creëren van communities o Creëren van (portaal)sites o Onderhouden van de websites

De taken die op de afdeling Research & Development worden vervuld zijn: Product development o Bouwen van nieuwe functionaliteiten o Onderhouden van de “Pharmeon Website Generator” o Voorstellen van nieuwe functionaliteiten

2.2 Bedrijfsprocessen Binnen Pharmeon spelen zich een aantal vaste processen af. Deze processen kunnen worden ingedeeld in primaire processen en ondersteunende processen. Primaire processen beginnen en eindigen bij de klant en hebben direct te maken met het maken of leveren van een product. Aan 1

Portal Sites / Incidental Sites

7


elk primair proces zijn een aantal ondersteunende processen verbonden die de effectiviteit of efficiëntie van het primair proces helpen te verbeteren. De primaire processen bij Pharmeon zijn: opzetten van een website ontwikkelen van een nieuwe functionaliteit extra service op de website activeren domeinnaam registreren pop account aanmaken onderhouden van de website Bij de primaire processen horen ondersteunende processen, die uitgevoerd moeten worden zodat het primaire proces succesvol wordt afgerond. De ondersteunende processen volgen elkaar op, zodat de output van het ene proces de input is van de volgende. Hieronder worden de ondersteunende processen behorende bij de primaire processen op de Research & Development afdeling besproken. Het ondersteunende proces behorende bij het proces ‘opzetten van een website’: Bij het opzetten van een website met een nieuw design, wordt er eerst een design gemaakt door een extern ontwerpbureau of een ontwerper van Pharmeon. Dit design wordt als Adobe Photoshop bestand afgeleverd. Dit design moet eerst de juiste afmetingen hebben en vervolgens voor HTML worden klaargemaakt door de Research & Development afdeling. De ondersteunende processen behorende bij het proces ‘ontwikkelen van een nieuwe functionaliteit’: Voordat een nieuwe functionaliteit ontwikkeld wordt, moet als eerst door de Customer Services of de Directie worden gevraagd wat de klant precies wil en alle onderliggende requirements worden geïdentificeerd. Hiervoor wordt na een uitgebreid gesprek met de klant over de functionaliteit en de mogelijkheden een functionele beschrijving gemaakt waarin alles wordt beschreven met daarbij enkele screenshots om de klant iets concreets te laten zien. Bij grote klanten en projecten wordt zowel het gesprek als de functionele beschrijving door de Directie afgehandeld. Als de functionele beschrijving goed is opgesteld en er geen aanvullingen hoeven plaats te vinden kan dit door de Research & Development afdeling vertaald worden naar een technische specificatie voor de ontwikkelaars. Vervolgens wordt de functionaliteit gebouwd en wordt er in de programmacode voor een deel documentatie geschreven. Tijdens de ontwikkeling van de functionaliteit wordt deze steekproefsgewijs getest op de juiste werking ervan. Het ondersteunende proces behorende bij het proces ‘extra service op de website activeren’: Klanten kunnen indien gewenst extra services op hun website krijgen. Deze services zijn al eerder ontwikkeld en hoeven slechts geactiveerd worden per website. Dit proces komt veelvuldig voor op een dag en neemt niet meer dan 15 minuten in beslag per extra service. Hiervoor moet op de website de service geactiveerd worden door deze te selecteren in de backoffice van Pharmeon. De ondersteunende processen behorende bij het proces ‘domeinnaam registreren’: Om een domeinnaam te registreren, moet de klant een aantal formulieren tekenen. Deze formulieren worden grotendeels door de Research & Development afdeling van tevoren ingevuld om onjuist ingevulde formulieren te voorkomen. Vervolgens worden de ingevulde formulieren naar de klant geë-maild of gefaxt. De juiste gegevens moeten worden genoteerd en de aanvraag voor de domeinnaam wordt ingediend. Vervolgens moet steeds worden gecontroleerd of het domein al geregistreerd is. De ondersteunende processen behorende bij het proces ‘pop account aanmaken’: Voor het aanmaken van een pop account moeten alle gegevens goed worden genoteerd. Dit zijn het domein, naam van de pop account en wachtwoord. Daarna kan de pop account door de Research & Development afdeling worden aangevraagd of, indien deze op de eigen mailserver

8


moet worden aangemaakt, zelf worden aangemaakt. Als laatst wordt er naar de aangemaakte pop account een testmail gestuurd. Het ondersteunende proces behorende bij het proces ‘onderhouden van de website’: Het onderhouden van een website houdt in dat de content op de website regelmatig moet worden aangepast of vernieuwd. Deze content wordt meestal door de Customer Services bijgehouden en wordt in sommige gevallen door de Research & Development afdeling vernieuwd. De twee grootste primaire processen zullen met behulp van Unified Modeling Language (UML) modellen beschreven worden. Ze komen heel regelmatig voor en nemen in verhouding tot de andere primaire processen veel tijd in beslag. Bij deze twee primaire processen zijn meerdere personen betrokken en dus is goede communicatie en informatie van groot belang. Voor de modellen van de overige primaire processen verwijs ik naar de bijlagen C, D en E van deze scriptie. Het primaire proces ‘opzetten van een website’ is een veel voorkomend proces bij Pharmeon dat deels gestandaardiseerd is. Voor het opzetten van een standaard website met standaard design zijn er enkele stappen die binnen een week voltooid kunnen worden. Bij het opzetten van een website met een eigen design zijn er meer stappen nodig en deze kosten elk meer tijd. In figuur 2.3 wordt het proces schematisch weergegeven met behulp van UML. Er komt op de Customer Services een aanvraag binnen voor een website, nadat de klant een informatiepakket heeft ontvangen. Indien de klant al precies weet wat er op moet komen te staan, wordt dit genoteerd in een database. De klant kan kiezen tussen een standaard website en een op maat gemaakte website met een speciaal design. Als de klant kiest voor een standaard website wordt op de Research & Development afdeling het domein geregistreerd, de website klaargezet op het domein, de content aangepast of overgenomen van een bestaande website en gecontroleerd of alles werkt. Als de website klaar is voor gebruik, wordt er een e-mail gestuurd naar de Customer Services, die de website nog even bekijkt en vervolgens de klant op de hoogte brengt. Als de klant kiest voor een speciaal design, dan kan de klant enkele bestaande designs bekijken en zelf een keuze maken of het geheel overlaten aan de ontwerper. Het design wordt gemaakt door een extern ontwerpbureau of door de ontwerper bij Pharmeon. Dit hangt af van de het budget van de klant en het gewenste ontwerp. Indien het gewenste ontwerp gebaseerd is op een bestaand ontwerp wordt het design door de ontwerper gemaakt. Zodra het design gemaakt is, wordt deze als een plaatje afgeleverd en aan de klant getoond. Indien de klant accoord gaat met het design wordt deze omgezet naar HTML. Vervolgens moet worden gecontroleerd of alles werkt en de website wordt klaargemeld aan de Customer Services, die de klant op de hoogte brengt. Het primaire proces ‘ontwikkelen van een nieuwe functionaliteit’ is een proces waarbij meerdere personen betrokken zijn en dus ook veel communicatie. De visuele weergave van dit proces is gemodelleerd in figuur 2.4. De aanvraag voor een nieuwe functionaliteit komt binnen op de Customer Services of via de Directie. Op de Customer Services wordt er een kort document gemaakt met daarin de wensen van de klant (Requirements document). Zodra bekend is dat het niet mogelijk is om de gewenste functionaliteit te bouwen of als dit niet binnen afzienbare tijd kan worden gerealiseerd, wordt dit meteen door de Research & Development afdeling aan de Customer Services doorgegeven, die dit met de klant bespreekt. Anders moet er een Development Task (Dev Task) worden aangemaakt. Een Dev Task is een taak die door de Research & Development afdeling uitgevoerd moet worden. Vanuit de Dev Task en het Requirements document wordt op de Research & Development afdeling een technische specificatie gemaakt (Requirements specification). Hiermee is het voor de ontwikkelaars duidelijk wat er gebouwd moet worden en hoe de functionaliteit moet werken. Vervolgens wordt de functionaliteit gebouwd, technische documentatie geschreven in de programmacode en de functionaliteit getest op de juiste werking. Deze stappen worden herhaald tot de functionaliteit af is. Daarna wordt een e-mail gestuurd of persoonlijk meegedeeld aan de Customer Services dat het af is. Vaak wordt de functionaliteit nog even gecontroleerd voordat de klant op de hoogte wordt gesteld.

9


Figuur 2.3 Primair proces ‘opzetten van een website’

10


Figuur 2.4 Primair proces ‘ontwikkelen van een nieuwe functionaliteit’

2.3 Capability Maturity Model Om de volwassenheid van het software ontwikkelproces bij Pharmeon te meten, is het Capability Maturity Model (CMM) gebruikt [2]. Een CMM is een referentiemodel van volwassen practices in een bepaalde discipline dat gebruikt wordt om het software ontwikkelproces te ontwikkelen en verfijnen. Het CMM deelt software ontwikkelorganisaties in een hiërarchie in van vijf niveaus, elk met een grotere bekwaamheid om software te ontwikkelen. Elk niveau wordt beschreven als een niveau van volwassenheid. De vijf niveaus beschrijven essentiële elementen die een organisatie kenmerken op een bepaald CMM niveau. Niveau 1: initial. De software ontwikkelprocessen zijn ad hoc en chaotisch. Meestal worden er maar weinig processen bepaald. Planningen lopen vaak uit, budgetten worden overschreden en procesverbetering is niet systematisch. Niveau 2: repeatable. De basis ontwikkelprocessen worden vastgezet en er is een mate van discipline om zich aan deze processen te houden. Onder normale omstandigheden is het proces goed voorspelbaar in termen van tijd, geld en hulpmiddelen. Bij invoering van nieuwe technologieën of methoden valt men nog terug op niveau 1. Niveau 3: defined. Alle processen worden bepaald, gedocumenteerd, gestandaardiseerd en in elkaar geïntegreerd. Procesverbetering vindt plaats op basis van een kwalitatieve analyse. Niveau 4: managed. De processen worden gemeten door gedetailleerde gegevens te verzamelen over de processen en hun kwaliteit. Procesverbetering vindt plaats op basis van kwantitatieve analyse. Niveau 5: optimizing. Systematische procesverbetering op basis van metingen is een geïntegreerd onderdeel geworden van de bedrijfsvoering. Nieuwe technologieën kunnen beheerst worden ingevoerd.

11


Bij Pharmeon is er wel een standaard proces dat doorlopen wordt voor het ontwikkelen van webapplicaties, maar deze wordt niet expliciet genoemd of beschreven. Het proces dat doorlopen wordt is niet gedefinieerd op papier en procesverbetering komt weinig aan de orde. Een planning wordt niet gemaakt, dus een overschrijding van planning of budget is niet echt te achterhalen. De stappen van het software ontwikkelproces zijn onder normale omstandigheden grotendeels voorspelbaar, de duur van het proces echter niet. De zojuist genoemde kenmerken van het software ontwikkelproces behoren tot het CMM niveau 1 en 2. Het software ontwikkelproces is echter niet ad hoc en chaotisch en de standaardprojecten bij Pharmeon verlopen goed. Echter bij nieuwe projecten of technologieën valt Pharmeon weer terug op een minder goed georganiseerd ontwikkelproces. Hiermee bevindt Pharmeon zich op het CMM niveau 2.

2.4 Projectenanalyse Bij Pharmeon worden verschillende projecten uitgevoerd. De grootte en het type projecten lopen sterk uiteen: de duur van een project kan 2 weken tot 1 jaar zijn. Er begint niet meer dan één project tegelijk, maar het kan wel voorkomen dat er meerdere projecten tegelijk lopen. Er worden ongeveer 35 projecten per jaar gedaan, dit betekent bijna elke week 1 nieuw project. In de projecten worden bestaande functionaliteiten uitgebreid of totaal nieuwe functionaliteiten ontwikkeld. Een project kan worden opgesplitst in meerdere taken die elk meerdere uren in beslag kunnen nemen. Afhankelijk van de grootte en type project worden er 2 tot 4 personen van de Research & Development afdeling op gezet. Op de Customer Services is er 1 persoon die betrokken bij het project die tussen de Research & Development afdeling en de klant in staat. Naast het lopende project zijn er ook nog de dagelijkse taken die uitgevoerd moeten worden. Het komt dan ook bijna niet voor dat de projectleden fulltime aan een stuk door aan het project werken. De al lopende projecten en de projecten die begonnen tijdens de eerste drie maanden van dit onderzoek zijn meegenomen in de analyse. Hierbij is gekeken naar de grootte van het project, de bezetting, de geschatte tijd dat het project in beslag neemt, de echte gespendeerde tijd aan het project, het resultaat en de status. De projecten zijn volgens de door mij opgestelde criteria in te delen in drie project grootten: klein, middel en groot. De project grootte hangt af de functionaliteiten die ontwikkeld moeten worden en het aantal bijkomende handelingen. De bijkomende handelingen kunnen het opzetten van websites of het maken van een design zijn. De projecten bij Pharmeon waren in het begin van dit onderzoek, afgezien van een uitzondering, in aantallen en grootte goed uit te voeren. Het aantal projecten groeide steeds harder en de grootte van de projecten werd steeds groter en complexer. Het gemiddeld aantal lopende projecten per maand in 2005 lag rond de 3, terwijl aan het eind van dit onderzoek het gemiddeld aantal lopende projecten per maand in 2006 al op 5 stond. Voor de ontwikkeling van de functionaliteiten wordt gebruik gemaakt van verschillende tools. Pharmeon werkt op een Microsoft Windows platform met een MS SQL database. De programma’s die gebruikt worden, verschilt per persoon. Dit hangt af van de voorkeur van de programmeur. De meest gebruikte programma’s voor het ontwikkelen van functionaliteiten zijn: Microsoft SQL Server Management Studio: database Notepad++/EditPlus: source code editor Visual Studio 2005 (ASP, .NET, C#): Integrated Development Environment (IDE) Macromedia Dreamweaver: webdevelopment tool Visual Sourcesafe: versiebeheer Om de bugs bij te houden is er een website (error handler) ingericht waar alle gegenereerde errors van de websites binnenkomen. Hier kunnen bugs aan een bepaalde persoon toegewezen worden, bugs die met elkaar te maken hebben aan elkaar gekoppeld worden en in één keer verwijderd worden als ze opgelost zijn. De projecten bij Pharmeon kwamen binnen via de directie, die met de klant contact heeft gehad. Tijdens dit contact werd besproken welke functionaliteiten er gewenst waren en met steekwoorden op papier vastgelegd. Daarna werd het document verder uitgewerkt en verdeeld in hoofdstukken, waarin in elk hoofdstuk een (nieuwe) andere functionaliteit werd uitgewerkt.

12


Vervolgens werd door de commercieel directeur een contract opgesteld op basis van een ‘fixed price’: de gewenste functionaliteiten en de daaraan verbonden uren plus nog extra ondersteunende uren. De ontwikkelaars werden vaak net voor of aan het begin van het project op de hoogte gesteld door de technisch directeur. Er werd met elk teamlid van het project apart gesproken over het project in zijn geheel en de door het teamlid te ontwikkelen functionaliteit. Er werden geen meetings gehouden aan het begin van het project, noch werden de teamleden (indien er meer dan twee teamleden in het project zaten) op de hoogte gebracht wie welke taken deed en hadden zij dus geen goed overzicht van de voortgang van het project. Wel hadden ze doordat iedereen in een ruimte zat een idee wat er allemaal gaande was en ongeveer hoever het project gevorderd was, maar precieze details over de duur en nog te ontwikkelen functionaliteit hadden ze niet tot hun beschikking. De communicatie over het project verliep vooral face-to-face en via e-mail. Vanwege de grote druk van buitenaf om snel producten af te leveren, worden de projecten vaak onderschat. De volledige requirements waren niet altijd helemaal duidelijk aan het begin van een project, waardoor het project langer duurde dan vooraf was ingeschat, indien er nog bijkomende requirements waren. De wensen van de klant werden vooraf zo duidelijk mogelijk vastgelegd en de tijdens het project was er regelmatig contact met de klant over de status van het project. De te ontwikkelen functionaliteiten werden vooraf en na oplevering besproken met de klant. Tegen het einde van het project werd de webapplicatie getest op de werking en werd een werkende webapplicatie afgeleverd aan de klant. De klant ging er vervolgens mee aan de slag en kwam vaak met verbeterpunten of laatste wensen, die dan zo snel mogelijk werden geïntegreerd. Dit koste weer extra tijd doordat alle documenten weer geopend moesten worden. De analyse van de projecten is gedaan door middel van besprekingen met de technisch directeur en raadpleging van de beschikbare documentatie. De documentatie bestond uit de toen aangemaakte Dev Tasks en memo’s. De besprekingen waren nodig om belangrijke informatie die niet terug te vinden was alsnog te achterhalen en voor duidelijkheid omtrent de aanpak van projecten. Zie tabel 2.1 voor de details over de uitgevoerde projecten. In de tabel worden de kenmerken van de projecten in een vaste volgorde besproken. Naast elk kenmerk is de bestede tijd in mensuur vermeld. Project: dit is de naam van de opdrachtgever, eventueel aangevuld met extra informatie over het project als dit maar één functionaliteit betreft. Grootte: de grootte van het project, bepaald aan de hand van criteria. Aantal personen: het aantal personen dat meewerkt aan het project. Schatting: een schatting van de tijd in mensuur dat het project in beslag zou nemen, indien een schatting gemaakt is. Doorlooptijd: de tijd in mensuur die het hele project bij elkaar in beslag heeft genomen. Status: de status van het project aan het eind van dit onderzoek. Opmerkingen: eventuele opmerkingen over het project.

13


Project Grootte Aantal personen Schatting Smoelenboek Doorlooptijd Status Opmerkingen

Intranet opzetten voor een apotheekketen Klein 4 30 mensuur 47 mensuur Afgerond 1 week uitstel door de opdrachtgever

Project Grootte Aantal personen Schatting Overnemen websites Nieuw design Intranet Doorlooptijd Status Opmerkingen

Websites opzetten voor een apotheekketen Groot 5 56 mensuur 23,5 mensuur 31,5 mensuur (7 mens/uur voor intranet design) 10 mensuur 65 mensuur (tot nu toe) Afronding Geen Customer Service uren meegeteld

Project Grootte Aantal personen Schatting Doorlooptijd Status Opmerkingen

Webshop bouwen voor een organisatie Groot 3 676 mensuur Bug fixing Uren niet goed bijgehouden sinds bug fixing

Project Grootte Aantal personen Schatting Design Webshop Doorlooptijd Status Opmerkingen

Portaal opzetten voor een cluster apotheken Middel 3 56 mensuur 22 mensuur 54,5 mensuur 79 mensuur Afronding Opzet portaal met webshop (nog niet af)

Project Grootte Aantal personen Schatting Nieuw design Overnemen websites 3 niveau menu structuur Doorlooptijd Status Opmerkingen

Websites opzetten voor een apotheekketen Groot 3 40 mensuur voor 3 niveau menu structuur 15 mensuur 49,5 mensuur 16,5 mensuur 121 mensuur (tot nu toe) Het design en de 3 niveau menu structuur zijn af Geen Customer Service uren meegeteld

Tabel 2.1 Uitgevoerde projecten bij Pharmeon (november 2005 – juni 2006)

Planning Een planning was nog niet in gebruik. Wel was het idee aanwezig dat er een planning voor de dagelijkse taken en projecten nodig was en was geprobeerd een planning op te zetten. Er was een opzet voor een planning gemaakt waarin per Dev Task de volgende informatie beschikbaar was: Plan_week: de geplande week dat een taak voltooid zou zijn End_week: de week waarin de taak voltooid is Priority: de prioriteit van de taak 14


Status_dev: de status van de taak (open, started, available4cust, w4reply, cancelled) Category: de categorie van de taak Subject: het onderwerp van de taak Follow_up date, CustID, NoteID, Naam bedrijf, Entered by De planning werd niet altijd bijgehouden en alleen bekeken door de technisch directeur. De categorieën die bestonden waren niet geschikt voor een goed werkende planning. Er waren teveel categorieën en in de namen van de categorieën zat geen structuur, logica en ordening. Voor elke taak die niet onder een bepaalde bestaande categorie viel, werd een nieuwe categorie aangemaakt. De technisch directeur wist op een bepaald moment niet wat voor taken er precies onder welke categorie allemaal vielen.

2.5 Knelpuntenanalyse Uit de bedrijfsanalyse kwam onder andere naar voren wat de primaire processen zijn bij Pharmeon. Deze primaire processen zijn nader bekeken en in kaart gebracht. Vooral het proces van software ontwikkeling is zo gedetailleerd mogelijk beschreven, waarbij de nadruk lag op de verschillende fasen van software engineering die onderscheden konden worden. In [3] worden er een aantal fasen onderscheiden bij het ontwikkelen van webapplicaties. Deze fasen zijn nagenoeg gelijk aan de fasen van software engineering bij het ontwikkelen van software. Het grote verschil is de tijd die besteed wordt aan elke fase, bij web engineering zijn deze korter en worden de fasen meerdere keren doorlopen. Alle fasen zouden doorlopen moeten worden om er zeker van te zijn dat het eindproduct aan alle eisen voldoet en van kwaliteit is. Bij Pharmeon beginnen en eindigen de meeste processen op de afdeling Customer Services. De afdeling Customer Services heeft direct contact met de klanten en alle problemen en klachten worden hier voor het eerst gemeld. Om een goede afspiegeling te krijgen van alle problemen en klachten zijn twee vaste fulltime medewerkers geïnterviewd. Het interview werd van tevoren aangekondigd, zodat de medewerkers de tijd hadden om erover na te denken. In het interview werd gebruik gemaakt van een korte vragenlijst met zowel open als meerkeuzevragen. De vragenlijst is gebaseerd op software engineering principes. Het doel van het interview was om inzicht te krijgen in de problematiek waarmee Pharmeon te maken had. Uit het interview kwamen de problemen en klachten die op de Customer Services binnenkomen naar voren. De problemen en klachten kunnen worden ingedeeld in drie categorieën. Deadlines worden niet gehaald: de afgesproken data of deadlines worden niet gehaald. Bugs op de website: deze kunnen ingedeeld worden in twee subcategorieën. o Technische bugs: de applicatie werkt niet en genereert foutmeldingen. o Design bugs: de lay-out van de website ziet er niet mooi uit. E-mail problemen: de klanten ontvangen geen e-mail of kunnen geen e-mail versturen. De verhouding tussen de bovengenoemde knelpunten was niet gelijk: in 30% van de gevallen werd de deadline niet gehaald. Ongeveer 50% van de problemen en klachten valt in de categorie bugs op de website. Hiervan was ongeveer 35% toe te schrijven aan technische bugs en 15% aan design bugs. De overige 20% kwam door e-mail problemen. De problemen en klachten zijn ontstaan uit knelpunten die zich op meerdere plaatsen in de primaire processen bevinden. De gevonden knelpunten hadden betrekking op de communicatie, de planning, het testen en documenteren. Het eerste knelpunt dat meteen opviel was de communicatie; deze verliep zowel intern als extern niet goed. Vaak was niet iedereen goed op de hoogte van nieuwe functionaliteiten en afspraken. Ook werd er niet efficiënt gecommuniceerd. Communicatie tussen de afdelingen onderling: de informatie verstrekking naar elkaar toe was niet volledig of soms werd er helemaal niet gecommuniceerd. Communicatie met de klant: de informatie die aan de klant doorgegeven werd, was vaak niet juist. Er werden beloftes gedaan die hoogstwaarschijnlijk niet konden worden nagekomen doordat er niet overlegd was over afleverdata. Ook werd de klant vaak niet op de hoogte gebracht van de status van de aanvraag of verlate afleverdata.

15


Het tweede knelpunt was de planning. Er was geen planning voor de dagelijkse taken. Hierdoor was er geen overzicht en wist niemand welk taken er in welke volgorde moesten worden gedaan. Taken werden dus meestal niet ‘first in first out’ gedaan, maar ‘first seen first done’. Datgene wat het eerst gezien werd, werd het eerst gedaan. Voor afleverdata werd met de klant altijd geschat door de Customer Services wanneer het volgens hen klaar was. Vervolgens werd dit geë-maild naar de persoon die de taak moest doen of persoonlijk gezegd. Er werd dus geen rekening gehouden met andere lopende taken, projecten die wel gepland waren en andere tussenkomende taken. Doordat er geen vaste manier was om te communiceren werden de taken die persoonlijk werden verteld vaak vergeten en de taken die via de e-mail gingen eerder gedaan. Dit zorgde voor erg chaotisch werken en frustrerende situaties. De taken die wel werden gepland waren grotere developments en projecten. Deze werden gepland door de technisch directeur in een document waar niemand van op de hoogte was. De developments en projecten werden gepland in dagen (waarbij werd uitgegaan van 100% inzet) en een schatting in uren werd niet gemaakt. Enkele dagen of net voordat het project startte, werd dit meegedeeld aan de betrokken personen en werden dus veel openstaande taken opgeschoven. Op deze manier kon het voorkomen dat enkele taken steeds maar werden opgeschoven, waardoor de Customer Services nogal eens in de problemen kwamen. Het derde knelpunt was het testen. Het testen van de applicaties gebeurde niet uitgebreid genoeg. De applicaties werden tijdens het bouwen ervan, door de programmeur, steekproefsgewijs getest door de applicatie op de testserver te doorlopen. Hierbij werden soms niet alle mogelijke opties getest. Regressietesten werden vaak vergeten of niet uitgevoerd waardoor eerder werkende programmacode na aanpassing daarvan niet meer werkte. Vooraf werden er geen test cases beschreven of testen geschreven waarmee de programmacode werd getest. Vaak werden er dingen over het hoofd gezien doordat er grotendeels werd gedacht en getest vanuit het perspectief van de programmeur en niet vanuit de klant. Nadat de applicatie op de testserver goed was doorlopen, werd de applicatie door de programmeur live op de website gezet. De grootste belemmering was de grote tijdsdruk waaronder de ontwikkelaars werken en waarmee de applicaties moeten worden afgeleverd. Doordat er niet genoeg tijd beschikbaar was, had het testen geen vaste plaats in het ontwikkelproces en werd het bijna automatisch naar achter geschoven en was de overgebleven tijd om te testen te weinig. Het vierde en laatst knelpunt was documenteren. Documenteren leek bijna een luxe. Bij Pharmeon werd weinig documentatie gemaakt. De bestaande documentatie over applicaties waren technische documentatie of technische specificaties. Documentatie over de werking van de applicaties of gebruikersdocumentatie was er helemaal niet. Requirements documents en/of requirements specifications werden niet altijd gemaakt. Vaak gebeurde dit wel voor grote, nieuwe functionaliteiten en projecten om ervoor te zorgen dat deze tijdsrovende taken in één keer goed werden gedaan en daarmee dus tijd te besparen. De knelpunten zijn in figuur 2.5 uitgewerkt. Het visgraatdiagram toont 4 assen waarop de knelpunten en de daarbij horende oorzaken. De problemen bevinden zich vooral in de methode en medewerkers en deels in de omgeving. Aan de materialen valt niets te wijten.

16


Figuur 2.5 Visgraatdiagram van de knelpunten bij Pharmeon

2.6 Conclusies Pharmeon is een klein informeel bedrijf waar de klant voorop staat. Soms is dit voor de klant zelf weinig merkbaar doordat de doorlooptijd lang is of omdat de afgeleverde functionaliteit niet helemaal voldoet aan de wensen van de klant. Pharmeon is hard groeiende en kan de taken die binnenkomen moeilijk bijhouden. Door de grote tijdsdruk worden de laatste belangrijke stappen, die de kwaliteit van het product moeten bewaken, versneld doorlopen of overgeslagen. De kwaliteit moet verbeterd worden om de klanten tevreden te houden. Dit geldt niet alleen voor taken, maar ook voor projecten waarbij grote functionaliteiten worden ontwikkeld. De projecten die worden uitgevoerd, variëren in type en grootte en de nieuwe projecten zijn in de meeste gevallen een grote uitdaging. De projecten worden steeds groter en de te ontwikkelen functionaliteiten steeds complexer. Hierdoor is het van groot belang dat de projecten in goede banen worden geleid en met succes afgerond worden. Een goede planning van zowel de projecten als de dagelijkse taken is dan heel belangrijk om ervoor te zorgen dat de dagelijkse taken ook nog worden afgemaakt en niet vergeten worden vanwege een project. Tijdens een project komen de knelpunten naar voren. De knelpunten bij Pharmeon worden steeds duidelijker en zichtbaarder voor de medewerkers van Pharmeon en merkbaar voor de klanten. Dit komt voor een deel vanwege het gebrek aan regels en procedures. Een goed voorbeeld daarvan is de manier waarop een afgemaakte Dev Task aan de Customer Services wordt doorgegeven. Dit kan op drie manieren gebeuren: persoonlijk, per e-mail of helemaal niet. Dit brengt de nodige verwarring met zich mee en doordat de communicatie niet efficiënt verloopt ook een aantal problemen. De knelpunten waarmee Pharmeon dagelijks mee te maken heeft, zoals besproken in paragraaf 2.5, zijn: slechte communicatie tussen de medewerkers onderling en met de klant weinig tot geen gebruikersdocumentatie en technische documentatie van de bestaande functionaliteiten geen uitgebreide testen van producten die worden opgeleverd geen planning van de dagelijkse taken en projecten

17

18

Hoofdstuk 3 Mogelijke oplossingen

Hoofdstuk 3 Mogelijke oplossingen In dit hoofdstuk zullen mogelijke oplossingen worden besproken voor de naar voren gekomen knelpunten van hoofdstuk 2. De meeste van deze knelpunten vallen onder het niet goed afronden van processen. Vooral de kwaliteit van de opgeleverde producten heeft hieronder te lijden. De knelpunten communicatie, planning, testen en documenteren kunnen bij het ontwikkelen van software voor een groot deel in één keer opgelost worden door aanpassing van de huidige software methode. Daarnaast zal het opstellen van regels en procedures de communicatie helpen verbeteren [4], doordat iedereen weet wat en hoe dingen aangepakt moeten worden en aangesproken kunnen worden waarbij verwezen kan worden naar de betreffende regel of procedure. De belangrijkste verandering die tevens de basis vormt voor goede software ontwikkeling is het maken van een planning. Een planning zal geen succes garanderen, maar geen planning garandeert wel mislukking [5]. In deze planning worden alle dagelijkse taken en projecten ingepland, de uren en alle relevante informatie betreffende de klant bijgehouden. Vervolgens moet er een gepaste software methode worden gevonden, die de knelpunten aanpakt. Er zullen oplossingen worden besproken die deels op wetenschappelijke gronden en deels op ervaringen van practitioners die gebaseerd zijn. Practitioners zijn personen die de software methode al toegepast hebben op een afdeling, succesvol of niet. Op de oplossingen voor software ontwikkelmethoden heeft een selectie plaatsgevonden die in paragraaf 3.1 besproken zal worden.

3.1 Software methoden Volgens The Standish Group International, die een top tien van faalfactoren in projecten heeft samengesteld in de Verenigde Staten [6], staat op de tweede plaats betrekking van de klant, op de zesde plaats een standaard software infrastructuur en op de achtste plaats een formele methodologie. In een methodologie wordt naast de methode ook uitgelegd hoe problemen moeten worden aangepakt. Bij software ontwikkelingmethoden wordt vaak gedacht aan conventionele methoden zoals het waterval-model of een daaruit geëvolueerde variant. Bij conventionele software ontwikkelmethoden wordt alle fasen een keer doorlopen en elke volgende fase begint als de vorige is afgerond. In deze methode wordt er aan het einde getest en gedocumenteerd waarna de software wordt afgeleverd. Er is weinig plaats voor aanpassingen of feedback van de gebruiker nadat het systeem al in ontwikkeling is [7]. Hier tegenover staan de agile software ontwikkelmethoden. Bij de agile methoden worden alle fasen iteratief en incrementeel doorlopen. Hierbij is er wel plaats voor veranderingen en feedback, deze worden in de volgende iteratie meegenomen en in de software geïntegreerd. Bij de keuze voor een software ontwikkelmethoden is gekeken naar het bedrijf zelf, het soort projecten dat wordt gedaan en wat er tijdens de projecten wordt opgeleverd. Zoals gebleken uit de conclusie van hoofdstuk 2, zijn de projecten bij Pharmeon dynamisch en meestal kortdurend. In de projecten worden webapplicaties ontwikkeld met een klein en hecht ontwikkelteam. Het verschil tussen agile methoden en andere iteratieve methoden is dat de duur van een iteratie korter is. Bij iteratieve methoden wordt de lengte van een iteratie gemeten in maanden, bij agile methoden in weken. Ook bieden agile methoden meer dan het ontwikkelen van software in iteraties. Agile methoden maken wel gebruik van iteraties, maar bieden daarnaast een raamwerk richting management en software ontwikkeling. Elke iteratie is een mini-project waarin activiteiten als analyse, ontwerp, implementatie en testen voorkomen. Voor de software ontwikkelmethode is gekozen voor de agile software ontwikkelmethoden. Deze passen beter doordat ze flexibel zijn en er is rekening wordt gehouden met nog niet duidelijke en veranderende requirements van de klant. Agile methoden lijken wat betreft de fasen die doorlopen worden erg op de traditionele software ontwikkelmethoden. Voor een groot deel worden dezelfde fasen doorlopen, alleen worden deze iteratief doorlopen. Hierdoor hebben de agile methoden de laatste jaren aandacht gekregen, ze benaderen de software ontwikkeling vanuit het perspectief van de ontwikkelaar. Het grote verschil

19


echter is dat agile methoden uitermate geschikt zijn voor de ontwikkeling van software waarbij er sprake is van veranderingen en het van belang is dat er snel gereageerd wordt op de veranderende situatie. De naam agile spreekt hier dus voor zich: lenig. Er bestaan meerdere agile methoden die elk de nadruk leggen op de volgende aspecten: incrementeel: kleine software afleveringen met snelle cycli coöperatief: klant en ontwikkelteam werken constant en nauw samen eenvoudig: de methode is makkelijk te leren, aan te passen en goed gedocumenteerd aanpasbaar: het is mogelijk om op het laatste moment nog aanpassingen te maken aan de funtionaliteit die wordt ontwikkeld De agile methoden komen voort uit een verklaring, die door de Agile Alliance is opgesteld in de Agile Manifesto [8]. Ook hebben zij 12 principes opgesteld die ten grondslag liggen aan de Agile Manifesto. De Agile Manifesto wordt wel gezien als de definitie van agile ontwikkeling en de bijbehorende principes. Hieronder volgt het Agile Manifesto. “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.” (Agile Manifesto, http://www.agilemanifesto.org) Samengevat volgt het volgende uit het Agile Manifesto. De ontwikkelaars moeten samenwerken en moeten dit effectief doen. Zolang er niet effectief wordt gewerkt, zullen zelfs de beste tools en goed gedefinieerde processen niet helpen. Werkende software heeft meer waarde dan ingewikkelde documentatie. Het primaire doel van software ontwikkeling is het afleveren van software, niet van documentatie. De klant begrijpt ook meer van werkende software die iets laat zien dan van ingewikkelde diagrammen en modellen. Alleen de klant weet precies wat hij wilt. Dit komt niet allemaal in één keer boven tafel, maar door nauw samen te werken met de klant kunnen de requirements boven tafel worden gehaald. Een contract kan niet de communicatie tussen de ontwikkelaars en de klant vervangen. Verandering hoort bij software ontwikkeling, dit moet terugkomen in de manier waarop op verandering wordt gereageerd. In een projectplan staat alles al van tevoren vast, maar hier moet ruimte zijn voor verandering anders wordt het projectplan ineens naar de achtergrond geschoven.

3.2 Onderzoeksmethode Uit de bestaande agile software ontwikkelmethoden is een selectie gemaakt, die toegepast zouden kunnen worden op de ontwikkeling van software. In paragraaf 3.3 worden alleen agile methodologieën beschreven die als zodanig worden aangeduid. Methodologieën die zich richten op modellerings- of programmeertechnieken zoals Agile Modeling, waarin uitgebreid aan het bod komt hoe geavanceerde modellen kunnen worden gemaakt, worden niet meegenomen. In Pragmatic Programming worden 70 tips aangestipt die de ‘best practices’ vormen voor programmeren. Ook methodologieën waarin geen practices of processen worden beschreven komen niet aan de orde (bijvoorbeeld Lean Development). Deze methodologieën zouden de kans op succesvolle aanname van de methodologie verminderen aangezien er geen concrete regels zijn die gevolgd kunnen worden. De besproken methodologieën zijn op zichzelf staande methoden die apart, maar ook samen gebruikt zouden kunnen worden. De besproken methodologieën zijn daadwerkelijk gericht op het ontwikkelen van software en niet voornamelijk op het concept, de filosofie of de cultuur erachter (bijvoorbeeld Adaptive Software Development). Daarnaast zijn de methodologieën duidelijk

20


omschreven (in tegenstelling tot Crystal Family) en zijn er meerdere publicaties over de methodologie verschenen. Om de verschillende agile methodologieën op een snelle manier duidelijk te maken, worden alle methoden besproken aan de hand van een aantal vooraf bepaalde vragen. De resultaten zijn gevonden door middel van een literatuuronderzoek naar bestaande software ontwikkelmethoden. Hierbij is gebruik gemaakt van zowel internet als wetenschappelijke literatuur (boeken en gepubliceerde artikelen). De meeste literatuur die gevonden is, is geschreven door personen die de methodologie zelf hebben toegepast. In de meeste gevallen zijn dit geen onafhankelijke publicaties.

3.3 Resultaten In deze paragraaf worden de resultaten van de literatuurstudie beschreven. De resultaten die in de paragrafen 3.3.1 t/m 3.3.4 zullen worden besproken, zijn overgebleven uit de selectie van paragraaf 3.2. Hoewel niet van elke methodologie alles tot in detail gedocumenteerd is, is er toch geprobeerd om een goed beeld te schetsen door een vaste structuur aan te houden. Elke subparagraaf heeft een vaste opbouw waarin de volgende vragen zullen worden besproken: wat is de methodologie? hoe wordt de methodologie gevolgd? wie doen mee? wat zijn de voor- en nadelen?

3.3.1 Extreme Programming Extreme Programming (XP), is de bekendste van de agile software methodologieën. Deze paragraaf is gebaseerd op [9,10,11]. XP is ontstaan uit de problemen die in de conventionele software ontwikkeling bestonden met lange ontwikkelcycli. Er wordt gebruik gemaakt van bekende software engineering practices. XP is een op vier waarden gebaseerde methodologie: communicatie: er is sprake van een mondelinge cultuur en de practices zijn gemaakt op het bevorderen van interactie binnen het team. eenvoud: er wordt altijd geprobeerd het eenvoudigste product dat aan de eisen van de klant voldoet te ontwikkelen. Hierbij dient niet alleen rekening te worden gehouden met de eisen, maar ook met onuitgesproken requirements. feedback: het team krijgt feedback van de klanten aan het eind van elke iteratie. Deze feedback stuurt de volgende iteratie. Hiernaast zijn er ook korte ontwerp en implementatie feedback loops ingebouwd in de methodologie. lef: de eerste drie waarden geven het team de mogelijkheid om lef te tonen in de acties en beslissingen die worden genomen. De ontwikkelaars moeten dus zich comfortabel voelen om veranderingen in programmacode aan te brengen en onnodige programmacode te verwijderen indien dit nodig is. Later is er nog een vijfde waarde toegevoegd: respect. Deze waarde heeft meerdere betekenissen. Teamleden respecteren elkaar, omdat programmeurs geen veranderingen maken waardoor de compilatie van de programmacode mislukt, bestaande unit tests falen of andere programmeurs vertraging oplopen. De teamleden respecteren hun eigen werk door altijd te streven naar hoge kwaliteit en te zoeken naar het beste ontwerp voor een oplossing door middel van refactoring. XP vertrouwt op mondelinge communicatie, geproduceerde code en het overdragen van kennis. Voor kleine teams werkt dit goed, maar voor grotere teams kunnen documenten goed van pas komen. De volgende documenten en artefacten kunnen gebruikt worden. User story cards: een kaart met een omschrijving van een requirement. Task list: een lijst met alle taken die gedaan moeten worden in een iteratie. Customer acceptance test: beschrijving van een test case gemaakt door de klant. Het ontwikkelteam laat aan de klant zien dat een user story af is en aan de requirement is voldaan door de acceptance test cases met succes te doorlopen. Visible wall graphs: de grafieken laten zien hoeveel user stories gecompleteerd zijn en/of hoeveel acceptance test cases met succes gerund zijn.

21


Practices XP is gebaseerd op de volgende twaalf best practices. 1. Simple design: het eenvoudigste ontwerp dat voldoet zal worden gebruikt. Het ontwerp kan in een vergadering met het team besproken worden. 2. Testing: er wordt gefocust op software validatie op elk moment. De programmeur schrijft eerst de testcode (unit test) voordat hij de functionaliteit codeert. Alle user stories hebben tenminste een acceptance test, bij voorkeur een automatische. Wanneer de acceptance test(en) van een user story met succes doorlopen wordt, is deze voltooid. De automatische unit tests worden incrementeel geschreven gebruik makend van test-driven development (TDD). Met TDD wordt programmacode geschreven door middel van snelle iteraties van de volgende stappen: (1) schrijven van automatische test cases (2) het runnen van deze unit test cases om te controleren dat ze mislukken (3) het implementeren van de programmacode om de unit test cases te doen slagen (4) opnieuw runnen van de test cases om te controleren of ze nu slagen (5) refactoring van de programma- of testcode, indien nodig (6) het opnieuw runnen van alle test cases om ervoor te zorgen dat de nieuwe programmacode niet zorgt voor het falen van eerder gerunde test cases 3. Refactoring: continue herstructurering van de programmacode. Hierbij wordt het ontwerp/structuur van de programmacode verbeterd zonder dat de functionaliteit verandert. Refactoring is een practice met als doel het verbeteren van de reactie op verandering, zodat bij elke verandering het systeem makkelijk aanpasbaar is. 4. Continuous integration: continue integratie van alle programmacode. Alle programmeurs integreren stukjes programmacode enkele malen per dag. Programmacode mag alleen worden geïntegreerd als alle bijbehorende unit tests en de unit tests van de gehele programmacode met succes worden gerund. 5. Collective code ownership: iedere ontwikkelaar heeft gelijke rechten over alle programmacode. Als de programmacode en de bijbehorende testen eenmaal zijn geïntegreerd tot een geheel, mag de programmacode door elk teamlid veranderd worden. Dit geeft elk teamlid het gevoel dat het ook van hem is en voorkomt knelpunten die veroorzaakt zouden kunnen worden doordat degene die de programmacode heeft geschreven niet aanwezig is om de verandering te maken. 6. Coding standards: iedere ontwikkelaar hanteert dezelfde stijl van code schrijven. 7. Pair programming: twee programmeurs werken samen achter een computer. Ze werken samen aan hetzelfde design, algoritme, programmacode of test. Een programmeur neemt de taak op zich van het typen of vastleggen van een design, terwijl de andere aandachtig meekijkt en problemen identificeert en suggesties voorstelt. Meestal wordt er tijdens een project meerdere keren de samenstelling van paren veranderd, dit helpt om de opgedane kennis over het team te verspreiden. 8. On-site customer: de klant is onderdeel van het ontwikkelteam en moet dus continu voor vragen beschikbaar zijn. De klant schrijft ook de acceptance tests. Wanneer de klant niet aanwezig kan zijn, wordt er een vertegenwoordiger aangewezen. Meestal is dit iemand die kennis heeft over het domein en de eisen. Als er een vertegenwoordiger wordt gebruikt, moeten echte klanten deelnemen aan het eind van elke iteratie en/of bij de planning game aanwezig zijn. 9. Small, frequent releases: het systeem wordt afgeleverd in evolutionaire stappen, waarbij de functionaliteit van het systeem steeds toeneemt. De uiteindelijke aflevering van het systeem is in XP projecten meestal binnen een jaar vanaf het begin van het project en iteraties duren tussen de een en drie weken. Kleine afleveringen geven voldoening aan het team en zijn de belangrijkste bron van feedback van de klant. 10. Iteration/release planning game: in een sessie geven de klanten prioriteiten aan de eerder opgeschreven functionaliteiten (user stories). De ontwikkelaars geven een schatting van de benodigde tijd. Hiermee kiezen de ontwikkelaars samen met de klant de functionaliteiten die de hoogste prioriteit hebben voor de volgende iteratie. De klant kan tussentijds nieuwe functionaliteiten toevoegen. Dit kan alleen als andere functionaliteiten uit de huidige iteratie verschoven worden. Iteraties zijn interne deadlines voor het team 22


en tegelijkertijd ook meetpunten om feedback van de klant te krijgen. Na elke iteratie wordt het systeem aan de klant afgeleverd. 11. System metaphor: alle teamleden (ontwikkelaars en de klant) ontwikkelen een thema of metafoor waardoor er een gemeenschappelijk beeld van het systeem ontstaat. Dit draagt bij aan de communicatie en om een hoog niveau beeld van het systeem te krijgen. 12. Sustainable pace: overwerken is een uitzondering. Er wordt niet voor langere perioden overgewerkt. Een werkdag is acht uur. Langere werkdagen zorgen voor vermoeidheid en ontevreden werknemers. Dit draagt niet bij aan de kwaliteit van het systeem en de verzuiming. De kracht van XP komt voort uit het in samenhang toepassen van de twaalf best practices doordat de practices samen elkaar versterken. Naast de twaalf best practices zijn er nog enkele activiteiten die consistent zijn met de principes van XP en dus ook gebruikt kunnen worden. De eerste is een dagelijkse stand-up meeting . In deze meetings staan de teamleden in een cirkel, dit is om de meeting kort te houden. Om de beurt vertelt elk lid aan de groep: wat hij/zij de vorige dag heeft gedaan wat hij/zij van plan is om vandaag te doen de obstakels of problemen die hij/zij is tegengekomen, zonder over oplossingen te discussieren De paren voor de pair programming worden tijdens de stand-up meeting gevormd terwijl de taken voor die dag worden besproken en de twee programmeurs die het best geschikt zijn voor de taak werken samen. De tweede activiteit is retrospectives. Aan het einde van elke iteratie vindt er een retrospectie plaats waarin wordt besproken wat er goed ging en wat er verbeterd kan worden. Hierbij kunnen er dingen geleerd worden en kunnen practices aangepast worden zodat deze beter passen. Rollen In XP zijn er verschillende rollen weggelegd, die elk hun eigen taken hebben. Dit zijn: Manager De manager is de leider, vormt het team, verkrijgt de benodigde bronnen, stuurt het team en de problemen en houdt zich bezig met externe groepen. Coach De coach leert het team over de processen bij XP, springt zonodig bij bij problemen en kijkt of de XP processen worden gevolgd. De coach is geen manager. Tracker De tracker verzamelt de user stories en acceptance tests cases van de programmeurs om er grafieken te maken. De tracker is geen manager of klant. Programmeur De programmeur schrijft testen, ontwerpt en programmeert. De programmeur refactort regelmatig en identificeert en schat de taken en user stories in. De programmeur kan ook tester zijn. Tester De tester helpt de klant met het schrijven en ontwerpen van testen. Klant De klant schrijft user stories en acceptance tests en kiest de user stories voor elke iteratie. De rol van klant hoeft niet per se door de klant zelf vervuld worden, dit kan ook een groep klanten zijn of een vertegenwoordiger zijn die buiten het ontwikkelteam staat. Proces De levenscyclus van XP bestaat uit vijf fasen: exploration, planning, iterations to release, productionizing, maintance en death. Deze fasen zijn in figuur 3.1 weergegeven. Exploration phase: in deze fase schrijft de klant alle functionaliteiten op die in de eerste iteratie moet worden meegenomen op zogenaamde story cards. Elke story card beschrijft een functionaliteit die aan het systeem moet worden toegevoegd. Tegelijkertijd maakt het team zich bekend met de practices, de technologie en de tools die zij in het project zullen gebruiken. De technologie die gebruikt zal worden, wordt getest en de mogelijkheden qua architectuur worden

23


onderzocht door een prototype van het systeem te bouwen. De Exploration phase neemt enkele weken tot enkele maanden in beslag afhankelijk van de bekendheid van de programmeurs met de technologie. Planning phase: hier wordt de prioriteit van de functionaliteiten gegeven en wordt er een overeenkomst gesloten over de inhoud van de eerste iteratie. De programmeurs schatten eerst in hoeveel tijd elke functionaliteit in beslag neemt en op basis daarvan wordt een planning gemaakt. De tijd waarin de functionaliteiten worden gepland van de eerste iteratie duurt niet langer dan twee maanden. Het maken van de planning zelf neemt enkele dagen in beslag. Iteration to Release phase: deze fase bevat meerdere cycli van het systeem voordat de eerste aflevering plaatsvindt. De planning die in de vorige fase gemaakt is, wordt verdeeld over een aantal cycli die elk één tot vier weken duurt om te implementeren. In de eerste cyclus wordt het systeem met de architectuur gemaakt. Dit wordt bereikt door de functionaliteiten te selecteren die dwingen om de structuur voor het hele systeem te bouwen. De klant beslist uiteindelijk wel de geselecteerde functionaliteiten voor elke iteratie. De functionele testen die door de klant zijn gemaakt, worden aan het eind van elke iteratie uitgevoerd. Aan het eind van de laatste cyclus is het systeem klaar voor productie. Productionizing phase: in deze fase wordt het systeem nog extra getest en gecontroleerd op de prestatie voordat het systeem aan de klant wordt afgeleverd. In deze fase kan het voorkomen dat er veranderingen optreden en moet er besloten worden of dit in de huidige of in de volgende aflevering verwerkt wordt. De cycli in deze fase worden versneld van drie naar een week. De uitgestelde ideeën en suggesties worden genoteerd voor latere implementatie. Na de eerste aflevering moet het project zowel het systeem dat in productie is als nieuwe iteraties gaande houden. Om hiervoor te zorgen is er een Maintenance phase. Hierin wordt vereist dat er ook aandacht wordt besteed aan klantondersteuning. Hierdoor kan de snelheid van de ontwikkeling van het systeem afnemen. De Maintenance phase kan ervoor zorgen dat er nieuwe mensen in het team komen en dat de structuur van het team daarmee verandert. De Death phase begint als de klant geen nieuwe functionaliteiten meer heeft die geïmplementeerd moeten worden. Hiervoor moet het systeem de klant tevreden stellen in alle opzichten (bijvoorbeeld prestatie, betrouwbaarheid). Pas in deze fase wordt de benodigde documentatie van het systeem gemaakt, nadat er geen veranderingen meer optreden in de architectuur, ontwerp of programmeercode. De Death phase kan ook voorkomen als het systeem niet de gewenste uitkomsten produceert of als het te duur wordt voor verdere ontwikkeling.

Figuur 3.1 XP proces

Voor- en nadelen XP kent vele voordelen waaronder de meest belangrijkste: je hoeft niet alle XP practices in een keer over te nemen. Het is mogelijk en wordt aangeraden om ze een voor een in de routine te passen. Begin bij het grootste probleem in het proces en probeer het op te lossen door een of meerdere XP practices toe te passen. Een sterk punt van XP is dat de aandacht gevestigd wordt op concrete ondersteuning waardoor de practices makkelijk te volgen en aan te passen zijn naar 24


de eigen situatie. Hierdoor kan een eigen ontwikkelstijl ontwikkeld worden. Bij XP wordt er gezamenlijk als een hecht team samengewerkt en helpt iedereen elkaar om tot een succesvol eindproduct te komen. Een nadeel van XP kan zijn dat het het best werkt met kleine teams die in één ruimte zitten. Bij grotere teams is het al moeilijker om de XP practices te volgen, helemaal als de teams niet op eenzelfde locatie zitten. Ook de practices TDD en pair programming kunnen op weerstand stuiten, omdat deze practices voor de programmeurs niet intuïtief kunnen werken. Uit de resultaten van [11] is gebleken dat XP na de eerste release zorgt voor een verbetering in verschillende opzichten. De productiviteit is omhoog gegaan met 12 programmacode regels per uur en de nauwkeurigheid van de geschatte tijdsbestedingen is verbeterd met 26%. De practices van XP zijn niet nieuw, de manier waarop de individuele practices zijn verzameld en opgesteld om elkaar te versterken wel.

3.3.2 Scrum Scrum is een empirische benadering van software ontwikkeling gebaseerd op flexibiliteit, aanpasbaarheid en productiviteit. Zie [9] voor een overzicht. Scrum houdt zich vooral bezig met project management principes, waaronder hoe een team zou moeten samenwerken om in een veranderende omgeving kwalitatieve producten op te leveren. De methodologie geeft het team de vrijheid om zelf specifieke softwareontwikkeling technieken, methoden en practices te kiezen. Er worden drie belangrijke documenten gemaakt door het Scrum team: de Product Backlog, de Sprint Backlog en de Sprint Burndown Chart. Alle drie de documenten zijn goed toegankelijk voor het Scrum team. Hieronder volgt een korte beschrijving van de documenten. Product Backlog: dit is een geprioriteerde rij van functionaliteiten die nog moeten worden ontwikkeld in het systeem en defecten die gemaakt moeten worden. Dit document verandert mee tijdens het hele proces en wordt in een spreadsheet bewaard. Voor elke eis bevat de Product Backlog een aantal waarden: de categorie (functionaliteit, verbetering, defect), de status, de prioriteit en de geschatte tijd die nodig is om aan de eis te voldoen. Sprint Backlog: hierin staan alle functionaliteiten, verbeteringen en defecten opgesomd die staan gepland voor de huidige iteratie (dit wordt een Sprint genoemd). De Sprint Backlog wordt ook in een spreadsheet format bijgehouden. De eisen van het systeem worden opgedeeld in taken. Voor elke taak in de Backlog bevat deze een korte omschrijving, van wie de taak afkomstig is, van wie de taak is, de status en het aantal uur dat nog open staat om de taak af te maken. Het is niet toegestaan om veranderingen aan te brengen in de Sprint tijdens de Sprint. Sprint Burndown Chart: in dit document staan de resterende uren die nog voltooid moeten worden voordat de Sprint taken af zijn, vermeld in een grafiek. Deze grafiek is goed zichtbaar voor het team. Rollen De rollen die in Scrum voorkomen zijn: Product Owner De product owner is verantwoordelijk voor het maken en prioriteren van de Product Backlog, kiest welke functionaliteiten worden meegenomen in de volgende Sprint en beoordeelt het systeem samen met andere betrokkenen aan het eind van elke Sprint. Scrum Master De scrum master is bekend met de waarden en practices van Scrum, bevordert iteratie en doelen, leidt de dagelijkse vergadering (Scrum Meeting) en de iteratie demonstratie (Sprint Review), ziet toe op de voortgang van het project, verwijdert belemmeringen en zorgt voor de benodigde resources. De Scrum Master is ook een developer en doet mee met systeemontwikkeling. Developer De developer is lid van het Scrum team. Het Scrum team bestaat uit developers en zet zich in om een Sprint Goal te behalen en doen alles om de Goal te behalen. De grootte van een Scrum team is ongeveer zeven personen. Proces De levenscyclus van Scrum bestaat uit de volgende activiteiten.

25


Aan het begin van een project wordt er een Sprint Planning vergadering gehouden met het ontwikkelteam, het management en de product owner. De product owner is een vertegenwoordiger van de klant of een afvaardiging van klanten. Ook maakt en prioriteert de product owner de Product Backlog. In de planning vergadering kiest de product owner welke functionaliteiten worden meegenomen in de Sprint (die 30 dagen duurt), meestal zijn dit die het meest van belang zijn en het hoogste risico met zich meebrengen. Daarnaast wordt er een Sprint Goal vastgesteld die dient als de minimale succes criteria voor de Sprint het houdt het Scrum team geconcentreerd op het grotere geheel. Het ontwikkelteam bepaalt welke taken en resources nodig zijn om de functionaliteiten af te leveren. Hierna beslissen het ontwikkelteam en de klant samen een aantal functionaliteiten die binnen de tijd in de volgende Sprint worden meegenomen. Wanneer deze functionaliteiten bekend zijn, kan er geen re-prioritering plaatsvinden gedurende de 30 dagen durende Sprint die volgt, waarin de functionaliteiten worden ontworpen, geïmplementeerd en getest. Gedurende een Sprint wordt de programmacode dagelijks geïntegreerd en opnieuw getest. Dagelijks wordt een 15 minuten durende meeting (Scrum Meeting) gehouden. De meeting wordt gehouden in een ruimte met een whiteboard zodat de taken kunnen worden opgeschreven. De meeting is voor iedereen toegankelijk, maar alleen de teamleden en de Scrum Master mogen praten. Elk teamlid beantwoordt tijdens de meeting de volgende vragen: wat heb je gedaan sinds de laatste Scrum Meeting? wat ga je doen voor de volgende Scrum Meeting? welke problemen kwam je tegen? De Scrum Meeting is een essentieel onderdeel van de methodologie. Sociale afspraken worden gemaakt tijdens de meeting die ervoor lijken te zorgen dat de verantwoordelijkheid en afwerking toenemen en houden het project op schema. Echter, de meetings kunnen oncontroleerbaar worden als er teveel personen zijn, daarom wordt het aangeraden om de teams een maximum van zeven leden heeft. Voor grotere teams wordt het team verdeeld in kleinere groepen die elk hun eigen meeting hebben. De vertegenwoordiger van elke groep gaat naar een ‘Scrum of Scrums’ meeting, waar hij dezelfde vragen beantwoordt om de activiteiten van zijn groep te laten zien. Aan het einde van een Sprint vindt er een vergadering plaats (Sprint Review) om de voortgang te beoordelen, de functionaliteiten te demonstreren aan de klant, het management en de gebruikers. De product owner beoordeelt het project vanuit een technisch perspectief. De Sprint Review wordt geleid door de Scrum Master, de product owner en andere geïnteresseerden bij de vergadering. De nieuwste versie van het systeem wordt gedemonstreerd waarin de functies, het ontwerp, de zwakke en sterke punten en probleemgebieden worden gedeeld met de product owner. De nadruk ligt op de presenteren van het systeem waarbij formele presentaties zoals Microsoft PowerPoint presentaties verboden zijn. De cyclus eindigt weer met een Sprint Planning meeting die het begin van de volgende cyclus introduceert. Het proces is in figuur 3.2 samengevat.

Figuur 3.2 Scrum proces

26


Voor- en nadelen Scrum biedt alleen richtlijnen aan voor project management en geen concrete methoden of technieken. Dit betekent dat Scrum alleen niet voldoende is en aangevuld moet worden met een andere methodologie die een benadering op software ontwikkeling aanbiedt. Een belangrijk nadeel van Scrum is dat er tijdens de Sprint geen veranderingen mogen worden aangebracht in de Sprint Backlog. Dit betekent dat er geen flexibiliteit zit in de requirements die geïmplementeerd moeten worden tijdens een Sprint en er dus niet meteen kan worden gereageerd op veranderende requirements. De klant kan pas na afloop van de Sprint de requirements voor de volgende Sprint re-prioriteren.

3.3.3 Dynamic Systems Development Method Het fundamentele idee achter de Dynamic Systems Development Method (DSDM) is om in plaats van de hoeveelheid functionaliteit van een systeem vast te zetten en daarop de tijd en resources op aan te passen juist de tijd en resources vast te zetten en vervolgens de hoeveelheid functionaliteit daarop af te stemmen. DSDM is ontstaan uit Rapid Application Development (RAD). Voor een overzicht zie [12,13]. Practices DSDM heeft negen practices die de ideologie definiëren en de basis zijn voor alle activiteiten. Deze practices worden de principes van DSDM genoemd. 1. Active user involvement is imperative: een aantal gebruikers moeten aanwezig zijn tijdens de ontwikkeling van het systeem om voor tijdige en precieze feedback te geven. 2. DSDM teams must be empowered to make decisions: lange beslissingsprocessen horen niet thuis in snelle ontwikkelcycli. De betrokken gebruikers hebben de macht om beslissingen te maken. 3. The focus is on frequent delivery of products: verkeerde beslissingen kunnen worden gecorrigeerd als de ontwikkelcycli kort zijn en de gebruikers goede feedback geven. 4. Fitness for business purpose is the essential criterion for acceptance of deliverables: eerst moet zeker zijn dat het juiste systeem wordt gebouwd, voordat het goed wordt gebouwd. Voordat de belangrijke delen van het systeem goed zijn ingebouwd, moet technische perfectie in minder belangrijke delen niet worden nagestreefd. 5. Iterative and incremental development is necessary to converge on an accurate business solution: systeem requirements blijven zelden hetzelfde van het begin tot eind van een project. Door het systeem te laten evolueren door middel van iteratieve ontwikkeling, kunnen veranderingen snel worden geïntegreerd. 6. All changes during development are reversible: tijdens de ontwikkeling kan er snel voor een verkeerde richting worden gekozen. Door korte iteraties te gebruiken en ervoor te zorgen dat er naar eerdere versies terug kan worden gegaan, kan een verkeerd genomen richting gecorrigeerd worden. 7. Requirements are baselined at a high level: de initiële requirements moeten op hoog niveau worden vastgezet, zodat de details ervan kunnen veranderen indien nodig. Dit zorgt ervoor dat belangrijke requirements vastgezet worden in een vroeg stadium van ontwikkeling, maar dat de ontwikkeling kan beginnen voordat alle requirements definitief ingevuld en vastgezet zijn. Tijdens de ontwikkeling worden steeds meer requirements ingevuld en vastgezet zodra het duidelijk is en er overeenstemming over is bereikt. 8. Testing is integrated throughout the lifecycle: door de tijdsdruk wordt testen nogal eens verwaarloosd als het aan het eind van het project aan de beurt is. Daarom zou elk deel van het systeem getest moeten worden door de ontwikkelaars en de gebruikers terwijl ze ontwikkeld worden. Het testen gebeurt incrementeel en de testen die gemaakt worden, worden steeds ingewikkelder door het project heen. Regressie testen is in het bijzonder belangrijk door het evolutionaire ontwikkelproces. 9. A collaborative approach shared by all stakeholders: de organisatie moet hetzelfde doel voor ogen hebben en gedreven zijn. De keuze wat er afgeleverd moet worden en wat niet is altijd een kwestie van compromissen sluiten en vereist overeenstemming. Op een lager niveau: de verantwoordelijkheid van het systeem wordt gedeeld zodat de ontwikkelaar – gebruiker samenwerking naadloos moet verlopen.

27


Rollen: DSDM definieert 15 rollen voor gebruikers en ontwikkelaars. De belangrijkste zijn [14]: Developers en senior developers Dit zijn de enige ontwikkelaars. Afhankelijk van de ervaring is er de titel developer of senior developer. Senior developer geeft ook een niveau van leiderschap aan in een team. De developers en senior developers omvatten alle ontwikkelaars: dit kunnen analisten, ontwerpers, programmeurs of testers zijn. Technical coördinator De technical coördinator definieert de architectuur van het systeem en is verantwoordelijk voor de technische kwaliteit in het project, ook voor de technische controle zoals het gebruik van software configuratie management. Ambassador user Dit is de meest belangrijke rol. De verantwoordelijkheden van de ambassador user zijn: de kennis van de het domein van de eindgebruikers te delen in het project en het verspreiden van informatie over de voortgang van het project naar de gebruikers. Het laatste zorgt voor voldoende feedback over het systeem. De ambassador user komt vanuit het domein van de eindgebruikers. Het is onwaarschijnlijk dat de ambassador user alle standpunten representeert, hiervoor is er een extra rol: de adviser user. De adviser user kan elke gebruiker zijn die een belangrijk standpunt representeert vanuit het project. Visionary De visonairy is de gebruiker die de meest nauwkeurige visie heeft de op business doelen en het project. Deze persoon is hoogst waarschijnlijk ook degene die met het idee van het systeem is gekomen. De taak is om ervoor te zorgen dat de belangrijkste requirements in een vroeg stadium worden gevonden en dat het project in de goede richting gaat vanuit het standpunten van de requirements. Executive sponsor De executive sponsort is iemand vanuit de organisatie van de gebruikers die financiële autoriteit en verantwoordelijkheid heeft. De executive sponser heeft dan ook de ultieme macht in het maken van beslissingen. Het DSDM team bestaat uit twee tot zes personen en er kunnen meerdere teams aan een project deelnemen. Het minimale aantal personen van twee is doordat er tenminste een gebruiker en een ontwikkelaar in een team moeten zitten. Het maximum van zes personen is gevonden in de praktijk. Proces Het proces van software ontwikkeling volgens DSDM bestaat uit vijf fasen: Feasibility Study phase: tijdens deze fase wordt er beoordeeld of DSDM geschikt is voor het project. Er wordt beoordeeld aan de hand van de gekozen technische realisatie, kosten en duur van het project of DSDM gebruikt wordt. Ook worden tijdens deze fase de technische mogelijkheden van het continueren van het project en de risico’s bekeken. Aan het einde van de fase zijn er twee producten voorbereid: een feasibility report en een uitgestippeld ontwikkelplan. Optioneel kan er als het domein niet bekend is een prototype gemaakt worden om te kunnen beslissen of er moet worden doorgegaan naar de volgende fase of niet. De feasibility study phase neemt niet meer dan een paar weken in beslag. Business Study phase: de essentiële kenmerken van het domein en de technologie worden geanalyseerd. De aanbevolen benadering is om workshops te organiseren, waar voldoende gast experts zijn verzameld om over alle belangrijke facetten van het systeem na te denken. De betrokken bedrijfsprocessen en user classes worden beschreven in een business area definition. Hierin worden hoog niveau omschrijvingen van de processen worden gepresenteerd, in een geschikt format (ER diagrammen, bedrijfsmodellen). Twee andere producten die gemaakt worden in de business study phase zijn een system architecture definition en een outline prototyping plan. De system architecture definition is een eerste architectuurtekening die tijdens het project mag veranderen. Het outline prototyping plan moet de strategie voor het maken van prototypes voor de volgende stadia bevatten en een plan voor configuratie management.

28


Functional Model Iteration phase: dit is de eerste iteratieve en incrementele fase van de levenscyclus. In elke iteratie worden de inhoud en aanpak gepland, de iteratie doorlopen en de resultaten geanalyseerd voor de volgende iteraties. Zowel analyseren als programmeren wordt gedaan: prototypes worden gebouwd en de ervaringen die daarmee worden opgedaan gebruikt om de analyse modellen te verbeteren. De prototypes worden niet zomaar aan de kant geschoven, maar worden langzaam maar zeker gestuurd naar goede kwaliteit zodat ze in het uiteindelijke systeem kunnen worden geincludeerd. In deze fase wordt een functioneel model gemaakt, dat de code van het prototype en de analyse modellen bevat. Ook testen is een continuerend en essentieel onderdeel van deze fase. Er zijn nog andere producten in deze fase die in verschillende stadia van deze fase worden gemaakt. Dit zijn de volgende documenten: Prioritized functions: een geprioriteerde lijst van functies die moeten worden afgeleverd aan het einde van de iteratie. Functional prototyping review document: verzameling van gebruikerscommentaar op het huidige resultaat, dat als input wordt gebruikt voor de daarop volgende iteraties. Non-functional requirements: requirements die in de volgende fase worden behandeld. Risk analysis of further development: belangrijk document in deze fase, omdat vanaf de volgende fase de problemen steeds moeilijker worden om op te lossen. Hierin staan de risico’s opgesomd die verdere ontwikkeling van het systeem met zich meebrengt. Design and Build Iteration phase: in deze fase wordt het systeem gebouwd. Het product is een getest systeem dat aan de minimale requirements voldoet. Deze fase is iteratief: de prototypes worden door de gebruikers bekeken en de verdere ontwikkeling is gebaseerd op het commentaar van de gebruiker. Implementation phase: in deze fase wordt het systeem verplaatst van de ontwikkelomgeving naar de omgeving waarin het systeem moet draaien. Er wordt een training gegeven aan de gebruikers en het systeem wordt overgedragen aan de gebruikers. Als er bij de implementatie van het systeem een groot aantal gebruikers is betrokken en wordt verspreid over een bepaalde periode, dan kan de implementatie fase ook iteratief worden gedaan. Naast het afgeleverde systeem wordt er een gebruikershandleiding en een project review geschreven. Het laatste vat de uitkomst van het project samen en gebaseerd op het resultaat wordt de richting van ontwikkeling bepaald. Er zijn vier mogelijke richtingen van verdere ontwikkeling: 1) het systeem voldoet aan de eisen, geen verdere ontwikkeling is nodig. 2) een groot deel van de eisen moest aan de kant worden gelaten, het proces wordt opnieuw doorlopen van begin tot eind. 3) een aantal minder kritieke functionaliteit moest overgeslagen worden, het proces begint weer bij de functional model iteration phase. 4) een aantal technische zaken konden niet behandeld worden door tijdstekort, het proces begint weer bij de design and build phase. De eerste twee fasen volgen elkaar op en worden één keer doorlopen. De laatste drie fasen, waarin de ontwikkeling van het systeem plaatsvindt, zijn iteratief en incrementeel. Zie figuur 3.3 voor een overzicht. De iteraties worden benaderd als timeboxes. Timeboxing is een techniek die zorgt voor de tijdige oplevering en realisatie van het project. Binnen DSDM is de opleverdatum vastgezet en de productiecapaciteit te benoemen op basis van beschikbare tijd en resources. Timeboxing zorgt ervoor dat tijd en geld vastgezet worden en dat de functionaliteit wordt gevarieerd. Een timebox duurt een bepaalde tijd en de iteratie moet eindigen binnen de timebox. De tijd die elke iteratie in beslag mag nemen, is vooraf gepland alsook het resultaat van elke iteratie. De duur van een standaard timebox kan variëren tussen enkele dagen en enkele weken. Het managen van functionaliteit gebeurt door middel van prioritering. Er wordt een lijst met requirements opgesteld waaraan vervolgens prioriteiten wordt gegeven. Dit wordt gedaan met behulp van MoSCoW: de afkorting staat voor de mate van belangrijkheid van de functionaliteiten van het systeem. Must have: functionaliteiten die gerealiseerd moeten worden. Should have: functionaliteiten die zouden gerealiseerd moeten worden. Could have: functionaliteiten die gerealiseerd kunnen worden (bijvoorbeeld als de must en should al gerealiseerd zijn). Would like to have: functionaliteiten waarvan het leuk is als ze gerealiseerd zouden worden, maar die waarschijnlijk niet gerealiseerd worden binnen het project.

29


De prioritering kan door ontwikkelaars en gebruikers veranderd worden tijdens het proces. De must’s (en should’s iets minder) staan echter in principe al vast en mogen alleen in overleg met de gebruikers en opdrachtgevers veranderd worden. Op deze manier kan sturend op tijd snel een bruikbaar resultaat worden bereikt en het project beter worden beheerst.

Figuur 3.3 DSDM proces

Voor- en nadelen De meerwaarde van DSDM wordt ten volle benut bij de ontwikkeling van systemen met bepaalde kenmerken. Een daarvan is goed visualiseerbare functionaliteit, via bijvoorbeeld schermen en rapporten. Prototypes kunnen met deze zichtbare resultaten eenvoudig en goed geëvalueerd worden. DSDM is een uiterst geschikte methode als de volgende aspecten aanwezig zijn: het is een interactief systeem er is een gedefinieerde gebruikersgroep aanwezig het systeem is rekenkundig complex en kan opgesplitst of geïsoleerd worden het systeem is groot en kan opgesplitst worden in kleinere functionele delen de ontwikkeling is sterk tijdsgebonden de eisen aan het systeem kunnen worden geprioriteerd de eisen aan het systeem zijn onduidelijk of aan verandering onderhevig DSDM is een volledige methodologie die in principe niet gecomplementeerd hoeft te worden met een andere methode. Het is een open standaard, in die zin dat de tools en practices die gebruikt worden vrij gekozen kunnen worden. DSDM is ontwikkeld en wordt onderhouden door het DSDM consortium 2 dat bestaat uit enkele bedrijven. De handleidingen en ondersteunende white papers zijn alleen toegankelijk voor de partners van het consortium tegen een jaarlijkse bijdrage. Buiten het consortium zijn er geen onderzoeken naar DSDM te vinden, terwijl binnen het consortium de methodologie voortdurend evolueert.

2

http://www.dsdm.org

30


De practices worden niet in detail beschreven, maar blijven algemeen. Hierdoor moet de organisatie de practices zelf verder ontwikkelen. Er wordt echter nergens beschreven hoe dit gedaan kan worden.

3.3.4 Feature Driven Development Feature Driven Development (FDD) is een proces georiënteerde software ontwikkelmethode voor het ontwikkelen van business critical systems. Het benadrukt het belang van goed personeel en sterke domeinexperts. In FDD wordt er uitgebreid gebruik gemaakt van Unified Modeling Lanuage (UML) voor het modelleren. De aandacht wordt gevestigd op het ontwerp en de bouw fase in plaats van op het hele software ontwikkelproces. Voor een uitgebreid overzicht zie [9,13]. Tijdens het software ontwikkelproces worden een aantal documenten en artefacten opgeleverd. Dit zijn de volgende: Feature lists: bestaat uit een set functionaliteiten die klein en bruikbaar zijn in de ogen van de cliënt. Het resultaat is een voor de cliënt waardevolle functionaliteit die binnen twee weken geïmplementeerd kan worden. Indien een functionaliteit meer dan twee weken in beslag neemt om te implementeren, wordt deze opgedeeld. Design packages: bestaan uit sequence diagrammen en class diagrammen en informatie over het ontwerp van de methode. Track by feature: een grafiek die de functionaliteiten die ontwikkeld moeten worden opsomt met de datum waarop elk af is. “Burn Up” Chart: een grafiek met de tijd op de x-as en op de y-as het toenemende aantal functionaliteiten die af zijn. De grafiek laat een positieve groei zien zodra functionaliteiten worden gecompleteerd. Practices FDD is ontwikkeld rondom acht best practices: Domain Object Modeling: dit bestaat uit het verkennen en begrijpen van het domein waarin het probleem zich voordoet. Het resultaat is een domein object model dat een raamwerk biedt waarin de functionaliteiten worden geïmplementeerd. Developing by Feature: als een functionaliteit te ingewikkeld is om binnen twee weken te implementeren, wordt deze opgedeeld in kleinere functies. Dit maakt het makkelijker om de juiste functionaliteiten af te leveren en om het systeem uit te breiden of aan te passen. Individual Class Ownership: verschillende stukken code worden toegewezen aan een persoon. Deze persoon is verantwoordelijk voor de consistentie, prestatie en conceptuele integriteit ervan. Feature Teams: een feature team is een kleine dynamisch gevormde groep ontwikkelaars die samen ontwikkelen. De teams zorgen ervoor dat meerdere personen kijken en denken voordat er een ontwerp beslissing wordt gemaakt en dat ook meerdere opties worden geëvalueerd voordat er uiteindelijk een wordt gekozen. Inspections: inspecties worden uitgevoerd om goede kwaliteit van het ontwerp en de code te waarborgen, door het detecteren van defecten. Regular Builds: zorgt ervoor dat er altijd een werkend system klaar staat dat kan worden gedemonstreerd aan de klant en om integratie errors vroeg te detecteren. Configuration Management: helpt om de programmacode van alle gecompleteerde functionaliteiten te identificeren en een geschiedenis van veranderingen bij te houden. Reporting/Visibility of Results: door vaak geschikte en nauwkeurige voortgangsrapporten op alle niveaus te laten zien, gebaseerd op gecomplementeerd werk, kunnen managers hiermee het project sturen. Rollen De rollen die zijn gedefinieerd in FDD zijn: Project Manager De project manager heeft de administratieve leiding over het project en is verantwoordelijk voor het rapporteren van de voortgang, het beheren van het budget en

31


het vrijmaken en beheren van hulpmiddelen voor het project waaronder het personeel, de apparatuur en de ruimte. Chief Architect De chief architect is verantwoordelijk voor het totale ontwerp van het systeem inclusief het houden van workshops sessies over het ontwerp met het team. Development Manager De development manager is verantwoordelijk voor het leiden van de dag tot dag ontwikkelactiviteiten inclusief oplossingen vinden op conflicten met betrekking tot de beschikbare hulpmiddelen. Chief Programmer De chief programmer is een ervaren ontwikkelaar die een team leider, mentor en ontwikkelaar is voor een team van drie tot zes ontwikkelaars. De chief programmer geeft kennis over het skelet model door aan het team, doet mee met hoog niveau requirements analyse en ontwerp en helpt het team met laag niveau analyses, ontwerp en ontwikkeling van nieuwe functionaliteiten. Class Owner De class owner is verantwoordelijk voor het ontwerpen, coderen, testen en documenteren van nieuwe functionaliteiten in de klassen die degene bezit. Domein experts, gebruikers, cliënten, sponsors etc. Deze personen hebben kennis van het domein waarvoor het systeem ontwikkeld wordt. Feature teams Dit zijn tijdelijke groepen ontwikkelaars die worden gevormd rondom de klassen waarmee de functionaliteit wordt geïmplementeerd. Een feature team wordt dynamisch samengesteld om een functionaliteit te implementeren en ontbindt zich wanneer de functionaliteit is geïmplementeerd. Dit duurt maximaal twee weken.

Proces Het FDD proces bestaat uit vijf incrementele, iteratieve processen. Er zijn richtlijnen opgesteld voor de hoeveelheid tijd die gespendeerd zou moeten worden in elke stap, waarbij de hoeveelheid tijd voor planning, architectuur zoveel mogelijk beperkt wordt en de nadruk wordt gelegd op ontwerpen en het ontwikkelen van functionaliteiten. De processen 1 t/m 3 worden aan het begin van het project doorlopen en worden tijdens het ontwikkelproces geüpdate. Processen 4 en 5 worden incrementeel doorlopen met twee wekelijkse cycli. Elk proces heeft specifieke inen output criteria waarbij de input van proces N de output is van proces N-1. In figuur 3.4 is het proces weergegeven. Proces 1: er wordt een model gemaakt van het hele systeem (tijdsbesteding: 10%, daarna 4%). Domeinkenners en ontwikkelaars werken samen om het doel van het systeem en de context te begrijpen. Hoog niveau modellen/class diagrammen worden gemaakt voor elk gebied van het probleem domein. De modellen bevatten informatie over de vorm en waarom sommige alternatieven zijn geselecteerd en andere niet. Proces 2: een feature list wordt samengesteld (tijdsbesteding: 4%, daarna 1%). Dit is een complete lijst van alle gewenste functionaliteiten opgesteld door het team in proces 1. Hierna volgt functionele decompositie waarbij een bedrijfsactiviteit door de klant gewenst, wordt opgedeeld in functionaliteiten die moeten worden geïmplementeerd in het systeem. Proces 3: plannen wordt gedaan aan de hand van functionaliteiten (tijdsbesteding: 2%, daarna 2%). Een team bestaande uit een project manager, development manager en chief programmer plant de volgorde waarin functionaliteiten worden ontwikkeld. Het plannen is gebaseerd op afhankelijkheden, risico’s, complexiteit, werkdruk, door de cliënt vastgestelde mijlpalen en checkpoints. Bedrijfsactiviteiten worden gepland, hieraan wordt een aflevermaand aan toegewezen. Elke klasse is toegewezen aan een bepaalde ontwikkelaar en functionaliteiten worden gebundeld op basis van technische redenen. Proces 4: ontwerpen wordt gedaan aan de hand van functionaliteiten (tijdsbesteding: 34% per twee weken). De chief programmer leidt de ontwikkeling van design packages en verfijnt object modellen met attributen. De sequence diagrammen worden vaak gemaakt als een groepsactiviteit. De class diagrammen en object modellen worden gemaakt door de class

32


owners. Domein experts werken met het team om de functionaliteit requirements te verfijnen. Als laatst worden de ontwerpen geïnspecteerd. Proces 5: bouwen wordt gedaan aan de hand van functionaliteiten (tijdsbesteding: 43% per twee weken). Het feature team implementeert de klassen en methoden geschetst door het ontwerp. De code wordt geïnspecteerd en er worden unit testen uitgevoerd. Hierna wordt de code toegevoegd aan het systeem. De voortgang wordt bijgehouden en zichtbaar gemaakt tijdens proces 4 en 5. Elke functionaliteit heeft zes mijlpalen, drie van proces 4 (domain walkthrough, design en design inspection) en drie van proces 5 (code, code inspection en promote to build). Wanneer de mijlpalen zijn bereikt, wordt de datum geplaatst op de Track by Feature Chart. Wanneer een functionaliteit alle zes de mijlpalen heeft behaald heeft, is dit te zien op de “Burn Up” Chart. Alle functionaliteiten moeten binnen een maximum van twee weken worden voltooid, inclusief de zes mijlpalen.

Figuur 3.4 FDD proces

Voor- en nadelen Er zijn geen succesverhalen of verhalen van mislukking bij het gebruik van FDD bekend. De methode is relatief nieuw en is zich aan het ontwikkelen, waarbij steeds meer ondersteunende tools beschikbaar worden. FDD verschilt vooral van andere agile methoden in de practice Individual Class Ownership waar één persoon verantwoordelijk is voor een stuk code in plaats van gedeelde verantwoordelijkheid. FDD heeft acht best practices die een must zijn, deze kunnen worden aangepast aan de ervaring van het team. Om het voordeel van de best practices te ervaren moeten alle practices gebruikt worden. Alleen wordt nergens beschreven hoe deze practices kunnen worden aangepast. Hier wordt dus gebruik gemaakt van abstracte principes.

3.4 Tools Bij de agile software ontwikkelmethoden worden verschillende soorten tools gebruikt om het software ontwikkelproces te ondersteunen. Niet alle agile methoden gebruiken dezelfde soort tools doordat het proces dat doorlopen wordt verschillend is. In deze paragraaf zullen de meest gebruikte tools worden besproken per stap die doorlopen wordt in het proces. De meeste tools zijn niet specifiek voor agile methoden, maar kunnen voor bij alle software ontwikkelmethoden gebruikt worden.

33


De eerste stap in het proces waarvoor ondersteuning beschikbaar is, is planning. De planning tool ondersteunt het maken van een goede planning voor projecten. Hiermee kan ook de planning worden gevolgd en bijgehouden. Een voorbeeld hiervan is XPlanner. 3 De tweede stap is het bouwen van de software, hiervoor zijn build tools beschikbaar. Deze tools automatiseren het bouwproces. Enkele bekende build tools zijn Ant 4 en Cruise Control. 5 Na het bouwen wordt de software getest met behulp van een test tool. Test tools ondersteunen testscripts (unit tests) die uitgevoerd worden. Ook zijn er tools beschikbaar die zowel het bouwen als het testen ondersteunen. De meest bekende test tool is JUnit, 6 een testing framework voor unit testen in Java. Er bestaan ook varianten voor andere programmeertalen. Voor de methoden waar refactoring een plaats inneemt in het ontwikkelproces, zijn er refactoring tools die de interne structuur van de programmacode helpen verbeteren. Eclipse 7 is hier een voorbeeld van; dit is een IDE met geïntegreerde refactoring ondersteuning. Voor het managen van een project bestaan project management tools. Met deze tools kan de voortgang van het project worden. Hele softwarepakketten waarin verschillende modules zijn geïntegreerd, zoals TargetProcess, 8 bieden één geïntegreerde tool waarmee het hele project mee te sturen is. Om de kwaliteit van software hoog te houden, is een bug tracking tool nodig. Bug tracking tools stellen programmeurs in staat om op een effectieve manier fouten in de software te volgen. Een van de bekendste bug tracking tools is Bugzilla. 9 Bij agile methoden is het van belang om snel te kunnen reageren, zo ook om snel terug te kunnen gaan naar een oudere versie van de programmacode. Om dit mogelijk te maken zijn er versiebeheer tools. Deze tools slaan alle oude versies op en sommige maken het mogelijk om aan verschillende versies te werken. Visual SourceSafe (VSS) 10 is een bekend versiebeheersysteem.

3.5 Vergelijking van methoden Alle agile methodologieën delen ongeveer dezelfde set van samenwerkende waarden en principes, maar elke methode benadert de problemen die worden tegengekomen bij software ontwikkeling vanuit een ander perspectief. Deze paragraaf is gebaseerd op [3,7,13,16]. Web engineering is een manier van ontwikkelen en organiseren van kennis over web applicatie ontwikkeling en het toepassen van deze kennis. Ook is het een manier om de complexiteit en diversiteit van web applicaties te managen [16,17]. Web engineering verschilt in veel opzichten van conventionele software, informatiesysteem of computer applicatie ontwikkeling. Web engineering maakt gebruik van software engineering principes en past deze aan aan het web dat open en flexibeler is dan standalone applicaties. Daarnaast omvat het ook nieuwe methoden, methodologieën, tools, technieken en richtlijnen. In web engineering staan de fasen die doorlopen moeten worden nog niet vast zoals bij software engineering. Bij de laatste bestaat er de software life cycle die de fasen beschrijft die doorlopen moeten worden bij software ontwikkeling. Bij web engineering is er nog niet een vergelijkbaar model die de fasen omschrijft die gevolgd moeten worden bij webapplicatie ontwikkeling. Daarvoor worden voor dit onderzoek de fasen uit de software engineering, waarmee web engineering goed vergeleken kan worden, gebruikt. Webapplicaties zijn weliswaar dynamischer en hebben een kortere doorlooptijd, maar alle fasen moeten evengoed doorlopen worden waarbij de nadruk meer ligt op het integreren van de requirements en het testen van de applicaties.

3

http://www.xplanner.org http://ant.apache.org http://cruisecontrol.sourceforge.net/ 6 http://www.junit.org 7 http://www.eclipse.org 8 http://www.targetprocess.com 9 http://bugzilla.redhat.com/bugzilla 10 http://msdn.microsoft.com/vstudio/products/vssafe 4 5

34


Om de beste methode te kunnen kiezen, en de meest bruikbare voor Pharmeon, zullen ze op vier fronten worden vergeleken. Hiermee kunnen de agile methoden op een uniforme manier met elkaar vergeleken worden en worden de kenmerken van elke methode goed zichtbaar. De vergelijking zal op vier fronten plaatsvinden: 1. Welke fasen van de software levenscyclus worden in de methode meegenomen? 2. Ondersteunt de methode project management activiteiten? 3. Biedt de methode voldoende ondersteuning of alleen vage aanwijzingen? 4. Kan de methode in elke organisatie gebruikt worden? De software levenscyclus wordt gebruikt om te vergelijken welke fasen van het software ontwikkelproces de agile methoden omvatten. Om een agile methode te kunnen gebruiken voor het uitvoeren van een project moet de agile methode de software levenscyclus ondersteunen. Bij de eerste vraag gaat het dus om de mate waarin de agile methode de software levenscyclus volgt. De software levenscyclus bestaat uit opeenvolgende fasen die worden doorlopen bij software ontwikkeling. Een software levenscyclus kan worden gezien als bestaande uit negen fasen: 1. Analyse 6. Integration test 2. Requirements specificatie 7. Systeem test 3. Ontwerp 8. Acceptance test 4. Bouwen 9. System in gebruik / Onderhoud 5. Unit test De tweede vraag gaat in op project management. De agile methoden moeten efficiënt zijn. Om efficiënt te werken, zijn er management activiteiten nodig om de taken goed uit te voeren. Project management heeft dus een ondersteunende functie en biedt vastigheid voor efficiënte software ontwikkeling. Vraag 3 gaat in op de vraag of de agile methode concrete ondersteuning biedt in de documentatie. Software ontwikkelmethoden zijn niet altijd alleen bedoeld als ontwikkelmethode, maar vaak ook als sociale verdediging tegenover de buitenwereld [18]. Om te evalueren of de methode echt gebruikt kan worden als ontwikkelmethode, wordt er gekeken of de methode concrete ondersteuning biedt of alleen op abstracte principes steunt, waarbij niet wordt uitgelegd hoe het proces of de practices moet worden uitgevoerd. Een bruikbare en efficiënte methode zou niet naar abstracte principes moeten verwijzen [18]. Concrete ondersteuning bestaat uit practices, activiteiten en eindproducten aan het eind van de verschillende fasen van de software levenscyclus, die aangeven hoe een bepaalde taak moet worden uitgevoerd. In vraag 4 gaat het erom of de methode in elke organisatie toegepast kan worden. Het doel van agile software ontwikkeling is het verbeteren van het vermogen om te reageren op veranderingen in de organisatie, vanuit de klant of in technologische behoeften. Terwijl agile refereert naar snelheid en lenigheid moet de methode die dit proces helpt ook ‘snel’ zijn: organisatie geschikt. Organisatie geschikt betekent dat een methode aan verschillende organisaties aangepast kan worden. Een methode zou flexibel genoeg moeten zijn om veranderingen ‘on the spot’ aan te brengen als de organisatie dat verlangt. Een universeel vooraf bepaald standpunt stelt een kanten-klare oplossing voor op alle agile ontwikkelpogingen. De antwoorden op de eerste drie vragen zijn verwerkt in figuur 3.6, waarin voor elke methode apart wordt aangegeven welke fasen worden behandeld in de methode, of er project management activiteiten worden aangeboden en of de methode ondersteuning biedt.

35


Figuur 3.6 Vergelijking agile methoden (naar [13])

De agile methoden verschillen van elkaar in de manier waarop project management wordt ondersteund. Scrum is ontwikkeld met de bedoeling om agile software ontwikkeling te managen, terwijl XP weinig project management practices heeft. Naast XP zou dus een andere methode of andere practices moeten worden aangenomen om de methode aan te vullen, zodat het project onder controle gehouden kan worden. FDD ondersteunt het plannen van projecten door project features en de voortgang van het project door tracking. Daarnaast heeft de project manager veel macht en dus nog altijd het laatste woord over het doel, de planning en personeel van een project. FDD richt zich voornamelijk op de ontwerpen bouwfase in plaats van op het hele software ontwikkelproces. DSDM biedt net voldoende project management activiteiten om te voorzien in effectief management van DSDM projecten. Voor alle andere projecten suggereert DSDM een raamwerk van controle om de methode aan te vullen. Deze zijn ontworpen om het reactievermogen van een organisatie op veranderingen te verbeteren. De meeste methoden omvatten de fasen 2 t/m 7 (requirements specificatie tot systeem test). DSDM omvat alle fasen van het software levenscyclus. DSDM is de meest onafhankelijk methode in de zin dat deze alle fasen van de levenscyclus probeert te omvatten en geen andere methode of practice nodig heeft om de methode aan te vullen. De compleetheid van de beschreven methoden verschilt per methode. Zowel horizontaal (de fasen die de methode omvat) als verticaal (mate van detail) zijn de methoden verschillend. Geen van de methoden is uitgebreid of gedetailleerd beschreven. De ondersteuning die de methode biedt bij het uitvoeren van de practices en het proces zijn niet bij alle methoden voldoende. Bij de meeste methoden worden richtlijnen gegeven die gevolgd moeten worden, maar hoe deze in praktijk kunnen worden toegepast wordt niet besproken. Ook mist de ondersteuning bij het aanpassen van de practices of proces naar de eigen situatie. XP is de enige methode die complete ondersteuning biedt tijdens de fasen die worden beschreven in XP. Er wordt beschreven wanneer en hoe de practices moeten worden uitgevoerd en beschrijven de situatie en de achterliggende denkwijze voor het toepassen van de practices. Bij de vierde en laatste vraag van de vergelijking is gekeken of de methode in elke organisatie toegepast kan worden, waarbij de methode al of niet aangepast wordt. Drie van de vier methoden zijn geschikt voor elke organisatie: DSDM, Scrum en XP. DSDM heeft een suitability filter waarmee aan de hand van een aantal vragen kan worden beoordeeld of de methode zelf geschikt is voor het project. [19] echter beschrijft hoe DSDM is aangepast in een CMM context aan de project doelen waarbij de nodige aanpassingen zijn gemaakt. Scrum en XP laten organisatie geschikte aanpassingen toe. Vooral XP vermeldt expliciet dat regels alleen maar regels zijn en dat ze aangepast kunnen worden als er een wederzijds begrip bij het ontwikkelteam is. FDD is ontwikkeld rond acht best practices. Deze practices moeten allemaal gebruikt worden om het ‘voordeel’ te ervaren. FDD claimt dat het geschikt is voor alle software ontwikkelorganisaties die kwalitatief goede software systemen op

36


tijd moeten afleveren, zoals ook DSDM. Ze representeren universele beschrijvingen die claimen dat ze geschikt zijn voor alle agile software ontwikkelsituaties, doelen en projecten. Geen enkele agile methode is perfect en kan zonder enige moeite in een bedrijf geïmplementeerd worden. Elke methode heeft haar eigen aanpak en practices die zich allemaal richten op software ontwikkeling, maar de nadruk leggen op andere fasen van de software levenscyclus. Welke methode het meest geschikt is, kan niet algemeen worden bepaald, maar hangt af van het bedrijf zelf, het ontwikkelteam en het type projecten dat uitgevoerd wordt.

37

Hoofdstuk 4 Oplossing voor Pharmeon

Hoofdstuk 4 Oplossing voor Pharmeon De oplossingen die in dit hoofdstuk worden besproken, zijn oplossingen voor de in hoofdstuk 2 naar voren gekomen knelpunten bij Pharmeon. Ze zijn gebaseerd op waarnemingen en het uitgevoerde literatuuronderzoek (zie hoofdstuk 1). Op de oplossingen heeft een selectie plaatsgevonden (zie hoofdstuk 3) waarbij voor de best toepasbare oplossing voor Pharmeon is gekozen. Het aantal oplossingen dat besproken wordt in dit hoofdstuk is kleiner dan het aantal knelpunten. Meerdere knelpunten kunnen dus worden aangepakt met één oplossing. In paragraaf 4.1 wordt een software ontwikkelmethode voorgesteld. Met deze methode kunnen de knelpunten communicatie, testen en documenteren aangepakt dan wel verbeterd worden. Ook zullen de projecten van Pharmeon beter gemanaged en gecontroleerd kunnen worden. In paragraaf 4.2 wordt de opzet van de planning besproken, die ook daadwerkelijk is ingevoerd. Hiermee wordt een oplossing geboden op de knelpunten communicatie en planning. Paragraaf 4.3 beschrijft het software ontwikkelproces bij Pharmeon bij toepassing van de voorgestelde software ontwikkelmethode.

4.1 Software ontwikkelmethode Voor een klein bedrijf waar de processen en procedures nog niet helemaal duidelijk en vast staan, is een eenvoudige methode met veel vrijheid een goede oplossing. Bij Pharmeon is er sprake van een zeer dynamische omgeving waarin webapplicaties ontwikkeld worden. Niet alle software ontwikkelmethoden zijn hiervoor geschikt. De software ontwikkelmethode moet dus aan een aantal eisen voldoen. De softwaremethode: 1. moet makkelijk te volgen zijn 2. hoeft niet in één keer te worden overgenomen 3. moet aangepast kunnen worden aan de organisatie 4. moet ruimte bieden voor eigen regels en practices 5. mag een project niet onnodig vertragen 6. moet een beter project resultaat leveren dan het resultaat op dit moment. De projecten moeten binnen de geplande tijd en goed werkend opgeleverd worden. Bij Pharmeon werken jonge ontwikkelaars die nog niet veel ervaring hebben op het gebied van webapplicatie ontwikkeling en projecten. Van ervaren project managers of ontwikkelaars is dus geen sprake. Wel is er een ervaren programmeur aanwezig die te allen tijde kan helpen of bijspringen. De ontwikkelaars moeten bij het gebruik van een methode er met zijn allen uit kunnen komen en niet vastlopen door het gebrek aan ervaring. Samengevat geeft voorgaande aan dat de software ontwikkelmethode niet moeilijk te volgen moet zijn, gefaseerd overgenomen moet kunnen worden en flexibel moet zijn om aan te kunnen passen. Extreme programming is de meest geschikte methode voor Pharmeon. De methode hoeft niet in één keer geïmplementeerd te worden, maar mag geleidelijk overgenomen worden. Niet alle practices hoeven gebruikt te worden en deze mogen naar eigen keuze overgenomen worden. Ook mogen de practices aangepast of aangevuld worden naar de manier van werken in de organisatie. De methode is gemakkelijk te volgen door de eenvoudigheid van de practices en het ontwikkelproces. Of XP de projecten bij Pharmeon doet vertragen is niet van tevoren te zeggen, maar pas na toepassing van XP binnen Pharmeon. Volgens [15] zorgt XP juist voor hoge software kwaliteit en snellere software ontwikkeling. Hetzelfde geldt voor een beter resultaat, dit is niet van tevoren te voorspellen. De methode is uitgebreid gedocumenteerd en door meerdere practitioners succesvol in gebruik genomen. De waarden eenvoud, lef en respect uit XP worden al voor een deel toegepast binnen Pharmeon, waar ze een belangrijke plaats innemen. De communicatie verloopt grotendeels al mondeling waardoor interactie ook plaatvindt. Feedback verkijgen van de klant, is bij Pharmeon pas aan de orde aan het eind van het project als de applicatie wordt opgeleverd. Door feedback aan het

39


einde van elke iteratie te krijgen, kan er eerder worden geanticipeerd op de wensen van de klant en wordt de kans op uitloop van het project verkleind. De overige drie waarden van XP zijn nieuw voor Pharmeon. XP richt zich op de belangrijkste fasen van de software levenscyclus, zoals gezien bij vraag 1 in hoofdstuk 3.5. De fasen 2 en 5 t/m 7 (zie paragraaf 3.5) zijn voor Pharmeon belangrijke fasen. In fase 2 worden de eisen en wensen van de klant naar boven gehaald, in de fasen 5 t/m 7 wordt de webapplicatie getest. Het testen gebeurt in meerdere stappen die herhaaldelijk worden doorlopen. Qua project management is XP niet erg uitgebreid, zoals ook besproken bij vraag 2 in paragraaf 3.5. XP kan worden gezien als een verzameling van software ontwikkeling best practices die een overlap hebben met de best practices van project management. Extra project management practices zouden, indien gewenst, goed kunnen worden geïntegreerd in XP en zouden de kans op een succesvol project verhogen. Op dit moment zijn de project management activiteiten die aangeboden worden in XP voldoende om de projecten bij Pharmeon succesvol te doorlopen en af te ronden. De projecten bij Pharmeon zijn over het algemeen niet erg groot en duren meestal niet langer dan enkele maanden. De iteraties zullen in de meeste gevallen dus korter zijn dan de iteraties beschreven in paragraaf 3.2.2, net zoals de planning fase. In elke iteratie wordt een klein deel van het project opgeleverd, waarbij moet gelet moet worden dat elke iteratie een toegevoegde waarde heeft voor de klant. In web engineering stopt de ontwikkeling meestal niet na het opleveren van de applicatie, maar het blijft een continue verbetering van de bestaande applicaties. De projecten zullen eindigen als de webapplicatie opgeleverd wordt, maar helemaal af zal het niet zijn. De meeste practices in XP zijn heel bruikbaar voor Pharmeon. Een aantal van de practices wordt al min of meer toegepast in het software ontwikkelproces. Dit zijn: Simple design: er wordt altijd gezocht naar het eenvoudigste ontwerp dat de gewenste functionaliteit kan leveren. Hiermee wordt tijd bespaard en is de klant toch tevreden doordat de applicatie de gewenste functionaliteit bezit. Vanwege de druk om producten binnen een redelijk tijdsbestek af te leveren, zal er nooit voor een ingewikkeld ontwerp worden gekozen indien er een eenvoudigere voorhanden is. Collective code ownership: met een klein ontwikkelteam zoals bij Pharmeon, kan het voorkomen dat een teamlid afwezig is. De ontwikkelaars hebben allen toegang tot alle programmacode en kunnen deze aanpassen. Exclusieve toegang tot bepaalde programmacode bestaat niet binnen Pharmeon. Small, frequent releases: in web engineering worden kleine releases gedaan die langzaam leiden tot een complete applicatie, zo ook bij Pharmeon. De webapplicaties worden stap voor stap gebouwd en afgeleverd, zodat de applicatie zichtbaar groeit en steeds meer functionaliteit krijgt. Hierdoor krijgen niet alleen de programmeurs steeds meer vertrouwen, maar ook de klant. Continuous integration: op de testserver wordt alle programmacode eerst uitgetest voordat deze live wordt gezet. Hierbij wordt de programmacode steeds geintegreerd op de testserver. De omgeving van de testserver is echter niet altijd vergelijkbaar met de eigenlijke omgeving waarin de webapplicatie draait. Het komt wel eens voor dat de webapplicatie wel werkt op de testserver maar niet live. Na het live zetten kunnen dus onvoorziene bugs tevoorschijn komen. De omgeving van de testserver zou gelijk moeten zijn aan de omgeving waarin de webapplicatie komt te draaien. Dit bespaart vooral tijd, die bij Pharmeon heel kostbaar is. Hiernaast zijn er goede practices in XP die Pharmeon zouden kunnen helpen om het software ontwikkelproces meer structuur te geven en te standaardiseren. Het volgen van deze practices garandeert echter niet een mooi en gestandaardiseerd ontwikkelproces, maar vergroot wel de kans daarop. De volgende practices zijn goed toepasbaar binnen Pharmeon: Testing: unit tests zullen helpen om de kans op bugs te verkleinen. Door de unit tests automatisch uit te voeren elke keer dat de programmacode compileert, worden de bugs 40


veroorzaakt door veranderingen in de programmacode snel opgemerkt. Ook zal er nooit verder kunnen worden gegaan zonder dat de unit tests met succes worden doorlopen en het product dus werkt. Refactoring: refactoring zal bijdragen aan de leesbaarheid en aanpasbaarheid van de programmacode. Door refactoring wordt de tijd die besteed moet worden aan onderhoud of om een aanpassing te maken verkleind. Bij Pharmeon wordt er nog veel tijd besteed aan het begrijpen van de programmacode als er een aanpassing moet worden gemaakt. Dit komt doordat niet iedereen de programmacode voorziet van commentaar en ook medewerkers die geen programmeur waren webapplicaties hebben gemaakt. Deze medewerkers hebben niet op een overzichtelijke en duidelijke manier de webapplicatie in elkaar gezet, waardoor er vaak gepuzzel aan te pas moet komen. Automatische unit tests zullen ervoor zorgen dat de het product na refactoring nog steeds werkt. Coding standards: door alle programmeurs dezelfde codeerstandaard te laten gebruiken, is de opbouw van de programmacode altijd gelijk en wordt er tijd bespaard met het ontcijferen van programmacode. Er is op dit moment geen expliciete codeerstandaard binnen Pharmeon, maar alle programmeurs gebruiken min of meer dezelfde standaard die ze na verloop van tijd van elkaar overnemen. Ook verschillen de genoten opleidingen van de programmeurs niet veel van elkaar, waardoor nagenoeg dezelfde manier van programmeren geleerd en behouden is. Toch zou het handig zijn om de codeerstandaard schriftelijk vast te leggen, zodat ernaar verwezen kan worden als er nieuwe programmeurs bijkomen en als naslagwerk. Iteration/release planning game: de klant bepaalt wanneer de user stories af moeten en bespaart de ontwikkelaars tijd om hierover na te denken. Tegelijkertijd moeten de ontwikkelaars wel de benodigde tijd per user story teruggeven, zodat een reële planning kan worden gemaakt. Door de klant na het selecteren van de user stories feedback te geven over de tijd die de user stories in beslag zullen nemen, wordt grotendeels voorkomen dat niet-reële deadlines worden overschreden. Samen met de klant kan besproken worden wat haalbaar is binnen een bepaalde tijd en na elke iteratie worden besproken wat er in de volgende moet worden opgeleverd. Dit is van groot belang voor Pharmeon. Bij Pharmeon gaan er een aantal dingen mis doordat 1. de communicatie tussen de Customer Services en de Research & Development afdeling betreffende afleverdata niet goed is en 2. de klant geen feedback krijgt over de tijd die eigenlijk nodig is om de functionaliteit te bouwen. Het gevolg is dat de klant samen met de Customer Services afspraken maakt over afleverdata terwijl geen van beiden op de hoogte zijn hoeveel tijd het beslag neemt. De afdeling Research & Development wordt erbuiten gelaten. Met de iteration/release planning game hebben de ontwikkelaars inbreng en wordt er in overleg met de klant besproken wat er precies afgeleverd wordt en wanneer. De afdeling Customer Services staat nadat de planning gemaakt is grotendeels weer tussen de Research & Development afdeling en de klant. Het wekelijks contact met de klant over de voortgang van het project en eventueel bijkomende wensen gaat via de Customer Services. Sustainable pace: bij Pharmeon komt structureel overwerken niet voor. Dit draagt bij aan de productiviteit van het team en gaat verzuim tegen doordat elke dag weer fris kan worden begonnen. Het komt bij Pharmeon wel eens voor dat medewerkers overwerken om iets af te ronden. Het gevolg hiervan is stress, ontevredenheid en een verminderde productiviteit de volgende werkdag. Door als eerst een realistische planning te maken die uitgaat van een 40-urige werkweek wordt de kans op overwerken verkleind. De werkdagen van het ontwikkelteam zullen productiever zijn en op de lange termijn zal het resultaat kwalitatief beter zijn.

Ook de activiteiten die consistent zijn met de principes van XP, kunnen goed gebruikt worden. Stand-up meetings: korte dagelijkse meetings zullen een goede basis en opfrissing vormen om de dag te beginnen. Vooral in kleine bedrijven waar nauw moet worden samengewerkt is het van belang dat het ontwikkelteam op de hoogte is van alle ontwikkelingen. Deze stand-up meetings zijn ook belangrijk om de communicatie binnen Pharmeon te verbeteren. Als iedereen op de hoogte is van de status van een project,

41


kan de klant beter op de hoogte worden gebracht en eventuele uitloop eerder worden opgemerkt. Bij projecten met meer dan 3 personen worden dagelijkse stand-up meetings gehouden. Projecten waaraan 3 of minder personen werken behoeven geen dagelijkse meetings en hebben genoeg aan korte overleggen van enkele minuten. Retrospectives: aan het einde van elke iteratie kan besproken worden wat er wel en niet goed ging en besloten worden om deze in het vervolg anders aan te pakken. Het ontwikkelproces wordt door retrospectives steeds verbeterd, zodat er efficiënt gewerkt kan worden. Tijdens de retrospective kunnen ervaringen uitgewisseld worden en gediscussieerd worden over de aanpak van projecten, wat de communicatie weer bevordert.

Niet alle XP practices zijn even bruikbaar voor Pharmeon. Als een practice op dit moment niet bruikbaar is voor Pharmeon, wil dit niet zeggen dat de practice in het geheel onbruikbaar is, maar alleen dat deze in de huidige situatie niet toepasbaar is. Onderstaande practices lijken momenteel niet bruikbaar voor Pharmeon. Pair programming: pair programming zal weinig tot niet mogelijk zijn op dit moment, maar later wellicht wel. Nu zijn er te weinig programmeurs en de druk om functionaliteiten op te leveren binnen een redelijk tijdsbestek is groot. Het aantal projecten is groter dan het aantal programmeurs, waardoor de druk om snel een product op de markt te brengen hoog kan oplopen. Volgens [20,21] zorgt pair programming voor kwalitatief betere software in minder tijd en programmeurs die meer tevreden en zelfverzekerder zijn. Dit is na de inwerktijd die kan variëren van een aantal uren tot een aantal dagen. Voordat pair programming de genoemde voordelen met zich meebrengt, moet er eerst geïnvesteerd worden. De programmeurs zullen moeten wennen aan het samenwerken zoals beschreven in pair programming, wat veel tijd in beslag kan nemen. Ook zal er in het begin enige weerstand kunnen zijn tegen pair programming waardoor de productiviteit verminderd wordt. Misschien is het mogelijk om pair programming te gebruiken wanneer er voldoende medewerkers zijn op de Research & Development afdeling om het groeiende aantal aanvragen te kunnen verwerken. Customer on-site: een klant constant op de werkvloer is niet nodig. Pharmeon heeft goede contacten met haar klanten en er zijn geen problemen rondom informatievoorziening. De klant is altijd bereikbaar via e-mail of telefoon en kan bij belangrijke meetings aanwezig zijn. De klant zou wel meer betrokken kunnen worden tijdens de ontwikkeling van een funtionaliteit. Bij grote projecten wordt de klant wel meer betrokken en is er wekelijks contact over de voortgang van het project. Op dit moment wordt in fase 2 (requirements specificatie) en soms in fase 8 van de software levenscyclus (acceptatie test) een meeting met de klant gepland. Dit zou in principe niet vaker te hoeven, maar het contact met de klant moet wel regelmatig plaatsvinden waarbij met de kant door de applicatie kan worden gelopen om feedback terug te krijgen. System metaphor: het lijkt overbodig om een thema of metafoor te bedenken waardoor alle teamleden een gemeenschappelijk beeld hebben. Er kan worden aangenomen dat alle partijen weten waarover het project gaat en wat het einddoel is. Een metafoor wordt vooral gebruikt bij complexe systemen, bij Pharmeon gaat het om zeer concrete applicaties waarbij een metafoor niet nodig is. Het XP proces bij Pharmeon zal heel erg lijken op het proces beschreven in hoofdstuk 3.2.1. XP is gericht op het snel en efficiënt ontwikkelen van applicaties, waarbij de klant centraal staat. Andere activiteiten die in combinatie met XP zouden kunnen helpen om projecten te managen zijn afkomstig uit Scrum. Product Backlog: de Functionality Backlog (Product Backlog) wordt opgesteld in de planning phase en zal tijdens de iteratie bijgehouden worden. Sprint Backlog: in de Planning phase wordt de Iteration Backlog (Sprint Backlog) opgesteld samen met de klant. Aan het begin van elke iteratie wordt de Iteration Backlog geüpdate.

42


Sprint Burndown Chart: de Iteration Burndown Chart (Sprint Burndown Chart) zal vanaf het begin van een project regelmatig bijgehouden worden zodra het project bij de fase Iteration to Release phase is aangekomen. Deze documenten zullen goed zichtbaar voor het ontwikkelteam worden neergezet en worden bijgehouden door de tracker. Zo kan het ontwikkelteam de voortgang van het project volgen en zijn zij op de hoogte van de bestede en nog te besteden uren aan het project. Ook XP heeft enkele documenten (task list, visible wall graphs) die gebruikt zouden kunnen worden (zie paragraaf 3.2.1), maar deze zijn niet erg gedetailleerd en lijken geen meerwaarde te hebben voor Pharmeon’s projecten. De user story cards daarentegen kunnen goed gebruikt worden bij het schatten van tijdsbestedingen en kunnen het requirements document vervangen. Op de user story cards wordt elke functionaliteit in enkele zinnen opgeschreven door de klant waardoor de hoeveelheid tekst beperkt blijft. Ook vormden ze de basis voor de customer aceptance tests. De combinatie van XP en Scrum wordt vaker gebruikt waardoor deze een aparte naam heeft gekregen: XP@Scrum. Hoewel XP en Scrum apart toegepast kunnen worden, werken ze samen effectiever [22,23]. Cijfers hierover zijn worden niet genoemd.

4.2 Planning Zoals in paragraaf 2.5 beschreven, was de klant vaak niet goed geinformeerd over afleverdata van functionaliteiten. Dit kwam doordat er geen planning gemaakt werd en niemand dus eigenlijk precies wist wat er nog allemaal gedaan moest worden voor de klant. Er was geen overzicht, dit droeg bij aan onjuiste informatieverstrekking aan de klant en voor frustraties bij de medewerkers binnen Pharmeon. Om de problemen omtrent informatieverstrekking aan de klant te verbeteren en een goed overzicht te creëren, is een nieuwe planning opgezet, paragraaf 2.4 beschrijft de eerste poging die voor aanvang van deze stage gedaan is om een planning op te zetten. In de planning zijn zowel de dagelijkse taken als de projecten opgenomen. Er moesten nieuwe categorieën worden gedefinieerd die gebruikt konden worden. Voordat de categorieën gemaakt konden worden, moesten de Dev Tasks die in de planning stonden geanalyseerd worden en werd gekeken of er een indeling gemaakt kon worden. Hiervoor werd gezocht naar de meest voorkomende taken in de planning en werden taken gegroepeerd naar vergelijkbare acties en tijd. Nadat de categorieën goed waren omschreven en het voor iedereen duidelijk was wat er onder de categorieën viel, moest er een planning worden gemaakt. De opzet voor een planning was er al, alle benodigde informatie stond erin, maar er werd nog geen gebruik van gemaakt. Het maken van een planning was een grote uitdaging. Niet alleen moesten de medewerkers wennen aan het werken volgens een planning van Dev Tasks, maar ook het daadwerkelijk volgen van de planning was een grote opgave. Het maken van een wekelijkse planning ging als volgt. Als eerst moest er een schatting gemaakt worden van de tijd die besteed wordt. Hierbij is gebruik gemaakt van de tijdsbesteding (indien ingevuld) van reeds voltooide taken. Indien bepaalde taken nog nooit zijn gedaan, dan werd er gekeken naar gelijksoortige taken. Daarna werd de taak gecategoriseerd volgens de gemaakte categorieën (zie bijlage F). Vervolgens is er een planning gemaakt voor twee weken op basis van een 40-urige werkweek waarbij 75% van de tijd werd ingepland. Aan het eind van elke week werd een evaluatie van de taken gedaan en de planning van de volgende week indien nodig aangepast. Ook is aan het eind van dit onderzoek de planning geëvalueerd met de mederwerkers van Pharmeon. Hierbij kwam geen kwantitatieve data naar voren, omdat dit niet werd bijgehouden. Wel kon worden geconstateerd dat de categorisering van de taken heeft geleid tot een verdubbeling van het aantal op tijd voltooide Dev Tasks en een efficiënte planning. De onderstaande categorieën zijn ingevoerd en hebben de oude categorieën vervangen. Small Task Er is gekozen voor een scheiding tussen kleine taken (Small Task), die binnen een uur gedaan kunnen worden en taken waarvoor meer tijd nodig is (Task). Dit onderscheid is ook een onderscheid tussen de makkelijkere en meer complexere taken, waarmee

43


iedereen meteen ziet of de taken door hem/haar gedaan kunnen worden of niet. Voor de complexere taken is meer kennis nodig dan voor de makkelijkere taken, waarbij een vooraf vastgestelde procedure gevolgd moet worden. Aan een Small Task wordt maximaal één uur besteed. Small Task (code) Daarnaast is gekozen voor een scheiding tussen taken met programmeerwerk en taken zonder programmeerwerk, omdat er een klein aantal personen werken aan programmeertaken. Hierdoor is het voor iedereen meteen duidelijk naar welke taken ze moeten kijken en welke taken zij kunnen doen. Het verschil tussen een Small Task en een Small Task (code) is dus of er programmeerwerk nodig is om de taak te voltooien. Task Een Task is groter en complexer dan een Small Task en neemt één tot zestien uur in beslag. Vaak komt er meer bij kijken zoals Cascading Style Sheets (CSS) of een database. De XP practices die Pharmeon hierbij kan gebruiken zijn refactoring, continuous integration, coding standards en sustainable pace. Task (code) Een taak in de categorie Task (code) vereist programmeren, is complexer en neemt meer tijd in beslag dan een taak in de categorie Small Task (code). XP practices zoals beschreven bij de categorie Task kunnen gebruikt worden plus de practice testing door middel van unit tests. Content Verder is er nog een aparte categorie gemaakt voor het aanpassen/bijhouden van de websites. Dit kan afhankelijk van de taak tussen een half uur tot twee uur duren. Hiervoor is geen specifieke kennis nodig en dit kan in principe door elke medewerker gedaan worden. Development en Project Voor de taken die meer dan zestien uur in beslag nemen zijn er twee categorieën gemaakt: een voor één nieuw te ontwikkelen functionaliteit (Development) en een voor meerdere nieuw te ontwikkelen functionaliteiten of meerdere grote taken (Project). Bij taken in categorie Development of Project kunnen alle XP practices die bestempeld zijn als bruikbaar voor Pharmeon in deze paragraaf gebruikt worden. Idea en Internal De twee laatste categorieën zijn de twee die altijd als laatst aan de beurt komen, doordat ze meestal een lagere prioriteit hebben. De eerste (Idea) is voor ideeën en nieuw te ontwikkelen functionaliteiten waarover nog moet worden nagedacht of nog moet worden onderzocht of er genoeg draagvlak voor is. De laatste categorie (Internal) is voor interne taken, die niet meteen heel erg belangrijk zijn maar niet vergeten moeten worden. Hier kan worden gedacht aan het verbeteren van een bestaand systeem dat binnen Pharmeon gebruikt wordt. De taken in de categorie Idea zullen na het besluit om deze te realiseren, verplaatst worden naar de categorie Task(code). De taken in de categorie Internal nemen meestal meerdere dagen in beslag en wordt gefaseerd uitgevoerd. Hierbij kunnen de XP practices refactoring, continuous integration, coding standards en sustainable pace gebruikt worden. Print Deze categorie is gereserveerd voor het maken van drukwerk. Hieronder vallen folders, flyers, brochures, beursdoeken en gadgets voor op de beurs (pennen en muismatten). Ook het maken van een ontwerp valt in deze categorie.

Naast de categorieën voor de planning, moesten er ook procedures worden opgesteld. Voor de processen beschreven in hoofdstuk 2 is een procedure geschreven (zie bijlagen C,D en E). Deze zullen helpen om ervoor te zorgen dat alle stappen doorlopen worden en hiermee de kwaliteit van de processen en het resultaat te verbeteren. De procedures zijn makkelijk te volgen instructies die zijn opgeslagen op de gemeenschappelijke schijf waar alle medewerkers toegang tot hebben.

44


4.3 Software ontwikkelproces Op basis van de besproken software methodologieën in hoofdstuk 3, de ‘eisen’ van Pharmeon in paragraaf 4.1 en de nieuw opgezette planning terug te vinden in paragraaf 4.2, kan een software ontwikkelproces dat geschikt is voor Pharmeon worden beschreven. Het software ontwikkelproces is realistisch en haalbaar binnen Pharmeon uitgaande van de situatie zoals beschreven in hoofdstuk 2.

Figuur 4.1 Software ontwikkelproces voor Pharmeon

Voor het bijhouden en bewaken van de voortgang van het project is er een extra functie nodig binnen Pharmeon. Deze persoon, de tracker, is verantwoordelijk voor de planning, het updaten van de documenten en zorgt ervoor dat het project op schema blijft. XP definieert nog een aantal rollen waaronder tester en coach, die binnen Pharmeon door één persoon wordt vervuld. De overige rollen worden verdeeld waarbij de programmeur ook de rol van tester op zich neemt. In XP werken het ontwikkelteam en de klant nauw samen aan het project. De aanvraag voor een functionaliteit kan wel via de Directie of de afdeling Customer Services binnenkomen, maar deze wordt dan verder doorgespeeld naar de Research & Development afdeling. De taken onder de categorie Development en Project vallen onder aanvraag voor een functionaliteit. In figuur 4.1 is

45


het software ontwikkelproces beschreven zoals het eruit zou kunnen zien bij toepassing van een combinatie van Extreme Programming en Scrum op de Research & Development afdeling bij Pharmeon. De aanvraag voor een functionaliteit komt direct of via de Customer Services binnen op de afdeling Research & Development. Hier wordt over de mogelijkheden van de nieuwe functionaliteit nagedacht, een ontwikkelteam samengesteld en een meeting met de klant gepland. Bij mogelijkheden voor een nieuwe functionaliteit wordt er nagedacht over een eventuele uitbreiding of aanpassing van een bestaande functionaliteit die Pharmeon eerder heeft ontwikkeld. Op basis van de uitkomst hiervan wordt een ontwikkelteam samengesteld. Het ontwikkelteam wordt geleid door de technisch directeur die de rol van manager op zich neemt. Er wordt altijd gekozen voor simple design: het eenvoudigste ontwerp dat voldoet aan de requirements van de klant. In de Exploration phase, de eerste fase van het software ontwikkelproces, maakt het ontwikkelteam zich bekend met het domein, de technologie en methoden die gebruikt zullen worden. Deze fase neemt bij een gemiddeld software project enkele weken tot enkele maanden in beslag, bij een project waar een webapplicatie wordt afgeleverd neemt deze fase slechts enkele uren tot enkele dagen in beslag. Na deze fase is het ontwikkelteam goed voorbereid op de meeting met de klant. De klant specificeert op papier zijn wensen voor de eerste iteratie en denkt goed na over alle opties die in de nieuwe functionaliteit moet worden verwerkt. De applicatie kan door middel van user stories worden uitgeschreven door de klant op zogenaamde user story cards. In de Planning phase is een meeting met de klant gepland. Hierin wordt afgesproken hoe en wanneer er contact zal zijn om de voortgang van het project te bespreken. Het ontwikkelteam en de klant stellen in de meeting de requirements op voor de eerste iteratie aan de hand van de user stories opgeschreven door de klant. Tijdens de meeting prioriteert de klant de functionaliteiten en hij heeft het beslissende woord over de functionaliteiten die per iteratie worden meegenomen. Aan de hand van de lijst met requirements wordt naast elke functionaliteit de bijbehorende tijd gezet. Deze tijd wordt bepaald door het ontwikkelteam. Nu is de Functionality Backlog opgesteld. Nadat voor elke functionaliteit de tijd is bepaald, kan een planning voor de eerste iteratie worden gemaakt. Hierbij kan een planning tool gebruikt worden. De duur van de eerste iteratie wordt samen met de klant bepaald en daarmee dus ook de functionaliteiten voor de eerste iteratie. Hierbij kan worden gedacht aan een aantal weken tot één maand. De meeting wordt afgesloten met het tekenen van een overeenkomst over de inhoud van de eerste iteratie. Hierna worden uit de requirements Dev Tasks gemaakt. Elke Dev Task staat voor een bepaalde taak waaraan meerdere personen kunnen werken. Nadat de Dev Tasks zijn aangemaakt, kan de Iteration Backlog worden aangevuld met de benodigde gegevens. Zowel de Iteration Backlog als de Functionality Backlog worden tijdens het project bijgehouden door de tracker. Het einde van de eerste iteratie is de volgende checkpoint voor feedback van de klant in een meeting bij Pharmeon. De Planning phase zal bij Pharmeon doorgaans binnen één dag worden afgerond. De meeting vindt plaats bij Pharmeon en tijdens de meeting is een whiteboard beschikbaar om het een en ander duidelijk te maken. De eerste iteratieve en incrementele fase is de Iteration to Release phase. De ontwikkelaars lopen enkele cycli door voordat de eerste release aan de klant plaatsvindt. Deze cycli zullen, afhankelijk van de grootte van het project, enkele dagen tot één week duren. Een webapplicatie is vergeleken met een software product qua omvang veel kleiner en de cycli zijn dus korter doordat de functionaliteiten tot kleinere taken worden opgedeeld. Per cyclus worden de volgende stappen doorlopen: Dev Task completeren, unit tests schrijven, unit tests runnen, continu integreren van de programmacode, testen en refactoring. Aan het eind van de cyclus, begint deze weer overnieuw met de volgende Dev Task. Zodra alle Dev Tasks voor de huidige iteratie zijn gecompleteerd, zijn de cycli doorlopen. Tijdens een iteratie houdt de afdeling Customer Services de klant op de hoogte van de status en voortgang van de Dev Tasks. Vanaf deze fase begint elke dag met een stand-up meeting rond één tafel van maximaal 10 minuten. Ook wordt er vanaf dit punt een Iteration Burndown Chart bijgehouden. Deze moet zichtbaar voor het ontwikkelteam aan de muur worden opgehangen en laat zien hoeveel Dev Tasks al voltooid zijn in de huidige iteratie. De ontwikkeling in deze fase begint voor het ontwikkelteam met het bouwen van de architectuur van de applicatie, terwijl de klant testscenario’s uitschrijft waarmee de 46


applicatie kan worden getest op de werking. Deze functionele testen worden aan het einde van elke iteratie uitgevoerd. Ook het ontwikkelteam schrijft testen: unit tests. Deze testen worden geschreven volgens het TDD principe en automatisch gerund tijdens de ontwikkeling van de applicatie. De programmacode wordt na succevolle unit tests continu geintegreerd en getest met behulp van een IDE. Om veilig terug te kunnen gaan naar vorige versies wordt gebruik gemaakt van versiebeheer. Zolang de testen niet met succes worden uitgevoerd, kan er niet verder worden gegaan. Het succesvol uitvoeren van de testen geeft toegang tot de volgende fase: de Productionizing phase. In de Productionizing phase wordt de applicatie verhuisd naar de gebruikersomgeving en worden extra controles en system tests en performance tests uitgevoerd om de prestatie van de applicatie te testen. De cycli in deze fase worden versneld naar enkele dagen of uren. Dit komt neer op een fase die één tot enkele weken duurt. In deze fase kunnen nog veranderingen optreden die in de huidige iteratie moet worden meegenomen of in de volgende iteratie. Dit is afhankelijk van de prioriteit die de klant eraan geeft. Indien de veranderingen in de huidige iteratie meegenomen moeten worden, zullen nog enkele cycli van de Productionizing phase volgen. Als de veranderingen in de volgende iteratie moeten worden meegenomen, dan moet dat eerst gepland worden in de Planning phase. Nadat de cycli succesvol zijn doorlopen, is de iteratie aan het einde aangekomen waarna, indien er geen veranderingen meer zijn, een geüpdate release wordt gedaan aan de klant. Hierna wordt verdergegaan met de Maintenance phase. Aan het einde van elke iteratie worden retrospectives gehouden met het ontwikkelteam. Hierin wordt de zojuist doorlopen iteratie van begin tot eind geëvalueerd. De Maintenance phase is een fase die door de ontwikkeling heen blijft lopen. Zowel de bestaande applicatie als nieuwe iteraties zullen blijven doorlopen. Aan de bestaande applicatie worden bug fixes gedaan en wordt er aandacht besteed aan klantondersteuning. Elke iteratie volgende op de eerste zal steeds langer duren doordat er steeds meer geproduceerd en geintegreerd wordt en dus steeds meer getest moet worden. De snelheid waarmee ontwikkeld wordt zal hierdoor afnemen. Een vorm van maintenance is refactoring. Dit wordt al vanaf de Iteration to Release phase regelmatig toegepast. De laatste fase van XP, de Death phase begint als er geen openstaande user stories meer zijn. De applicatie moet hiervoor de klant tevreden stellen op het gebied van prestatie, betrouwbaarheid maar ook interface. In deze fase wordt de technische documentatie geüpdate door de programmeurs, maar ook gebruikersdocumentatie gemaakt door de tracker. Bij elke release wordt wel een korte documentatie geschreven, maar deze is informeel en beperkt. Aan het eind van de Death phase wordt de laatste release gedaan die tevens de definitieve is. Een project kan ook in de Death phase terechtkomen indien het project wordt stopgezet. Tijdens projecten worden normale 40-urige kantooruren gehanteerd van acht uur per dag. Structureel overwerken komt niet voor in XP projecten. Een enkele keer overwerken is toegestaan. Na de Death phase is de webapplicatie klaar voor de uitrol en is het project in principe beëindigd. XP beschrijft het ontwikkelproces vanaf het begin, dat begint bij een aanvraag voor een functionaliteit tot het einde van de ontwikkeling van de webapplicatie. Hierop volgt de implementatie van de applicatie die beschreven zal worden in paragraaf 5.4. Voor maintenance zoals bug fixes en nieuwe requirements na uitrol van de webapplicatie, worden nieuwe Dev Tasks aangemaakt. Deze Dev Tasks zullen afhankelijk van de grootte ervan elk aan de categorie Task (code), Development of Project worden toegewezen. De aangemaakte Dev Tasks zullen vervolgens weer ingepland moeten worden. Dit is afhankelijk van de belangrijkheid van de Dev Task. De maintenance zoals hierboven besproken is niet gelijk aan de Maintenance phase van XP. In de maintenance wordt onderhoud aan de bestaande webapplicatie verricht, terwijl de Maintenance phase van XP kan worden gezien als een tussenstop waar alle onderdelen van de applicatie samenkomen om vervolgens één of meerdere applicaties te formeren. De Maintenance phase is dus niet het onderhouden van de software. Met het software ontwikkelproces zullen alle vier de knelpunten aangepakt worden. Door het gebruik van een agile methode werkt het ontwikkelteam nauw samen met de klant waarbij de

47


communicatie tussen de medewerkers van Pharmeon efficiënter moet verlopen en ook de communicatie met de klant moet onderhouden worden. Hierdoor worden de medewerkers van Pharmeon in de goede richting geduwd. Ook is communicatie één van de vier waarden van XP waarin sprake is van een mondelinge cultuur en de practices de communicatie binnen het ontwikkelteam bevorderen. De hoeveelheid documentatie zal in XP beperkt blijven tot korte en duidelijke technische en gebruikersdocumentatie. Hiervoor is in het software ontwikkelproces tijd gereserveerd in de Death phase. De documenten uit Scrum helpen het project te managen door een duidelijk overzicht te creëeren van de voortgang. Het testen zal door de automatische unit tests verbeterd worden. Daarnaast kan de programmacode niet geintegreerd worden voordat de automatische unit tests en de customer acceptance tests succesvol doorlopen worden. Met de vernieuwde planning kan door de categorisering een goede planning worden gemaakt en een overzicht worden gecreëerd. Onderdeel van XP is de planning phase waarin de planning de basis is voor de uitvoering van het project. Het ontwikkelteam vult zelf de tijdsbestedingen in en stelt samen met de klant de planning op waardoor deze realistischer zal zijn. De planning heeft hiermee een vaste plaats in het software ontwikkelproces en meteen een onmisbare functie.

48

Hoofdstuk 5 Implementatietraject HerhaalRecepten

Hoofdstuk 5 Implementatietraject HerhaalRecepten In 2005 is Pharmeon begonnen met de ontwikkeling van een webapplicatie voor het bestellen van herhaalrecepten via internet. Door deze webapplicatie eerst in een simpele vorm aan te bieden op de website van de apotheken wilde Pharmeon de concurrentie voor zijn. De webapplicatie was een formulier dat helemaal ingevuld moest worden. Hierbij moest de patiënt om alle gegevens in te kunnen vullen het herhaalreceptbriefje bij de hand hebben. Ondertussen werd er gewerkt aan een andere versie waarbij de patiënt na inloggen op de website van de apotheek herhaalrecepten kon bestellen. Er waren geen herhaalrecept briefjes meer nodig en alle herhaalmedicatie was in één oogopslag op het scherm te zien. Dankzij de koppeling tussen de webapplicatie en het apothekerssysteem kunnen alle patiëntgegevens uit het apothekerssysteem gehaald worden en op het scherm worden getoond. Fase 1 van het project HerhaalRecepten was voltooid en de pilot-fase kon beginnen. Het doel van de pilot-fase was om feedback te krijgen over de manier van bestellen en de aangeboden opties. In de tweede en laatste fase van het project moest er gewerkt worden aan de beveiliging van patiëntgegevens. Bij de uitwisseling van patiëntgegevens tussen het apothekerssysteem en de webapplicatie HerhaalRecepten in de pilot-fase konden de patiëntgegevens in principe onderschept worden en in het openbaar terechtkomen. Dit probleem is in de tweede fase van het project aangepakt. De laatste versie van de webapplicatie HerhaalRecepten is bijna klaar voor uitrol. De beveiliging gaat via een authenticatie- en communicatieserver. Na het inloggen moet de patiënt om herhaalmedicatie te kunnen bestellen, een extra toegangscode invoeren om te verifiëren of er aan de juiste persoon toegang wordt verleend. Authenticatie gebeurt via e-mail of sms, afhankelijk van de instellingen. Via de management console kan de apotheker de patiënten die gebruik willen maken van de webapplicatie en de instellingen beheren. Zoals eerder genoemd is er een pilot-fase in vijf apotheken gedraaid. Paragraaf 5.1 zal ingaan op de details omtrent deze pilot-fase en de voorbereidingen daarvan. In paragraaf 5.2 worden de resultaten van de pilot-fase uiteen gezet en het verdere verloop vanaf dat punt besproken. De volgende paragraaf, 5.3, bevat een implementatie advies voor het project HerhaalRecepten. Dit advies is bedoeld voor Pharmeon en zal kunnen bijdragen aan een succesvolle implementatie van de webapplicatie. In paragraaf 5.4 zal het implementatietraject, onderdeel van het software ontwikkelproces van XP worden beschreven. Deze paragraaf is een vervolg op paragraaf 4.3 waarin het software ontwikkelproces, met uitzondering van het implementatietraject is beschreven.

5.1 Pilot De pilot begon in december 2005 en eindigde in februari 2006. De deelnemende apotheken waren op de hoogte gesteld van een nog te ontwikkelen applicatie voor herhaalrecepten via de website en aan hen werd feedback gevraagd over de functies van de applicatie. De apotheken gaven aan deel te willen nemen aan de pilot-fase en waren erg enthousiast over het vooruitzicht. De voorbereidingen voor de pilot-fase die moesten plaatsvinden voordat een apotheek kon deelnemen aan de pilot waren: een koppeling maken tussen het apothekerssysteem en de website en een testpersoon aanmaken waarmee door de procedure heen werd gelopen samen met de klant. In december 2005 konden de vijf apotheken beginnen met een kleine zelf gekozen patiëntenpopulatie. Niet alle functies waren geïmplementeerd voor de pilot-fase, maar vanwege de tijdsdruk om als eerste op de markt te komen met deze nieuwe applicatie en de vraag ernaar van de apotheken werd besloten de pilot-fase alvast te beginnen. De nog niet geïmplementeerde functies zouden tijdens de pilot worden geïmplementeerd. Aan het begin van de pilot werd met de apotheker de applicaties doorgenomen vanaf het moment dat een patiënt zich aanmeldt voor HerhaalRecepten via internet tot en met het bestellen van medicatie. Gedurende de drie maanden durende pilot konden de apotheken voor hulp en ondersteuning bellen of e-mailen met de Customer Services van Pharmeon. Hiervan werd dan ook goed gebruik gemaakt als de applicatie niet werkte of als de benodigde functie nog niet in de webapplicatie zat.

49


De webapplicatie HerhaalRecepten werd verbeterd door feedback van de pilot-apotheken en uitgebreid met een aantal extra functies. De volgende versie die zou worden vrijgegeven was er een met authenticatie via e-mail of sms. Om een succesvolle implementatie van de webapplicatie HerhaalRecepten zoveel mogelijk te vergroten, is besloten een implementatie advies te schrijven op basis van interviews met de pilotapotheken. Van de vijf pilot-apotheken hebben twee apotheken daadwerkelijk de webapplicatie HerhaalRecepten uitgeprobeerd. De overige drie apotheken hebben vanwege tijdstekort of onvoldoende vertrouwen in de toen opgeleverde webapplicatie er weinig mee gedaan. De pilotapotheken hebben ingestemd met een telefonisch interview. Hierin zijn een aantal vragen gesteld om de webapplicatie te evalueren. De vragen zijn gebaseerd op de testtechniek: Software Usability Measurement Inventory (SUMI). 11 SUMI is een geteste en gevalideerde methode om de kwaliteit van software vanuit het perspectief van de gebruiker te meten.

5.2 Resultaten De implementatie van de HerhaalRecepten pilot is geëvalueerd door middel van telefonische interviews met de vijf pilot-apotheken (zie bijlage B). In het interview werd gevraagd naar de het verloop van de implementatie van HerhaalRecepten in de apotheek, de ondersteuning en begeleiding die werd gegeven, maar ook hoe de apotheek de implementatie heeft ervaren. De implementatie van de webapplicatie Herhaalrecepten verliep erg rommelig en chaotisch. Er was niet voldoende ondersteuning vanuit Pharmeon voor zowel de apotheek als de patiënten. Ook verliep de communicatie tussen de apotheek en Pharmeon niet altijd efficiënt. Voor het begin van de pilot is er telefonisch informatie gegeven over de werking van Herhaalrecepten, maar er is geen training of uitleg geweest voor het overige personeel. Ook is er geen documentatie gegeven, noch aan de apotheek, noch aan de patiënt, betreffende de werking van de webapplicatie. Bij de start van de pilot is er een bezoek gebracht aan de apotheken om de webapplicatie door te lopen. Bij elke apotheek werd een testpersoon aangemaakt en gekoppeld aan het apothekerssysteem. Hierin zijn de volgende aspecten aan bod gekomen: de webapplicatie Herhaalrecepten in het algemeen de aanmeldprocedure inloggen als patiënt en bestellen van herhaalmedicatie bekijken als apotheker welke informatie binnenkomt in de apotheek Tijdens de pilot is meerdere malen via de telefoon en e-mail contact geweest over de voortgang, problemen en verbeteringen. Deze contacten zijn vooral via de Customer Service verlopen. De problemen zijn volgens de apotheker niet altijd goed opgepikt door Pharmeon. Aan sommige probleemmeldingen werd weinig aandacht geschonken; dat wil zeggen het duurde te lang voordat er iets mee gedaan werd, terwijl deze voor de apotheek en/of de patiënten belangrijk waren. Andere kleine problemen en verbeteringen werden snel aangepast of verholpen. In de pilot-fase werd alles pas goed getest en er werden dus nog verbeteringen gedaan gedurende de pilot, terwijl de apotheken er al vanuit gingen dat de meeste functionaliteit al werkzaam was. Niet op tijd afgeleverde functionaliteit was de grootste oorzaak van miscommunicatie en problemen. Elke apotheek heeft voor de pilot-fase zelf een aantal patiënten geselecteerd om van de webapplicatie gebruik te maken. Deze patiënten misten vooral ondersteuning in de vorm van gebruikersdocumentatie. Ook hebben zij een aantal verbeterpunten tijdens de pilot naar voren gebracht. De apotheken kozen ervoor om de webapplicatie niet voor iedereen open te stellen zolang de functionaliteit niet optimaal was. Pharmeon werkte aan de verbetering van de applicatie en hoopte deze half maart 2006 af te ronden om deze te kunnen promoten en verkopen. 11

http://sumi.ucc.ie

50


De problemen die tijdens de pilot naar voren kwamen hebben vooral betrekking op niet werkende functionaliteiten en miscommunicatie over functionaliteiten. De klant dacht dat alle functionaliteiten bij aanvang van de pilot-fase in de webapplicaties zouden zitten. Dit was niet het geval, waardoor er teleurstelling bij de apotheek was. Tijdens en na afloop van de pilot-fase zijn een aantal verbeterpunten voorgesteld door de apotheek. Deze verbeterpunten zijn inmiddels door Pharmeon gerealiseerd. De belangrijkste waren onder andere: de optie om uit de bestelgeschiedenis opnieuw te bestellen. Op deze manier werd de applicatie gebruiksvriendelijker. default bezorgoptie is ophalen in apotheek. Tijdens de pilot-fase konden in een oogopslag alle mogelijke opties en adressen worden gezien, zowel ophalen in de apotheek als bezorgen. Bovendien was er geen default bezorgoptie. enkele tekstuele aanpassingen. Dit waren vooral aanpassingen van algemene aard. enkele lay-out aanpassingen die de user interface van de webapplicatie er mooier uit liet zien. Aan het eind van dit onderzoek is de 2e fase van het project HerhaalRecepten nog niet voltooid. De communicatie- en authenticatieserver zijn gebouwd, maar werkten nog niet optimaal. De apotheek moet bijvoorbeeld alle persoonlijke gegevens van al zijn patiënten handmatig invoeren in de management console. Het is veel makkelijker voor de apotheek als alle persoonlijke gegevens bij de aanmelding van de patiënt gelijk opgeslagen worden. Pharmeon is hier nog mee bezig en de uitrol van de webapplicatie HerhaalRecepten is voor onbepaalde tijd uitgesteld. De reden hiervan is de tijdsdruk en de vele projecten en taken waarmee Pharmeon te maken heeft. Om alle klanten tevreden te houden, is gekozen om alle projecten stap voor stap te voltooien zodat voor elke klant voortgang van het project te zien is.

5.3 Advies Om een succesvolle implementatie van een webapplicatie zoveel mogelijk te bevorderen, zijn er een aantal factoren waar rekening mee moet worden gehouden. Deze factoren hebben een grote invloed op het accepteren van een nieuwe applicatie binnen een organisatie [24]. Compatibility Relative advantage Complexity Customer interaction Top management support Information System infrastructure (IS infrastructure) Information System expertise (IS expertise) Importance of Information System security (Importance of IS security) De compatibility ofwel de mate van consistentie met de bestaande ervaringen en behoeften van de klant bepaalt of er weerstand wordt geboden. Hoe meer consistent de nieuwe applicatie is met de bestaande opvattingen en standpunt van de klant, hoe kleiner de kans op weerstand. De relative advantage geeft aan of de nieuwe applicatie vanuit het perspectief van de eindgebruiker ‘beter’ is dan de huidige. Een ‘betere’ applicatie brengt voordelen met zich mee en zorgt voor een snellere aanname van de applicatie. Natuurlijk heeft ook de complexity een grote invloed op de implementatie van een applicatie, hierbij wordt gekeken of de applicatie begrijpelijk en makkelijk in gebruik is. Complexiteit kan een grote belemmering zijn bij de implementatie doordat het aangeeft dat er technische kennis nodig is om de applicatie te implementeren en te gebruiken. De mate van customer interaction, interactie met de gebruiker, geeft het belang aan van de behoeften van de klant in de organisatie. De leverancier zou de markt in de gaten moeten houden om de behoeften van de klant te detecteren en daarop te kunnen reageren. Het betrekken van de klant bij de ontwikkeling van een applicatie is ook één van de practices van XP.

51


Bij het missen van de steun van het management van de organisatie, is geen enkele implementatie mogelijk. Verder zijn de IS infrastructure, de infrastructuur van de applicatie, IS expertise, de technische kennis van de uitvoerende organisatie en importance of IS security, de beveiliging van de applicatie van belang. De eerste twee factoren lijken op het eerste gezicht niet direct invloed te hebben op de implementatie van de applicatie, maar de eerste zal voor de meer technisch geschoolde klant en de tweede juist voor de minder technische geschoolde klant wel een grote rol spelen. Beveiliging en betrouwbaarheid spelen een grote rol bij applicaties waarbij persoonlijke informatie wordt verstuurd. De client van de klant wil niet het risico lopen dat zijn persoonlijke gegevens voor derden zichtbaar zijn. Met de nieuwe versie van HerhaalRecepten is er een nieuwe uitdaging: beveiliging van patiëntgegevens. Deze uitdaging is in de literatuur [25,26] al veel besproken, maar voor de gemiddelde burger is dit nog onbekend terrein. Een veelbesproken project is het Elektronisch Patiënten Dossier waarbij beveiliging een grote rol speelt. 12 Er wordt veel gesproken over beveiliging van patiëntgegevens, maar tot dusver heeft de patiënt zelf hier weinig mee te maken gehad. Zowel de apotheek als de patiënt zullen dus voorzichtig zijn bij het aannemen van de webapplicatie en willen zeker zijn dat de patiëntgegevens goed beveiligd zijn, worden verstuurd en niet onderschept kunnen worden [27]. Dit betekent dat er met de factor importance of IS security tijdens de ontwikkeling rekening gehouden moet zijn. De manier waarop de patiëntgegevens in de webapplicatie HerhaalRecepten beveiligd worden, moet dus duidelijk worden gedocumenteerd en eventueel uitgelegd kunnen worden aan de personen die hierin geinteresseerd zijn. Hiernaast worden om de apotheek en de patiënten zo goed mogelijk voor te bereiden op het gebruik van de webapplicatie HerhaalRecepten, zowel een handleiding voor de apotheek als gebruikersdocumentatie voor de patiënten gemaakt. De documentatie kan verduidelijkt worden door het gebruik van screenshots. Hiermee worden de meeste vragen beantwoord, kan er snel en goed begonnen worden aan het gebruik van de webapplicatie en bovendien is het een goed visitekaartje voor de webapplicatie. De afdeling Customer Services zal hierdoor minder vragen krijgen, maar blijft het eerste aanspreekpunt voor vragen en ondersteuning. Voordat de webapplicatie uitgerold wordt, is het zeer belangrijk om met een groep apotheken een pilot te doen. Customer interaction is daarmee een belangrijke factor. Dit zou kunnen met de apotheken die ook in de eerste pilot hebben meegedaan en enkele nieuwe apotheken. De apotheken die in de eerste pilot hebben meegedaan zijn al bekend met de applicatie en zullen het na hun bijdrage zeer op prijs stellen om als één van de eersten met de vernieuwde applicatie te mogen werken. Hiermee wordt het contact met de klant verbeterd en wordt de applicatie door ‘ervaren’ gebruikers getest. Met deze groep kan gecontroleerd worden of de applicatie ‘beter’ is en aan de factor relative advantage tegemoet is voldaan. Ook kan de factor compatibility geëvalueerd worden door te peilen of de applicatie voldoet aan de verwachtingen van de ‘ervaren’ gebruikers. De pilot groep moet ook uit enkele apotheken bestaan die nog niet bekend zijn met de applicatie om achter beginnende onduidelijkheden te komen.

5.4 Implementatietraject Het implementatietraject dat in deze paragraaf besproken wordt, is van toepassing op elk project dat gebruik maakt van XP. Dit traject is geen onderdeel van één van de fasen van XP, maar volgt op de laatste fase van het software ontwikkelproces, de Death phase. Nadat de applicatie is goedgekeurd en de bijbehorende documentatie is gemaakt, kan de applicatie worden uitgerold. Indien tijdens de ontwikkeling van de applicatie rekening is gehouden met de factoren genoemd in paragraaf 5.3, is de kans op een succesvolle implementatie vergroot [24]. Het implementatietraject kan al in de Death phase worden voorbereid. Hier wordt al onderzoek gedaan naar het niveau van de eindgebruikers, de systemen waarmee gewerkt wordt en technische en organisatorische voorbereidingen getroffen voor de implementatie. Alle klanten die 12

www.nictiz.nl

52


gebruik willen maken van de nieuwe webapplicatie moeten hierover geïnformeerd worden. Het informeren van de klanten gaat via de afdeling Customer Services, zij onderhouden het klantencontact en brengen nieuwe applicaties onder de aandacht. Wanneer een klant interesse heeft in de webapplicatie en besloten heeft deze af te nemen, gaat Pharmeon over tot implementatie. Het systeem van de klant zal klaar worden gemaakt en de eindgebruikers zullen een korte training krijgen over het gebruik van de webapplicatie. De implementatie zal in samenwerking met de Customer Services worden gedaan, waarbij zij, indien het een webapplicatie betreft die gekoppeld is aan een systeem van de klant, een bezoek zullen brengen aan de klant en het ontwikkelteam zal zorgen voor de gebruikersdocumentatie en de werking van de applicatie. De gebruikersdocumentatie zal aan de klant overhandigd worden tijdens de training. Betreft het een op zichzelf staande webapplicatie, dan is uitleg over de telefoon en het opsturen van de gebruikersdocumentatie al voldoende voor een succesvolle aanname en gebruik van de webapplicatie. Voor aanvullende vragen en opmerkingen is de Customer Services altijd het eerste aanspreekpunt. Na een bepaalde tijd zou er een evaluatie moeten worden gedaan door de Customer Services om te kijken of de webapplicatie nog steeds voldoet in de ogen van de klant. Hiervoor kunnen een aantal klanten die actief zijn met de website worden opgebeld om naar hun mening te vragen en eventuele verbetervoorstellen. Op deze manier wordt de klant actief betrokken bij de ontwikkeling van de applicatie en verbetert dit het contact met de klant. Daarnaast biedt het een mogelijkheid om een nieuw project voor uitbreiding van de webapplicatie binnen te halen. Voordat een webapplicatie ook daadwerkelijk uitgerold wordt, kan een pilot-fase bij een groep diverse klanten introduceren toegevoegde waarde hebben. Een pilot-fase geeft de gelegenheid om de applicatie goed te laten testen in verschillende gebruikersomgevingen en brengt feedback met zich mee omtrent de applicatie. Nadat de applicatie een pilot-fase goed heeft doorstaan heeft het al bekendheid verworven en kunnen de klanten er meer vertrouwen in hebben gekregen. Dit kan komen doordat de applicatie al door collegea is uitgetest en ‘goedgekeurd’ is. Pharmeon houdt de markt goed in de gaten en probeert op de hoogte te blijven van alle ontwikkelingen in de zorg en hierop in te spelen. Een goed contact met de klant is hierbij ook belangrijk om alles vanuit een ander perspectief te horen en hierover te kunnen praten. Regelmatig komt Pharmeon met nieuwe applicaties waarbij het concept voor de gemiddelde burger onbekend zijn. Vooral bij deze applicaties zijn goede informatieverstrekking, begrijpelijkheid van de werking van de applicatie en makkelijk in gebruik belangrijk voor het kunnen aanbieden van de applicatie.

53

54

Hoofdstuk 6 Conclusies en discussie

Hoofdstuk 6 Conclusies en discussie In dit hoofdstuk worden de onderzoeksvragen beantwoord in paragraaf 6.1 waarna ook de hoofdvraag beantwoord zal kunnen worden. Vervolgens worden er in paragraaf 6.2 aanbevelingen gedaan met het oog op de toekomst en zal tot slot in paragraaf 6.3 een discussie volgen over de onderzoeksperiode.

6.1 Onderzoeksvragen Hieronder worden de onderzoeksvragen achtereenvolgens beantwoord: Welke bedrijfsprocessen spelen zich af binnen Pharmeon? Binnen Pharmeon spelen zich een aantal bedrijfsprocessen af op de afdeling Research & Developent. De belangrijkste bedrijfsprocessen, zoals beschreven in paragraaf 2.2, zijn ‘opzetten van een website’ en ‘aanvragen van een functionaliteit’. Deze twee processen nemen de meeste tijd in beslag en geven een goed beeld van werkzaamheden van Pharmeon. Daarnaast spelen zich ook de processen ‘extra service op de website activeren’, ‘domeinnaam registreren’, ‘pop account aanmaken’ en ‘onderhouden van de website’ af. De processen op de Research & Development afdeling worden niet volgens een standaard procedure doorlopen. Welke knelpunten zijn er? Mede vanwege de groei van Pharmeon zijn een aantal problemen goed zichtbaar geworden. De knelpunten, opgesomd in paragraaf 2.6, hebben allemaal te maken met het software ontwikkelproces op de Research & development afdeling. Dit proces voldoet niet meer aan de eisen om kwalitatief hoge software af te leveren en moet herzien worden. Na het interviewen van de medewerkers van Pharmeon en alle bedrijfsprocessen op de Research & Development afdeling nader geanalyseerd te hebben, werden de knelpunten duidelijk. De knelpunten zijn: (1) slechte communicatie tussen de afdelingen onderling en met de klant, (2) weinig tot geen gebruikersdocumentatie en technische documentatie van de bestaande functionaliteiten, (3) geen uitgebreide testen van producten die worden opgeleverd en (4) geen planning van de dagelijkse taken en projecten. Samen zorgden de knelpunten voor een kwaliteitvermindering van de producten. Wat voor type projecten worden er uitgevoerd? Bij Pharmeon worden verschillende soorten projecten uitgevoerd met een klein ontwikkelteam. Tijdens deze kortdurende (2 weken – 2 maanden) en relatief eenvoudige projecten worden webapplicaties ontwikkeld. Het schatten van tijdsbestedingen aan projecten werd zelden gedaan, waardoor er moeilijk kon worden achterhaald of de projecten binnen het budget bleven of op tijd werden opgeleverd. De ingevulde tijdsbesteding was een schatting van de gespendeerde tijd aan een project en werd niet altijd goed bijgehouden. Tijdens de onderzoeksperiode begonnen de projecten langzaam in aantal toe te nemen en steeds langduriger en complexer te worden. Welke mogelijke oplossingen zijn er voor de knelpunten? Voor de knelpunten bij Pharmeon zijn verschillende oplossingen gevonden in de literatuur. Alle vier de knelpunten kunnen grotendeels opgelost worden door het volgen van een gestructureerde software ontwikkelmethode. Tijdens het zoeken in de literatuur is de keuze gemaakt voor Agile software ontwikkelmethoden. Deze methoden zijn gericht op het afleveren van kwalitatief hoge software in een dynamische omgeving waar tijd een grote rol speelt. De gevonden oplossingen zijn gereduceerd tot vier oplossingen die het best toepasbaar leken bij Pharmeon: Extreme Programming, Scrum, DSDM en FDD. Wat is de beste oplossing voor Pharmeon? De best toepasbare software ontwikkelmethode voor Pharmeon is een combinatie van Extreme Programming (XP) en Scrum. XP is uitermate geschikt voor kleine ontwikkelteams die in korte tijd

55


goede kwaliteit software willen ontwikkelen waarvan de requirements vooraf nog niet vaststaan. XP gaat uit van twaalf practices die elkaar versterken. De practices die goed binnen Pharmeon ingevoerd zouden kunnen worden zijn testing, refactoring, coding standards, iteration/planning game en sustainable pace. Daarnaast zijn er nog enkele activiteiten die goed passen binnen XP en die kunnen bijdragen aan het software ontwikkelproces. Dit zijn de stand-up meetings, retrospectives en de drie documenten die in Scrum gebruikt worden (Functionality Backlog, Iteration Backlog, Iteration Burndown Chart). Deze documenten zijn gedetailleerder dan de documenten die in XP gebruikt zouden kunnen worden zoals de task list en visible wall graphs. Om alle documenten op te stellen, bij te houden en de voortgang van het project te bewaken is er een extra functie nodig binnen Pharmeon die de rol van tracker gaat vervullen. Naast de software ontwikkelmethode is er voor de planning een categorisering van de te verrichten taken gemaakt. Deze categorisering zorgt voor overzicht en maakt het plannen van de dagelijkse taken, maar ook van de projecten beter mogelijk. De planning met de categorisatie is ingevoerd tijdens de stage, het software ontwikkelproces zoals hierboven besproken niet. Daarnaast is het aantal op tijd voltooide Dev Tasks met 50% toegenomen en werkt de planning efficiënt. Om de dagelijkse taken met een goed resultaat op te leveren zijn procedures geschreven. Deze procedures zorgen voor standaardisering en dragen bij aan de kwaliteit van de opgeleverde producten en daarmee aan de tevredenheid van de klant. Welk implementatietraject zou gevolgd moeten worden om van het project HerhaalRecepten een succes in apotheken te maken? Voor het project HerhaalRecepten, waarvan de eerste fase al achter de rug is, maar aan de tweede fase nog gewerkt wordt, is een implementatie advies geschreven. In dit advies komen een aantal belangrijke factoren naar voren waarmee rekening moet worden gehouden al tijdens de ontwikkeling en voor de implementatie van de applicatie. Voor de tweede fase van het project HerhaalRecepten waren dit importance of IS security, relative advantage en compatibility. Het implementatietraject dat de kans op een succesvolle implementatie in apotheken vergroot bestaat uit het goede voorbereiding en voorlichting van de eindgebruikers. Vóór de implementatie moeten al voorbereidingen worden getroffen zoals onderzoek naar de manier van werken en het schrijven van een handleiding. De eindgebruikers moeten goed voorgelicht worden over de mogelijkheden van de applicatie en ondersteund worden bij het gebruik ervan. De hoofdvraag luidde als volgt: Hoe kunnen de bedrijfsprocessen van Pharmeon BV geoptimaliseerd worden, zodat het software ontwikkelproces met goed resultaat wordt doorlopen? In hoofdstuk 2 is een begin gemaakt met het in kaart brengen van de bedrijfsprocessen bij Pharmeon. Hierbij zijn de twee belangrijkste processen op de Research & Development afdeling in kaart gebracht en naast de ideale situatie gezet. Hoofdstuk 3 noemt een aantal oplossingen uit de literatuur voor op de knelpunten. Alle oplossingen zijn Agile softwaremethoden die uitgaan van dezelfde principes: de Agile Manifesto. De best toepasbare oplossing bij Pharmeon, uitgaande van de huidige situatie is een combinatie van Extreme Programming en Scrum. Met deze oplossing worden tegelijk de knelpunten betreffende communicatie, documentatie, testen en planning opgelost. Het volgen van XP zorgt voor meer structuur, meer en betere communicatie doordat de practices hierop gericht zijn, documentatie daar waar nodig is, het uitgebreid testen van de op te leveren webapplicatie door middel van unit test en customer acceptance tests en een realistische planning doordat het ontwikkelteam samen met de klant de tijdsbestedingen invult. XP dekt niet het hele software ontwikkelproces tot aan de implementatie van de applicatie, maar beschrijft het software ontwikkelproces tot aan de fase systeem test (fase 7 van figuur 3.6). Het traject tot hierop volgt is het implementatietraject, dat beschreven is in paragraaf 5.4. Als alle fasen doorlopen zullen worden, dan is er goede kans dat de software werkend, getest en op tijd opgeleverd kan worden. Met de vernieuwde planning kunnen alle taken en projecten beter gepland worden. De Dev Tasks kunnen gecategoriseerd worden en op deze manier sneller gesorteerd en herkend worden. De planning is tijdens de stage ingevoerd. 56


6.2 Aanbevelingen Pharmeon vecht hard om aan de top te blijven op het gebied van websites voor medisch zorgverleners. Goed klantencontact en de markt scherp in de gaten houden zijn daarom een must. Om verder te kunnen groeien en succesvol te zijn, moeten naast de invoering van de voorgestelde combinatie van Extreme Programming en Scrum de processen en procedures verder onderzocht en beschreven worden. Tijdens de onderzoeksperiode is hiermee een begin gemaakt, maar niet alle processen zijn onderzocht en daarmee niet alle procedures beschreven. Alleen de processen op de afdeling Research & Development zijn onderzocht en dit is eenmalig aan het begin van het onderzoek gedaan. De procedures moeten indien één of meerdere processen zijn veranderd weer herzien worden en de processen op de afdeling Customer Services zijn niet onderzocht. Zoals al eerder genoemd is Pharmeon een klein en informeel bedrijf waar communicatie het voornaamste probleem is. De software ontwikkelmethode die wordt gebruikt is verouderd en niet meer goed toepasbaar in de huidige situatie. Verandering is echter in deze tijd van groei een risico dat genomen moet worden om verder te kunnen groeien. Om de verwachte groei van Pharmeon bij te kunnen houden, zullen procedures steeds belangrijker worden en er steeds meer standaarden moeten komen om alles in goed banen te leiden. Nieuwe medewerkers zullen aangenomen moeten worden die op dezelfde manier moeten werken als de anderen. Er zal tijd moeten worden vrijgemaakt voor standaardisatie en dit zal een vast onderdeel moeten worden dat steeds herzien moet worden om up-to-date te blijven. Met dit onderzoek is een begin gemaakt met kwaliteitswaarborging van de producten. Om dit voort te kunnen zetten is minstens één fulltime medewerker nodig voor de rol van tracker. Mocht Pharmeon over willen gaan op een combinatie van Extreme Programming en Scrum, dan zou dat gefaseerd ingevoerd kunnen worden te beginnen met de practices testing en refactoring. Deze twee practices zullen samen met de al ingevoerde planning zorgen voor een kwaliteitsverbetering van de producten. De besproken oplossingen zijn adviezen, die indien ze worden opgevolgd, voor meer structuur en standaardisering zouden kunnen zorgen. Hiermee is Pharmeon een stap dichter bij een CMM niveau 3.

6.3 Discussie Het onderzoek is uitgevoerd bij een klein en informeel bedrijf. Weinig was al gestandaardiseerd en procedures zaten veelal in de hoofden van de medewerkers. Er waren veel mondelinge afspraken waardoor niet alle nieuwe medewerkers en stagiaires van alles op de hoogte waren. De knelpunten uit hoofdstuk 2 waren makkelijk te signaleren met behulp van interviews en de ideale situatie uit de literatuur ernaast. Dit waren de ‘typische’ knelpunten waarmee een bedrijf te maken kan hebben tijdens zijn groei. Het knelpunt planning was al voor aanvang van dit onderzoek bekend en een eerste opzet hiervan was al gemaakt. Hier bleek nog niet goed over nagedacht te zijn waardoor er eerst tijd moest worden besteed aan analyse van de planning. In hoofdstuk 4 wordt de best toepasbare software ontwikkelmethode voor Pharmeon besproken. Hierbij is uitgegaan van het type projecten zoals beschreven in paragraaf 2.5. Mocht het type project dat Pharmeon uitvoert veranderen, dan zal ook de software ontwikkelmethode opnieuw bekeken moeten worden. Ook aan de planning zitten beperkingen. Deze zal goed blijven werken met een klein team en waarbij het plannen van afzonderlijke taken voldoende is. Het is niet mogelijk om afhankelijkheden in te voeren of meerdere personen te koppelen aan één taak. De invoering van een ander software ontwikkelproces is nog niet aan bod gekomen. Hiervoor moet eerst tijd vrij gemaakt worden om te zorgen dat alle andere taken en projecten geen vertraging oplopen. Ook is er geduld voor nodig die men in een tijd van drukte vaak niet heeft. De meeste publicaties zijn geschreven door practitioners die de succesverhalen beschrijven aan de hand van hun eigen ervaringen. Dit zijn dus geen objectieve resultaten.

57

Literatuurlijst

Literatuurlijst [1] G. Kreytz, O. Rossman, Missie visie, Pharmeon BV, 2004. [2] M. Paulk, B. Curtis, M. Chrissis, C. Weber, Capability Maturity ModelSM for Software, Version 1.1, www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf, 1993. [3] S. Murugesan, Y. Deshpande, S. Hansen, A. Ginige, Web Engineering: A New Discipline for Development of Web-based Systems, Journal of Web Engineering, vol. 1 no. 1, p3-17, 2002. [4] B. Pedigo, D. Callahan, Communication Lessons from IT Consultancies, IT Professional, vol. 5 no. 4, p53-56, 2003. [5] D. Dvir, T. Raz, A. Shenhar, An empirical analysis of the relationship between project planning and project success, International Journal of Project Management, vol. 21 no. 2, p89-95, 2003. [6] The Standish Group International, Extreme Chaos, http://www3.uta.edu/faculty/reyes/teaching/general_presentations/extreme_chaos.pdf, 2001. [7] F. Paetsch, A. Eberlein, F. Maurer, Requirements Engineering in Agile Software Development, Proceedings of the Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’03), IEEE, 2003. [8] K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. Martin, S. Mellor, K. Schwaber, J. Sutherland, D. Thomas, The Agile Manifesto, http://www.agilemanifesto.org. [9] L. Williams, A Survey of Agile Development Methodologies, http://agile.csc.ncsu.edu, 2004. [10] K. Beck, Embracing Change with Extreme Programming, IEEE Computer, vol. 32 no. 10, p70-77, 1999. [11] P. Abrahamsson, Extreme Programming: First Results from a Controlled Case Study, 29th Euromicro Conference (EUROMICRO'03), p259, 2003. [12] P. Abrahamsson, O. Salo, J. Ronkainen, J. Warsta, Agile software development methods: Review and analysis, www.inf.vtt.fi/pdf/publications/2002/P478.pdf, 2002. [13] P. Abrahamsson, J. Warsta, M. Siponen, J. Ronkainen, New directions on Agile Methods: A Comparative Analysis, 25th International Conference on Software Engineering (ICSE'03) Proceedings of the 25th International Conference on Software Engineering, p244-254, 2003. [14] J. Stapleton, Dynamic systems development method – The method in practice, AddisonWesley Professional; 1e druk, ISBN 0201178893, 1997. [15] K. Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, 1999. [16] S. Murugesan, A. Ginige, Web engineering Introduction, IEEE Multimedia, vol. 8 no. 1, p1418, 2001. [17] A. Ginige, S. Murugesan, Guest Editors' Introduction: The Essence of Web Engineering— Managing the Diversity and Complexity of Web Application Development, IEEE Multimedia, p2225, 2001. [18] J. Nandhakumar, J. Avison, The fiction of methodological development: a field study of information systems development, Information Technology & People, vol. 12, p176-191, 1999. 58

Literatuurlijst

[19] M. N. Aydin and F. Harmsen, Making a method work for a project situation in the context of CMM, Product Focused Software Process Improvement (Profes 2002), 2002. [20] L. Williams, R. Kessler, W. Cunningham, R. Jeffries, Strenghtening the Case for Pair Programming, IEEE Software, vol. 17 no. 4, p19-25, 2000. [21] F. Padberg, M. Müller, Analyzing the Cost and Benefit of Pair Programming, Proceedings of the Ninth International Software Metrics Symposium (METRICS’03), IEEE, p166, 2003. [22] C. Vriens, Certifying for CMM Level 2 and ISO9001 with XP@Scrum, Proceedings of the Agile Development Conference (ADC’03), p120-124, 2003. [23] Object Mentor, Inc. and Advanced Development Methods, Primavera success http://www.controlchaos.com/download/Primavera%20White%20Paper.pdf, 2004

story,

[24] S. Lee, K. Kim, Factors affecting the implementation success of Internet-based information systems, Computers in Human Behavior, In press corrected proof, http:// www.sciencedirect.com. [25] K. Spaink, Medische geheimen, Nijgh & Van Ditmar, 2005. [26] Nederlands Normalisatie-instituut (NEN), NEN Informatiebeveiliging in de zorg - Algemeen, NEN, 2004.

7510

Medische

informatica

-

[27] F. Hentenaar, Patiënten over informatie in medische informatie overdracht: een verkennend onderzoek, http://www.npcf.nl (TNS NIPO), 2003. .

59

Bijlagen

Bijlagen Bijlage A: Procedure Development Task aanmaken Bijlage B: Vragen interview pilot-apotheken Bijlage C: Procedure domeinnaam aanvragen Bijlage D: Procedure pop account aanmaken Bijlage E: Procedure onderhouden van de website Bijlage F: Procedure planning categorie toewijzen

61

Bijlagen

Bijlage A Procedure Development Task aanmaken

62

Bijlagen

Bijlage B Vragen interview pilot-apotheken Interface Vindt u dat de applicatie er mooi/aantrekkelijk uitziet? Vindt u dat de applicatie gebruiksvriendelijk is? Heeft de applicatie een logische plaats op de website/Is het vindbaar? Ondersteuning Heeft u een handleiding ontvangen? Is er een training/uitleg geweest? o Zo ja, in welke vorm? o Was dit voldoende? Is er altijd een heldesk/troubleshooter beschikbaar? Gebruik Is de applicatie makkelijk in gebruik/Is het duidelijk wat je moet doen? Zijn de uit te voeren handelingen goed te doen? Vindt u dat er genoeg rekening is gehouden/Past het in de werkwijze? Zijn de aangeboden opties voldoende? Verwerking Heeft u last van aanvragen waar u niks mee kunt of verkeerd ingevulde aanvragen? o Zo ja, wordt alle benodigde informatie in de applicatie gevraagd? o Worden alle velden ingevuld? Staan de HR aanvragen altijd op tijd klaar? Wat vindt u van de inhoud van de HR berichten die worden verstuurd per e-mail? Extra

Hoe zijn de patiënten geïnformeerd over het gebruik van HR? Waarom heeft u gekozen om HR als service aan te bieden?

63

Bijlagen

Bijlage C Procedure domeinnaam aanvragen

64

Bijlagen

Bijlage D Procedure pop account aanmaken

65

Bijlagen

Bijlage E Procedure onderhouden van de website

66

Bijlagen

Bijlage F Procedure Planning categorie toewijzen

67

Kwaliteitswaarborging in het software ontwikkelproces: meegroeien van de methodologie

Recommend Documents