Implementatie RUP

$edere ontwikkelaar komt in elk project in aanraking met al dan niet
gedetailleerde eisen en wensen ten aanzien van het bewaren en ophalen van
gegevens of objecten. In wat voor vorm moeten die gegevens opgeslagen
worden? En hoe snel moeten die weer oproepbaar zijn? Veelal zal er een
specialist zijn die zich met deze taak bezighoudt, maar vaakzal de ontwikkelaar
gevraagd worden mee te denken over de persistentie. In dit hoofdstuk wordt
besproken welke werkzaamheden in welke fase van een project worden
uitgevoerd, om te zorgen dat persistentie van gegevens goed geregeld is.
Welke stappen moeten bijvoorbeeld worden doorlopen om te komen tot een
goed datamodel? Wat zijn goede Mechanisms om gegevens op te slaan en
welke kan het beste gekozen worden? Verder kijken we naar veelgebruikte dat
abasemanagementsystemen. De keuze daarvan heeft vanzelfsprekend invloed
op de methode van dataopslag.
Svsteemontwikkelina met RUP
samengesteld aan de hand van deze gegevens. Die SQL-code stuurt

ze vervolgens naar de database en voilà, we hebben een opgeslagen
notaris. Hoezo moeilijk, die persistentie?
Robert nodigt twee dagen later Nico en Michiel uit voor een overleg: hij
heefi een ontwerp gemaakt voor een anntal data classes die de opslag
van gegevens gaan regelen. Hij heeft een class bedacht die de objecten
klaarzet voor opslag en een aparte class die de gegevens transformeert
naar een formaat dat geschikt is voor een Oracle-database.
Nico meldt dat er inmiddels al een database is met een tabel Notaris.
Miclziel merkt op dat hij net zag dat Jeanette al een class heejì gemaakt
die een en ander regelt. "Ju, wacht even, dát is niet helemaal de
bedoeling.. ." zegt Robert.
Objecten hebben een levenscyclus; ze worden gecreëerd, gebruikt, gewijzigd

en verdwijnen uiteindelijk weer. Deze levenscyclus van een object omvat voor
vele objecten een tijdspanne langer dan de sessie waarin de gebruiker met de
applicatie communiceert. Met name entity-objecten hebben nagenoeg altijd
een langere levenscyclus. Objecten in de presentatielaag (de boundary-objec-
ten) of applicatielaag (de control-objecten) hebben meestal een levenscyclus
die zich tot één sessie beperkt.
Is de levenscyclus langer dan één sessie, dan moeten objecten worden opgesla-
gen. We spreken over persistente objecten.
Behalve vanuit de eis tot een langere levensduur, kan ook de wens tot gelijktij-
dig en gemeenschappelijk gebruik van dezelfde objecten leiden tot persisten-
tie.
Objecten maken deel uit van een applicatie op een Server of deels op een
Server bevindt, terwijl meerdere Cliënts gelijktijdig communiceren binnen die
applicatie en zijn data. Bij deze communicatie kan het nodig zijn dat objecten
of kopieën daarvan, van de Server naar de Cliënt verhuizen. Het proces dat
hierbij komt kijken, lijkt erg op het proces dat nodig is om objecten persistent
te krijgen.
9 Persistentie
opslag
Figuur 9.1: Persistent object - Levensduur van object langer dan I sessie
00:00:01
Figuur 9.2: Persistent object - Gelijktijdigheid en gemeenschappelijk

gebruik
In beide gevallen worden geëncapsuleerde gegevens getransformeerd naar

transporteerbare bits. Bij persistentie gaan deze bits naar een achterliggen-
Systeemontwikkeling met RUP
de opslagvorm. Bij communicatie (ClientIServer) worden deze bits over het

netwerk gestuurd. Dit transformeren wordt in beide gevallen serialisatie ge-
noemd.
In de volgende paragraaf gaan we eerst in op de taak van de Database Desig-

ner en zijn taken. Bij het uitvoeren van zijn taken zal de Database Designer ge-
bruik maken van mechanismen die door de System Architect en de Developer
zijn beschreven. Daarna komt het serialiseren van objecten weer aan de orde.
Database Desi at is zijn taak?

De Database Designer is een RUP-rol binnen de Developer role-set. Deze rol
heeft tot taak te zorgen voor consistentie met betrekking tot persistentie van
gegevens. In RUP wordt aangegeven dat deze rol zich bezighoudt met het defi-
niëren van tabellen, indexen, views op de database, triggers, condities, stored
procedure en allerlei database specifieke zaken.
Supplernentary
Specifications
Use-Case
Realizations
Anaiysls
Model
\\
e Design
Ciass
\
Data Model
Review
Record
I Project
Specific
Guidelines
Supplementary
Specifications
Figuur 9.3: De rol van de Database Designer

Een Database Designer heeft kennis en ervaring met
meerdere soorten databases en over het bewaren, opzoeken
van persistente objecten. Het is een rol die door één persoon
gevoerd, maar ook door een groep Designers.
Een Database Designer is verantwoordelijk voor het opstellen en onderhouden

van het datamodel. Daarbij is de Design Class uit het Design Model een be-
langrijk inputartefact.
Rondom persistentie zijn een paar artefacts met name van belang binnen RUP:
de Design Classes uit het Design Model en het Data Model. Niet alle Design
Classes zijn logischerwijs van belang voor persistentie. Alleen Classes die data
bevatten die bij een volgende sessie van de applicatie nog steeds benaderbaar
moet zijn, zijn van belang. Dit zijn de persistente Design Classes. Deze groep
Design Classes vormt de belangrijkste input voor die andere belangrijke arte-
fact, het Data Model.
Zoals in de figuur 9.4 te zien is, bestaat het Data Model uit maximaal twee
bestanddelen: het logische datamodel en het fysieke datamodel. Het logische
datamodel is optioneel.
Analysls C l a n
Analysis Model
-44
Design Model
Database Designer
Figuur 9.4: Bestanddelen van het Data Model

Er zijn twee scenario's om tot het uiteindelijke datamodel te komen. Het eerste
scenario speelt op het moment dat de Design Classes uit het Design Model
grotendeels overeenkomen met de elementen uit het Data Model. In zo'n geval
namelijk kunnen de Designer en de Database Designer (in het geval van onze
casus Robert en Nico) samen direct het Physical Data Mgdel ontwerpen. Dit
scenario zou eigenlijk de voorkeur moeten hebben. Het is dan namelijk veel
makkelijker om in het Data Model de Design Classes terug te vinden. Zoiets
maakt de applicatie veel doorzichtiger en eenvoudiger te onderhouden.
Stel nu dat de fysieke database noodgedwongen flink moet afwijken van het
Design Model. Met andere woorden, de persistente Design Classes zijn niet
eenvoudig terug te vinden als structuurelementen binnen de database. Dit zou
bijvoorbeeld kunnen gebeuren als het grotendeels overnemen van de persisten-
te Design Classes een hopeloze performance tot gevolg zou hebben. Dit pro-
bleem zal vooral spelen bij gebruik van relationele databases, aangezien een
00-begrip als encapsulatie binnen een relationele database nogal omslachtig
werkt. Een database-object zou dan namelijk alleen mogen communiceren
met een object waar een directe relatie mee is. In een relationele database
worden echter bij voorkeur manipulaties op meerdere tabellen tegelijk in één
query uitgevoerd, in plaats van door een keten van queries die van tabel naar
tabel gaan. In zo'n geval is het gewenst om nog een soort tussenstap te maken
tussen het Design Model en het Physical Data Model, zodat het verband tussen
de logische en de fysieke elementen nog te traceren is. De tussenstap die we
dan maken is die van het Logical Data Model.
In het Logical Data Model legt de Designer vast hoe het datamodel er uit
oogpunt van de persistente classes idealiter uit zou moeten zien. De Database
Designer neemt vervolgens dit logische Data Model als uitgangspunt en gaat
dit omvormen zodat het geoptimaliseerd wordt voor het gekozen database-
managementsysteem.
In de volgende paragraaf wordt eerst ingegaan op een flexibele implementatie

van persistentie, waarna met enige opmerkingen betreffende de CliëntIServer
applicaties wordt afgesloten.
Voor het ontwerpen van een flexibel persistentiemechanisme wordt er gedu-

rende de Design-fase gebruikgemaakt van diverse mechanismen die uiteinde-
lijk leiden tot een keuze voor een implementatiemechanisme.
In een iteratie worden door de Designer samen met de Architect in Use Case
Analysis op basis van de Use Case bepaald welke analyseclasses nodig zijn en
welke Analysis Mechanisms voor deze Class van toepassing zijn. Een Analy-
sis Mechanism beschrijft de aspecten van een oplossing op een implementatie
onafhankelijke wijze. Analysis Mechanisms zijn vaak niet gerelateerd aan het
domein, maar meer aan het automatiseringsconcept. Ze beschrijven gedrag
dat te maken heeft met het leven van een object of component zoals het bewa-
ren van een object, communiceren tussen objecten et cetera. Voorbeelden van
Mechanisms zijn Persistentie, Licencing, Error Handling of Fault Handling en
Notification.
Voor persistentie moeten onderwerpen geregeld worden als:
hoeveel objecten moeten bewaard worden;

hoe groot zijn die objecten;
e wat is de bewaartermijn;
e unieke identificatie van een object, zodat het opgehaald kan worden;
hoe vaak wordt een object of gegeven bijgewerkt;
hoe overleven objecten een crash van bijvoorbeeld de applicatie.
Veelal zullen Analysis Classes van het 5 p e Entity Classes in ieder geval het
persistentiemechanisme hebben. Immers een Entity Class bevat relevante in-
formatie voor een organisatie en deze informatie zal langer bewaard moeten
worden dan enkel binnen een activiteit.
Een Analysis Mechanism wordt meestal vastgelegd in de vorm van een Inter-
action Diagram. Meestal wordt hiervoor een Collaboration Diagram gebruikt.
Zo'n diagram ziet er als volgt uit.
7: Print item values

2. Handle Item 8: Print total
5: Handle receipt 9: Get paper status
I p e m inserted
4: Receipt requested
7 /: CustomerPanel : Receivt Printer
X
: Customer
6: Get item values
3: Increment item
:Deposit Item : Alarm Device

Type
Figuur 9.5: Voorbeeld van een Interaction Diagram
Door de Designer worden (al dan niet in samenwerking met de Analyst) ka-
rakteristieken aan de Analysis Mechanisms toegevoegd. Voorbeeld: een arrest
wordt 1000 keer per dag geraadpleegd maar slechts zelden gewijzigd. Daar-
naast wordt I keer per dag een arrest toegevoegd. Het raadplegen is echter
ook parallel en moet snel gebeuren om daarmee het gerechtelijke proces te
ondersteunen (doorlooptijd minder dan één seconde).
9 Persistentie
De Software Architect zal op basis van de karakteristieken de Analysis Me-

chanisms worden omgezet naar een Design Mechanism.
acses Analysis Wlecha
storage
I I 1
Figuur 9.6: Omzetten van Analysis Mechanisms naar Design Mechanisms
Voor mechanismen naar de database kan de architect daarbij zeker om advies

vragen van een specialist zoals de Database Designer. Anderzijds zijn er ook
al diverse mechanismen beschreven en zullen vooral Design Patterns of Persi-
stentie Patterns nu kunnen worden ingevuld.
De Architect bepaalt daarna welk Implementation Mechanism voor een spe-

cifieke Class het best gebruikt kan worden en legt deze informatie vast bij de
Class in het Design Model. Dit implementatiemechanisme geeft de specifieke
gekozen technische oplossing voor het probleem weer. De specificatie van de
mechanismen zijn beschreven in het Software Architecture Document. Als dit
een nieuw soort mechanisme betreft zal het uitgebreider zijn beschreven en
zelfs zijn uitgewerkt in Sequence Diagram om daarmee voor anderen duide-
lijk te maken hoe dit mechanisme werkt en hoe iedereen dit moet gebruiken
(uiteraard kan dit dan uitmonden in het maken van instructies of regels die in
de guidelines worden opgenomen).
Op basis van de Design Classes zal de Database Designer gaan werken aan het
omvormen van een class naar een vorm van persistentie voor de database.
Figuur 9,7 probeert het verschil aan te geven tussen Design en Implementation
Mechanisms voor wat betreft Persistentie.
Classes Analysis M e c h a n i s m s Design Mechanisms Implernentation Mechanisms

CONCURRENCY I
Flight In-memory storage t,AVL Tree from Z-library
SGRAMBLING
I
PERSISSENCY
Aircraft CONCURAENCY Flash card MyLiYeCard
CECURITY l
Binary File UNIX
Mission SEGURtTY
I
SCRAMBLING DBMS hI Object store
SEFURITY I
I
Figuur 9.7: Omzetten van Design Mechanisms naar Implementation

Mechanisms
Zoals je ziet geeft het Design Mechanism een wat meer specifieke uitleg aan
de logische begrippen die in het Analysis Mechanism werden gebruikt. Pas in
het Implementation Mechanism wordt echter de precieze technische methode
gekozen waarmee deze Designoplossing technisch uitgevoerd gaat worden.
Omdat we uitgaan van een persistentiemechanisme waarin serialisatie ge-

scheiden is van het opslagprotocol,is het advies om hier ook twee Classes voor
te ontwerpen. Deze Classes zouden we Buffer en Archiver kunnen noemen.
Diverse vormen van serialisatie zijn nu te verkrijgen door subclasses van

