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

Transcriptie

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

2 Organisatie SYSQA B.V. Pagina 2 van 14 Inhoudsopgave 1 INLEIDING ALGEMEEN VERSIEBEHEER OVERVIEW FASES INCEPTION ELABORATION CONSTRUCTION TRANSITION DISCIPLINES BUSINESS MODELING REQUIREMENTS ANALYSE EN ONTWERP (ANALYSIS AND DESIGN) ONTWIKKELING (IMPLEMENTATION) TESTEN IMPLEMENTATIE (DEPLOYMENT) CONFIGURATIE- EN CHANGEMANAGEMENT OMGEVING (ENVIRONMENT) PROJECTMANAGEMENT OVERIGE ASPECTEN VAN RUP ROLLEN LITERATUURVERWIJZINGEN... 14

3 Organisatie SYSQA B.V. Pagina 3 van 14 1 Inleiding 1.1 Algemeen Rational Unified Process (RUP) is een systeemontwikkelmethode die eind van de 20 e eeuw is ontwikkeld door het bedrijf Rational. Rational is een producent van ontwikkel- en testtools. Bij RUP wordt geïntegreerd gebruik gemaakt van tools. Toch is RUP een volwaardige systeemontwikkelmethode en niet (alleen) een verkoopkanaal voor de tools van Rational. In RUP is een aantal moderne inzichten verwerkt, zaken die bij andere wat oudere systeemontwikkelmethodes ontbreken. Zo wordt het ontwerpen vooraf gegaan door een volwaardige requirementsanalyse en wordt iteratief ontwikkeld. De gedetailleerde uitwerking van fases, activiteiten, rollen (taken, bevoegdheden en verantwoordelijkheden), mijlpaalproducten en geïntegreerde quality assurance maakt RUP een complete methode voor het ontwikkelen van een geautomatiseerd systeem. In deze introductie wordt in kort bestek uiteen gezet wat RUP is en wordt stil gestaan bij de verschillende onderdelen van RUP. Na het lezen van de introductie heeft u geen diepgaande kennis van RUP, het is een eerste kennismaking met RUP. Als u meer informatie wilt over RUP vindt u meer informatie in de literatuurverwijzingen aan het eind van deze introductie. 1.2 Versiebeheer Versie Status Datum Auteur Opmerkingen 0.1 Concept 16 januari 2002 SYSQA Eerste opzet 1.0 Definitief 18 februari 2002 SYSQA Verwerken opmerkingen van K. Straesser en mijzelf 1.1 Definitief 19 februari 2002 SYSQA Wijzigingen B. Dekkers 1.2 Definitief 12 april 2011 SYSQA Aanpassen aan de nieuwe huisstijl

4 Organisatie SYSQA B.V. Pagina 4 van 14 2 Overview De Rational Unified Process (RUP) is een systeemontwikkelingsmethode. Het verschaft een gestructureerde methode voor het toewijzen van verantwoordelijkheden in een ontwikkelingsorganisatie. Het doel van RUP is het zekerstellen van het maken van software van hoge kwaliteit die tegemoet komt aan de eisen van de gebruikers binnen de begrootte tijdsspanne en het budget. Onderstaande figuur is een overzicht van RUP RUP heeft twee dimensies: Op de horizontale as staan de tijd, fasering en iteraties; Op de verticale as staan de verschillende disciplines welke logisch zijn gegroepeerd. De eerste dimensie heeft betrekking op het dynamische aspect van het proces dat tot uitdrukking komt in fases, iteraties en mijlpalen. De tweede dimensie heeft betrekking op het statische aspecten van het proces dat tot uitdrukking komt in componenten, disciplines, activiteiten, workflow, tussenproducten en rollen. In de figuur staat de inspanning in de tijd per discipline. In het begin wordt bijvoorbeeld meer tijd besteed aan requirements, later in het project wordt er meer tijd besteed aan implementatie.

