Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V

Unified Process Een introductie

Algemene informatie voor medewerkers van SYSQA B.V.

Organisatie Titel Onderwerp

SYSQA B.V. Unified Process Een introductie

Pagina Versie Datum

2 van 10 1.1 12-4-2011

Inhoudsopgave 1.

Inleiding ............................................................................................................ 3

2.

Unified Process ................................................................................................ 4

3.

Fasering ............................................................................................................ 5 3.1. 3.2. 3.3. 3.4.

4.

Inception ............................................................................................................ 5 Elaboration ......................................................................................................... 5 Construction ....................................................................................................... 5 Transition ........................................................................................................... 6

Kenmerken........................................................................................................ 7 4.1. 4.2. 4.3.

Unified Process best practices ........................................................................... 7 Use-cases .......................................................................................................... 8 Basisveronderstellingen ..................................................................................... 8

5.

Unified Process en andere methodes ............................................................ 9

6.

Literatuurverwijzingen ................................................................................... 10

Almere © 2004

Quality Assurance in ICT



Pagina Versie Datum

3 van 10 1.1 12-4-2011

1. Inleiding De traditionele systeemontwikkelmethodes zoals SDM I, SDM II en LAD hebben, zo blijkt in de praktijk, een aantal nadelen. Zo wordt de fasering als rigide ervaren, is de doorlooptijd vaak langer dan gewenst, zijn de kosten hoog en is de gebruikersparticipatie te laag. Ook worden riskante activiteiten, zoals de integratie van modules en een load test, pas in een laat stadium uitgevoerd. Als gevolg hiervan zijn er aan het einde van de 20e eeuw een aantal systeemontwikkelmethodes ontstaan die tegemoetkomen aan deze tekortkomingen. De methodes worden gekenmerkt door een hoge gebruikersparticipatie en het iteratief ontwikkelen. Met dit laatste wordt bedoeld dat er meerdere ontwikkelrondes na elkaar plaatsvinden. In plaats van ernaar te streven in één keer het systeem te bouwen worden meerdere versies gemaakt en steeds verbeterd en verfijnd. Deze methodes staan bekend als Iterative and Incremental Development (IID). Verwant aan IID zijn de zogenaamde „agile‟ methodes, waarbij „agile‟ staat voor „snel en flexibel reagerend op veranderingen‟. Deze agile methodes zijn behalve iteratief ook gebaseerd op evolutionaire ontwikkelmethodes. Daarnaast speelt flexibiliteit een grote rol, het vermogen om het systeem tijdens de ontwikkeling snel aan te passen aan veranderende eisen. Agile ontwikkelmethodes zijn dus iteratief, evolutionair en flexibel. Unified Process is een agile systeemontwikkelmethode.

Almere © 2004




Pagina Versie Datum

4 van 10 1.1 12-4-2011

2. Unified Process Het Unified Process (UP) is een populaire iteratieve ontwikkelmethode, met name het hieruit voorkomende RUP (Rational Unified Process) wordt vaak gebruikt. De basis van Unified Process is samen te vatten aan de hand van een aantal belangrijke werkwijzen en richtlijnen: Ontwikkel binnen kortlopende iteraties; Ontwikkel de onderdelen met een groot risico en onderdelen welke van groot belang zijn (bijvoorbeeld de basisarchitectuur) in vroege iteraties, bij voorkeur gebruik makend van bestaande componenten; Stel vast dat je kwaliteit levert aan de klant; Voer veranderingen vroeg in het project door; Werk samen als één team Misschien de belangrijkste kwaliteit van UP, in vergelijking met andere populaire IID methoden, is haar vermogen om meer of minder formaliteiten in het proces in te bouwen, met optionele ondersteuning voor hogere formaliteit en documentatie. In tegenstelling tot wat vaak gedacht wordt, moedigt UP aan tot een relatieve lage mate van formaliteit, alhoewel het meer documentatie en modellering aanbeveelt als bij bijvoorbeeld XP het geval is. UP biedt een set van ongeveer 50 optionele werkproducten. Unified Process werkt met iteraties die onderverdeeld zijn in vier fases, zie hoofdstuk 3. UP kan bij zowel kleine, als grotere projecten worden toegepast. UP moet wel altijd worden aangepast aan de organisatie of het project in de vorm van gedetailleerde procesomschrijving. Het op maat maken van de gebruikte processen wordt de development case van het project genoemd. Hierbij wordt gekozen welke best practices en UP werkproducten gebruikt worden. Daarbij wordt over het algemeen uitgegaan van het principe “hoe minder hoe beter”. Aangeraden wordt om alleen de minimaal benodigde werkproducten, om de risico‟s en doelen van het project aan te kunnen pakken, op te nemen in de development case.