Buffer te maken. Zoals een (leesbare) ascii-serialisatie in een Ascii-Buffer
en een (versleutelde) serialisatie in een Encrypted-Buffer-subclass. Door in
de applicatie nu een instance van de ene of de andere buffer te instantieren,
kan zonder overige wijzigingen aan te brengen een andere variant van per-
sistentie worden gebruikt. Dit alles dankzij polymorphism.
Diverse vormen van opslag (bestand, diverse RDBMS-va
leiden op zo'n zelfde manier tot diverse Archiver-subclasses.
bedrijfssituatie waarin men voor RDBMS heeft gekozen kan het g
voordelen hebben om voor de eerste tests of tijdens prototyping gebruik te
kunnen maken van opslag in een sequentieel bestand.
Merk op dat voor OBMS eigenlijk geen serialisatie nodig is. Wil men toch
dezelfde flexibiliteit hebben (wijzigen van OBMS naar bestand bijvoorbeeld),
dan is dit inderdaad realiseerbaar. Er moet een dummy buffer-subclass wor-
den ontworpen die geen serialisatie uitvoert, maar wel polymorph is met de
overige buffervarianten.
In onze casus heeft ontwikkelaar Jeanette duidelijk niet voor een flexibel per-
sistentiemechanismegekozen door SQL op te nemen in de Class die de opslag
regelt. Deze Class is nu specifiek gebonden aan opslag in een database, en dan
ook nog specifiek aan deze ene Oracle-database.
Allereerst moet een flexibel mechanisme ontworpen of gekozen worden, dat
niet direct afhankelijk is van het opslagmedium dat hier achter ligt. Pas als dat
generieke mechanisme er is, kunnen we dit inzetten voor het persisteren van
gegevens voor ons specifieke opslagmedium, de Oracle-database.
Zoals al eerder aangeven, lijkt het communicatieproces dat optreedt tussen

het Cliëntdeel en het Serverdeel van een CliëntIServerapplicatie veel op het
persistentieproces. Zo kunnen objecten van het ene naar het andere deel moe-
ten worden verplaatst. De daarbij te gebruiken serialisatie is dezelfde als bij
opslag. Het maakt dus niet uit of het geserialiseerd object - een rij bitjes - in
een database wordt opgeslagen of naar een andere applicatie wordt gestuurd.
Wel zal schrijven en lezen naar en van schijf iets anders zijn dan zenden en
ontvangen naar en van een netwerk. De Archiver-class wordt vervangen door
een analoge Class met bijvoorbeeld Communicator als naam.
Er is nog een tweede verschil. Tijdens persistentie wordt alleen over de opslag
van objecten gesproken, terwijl het bij communicatie om zowel objecten, maar
meer nog om messages gaat. Willen we hetzelfde mechanisme gebruiken, dan
moeten deze messages worden 'geobjectiveerd'. Er zal een object moeten wor-
den gemaakt dat de drager is van de inhoud van de message, het zogenaamde
Vraagobject. Alle parameters van de message kunnen als attribute (of geën-
capsuleerd object) van het Vraagobject dienen. Het Vraagobject kan nu wor-
den geserialiseerd en de resulterende bits verstuurd. In het andere deel van de
applicatie worden de ontvangen bits weer gedeserialiseerd (=geobjectiveerd).
Het Vraagobject ontstaat weer. Behalve drager van data, is het Vraagobject
ook drager van gedrag. Dit gedrag is als 'method' in het Vraagobject aanwezig
en wordt geactiveerd zodra het Vraagobject ontvangen is. In deze method (met
bijvoorbeeld de naam 'Run') kan het Vraagobject zijn taak uitvoeren, dat wil
zeggen zijn vraag stellen.
Op dezelfde wijze kan een antwoord op een vraag (de returnwaarde van een
message) weer worden geobjectiveerd in een Antwoordobject. Dit Antwoord-
object wordt geserialiseerd, bits worden verstuurd en aan de andere kant ont-
vangen en daar gedeserialiseerd zodat het Antwoordobject weer levend is.
Ook het antwoord is drager van gedrag in een standaard (bijvoorbeeld Run-
method). Wordt het gedrag van het Antwoordobject geactiveerd, dan zal het
antwoord op zoek gaan naar de originele afzender van de vraag (die moet dus
bekend zijn) en daar het inhoudelijke antwoord afgeven.
De ontwerper en Database Designer lopen natuurlijk niet als eerste ter wereld
tegen het probleem van persistentie aan. Integendeel, nagenoeg iedere applica-
tie zal een oplossing voor persistentie moeten gebruiken.
Toch zullen de meeste ontwikkelaars nog nooit zelf een mechanisme voor
flexibele persistentie gebouwd hebben. Hoe is dat mogelijk? Persistentie is al
een van de oudste concepten uit de automatisering en er zijn al veel oplossin-
gen gebouwd en gebruikt. De bedenkers van een framework als J2EE en de
producenten van ontwikkelomgevingen of DBMS-systemen maken gebruik
van ervaringen voor het oplossen van het probleem van persistentie. Vaak is
er daarom al een mechanisme voor persistentie ingebouwd in het framework
of pakket.
Voor Java zijn diverse standaardframeworks beschikbaar. Zo worden in het

J2EE- framework zelfs twee mechanismen geboden om persistentie te rege-
len: voor Enterprise Java Beans (EJB's) kan gebruikgemaakt worden van het
CMP-mechanisme: Container Managed Persistence. Daarnaast zijn er nog de
JDO's, de Java Data Objects. Dit zijn objecten waarmee een nog flexibeler me-
chanisme gemaakt kan worden dan met CMP. De JDO's zijn dan ook vooral
goed te gebruiken bij het persisteren van uitgebreide, 'rijke' objecten, die niet
specifiek zijn verbonden met een bepaalde API.
Daarnaast zijn er nog het open source framework Casfor (http://castor.exolab.

orgl), Oracle's TopLink, of bijvoorbeeld CocoBase (http://www.thoughtinc.
coml).
9 Persistentie
Het .NET-framework kent ook eigen mechanismen voor persistentie.

Voor het serialiseren van objecten kent .NET classes als CryptoStream en
NetworkStream. Daarnaast zijn er ook nog 'third-party' pakketten beschikbaar
die nog eenvoudigere persistentie mechanismen claimen, zoals Persistence.
NET (http://www.objectpersistence.com).
Vergeet niet dat ook in een DBMS tegenwoordig veel logica kan worden ge-
stopt. Ook voor de persistentie geldt dat lang niet alle logica in programma-
code hoeft te worden gezet. Het biedt zelfs grote voordelen om dit deels in
het DBMS op te lossen: de performancewinst is vaak aanzienlijk indien je
het persistentiemechanisme zo dicht mogelijk bij de uiteindelijke dataopslag
uitvoert. Hier kleeft echter ook een voor de hand liggend nadeel aan: als de
logica in het DBMS vastligt, zijn we daarmee dus gebonden aan dit DBMS en
verliezen we een belangrijk deel van de flexibiliteit. De vraag is dan: hoe groot
is de kans dat van DBMS gewisseld gaat worden?
Ook een standaardframeworkmechanisme zal altijd concepten als Buffer en

Archiver bevatten, precies zoals we die zouden gebruiken in een zelf ontwor-
pen mechanisme. De vraag is of de manier hoe die concepten zijn geïmple-
menteerd wel de optimale manier is voor ons project.
In bestaande frameworks en pakketten is reeds een hoop tijd en geld geïnves-

teerd en de meest gangbare zijn ook al vaak in de praktijk getest. We mogen
er dus van uitgaan dat het gebruikte persistentiemechanismein ieder geval be-
hoorlijk doortimmerd is. Zelf ontwikkelen leidt onvermijdelijk tot bugs in de
code, die er met zorgvuldig testen (lees: extra tijd en geld) uitgehaald moeten
worden. Geslaagde persistentie is essentieel voor een applicatie; een haperende
persistentie valt daarom eigenlijk altijd in de categorie showstoppers, een pro-
bleem waar de gehele applicatie mee staat of valt. Dit risico wordt gemeden
door een ready-made mechanisme te gebruiken. Een project bespaart boven-
dien een hoop tijd als de persistentie op deze manier eenvoudig kan worden
ingevuld: het ontwerpen en ontwikkelen van degelijk eigen mechanisme is een
redelijk tijdrovende klus.
Het gevaar hierbij is dat Implementers, Database Designers en eigenlijk alle

rollen in de Developer role set al snel geneigd zullen zijn dit mechanisme klak-
keloos over te nemen. Persistentie wordt dan niet meer als apart issue bekeken
gedurende een traject, maar het geboden mechanisme wordt zonder slag of
stoot overgenomen. Wat nu als dit persistentiemechanismeniet handig lijkt te
werken in de huidige projectomstandigheden? Het is dan belangrijk om te ont-
houden dat u niet vast zit aan het meegeleverde persistentiemechanisme.Het is
niet verstandig - zeker niet voor grote projecten of projecten die later nog uit-
gebreid zullen worden - om allerlei workarounds toe te passen in het geval van
een matig werkend mechanisme. Op de lange duur zullen de effecten daarvan
op de werking van een applicatie steeds groter worden. Als dan na lange tijd
nog het persistentiemechanismewordt gewijzigd, zal dit veel extra tijd en geld
kosten, gezien het effect van deze wijziging op de architectuur.
Logischerwijs hebben de Database Designer en Implementer meer controle

over de persistentie indien ze het mechanisme hiervoor custom-made is. Een
kleine optimalisatie doorvoeren aan een ingebouwd mechanisme is moeilijk
en soms zelfs onmogelijk. Bij een zelf gebouwd mechanisme is het eenvou-
dig.
In het geval van een ingebakken mechanisme is de Tester in feite een black-
box aan het testen. Eventuele bottlenecks van een ingebakken mechanisme
zijn lastig te achterhalen, aangezien de Tester geen goed inzicht heeft in de
werking ervan. Ook dit probleem speelt niet bij een eigen ontwerp.
Voor kleinschalige projecten zal een standaardframework vaak de beste keuze

zijn. Misschien biedt dat persistentiemechanismeniet de ideale oplossing, maar
vaak is het wel de optimale oplossing in de geldende projectomstandigheden.
Voor grote projecten of projecten die in de toekomst erg groot zuilen gaan
worden, moet de mogelijkheid
- van een eigen persistentiemechanisme nog
zwaarder wegen. Een degelijk, op maat gesneden mechanisme kan dan veel
voordelen opleveren.
Hoe dan ook geldt dat de keuze voor zelf ontwerpen of overnemen altijd expli-
ciet gemaakt dient te worden, hoe klein het project ook is.
Verschillende alternatieven voor opslagvormen kunnen worden overwogen:
Bestanden
In-Memory data structures
e Databases:
o Object Base
0 Relationele Database
0 Hiërarchische Database
o Netwerk Database
Hybride-oplossing
In deze paragraaf gaan we wat uitgebreider in op deze mogelijkheden. De

meeste aandacht zullen we besteden aan databases, aangezien dat de meestge-
bruikte opslagvorm is.
Opslag in losse bestanden @Ze based) is goedkoop en voor iedereen mogelijk

(geen licentie nodig). Onderhoud en uitbreidingen kunnen erg moeilijk zijn.
Bovendien speelt hier het probleem van meerdere gebruikers die tegelijker-
tijd hetzelfde bestand willen benaderen. Bestanden zijn daarom uitermate ge-
schikt voor tijdelijke opslag en voor single user-systemen. Voor de gemiddelde
applicatie echter zal deze oplossing niet reëel zijn.
Overigens zal wel vaak een oplossing met losse bestanden worden ge-
kozen voor configuratiegegevens van een applicatie, zodat deze gege-
vens eenvoudig te wijzigen zijn buiten de applicatie om.
Bij opslag in bestanden kunnen slechts de gegevens van de objecten in de

bestanden worden opgeslagen. Het gedrag van de objecten is en blijft gespe-
cificeerd in de Class en daarmee in de exe-, dll-, of jar-files die eruit ontstaan.
Het gedrag nodig voor het fysiek wegschrijven en het weer inlezen van de ge-
gevens, het creëren en initialiseren van de relaties met object, moet zelfs door
middel van datalaag-Classes worden gecodeerd. Omdat bestandsbenadering
per operating systeem varieert, is een goede encapsulatie van dit gedrag in af-
zonderlijke Classes wenselijk. De entity-Classes (waar het eigenlijk om draait)
blijven dan platformonafhankelijk herbruikbaar.
ory Data Structures

Intern geheugen van een computer kan ook persistente data ondersteunen als
dat geheugen wordt uitgebreid met de benodigde stroomvoorziening en hard-
ware. Een dergelijke vorm van dataopslag zien we vaak in elektronische appa-
raten die op een batterij (of accu) werken (bijvoorbeeld mobiele telefoons). De
gegevens zijn opgeslagen in het interne geheugen. Zodra de batterij op is, zijn
daarmee echter ook de gegevens verdwenen. Deze wijze van opslag vergt erg
specialistische kennis en zal daarom hier niet verder behandeld worden.
Databases
Dit is verreweg de meest gebruikte vorm van opslag. Bij databases is een be-
heersysteem aanwezig. Een relationele database wordt beheerd door een rela-
tioneel databasemanagementsysteem (RDBMS) en een object base door een
objectbasemanagementsysteem (OBMS). Tezamen worden deze systemen met
de ietwat verwarrende naam databasemanagement systemen (DBMS) aange-
duid.
In objectgeoriënteerdedatabases, kortweg object bases, worden objecten inte-

graal opgeslagen, dus zowel de gegevens als het gedrag (code). Er is geen verta-
ling naar records of rijen nodig en ook is transformatie van relaties overbodig.
Aangezien in RUP eigenlijk altijd met Classes en dus met objecten gewerkt
wordt, is dit de meest eenvoudige manier voor het verkrijgen van persistentie.
Bij gebruik van een object base is er geen verschil (merkbaar) tussen objecten
in memory en objecten die zijn bewaard. Persistentie is een eigenschap van het
object. Door die eigenschap aan te zetten, zorgt de OBMS voor alle overige
zaken.
Op deze manier zijn in een objectgeoriënteerd systeem bij voorkeur de persi-

stentie gerealiseerd. Er worden extra Classes ontworpen (niet in het Analysis
Model, wel in het Design Model), die belast zijn met de persistentie. In een
gelaagde Architectuur maken deze Classes ook geen deel uit van de business
logic-laag, maar van de dichter bij de hardware staande datalaag.
9 Persistentie
De ideale situatie van een object base komt in de praktijk nog steeds weinig
voor. Hoewel Gartner in 1998 voorspelde dat in 2003 de omzet van OBMS'en
die van RDBMS'en zou overtreffen, is dit niet uitgekomen. Verreweg de mees-
te bedrijven gebruiken relationele databases. Een mogelijke reden hiervan is
dat 00-systemen overweg kunnen met relationele databases, hoewel daar wel
veel voor moet worden geregeld. Traditionele systemen die gebruikmaken van
relationele systemen worden niet onmiddellijk uitgefaseerd omdat er ergens in
het bedrijf een 00-systeem ontstaat. Deze traditionele systemen worden mis-
schien wel op termijn vervangen. Overgang naar een OBMS is voor de nieuwe
00-systemen een eenvoudige wijze om tot persistentie te komen. Traditio-
nele systemen moeten echter aangepast worden en dat is een onoverkomelijke
horde gebleken.
Daarnaast is het zo, dat de producenten van de meestgangbare RDBMS-sys-

temen wel degelijk de voordelen van object bases hebben ingezien. Oracle
8 bijvoorbeeld, een relationele database, ondersteunt abstracte datatypen, ob-
jectviews en objecttabellen.
Relationele databases
Bij gebruik van een RDBMS wordt uitgegaan van het Class Diagram, dat in
een logisch datamodel en vervolgens in een databaseschema wordt omgezet.
Het Class Diagram is leidend. Het databaseschema is veelal niet een I:I-af-
beelding van het Class Diagram; er is dus sprake van transformatie. Deze
transformatie moet vanwege eisen van flexibiliteit buiten de entity-objecten
blijven. De Database Designer, geconfronteerd met performanceproblemen,
zal het databaseschema in zekere mate normaliseren. Dat kan pas gedurende
volgende iteraties nodig blijken. De bulk aan gebouwde software moet door
database- schemawijziging niet beïnvloed worden.
Ook nu worden alleen de gegevens van de objecten in de kolommen van de da-

tabase weggeschreven. Het vertalen van relaties tussen objecten onderling en
de inheritance-relatie tussen Classes naar relaties in de database vergt bijzon-
dere aandacht. In een relationele database worden deze relaties met behulp van
identificerende gegevens weergegeven. Dit houdt in dat deze relaties indirect
zijn vastgelegd in de relationele database. Bij het creëren van objecten moeten
de relaties in de vorm van identificerende gegevens weer vertaald worden naar
directe objectverwijzingen. Ook dit is de taal van Classes in de datalaag.
Het gebruik van SQL voor het wegschrijven en inlezen van objecten (het save/
load-protocol) is sterk aan te raden, aangezien SQL door de meeste commer-
ciële relationele databases wordt ondersteund. Ook het gebruik van deze SQL
moet worden geëncapsuleerd, want diverse leveranciers van relationele pak-
ketten hebben elk toch weer hun eigen subdialect.
Voor het vertalen van objecten naar een relationeel model zijn diverse zoge-
naamde object-relational frameworks voorhanden. Het idee achter zo'n frame-
work is dat de fysieke dataopslag geëncapsuleerd wordt, zodat de applicatie
geen rekening meer hoeft te houden met de specifieke eigenschappen van die
data-opslag. Tussen de fysieke opslag en de objecten zit verder een transfor-
matielaag, die de objecten transformeert naar het relationele model. Figuur 9.8
geeft het principe weer:
9 Persistentie
Business Object Model
Laag eigenschappen:
- Compacte interface
- Object-relationele vertaling
- Ge-encapsuleerde data-opslag
Relationeel Database Model
Figuur 9.8: Transformatie van objecten naar Relationeel Model
In Java bevat de EJB (Enterprise Java Bean) Container ook een t001 om een-
voudige mappings van objecten naar relationele data (vaak afgekort tot O/R
mapping) te maken. Een DBMS als Oracle 8i wordt tegenwoordig geleverd
met een versie van deze EJB Container.
Hiërarchische en Netwerk databases

Deze beide databases kunnen als verouderd worden beschouwd. Ze komen
eigenlijk alleen nog voor als legacy-DBMS en worden niet meer gekozen als
oplossing voor nieuw te bouwen systemen. Persistentie binnen deze DBMS'en
vergt specialistische kennis, die hier niet wordt behandeld.
Behalve dat men voor een project een relationele ,database met 00-trekken
zou kunnen kiezen, bestaat natuurlijk ook de mogelijkheid van een hybride
oplossing. In zo'n geval wordt bijvoorbeeld een RDBMS als primaire oplos-
sing gekozen, maar voor een onderdeel van de applicatie met veel complexe
objecten zou een OBMS kunnen worden gebruikt.
ecten in een Watioiaele Database

Veelal zal de DBA te maken hebben met een relationele database en derhalve
zal hij moeten beslissen hoe een Class is om te vormen naar een tabel in de
database. Het kan ook dat de organisatie beschikt over legacysystemen en dat
er aanpassingen of conversie nodig zijn van de Class naar deze legacydatabase
(hiërarchische of codasyl-database). Daar deze conversie zeer specifieke ken-
nis vereist, wordt deze niet besproken.
9 Persistentie
Fabrikant Model
Figuur 9.9: Voorbeeld van schematechniek voor een database
De notatie van de schematechnieken voor een database kan afwijken van die
van het Class Diagram. Maar zoals uit het voorbeeld blijkt, is er veel verwant-
schap met het Class Diagram. In het diagram van figuur 9.9 kan een Eigenaar
meerdere Auto's bezitten en heeft een Auto altijd precies één kenteken en hoort
een kenteken bij precies één auto et cetera.
Voor de werking van relationele databases is kennis van de achtergrond en het

ontstaan van dit soort databases nodig. Essentieel is ook het normaliseren van
gegevens, omdat dit een belangrijke aanpak is om attributen zo te verdelen
over verschillende tabellen dat gegevens consistent zijn en blijven.
Algemeen wordt voor een Design Class van het type Entity een tabel in de
database gemaakt. De Class Arrondissement uit de case bevat een aantal at-
tributen zoals arrondissementcode, naam, omvang, het aantal notarissen en de
verwijzing naar de desbetreffende notarissen. Deze Class kan worden omge-
vormd naar een tabel Arrondissement.
De attributen worden kolommen in de tabel, met uitzondering van de verwij-

zingen naar de desbetreffende notarissen. Hiervoor kan een aparte relatietabel
ArronNotaris worden gedefinieerd, waarin per notaris een voorkomen wordt
opgenomen met de sleutel (key) van de notaris en de sleutel van het arron-
dissement. Als een notaris in meerdere arrondissementen kan werken, dan
komt dit deel van de sleutel meerdere keren voor. Is een notaris werkzaam in
precies één arrondissement, dan mag de combinatie van de sleutels notaris en
arrondissement precies één keer voorkomen. Voor deze regel kan de Database
Designer een constraint definiëren en deze specificeren zodat de iedere keer
als een occurence wordt toegevoegd, deze regel wordt gecontroleerd.Nog een-
voudiger is om de sleutel van de tabel ArronNotaris te beperken tot notaris.

Dat betekent dat de relatie tussen ArronNotaris en Notaris van het type I:I is.
De Database Designer kan nu beslissen deze tabellen samen te voegen en in
plaats van een constraint op de relatietabel ArronNotaris, in de tabel Notaris
een foreign of verwijzende key op te nemen met het arrondissement. Deze
laatste aanpak levert minder joins op en is daardoor sneller. Daarnaast wor-
den constraints op een primaire sleutel en foreign key door de meeste recente
databases goed ondersteund. Hier staat tegenover dat het toevoegen van veel
verwijzende keys vertraging oplevert op bij het veelvuldig toevoegen of wijzi-
gen (mutatiegraad)van de tabellen.
Voor classes die in het Design Model I:N associaties bevatten, kan deze aan-
pak ook gevolgd worden.
Bij Classes die in het Design Model een associatie hebben die aan beide as-
sociatie-einden een multipliciteitbovenwaardehebben van N, is het invoeren
van een relatietabel een veeltoegepaste oplossing.
Als de Class Notaris minstens I associatie heeft met Class Zaak en aan een
Zaak door meerdere Notarissen kan worden gewerkt, dan kan dit in het data-
basemodel omgezet worden door een tabel NotarisZaak te introduceren, die
minimaal de key Notaris en de key Zaak bevat. Deze twee keys vormen samen
de primairy key van de tabel NotarisZaak.
In het Design Model kan een Design Class erven van een abstracte,class, bij-
voorbeeld van de abstract Class Notaris.
Zaak
o..*
Figuur 9.10: Voorbeeld van een Design Class die erft van een abstracte class
9 Persistentie
Overerving kan in een relationele database op drie manieren worden opge-

lost:
Alle attributen van de superclasses en de verschillende subclasses komen

in een tabel. In het bovenstaande voorbeeld dus een tabel Notaris met alle
attributen van zowel Notaris, KandidaatNotaris, EigenaarNotaris en Jus-
titieelNotaris met per occurence de constraint dat een aantal velden niet
mag worden gevuld. Alleen de velden uit Notaris moeten altijd een waarde
hebben. Deze oplossing zal worden gebruikt als er maar een beperkt aantal
subclasses is met slechts enkele attributen, omdat anders een zeer grote
tabel ontstaat die performanceproblemen oplevert.
Er wordt per subclass een tabel gecreëerd met de attributen van de super-
class en de attributen van de subclass. In casu een tabel KandidaatNotaris
die alle attributen bevat van Notaris en alle attributen van KandidaatNota-
ris, naast een tabel EigenaarNotaris et cetera.
Er wordt een tabel gecreëerd voor elke subclass en een aparte voor de su-
perclass. In de tabel van de subclass wordt een verwijzende sleutel opge-
nomen naar de overeenkomstige occurence in de supertabel. Verder is de
constraint dat de sleutel uit de supertabel ook voorkomt in een van de an-
dere tabellen, maar dan ook precies één keer. Hoewel deze aanpak geheel
conform de theorie is, heeft hij als nadeel dat het opvragen van gegevens
of onderhoud van gegevens altijd eist dat een of enkele tabellen worden
gejoined.
Tot slot komt in het Design Model vaak een composition voor. Dit betekent dat
het gehele object is samengesteld of bestaat uit één of meer andere objecten.
Het is voor de Database Designer heel belangrijk te beslissen welke oplossing
hij wil toepassen. Veelal wordt iedere Class weer een tabel. Echter, de delen
van een composition kunnen ook niet zonder dit geheelobject bestaan (life
cycle dependancy).
Volgt de Database Designer de bovenstaande regels dan zal de I:I-relatie tus-

sen composition-object en deelobject vaak aanleiding zijn om te beslissen een
foreign key op te nemen in het deelobject. Dat betekent echter dat het gehele
object geen kennis heeft over zijn samenstelling en dat is exact het omgekeerde
van hetgeen in de Design-fase met composition beoogd wordt. Afhankelijk
van de eisen vanuit het project en de andere toegangseisen kan deze oplos-
sing toegestaan worden. Echter, wil men de 00-concepten ook implementeren
binnen de database, dan zal snel een oplossing met een relatietabel worden
gekozen.
In het bovenstaande is steeds uitgegaan van een nieuw te creëren database.

Dit kan uiteraard voorkomen in de Inception-fase en de eerste iteratie van de
Elaboration-fase.
Bij volgende iteraties zal de Database Designer rekening moeten houden met
het bestaande datamodel. Dat geldt uiteraard ook voor een applicatie die uit-
breidingen moet realiseren op een bestaande database.
Hierbij kunnen de volgende wijzigingen voorkomen:
Er is een nieuwe Class aan het Design Model toegevoegd met een of meer-
dere relaties. In principe betekent dit een nieuwe tabel toevoegen en be-
slissen of de relaties al bestaan. Voor de relatie kan gewerkt worden met
verwijzende sleutels of met relatietabellen.
Er zijn meer subclasses toegevoegd aan het model. Dit betekent een extra
tabel toevoegen en conform eerder aangegeven aanpak verder gaan. Ook
kan het betekenen dat het hanteren van variant één (alle subclasses in een
tabel) niet effectief meer zal werken en een van de andere varianten geko-
zen moet worden.
Door het toevoegen van extra specialisatie in het Design Model kan een
Concrete Class gewijzigd zijn in een Abstract Class met subclasses. Ook
deze aanpassing zal betekenen dat een keuze moet worden gemaakt over de
implementatie van de overerving.
In het Design Model zijn bij verschillende classes nieuwe attributen toege-
voegd. Dit levert een eenvoudige aanpassing. De Database Designer voegt
een kolom toe aan de desbetreffende tabel. Hij kan zelfs al aangeven wat de
defaultwaarde moet worden voor dit attribuut, waardoor meteen alle attri-
buten een waarde bevatten en constraints als Not Nul1 in de database geen
problemen geven bij de conversie. Daarnaast moet de Database Designer
controleren of het toegevoegde attribuut niet een verwijzende sleutel is naar
een andere tabel. In dat geval zal hij moeten beslissen of het DBMS deze
verwijzende sleutel zal controleren en beheren (extra index definiëren en
aanpassen van het schema) of dat deze controle anders geregeld wordt (via
de applicatie zelf).
In het Design Model is er tussen een overervingsstructuur een niveau toe-
gevoegd. Dit komt voor als tussen de superclass en de reële subclasses een
extra superclass wordt gevoegd. Voorbeeld Notaris wordt toegevoegd en
gaat ook nog erven van Persoon. In wezen worden nu de regels van overer-
ving weer toegepast.
Wanneer de Design Classes zijn omgezet naar een of meerdere classes,
kan de Database Designer starten met de definitie van het databaseschema
of dit laten genereren. Hierbij zal hij gebruikmaken van de gegevens over
toegang, gebruikswensen en eisen ten aanzien van performance. Veel van
deze gegevens zijn verzameld en terug te vinden in de Requirements, de
beschrijvingen van de Class en bij de Mechanisms. Op basis van deze ge-
gevens kan besloten worden om deels te denormaliseren (redundante infor-
matie toevoegen om performance te verbeteren; tabel inlezen in de applica-
9 Persistentie
tie om daarmee snelheid bij het zoeken in de database te bevorderen; extra

indexen toevoegen et cetera). RUP biedt hiervoor diverse aanwijzingen.
Het ontwerpen van een database en de mechanismen om in deze databases

gegevens op te slaan, zijn activiteiten die reeds in de Inception-fase kunnen be-
ginnen. Zo is het goed mogelijk dat een applicatie een uitbreiding of migratie
is van een bestaande applicatie. In dat geval zal het bestaande datamodel vaak
als uitgangspunt voor het datamodel worden genomen. Als van een bestaande
database geen (goed) datamodel voorhanden is, dan kan dat zelfs reverse-en-
gineered worden met tools als Rational Rose en Rational XDE. Elementen uit
het datamodel van de bestaande database kunnen dan - zeker in het geval van
een Proof of Concept - worden omgezet in Design Model- elementen. Deze
vorm van reuse kan de ontwikkeling een stuk sneller laten verlopen.
Er is nog een andere reden om reeds tijdens de Inception rekening te houden

met Persistentie. Diverse persistentie-issues zijn namelijk van belang voor de
architectuur. Een paar voorbeelden.
Distributiebeslissingen: gegevens worden mogelijk op meerdere plaatsen

opgeslagen. Bovendien is het niet zeker dat die database op iedere locatie
van hetzelfde type is.
Concurrency en locking: meerdere gebruikers die tegelijkertijd dezelfde
data willen benaderen of wijzigen.
Caching issues: oude data wordt vastgehouden in een cache, terwijl die
data 'onder water' reeds is gewijzigd.
Het bestaan van many-to-many relaties tussen classes: het rechtstreeks
vertalen van zulke relaties in het fysieke datamodel leidt al snel tot perfor-
manceproblemen.
Als dergelijke issues spelen binnen een project, zal de Software Architect hier
direct rekening mee moeten houden. Dit zou zelfs tot gevolg kunnen hebben
dat de keuze voor een bepaald persistentiemechanisme al in deze fase wordt
vastgelegd.
Je kunt je natuurlijk afvragen in hoeverre de Architect voldoende database-

expertise heeft om dit soort beslissingen te nemen. Het is dus wenselijk dat in
zo'n geval ook de Database Designer bij de architectuur wordt betrokken.
Elaboration
Tijdens de Elaboration-fase moeten in ieder geval de te gebruiken mechanis-
men voor persistentie worden gedefinieerd.Deze vormen een belangrijke basis
voor het ontwikkelwerk tijdens de Construction-fase en moeten tegen die tijd
beschikbaar zijn voor de ontwikkelaars.
Als tijdens de Elaboration de voor de architectuur belangrijke Use Cases wor-

den uitgemodelleerd, zullen Design Classes en dus ook de persistente Design
Classes bekend worden. Zo'n persistente Class kan dan worden omgezet in
een Data Model-element door de Database Designer. Aan het einde van de
Elaboration-fase moeten zo de belangrijkste Data Model-elementen bekend
zijn: tabellen, indexen, primary en foreign keys.
Construction en Transition
In de Construction- en Transition-fase is het niet de bedoeling dat er nog grote
wijzigingen aan het Data Model plaatsvinden. Als er zowel een Logical als
een Physical Model gemaakt is, zou in ieder geval het Logical Model niet of
nauwelijks meer moeten veranderen.
Tijdens de Construction- en Transition-fase wordt het Data Model vooral be-

waakt en geoptimaliseerd. Zo kan bijvoorbeeld worden besloten om de da-
tabase te denormaliseren of om indexen toe te voegen zodat de performance
wordt verbeterd.
Het is natuurlijk mogelijk dat er een meer structurele wijziging komt naar
aanleiding van een change-request, of anders naar aanleiding van een test-
resultaat. Zelfs in de Transition-fase kunnen er dan nog wijzigingen aan het
Physical Data Model zijn.
Hoe dan ook is het zaak, dat de Database Designer te allen tijde het Data Mo-
del gelijk laat lopen met de fysieke database. Vaak worden wel kleine updates
aan een fysieke database gedaan, maar wordt vergeten om deze aanpassingen
direct te verwerken in het Data Model. Dit kan grote (negatieve) gevolgen heb-
ben bij latere onderhoudswerk.
De componenten die onder andere persistente Classes gebruiken, worden door

de Implen mter gebouwd. Het Data Model moet bovenal duidelijk maken hoe
iedere per: istente Design Class opgeslagen wordt: is er een bijbehorend struc-
tuurelement in de fysieke database? Of worden de gegevens van een persistente
Class verspreid over diverse structuurelementen. In dat geval zal er altijd ook
een logisch datamodel als tussenstap gemaakt zijn.
9 Persistentie
De persistentiemechanismen moeten aan het eind van de Elaboration-fase

transparant zijn voor de Implementer. Met andere woorden: als het mechanis-
me er eenmaal is, moet hij een 'method' als Save, Delete of Retrieve kunnen
aanroepen zonder zich druk te hoeven maken over hoe die actie verder wordt
afgehandeld met het gebruikte data-opslagmedium.
De Designer en Implementer moeten ervan opaan kunnen dat het Data Model
volledig bijgewerkt is tot en met de laatste (zelfs kleine) wijziging. Veel fouten
worden gemaakt doordat een Implementer een component ontwikkelt die ge-
baseerd is op een niet-bijgewerkt datamodel. Regelmatig moet de Implementer
in zo'n geval een deel van zijn werk weggooien en het opnieuw uitvoeren met
het juiste Data Model; een verspilling van tijd.
We zagen in dit hoofdstuk hoe je persistentie van gegevens in een applica-

tie moet regelen. Als er bijzondere eisen worden gesteld aan de technische
omgeving, moet hier al tijdens het Architectuurontwerp in de Inception-fase
rekening mee gehouden worden. In de Elaboration-fase moeten de persisten-
tiemechanismen voor dingen als opslaan en zoeken van gegevens gereed zijn.
Ook moet de databasestructuur aan het einde van die fase bekend zijn. In de
fasen daarna wordt het Data Model bewaakt en indien nodig bijgewerkt als
reactie op een change request of een testresultaat.
Als mechanisme voor persistentie zal meestal gekozen worden voor een rela-
tioneel databasemanagementsysteem (RDBMS), maar ook een Object Base
Management System (OBMS), persistentie via losse bestanden of In-Memory-
Storage horen tot de mogelijkheden.
Hoe dan ook moet er een zo flexibel mogelijk mechanisme voor de persistentie
zijn, zodat bij een eventuele wijziging in de fysieke opslagmethode niet een
groot deel van de applicatie-architectuur gewijzigd hoeft te worden.
Het mechanisme voor het communiceren van gegevens in Client/Server-ap-

plicaties lijkt sterk op dat van persistentie van objectgegevens. De buffer-class
(zowel de ASCII als de encrypted variant) kunnen zelfs hergebruikt worden.
Of voor een standaardframework voor persistentie wordt gekozen of voor een

eigen ontwerp, hangt sterk af van de projectsituatie. Voor een gemiddeld pro-
ject (voor zover dat bestaat) zal een standaard framework vaak de betere oplos-
sing zijn.
Eric J. Naiburg en Robert A., Maksimchuk UML For Database Design. Ad-
dison-Wesley Longman, 2001. ISBN 0201721635.
Ambler, S., The design of a Robust Persistente Layerfor Relational Databases.

White Paper, 2000. www.ambtsoft.com
Uit het Rational Unified Process:

C6ncepts: Relational Databases and Object Orientation.
Guidelines: Forward-Engineering Relational Databases.
In dit hoofdstuk staat waarop je moet letten bij het bouwen en hoe je ervoor
zorgt dat het resultaat voldoet. Vervolgenswordt ingegaan op de voordelen die
een componentgebaseerde architectuur levert en welke rol de Implementer en
de Integrator vervullen bij de ontwikkeling van componenten. Daarna wordt
het nut en het gebruik van prototypes toegelicht en volgt een beschrijving van
de diverse soorten van prototyping. Ook wordt benadrukt dat het werk van
de Implementer niet in de Construction-fase begint, maar dat al tijdens de
Inception-fase de Implementer een signiJicante rol kan vervullen. Tenslotte
komen het wat, waarom en de frequentie van het integreren van componenten
aan de orde.
Wat in het Design Model is ontworpen, gaat in het Implementation Model ge-
bouwd worden. In plaats van direct te gaan programmeren, is het vaak zinvol
ook een Implementation Model te maken. In het Implementation Model wordt
op een gedetailleerd niveau nagedacht over de structuur van de implementatie,
de interfaces en de afhankelijkheden, de verschillende subsystemen, en na-
tuurlijk krijgen ook de componenten zelf er hun plaats.
Hoe kom je nu uitgaande van de Use Cases uit het Use Case Model en de
Supplementary Specifications tot de uiteindelijke executeerbare code? Elke
Use Case is uitgewerkt in een Use Case Realization. De interne communicatie
tussen de objecten in een Use Case Realization is met één of meer interactie-
diagrammen (de Sequence Diagrams of de Collaboration Diagrams) in kaart
gebracht. Daarnaast is zonodig per Use Case een VOPC (View Of Participa-
ting Classes) gemaakt, waarin de classes - en hun relaties - staan die nodig
zijn voor deze Use Case. Elke Use Case wordt op deze manier uitgewerkt tot
samenwerking tussen Analysis Classes.
Per Analysis Class is door de Software Architect reeds besloten hoe deze Ana-
lysis Class in het Design Model technisch getransformeerd wordt tot één of
meer design elements. Het design element kan zijn: een Design Package, een
Subsystem of een Design Class. Elk design element is uiteindelijk input voor
de codering door de programmeur. Die code wordt gegroepeerd en executeer-
baar gemaakt (compile & build).
Figuur 10.1: Uitwerken van Use Case tot code
De worker die daadwerkelijk gaat bouwen, heeft vaak een of meer van de
volgende rollen: Designer, Implementer of Integrator. Het werk van de Inte-
grator komt in de volgende paragraaf aan bod. In de praktijk gebeurt het veel
dat iemand met de rol van Implementer ook nog de rol van Designer heeft en
beslissingen neemt over bijvoorbeeld de structuur van een package. Er wordt
nauw samengewerkt met de Architect, want deze beschrijft op hoofdlijnen de
structuur van het Implementation Model en de verschillende interfaces.
Belangrijke input voor een Implementer zijn de Use Case-specificaties, het

Design Model (met Use Case Realizations) en de Programming Guidelines.
Er treden vaak grote verschillen op in de diepgang of de mate van detaillering

van de input voor hetgeen er gebouwd moet worden. In wat kleinere projecten
met minder tooling zijn het Design Model en Implementation Model redelijk
summier. Als het project team over uitgebreidere tooling beschikt kan van-
uit deze modellen code worden gegenereerd. Dan is hetgeen geïmplementeerd
moet worden nog specifieker gemaakt, maar ook dan is het nodig om, voordat
er geprogrammeerd wordt, even de Use Case Realization te lezen. Dit geeft
namelijk veel houvast.
Wat moet je als Implementer doen als er te weinig Design Model dan wel
Implementation Model is? Je kunt dan kiezen om de pet van de Designer op te
zetten, maar doe dat dan welbewust en lever de noodzakelijke artefacts op. Je
kunt ook overwegen het ontwerp terug te sturen naar de Designer. Een andere
mogelijkheid is om in je hoofd te ontwerpen, terwijl je programmeert. Wat je
ook doet, maak de keuze bewust!
Dat is best een lastige vraag, maar toch is daar een heel eenvoudig antwoord
op. Maak eerst de Test Case en programmeer dan de functionaliteit. Als de
Test Case slaagt, heb je iets gebouwd wat OK is. Deze aanpak heet het 'test-
first-design' en is beschreven in RUP (de RUP-kennisbank versie zoo3 bevat
een PDF-bestand: RUPtXP Guidelines: Test-first Design and Refactoring).
Test-first design is ook een van de pijlers van Extreme Prograrnming (XP).
Het gebruik van een automated t001 als Junit of Nunit is zeker aan te bevelen
bij een test-first-aanpak (zie het hoofdstuk Testen).
Ook de aanpak van het programming by contract-concept kan hier verhel-

dering verschaffen. Want hetgeen gebouwd moet worden, is al grotendeels
beschreven. De method signatures en de return types zijn al bekend, de inter-
faces zijn bekend, de stubs zijn gegenereerd en deze moeten nog ingevuld en
geïmplementeerd worden.
Het antwoord op de vraag 'wat moet ik bouwen?' is ook afhankelijk van de fase
waarin je zit. Het doel van bouwen aan een proof of concept in de Elaboration-
fase is heel anders dan bouwen aan het werkelijke systeem in de Construction-
fase. In deze context is 'goed is goed genoeg' een toepasselijke omschrijving.
Houd altijd het doel in de gaten van als je aan het bouwen bent.
Er zijn vele definities van het begrip component. De definitie van een compo-
nent binnen RUP is niet zeer strak. Een component is een stuk software dat
redelijk onafhankelijk is, op zichzelf staat en een duidelijke functie heeft die is
vastgelegd in de interface. Een component kan op meerdere plekken gebruikt
worden.
Binnen RUP staat een componentgebaseerdearchitectuur centraal (een van de

zes best practices, zie hoofdstuk 'RUP-Basis'). Deze architectuur biedt name-
lijk oplossingen voor vele problemen rond softwareontwikkeling.
Een flexibele architectuur
zorgt voor een betere aanpasbaarheid en vervangbaarheid van onderdelen

(componenten);
0 biedt mogelijkheden tot hergebruik van software;
Let op dak het ontwikkelen vm herbruikbare componentBa geen doel op

