Ontwikkelmethodiek voor software

Transcriptie

1 voor software Sonja Rouwhorst Instituut voor interactieve media Hogeschool van Amsterdam Datum: 28 januari 2008 Versie: 1 Status: definitief

2 Inhoudsopgave Inleiding... 3 Het proces van software ontwikkelen... 3 Wat is ontwikkelmethodiek?... 3 Methode is als een vangnet... 4 In de tijd... 4 CASE-tools... 4 Sequentieel versus Iteratief... 5 Agile... 6 Waterfall... 8 Ontstaansgeschiedenis... 8 Uitgangspunten... 8 Stappenplan... 8 (R)UP... 9 Ontstaansgeschiedenis... 9 Uitgangspunten... 9 Stappenplan Tools Technieken DSDM Ontstaansgeschiedenis Uitgangspunten Stappenplan Tools Technieken XP Ontstaansgeschiedenis Uitgangspunten Stappenplan Tools Technieken van 15

3 Inleiding Onze dagelijkse wereld is vol apparaten die gebruik maken van software die ooit ontwikkeld is, zoals de programma's die op je computer draaien, het internet staat vol met applicaties en games, je mobiele telefoon gebruikt software. Zelfs huishoudelijke apparatuur bevat steeds meer software. Met de uitvinding van de microprocessor in de jaren '70 werd de computer toegankelijk voor alle bedrijven en consumenten. De afgelopen 30 jaar is daarmee een nieuw vakgebied ontstaan dat zich bezig houdt met software ontwikkeling. Het proces van software ontwikkelen Wanneer je software ontwikkelt doorloop je altijd een aantal stappen. Het is onverstandig gelijk te beginnen met de realisatie. Je gaat eerst na hoeveel tijd je hebt voordat de software af moet zijn, je kijkt naar budget, je onderzoekt de wensen van toekomstige gebruikers en beheerders, wat randvoorwaarden zijn, wat voor kwaliteit er gewenst is en zo meer. De resultaten van deze analyse gebruik je voor het ontwerp van de software. Bij het ontwerp kun je onderscheid maken in technisch ontwerp, functioneel ontwerp, interface ontwerp en grafisch ontwerp. Het ontwerp wordt gebruikt voor de realisatie van de software, maar dan ben je nog niet klaar. Voordat een applicatie echt gebruikt kan worden, zul je nog eens goed testen of alle fouten eruit zijn en of het aan de kwaliteitscriteria voldoet. Parallel aan dit hele proces is er projectmanagement en documentatie nodig om het project soepel te laten verlopen. Wat is ontwikkelmethodiek? De afgelopen dertig jaar zijn er ontzettend veel softwareprogramma's ontwikkeld. Mensen hebben de neiging om routines te ontwikkelen wanneer ze iets herhaaldelijk doen. De routines of methodes kunnen overgedragen worden aan anderen. Waarschijnlijk heb je zo ooit van je ouders geleerd hoe je je band moet plakken van je fiets. Zonder die uitleg was het waarschijnlijk uiteindelijk ook wel gelukt om een lekke band te plakken, maar een stuk minder snel. Een methode bestaat vaak uit: 1. Uitgangspunten: Voor welke situatie is de methode geschikt. Als je de methode weet om een fietsband te plakken, kun je die dan ook gebruiken bij de band van een rolstoel, of bij een autoband? 2. Stappenplan: Eerst zet je de fiets op zijn kop en gebruik je de bandenlichters om de binnenband los te halen. Vervolgens pomp je de binnenband op en ga je op zoek naar het gat. Enzovoort, enzovoort. 3. Tools: Bijvoorbeeld, om een band te plakken heb je bandenlichters, een fietspomp, lijm en dergelijke nodig. 4. Technieken: Bijvoorbeeld, wanneer het gat moeilijk te vinden is, kun je een emmer water gebruiken om het te vinden. 3 van 15