Almere © 2004




Pagina Versie Datum

5 van 10 1.1 12-4-2011

3. Fasering Het ontwikkelproces van UP is vanuit managementperspectief onderverdeeld in vier fases. Iedere fase is een essentieel onderdeel voor het project. De fases zijn: Inception (opstartfase); Elaboration (uitwerkingsfase); Construction (bouwfase); Transition (overdrachtsfase).

3.1. Inception Het doel van de Inception fase is het bereiken van overeenstemming tussen de stakeholders over de doelstellingen van het project. Idealiter beslaat de inception fase een korte periode (bijvoorbeeld een paar dagen) in het ontwikkelproces. Iteraties zijn mogelijk maar zeldzaam. Doelen: Doelstellingen, business case, visie en scope definiëren en vaststellen; 10% van de belangrijke requirements tot in detail specificeren; Belangrijkste risico‟s definiëren; Inschatting maken van de werkzaamheden voor de elaboration fase. Mogelijke activiteiten Uitvoeren requirements workshop; Opstellen visiedocument; Opstellen Start Use-case model en aanvullende specificaties; Prototyping.

3.2. Elaboration In de Elabortion fase worden de architecturaal belangrijke onderdelen, geprogrammeerd en getest in een serie van korte iteraties. Op het eind van deze fase kan een redelijk betrouwbaar plan en inschatting worden gemaakt van het project. Die vormen een stabiele basis tijdens het ontwerp en de ontwikkeling. Doelen: Architecturaal belangrijke onderdelen van systeem bouwen en testen; Belangrijke risico‟s geïdentificeerd en gereduceerd; 80% van de belangrijkste requirements tot in detail specificeren; Het bereiken van voldoende stabiliteit en informatie om de doorlooptijd en benodigde inspanning voor het project te bepalen. Mogelijke activiteiten: Ontwerpen, programmeren en testen van de architecturaal belangrijkste onderdelen in korte iteraties; Uitvoeren Requirements workshop, scherper stellen visie; Verbeteringen aanbrengen in de omgeving (procesmatig en technisch).

3.3. Construction Het doel van de Constuction fase is het verder uitwerken van de requirements en het ontwikkelen van het systeem op basis van de architectuur. In deze fase wordt de rest van het systeem gebouwd in korte iteraties, op basis van de in de elaboration fase gebouwde architectuur. Almere © 2004




Pagina Versie Datum

6 van 10 1.1 12-4-2011

Doelen: Systeem compleet ontwerpen, programmeren en testen zodat het klaar is voor de uitrol; Efficiënte en voorspelbare ontwikkeling, bouwend op de stabiele architectuur welke in Elaboration fase is ontwikkeld. Mogelijke activiteiten: Ontwerpen, programmeren en testen van het systeem in korte iteraties; Stakeholder evaluatie en bijsturing; idealiter is er alleen sprake van minimale veranderingen in de requirements; Opstellen alle documenten; Alfa-testen.