5 Organisatie SYSQA B.V. Pagina 5 van 14 3 Fases Het ontwikkelproces van RUP is vanuit managementsperspectief onderverdeeld in vier fases, welke worden afgesloten met een mijlpaal. Iedere fase is een essentieel onderdeel van het project. De fases zijn: Inception (opstartfase); Elaboration (uitwerkingsfase); Construction (bouwfase); Transition (overdrachtsfase). Iedere fase wordt afgesloten met een assessment, een vorm van review, om te bepalen of de doelstellingen van die fase zijn bereikt. Als het assessment positief uitvalt wordt overgegaan naar de volgende fase. De doorlooptijd en inspanning verschilt per fase. Hoewel het per project verschilt kan worden uit gegaan van de volgende verdeling: Fase Inception Elaboration Construction Transition Inspanning 5% 20% 65% 10% Doorlooptijd 10% 30% 50% 10% Bij onderhoudsprojecten zijn de Inception- en Elaborationfase korter dan bij een nieuwbouwproject. 3.1 Inception Het doel van de inceptionfase is het bereiken van overeenstemming tussen de stakeholders over de doelstellingen van het project. De inceptionfase is vooral van belang bij nieuwbouwprojecten waar sprake is van significante organisatie- of requirementsrisico s die opgelost moeten zijn voordat het project voortgang vindt. Bij projecten die gericht zijn op aanpassing en uitbreiding van een bestaand systeem is de inceptionfase meestal kort. De inceptionfase is er nog steeds op gericht zeker te stellen dat het project de moeite waard is en uit te voeren. De primaire doelstellingen van de inceptionfase zijn: Ontwikkelen van de scope van het project, randvoorwaarden en uitgangspunten, een visie, benoemen van acceptatiecriteria en een weergave wat het product wel en niet moet worden; Bepalen van de kritische use-cases van het systeem, alsmede de primaire gebruiksscenario s. Dit vormt input voor het ontwerp; Vaststellen van de mogelijke architectuur; Schatten van de totale kosten en benodigde tijdsinspanning van het gehele project; Uitvoeren van de risicoanalyses; Voorbereiden van de projectstructuur. Tijdens de Inceptionfase worden onder andere de volgende activiteiten uitgevoerd: Formuleren van de scope van het project inclusief requirements, beperkingen en acceptatiecriteria; Plannen en voorbereiden van de business case; Maken van een mogelijke architectuur, deze is de basis voor de beslissing; nieuwbouw, hergebruik of kopen en is ook de basis voor het bepalen van de kosten, het tijdschema en de benodigde resources. Eventueel wordt de werkbaarheid van de architectuur aangetoond door een proof of concept; Voorbereiden van een projectomgeving, zoals de projectorganisatie en het selecteren van tools.

6 Organisatie SYSQA B.V. Pagina 6 van 14 De Inception fase wordt afgesloten met de mijlpaal Levenscyclus doelstellingen waarin de levensvatbaarheid van het project wordt geëvalueerd. 3.2 Elaboration Doelstelling van de Elaborationfase is het opstellen van een architectuur van het systeem. Deze vormt een stabiele basis tijdens het ontwerp en de ontwikkeling. De architectuur wordt opgesteld op basis van de belangrijkste requirements en de risicoanalyse. De bruikbaarheid van de architectuur wordt vastgesteld aan de hand van één of meer prototypes. De primaire doelstellingen van de Elaborationfase zijn: Opstellen van de baseline architectuur; Het zekerstellen dat de architectuur, requirements en plannen stabiel genoeg zijn en dat de risico s voldoende zijn afgedekt om het project uit te kunnen voeren binnen de gestelde kosten en het gestelde tijdschema. Na afloop van deze fase verandert het project van een klein, snel en goedkoop project met een laag risico in een project met hoge kosten, hoge risico s die een substantieel effect hebben op de organisatie. Het bepalen van de risico s die uit de architectuur naar voren komen; Het maken van een prototype; Aantonen dat de architectuur tegemoet komt aan de requirements van het systeem en dat het te realiseren is binnen redelijke kosten en een redelijk tijdschema; Het inrichten van een project omgeving (ontwikkelomgeving, templates, richtlijnen en tools). Tijdens de Elaborationfase worden onder andere de volgende activiteiten uitgevoerd: Definiëren en valideren van de basisarchitectuur; Uitwerken van de visie; Inrichten van de ontwikkelomgeving inclusief het proces, de tools en de ondersteuning van het ontwikkelteam; Uitwerken van de architectuur en het selecteren van de componenten, deze componenten kunnen worden gemaakt, gekocht of hergebruikt. De mijlpaal waarmee de Elaborationfase wordt afgesloten is het rapport Levenscyclus architectuur. Dit bevat de architectuur van het uiteindelijke systeem en stelt het projectteam in staat het systeem te realiseren in de Constructionfase. 3.3 Construction Het doel van de Constructionfase is het verder uitwerken van de requirements en het ontwikkelen van het systeem op basis van de architectuur. De Constructionfase is een fabricageproces die gericht is op het managen van de resources en besturen van de uitvoering gericht op het optimaliseren van kosten, tijdschema en kwaliteit. Op deze manier beschouwd verandert de aard van het project van een creatief proces tijdens de Inception en Elaboration naar het ontwikkelen van bruikbare producten tijdens de Construction en Transition. De primaire doelstellingen van de Constructionfase zijn: Het minimaliseren van ontwikkelingskosten door het optimaal gebruik maken van resources en voorkomen van fouten en herstel; Bereiken van het gewenste kwaliteitsniveau; Het zo snel mogelijk maken van bruikbare versies van de software (alfa, beta en andere testreleases); Het analyseren, ontwerpen, ontwikkelen en testen van alle benodigde functionaliteit;