4 Methode is als een vangnet Methodes zijn niet heilig! Soms hebben mensen de neiging om de methode voorop te stellen in plaats van het eindresultaat. Denk aan de bureaucratie die in veel grote organisaties bestaat. Wanneer procedures en papierwerk het doel in plaats van het middel worden, werkt een methode averechts. Een methode kun je zien als een vangnet. Je loopt over een wiebelend touw en je doel is om de overkant te bereiken. Je moet zelf de concentratie opbrengen en de stappen zetten om aan de overkant te komen, maar het vangnet zorgt ervoor dat je je zeker genoeg voelt om dit ook daadwerkelijk te doen. De voordelen van methoden zijn: Overdraagbaar: Een methode ontstaat uit ervaring en kan worden overgedragen aan mensen met minder ervaring. Zo hoef je niet steeds opnieuw 'het wiel uit te vinden'. Opdeling in behapbare stukken: Bij een complexe taak, zorgt een stappenplan voor een opdeling in stukken die minder complex zijn. Zonder een stappenplan heb je wellicht geen idee waar je moet beginnen. Checklist: Een methode kan gebruikt worden als checklist om na te gaan of je aan alles hebt gedacht. In de tijd De eerste methode waarmee werd gewerkt en waar nog steeds veel mee wordt gewerkt, is de Waterfall methode. Het stappenplan dat bij deze methode hoort, heeft de vorm van een waterval. In de tijdbalk hierboven zie je het ontstaan van een aantal van de belangrijkste ontwikkelmethodieken. In de rest van dit document zal dieper ingegaan worden op een aantal van deze methoden. Naast de methoden uit dit plaatje zijn er nog veel meer andere methoden. In de volgende paragrafen wordt toegelicht waarom juist deze methoden een belangrijke invloed hebben gehad op de manier waarop software werd ontwikkeld. CASE-tools De jaren tachtig zijn de eerste periode waarin op grote schaal software gemaakt moest worden. In die tijd was vrijwel elk bedrijf bezig met automatiseren. Tot dan toe werd alles op papier gezet, maar nu werden overal computers geïntroduceerd die het papier moesten vervangen. Je moet je voorstellen dat ontwikkelaars tot die tijd in kladblok-achtige omgevingen werkten. Het werk van programmeurs zou makkelijker gemaakt kunnen worden met tools specifiek voor de programmeur. Dit werden CASEtools genoemd, wat staat voor Computer Aided Software Engineering. CASE-tools zijn software programma's die helpen bij het maken van software. Het ideaal was dat deze CASE-tools op termijn zo goed zouden zijn, dat er geen programmeertaal meer gebruikt hoefde te worden. Zoals je weet zijn er inmiddels programma's als Dreamweaver en Eclipse die dit deels kunnen. 4 van 15

5 Een methode die gebaseerd is op het gebruik van CASE-tools is RUP. RUP staat voor Rational Unified Process. Rational was een bedrijf dat CASE-tools ontwikkelde. De tools werden eerst gebruikt om de software te ontwerpen. Om dit mogelijk te maken werd een visuele ontwerptaal bedacht, UML, ofwel Unified Modeling Language. Vervolgens kon een deel van de programmacode automatisch gegenereerd worden op basis van dit ontwerp. Sinds die tijd wordt het nut van CASE-tools door vrijwel alle methoden onderschreven. Sequentieel versus Iteratief De werkwijze van bedrijven is in de jaren tachtig en negentig ontzettend veranderd door de automatiseringsslag die er toen gemaakt werd. De projecten waren groot en complex en hadden invloed op vrijwel iedereen die in het bedrijf werkte. Handwerk werd geautomatiseerd waardoor sommige functies verdwenen. Daarnaast ontstonden er juist weer nieuwe functies omdat de computersystemen zelf onderhouden moesten worden. De complexiteit van deze projecten zorgde ervoor dat een goede analyse essentieel was om goede software te maken. Bedrijfsprocessen werden in kaart gebracht en de invloed van het nieuw te bouwen systeem op deze bedrijfsprocessen moest in kaart gebracht worden. Doordat bedrijven zich vrijwel continu in een veranderingsituatie bevonden, kwam er aan de analysefase eigenlijk geen eind. Wat meestal gebeurde was dat de analyse dan toch maar gestopt werd en men ging over op het ontwerpen, realiseren en testen van de complexe software. Tegen de tijd dat de software in gebruik werd genomen, was het eigenlijk al weer achterhaald. Wanneer je zelf een stappenplan voor iets bedenkt, is het simpelste om sequentieel te denken. Eerst doe je dit, als dat klaar is doe je stap 2 gevolgd door stap 3 enzovoort. Het waterfall model was zo'n sequentiële methode. Maar zoals je in de vorige paragraaf hebt gelezen, werkt dit in de praktijk vaak niet. De wereld verandert continu en voordat je klaar bent, loop je al weer achter. 5 van 15