zichzelf is. Bet werkt doorgaans beter om eerst die hnctionali-teit in de
campomt te bouwen die je nodig hebt en later je af te vragen dje het
nog generieker kan maken (refactoren van de componentj.
biedt mogelijkheden om aan te sluiten op standaarden en reeds beschikbare

componenten;
biedt mogelijkheden om software te ontwikkelen met verschillende tools
en technologieën (.Net- en Java-componenten die elkaar oproepen);
biedt mogelijkheden voor parallelle ontwikkeling en scheiding van verant-
woordelijkheden in projecten;
vereenvoudigt het integreren van de afzonderlijke stukken software;
Een unittest kan worden uitgevoerd op de eigen component, voordat

die in de integratietest in het subsysteem getest wordt. Fouten die in de
samenhang zitten zijn zo eenvoudig te onderscheiden van fouten in de
component zelf.
0 biedt de mogelijkheid om een groot systeem niet in één keer te bouwen,

maar in delen, in verschillende iteraties.
Het is goed om je af te vragen of een bepaalde component al door een ander

gebouwd is, zowel binnen als buiten je project, zowel niet-commercieel als
commercieel. (b.v. Oracle business components).
Eén van de Developer-rollen is de rol Implementer. De Implementer ontwik-

kelt en test componenten. Als een component ontwikkeld is, wordt hierop eerst
de unittest uitgevoerd. Dit kan door middel van het bouwen van testcompo-
nenten om de interface van de component te testen. Indien alle individuele
componenten van een subsysteem gebouwd en getest zijn, kunnen deze com-
ponenten door de Integrator gecombineerd worden tot een (sub)systeem door
middel van een Build (een executable versie van een of meer componenten) in
de testomgeving (Integration Workspace).
De integrator is er verantwoordelijk voor dat ontwikkelde artefacts1 compo-

nenten goed gearchiveerd worden. Dit doet hij door middel van het creëren van
baselines. (zie Hoofdstuk 'Configuratiemanagement en Changes')
Bij het ontwikkelen van componenten is het van belang om de ontwikkelstan-
daarden, de zogenaamde programming guidelines (bijvoorbeeld afspraken
over interface-definities, programmeerstandaarden, afspraken over commen-
taar) te volgen. Dit bevordert de eenduidigheid en de overdraagbaarheid.
10 Implementeren en integreren
Het is bij het implementeren en integreren dus belangrijk uit te gaan van het
bestaande en niet steeds opnieuw trachten het wiel uit te vinden.
In RUP worden prototypes ingedeeld naar verschillende invalshoeken. Zo on-

derscheiden we als we het doel van het prototype beschouwen:
Het behavioral prototype.

Met dit prototype wordt een deel van het gedrag van het systeem uitge-
werkt.
Het structural prototype.
Dit onderzoekt een architectureel of technisch probleem.
Als je kijkt naar de levenscyclus dan zijn er twee soorten prototypen name-
lijk:
o Het exploratory prototype.

Dit prototype wordt weggegooid nadat het doel is bereikt.
Het evolutionary prototype.
Dit prototype wordt stap voor stap uitgebouwd en groeit uiteindelijk uit tot
het werkelijke systeem.
In een project kun je prototypes in verschillende disciplines en soorten tegen-

komen.
avioral) prototypes kun je gebruiken in Business Modeling,

in Requirements en in Analysis and Design. Daarmee kun je aantonen dat een
proces goed verloopt en schermverloop of lay-out zijn afgestemd op de wensen
van de gebruiker, of je gebruikt het om de requirements beter te specificeren.

Het is niet eens per se noodzakelijk dat deze prototypes met behulp van de uit-
eindelijk gekozen ontwikkeltools gebouwd worden. Enkele voorbeelden van
deze soort zijn:
User-interface
Alleen de voorkant is geïmplementeerd, de achterkant wordt gesimuleerd.
Het kan bijvoorbeeld zo zijn, dat wat je ook invoert in het systeem, er altijd
eenzelfde uitkomst uit komt rollen, of een beperkt aantal mogelijkheden.
Zo kun je met de gebruiker de User-interface testen. De gebruiker kan
zeggen of de knoppen en de edit-boxen op de juiste plek staan en of de
volgorde van de schermen volgens wens is.
Storyboard
Dit (optionele) RUP-artefact kan vervaardigd worden om een opeenvolging
van acties van een systeem uit te beelden. Dit kan in de vorm van een pa-
pieren prototype of als PowerPoint presentatie. Zo test je met de gebruiker
of de juiste werkwijze geïmplementeerd wordt.
Technische Proof of Concepts. Om een bepaald technisch risico te ondervan-

gen, kan een product of combinatie van producten getoets worden, nog voordat
is vastgesteld wat precies de functionaliteit is die met deze producten gereali-
seerd moet worden. Voor de proef wordt functionaliteit verzonnen. Vaak zijn
performance-issues het onderwerp van dit soort prototypes. Zo bewijs je bin-
nen het project dat de gekozen technische oplossing werkt, nog voordat veel
tijd in de werkelijke implementatie, die gecompliceerder is, wordt gestoken.
Technische Proof of Concepts (Architectural Proof of Concepts) worden ge-
maakt in de Inception- of Elaboration-fase.
roof of Concepts. Er wordt een dummy-applicatie gebouwd.

Zo wordt voor de organisatie getest of het bedrijfsproces waarin de applicatie
gebruikt gaat worden echt werkt. Maar de omvang blijft beperkt en er is geen
risico, omdat het proces alleen gespeeld of gesimuleerd wordt, maar niet in
productie wordt genomen. Een procesmatige Proof of Concepts (Behavorial
prototype) kan worden gebruikt in de Elaboration-fase binnen de Business
Modeling- en Requirements-discipline.
es. Het kan zijn dat de ontwikkelomgeving die gekozen is voor

een project, nieuw is voor het gros van de projectleden. Dan kan het maken
van een prototypeapplicatie,met verzonnen functionaliteit een trainingstraject
zijn, zodat beter voorbereid met het echte traject gestart wordt. Oefenprototy-
pes kunnen worden gebruikt in de diverse fasen van het project.
Met prototypes wil je iets testen. Dat kan zijn of de performance acceptabel is,
maar het kan ook zijn dat je met de gebruiker wilt uitzoeken hoe het systeem
moet werken. Een prototype is een krachtig hulpmiddel, omdat je zaken waar
je tot dan toe waarschijnlijk alleen in tekst over gecommuniceerd hebt, heel
concreet maakt. Het voordeel is dat je test, nog voordat je veel tijd en geld hebt
geïnvesteerd in het bouwen van een compleet systeem.
Met welk doel je een prototype ook maakt, stel vooraf de evaluatiecri-
teria vast waaraan je het prototype achteraf gaat toetsen.
Wat doe je met een prototype nadat je de test hebt uitgevoerd? Sommigen zijn
hier heel rigoureus in. Je kunt na gebruik, en dat kan ook een iteratief proces
zijn met meerdere versies van het prototype, het prototype weggooien en op-
nieuw beginnen met het bouwen van het systeem. Een andere benadering is
om bepaalde elementen uit een prototype te gebruiken als startpunt voor het te
bouwen systeem. Het laatste bevat wel een risico. Het bouwen van een proto-
type is niet gericht op het bouwen van een net en onderhoudbaar systeem. Het
kan dus een rommeltje zijn en als dat niet wordt hersteld zal dat een nadelige
invloed hebben op de onderhoudbaarheid van het productiesysteem.
De Implementer ontwikkelt en test componenten. De Implementer werkt ech-

ter niet alleen in de Construction-fase. Ook tijdens de Inception-fase kan de
Implementer een specifieke rol vervullen. Welke rol is dat dan?
De Inception-fase kent alle disciplines, omdat het mogelijk is om dan al onder-

delen van de applicatie, of een zeer vroege versie van het systeem, te ontwik-
kelen en te implementeren. Vaak wil de Software Architect in de Inception-
fase een Proof of Concept leveren; hij mag zelf software bouwen in zo'n geval.
Of de architect dat (alleen) kan staat niet op voorhand vast. Hij is immers niet
uitgekozen om zijn ervaring met de beschikbare of gekozen ontwikkeltools.
Daarom is ondersteuning door een DesignerIImplementer veelal gewenst.
Het resultaat van bouwen in de Inception-fase is altijd een (zeer) tijdelijk re-
sultaat. Niet per se wegwerpsoftware, maar dan toch zeker software met een
beperkte houdbaarheidsdatum. De oplossing is vaak ook niet geschikt voor
onderhoud, maar juist bedoeld is om door een volgende versie of release ver-
vangen te worden.
Er wordt wel wat opgeleverd. Dat kan software zijn, maar als het bijvoorbeeld
gaat om performance-testen, dan kan dat ook heel goed rekenwerk - achter het
bureau - zijn geweest. Dit rekenwerk is ook een Implementation artefact van
de Inception-fase.
Redenen om te bouwen in deze fase zijn de volgende.
Er is grote onzekerheid of de uiteindelijke applicatie zal voldoen of geac-

cepteerd zal worden. Dan is proefdraaien met een vroege versie of een
prototype een goede testcase. Het hoeft niet eens echt software te zijn.
Er is onzekerheid of implementatie wel mogelijk is op de gekozen stan-
daarden voor ontwikkelplatform en hardware. Een vroege implementatie
geeft alle gelegenheid alles te testen.
Onervarenheid van het ontwikkelteam, zodat het slim is een deel van alle
flows vroeg uit te voeren, zodat iedereen kan wennen wat het werk is.
Een dergelijke aanpak staat bekend als Proof of Concept (PoC).
Als de Inception-fase wordt gebruikt om software te maken, is het wel belang-

rijk dat de inspanning van de implementatiediscipline beperkt wordt. PoC's
duren ongeveer een maand en als ze langer duren zijn het eigenlijk gewoon
complete projecten.
Het hoeft overigens niet eens van tevoren duidelijk te zijn welke fysieke vorm
de implementatiezal hebben in de Inception-fase. Het kan zeer goed pas tijdens
die fase duidelijk worden wat handig is, en dan is het vaak weer afhankelijk
van de bemensing op het project wat nog mogelijk is. In feite moet de project-
behoefte natuurlijk de gewenste bemensing bepalen, maar in de praktijk loopt
dat wel eens anders en kun je niet op elk moment de bemensing aanpassen.
Hier is het hebben van verschillende rollen door medewerkers weer handig,
want dan kun je nog laat besluiten wat je gaat doen.
Het nut van componenten is reeds aangegeven. Deze componenten worden

geïntegreerd. Waarom vindt de integratie plaats, hoe vaak en wanneer? Daar
geeft deze paragraaf antwoord op.
Integratie van componenten is een vereiste in projecten waar grote systemen

opgedeeld worden in kleinere onderdelen, in componenten. Pas door te inte-
greren kun je vaststellen of alle onderdelen goed samenwerken.
Bij integratie van componenten kan ervoor gekozen worden om gefaseerd

grote delen van het systeem te integreren. Bij deze aanpak worden de verschil-
10 Im~lementerenen inteareren
lende functies eerst compleet uitgewerkt en pas als ze gereed en getest zijn,
worden ze toegevoegd aan de reeds bestaande onderdelen van het systeem.
Voordeel van deze manier van (uitgestelde) integratie is dat je sneller kunt
werken, omdat er minder overhead is. Het nadeel is een extra risico op het
vlak van relaties tussen componenten: pas op een laat tijdstip (het moment van
integratie) wordt ontdekt dat onderdelen niet goed op elkaar aansluiten. Deze
manier van integreren komen we wel vaak in de praktijk tegen.
Een principe in RUP is: risico's direct en vroegtijdig aanpakken. Bovendien

is 'continu toetsen van kwaliteit' in RUP een best practice. Daarom gaat de
voorkeur uit naar een andere aanpak: het incrementeel integreren van compo-
nenten. Hierbij wordt frequent (bijvoorbeeld dagelijks, in de daily build) getest
hoe verschillende componenten integreren. Dit kost tijdens het ontwikkelpro-
ces wat extra tijd, maar kan verrassingen in een later stadium voorkomen.
Zoals aangegeven worden componenten door de Implementer vervaardigd in

een eigen omgeving. De componenten worden op gezette tijden met elkaar ge-
integreerd. RUP onderkent daarvoor de rol van Integrator. In de praktijk wordt
die rol vaak uitgevoerd door de ontwikkelaars zelf of door de Configuration
Manager (CM).
systeem ontwikkel in^ met RUP
In een ontwikkelteam kan de afspraak bestaan dat de ontwikkelaars zelf zorg-

dragen voor integratie. Zij dragen er dan zorg voor dat de componenten worden
getest in een unit-test en correct samenwerken met alle andere componenten.
Het is dan de rol van de CM om te zorgen dat alle componenten in een build
samen gecompileerd worden tot een systeem. Dit kan dan getest gaan worden
door het testteam.
Een CM kan ook controle willen houden over het integratieproces door dit
zelf uit te voeren, meestal in de vorm van een daily build waarbij dagelijks het
complete systeem wordt gecompileerd. Met name later in de Construction-fase
wordt dit belangrijk, want op dat moment zou een build een werkend systeem
moeten opleveren. Als de CM deze taak op zich neemt, blijft het de rol van
de ontwikkelaar om een component pas aan te leveren voor integratie op het
moment dat deze correct de unittest heeft doorstaan.
Als gekozen wordt voor een daily build zal zeker een maal per dag een con-
trole plaatsvinden op onderlinge samenhang van componenten. Vooral als dit
buildproces automatisch verloopt, waarvoor de meeste hedendaagse Configu-
ratie Management tools en ontwikkelomgevingen de mogelijkheden bieden,
biedt dit een zekere mate van kwaliteitsbewaking. Als niet wordt gekozen voor
daily builds maar voor integratiecontroles door de ontwikkelaar, kan dit bete-
kenen dat op een laat tijdstip in de Construction-fase wordt ontdekt dat com-
ponenten niet integreren.
Het integreren van de verschillende componenten in een subsysteem gaat op

basis van een Integration Build Plan. Dit is een artefact uit de Implementa-
tion-discipline. Hierbij worden de diverse componenten samengevoegd tot
een testbaar subsysteem. Een subsysteem kan sterk in afmetingen variëren.
In sommige systemen is een subsysteem de database met bijbehorende stored
procedures. In een wat groter project kan een subsysteem een specifieke set
schermen zijn met bijbehorende business logica. Een subsysteem kan zelfs een
enkel brok businesslogica zijn.
Het Integration Build Plan kan dus verschillend van inhoud zijn. In dit plan
staat wanneer welke onderdelen zullen worden geïntegreerd in iedere iteratie.
Het samenvoegen van componenten wordt gedaan door iemand met de rol In-
tegrator. Bij het maken van .NET-assemblies en Java-packages is dit vaak het
maken van de XML-descriptors. In veel IDE's kan dit al geautomatiseerd zijn.
Ook het maken en uitvoeren van een ANT-script is een praktijkvoorbeeld van
het werk van de Integrator: hij voegt classes (components) samen tot subsyste-
men (packages). De unittests spelen hierbij een belangrijke rol (zie Hoofdstuk
Testen).
Nadat de componenten zijn samengevoegd tot subsystemen, kunnen de ver-

schillende subsystemen worden samengevoegd tot één systeem. Hierbij maakt
de Integrator het werkende systeem en zet dit ook in de goede omgeving. De
Integrator maakt op dit moment bijvoorbeeld WAR- of EAR-bestanden en
zorgt voor deployment in de juiste omgeving.
In kleinere projecten met minder specialisatie, beweegt een ontwikkelaar zich

heen en weer tussen de rollen Designer, Implementer en Integrator. Hij doet
een stuk detailontwerp van een component, voegt een method of attribuut toe,
implementeert deze method, compileert zijn package en voert de unittests uit.
Het integratieproces is een heel zorgvuldig karwei. Zeker als er veel handma-
tige handelingen vereist zijn. Vandaar dat een geautomatiseerd buildproces zo
belangrijk is. Als een build- of integratieproces lastig is, zal het vaak worden
uitgesteld zodat inconsistenties en botsende interfaces te laat aan het licht ko-
men.
Het integratieproces moet minimaal bestaan uit: ophalen laatste versies van de
sources, compileren, unittesten, samenvoegen, kopiëren, integratietesten. Als
het integratieproces automatisch verloopt is het eenvoudiger om 'Daily builds'
te maken. In grotere projecten, waar verschillende teams aan verschillende
subsystemen werken, zie je ook wel een wekelijkse build. Van belang is een
vaste periode, die dan als een soort hartslag van het project geldt.
Als er een omgeving is waarin regelmatig builds worden gemaakt, moet bij
het implementeren van een component worden stilgestaan bij de afhankelijk-
heden. Deze afhankelijkheden moeten, om de integratie niet te verstoren, af-
gedekt zijn. Soms is dit niet mogelijk omdat andere onderdelen nog niet klaar
zijn. Dit lossen we op door stubs te gebruiken. Stubs zijn stukjes code die de
interface simuleren. Bijvoorbeeld: op een bepaald moment moet er iets in de
database worden opgeslagen en je krijgt een 'true' of 'fake' terug afhankelijk
van of het gelukt is of niet. Je simuleert dan in de code dat het weggeschreven
wordt en geeft altijd dezelfde return waarde terug. Bij het implementeren van
een component voldoe je dan altijd aan de interface. Òf door de daadwerke-
lijke functionaliteit te bieden (de method bestaat en werkt), òf door de functio-
naliteit te simuleren door middel van een stub.
Deze manier van implementeren is een voorwaarde om iteratief en incremen-

teel te kunnen werken. Ook niet afgeronde componenten kunnen op deze ma-
nier worden geïntegreerd.
Met de kreet 'vit's not worth testing, don't build it', is de essentie van dit
hoofdstuk gegeven. Testen is een veel beschreven discipline, die toch vaak in
de praktijk onder druk komt te staan wanneer kosten en tijd bespaard moeten
worden. Dit hoofdstuk geeft een invulling aan de manier waarop RUP met
testen omgaat en op welke wijze testen een geïntegreerd onderdeel vormt van
een ontwikkelingsproces.
Iedere ontwikkelaar heeft op enig moment te maken met testen. Is het niet in
de rol van Implementer of Integrator, dan wel in de rol van Designer, Analyst
of Tester. De relatie van de Test-discipline met de andere disciplines in RUP is
beschreven in de RUP-knowledge base en wordt derhalve niet verder beschre-
ven. Het belang van testen is algemeen bekend; wie gaat in een nieuwe auto
zitten zonder dat deze eerst uitvoerig aan allerlei testen is onderworpen? Bij de
aanschaf gaat de nieuwe bezitter uit van een goed werkend product. Dit is ook
zo voor een systeem: de gebruiker en de stakeholder gaan uit van een correct
werkend product volgens de opgegeven specificaties. Om hier aan te voldoen
is testen onmisbaar. Voor een gemiddeld project is de ingeplande testtijd mar-
ginaal (of is als eerste wegbezuinigd). Dit is op zijn minst eigenaardig te noe-
men, omdat juist vanuit het testen een reëel beeld ontstaat van het ontwikkelde
systeem. Door testen gestructureerd en in het project in iedere iteratie op te
pakken (conform RUP) geeft de testdiscipline de toegevoegde waarde aan het
project (en aan de andere disciplines) en een bepaalde objectieve beoordeling
van het ontwikkelde product.
In RUP is testen als een aparte discipline opgenomen. Het belang van testen
wordt door RUP benadrukt en is terug te voeren op de best practice 'Continue
verificatie van de kwaliteit'. Door activiteiten uit de testdiscipline uit te voeren
ben je steeds bezig de kwaliteit te beoordelen, te evalueren en aan te geven
welke delen nog verbeterd moeten worden. Dat bereik je door doorlopend,
niet alleen aan het einde van een iteratie, de best practices voor testen toe te
passen:
zoeken en documenteren van fouten in de software;

adviseren om te gewenste kwaliteit te realiseren;
valideren van de gemaakte vooronderstellingen in design en Requirements
door concrete demonstratie;
valideren van de functies uit het software product in vergelijking met het
design;
controleren of de Requirements op de juiste manier zijn geïmplementeerd.
De Test-discipline heeft dus een essentiële taak in het vinden van zwakheden
in het op te leveren software product.
Een Class, component of (sub)systeem zal veelal op verschillende manieren

een test ondergaan en daarmee een bepaald testniveau hebben.
Een bekende indeling is unit-, integratie-, systeem- en acceptatietest. Deze

testniveaus hebben elk specifieke testdoelen. Een unittest bekijkt de kleinst ge-
11 Testen
definieerde testeenheid (bijvoorbeeld een Class of een component) en test of de

gewenste functionaliteit aanwezig is en correct door de test wordt doorlopen.
De acceptatietest daarentegen is een test waarbij in eerste instantie de nieuwe
functionaliteit op juiste werking wordt getest en bovendien wordt beoordeeld
of het systeem bruikbaar is in de doelomgeving.
De gebruikte testspecificaties komen binnen RUP vanuit verschillende bron-

documenten (artefacts). De artefacts hebben verschillende niveaus in het
beschrijven van de specificaties, maar vullen elkaar wel aan op specificatie
gronden. Het is zaak om deze verschillende niveaus in test specificaties terug
te laten komen in de verschillende testniveaus: de vertaling van de verschil-
lende specificaties naar uit te voeren testen vormt een uitdaging die later in dit
hoofdstuk terugkomt. Door de testniveaus te koppelen - aan de verschillende
artefacts ontstaat het V-model van testen.
Figuur 11.1: Het test V-model
In elke testlaag komen testen aan de orde die invulling geven aan de specifi-
caties zoals deze uit de artefacts te voorschijn komen. Het algemene beeld van
testen moet gericht zijn op het beoordelen van het systeem vanuit de gegeven
(test)specificaties. Een tester beoordeelt een systeem specifiek op de imple-
mentatie van de specificaties en niet op wat er is ontwikkeld. Hij test niet wat
het systeem doet, maar wat het behoort te doen. Hiervoor is het noodzakelijk
om de specificaties te koppelen aan de uit te voeren testen. Dit komt later aan
de orde.
i
kJinittest
De unittest is het eerste testniveau binnen elk project. De Test Manager heeft
in zijn testplan reeds nagedacht over invulling van de unittest en zal daarvoor
vaak bij de Developer terechtkomen. Als Developer ben je dus zowel Test De-
signer, Test Analist als Tester. In de rol Test Designer vraag je je af, op basis
van de gebruikte technieken in het project zoals applicatieplatform, infrastruc-
tuur en middleware, op welke wijze de unittest ingevuld moet worden op ba-
sis van de afgesproken diepgang. Gelukkig zijn hiervoor vaak frameworks en
tools aanwezig.
Enkele voorbeelden van frameworks en tools zijn:
Junit of Nunit;
Microsoft Application Center Test;
Rational Teststudio;
Nunit;
Microsoft FXCoP;
Ndoc;
.MS1 (evtueel plus Crystal reports);
Rational XDE Developer en XDE Tester;
Rational ClearQuest (Defects list).
Het is belangrijk om een eigen interne controle te hebbe~n,om de kwaliteit van

je eigen opgeleverde classes te verifiëren. In principe controleert de program-
meur (Implementer) die de software heeft gebouwd, de gebouwde software
zelf en bouwt daarvoor unittest-classes. Het is meestal een snelle manier om
te controleren of een specifiek stuk code of een module volgens verwachting
werkt. Met unittesten wordt van elke method van elke gecodeerde class getest
of deze wel consistent werkt.
Naast de test-classes wordt er een unittestprogramma geschreven. Dit pro-

gramma test alle methods van alle classes. Bij het unittesten wordt ook fou-
tieve input ingevoerd in de desbetreffende classes en wordt gecheckt of dit ook
goed wordt afgehandeld.
Het voordeel van unittesten blijkt ook bij aanpassingen. Dan wordt alles op-
nieuw gecompileerd en kun je meteen zien of de methods nog werken en of
nu compatibiliteitsproblemen zijn ontstaan. Bijvoorbeeld doordat de testsuite-
classe nog niet is geüpdatet, of dat een verandering is aangebracht in de data-
structuur waarbij nog niet is gelet op de invoer vanuit de andere classes.
Belangrijk gegeven is de unittestgrootte. Deze zal per techniek verschillend

zijn. Daarna moet de diepgang van de unittest worden afgesproken: worden
11 Testen
alle situaties van de unit meegenomen in de test (normaliter een eis binnen
unittest) of komen bepaalde testen later aan bod. In sommige situaties kan het
zelfs wenselijk zijn om reeds unittesten via een GUI uit te voeren. In de rol van
Test Analist ziet de Developer ook toe op de voortgang en het kwaliteitsniveau
van de test.
Voor een Developer is het scheiden van de verschillende testrollen essentieel

om de benodigde objectiviteit te handhaven. Stelregel is dat de rol die de test
voorbereidt (Test Designer, Test Analist) niet de test uitvoert. Binnen een unit-
test is het dan ook raadzaam om de testuitvoer te verdelen over de Developers
die niet uit te voeren unittest hebben voorbereid. Op deze wijze kan ook gelijk
de review van de code plaatsvinden (X-implementing).
De voor unittest specifieke procesgang bij de opzet van de testen is:
aangeleverde Use Cases & Requirements;

unittest definiëren;
unittest ontwikkelen (test-classes en andere voorbeelden);
code maken;
o unittest uitvoeren; -
resultaten vastleggen.
Voor unittesten is het vastleggen van de resultaten een apart verhaal. Unittes-
ten gaan vaak niet via de gebruikte testtools in andere testniveaus en daarom
zal vastleggen van de resultaten apart plaats vinden. In de praktijk gaan de
defects vanuit de unittest niet in een probleem-t001 omdat de developer zelf de
testresultaten gebruikt om voortgang en fouten te verbeteren. Het gaat om vast
te leggen welke unittesten uitgevoerd zijn en wat de status van een artifact is.
Een oplevering naar een volgend niveau van testen zal pas plaatsvinden wan-
neer de unittest volledig succesvol is doorlopen.
Geautomatiseerd testen (zie verderop in dit hoofdstuk) kan behulpzaam zijn in

het optimaliseren van de unittest.
ntegratie- en Systeemtest
De integratietest is het volgende niveau in het V-model. Uitgangspunt vormt
een succesvolle unittest. Deze testen kijken echter uitsluitend naar de kleinste
gedefinieerde testeenheid: de samenhang tussen de eenheden komt in een in-
tegratie- en systeemtest aan bod.
De integratietest bekijkt of de samenwerkende units correct functioneren.

Hierbij wordt vaak de strategie gebruikt om het uiteindelijke systeem stukje
bij beetje op te bouwen (per Use Case, per applicatiedeel, per technisch deel)
waarbij uiteindelijk een volledig systeem ontstaat.
Een systeemtest bekijkt bij voorkeur de werking van een geheel systeem, al zal
dit in de praktijk niet altijd het geval zijn. Vaak krijgt een systeemtest de naam
preacceptatie mee om zo in te spelen op het volgende testniveau.
Vaak zijn de integratietesten meer technisch van aard en ligt de focus op een
juiste technische werking van de delen van het systeem, terwijl de systeemtest
een duidelijk functioneel karakter kent. Het opzetten van de testen voor inte-
gratie en systeem hangt sterk samen met de gekozen teststrategie, testdoelen en
testaanpak. Hiermee worden ook de inhoudelijke activiteiten van de testrollen
voor een belangrijk deel bepaald maar moeten alle testrollen vertegenwoordigd
zijn. Wanneer een duidelijk onderscheid ligt in de testaanpak van integratie en
systeemtest, kan het nodig zijn om de testrollen door verschillende personen
in te vullen: een Test Designer voor integratietest en een Test Designer voor
systeemtest. Wanneer de integratie- en systeemtest duidelijk gescheiden zijn is
het tevens eenvoudiger de testvoorbereiding gelijktijdig uit te voeren.
Ligt de scheidslijn tussen integratie- en systeemtest uitsluitend op het gebied

