Wijzigingen van de tweede druk ten opzichte van de eerste 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.
De relatie tussen de inspanning van opdrachtnemer en opdrachtgever op specifieke gebieden is kwantitatief gemaakt. Dit is te zien in de nieuwe staafdiagrammen die de oude walvisplaat vervangen.
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 uitgangspunten van RUP en de evaluatiecriteria voor de fasen zijn opnieuw geformuleerd.
Overige wijzigingen
Door het hele boek heen hebben we de lopende tekst tegen het licht gehouden en waar nodig verhelderd.
We hebben aan de paragraaf ‘RUP anti-patterns’ het anti-pattern ‘full-blown RUP’ toegevoegd omdat dit in de praktijk vaak wordt nagestreefd.
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 rollen (hoofdstuk 9) zijn de fasen niet langer zichtbaar. Deze informatie is meer gedetailleerd beschikbaar in de vorm van de nieuwe staafdiagrammen.
Bij de werkproducten (hoofdstuk 11) noemen we niet alleen de verantwoordelijkheid van schrijven, maar ook de aanvullende en goedkeurende verantwoordelijkheden. Dit maakt het beeld voor het desbetreffende werkproduct completer. Ook is een meer natuurlijke volgorde in deze hoofdstukken gekozen: rollen, taken en werkproducten, waardoor de hoofdstukken 10 en 11 van plaats wisselen.
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.