6 In 1988 schreef Barry Boehm een artikel met een model waarin software iteratief ontwikkeld werd. Iteratief betekent herhalend en zoals je in het plaatje hierboven ziet, worden dezelfde stappen herhaaldelijk doorlopen. Elke ronde resulteert in een prototype wat uiteindelijk leidt tot een werkend product. Elke iteratie zou 6 maanden tot 2 jaar duren en begint met het formuleren van een ontwerpdoel en eindigt ermee dat de opdrachtgever de voortgang controleert. De methoden die sinds die tijd zijn bedacht hebben allemaal een iteratief karakter. Het eerste prototype dat ontwikkeld wordt geeft vaak alleen de grote lijnen aan. Vervolgens wordt het prototype langzaam uitgebreid tot een compleet eindproduct. In elke iteratie wordt een klein deel geanalyseerd, ontworpen, gerealiseerd en getest. Zo wordt het mogelijk om te gaan met een wereld die continu in verandering is. Agile Hoewel men op gegeven moment een redelijke manier had gevonden om om te kunnen gaan met continue veranderingen, bleven softwareprojecten erg complex. Het maken van goede planningen en kostenramingen bleek vrijwel onmogelijk. Men ging steeds meer vastleggen in documenten, omdat dat een gevoel van zekerheid geeft. De behoefte aan zekerheid zorgde voor een bureaucratie aan papier en uiteindelijk werd het er met alle documentatie niet overzichtelijker op. Besluitenlijsten, lijsten met aanpassingen, ontwerpdocumenten met status concept, of definitief, of toch weer niet definitief. Tegen de tijd dat getest moest worden, was niet meer duidelijk wat er nu eigenlijk afgesproken was. Ondertussen was er een nieuwe markt in opkomst. Sinds begin jaren negentig kregen steeds meer mensen een computer thuis. Internet was in opkomst en ook mobiele telefonie zorgt onderhand voor behoefte aan nieuwe software. Over het algemeen ging het hier om software die lang niet zo omvangrijk was als de software die door bedrijven wordt gebruikt. Gebruiksvriendelijkheid werd veel 6 van 15

7 belangrijker. Ook bedrijven zagen in dat het trainen van personeel erg kostbaar was en dat een gebruiksvriendelijk product deze kosten kon drukken. Sinds midden jaren negentig wordt de roep om Agile, ofwel lichtgewicht, methoden steeds groter. Methoden die flexibel zijn, waar documentatie minder de nadruk heeft en waar het draait om het maken van software die gebruiksvriendelijk is. Uiteindelijk heeft een groep ontwikkelaars in 2001 hierover een manifest geschreven, welke je kunt vinden op In dit manifest staan 12 principes die de ontwikkelaars hoog houden. De inleiding is als volgt: Manifesto for Agile Software Development 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. Methoden als DSDM en XP vallen in de categorie van Agile methoden. 7 van 15