3.4. Transition Doelstelling van de Tranisition fase is het ter beschikking stellen van de software aan de eindgebruikers. Aan het eind van deze fase dienen de doelstellingen van het project gehaald te zijn en kan het project worden beëindigd. Deze fase eindigt met de uiteindelijk uitrol (mogelijk in meerdere iteraties) van het systeem in productie. Doel: Bevestigen dat het systeem klaar is voor uitrol; Uitrollen van het systeem. Mogelijke activiteiten: Beta-testen en het krijgen van feedback; Verwerken van bevindingen en aanpassen van de documentatie; Verzorgen van opleiding en marketing; Uitrol van het systeem.

Almere © 2004




Pagina Versie Datum

7 van 10 1.1 12-4-2011

4. Kenmerken Om een project een UP project te kunnen noemen moet het tenminste voldoen aan de volgende kenmerken: Het project volgt de UP richtlijnen en best practices; Er wordt minimaal gebruik gemaakt van minimaal een aantal van de UP middelen zoals het visiedocument en risicolijst. De iteraties en mijlpalen zijn georganiseerd volgens de UP fasering, te weten Inception, Elaboration, Construction en Transition. Alhoewel de originele UP ontwikkelaars een voorkeur hadden voor een relatief lichte inrichting van het proces, werd dit niet goed gecommuniceerd in hun eerste lesmateriaal. In de meer recentelijk uitgebrachte versies is dit verbeterd.

4.1. Unified Process best practices UP is feitelijk niet beperkt tot de onderstaande zes best practices, maar onderstaande zes zijn belangrijk om minimaal toe te passen. Gebruikers van Unified Process moeten deze werkwijzen begrijpen en toegepassen in elk UP project. 1. Werk iteratief De belangrijkste van de “UP best practices” is het gebruik maken van iteraties met een (vooraf) vastgestelde duur. Periodes van twee tot zes weken wordt aangeraden. Met andere woorden, begin vroeg met programmeren, als slechts een deel van de meest belangrijke requirements tot in detail bekend zijn. Verbeter de requirements en het ontwerp op basis van feedback, in plaats van te proberen alle requirements van te voren te analyseren. 2. Realiseer de belangrijkste onderdelen eerst Leg de nadruk bij het programmeren op de onderdelen die van groot belang zijn en/of een groot risico met zich meebrengen en programmeer een samenhangende architectuur in vroege iteraties. Streef er hierbij naar om bestaande componenten (zowel grote als kleine) te hergebruiken om het creëren van nieuwe code en de kans op fouten te reduceren. Voor grote projecten worden de requirements analyses en de kernarchitectuur idealiter ontwikkeld door een samengesteld klein team, later wordt dit team opgesplitst en worden de teamleden, subprojectleiders die leiding geven aan subteams welke parallel werken. 3. Controleer voortdurende de kwaliteit. Test vroeg, vaak en realistisch door alle software geïntegreerd te testen tijdens elke iteratie. Deze “best practice” houdt in dat er gebruik wordt gemaakt van technieken zoals test-driven developement en continue integratie. Bovendien gaat het verder dan alleen het testen van de code, aangezien vroeg in het traject de bruikbaarheid van de software wordt getest. Bovendien wordt het ontwikkelproces zelf via regelmatige team vergaderingen onder de loep genomen om vast te stellen wat de toegevoegde waarde is van verschillende activiteiten. 4. Ontwerp software voordat deze gerealiseerd wordt. Maak, voordat er binnen een iteratie daadwerkelijk wordt begonnen met programmeren, in ieder geval een visueel model. Maak bijvoorbeeld gebruik van schetsen op een whiteboard om verschillende ontwerpideeën te bespreken, zonder in te gaan op gedetailleerde ontwikkelmethodes. 5. Verbeter continu de requirements Verbeter requirements door gebruik te maken van handige manieren om ze te vinden, vast te leggen en bij te houden. Vind en verbeter requirements iteratief en opbouwend, in plaats van via uitgebreide analyse vooraf, maak bijvoorbeeld gebruik van een serie (één per iteratie) Almere © 2004




Pagina Versie Datum

8 van 10 1.1 12-4-2011

