Versieinformatie

Deze naslagsite is gebaseerd op de tweede herziene druk, derde oplage van RUP op Maat, gepubliceerd in maart 2010.

 

TODO mei 2011 veranderingen derde druk inwerken

Juli 2010:

In de vergelijking van RUP op Maat, RUP en OpenUP een fout hersteld: Test Plan is geen werkproduct in OpenUP.

 

April 2010:

Het volgende te downloaden template toegevoegd: Iteration Assessment.

 

Januari 2010:

De volgende te downloaden templates aangepast: Vision, Business Object Model, Data Migration Specification, Glossary, Iteration Plan, Navigation Map, Product Acceptance Plan, Software Architectuur Document, Software Development Plan, Testplan, Use Case Model, Use Case Realization, Use Case Specification.

 

September 2009:

In de Inception workflow een pijl toegevoegd van Vision naar Inventariseer Actors en Use Cases.

 

Oktober 2008:

Demo vernieuwd naar aanleiding van tweede, herziene druk van RUP op Maat.

Bij downloads een link toegevoegd naar downloadlocatie voor Ordina medewerkers.

Product Acceptance Plan omschrijving aangepast in Glossary

Ontbrekende links toegevoegd bij taken Projectleider

Lesmateriaal pagina toegevoegd.

 

September 2008:

Workflows toegankelijk gemaakt a.d.h.v. de RUP Lifecycle workflow en de iteratieworkflow.

Templates toegevoegd voor Business Object Model, Data Migration Specification, Test Plan en Navigation Map.

 

April 2008 n.a.v. tweede herziene druk:

Opdrachtnemer- opdrachtgever perspectief
Het perspectief van de opdrachtgever is breder uitgewerkt. De samenvattende opdrachtgeverrol is gesplitst in Projecteigenaar, Project Manager, Business Analist en ICT Architect. Op deze manier wordt sneller inzichtelijk welke taken de opdrachtgeverorganisatie geacht wordt te kunnen vervullen. Verder is de gebruikerrol verscherpt en heet nu Domeindeskundige. Een Domeindeskundige heeft kennis van (een deel van) de business, maar hoeft niet altijd zelf een gebruiker te zijn.

Aan de opdrachtgeverzijde is de rol van Contractmanager toegevoegd teneinde de verschillende verantwoordelijkheden van Projectleider en achterliggende opdrachtnemerorganisatie explicieter te kunnen maken.

In de verantwoordelijkhedenmatrix (voorheen genoemd rollenplaat) is de opdeling voorzien van nieuwe opschriften. Niet langer ‘opdrachtgever’ en ‘opdrachtnemer’ maar ‘belanghebbenden’ en ‘ontwikkelteam’. We hebben gemerkt dat er gemakkelijk verwarring kon ontstaan als beheertaken van de opdrachtgever bij dezelfde opdrachtnemer waren belegd die ook het ontwikkelteam levert. Door de term ‘ontwikkelteam’ te gebruiken is er een natuurlijke splitsing, namelijk wel of niet bij het ontwikkelteam horend. Ook hebben we de term ‘discipline’ exclusief voor het ontwikkelteam gemaakt. Bij elkaar horende activiteiten bij de opdrachtgever (buiten het ontwikkelteam) zijn gebundeld via ‘belanghebbenden’, niet langer via disciplines.

‘Beheerrollen’ is bij de opdrachtnemer verscherpt naar ‘Toolbeheerder’ en ‘Applicatiebeheerder’ is gewijzigd naar ‘Integrator’, om aan te geven dat het beheer bij de opdrachtnemer verschilt van dat bij de opdrachtgever. Om dezelfde reden is de discipline ‘Beheer’ hernoemd naar ‘Ondersteuning’.

Workflows
In de workflows is het schrijven van de Use Case Realization verplaatst van het begin van de realisatieiteratie naar het einde van de ontwerpiteratie, om inzichtelijker te maken dat de bouwers input leveren op het ontwerp. Verder zijn er enkele activiteiten uit het niet-iteratieve gedeelte van Elaboration verplaatst naar de iteratieve activiteiten en is de verantwoordelijkheid voor het Data Model verlegd van de Informatieanalist naar de Software Architect.

Het verschijnsel ‘kwaliteit’ is meer expliciet gemaakt door aan de iteratieve workflows een kwaliteitsworkflow toe te voegen. Opmerkingen daarover stonden tot nu toe verspreid in de tekst.

De managementworkflow is uitgebreid met de rol van Test Manager, die nu expliciet ook de taak heeft Bevindingen te managen. Ook is het Wijzigingsvoorstel expliciet input geworden voor het plannen van een iteratie.

De workflows hebben een nieuw uiterlijk gekregen.

Veranderingen vanuit RUP 7.1
We hebben rekening gehouden met veranderingen die zijn ontstaan in RUP 7.0 en 7.1. Dit zijn veranderingen in termen: ‘Artifact’ is vervangen door ‘werkproduct’, ‘activiteit’ is waar van toepassing vervangen door ‘taak’.

‘Class Model’ is vervangen door ‘Design Model’, omdat we hebben gemerkt dat onze bedoeling niet altijd helder overkwam. Evenzo zijn de namen van acceptatiehandleiding en conversiehandleiding gewijzigd naar Product Acceptance Plan en Data Migration Specification, om dichter aan te sluiten bij RUP 7.0 en 7.1.

De evaluatiecriteria voor de fasen zijn opnieuw geformuleerd.

Overige wijzigingen
De rollen ‘Test ontwerper’ en ‘Tester’ zijn samengekomen in ‘Tester’, omdat dezelfde competenties vereist zijn en het ontwerpen en uitvoeren van tests in de praktijk meestal door dezelfde personen wordt uitgevoerd.

In de ’inrichting van het iteratief proces’ (voorheen genoemd ‘vissenplaat’) hebben we betere termen gevonden voor de activiteiten. Niet langer ‘ontwerp’, ‘bouw’ en ‘test’ maar ‘ontwerp’, ‘realisatie’ en ‘acceptatie’. Bij realisatie gaat het om meer dan bouw, en bij acceptatie is direct duidelijk dat hier de opdrachtgeverorganisatie bij betrokken is.

Bij de werkproducten noemen we niet alleen de verantwoordelijkheid van schrijven, maar ook de aanvullende en goedkeurende verantwoordelijkheden. Dit maakt het beeld voor het desbetreffende werkproduct completer.

Er is een extra bijlage toegevoegd waarin diegenen die al vertrouwd zijn met RUP of het Open Unified Process gemakkelijk kunnen zien hoe de disciplines, rollen en werkproducten van RUP op Maat hierbij aansluiten.

Product Acceptance Plan template toegevoegd.

 

Maart 2006:

initiële versie.

Reviewcommentaar

We zijn dankbaar voor elk reviewcommentaar. Of het nu gaat om spellingsfouten of inhoudelijke op- en aanmerkingen.

Selecteer de tekst waar je commentaar op wil leveren en klik op de onderstaande knop.