7 Organisatie SYSQA B.V. Pagina 7 van 14 Het door iteraties of incrementele ontwikkeling bouwen van een product dat klaar is voor overdracht naar de gebruikersorganisatie. Dit impliceert het beschrijven van de overgebleven use cases en andere requirements, het uitwerken van het ontwerp en het ontwikkelen en testen van de software; Bepalen of de software, de gebruikersorganisatie en de gebruikers klaar zijn om de applicatie te gaan gebruiken; Het tot stand brengen van enige mate van paralleliteit in het werk van de ontwikkelteams. Door verschillende ontwikkelteams parallel onderdelen te laten ontwikkelen wordt de doorlooptijd verkort. Dit proces dient wel beheerst te worden. De belangrijkste activiteiten van de Constructionfase zijn: Resourcemanagement, procesbeheersing en optimalisatie; Ontwikkelen en testen van de compontenten; Vaststellen of de software voldoet aan de acceptatiecriteria. De Constructionfase wordt afgesloten met de mijlpaal Operationele capaciteit. In deze mijlpaal wordt aangegeven dat het product klaar is voor overdracht naar de beta-test omgeving. 3.4 Transition Doelstelling van de Transition fase is het ter beschikking stellen van de software aan de eindgebruikers. De Transition fase kan uit meerdere iteraties bestaan en omvat het testen van het product in de voorbereiding van een release en het maken van kleine aanpassingen in de software op basis van feedback van gebruikers. De feedback van gebruikers dient zich op dit moment van het project te beperken tot het fine-tunen van het product; het configureren, installeren en het gebruiksklaar maken. De belangrijke, structurele zaken zijn veel eerder in het project aangepakt. Aan het einde van de Transition fase dienen de doelstellingen van het project gehaald te zijn en kan het project beëindigd worden. In sommige gevallen begint na de Transition fase een nieuwe ontwikkelcyclus van hetzelfde product, die tot de volgende release van het product leidt. In andere gevallen leidt de Transition fase tot het opleveren van alle tussen- en eindproducten aan een derde partij die verantwoordelijk is voor beheer en onderhoud van het systeem. De activiteiten die uitgevoerd worden tijdens de Transition fase zijn afhankelijk van het doel en de impact van het systeem en kunnen kort en eenvoudig zijn, maar ook lang en uitgebreid. De Transition fase start als het product volwassen genoeg is om overgedragen te worden aan de eindgebruiker. Dit vereist dat een bruikbaar deel van het systeem klaar is met een acceptabele kwaliteit en gebruikersdocumentatie, opdat overdracht aan de gebruiker voor alle partijen succesvol is. De primaire doelstellingen van de Transition fasezijn: Beta-testen (beperkte acceptatietest, gericht op het vaststellen van de bruikbaarheid) van het systeem om vast te stellen of het nieuwe systeem voldoet aan de verwachtingen van de gebruikers; Beta-testen en schaduwdraaien naast het oude systeem dat het vervangt; Converteren van de operationele database; Trainen van gebruikers en beheerders; Roll-out naar marketing, distributie en sales; Implementatie-specifieke zaken zoals overdracht, verpakken en versturen, aanpassen van het salesproces en de training; Fine-tuning van het systeem zoals het herstellen van bugs en het verbeteren van performance en bruikbaarheid; Vaststellen of het uitgeleverde product voldoet aan de acceptatiecriteria van de gebruikers;