van de omvang van de testdelen, dan is het samenvoegen van deze twee testni-
veaus een optie: houd hier dan wel rekening met de verschillende soorten spe-
cificaties volgens het V-model. Samenvoegen betekent een complexere wijze
van het samenstellen van de testen omdat meer zaken gelijktijdig getest gaan
worden.
Het vertalen van de Requirements voor integratie- en systeemtest is afhanke-

lijk van de gemaakte scheiding binnen het project. Voor integratietesten vormt
het design het uitgangspunt via State Chart Diagrams en Use Case Design
en aangevuld met de Use Case. Voor systeemtesten zijn de Use Cases zelf
bron van Requirements. Aanpak voor de Use Cases is te starten met de hoofd-
stroom, gevolgd door het opstellen van testcases die de alternatieve stromen
bedekken.
11 Testen
Aparte aandacht verdient de acceptatietest. Normaliter is de gebruikersorgani-

satie zowel verantwoordelijk als ook uitvoerend in dit testniveau. In dit geval is
het handig om vanuit het project een systeemtest in te steken (onder de noemer
preacceptatie) die voor het project een goede inschatting kan geven over het
verwachte acceptatieproces.
Is de acceptatietest binnen het project belegd, dan zal altijd de eindverantwoor-

delijkheid voor de acceptatietest bij de gebruikersorganisatie moeten liggen.
In deze situatie levert het project uitsluitend de resources. Voor de acceptatie-
test zijn de testrollen sterk afhankelijk van de projectcontext. De acceptatie-
testen zijn per definitie functioneel van aard en het testen van het systeem is
het doorlopen van het systeem op de bruikbaarheid. Het is ook raadzaam om
Developers vanuit de integratie- en systeemtest in de rol van consultant mee te
laten draaien, gezien de opgedane kennis in de eerdere testniveaus.
Binnen RUP is de Deployment Manager verantwoordelijk voor het caördine-

ren van het acceptatietesten.
Speciale aandacht is nodig voor het testen van architectuurprototypes. Een

prototype is niet een compleet systeem en bovendien is dat wat gebouwd is
bedoeld om specifieke aspecten te bewijzen. Het testen van een prototype is
gericht op het testen van alleen de aspecten waarvoor het prototype bedoeld is.
Alle overige gebreken worden genegeerd. Dat neemt niet weg dat het V-model
zoals hier besproken is ook op het testen van prototypes van toepassing is.
Afhankelijk van de te testen aspecten zal het prototype aan verschillende test-
niveaus worden blootgesteld. Als het bijvoorbeeld gaat om een prototype dat
de performance van een bepaalde component moet bewijzen, zal een Unittest
toegepast worden. Een prototype kan ook gericht zijn op de schaalbaarheid
of betrouwbaarheid. In dat geval zullen zowel Unittest als integratie- enlof
systeemtest toegepast worden. Prototypes die de aansluiting van de functiona-
liteit op een bedrijfsproces toetsen worden op acceptatietest niveau getest.
In ieder geval zal het testen van architectuurprototypes op die aspecten waar-
voor het bedoeld is, net zo zorgvuldig moeten worden uitgevoerd als het testen
van het uiteindelijke systeem.
Het testen van prototypes betekent dat ook tijdens de Elaboration-fase of zelfs
de Inception-fase aandachtig getest wordt. Zie je wel, testen is tijdens alle fa-
sen van RUP belangrijk.
Voor elk testniveau geldt het onderscheid in white boxen black box-testen. De
white box-test maakt gebruik van de kennis van de interne technische struc-
tuur van het te testen object controleert of de gekozen oplossing in technische
zin goed functioneert. Doel van de white box-test is het opleveren van een wer-
kend object dat onder normale omstandigheden steeds zinvolle, beoordeelbare
uitvoer oplevert. Bij black box-testen wordt het object van buiten af bekeken en
wordt gecontroleerd of de noodzakelijke eigenschappen van het object aanwe-
zig zijn. De manier waarop dit technisch is gerealiseerd is van minder belang.
Het uitvoeren van black box testen is niet zinvol voordat de white box-testen
achter de rug zijn.
White box-testen komt het meest terug bij de unittest. De integratietest is, af-
hankelijk van de benodigde diepgang en aansluiting op de unittest, een white
box- of black box-test. De systeem- en acceptatietest zijn vaak black box-tes-
ten.
Apart aandacht verdient het testen van de performance. Dit omvat niet alleen
het aspect snelheid, maar ook hoeveelheden, resourcegebruik en het verken-
nen van systeemgrenzen. Dit dient gefaseerd aangepakt te worden. Binnen een
RUP-project is de Elaboration-fase de aangewezen fase om te starten met per-
formancetesten. Performance kan meegenomen worden in nagenoeg elke test-
fase. In unittesten als aanvulling op de bestaande unittestset (als uitbreiding op
het unittestframework zoals Perfunit), binnen integratie- en systeemtesten om
performancescenario's te doorlopen. Ook voor performancetesten geldt dat het
doel zal zijn in een zo vroeg mogelijk stadium met zo min mogelijk middelen
de grootste en meest risicovolle afwijkingen van de Requirements te ontdek-
ken. Vaak is voor performancetesten een separaat testtraject nodig, gezien de
specifieke eisen aan een performancetest zoals benodigde testkennis, tooling
en omgeving.
In de praktijk komt performance vaak (te) laat aan de orde; soms worden af-
wijkingen ten opzichte van de Requirements pas ontdekt tijdens acceptatie. Dit
is deels te verklaren door'de complexiteit in het aantonen van een te behalen
performance in een niet-productieomgeving. Toch vormen performance-eisen
vaak een belangrijk onderdeel uit de verschillende acceptatiecriteria. De Soft-
ware Architect zal samen met Test Analyst en Test Designer een vertaling
dienen te maken van de eisen aan performance naar testen, die in een vroeg
stadium uitvoerbaar zijn. Op het niveau van unittest betekent dit bijvoorbeeld
erstaken simuleren is de integratie- en systeemtest meer
discussie is die over het moment van testen. Het gaat dan
ersteuning zijn gedefinieerd, en het onderkennen van de ri-

tiek. Dit is afhankelijk van het bekend zijn van de gewenste
rende producten. Geeft het Software Development Plan een
voor het gehele project of is de reikwijdte nog beperkt tot
en Elaboration? Test is in de opstartfase sterk afhanke-
als het Software Development Plan, Iteration Plan, Vision
ss Case en Use Case model. In de Inception-fase worden
r implementaties binnen de Inception-fase. Een belangrijk

de discipline Test is in deze fase het Master Test Plan.
isatie een standaard Master Test Plan beschikbaar, zo-
r het opstellen van een Master Testplan van het project. In

omgeving nog niet is ingericht, zal een Master Test plan
en komt in de Elaboration-fase het gehele testproces voor

ij aanvang van deze fase zijn alle randvoorwaarden voor
de benodigde tools, koppelingen met andere disciplines en
oration levert vaak prototypes op van technische oplossin-
I 87
gen of juist GUI-interfaces vanuit de User Experience. De uit te voeren testen

stemmen af op de op te leveren producten binnen de iteratie-en RUP-fase.
In de Construction-fase komt het gehele arsenaal aan testniveaus en testtypen

aan bod. In het RUP-overzicht zit in deze fase duidelijk de grootste inspan-
ning. Binnen elke iteratie wordt het testproces doorlopen, startend met het
opstellen of beschikbaar maken van de (test) specificaties via het voorbereiden
van de test tot en met het uitvoeren van de test en vastleggen van de resultaten.
Herbruikbaarheid van testen en het automatiseren van testen zijn belangrijke
wapens.
In de Transition-fase is de testinspanning sterk afhankelijk van de projectin-

steek. In het algemeen valt binnen Transition-fase vaak nog bug fixing plaats
en daarmee ook testactiviteiten (hertesten). Acceptatietesten vormen een dui-
delijke testfase die in Transition aan bod komt. De acceptatietest is per defini-
tie een taak van de opdrachtgevende organisatie.
Vanuit zowel de verschillende testniveaus als de RUP-fases blijft de bood-

schap dezelfde: hoe vroeger een defect wordt gesignaleerd, hoe minder resour-
ces (tijd, middelen) dit kost. Dit geldt in eerste instantie voor de test niveaus:
vergelijk maar eens de benodigde inspanningen voor een Developer vanuit de
unittest naar een project dat zich in de fase van acceptatie bevindt. Hetzelfde
voor de RUP-fases: hoe eerder een defect is gesignaleerd, hoe minder inspan-
ning het kost om deze op te lossen. Vanuit dit oogpunt is het handig het uit-
voeren van de meest kritische testen zo vroeg mogelijk in het project plaats te
laten vinden en deze inschatting dient als input voor het samenstellen van een
Software Development plan en Iteration Plan.
TESTFASES
Reviewen
L Zijn de requiremenfs duidelijk?
Unit-Test
L Werkt mijn onderdeel?
Integration Test
L Werken de onderdelen samen?
1
2
O
t System Test
L Werkt het Systeem?
L Acceptence Test
Development C- --+ Deployment
Des te later het signaleringsmoment van een

defect, des te hoger de kosten van het project
L Kan het systeem gebruikt worden? bij het oplossen van zo'n defect.
Figuur 11.2: Kosten per defect

11 Testen
Test en
RUP kent een aantal testtypen die zijn gekoppeld aan kwaliteitsdirnensies.
Testen is feitelijk het beoordelen van een kwaliteitsniveau, dus deze koppeling
ligt voor de hand. Een testtype zegt iets over de soort test (bijvoorbeeld func-
tioneel testen, performance testen). Een kwaliteitsdimensie kent de FURPS+
indeling (zie het hoofdstuk Interpreteren Requirements).
De testniveaus, testtypen en kwaliteitsdimensies vullen elkaar aan. Wanneer

de verschillende testtypen en kwaliteitsdimensies strikt gescheiden kunnen
blijven (elke kwaliteitsdimensie kent haar eigen testtype en krijgt haar eigen
uit te voeren testen) wordt de hoogste test effectiviteit behaald. Dit betekent
wel dat het aantal uit te voeren testen relatief groot is.
In de praktijk komt een aantal kwaliteitsdimensies en testtypen bij elkaar. Hoe

meer testtypen en kwaliteitsdimensies in elkaar worden geschoven, hoe com-
plexer de testopzet zal zijn omdat dan één test vele testtypen in zich heeft en
hoe geringer dan het aantal testen is. De juiste balans vinden tussen testtypen
en kwaliteitsdimensies en het samenvoegen hiervan in dezelfde testen is be-
langrijk. Ook komen niet altijd alle testtypen en kwaliteitsdirnensies volledig
aan bod, afgestemd op de inhoud van het project en de risico-inschatting.
In de praktijk is het niet altijd mogelijk om alles 100% te testen. De beperkin-

gen hierbij zijn tijd, geld, planning en resources. Is het niet een einddatum, dan
is het wel de beschikbare geldstroom die er voor zorgt dat niet alles volledig
binnen een test aan bod zal komen. Er zal altijd een afweging moeten wor-
den gemaakt tussen inspanning, beoogde kwaliteit en betrouwbaarheid. Maak
hiervoor een risico-inschatting aan de hand van de verschillende testtypen en
neem dit op in het Master Test Plan.
Voor een Developer is het belangrijk om te weten op welke momenten (lees

welke testniveaus) er welke soorten testen uitgevoerd gaan worden. De Test
Manager zal hiertoe, gebruik makend van de Test Analist en Test Designer,
een Master Test Plan opstellen waarin is aangegeven wat het doel is van de test
binnen het project (en per iteratie), de teststrategie en testaanpak. Dit zal geen
uitputtende lijst zijn: gedurende het project evolueert ook de testvoorbereiding
en komen er testen bij enlof vallen er testen af. Uitgangspunt moet zijn dat de
afgesproken kwaliteitsdimensies,vertaald in requirements, in een test aan bod
komen en dat het totaal aan uitgevoerde testen binnen de verschillende testni-
veaus op elkaar aansluit.
De samenhang tussen de verschillende testtypen in de verschillende testni-

veaus is cruciaal in het bereiken van de gestelde testdoelen zonder buitenspo-
rige testinspanningen.
Relatie met andere disciplines

Vanuit de testdiscipline is er een sterke relatie naar de disciplines Require-
ments Management en Configuration & Change Management (CCM).
Requirements Management (in de rol van Requirements Specifier) levert de

benodigde Requirements aan die beoordeeld gaan worden. Zie het hoofdstuk
Interpreteren Requirements. Uit de requirements komen testbare requirements
die aan testcases gekoppeld zijn. Uitgangspunt vormt de vaststelling dat elke
vastgestelde (test)-Requirement in minimaal één testcase voorkomt die deze
requirement afdekt. Wijzigingen in de Requirements, of ze nu van gebruikers
afkomstig zijn of een technische achtergrond hebben, moeten bekend zijn voor
de testdiscipline. Wanneer zich een wijziging voordoet bepaalt de Test Analist
en Test Designer of een aanpassing van de ter zake doende test noodzakelijk is
en of een eventuele hertest noodzakelijk is.
Het koppelen van Requirements aan testcases is via testtools (zoals Rational
Testmanager) mogelijk, waarmee tevens de traceerbaarheid van requirements
wijzigingen is opgepakt.
11 Testen
Koppel defects terug
Configuration a Change
Figuur 11.3: Relatie vanuit de testdiscipline naar andere disciplines
Binnen CCM is de Configuration Manager verantwoordelijk voor het plan-

nen van de opleveringen, ook aan de Tester. Wanneer tijdens het testen de
Test Analyst de testresultaten beoordeelt, levert CCM de mogelijkheid om een
Change Request aan te maken. (zie ook Hoofdstuk Configuratiemanagement
en Changes.)
In de praktijk is het gehele defectbeheer binnen CCM belegd: hier bepaalt men
op welke wijze de defects opgepakt worden.
Pas wanneer de relatie tussen Test, Requirements Management en CCM vol-

ledig is, kan er gesproken worden van een volledige traceerbaarheid van requi-
rements naar test en defects toe. Metrieken zoals het aantal Requirements dat
in testen voorkomt en het aantal aangemelde en opgeloste defects, geven voor
projectmanagement waardevolle informatie.
Iteratief testen
Het iteratief werken binnen RUP vraagt een specifieke en flexibele aanpak van
testen: per iteratie wordt het gehele testproces doorlopen. Voor elke iteratie
wordt, afgestemd op het Master Test Plan, bepaald welke testen aan bod ko-
men. Het kan hiervoor noodzakelijk zijn om per iteratie een iteratietestplan op
te stellen. Binnen een iteratie komen in ieder geval de testniveaus unittesten
en de integratie- en systeemtesten (of een combinatie) aan bod. Het iteratieve
karakter kan verder ingevuld zijn door de testen een opbouwend karakter te
geven: de volgende iteratie borduurt dan voort op de testen die zijn opgesteld
voor de eerdere iteratie. Deze keuzes vallen onder de noemers teststrategie en
testaanpak, beschreven in het Master Test Plan.
Voor een test zijn de aanwezige omgevingen een onmisbaar instrument om

de verschillende testniveaus door te komen. De unittest wordt op de ontwik-
kelomgeving uitgevoerd, integratie- en systeemtesten op de testomgeving en
acceptatietesten op de acceptatieomgeving. Een Test Manager kan niet accep-
teren dat integratietesten en volgende testniveaus op de ontwikkelomgeving
plaatsvinden. De ontwikkelomgevingis geen stabiele testomgeving en een lo-
gische opbouw van een testsysteem is niet mogelijk.
De wijze van het opbouwen van de testomgeving volgt het Iteration Plan. Af-
hankelijk van de gekozen ontwikkelstrategie wordt de testomgeving steeds
aangevuld met een oplevering vanuit een iteratie of volgt vanuit elke iteratie
een geheel nieuwe testomgeving.
Testtools is het overkoepelend begrip van alle geautomatiseerdeondersteuning

binnen test. De testtools zijn ingedeeld naar functionaliteit. Grofweg geven de
testtools ondersteuning aan het invullen van specifieke testen (denk aan per-
formance en stress testen) of het testproces zelf (zoals de Testmanager).
Geautomatiseerd testen heeft te maken met de invulling van de testen zelf en
is verdeeld naar de verschillende testniveaus. Tijdens unittesten is de geijkte
vorm van geautomatiseerd testen het dagelijks automatisch aanroepen van de
unittesten als onderdeel van de dagelijkse build (zie het hoofdstuk Implemen-
teren en Integreren).
In integratie- en systeemtesten (en eventueel acceptatietesten) bestaat geau-

tomatiseerd testen uit het geautomatiseerd kunnen laten uitvoeren van testen.
Dit is afhankelijk van de testtypen en wordt vaak ondersteund door testtools:
zo is bij functionele testen een record & playback t001 een prima hulpmiddel
om testen geautomatiseerd op te zetten. De t001 kopieert exact de schermhan-
delingen en kan deze later 'afspelen'. Voor performance en stressachtigetesten
is geautomatiseerd testen een must: zonder een ondersteunende t001 (kan ook
11 Testen
zelf ontwikkeld zijn) is het niet mogelijk om deze testen uit te voeren. Het is
onvoorstelbaar om zonder deze ondersteuning 1000 multiple users te simule-
ren die elk 8 uur lang bepaalde schermafhandelingen verrichten.
Het gebruik van geautomatiseerd testen hangt samen met de:
Q uit te voeren testtypen (voor performance-testen is een testtool onontbeer-

lijk);
e beschikbaarheid van tools: zelf bouwen of zijn tools al beschikbaar;
stabiliteit van Requirements: bij steeds wijzigende Requirements is er meer
onderhoud op testcases nodig;
controle op omgeving: voorwaarde aan geautomatiseerd testen;
* behoefte en frequentie van regressietesten.
Inzet van geautomatiseerd testen is dus sterk contextafhankelijk. In de praktijk

is er altijd een mix van geautomatiseerd testen en manueel testen. Houd er wel
rekening mee dat het opzetten van geautomatiseerd testen meer tijd vergt (fac-
tor 2 tot 5) dan manueel testen en specifieke testtoolkennis vraagt.
Wanneer voor geautomatiseerd testen gekozen is, krijgen alle rollen binnen
de testdiscipline hier mee te maken: de Tester bij voorbereiding en vooral uit-
voeren van testen en de Test Designer en Analyst bij het bepalen van de uit
te voeren testen. Het is zaak om tijdig het gebruik van geautomatiseerd testen
vast te stellen en dan desgewenst voor te bereiden (tijdens Inception is beno-
digde ondersteuning voor testen vastgesteld). Vergeet hierbij niet de benodigde
(test)ervaringen met geautomatiseerd testen.
Het is raadzaam om in geval van geautomatiseerd testen voldoende pre-testen
in te plannen en exact te weten wat de geautomatiseerd testen opleveren (test
de geautomatiseerde ondersteuning zelf).
a$ na het voltooien van de systeemtest, met welke zaken de gebruikers

vanuit de acceptatie komen. liij heefr immers gedurende het testen
geen input gehad van eindgebruikers.
Maurice Siteur, Testen met testtools. Academic Service, 1999. ISBN

9039513899 (uitverkocht).
Martin Pol, Ruud Teunissen, Erik van Veenendaal, Software Testing: A Guide
to the TMap Approach. Tutorial for Users, Intermediate and Advanced
Level. Addison Wesley ,2002. ISBN 0201745712.
Martin Pol, Ruud Teunissen, Erik van Veenendaal, Testen volgens TMap. Tu-
tein Nolthenius, 2e druk, 2000. ISBN: 9072194586.
bsites
Productinformatie over de testsuite:
www.rational.com/products/tstudio/prodinfo.jsp
Archief van Rational community-artikelen (niet testspecifiek):

www.therationaledge.com/admin/archives.jsp
Artikelen over testen: www.sqa-test.com/articles.html
Algemene info en downloads voor testers: www.sqatester.com
Pagina van de Nederlandse vereniging van testers: www,testnet.org
Open Source voor Java-testen: www.junit.org
Open Source voor .NET www.nunit.org

Hetdoel vandedeployment is tezorgendat het systeemzodanig geïmplementeerd
wordt, dat de eindgebruikers tevreden zijn. De voorbereidingen - die
resulteren in het Deployment Plan - beginnen al tijdens de Znception-fase. Alle
systemen en applicaties die uiteindelijk in productie gaan, dienen vergezeld
te gaan van een Deployment Plan. Alleen wanneer een Proof of Concept
(PoC) wordt ontwikkeld kan een Deployment Plan overbodig zijn, want in
een PoC worden knelpunten uit de applicatie- architectuur onderzocht en
worden standaardoplossingen voor deze knelpunten gezocht, zodat deze de
uiteindelijke applicatieontwikkeling niet meer zullen belemmeren. Daarom
komt een PoC-resultaat niet in aanmerking voor Deployment.
De Deployment Manager houdt zich onder andere bezig met het schrijven,
testen, verbeteren en zelfs ook het uitvoeren van installatiescripts. Het systeem
dat door de Deployment Manager wordt opgeleverd gaat vergezeld van gebrui-
kersinformatie. Deze kan door de Deployment Manager zelf worden samenge-
steld, maar wordt veelal samengesteld op basis van documentatie aangeleverd
door het team. In de gebruikersdocumentatie vind je onder andere informatie
uit Use Cases, Release Notes en ook uit testrapporten (waar workarounds be-
schreven kunnen zijn).
Ook zorgt de Deployment Manager voor het vergaren van informatie uit de
SCM-repository (Software Configuration Management repository) van confi-
guratiegegevens. Het kan hier gaan om .INI-files of 'registry settings', maar
ook om de eisen die gesteld worden aan het te installeren systeem. De Deploy-
ment Manager zal hier ook samenwerken met de Configuration Manager om
deze informatie te verkrijgen.
In sommige projecten wordt een reeds bestaand systeem (of worden reeds be-
staande systemen) vervangen door een nieuw systeem. Als dit het geval is zal
er ook dataconversie nodig zijn. Tot de taken van de Deployment Manager
behoort dan ook het verzorgen van migratie- of dataconversieprogrammatuur
en het uiteindelijk uitvoeren van de dataconversie.
Een laatste taak (in deze opsomming) van de Deployment Manager is het stel-
len en opschrijven van randvoorwaarden aan het testresultaat. Een Deploy-
ment Manager kan op deze manier zorgdragen voor de kwaliteit van het sy-
steem dat opgeleverd gaat worden. Hiermee wordt voorkomen dat een systeem
met geringe kwaliteit - met andere woorden dat nog bepaalde fouten bevat - in
productie wordt genomen.
Een Deployment Manager krijgt binnen het project te maken met een aantal
groepen of rollen. Deze zijn te verdelen in aanleverende partijen en ontvan-
gende partijen.
De Ontwikkelaar levert, vaak via de Configuration Manager en nadat het test-

team akkoord heeft gegeven, een werkend systeem aan de Deployment Ma-
nager. Ook de Software Architect is toeleverancier voor de Deployment Ma-
nager. Hij levert allerlei zaken aan die uit het oogpunt van architectuur van
belang kunnen zijn bij deployment. Denk bijvoorbeeld aan de infrastructuur
en de onderverdeling van componenten, subsystemen en packages.
Verder zijn er de System Administrators of andere vertegenwoordigers van de

toekomstige beheerorganisatie, die aangeven wat specifieke eisen zijn voor wat
betreft het aanleveren van de systeemartefacts, bijvoorbeeld in verband met de
uitrol binnen de organisatie of de infrastructuur.
Een ontvangende partijen vormen in de eerste plaats natuurlijk de System Ad-

ministrators. Zij krijgen een systeem opgeleverd en zorgen samen met de De-
ployment Manager of op eigen initiatief voor de distributie binnen hun eigen
organisatie. Deze System Administrators zorgen voor uitrol van het systeem
en uiteindelijk zijn het de eindgebruikers die gebruik gaan maken van het sy-
steem en hun bevindingen over het systeem kenbaar maken.
12 Deplovment
Voor de Deployment Manager is het, evenals voor ander projectleden, zaak

om voordat het uiteindelijke deployment proces begint, een aantal zaken goed
in kaart te brengen. Een volledige en correcte omschrijving van de Ontwik-
kel-, Test-, Acceptatie- en Productieomgevingen, ook wel OTAP genoemd, is
hierbij cruciaal. Zie figuur 4.1 voor de OTAP-kaart.
Voor de ontwikkelomgeving worden de systeemspecificaties beschreven, waar-

bij zaken als aantal CPU's, hoeveelheid geheugen, het Disksubsystem (RAID
of gewoon) en netwerk zeker ter sprake dienen te komen. Een onderdeel hier-
van is of het een vereiste is dat de ontwikkelomgeving locatiegebonden is, of
dat thuiswerken een mogelijkheid moet zijn. Denk ook aan het uitbesteden van
het ontwikkelwerk.
Verder dient bij de ontwikkelomgeving nagedacht te worden of de gebruikte

ontwikkeltools wel aansluiten bij de productieomgeving waar het te bouwen
systeem uiteindelijk gebruikt en, nog belangrijker, onderhouden zal gaan wor-
den.
Voor de testomgeving dienen ook weer de systeemspecificaties te worden om-

schreven. Deze zijn vaak afwijkend van die van de ontwikkelomgeving, aan-
gezien de testomgeving meer moet lijken op de uiteindelijke (productie) situ-
atie dan de ontwikkelomgeving. Belangrijke zaken zijn bijvoorbeeld de keuze
van het te gebruiken bestandssysteem (NTFS, FAT32) en de rechtenstructuur
(wie mag wat op welke folder).
Een ander belangrijk punt binnen de testomgeving is of er een omgeving be-

schikbaar is of moet zijn waarin ontwikkelaars eenvoudig zelf nieuwe versies
kunnen deployen en testen. Dit kan de kwaliteit van het op te leveren systeem
sterk ten goede komen en het testproces versnellen.
Net als voor de vorige omgevingen moeten ook hier weer specificaties worden
opgesteld. De acceptatieomgeving dient, meer dan de testomgeving, gelijk te
zijn aan de productieomgeving. Eventuele problemen van het te bouwen sy-
steem in de productie omgeving dienen hier naar voren te komen.
Vaak wordt de acceptatieomgeving ook gebruikt om zaken als stress- en per-

formancetests uit te voeren. Er worden hiervoor dus extra eisen aan de capaci-
teit van de systemen gesteld.
De applicatie wordt opgeleverd compleet met:
e installatie handleiding;
backup- en restore procedures;
escalatie procedures;
0 ingerichte changelrequest procedure.
Om de applicatie in productie te kunnen nemen is een beschrijving nodig van

de systeemspecificaties: CPU, Memory, Disksubsystem, Netwerk en dergelij-
ke. Met name als de productieomgeving afwijkt van de ontwikkelomgeving is
de specificatie van groot belang. Daarnaast zijn enkele specificaties, specifiek
voor de productieomgeving nodig:
welke andere (middleware) software is reeds geïnstalleerd;

welke andere applicaties draaien in die omgeving;
waar staan de applicatieslserviceswaarvan je afhankelijk bent - denk aan
LDAP, SMTP, POP3 Radius.
Om alle benodigde informatie over de productieomgeving te kunnen verzame-

len, wordt de volgende checklist gehanteerd.
OS, versie en service release

beheer inrichting
wat is de company policy (altijd de één-na-laatste versie)
waar is de middleware geïnstalleerd
wat zijn de rechten van de applicatie-user
hoe is de user-inrichting (homedir, rechten)
verantwoordelijkheden beheer
is er een specifieke releasemanager
wie heeft welke rechten
voor welke taken moet je waar zijn
infrastructure aspecten
netwerkspecificaties (snelheid)
systeemspecificaties (webserver)
veiligheidszones
Intranet: niet toegankelijk van buiten
Secure-extranet, ook wel DMZ, beperkt toegankelijk van buiten
Publiek-extranet, ook wel Internet, beperkte toegang van intranet
12 Deployment
e hoe is verkeer geregeld van zone-naar-zone