8 Waterfall Ontstaansgeschiedenis Het Waterfall model is in 1970 beschreven door Winston W. Royce en was door hem beschreven als een concept model in een sequentiële vorm. Vreemd genoeg gaf hij zelf daarbij aan dat het model verder ontwikkeld zou moeten worden naar een iteratief model. Zijn sequentiële model is echter door veel mensen overgenomen en in de praktijk toegepast. Uitgangspunten Het Waterfall model gaat uit van het principe dat wanneer de tijd genomen wordt voor een goede analyse en een goed ontwerp, dit uiteindelijk kostenbesparend werkt. Wanneer in een latere fase van het project fouten of onmogelijkheden worden ontdekt, is het veel duurder om te repareren. Het Waterfall model is een simpel model dat makkelijk is uit te leggen en te volgen. Het is geschikt voor projecten waarbij ingeschat wordt dat de analyse en de het ontwerp volledig gedaan kunnen worden en waarbij de omgeving redelijk stabiel is. Stappenplan Het model bestaat uit vijf stappen: 1. Requirements: Analyseren aan welke eisen en randvoorwaarden de software moet voldoen 2. Design: Ontwerpen van de software 3. Implementation: Bouwen of realiseren van de software 4. Verification: Testen van de software 5. Maintenance: Onderhoud van de software 8 van 15

9 (R)UP Ontstaansgeschiedenis Rational Unified Process is een iteratieve ontwikkelmethode gebaseerd op het Spiral model van Boehm. De methode is in de jaren tachtig en negentig ontwikkeld door het bedrijf Rational, dat later werd overgenomen door IBM. De Unified Process is een raamwerk voor een ontwikkelproces, waarbij elke organisatie voor zichzelf het raamwerk moet aanpassen en verfijnen. Uitgangspunten RUP is bedoeld voor de ontwikkeling van software voor bedrijven en organisaties waar de kwaliteit van het eindproduct essentieel is. De bedrijfsprocessen van zo'n organisatie staan centraal. RUP is gebaseerd op zes principes: 1. Adapt the process de unified process is een raamwerk wat nog aangepast en verfijnd moet worden. 2. Balance stakeholder priorities belanghebbenden kunnen tegenstrijdige belangen hebben, daarom is het van belang om de prioriteiten van die belangen te bepalen. 3. Collaborate across teams om misverstanden te voorkomen moeten teams zoveel mogelijk samenwerken. 4. Demonstrate value iteratively zorg voor regelmatige levering van prototypes zodat de belanghebbenden de toegevoegde waarde kunnen zien 5. Elevate the level of abstraction hergebruik bestaande systemen en werk onder architectuur 6. Focus continuously on quality zorg dat iedereen op de hoogte is van kwaliteitscriteria en begin vroeg met testen 9 van 15

10 Stappenplan Het bovenstaande plaatje toont een voorbeeld van een typisch RUP proces. Bovenaan zie je vier fases staan: inceptie, elaboratie, constructie en transitie. Binnen elke fase worden een of meerdere iteraties uitgevoerd die leiden tot de prototypes die onderaan zijn vermeld. Elke iteratie bestaat uit zes stappen: bedrijfsmodellering, eisen en randvoorwaarden vaststellen, analyse en ontwerp, implementatie / bouw, testen en uitrollen. Inceptie Tijdens de inceptie ligt de nadruk op bedrijfsmodellering en het vaststellen van eisen en randvoorwaarden. Het resultaat van deze fase is een prototype waaruit af te leiden moet zijn of het uiteindelijke product haalbaar is en toegevoegde waarde heeft. Elaboratie In deze fase ligt de nadruk op analyse en ontwerp. In deze fase wordt de architectuur van de software bepaald, wordt de functionaliteit voor 80% vastgelegd en worden risico's voor de rest van het project in kaart gebracht. Constructie De realisatie van de software gebeurt iteratief tijdens de bouwfase. Nog steeds zal nog enige bedrijfsmodellering nodig zijn en het ontwerp zal nog verder uitgewerkt worden. Ook worden de gerealiseerde prototypes uitgebreid getest. Transitie Wanneer de software gerealiseerd is, zal het product in gebruik genomen worden. Gebruikers worden opgeleid, gegevens moeten uit oude systemen overgezet worden en de laatste testen vinden plaats. Tools RUP is een methode die ontwikkeld is door het bedrijf Rational dat tools maakt voor softwareontwikkelaars. Inmiddels is Rational overgenomen door IBM, waardoor de verzameling tools alleen maar groter is geworden. Het bedrijf biedt zowel commerciële als open-source tools voor softwareontwikkeling en projectmanagement. 10 van 15