8 Organisatie SYSQA B.V. Pagina 8 van 14 Het bereiken van selfsupport bij de gebruikers; Verifiëren of het systeem aan de eisen van de stakeholders voldoet; Vaststellen dat het uitgeleverde product in lijn is met de geformuleerde visie. Tijdens de Transition fase vinden de volgende activiteiten plaats: Uitvoeren van overdrachtsplannen; Maken van ondersteunend materiaal voor eindgebruikers; Testen van het ontwikkelde product op de gebruikerslocatie; Creëren van een productrelease; Ontvangen van user feedback; Fine-tunen van het product op basis van de feedback; Het beschikbaar stellen van het product aan de eindgebruikers. De Transition fase wordt afgesloten met de productrelease.

9 Organisatie SYSQA B.V. Pagina 9 van 14 4 Disciplines Disciplines zijn logische groepen activiteiten die een afgebakend doel hebben en leiden tot bepaalde tussenproducten. Door het iteratieve karakter van RUP kunnen disciplines over meer fases verdeeld zijn. In RUP worden de volgende disciplines onderkend: Business modeling; Requirements; Analyse en ontwerp (analysis and design); Ontwikkeling (implementation); Testen; Implementatie (deployment); Configuratie- en changemanagement; Omgeving (environment); Projectmanagement. 4.1 Business modeling De doelstellingen van business modeling zijn: Het doorgronden van de structuur en dynamiek van de organisatie waarin een systeem geïmplementeerd dient te worden; Het doorgronden van de huidige problematiek van de organisatie en het identificeren van verbetermogelijkheden; Het zeker stellen dat klanten, eindgebruikers en ontwikkelaars hetzelfde begrip hebben van de problematiek van de organisatie; Het bepalen van de eisen die aan het systeem worden gesteld door de organisatie. Om deze doelstellingen te bereiken wordt een visie van de nieuwe organisatie ontwikkeld. Gebaseerd op deze visie worden de processen, rollen en verantwoordelijkheden gedefinieerd in de vorm van een business-case en een business object model. 4.2 Requirements Het doel van de requirements discipline is: Het tot stand brengen en onderhouden van overeenstemming tussen klanten en de andere stakeholders over wat het systeem moet doen; Zorgen dat de systeemontwikkelaars de eisen die aan het systeem worden gesteld beter begrijpen; Het definiëren van de grenzen van het systeem; Het creëren van een basis voor de technische inhoud van de iteraties; Het creëren van een basis voor kosten en tijdschattingen voor het ontwikkelen van het systeem; Het definiëren van de user-interface van het systeem, gebaseerd op de behoeften en doelen van de gebruikers. Om deze doelen te bereiken is het belangrijk om allereerst de definitie en scope van het probleem dat we proberen op te lossen met het systeem te doorgronden. De business rules, business usecase model en business object model die ontwikkeld zijn tijdens de business modeling zijn hierbij zeer bruikbaar. De stakeholders worden geïdentificeerd en eisen en wensen van de stakeholders worden verzameld en geanalyseerd. De eisen en wensen van de stakeholders zijn zowel actief geïnventariseerd als verzameld uit bestaande bronnen om zo een volledige wensenlijst te krijgen.