wie is verantwoordelijk voor het security beleid
wat zijn de lessons learned bij de overgang tussen de diverse omgevingen
Uit deze checklist zijn argumenten af te leiden waarom je de omgevingen goed

in kaart moet brengen. Bij gebrek aan deze informatie is de kans niet groot dat
de applicatie goed zal werken.
Het ontwikkelen heeft plaatsgevonden op Winzk in een J2EE IDE-ontwikkel-

omgeving. De uiteindelijke applicatie draait in een multi-tieromgeving onder
Unix (of exotischer onder OSI~OO), weliswaar nog steeds in een JzEE-omge-
ving.
Development = Winzk
JzEE IDE
Test - Linux
Acceptatie = conform productie
Productie = Unix
Linux
OSl~00
NTIwinzk
Unix AIX, Solaris, HPJUX of Linux.
Om de overgang tussen deze omgevingen soepel en zonder risico's te laten

verlopen, is het noodzakelijk om van deze omgevingen als onderdeel van de
deploymentinstructie een beschrijving te maken. Deze instructie zal bespro-
ken moeten worden met de beheerafdeling en maakt onderdeel uit van de ac-
ceptatietest.
In dit hoofdstuk komen conjiguratiemanagement (versiebeheer) en Change
Management (wijzigingsbeheer)aan bod. Dit is geen toeval: ook in RUP vormen
deze twee samen één discipline: Conjiguration & Change Management.
Configuratiemanagement, ook wel bekend als Software Configuration Ma-

nagement (SCM), houdt zich bezig met het beheer van alle artefacts binnen
een project. De onderdelen die binnen SCM een rol spelen zijn:
versiebeheer van artefacts;

build management;
release management;
e bepalen van configuratie-items.
Het versiebeheer, ofwel het 'beheren' van artefacts, houdt in dat elkaar op-
volgende versies van documentatie, Requirements, maar ook alle source code
en uiteindelijke executables bij elkaar bewaard worden. Van al deze artefacts
worden verschillende versies bewaard en wordt met behulp van SCM aange-
geven welke onderdelen samen een release vormen van een gedeelte of het .
van het gehele systeem. Om alle medewerkers binnen het project goed te laten
werken aan de artefacts en de verschillende versies hiervan, stelt het configu-
ratiemanagement procedures op en zorgt voor de inrichting van tool(s) om dit
alles mogelijk te maken.
Verder houdt SCM zich bezig met het verzorgen van het bouwen (buildma-
nagement) van onderdelen van het systeem of van het gehele systeem, waarna
deze samengevoegd worden vor levering aan bijvoorbeeld het testteam of een
productieomgeving. Builds horen bij het integratieproces en worden meer in

detail beschreven in het hoofdstuk Implementeren en Integreren.
Releasemanagement houdt in dat afspraken gemaakt worden over welke func-

tionaliteit er in een bepaalde release van een systeem zit, wanneer de release
getest gaat worden, wanneer deze in productie gaat, et cetera. Het gaat hier
met name om de planning van en afspraken over de oplevering van het te
realiseren systeem. Daarnaast moet, als gevolg van de releaseplanning, ook
worden bepaald welke sources en executables - kortom artefacts - dan moeten
worden opgeleverd bij een release. Releasemanagement maakt ook onderdeel
uit van SCM.
Als laatste, maar zeker niet het minste onderdeel staat genoemd het bepalen
van configuratie-items. Hiermee wordt een systeem opgedeeld in deelsyste-
men die makkelijk zijn te 'configureren'. Afhankelijkheden tussen onderdelen
en verdeling van werk spelen een rol bij het bepalen van de configuratie-items.
In de paragraaf Inrichting van SCM wordt dieper ingegaan op het bepalen van
configuratie-items.
onfiguration
nodig?
SCM is nodig binnen software-ontwikkeltrajectenvan twee personen of meer,
Eén van de hoofddoelen voor het gebruik van SCM is om het tegelijkertijd sa-
menwerken aan artefacts binnen een project mogelijk te maken en te bewaken.
Stel de situatie dat twee ontwikkelaars samen willen werken aan de sources
van dezelfde component. Dan wil je zeker waarborgen dat beide gecontroleerd
aan dezelfde file werken.
Naast het samenwerken aan een release van een component of systeem maakt
het gebruikmaken van SCM het werken aan 'bug fixes' mogelijk. Deze situ-
atie doet zich bijvoorbeeld voor als tijdens het ontwikkelen van versie 2.0 van
een systeem, in versie 1.0, die al in productie is, zich een fout voordoet die
opgelost moet worden voordat versie 2.0 in productie gaat. Het moet dan dus
mogelijk zijn om versie 1.0 te kunnen bewerken zonder dat deze aanpassingen
ook meteen in andere versies beschikbaar komen. Het aangegeven voorbeeld
kan worden beschouwd als parallel ontwikkelen.
De ultieme vorm van samenwerken aan artefacts is het parallel ontwikkelen

van verschillende releases (versies) van een systeem. Ook hier is het zaak dat
men kan werken aan een versie zonder dat dit effecten heeft op de andere ver-
sies van het systeem waaraan ook ontwikkeld wordt.
13 Configuratiemanagement en changes
Met name omdat binnen RUP-projecten iteratief gewerkt wordt, waarbij steeds
een stukje functionaliteit wordt toegevoegd, is het van belang dat dit goed
wordt ondersteund door het SCM. De gebruikte SCM-tools spelen hierbij een
belangrijke rol: als zij parallel ontwikkelen aan kunnen, is bug fixing op oude
release mogelijk, zonder dat de huidige ontwikkelversie wordt aangetast.
Behalve het kunnen werken aan verschillende versies van artefacts, speelt ook
autorisatie een rol bij SCM. Vooral in grote teams mag niet iedereen aan alle
artefacts veranderingen aanbrengen. Een voorbeeld van autorisatie kan zijn:
het testteam mag wel de Requirements zien, maar hier geen aanpassingen aan
doen.
Binnen een software-ontwikkeltrajecthoudt eigenlijk iedereen zich op zijn ge-

bied bezig met SCM.
De RUP-rol Configuration Manager heeft de verantwoordelijkheid voor het

opstellen van artefacts als een Configuration Management Plan, maar ook
voor het inrichten van de SCM omgeving (bijvoorbeeld met ClearCase, PVCS
of MS Visual SourceSafe).
De System Analyst maakt gebruik van deze SCM-omgeving om het Use Case
Model in bij te houden (opeenvolgende versies). Een ontwikkelaar die sources
aanpast in verband met een bug fix, behoort de juiste versie van de sources te
selecteren uit de SCM omgeving.
Over het algemeen is het dus zo dat iedereen die artefacts maakt of wijzigt,
goed moet opletten welke versie van een artefact wordt gebruikt voor het aan-
passen en hier dus ook tot op zekere hoogte verantwoordelijk voor is. Een ieder
volgt dus de door de Configuration Manager opgestelde procedures.
In de paragraaf Do's en Don'ts wordt dieper ingegaan op een aantal proble-

men dat zich voor kan doen bij ongedisciplineerd werken aan versies van ar-
tefact~.
De inrichting van het SCM is per project verschillend en hangt sterk samen
met andere zaken zoals de gebruikte architectuur, het te bouwen systeem of
bijvoorbeeld de projectstructuur.
Bij afhankelijkheid van de architectuur moet worden gedacht aan een systeem
dat gebouwd wordt in een drielagenarchitectuur: een Datalaag, een Busines-
slaag en een Gebruikersinterfacelaag. De hoofdverdeling van de SCM-omge-
ving kan dan bijvoorbeeld zijn zoals in figuur 13.1 is aangegeven. Binnen deze
hoofdverdeling wordt dan vaak per component een onderverdeling gemaakt,
waarin alle documentatie, sources en test gegevens kunnen worden geplaatst.
Op die manier blijven alle onderdelen van één component keurig gegroepeerd.
Zie hiervoor figuur 13.1.
i3 RUPgrolect
O Busmess
Q Data
O GUI
Q !& RUPgroject
i3 &iBusmess
B @i boKlant
l%docJ
src
test
Figuur 13.1: Boven de hoofdindeling SCM-omgeving; onder de subindeling

per component
In plaats van de architectuur leidend te maken bij de inrichting van het SCM-
systeem, kan ook de projectverdeling eisen stellen aan de manier waarop SCM
wordt ingericht. Denk hierbij aan teams die op een bepaalde manier samen-
gesteld zijn en dus per team aan een ander gedeelte van het systeem willen
werken (denk aan een team dat bouwt aan de Web-GUI en een ander team dat
de normale Windows-GUI voor zijn rekening neemt).
Andere voorbeelden zijn nog de onderverdeling in componenten, of geografi-

sche gescheiden teams.
Zoals aangegeven wordt een structuur opgezet voor de indeling in folders.

Dit is echter niet het enige dat moet worden ingericht in de SCM-omgeving.
Om goed te kunnen werken, moeten ook labels en branches worden ingericht.
Daarnaast kunnen in sommige SCM-omgevingen ook scripts worden gebruikt
om extra functionaliteit toe te voegen aan het SCM-systeem.
Labels zorgen voor een unieke identificatie van een 'doorsnede' van het SCM-
systeem op een gegeven moment, bijvoorbeeld bij een daily build. Denk bij
doorsnede aan een deelverzameling van de artefacts, waarbij voor elk artefact
maximaal één exemplaar (of versie) aanwezig is. Deze versies zijn onderling
consistent. Zoals we hieronder zullen zien, kan omgekeerd één artefactversie
wel meerdere labels hebben: denk maar aan een artefact dat in zowel release I
als 1.1 voorkomt, maar geen wijziging heeft ondergaan.
Bij het maken van een zogenaamde baseline van een systeem wordt van alle
artefacts (dus niet alleen van de sourcecode en executables, zoals in een daily
build) een versie gekozen en van een gezamenlijk label voorzien. Hierbij wor-
den dus ook artefacts als Vision document, Use Case modellen, et cetera gela-
beled. De kunst is natuurlijk om te zorgen dat de artefacts binnen zo'n baseline
onderling consistent zijn.
Branches worden in een SCM systeem gebruikt om een versieboom mee op te

bouwen. In de figuur 13.2 is een voorbeeld gegeven van een versieboom van
het bestand Class~.vb.De branches in deze versieboom zijn te herkennen aan
de rechthoeken. Net als alle andere bestanden is begonnen met een '/main'
branch en worden een versie o en I (intern versie nummer) gecreëerd. De base-
lines (of releases) REL1.o en RELIJ zijn gelabeld en te zien is dat hiervoor
versie I geselecteerd is van het bestand Class~.vb.Bij Release REL1.2 blijkt na
een tijdje (er is al doorgewerkt aan versies 3 en 4) dat er een ernstig probleem is
met REL1.2 dat opgelost moet worden aan deze versie van het systeem die al in
productie is. Hiervoor wordt REL1.2 geselecteerd en wordt een aparte branch
('sub-tak'van de versieboom) aangemaakt, namelijk '/bf-re11-2'. Als de bug is
opgelost en de Unit Test van dit onderdeel blijkt correct, wordt opnieuw een
label toegekend, maar nu het label P-RI.~(Patch voor Release 1.2).
Svsteemontwikkeling met RUP
Classl .vb
Figuur 13.2: Voorbeeld van een versieboom
Om extra functionaliteit toe te kunnen voegen aan de SCM-omgeving bieden

SCM tools vaak de mogelijkheid om via scripting of anderszins uitbreidingen
mogelijk te maken. Zo kan bijvoorbeeld op het inchecken van een bestand
een extra controle worden ingebouwd op het commentaar dat moet worden
toegevoegd: als dit niet is gebeurd, wordt het bestand niet ingecheckt. Het is
de verantwoordelijkheid van de Configuration Manager om functionaliteit te
definiëren om op die manier projectspecifieke zaken te regelen.
Baselining of het maken van een baseline is binnen RUP een taak voor de
Integrator. Hij zorgt dat op afgesproken tijden in een ontwikkelproject (af-
spraken staan in het CM plan) een label wordt toegekend aan alle artefacts die
zich bevinden in het SCM systeem (repository). Op deze manier worden alle
artefacts met een bepaalde versie samen uniek geïdentificeerd (zie figuur 13.3)
en kunnen in een later stadium deze versies op eenvoudige wijze uit het SCM
13 Configuratiemanagement e n c h a n a e s
systeem worden geselecteerd. Dit is bijvoorbeeld nodig op het moment dat er

een foutherstelling moet plaatsvinden op een versie die uitgebracht is, maar
ook om opnieuw een release op te kunnen leveren.
Label Rell.0
l
Figuur 13.3:Baselinen - unieke identijicatie van artefacts per versie
Het maken van een baseline komt binnen RUP op twee plekken in de work-
flow voor, namelijk in 'Change and Deliver Configuration Items' en in 'Ma-
nage Baselines & Releases'. Op de eerste plek wordt bedoeld het baselinen ten
behoeve van het projectteam, bijvoorbeeld het toevoegen van een configuratie-
item -een ontwikkelaar heeft een nieuwe component die moet worden toege-
voegd - aan een bepaalde release. In 'Manage Baselines & Releases' gaat het
vooral om het baselinen ten behoeve van het opleveren naar een testteam of
naar een productiesysteem.
e ontwikkelaar?
SCM betekent voor een ontwikkelaar met name dat hij artefacts die hij wij-
zigt op een juiste wijze vanuit de SCM-repository uitcheckt en incheckt. Het
inchecken is hierbij cruciaal. Als we even kijken naar sources, dan wordt ver-
wacht dat deze getest (unit-test) zijn door de ontwikkelaar en werkend zijn
bevonden voordat ze worden ingecheckt. Verder moeten deze sources van
bruikbaar commentaar zijn voorzien.
De door de CM opgestelde procedures voor het uitvoeren van bug fixes en pa-
rallel ontwikkelen, moeten door de ontwikkelaar nauwgezet gevolgd worden.
Alleen op die manier is te waarborgen dat SCM goed wordt uitgevoerd binnen
een project.
Grote valkuilen bij inrichting en gebruik van SCM-systemen binnen projecten

zijn enerzijds de complexiteit van de inrichting, zoals de directorystructuur
of de onderverdeling in componenten, en anderzijds de complexiteit van ver-
siebomen. Beide zijn natuurlijk vooral verantwoordelijkheden voor de CM,
maar kunnen het werk van de ontwikkelaar extra complex maken. Voorbeel-
den hiervan zijn een directorystructuur die niet geheel overeenkomt met de
onderverdeling in componenten die bepaald is aan de hand van de architec-
tuur, of een versieboom waarin meerdere releases parallel worden ontwikkeld
en ook nog een aantal bug fixes plaats moeten vinden. In deze situatie treden
vaak fouten op zoals een nieuwe release die opeens weer een fout bevat die al
eerder was opgelost.
Een andere don't in dit rijtje heeft te maken met de nauwgezetheid die een ont-
wikkelaar zich aanmeet bij het werken met het SCM-systeem. Als een ontwik-
kelaar zich bijvoorbeeld slechts gedeeltelijk of zelfs helemaal niet aan de door
de CM opgestelde procedures voor in- en uitchecken van bestanden houdt, kan
dit op allerlei momenten problemen opleveren. Denk aan een niet werkende
component, die opgeleverd (ingecheckt) is door een ontwikkelaar en ervoor
zorgt dat bij integratie van de componenten - in daily build bijvoorbeeld - zich
een fout voordoet. Als de ontwikkelaar hierbij dan commentaar toevoegt als
'veranderingen aangebracht', moet helemaal opnieuw zoek gegaan worden
naar de veranderingen.
SCM kan uitgevoerd worden in complexe omgevingen, zoals bij mondiale of

geografisch gescheiden teams, offshore-ontwikkeling of bij gescheiden be-
heer- en ontwikkelgomgevingen. De complexiteit uit zich bijvoorbeeld in de
backupmogelijkheden, afwijkende procedures voor versiebeheer, een grotere
zorgvuldigheid bij het beschikbaar maken van changes (een change kan ver-
strekkende gevolgen hebben terwijl jij slaapt), mogelijk langere testdoorloop-
tijden en duidelijke afspraken over buildmanagement.
Een aantal do's:

zorg dat er altijd een SCM-procedure aanwezig is;

zorg dat een ieder de SCM-procedure kent;
zorg dat de SCM-procedure door anderen kan worden uitgevoerd.
Het proces Change Management staat in het teken van het omgaan met veran-
deringen en wijzigingen. In een iteratief project weet je als ontwikkelaar dat
er wijzigingen optreden. De wereld staat niet stil tijdens de projectuitvoering,
dus zullen ook de eisen aan het systeem veranderen. Je zou deze veranderingen
kunnen negeren, maar dan weet je zeker dat het eindproduct niet voldoet aan
de eisen die de gebruikers hebben op het moment van opleveren. Je kunt er
natuurlijk beter in mee gaan, maar dan op een gecontroleerde manier: Change
Management.
Wijzigingsverzoeken (changes) kunnen afkomstig zijn van de gebruikersor-

ganisatie (in de vorm van Requirements). Je kunt ook zelf als ontwikkelaar
wijzigingsverzoeken aandragen (wanneer dat noodzakelijk is voor de door jou

geïmplementeerde oplossing). Toverwoord hierin is voortschrijdend inzicht.
Nu willen we daar nog wel eens alle losse eindjes, nieuwe ontwikkelingen of
gewijzigde behoeften onder laten vallen. Je zult zien dat het afkaderen van alle
wijzigingsverzoekenje als ontwikkelaar helpt om tot een goed projectresultaat
te komen.
De changes (wijzigingsverzoeken) kunnen divers zijn met verschillende im-

pact, risico's maar ook prioriteit en verwachte inspanning. De major changes
(die een verandering van het design tot gevolg hebben) los je in een volgende
iteratie pas op. Minor changes kunnen eerder op de planning staan. Bug fixes
komen gelijk aan bod, al kan het zijn dat een grote hoeveelheid fixes in een
aparte iteratie terechtkomt.
De implementatie van een change-procedure in een project is in elk geval no-

dig na de Elaboration-fase. Op dat moment zijn er namelijk afspraken over de
prijs en de te realiseren functionaliteit gemaakt. Een change op deze functio-
naliteit kan hierop van invloed zijn. Dus voordat besloten wordt of de change
opgepakt gaat worden, zal de impact ervan op de op te leveren artefacts en op
benodigd tijd en geld, moeten worden vastgesteld. Dit moet op een geordende
manier gebeuren. Hoe neem je besluiten? Wie mag besluiten nemen? Wanneer
ga je escaleren? De procedure kan vastgelegd worden in het t001 ClearQuest.
Hierin wordt de workjow voor het verwerken van een change gedefinieerd en
kan de voortgang worden bewaakt.
Een change met impact heeft gevolgen voor de afspraken die met de gebrui-
kersorganisatie zijn gemaakt. Mogelijk moet er, om ruimte vrij te maken, an-
dere functionaliteit worden geschrapt. Deze kan dan in latere fases opgepakt
worden. Ook kan de change zelf worden uitgesteld en later worden geïmple-
menteerd.
Het projectmanagement heeft er voor gezorgd dat voor Change Management

een uniforme en met de alle stakeholders afgestemde procedure beschikbaar
is. Als ontwikkelaar moet je deze procedure kennen. Weet ook wanneer deze
procedure officieel van start gaat. In vroege iteraties kan vaak nog wat lichter
met wijzigingen worden omgegaan. Gaandeweg het project, zeker als er al
veel software-artefacts zijn, wordt het consistent doorvoeren van een wijziging
een steeds arbeidsintensiever proces. Dan wordt het tijd voor een formelere
aanpak. De procedure is cruciaal wanneer (een deel van) de requirements een
bevroren status kennen: via Change Management maak je dan inzichtelijk wat
de change betekent. Changes die op een later moment in de tijd naar boven
komen hebben per definitie meer impact dan changes vanuit de eerste iteraties.
Hoe verder een project evolueert, hoe meer disciplines geraakt gaan worden
met een change en hoe complexer het is om changes door te voeren.
Realisatie van Change Management kan op twee manieren. '
Het volledige changeproces blijft binnen de scope van een project. Hier-
voor is het noodzakelijk dat de benodigde beslissingsbevoegdheid dan ook
binnen het project zit. De Change Control Board (CCB) hoeft alleen beslis-
singen te nemen met betrekking tot het project. Dit zal het geval zijn als het
project geen relaties heeft met operationele systemen of andere projecten.
e Change Management of een deel ervan wordt extern belegd in de vorm van
een externe Change Control Board. Dit zal nodig zijn als de impact van
changes buiten de scope van het project kan vallen.
In een procedure kunnen natuurlijk beide mogelijkheden voorkomen. Dan zal

in de procedure het vaststellen van het feit of een change de scope van andere
systemen of projecten raakt, moeten zijn opgenomen.
Voor een ontwikkelaar maakt de keuze niet uit: belangrijk is het om te signa-
leren wanneer changes worden aangeboden enlof aan te geven wat de changes
gaan betekenen. Als ontwikkelaar moet je het uitgangspunt hanteren dat je
niet de verantwoordelijkheid en bevoegdheid hebt om changes goed te keuren.
Zorg er altijd voor dat de procedure gevolgd wordt. Niets is zo erg als een niet-
gedocumenteerde en goed ' afgetikte' change.
Als je merkt dat er op een project geen vastgestelde changeprocedure is, trek
dan aan de bel. Je hebt dan een major risk voor het project ontdekt. Het op-
pakken van dit risico zal altijd een projectmanagement of CCB taak zijn (die
vervolgens weer gedelegeerd kan zijn).
Een change zal de volgende levenscyclus doorlopen: logged; holdlapproved en

completed.
De changeprocedure beschrijft hoe dit proces verloopt en welke rollen daarbij

van toepassing zijn, zoals: Wie mag een change request aandragen? Wie ana-
lyseert de impact? Wie besluit óf en zo ja wanneer een change moet worden
doorgevoerd et cetera. Ook beschrijft de changeprocedure wat van een change
request moet worden vastgelegd. Een Change Manager is verantwoordelijk
voor de change-procedure en begeleidt als het ware de changes. De Change
Manager is binnen kleine projecten vaak een teamleider, terwijl grote projec-
ten daar een aparte persoon voor hebben.
Figuur 13.4: ChangeRequest - levenscyclus en status
Een goede praktijk is om onderscheid te maken tussen echte change requests

(verbetervoorstellen) en bug fixes of defects. De procedures waarmee deze
worden afgehandeld zullen verschillen. Change requests worden veelal door
stakeholders aangedragen. Testers zullen per definitie geen changes indienen.
Zij kunnen alleen controleren of de gevraagde functionaliteit al dan niet gere-
aliseerd is: dit leidt dan tot een defect en niet tot een change. Bug fixes blijven
binnen het project en worden voorzien van een prioriteit. Eventueel wordt een
impactanalyse uitgevoerd.
Van change requests zal een impactanalyse gemaakt worden op basis van kos-
ten, doorlooptijd,risico's en complexiteit. Op basis van de afgesproken criteria
waaraan changes moeten voldoen en hoe deze verder worden opgepakt zal het
change request worden ingepland en uitgevoerd. Een change zal dan leiden tot
een gewijzigd applicatiedeel, component, database-structuur et cetera. Dit zal
weer leiden tot een nieuwe (dee1)oplevering.
Wanneer een change verwerkt wordt, zal de gehele keten opnieuw doorlopen
worden. Requirements gaan op de schop, gevolgd door wellicht analyse en
design. Een test zal in ieder geval opgezet dan wel opnieuw uitgevoerd gaan
worden.
Wanneer een gebruiker, collega of medeprojectlid aan je bureau staat met al-
weer de zoveelste change, helpt het om hem of haar te verwijzen naar een
over.
Een changeprocedure zorgt dat wijzigingen op een gecontroleerde manier uit-