11 Technieken RUP en UML zijn nauw met elkaar verbonden, maar kunnen beiden afzonderlijk worden gebruikt. UML staat voor Unified Modelling Language en is een visuele taal voor het ontwerpen van software. UML kan gebruikt worden voor het modelleren van bedrijfsprocessen, interactie, code, gegevensstromen en meer. 11 van 15

12 DSDM Ontstaansgeschiedenis DSDM is een iteratieve en agile ontwikkelmethode gebaseerd op Rapid Application Development (RAD) en werd halverwege de jaren negentig uitgebracht. De overeenkomst met RUP is dat een raamwerk is en niet een methode die kant-en-klaar toegepast kan worden. Het raamwerk is een verzameling best-practices waaruit gekozen kan worden. Anders dan RUP, is DSDM niet door een specifiek bedrijf bedacht, maar door en non-profit organisatie genaamd het DSDM consortium. Het belangrijkste uitgangspunt bij DSDM is dat een product op tijd en binnen budget opgeleverd moet worden. Bij DSDM ligt de focus op projectmanagement. Daarom kan deze methode ook gecombineerd worden met XP en RUP. Uitgangspunten Bovenstaande figuur toont het verschil tussen traditionele methoden als Waterfall en DSDM. In traditionele methoden wordt zo snel mogelijk vastgezet welke functionaliteit gemaakt gaat worden. De hoeveelheid tijd en geld die hiervoor nodig zijn, hangt af van hoeveel functionaliteit nodig is. Bij DSDM is de driehoek omgedraaid. Als eerste wordt de hoeveelheid tijd en geld vastgezet. Vervolgens wordt binnen die tijd en binnen het budget zoveel mogelijk functionaliteit gerealiseerd. DSDM hanteert negen uitgangspunten: 1. Actieve betrokkenheid van de gebruiker 2. Beslissingsbevoegdheid van het team 3. Regelmatige levering van producten 4. Geschiktheid voor het bedrijfsdoel 5. Incrementele/ iteratieve ontwikkeling 6. Veranderingen zijn omkeerbaar 7. Vereisten worden op hoog niveau bevroren 8. Testen gebeurt tijdens de gehele levenscyclus 9. Medewerking en samenwerking is noodzaak 12 van 15

13 Stappenplan Het DSDM-proces bestaat uit vijf fases: 1. Feasibility Study In deze fase wordt gekeken of DSDM een geschikte methode is voor de situatie. 2. Business Study In deze fase wordt de projectorganisatie opgericht, er wordt een planning op grote lijnen gemaakt, er vindt een risicoinventarisatie plaats, de architectuur voor de software wordt bepaald en een lijst met eisen en randvoorwaarden op hoog niveau wordt vastgesteld. 3. Functional Model Iteration Deze fase kan uit één of meerdere iteraties bestaan afhankelijk van de complexiteit van het project. In deze fase wordt gewerkt aan functionele prototypes die bedoeld zijn om de gewenste functionaliteit duidelijk te krijgen. 4. Design and Build Iteration Tijdens deze fase wordt de software in één of meerder iteraties ontworpen en gebouwd. 5. Implementation De term implementatie is verwarrend, omdat hiermee vaak het 'programmeerwerk' wordt bedoeld. In dit geval gaat het om het in gebruik nemen van de software. Tools DSDM is een methode die toolonafhankelijk is. Dat betekent niet dat er geen tools worden gebruikt, maar dat het met alle mogelijke tools te combineren is. Technieken De techniek die het meest geassocieerd wordt met DSDM is timeboxen in combinatie met MoSCoW. Bij de start van een iteratie zijn tijd en budget vastgelegd, dit wordt een timebox genoemd. De volgende stap is om de gewenste functionaliteit in kaart te brengen en de prioriteiten daarvan vast te leggen. MoSCoW is een manier om deze prioriteiten aan te geven. MoSCoW is een acronym voor Must-have, Should-have, Could-have en Won't-have-this-time. Binnen een timebox wordt gezorgd dat de functionaliteiten met de hoogste prioriteit als eerste gemaakt worden, dit zijn de Must-haves. Als er tijd over is wordt er gewerkt aan de Should-haves enzovoort. 13 van 15