van requirement workshops in de vroege fases van een project. Zoek waar van toepassing functionele requirements door het schrijven van use cases en leg deze vervolgens vast. Organiseer de requirements (gebruikmakend van beschikbare hulpmiddelen) aan de hand van attributen (zoals risico, prioriteit en status) en zorg ervoor dat afhankelijkheden makkelijk kunnen worden teruggevonden, zodat deze kunnen worden geanalyseerd. Hou vervolgens de status van requirements bij zodat bekend is wat klaar is, waar men mee bezig is enz. 6. Beheers configuraties. Leg veranderingen vast door strak configuratiemanagement, changemanagement en releasemanagement.

versiemanagement,

4.2. Use-cases Unified Process vereist geen gebruik van use cases voor het vastleggen van functionele reguirements. Lijsten met kenmerken en ontwikkeling op basis van vereiste kenmerken zijn mogelijk. Use cases worden echter wel aangemoedigd binnen UP, mits het gebruik van use cases geschikt is voor het probleem domein. In dat geval wordt binnen UP aangeraden om iteraties te organiseren rond scenario‟s van use cases, waarbij de scenario‟s die het meest risicovol zijn, architecturaal van groot belang zijn of van groot belang zijn voor de business vroeg in het project worden opgepakt. Het ontwerpen en implementeren gebeurt vervolgens op basis van wat nodig is om de use case scenario‟s te kunnen uitvoeren. Daarnaast raadt UP aan om de acceptatietesten op systeemniveau op deze use cases te baseren. Use cases vormen dan de basis voor de iteratieve ontwikkeling en acceptatietesten.

4.3. Basisveronderstellingen In tegenstelling tot XP en Scrum, heeft UP geen expliciete onderliggende basisveronderstellingen, deze kunnen echter wel worden afgeleid. Waar XP bijvoorbeeld de nadruk legt op menselijke en communicatieve kwaliteiten, legt UP de nadruk op een project georiënteerde (i.p.v. een mens georiënteerde) focus.

Almere © 2004




Pagina Versie Datum

9 van 10 1.1 12-4-2011

5. Unified Process en andere methodes Unified Process is een brede en algemene IID proces definitie. Het definieert en gebruikt vele gedetailleerde werkwijzen, zowel werkwijzen die onderdeel uitmaken van Unified Process als werkwijzen overgenomen van andere methodes, zoals XP testing of Scrum Meetings. Menig werkwijze zoals XP‟s testdriven development en continue controle op de kwaliteit, zijn feitelijk specialisaties of variaties op de UP werkwijzen. Voor softwareontwikkeling biedt UP een aantal voordelen ten opzichte van andere methodes: UP bevat een uitgebreide beschrijving van de verschillende stappen binnen een project, dit maakt het zeer geschikt voor onervaren ontwikkelaars; UP biedt een goed beschreven proces en voorspelbare stappen, wat help bij het sturen van de activiteiten, het onder controle houden van het project en het mogelijk maakt om meerdere keren van hetzelfde proces gebruik te maken; UP biedt verschillende werkproducten die al of niet door de ontwikkelaar kunnen worden ingezet om het proces te verbeteren; UP biedt een gemeenschappelijk taal voor alle betrokkenen. Unified Process kan eventueel gecombineerd worden met (elementen uit) andere agile ontwikkelmethodes zoals Evo, Scrum en XP. Wel is bijvoorbeeld de lengte van een iteratiestap bij UP (30 kalenderdagen) te lang voor Evo. Het vermijden van vooraf gedefinieerde processen en voorspelbare stappen bij Scrum kan strijdig zijn met de UPmethode, terwijl binnen XP de tijd besteed aan het modelleren bij UP (tot ½ dag) niet acceptabel is.

Almere © 2004




Pagina Versie Datum

10 van 10 1.1 12-4-2011

6. Literatuurverwijzingen Larman, C. 2004. „Agile and Iterative Development. A Manager‟s Guide‟. Addison-Wesley.

Almere © 2004


Unified Process. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V

Recommend Documents