10 Organisatie SYSQA B.V. Pagina 10 van 14 De eisen en wensen worden vastgelegd in een visie-document. Het visie-document is geschreven vanuit het perspectief van de klant en focust op de essentiële features van het systeem en het acceptabele kwaliteitsniveau. Het visiedocument verschaft een compleet beeld van het softwaresysteem dat ontwikkeld gaat worden en dient als basis voor het contract tussen de opdrachtgever en de ontwikkelingsorganisatie. Ieder project heeft een bron nodig voor het vastleggen van de verwachtingen van de stakeholders. Het use-case model dient als een communicatiemedium en kan dienen als een contract tussen de klanten, de gebruiker en de systeemontwikkelaars met betrekking tot de functionaliteit van het systeem. Het dient voor: Klanten en gebruikers om te valideren dat het systeem wordt wat ze ervan verwachten; Systeemontwikkelaars om te zorgen dat ze bouwen wat verwacht wordt. Het use-case model bestaat uit use-cases en actoren. Elke use-case in het model beschrijft stap voor stap hoe het systeem interacteerd met de actoren en wat het systeem in dat geval doet. Usecases zijn de rode draad door de software lifecycle en worden gebruikt bij analyse, ontwerp, implementatie en test. De supplementary specification is een belangrijke completering van het use-case model omdat daarin alle software requirements (functioneel en niet-functioneel) vastliggen. Het totaal van usecases en supplementary specifications worden samengevoegd in de software requirements specificatie. Het requirements management plan bevat alle informatie en beheermechanismen met betrekking tot meting, rapportering en beheer van veranderingen in de requirements. 4.3 Analyse en ontwerp (analysis and design) De doelstellingen van analyse en ontwerp zijn: Het omzetten van de requirements in een ontwerp van het systeem; Het ontwikkelen van een robuuste architectuur van het systeem; Het pas klaar maken van het ontwerp zodat het gerealiseerd kan worden. Allereerst worden er een aantal mogelijke architecturen ontwikkeld. De architectuur van een softwaresysteem is de structuur van het systeem bestaande uit componten, hun samenhang en de interfaces. De architectuur kan vanuit verschillende oogpunten worden gemaakt, vanuit de gebruiker, de klant, de software ontwikkelaar et cetera. De mogelijke architecturen worden geanalyseerd en er wordt voor een bepaalde architectuur gekozen. Later in de software lifecycle kan bij een nieuwe iteratie de architectuur verder worden ontwikkeld. De architectuur wordt altijd gereviewd op basis van de requirements en use-cases. Vervolgens worden de verschillende componenten ontworpen; de batch componenten, de realtime componenten en de database. Alle componenten en het datamodel worden gereriewd voordat ze in het vervolg van het proces worden gebruikt. RUP geeft aan op basis van welke eerder gemaakte tussenproducten de review plaats dient te vinden. 4.4 Ontwikkeling (Implementation) RUP noemt ontwikkeling implementatie. Het doel van de ontwikkeling is: Het bepalen van de organisatie van de code; in de vorm van subsystemen georganiseerd in lagen; Het ontwikkelen van componenten; Het uitvoeren van de unittest; Het integreren van het werk van de verschillende ontwikkelaars of teams in executables.