14 XP Ontstaansgeschiedenis XP staat voor extreme Programming en is een methode die ontwikkeld wordt sinds eind jaren negentig. XP is een agile methode die als uitgangspunt heeft dat eisen en uitgangspunten continu veranderen. Het is een poging om een methode te ontwikkelen die met deze continue veranderingen om kan gaan. Uitgangspunten Binnen XP worden een aantal waarden centraal gesteld. Communicatie Om duidelijk te krijgen aan welke eisen en randvoorwaarden de software moet voldoen is het noodzakelijk dat de ontwikkelaars met de toekomstige gebruikers praten. Binnen XP wordt documentatie echter zoveel mogelijk vermeden. Er wordt de voorkeur gegeven aan simpele ontwerpen, directe betrokkenheid van gebruikers en face-to-face communicatie. Eenvoud Ontwikkelaars starten met het realiseren van eenvoudige oplossingen die op een later moment mogelijk uitgebreid kunnen worden. Feedback Onder feedback worden verschillende dingen verstaan: o Feedback van het systeem Elk onderdeeltje van de software wordt getest zodra deze gerealiseerd is o Feedback van de gebruiker De gebruiker wordt betrokken bij de ontwikkeling en bij het uitvoeren van acceptatie testen o Feedback van het team Ontwikkelaars geven direct een schatting van de kosten en de ontwikkeltijd zodra een gebruiker een wijziging aangeeft. Moed In de loop van een project kan het beter zijn als een stuk code herschreven wordt of misschien wel weggegooid wordt omdat het overbodig is geworden. Ook is soms doorzettingsvermogen nodig bij complexe opdrachten. Respect Teamleden moeten streven naar hoge kwaliteit en krijgen zo het respect van andere teamleden. Niemand moet ongewaardeerd of genegeerd worden, zodat teamleden gemotiveerd en loyaal blijven. Stappenplan Binnen XP worden vier activiteiten onderscheiden 1. Coderen Binnen XP wordt vrijwel direct begonnen met werkende prototypes maken. Bij het programmeren worden onduidelijkheden ontdekt, moeilijkheden overkomen en de prototypes kunnen gebruikt worden voor communicatie met gebruikers. De code zal in de loop van het project mogelijk vele malen herschreven moeten worden. 2. Testen Binnen XP worden twee soorten testen onderscheiden: a. Unit testen, om te controleren of de software doet wat het ontwikkelteam wil. b. Acceptatie testen, om te controleren of de software voldoet aan de eisen en wensen van de gebruiker. 3. Luisteren Een ontwikkelaar moet luisteren naar de opdrachtgever en gebruikers om erachter te komen wat gewenst is en wat mogelijke problemen zijn. 4. Ontwerpen Binnen XP is ontwerpen een stap die niet per definitie noodzakelijk is. Voor complexe situaties kan ontwerpen nodig zijn, maar deze stap wordt overgeslagen voor zover mogelijk. 14 van 15

15 Tools Doordat testen zo'n grote rol speelt in XP, wordt er veel gebruik gemaakt van testtools. Voordat een ontwikkelaar iets gaat programmeren, schrijft hij eerst de condities waar de code op getest zal worden. Technieken Bij XP werken programmeurs in tweetallen tegelijkertijd aan dezelfde code op dezelfde computer. Degene die typt denkt vooral na over details, terwijl degene die meekijkt vooral de grote lijnen in de gaten houdt. De tweetallen veranderen continu, zodat iedereen in het team goed op de hoogte blijft van de rest aan het doen is. 15 van 15