gevoerd worden. Je bent werk aan het doen dat niet in de planning opgenomen
is. Dit is achteraf niet meer te controleren, dus loopt het project uit zonder dat
daar een verklaring voor is (behalve je blauwe ogen met 'ik heb dit ook nog
gedaan'-blik).
Op het moment dat de procedure gevolgd wordt, kunnen de mensen die het
overzicht hebben de prioritering van de changes afwegen en eventuele verban-
den naar andere wensen leggen. Het gebruiken van dit soort procedures levert
stuurinformatie op: hoeveel changes hebben we nu eigenlijk voor onze kiezen
gehad (en waarom is dus de planning gewijzigd)? Met name is dit van belang
als wijzigingen eigenlijk toevoegingen zijn op datgene wat is afgesproken. Het
gevaar van ongecontroleerde uitbreiding - zogenoemde scope creep - ligt an-
ders op de loer.
Wanneer een fout (defect) is ontdekt, is de eerste belangrijke vraag of deze

binnen of buiten de scope van de ontwikkelaar ligt. Is de defect gelegen in de
componenten die je op dat moment onder handen hebt, of ligt deze in één van
de al opgeleverde componenten die je gebruikt om te testen. Ligt deze binnen
je eigen werkgebied en is de bug fix als zodanig aangegeven en wordt verwacht
dat je deze oplost, dan zul je eerst weer bepalen welke activiteiten opnieuw
moeten worden uitgevoerd. Heb je andere rollen nodig omdat bijvoorbeeld een
design wordt aangepast? Moeten testen opnieuw worden uitgevoerd? Is wel
duidelijk wat de fout inhoudt (is hij reproduceerbaar)? Communicatie is hierin
van wezenlijk belang: juist bij fouten en changes is het cruciaal om elkaar op
de hoogte te stellen van wijzigingen (want dat zijn het uiteindelijk allemaal)
om de laatste benodigde stand van zaken te creëren.
13 Configuratiemanagement e n changes
De vraag die hier speelt is het moment waarop je fouten (bug fixes) gaat vast-
leggen: ben je vol in ontwikkeling en zijn er nog veel 'open eindjes' dan zal het
vastleggen van fouten niet zoveel toegevoegde waarde hebben. Fouten moeten
doorgegeven of vastgelegd worden indien ze buiten je scope liggen.
Brian A. White. Software Conjguration Management strategies and Rational

Clearcase. Addison Wesley, 2004. ISBN: 0201604787.
Transition is de fase in softwareontwikkeling waarin de verantwoordelijkheid
voor de activiteiten met betrekking tot de applicatie overgaat van de ontwikkel-
groep naar de gebruikersorganisatie en de beheerorganisatie. Uitgangspunt
is dat de bouw van de applicatie, uitgevoerd in het ontwikkelproject, afgerond
is. Een belangrijk doel is dat de gebruikersorganisatie en de beheerorganisa-
tie het systeem accepteren. De Deployment Manager is verantwoordelijk voor
de activiteit Manage Acceptance Test die in deze fase wordt uitgevoerd.
Het doel van de Transition-fase is zeker te stellen dat de software beschikbaar

komt voor de gebruikers en daarna wordt onderhouden. Een Transition-fase
kan uit meerdere iteraties bestaan en omvat naast kleine werkzaamheden in
requirements, analyse& design en implementation, veel testen om de release
voor te bereiden voor de productieomgeving. De accenten uit de andere dis-
ciplines liggen op het terrein van kleine aanpassingen die meer betrekking
hebben op fine-tuning van het product gebaseerd op gebruikersfeedback. De
focus van de gebruikersfeedback ligt in deze fase op configureren, installeren
en problemen met betrekking tot het gebruik: alle functionele en structurele
zaken moeten al uitgewerkt zijn in voorgaande fasen.
Doelstellingen voor deze fase zijn:
e bêtatesten om te valideren dat het systeem werkt conform de verwachtin-

gen van gebruikers;
bêtatesten en parallel werken van nieuwe systeem en het systeem dat wordt
vervangen;
converteren van operationele databases;
verzorgen van ondersteunende artefacts, nodig voor een succesvolle invoe-
ring in de gebruikersorganisatie zoals opleidingen en gebruikershandboe-
ken;
e tuning van activiteiten zoals bug fixing en verbeteringen ten behoeve van
performance en bruikbaarheid;
bereiken van overeenstemming dat de baselines compleet zijn en dat ze
consistent zijn met de evaluatiecriteria uit het Vision-document.
Als de applicatie wordt gerealiseerd als een commercieel product of pakket,

werken we in een andere setting. In dat geval is er geen directe relatie naar een
toekomstige gebruikersafdeling.Dan horen Marketing en Distributie vanaf het
begin als stakeholdersbetrokken te zijn. Tijdens Transition is er dan de opleve-
ring van artefacts die horen bij de aankleding van het product: een fraaie doos,
glossy handleiding, brochures met informatie over opleidingen en helpdesk.
In RUP staat applicatieontwikkeling en overdracht centraal. De voorbereiding

en aanpassing van de organisatie aan de nieuwe applicatie valt buiten de scope
van RUP. Een voorbeeld daarvan: 'Ontwikkelen trainingsmateriaal' is een ac-
tiviteit in RUP; 'Trainen gebruikers' valt buiten RUP. In Nederland zijn we
echter gewend deze zaken wel in projectverband mee te nemen. Zo'n bredere
aanpak wordt in dit hoofdstuk beschreven.
In de rest van dit hoofdstuk wordt niet de RUP-aanpak beschreven, maar een
aanpak gebaseerd op best practices, aangezien RUP hiervoor weinig handvat-
ten biedt in een situatie van maatwerkontwikkeling.
Bij het afsluiten van de Transition-fase of het bereiken van de Product Release
Milestone kan het product in productie genomen worden. Daarna start het
onderhoud. Dit kan betekenen dat een nieuwe Development-cyclus start voor
aanvullende of toevoegingen aan het product, maar het kan ook het startpunt
van releases zijn waarin slecht kleine aanpassingen worden gedaan.
Transition is een aparte fase waarvoor een apart plan nodig is. De fase start bij
het afsluiten van Construction met de Initia1 Operational Capability Milesto-
ne. Alle functionaliteit is dus ontwikkeld en een eventuele alpha-test is gehou-
den. Het is gewenst dat er al aandacht voor Transition is aan het begin van het
project, tijdens Inception. Dit borgt dat er op dat moment al wordt nagedacht
over bijvoorbeeld het betrekken van toekomstige gebruikers en beheerders in
het projectteam, om kennisoverdracht te vereenvoudigen. Bovendien kan zo
eenvoudig bereikt worden dat de eisen en wensen vanuit beheer betrokken
worden. Beheer is ten slotte een belangrijke stakeholder.
Transition eindigt op het moment dat de applicatie productiegereed is. RUP

spreekt over de Product Release Milestone en zegt 'the product is in produc-
14 Transition
tion'. Dat betekent bij het realiseren van een commercieel softwarepakket dat s
er kopieën vervaardigd, verpakt en verkocht gaan worden, en dat het gebruik
valt buiten de scope van het ontwikkelproject. In de wereld van de maatwer-
kapplicatie betekent in productie dat de applicatie daadwerkelijk draait in een
exploitatieomgeving en gebruikt wordt door eindgebruikers. Net een stapje
verder dus, maar dat is wel de situatie die ons voor ogen staat. Gebruikelijk is
dat het ontwikkelproject in afgeslankte vorm nog korte tijd na in productie ne-
men ondersteuning verleent aan gebruikers en beheerorganisatie. Soms loopt
dat parallel met een nieuw ontwikkelproject voor een volgende release.
Als de Transition is afgerond, moet het beheerteam in staat zijn om de activi-

teiten voor de gebruikersorganisatiem.b.t. de instandhouding en aanpassingen
van de applicatie zelfstandig op te pakken. Dan moeten er duidelijke afspraken
zijn over de serviceniveaus waaraan het team tegemoet dient te komen. Om te
voorkomen dat de Transition-fase te lang gaat duren, door perfectionisme van
de beheerders of onzekerheid van de gebruikers, is het zaak om tijdig en in
volle breedte aandacht te geven aan de implementatieaspecten,die we hieron-
der bij COPAFIJTH noemen. Soms blijkt dat niet mogelijk, bijvoorbeeld als
beheer wordt uitbesteed en deze externe partner pas laat betrokken wordt. Dan
is een best practice om vertraging te voorkomen: de bestaande beheerproces-
sen zoveel mogelijk één op één over nemen en pas na overdracht te gaan wer-
ken aan het verbeteren of standaardiseren van deze beheerprocessen.
Transition is de fase van overdracht. In onderstaande afbeelding geven we aan

welke organisatieonderdelendaarbij betrokken kunnen zijn.
Figuur 14.1: Onderdelen bij een Transition

Als je vanuit het project naar de activiteiten binnen de Transition-fase kijkt,

zie je dat de activiteiten in deze fase op te splitsen zijn naar twee ontvan-
gende groepen: de gebruikersorganisatie en de beheerorganisatie. Ook tussen
gebruikers en beheer onderling zullen afspraken nodig zijn: op welk beschik-
baarheidsniveau en tegen welke kosten zal de applicatie geëxploiteerd worden.
Gewoonlijk leidt dat tot een SLA (Service Level Agreement) tussen beide par-
tijen. In Nederland wordt ook de term DN0 (Dienstenniveauovereenkomst)
gebruikt.
In de RUP-knowledge base is de Transition-fase primair gericht op het ople-

veren van een product voor exploitatie. Aanpassingen of activiteiten die in de
gebruikersorganisatieenlof in de beheerorganisatie nodig zijn, worden nauwe-
lijks belicht. Dat past goed bij het opleveren van een pakket of een commerci-
eel software product, als de toekomstige gebruikers nog niet bekend zijn. Maar
bij opleveren van een maatwerkapplicatie is er natuurlijk grote interactie met
gebruikers en beheer vereist. Wij beschrijven in dit hoofdstuk de activiteiten
die in het project plaatsvinden én de activiteiten die op de ontvangende afde-
lingen plaatsvinden. Daarbij gaan we uit van bovenstaand model: het project
trekt de overdracht naar beheer én gebruikers. Maar alternatieven, zoals in
onderstaande afbeelding zijn ook denkbaar.
Figuur 14.2: Overdrachtsmodel
Zeker als het uitrollen in een gebruikersorganisatie een gefaseerde actie is

waarbij diverse locaties betrokken zijn, dan ligt het voor de hand dat het pro-
ject wel bij de eerste uitrol betrokken is, maar dat vervolgacties door beheer
worden verzorgd.
14 Transition
RUP is een proces voor software engineering. Het richt zich op het opleveren
van een applicatie en ondersteunende artefacts, maar niet op het implemente-
ren van een systeem, waarbij een systeem gezien mag worden als samenspel
tussen organisatie, processen en applicatie.
Om een applicatie succesvol in gebruik te kunnen nemen dient niet alleen de

ITin orde te zijn, maar zijn er veel meer aspecten die aandacht verdienen.
Dat is niet nieuw. Die bredere invulling vinden we terug in de OPAFIT of

COPAFIJTH-aspecten.OPAFIT is een acroniem dat stamt uit de jaren 80 van
de vorige eeuw. Later is het uitgebreid tot COPAFIJTH, waarbij elke letter een
bepaald aspectgebied aanduidt.
Bij het evalueren van deze aspecten moet gekeken worden naar alle partijen die
betrokken zijn bij het invoeren en exploiteren van de nieuwe applicatie. Ver-
wacht mag worden dat de implicaties voor de gebruikersafdeling het grootst
zijn, maar ook voor de beheerorganisatie kunnen aspecten van belang zijn.
De COPAFIJTH-aspecten moeten al tijdens de Inception-fase aandacht krij-

gen, om te zorgen dat het op te leveren softwareproduct terecht komt in een
omgeving die daarop is voorbereid. Bepaalde deelaspecten kennen een lange
aanlooptijd. We noemen het hier bij de fase Transition, omdat in die fase de
punten op de i gezet moeten worden. Wat moet worden opgepakt door het
project en wat door de staande organisatie is afhankelijk van de afspraken
(verantwoordelijkheden 1bevoegdheden) met de organisatie.
Hieronder stippen we de verschillende aspecten kort aan, zodat jij als ontwik-
kelaar beseft dat er nog veel meer speelt dan het realiseren van software die
voldoet aan de Requirements.
CommercieICommunicatie
Onder dit hoofdaspect vallen: Marketing, Externe Communicatie, Imago,
Public Relations, Klantcontacten, Partners. Aandacht voor dit aspect is zeer
belangrijk als het project een product oplevert voor de commerciële markt of
als de gebruikersgroep buiten de eigen organisatie valt. Dit komt bijvoorbeeld
voor bij een touroperator die een extranet-applicatieheeft ontwikkeld ten be-
hoeve van reisboekingen door reisagenten. Die heeft er belang bij om het ge-
bruik van de applicatie te bevorderen, maar blijft eigenaar van de applicatie.
Organisatie en Personeel
Welke consequenties heeft de ingebruikname van de applicatie op organisatie
en personeel? Voor de gebruikersorganisatie kan het betekenen dat personen
moeten afvloeien of juist moeten worden aangetrokken, of dat huidig perso-
neel moet worden opgeleid of bijgeschoold. We zien direct dat bepaalde zaken
veel verdergaande implicaties hebben dan door een softwareontwikkelteam
getrokken kan worden. Dergelijke zaken zouden al tijdens de Inception in de
Business Case naar voren moeten zijn gekomen.
14 Transition
Voor beheer moet bepaald worden hoeveel mensen ermee gaan werken en
welke competenties zij dienen te bezitten. Wie komen hiervoor in aanmerking,
wie zijn beschikbaar, waar in de beheerorganisatie wordt de verantwoordelijk-
heid belegd et cetera. Een opleidingseis die vanuit RUP naar voren komt is dat
medewerkers die verantwoordelijk worden voor het applicatiebeheer kennis
hebben van RUP en UML.
Administratieve Organisatie
Met name op de gebruikersafdeling kunnen administratieve procedures en
processen op de schop gaan. Nieuwe processen moeten ontworpen, vastgelegd
en onderwezen worden.
Misschien zijn er externe partijen (leveranciers, klanten) waarmee op een an-
dere manier moet worden samengewerkt, bijvoorbeeld via internet.
Voor beheer kunnen we ons afvragen of de interne procedures toereikend zijn

voor het in productie nemen van de applicatie. Denk daarbij aan een wijzi-
gingsprocedure, inrichting van een helpdesk (stand by buiten kantooruren),
procedures voor uitwijk tijdens noodscenario's. Vaak wordt hiervoor gebruikt
gemaakt van ITIL, als best practice voor het inrichten van beheerprocessen.
Financiën
Bijna alle punten, genoemd bij de andere aspecten, hebben ook een financiële
component. Maar die is zeker aanwezig bij tarifering (doorbelasting van het
runnen van de applicatie aan de verschillende eindgebruikersgroepen) en bij

het opstellen van een SLA.
rmatie
Onder dit hoofdaspect vallen: interne communicatie, productinformatie, pro-
jectinformatie, rapportage en verantwoording, mediabeleid, interfaces met an-
dere systemen, informatiehuishouding, externe databases. Een noodzakelijke
factor voor succesvol gebruik door de gebruikersafdeling is draagvlak. Daar-
aan moet al tijdens de loop van het project worden gewerkt door betrokken-
heid te creëren: het bedrijfsjournaal, het intranet, een nieuwsbrief zijn kanalen
waardoor het project naar buiten kan treden.
Juridisch
Zeker als de applicatie impact heeft op doelgroepen buiten het bedrijf, dan
spelen zaken als contractbesprekingen, bezwaarprocedures, weten regelge-
ving, jurisprudentie. Ook het eigendom van de applicatie moet goed geregeld
worden zeker als er tijdens ontwikkelen delen zijn uitbesteed aan subcontrac-
tanten of als er componenten van derden worden gebruikt. Ook als het beheer
wordt uitbesteed aan een externe partij, dan zijn er contractbesprekingen over
een SLA.
Technologie
Onder dit hoofdaspect vallen zaken als infrastructuur, netwerken, hardware,
hulpmiddelen en inrichting werkplek. Allereerst geldt dat voor de gebruiker-
somgeving, die wellicht anders ingericht moet worden. Maar alle nieuwe tech-
nologische componenten moeten ook beheerd worden. Veelal in dezelfde be-
heerorganisatie die ook het beheer van de applicatie op zich neemt. De beheer-
organisatie moet de (financiële) middelen krijgen om de applicatie te beheren.
Vaak is de koppeling tussen applicatie en infrastructuur niet een-op-een, maar
zullen in dezelfde infrastructuur verschillende applicaties geëxploiteerd wor-
den. Belangrijk is dat een beheerorganisatie dient te beschikken over een vol-
ledige OTAP-omgeving (Ontwikkel, Test, Acceptatie, Productie). Tooling is
een ander onderwerp waar afspraken over gemaakt dienen te worden. Vaak is
er vanuit het RUP-project gewerkt met standaard tools. De artefacts die hierin
zijn opgesteld kunnen makkelijker worden overgenomen indien de beheerpar-
tij dezelfde tools hanteert. Licenties voor deze tools dienen te worden geregeld,
evenals voldoende werkplekken met de juiste infrastructuur.
uisvesting
Onder dit hoofdaspect vallen vestigingsbeleid, geografische spreiding, huis-
vesting, thuiswerken, facilitaire dienst. Allemaal onderwerpen met impact op
de lange-termijn. Als er door het invoeren van de applicatie wijzigingen nodig
zijn op deze onderwerpen is het zaak dat tijdig aan te kaarten.
14 Transition
Overeenkomstig het eerder geschetste beeld van drie betrokken organisatieon-

derdelen, te weten het project, de gebruikersorganisatie en de beheerorganisa-
tie kunnen we deze activiteiten opdelen in drie onderdelen:
activiteiten door project, gericht op overdracht naar gebruikersorganisatie

resp. naar beheer;
activiteiten in de gebruikersorganisatie;
e activiteiten in de beheerorganisatie.
De veronderstelling daarbij is dat het project het initiatief neemt zowel richting
gebruikersorganisatie als richting beheer. In de praktijk kan dat anders liggen
zoals hiervoor geschetst.
Tijdens de Transition-fase worden alle activiteiten ondernomen om een suc-

cesvolle uitrol te realiseren. De belangrijkste activiteiten zijn te vinden in het
Deployment Plan en omvatten het completeren van de gebruikersdocumenta-
tie, het testen van het product, het verwerken van gebruikers feedback en het
uitvoeren van kleine aanpassingen. Afgesloten wordt met een oplevering van
een productrelease.
Een belangrijke activiteit in deze fase is het Project Acceptance Review. Dit
is een formeel review van het projectteam en een representatieve vertegen-
woordiger van de gebruikersorganisatie. Door middel van dit review verifi-
eert de gebruiker of het product en de ondersteunende documentatie door het
project opgeleverd in overeenstemming is met de doelen uit het beschreven in
het Software Development Plan. Voor de ontwikkelaar gaat het erom in deze
periode aan te tonen dat goede kwaliteit is geleverd. De ontwikkelaars die in
deze fase nog participeren zien het accent verschuiven van design, testen en
implementeren naar afmaken van documentatie. Soms kan de ontwikkelaar
een rol krijgen bij het instrueren van toekomstige gebruikers of het verzorgen
van trainingen aan gebruikers en beheerders.
Deze activiteiten vloeien voort uit de COPAFIJTH-brede blik, maar spelen

zich grotendeels buiten het gezichtsveld van de ontwikkelaar af. Ze zijn vanuit
de doelstelling van dit boek dus minder interessant. Maar het gereedmaken
van de gebruikersorganisatie voor een geslaagde uitrol van een nieuwe appli-
catie is een kritische succesfactor voor het uiteindelijke succes.
Activiteiten door
Doelstelling voor beheer tijdens de Transition is een goed beeld te krijgen van
de over te nemen applicatie en het maken van afspraken over de dienstverle-
ning. De beheerorganisatie moet daarvoor de volgende activiteiten uitvoeren:
Kennisopbouw. Dit is het meest moeilijk te managen en te meten onder-

deel. Alles staat of valt met vertrouwen in de competenties van de beheer-
ders en de mate waarin de projectteamleden, hun 'kindje', de applicatie
kunnen loslaten. Het kan helpen om te zoeken naar objectieve criteria en
deze door middel van een soort examen of een case te meten.
e Bepalen welke artefacts overgedragen moeten worden.
Verifiëren dat de over te dragen artefacts aanwezig, compleet en up-to-date
zijn. Tijdens de laatste tests en aanpassingen wordt het up-to-date houden
niet altijd in het oog gehouden.
Beoordelen van de Incidentlist en de foutregistratie. Zijn er nog openstaan-
de of bekende problemen? En zijn die via work-arounds opgelost?
Beoordelen van testresultaten. Zijn tests aantoonbaar en naar verwachting
uitgevoerd?
Verifië en dat de gebruikersorganisatie de applicatie heeft geaccepteerd.
Naast deze activiteiten dient de beheerpartij met de gebruikersorganisatie af-

spraken te maken over de dienstverlening. Hierbij wordt gekeken naar de kos-
ten van het beheer op jaarbasis, gebaseerd op de baseline die wordt opgeleverd
14 Transition
en de ervaringen vanuit het project. Om de omvang en complexiteit van het te

beheren systeem vast te stellen, kan een Quick Scan uitgevoerd worden waarin
een uitgebreide vragenlijst wordt ingevuld. Omvangbepaling baseert zich vaak
op Functiepunten. Nieuwere technieken die beter aansluiten bij de RUP-arte-
facts zijn Use Case punten of COSMIC Full Functions Points. Daarnaast wordt
met de gebruikersorganistie afgestemd of er al een volgende release is gepland
en of er al aanvullende wensen bekend zijn. Dezedienen ook gecalculeerd en
ingepland te worden voor de beheeractiviteiten.
De RUP-documentatie is een zeer belangrijke bron van gegevens voor het be-
heerteam in de Transition-fase. In elk geval bekijken de toekomstig beheerders
de volgende artefacts:
Business Object Model (Business Entities + Business Workers), indien aan-

wezig;
Glossary;
Vision document, dat bevat de afgesproken uitgangspunten en acceptatie-
criteria;
Software Development Plan;
SRS Software Requirements Specifications;
Use Case Model + Use Case Specifications;
SAD (Software Architecture Document) omdat hierin alle belangrijke be-
slissingen in zijn verwoord;
Deployment Plan;
Testplan;
Use Case Realizations + class model. Gecontroleerd wordt ook of ze actu-
eel gehouden zijn. UCR's zijn vaak initieel opgezet, maar niet onderhou-
den;
Source code. Deze moet gedocumenteerd zijn óf in de code óf in goede
aparte documentatie. Deze documentatie moet worden beoordeeld op on-
derhoudbaarheid, d.w.z. modulair, structuur, eenduidigheid naamgeving,
aanwezigheid commentaar.
De belangrijkste producten die een beheerorganisatie tijdens de Transition-

fase oplevert zijn de volgende.
De activiteiten van beheer tijdens deze overdrachtsfase worden vanuit het be-
heerperspectief vastgelegd. Afhankelijk van de situatie in de organisatie kan
dit een onderdeel zijn van het overkoepelend projectplan voor de fase Transiti-
on. In elk geval zullen de datums afgestemd moeten zijn met dat projectplan.
nventarisatiesheet van kennis

Deze wordt gemaakt tijdens de kennisoverdracht. In beeld wordt gebracht wel-
ke kennisgebieden er zijn en in welke mate deze door de medewerkers wordt
beheerst. Dit document wordt aan het begin van de kennis overdracht gemaakt
en aangevuld tijdens de kennisoverdracht.
14 Transition
Acceptatieforma
Het formulier waarop de beheergroep aangeeft dat zij akkoord met hetgeen is
opgeleverd en in staat zijn om het beheer correct uit te kunnen voeren.
Service Level Agreement (SLA)

Overeenkomst met de gebruikers conform het proces Service Level Manage-
ment uit ITIL.
Hierin wordt beschreven hoe de SLA-afspraken nageleefd zullen gaan worden

door de beheerorganisatie. Daarbij dient rekening gehouden te worden met de
werkwijzen en artefacts zoals deze vanuit het project worden opgeleverd. Ook
wordt vastgelegd welke RUP-artefacts en welke specifieke beheerdocumenta-
tie (zoals incidentenlijst) wordt bijgehouden door de beheergroep. Use cases
dienen veelal wel te worden bijgewerkt, terwijl het vision document en de glos-
sary doorgaans niet meer worden gewijzigd in de beheerfase.
Tot slot: In het SQP wordt ook vastgelegd of onderhoud met dezelfde (RUP)
tools zal plaatsvinden als de initiële ontwikkeling. Dat lijkt voor de hand te lig-
gen in een organisatie die ontwikkeling en beheer in eigen hand houdt, maar
bij uitbesteding ligt hier echt een beslispunt. En hangt er een kostenplaatje
aan!
In dit hoofdstuk behandelen we wat algemene aspecten en achtergronden van
beheer. Vervolgenswordt aangegeven voor welke soorten van beheer RUP een
interessant proces kan zijn. We belichten de ZTZL-indeling die vaak gebruikt
wordt voor het inrichten van processen in een beheerorganisatie en kijken
naar de overlap en wederzijdse aanvulling tussen RUP en ZTZL. Ook wordt
kort stilgestaan bij ASL, een relatief nieuwe methode voor beheer. We sluiten
af met een paragraaf die aangeeft op welke wijze je als ontwikkelaar tijdens
de initiële ontwikkeling aandacht kunt besteden aan beheer.
Als een applicatie ontwikkeld is, komt hij in een volgend stadium van zijn
levenscyclus: die van exploitatie en beheer. Exploitatie is het operationeel in
de lucht houden met activiteiten als backup en recovery, monitoren van de
werking en analyseren van het gedrag. Beheer richt zich op het onderhoud van
de applicatie. Daarbij kan onderscheid gemaakt worden tussen:
e correctief onderhoud, om fouten op te lossen. Fouten kunnen zo urgent

zijn, dat ze onmiddellijk moeten worden hersteld;
adaptief onderhoud, om de applicatie aan te passen aan gewijzigde behoef-
ten;
e perfectief onderhoud, om het systeem te verbeteren of om de beheerkosten
te verlagen. Denk aan het opruimen van nutteloze transacties, het verwijde-
ren van overbodige stukken in de code, het optimaliseren van de code van
een rekenalgoritme.
Kort gezegd: het doorvoeren van wijzigingen in de applicatie is beheer. In de

praktijk wordt de term beheer in ruimere zin wel gebruikt voor zowel onder-
houd als exploitatie.
De kosten die gemoeid zijn met het operationeel houden van de applicatie (ap-
plication management) zijn substantieel. Naar schatting gaat het om 80% van
alle kosten gedurende de levenscyclus van een applicatie.
Gebruikersorganisaties zijn zich er steeds meer van bewust dat beheer een
belangrijke rol vervult in de levenscyclus en vragen een zo efficiënt en effectief
mogelijk onderhoud tegen de laagst mogelijke kosten. Tijdens het ontwikkel-
traject moet al serieus rekening gehouden worden met de eisen ten aanzien
van beheer.
Bestaande applicaties operationeel houden en de dienstverleninggaranderen,is

met name van belang voor bedrijfskritische applicaties. Applicaties die een es-
sentieel onderdeel van de bedrijfsvoering zijn, zullen met een zo minimaal
mogelijke impact op de bedrijfsvoering moeten worden beheerd.
Sommige applicaties zijn lang operationeel en wijzigen niet omdat de functi-

onaliteit voldoet en de performance en de stabiliteit prima zijn. Andere appli-
caties zijn wel onderhevig aan veranderingen, organisaties veranderen immers
ook steeds vaker, de software die hun bedrijfsprocessen ondersteunt zal dus
mee moeten veranderen. Het uitbreiden en aanpassen van deze software mag
geen impact hebben op de activiteiten van de organisatie en vraagt dus om een
efficiënt en gestructureerd beheer.
Vaak wordt het beheer van de applicatie door een eigen beheerorganisatie ver-
richt. Er zijn echter ook externe partijen die het beheer van applicaties verzor-
gen, veelal in een speciaal AMSC (Applicadon Management Service Center).
Dergelijke aanbieders van beheer moeten scherp zijn op hun proces om hun
diensten concurrerend te kunnen blijven leveren. Standaardisatie van de werk-
wijze en documentatie zijn belangrijke mogelijkheden voor kostenreductie.
Beheer van productiesystemen houdt ook in dat er breder moet worden geke-
ken dan de initieel ontwikkelde applicatie. De gehele infrastructuur staat ten
dienste van de organisatie en storingen hieraan kunnen vergaande gevolgen
hebben. Het wijzigen van, op het eerste oog, onbelangrijke configuratiepara-
meters kan tot gevolg hebben dat applicatieonderdelen niet meer functioneren.
Hier is een belangrijke rol weggelegd voor de Change Manager, die op de
hoogte dient te zijn van alle wijzigingen in het productiedomein en na een ge-
degen impactanalyse goedkeuring geeft voor het doorvoeren van de wijziging.
15 Beheer
Dit geldt naast applicatiecomponenten ook voor infrastructuurcomponenten

als servers, netwerken, databases en middleware.
Het niveau van dienstverlening wordt vastgelegd in een Service Level Agree-
ment (SLA). Deze overeenkomst wordt opgesteld tijdens de transitie naar de
beheerorganisatie en bevat afspraken met de gebruikersorganisatie, veelal ei-
genaar van de applicatie. Zie ook het hoofdstuk Transition.
Het SQP (Service Quality Plan), ook een artefact gemaakt tijdens de Transi-
tion-fase, is de invulling van de in het SLA vastgelegde afspraken. Hierin is
in detail beschreven hoe de verschillende processen worden uitgevoerd en wat
de werkafspraken zijn, zoals betreffende reactietijden voor storingen. Activi-
teiten en processen die worden beschreven in het SQP zijn de ITIL-processen:
Service Level Management, Incident Management, Problem Management,
Change Management, Availability Management, Configuration Management,
Security Management en Capacity Management.
Zie paragraaf RUP en ITIL.
Er zijn verschillende soorten beheer. Naast het doorvoeren van kleine correc-
tieve wijzigingen om de applicatie draaiende te houden, worden adaptieve wij-
zigingen uitgevoerd om nieuwe functionaliteit toe te voegen. Komt het voor dat
grote stukken functionaliteit worden bijgebouwd, dan kan ook gedacht worden
aan het inrichten van een nieuw ontwikkelproject. Wijzigingen die meer dan
een aantal nader vast te stellen uren gaan kosten, zullen projectmatig opgepakt
worden. Zo'n project krijgt het karakter van (ver)nieuwbouw en daarmee van
een normaal systeemontwikkelprojecten verliest dan de specifieke invalshoek
van hetbeheer. In overleg met de klant wordt zo'n bovengrens voor directe
afhandeling door de beheerorganisatie vastgelegd in de SLA.
Er zijn verschillen tussen maatwerkbeheer en maatwerkontwikkeling, zoals

de toegelaten doorlooptijd. Die is bij beheerveranderingen vaak korter dan bij
een project. Het is dan essentieel de functionaliteit compleet en snel te kunnen
testen. Verder ligt de focus bij het wijzigen en testen op de algehele werking
van het systeem, de impact op de productie moet zo klein mogelijk blijven.
Een veelgemaakte onderverdeling gemaakt is die in

r. Vaak ondergebracht bij de gebruikersorga-

van functionele specificaties en het beant-
. Het uitwerken van technisch ontwerp (Use

Case Realizations) en implementatie van de technische (code-)wijzigin-
gen.
Daarnaast onderscheidt men nog 'technisch infrastructuurbeheer'. Dit is het

aanpassenlbewaken van de non-functional Requirements, zoals aanpassingen
van een operating system of de aanpasing van diverse netwerkcomponenten.
Ook onderscheidt men proactief beheer door middel van monitoring van de
server, het netwerk, databases, etc.
Delen van beheer kunnen uitgevoerd worden door verschillende partijen, zoals
de gebruikersorganisatie zelf (vaak functioneel beheer), een eigen beheerafde-
ling bij de gebruikende organisatie (technisch applicatiebeheer), of de moeder-
of zusterorganisatie voor de exploitatie en het technisch beheer.
De organisatie kan ook kiezen voor het outsourcen van beheer naar een on-
afhankelijke commerciële partij, die het totale beheer en exploitatie van de
applicatie, of delen daarvan (hybride model) kan verzorgen.
De scope bij beheer is gericht op het hele businessdomein, in tegenstelling

tot bij softwareontwikkeling waar sprake is van een projectscope (vaak een
applicatie). Het businessdomein bestaat vaak uit meerdere applicaties met on-
derlinge interfaces, databases, middleware, hardware en dergelijke, die alle
aan verandering onderhevig zijn. Hierdoor is het extra belangrijk om ook de
ITIL-processen zoals incident-, change- en configuratiemanagement goed in
te richten.
ITIL is voor veel beheerorganisaties de leidende methode voor de inrichting

van de eigen processen. RUP is een methode, die in het beheer van applicaties
zinvol gebruikt kan worden als proces bij het doorvoeren van wijzigingen op
de applicatie. Daarom is het van belang om de relatie te leggen tussen RUP in
beheer en ITIL.
15 Beheer
HTIL en RUP
Configuration Management
Voor applicatiebeheer omvat dit het managen en registreren van de software-
versies en artefacts, maar ook van infrastructuur- en middlewarecomponenten.
Deze laatste twee onderdelen worden als randvoorwaarden in RUP vastgelegd
in het Software Architecture Document. Later, in de operationele fase, zijn zij
een onderdeel van de configuratie. Binnen de ontwikkeling van veranderingen
in de applicaties kan dus wel gebruik gemaakt worden van werkwijzen uit
RUP, die zelfs een eigen discipline Configuratie Management onderkent. Daar
wordt namelijk beschreven hoe voortdurend de iteratieve wijzigingen in de
configuratie worden bijgehouden en gemanaged. Bij opleveren kan dit naad-
loos in de beheerorganisatie opgepakt en voortgezet worden.
Deze processen kunnen putten uit de artefacts die vanuit RUP worden opge-
leverd. Vooral bij het analyseren van een incident, om te bepalen of het daad-
werkelijk om een verstoring van de dienstverlening gaat, wordt gekeken of de
applicatie nog voldoet aan de opgestelde requirements. Traceability van Re-
quirements, ondersteund door RUP, is hierbij een belangrijk voordeel. Afhan-
kelijk hiervan wordt bepaald of er mogelijkerwijs sprake is van een 'change'.
In dat geval gaat de melding over naar het Change-proces.
De afhandeling van wijzigingen op applicaties kan voor wat betreft het ont-
werpen en realiseren van deze wijziging uitgevoerd worden door gebruik te
maken van werkwijzen zoals in RUP beschreven. Deze aanpak wordt beschre-
ven in de Beheer Development Case.
15 Beheer
Binnen RUP beschrijft het Sofware Architecture Document hoe de software

moet zijn gedistribueerd over de infrastructuur. Het SAD bevat belangrijke
informatie voor dit ITIL-proces. De discipline Deployment beschrijft onder
andere de installatiestappen en componenten.
Vanuit de processen Service Level Management, Capacity, Availability , Con-

tingency Planning en Cost Management worden eisen gesteld aan de appli-
catie. Deze eisen kunnen worden vertaald in non-functionele Requirements, .
die ook al tijdens de ontwikkeling van de applicatie meegenomen behoren te
worden. Het is daarom aan te raden om in een vroegtijdig stadium deze be-
heerpro&ssen te bekijken en op basis daarvan acceptatiecriteria op te stellen.
Een andere, relatief nieuwe methode voor beheer die steeds vaker wordt ge-
bruikt voor het inrichten van processen voor applicatiebeheer is ASL. Een
belangrijke ontwikkeling hierbij is dat niet alleen aandacht wordt besteed aan
operationele en tactische processen, maar ook aan strategische overwegingen.
Innovatie van applicaties en applicatiebeheerorganisaties zijn de sleutel tot
succes van informatie-intensieveorganisaties.
De ASL Foundation (http://www.aslfoundation.org) verklaart dat ASL als

doel heeft het vak Applications Management te professionaliseren en dat wil
bereiken door het bieden van een framework, waarin de processen van appli-
cations management tot elkaar in relatie gebracht worden. Daarnaast dient het
framework als kapstok om ontwikkelde best practices te categoriseren.
Naast het framework omvat ASL een uniforme woordenlijst. Door het gebruik
daarvan kunnen bij het applications management betrokken partijen beter met
elkaar communiceren.
ASL is een methodiek uit het publieke domein en streeft het doel na niet alleen
binnen één organisatie, maar ook als uniformerende factor tussen organisaties.
ASL sluit ondermeer aan op ITIL, dat zich met name focust op het technisch
beheer. ASL bestaat uit een framework en een library van best practices op
gebied van applicatiebeheer (de partij die de functionaliteit en werking van de
applicatie onderhoudt). ASL beoogt de bedrijfsprocessen optimaal te onder-
steunen met informatiesystemen gedurende de gehele levenscyclus van deze
bedrijfsprocessen.
ASL wordt vooralsnog hoofdzakelijk toegepast bij in Nederland werkende or-

ganisaties, maar kent een groeiend gebruik.
Al tijdens het ontwikkelen is het van belang om te weten wat de gevolgen van
de gekozen oplossingsrichting zijn voor het onderhoud. Natuurlijk is het leuk
om iets ingewikkelds heel goed uit te werken in design en code, maar als de
documentatie ingewikkeld is en aanpassen ruime studie en kennis vereist, is
het voor de beheerder extra risicovol om deze software in beheer te nemen. Het
kost dan immers veel tijd om het complexe design en de code te begrijpen en
de kans op fouten en extra aanpassingen neemt toe. Dit geldt des te meer als
de documentatie summier is of niet consistent is (telkens een andere vorm of
andere modellen). Vanaf de aanvang moet dus duidelijk zijn welke mate van
documentatie gewenst is en hoe deze later gebruikt gaat worden.
Om problemen in de productieomgeving te voorkomen, moet rekening worden

gehouden met mogelijke versieverschillen van bijvoorbeeld het operating sy-
stem, modelleer- en conversietools en interfaces in de ontwikkelen productie-
15 Beheer
fasen. Hierdoor kunnen zich problemen in die productie-omgeving voordoen

die niets te maken hebben met de applicatie maar met de omgeving waarin de
applicatie moet werken.
Daarom moet het tijdens een ontwikkeltraject duidelijk zijn wat de consequen-
ties van een bepaalde design- of architectuurkeuze voor beheer zijn. Houd
daarbij niet alleen rekening met het direct in productie brengen en operatio-
neel houden, maar ook met toekomstige wijzigingen van de applicatie.
Om te bereiken dat de Software Architect of Designer vanaf het begin reke-

ning houdt met de implicaties van een design in de exploitatie- en beheerfase,
is het zaak om de acceptatiecriteria van de beheerorganisatie als 'supplemen-
tary requirements' in het projectdossier te laten opnemen. Daarmee komen
de beheeraspecten aan bod. Voor de beheerorganisatie ligt er dus een taak
om deze acceptatiecriteria als duidelijke instructie of checklist beschikbaar
te stellen.
Tijdens de ontwikkeling van een applicatie moet beheer als belangrijke stake-
holder worden beschouwd, die zijn Requirements inbrengt. Acceptatiecriteria
vanuit beheer kunnen de volgende punten omvatten:
eenduidige, consistente en complete documentatie;

e commentaar opgenomen in de code;
beschikbaarheid van testsets;
passend op de infrastructuur (netwerk, hardware, operating systemen, da-
tabases);
performance- en systeembelasting: de applicatie moet kunnen draaien in
een gebruikersomgeving waar al meerdere andere applicaties, systemen en
databases draaien;
er worden Guidelines met codeerstandaarden opgeleverd en de applicatie is
gebouwd conform deze codeerstandaarden;
e er is een versiebeheersysteem ingericht;
e er is een Configuratie Management Plan en opname in en migratie naar de

Configuratie Management Database van beheer is (eenvoudig) mogelijk;
er is en installatiehandleiding en bijbehorende installatiescripts.
Zo kunnen we voorkomen dat de beheerorganisatie te maken krijgt met het

beruchte 'gooi over de muury-gedrag.
Daarnaast hebben beheerders vaak niet dezelfde kennis en ervaring met be-
trekking tot de werkwijzen en documentatie vanuit het ontwikkelproject: goe-
de overdrachtltransitieis daarmee essentieel voor het beheer.
Het betrekken van beheer bij de ontwikkeling leidt tot een win-winsituatie.
Zowel het project als de beheerorganisatie hebben er baat bij. Immers het suc-
cesvol uitrollen en exploiteren van een applicatie straalt af op beide groepen.
We moeten beseffen dat de kosten van beheer verreweg het grootste van de
kosten uitmaken in de lifecycle van een applicatie; de ontwikkelkosten bedra-
gen veelal niet meer dan 20% van de kosten van de totale lifecycle.
15 Beheer
Bovendien leidt het veronachtzamen van beheereisen tijdens de initiële ontwik-

keling van de applicatie tot extra onderhoudskosten en een moeilijk toeganke-
lijke applicatie. Daardoor kan de bruikbaarheid van de applicatie afnemen,
zodat deze niet het verwachte rendement oplevert en wellicht zelfs voortijdig
uit productie wordt genomen.
Als designer in een developmentproject kun je al je aandacht richten op het

realiseren van je artefacts. In de rol van Developer of Implementer heb je vaak
alleen oog voor de nieuwe applicatie, de functionaliteit die je moet gaan ople-
veren en wat belangrijke designaspecten zijn. Dat er ook eisen zijn wat betreft
onderhoud wordt dan gemakkelijk vergeten. Als je echter een keer in een be-
heerproject hebt meegewerkt, dan besef je heel goed dat er vele eisen zijn die
je aan een applicatie kunt stellen om het geheel succesvol te kunnen invoeren
en operationeel te houden.
Tijdens de initiële ontwikkeling wordt er vaak onvoldoende aandacht besteed
aan deze aspecten en ligt de focus op realisatie van de gewenste functionali-
teit.
Svsteemontwikkelina met R U P
Vaak zie je dat in projecten allereerst wordt nagedacht over de eisen en wen-
sen van een nieuw stukje functionaliteit. De nadruk ligt logischerwijs op de
nieuwe functionaliteit en het zoeken naar een goede oplossing. Zelfs bij het
opstellen van de planning wordt veelal alleen gekeken naar de nieuwe functio-
naliteit en de risico's voor het ontwikkelen daarvan. Als beheerder of designer
kun je dan een grote bijdrage leveren door gericht met een aantal aspecten te
komen, concreet en meetbaar, die zorgen dat tijdens design, bouw en testen
ook aandacht besteed wordt aan de beheeraspecten.
15 Beheer
Als er nog geen acceptatiecriteria zijn, is het van belang ervaringen uit het
verleden te analyseren en daaruit een aantal aanbevelingen te formuleren die
de mogelijkheden van een succesvol beheer bevorderen.
We hebben vastgesteld dat Beheer een van de stakeholders is tijdens ontwik-

keling van nieuwe software en als zodanig moet genoemd worden in het Vi-
sion-document. Daarvoor zou aan de projectleider de navolgende standaard
stakeholder beschrijving ingevuld met de echte gegevens kunnen worden
doorgegeven.
Voorbeeld van een standaardbeschrijving van een stakeholder.
Representative Jan Proactief - Afdeling Productie en onderhoud

Description Enkele identificerende persoonsgegevens
I Tyy Expert met betrekking tot onderhoud van softwaresystemen in het

bijzonder interface dotNet en legacy
Responsibilities Verantwoordelijk voor het in stand houden van de dienstverlening

die de applicatie biedt aan de eindgebruikers. Uitvoeren van de
afspraken uit de SLA
Success Criteria Als de software goed werkt in samenwerking met andere systemen
en eenvoudig te hanteren is in de productie en beheer kan beter
voldaan worden aan de eisen gesteld in de SLA
I
Involvement I Stakeholder, gaat applicatie beheren
Deliverables .....
Comments / Is- .....
mes
Bij kleine projecten is de projectleider of de softwarearchitect het aanspreek-

punt voor de beheerders. Bij grote projecten zal er vaak een aparte Deploy-
ment Manager zijn. Dan zijn er ook veel meer aspecten die een rol spelen
(meerdere clients, meerdere servers, versiebeheer tijdens invoering, etc.) en
nauw samenwerken met de beheerorganisatie zal nodig zijn om de applicatie
uit te rollen, soms zelfs in meerdere iteraties.
Dit laatste aspect geeft ook aan dat er nauw moet worden samengewerkt, want
na de overdracht is de beheerorganisatie verantwoordelijk voor het geheel.
Zorg voor een duidelijke kennisoverdracht, niet alleen in de vorm van model-
len en documentatie, maar door geregeld overleg en betrokkenheid bij design
en implementatie. Pas wel op voor de valkuil dat het overleg tussen ontwik-
kelaars en beheerders de aanwezigheid van complete en consistente documen-
tatie kan vervangen.
Als best practice is al genoemd continuïteit in de personele bezetting. Dat kan

door de beheerorganisatie al tijdens ontwikkeling teamleden te laten leveren
voor het project en in de eerste periode na overdracht naar beheer nog enkele
ontwikkelaars deel te laten nemen in het beheerteam. Desgewenst kan dit met
gesloten beurzen tussen afdelingen als vooraf duidelijke tijdsafspraken worden
gemaakt. Voor zowel projectleden als beheerleden is dit een leuke afwisse-
ling. Voor elke ontwikkelaar is het een verrijking om enige tijd te werken als
beheerder. Daarmee ontstaat meer gevoel voor beheeraspecten en ook voor
de wenselijkheid om de impact van beheer op een ontwikkelproject tijdig te
onderkennen.
De beheerorganisatie wordt verantwoordelijk voor het instandhouden van de

dienstverlening die de applicatie biedt aan de eindgebruikers.
15 Beheer
Er is een aantal vanuit het perspectief van het beheer belangrijke onderwerpen.
Ten aanzien van de onderhoudbaarheid van het ontwerp zijn dat de volgende.
Flexibiliteit. Is de applicatie eenvoudig aan te passen? Zijn variabele gegevens

daadwerkelijk als parameter onderkend en te muteren? In het algemeen kun je
stellen dat 'data' eenvoudig te muteren zijn en 'programmatuur' het inschake-
len van programmeurs vereist.
aliteit. Een oordeel over de kwaliteit ontstaat door het bekijken van de
Risk List en van de testresultaten.
coaastraints. Voorbeelden daarvan:

eenduidige1duidelijke foutmeldingen;
gestandaardiseerde schermen;
s set van toegestane protocollen;
Sst van toegestane aanvullende software;
eisen van privacy en beveiliging.
van requirements naar design en code om vanuit beheer

eenvoudige de impact van een wijziging te kunnen vaststellen.
Een ander belangrijk onderwerp zijn de hardwarevereisten zoals de eisen aan

configuratie-items wat betreft beeldscherm, geheugencapaciteit en processor-
capaciteit.
Hierboven is aangegeven dat bij een softwareontwikkelingsproject de focus

erg gericht is op het realiseren van de gewenste software. Daardoor wordt
beheer regelmatig pas betrokken tegen de tijd dat de software gebouwd of uit-
gerold moet gaan worden. Kreten als: 'Goed is goed genoeg', 'Ons project gaat
alleen over ontwikkelen' geven aan dat men weinig oog heeft voor de lange
levensperiode van de software na de initiële ontwikkelinspanning.
De oorzaak daarvan is deels te wijten aan onvoldoende kennis over beheer en

gerichtheid op de korte termijn. Dat speelt des te meer als een project onder
(tijds)druk komt en er resultaten moeten komen. Aandacht voor onderhoudsas-
pecten levert geen direct zichtbaar resultaat, maar zal eerder een vertraging in
de resultaten meebrengen.
Daarnaast speelt de gedachte dat beheer niet zo belangrijk is, en eenvoudig.

Bovendien wordt het werk van een beheerder soms als saai, niet leuk en niet
creatief gekwalificeerd. Een goede beheerder is echter van groot belang, heeft
systeem ontwikkel in^ met RUP
wellicht minder creatief werk, maar moet in staat zijn niet alleen te denken
vanuit de techniek, maar ook vanuit de gebruikers en beheerders van de ap-
plicatie. Hij is dus veelzijdig en moet alle facetten van het engineering vak
begrijpen.
Een goede beheerder-designer moet namens de eindgebruiker 'eenvoudige'

Requirements en Changes kunnen inventariseren en beschrijven. Deze wij-
zigingen moet hij analyseren en daarvoor moet hij het Design doorgronden,
zodat hij kan schatten wat de impact is en hoeveel tijd hij nodig zal hebben om
een wijziging te realiseren (design, code ) en te testen. Hiervoor zijn nodig:
e kennis van de applicatie;

documentatie (structuur, compleetheid, toegankelijkheid);
broncode (structuur, commentaren);
niet-functionele vereisten;
kennis van de hardware en infrastructuur;
e kennis van testen en hergebruiken van testen na aanpassingen;
e kennis van ontwikkelomgeving, testomgeving en productieomgeving.
Nederlandstalig: R. van der Pols, ASL. Een framework voor applicatiebeheer.

Sdu, 2001. ISBN go4400266X.
Engelstalig: R. van der Pols, ASL, a framework for application management.
Van Haren publishing, 2005. ISBN 9077212051.
In dit hoofdstuk is beschreven hoe RUP gebruikt en uitgebreid kan worden om
beheeractiviteiten uit te voeren. Eerst wordt aangegeven in welke situaties RUP
gebruikt kan worden, zowel voor applicaties die met RUP, als voor applicaties
die volgens een ander procesmodel zijn ontwikkeld. Er wordt beschreven
in welke situaties het niet handig is om RUP te gebruiken. Vervolgens is in
kaart gebracht hoe de Development Case voor een beheerproject eruit ziet,
welke bestaande artefacts worden gebruikt en welke nieuwe artefacts worden
toegevoegd. Ook is aangegeven hoe wijzigingsverzoeken ontstaan en worden
afgehandeld en hoe belangrijk requirementmanagement is voor het afhandelen
van incidenten en wijzigingsverzoeken en voor het uitvoeren van changes.
RUP-fasen zijn gericht op het bereiken van een mijlpaal. Na het bereiken van
de mijlpaal krijgt een aantal activiteiten een ander accent. Zo zullen in de
Elaboration-fase eerst de risicovolle zaken opgepakt worden en vervolgens de
zaken die belangrijk zijn voor een stabiele architectuur. In de Construction-
fase ligt de nadruk op 'het maken van meters' en het completeren van alle
artefacts.
Deze mijlpalen kunnen we ook voor het applicatieonderhoudstraject hante-

ren:
Inception - is het haalbaar (technisch), business case, risico's en maatregelen.
Elaboration - risicovolle aanpassingen ontwerpen, bouwen en uitwerken.
Construction - completeren.
Transition - release uitrollen, transitie naar een nieuwe versie.
De omvang en aard van de wijziging bepaalt de te vervaardigen of te onder-

houden artefacts. Het aanpassen van een Business Case zal niet gauw van
toepassing zijn bij wijzigingen van correctieve aard. De Development Case
schrijft voor welke producten vervaardigd of onderhouden moeten worden.

Onderhoud wordt vaak releasematig aangepakt.
RUP is sterk gericht op het ontwikkelen van maatwerksoftware en daardoor is

beheer deels buiten beschouwing gelaten. Uitgangspunt is dat je na de applica-
tieontwikkeling hetzelfde frame gebruikt voor het beheren van de applicatie.
Je maakt een nieuwe release. Toch kent beheer ook diverse activiteiten die
niet direct in RUP zijn terug te vinden. Met name het alledaags beheer en het
operationeel houden van de applicatie valt hieronder.
NJP uitbreiden ten

In de praktijk is RUP voor Beheer uit te breiden, door disciplines enlof fa-
sen toe te voegen. Als discipline moet men denken aan Operation, dat het
alledaagse beheer en de operationele support van de gebruikers omvat. Deze
discipline zal maar weinig activiteiten kennen binnen de gewone ontwikkel-
fasen. Het voorbereiden van de Operations valt immers onder de Deployment-
discipline in de Construction- en Transition-fase. Het operationeel houden van
de ontwikkelomgeving valt onder de Environment-discipline. Een alternatief
is om de disciplines Deployment en Environment uit te breiden met specifieke
beheerartefacts.
Ook kan men twee nieuwe fasen onderkennen: Production (of Run) en Retire-
ment (of Run down). Production is gericht op het onderhouden en operationeel
houden van de applicatie, de laatste fase op het afbouwen van de applicatie.
In de praktijk komen we dergelijke uitbouw van het RUP-framework tegen

bij het Enterprise Unified Process (EUP) (zie http://www.enterpriseunified-
Figuur 16.1: RUP aangevuld met beheerdisciplines

16 RUP als proces in beheer
Binnen dit boek hebben we EUP niet gevolgd, omdat het nog geen breed geac-
cepteerde standaard is. Toch zijn de algemene aspecten bruikbaar bij applica-
tiebeheer. Zo is de discipline Operations & Support hier specifiek gericht op
activiteiten die in een beheerproject worden uitgevoerd. EUP haalt een aantal
activiteiten uit de overige disciplines naar Operations & Support. Hetzelfde
resultaat kan bereikt worden door het RUP proces aan te passen, zoals we
beschreven hebben in de paragraaf Beheer Development Case.
Welke overwegingen spelen een rol om voor RUP te kiezen tijdens de beheer-
fase? We sommen hieronder enkele aspecten op.
Er is in ieder geval een methodische aanpak nodig in beheer. RUP als in-
dustriestandaard komt hiervoor in aanmerking.
Eén aanpaktstandaardproces voor zowel de ontwikkel- als de beheerorga-
nisatie biedt verschillende voordelen. Je hanteert hetzelfde begrippenka-
der, spreekt dezelfde taal. Zeker als de organisatie grensoverschrijdend is,
is een internationale standaard als RUP een goede keuze.
Standaardisatie leidt tot kostenreductie. Opleidingen kunnen vervaardigd
worden voor zowel ontwikkelaars als beheerders. Tools worden gemeen-
schappelijk toegepast. Dat biedt schaalvoordelen bij aanschaf.
De organisatie kan flexibeler zijn, omdat ontwikkelaars en beheerders be-
ter uitwisselbaar worden.
Communicatie en derhalve overdracht wordt vereenvoudigd, als de opleve-
ring ook vanuit een RUP project komt.
Als een applicatie volgens RUP ontwikkeld is, ligt het voor de hand deze ook
op basis van RUP in onderhoud te nemen. Hier beschrijven we welke criteria
een rol spelen om, kijkend naar de aard van de werkzaamheden, daadwerkelijk
voor RUP te kiezen:
Als de ontwikkeling met RUP heeft plaatsgevonden zien we de volgende inde-

ling.
Herbouw of zeer grote wijzigingen (>50% bij herbouw) vallen buiten be-
heer en zullen opnieuw met RUP projectmatig worden uitgevoerd, als
voortzetting van de initiële aanpak.
Grote wijzigingen die wel door de beheergroep worden uitgevoerd, worden
aangepakt conform de RUP Development Case voor grote wijzigingen.
Bij kleine wijzigingen, als er maar één iteratie is, kan RUP ook worden
toegepast, maar dan volgens een uitgeklede Development Case, de Beheer
Development Case.
Indien in de beheeromgeving veel gebruik gemaakt wordt van ITIL voor de

inrichting van de processen, kan ook een combinatie van RUP en ITIL worden
toegepast. Incidenten worden dan volgens ITIL opgepakt (incident manage-
ment, problem management). Pas als deze leiden tot een wijziging kunnen ze
conform RUP worden aangepakt.
Indien de ontwikkeling van een applicatie niet met RUP heeft plaatsgevonden,
kan op basis van een aantal criteria de beslissing worden genomen om het
beheer met RUP uit te voeren.
De klantorganisatie is bereid volgens RUP te gaan werken. Dat betekent

onder andere dat de klant bereid is om iteratief te gaan werken.
De opgeleverde producten zijn geschikt om te transformeren naar een RUP-
artefact en zo'n transformatie vergt geen onacceptabele grote inspanning.
Bij de overgang naar RUP gelden de volgende aandachtspunten.
Indien de applicatie naar verwachting weinig meer zal veranderen, is in-

vesteren in de migratie van de deliverables van het project weinig zinvol.
Staat de organisatie aan de vooravond van veranderingen en verandert de
software mee, dan is RUP de beste keuze.
Als de applicatie volgens 00 is opgezet, is de transformatie eenvoudig uit
te voeren. Met name het design van een 00-applicatie blijft grotendeels
overeind. RUP zal hier veel voordelen bieden en bouwt voort op de tijdens
de ontwikkeling vervaardigde artefacts. Hier en daar zullen enkele aanpas-
singen noodzakelijk zijn, zoals beschreven wordt in de Beheer Develop-
ment Case.
Indien de applicatie niet-O0 is opgezet, zal een omzetting van ontwerp-
producten naar RUP Design artefacts meer voeten in de aarde hebben. Of
die transformatie zinvol is, hangt mede af van de opzet van de applicatie
en de gebruikte processen en standaarden binnen de beheerorganisatie.
Ook de verwachtingen ten aanzien van aanpassingen aan de applica-
tie in de toekomst spelen een rol. Het is niet nodig dat alle traditionele
ontwerpproducten, zoals Data Flow Diagrams (DFD's) en Entity Re-
lationship Diagrams (ERD's) naar UML-artefacts worden omgezet.
Als we ervoor kiezen om verder te gaan met de traditionele technie-
ken, biedt het werken met RUP als proces niet de optimale ondersteu-
ning. Maar principes als 'risicovolle zaken snel aanpakken, iteratief
werken en aandacht voor requirements' blijven natuurlijk overeind.
Als besloten wordt de deliverables te migreren, dan is daarvoor een aantal
standaardtransformatieregels bekend. Die tonen we in tabel 16.1. Entity
Relationship Diagrammen kunnen eenvoudig naar Class Diagrams worden
omgezet, maar in het algemeen blijft het een arbeidsintensieve aanpak. Be-
zint eer ge begint!
Traditioneel document RUP-Artifact

Functioneel Ontwerp Use Case Specification + Additional Re-
quirement Specification
Technisch Ontwerp Use Case Realization + UML Class dia-
grams, Sequence Diagrams, Activity Dia-
grams, State Transition Diagrams
Architectuur Ontwerp Software Architecture Document
Datamodel (op bedrijfsniveau, logisch en Business Analysis Model, Analysis Model,
fysiek niveau) Data Model
Testplan en overige documentatie Testplan, Test Ideas List, Test Results
Installatiehandleiding Deployment plan + Installation Artefact +
Release notes
- Configuration Management Plan (I) + CM
database(@
Tabel 16.1: Standaardtransformatieregels tijdens een migratie
Opmerkingen bij deze tabel:

(I): door de introductie van iteratief ontwikkelen wordt de scope van een pro-
ject steeds uitgebreider en zijn documenten als het CMP belangrijker aan het
worden.
(2): CM Database is een deliverable met alle software configuratie-items van
het project.
ens exploitatie?
Beheer kent ook een dagelijkse variant: het operationeel houden van de ap-
plicatie. Denk daarbij aan: backups, recovery, het regelen van autorisaties, het
monitoren van de performance en van servers, het netwerk en de computer-
ruimte, het voeren van een servicedesk, beantwoorden van gebruikersvragen
en bieden van eerstelijnsondersteuning aan de klantorganisatie. Hiervoor is
RUP niet geschikt. De verschillende ITIL-processen zijn hiervoor beter ge-
schikt.
Als besloten is om RUP ook voor het beheerproces te gebruiken, zal nog een
aanpassing moeten plaatsvinden gericht op de specifieke beheeromgeving.
Aanpassingen met betrekking tot het proces (bijvoorbeeld wijzigingen aan
fasen, disciplines, artefacts en activiteiten) zijn terug te vinden in de 'Beheer
Development Case'. Een Development Case is een specifieke invulling van het
RUP-proces (Zie het hoofdstuk Projectstructuur).
Meestal is de Beheer Development Case een subset van de initiële Develop-

ment Case. Om bepaalde redenen kan besloten worden om specifieke artefacts
niet meer te. onderhouden of het onderhoud van deze artefacts elders, buiten
beheer, onder te brengen. Zo kunnen de Glossary, het opleidingsmateriaal of
de werkinstructies bijvoorbeeld worden beheerd door de gebruikersorganisatie
zelf.
Het gebruik van een Development Case wordt weleens toegepast in een Ap-
plication Management Service Center (AMSC). Een AMSC is een gespeciali-
seerd centrum voor outsourcing en beheer. Het biedt standaard ingerichte pro-
cessen en een omgeving met infrastructuur voor applicatiemanagement. Door
deze gestandaardiseerde manier van werken is het mogelijk om sneller, beter
en effectiever het beheer uit te voeren. Veel artefacts uit de Beheer Develop-
ment Case, met name voor de ondersteunende disciplines, zijn standaard in het
AMSC aanwezig en worden over de verschillende projecten heen hergebruikt.
Door standaardisatie van proces en omgeving op deze manier wordt het dus
mogelijk om een standaard Development Case tigebruiken.
Figuur 16.2: AMSC

Een belangrijke input voor het opstellen van een Beheer Development Case is
de omvang en aard van de uit te voeren wijziging. Deze bepaalt of een artifact
wordt opgenomen in de Development Case. Als een kleine wijziging in Use
Cases geen effect heeft op het businessmodel, de architectuur of het design,
dan kunnen de artefacts uit de disciplines Business Modeling, Requirements
en Analysis & Design buiten de Beheer Development Case blijven. Ook zal bij
het opstellen van de Beheer Development Case voor een groot of klein project
voor iedere discipline gekozen moeten worden voor de beheer relevante acti-
viteiten en artefacts. De afspraken die met de klant in het SLA zijn vastgelegd
zullen hierbij een rol spelen. We zien dus dat een aantal Development Cases
ontwikkeld kunnen worden, samenhangend met de aard en omvang van een
wijziging en met de onderliggende SLA. Dat is geheel conform RUP, dat stelt
dat bij ieder project een eigen Development Case moet worden opgesteld. In
beheer zal een aantal typen Development Cases ontstaan, die vervolgens her-
gebruikt kunnen worden bij soortgelijke beheeractiviteiten.
Het aantal artefacts voor kleine beheerprojecten blijft veelal hetzelfde; ze wor-
den aangepast, uitgebreid of gewijzigd en bij nieuwe artefact verschilt de in-
vulling in detaillering van de softwareontwikkeling.In kleine beheerprojecten
is het ook vaak zo dat de Developer meerdere RUP-rollen vertegenwoordigt.
Bij grotere projecten zal vanwege de omvang en het risico het aantal artefacts
uitgebreider zijn en zullen meerdere personen gezamenlijk de verschillende
rollen invullen. De continuïteit van de dienstverlening mag nooit afhankelijk
zijn van één persoon.
eer en toegevoegde artefacts

Voor een Beheer Development Case kan een aantal nieuwe artefacts worden
gedefinieerd. Zo worden de werkafspraken met de opdrachtgever vastgelegd in
een SQP (Service Quality Plan) en zullen Problem Reports worden opgesteld
voor het vastleggen van incidenten en problemen.
Als we RUP voor de beheeromgeving oprekken, zodat ook 'Operations &

Support' als discipline worden onderkend, dan kunnen verschillende nieuwe
artefacts worden onderkend, zoals:
Run Down Plan;

SLA (Service Level Agreement);
backup;
autorisatieregister;
checklist dagelijkse activiteiten;
gebruiksstatistieken (aantallen incidenten, schijfgebruik, performancecij-
fers enzovoorts, zoals afgesproken met opdrachtgever in de SLA);
periodieke rapportages aan de eigenaar (om SLA afspraken te meten).
Door een project wordt vaak een groot aantal artefacts vervaardigd. Zoals al
vanouds bekend kunnen die worden verdeeld in projectdocumentatie en sy-
steemdocumentatie. De projectdocumentatie is primair bedoeld om het pro-
ject efficiënt te runnen en te beheersen. De systeemdocumentatie beschrijft
primair de opgeleverde applicatie en komt dus in aanmerking voor onderhoud.
Van belang voor beheer zijn:
SAD - zal wijzigen bij groot vernieuwend onderhoud, maar wijzigingen

die tot aanpassingen van het SAD leiden vallen gewoonlijk buiten de scope
van beheer.
Use Cases - te onderhouden.
Analysis Model - biedt inzicht in de applicatie. Eventueel onderhoud wordt
afgesproken en vastgelegd in de Development Case.
Design Model - te onderhouden.
Requirements Management plan - te onderhouden.
Testplan - te onderhouden.
Guidelines - desgewenst aan te scherpen op basis van SLA of eigen stan-
daards van de beheerorganisatie.
Andere artefacts die vervaardigd zijn tijdens de initiële ontwikkeling zullen

voor het beheer minder relevant zijn en niet verder worden onderhouden. Deze
documenten kunnen wel belangrijke informatie bevatten en een rol spelen bij
de onboarding van nieuwe projectmedewerkers. De volgende documenten
worden daarom in archief gehouden:
Business Architecture Document;

e Glossary;
Vision Document;
Prototypes;
Projectliteration plans.
Het Vision Document en de Glossary worden maar zelden aangepast omdat

deze niet aan de beheerorganisatie zijn opgeleverd, maar aan de eindgebrui-
kersorganisatie. Indien dusdanig substantiële aanpassingen op het systeem
worden uitgevoerd die dit toch noodzakelijk maken, dan zal dit worden door-
gegeven aan de gebruikersorganisatie.
In figuur 16.3 beschrijven we een Development Case voor een grote onder-
houdsslag in Beheer. We zien verplichte (v) en optionele (o) artefacts. In de
discipline Business Modeling hebben we geen artefacts onderkend. Sowieso
is Business Modeling een optionele discipline, maar daarnaast is de veronder-

stelling daarbij: als er bedrijfsprocessen wijzigen, hebben we te maken met een
wijziging van dusdanige omvang dat deze niet meer door een beheerorganisa-
tie afgehandeld wordt. De gebruikersorganisatie is betrokken en er wordt een
nieuw project voor opgezet.
RUP Engineering Deliverables (Beheer Development Case) >
( Inception Ctlaboration) C Construction ) c l ransition 3
Business
Modelling
Requirements
Analysis &
Design
- Implementation - Implementation
I I
- Implementation
Implementation
-
Model (v)
Build (v) - Modal (v)
Build (v)
MOdd(V)
- Build (v)
Test
Deployment
Change Mgt
Project Mgt
Environment
Figuur 16.3: RUP Engineering Delivirables (Beheer Development Case)

We gaan uit van een releasematige aanpak. Dat wil zeggen dat een bundel van
wijzigingen gezamenlijk wordt opgeleverd en uitgerold naar de gebruikersor-
ganisatie. Hiervoor wordt door het onderhoudsteam volgens de in het Service
Quality Plan beschreven werkwijze een iteratieplan opgesteld.
Afhankelijk van de grootte van de release en de aard en de impact van de

wijzigingen worden enkele iteraties doorlopen. Voor wijzigingen met weinig
impact zal veelal één iteratie in de fases Inception en Elaboration voldoende
zijn omdat deze beperkt zijn in doorlooptijd. Na de fase Construction zal in
- een keer de release aan de gebruikers ter beschikking worden gesteld. Dit
vindt plaats in de fase Transition. Ook al kan een fase zeer kort zijn, het blijft
wenselijk om alle fasen te doorlopen en de doelstelling van de verschillende
fasen te toetsen. Het kan bijvoorbeeld voorkomen dat er weinig of geen risico's
zijn voor een release. Toch zal, als dat in de Beheer Development Case is voor-
geschreven, de risicolijst wel moeten zijn ingevuld of afgevinkt.
Een beheerproject zal meestal aansluiten bij het iteratiepatroon 'Incremental

Lifecycle', zoals beschreven in RUP. Incremental Lifecycle heeft de navol-
gende karakteristieken.
Een korte Inception-fase om de scope te bepalen en een kleine business

case op te stellen. Ook de SLA kan hier aan de orde komen.
Een enkele Elaboration-iteratie waarin de requirements opgesteld worden,
de meest risicovolle worden uitgewerkt en aan de architectuur wordt ge-
toetst.
Een of meer Construction-iteraties waarin de wijzigingen verder worden
uitgewerkt en gerealiseerd.
Een of meerdere Transition-iteraties waarin de aangepaste en nieuwe func-
tionaliteit wordt uitgerold naar de gebruikersorganisatie.
Dit iteratiepatroon is geschikt als de wijziging bekende materie bevat en even-

tuele risico's goed ingeschat kunnen worden.
De term Wijziging is de directe vertaling van de Engelse term Change (Re-

quest). Wij kennen dit begrip ook als Wijzigingsverzoek of Wijzigingsvoorstel.
Het door elkaar gebruiken van de termen Wijziging en Wijzigingsvoorstel is
wat slordig, maar wel gebruikelijke praktijk. Zo gebruikt, kan een Wijziging
dus leiden tot verschillende gewijzigde artefacts.
Een beheerder vervult vaak meerdere rollen en heeft soms alle RUP-petten op.
Dit maakt een beheerrol uitdagend en veeleisend. Beheer heeft de verantwoor-
ding om de impact van wijzigingen te toetsen aan de visie en het overall design
van de applicatie. Daaruit vloeit voort dat men adviseert over toekomstige ont-
wikkelingen t.a.v. de applicatie. Beheer raakt ook alle disciplines.
Beheer houdt rekening met een applicatie in productie: wat zijn bijvoorbeeld
consequentie voor de productiedatabase, opleidingen voor gebruikers en hand-
leidingen. Als beheerder in de rol van Analyst of Designer dient je blik dus
erg ruim te zijn.
rong van wijzigingsverzoeken

Er zijn verschillende manieren waarop Wijzigingverzoeken tijdens de beheer-
fase worden aangemeld. Als gevolg van een Wijzigingverzoek'kunnen één of
meerdere artefacts worden gewijzigd. Welke artefact geraakt worden, is af-
hankelijk van het feit of de Change een functioneel dan wel een technisch ka-
rakter heeft. Het wijzigingsproces is in de ITIL-methodiek bekend als Change
Management. Zie de paragraaf ITIL en RUP in het hoofdstuk Beheer.
Als gevolg van een gemeld incident

Incidenten die vanuit de klant bij de beheerorganisatie worden gemeld kunnen
leiden tot een Change. Tijdens het analyseren van een incident is het van be-
lang dat alle artefacts (met name de Use Cases) goed zijn bijgehouden om vast
te stellen of sprake is van adaptief beheer of correctief beheer.
Bij correctief beheer verloopt het via het Problem- en Changeproces. Er wordt
vanuit Incident Management een analyse gemaakt, waaruit blijkt dat er sprake
van een 'problem', gedefinieerd als: significant groot incident, of clustering
van incidenten met één onderliggende oorzaak. De onderliggende oorzaak van
een probleem is te wijten aan een discrepantie tussen de requirements van het
systeem, zoals ze zijn vastgelegd in de Use Cases en de Supplementary Specs
en de gerealiseerde applicatie.
Indien wordt geconstateerd dat een gemeld incident leidt tot een aanpassing
van de functionele specificaties, betekent dit een functionele aanpassing die
doorgaans als een additionele wijziging (valt dus buiten het correctieve onder-
houd) wordt aangepakt.
In beide gevallen zal - zoals hieronder besproken - een wijzigingsvoorstel

(Request for Change) worden gemaakt en ter controle te worden overlegd aan
de klant.
Door een Request for C

Deze situatie doet zich voor zodra een klant een wijziging op de applicatie
vraagt (Request f o Change).
~ ITIL beschrijft in Change Management een stan-
daard voor dit proces.
vraag. Hoe deze vraag eruit ziet, is sterk afhankelijk van

zijn gemaakt in de SLA. Hierin wordt vastgelegd of er
sprake is van de aanlevering van een compleet gewijzigde Use Case. De
klant is in dat geval verantwoordelijk voor het functionele beheer. Het kan
echter ook zijn dat het functioneel beheer ook is belegd bij de beheergroep.
Dan dient er ook een stuk re
Analyse van de im
eebrengt. Hiervo
als vormgegeven tijdens de bouw, enorm belangrijk. Een goed gedocumen-
teerd en traceable systeem stelt de beheerders in staat om snel en nauwkeu-
rig te bepalen welke artefacts (waaronder: source code) door de wijziging
ke risico's dit met zich mee zal brengen.
ijzigingsvoorstel. Het voorstel wordt aangevuld met
de ana.yse van de vraag, de impact, de kosten en de planning. Daarnaast
wordt vermeld welke artefacts worden aangepast. Het geheel wordt opge-
leverd aan de klant.
eoordeling door et wijzigingsvoorstel. De klant toetst

het voorstel op functionaliteit en kosten en geeft akkoord op zowel de func-
tionaliteit als de geschatte kosten.
Er zijn nog meer triggers mogelijk, ook vanuit de beheerorganisatie zelf, die
op een vergelijkbare manier als boven tot een Wijzigingsvoorstel leiden. Denk
hierbij aan perfectief onderhoud of substantiële veranderingen in de omgeving,
zoals een Windows-upgrade.
Een belangrijke tip is om kleine wijzigingen te bundelen, waardoor een onder-

houdsproject van iets grotere omvang ontstaat en een nieuwe release in een keer
kan worden uitgerold. Dat levert op verschillende fronten efficiencyvoordelen
op. Gebruikers hoeven maar een keer gestoord te worden voor implementatie
van een release en handleidingen hoeven maar een keer verspreid te worden en
niet voor elke zelfstandige wijziging. Ze worden wel iteratief bijgewerkt.
Nadat door de klant akkoord is gegeven op het wijzigingsvoorstel, wordt de

wijziging ingepland voor een bepaalde release of direct in behandeling ge-
nomen. Dit is afhankelijk van de gewenste prioriteit en de afspraken die zijn
gemaakt in het SLA.
Zoals hierboven geschetst, kan de wijziging een functionele of een technische

insteek hebben. De op te leveren artefacts zijn per soort wijziging verschillend.
Vanuit de beheerorganisatie gezien is het ook van belang te weten waar de
verantwoordelijkheden belegd zijn. Steeds vaker wordt het functioneel beheer
door de klantorganisatie gedaan in plaats van door een externe beheerorgani-
satie. Vaak wordt het technische beheer toegewezen aan de beheerorganisatie.
Bij technisch beheer zal een andere instantie (veelal binnen de klantorganisa-
tie) verantwoordelijk zijn voor de aanpassing van de functionele artefacts. Dat
vereist bij functionele wijzigingen een samenwerking over afdelingsgrenzenof
zelfs over organisatiegrenzen heen.
RUP gaat er van uit dat disciplines samenwerken en dat de werkwijze iteratief a
is. Dat staat op gespannen voet met een werkwijze waarin de ene partij, als op-
drachtgever, eerst complete functionele specificaties oplevert en de andere par-
tij, als opdrachtnemer, daarvoor een offerte uitbrengt en vervolgens conform
specificatiesrealiseert en oplevert. Maar zo'n lineaire werkwijze is wel in RUP
in te passen en kan uitstekend geschikt zijn als de Requirements inderdaad in
één keer vast te stellen zijn en er geen architecturele risico's zijn. Kortom: bij
wijzigingen van bescheiden omvang.
In beheer stelt het beheerteam vast wat nodig is om de wijziging 'traceable' te

maken. Bijvoorbeeld:
het documenteren in de source welke aanpassing bij welke wijziging

hoort;
m hetin de CMDB (Configuration Management DataBase) vermelden van het
betreffende document om welke wijziging het gaat;
het in het wijzigingsvoorstel beschrijven welke requirements het betreft.
Eerder hebben we beschreven dat een van de redenen om ook in een beheer-
organisatie met RUP te werken, ligt in de standaardisatie en uitwisselbaarheid
van werkwijzen en tools. Daarbij hebben we natuurlijk het applicatieonder-
houd tijdens beheer voor ogen. Omdat beheer (inclusief exploitatie) breder is
dan applicatieonderhoud, is er vaak een toolset, die afgestemd is op de verza-
meling ITIL-processen die ondersteund moet worden.
Het is een uitdaging om die tools op een goede manier te laten samenwerken
en uitwisselen met ontwikkeltools. In deze paragraaf bespreken we een aantal
aspecten:
configuratiemanagement of versiebeheer;
management van incidenten en wijzigingsverzoeken;
onderhouden van requirements.
Tijdens de initiële softwareontwikkeling wordt meestal een versiebeheertool

gebruikt, bijvoorbeeld Rational ClearCase of MS Visual SourceSafe. Daarin
worden de artefacts van het project opgenomen. Dat zijn applicatiespecifieke
configuratie-items (documentatie, software). Er worden geen (versies van)
hardware-items beschreven. In Beheer wordt, conform ITIL Configurations
Management, een Configuratie Management Database (CMDB) onderhouden.
Die bevat alle configuratie-items in de productieomgeving die een relatie heb-
ben met de applicatie.
Typisch voor een ontwikkelproject is dat configuratie-items vaak verschillen-

de keren per dag een nieuwe versie krijgen. Het past in de ontwikkelwerkwijze
om diverse keren per dag te integreren en te 're-basen'. Of er zijn items die
door verschillende personen achtereenvolgens via check-out + update + check-
in worden aangepast.
In een CMDB die een productie-omgeving beschrijft, zal de mutatiefrequentie

per individueel item veel lager liggen. Dat mogen we in ieder geval hopen voor
een productieomgeving die 'onder controle' is.
Het is de uitdaging voor de beheerorganisatie om voor applicatieonderhoud,

het development tijdens beheer, tot een goede inrichting en samenwerking te
komen tussen versiebeheer voor de applicatie in de ontwikkelen testomge-
vingen en configuratiemanagement op een veel bredere verzameling aan con-
figuratie-items in productie.
De t001 die tijdens het RUP-project wordt gebruikt om defects en wijzigings-

verzoeken te managen, is Rational ClearQuest. In beheer wordt de t001 EARS
(Extended Action Request System) gebruikt voor Incident en Change Manage-
ment. In de Rational Suite is een koppeling mogelijk van defects en wijzigings-
verzoeken naar de Requirements indien deze worden vastgelegd met Rational
RequisitePro. Vanuit andere tools, zoals EARS, zijn dergelijke koppelingen
met Requirements niet mogelijk.
Traceability van Requirements begint bij het vastleggen van de gebruikers-

wens. In een beheerorganisatie wordt dat allereerst vastgelegd in een t001 als
EARS. Vervolgens wordt, tijdens het uitvoeren van de change, de gebruikers-
wens verwerkt in de Use Cases en Supplementary Specifications. Als deze ar-
tefacts uit de Requirements-disciplineniet louter als document aanwezig zijn,
maar als ook het gebruikte tooi uit het project is meegeleverd (bijvoorbeeld:
Rational RequisitePro), dan zal de beheerorganisatie ook met dat t001 willen
doorwerken. Daar liggen immers allerlei relaties tussen requirements vast en
vinden we het startpunt van de traceability.
Deze Use Cases worden gerealiseerd in de design en bouw van de applicatie,

waarbij modellen en code worden opgeleverd. Uiteindelijk moeten alle Re-
quirements worden getest. Traceability houdt in dat de relatie tussen Require-
ments en design- en implementationartefactsterug te vinden is.
De nadruk in beheer ligt op de traceability van designonderdelen om te bepalen

wat de impact is van een wijziging. Bij initiële ontwikkeling wordt traceability
vaak minder streng bewaakt: de kennis is in de hoofden van de medewerkers
aanwezig. Voor het beheer is traceability echter erg belangrijk: de kennis in de
hoofden van de projectmedewerkers is niet meer toegankelijk
Systeemontwikkelinci met RUP
Requirements Management is enorm belangrijk voor het afhandelen van in-

cidenten en van wijzigingsverzoeken. Een goed gedocumenteerd en traceable
systeem stelt de beheerders in staat om snel en nauwkeurig te bepalen of een
klantmelding daadwerkelijk een incident betreft of dat er sprake is van een
verkapte change. Er kan worden bepaald welke design-artefacts en broncode
door een aangevraagde wijziging geraakt worden en welke risico's dit met zich
mee zal brengen.
Daarnaast geeft het Requirement Management proces inzicht in kwaliteit van

de uitgevoerde changes: als er veel incidenten optreden na een change, dan is
er iets mis met de manier waarop de impact op de applicatie is geanalyseerd, is
er onzorgvuldig getest, of zijn er andere redenen die nader onderzocht dienen
te worden.
In dit hoofdstuk worden de communicatie en de relatie met de manager
besproken. Eerst wordt ingegaan op de tegengestelde belangen die ontstaan
tussen de projecten de lijnorganisatie en het individuele belang van de
medewerker hierin. Het spanningsveld tussen project en lijn wordt met een
aantal voorbeelden toegelicht. Aan de hand van een aantal activiteiten in d e p
rojectmanagementworkJlowwordt ingegaan op de rol van ontwikkelaar bij de
uitvoering van die activiteiten. In het bijzonder wordt die rol bij het schatten,
plannen en de voortgangsrapportages beschreven en mei enkele voorbeelden
toegelicht. Er wordt dieper ingegaan op een aantal aspecten die spelen in de
communicatie met de projectmanager en lijnmanager, zoals het maken van
afpraken, coaching en probleemsignalering.
Een ontwikkelaar is vaak tewerkgesteld in zowel projecten als in de lijnorga-

nisatie en heeft daardoor met meer dan één manager te maken. Aspecten als
afspraken, coaching en denkwerelden worden voor beide soorten managers
aan de orde gesteld. Een medewerker heeft een dienstverband met een bedrijf
en is gewoonlijk ingedeeld bij een afdeling in de lijnorganisatie. Dergelijke
afdelingen zijn meestal opgebouwd rond bepaalde expertise. Enkele voorbeel- .
den zijn:
databaseontwerp;
functioneel ontwerp materiegebied;
analyse en design;
e Lotus Notes en webapplicaties.
In de lijn werk je met gelijkgestemde collega's aan zaken die continuïteit be-
hoeven. IT-Beheerafdelingen vinden we ook in de lijn. Werk, zeker werk rond

Implementatie RUP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Implementatie RUP

Uploaded by

Copyright:

Available Formats

$edere ontwikkelaar komt in elk project in aanraking met al dan niet

samengesteld aan de hand van deze gegevens. Die SQL-code stuurt

Objecten hebben een levenscyclus; ze worden gecreëerd, gebruikt, gewijzigd

Figuur 9.2: Persistent object - Gelijktijdigheid en gemeenschappelijk

In beide gevallen worden geëncapsuleerde gegevens getransformeerd naar

de opslagvorm. Bij communicatie (ClientIServer) worden deze bits over het

In de volgende paragraaf gaan we eerst in op de taak van de Database Desig-

Database Desi at is zijn taak?

Figuur 9.3: De rol van de Database Designer

Een Database Designer is verantwoordelijk voor het opstellen en onderhouden

Figuur 9.4: Bestanddelen van het Data Model

In de volgende paragraaf wordt eerst ingegaan op een flexibele implementatie

Voor het ontwerpen van een flexibel persistentiemechanisme wordt er gedu-

Voor persistentie moeten onderwerpen geregeld worden als:

hoeveel objecten moeten bewaard worden;

7: Print item values

:Deposit Item : Alarm Device

Figuur 9.5: Voorbeeld van een Interaction Diagram

De Software Architect zal op basis van de karakteristieken de Analysis Me-

acses Analysis Wlecha

Figuur 9.6: Omzetten van Analysis Mechanisms naar Design Mechanisms

Voor mechanismen naar de database kan de architect daarbij zeker om advies

De Architect bepaalt daarna welk Implementation Mechanism voor een spe-

Classes Analysis M e c h a n i s m s Design Mechanisms Implernentation Mechanisms

Figuur 9.7: Omzetten van Design Mechanisms naar Implementation

Omdat we uitgaan van een persistentiemechanisme waarin serialisatie ge-

Diverse vormen van serialisatie zijn nu te verkrijgen door subclasses van

Zoals al eerder aangeven, lijkt het communicatieproces dat optreedt tussen

Voor Java zijn diverse standaardframeworks beschikbaar. Zo worden in het

Daarnaast zijn er nog het open source framework Casfor (http://castor.exolab.

Het .NET-framework kent ook eigen mechanismen voor persistentie.

Ook een standaardframeworkmechanisme zal altijd concepten als Buffer en

In bestaande frameworks en pakketten is reeds een hoop tijd en geld geïnves-

Het gevaar hierbij is dat Implementers, Database Designers en eigenlijk alle

Logischerwijs hebben de Database Designer en Implementer meer controle

Voor kleinschalige projecten zal een standaardframework vaak de beste keuze

Verschillende alternatieven voor opslagvormen kunnen worden overwogen:

In deze paragraaf gaan we wat uitgebreider in op deze mogelijkheden. De

Opslag in losse bestanden @Ze based) is goedkoop en voor iedereen mogelijk

Bij opslag in bestanden kunnen slechts de gegevens van de objecten in de

ory Data Structures

In objectgeoriënteerdedatabases, kortweg object bases, worden objecten inte-

Op deze manier zijn in een objectgeoriënteerd systeem bij voorkeur de persi-

Daarnaast is het zo, dat de producenten van de meestgangbare RDBMS-sys-

Ook nu worden alleen de gegevens van de objecten in de kolommen van de da-

Business Object Model

Relationeel Database Model

Figuur 9.8: Transformatie van objecten naar Relationeel Model

Hiërarchische en Netwerk databases

ecten in een Watioiaele Database

Figuur 9.9: Voorbeeld van schematechniek voor een database

Voor de werking van relationele databases is kennis van de achtergrond en het

De attributen worden kolommen in de tabel, met uitzondering van de verwij-

voudiger is om de sleutel van de tabel ArronNotaris te beperken tot notaris.

Overerving kan in een relationele database op drie manieren worden opge-

Alle attributen van de superclasses en de verschillende subclasses komen

Volgt de Database Designer de bovenstaande regels dan zal de I:I-relatie tus-

In het bovenstaande is steeds uitgegaan van een nieuw te creëren database.

Hierbij kunnen de volgende wijzigingen voorkomen:

tie om daarmee snelheid bij het zoeken in de database te bevorderen; extra

Het ontwerpen van een database en de mechanismen om in deze databases

Er is nog een andere reden om reeds tijdens de Inception rekening te houden

Distributiebeslissingen: gegevens worden mogelijk op meerdere plaatsen