11 Organisatie SYSQA B.V. Pagina 11 van 14 Tijdens de ontwikkeling worden de verschillende systeemcomponenten ontwikkeld en geïntegreerd. Zowel de code van de componenten als de integratie worden zowel gereviewd als getest. 4.5 Testen Het doel van testen is: Vaststellen dat de interactie tussen de objecten goed verloopt; Vaststellen dat het systeem correct is ontwikkeld; Vaststellen dat het systeem voldoet aan de requirements; Vaststellen dat de fouten het gebruik van de software niet in de weg staat. Softwaretesten kost bij veel organisaties tussen de 30 tot 50% van de software ontwikkelkosten. Toch bestaat het beeld dat de software bij oplevering onvoldoende getest is. Deze contradictie komt door twee redenen. Ten eerste is het testen enorm moeilijk. De verschillende manieren waarop een programma kan werken is niet te kwantificeren. Ten tweede wordt testen vaak gedaan zonder duidelijke methode en zonder de benodigde tools en ondersteuning. Hoewel de complexheid van de software ervoor zorgt dat het compleet testen van een systeem onmogelijk is, brengt het toepassen van een gestructureerde methode en goeie tools grote productiviteits- en effectiviteitsverbeteringen met zich mee. Goed uitgevoerde testen die vroeg in de software lifecycle zijn uitgevoerd verlagen de kosten van ontwikkeling en onderhoud significant. Het reduceert ook het risico en de verantwoordelijkheid met betrekking tot het gebruik van slechte kwaliteit software zoals lage gebruikers productiviteit, fouten bij het invoeren van data en berekeningen en onacceptabele functionele werking. Tegenwoordig zijn veel systemen kritiek voor het succes van organisaties. Het testen begint met het maken van een testplan. In het testplan staan de te testen requirements, de risicoanalyse, de teststrategie, de benodigde resources en de planning. In het testplan worden ook alle verschillende vormen van testen benoemd (functioneel, bedrijfsproces, load, stress etc.). Vervolgens worden de tests ontworpen en worden de testgevallen ontwikkeld. Daarna worden de verschillende tests uitgevoerd en de uitkomsten geëvalueerd. 4.6 Implementatie (Deployment) RUP noemt implementatie deployment. Implementatie beschrijft de activiteiten met betrekking tot het ter beschikking stellen van het product aan de gebruikers. Dit omvat ook het acceptatietesten op de locatie van de gebruiker (betatest) en uitbrengen van de release. Veel van de implementatieactiviteiten worden al vroeg in het ontwikkeltraject voorbereid. Er wordt een separaat implementatieplan opgesteld met daarin de implementatieactiviteiten. 4.7 Configuratie- en changemanagement Configuratie- en changemanagement heeft betrekking op: Identificeren van configuratieitems; Beheersen van de wijzigingen met betrekking tot deze items; Vaststellen van de integriteit van de items; Definiëren en managen van de configuraties van deze items. Een configuratie management systeem (CM systeem) is essentieel voor het beheersen van diverse producten die ontstaan tijdens een project. Beheer voorkomt kostbare fouten zoals: Gelijktijdige aanpassing; Beperkte kennis van het product; Gelijktijdig gebruik van meerdere versies.

12 Organisatie SYSQA B.V. Pagina 12 van Omgeving (Environment) De omgevingsdiscipline richt zich op de activiteiten die benodigd zijn voor het ondersteunen van het proces van het project. De ontwikkelomgeving zijn alle zaken die het project nodig heeft om een systeem te ontwikkelen en in te voeren, zoals tools, processen, templates en infrastructuur. Het doel van de omgevingsactiviteiten is zorgen voor een software ontwikkelingsorganisatie, inclusief processen en tools, die het ontwikkelteam ondersteunt. Voorbeelden zijn: Tools, inclusief richtlijnen voor gebruik; Project specifieke templates; Beschrijving van het ontwikkelproces; Richtlijnen voor business-modelering; Configuratie management plan; Ontwerprichtlijnen; Stijlgids voor de handleiding; Programmeerrichtlijnen; Testrichtlijnen; Richtlijnen voor het opstellen van use-cases; User-interface richtlijnen; Ontwikkelinfrastructuur. 4.9 Project management Software project management is een vak van balanceren tussen verschillende doelstellingen, het managen van risico s en overwinnen van obstakels met als doel een product af te leveren dat voldoet aan de wensen van de klant en de andere stakeholders. En dat is niet makkelijk. Het doel van projectmanagement is zorg dragen voor: Een raamwerk voor het managen van software intensive projecten; Richtlijnen voor planning, bemensing, uitvoering en monitoring van projecten; Een raamwerk voor het managen van risico.

13 Organisatie SYSQA B.V. Pagina 13 van 14 5 Overige aspecten van RUP 5.1 Rollen RUP onderkent de volgende rollen binnen een project: Analisten: Business designer; Business model reviewer; Business process analist; Requirements reviewer; System analist; Requirements specifier; User interface designer. Developers: Software Architect; Architecture Reviewer; Capsule Designer; Code Reviewer; Database Designer; Design Reviewer; Designer; Implementer; Integrator. Testers: Test designer; Tester. Managers Change Control Manager; Configuration Manager; Deployment Manager; Process Engineer; Project Manager; Project Reviewer. Overige rollen: Stakeholder; Any Role; Course Developer; Graphic Artist; System Administrator; Technical Writer; Tool Specialist. RUP kent ook zeer veel tussenproducten (in totaal 105). Het voert te ver om ze allemaal op te sommen en te behandelen, hiervoor wordt verwezen naar de CD-ROM.

14 Organisatie SYSQA B.V. Pagina 14 van 14 6 Literatuurverwijzingen CR-ROM op te vragen bij het productmanagement