Hergebruik van software artefacten bij de kennisorganisatie TNO

Hergebruik van software artefacten bij de
kennisorganisatie TNO Defensie en Veiligheid
Tim Hartog
In opdracht van TNO Defensie en Veiligheid,
Afdeling Modelling & Simulation
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
2
Hergebruik van software artefacten bij de
kennisorganisatie TNO Defensie en Veiligheid
Tim Hartog
Afstudeercommissie:
dr. mr. ir. Th.J.G. Thiadens
dr. ir. K.G. van den Berg
ir. D. Keus
ir. H.J. Borgers
Den Haag, juni 2005
Technische Universiteit Twente
Faculteit Informatica,
BedrijfsInformatieTechnologie
Bedrijf Bestuur en Technologie
Elektrotechniek Wiskunde & Informatica
TNO Defensie en veiligheid
TNO Defensie en veiligheid
De inhoud van dit rapport kwam tot stand in het kader
van een stage. TNO Defensie en veiligheid stelt zich niet
verantwoordelijk voor de inhoud, eventuele conclusies en
aanbevelingen van deze rapportage.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
4
Management samenvatting
Aanleiding
Deze scriptie bespreekt de toepassing van hergebruik van software binnen TNOD&V, afdeling Modelling & Simulation. Bij een deel van de software engineers
staat hergebruik van software hoog in het vaandel. Zij veronderstellen dat
hergebruik van software een aanzienlijke kostenbesparing en verlaging van de
doorlooptijd kan veroorzaken. De angst bestaat namelijk dat, indien er niets
verandert, de softwareontwikkeling binnen TNO-D&V, en daarmee belangrijke
kennisaspecten voor TNO-D&V, op den duur zal verdwijnen. Er bestaan echter
enkele knelpunten waardoor de toepassing van hergebruik van software wordt
belemmerd.
Het doel van deze scriptie is om advies te geven ten einde de toepassing van
hergebruik van software te bevorderen. Dit wordt gerealiseerd door de knelpunten
die bestaan bij de toepassing van hergebruik van software te identificeren. Voor
deze knelpunten worden oplossingen geformuleerd en aanbevelingen gedaan op het
gebied van de herbruikbare software artefacten, het softwareontwikkelproces en de
organisatie daar omheen. Deze zijn nodig om een systematische toepassing van
hergebruik van software te ondersteunen en te bevorderen.
Aanbevelingen
- Richt een groep op waar de kennis van de herbruikbare artefacten wordt
geconcentreerd. Deze groep dient verantwoordelijk te zijn voor de
projectoverschrijdende hergebruikprocessen zoals sturing, certificatie,
ondersteuning en onderhoud en beheer.
- De groep moet de bevoegdheid hebben om tijdens offertetrajecten te
beoordelen welke software artefacten er hergebruikt kunnen worden.
Tevens moet de groep projecten de opdracht kunnen geven bepaalde delen
van de software zo te ontwikkelen dat deze hergebruikt kan worden.
- Inventariseer de huidige verzameling herbruikbare software artefacten en
houd de verzameling beperkt tot hoogwaardige herbruikbare artefacten,
zoals componenten en frameworks.
- Geef de groep de bevoegdheid om software engineers verantwoordelijk te
maken voor het onderhoud, beheer en verdere ontwikkeling van de
herbruikbare artefacten.
- Om de kosten voor hergebruik te financieren moet elk project een bepaald
percentage van zijn budget afstaan.
Conclusie en motivatie
De aanbevelingen zijn tot stand gekomen op basis van een literatuurstudie en een
analyse van de huidige situatie met betrekking tot hergebruik van software. Voor
de analyse van de huidige situatie zijn diverse interviews en gesprekken gehouden
binnen de afdeling Modelling & Simulation. Tevens zijn er drie concrete case
studies onderzocht.
De conclusie van deze scriptie is dat hergebruik al zeker plaatsvindt, al is dit wel
op een adhoc niveau. Als gevolg hiervan bestaan er diverse knelpunten die de
toepassing van hergebruik door software engineers en projectleiders belemmeren.
Deze knelpunten zorgen ervoor dat kansen voor hergebruik worden gemist.
De knelpunten voor hergebruik ontstaan doordat er geen opvang van de
herbruikbare artefacten buiten de projecten is. Hierdoor is er vaak geen beheer,
onderhoud en ondersteuning aanwezig. Tevens is er geen sturing op de
ontwikkeling van herbruikbare artefacten waardoor het proces sterk van toeval
afhankelijk is en voortkomt uit de toewijding van software engineers. Onder
projectleiders bestaat er weerstand omdat het ontwikkelen van herbruikbare
software extra moeite kost. Tevens is er geen sturing op de ontwikkeling van
software met de herbruikbare artefacten. Hierdoor wordt er om diverse redenen,
van gebrek aan vertrouwen, geen kennis van het bestaan tot de onwil om te
hergebruiken aan toe, niet hergebruikt.
Indien deze knelpunten worden opgelost zal hergebruik toenemen en het resultaat
door hergebruik verbeteren. De opbrengsten door hergebruik worden gevormd door
besparingen op ontwikkel- en onderhoudsuren. De kosten worden gevormd door de
sturing van de projecten, het onderhoud & beheer, certificatie en de ondersteuning
aan de projecten. Schattingen van de resultaten door hergebruik, bestaande uit
productiviteitsverbeteringen en kostenbesparingen, liggen in de orde van grote van
enkele mensjaren.
Consequenties
TNO-D&V zal een keuze moeten maken over het systematisch toepassen van
hergebruik van software. Het systematisch hergebruiken van software gebeurt niet
vanzelf en er zijn diverse aanpassingen en investeringen nodig. TNO-D&V heeft
een vliegende start doordat er al een aanzienlijke hoeveelheid herbruikbare
artefacten beschikbaar is. Er zal echter wel een aantal uren geïnvesteerd moeten
worden om deze software artefacten te testen en te voorzien van documentatie.
Verder vormt hergebruik een beperking op de vrijheid van de projectteams doordat
de nieuwe groep inspraak krijgt met betrekking tot de ontwikkeling van software
binnen een project. De groep kan immers opdracht geven bepaalde delen van de
software zo te ontwikkelen dat deze hergebruikt kan worden en de groep heeft
inspraak op het gebruik van herbruikbare software artefacten binnen dat project.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
6
Voorwoord
Deze scriptie is het resultaat van een zeven maanden durende opdracht bij het
kennisinstituut TNO Defensie en Veiligheid. De scriptie die voor u ligt vormt de
laatste opdracht binnen mijn doctoraal voor de studie BedrijfsInformatieTechnologie aan de Universiteit Twente, te Enschede. Het onderwerp van deze
scriptie is de toepassing van hergebruik van software bij de softwareontwikkeling
van een kennisinstituut. Ik wil hierbij iedereen bedanken die mij op enige manier
heeft geholpen gedurende deze periode. Speciale aandacht gaat hierbij uit naar,
Theo Thiadens
Klaas van den Berg
Daniëlle Keus
Erik Borgers
Medewerkers van Modelling & Simulation
Susanne Buijtenhek
Den Haag,
16 juni 2005
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
7
Versiebeheer
De tabel hieronder geeft aan welke wijzigingen zijn gemaakt in dit document.
Versie
Datum
Auteur
Wijziging
0.0.0.0
0.0.1.0
0.0.2.1
0.0.2.2
0.0.3.1
0.0.3.2
0.0.3.3
01-12-2004
14-12-2004
16-12-2004
24-12-2004
21-01-2005
25-01-2005
02-02-2005
Tim Hartog
Tim Hartog
Tim Hartog
Tim Hartog
Tim Hartog
Tim Hartog
Tim Hartog
0.0.3.4
0.1.0.0
0.1.1.0
0.1.2.0
0.2.0.0
0.2.5.0
0.3.0.0
1.0.0.0
2.0.0.0
24-02-2005
27-02-2005
28-03-2005
04-04-2005
28-04-2005
08-05-2005
24-05-2005
25-05-2005
16-06-2005
Tim Hartog
Tim Hartog
Tim Hartog
Tim Hartog
Tim Hartog
Tim Hartog
Tim Hartog
Tim Hartog
Tim Hartog
Eerste versie document.
Verwerking PVA versie 1.1
Invoeging theorie § 3.1 + 3.2 + 3.3
Feedback bespreking UT verwerkt
Invoeging theorie § 3.4 + 3.5
§ 3.6 Best Practice Sodalia toegevoegd.
Verwerking feedback dhr. Van den Berg –
Interviewopzet + toevoeging § 3.6 Eliop
Feedback n.a.v. bijeenkomst 27-01-2005 verwerkt
§ 3.7 toegevoegd, 1ste Concept Versie Theorie
§ 3.8 Theoretisch raamwerk toegevoegd
Eerste opzet Huidige Situatie
Feedback n.a.v. bijeenkomst 12-04-2005 verwerkt
Algemene verbeteringen & correcties
Gewenste Situatie toegevoegd
1ste Concept versie verslag
Scriptie Hergebruik van Software Artefacten
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
8
Inhoud
1.
Inleiding ...................................................................................................14
1.1
TNO Defensie en Veiligheid ....................................................14
1.2
Hergebruik van software...........................................................15
2.
Onderzoeksontwerp .................................................................................17
2.1
Doelstelling...............................................................................17
2.2
Onderzoeksvragen ....................................................................17
2.3
Onderzoeksmodel .....................................................................18
2.4
Aanpak......................................................................................18
2.5
Afbakening ...............................................................................20
3.
Theoretische Analyse...............................................................................21
3.1
Hergebruik ................................................................................21
3.2
Kritieke succes- en faalfactoren................................................25
3.3
Herbruikbare artefacten ............................................................28
3.4
Hergebruik processen ...............................................................39
3.5
Hergebruik organisatie..............................................................48
3.6
Kwantificeren van hergebruik ..................................................60
3.7
Theoretisch raamwerk ..............................................................70
3.8
Best practices ............................................................................74
3.9
Conclusie ..................................................................................78
4.
Huidige Situatie bij TNO .........................................................................79
4.1
Aanpak......................................................................................79
4.2
Algemene analyse.....................................................................80
4.3
Case studies ..............................................................................93
4.4
Conclusie ................................................................................109
5.
Gewenste Situatie voor TNO .................................................................111
5.1
Keuze voor hergebruik ...........................................................111
5.2
Herbruikbare software artefacten ...........................................113
5.3
Gewenste hergebruikorganisatie en processen .......................117
5.4
Financiering van hergebruik ...................................................133
5.5
Stappenplan voor hergebruik..................................................138
5.6
Hergebruik als business case ..................................................140
6.
Advies aan TNO-D&V ..........................................................................145
6.1
Conclusie ................................................................................145
6.2
Aanbevelingen ........................................................................147
7.
Reflectie .................................................................................................149
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
9
8.
Referenties .............................................................................................151
Bijlage A Kosten en opbrengsten van hergebruik .....................................................1
Bijlage B Reuse Maturity Framework ......................................................................1
Bijlage C Toelichting op de AMI methode...............................................................1
Bijlage D Best practices Sodalia and Eliop...............................................................1
Bijlage E Interviewopzet...........................................................................................1
Bijlage F Codes of Practice binnen TNO-D&V .......................................................1
Bijlage G Componenten uit het Kibowi MP Framework ..........................................1
Bijlage H Stroomschema voor gebruik Electronic Battlespace Facility ...................1
Bijlage I Uitkomsten Group Facility Room Sessie..................................................1
Bijlage J Financiële scenario’s hergebruik voor M&S ...........................................1
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
10
Lijst van gebruikte afkortingen
ALSP
AMI
ASF
BOAI
BU
CBD
CCS
CDE
CMM
CORBA
COP
COTS
DIS
D&V
EBF
ELSTAR
GQM
HLA
IT/QA
ITEMS
J-Roads
KL
KLU
KM
LOC
M&S
MDA
MOSES
MP
NIH
ORB
PLF
RCM
RSO
RTG
RTI
RCI
SALMS
SDD
SE
SEI
SF
SPC
SRS
Aggregate Level Simulation Protocol
Application of Metrics in Industry
Advanced Simulation Framework
Beleidstudies, Operationele Analyse en Informatievoorziening
Business Unit
Component-Based Software Development
Command Control & Simulatie
Collaborative Development Environment
Capability Maturity Model
Common Object Request Broker Archicture
Code of Practice
Commercial-Off-the-Shelf
Distributed Interactive Simulation
Defensie en Veiligheid
Electronic Battlespace Facility
European Low-cost Simulators for Training of Armed Forces
Goal-Question-Metric
High Level Architecture
IT Quality Assurance
Interactive Tactical Environment Management System
Joint Research on Air Defence Simulation
Koninklijke Landmacht
Koninklijke Luchtmacht
Koninklijke Marine
Lines of Code
Modelling & Simulation
Model Driven Architectures
Maritime Operations Simulation and Evaluation System
Multi Platform
Not Invented Here
Operationele Research en Bedrijfsvoering
Platform Framework
Reuse Capability Model
Reuse Support Organization
Reuse Task Group
Runtime Infrastructure
Runtime Communication Infrastructure
Sodalia’s Asset Library Management System
Software Design Description
Software Engineering
Software Engineering Institute
SourceForge
Software Productivity Consortium
Software Requirements Specification
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
11
SSDD
SSS
TBM
TNO
TNO-D&V
TNO-FEL
TSA
TOPICS
UML
VVA
System Subsystem Design Description
System Subsystem Specification
Terrein Bewerking Module
Nederlandse Organisatie voor toegepast-natuurwetenschappelijk
onderzoek
TNO Defensie en Veiligheid
TNO Fysisch en Elektronisch Laboratorium
TNO Simulation Architecture
Tactical Operations in Confined and Shallow waters
Unified Modeling Language
Verificatie Validatie en Accreditatie
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
12
Lijst van figuren en tabellen
Figuren
Figuur 1 - Organisatiestructuur TNO. .................................................................... 14
Figuur 2 - Onderzoeksmodel hergebruik van software artefacten bij TNO-D&V. 18
Figuur 3 - Compositie van een herbruikbaar asset [EZR02]. ................................ 30
Figuur 4 - Mogelijke wildgroei aan versies van één herbruikbaar artefact. ........... 35
Figuur 5 - Compositiescenario's tussen herbruikbare artefacten [MIL02]. ............ 36
Figuur 6 - Het Model - View - Controller (MVC) Framework [MIL02]. .............. 38
Figuur 7 - Processen voor systematisch hergebruik [JAC97]. ............................... 39
Figuur 8 - Gewenste levenscyclus van een herbruikbaar artefact .......................... 43
Figuur 9 - Relatie tussen CMM-niveau en Reuse Management niveau [VAD98] . 47
Figuur 10 - Onderdelen binnen een organisatiestructuur voor hergebruik............. 52
Figuur 11 - Lone Producer structuur [FAF94][MIL02]. ........................................ 53
Figuur 12 - Nested Producer structuur [FAF94][MIL02]....................................... 54
Figuur 13 - Pool Producer structuur [FAF94][MIL02]. ......................................... 55
Figuur 14 - Team Producer structuur [FAF94][MIL02]......................................... 57
Figuur 15 - Verschillende fasen volgens de AMI methode [PUL96]..................... 61
Figuur 16 - Goaltree voor de intensiteit van hergebruik......................................... 63
Figuur 17 - Goaltree voor de netto kosten van hergebruik binnen een project ...... 64
Figuur 18 - Stakeholders bij hergebruik van software artefacten........................... 79
Figuur 19 - Algemene Projectstructuur binnen BU2.............................................. 81
Figuur 20 - Overzicht hergebruik-activiteiten binnen voormalig divisie ORB. ..... 83
Figuur 21 - Productie van herbruikbare artefacten binnen BU2 van TNO-D&V. . 87
Figuur 22 - Typische architectuur van een simulatie-model [WIT02]. .................. 93
Figuur 23 - Hergebruikte componenten uit KIBOWI MP...................................... 96
Figuur 24 - Generieke EBF simulator architectuur [HUI98][JEN97]. ................... 99
Figuur 25 - Structuur van het Advanced Simulation Framework [JEN97]. ......... 100
Figuur 26 - Platform Architectuur [JEN97]. ........................................................ 100
Figuur 27 - Organisatiestructuur EBF .................................................................. 103
Figuur 28 - Indicatie van de resultaten per case studie......................................... 107
Figuur 29 - Organisatiestructuur voor hergebruik binnen M&S. ......................... 118
Figuur 30 - Productieproces voor een herbruikbaar artefact. ............................... 120
Figuur 31 - Fasen in het softwareontwikkelproces en keuzes voor hergebruik... 122
Figuur 32 - Hergebruikdilemma: mogelijke voordelen vs. inzicht....................... 122
Figuur 33 - Betekenis van hergebruik binnen M&S............................................. 123
Figuur 34 - Proces voor Change Requests bij een herbruikbaar artefact.............. 129
Figuur 35 - Kosten en Opbrengsten van hergebruik [FIC01]................................... 1
Figuur 36 - Globaal overzicht hergebruikorganisatie Sodalia .................................. 4
Figuur 37 - Globaal overzicht hergebruikorganisatie Eliop. .................................... 9
Figuur 38 - COP’s t.o.v. de fasen waarin een softwareproject kan verkeren. .......... 1
Figuur 39 - Stroomschema voor het gebruik van het EBF. ...................................... 1
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
13
Tabellen
Tabel 1 - Definities uit de literatuur van ‘Software Reuse' .....................................21
Tabel 2 - Te hanteren definitie m.b.t. hergebruik van software artefacten..............22
Tabel 3 - Documentatie Template herbruikbare artefacten [KAL01][MIL02]. ......31
Tabel 4 - Keuzes bij productie van herbruikbare artefacten [FIC01]......................40
Tabel 5 - Dimensies van volwassenheid van het Reuse Maturity Framework........47
Tabel 6 - Verschillende manieren van sturing [THI02]. .........................................50
Tabel 7 - Niveaus van sturing [NOL00]..................................................................51
Tabel 8 - Afwegingen bij de Lone Producer structuur. ...........................................54
Tabel 9 - Afwegingen bij de Nested Producer structuur. ........................................55
Tabel 10 - Afwegingen bij de Pool Producer structuur. ..........................................56
Tabel 11 - Afwegingen bij de Team Producer structuur. ........................................57
Tabel 12 - Template voor de definitie van doelen [FEN97][EZR02]. ....................63
Tabel 13 - Metric template voor ´Development Cost Avoidance´ [POU97]...........66
Tabel 14 - Interpretatie van de metingen bij doel 1.................................................67
Tabel 15 - Dataset van metingen van metriek B2. ..................................................68
Tabel 16 - Theoretisch raamwerk voor het analyseren van hergebruik...................73
Tabel 17 - Hergebruik bij Sodalia en Eliop [EZR02][DOU97][MOR00][VIL95]. 75
Tabel 18 - Overzicht type systemen, klanten en benodigde kwaliteit [TNO03]. ....80
Tabel 19 - Voorbeelden van ontwikkelde software producten van TNO-D&V......81
Tabel 20 - Beschikbare (grotere) herbruikbare artefacten binnen BU2. .................85
Tabel 21 - Hergebruik binnen BU2 volgens het Reuse Maturity Framework.........92
Tabel 22 - Analyse van de Case Studies Cases a.d.h.v. het theoretische model. ..105
Tabel 23 - Onderverdeling naar type simulators [SLU04]. ...................................112
Tabel 24 - Benodigde documentatie en informatie bij een herbruikbaar artefact. 115
Tabel 25 - Kostenposten door hergebruik voor M&S. ..........................................134
Tabel 26 - Overzicht van de kostenposten en de financiering hiervan..................135
Tabel 27 - DCA en SCA bij stijging hergebruikpercentage. .................................141
Tabel 28 - DCA en SCA bij variatie ratios blackbox & whitebox hergebruik......141
Tabel 29 - RCA bij verschillende hergebruikpercentages.....................................142
Tabel 30 - Totale kosten hergebruik bij variërende investeringen. .......................143
Tabel 31 - Nettoresultaat van hergebruik. .............................................................143
Tabel 32 - Reuse Maturity Framework [KOL91]......................................................1
Tabel 33 - De 12 stappen van de AMI methode [PUL96][DOB96]. ........................1
Tabel 34 - Metric template [PUL96]. ........................................................................3
Tabel 35 - Eigenschappen en hergebruikfactoren bij Sodalia. ..................................3
Tabel 36 - Eigenschappen en hergebruikfactoren bij Eliop. .....................................8
Tabel 37 - Overzicht van het aantal interviews per stakeholdergroep.......................2
Tabel 38 - Relatie interviewvragen ontwikkelaars en theorie. ..................................2
Tabel 39 - Relatie interviewvragen Projectleiders en theorie....................................5
Tabel 40 - Overzicht van Code of Practices (COPS) binnen TNO-D&V. ................2
Tabel 41 - Toelichting bij de componenten uit het Kibowi MP Framework.............2
Tabel 42 - Gehanteerde (harde) kengetallen in de 'hergebruik business case'..........1
Tabel 43 - Gehanteerde schattingen in de 'hergebruik business case'. ......................1
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
14
1.
Inleiding
1.1
TNO Defensie en Veiligheid
TNO Defensie en Veiligheid, een mix van voormalig TNO Fysisch en Elektronisch
Laboratorium (Den Haag) en TNO Human Factors (Soesterberg), is onderdeel van
de Nederlandse Organisatie voor toegepast-natuurwetenschappelijk onderzoek.
TNO is een onafhankelijke kennisorganisatie die een brug slaat tussen
fundamentele kennis en de praktijk van overheden en bedrijfsleven.
TNO Defensie en Veiligheid is één van de vijf kerngebieden van TNO, zoals Figuur 1
weergeeft, en heeft circa 1000 werknemers. Het kerngebied Defensie en Veiligheid
bestaat op haar beurt uit vijf Business Units. De Business Unit Beleidsstudies,
Operationele Analyse en Informatievoorziening (BOAI) bestaat op haar beurt uit vier
afdelingen. Eén van deze afdelingen vormt het kader waarin deze afstudeerscriptie
plaatsvindt, namelijk de afdeling Modelling en Simulation (M&S).
TNO
Kwaliteit van het
leven
Waarnemingssystemen
Operationele
Analyse
Defensie en
Veiligheid
Beleidsstudies
Operationele
Analyse en
Informatievoorziening
Command Control en
Informatievoorziening
Bescherming,
Munitie en
Wapens
Industrie en
Techniek
Biologische en
Chemische
Bescherming
Modelling &
Simulation
Bouw en
Ondergrond
Informatie- en
communicatietechnologie
Gedrag,
Training en
Prestatie
Beleid en
Strategie
Figuur 1 - Organisatiestructuur TNO.
De afdeling Modelling & Simulation van TNO-D&V, onderdeel van Business Unit
BOAI, voert opdrachten uit voor de militaire en civiele wereld. De ondersteuning van
de Krijgsmacht en het Ministerie van Defensie vindt plaats op de volgende gebieden:
-
-
-
ondersteuning van besluitvormingsprocessen gericht op operationele
behoeftestelling, materieelverwerving en tactische inzet van middelen van de
Krijgsmachtdelen en het Ministerie van Defensie,
operationele effectiviteit van (wapen- en sensor)systemen,
algemene ondersteuning van bedrijfsvoering op de gebieden logistiek, onderhoud,
resultaatverantwoordelijkheid en planning, onder andere met behulp van decision
support-systemen,
tactische training en opleiding.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
15
De taak van M&S is hoofdzakelijk het ontwikkelen van tools en simulators om
deze opdrachten te vervullen. Deze softwareontwikkeling vindt zowel plaats naar
aanleiding van opdrachten van klanten als vanuit interne kennisbehoeftes van
TNO-D&V zelf.
1.2
Hergebruik van software
Hergebruik is geen nieuw fenomeen, ook niet binnen software engineering. Maar
waar het in andere disciplines al veelvuldig met succes wordt toegepast lijkt het
binnen de software engineering discipline maar moeilijk door te breken.
Hergebruik van software bestaat al tientallen jaren, bijna sinds het ontwikkelen van
software zelf. In de loop der jaren heeft het zich ontwikkeld van hergebruik van
subroutines en stukken code naar het hergebruiken van complete frameworks,
componenten en architecturen. De voordelen van hergebruik kunnen zeer
overtuigend zijn: flinke kostenbesparingen, productiviteitsverbeteringen en
verbeterde kwaliteit. Maar toch is hergebruik nog geen gemeengoed in de software
industrie.
Een veelgemaakte fout is om hergebruik alleen als een technische uitdaging te
beschouwen. Hergebruik heeft immers ook een flinke impact op niet-technische
aspecten zoals organisatorische, economische, administratieve en psychologische
factoren. Het behalen van goede resultaten met hergebruik is onder andere
afhankelijk van de manier waarop een organisatie invulling weet te geven aan deze
factoren.
Op individueel niveau kan een software engineer redelijke resultaten behalen met
het adhoc hergebruiken van bestaande stukken code. Deze resultaten vallen echter
in het niet bij de mogelijke resultaten van een systematische toepassing van
hergebruik. De impact van een dergelijke toepassing op het softwareontwikkelproces, de taken en verantwoordelijkheden en de organisatie is echter ook groter.
Binnen M&S staat bij een deel van de software engineers hergebruik van software
hoog in het vaandel. Er bestaat een sterke behoefte om hergebruik te definiëren en
verder te stimuleren. Anno 2003 is hiervoor een zogenaamde hergebruikgroep
opgericht, die aan de hand van een aantal workshops het onderwerp op de kaart
heeft gezet. Een van de resultaten is de aanschaf van de tool SourceForge.
SourceForge wordt gebruikt als projectmanagementtool en kan ook gebruikt
worden als repository voor de herbruikbare artefacten.
Binnen de afdeling M&S bestaan er weerstanden en knelpunten die een brede
toepassing van hergebruik belemmeren. Tevens is bestaat er onduidelijkheid of
hergebruik van software wel geschikt is voor een organisatie als TNO waar elk
softwareproduct uniek is.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
16
Deze scriptie sluit zich aan bij het initiatief van de hergebruikgroep en definieert
hergebruik doormiddel van een literatuuronderzoek. Hierbij ligt de nadruk op de
herbruikbare software artefacten, de processen en de organisatie die nodig zijn
voor de toepassing van hergebruik van software. Tevens worden enkele best
practices geanalyseerd om een beeld te krijgen van de succesfactoren binnen die
organisaties.
Binnen TNO-D&V wordt op basis van interviews de huidige situatie onderzocht en
getoetst aan de theorie. Hierbij worden voor de afdeling M&S knelpunten en
verbeterpunten geïdentificeerd. Op basis van deze analyse wordt in de gewenste
situatie beschreven hoe hier voor M&S het beste invulling aan gegeven kan
worden. Het geheel resulteert in een serie aanbevelingen en een conclusie met
betrekking tot de systematische toepassing van hergebruik van software binnen de
afdeling Modelling & Simulation.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
17
2.
Onderzoeksontwerp
Dit hoofdstuk definieert de doelstelling en onderzoeksvragen van dit project.
Tevens worden de aanpak en afbakening van dit onderzoek besproken.
2.1
Doelstelling
De doelstelling voor dit onderzoek is als volgt gedefinieerd:
“Het doen van aanbevelingen op het gebied van het softwareontwikkelproces
en de inrichting van de organisatie daar omheen, met betrekking tot de invoering
en bevordering van hergebruik van software artefacten binnen de afdeling
Modelling & Simulation.”
2.2
Onderzoeksvragen
De onderzoeksvragen zijn opgedeeld naar de theorie, de huidige situatie en de
gewenste situatie binnen de afdeling M&S.
1. Hoe wordt hergebruik van software artefacten in de theorie beschreven?
a. Welke software artefacten kunnen er hergebruikt worden?
b. Welke processen zijn er nodig voor hergebruik?
c. Hoe dient hergebruik georganiseerd te worden?
d. Wat zijn kritieke succesfactoren voor hergebruik?
e. Hoe vindt hergebruik van software artefacten plaats bij de ‘Best
Practices’?
f. Hoe kan de mate van hergebruik worden gekwantificeerd?
2. Hoe wordt hergebruik in de huidige situatie toegepast?
a. Welke software artefacten worden er hergebruikt?
b. Hoe zijn de processen ingericht voor hergebruik?
c. Hoe is de hergebruik-organisatie ingericht?
d. In welke mate wordt hergebruik toegepast?
e. Welke weerstanden en knelpunten bestaan er?
3. Wat is het gewenste niveau van hergebruik in de afdeling Modelling &
Simulation en hoe kan daar gekomen worden?
a. Welke software artefacten kunnen er nog meer hergebruikt
worden?
b. Welke veranderingen in de huidige processen zijn er nodig?
c. Welke veranderingen in de hergebruik-organisatie zijn er nodig?
d. Welke weerstanden kunnen zich voordoen en hoe kunnen deze
opgelost worden?
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
18
2.3
Onderzoeksmodel
Het onderzoeksmodel in Figuur 2 toont aan hoe het project is vormgegeven en hoe
het eindresultaat tot stand gekomen is [VER04]. Figuur 2 dient van links naar
rechts gelezen te worden.
Huidige Situatie
M&S
Artefacten
Processen
Theorie Hergebruik
Organisatie
Artefacten
Gewenste Situatie
M&S
Processen
Artefacten
Organisatie
Theoretisch Model
Aanbevelingen
Processen
voor Hergebruik
en conclusies
Metrics
Organisatie
Best Practices
b
a
c
d
Figuur 2 - Onderzoeksmodel hergebruik van software artefacten bij TNO-D&V.
Het onderzoeksmodel in Figuur 2 wordt als volgt verwoord:
(a) Op basis van een theoretische verkenning van hergebruik gespitst op de
software artefacten, de processen, de organisatie, de metrics en de best practices
(b) is een theoretisch model ontworpen waarmee de huidige situatie qua hergebruik
binnen de afdeling ‘Modelling & Simulation’ geanalyseerd is. (c) Op basis van de
uitkomsten van deze analyse en het theoretische model is er een gewenste situatie
geschetst. (d) De aanbevelingen en conclusies zijn gebaseerd op deze gewenste
situatie.
2.4
Aanpak
Om tot de beantwoording van de onderzoeksvragen en daarmee de vervulling van
de doelstelling te kunnen komen, is het noodzakelijk een duidelijke aanpak te
hanteren. Voor deze scriptie wordt er een onderscheid gemaakt naar een theoretisch
en empirisch gedeelte. Het theoretische gedeelte vormt de basis voor de rest van
het verslag.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
19
2.4.1
Theoretisch onderzoek
Het theoretische onderzoek richt zich op drie hoofdaspecten.
-
De herbruikbare software artefacten
De herbruikbare software artefacten zijn de entiteiten die daadwerkelijk
hergebruikt worden. Denk hierbij aan broncode, losse componenten of
architecturen.
- De processen
De processen beschrijven de opeenvolging van handelingen die nodig zijn
in het kader van hergebruik.
- De organisatie
De organisatie beschrijft onder andere de stakeholders, verantwoordelijkheden, functies van de betrokkenen en de inrichting van de organisatie
voor hergebruik.
Het theoretische onderzoek heeft als doel een model te schetsen waarmee
hergebruik van software artefacten in een organisatie geanalyseerd kan worden.
De drie behandelde onderwerpen vormen samen een gedegen beeld van wat er
hergebruikt kan worden, hoe dit gedaan kan worden en hoe het georganiseerd kan
worden.
Tevens wordt er aandacht besteed aan praktijkervaringen doormiddel van
bestudering van twee organisaties die worden gekenmerkt als ‘best practices’. Bij
de analyse van deze organisaties wordt het theoretische model toegepast.
Voor deze literatuurstudie is kennis vergaard uit boeken, wetenschappelijke
artikelen, relevante vakbladen, internet en, voor zover mogelijk, van specialisten.
2.4.2
Empirisch onderzoek
Aan de hand van de bestudeerde theorie wordt de huidige situatie binnen de
afdeling M&S geanalyseerd. Bij de beschrijving van de huidige situatie wordt een
onderscheid gemaakt naar de algemene situatie met haar projectoverschrijdende
kenmerken en naar drie case studies met hun specifieke kenmerken. Voor de
bestudering van de case studies wordt ook het theoretische raamwerk gehanteerd.
Op deze manier wordt inzicht verkregen in de knelpunten en weerstanden die
voorkomen bij de toepassing van hergebruik.
De benodigde informatie voor het empirische onderzoek wordt verkregen uit
interviews, presentaties, informele gesprekken en de aanwezige documentatie.
Op basis van de analyse van de huidige situatie, de bestudeerde theorie en de visie
van verschillende stakeholders binnen TNO-D&V wordt er een beeld geschetst van
de gewenste situatie. De gewenste situatie bevat verscheidene aanbevelingen voor
de toepassing en specifieke invullingen voor hergebruik.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
20
2.5
Afbakening
De aspecten die hieronder worden vermeld vormen de afbakening voor deze
scriptie.
-
Deze scriptie richt zich op de software engineering kernen binnen de
divisie Operationele Research en Bedrijfsvoering en Command Control en
Simulatie. Als gevolg van de reorganisatie vallen deze twee divisies onder
de business unit ‘Beleidstudies, operationele analyse en
informatievoorziening’, afdeling ‘Modelling & Simulations’
-
In deze scriptie wordt er gekeken welke categorieën van software
artefacten geschikt zijn voor hergebruik. De auteur van deze scriptie houdt
zich niet bezig met het beoordelen van de specifieke artefacten zelf.
-
De opbrengsten van hergebruik voor TNO-D&V zijn in beginsel geen
onderwerp van onderzoek binnen deze scriptie. Dat wil zeggen dat er voor
M&S niet berekend wordt wat de kostenbesparingen,
kwaliteitsverbeteringen en vermindering in ontwikkeltijd als gevolg van
hergebruik zijn geweest. Er wordt wel aandacht besteed aan hoe TNOD&V zelf kan onderzoeken.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
21
3.
Theoretische Analyse
“… reuse is neither a silver bullet nor a magic weight loss pill.
It is a diet and exercise program…” [BAS97]
In dit hoofdstuk worden verschillende theoretisch aspecten met betrekking tot
hergebruik van software artefacten behandeld. Gezien de grote hoeveelheid
informatie binnen dit onderwerp worden er een aantal aspecten uitgelicht te weten:
herbruikbare software artefacten, processen, organisatie, kritieke succesfactoren en
best practices. Tot slot wordt er nog aandacht besteed aan het kwantificeren van
belangrijke aspecten van hergebruik in het softwareontwikkelproces.
3.1
Hergebruik
In deze paragraaf wordt een definitie voor hergebruik van software artefacten
opgesteld en wordt bekeken wat de voor- en nadelen van hergebruik zijn.
3.1.1
Definities
Binnen de literatuur worden verschillende definities van hergebruik gehanteerd. In
Tabel 1 staan enkele definities opgesomd. Op basis van deze definities wordt een
eigen definitie geformuleerd die in deze scriptie gehanteerd wordt.
Definities vanuit de literatuur
Auteur
“Reuse is the process of adapting a generalized component to various
contexts of use”
“Software reuse is the process whereby an organization defines a set of
systematic operating procedures to specify, produce, classify, retrieve and
adapt software artifacts for the purpose of using them in its development
activities”
“Futher use or repeated use of an artifact, typically software artifacts are
designed for use outside of their original context to create new systems”
“Reuse is the systematic application of existing software artifacts during
the process of building a new software system, or the physical
incorporation of existing software artifacts in a new software system.”
“Software reuse, the use of existing software artifacts or knowledge to
create new software”
“Software reuse is the systematic practice of developing software from a
stock of building blocks, so that similarities in requirements and/or
architecture between applications can be exploited to achieve substantial
benefits in productivity, quality and business performance”
[BAS97]
Tabel 1 - Definities uit de literatuur van ‘Software Reuse'
[MIL02]
[JAC97]
[DUS95]
[FRA96]
[MOR02]
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
22
In de bovenstaande definities zijn belangrijke aspecten met betrekking tot
hergebruik van software artefacten dikgedrukt. De volgende aspecten vallen op:
-
-
-
Systematisch
Hergebruik is vaak onzichtbaar in een organisatie. Het komt wel voor maar
slechts beperkt en in een ad hoc vorm. Software ontwikkelaars maken
hierbij gebruik van eigen lokale bibliotheken bij het ontwikkelen van
software. Indien hergebruik systematisch zou worden aangepakt kunnen de
voordelen op een veel breder vlak uitgebuit worden. Hergebruik wordt
zichtbaar, meetbaar en er zijn processen te definiëren voor het produceren
en consumeren van herbruikbare artefacten. De opbrengsten van een
systematisch hergebruikinitiatief zijn in potentie veel groter.
Bestaande software artefacten1
Alleen bestaande software artefacten kunnen hergebruikt worden. Software
artefacten die tijdens project A zijn ontwikkeld worden tijdens project A
gebruikt en niet hergebruikt. Wordt het software artefact echter ook in
project B gebruikt, dan wordt het wel als hergebruik beschouwd. Wat een
software artefact precies is wordt in § 3.3.1 besproken.
Ontwikkeling nieuwe software systemen.
In de theorie bestaat er onenigheid of onderhoud ook een vorm van
hergebruik is. In dit verslag worden onderhoud en hergebruik als
principieel gescheiden beschouwd. In de praktijk kan er wel een relatie
bestaan tussen hergebruik en onderhoud van software producten.
Deze drie aspecten vormen de kern van software hergebruik. In Tabel 2 staat de
definitie die verder gehanteerd wordt in dit verslag.
Gehanteerde Definitie in deze scriptie
“Software hergebruik is het systematische proces waarbij bestaande
software artefacten worden gebruikt bij het ontwikkelen van nieuwe software.”
Tabel 2 - Te hanteren definitie m.b.t. hergebruik van software artefacten.
1 De term software artefact is gekozen vanwege de neutraliteit ten opzichte van
termen als object of component. Objecten en componenten zijn voor vele sterk
gerelateerd aan bijvoorbeeld een java-object of stukken code, hergebruik is
hiertoe echter niet beperkt.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
23
3.1.2
Voordelen
Net als bij andere engineering disciplines kan hergebruik binnen software
engineering ook veel profijt opleveren. De voordelen van hergebruik binnen
software engineering worden in drie categorieën onderverdeeld [MIL02].
-
Verbeteringen in de doorlooptijd
De essentie van hergebruik is het feit dat het wiel niet continue opnieuw
uitgevonden hoeft te worden, maar dat er gebruik kan worden gemaakt van
bestaande oplossingen. Indien dit netto minder tijd kost dan het zelf
ontwikkelen, heeft dit een positief effect op de doorlooptijd.
-
Verbeteringen in de kwaliteit.
Door het (mogelijk) grotere aantal gebruikers van een herbruikbaar artefact
kunnen fouten eerder opgemerkt en verholpen worden. De kwaliteit van de
herbruikbare artefacten kan hierdoor beter zijn dan van zelf ontwikkelde
artefacten. Tevens ontstaat de mogelijkheid om meer te investeren in de
kwaliteit van de software artefacten doordat de kosten over meerdere
gebruikers verrekend kunnen worden.
-
Daling in de kosten
Hergebruik van software artefacten kan een daling in de totale
softwareontwikkelkosten realiseren. Een herbruikbaar software artefact
hoeft immers maar één keer ontwikkeld te worden terwijl het meerdere
keren hergebruikt kan worden. Door tevens het beheer van het
herbruikbare artefact centraal uit te voeren bespaart een organisatie in de
onderhoudskosten van een herbruikbaar artefact. Een voorwaarde om deze
besparingen te realiseren is dat de herbruikbare artefacten meerdere keren
hergebruikt worden.
3.1.3
Risico’s en belemmeringen
Ondanks de voordelen bestaan er ook belemmeringen en risico’s die ervoor hebben
gezorgd dat het systematisch hergebruiken van software artefacten nog geen
algemene intrede heeft gedaan in de software industrie [MIL02][SOM04].
-
Beperkt potentieel voor systematisch hergebruik
Er zijn drie factoren die de mogelijkheid tot systematisch hergebruik
beperken.
1. Volwassenheid van het softwareontwikkelproces
Het mogelijke niveau van hergebruik is verbonden met huidige
manier van werken binnen het softwareontwikkelproces. Indien het
softwareontwikkelproces chaotisch is, is een systematische vorm
van hergebruik moeilijk te bereiken. In § 3.4.5 wordt hier dieper
op ingegaan.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
24
2. Homogeniteit van de software producten
Naar mate de diversiteit tussen de producten die door een
organisatie ontwikkeld worden toeneemt, neemt de mogelijkheid
voor hergebruik af. Bij een organisatie waar er sprake is van een
sterke homogeniteit tussen de ontwikkelde softwareproducten is
de potentie van hergebruik groter dan bij een organisatie waar dit
minder het geval is.
3. Ontwikkeling van een applicatie domein
Indien een organisatie zich in een relatief nieuw domein
bezighoudt, is de basis voor hergebruik mager aangezien er nog
relatief weinig aspecten bekend en stabiel zijn. Indien het domein
bekender wordt ontstaat er een beter inzicht in wat er wel en niet
hergebruikt kan worden.
-
Niet te verwaarlozen kosten en onzekere opbrengsten
Er wordt vaak gepropageerd dat hergebruik veel kan opleveren en weinig
zal kosten. De realiteit is vaak anders; er zijn vele (verborgen) kosten
waarmee ook rekening gehouden moet worden. Figuur 35 in Bijlage A
toont duidelijk de financiële impact op projectniveau met betrekking tot de
kosten en opbrengsten van hergebruik. De kosten voor hergebruik zijn
zeker, direct en vaak gebonden aan bepaalde projecten. De baten komen
later, zijn onzeker en komen vaak andere projectteams toe [FIC01]. Op
organisatieniveau moet hergebruik van software artefacten worden gezien
als een investering in de toekomst. Eerst zal er geïnvesteerd moeten
worden om een verzameling herbruikbare artefacten te creëren, de
hergebruikprocessen te definiëren en te implementeren en de organisatie
erop aan te passen. Pas wanneer de artefacten worden hergebruikt ontstaan
de baten van hergebruik.
-
Aanzienlijke obstakels
De invoering van een systematisch toepassing van hergebruik van software
artefacten heeft een grote impact op de processen en organisatie binnen een
onderneming. Dit vergt een cultuurverandering en gaat meestal gepaard
met weerstand. Om deze wijzigingen in de processen en organisatie en de
cultuurverandering te bewerkstelligen is management support
onontbeerlijk.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
25
3.2
Kritieke succes- en faalfactoren
In deze paragraaf worden de verschillende kritieke succesfactoren die zich
voordoen bij de invoering en beoefening van hergebruik van software artefacten
besproken. Tevens bespreekt deze paragraaf een aantal factoren die worden
aangemerkt als faalfactoren.
3.2.1
Kritieke succesfactoren
Een kritieke succesfactor voor hergebruik is een factor dat van doorslaggevend
belang is in het succes van hergebruik van software artefacten.
(Top) Management Support
Dit is een van de belangrijkste factoren die het succes van een
hergebruikprogramma bepalen [MOR00][DOU97]. Een hergebruik programma
heeft veranderingen in de organisatiestructuur, de processen en de cultuur tot
gevolg. Om dit te realiseren is het noodzakelijk dat het top management het
hergebruikinitiatief actief steunt. Ook op middle management en
projectmanagement niveau moet er ondersteuning zijn.
Invoering van hergebruik processen
Om hergebruik te realiseren moeten er nieuwe processen ingevoerd worden.
Belangrijke aandachtspunten hierbij zijn processen voor het produceren van
herbruikbare artefacten, het zoeken en gebruiken van deze herbruikbare artefacten
en ondersteuning en beheer[MOR02]. Er worden trouwens niet alleen nieuwe
processen ingevoerd, ook de huidige processen zullen aangepast moeten worden
om de specifieke hergebruik processen te integreren [MOR00][EZR02]. Indien er
een situatie ontstaat waarbij de hergebruikprocessen buiten de normale processen
komen te liggen of hergebruik de normale softwareontwikkelprocessen verstoort,
heeft dit een negatieve invloed op het imago, de toepassing en ondersteuning voor
hergebruik [SMI94][EZR02].
Anticipatie op menselijke factoren
Hergebruik heeft een flinke impact op de betrokken stakeholders. Niet alleen
werkwijzen veranderen, ook beloningsstructuren, processen en
verantwoordelijkheden veranderen. Het is noodzakelijk de ontwikkelaars en
projectmanagers via voorlichting en trainingen vertrouwd te laten raken met hergebruik en de verschillende veranderingen en technieken hierin [ROT99][MOR00].
Incrementele invoering van hergebruik
Omdat de invoering van een systematische hergebruik aanpak een grote impact
heeft op een organisatie is het belangrijk om dit incrementeel te doen. Bij een
incrementele aanpak worden de obstakels afzonderlijk genomen en worden de
risico’s van hogere kosten kleiner en de kans op succes groter [VIL95][LYN98].
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
26
Repository
Om te kunnen hergebruiken is het noodzakelijk een centraal punt te hebben waar
de herbruikbare artefacten opgeslagen en verkregen kunnen worden. Deze
opslagplaats is tevens de plaats waar processen zoals configuratie management en
versiebeheer, changemanagement en onderhoud goed centraal geregeld kunnen
worden.
Uit onderzoek is gebleken dat ook binnen een organisatie verschillen voorkomen in
de mate van succes van hergebruik tussen verschillende projecten [ROT99]. Ook
op projectniveau zijn er dus factoren die het succes van hergebruik beïnvloeden
[ROT99]. Hierbij is er wel een overlap met de factoren op organisationeel niveau.
Factoren die hergebruik van software artefacten op projectniveau beïnvloeden zijn:
-
tijd en monetaire beperkingen,
mate van training en beloning,
kennis en ervaring van de ontwikkelaar met hergebruik,
visie en mening van de projectmanager en de ontwikkelaar ten opzichte
van hergebruik.
3.2.2
Faalfactoren
De genoemde succesfactoren geven allemaal aan welke factoren bijdragen aan een
succesvolle invoering en exploitatie van hergebruik binnen een organisatie. De
faalfactoren beschrijven die vanuit het omgekeerde perspectief, namelijk welke
factoren hebben een negatieve invloed op hergebruik [MCC95][LYN98].
-
‘Not-Invented-Here’ syndroom (NIH)
Dit betekent het, bedoeld of onbedoeld, niet gebruik maken van een
bestaand artefact omdat het niet zelf ontwikkeld is. Dit kan voorkomen
omdat het bestaan van het artefact niet bekend is (onbedoeld). Vaak is het
echter zo dat bij de ontwikkelaar de wil om het artefact te doorgronden
ontbreekt en de gedachte bestaat dat het zelf ontwikkelen een superieur
artefact oplevert, goedkoper is of tijdwinst oplevert. NIH wordt versterkt
door een zwakke vorm van management [EZR02].
Communicatieproblemen versterken dit syndroom. Het komt vaak voor dat
afdelingen of business units een eigen werkwijze en vocabulaire hebben
waardoor kansen voor hergebruik niet direct herkend worden [HAR98].
Een duidelijke informatievoorziening over de herbruikbare artefacten en
hergebruik kan dit syndroom beperken. Tevens kan een sterke vorm van
management waarbij hergebruik bijvoorbeeld wordt verplicht het NIH
syndroom beperken [EZR02].
-
Gebrek aan commitment op lange termijn
Om hergebruik mogelijk te maken zijn vooraf flinke investeringen
noodzakelijk. Tevens tonen de baten van hergebruik zich niet direct. Deze
twee eigenschappen stellen het management voor een dilemma aangezien
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
27
zij eindverantwoordelijk zijn voor de investeringen. Om de toewijding voor
hergebruik vast te houden, dient er vooraf een duidelijk beeld geschetst te
worden van de benodigde investeringen en de verschillende voor- en
nadelen die eraan verbonden zijn. Gedurende het proces kunnen met
behulp van metingen van specifieke aspecten de voortgang en kosten en
baten gekwantificeerd worden. Dit is belangrijk om de gedane
investeringen te kunnen verantwoorden en de commitment te behouden.
-
Grote verzameling van kwalitatief slecht ‘herbruikbare’ artefacten
Het komt vaak voor dat bij de aanvang van een hergebruik programma de
repository snel wordt gevuld met ‘herbruikbaar’ gelabelde artefacten. Dit
dient te allen tijde gecontroleerd te gebeuren zodat er geen situatie ontstaat
waarbij de herbruikbare artefacten veelal van slechte kwaliteit zijn.
Een effectieve manier is om te beginnen met een kleine verzameling van
kwalitatief hoogstaande, nuttige herbruikbare artefacten. Dit voorkomt ten
eerste het nutteloos produceren van matig herbruikbare artefacten en ten
tweede de mogelijke schade die hergebruikers oplopen bij het hergebruiken
van kwalitatief slechte artefacten. Op deze manier wordt de kans dat
investeringen niet worden terugverdiend beperkt. Tevens wordt de kans op
een negatieve houding ten opzichte van hergebruik beperkt.
-
Weerstand
Weerstand ontstaat uit angst of onwil om te veranderen, angst voor het
onbekende of gebrek aan kennis over het nieuwe fenomeen. De bron van
weerstand verschilt per stakeholder.
Zo kan het voor ontwikkelaars een beperking in hun creativiteit vormen als
ze gedwongen worden bestaande software artefacten te hergebruiken.
Slechte ervaringen met hergebruik, bijvoorbeeld door gebrekkige kwaliteit
van de herbruikbare artefacten, vormen ook een sterke bron van weerstand
tegen hergebruik. Voor de project- en senior managers is het natuurlijk
belangrijk hoe de financiële aspecten geregeld worden. Projectmanagers
willen geen budget kwijtraken aan hergebruik en de senior managers willen
uiteindelijk een positief resultaat zien.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
28
3.3
Herbruikbare artefacten
Deze paragraaf richt zich op de software artefacten die hergebruikt kunnen worden.
Eerst wordt bekeken wat een herbruikbaar artefact is en worden er definities van
enkele termen vastgesteld. Hierbij wordt ook beschreven welke documentatie en
informatie er bij een herbruikbare artefact beschikbaar dient te zijn. Daarna wordt
er een vergelijking gemaakt tussen een herbruikbaar artefact en een niet
herbruikbaar artefact en worden er twee manieren van hergebruik besproken. Tot
slot beschrijft deze paragraaf hoe artefacten gekoppeld kunnen worden en welke
niveaus van intensiteit van hergebruik te onderscheiden zijn.
3.3.1
Definitie
De theorie spreekt over hergebruik van componenten, assets en artefacten. In de
gehanteerde definitie van hergebruik wordt gesproken over software artefacten.
Voor een artefact wordt hier de volgende definitie gehanteerd:
“a piece of formalized knowledge that can contribute
to the software engineering process” [DUS95].
Een herbruikbaar artefact 2 is dus een stuk geformaliseerde kennis, een
werkproduct, dat een positieve bijdrage kan leveren aan het software
ontwikkelproces. Hierbij hoeft het niet zo te zijn dat het artefact met het oog op
hergebruik is ontwikkeld. Een goed softwareontwikkelproces, waarin rekening
wordt gehouden met algemene principes zoals modulariteit, interoperabiliteit en
standaarden, draagt bij aan de herbruikbaarheid van een software artefact.
Voorbeelden van herbruikbare artefacten zijn [MIL02]:
-
requirements,
ontwerpen,
architecturen,
broncode,
uitvoerbare code,
testdata,
documentatie.
De theorie beschrijft een component op verschillende manieren. Sommige auteurs
benaderen een component op dezelfde manier als in deze scriptie een herbruikbaar
artefact wordt beschreven. Andere zien een component als een stuk losstaande
functionaliteit met gespecificeerde interfaces en (bijna) onafhankelijk van andere
componenten. Dit is ook de manier waarop componten in deze scriptie gezien
2 Indien er in deze scriptie wordt gesproken over artefacten dan worden hier altijd
software artefacten mee bedoeld.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
29
worden. Een component is dus een type herbruikbaar artefact. Naast componenten
en artefacten bestaan er ook assets. Een asset is als volgt gedefinieerd:
“een verzameling van gerelateerde artefacten die tezamen een
oplossing bieden voor een bepaald probleem” [EZR02].
Een asset is volgens de definitie breder dan een herbruikbaar artefact. De definitie
van een asset spreekt van gerelateerde artefacten. Hiermee worden artefacten
bedoeld die bij elkaar horen, zoals een ontwerpmodel en testplan bij een stuk code
horen, en niet artefacten die enkel van elkaar afhankelijk zijn zoals componenten
waar afhankelijkheden tussen bestaan. In dit laatste geval is er sprake van relaties
tussen herbruikbare assets. Figuur 3 geeft een beeld van de gewenste informatie
omtrent een herbruikbaar asset. De documentatie wordt in § 3.3.2 toegelicht.
Een herbruikbaar asset bestaat dus uit een body en een beschrijving. De body wordt
gevormd door één of meer bij elkaar horende herbruikbare artefacten3. In Figuur 3
zijn twee relaties te zien die toelichting verdienen. Als eerst de ‘gebruikt’ relatie
tussen herbruikbare assets onderling. Deze relatie duidt de afhankelijkheden tussen
assets aan. De tweede relatie is de relatie ‘bestaat uit’. Deze relatie geeft aan dat
een herbruikbaar asset opgebouwd kan zijn uit andere herbruikbare assets. Op deze
manier is het mogelijk applicatie frameworks te vormen met bijbehorende
componenten. Tussen deze applicatie frameworks en componenten bestaat er een
sterke synergie. § 3.3.7 gaat hier verder op in.
Figuur 3 spreekt over ‘omgeving’, hiermee worden omgevingsfactoren bedoeld.
Deze factoren beschrijven in welke software en hardware omgeving het artefact is
ontwikkeld en getest en voor welke omgeving het geproduceerd is. Het is
belangrijk deze ‘omgevingsfactoren’ van een herbruikbaar artefact te
standaardiseren om zo de mogelijkheid tot hergebruik van software artefacten in
een organisatie te vergroten. Het is evident dat in een organisatie die veel
verschillende programmeertalen, ontwikkelomgevingen en hardwareplatvormen
gebruikt, de mogelijkheid tot hergebruik beperkter is dan in dezelfde organisatie
waar deze factoren zoveel mogelijk zijn gestandaardiseerd. Hetzelfde geldt voor
gebruikte standaarden en tools. Indien dit niet gebeurt ontstaan er ‘technology
islands’ en hier is een organisatie niet bij gebaat [BAS97].
In Figuur 3 geeft een opsomming van mogelijke herbruikbare artefacten. Elke
organisatie moet hier zijn eigen model definieren met de artefacten die in die
organisatie hergebruikt worden en de informatie die bij een artefact wordt
beschreven.
3 De herbruikbare artefacten in Figuur 3 vormen slechts voorbeelden, het is geen
afbakening van dat wat hergebruikt kan worden.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
30
Legenda
relatie
aggregatie
specialisatie
Figuur 3 - Compositie van een herbruikbaar asset [EZR02].
3.3.2
Documentatie van herbruikbare artefacten
Documentatie is een belangrijk aspect bij een herbruikbaar artefact. Om het artefact
te kunnen hergebruiken, heeft de hergebruiker over verschillende items informatie
nodig. Tabel 3 toont een documentatie template. Deze template is bedoeld voor
herbruikbare componenten maar kan ook worden gebruikt voor andere typen
herbruikbare artefacten.
Basis Informatie
Algemene informatie
Historie
Functionele specificatie
Interfaces
Certificatie
Beschrijft de naam van het artefact, type artefact, de bron van
het artefact, korte beschrijving waarom dit artefact is
ontwikkeld en wat het voor de hergebruiker kan betekenen.
Beschrijft de evolutie van het artefact. Tevens wordt er
aandacht besteedt aan situaties waarin dit artefact eerder is
hergebruikt.
Beschrijft de inputs, outputs en aangeboden functionaliteit van
het artefact in detail.
Beschrijft de aangeboden en gewenste interfaces van het
artefact.
Beschrijft de certificering van dit artefact en hoe het aan de
certificatie criteria voldoet.
Gedetailleerde informatie
Technische details
Beschrijft de informatie over het formaat van het artefact,
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
31
Installatie handleiding
Beperkingen
Aanpasbaarheid
omgeving waarin het herbruikbare artefact is ontwikkeld,
waarin het is getest en waarin het gebruikt dient te worden
[EZR02], fysieke bronnen die het artefact nodig heeft,
afhankelijkheden van andere artefacten en eventuele technische
beperkingen bij het gebruik van het artefact.
Beschrijft hoe het artefact geïmplementeerd en geïnstalleerd
dient te worden. Een voorbeeld van gebruik is hierbij essentieel
aangezien dit in de praktijk vaak een zeer belangrijke bron van
informatie vormt voor de potentiële hergebruiker [MIL02].
Beschrijft alle zaken die de ontwikkelaar beperken. Denk
hierbij aan interface beperkingen, de benodigde hardware en
software.
Beschrijft hoe dit artefact aangepast kan worden. In geval van
black box beschrijft dit bijvoorbeeld hoe het artefact via
parameterisatie afgesteld kan worden of waar de expliciete
extentiepunten zitten.
Overige informatie
Testen
Ondersteuning
Beschrijft de omgeving waarin het artefact is getest, welke data
hiervoor is gebruikt, eventuele test cases en methoden en de
resultaten.
Beschrijft wie het aanspreekpunt voor dit herbruikbare artefact
is en hoe deze persoon bereikt kan worden.
Tabel 3 - Documentatie Template herbruikbare artefacten [KAL01][MIL02].
3.3.3
Eisen aan een herbruikbaar software artefact
Vanuit de theorie worden er een aantal eisen geformuleerd waar herbruikbare
artefacten aan moeten voldoen. Dit zijn algemene criteria, functionele criteria en
technische criteria [EZR02]. Hieronder staan per aspect een aantal voorbeelden van
criteria opgesomd.
Algemene criteria
- Naleven van richtlijnen en standaarden
Dit betreft de standaarden voor de documentatie en implementatie van
herbruikbare software artefacten. Voor programmeerstandaarden kan gebruik
gemaakt worden van standaarden zoals de JAVA sun standaard4 of de C++
Ellemtel standaard5.
- Eenvoud, modulariteit en begrijpbaarheid
Eenvoud, begrijpbaarheid en modulariteit zijn ook belangrijk. Zo zal een
component dat uit één grote lap code bestaat minder herbruikbaar zijn dan een
component dat logisch is opgedeeld in verschillende modulen [PRE00].
4
5
Zie http://java.sun.com/docs/codeconv/
Zie http://www.doc.ic.ac.uk/lab/cplus/c++.rules/
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
32
Functionele criteria
Dit betreft vaak domein specifieke criteria. Het is niet mogelijk hier, zonder kennis
van het domein, eenduidige criteria voor op te stellen. Organisaties moeten deze
zelf opstellen op basis van standaarden en richtlijnen die binnen dat domein
gehanteerd worden.
Technische criteria
- Interoperabiliteit
Dit is het gemak waarmee een artefact communiceert met andere artefacten.
Binnen een applicatie framework kunnen er bijvoorbeeld protocol-afspraken
worden gemaakt die vastleggen hoe de componenten onderling communiceren.
- Portabiliteit
De benodigde moeite om een herbruikbaar artefact van de ene hardware en/of
software omgeving in de andere te kunnen gebruiken.
- Scheiding interface en implementatie
Hoe een herbruikbaar artefact wordt gebruikt (interface) en de manier waarop
het is geimplementeerd zijn twee aparte zaken die ook apart kunnen evolueren.
3.3.4
Herbruikbare versus niet herbruikbare software artefacten
Er bestaan een aantal verschillen tussen herbruikbare en niet herbruikbare software
artefacten. Deze paragraaf beschrijft twee belangrijke aspecten: de verschillen in de
opzet en kosten tussen een herbruikbaar en niet herbruikbaar software artefact.
Opzet
Normaal worden software artefacten voor een specifieke applicatie ontwikkeld.
Herbruikbare artefacten daarentegen moeten applicatie onafhankelijk zijn, dat wil
zeggen dat ze bij gebruik niet aan één specifieke applicatie zijn verbonden.
Om in verschillende projecten hergebruikt te kunnen worden dient het artefact
bepaalde functionaliteiten te bieden waar binnen die projecten behoefte aan is
(functionele herbruikbaarheid) en moet aan bepaalde gebruikerseisen voldaan zijn
(technische herbruikbaarheid en kwaliteit). Niet elk artefact is dus een herbruikbaar
artefact.
Nu is het niet zo dat er een absolute scheiding is tussen een herbruikbaar en een
niet herbruikbaar artefact. In de theorie bestaat er ook geen consensus over wat
herbruikbaarheid nu precies is en welke kwalitatieve of kwantitatieve aspecten hier
aan verbonden zijn. Deze scriptie gaat er vanuit dat het een samenspel is van
factoren zoals bruikbaarheid, variabiliteit en algemeenheid [BAS97]. Voor de
bruikbaarheid wordt er gekeken naar aspecten die een rol spelen indien het
herbruikbare artefact wordt hergebruikt. Aspecten als functionaliteit, efficiency
(snelheid en benodigde ruimte) en ease-of-use spelen hierin een belangrijke rol.
Variabiliteit staat voor de mate waarin het aangepast kan worden. Algemeenheid
duidt de scope aan waarin het toegepast kan worden.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
33
Bij het produceren van een herbruik artefact heeft de producent ook altijd te maken
met de afweging tussen abstractie en concreetheid [MIL02]. Hoe generieker het
artefact is opgezet hoe te breder het toepasbaar zal zijn. De inspanning om het te
kunnen hergebruiken neemt echter ook toe. Hoe concreter een artefact is hoe
minder inspanning het zal kosten om het te kunnen hergebruiken. De mate waarin
het hergebruikt kan worden neemt echter af. Hier ligt ook een belangrijk verschil
tussen herbruikbare en niet herbruikbare artefacten. Niet herbruikbare artefacten
zijn specifiek voor één situatie of probleem ontwikkeld terwijl herbruikbare
artefacten in meerdere situaties toegepast moeten kunnen worden.
Kosten
De productiekosten van herbruikbare artefacten zijn hoger dan de productiekosten
van niet-herbruikbare artefacten. De daadwerkelijke kosten voor het produceren
van een herbruikbaar artefact zijn afhankelijk van de complexiteit en grote van het
artefact [FRA96]. De schattingen voor de productiekosten van herbruikbare
artefacten ten opzicht van niet-herbruikbare artefacten variëren van 1,2 tot 2,2 keer
zo hoog [FRA96]. In de theorie wordt het kengetal 1,5 gehanteerd [POU97].
Hierbij moet ook rekening gehouden worden met het feit dat er een verschil bestaat
in de benodigde inspanning om een herbruikbaar artefact te kunnen hergebruiken.
De verhouding hiervan tot het zelf ontwikkelen van het artefact is afhankelijk van
de manier waarop het artefact hergebruikt wordt, met of zonder aanpassingen. In de
literatuur worden de volgende ratio’s gehanteerd, 0,2 voor hergebruik zonder
aanpassingen en 0,67 voor hergebruik met aanpassingen[JAC97][MIL02][POU97].
Dit betekent dat het hergebruiken van een software artefact als black box 20% van
de moeite kost, die het normaal kost om het artefact vanuit niets te ontwikkelen.
Dit zijn industriewijde kengetallen en kunnen dus afwijken voor een specifieke
organisatie. Om de kosten voor het produceren en hergebruiken van een
herbruikbaar artefact terug te verdienen, dient het artefact dus meerdere malen
hergebruikt te worden. Schattingen variëren van 2 tot 13 maal, afhankelijk van de
grootte, complexiteit en manier van hergebruik [FRA96].
3.3.5
Black box en White box hergebruik
De theorie onderscheidt twee uitersten voor de manier waarop de herbruikbare
artefacten kunnen worden hergebruikt: black box en white box hergebruik
[EZR02][MIL02]. Deze paragraaf bespreekt beide manieren en bekijkt de voor- en
nadelen, de technische implicaties en de gevolgen op bijvoorbeeld de productie en
onderhoudsprocessen.
Black box hergebruik
Black box hergebruik is het hergebruiken van software artefacten zonder deze te
wijzigen. De artefacten worden ‘as-is’ gebruikt. Het voordeel hiervan is dat de
hergebruiker geen kennis nodig heeft van het ontwerp of de implementatie en op
deze manier een flinke hoeveelheid tijd bespaard omdat hij het artefact zelf niet
intern hoeft te doorgronden of op code niveau aan zijn wensen hoeft aan te passen.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
34
Het nadeel van black box hergebruik is dat het relatief veel moeite kost om een
dergelijk artefact te produceren omdat er rekening gehouden moet worden met
verschillende wensen en toekomstige (onbekende) behoeften.
Er zijn verschillende methoden om variabiliteit in black box artefacten te
realiseren. Black box hergebruik blijft zo praktisch en effectief [JAC97]. Voor deze
variabiliteit zijn variatiepunten in het software artefact opgenomen. Variatiepunten
zijn locaties in het artefact waar de hergebruiker iets kan instellen of toevoegen
(aggregatie, overerving, parameterisatie) [JAC97]. Hieronder worden twee
belangrijke methoden besproken om deze variabiliteit in herbruikbare artefacten te
realiseren.
-
Hooks en Slots
Een hook is een punt in het artefact dat zo is ontworpen/geïmplementeerd dat
het de gebruikers de mogelijkheid geeft additionele functionaliteit toe te
voegen. Een slot is een missend gedeelte van het artefact dat opgevuld dient te
worden door de gebruiker naar zijn of haar wensen.
Dit kan bijvoorbeeld via inheritance, stel dat een software artefact een
abstracte klasse ‘rekening’ bevat. Om van dit artefact gebruik te kunnen maken
dient de gebruiker een subklasse voor de methode te schrijven waarin hij zijn
eigen implementatie geeft aan de abstracte methoden uit de klasse ‘rekening’.
Zo kan de hergebruiker bijvoorbeeld een subklasse ‘kapitaalrekening’ of
‘spaarrekening’ aan de abstracte klasse ‘rekening’ hangen.
-
Parameterisatie
Bij parameterisatie worden variabele aspecten in het artefact opgevangen
doormiddel van parameters. De hergebruiker van het artefact bepaald welke
parameters er voor het artefact gezet worden en specialiseert op deze manier
het artefact naar zijn behoefte. Er zijn twee type parameterisatie die gebruikt
kunnen worden, namelijk functionele en data parameterisatie [MIL02]. Bij data
parameterisatie wordt de input van een functie van één specifiek type input
uitgebreid naar verschillende typen input waarop de functie van toepassing kan
zijn. Bij functionele parameterisatie biedt het artefact in plaats van één type
functionaliteit verschillende functionaliteiten. Denk bijvoorbeeld aan een
merge algoritme dat twee gesorteerde lijsten als parameters nodig heeft en
criteria om deze te vergelijken. Door zelf het sorteercriterium te bepalen kan de
methode merge alle soorten data in de lijsten vergelijken.
Een goede beschrijving van de interfaces en manier waarop het gebruikt kan
worden is essentieel bij black box hergebruik. Een voorbeeld van gebruik kan hier
goed bij helpen [MIL02]. In geval van parameterisatie dient er beschreven te
worden wat de hergebruiker hiermee kan doen en welke ranges van parameters
mogelijk zijn. In het geval van hooks & slots dient beschreven te worden wat de
hergebruiker nog aan functionaliteit moet implementeren (slots) en waar hij
eventueel extra functionaliteit op kan bouwen (hooks).
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
35
White box hergebruik
Bij white box hergebruik worden de artefacten wel aangepast voordat ze in het
nieuwe systeem geïntegreerd worden. De mate waarin de artefacten hergebruikt
kunnen worden neemt hierdoor toe, hetzelfde geldt ook voor de kosten. Om een
artefact succesvol te kunnen modificeren is een gedegen mate van kennis van het
ontwerp en de implementatie nodig. In het geval van een component of broncode is
het daarbij essentieel dat er documentatie in de code zelf aanwezig is, bijvoorbeeld
javadoc in het geval van Java. De flexibiliteit van white box hergebruik is groter
dan de flexibiliteit van black box hergebruik, in de praktijk blijkt ook dat white box
hergebruik vaker voorkomt [MIL02].
In de mogelijkheid om de artefacten aan te passen schuilt ook een risico. Uit
onderzoek is gebleken dat bij herbruikbare componenten die voor meer dan 25%
zijn gewijzigd het aantal fouten vier tot acht keer zo hoog lag in vergelijking met
componenten die vanuit niets zijn geschreven [FEN97]. Het gebrek aan kennis van
de interne werking van het artefact kan dus leiden tot fouten.
Beheer van black box en white box artefacten
Naast de genoemde voor- en nadelen van black en white box is er nog een laatste
aspect: het management van de artefacten. Bij black box hergebruik bestaat er
slechts één versie van een artefact. Ondersteuning, onderhoud en configuratie
management kunnen in dit geval op één centrale plaats uitgevoerd worden. Bij
white box hergebruik bestaat er, door de aanpassingen, een risico dat er een
veelvoud aan versies, van één artefact, ontstaat. Dit is in Figuur 4 te zien.
Artefact v1.1.1
Artefact v1.1
Artefact v1.1.2
Artefact v1.0
Artefact v1.2
Artefact v1.3.1
Artefact v1.3
Artefact v1.3.2
Artefact v1.3.3
Figuur 4 - Mogelijke wildgroei aan versies van één herbruikbaar artefact.
In dit geval is centraal management van het artefact ook niet meer mogelijk en kan
iedere versie een eigen leven gaan leiden waardoor veel voordelen van hergebruik
verloren gaan.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
36
3.3.6
Compositiescenario’s en -mechanisme voor herbruikbare artefacten
In de praktijk komt het veelvuldig voor dat hergebruikers verschillende artefacten
met elkaar willen laten communiceren binnen een applicatie. Hierbij zijn vier
scenario´s mogelijk [MIL02]. Figuur 5 schetst deze scenario’s. Alvorens deze te
bespreken worden er twee termen vastgelegd:
Gebruiker (client):
Leverancier (server):
Scenario 1
Het artefact dat binnen een applicatie een bepaalde functie
vervuld en daarvoor een bepaalde service wenst van een
ander artefact.
Het artefact dat aangeroepen wordt via één van zijn
methode om een bepaalde service te leveren.
Scenario 2
Scenario 3
Wrapper
Gebruiker
Leverancier
Figuur 5 - Compositiescenario's tussen herbruikbare artefacten [MIL02].
Scenario 1: Exacte overeenkomst
De leverancier heeft precies de functionaliteit en interface die de gebruiker wenst.
Dit is de ideale situatie waarbij er geen aanpassingen nodig zijn.
Scenario 2: Extra services
De leverancier biedt meer services dan de gebruiker nodig heeft, de services en
interface die de gebruiker wenst worden echter wel aangeboden. Over het
algemeen is dit geen probleem, het kan echter wel voorkomen dat deze extra
services een nadelige invloed hebben op de performance van het artefact [MIL02].
Scenario 3: Aangepaste services
Dit komt voor indien de interfaces van de aanbieder en gebruiker niet geheel
overeenkomen [MIL02]. In dit geval is het mogelijk de leverancier aan te passen
om alsnog een match te bewerkstelligen. Dit komt bijvoorbeeld voor indien de API
of het component meer parameters vraagt dan dat de gebruiker kan leveren. Er
wordt dan een extra laag software (wrapper) toegevoegd die de communicatie op
elkaar afstemt.
Scenario 4: Aanvullende services
In dit geval biedt de gebruiker niet direct de functionaliteit die binnen de applicatie
nodig is maar moeten de twee artefacten gecombineerd worden om de gewenste
functionaliteit binnen de applicatie te leveren. In dit geval worden de twee
artefacten aan elkaar ‘gelijmd’.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
37
Om herbruikbare artefact toch te kunnen koppelen zijn er twee mogelijkheden.
1. Directe samenstelling
Hierbij worden de artefacten die een applicatie opbouwen direct gekoppeld.
De artefacten roepen direct de services van elkaar aan waardoor er een sterke
koppeling ontstaat tussen de interfaces van de artefacten. Dit kan echter tot
zeer complexe situaties leiden aangezien het aantal interfaces nagenoeg
exponentieel, n × n = n2, toeneemt met het aantal artefacten [MIL02]. Indien
er een nieuw artefact wordt toegevoegd, moeten er in het slechtste geval n
nieuwe interfaces ontwikkeld moeten worden.
Design patterns kunnen helpen de sterke koppeling tussen artefacten te
beperken [MIL02]. Dit is mogelijk door van typerende kenmerken van
specifieke implementaties (bijvoorbeeld platformspecifieke eisen) te
abstraheren of door communicatie mogelijk te maken tussen artefacten die
geen kennis van elkaars API hebben. Dit wordt bijvoorbeeld gedaan door het
observer/observable patroon [MIL02].
2. Middleware
Middleware is een softwarelaag tussen het besturingssysteem en de
applicatiecomponenten. Middleware maakt de communicatie tussen de
(gedistribueerde) componenten mogelijk op zo’n manier dat de componenten
niet direct met elkaar communiceren maar via het framework. Voorbeelden
zijn Common Object Request Broker Architecture (CORBA), Distributed
Component Object Model (DCOM) en JAVA Remote Method Invocation
(RMI).
3.3.7
Intensiteit van hergebruik
Hergebruik kan op verschillende niveaus van intensiteit beoefend worden
[HAL97]. Dit heeft betrekking op de mate waarin overeenkomsten tussen
gerelateerde software producten worden uitgebuit. Hier wordt een onderscheid
gemaakt naar drie niveaus van intensiteit [HAL97].
1. Hergebruik van algemene artefacten
Deze vorm van hergebruik is de eenvoudigste en minst risicovolle manier om
hergebruik te beoefenen. Deze aanpak omvat het hergebruiken van
zogenaamde horizontale artefacten.
Horizontaal hergebruik benut de overeenkomsten binnen technische
domeinen, denk bijvoorbeeld aan componenten als GUI’s, data storage en
retrieval, distributie en communicatie. Tevens benut het ook overeenkomsten
tussen verschillen applicatie domein. Bijvoorbeeld een loon- of
reserveringssysteem dat zowel gebruikt kan worden binnen het domein van
bibliotheken als autoverhuur. De mate van hergebruik is op dit niveau niet
hoog, de benodigde inspanning om dit te bereiken is echter beperkt. Bij
organisaties waar deze aanpak is gehanteerd zijn hergebruikpercentages van
20 tot 30% gemeten [HAL97].
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
38
2. Hergebruik binnen een applicatie domein
Het uitbreiden van de scope van algemene (horizontale) artefacten naar
domein specifieke (verticale) artefacten is een uitdagendere stap. Bij verticaal
hergebruik worden de overeenkomsten binnen één applicatie domein benut.
Goede domeinkennis is noodzakelijk om de overeenkomsten en variabiliteit
binnen een domein te kunnen onderscheiden en op basis hiervan de juiste
domein specifieke artefacten te kunnen produceren.
Dit niveau vergt een dieper inzicht in het domein en brengt meer risico’s met
zich mee in vergelijking met het hergebruiken van algemene artefacten. De
mogelijke opbrengsten daarentegen zijn een stuk hoger.
Hergebruikpercentages tot 50% zijn gemeten [HAL97].
3. Hergebruik met applicatie frameworks
Bij deze aanpak wordt er een applicatie framework ontwikkeld waarin
verschillende applicaties binnen een domein ontwikkeld kunnen worden. Een
applicatie framework is een blauwdruk van een applicatie met een gedeelte
aan gerealiseerde functionaliteit. Het geeft een beeld van de (losse)
componenten in het framework, de relaties tussen de componenten en de
mogelijke interacties tussen deze componenten [MIL02]. Een voorbeeld is het
Model View Controller framework, zoals in Figuur 6 is te zien. Dit framework
bevat drie component die elk een eigen verantwoordelijkheid hebben.
Update Display
View
Notifications
State data
Controller
User input
Application calls
Model
Figuur 6 - Het Model - View - Controller (MVC) Framework [MIL02].
Het ontwikkelen van applicatie frameworks en componenten vormt een
geavanceerde en efficiënte manier om hergebruik te bereiken. Hogere
hergebruikpercentages, productiviteit en kwaliteit zijn mogelijk ten opzichte
van component-based hergebruik [MIL02][EZR02]. Domein engineering is de
manier om dit te bereiken. Dit is echter een tijdsconsumerend proces waarbij
een zeer goed inzicht in het domein en geavanceerde modelleringsvaardigheden noodzakelijk zijn. Om deze aanpak te realiseren is er dus een grote
investering vooraf nodig.
Bij de toepassing van hergebruik doormiddel van applicatie frameworks en
componenten zijn er hergebruikpercentages tot 80% gemeten [HAL97]. Veel
auteurs zien de toepassing van applicatie frameworks als een belangrijke
succesfactor voor hergebruik [MIL02].
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
39
3.4
Hergebruik processen
Om hergebruik van software artefacten systematisch toe te passen moeten er een
aantal processen gedefinieerd en geïnstitutionaliseerd te worden. Deze paragraaf
bespreekt deze processen.
Er zijn vier hoofdprocessen te identificeren die elk weer uit één of meerdere
subprocessen bestaan. Deze hoofdprocessen omvatten het verkrijgen (productie)
van herbruikbare artefacten, de ondersteunende processen ten behoeve van
hergebruik, het gebruik van de herbruikbare artefacten (consumptie) en het
management van hergebruik, zoals in Figuur 7 is te zien. Binnen de discipline
software engineering en hergebruik bestaat een klassiek onderscheid tussen ‘design
for reuse’, de productie van herbruikbare artefacten, en ‘design with reuse’, het
gebruik van herbruikbare artefacten bij het ontwikkelen van nieuwe software
producten.
Management van hergebruik
Plannen, zetten van doelen, budgettering, prioriteitstelling,
coordinatie en sturing
Productie
Domein engineering,
generalisatie, externe bronnen
Ondersteunende processen
Onderhoud, beheer, certificatie,
classificatie, ondersteuning
Technologische
ontwikkelingen,
toekomstige klantwensen
en lopende projecten
Product requirements
en bestaande software
Consumptie
Selecteren, analyseren,
modificeren, integreren
Producten
Figuur 7 - Processen voor systematisch hergebruik [JAC97].
3.4.1
Produceren van herbruikbare artefacten
Herbruikbare artefacten kunnen op drie manieren verkregen worden.
-
Ontwikkelen van nieuwe herbruikbare artefacten.
Re-engineeren van bestaande artefacten tot herbruikbare componenten.
Verkrijgen van herbruikbare artefacten vanuit ‘component-markets’ of
open source bronnen.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
40
Bij de eerste twee manieren is het herbruikbare artefact afkomstig vanuit een
interne bron, de derde manier is het verkrijgen van een herbruikbaar artefact uit een
externe bron. Bij de interne productie van herbruikbare artefacten staat een
organisatie naast de keuze van een bepaalde aanpak ook nog voor de keuze van het
moment waarop het herbruikbare artefact ontwikkeld wordt. Tabel 4 toont de
verschillende productiemodellen die ontstaan bij de opsplitsing tussen de manier
waarop herbruikbare artefact worden gemaakt en het moment waarop dit
plaatsvindt.
A priori
Domain analysis
A posterioiri
Generalization
Pre-Project
In-Project
Post-Project
1. Pre-project
domain analysis
2. In-project
domain analysis
3. In-project
generalization
4. Post-project generalization
5. Next-project generalization
Tabel 4 - Keuzes bij productie van herbruikbare artefacten [FIC01].
Ontwikkeling van nieuwe herbruikbare artefacten
Het ontwikkelen van herbruikbare software artefacten kan op twee momenten
plaatsvinden, vooraf en tijdens een project. Aangezien er geen bestaande artefacten
voorhanden zijn, dient er een gedegen inzicht te zijn aan wat voor functionaliteit er
binnen meerdere (toekomstige) projecten behoeften is. De theorie beschrijft vele
verschillende aanpakken voor de productie en toepassing van herbruikbare
frameworks en componenten. Hieronder staan enkele voorbeelden opgesomd.
-
-
-
-
-
-
Applicatie Family Engineering [JAC97]
Hierbij wordt er een functionele architectuur ontwikkeld voor een familie van
applicaties binnen of een productlijn. Deze architectuur is het startpunt voor de
ontwikkeling van nieuwe applicatie en artefacten binnen de familie of
productlijn.
Component System Engineering [JAC97]
Hierbij worden er herbruikbare artefacten (vooral software componenten)
ontwikkeld op basis van algemene overeenkomsten en variabiliteit binnen een
applicatie familie.
Application System Engineering [JAC97]
Bij deze aanpak worden applicaties ontwikkeld op basis van een algemene
architectuur, gebruikmakend van bestaande artefacten.
Component-Based Software Engineering [MIL02]
Het ontwikkelen van applicaties doormiddel van het koppelen van bestaande
componenten.
COTS Based Development [MIL02]
Dit is het proces waarbij applicaties worden ontwikkeld op basis van
commercieel beschikbare software componenten.
Product-Line Engineering [MIL02]
Het faciliteren van de productie van gelijke producten binnen een domein door
gebruik te maken van bestaande domein specifieke artefacten.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
41
Het gaat niet zozeer om de technologieën zelf maar om de factor die ze bijna
allemaal gemeen hebben; domein analyse en domein engineering.
Domein analyse is het verkrijgen, analyseren en modelleren van informatie over
applicaties binnen een domein, waarbij de aandacht ligt op gemeenschappelijke
factoren en oorzaken van variaties [MIL02]. Op basis van overeenkomsten en
variaties binnen de applicaties van het afgebakende domein kunnen herbruikbare
artefacten worden ontwikkeld die de elementen en relaties binnen een familie van
gerelateerde applicaties karakteriseren. Domein engineering is het gebruiken van
de domein kennis en een technische infrastructuur om effectief een familie van
applicaties binnen een bepaald domein te ontwikkelen en te onderhouden [MIL02].
Een domein kan op basis van drie aspecten onderscheiden worden:
gemeenschappelijke expertise, gemeenschappelijk ontwerp of gemeenschappelijke
markt. Deze aspecten sluiten elkaar niet uit, een ideaal domein komt op alle drie de
aspecten overeen [MIL02].
Re-engineering van bestaande artefacten
Het komt vaak voor dat herbruikbare artefacten pas worden herkend op het
moment dat het artefact weer nodig is. De transformatie naar een herbruikbaar
artefact kan plaatsvinden op twee momenten, tijdens het project of na het project.
In-project generalisatie is de aanpak waarbij ontwikkelaars tijdens het project extra
tijd en moeite investeren in het herbruikbaar maken van het artefact. Deze
artefacten worden direct in het eindproduct opgenomen maar zijn dus beschikbaar
en herbruikbaar voor andere projecten.
Bij post-project generalization wordt, nadat het project is beëindigd, gekeken welke
artefacten een hoge potentie voor hergebruik hebben. Vervolgens worden deze
verwerkt tot herbruikbare artefacten.
Next-project generalization is hetzelfde als post-project generalization, echter nu
wordt pas bij aanvang van een nieuw project besloten tot het generaliseren van
bepaalde artefacten. Een gevolg hiervan is dat er bijgehouden dient te worden
welke artefacten zich lenen voor hergebruik maar nog verwerkt moeten worden tot
een herbruikbaar artefact.
Extern verkrijgen van artefacten.
Het extern verkrijgen van herbruikbare artefacten kan worden opgesplitst naar twee
bronnen: ‘open source’6 bronnen en ‘components markets’7.
In de literatuur bestaat er geen consensus over of het kopen of extern verkrijgen
van artefacten op zichzelf hergebruik is. In deze scriptie wordt het, gezien de
definitie, wel aangemerkt als hergebruik.
6 Voorbeelden zijn: http://www.freedownloadscenter.com/Programming/ en
http://sourceforge.net/, http://www.gnu.org/fsf/fsf.html
7 Voorbeelden zijn: www.componentsource.com, www.developer.com en
http://www.internetcomponent.com.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
42
Indien een organisatie gebruik maakt van COTS producten of artefacten uit open
source bronnen moet het wel rekening houden met de support die erbij geboden
wordt. Deze situatie wijkt immers af van een software artefact dat intern wordt
beheerd. Tevens is het afhankelijk van de licenties van het herbruikbare artefact of
het wel of niet kan worden opgenomen in de repository. Het gebruiken van virtuele
artefacten vormt een oplossing [EZR02]. Dit zijn artefacten waarvan alleen de
beschrijving is opgenomen in de repository. Het artefact zelf moet nog worden
aangeschaft of gemaakt.
3.4.2
Ondersteunende processen
Voor de ondersteuning van hergebruik van software artefacten dienen er zeven
projectoverschrijdende processen geregeld te zijn.
1. Onderhoud
Zolang het herbruikbare artefact hergebruikt wordt, is onderhoud
noodzakelijk. Nieuwe technische of functionele eisen en herstel van fouten
zijn redenen voor onderhoud.
2. Configuratie Management & Versiebeheer
Configuratie managent (CM) vormt het beheer en management van de
verschillende typen en instanties van software artefacten gedurende de
levenscyclus van het software artefact. Versiebeheer is sterk verbonden
met het configuratie management aangezien het de verschillende versies
van het artefact identificeert en bijhoudt.
De systematische toepassing van hergebruik kan de eisen aan het CM
aanzienlijk vergroten. De herbruikbare artefacten worden immers niet
slechts in één systeem gebruikt maar in meerdere. De complexiteit stijgt
om twee redenen [MIL02]:
-
bij elke verandering aan een herbruikbaar artefact moet er rekening
gehouden worden met de systemen die het artefact gebruiken,
meerdere versie van het artefact moeten opgeslagen en
onderhouden worden en dienen beschikbaar te zijn.
Dit tweede punt is echter niet wenselijk op de manier zoals in Figuur 4
wordt weergegeven. De evolutie van een herbruikbaar artefact waarbij één
versie van het artefact centraal wordt beheerd, zoals in Figuur 8 is te zien,
is te prefereren. In deze situatie is de ontwikkeling van het artefact in de
hand te houden en profiteert de organisatie van het centrale onderhoud.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
43
Artefact v1.1
Artefact v1.0
Artefact v2.0
Artefact v1.2
Artefact v2.1
Artefact v3.0
Artefact v2.2
Figuur 8 - Gewenste levenscyclus van een herbruikbaar artefact
Bij white box hergebruik mogen projecten de herbruikbare software
artefact hergebruiken en aanpassen. De versie van het hergebruikende
project moet dan worden gezien als een lokale versie waar ander projecten
geen toegang toe hebben. Indien er updates of nieuwe releases uitkomen,
moet de keuze worden gemaakt of de projecten hun lokale versie
vervangen door de nieuwe versie. Deze keuze wordt gemaakt op basis van
factoren zoals budget en de noodzaak om de nieuwe versie te gebruiken.
Indien het hergebruikende project fouten tegenkomt of extra functionaliteit
toevoegt aan het herbruikbare artefact, moet dit worden teruggekoppeld
naar de beheerder van het artefact zodat deze dit eventueel kan verwerken
in een volgende release.
3. Problem en Change Management
Indien een hergebruiker een probleem of wijzigingsverzoek heeft, dan
moet hij dit kunnen indienen bij de verantwoordelijke van het herbruikbare
artefact. De beheerder van het software artefact is verantwoordelijk voor de
verdere afhandeling van het probleem of wijzigingsverzoek. In het geval
van een bug in het artefact dient dit in het onderhoud meegenomen worden,
in het geval van een wijzigingsverzoek zal de eigenaar van het artefact dit
verzoek beoordelen op wenselijkheid en noodzaak.
4. Certificatie
Certificatie is het proces waarbij wordt bevestigd dat het artefact de
beloofde functionaliteit inderdaad levert, geschikt is voor (her)gebruik en
voldoet aan eventuele andere eisen die eraan gesteld worden. Door de
herbruikbare software artefacten te certificeren kan de angst voor
kwalitatief slechte herbruikbare software artefacten grotendeels
weggenomen worden [LYN98].
Om een herbruikbaar artefact te kunnen beoordelen moeten er ook eisen
zijn waaraan het artefact moet voldoen. Deze zijn besproken in § 3.3.3.
Een meer informele manier van certificering is het gebruik van feedback en
het aantal malen dat een software artefact is hergebruikt. Gebruikers van
herbruikbare artefacten moeten de mogelijkheid hebben om vragen,
feedback of gebruikerservaringen over een specifiek artefact te melden. Op
deze manier bestaat er een vorm van terugkoppeling naar de producenten
van de herbruikbare artefacten en kunnen toekomstige gebruikers van dat
artefact zich er een beter beeld van vormen [SMI94].
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
44
5. Classificatie
Classificatie is het proces waarbij de herbruikbare artefacten worden
gerangschikt volgens een bepaald patroon. Dit wordt gedaan om de
gebruikers op een snelle en efficiënte manier de juiste herbruikbare
artefacten te laten vinden. De manier waarop een verzameling
geclassificeerd is, is vooral afhankelijk van de grote van de verzameling en
de bekendheid van de gebruikers met de inhoud [SMI94].
Voor kleine verzamelingen is het niet direct nodig om deze te classificeren,
de gebruikers zijn prima in staat de gewenste artefacten te vinden.
Er zijn verschillende classificatieschema’s beschikbaar, deze zullen hier
echter niet besproken worden.
6. Ondersteuning
Voor hergebruikers is het belangrijk dat er ondersteuning bestaat bij het
hergebruiken van software artefacten. Nu is dit niet noodzakelijk voor alle
herbruikbare software artefacten, maar voor complexe of grote
herbruikbare software artefacten is dit wel een pre.
7. Informatieverstrekking m.b.t. (nieuwe) artefacten & nieuwe versies.
Bekendheid van de beschikbare herbruikbare artefacten is een belangrijke
voorwaarde voor hergebruik. Het is een optie potentieel geïnteresseerden te
informeren over de beschikbaarheid van nieuwe herbruikbare artefacten.
Hetzelfde geldt voor nieuwe versies van bestaande herbruikbare artefacten
[EZR02].
3.4.3
Consumeren van herbruikbare artefacten
Om tijdens het ontwikkelproces gebruik te kunnen maken van de herbruikbare
artefacten, moeten nieuwe processen gedefinieerd en geïmplementeerd worden.
Onafhankelijk van het herbruikbare artefact bestaan er vier algemene stappen die
het verkrijgen en verwerken van herbruikbare artefacten omvatten [MIL02].
1. Selectie
Bij het selecteren van herbruikbare artefacten wordt er gekeken naar
artefacten die mogelijk aan de behoefte van de hergebruiker voldoen.
Hierbij wordt er gelet op functionele en technische aspecten die van belang
zijn. Om deze stap uit te kunnen voeren is een centrale opslagplaats
gewenst waar de herbruikbare artefacten te vinden zijn. Deze fase levert
mogelijk meerdere geschikte herbruikbare artefacten op.
2. Analyse
Om een specifieke keuze te kunnen maken uit de geselecteerde artefacten
dienen deze herbruikbare artefacten geanalyseerd en geëvalueerd te
worden. Hierbij wordt gekeken of het artefact daadwerkelijk aan de
functionele eisen van de gebruiker voldoet, in welke mate er aanpassingen
nodig zijn en of er aan eventuele niet-functionele eisen wordt voldaan.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
45
Indien het software artefact voldoet aan de wensen wordt op basis van een
kosten/baten analyse besloten of het daadwerkelijk hergebruikt wordt.
3. Modificatie
In deze stap wordt het artefact aangepast aan de wensen van de gebruiker.
De mate van aanpassing is afhankelijk van het type hergebruik (black box
of white box) en de mate waarin het voldoet aan de functionele eisen van
de gebruiker.
4. Integratie
Nadat het artefact geselecteerd en eventueel aangepast is, moet het nog
geïntegreerd worden in het nieuwe systeem. Een essentieel onderdeel
hierbij is het testen of het geïntegreerde artefact daadwerkelijk voldoet aan
de eisen en of het systeem na de integratie nog betrouwbaar is.
Aangezien hergebruik een sterke invloed heeft op de kosten en ontwikkelduur van
een applicatie moet er al in een vroeg stadium rekening mee worden gehouden.
Voor hergebruik geldt dat hoe eerder het in het softwareontwikkelproces wordt
meegenomen hoe groter de voordelen zijn.
3.4.4
Management van hergebruik
Deze paragraaf licht een aantal aspecten en procedures toe waarbij management
van hergebruik van belang is.
1. Keuze voor hergebruik
Management van hergebruik begint al bij de keuze voor hergebruik. De
keuze voor hergebruik en de manier waarop een organisatie hergebruik
toepast zijn afhankelijk van verschillende factoren [EZR02]. Bestaat er
bijvoorbeeld vanuit de markt een noodzaak om te hergebruiken, is de
organisatie er geschikt voor en zijn er voldoende mogelijkheden om te
hergebruiken. Een organisatie die hergebruik wil gaan toepassen zal ook de
afweging moeten maken tussen de mogelijke opbrengsten en kosten van
hergebruik.
Indien een organisatie ervoor kiest om op een systematisch manier software her te
gebruiken moeten de drie belangrijke processen gemanaged worden, te weten:
productie, consumptie en de ondersteunende processen.
2. Management van de productie van herbruikbare artefacten
Er is sturing nodig om ervoor te zorgen dat de juiste herbruikbare
artefacten daadwerkelijk ontwikkeld worden. Het mag niet voorkomen dat
verschillende projecten dezelfde of soortgelijke herbruikbare artefacten aan
het ontwikkelen zijn. Om dit te kunnen realiseren is inzicht nodig in de
projecten en de verzameling herbruikbare artefacten.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
46
Een organisatie moet zich realiseren dat de grote van de verzameling
herbruikbare artefacten in verhouding moet staan met de kansen op
hergebruik. Een organisatie waar jaarlijks zes software projecten worden
gestart heeft minder profijt van een zeer uitgebreide verzameling
herbruikbare artefacten dan een organisatie waar jaarlijks zestig software
projecten starten.
3. Management van de consumptie van herbruikbare artefacten
Bij de consumptie van herbruikbare artefacten geldt hetzelfde als bij de
productie. Des te kleiner het aantal kansen voor hergebruik des te strikter
de sturing hierin moet zijn. Dit kan doormiddel van procedures.
Bijvoorbeeld door hergebruik te verplichten of door projecten een voorstel
te laten doen over wat ze willen gaan hergebruiken en dat deze voorstellen
door een derde partij worden beoordeeld.
4. Ondersteuning en beheer
Voor deze processen dienen ook een aantal procedures vastgelegd te
worden.
- Procedure voor Configuratie Management en Versiebeheer
Bijvoorbeeld de IEEE 828-1998 standaard.
- Procedure voor Problem en Change Management
- Procedure voor Certificatie van herbruikbare artefacten
Bijvoorbeeld de IEEE 1420.1a-1996 standaard. Dit beschrijft een
‘Asset Certification Framework’ voor software hergebruik.
- Procedure voor Intellectueel Eigendom voor herbruikbare artefacten
Bijvoorbeeld de IEEE 1420.1b-1999 standaard. Hierin wordt een
framework voor ‘Intellectuel Property rights’ gegeven.
Niet elke procedure die in deze paragraaf is beschreven zal nieuw zijn voor een
organisatie. De meeste organisaties hebben geformaliseerde procedures of
werkwijzen opgesteld voor bijvoorbeeld Configuratie Management en
Versiebeheer. Voor de andere onderwerpen zal een organisatie wel procedures
moeten opstellen om de verschillende processen te standaardiseren en herhaalbaar
te maken. Per procedure moet een organisatie vaststellen welke aspecten erin
verwerkt worden, wie er betrokken zijn en welke verantwoordelijkheden er zijn.
3.4.5
Afhankelijkheid hergebruik van Process Maturity
De manier waarop een organisatie hergebruik van software kan vormgegeven, is
deels afhankelijk van de volwassenheid en professionaliteit van de huidige
softwareontwikkelprocessen. Indien deze processen niet gedefinieerd zijn, is het
zeer moeilijk om een planmatige en georganiseerde vorm van hergebruik van
software artefacten te realiseren. Er bestaat dus een relatie tussen de volwassenheid
van het normale softwareontwikkelproces en de reële na te streven volwassenheid
van hergebruik van software artefacten. Figuur 9 geeft deze situatie weer
[VAD98].
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
47
Uit Figuur 9 kunnen twee dingen afgeleid worden: ten eerste dat er verschillende
niveaus van hergebruik te onderscheiden zijn en ten tweede dat deze niveaus
gekoppeld zijn aan het niveau van het normale softwareontwikkelproces.
Een organisatie dient zich te realiseren dat het maximaal haalbare reële niveau van
hergebruik gerelateerd is aan de volwassenheid van het huidige
softwareontwikkelproces.
CMM Stage
Initial
Ad-Hoc
Repeatable
Defined
Managed
Coordinated
Optimized
Planned
Reuse Management Stage
Figuur 9 - Relatie tussen CMM-niveau en Reuse Management niveau [VAD98]
Vadapalli en Nazareth onderscheiden drie niveaus van hergebruik. Kolton en
Hudson [KOL91] onderscheiden hier vijf niveaus waarbij hun model is afgeleid
van het CMM, zie voor het model Bijlage B. De vijf niveaus van volwassenheid
waar dit model een onderscheid naar maakt, definiëren de toepassing van
hergebruik van software artefacten van chaotisch tot planmatig en diep ingeworteld
in de manier van werken binnen een organisatie. Hierbij wordt naar verschillende
aspecten gekeken, zie Tabel 5.
Dimensie
Betekenis
Cultuur
Hoe staat de bedrijfscultuur t.o.v. hergebruik? Wordt hergebruikt afgeraden, beloond of
is het de manier van werken?
Wordt er structureel rekening gehouden met hergebruik? Of is het puur toeval dat het
gebeurt?
Wordt hergebruik alleen door individuele software engineers uitgevoerd, gebeurt het
over afdelingen of is het bedrijfswijd?
Wie zorgen ervoor dat hergebruik plaatsvindt? Zijn dit ontwikkelaars, een werkgroep of
is er ook vanuit het management betrokkenheid?
Waar komt hergebruik het proces in en in hoeverre zijn de processen gestandaardiseerd?
In hoeverre is de verzameling gestructureerd? Helemaal niet of langs productlijnen of
wordt er zelfs op basis van missende delen in de inventaris ontwikkeld?
In welke mate is de verzameling gestructureerd en geclassificeerd?
In hoeverre wordt hergebruik ondersteund d.m.v. tools? Helemaal niet, via enkele tools
of is er een electronische bibliotheek beschikbaar?
In welke mate wordt hergebruik gekwantificeerd? Helemaal niet of zeer drastisch om de
impact van hergebruik te volgen en daarop te sturen?
Vormen rechtsmatige, contractuele of financiële aspecten een drempel om te
hergebruiken of zijn er hier oplossingen voor ontwikkeld m.b.t. hergebruik?
Planning
Betrokkenheid
Driver
Proces
Inventaris
Classificatie
Technologische
ondersteuning
Metingen
Contractuele en
verrekeningsoverwegingen
Tabel 5 - Dimensies van volwassenheid van het Reuse Maturity Framework.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
48
3.5
Hergebruik organisatie
Naast veranderingen op procesniveau zijn er ook veranderingen op organisatie
niveau. Ten eerste de organisatie rondom de productie en consumptie van de
herbruikbare artefacten en ten tweede de organisatie rondom de ondersteuning van
hergebruik. Deze paragraaf bespreekt de verschillende rollen en stakeholders bij
hergebruik. Tevens wordt er aandacht besteed aan organisatiemodellen en
verrekeningsmodellen voor hergebruik.
3.5.1
Nieuwe Rollen voor hergebruik
In §3.4 zijn de verschillende processen voor hergebruik van software artefacten
besproken. Hier worden de rollen aan deze taken gekoppeld.
Producent
Deze persoon is verantwoordelijk voor het ontwikkelen van herbruikbare
artefacten.
Consument
Deze persoon of groep personen is verantwoordelijk voor het ontwerpen en
ontwikkelen van nieuwe software producten met herbruikbare artefacten.
Verantwoordelijke(n)
Deze persoon is verantwoordelijk voor verschillende taken zoals het onderhouden
van de herbruikbare artefacten, het configuratiemanagement en Problem en Change
management. De persoon in deze rol is tevens verantwoordelijk voor de
ondersteuning bij het hergebruiken van herbruikbare artefacten door hergebruikers.
Deze rol kan worden uitgevoerd door de producent van het artefact, dit is echter
niet noodzakelijk.
Repository Manager
Deze persoon is verantwoordelijk voor het beheer van de herbruikbare artefacten
die in de repository zijn beschreven en opgeslagen. Hij zorgt ervoor dat het gebruik
van de repository nuttig en efficiënt blijft. Hij voegt de nieuwe herbruikbare
artefacten toe nadat deze goedgekeurd of gecertificeerd zijn.
Hergebruik Commissie
Deze groep personen heeft een faciliterende rol ten opzichte van de producenten en
consumenten. Deze groep is verantwoordelijk voor verschillende taken.
- Aanspreekpunt voor hergebruikers. Indien er vanuit projecten vragen zijn
of ondersteuning nodig is, voert de hergebruikgroep deze taak uit of
delegeert ze deze naar de verantwoordelijke van het betreffende artefact.
- Opstellen van procedures voor het certificeren van de herbruikbare
artefacten voordat ze in de repository worden opgenomen en het
certificeren van de herbruikbare artefacten zelf.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
49
- Het verzorgen van trainingen voor de software engineers en project
managers met oog op hergebruik.
- Onderzoek naar nieuwe herbruikbare artefacten en het begeleiden van
projecten in wat er mogelijk hergebruikt kan worden.
Hergebruik manager
Deze persoon is verantwoordelijk voor de verdere sturing en uitvoering van het
hergebruik programma. Hij is ook sterk betrokken bij de hergebruik commissie. Bij
voorkeur heeft deze persoon een hogere positie in de organisatie en ook technisch
inzicht in datgene wat er ontwikkeld wordt. De hergebruik manager is
verantwoordelijk voor een aantal taken.
- Het zetten van doelstellingen.
- Het sturen van zowel de producenten als de consumenten.
- Het stellen van prioriteiten.
- Het coördineren van hergebruik activiteiten binnen de betrokken
organisatie.
- Het bepalen van metrics/metingen om de resultaten van hergebruik vast te
kunnen stellen.
- Het promoten en verspreiden van een hergebruik cultuur.
De hierboven besproken rollen zijn veelal nieuw voor een organisatie. Er zijn
natuurlijk ook verschillende stakeholders in een organisatie die beïnvloed worden
door hergebruik van software. Bijvoorbeeld de projectmanager die al vroeg in zijn
project rekening moet houden met hergebruik bestaande software artefacten en
mogelijk binnen zijn project herbruikbare artefacten moet gaan produceren. De
software engineers die herbruikbare artefacten moeten gaan ontwikkelen en
hergebruiken en het management die de procedures en standaarden moet
vaststellen en de projecten moet gaan sturen op hergebruik.
3.5.2
Sturing
Het systematisch hergebruiken van software artefacten vindt niet uit zichzelf
plaats. Enige vorm van sturing is nodig om dit te realiseren. Indien een organisatie
de productie van herbruikbare artefacten neerlegt bij de lopende projecten, kan dit
een heikel punt zijn. De projecten moeten immers tijd en geld vrijmaken voor het
produceren van herbruikbare artefacten terwijl zij daar zelf niet direct voordeel bij
hebben.
Bij ‘design with reuse’ is dit probleem minder aanwezig. De projecten profiteren
immers van de voordelen van het hergebruiken van de software artefacten. In de
praktijk blijkt echter dat sturing ook hier belangrijk is. Om uiteenlopende redenen,
veelal weerstand of beperkte betrokkenheid vanuit de software engineers of
projectmanagers, hergebruiken de projecten niet of minder dan gewenst of
mogelijk zou zijn.
Sturing kan op verschillende manieren beoefend worden. Tabel 6 vat de
verschillende mogelijkheden samen.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
50
Manieren van Sturing
Directief
Rationeelempirische
strategie
Normatiefreëducatieve
strategie
Facilitaire
strategie
Dit is een top-down op macht en dwang gebaseerde strategie. Met
behulp van de machtspositie worden veranderingen of werkzaamheden
afgedwongen. Deze strategie is vaak te beperkt om op het niveau van
individuen te werken.
Bij deze strategie worden mensen via rationele communicatie en
voorlichting ertoe bewogen de veranderingen of werkzaamheden te
accepteren.
Gedrag van mensen komt voort uit hun sociaal-culturele normenstelsel.
Het is de taak van de leidinggevende om de medewerkers te stimuleren
om een zo groot mogelijke betrokkenheid bij de verandering of
werkzaamheden te realiseren.
Het management zorgt voor een invulling van de randvoorwaarden
zodat de verandering of werkzaamheden uitgevoerd kunnen worden. Dit
omvat bijvoorbeeld het zorgen voor financiële of fysieke faciliteiten.
Tabel 6 - Verschillende manieren van sturing [THI02].
De theorie spreekt ook veel over het belonen van hergebruik. Dit kan dan
financieel, via status of via promotie gebeuren [MCC95]. In de praktijk blijkt
echter dat financiële beloningsstrategieën voor het produceren en hergebruiken van
herbruikbare artefacten complex en fraudegevoelig zijn [DOU97].
Er zijn ook niveaus van sturing te onderscheiden. Het model in Tabel 7 is
gebaseerd op het model van architectuurdenken in een organisatie [NOL00]. Een
architectuur kan in dit model op verscheidene manieren geïnterpreteerd worden.
Het kan de huidige of gewenste organisatie beschrijven, maar ook een architectuur
zijn voor ICT-voorzieningen [THI02]. In de context van hergebruik van software
artefacten is het hier ook toepasbaar, met nadruk op de sturing van de hergebruik
activiteiten.
Het model van architectuurdenken beschrijft vijf niveaus met de aspecten sturing,
modellen, de rol van de architect, het proces en het product. In de context van
hergebruik van software artefacten beschrijft het model in Tabel 7 wederom de vijf
niveaus maar nu toegepast op drie aspecten:
-
-
-
Sturing
Dit aspect beschrijft hoe de ‘design for reuse’ en ‘design with reuse’
activiteiten gestuurd worden.
Rol van de hergebruikmanager
Dit aspect beschrijft wat de verantwoordelijkheid is van de
hergebruikmanager.
Proces
Dit aspect beschrijft op welk niveau de processen voor hergebruik zijn
vormgegeven.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
51
Sturing
Rol hergebruikmanager
Niveau 1 Geen
Niveau 2 Sturing op mensen
N.v.t.
Rol toegekend
Niveau 3 Sturing op proces
Verantwoordelijk voor proces
Niveau 4 Sturing op basis van
resultaten en
alignment
Niveau 5 Sturing op continue
verbetering
Verantwoordelijk voor
resultaten
Initieert innovaties en
verbeteringen
Proces
Niet gedefinieerd.
Proces is gedefinieerd
per project of domein
Afstemming tussen
projecten en domeinen
Geïntegreerd proces
centraal gecoördineerd
Geoptimaliseerd proces
Tabel 7 - Niveaus van sturing [NOL00].
Deze drie factoren geven samen een beeld van de manier waarop de
hergebruikactiviteiten gestuurd kunnen worden en wat de scope van deze sturing is.
De vijf niveaus worden hieronder kort toegelicht.
- Niveau 1
Er is nog geen proces gedefinieerd voor hergebruik van software artefacten.
Hergebruik vindt op ad hoc basis plaats zonder enige vorm van sturing. Het is
een initiatief van individuen.
- Niveau 2
Er zijn processen gedefinieerd per project of domein. De software engineers
hebben hierin een rol gekregen met betrekking tot hergebruik. Op basis van
deze rol vindt er ook sturing plaats. Dit is een eerste stap naar een
systematische vorm van hergebruik.
- Niveau 3
De processen voor hergebruik van software artefacten worden afgestemd
tussen de verschillende projecten en domeinen. De hergebruikmanager stuurt
op basis van deze processen.
- Niveau 4
Hergebruik is geïntegreerd in de normale processen en wordt uniform
uitgevoerd. De processen worden centraal gecoördineerd en de
hergebruikmanager is verantwoordelijk voor de resultaten.
- Niveau 5
Hergebruik is de manier waarop er gewerkt dient te worden. De sturing is
gericht op continue verbetering van de hergebruikactiviteiten en resultaten. De
hergebruikmanager initieert deze innovaties en verbeteringen die leiden tot een
geoptimaliseerd proces.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
52
3.5.3
Inrichting
Een organisatie moet aangepast worden om de nieuwe processen voor hergebruik
te verankeren. Vooral bij voor de productie, ondersteuning en sturingsprocessen
zijn er wijzigingen mogelijk. De keuze bestaat uit twee uitersten: het integreren in
de bestaande structuur of het creëren van een aparte losstaande eenheid. In de
organisatie voor hergebruik dient er met de vier processen rekening gehouden te
worden, zie Figuur 10.
Management
Productie
Ondersteuning
Consumptie
Figuur 10 - Onderdelen binnen een organisatiestructuur voor hergebruik.
De productie van herbruikbare artefacten kan zowel geïntegreerd worden in de
projecten als worden uitgevoerd door een aparte eenheid. Beide opties hebben
voor- en nadelen [EZR02]. Indien de productie wordt opgenomen in de bestaande
projecten zijn er weinig organisatorische veranderingen nodig. Er bestaat echter
wel een risico dat de korte termijn visie en druk binnen het project het belang van
hergebruik overheersen. Een projectleider zal immers niet graag de productie van
herbruikbare artefacten op zich nemen aangezien het geen bijdrage levert aan zijn
project en wel ten kosten gaat van zijn budget. Indien er een losstaande eenheid
verantwoordelijk is voor de productie van herbruikbare artefacten, zijn de rollen
duidelijk gescheiden en worden vaardigheden gebundeld. Sterke coördinatie over
de projecten is dan wel nodig.
De ondersteunende processen voor hergebruik kunnen niet opgenomen worden in
de projecten. Indien een project afloopt zouden deze processen immers eindigen en
dit kan niet de bedoeling zijn. Er is hiervoor dus een organisatorische eenheid
nodig die onafhankelijk is van de projecten waarin het is ontwikkeld of wordt
gebruikt.
Er zijn verschillende manieren waarop de productie- en ondersteunende processen
ingericht kunnen worden. Bij Hewlett-Packard (HP) bleek dat een succesvol
hergebruikprogramma geïntegreerd moet worden in de cultuur van de bestaande
organisatie structuur [FAF94].
Op basis van dit onderzoek heeft Fafchamps vier modellen opgesteld die de relatie
tussen de producenten en de consumenten beschrijven [FAF94]. Enkele van deze
modellen kunnen ook gebruikt worden voor de organisatie van de ondersteuning en
het beheer van de herbruikbare artefacten.
1. Het Lone Producer model.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
53
2. Het Nested Producer model.
3. Het Pool Producer model.
4. Het Team Producer model.
Fafschamps raadt bij elk model aan het hergebruik van software artefacten te
verplichten [FAF94]. Tevens is het aan te raden een structuur te kiezen die het
beste bij de eigen organisatie past en deze ook naar de eigen organisatie te vertalen.
1. Lone Producer Model
De ‘lone producer’ levert hergebruik diensten aan twee of meer projectteams. Deze
diensten kunnen het ontwerpen, ontwikkelen of onderhouden van herbruikbare
artefacten omvatten. De rol van de ‘lone producer’ voor de projectteams, de
consumenten, kan variëren van het afhandelen van wijzigingsverzoeken tot het
helpen in een project tijdens verschillende fasen van het ontwikkeltraject. De ‘lone
producer’ speelt in deze structuur dus de rol van producent en verantwoordelijke
voor een aantal herbruikbare artefact. De ‘lone producer’ rapporteert primair aan de
level 2 manager, net zoals de projectmanagers. De ‘lone producer’ communiceert
tevens met de projectmanagers over wat zij nodig hebben en over
wijzigingsverzoeken die vanuit de projecten komen.
Level 2
Manager
Legenda
Project
Manager
Project
Manager
Primaire lijn van
verantwoording
Secundaire lijn van
verantwoording
Lone
producer
Project
Team A
Project
Team B
Figuur 11 - Lone Producer structuur [FAF94][MIL02].
Afwegingen bij de Lone Producer structuur
Voordelen
Nadelen
- Brede kennisbasis bij ‘lone producer’ door deelname aan verschillende projecten.
- Duidelijk aanspreekpunt voor de gebruikers van de herbruikbare artefacten.
- Duidelijk inzicht in de kosten van het produceren en onderhouden van
herbruikbare artefacten.
- Overbelasting qua communicatie, de ‘lone producer’ moet aan verschillende
managers rapporteren.
- Zware belasting op de ‘lone producer’ indien deze sterk betrokken wordt bij
verschillende projecten.
- Onduidelijke prioriteitstelling tussen verschillende projecten, het is onduidelijk
wat er gebeurt bij conflicterende wijzigingvoorstellen.
- Geen sturing op hergebruik, er is geen geformaliseerde communicatie tussen de
verschillende ‘lone producers’. Vooral in grote organisatie met veel grote
herbruikbare artefacten kan dit een probleem vormen omdat de ‘lone producers’
onafhankelijk van elkaar opereren.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
54
Aanbevelingen
- Specificeer het proces van veranderverzoeken (change-requests).
- Specificeer een formele communicatiestructuur, zowel tussen de projectmanagers
en de ‘lone producers’ als tussen de ‘lone producers’ onderling.
- Zorg voor een persoon of groep die de projecten begeleidt bij het bepalen wat er
hergebruikt kan worden. Deze entiteit kan tevens de coördinatie of sturing van de
‘lone producers’ op zich nemen.
- Moedig informele interactie tussen de projectteams en de ‘lone producer’ aan.
Door zijn afgezonderde positie kan de ‘lone producer’ snel geïsoleerd raken.
Tabel 8 - Afwegingen bij de Lone Producer structuur.
Wanneer geschikt
Deze structuur is geschikt wanneer er slechts een beperkt aantal grote herbruikbare
artefacten zijn. De ‘lone producer’ heeft een goed inzicht in deze artefacten en kan
de verschillende projecten goed ondersteunen bij het gebruik hiervan.
2. Nested Producer Model
Met de ‘nested producer’ structuur wordt getracht de zwakte van de ‘lone
producer’ te overkomen door aan elk project een producent toe te kennen. In deze
structuur is de kans dus kleiner dat er sprake is van overbelasting qua werkdruk of
communicatie. Er is echter wel een sterkere sturing van de ‘nested producer’ nodig
omdat deze nu voor één project werkt. De ‘nested producer’ rapporteert hierdoor
zowel aan de hergebruikmanager als aan zijn projectmanager. Dit kan
conflicterende eisen opleveren. Zowel productie als ondersteuning zijn hier
geïntegreerd in de normale processen doordat de ‘nested producer’ deel uitmaakt
van een project.
Level 2
Manager
Project
Manager
Project
Manager
Project
Team A
Project
Team B
Hergebruik
manager
Nested
Producer A
Nested
Producer B
Figuur 12 - Nested Producer structuur [FAF94][MIL02].
Afwegingen bij de Nested Producer structuur
Voordelen
Nadelen
- De ‘nested-producer’ hoort bij één specifiek projectteam, de projectteams
hebben op deze manier kennis van de herbruikbare artefacten.
- Beperkte verandering in de organisatiestructuur.
- Centrale sturing van de ‘nested producers’ d.m.v. de hergebruikmanager.
- Dubbele verantwoording, de ‘nested producer’ moet zowel aan de
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
55
-
-
Aanbevelingen
-
hergebruikmanager als aan de projectmanager verantwoording afleggen.
De prioriteiten van het lopende project kunnen boven de prioriteiten van
hergebruik komen te liggen waardoor hergebruikbudget en resources worden
omgeleid naar het project.
Gebrek aan macht van de hergebruik manager. Onbekend wat zijn positie is
t.o.v. de projectmanagers en de level 2 managers.
Beperkte kennis bij de ‘nested-producers’ van de andere projecten en van de
verschillende herbruikbare artefacten. Vooral indien er meerdere complexe
herbruikbare artefacten zijn is het een kostbare aangelegenheid om alle ‘nestedproducers’ met alle herbruikbare artefacten bekend te laten worden.
Leg vast wat de positie is van de hergebruikmanager ten opzichte van de
projectmanager.
De hergebruikmanager dient een goed inzicht te hebben in de lopende en
toekomstige projecten. Op deze manier kan hij kansen voor hergebruik
identificeren en de ‘nested producers’ op basis hiervan sturen. Hiervoor is het
belangrijk dat er ook communicatie is tussen de projectmanagers en de
hergebruikmanager.
Tabel 9 - Afwegingen bij de Nested Producer structuur.
Wanneer geschikt
Binnen HP is deze variant ongeschikt bevonden. Het grootste probleem met dit
model bij HP was het gebrek aan macht van de hergebruik manager. Deze moet
kunnen bepalen wat de ‘nested producer’ doet.
3. Pool Producer
In deze structuur combineren twee projectteams hun hergebruikspecialisten. Ze
werken samen aan de productie van herbruikbare artefacten en delen deze ook. In
deze structuur zijn productie en ondersteuning wederom geïntegreerd in de normale
processen. Er vindt geen sturing van buitenaf plaats, de projecten bepalen in
onderling overleg welke artefacten hergebruikt kunnen worden. De scope van
hergebruik blijft dus ook beperkt tussen datgene wat er binnen die twee projecten
beschikbaar is.
Level 2
Manager
Project
Manager
Project
Manager
Project
Manager
Project
Manager
Project
Team A
Project
Team B
Project
Team C
Project
Team D
Pool Producers
Figuur 13 - Pool Producer structuur [FAF94][MIL02].
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
56
Afwegingen bij de Pool Producer structuur
Voordelen
Nadelen
Aanbevelingen
- Geen veranderingen in de organisatiestructuur nodig.
- Kosten en baten voor hergebruik worden op een natuurlijke wijze verrekend
binnen de projecten.
- Overbelasting qua communicatie indien er teveel projecten in een dergelijke
constructie samenwerken.
- Kans op conflicten en problemenlast bij oude conflicten.
- Verschillende prioriteiten tussen de projecten kunnen tot conflicten leiden.
- Beperking van hergebruik tot de kansen hiertoe binnen een dergelijk
samenwerkingsverband. Verder worden de ontwikkelde artefacten vaak binnen
de betrokken projecten gehouden. De scope is dus zeer beperkt.
- Conflicten als gevolg van een oneerlijke verdeling van de baten en lasten van
hergebruik.
- Koppel maximaal 3 projecten.
- Formaliseer de communicatiestructuren.
- Verzeker snelle respons op wijzigingsverzoeken.
- Balanceer de workload over de betrokken projecten.
- Stel de binnen de projecten ontwikkelde herbruikbare artefacten ook buiten dit
samenwerkingsverband beschikbaar.
Tabel 10 - Afwegingen bij de Pool Producer structuur.
Wanneer geschikt
Aangezien deze structuur geen verandering nodig heeft in de bestaande
organisatiestructuur lijkt het ideaal als een bottom-up aanpak voor hergebruik.
Deze structuur is vooral geschikt bij een hergebruikprogramma met een beperkte
scope en doelstelling, aangezien het resultaat beperkt blijft tot het delen van enkele
gemeenschappelijke artefacten. Deze aanpak is niet geschikt voor een langdurige
hergebruikstrategie. Tevens is er door de losse structuur tussen de projecten geen
duidelijke afbakening van verantwoordelijkheden.
4. Team Producer
Deze opzet voorziet in een apart doorlopend project (team) voor de productie en
ondersteuning met betrekking tot herbruikbare artefacten. Productie en
ondersteuning zijn in deze structuur dus expliciet gescheiden van de gebruikers van
deze herbruikbare artefacten. De hergebruik manager is verantwoordelijk voor de
sturing van dit team. De productie vindt hier plaats op basis van domein analyse en
naar aanleiding van wensen van de projectteams. De hergebruik manager
beoordeelt deze wensen. Hierbij wordt gekeken of er voldoende algemeen belang is
of dat het slechts ten behoeve van één specifiek project is. Deze structuur maakt
tevens een directe verrekening mogelijk en propageert een marktwerking tussen dit
producerende team en de andere projectteams. Zie Figuur 14 en Tabel 11 voor de
structuur en afwegingen bij dit model.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
57
Level 2
Manager
Project
Manager
Hergebruik
Manager
Project
Manager
Project
Team A
Team
Producenten
Project
Team B
Figuur 14 - Team Producer structuur [FAF94][MIL02].
Afwegingen bij de Pool Producer structuur
Voordelen
Nadelen
Aanbevelingen
- Eén manager die puur is toegewijd aan hergebruik.
- Controle over hergebruikbudget en inzicht in de kosten.
- Brede kennisbasis over de verschillende projecten en goed inzicht in
mogelijkheden voor hergebruik.
- Bundeling van kennis om adequaat op de verzoeken van de projectteams te
kunnen reageren.
- Door het centraliseren van de productie en onderhoud is sturing eenvoudiger.
Qua ‘design with reuse’ is het mogelijk dat de hergebruik manager in overleg
met de projectmanager aan het begin van een project bepaalt wat er wel of niet
hergebruikt kan worden.
- Het risico bestaat dat de producenten een te goede oplossing willen creëren die
voorbij gaat aan de problemen van de projectteams.
- Indien er teveel herbruikbare artefacten zijn, worden de producenten teveel bezig
gehouden met onderhoud daarvan.
- Er is veel communicatie nodig met de projectteams.
- Houd de focus op consumentgeoriënteerde productie! Zorg ervoor dat de
productie ook overeenkomt met de behoefte van de projectteams.
- Definieer duidelijke communicatie strategieën. Communicatie met de
projectteams (de klanten) is essentieel, aangezien ook op basis hiervan
herbruikbare artefacten worden geproduceerd.
- Lever complete documentatie bij de herbruikbare artefacten die worden
aangeboden.
- Rouleer de mensen. Dat wil zeggen, rouleer de producer over de projecten en
laat nieuwe mensen in het producerteam plaatsnemen. Op deze manier wordt
hergebruik verankerd onder de software engineers en wordt de algemene kennis
van de herbruikbare artefacten vergroot.
Tabel 11 - Afwegingen bij de Team Producer structuur.
Wanneer geschikt
Binnen HP is dit model het meest succesvol. Het is een organisatiemodel dat
geschikt is voor een lange termijn strategie. Dit model is ook zeer geschikt voor
organisaties met specifieke productfamilies of productlijnen. Indien de organisatie
en het potentieel voor hergebruik binnen een domein groot genoeg zijn, kan ervoor
worden gekozen om aparte teams op te zetten voor bepaalde domeinen.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
58
3.5.4
Verrekening
De projecten, die gebruik maken van de herbruikbare artefacten, profiteren hier op
twee manieren van: het scheelt qua tijd en kosten. De productie van herbruikbare
artefacten, de ondersteunende processen en de sturingsactiviteiten moeten vanuit
deze opbrengsten gedekt worden, is dit niet mogelijk dan is hergebruik financieel
gezien ook niet aantrekkelijk.
Er zijn een aantal methoden om de kosten voor hergebruikt te verrekenen. Deze
verrekeningsschema’s kunnen opgedeeld worden naar het direct of indirect
verrekenen. Waar er in een normale ontwikkelomgeving (zonder hergebruik) een
directe relatie bestaat tussen de geproduceerde software en de activiteiten die nodig
waren om dit te realiseren, is dit bij hergebruik niet het geval. Tevens moet er
rekening worden gehouden met het feit dat de kosten van iets herbruikbaars over
meerdere projecten verrekend dienen te worden terwijl vooraf onbekend is hoeveel
projecten dit zijn [FIC01].
Bij het direct verrekenen is het noodzakelijk dat er een directe relatie bestaat tussen
de gemaakte kosten en de geleverde dienst. Bij indirecte verrekening is dit niet het
geval. Of de kosten direct te relateren zijn aan de geleverde dienst is afhankelijk
van de manier waarop de productie, sturing en ondersteuning zijn georganiseerd en
de inzichtelijkheid in de daadwerkelijk gemaakte kosten. Er zijn drie manieren om
de kosten van hergebruik te verrekenen [FIC01]:
1. Traditional overhead funding
Deze methode rekent de kosten voor hergebruik als overhead. Dit houdt in
dat kosten die bijvoorbeeld zijn gemaakt voor het produceren en beheren
van de herbruikbare artefacten uit één pot worden betaald. Dit potje moet
echter ook gevuld worden. Het is een mogelijkheid om via een vast of
variabel bedrag de projecten hieraan bij te laten dragen. Bij deze methode
betalen projecten, en dus de klanten, altijd impliciet voor hergebruik.
2 Tax funding
Deze methode probeert de projecten te laten betalen voor het hergebruik
wat ze toepassen, bij wijze van spreken een hergebruikbelasting. Er is
echter geen mogelijkheid om de gemaakte ´hergebruikkosten´ binnen
project A direct aan project B door te berekenen omdat dit inzicht vaak
ontbreekt of variabel is. Deze methode lost dit op door een percentage van
het budget of de opbrengsten van hergebruik in het hergebruikende project
af te staan. Bij deze methode worden de kosten voor hergebruik dus alleen
doorberekend aan de projecten die daadwerkelijk hergebruiken. Het nadeel
van de methode is dat er een situatie kan ontstaan waarbij projecten
verschillende bedragen gaan betalen voor dezelfde dienst of herbruikbare
artefacten.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
59
3 Payments for components and services
Deze optie kan worden toegepast indien er een direct verband bestaat
tussen de gemaakte kosten en de geleverde dienst. De projectteams die
gebruik maken van herbruikbare artefacten en services hieromheen (extra
functionaliteit of ondersteuning bij gebruik) betalen hier voor. Deze aanpak
kan alleen gebruikt worden in situaties waar dit directe verband bestaat.
Voor indirecte kosten zoals onderhoud en beheer dient een andere manier
gehanteerd te worden.
De keuze voor een bepaalde manier van verrekenen is afhankelijk van de inrichting
van de hergebruik organisatie. Zo kan bij de team producer structuur een
betalingsmethode als payments for components and services goed werken. Deze
methode zou bij een structuur waar de producenten in de projectteams zitten
onlogisch zijn omdat de kosten niet direct te relateren zijn aan andere projecten.
3.5.5
Tools
Er zijn verschillende processen die met tools ondersteund kunnen worden. In
§ 3.4.2 zijn deze processen besproken. Dit waren onder andere distributie,
configuratie management & versiebeheer en de informatievoorziening rondom de
herbruikbare software artefacten.
Een belangrijke tool voor hergebruik is een repository, dit is een centrale
opslagplaats voor de herbruikbare artefacten. Een repository kan een aantal
belangrijke processen en functies ondersteunen. Ten eerste creëert het de
noodzakelijke link tussen de productie van herbruikbare artefacten en de
consumptie hiervan. Het vormt een bekende locatie waar de producenten van
herbruikbare artefacten bereikt kunnen worden. Ten tweede vergroot het de kans
dat ontwikkelaars een herbruikbaar artefact naar wens vinden doordat alles centraal
is opgeslagen. Hierdoor is het ook mogelijk betrokkenen gemakkelijker bekend te
laten worden met de beschikbare herbruikbare artefacten.
Een belangrijk aandachtspunt bij een repository is de manier waarop herbruikbare
artefacten erin opgenomen kunnen worden. Zo kunnen de software engineers
volledig vrijgelaten worden om herbruikbare artefacten op te slaan. Dit verlaagt de
drempel voor de software engineers om hun producten centraal beschikbaar te
stellen. Aan de andere kant bestaat wel het risico dat de repository gevuld wordt
met slecht gedocumenteerde en kwalitatief slecht herbruikbare artefacten.
Het andere uiterste is een vorm van selectie aan de poort waarbij door een andere
partij wordt bepaald of het herbruikbare artefact voldoet aan kwaliteitscriteria en of
de documentatie in orde is.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
60
3.6
Kwantificeren van hergebruik
‘Meten is weten’, een simpel gezegde dat ook zeker op hergebruik van software
artefacten van toepassing is. Het heeft echter weinig nut om stuurloos allerlei
aspecten te gaan meten. In deze paragraaf wordt bekeken welke aspecten belangrijk
zijn om gekwantificeerd te worden, met betrekking tot hergebruik van software
artefacten. Tevens wordt er een voorbeeld uitgewerkt waarbij er vanuit een
vooropgezet doel een afleiding wordt gemaakt naar subdoelen en metingen en de
eventuele interpretatie van die metingen.
3.6.1
Wat zijn metingen
Meten is het kwantificeren van attributen van entiteiten volgens duidelijk
gedefinieerde regels. Een attribuut is hierbij een kenmerk of eigenschap van de
entiteit. Metingen kunnen direct of indirect zijn [FEN97]. Bij een directe meting is
er slechts één attribuut betrokken, het is dus direct meetbaar. In de praktijk doen
zich echter vaker complexe situaties voor waarbij de gewenste informatie een
functie is van meerdere attributen. In dit geval spreekt men van indirecte metingen.
De attributen kunnen daarnaast intern of extern zijn [FEN97]. Een intern attribuut
van een entiteit kan gemeten worden zonder dat de context nodig is. Bijvoorbeeld
de grootte van een stuk code (aantal regels code of operaties). Een extern attribuut
kan alleen gemeten worden in relatie met de context, bijvoorbeeld de productiviteit
van een werknemer.
3.6.2
Kwaliteit van de data
Dat de kwaliteit van de data een belangrijke rol speelt bij de bruikbaarheid van de
metingen is evident. Er zijn een vijftal aspecten waar rekening mee moet worden
gehouden bij het interpreteren van de data [FEN97]:
1. Correctheid
De mate waarin de data verzameld en vastgesteld is volgens vooraf vastgelegde
regels. Zo kan het aantal regels code van een stuk software afhangen van de
meetdefinities. Worden bijvoorbeeld de regels commentaar meegerekend of
niet? Uniformiteit in de meetdefinities tussen de verschillende metingen is
essentieel voor de consistentie tussen de metingen.
2. Betrouwbaarheid
Dit aspect omvat twee aspecten, namelijk de accuraatheid en de precisie. De
accuraatheid heeft betrekking op de mate waarin de gemeten data overeenkomt
met de echte waarde. De precisie duidt op de nauwkeurigheid waarin de data
wordt weergegeven. Wordt de tijd waarin een aantal ontwikkelaars nodig zijn
voor een bepaald een project bijvoorbeeld weergegeven in minuten, uren, dagen
of maanden.
3. Consistentie
De data dient consistent te zijn tussen de gemeten entiteiten. De uitkomsten
dienen vergelijkbaar te zijn.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
61
4. Tijdsafhankelijkheid
Indien de uitkomst van een meting geassocieerd is met een bepaalde periode
dan dient dit ook vermeld te worden bij de data (time-stamp).
5. Reproduceerbaarheid
Om resultaten te kunnen vergelijken is het noodzakelijk dat de metingen en
uitkomsten reproduceerbaar zijn.
3.6.3
Goal Question Metric en AMI
Er zijn verschillenden methoden beschikbaar waarmee een organisatie een
meetplan kan samenstellen. Een bekende methode is de Goal Question Metric
(GQM) methode. Deze methode is geschikt om metingen te definiëren voor
software projecten, processen, producten en resources [FEN97][EZR02] op een
zodanige manier dat:
-
de metingen zijn aangepast aan de organisatie en haar doelen,
de uitkomsten een constructieve en instructieve bijdrage leveren,
de uitkomsten vanuit de verschillende gezichtspunten van de groepen in
een organisatie bekeken worden.
Het kwantificeren van aspecten uit het softwareontwikkelproces omvat
verschillende activiteiten: het bekijken van de huidige situatie om te bepalen wat de
doelen van het kwantificatie proces zijn, het opbreken van deze doelen naar
meetbare subdoelen, het opstellen van de specifieke metingen, het verzamelen en
verifiëren van de data, het verwerken en interpreteren van deze data en het
terugkoppelen hiervan naar de oorspronkelijke doelen. In Figuur 15 wordt dit
weergegeven volgens de AMI methode. AMI is gebaseerd op het GQM en CMM
en biedt een gestructureerde manier om aspecten van het softwareontwikkelproces
te kwantificeren. In Bijlage C wordt deze methode nader toelicht.
Environment
Management Objectives
Current Practices
Customer Requirements
Asses
Primary Goals
Analyse
Metrics
Specification
Reference to
Assessment
Reference to
Goals
Metricate
Improve
Measurement
Data
Resources
Processes
Products
Figuur 15 - Verschillende fasen volgens de AMI methode [PUL96].
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
62
3.6.4
Bijdrage van metingen aan hergebruik
De vraag is op welke manier metingen een bijdrage kunnen leveren aan hergebruik
van software artefacten binnen een organisatie. Waarom wordt dit gemeten en wat
kan er uit de verzamelde data geconcludeerd worden? Hierbij is het belangrijk om
te weten vanuit welk perspectief de meting is uitgevoerd, met andere woorden,
welke stakelholder is erin geinteresseerd of wordt erdoor beïnvloed?
Frakes heeft hiervoor een categorizering gemaakt naar verschillende metingen en
modellen die gebruikt kunnen worden om inzicht te krijgen in de toepassing van
hergebruik binnen een organisatie [FRA96].
1. Hergebruik Cost-Benefits modellen.
2. Hergebruik Volwassenheidsmodellen.
3. Hoeveelheid hergebruik.
4. Mislukkingsmodellen.
5. Herbruikbaarheid van de artefacten.
6. Repository metingen.
Enkele aspecten uit zijn categorizering zijn echter gebaseerd op niet-kwantitatieve
methoden, zoals de volwassenheidsmodellen of de mislukkingsmodellen. Er zijn
een aantal aspecten in het softwareontwikkelproces waar kwantitatieve gegevens
belangrijk zijn om een goede keuze te kunnen maken. Denk bijvoorbeeld aan aan
de keuze om bepaalde software artefacten herbruikbaar te maken, het evalueren
van de opbrengsten van hergebruik (zowel op projectniveau als organisatieniveau)
of de keuze om een artefact her te gebruiken tegenover de keuze om het zelf te
ontwikkelen.
3.6.5
Voorbeeld uitwerking volgens de AMI methode
In deze paragraaf wordt een voorbeeld uitgewerkt aan de hand van de AMI
methode. Hierbij wordt niet ingegaan op de organisatorische aspecten maar wordt
vooral gekeken naar de opzet van de doelen, het verkrijgen van de subdoelen, het
afleiden van de metingen en het interpreteren van de data.
Fase ‘Assess’
Er wordt uitgegaan van een organisatie met CMM level 2 waar hergebruik op adhoc basis plaatsvindt. Recent is er een initiatief gestart om hergebruik van software
artefacten systematischer aan te pakken. Er is een repository aangeschaft en
geïmplementeerd en er zijn een aantal herbruikbare artefacten beschikbaar waar de
ontwikkelaars gebruik van kunnen maken. Er is voor de organisatie geen
´baseline8´ beschikbaar aangezien zowel de repository als het systematisch
hergebruiken relatief nieuw zijn.
Gezien de prille status van het hergebruik initiatief wil de organisatie eerst inzicht
krijgen in de huidige situatie. Hiervoor kunnen er verschillende kennisdoelen
8 Een baseline is een soort nulpunt waar de uitkomsten van toekomstige metingen
mee vergeleken kunnen worden.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
63
geformuleerd worden. Aangezien de organisatie verder weinig tot geen ervaring
heeft met het uitvoeren van kwantitatieve analyses, wordt er besloten te beginnen
met twee doelstellingen.
‘Het evalueren van de intensiteit van hergebruik binnen een organisatie ’
‘Het evalueren van de kosten van hergebruik binnen een project’
Goal Purpose
Attribute
Entity
Perspective
Context
1
Evalueren
De intensiteit
van hergebruik
De
organisatie
Hergebruikmanager
2
Evalueren
De kosten
Herbruikbare
artefacten
Projectmanager
Er is geen inzicht in de
mate waarin er hergebruikt
wordt.
De projectmanagers zijn
van mening dat hergebruik
nadelig is voor hun project.
Tabel 12 - Template voor de definitie van doelen [FEN97][EZR02].
Fase ‘Analyse’
De gestelde doelen zijn niet direct meetbaar. Bij de GQM methode worden
hiervoor een aantal vragen opgesteld die samen bepalen of aan het doel is voldaan.
Voor de vragen worden daarna metingen opgesteld die deze kunnen beantwoorden.
Bij de AMI methode wordt dit anders aangepakt, hierbij worden er geen vragen
maar subdoelen opgesteld waarbij deze subdoelen wel direct meetbaar zijn. Er zijn
ook variaties op het GQM waarbij direct wordt overgegaan van doelen naar
metingen. In dit voorbeeld wordt de GQM methode gevolgd om de stap van het
doel naar de vragen naar de metingen aan te geven. Figuur 16 toont voor het 1ste
doel de ‘goaltree’.
Het evalueren van de intensiteit van
hergebruik binnen een organisatie
Goal:
Questions:
Metrics:
In welke mate wordt de
repository gebruikt?
1.
2.
3.
4.
5.
6.
Aantal herbruikbare artefacten
in de repository
Aantal hits per periode (geen
downloads)
Aantal downloads van
herbruikbare artefacten per
periode
Aantal mislukte zoekpogingen
per periode
Cumulatief aantal malen
hergebruik per artefact
Cumulatief aantal malen
hergebruik van alle artefacten
Figuur 16 - Goaltree voor de intensiteit van hergebruik
In welke mate wordt er gebruik
gemaakt van de beschikbare
herbruikbare artefacten?
1.
2.
3.
Percentage nieuwe code
Percentage onaangepaste
herbruikbare code
Percentage aangepaste
herbruikbare code
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
64
In deze goaltree wordt de intensiteit gedefinieerd als de mate van gebruik van de
repository en de mate van hergebruik van software artefacten bij het ontwikkelen
van nieuwe software. Er zijn ook andere aspecten die hier nog meegenomen
kunnen worden zoals de productie of ondersteuning. De nadruk ligt echter op het
‘design with reuse’ aspect. Om de mate van design with reuse te bepalen zijn er
verschillende methoden beschikbaar. LOC, lines of code, is waarschijnlijk de
meest bekende en wordt hier ook gehanteerd. Indien er wordt gemeten aan de hand
van LOC, kan dit pas gebeuren nadat het implementeren is begonnen. Ontwerpen
en analyses kunnen er niet in worden meegenomen. Het is ook moeilijk om
conceptuele producten zoals frameworks, architecturen of design patterns te
kwantificeren. Zolang daar geen herhaalbare en betrouwbare methoden
beschikbaar voor zijn, is het LOC een zeer geschikte indicator voor de mate van
hergebruik in het ontwikkelproces [POU97].
Goal:
Questions:
Metrics:
Het evalueren van de netto kosten
van hergebruik voor een project
Wat zijn de financiële baten
van hergebruik van software?
1. Kosten besparing bij het
ontwikkelen van software
2. Kosten besparing voor het
onderhouden van software
Wat zijn de financiële lasten
van hergebruik van software?
1.
2.
3.
4.
5.
6.
7.
Kosten voor kosten/baten analyse
Kosten voor zoeken
Kosten voor bestuderen
Kosten voor integreren
Kosten voor modificeren
Kosten voor testen
Kosten voor ondersteuning bij
gebruik van de herbruikbare
artefacten
8. Kosten voor onderhoud van
aangepaste herbruikbare artefacten
Figuur 17 - Goaltree voor de netto kosten van hergebruik binnen een project
Bij deze goaltree zijn er een aantal aannames gemaakt. De kosten van hergebruik
voor een project worden puur gevormd door de kosten voor het zoeken, bestuderen,
integreren, aanpassen en testen van herbruikbare artefacten alsmede het doen van
een kosten/baten analyse en de kosten voor het onderhoud van aangepaste
herbruikbare artefacten. De extra kosten voor de productie van herbruikbare
artefacten is hier dus buiten gelaten, het gaat enkel om de kosten die optreden bij
de consumptie van herbruikbare artefacten. Verder wordt het onderhoud en de
ondersteuning van de herbruikbare artefacten door een aparte eenheid uitgevoerd.
De opbrengsten voor een project zijn tweeledig. Ten eerste de besparing voor het
ontwikkelen met de herbruikbare software ten opzichte van het zelf ontwikkelen,
ten tweede de besparing op het onderhoud wat voorkomt uit een lager aantal bugs
en het feit dat het onderhoud niet door het project zelf gedaan hoeft te worden.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
65
Fase ‘Metricate’
Op basis van het doel, de vragen en de opgestelde metingen kan er nu een meetplan
geschreven worden. Dit plan licht de analyse, het doel en de subdoelen toe. Voor
de metingen wordt gedefinieerd waar die specifieke meting voor dient, hoe het
wordt berekend en wie ervoor verantwoordelijk is. De metric template van AMI is
hiervoor geschikt.
Metric Template
Deel A: Definitie van de meting en analyse procedure
Naam
Definitie
Kosten besparing bij het ontwikkelen van software
DCA, Development Cost Avoidance [POU97]9. De besparing door
ontwikkelen met herbruikbare artefacten ten opzichte van het zelf
ontwikkelen. Dit is opgebouwd uit een besparing door black box
hergebruik en door een besparing uit white box hergebruik.
RSI, Reused Source Instructions. Datgene wat hergebruikt wordt, kan in
LOC of Functie punten gemeten worden. In dit geval wordt LOC
gehanteerd. Deze standaard is afkomstig van IBM en is bedoeld voor
black box hergebruik. In dit voorbeeld wordt zowel black box als white
box hergebruik meegenomen. Daarom wordt het RSI gesplitst naar RSI
black box en RSI white box. Respectievelijk RSIb en RSIw.
RCR, Relative Costs of Reuse. Dit is de verhouding tussen de
benodigde inspanning voor het black box hergebruiken ten opzichte van
het ontwikkelen voor eenmalig gebruik. Elke organisatie heeft hier zijn
eigen waarde voor en deze is afhankelijk van verschillende factoren.
Industriewijd kengetal is 0,2 [POU97][MIL02].
CAC, Costs of Adapted Code. Dit is de verhouding tussen de benodigde
inspanning voor het white box hergebruiken ten opzichte van het zelf
ontwikkelen voor eenmalig gebruik. Industriewijd kengetal is 0,67
[MIL02][POU97].
DCA = (RSIb x (1- RCR) + RSIw x (1- CAC)) x Kosten nieuwe code
Doel
Inzicht verkrijgen in de besparing bij het ontwikkelen met herbruikbare
artefacten. Wat is nu het verschil met het zelf ontwikkelen?
Analyse Procedure
Geeft snel en gemakkelijk een inzicht in de besparing als gevolg van het
hergebruik van software bij het ontwikkelen van nieuwe software.
Verantwoordelijkheden N.v.t.
Benodigde training
Kennis van economische aspecten bij de ontwikkeling van software.
Deel B: Definitie van primitieve metingen en verzamelprocedures
Naam
RSIb en RSIw
9 Poulin heeft Reuse Calculator ontwikkeld waarmee organisaties op een snelle
manier inzicht kunnen krijgen in wat hergebruik voor hun kan betekenen. Zie
http://home.stny.rr.com/jeffreypoulin/html/reucalc_basic.html
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
66
Definitie
RSIb aantal regels code dat wordt hergebruikt zonder wijziging.
RSIw aantal regels code dat wordt hergebruikt waarbij deze fragmenten
wel worden aangepast.
Verzamelprocedure
Verantwoordelijkheden Tabel 13 - Metric template voor ´Development Cost Avoidance´ [POU97].
Deel B van de metric template is hier leeg gelaten, aangezien de relevante aspecten
allemaal in deel A zijn beschreven. Aangezien organisaties vaak geen inzicht
hebben in aspecten zoals de besparing in moeite bij black box hergebruik ten
opzichte van het zelf ontwikkelen, de kosten per regel code of de kosten per functie
punt kunnen hier kengetallen gehanteerd worden. Voor het RSI met black box
wordt de ratio 0,2 als kengetal gehanteerd en voor white box hergebruik 0,67. Op
deze manier kan een organisatie zonder eigen specifieke kengetallen toch op basis
van industriële kengetallen tot een goede schatting komen.
Fase ‘Improve’
In deze fasen worden de verzamelde gegevens verwerkt. Hoe de gegevens
gepresenteerd worden is hier niet van belang, het kan met een histogram, een
diagram of een andere representatie. Het is belangrijker te kijken of de verzamelde
data onverwachte of ongebruikelijke waarden laat zien en of er trends zijn te
ontdekken.
Wat nog rest is de interpretatie van de gegevens. Want hoe kunnen de uitkomsten
van de metingen geïnterpreteerd worden in relatie met de gestelde doelen?
De twee doelstellingen zoals geformuleerd in de fase ‘Assess’ worden beide
besproken.
Doel 1 - Intensiteit van hergebruik
Dit doel is opgesplitst in 2 vragen, respectievelijk A en B. Indien er over een
specifieke metriek wordt gesproken, wordt deze aangeduid met (de aanduiding
van) de vraag en het nummer van de metriek. Bijvoorbeeld A3 staat voor Aantal
downloads per periode. Hetzelfde geldt straks voor het tweede doel.
Metriek
Interpretatie
A1
Deze meting geeft inzicht in het aantal beschikbare herbruikbare artefacten. Op zichzelf zegt
deze meting weinig, stel bijvoorbeeld dat de waarde 15 is. Dan zijn er dus 15 herbruikbare
artefacten. Indien het echter gekoppeld wordt aan andere informatie, zoals de grote en
complexiteit van het artefact, het aantal software engineers en de productie van software dan
krijgt de waarde meer betekenis. Blijkt bijvoorbeeld dat een organisatie veel software
ontwikkeld maar het aantal herbruikbare artefacten laag blijft, dan zegt dit mogelijk iets over het
potentieel van hergebruik binnen de organisatie of over een gebrek aan sturing op de productie
van herbruikbare artefacten.
Deze meting geeft inzicht in de mate waarin de repository wordt bekeken. Stel dat er 41 als
waarde uitkomt. Dat betekent dus dat er in een bepaalde periode 41 maal in de repository is
gekeken. In combinatie met het aantal software engineers geeft dit inzicht in de mate van
A2
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
67
A3
A4
A5
A6
B1
B2
B3
gebruik van de repository. Indien deze ratio heel laag is kan het duiden op onbekendheid van de
repository of het ontbreken van motivatie het te gebruiken.
Deze meting geeft inzicht in het aantal downloads van herbruikbare artefacten per periode.
Indien deze waarde bijvoorbeeld 2 is terwijl de metriek A2 41 is dan duidt dit erop dat de
repository wel wordt gebruikt om herbruikbare artefacten te zoeken maar dat blijkbaar de juiste
artefacten er niet in zijn opgenomen.
Deze meting geeft het aantal mislukte zoekpogingen aan naar herbruikbare artefacten. Stel
bijvoorbeeld dat A4 een waarde heeft van 39, dus 39 mislukte zoekpogingen, dan kan dit
gecombineerd worden met de metrieken A2 en A3. Indien A4 namelijk het grootste deel van het
verschil tussen A2 en A3 opvult kan dit een verklaring zijn voor de lage waarde van A3.
Namelijk dat de gewenste herbruikbare artefacten missen. Indien A4 heel laag is, bijvoorbeeld 3
terwijl A2 41 is en A3 2 dan kan het erop duiden dat de hergebruikers niet weten welke
herbruikbare artefacten beschikbaar zijn en hoe het repository gebruikt kan worden om deze te
vinden en downloaden.
Deze meting geeft inzicht in het aantal malen dat een specifiek herbruikbaar artefact is
hergebruikt. Deze metriek geeft inzicht in het technische vlak van hergebruik. Stel dat A1 15 is
(15 herbruikbare artefacten), A2 is 60 (60 zoekpogingen) en A3 is 55 (55 downloads van
herbruikbare artefacten). Er zijn dus 15 artefacten die tesamen 55 maal zijn gedownload, dus
ongeveer 3,7 maal per artefact. Stel dat een specifiek herbruikbaar artefact 1 keer is hergebruikt
terwijl het meerdere keren is gedownload, dan duidt het erop dat het artefact vanuit technisch
oogpunt slecht herbruikbaar is.
Deze meting geeft inzicht in het aantal malen hergebruik van alle herbruikbare artefacten. Stel
dat A1 wederom 15 is, A2 60 en A3 55. A6, het totale aantal malen hergebruik over alle
artefacten, is 50. Dus van de 55 downloads hebben er 50 geresulteerd in het daadwerkelijk
hergebruiken van het artefact. Dit duidt erop dat de herbruikbare artefacten voldoen aan de
aspecten waarop de hergebruikers zochten en ook daadwerkelijk herbruikbaar zijn. Heeft A6
bijvoorbeeld een waarde van 3 terwijl het aantal downloads 55 is dan duidt het erop dat er
serieus iets mis is met de herbruikbare artefacten ten opzichte van behoefte van de hergebruikers.
Deze meting geeft inzicht in het percentage code dat nieuw wordt ontwikkeld. Stel dat hier 50
uitkomt, dus 50% van de code die wordt ontwikkeld binnen een project of organisatie is echt
nieuwe code. Dat betekent dus dat de overige code voort komt uit hergebruik. Indien dit
percentage stijgt, betekent dit dat de rol van hergebruik in de ontwikkeling van software afneemt
en visa versa.
Deze meting geeft inzicht in het percentage code dat onaangepast hergebruikt wordt. Stel dat B2
18 is, dus dat 18% van de totale code afkomstig is van black box hergebruik. Dit is natuurlijk al
een flink percentage aangezien dit betekent dat bijna 1/5 van alle geproduceerde code niet
telkens opnieuw ontwikkeld hoeft te worden. Hierbij is wel voorzichtigheid geboden aangezien
er sprake kan zijn van ‘inflatie’. Niet alle code van herbruikbare componenten hoeft immers
gebruikt te worden, terwijl het hier wel wordt meegerekend [MIL02].
Deze meting geeft inzicht in het percentage code dat na aanpassing hergebruikt wordt. Stel dat
B3 30 is, dus dat 30% van de totale code uit white box hergebruikt voorkomt.
Tabel 14 - Interpretatie van de metingen bij doel 1.
Uit de interpretaties in Tabel 14 blijkt dat de metrieken afzonderlijk slechts beperkt
van waarde zijn maar gezamenlijk belangrijke relaties kunnen leggen en tot diepere
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
68
inzichten kunnen leiden. Trends spelen hierin ook een belangrijke rol aangezien
hergebruik ook op basis hiervan gestuurd kan worden. Indien men metingen over
een langere periode vergelijkt kunnen uitkomsten significant afwijken, hier spreekt
met van outliers. Stel bijvoorbeeld dat de metriek B2 de volgende data laat zien:
Meting
Metriek
B2
1
30
2
3
32
31
4
28
5
35
6
30
7
5
Tabel 15 - Dataset van metingen van metriek B2.
Een dergelijke meting moet natuurlijk verklaard worden, zeker aangezien het hier
een sterke impact heeft op de resultaten van hergebruik. Als bijvoorbeeld in Meting
7 metriek B1 een sterke stijging en B3 gelijk blijft laat zien betekent dit dat er
nieuwe code wordt ontwikkeld in plaats van het her te gebruiken. Indien B1 gelijk
blijft maar B3 een sterke stijging laat zien betekent het dat black box hergebruik
plaats maakt voor white box hergebruik, bijvoorbeeld omdat er als gevolg van een
bepaalde ontwikkeling een aantal herbruikbare artefacten niet direct black box zijn
her te gebruiken. Het is dus belangrijk om de oorzaken van de ‘outliers’ te
achterhalen om op basis hiervan het proces weer bij te sturen.
Doel 2 - Kosten van hergebruik
De netto kosten van hergebruik worden in dit voorbeeld gevormd door de
opbrengsten minus de kosten voor hergebruik binnen een project. De opbrengsten
bestaan uit de voorkomen kosten voor het produceren van software en de
voorkomen kosten van het onderhoud. De kosten van hergebruik bestaan uit de
kosten voor het herbruikbaar maken van software artefacten en de kosten voor
ondersteuning bij het ‘design with reuse’. Er wordt dus vanuit gegaan dat er een
aparte eenheid is voor het onderhoud en support bij de herbruikbare artefacten.
Voor het berekenen van A1, A2 en B1 kunnen kengetallen gehanteerd worden
indien deze niet binnen de organisatie voor handen zijn.
Hieronder is een voorbeeld van de metric A1 opgenomen. Er wordt aangenomen
dat een project een applicatie ontwikkeld en hiervoor enkele componenten (black
box) hergebruikt. Deze componenten bevatten samen 12 KLOC. Voor de kosten
van het ontwikkelen van nieuwe code wordt $100 per LOC gehanteerd. De
bespaarde kosten ten opzichte van het zelf ontwikkelen van de betreffende code
zou dan zijn:
DCA = RSIb x (1- RCR) x (Kosten nieuwe code)
DCA = 12.000 x (1-0,2) x 100
DCA = $ 960.000
Dit betekent dat indien de componenten niet hergebruikt worden, het project
$ 960.000 moet uittrekken om dit zelf te ontwikkelen. Hierbij wordt er echter
vanuit gegaan dat het component hetzelfde is als wanneer het specifiek voor dit
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
69
project zou worden ontwikkeld. Dit is waarschijnlijk niet het geval en de
daadwerkelijke besparing kan daarom lager uitvallen.
Verder heeft een project natuurlijk baat bij het onderhoud op de herbruikbare
artefacten. Stel er deze organisatie ook inzicht heeft in het aantal fouten in haar
geproduceerde software en ook weet wat het kosten zijn om deze te repareren dan
kan ook de kostenbesparing op het onderhoud berekend worden. Stel bijvoorbeeld
dat er vanuit historische gegevens verwacht kan worden dat er 2 fouten per 1000
regels code bestaan en het gemiddeld $ 1.000 kosten om een fout te repareren dan
scheelt dit het project 12.000 / 1.000 * 2 = 24 fouten. Dus 24 * 1.000 = $ 24.000
voor alle hergebruikte software. De kostenbesparing voor dit project is samen dus
circa 1 miljoen dollar.
Daar tegenover staan de kosten van het hergebruiken van de herbruikbare
componenten. Stel dat deze kosten samen $ 500.000 zijn. Dan betekent dat dit
project netto $ 700.000 baat heeft gehad bij het ontwikkelen met de herbruikbare
artefacten. Op organisatieniveau zijn deze gegevens belangrijk aangezien ook de
kosten voor het produceren, onderhouden, beheren, het bieden van ondersteuning
en het coördineren van hergebruik gefinancierd moet worden. De financiële
voordelen van hergebruik kunnen niet volledig aan de klant worden doorberekend
aangezien een organisatie zichzelf dan in de vingers snijdt.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
70
3.7
Theoretisch raamwerk
Deze paragraaf zet op basis van de behandelde theorie een raamwerk op. Het doel
van dit theoretische raamwerk is het analyseren van hergebruik van software
artefacten binnen een organisatie (ook mogelijk op projectniveau). Aan de hand
van dit raamwerk kan er in een oogopslag worden gezien waar er zich knelpunten
of problemen voordoen op het gebied van hergebruik van software artefacten.
Om aan de hand van dit theoretische raamwerk een organisatie te kunnen
analyseren, dient het raamwerk inzicht te geven in de invulling van de
verschillende aspecten en keuzen op het gebied van hergebruik van software
artefacten. Het raamwerk in Tabel 16 bestaat uit drie delen: de artefacten die
worden ontwikkeld en hergebruikt, de processen die hierbij voorkomen en de
manier waarop het organisatorisch is ingericht. Per onderwerp worden de relevante
aspecten opgesomd waarbij per aspect wordt beschreven wat het inhoud en wat de
mogelijke invullingen daarvan zijn.
Aspect
Artefacten
Type artefacten
Manier van gebruik
Documentatie
Intensiteit van
hergebruik
Toelichting
Wat voor type artefacten worden er daadwerkelijk hergebruikt?
- Requirements
- Ontwerpen
- Broncode
- Componenten
- Architectuur
- Frameworks
- Testdata & plannen
- Documentatie
- Anders
Wat is het beoogde gebruik van de herbruikbare artefacten?
- Black box
- White box
Is er begeleidende documentatie bij het herbruikbare artefact?
- Ja (beschrijf wat de documentatie omvat)
- Nee
Wat is de intensiteit van hergebruik?
- Horizontale artefacten
- Verticale artefacten
- Applicatie frameworks
Processen
Moment van productie
Manier van productie
Op welk moment worden de herbruikbare artefacten geproduceerd?
- Pre-project
- In-project
- Post-project
Op welke manier worden de herbruikbare artefacten verkregen?
- Domein engineering
- Re-engineering
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
71
Ondersteuning
Configuratie
Management
Problem & Change
Management
Certificatie
Sturing Productie
Sturing Consumptie
Metingen
- Verkregen via externe partij
Op welke manier worden de hergebruikers ondersteund bij het
hergebruiken van de herbruikbare artefacten?
- Niet
- Via documentatie
- Ondersteuning via maker of verantwoordelijke van het
herbruikbare artefact
Is er iemand die het configuratie management van het herbruikbare
artefact uitvoert?
- Ja
- Nee
Is er iemand die het problem & change management van het
herbruikbare artefact uitvoert?
- Ja
- Nee
Hoe worden de herbruikbare artefacten gecertificeerd?
- Niet
- Informeel, op basis van bijvoorbeeld gebruikerservaringen
en aantal malen hergebruik
- Formeel
Hoe wordt de productie van herbruikbare artefacten gestuurd?
- Geen sturing
- Adviserende en faciliterende sturing
- Dwingende sturing
Hoe wordt de consumptie van herbruikbare artefacten gestuurd?
- Geen sturing
- Adviserende en faciliterende sturing
- Dwingende sturing
Welke gegevens worden geregistreerd om inzicht te krijgen in het
softwareontwikkelproces m.b.t. hergebruik specifieke aspecten?
- Geen
- Financiele aspecten
- Hoeveelheid hergebruik
- Volwassenheid van hergebruik
- Herbruikbaarheid
- Repository metingen
Organisatie
Verantwoordelijkheid
voor ondersteuning bij
herbruikbare artefacten
Verantwoordelijkheid
voor het beheren van
herbruikbare artefacten
Sturing Productie
Is er een aanspreekpunt en verantwoordelijke voor de
ondersteuning bij de herbruikbare artefacten aangewezen?
- Nee
- Informeel
- Formeel
Is er iemand verantwoordelijk voor taken zoals onderhoud,
configuratiemanangement en change en problem management?
- Nee
- Informeel
- Formeel
Is er een organisatie eenheid ingericht voor de coördinatie van de
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
72
Sturing Consumptie
Niveau van sturing
Top Management
Commitment
Voorschriften
Inrichting Productie
Inrichting
Ondersteuning
Financiering productie
Financiering beheer
Financiering
ondersteuning
productie van herbruikbare artefacten?
- Ja
- Nee
Is er een organisatie eenheid ingericht voor de coördinatie van de
consumptie van herbruikbare artefacten?
- Ja
- Nee
Op welk niveau in de organisatie is de sturing van hergebruik
opgehangen?
- Geen sturing aanwezig
- Per project/domein afzonderlijk
- Afstemming tussen projecten/domeinen
- Centraal, geïntegreerd proces over projecten
Is het top management betrokken bij de introductie en
instandhouding van hergebruik van software artefacten?
- Ja (duidelijke commitment van top management voor
hergebruik)
- Nee (top management niet betrokken, hergebruik is
geïnitieerd vanuit technische staf)
Zijn er voorschriften voor hergebruik specifieke activiteiten?
- Ja (beschrijf welke voorschriften dit zijn)
- Nee
Hoe is de productie van het herbruikbare artefact georganiseerd?
- Geïntegreerd in de projecten
- Losstaande eenheid
Hoe is de ondersteuning van het herbruikbare artefact
georganiseerd?
- Niet georganiseerd
- Losstaande eenheid
Hoe worden de productiekosten van de herbruikbare artefacten
verrekend?
- Niets geregeld
- Indirect, algemeen budget voor productie beschikbaar
- Direct, projecten betalen voor de artefacten die ze
hergebruiken
Hoe wordt het beheer van de herbruikbare artefacten verrekend?
- Niets geregeld
- Indirect, algemeen budget voor onderhoud
- Direct, projecten die het artefact hergebruiken betalen een
percentage van het beheer & onderhoud van het artefact.
Hoe worden de kosten voor de ondersteuning ten behoeve van de
hergebruikers verrekend?
- Niets geregeld
- Indirect, algemeen budget voor ondersteuning
- Direct, projecten betalen direct voor de ondersteuning die
ze gebruiken
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
73
Repository
Is er een centraal punt waar de herbruikbare artefacten zijn
opgeslagen en teruggevonden kunnen worden?
- Ja
- Nee
Tabel 16 - Theoretisch raamwerk voor het analyseren van hergebruik.
Justificatie van het raamwerk
Dit raamwerk dient om snel inzicht te verkrijgen in de manier waarop een
organisatie invulling heeft gegeven aan hergebruik. Dit raamwerk kan dus niet
alleen gebruikt worden ter analyse van een organisatie maar kan worden gezien als
een template waarin de relevante aspecten worden samengevat. Elk aspect dient
dus altijd te worden toegelicht.
De aspecten die in het raamwerk naar voren komen geven een korte samenvatting
van de aspecten die in de theorie zijn behandeld. Elk aspect in het raamwerk vormt
een keuze of manier van invulling voor de organisatie.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
74
3.8
Best practices
Deze paragraaf bekijkt hoe bij twee organisaties, Sodalia en Eliop, hergebruik van
software artefacten is vormgegeven. Deze twee organisaties verschillen op vele
aspecten van elkaar, bijvoorbeeld in grote, het domein waarin ze werkzaam zijn en
de manier waarop hergebruik wordt toegepast. In deze paragraaf worden de twee
organisaties geanalyseerd doormiddel van het theoretische raamwerk.
3.8.1
Sodalia en Eliop
Sodalia is ontstaan in het begin van de jaren negentig na een joint venture tussen
Telecom Italia en Bell Atlantic. Sodalia heeft ongeveer 300 software ontwikkelaars
en heeft in een korte tijd na oprichting CMM level 3 weten te bereiken. Sodalia is
hier gekozen omdat het in de literatuur wordt beschouwd als één van de
belangrijkste voorbeelden op het gebied van hergebruik van software artefacten
[EZR02][DOU97][MOR00].
Eliop daarentegen, is een kleine organisatie met circa 100 man waarvan er 30 direct
betrokken zijn bij de ontwikkeling van software. Het is een goed voorbeeld van een
kleine organisatie waar de volwassenheid van het softwareontwikkelproces nog
beperkt is, maar waar hergebruik van software artefacten wel succesvol wordt
toegepast [EZR02][MOR00][VIL95].
Tabel 17 analyseert de twee organisaties met behulp van het theoretische
raamwerk. In Tabel 35 en Tabel 36 in Bijlage D wordt een samenvatting gegeven
van respectievelijk de eigenschappen van Sodalia en Eliop en de manier waarop
Sodalia en Eliop hergebruik systematisch toepassen.
Aspect
Artefacten
Type artefacten
Manier van gebruik
Documentatie
Intensiteit van
hergebruik
Sodalia
Eliop
Domein modellen, applicatie
frameworks (rond 10.000 functie
punten), libraries en componenten
Hoofdzakelijk black box
Ontwerp- en testdocumentatie,
gebruikershandleidingen
Applicatie Frameworks met
algemene en domein specifieke
componenten
Broncode, specificaties en
ontwerpmodellen, testprocedures
White box hergebruik
Onbekend welke documentatie.
Hergebruik van algemene en domein
specifieke artefacten
Processen
Moment van productie
Manier van productie
Ondersteuning
Pre-project & In-project
Domein Engineering
In-project, next-project
Domein Engineering & Reengineering
Ja
Configuratie
Ja
Nee, wel training software engineers in
hergebruik technieken.
Nee
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
75
Management
Problem & Change
Management
Certificatie
Ja
Nee
Formeel via audits (en validatie en
verificatie)
Geen (wel validatie voordat
herbruikbare artefacten worden
toegevoegd aan repository)
Dwingende sturing
Faciliterende en adviserende sturing /
dwingende sturing.
Mate van hergebruik, kosten
herbruikbare artefacten en kwaliteit
herbruikbare artefacten
Sturing Productie
Sturing Consumptie
Dwingende sturing
Faciliterende en adviserende sturing
Metingen
Enkele repository metingen (aantal
malen hergebruik per artefact)
Organisatie
Verantwoordelijkheid
voor ondersteuning bij
herbruikbare artefacten
Verantwoordelijkheid
voor het beheren van
herbruikbare artefacten
Sturing Productie
Sturing Consumptie
Niveau van sturing
Top Management
Commitment
Voorschriften
Inrichting Productie
Inrichting
Ondersteuning
Financiering productie
Financiering beheer
Financiering
ondersteuning
Repository
Formeel via Reuse Support
Organization (RSO)
Informeel via hergebruik specialisten.
Formeel via Reuse Support
Organization (RSO)
Reuse Task Group (RTG). Bestaat uit
Reuse Manager en Projectmanagers.
Ja (RSO)
Ja (RSO)
Centraal, geïntegreerd proces over
projecten en domeinen
Ja, hergebruik is opgestart en
opgelegd door het top management.
Ja, voor de verschillende processen
met inachtneming van hergebruik.
Ja (RTG)
Ja (RTG)
Per project/domein afzonderlijk
Losstaande eenheid (RSO) + soms
in projecten
Losstaande eenheid (RSO)
Ja, systematisch hergebruik initiatief is
ook opgestart vanuit management.
Ja, coding standards en
documenttemplates (voor
standaardisatie van herbruikbare
artefacten)
Losstaande eenheid (RTG) + in
projecten
Geen
Indirecte verrekening (apart budget)
Indirecte verrekening (apart budget)
Directe verrekening
Niet bekend
Niet bekend
Niet bekend
Ja, SALMS (Sodalia Assets Library
Management System)
Ja, combinatie Database Management
Systeem en Configuratie Management
systeem.
Tabel 17 - Hergebruik bij Sodalia en Eliop [EZR02][DOU97][MOR00][VIL95].
3.8.2
Belangrijke factoren voor het succes bij Sodalia en Eliop
Deze paragraaf identificeert de belangrijkste aspecten die bij Sodalia en Eliop
doorslaggevend zijn geweest voor het succes van hergebruik van software
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
76
artefacten. Sodalia en Eliop zijn twee verschillende organisaties die een
verschillende invulling hebben gegeven aan hergebruik van software artefacten.
Sodalia hanteert een sterk geformaliseerde aanpak waarbij productie en consumptie
van herbruikbare artefacten strikt gescheiden zijn. Er is een aparte organisatie
opgericht voor de productie van de software artefacten, het valideren en
onderhouden en het bieden van ondersteuning aan de hergebruikers: de Reuse
Support Organization (RSO). Hergebruik van software heeft een sterke support van
het Top Management en is doorgedrongen in alle software engineering activiteiten
binnen Sodalia, kortom het is de manier van werken.
Door de systematische toepassing van domein engineering worden de
mogelijkheden tot hergebruik zoveel mogelijk in herbruikbare artefacten vertaald.
Doordat de productie en consumptie twee gescheiden processen zijn, komen de
voordelen bij de projectteams, de echte hergebruikers, terecht wat een extra
motivatie is om te hergebruiken. Hergebruik is niet per definitie verplicht, maar de
projecten zien zelf de noodzaak en voordelen van het hergebruiken in. Er worden
hier zowel algemene als domein specifieke artefacten hergebruikt en Sodalia heeft
enkele frameworks ontwikkeld waarin de applicaties worden gebouwd. Deze
aanpak heeft het mogelijk gemaakt dat Sodalia hergebruik percentages tot 80%
heeft bereikt.
De aanpak van Eliop wijkt sterk af van de aanpak van Sodalia. De volwassenheid
van het softwareontwikkelproces van Eliop is beperkt. Eliop probeert de
betrokkenen op verschillende manieren handvaten aan te reiken om hergebruik ook
systematisch toe te kunnen passen. Hiervoor heeft Eliop formele regels en
procedures opgesteld, standaardiseert het de documenten en code doormiddel van
templates en coding rules en biedt het vele trainingen voor zowel software
engineers als projectmanagers aan. De nadruk ligt hierbij op kwaliteit van de
herbruikbare artefacten en de hiermee gerelateerde verbetering van de kwaliteit van
de software producten voor de klanten. Dit lijkt echter in tegenspraak te zijn met
gehanteerde aanpak, namelijk whitebox hergebruik, en de kans op fouten als
gevolg van hergebruik zoals in § 3.3.5 is besproken.
De belangrijkste factoren voor het succes bij beide organisaties met betrekking tot
het systematisch hergebruiken van software artefacten worden hieronder
opgesomd.
Sodalia
- Top Management Support. Hergebruik is opgelegd door het Top
Management.
- Aparte groep voor de productie en ondersteuning van herbruikbare
artefacten. Deze groep ontvangt een sterke steun vanuit het (top)
management.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
77
-
-
Eliop
-
-
-
-
Standaardisatie met hergebruik. Een beperkt aantal duidelijk gedefinieerde
productlijnen waarvoor applicatieframeworks met componenten zijn
ontwikkeld.
Domein engineering om zoveel mogelijk kansen voor hergebruik te
benutten.
Gestandaardiseerde processen met betrekking tot de productie, consumptie
en beheer & ondersteuning.
Standaardisatie van herbruikbare artefacten doormiddel van programmeerstandaarden en documentatie templates.
Standaardisatie van processen door procedures en richtlijnen. De
activiteiten voor hergebruiken zijn expliciet opgenomen in de normale
procesbeschrijvingen.
Training voor de software engineering in methoden en technieken van
hergebruik. Belangrijk aangezien Eliop voor White Box hergebruik kiest.
Aparte groep voor de geplande productie van de herbruikbare artefacten.
Deze groep wordt gesteund door het Top Management en bevat de
projectleiders zodat hergebruik in de projecten direct geborgd is.
Domein engineering om zoveel mogelijk kansen voor hergebruik te
benutten. Tevens om hergebruik binnen productfamilies mogelijk te
maken.
Top Management Support, onder de voorwaarde dat hergebruik zichzelf
bewijst. Het registreren van kwantitatieve gegevens is hierbij een must.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
78
3.9
Conclusie
Het systematisch hergebruiken van software artefacten kan een daling in de kosten
en doorlooptijd veroorzaken en een betere kwaliteit van de ontwikkelde software
realiseren. Dit is echter niet voor iedere organisatie weggelegd. Een beperkte
potentie voor het systematisch hergebruiken, aanzienlijke aanloopkosten in
combinatie met onzekere opbrengsten en weerstand vanuit de organisatie vormen
een flinke drempel om voor hergebruik te kiezen.
Indien een organisatie hergebruik van software systematisch wil gaan toepassen,
zijn een aantal factoren van essentieel belang. Het aanpassen van de organisatie,
het invoeren van nieuwe hergebruikspecifieke processen en het aanpassen van de
bestaande processen is essentieel. Hiervoor is top management support
onontbeerlijk.
In een normaal softwareontwikkelproces worden de software artefacten voor
eenmalig gebruik ontwikkeld en is het bestaan verbonden aan het bestaan van de
applicatie waarvoor ze zijn ontwikkeld. Bij hergebruik leiden de herbruikbare
artefacten echter een eigen bestaan, los van de applicaties waarin ze zijn
hergebruikt. Daarom moet al bij het ontwikkelen van een herbruikbaar artefact
rekening worden gehouden met toekomstige situaties waarin het artefact
hergebruikt kan worden. Tevens ontstaan er een aantal projectoverschrijdende
processen voor de herbruikbare software artefacten.
- Configuratiemanagement & versiebeheer
- Problem en Change management
- Certificatie
- Classificatie
- Ondersteuning
Om hergebruik te borgen is sturing over de projecten heen noodzakelijk. Dit betreft
zowel de sturing op de ontwikkeling van herbruikbare artefacten als de sturing op
het ontwikkelen met de herbruikbare artefacten. Al deze activiteiten moeten echter
ook verrekend worden. Er zijn drie methoden beschikbaar om dit te doen, namelijk
het verrekenen via overhead, het inhouden van een, vast of variabel, percentage
van het budget en pay for use. Om inzicht te krijgen in de kosten, opbrengsten en
mate van hergebruik is het essentieel om aspecten uit het softwareontwikkelproces
betreffende hergebruik te registreren. Op die manier kan bepaald worden of
hergebruik daadwerkelijk iets oplevert en kan het proces gestuurd worden.
Bij de best practices bleek het projectoverschrijdende karakter van hergebruik te
zijn opgevangen door een aparte groep, speciaal voor hergebruik. Deze groep was
onder andere verantwoordelijk voor de sturing en coördinatie van hergebruik. Top
management support bleek ook in bij de best practices een essentiële rol te spelen.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
79
4.
Huidige Situatie bij TNO
Dit hoofdstuk analyseert de huidige toepassing van hergebruik van software
artefacten binnen de afdeling M&S van TNO-D&V. Als eerste wordt de
gehanteerd aanpak toegelicht. Daarna wordt de huidige situatie geanalyseerd, onder
andere via case studies. Dit hoofdstuk eindigt met een overzicht van de
belangrijkste knelpunten die bestaan in de huidige toepassing van hergebruik van
software artefacten binnen de afdeling M&S.
4.1
Aanpak
Het doel van dit hoofdstuk is inzicht verkrijgen in de manier waarop hergebruik
van software artefact is vormgegeven en de knelpunten die zich hierbij voordoen.
Om dit te kunnen onderzoeken dient de huidige situatie geanalyseerd te worden.
Dit hoofdstuk kan grofweg in twee delen gesplitst worden;
-
-
Een algemene analyse van hergebruik van software artefacten binnen de
afdeling M&S. Deze analyse resulteert in een beschrijving van hergebruik
van software artefacten en de context waarin hergebruik plaatsvindt.
Een diepgaande analyse van drie case studies waarbij wordt bekeken hoe
hergebruik van software artefacten is vormgegeven en waar de knelpunten
liggen.
4.1.1
Waarom deze aanpak
Door eerst een algemeen beeld te schetsen en daarna de case studies te behandelen
wordt er getracht een zo accuraat en representatief mogelijk beeld te vormen van
de toepassing van hergebruik van software artefacten binnen M&S. Deze algemene
beschrijving neemt aspecten mee die buiten de typering van de case studies vallen
maar wel belangrijk zijn voor het totaalbeeld.
4.1.2
Informatieverzameling
Voor de analyse van de huidige situatie is er gebruik gemaakt van interviews,
documentatie en informele gesprekken. Bij de interviews is er rekening gehouden
met de verschillende stakeholders. In Bijlage E zijn de interviewopzet en
uitkomsten verwerkt. De stakeholder ‘klant’ is niet opgenomen in deze analyse.
Software Engineers
Management
Hergebruik van
software artefacten
Project Leiders
Klanten (extern)
Figuur 18 - Stakeholders bij hergebruik van software artefacten
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
80
4.2
Algemene analyse
Deze paragraaf analyseert de toepassing van hergebruik van software artefacten
binnen de afdeling Modelling & Simulation. Hiervoor worden de algemene
kenmerken van TNO-D&V beschreven die van belang zijn om het hergebruik van
software artefacten in de juiste context te kunnen plaatsen. Tevens wordt de
toepassing van hergebruik van software artefacten binnen M&S getypeerd
doormiddel van het Reuse Maturity Framework uit Bijlage B.
4.2.1
Softwareontwikkeling en hergebruik binnen TNO-D&V
TNO-D&V is een kennisorganisatie. Het is geen softwarehuis en zal dit in de
nabije toekomst ook niet worden. Softwareontwikkeling binnen TNO-D&V kan
beter gezien worden als een ondersteunende taak voor andere activiteiten. Zo
bestaat er ook geen pakket van softwareproducten die kant-en-klaar aan klanten
kunnen worden verkocht, uitzonderingen daargelaten.
4.2.2
Producten en kwaliteit
De afdeling Modelling & Simulation ontwikkelt verschillende type
softwareproducten. Deze softwareproducten kunnen zowel voor intern als extern
gebruik zijn. Een voorbeeld is de situatie waarbij een externe klant met een
kennisvraag komt waarvoor een onderzoeksmodel wordt ontwikkeld. De resultaten
van de simulaties in het onderzoeksmodel worden aan de klant geleverd, de
applicatie blijft binnen TNO-D&V. Bij operationele systemen kan het zo zijn dat
de klant naar TNO komt om het te gebruiken of dat het systeem op locatie van de
klant wordt gebruikt.
Bij TNO-D&V worden er twee typen project onderscheiden, basis
financieringsprojecten en additionele projecten. Basis financieringsprojecten
worden gefinancieerd door de overheid en bieden TNO de kans om in overleg met
een eventuele klant een bepaald onderzoek te doen. Deze projecten vormen circa
50 á 60% van het totale budget van TNO-D&V. Additionele projecten vormen een
steeds belangrijkere bron van inkomsten voor TNO-D&V aangezien het budget
voor de basis financieringsprojecten gestaag afneemt. Additionele projecten komen
voort uit een klantvraag en zijn onderhevig aan concurrentie.
In Tabel 18 staat een opsomming van de verschillende type systemen die binnen
TNO-D&V worden ontwikkeld.
Type systeem
Klant
Gewenste kwaliteit
Bedrijfskritisch
Operationeel
Onderzoeksmodel
Prototype
Tools
Intern/extern
Intern/extern
Intern
Intern/extern
Intern
Extreem
Hoog
Goed
Matig
Gemiddeld
Tabel 18 - Overzicht type systemen, klanten en benodigde kwaliteit [TNO03].
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
81
Voor de verschillende typen systemen die worden ontwikkeld, worden
verschillende niveaus van gewenste kwaliteit gehanteerd. Enkele voorbeelden van
software producten die worden of zijn ontwikkeld staan in Tabel 19.
Naam
Omschrijving
J-Roads
Simulatie model voor luchtverdedigingsystemen vanaf land en zee. Kan
worden gebruikt als analyse tool, exercise en trainingstool en als testbed
voor de ontwikkeling van software binnen J-Roads.
Optimalisatietool voor 11de Lucht Mobiele Bridage (11LMB) om op
bataljon niveau helicoptervluchten te plannen.
Kibowi MP is een stafprocedure trainer die gebruikt kan worden om
officieren op bataljon, brigade en divisie niveau te trainen in ‘train as u
fight’ simulaties.
Moses levert een framework voor de ontwikkeling van applicaties en
modellen voor ‘underwater warfare’. Dit kan variëren van ‘AntiSubmarine Warfare’, ‘Mine Countermeasures’, ‘Torpedo Defence
Systems’ tot onbemande onderwater voertuigen.
Simulatie model voor ‘anti submarine warfare’.
Othello
Kibowi MP
Moses
Topics
Tabel 19 - Voorbeelden van ontwikkelde software producten van TNO-D&V.
4.2.3
Organisatie en Reorganisatie
Bij aanvang was deze opdracht vooral gericht op de divisie Operationele Research
en Bedrijfsvoering waarbij de divisie Command Control en Simulatie betrokken
zou worden. Per 1 januari 2005 is er echter een TNO-brede reorganisatie gestart
waardoor de divisie Operationele Research en Bedrijfsvoering en de divisie
Command Control en Simulatie zijn samengevoegd in één afdeling: Modelling &
Simulation (M&S). Voor zover mogelijk wordt de gewijzigde situatie meegenomen
in deze scriptie, bij factoren waar de nieuwe situatie niet duidelijk of bekend is
wordt de oude situatie als uitgangspunt gehanteerd.
Mananager
Resource Mananager /
Afdelingshoofd
Technologietrekker
Project A
- Projectleider
- Software Engineers
Project B
- Projectleider
- Software Engineers
Project C
- Projectleider
- Technisch projectleider
- Software Engineers
Figuur 19 - Algemene Projectstructuur binnen BU2.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
82
M&S bestaat uit 45 werknemers, dit zijn software engineers, projectleiders,
software architecten en medewerkers die meer op een conceptueel of technologisch
niveau met software ontwikkeling bezig zijn. Van deze 45 werknemers zijn er zo’n
25 fulltime (circa 1600 uren per werknemer per jaar) bezig met de daadwerkelijke
ontwikkeling van software. Verder worden er circa 20 projecten per jaar gestart
waarin een softwareproduct wordt ontwikkeld.
De projecten bestaan uit een projectleider en een groep software engineers, zie
Figuur 19. Bij grote projecten is er soms ook een technisch projectleider aanwezig
is die de software engineering zaken behandeld zodat de projectleider zich kan
richten op de management aspecten. De achtergrond van de software engineers
verschilt, een deel heeft geen IT of software engineering achtergrond en heeft het
programmeren zelf aangeleerd.
Voor de reorganisatie bestond er voor de software engineers een
technologiemanager. In hoofdlijnen was de rol van deze persoon om ervoor te
zorgen dat de juiste technologieën in voldoende mate aanwezig waren binnen
TNO-FEL. In de nieuwe organisatie is deze rol vervangen door een
technologietrekker. Zowel de huidige technologietrekker als de oude
technologiemanager zijn sterk voorstander van software hergebruik. Een andere rol
die invloed heeft op hergebruik van software, is de resource manager. De resource
manager is onder andere verantwoordelijk voor het samenstellen van de
projectteams. De resource manager speelt een aanzienlijke rol in hergebruik omdat
hij de mensen op basis van kennis in een project kan plaatsen. Dit bevordert
hergebruik doordat de software engineers hierdoor eerder artefacten en kennis, die
zijn gecreëerd in voorgaande projecten, hergebruiken.
4.2.4
Voormalig divisie ORB en divisie CCS
De visie en cultuur binnen de voormalige divisies ORB en CCS zijn verschillend.
Binnen voormalig divisie ORB ligt de nadruk sterk op de implementatiefase, het
daadwerkelijke programmeren van de simulator. In voormalig divisie CCS is er
meer aandacht voor het modelleren en specificeren, wat ook tot gevolg heeft dat
het implementeren een stuk minder moeite kost. Dit lijkt ook invloed te hebben op
de manier waarop hergebruik in beide voormalige divisies is vormgegeven. In
voormalig divisie ORB is hergebruik nog sterk adhoc van karakter en gebaseerd op
code hergebruik. Hier moet wel worden opgemerkt dat er een beweging bestaat
richting het hergebruiken van componenten en generieke frameworks. Voormalig
divisie CCS heeft al langere tijd ervaring met het koppelen van simulators, ook op
componentniveau binnen de simulators. Door het hanteren van standaarden zoals
HLA en DIS en de toepassing van technieken zoals Model Driven Architectures
(MDA) is hergebruik binnen voormalig divisie 2 al langere tijd gericht op
generieke architecturen en frameworks met herbruikbare componenten. In dat
opzicht is de samenvoeging van voormalig divisie ORB en voormalig divisie CCS
goed voor hergebruik aangezien de toepassing van hergebruik in divisie CCS kan
dienen als een springplank voor voormalig divisie ORB.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
83
4.2.5
Hergebruik als thema binnen TNO
Hergebruik speelt al geruime tijd binnen TNO-D&V. In 2003 is een groep van
software engineers gevormd, de hergebruikgroep. De hergebruikgroep probeert
draagvlak te creëeren bij de software engineers en concrete invullingen en
oplossingen te geven betreffende hergebruik van software artefacten. Figuur 20
geeft een globaal overzicht van de activiteiten die betrekking hebben op hergebruik
van software artefacten binnen TNO-FEL.
Hergebruik zichtbaarder
Stagiair Tim Hartog
Source Forge voor hergebruik
1ste Stagiair
Source Forge
Workshops SE’rs
Hergebruikgroep
2003
2004
2005
Tijd
Figuur 20 - Overzicht hergebruik-activiteiten binnen voormalig divisie ORB.
Het oorspronkelijke doel vanuit TNO-FEL voor deze afstudeeropdracht was
drieledig.
- Het creëeren van draagvlak onder de software engineers.
- Het dienen als catalysator voor hergebruik van software artefacten binnen
TNO-FEL.
- Het bieden van oplossingen voor problemen die zich voordoen bij
hergebruik van software artefacten.
Al snel bleek echter dat het draagvlak onder de software engineers niet de
beperkende factor zou zijn, maar dat vooral procesmatige en organisatorische
aspecten de drempels vormden en problemen veroorzaakten. Deze aspecten
vormen een belangrijk deel van deze scriptie aangezien er qua processen en
organisatie bijna geen concrete invulling is gegeven aan hergebruik van software
artefacten.
Herbruikbare Artefacten
Verschillende typen software artefacten worden hergebruikt binnen TNO-D&V.
Hoofdzakelijk algemene software artefacten (componenten en code) en soms
domein specifieke software artefacten. In enkele gevallen is er ook sprak van
hergebruik van applicatie frameworks, dit komt in de case studies ook terug.
Tabel 20 toont de lijst van de herbruikbare componenten en frameworks binnen
BU2. Hierbij is, indien bekend, ook een indicatie gegeven van de tijd die erin is
geinvesteerd. Deze indicaties zijn afkomstig van de ontwikkelaars zelf.
Herbruikbaar Bron
Artefact
Functionaliteit
Ontwikkeluren
Database Store + Kibowi
Manager
IDM
Component voor storages & retrieval van data uit de databases.
750 uur
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
84
Statemachine
Kibowi
CSE
(Computer
Simulation
Environment)
Monitor
Kibowi
Kibowi
TNO Mailserver Kibowi
IDM
ORB kernel
Searoads
TBM
Kibowi
ORBAT
Browser
EBF
ASF
(Advanced
Simulation
Framework)
PLF
(Platform
Framework)
EBF
Stealth
EBF
Visual
EBF
VR-Link
EBF
EBF
Doelmodellen
EBF
Terreindatabases EBF
EBF SimCore
EBF
TSA
(TNO
Simulation
Architecture)
EBF
150 uur
Component waarmee met name synchronisatie van werkzaamheden
kan worden beheerd. De gebruiker kan state machines bouwen door
zelf de states, signals en state transitions op te geven. Aan de states en
aan de transities kunnen vervolgens events worden gehangen.
Een framework voor simulatiemodellen. Vormt een schil over de
400 uur
diverse herbruikbare Kibowi MP componenten (generieke GUI,
generieke applicatie, database manager etc.).
Generiek component waarmee informatie van deelsystemen kan
worden opgevraagd en in een aparte module overzichtelijk kan
worden weergegeven. Met name handig om systemen ook run-time te
kunnen volgen.
Component waarmee applicaties in een netwerk onderling (op
inhoudelijk niveau) kunnen communiceren. Het pakket maakt het
mogelijk kanalen te definiëren waarop kan worden uitgezonden en
geluisterd. Applicaties melden zich door middel van RMI aan. Het
pakket schermt met name netwerkprotocollen en unicast, multicast of
broadcast zaken voor de gebruiker af.
Simulatiekernel voor zowel event driven als real time simulaties. De
ORB kernel verzorgt in het bijzonder de juiste scheduling van
activiteiten en het beheer van de tijd.
Tool die kan worden gebruikt om terreinen te ontwikkelen of
importeren uit bestanden.
Dit component creëert een overzicht van alle eenheden binnen een
gevecht op verschillende niveaus (bataljon, brigade, tot aan
individuele eenheden) en geeft hierbij ook de status van de eenheden
aan (actief/uitgeschakeld).
Het ASF vormt de basislaag van EBF applicaties. Het verzorgt de
communicatie tussen de verschillende applicaties. Deze release
ondersteunt de DIS 2.0.4 draft standard en een subset van de HLA
RPR-FOM 0.1.7.
Het PLF is een framework bovenop het ASF. Het bevat een aantal
herbruikbare componenten:
Environment (generieke simulatie omgeving)
PLF Audio (De Audio server verzorgt de weergave van
platform- en omgevingsgeluiden binnen de EBF simulators)
PLF Generic (Deze library bevat generieke subsystemen die
gebruikt kunnen worden binnen PLF.)
PLF Utilities (Algemene utility software classes/functions
gebruikt in diverse EBF software componenten)
Component die het mogelijk maakt om vanuit verschillende
viewpoints in een synthetische omgeving mee te kijken.
3D module voor de visualisering van de omgeving (oppervlak,
hoogte, sculpturen) en entiteiten in deze omgeving.
Toolkit inclusief 3D Stealth, Packet Server en Datalogger. Deze
toolkit biedt ondersteuning voor de ontwikkeling van DIS 2.0.4
compliant applications.
Real-Time geometrische modellen
Er zijn een aantal terreindatabases beschikbaar
Biedt een verzameling van software componenten voor de
ondersteuning van rapid prototyping en hergebruik van software voor
het bouwen van bemande simulators, computer generated forces,
scenario management etc. SimCore omvat drie grote componenten:
Platform Framework (PLF-ASF & PLF-RCI),
Distributed Simulation Standards (DIS, HLA),
Support Modules (visueel, audio, process management/real-time
scheduling, intertool communication, etc.)
Een op HLA gebaseerde simulatie architectuur op component niveau.
Het TSA framework is een implementatie van het TSA concept en
bestaat uit:
1. TSA Infrastructuur,
200 uur
400 uur
500 uur
1200 á 1400 uur
Onbekend
Onbekend
Onbekend
Onbekend
Onbekend
Onbekend
Onbekend
Onbekend
Onbekend
Onbekend
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
85
2. TSA Support tools.
De TSA Infrastructuur bestaat uit:
TSA-RCI, middlewarelaag.
TSA-FMC, representeert een specifieke set componenten als een
Federate.
De TSA Support tools bestaan uit:
TNO-RTI,
TSA Gateway
Di Guy
COST
STK
COTS
LuciadMap
Visual OMT
ITEMS
COTS
COTS
COTS
CASLOGGER
COTS
Ontwikkelomgeving voor het visualiseren van infanterie.
http://www.bdi.com/content/sec.php?section=diguy
Commercieel pakket voor 3D visualisatie voor bijvoorbeeld satellietof raketbanen. http://www.agi.com/products/desktopApp/stkFamily/
Geografisch Informatie Systeem (2D) (library)
Visual editor voor het maken van HLA Object Model Templates
Tool voor het generen Computer Generated Forces in een taktische
omgeving. ITEMS biedt tevens de mogelijkheid om via DIS met
andere simulatiefaciliteiten te interacteren.
After Action Module. Slaat enkele de informatie die over het DISnetwerk wordt verstuurd op zodat het later met een andere applicatie
teruggespeeld kan worden.
N.V.T.
N.V.T.
N.V.T.
N.V.T.
N.V.T.
N.V.T.
Tabel 20 - Beschikbare (grotere) herbruikbare artefacten binnen BU2.
De herbruikbare artefacten in Tabel 20 zijn de grotere componenten en frameworks
waar vele uren in zijn gestoken om ze te ontwikkelen. Indien deze worden
hergebruik levert dit ook een flinke besparing ten opzichte van het ontwikkelen
vanuit niets. Naast deze herbruikbare artefacten wordt er ook nog veel op adhoc
basis hergebruikt. Hergebruik is daarbij sterk gericht op code hergebruik. De
software artefacten, die hergebruikt worden, zijn niet altijd specifiek voor
hergebruik ontworpen. De geïnterviewde software engineers geven wel aan dat de
ontwikkelde software veelal zo generiek mogelijk opgezet wordt. In het geval van
hergebruik worden de bestaande software artefacten zowel als black box en als
white box hergebruikt.
Hergebruik is veelal nog onzichtbaar; software engineers gebruiken stukken code
of componenten die zijn ontwikkeld in andere projecten. Deze componenten en
stukken code komen uit verschillende bronnen.
- ‘Voorraad’ zelf ontwikkelde code.
- Software artefacten uit projecten waaraan de software engineer
deelgenomen heeft.
- Code van collega’s.
- Internetbronnen (commercieel en open source.)
De documentatie bij de herbruikbare artefacten varieert sterk. Vaak is de
documentatie zeer beperkt of niet aanwezig. Dit hangt vooral samen met de bron
van het artefact en het type artefact. Commerciële componenten zijn goed voorzien
van informatie en bevatten gebruikershandleidingen waarmee de ontwikkelaars
voldoende uit de voeten kunnen. Java libraries of Javabeans zijn bijvoorbeeld
voorzien van javadoc waardoor de software engineers snel een goed inzicht kunnen
krijgen in de beschikbare interfaces. Van de herbruikbare artefacten die binnen
M&S zijn ontwikkeld is de mate van documentatie ook variabel. Voor sommige
componenten die veel hergebruikt worden zoals de ORB Kernel is er goede
ontwerpdocumentatie beschikbaar en is er een gebruikershandleiding geschreven.
Hier was echt budget voor beschikbaar. Bij stukken code die door software
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
86
engineers zelf is geschreven of uit projecten is gehaald is de documentatie vaak
niet aanwezig.
Zoals gezegd worden de software artefacten zowel black box als white box
hergebruikt. Aangezien hergebruik veel adhoc gebeurt en op code is gericht, vindt
overwegend white box hergebruik plaats. Commerciële pakketten, bijvoorbeeld het
geografisch informatie systeem LuciadMap, worden hoofdzakelijk als black box
gebruikt. Deze producten bieden vaak nog wel de mogelijkheid om aangepast te
worden (parameterisatie).
De Hergebruik Groep heeft een aantal voorwaarden opgesteld waaraan een
herbruikbaar component dient te voldoen.
- De broncode van een component mag maar op één plaats in SourceForge
worden beheerd.
- De meerwaarde van het component moet project overschrijdend zijn.
- De naam van het component moet onder andere aangeven in welke taal het is
ontwikkeld (Java, Delphi, C++).
- Het bijvoegen van projectgerelateerde files ( InstallatieScript, voorbeeld
applicatie, Project ontwikkelfiles ) is verplicht.
- Indien enkele van de aan het component gerelateerde files al onder
SourceForge staan, dan moet hiernaar gerefereerd worden.
Een herbruikbaar component wordt door de hergebruikgroep als volgt
gedefinieerd:
“Een reuseable component is een, binnen TNO-FEL openbaar verkrijgbaar, stuk
herbruikbare code, dat onderdeel uitmaakt van minstens één binnen TNO-FEL
ontwikkelde applicatie. Een component wordt wel onderhouden binnen TNO-FEL.
Een reuseable component is ongerubriceerd. Kleine reusable componenten of
delen ervan die erg klein zijn kunnen worden toegevoegd aan een Componenten
Library.”
Er wordt hierbij ook een onderscheid gemaakt met herbruikbare tools, die zijn als
volgd gedefinieerd:
“Een reuseable tool is een, openbaar verkrijgbare, applicatie ( of methode
beschrijving ) die geen onderdeel uitmaakt van de te ontwikkelen applicatie, maar
wel bijdraagt aan het versnellen van het ontwikkelproces of aan de uitbreiding van
de functionaliteit van de te ontwikkelen executable. Een tool wordt niet
onderhouden binnen TNO-FEL. Een reuseable tool is ongerubriceerd.”
Aan een herbruikbare tool worden de volgende eisen gesteld:
- bestaat uit een package met daarin een readme.txt en een zipfile met daarin de
her te gebruiken tool.
In de readme.txt dient de volgende informatie opgenomen te worden:
- naam van het product,
- categorie. Hier is nog geen verdere aandacht aan besteedt aangezien
SourceForge dit voorlopig nog niet ondersteund. Voorbeelden van
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
87
-
categorieen zijn Network, GUI, Kernel, SE Fundamentals, special
functionality,
keywords,
beschrijving,
aanspreekpunt (intern/extern),
gebruiksaanwijzingen,
installatieprocedure,
indien van toepassing: Gerelateerde links & FAQ.
JAVA is formeel de standaard programmeertaal. Nieuwe projecten dienen in deze
taal te werken. Hier wordt echter pragmatisch mee omgegaan. Nieuwe projecten
die zijn gebaseerd op oude projecten waarbij bijvoorbeeld in delphi, C of C++ is
ontwikkeld worden waarschijnlijk weer in die programmeertaal uitgevoerd
vanwege de grote hoeveelheid reeds aanwezig code. De projectleiders hebben ook
de vrijheid om die keuze te maken.
De manier waarop hergebruik van software artefacten binnen TNO-D&V is
vormgegeven, wordt vanuit de procesinvalshoek en de organisatie invalshoek
bekeken.
Procesinvalshoek
Hieronder worden de productie (design for reuse), consumptie (design with reuse)
en ondersteunende processen met betrekking tot herbruikbare software artefacten
besproken. Tevens wordt het managen van deze processen besproken.
Productie
Zoals in Figuur 21 is te zien, zijn er twee momenten waarop de herbruikbare
artefacten worden geproduceerd. Dit gebeurt zowel in het project waarin het
originele component is ontwikkeld als in andere projecten waar het component uit
project A in project B wordt ge-reëngineerd. Het komt ook voor dat een component
uit project A wordt aangepast in project B, waarbij later voor project C het
component uit project B weer wordt aangepast. Dit gebeurt vooral met kleine
componenten en stukken code. Vaak is dit onzichtbaar omdat het op initiatief van
software engineers plaatsvindt. Hierbij moeten ze voor project B iets ontwikkelen
waarbij ze code die ze in project A hebben ontwikkeld kunnen hergebruiken.
Project - A
Ontwikkelen
code/componenten
Project - B
Re-engineren
beschikbaar component
t.b.v. herbruikbaarheid
Re-engineren
code/component uit ander
project t.b.v.
herbruikbaarheid en
toepasbaarheid in project B
Herbruikbaar Artefact
Herbruikbaar Artefact
Tijdslijn
Figuur 21 - Productie van herbruikbare artefacten binnen BU2 van TNO-D&V.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
88
In enkele gevallen komt het voor dat grotere herbruikbare componenten worden
ontwikkeld. Voorbeelden hiervan zijn de ORB kernel, die hoofdzakelijk binnen
Searoads is ontwikkeld of de databasestore & manager en mailserver die binnen
Kibowi zijn ontwikkeld. Dit wordt in de case studies verder besproken.
Er is geen duidelijk proces of strategische keuze voor de productie van
herbruikbare artefacten. Er is ook geen standaard of informatie voorhande over hoe
iets herbruikbaar gemaakt dient te worden. Dit gebeurt nu allemaal naar eigen
inzicht en is dus gebaseerd op toeval. Dit is niet direct een showstopper, maar het
kan wel leiden tot dubbele herbruikbare artefacten, slechte ‘herbruikbare’
artefacten, onnodige investeringen en het missen van goede mogelijkheden voor
hergebruik.
Consumptie
Het hergebruiken van software artefacten vindt veelal adhoc plaats. Een deel van
de software engineers bekijkt, voordat ze beginnen met programmeren, wel of er al
iets naar hun wensen ontwikkeld is. Het bestaan van veel (herbruikbare) software
artefacten is echter nog relatief onbekend, mede doordat nog lang niet alles is
opgeslagen in een centrale repository. Hergebruik komt dus laat het
softwareontwikkelproces in en het vinden van een herbruikbare artefacten is
afhankelijk van het sociale netwerk van de software engineers.
De geinterviewde software engineers geven aan dat de keuze om iets te
hergebruiken op verschillende factoren gebaseerd:
- aanwezigheid broncode,
- aangeboden functionaliteit,
- mate van ontwikkeling van het artefact (status, aantal bugs die verholpen
zijn, nog open staan en hoelang staan deze bugs al open staan),
- voorbeeld van gebruik,
- platvorm waarvoor het is ontwikkeld,
- ondersteuning en onderhoud van het artefact,
- het moet los te gebruiken zijn, plug & play.
Verder lijkt de overtuigingskracht van andere software engineers ook een sterke
invloed te hebben op de keuze om iets te hergebruiken. Er is geen standaard
beschikbaar op basis waarvan de software engineers kunnen besluiten iets te
hergebruiken en het gebeurt zelden dat er een kosten/baten analyse wordt gemaakt.
Indien er een geschikt herbruikbaar artefact wordt gevonden, is de manier waarop
het wordt hergebruikt sterk afhankelijk van de bron van het herbruikbare artefact.
Code van collega’s of uit andere projecten wordt vaak als white box behandeld. Bij
andere herbruikbare artefacten zoals de ORB Kernel of artefacten uit externe
bronnen is de documentatie over het algemeen goed in orde en is hergebruik deels
om die reden mogelijk. Het komt ook voor dat er een wrapper voor het
herbruikbare artefact wordt ontwikkeld of dat het middels parameterisatie her te
gebruiken is.
Projectleiders hebben er bij uitstek baat bij dat er in hun project gebruik wordt
gemaakt van herbruikbare artefacten indien dit de kwaliteit of functionaliteit van
het software product niet schaadt. Om diverse redenen (zowel van projectleiders als
software engineers) wordt hier echter van afgezien.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
89
-
Geen ondersteuning bij het herbruikbare artefacten.
Bestaan van het herbruikbare artefact is onbekend.
Gebrek aan vertrouwen in kwaliteit. Het is immers niet zelf ontwikkeld.
Geen of matige documentatie (minder noodzakelijk indien er
ondersteuning beschikbaar is).
Het levert een beperking op omdat het anders werkt dan men zelf zou
willen. “Met hergebruik voldoet de applicatie niet 100% aan de wensen
van de klant.”
Ondersteuning en beheer
De manier waarop er invulling is gegeven aan ondersteuning en beheer bij de
beschikbare herbruikbare artefacten verschilt.
Sommige grote componenten zoals de ORB Kernel of de MOSES-kernel (c++
tegenhanger van de ORB Kernel) hebben voor een periode een budget toegewezen
gekregen. Hierdoor is het mogelijk het component onafhankelijk van projecten te
blijven onderhouden en beheren. Vaak is dit budget echter niet aanwezig en is de
ontwikkeling afhankelijk van de beschikbare tijd binnen projecten waarin het
ontwikkeld en hergebruikt wordt. Indien een project ophoudt, verdwijnt vaak ook
de ondersteuning en het beheer van het herbruikbare artefact. Wat wel voorkomt is
dat een project de ontwikkelaar van een herbruikbaar artefact ‘inhuurt’, indien deze
daartoe bereid is en tijd beschikbaar heeft. Op deze manier is er toch ondersteuning
bij de herbruikbare software artefacten.
Bij deze twee voorbeelden, de ORB Kernel en de MOSES-kernel, is er ook een
verschil te zien in het beheer. De ORB Kernel wordt door één persoon beheerd die
tevens verantwoordelijk is voor de ontwikkeling van het artefact. Voor MOSES is
enige uitleg nodig. Het MOSES framework bestaat uit een simulatie kernel en een
repository met daarin verschillende objecten die bij de simulaties gebruikt kunnen
worden. Het kan worden gezien als een gezamenlijk omgeving waarin meerdere
simulatiemodellen ontwikkeld worden. Er is echter geen beheer, van de objecten in
deze repository, aanwezig. Het is dan ook geen uitzondering dat er voor project X
in object A iets wordt gewijzigd waardoor er bij project Y problemen optreden.
Veel hergebruik is beperkt tot broncode niveau, afkomstig van eigen werk of
collega’s. In deze adhoc vorm van hergebruik is er geen configuratie management,
centraal beheer, distributie en onderhoud geregeld. Dit is allemaal afhankelijk van
de inzet van individuele software engineers.
Management
Op management niveau is weinig over hergebruik nagedacht. Top Management
support is vooralsnog dan ook niet aanwezig. Een meer systematische vorm van
hergebruik is gestart vanuit een groep software engineers. In het begin stonden veel
software engineers hier zeer kritisch tegenover maar tegenwoordig lijkt een groot
deel van de software engineers hier toch positiever tegenover te staan. Wat nog
ontbreekt is het Top Management support.
Sturing
Qua sturing en coördinatie is er voor de productie en consumptie van herbruikbare
artefacten nagenoeg niets geregeld. Er is geen sturing over de projecten heen
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
90
betreffende de productie van herbruikbare artefacten. Ook binnen de projecten is de
sturing over het algemeen zeer beperkt. De software engineer maakt vaak zelf de
keuze, de projectleider is hier niet bij betrokken. Een projectleider heeft er zelf ook
geen baat bij dat binnen zijn project iets herbruikbaar wordt gemaakt, het kost hem
immers alleen maar tijd en budget. Qua consumptie geldt hetzelfde, het is de
software engineers en projectleiders volledig vrij om hierin een keuze te maken.
Dit wordt ook veroorzaakt doordat niet alle projectleiders voldoende kennis hebben
van software engineering en omdat hergebruik niet bij alle projectleiders niet
bekend is.
De voormalig technologiemanager heeft een grote rol in het creëren van draagvlak
voor het hergebruiken van software artefacten en probeert de software projecten
hier zoveel mogelijk bij te betrekken. Zijn betrokkenheid is echter beperkt
aangezien hij niet de tijd en middelen heeft om bij elk project betrokken te zijn. De
huidige technologietrekker is ook sterk voorstander van hergebruik. Tevens heeft
hij een grotere invloed op de projecten. In deze positie kan hij de rol van champion
voor hergebruik vervullen.
Procedures & standaarden
Om projecten te begeleiden bij de invulling van het softwareontwikkelproces en
het produceren van de ondersteunende documentatie is het IT/QA forum opgericht.
Het IT/QA vervult puur een faciliterende functie. De doelen van het IT/QA zijn:
-
het bieden van standaarden en templates voor de software ontwikkeling,
het uitbreiden en onderhouden van deze standaarden en templates,
Ondersteuning en advies bieden bij het toepassen van deze standaarden en
templates.
Het ITQA heeft verschillende procedurele standaarden gedefinieerd voor het
software engineering proces. Voor hergebruik omvat dit onder andere procedurele
standaarden voor Configuratie Management, Problem en Change Management en
verschillende testprocedures. Verder heeft het ITQA standaarden gedefinieerd voor
wat betreft een aantal talen waarin geprogrammeerd wordt, hiervoor zijn
handleidingen beschikbaar voor het programmeren in ADA, C en C++ (gebaseerd
op de Ellemtel C++ standaard) en voor het programmeren in Java wordt er
verwezen naar de Java Sun code conventies. In Bijlage F zijn alle procedures te
vinden die door het ITQA zijn opgesteld, ook wel Codes of Practice genoemd.
Het werken volgens deze Codes of Practice is niet verplicht maar dient als een
hulpmiddel voor de projectleiders en software engineers. De projecten worden
echter wel via audits gecontroleerd op de gehanteerde werkwijze en de
aanwezigheid van de verschillende producten uit het software engineerg proces. De
auditeurs hebben echter geen software engineer achtergrond en kunnen derhalve
alleen naar de aanwezigheid van bepaalde documenten en processen kijken.
Van standaardisatie van de software producten die ontwikkeld worden is er
momenteel nog geen sprake.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
91
Organisatie invalshoek
Op organisatie niveau is praktisch nog niets geregeld voor hergebruik. Er zijn geen
formele afspraken gemaakt over verantwoordelijkheden voor ondersteuning,
onderhoud, verrekening en eigendom van de herbruikbare artefacten. De invulling
van deze aspecten gebeurt veelal adhoc zonder enige standaardisatie tussen de
projecten. Er zijn hier wel enkele uitzonderingen op, dit is ook te zien zijn bij de
case studies.
Hergebruik is opgestart door de software engineers en de voormalig
technologiemanager. Het geheel is momenteel puur een aangelegenheid van de
software engineers. Het management is er nog niet bij betrokken. De voormalig
technologiemanager formuleert dit als volgt: “je moet het gras van onderaf laten
groeien”. Indien er voldoende support bestaat onder de software engineers en
hergebruik ook een positieve invloed heeft op de resultaten, zal het Top
Management daar ook eerder in meegaan.
Financiering van de productie is momenteel niet geregeld. Het komt hoofdzakelijke
vanuit de budgetten van de projecten waarin de herbruikbare artefacten worden
ontwikkeld. Dit creëert een drempel aangezien projectleiders worden afgerekend
op onder andere de financiële resultaten van hun project. De ondersteuning voor
hergebruikers is gebaseerd op directe verrekening. De beheerder van het
herbruikbare artefact wordt voor een korte tijd ingehuurd door het project waarin
het artefact wordt hergebruikt. Op deze manier wordt ook vaak in het onderhoud
van de herbruikbare artefacten voorzien.
TNO-FEL heeft halverwege 2003 de tool SourceForge 10 aangeschaft. Vanuit de
divisie Command Control en Simulatie en de hergebruikgroep van de divisie
Operation Research hergebruikgroep is hiertoe besloten. De tool is aangeschaft om
twee redenen.
1. Uniforme wijze voor projectmanagement.
2. Repository voor hergebruik van software artefacten.
SourceForge is een centrale opslagplaats waarin de projecten, maar ook de
herbruikbare software artefacten, beheerd kunnen worden. Het biedt functionaliteit
voor versiebeheer, configuratiemanagement, bugtracking, het toewijzen van taken
en voeren van discussies. Momenteel zijn er enkele herbruikbare software
artefacten opgenomen in SourceForge. Sommige herbruikbare artefacten zijn hierin
publiekelijk toegankelijk voor potentiële hergebruikers, andere zijn afgeschermd
zodat er eerst toegang tot het artefact moet worden aangevraagd. SourceForge
wordt ook gebruikt voor normale (software) projecten die niets met hergebruik te
maken hebben. Aangezien er nog geen classificatie beschikbaar is in SourceForge,
kan het lastig zijn een specifiek artefact te vinden. De herbruikbare artefacten
worden namelijk op dezelfde manier als een normale software projecten
10 Dit betreft de ‘Enterprise Edition’. Zie http://www.vasoftware.com/sourceforge/
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
92
opgenomen in SourceForge en met ruim 120 projecten in SourceForge kan een
herbruikbare artefact lastig te vinden zijn.
Hergebruik binnen TNO-FEL volgens het RMF
In § 3.4.5 is het Reuse Maturity Framework van Koltun en Hudson geïntroduceerd.
In Tabel 32 in Bijlage B is dit Reuse Maturity Framework opgenomen. Aan de
hand van dit framework kan het niveau van hergebruik binnen M&S getypeerd
worden. In deze Tabel 32 geven de groen gearceerde hokjes het niveau van TNOFEL op de betreffende aspecten aan, dit wordt in Tabel 21 toegelicht. Hergebruik
binnen BU2 is volgens dit raamwerk te typeren als initieel/chaotisch.
Dimension of
maturity
Situatie binnen BU2 TNO-D&V
Motivation &
Culture
Het hergebruiken van software artefacten is met een opwaardse mars
bezig binnen TNO-D&V. Waar de software engineers er 1 á 2 jaar
geleden nog zeer kritisch of negatief tegenover stonden is er nu een
breder draagvlak ontstaan. Een belangrijke rol hierin speelt de voormalig
technologietrekker die zelf zeer positief tegenover hergebruik staat en
andere mensen hier ook in probeert te betrekken. Vanuit het
management is er nog geen mening uitdragen over hergebruik.
Het rekening houden met mogelijkheden voor hergebruik komt beperkt
voor. Het is vooral afhankelijk van de samenstelling van een projectteam
of er rekening wordt gehouden met hergebruik.
Hergebruik is momenteel nog een aangelegenheid van de (veelal
individuele) software engineers. Er is een hergebruikgroep opgericht,
bestaande uit software engineers, maar deze heeft geen zeggenschap of
authoriteit om hergebruik te bevorderen.
Momenteel ligt de verantwoordelijkheid voor hergebruik puur bij de
software engineer. Het is ook vaak de keuze van een individuele
software engineer of een projectteam om een herbruikbaar artefact te
hergebruiken.
Omdat er nog geen formele procedures zijn opgesteld voor hergebruik,
is het onduidelijk waar hergebruik in de huidige situatie het software
engineering proces binnenkomt. In enkele gevallen is dit reeds vroeg in
het proces, tijdens de ontwerpfase en requirementsfase, vaak gebeurt dit
echter pas wanneer men begint met het implementeren.
SourceForge biedt momenteel nog geen classificatiemogelijkheden. De
projecten voor herbruikbare artefacten staan dan ook tussen de reguliere
softwareprojecten. Er is geen structuur aanwezig.
Niet aanwezig.
Planning for
reuse
Breadth of
reuse
involvement
Responsibility
for making
reuse happen
Process by
which reuse is
leveraged
Reuse inventory
Classification
activity
Technology
support
Metrics
Legal,
contractual,
accounting
consideration
Er is een centrale repository (SourceForge) beschikbaar. Tevens zijn er
tools beschikbaar voor ConfiguratieManagement en VersieBeheer
(CVS, smartCVS). Deze tools zijn niet specifiek voor hergebruik.
Niet aanwezig.
Momenteel is dit nog een beperkende factor in de toepassing van
hergebruik binnen BU2. Er is geen verrekening voor de productiekosten
van de herbruikbare artefacten en gerubriceerde artefacten
mogen/kunnen niet hergebruikt worden vanwege de rubricering. Bij
software die aan klanten wordt verkocht, wordt zoveel mogelijk
geprobeerd de rechten van eigendom van die software binnen TNO te
houden.
Tabel 21 - Hergebruik binnen BU2 volgens het Reuse Maturity Framework.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
93
4.3
Case studies
Deze paragraaf analyseert de drie case studies die zijn uitgekozen op basis van
verschillen in de scope van hergebruik en verschillen in het niveau van hergebruik.
Bij elk van de drie case studies is hergebruik echter wel duidelijk zichtbaar. De drie
case studies worden eerst per stuk besproken en daarna gezamenlijk geanalyseerd
aan de hand van het theoretische raamwerk uit § 3.7. Tevens zal er een indicatie
worden gegeven van het resultaat van hergebruik binnen de drie case studies.
4.3.1
ORB Kernel
De ORB Kernel is een java simulatie kernel die bedoelt is voor object
georiënteerde, event driven simulaties. Deze kernel is gebaseerd op kennis die is
opgedaan bij de ontwikkeling van soortgelijke kernels in de talen C++ en delphi
(respectievelijk de MOSES en SURPASS-kernel). De ORB Kernel is destijds
ontwikkeld voor het project Searoads11, een simulatie model voor maritieme
luchtverdediging. Later is deze kernel losgekoppeld van dit specifieke
simulatiemodel en verder ontwikkeld als losstaande simulatiekernel. Tegenwoordig
vormt het de basis voor veel nieuwe simulatie-modellen die ontwikkeld worden.
Deze case is uitgekozen vanwege een aantal redenen. Ten eerste is het een
voorbeeld waarbij het beheer van het software artefact op een informele manier
goed geregeld lijkt te zijn. Tevens is de ORB Kernel een bekend begrip bij de
meeste software engineers en wordt het ook daadwerkelijk regelmatig hergebruikt.
Het artefact
Een simulatiekernel is slechts een onderdeel van een groter geheel. Typisch ziet de
architectuur van een simulatie-model er zoals in Figuur 22 uit [WIT02].
GUI
External Observers
Output
File
Kernel
RunController
Parser
Input
File
Model
Figuur 22 - Typische architectuur van een simulatie-model [WIT02].
GUI
RunController
Parser
Kernel
Model
Externe Observers
Verzorgt de interactie met de gebruikers.
Stuurt één of meerdere simulatie-runs aan
Leest de simulatie-file in.
Stuurt de simulatie aan (dit is het hart van de simulatie).
Bevat de simulatie-objecten.
Visualisatie en verzamelen uitvoer.
11 Voor meer informatie over Searoads zie: http://www.tno.nl/defensie_en_veiligheid
/militair_optreden/operational_analysis/ searoads_simulation,_eval/
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
94
De simulatiekernel zorgt voor het voortschrijden van de tijd in een simulatie en
voor het op een juiste manier verwerken en afhandelen van events die door de
simulatie-objecten worden gegenereerd. Het voortschrijden van de tijd in de kernel
wordt bepaald door de tijd waarop het volgende event wordt uitgevoerd. Hierbij
kan er gekozen worden dit real-time (theKernel.setMode(“real time”)) danwel ‘As
fast as possible’ (theKernel.setMode(“as fast as possible”)) te doen [DON05]. Bij
de real-time modus bestaan er ook methoden om dit x keer realtime te doen.
Bijvoorbeeld 2x realtime, dus 2 maal de werkelijke snelheid. Verder is de ORB
Kernel HLA12 compliant (voor de interoperabiliteit), biedt het mogelijkheden voor
de visualisatie van de simulatie en biedt het mogelijkheden om de kernel te
koppelen aan source code in andere talen (delphi, C++).
De ORB Kernel biedt dus essentiele functionaliteit voor een simulator waarbij het
tevens verschillende mogelijkheden biedt voor de hergebruiker. De ORB Kernel is
voorzien van javadoc voor de interface beschrijvingen, ontwerpdocumentatie en
een programmeurshandleiding waarin wordt toegelicht hoe de kernel te gebruiken
is [DON05]. In deze programmeurshandleiding wordt tevens een voorbeeld van het
gebruik van de kernel uitgewerkt.
In SourceForge is de ORB Kernel publiekelijk, binnen TNO-D&V, beschikbaar
gesteld. Hierbij kunnen hergebruikers de ORB Kernel als een package (in een .jar
file) downloaden, de source is echter ook beschikbaar en kan zo gedownload
worden. Over het algemeen wordt de ORB Kernel als black box hergebruikt. De
ORB Kernel is geschreven volgens de java code convention. Gezien de goede
documentatie en beschrijving van de interfaces is de ORB Kernel goed als black
box her te gebruiken. Bij de ORB Kernel is er tevens een scenario parser
beschikbaar die een scenario naar het juiste formaat kan transformeren.
Procesinvalshoek
Productie
De ORB Kernel is initieel ontwikkeld voor het Searoads project. In het begin zat de
kernel ingebakken in de simulatie. Toen vanuit een ander project (Gunmodel) de
wens werd geuit om de kernel te hergebruiken, is deze uit het Searoads model
gehaald en als losstaande kernel verder ontwikkeld.
Consumptie
De ORB Kernel is een welbekende kernel binnen BU2. In een flink aantal
projecten (is en) wordt de kernel hergebruikt. Het gebruik van de kernel wordt niet
opgelegd, maar de (informeel) verantwoordelijke speelt wel een sterk faciliterende
en informerende rol. Indien er nieuwe projecten starten waarin de kernel gebruikt
12 HLA staat voor High Level Architecture en is binnen de Modelling en Simulation
gemeenschap een veelgebruikte standaard. HLA is een herbruikbare software
architectuur voor de ontwikkeling en executie van gedistribueerde simulatie
objecten en applicaties [TUR99]. IEEE 1516 beschrijft de HLA standaard.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
95
zou kunnen worden, gaat hij langs om dit te bespreken. De keuze om de kernel
daadwerkelijk her te gebruiken ligt bij de projecten.
Ondersteuning & beheer
De (informeel) verantwoordelijke voor de ORB Kernel verzorgt ook de
ondersteuning aan de hergebruikers. Inmiddels zijn er meerdere mensen die met
deze ORB Kernel kunnen werken, deze worden vaak ook opgenomen in de
projecten waar de kernel gebruikt gaat worden. Dit is ook belangrijk, ervaring in
het gebruik van de ORB Kernel is een katalysator voor zowel het hergebruik als de
benodigde tijd om het her te gebruiken. Er is geen formele vorm van beheer op de
ORB Kernel. De huidige versie van de ORB Kernel is stabiel en eventuele
onderhoud gebeurt binnen projecten die gebruik maken van de ORB Kernel of
binnen Searoads.
Organisatie invalshoek
Formeel is er niets geregeld voor de ORB Kernel. Informeel is er wel iemand die
zich hier voor beschikbaar stelt. Deze persoon verzorgt het beheer en de
ondersteuning voor de ORB Kernel. Tevens is hij degene die andere projecten
stimuleert de ORB Kernel te hergebruiken. Dit is dus allemaal volledig informeel
georganiseerd en sterk verbonden aan de inzet van één (of een beperkt aantal)
individu(en). Deze organisatie structuur voor het beheer en de ondersteuning lijkt
sterk op het ‘lone producer’ model zoals staat beschreven in § 3.5.3, maar dan op
een informele manier.
Qua verrekening is er niets formeel geregeld. In de praktijk is de productie van de
ORB Kernel deels bekostigd vanuit een vast budget (budget voor verkennend
onderzoek) en deels vanuit het project Searoads. Het gebruik van de ORB Kernel
door andere projecten is gratis. Beheer en ondersteuningsactiviteiten worden over
het algemeen geschreven op de projecten waarvoor de werkzaamheden worden
uitgevoerd.
KIBOWI Multi Platform (PM)
Kibowi MP is een stafproceduretrainer. Het doel van Kibowi MP is primair het
trainen van officieren op bataljon, brigade en divisie niveau in zogenoemde ‘train
as you fight’ simulaties. Kibowi heeft een lange geschiedenis. Al begin jaren 1990
werd er gebruik gemaakt van een demo versie van het systeem, destijds geschreven
in ADA. Door de loop der jaren is het systeem uitgebreidt en verder ontwikkeld.
Op 31 januari 2005 heeft TNO in samenwerking met Ordina en Capgemini een
tenderprocedure gewonnen voor de ontwikkeling van ‘Kibowi Multi Platform’13.
Dit systeem is geschreven in Java. Deze case study gaat ook specifiek over dit
project, Kibowi MP.
13 Voor meer informatie zie www.kibowi.com en
http://www.tno.nl/defensie_en_veiligheid/militair_optreden/operational_analysis/t
he_command_and_staff_tra/
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
96
Deze case is uitgekozen, omdat er bij de ontwikkeling van het systeem gebruik is
gemaakt van herbruikbare artefacten. Tevens zijn er delen van Kibowi MP al
tijdens de ontwikkeling van het systeem herbruikbaar gemaakt. Een groot aantal
van deze onderdelen worden ook hergebruikt in een ander project, SCOPE. De
herbruikbare artefacten die tijdens het project Kibowi MP zijn ontwikkeld, zijn
relatief nieuw. Daarom worden deze nog weinig hergebruikt. Om deze reden wordt
specifiek de relatie tussen Kibowi MP en SCOPE bekeken.
SCOPE heeft een heel andere doel met haar simulatiemodel, namelijk het
simuleren van oorlog en gevechtsituaties voor kleine teams van soldaten om inzicht
te krijgen in de psychologische gevolgen en afwegingen die er worden gemaakt.
Voor de ontwikkeling van SCOPE wordt echter een zeer groot deel van de
architectuur en de componenten van Kibowi MP overgenomen. Een interessant
detail is dat SCOPE een beperkt budget ter beschikking heeft, slechts een klein
percentage van het budget dat voor Kibowi MP beschikbaar is. Zonder de
mogelijkheid tot hergebruik van software artefacten uit Kibowi zou het SCOPE
project niet (met dat budget) uitgevoerd kunnen worden.
De artefacten
In Figuur 23 wordt het generieke framework van de applicatie Kibowi MP
getoond. In dit figuur is ook aangegeven welke componenten als black box
hergebruikt zijn en welke componenten als white box.
Applicaties
Control
Observer
Entity Editor
Otas Editor
Kibowi Application
Administrator
Kibowi GUI*
Evaluator
Permissions
Phoenix
Database definitions
Computer
Simulation
Environment
TNO
System
API’s
Generic GUI*
Generic Application*
Mail*
Messages
Database
Management* Coordinates Graph
*
State Machine*
GLF
GIS*
ORB Kernel*
Helpers*
Monitor*
Events
ModelParameters
Expressions*
Versioning*
Het component uit
deze laag met een * is
als white box
hergebruikt in SCOPE.
De componenten uit
deze twee lagen zijn
applicatie
onafhankelijk. De
componenten met een
* zijn als black box
hergebruikt in SCOPE.
Figuur 23 - Hergebruikte componenten uit KIBOWI MP.
Dit framework bestaat uit vier lagen. In Bijlage G wordt de functionaliteit van de
verschillende componenten kort toegelicht. De onderste twee lagen zijn applicatie
onafhankelijk en kunnen in verschillende simulators hergebruikt worden. De
phoenix laag is specifiek voor Kibowi geschreven. Hier kan weinig direct
hergebruikt worden. In SCOPE is wel gebruik gemaakt van Kibowi GUI door het
op code niveau te wijzigen, het is echter toeval dat dit hergebruikt kan worden
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
97
binnen SCOPE. Veel van de componenten die in deze Phoenix laag worden
getoond, zijn in Scope ook aanwezig. Scope heeft ook een Scope applicatie,
databasedefinities, messages en permissions en events. Deze zijn echter opnieuw
voor SCOPE ontwikkeld.
De componenten uit de ‘TNO System API’s’ laag zijn voorzien van Javadoc en
kunnen veelal op basis daarvan hergebruikt worden. Deze componenten zijn ook
apart opgenomen onder SourceForge. Voor de State Machine dient de gebruiker
zelf de states en transitions op te geven voordat het gebruikt kan worden. De
Generic GUI en Generic Application moeten gespecialiseerd worden door de
hergebruiker. Het CSE is als herbruikbaar framework op SourceForge gezet. Voor
alle herbruikbare componenten van Kibowi MP die zijn opgenomen in
SourceForge geldt dat deze niet direct toegankelijk zijn. Hiervoor dient eerst
toegang aangevraagd te worden bij de beheerder van het artefact.
Aangezien zowel Kibowi MP als Scope nog volop in ontwikkeling zijn, is dit
framework nog niet definitief. Het komt nog regelmatig voor dat de ontwikkelaar
van SCOPE delen in de phoenix laag ontdekt die hier niet in thuis horen. De
desbetreffende delen zijn vaak niet specifiek voor SCOPE of Kibowi MP aan te
merken en zijn generiek genoeg om naar een lager niveau geplaatst te worden.
Verder is Kibowi MP HLA compliant en loopt momenteel de discussie om een
aantal componenten ook HLA compliant te maken.
Procesinvalshoek
Productie
De voormalige technologiemanager heeft een sterke inspraak gehad in de
samenstelling van het projectteam van Kibowi MP. Bij de projectsamenstelling is
gekozen voor mensen die verstand hebben van JAVA en mogelijk kennis en
ervaring hebben van andere projecten, die belangrijk kan zijn voor Kibowi MP. De
productie van herbruikbare artefacten vindt binnen het Kibowi MP project plaats,
waarbij de artefacten zowel direct herbruikbaar worden gemaakt als dat ze op basis
van re-engineering herbruikbaar worden gemaakt. De voormalige
technologiemanager heeft ook hierop een sterke invloed gehad. Momenteel is er
nog geen documentatie beschikbaar bij de herbruikbare componenten die in
Kibowi MP zijn ontwikkeld en in Scope worden hergebruikt. Javadoc is wel
aanwezig dus de interfaces van de componenten zijn beschreven. Dit is echter niet
voldoende om de artefacten direct te kunnen hergebruiken.
Consumptie
Deze subparagraaf is tweeledig. Er wordt ingegaan op de consumptie van
herbruikbare artefacten binnen Kibowi MP en de consumptie van herbruikbare
artefacten binnen SCOPE.
Bij de ontwikkeling van Kibowi MP is van verschillende herbruikbare artefacten
gebruikt gemaakt. Dit is vooral gebeurd vanwege het feit dat de projectleden
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
98
ervaring hadden met deze artefacten en omdat ze zelf vanuit de filosofie ‘beter
goed gejat dan slecht gemaakt’ werken.
Binnen SCOPE worden zowel de architectuur als een groot aantal van de in
Kibowi MP ontwikkelde componenten hergebruikt. Vanwege het beperkte budget
van SCOPE is dit project sterk gericht op het hergebruiken van bestaande
componenten en oplossingen. Het project wordt impliciet gedwongen tot
hergebruik. Aangezien de componenten uit Kibowi MP nog niet voorzien zijn van
een gebruikershandleiding of voorbeeld van gebruik is de ontwikkelaar van het
SCOPE project afhankelijk van de support vanuit Kibowi MP en de toegang tot de
broncode van de herbruikbare artefacten.
Ondersteuning & beheer
Er is formeel niets geregeld voor de ondersteuning en het beheer van de, in Kibowi
MP ontwikkelde, herbruikbare artefacten. Het beheer vindt plaats binnen het
Kibowi MP project aangezien dit project ook nog niet afgerond is. Qua
ondersteuning lost SCOPE dit op door de mensen die in Kibowi MP aan een
specifiek artefact hebben gewerkt in te huren. Deze personen helpen bij het
hergebruiken van de specifieke artefacten binnen SCOPE. Dit gebeurt echter deels
in direct contact zonder tussenkomst van SourceForge. Dit heeft tot gevolg dat de
projectleider niet alles kan overzien en coördineren. Om te voorkomen dat er
conflicten optreden heeft de projectleider van Kibowi MP een aantal afspraken
opgesteld waar hergebruikers van Kibowi MP herbruikbare artefacten zich aan
dienen te houden. Hierin is onder andere afgesproken dat er niet aan branching
wordt gedaan en dat binnen Kibowi MP wordt besloten over de verdere
ontwikkeling van de herbruikbare artefacten.
Organisatieinvalshoek
De manier waarop hergebruik plaatsvindt tussen Kibowi MP en SCOPE berust
sterk op ‘toeval’. Het is grotendeels te danken aan de inzet van individuele
software engineers zelf. In dit geval een software engineer die zijdelings bij
Kibowi betrokken is geweest en ook deel uitmaakt van het SCOPE team. Er is dus
van buiten Kibowi MP geen sturing op zowel de productie als consumptie van
herbruikbare artefacten, het komt vooral neer op toeval en het enthousiasme van
enkele software engineers. Vooral de voormalig technologiemanager heeft hier
nagestreefd om de software artefacten generiek en herbruikbaar te ontwikkelen.
Ook qua ondersteuning en beheer is formeel niets geregeld. Ondersteuning wordt
door SCOPE verkregen door de ontwikkelaars vanuit Kibowi MP in te huren. Het
beheer van de hergebruikte artefacten ligt nog hoofdzakelijk binnen Kibowi MP. Er
zijn echter geen afspraken gemaakt over onderhoud, CM en PCM.
Ook qua verrekening is er niets geregeld. In de huidige situatie ligt de last bijna in
zijn geheel bij het Kibowi MP project. Dit project draait op voor de productie en
het beheer van de herbruikbare artefacten. In het geval van ondersteuning door
Kibowi projectleden aan het SCOPE team is er sprake van directe verrekening,
indien het al verrekend wordt. Vanuit Kibowi MP is er bij het management verzoek
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
99
gedaan voor enige vorm van verrekening. Deze verzoeken zijn tot nu toe
afgewezen.
4.3.2
Electronic Battlespace Facility (EBF)
Het EBF is een, voor de Nederlandse krijgsmacht ontwikkelde, gedistribueerde
simulatie-infrastructuur voor R&D en training. Het EBF genereert synthetische
omgevingen door (gedistribueerde) simulators te koppelen met andere (simulatie)
componenten. Doormiddel van High Level Architecture (HLA) is het EBF in
vergaande mate interoperabel met andere systemen.
Het EBF biedt gebruikers de analysemogelijkheden voor gedistribueerde,
interactive simulaties. Tevens biedt het de mogelijkheid snel simulaties en tools te
ontwikkelen om geëvalueerd te worden of om in het framework opgenomen te
worden. Figuur 24 geeft een beeld van de architectuur van het EBF met het
Advanced Simulation Framework (ASF), het Platform Framework (PLF) en enkele
van de generieke componenten.
Simulator Application
I/O
Support
3D
Visual
Platform
Framework
(PLF)
Audio
Advanced Simulation Framework
(ASF)
Figuur 24 - Generieke EBF simulator architectuur [HUI98][JEN97].
Deze case is uitgekozen vanwege de mate van toepassing en het niveau van
hergebruik van software artefacten binnen het EBF. Zo heeft het EBF een eigen
kwaliteitssysteem (afgeleid van het divisie brede kwaliteitssysteem) waarmee een
aantal aspecten worden gecontroleerd:
- het beheer van bestaande EBF componenten,
- de ontwikkeling van nieuwe componenten,
- management activiteiten.
De artefacten
Het EBF is destijds ontstaan vanuit een onderzoek naar flexibele generieke
architecturen. De basislaag van het EBF is het ASF, deze laag verzorgt de
connectie met de gedistribueerde virtuele omgeving. Op deze manier wordt de
gebruiker afgeschermd van de communicatie infrastructuur. In Figuur 25 is de
structuur van het ASF te zien.
Het ASF bestaat dus uit twee subsystemen, Environment en ObjectServer. De
Environment houdt de huidige status bij van alle simulatie objecten in de simulatie.
Denk hierbij aan tanks, vliegtuigen of dynamische terrein objecten zoals huizen en
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
100
bruggen. De Environment bevat ook de events die worden uitgewisseld tussen de
objecten en applicaties. De ObjectServer is verantwoordelijk voor de uitwisseling
van object- en event informatie met andere ObjectServer instanties en voorziet de
Environment met up-to-date informatie over de gevechtsomgeving.
Application
User defined simulation model
Environment
ObjectServer
DIS ObjectServer
Advanced Simulation
Framework
HLA ObjectServer
DIS compliant
HLA/RTI Compliant
Network
Figuur 25 - Structuur van het Advanced Simulation Framework [JEN97].
De gebruikers van het EBF krijgen vooral te maken met het PLF. Het PLF is een
open, schaalbare en uitbreidbare architectuur waarin de simulators (bemande en
onbemande) ontwikkeld kunnen worden. Het PLF vergroot herbruikbaarheid door
een opgelegde gestandaardiseerde interface tussen de componenten in het
framework. De simulatie applicaties die met het PLF worden gebouwd, worden
doormiddel van specialisatie van de generieke componenten van het PLF
ontwikkeld.
Figuur 26 - Platform Architectuur [JEN97].
Figuur 26 toont de structuur van het PLF. Deze structuur onderscheidt vier
belangrijke componenten.
1. Subsystems
Dit zijn de fysieke delen die onderdeel kunnen zijn van het platvorm,
bijvoorbeeld wapensystemen, sensoren, communicatie systemen en
voortstuwingsystemen.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
101
2. Personnel
Het platvorm kan bediend worden door menselijke of artificiële operators
of beide.
3. Environment
Dit component is een specialisatie van het ASF Environment. Het bevat
alle data en afstellingen betreffende het gevechtsgebied (terrein, weer,
entiteiten).
4. Support Modules
Dit zijn generieke software tools die de platform simulatie ondersteunen,
bijvoorbeeld een 3D visuele module, audio module of een I/O module.
Het EBF kan door de gebruiker hergebruikt worden doormiddel van
parameterisatie en doormiddel van het implementeren van eigen software bovenop
de generieke componenten. Het parameterisatieproces is veel werk gezien de vele
instellingen die gezet moeten worden.
Procesinvalshoek
Productie
De productie van herbruikbare artefacten voor het EBF vindt zowel plaats in de
projecten die gebruiken maken van het EBF als binnen het EBF-team zelf. De
projecten ontwikkelen componenten afhankelijk van hun eigen behoefte die nog
niet binnen het EBF beschikbaar zijn. Indien dit van tevoren is aangegeven bij het
EBF-team, wordt het project begeleid en gestuurd door het EBF-team. Bij
productie door het EBF-team wordt er gekeken naar de wensen van de gebruikers
van het EBF en hiaten in de huidige verzameling van herbruikbare artefacten.
Consumptie
De gebruikers van het EBF krijgen hulp bij het kiezen van de componenten die ze
kunnen hergebruiken voor hun simulatie. In Bijlage H is een stroomschema voor
het gebruik van het EBF te zien. De keuze voor het gebruik van het EBF is voor de
gebruikers een functionele en financiële afweging.
Ondersteuning & Beheer
Het EBF-team verzorgt het onderhoud en beheer van het EBF framework en de
generieke componenten hierin. Ook bieden ze ondersteuning aan de gebruikers van
het EBF. Voor het EBF zijn er ook verschillende specifieke procedures opgesteld:
- Configuratie Management
- Problem and Change Management
- Verificatie, Validatie en Accreditatie
- C++ Programmeerstandaard
- EBF Kwaliteitsplan
Bij het Verificatie, Validatie en Accreditatie proces ligt de nadruk zowel op
technische als procedurele eisen. Van validatie van de componenten is nog geen
sprake. Het EBF-team is bevoegd niet-geaccepteerde componenten uit de EBF-
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
102
repository te weren. De eisen die aan de herbruikbare componenten worden gesteld
voordat ze onder het EBF configuratie management worden opgenomen zijn
[BRA98]:
-
-
-
-
de ontwikkelaar zal een document van eisen van de component overleggen,
de ontwikkelaar zal een document van ontwerp van de component overleggen,
het nieuw te ontwikkelen EBF component zal maximaal gebruik maken van
standaard EBF componenten, zoals ASF en PLF voor de ontwikkeling van
nieuwe software componenten, vanuit het oogpunt van flexibiliteit en
herbruikbaarheid,
de EBF component is herconfigureerbaar om conflicten met andere EBF
componenten te minimaliseren (bijvoorbeeld bij het gebruik van DIS port
nummers),
de EBF ontwikkelaar zal op basis van een test-document met een beschrijving
van reproduceerbare testresultaten aantonen dat de component voldoet aan de
gestelde eisen,
de EBF ontwikkelaar zal een document overleggen waarin de installatie en het
gebruik van het systeem beschreven staat.
Additionele eisen die gesteld worden aan software, data, documentatie, federates of
EBF-federaties zijn [BRA98]:
-
-
-
-
-
Software
Source code moet voldoen aan de EBF Coding Standard [COD].
Software moet voorzien zijn van een bijbehorende User Manual.
Data
Data moet voorzien zijn van documentatie aangaande structuur en formaten.
Terrein-databases moeten kunnen worden geconverteerd naar de op dat
moment in de EBF gangbare terrain-database formaten.
Documentatie
Documentatie kan zowel elektronisch als niet-elektronisch geleverd worden.
Indien elektronisch dient een document geconverteerd te worden naar Word,
Postscript of Portable Document Format.
Federate14
Op HLA gebaseerde federates moeten getest kunnen worden of ze HLA
Compliant zijn; een federate moet geleverd worden met onder meer een SOM
(Simulation Object Model), een Conformance Statement, en eventueel
Scenario’s. Tevens dient iedere federate een expliciete beschrijving te hebben
van de samenhang tussen de gebruikte software en hardware.
EBF-federatie15
Op HLA gebaseerde federaties moeten getest kunnen worden of ze HLA
Compliant zijn.
14 Een federate is een verzameling van, mogelijk gedistribueerde, componenten die
samen een deel van de functionaliteit binnen een simulatie verzorgen.
15 Een federatie is een verzameling federates die samen een bepaald doel vervullen.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
103
Organisatie invalshoek
De organisatie van het EBF-team is te zien in Figuur 27. Dit is de
organisatiestructuur zoals deze binnen TNO-FEL wordt gehanteerd.
Verantwoordelijkheden voor de ontwikkeling en beheer van het EBF en haar
componenten zijn hierin vastgelegd. Ondersteuning voor de hergebruikers wordt
ook verricht vanuit het EBF-team.
EBF
Management
Gebruikersgroep
TNO-FEL
EBF
Kwaliteitszorg
Gebruikersgroep
Krijgsmacht
EBF
Beheer
EBF
Ontwikkeling
Figuur 27 - Organisatiestructuur EBF
Qua sturing vervult het EBF-team, zowel bij de productie als bij de consumptie van
herbruikbare artefacten, vooral een faciliterende rol. In Bijlage H is te zien dat
gebruikers van het EBF middels een stroomschema begeleid worden bij het
gebruik van het EBF en het kiezen van componenten. De filosofie dat men het zal
hergebruiken indien men de voordelen ervan inziet, speelt hier een belangrijke rol.
De financiering van het EBF heeft in de loop der jaren verschillende vormen
aangenomen. De krijgsmacht heeft hierbij altijd een deel van het EBF gefinancierd.
Dit was vooral bedoeld om het EBF in stand te kunnen houden. Momenteel heeft
het EBF ook een binnen TNO-FEL en betalen projecten voor ondersteuning en
wijzigingen die zij nodig hebben. In het verleden moesten projecten die gebruik
maakten van het EBF een deel van hun budget afstaan. Dit is echter opgeheven
vanwege de weerstand die hiertegen ontstond door scheve betalingsverhoudingen
tussen projecten.
4.3.3
Case studies volgens het Theoretische Raamwerk
Het niveau van hergebruik van software artefacten binnen het EBF lijkt op het
eerste gezicht hoger dan bij de andere twee case studies. Met behulp van het
theoretische raamwerk uit § 3.7 worden de drie case studies in Tabel 22
vergeleken. Zo kan er inzicht verkregen worden in de invulling van hergebruik van
software artefacten binnen de drie case studies. Door de uniforme wijze van
vergelijking kan er snel bekeken worden hoe de cases aan de verschillende
aspecten invulling hebben gegeven en waar er zich nog ‘gaten’ voordoen. Dat wil
zeggen aan welke aspecten nog geen invulling of oplossing voor is.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
104
CASES
KENMERKEN
Artefacten
ORB Kernel
Type artefact(en)
Component
Manier van gebruik
Documentatie
Black Box
Gebruikers handleiding
& Javadoc
Domein specifiek
artefact
Intensiteit van
hergebruik
KIBOWI MP
Architectuur,
componenten en
broncode
Black Box & White Box
Javadoc
Applicatie framework
met algemene
componenten
EBF
Architectuur en
componenten
Hoofdzakelijk Black Box
Interface beschrijvingen,
gebruikershandleidingen
Applicatie framework met
algemene en domein
specifieke componenten
Processen
Moment van productie
Manier van productie
Ondersteuning
Configuratie
Management
Problem & Change
Management
Certificatie
Sturing Productie
Sturing Consumptie
Metingen
Pre-project & In-project
Domein Kennis +
Re-engineering
Informele ondersteuning
via informeel
verantwoordelijke
Ja
In-project
Domein Kennis +
Re-engineering
Informeel ondersteuning
via de maker van het
herbruikbare artefact
Ja (binnen KIBOWI)
In-project
Domein Kennis + Reengineering
Formeel ondersteuning
vanuit EBF-team
Ja
Ja (binnen KIBOWI)
Ja
Geen certificatie
N.V.T.
Geen certificatie
Geen sturing
Informeel
faciliterend/adviserend
Geen metingen
Geen sturing
Geen metingen
Verificatie
Faciliterend/adviserende
rol van het EBF-team
Faciliterend/adviserende
rol van het EBF-team
Geen metingen
Informeel
Nee
EBF-Team
Informeel
Nee
EBF-Team
Nee
Nee
Per project afzonderlijk
door software engineer
Nee
Nee
Nee
Geen sturing aanwezig
Nee
EBF-Team
EBF-Team
Afstemming tussen
projecten door EBF-Team
Nee
Geen
N.v.t.
Geen
Geïntegreerd in project
Ja
Organisatie
Verantwoordelijkheid
ondersteuning bij
herbruikbaar artefact
Verantwoordelijkheid
beheer herbruikbaar
artefact
Sturing Productie
Sturing Consumptie
Niveau van sturing
Top Management
commitment
Voorschriften
Inrichting Productie
EBF-beheersvoorschriften
Geïntegreerd in projecten
+ EBF team
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
105
Inrichting
Ondersteuning
Niet formeel aanwezig
Niet formeel aanwezig
Formeel aanwezig binnen
EBF team
Financiering productie
Financiering beheer
Financiering
ondersteuning
Repository
Indirecte verrekening
Directe verrekening
Directe verrekening
Geen
Geen
Directe verrekening
Indirecte verrekening
Indirecte verrekening
Directe verrekening
Ja, in SourceForge.
Publiekelijk
beschikbaar.
Ja, in SourceForge.
Echter niet publiekelijk
toegankelijk.
Eigen repository, nog niet
publiekelijk toegankelijk
binnen TNO-FEL
Tabel 22 - Analyse van de Case Studies Cases a.d.h.v. het theoretische model.
Tabel 22 toont dat alleen binnen het EBF aandacht is besteed aan organisatorische
aspecten betreffende hergebruik. Dit ‘project’ is ook gericht op het beheer van de
EBF faciliteit en verdere ontwikkeling ervan. Andere projecten kunnen gebruik
maken van deze faciliteit. Hier is dus een visie en een budget aanwezig. Dit in
tegenstelling tot Kibowi MP waar het project zelf een product moet opleveren.
Binnen Kibowi MP is beperkt aandacht besteedt aan beheer en ondersteuning voor
hergebruik. Dit is echter logisch aangezien het helemaal geen doel of taak van het
project zelf is. Er is op organisatorisch niveau nog geen aandacht besteed aan het
projectoverschrijdende karakter van hergebruik: geen verrekening, sturing en
opvang van de herbruikbare software artefacten.
4.3.4
Vergelijking Case Studies TNO met Best Practices
In § 3.8 zijn de best practices Sodalia en Eliop geanalyseerd. In dit hoofdstuk is de
toepassing van hergebruik binnen TNO-D&V Business Unit 2 geanalyseerd. Deze
paragraaf vergelijkt de case studies binnen BU2 met de best practices Sodalia en
Eliop.
Top Management Support
Bij de twee case studies is Top Management Support duidelijk aanwezig. Het
management van Sodalia is een zeer sterk voorstander van hergebruik van software
en heeft het opgelegd als de manier van werken. Bij Eliop heeft hergebruik de
steun van het Top Management onder de voorwaarde dat het een positieve bijdrage
levert aan de resultaten (financieel, kwalitatief en op de doorlooptijd). Bij TNOD&V BU2 is deze Top Management Support echter nog niet aanwezig. Het zijn de
software engineers, de technologietrekker en heel soms projectleiders die ermee
bezig zijn. Doordat het Top Management nog niet betrokken is bij hergebruik van
software, ontstaat er binnen TNO-D&V BU2 problemen op procesmatig en
organisatorisch niveau.
Niveau van sturing van hergebruik
Hergebruik binnen TNO-D&V BU2 is tot nu toe een sterk bottom-up gerichte
activiteit geweest. Hergebruik is opgehangen aan de software engineers, zij zijn
degene die het doen en mogelijk maken. Dit brengt natuurlijk problemen met zich
mee aangezien zij niet de autoriteit hebben om wijzigingen in het proces te
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
106
realiseren, andere projecten herbruikbare artefacten te laten produceren of
consumeren of een verrekeningsstructuur op te zetten. Bij de Sodalia en Eliop is
hergebruik sterker vertegenwoordigd in de managementniveaus. De Reuse Support
Organization van Sodalia kan de projectteams ondersteunen bij het hergebruiken en
produceert de herbruikbare artefacten. Bij Eliop is er een Reuse Task Group
opgericht waarin ook de projectleiders zijn opgenomen. Deze projectleiders
dwingen op hun beurt hergebruik binnen de projecten af.
Manier van verkrijgen herbruikbare artefacten
Sodalia en Eliop hanteren beide Domein Engineering om herbruikbare artefacten
binnen specifieke domeinen te identificeren, modelleren en implementeren. Vanuit
de theorie wordt ook gesteld dat Domein Engineering mogelijk een belangrijke rol
speelt in hergebruik. Binnen TNO-D&V wordt er formeel geen Domein
Engineering toegepast, hergebruik komt veelal voort uit re-engineering. De
herbruikbare artefacten worden vaak in meerdere projecten verder ontwikkeld en
op basis van voortschrijdend inzicht ontwikkeld. Er is dus geen gestructureerde
manier om herbruikbare artefacten te ontwikkelen.
Standaardisatie proces & product
Waar bij Sodalia en Eliop de processen duidelijk zijn gestandaardiseerd middels
procedures en richtlijnen die ook nageleefd worden, wordt er binnen M&S meer
naar eigen inzicht gewerkt. De Codes of Practice dienen als hulpmiddel voor de
software engineers met als gevolg dat er vaak geen duidelijke gestandaardiseerde
processen te onderkennen zijn. Hetzelfde geldt voor de herbruikbare artefacten.
Waar Sodalia de herbruikbare artefacten via audits keurt heeft Eliop coding
standards en templates voor de documentatie opgesteld. Binnen TNO-D&V zijn er
COP’s voor gebruikershandleidingen en voor andere documentatie zoals software
ontwerpen en testbeschrijvingen. Ook zijn er standaarden voor het programmeren
in Ada, C, C++ en Java. Tevens heeft de hergebruikgroep een aantal voorwaarden
opgesteld voor de opname van een herbruikbaar component of tool in SourceForge.
4.3.5
Resultaten door hergebruik binnen de case studies
Harde cijfers over resultaten door hergebruik zijn binnen BU2 niet beschikbaar.
Voor enkele gevallen is het echter wel mogelijk om een indicatie te geven van de
resultaten door hergebruik.
ORB Kernel
De ORB Kernel is volgens de beheerder in circa 10 verschillende projecten in een
flinke mate hergebruikt. Het ontwikkelen van de ORB Kernel heeft circa 500
manuur gekost. In § 3.3.4 is aangegeven dat het ontwikkelen van een herbruikbaar
software artefact circa 1,5 keer zoveel kosten als het niet herbruikbaar ontwikkelen.
Indien een project de ORB Kernel naar volle potentie hergebruikt krijgen ze dus
een product dat ze zelf circa 500/1,5 = 330 uur zou hebben gekost om te
ontwikkelen. De cumulatieve besparing over circa 10 projecten is dus ongeveer
3300 uur.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
107
Kibowi MP
Het CSE framework van Kibowi MP is alleen nog in SCOPE naar volle potentie
hergebruikt. De losse componenten zijn ook al in diverse, momenteel circa 5,
projecten hergebruikt. Dit betreft de database store & manager, de statemachine en
de monitor. Doordat SCOPE het gehele CSE framework en de componenten uit
Kibowi MP hergebruikt zet het een knappe prestatie neer, ook gezien het beperkte
budget van SCOPE. Om te vergelijken: SCOPE heeft een budget heeft van circa €
67.000 voor het bouwen van de gehele applicatie exclusief het daadwerkelijke
model en Kibowi MP een budget heeft dat vele malen hoger ligt.
Het CSE framework en de herbruikbare componenten van Kibowi MP hebben
circa 3500 ontwikkeluren gekost. Indien dit volledig wordt hergebruikt is de
‘besparing’ dus 3500/1,5 = 2330 uur. Binnen het SCOPE project heeft het circa
200 manuren gekost om dit framework en de componenten te integreren en aan te
passen voor SCOPE. Dit staat in geen verhouding tot de originele ontwikkeluren.
EBF
Bij het EBF kunnen de hergebruikers gebruik maken van het framework en de
componenten die beschikbaar zijn. Deze voorziening biedt een grote besparing op
ten opzichte van een situatie waarbij elke simulatieapplicatie opnieuw ontwikkeld
zou moeten worden. Er zijn geen cijfers voor beschikbaar over de geïnvesteerde
ontwikkeluren. De EBF faciliteit is echter al beschikbaar sinds 1997. Als er wordt
gekeken wordt naar de besparing binnen het SCOPE project door het hergebruik
van de Kibowi MP artefacten dan kan men inzien dat de besparing hier in de loop
der tijd een veelvoud is van de origineel benodigde ontwikkeluren. Vele projecten
die uitgevoerd zijn met het EBF zouden anders waarschijnlijk financieel helemaal
niet, of niet in de gerealiseerde vorm, uitgevoerd kunnen worden.
Resultaat in
ontwikkeluren
EBF
Framework
&
Componenten
Kibowi MP
5000
Framework
&
Componenten
4000
3000
ORB
2000
Cumulatieve
besparing
1000
Kibowi
MP
Cumulatieve
besparing
Ontwikkel (geheel 1x +
enkele
uren
componenten
in 5
projecten)
Cumulatieve
besparing
(reeds vele
malen
hergebruikt)
EBF
Ontwikkel
uren
ORB
Case studies
Figuur 28 - Indicatie van de resultaten per case studie.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
108
In Figuur 28 is de linkerkolom per case studie de investering qua uren. De
rechterkolom geeft een indicatie van de cumulatieve besparing indien het
component of framework met componenten volledig wordt hergebruikt. Deze
indicaties zijn gebaseerd op de geïnvesteerde ontwikkeluren in de herbruikbare
artefacten per case studie en het aantal malen dat deze zijn hergebruikt (voor zover
bekend). Over het EBF zijn geen concrete cijfers bekend. Wel is bekend dat dit
sinds 1997 wordt hergebruikt en dat er circa 20 project op jaarbasis gebruik van
maken.
Figuur 28 geeft een indicatie van de resultaten door hergebruik per case studie.
Binnen de drie case studies lijkt hergebruik weldegelijk resultaat op te leveren.
Het is echter moeilijk om vast te stellen of dit nu een besparing of een
productiviteitsstijging is. Indien bij het vaststellen van het budget van een project
geen rekening is gehouden met de herbruikbare artefacten is de bespaarde tijd
waarschijnlijk besteed aan andere activiteiten. Er kan dan niet worden gesproken
over een besparing maar over een productiviteitsstijging.
Omdat hergebruik adhoc plaatsvindt, zonder regie over de projecten heen, worden
niet alle kansen voor hergebruik benut. Tevens resulteert hergebruik hierdoor vaak
in een productiviteitsstijging en/of een kortere levertijd en niet tot een besparing.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
109
4.4
Conclusie
Hergebruik van software artefacten vindt al plaats binnen M&S al is dit veel nog
op een adhoc basis. Zo is er geen financiering of sturing op de productie van
herbruikbare artefacten, geen opvang en beheer van herbruikbare artefacten, is de
verzameling van beschikbare herbruikbare artefacten onduidelijk en bevindt
hergebruik zich vooral op het niveau van de software engineers zonder
projectoverschrijdende coördinatie. Hierdoor worden kansen voor het hergebruiken
van herbruikbare software artefacten gemist, bestaat er weerstand tegen zowel de
productie als consumptie bij de software engineers en projectleiders en is het
resultaat van hergebruik onduidelijk.
Er worden successen geboekt door het hergebruik van componenten en
frameworks, maar de schaal waarop dit gebeurt is nog beperkt. De potentie voor
hergebruik lijkt dus wel aanwezig te zijn, maar er bestaan in de huidige situatie een
aantal knelpunten die hergebruik belemmeren. Zolang deze knelpunten niet
verholpen zijn blijft hergebruik adhoc en zal M&S niet profiteren van de voordelen
van een systematische vorm van hergebruik van software artefacten.
-
Geen Top Management Support
Hergebruik van software artefacten binnen M&S is vooralsnog sterk adhoc en
bottom-up gericht. Het (top) management is nog niet sterk betrokken geweest
bij hergebruik. Op technisch gebied zijn er redelijke resultaten gehaald maar
organisatorisch en procesmatig gezien is er nog weinig geregeld.
-
Geen sturing van de productie en consumptie van herbruikbare artefacten
Er is geen sturing op de productie of consumptie van herbruikbare artefacten
aanwezig. De productie van herbruikbare artefacten is gebaseerd op toeval en
toewijding van enkele software engineers. Er bestaat ook geen inzicht in de
beschikbare herbruikbare artefacten waardoor veel kansen worden gemist.
Enkele software engineers proberen het bewustzijn betreffende de beschikbare
artefacten te vergroten door deze sterk te promoten. Ze hebben echter geen
zeggenschap over de keuzes die in andere projecten gemaakt worden.
Waar er bij de best practices hergebruikgroepen bestaan die de projecten
sturen op de productie en consumptie is dit binnen M&S niet het geval
vanwege een gebrek aan autoriteit van de hergebruikgroep.
-
Geen organisatie over de projecten heen
Er is formeel niets geregeld voor de herbruikbare artefacten nadat het project
waarin ze zijn ontwikkeld eindigt. In sommige gevallen neemt een software
engineer het beheer en de ondersteuning van het herbruikbare artefact op zich,
bijvoorbeeld zoals bij de ORB Kernel. Dit is bewonderenswaardig maar biedt
geen goede basis voor systematisch hergebruik waarin onderhoud,
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
110
configuratie management, problem and change management en eventuele
ondersteuning aanwezig moeten zijn.
-
Beperkte standaardisatie van proces en product
TNO-D&V heeft geformaliseerde standaarden voor de verschillende
processen in het software engineering proces en standaarden voor de productie
van code. Deze worden echter niet altijd nageleefd. Ze zijn ontwikkeld om de
software engineer en projectleider te ondersteunen in zijn werkzaamheden.
Hergebruik is hier ook nog niet in meegenomen, noch op technisch noch op
procedureel niveau. Sommige codes of practice kunnen echter zonder
wijziging worden toegepast in geval van hergebruik of herbruikbare
artefacten. Verder zijn er vanuit de hergebruikgroep wel voorwaarden
opgesteld waar een herbruikbaar software artefact aan moet voldoen voordat
het wordt opgenomen in SourceForge.
-
Geen financiering voor hergebruik
Er is niets geregeld voor de financiering van de activiteiten voor hergebruik.
Waar mogelijk worden de kosten van hergebruik direct doorberekend. Voor
projectoverschrijdende kosten, zoals die voor de productie of het onderhoud
en beheer, is echter niets geregeld. Dit heeft tot gevolg dat projectleiders
kritisch zijn over het herbruikbaar maken van software artefacten. Dit aspect,
gecombineerd met het gebrek aan sturing betreffende de productie van
herbruikbare artefacten, zorgt ervoor dat de productie van herbruikbare
artefacten zeer gering is en vooral afhankelijk van de inzet van individuele
software engineers.
-
NIH-syndroom
Het inzicht in de beschikbare herbruikbare artefacten ontbreekt. Slechts enkele
herbruikbare artefacten zijn opgenomen in SourceForge. De andere
herbruikbare artefacten zijn vaak lokaal opgeslagen. Verder zien de software
engineers en projectleiders hergebruik vaak als een beperkende factor op hun
keuzevrijheid en creativiteit. Tevens vormt een gebrek aan vertrouwen in de
kwaliteit en herbruikbaarheid van de herbruikbare artefacten een obstakel tot
het daadwerkelijk hergebruiken ervan.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
111
5.
Gewenste Situatie voor TNO
In dit hoofdstuk worden de verschillende keuzes en invullingen, die aan hergebruik
van software artefacten kunnen worden gegeven, toegepast op de afdeling M&S.
Hierbij wordt de gewenste situatie qua herbruikbare artefacten, processen en
organisatie beschreven waarbij oplossingen worden aangedragen voor de
geconstateerde knelpunten. Tevens wordt er een stappenplan ontwikkeld met een
indicatie van de financiële gevolgen van hergebruik van software artefacten.
Enkele aspecten uit de gewenste situatie zijn getoetst tijdens een groepssessie,
verdere informatie en uitkomsten hiervan zijn te vinden in Bijlage I.
5.1
Keuze voor hergebruik
Hergebruik van software artefacten is geen doel op zichzelf. Het moet een
positieve bijdrage leveren aan de ontwikkeling van software binnen TNO-D&V,
bijvoorbeeld via productiviteitsverbeteringen of kostenbesparingen. Zoals in
§ 3.4.4 is beschreven, is de keuze voor hergebruik afhankelijk van een aantal
aspecten. Het financiële aspect wordt in § 5.4 en § 5.6 besproken.
5.1.1
De markt en organisatie
TNO-D&V voert opdrachten uit voor de Nederlandse Krijgsmacht en voor civiele
partijen. Momenteel is de Nederlandse Krijgsmacht de grootste klant. Binnen de
krijgsmacht bestaat er echter een drive om voor de niet-strategische producten
meer off-the-shelf producten aan te schaffen. Een voorbeeld is Kibowi MP, de
uitbesteding hiervan is via een openbare tenderprocedure verlopen. Om dit soort
opdrachten, waar voor TNO-D&V een belangrijk kennisaspect in is verwerkt,
binnen te halen is het noodzakelijk dat de afdeling M&S kan meedraaien in een
concurrerende omgeving in samenwerking met partners uit de industrie. Andere
externe invloeden zoals outsourcing van IT naar lage lonen landen en een
toenemende concurrentie binnen de kennisdomeinen van TNO-D&V kunnen het
behouden van deze kennisdomeinen lastiger maken. Indien TNO-D&V haar manier
van softwareontwikkeling niet efficiënter maakt is de kans groot dat de software
engineer activiteiten binnen TNO-D&V op den duur verdwijnen. Hiermee zal voor
TNO-D&V ook belangrijke kennis verloren gaan.
5.1.2
Software ontwikkeling
TNO-D&V is ISO 9001 gecertificeerd, maar is niet CMM gecertificeerd. M&S
voert wel opdrachten uit waarbij een bepaald CMM niveau wordt vereist, tot CMM
niveau 3 aan toe. Over het algemeen is de volwassenheid van het
softwareontwikkelproces echter beperkt. Dit heeft ook invloed op de manier
waarop hergebruik van software vormgegeven kan worden, de precieze gevolgen
komen later aan bod. Tevens bestaat er een sterke mate van heterogeniteit tussen de
ontwikkelde software producten. Dit betekent echter niet dat hergebruik
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
112
onmogelijk is. Al is de heterogeniteit van de software producten groot, binnen de
software producten zijn er componenten of delen die een dergelijke mate van
homogeniteit hebben dat hergebruik zeker mogelijk is. Dit blijkt ook uit een
onderzoek dat binnen TNO-D&V is uitgevoerd door Sluimer et al.[SLU04].
Sluimer et al.[SLU04] heeft de mogelijkheid voor familievorming van
trainingssimulators bij de KL onderzocht. Het blijkt dat de KL steeds meer
aandacht heeft voor beleidsvorming richting een meer effectief en efficiënt gebruik
van M&S technologie. Standaardisatie van de simulators is hier onderdeel van.
Binnen dit onderzoek is de onderverdeling van de Universal Joint Task List van de
NAVO en het EUCLID project Elstar gehanteerd. Deze onderverdeling is goed
toepasbaar aangezien de afdeling M&S veel simulators ontwikkelt.
Type
Toelichting
Voertuigbesturing en
Dit betreft simulators voor training van taken die betrekking hebben op transportfuncties
navigatie
ter land, zee of in de lucht.
Doelopsporings-
Dit betreft simulators voor training van taken die betrekking hebben op verkenning en
simulators
het verzamelen en overbrengen van informatie over doelen, schade aan objecten en
andere tactische of strategische informatie.
Bedienings- en schiet-
Dit betreft simulators voor training van taken die betrekking hebben op doelacquisitie en
technische simulators
doelbestrijding ter land, ter zee en in de lucht.
Tactische
Dit betreft simulators voor training van taken die betrekking hebben op Command en
proceduretrainers en
Control vanaf individuele platforms tot op divisie niveau. Het betreft de planning,
staftrainers
preparatie en/of uitvoering van missies ter land, ter zee en in de lucht.
Onderhoudstrainers
Dit betreft simulators voor training van taken die betrekking hebben op
verzorgingssteun, zoals onderhoud, storingzoeken en reparatie, noodprocedures
uitvoeren, beschermen en verzorgen van personeel, logistiek en administratie.
Logistiek en genie
Dit betreft simulators voor training van taken die betrekking hebben op logistieke en
genie steun op het land, ter zee en in de lucht.
Tabel 23 - Onderverdeling naar type simulators [SLU04].
Ook binnen M&S is er een verdeling te maken in de typen simulators die worden
ontwikkeld. Hergebruik van software kan zowel over de verschillende typen
simulators heen worden uitgevoerd als binnen een bepaalde type van simulators.
5.1.3
Het personeel
Een deel van de software engineers heeft al veel ervaring met het ontwikkelen van
en met herbruikbare software artefacten. Tevens zijn de software engineers meer
gewend geraakt aan hergebruik. Waar het eerst een punt van discussie was, is het
tegenwoordig meer geaccepteerd. Dit wordt waarschijnlijk veroorzaakt door de
aandacht aan het onderwerp en de successen die worden gerealiseerd door
hergebruik van software artefacten. Het is echter nog niet zo dat hergebruik
vanzelfsprekend is.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
113
5.2
Herbruikbare software artefacten
Deze paragraaf behandelt de software artefacten die binnen M&S kunnen worden
hergebruikt. Hierbij wordt besproken welke typen artefacten er hergebruikt kunnen
worden, welke documentatie er aanwezig moet zijn en aan welke eisen een
herbruikbaar artefact moet voldoen.
5.2.1
Artefacten
In Tabel 20 uit Hoofdstuk 4 is een opsomming gegeven van de grotere software
artefacten die binnen M&S beschikbaar zijn om te hergebruiken. Dit bevat zowel
tools als uitgebreide libraries waarmee een hergebruiker vele ontwikkeluren kan
besparen bij het bouwen van een simulator. De herbruikbare artefacten zijn zowel
domein specifieke artefacten, zoals de ORBAT Browser, als algemene, niet domein
gerelateerde, artefacten, zoals de Monitor of State Machine. Verder zijn er
(technische) frameworks beschikbaar waarmee een ontwikkelaar zijn simulatie kan
bouwen. Bijvoorbeeld het Kibowi framework, CSE, of het EBF framework, deze
vormen goede mogelijkheden voor hergebruik.
§ 5.1.2 spreekt over een onderverdeling van typen simulators. Sluimer et al.
identificeert hier ook een aantal onderdelen in simulators die als losse
componenten gestandaardiseerd en hergebruikt kunnen worden.
-
User Interfaces,
Terrein databases,
Visuele modellen van objecten/entiteiten,
Fysische- en gedragsmodellen van entiteiten,
Scenariomanagement,
After Action Review.
Tevens worden er vanuit de hergebruikgroep drie aspecten genoemd die zich lenen
voor hergebruik:
-
Simulatie modellen,
Kernels,
Synthetische omgevingen.
Deze componenten lenen zich goed voor hergebruik, behalve de fysische- en
gedragsmodellen van entiteiten. Deze modellen omvatten bijvoorbeeld
eigenschappen zoals beweging, wapeneffectiviteit of kwetsbaarheid. Vaak zijn
deze eigenschappen in grote mate verbonden met de gemodelleerde systemen en
bestaat er slechts een beperkte mogelijkheid voor hergebruik [SLU04].
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
114
Hergebruik binnen M&S moet zich hoofdzakelijk richten op hergebruik van
grotere componenten en waar mogelijk frameworks waarmee simulators gebouwd
kunnen worden. Met andere woorden, een Component Based Software
Development aanpak. Het is verstanding een compacte verzameling van
hoogwaardig herbruikbare artefacten te hanteren, zie § 3.2.2, om nieuwe simulators
mee te ontwikkelen en frameworks om dit te ondersteunen.
5.2.2
Documentatie bij een herbruikbaar artefact
De documentatie die bij een herbruikbaar artefact beschikbaar moet zijn hangt af
van het type artefact. De template in Tabel 24 is vooral gericht op software
componenten. Deze template is gebaseerd op de eisen die vanuit de
hergebruikgroep aan een herbruikbare tool worden gesteld en op de documentatie
template zoals in § 3.3.2 is opgenomen. Tabel 24 geeft ook aan in welk document
de specifieke informatie genomen kan worden.
Type Informatie Toelichting
Document
binnen M&S
Basis Informatie
Algemene
informatie
Historie
Interfaces
Certificatie
- Naam van het artefact
- Keywords voor de categorie van het artefact
- Bron van het artefact (intern / extern)
- Beschrijving van het artefact
Beschrijft de wijzigingen per versie vanaf de eerste versie die
gereleased is.
Beschrijft de aangeboden en gewenste interfaces van het artefact.
Bij javacode of componenten kan hiervoor gebruik worden gemaakt
van Javadoc.
Beschrijft aan welke eisen dit artefact is getoetst en voor welke
situaties/context het ontwikkeld is.
Software User
Manual (SUM)
Software User
Manual
Javadoc &
Interface Design
Description(IDD)
Apart document
in SourceForge
of extra in SUM.
Gedetailleerde Informatie
Technische details
Installatie
handleiding
Beperkingen
Aanpasbaarheid
Beschrijft het formaat van het artefact en de omgeving waarin het
herbruikbare artefact is ontwikkeld, getest en kan worden gebruikt
[EZR02]. Biedt ook informatie over fysieke bronnen die het artefact
nodig heeft, afhankelijkheden van andere artefacten en eventuele
technische beperkingen bij het gebruik van het artefact.
Beschrijft hoe het artefact geïmplementeerd en geïnstalleerd dient te
worden. Een voorbeeld van gebruik is hierbij essentieel aangezien
dit in de praktijk vaak een zeer belangrijke bron van informatie
Software User
vormt voor de potentiële hergebruiker [MIL02].
Manual
Beschrijft alle zaken die de ontwikkelaar beperken. Denk hierbij
aan interface beperkingen, de benodigde hardware en software, en
eventuele andere dingen die niet mogelijk zijn.
Beschrijft hoe dit artefact aangepast kan worden. In geval van black
box beschrijft dit bijvoorbeeld hoe het artefact via parameterisatie
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
115
afgesteld kan worden of waar de expliciete extentiepunten zitten.
Overige Informatie
Testen
Ondersteuning
Beschrijft hoe dit artefact is getest. Hierbij kan verwezen worden
naar de STD, STP en STR documenten.
Beschrijft de procedure betreffende de ondersteuning bij dit artefact.
Aanspreekpunt voor bugs, change requests of ondersteuning bij
gebruik.
Software User
Manual
Software User
Manual
Tabel 24 - Benodigde documentatie en informatie bij een herbruikbaar artefact.
Alle informatie die in de template in Tabel 24 is opgenomen kan al verwerkt
worden in één van de codes of practice van TNO-D&V. De Software User Manual
(SUM) speelt hier de belangrijkste rol in. Voor overige documentatie bij de
herbruikbare artefacten, zoals de requirements of ontwerpdocumenten, kunnen de
relevante codes of practice (respectievelijk SRS en SDD) gebruikt worden. Deze
documenten moeten worden opgenomen in SourceForge.
5.2.3
Eisen aan herbruikbare artefacten
Een herbruikbaar artefact moet aan een aantal eisen voldoen voordat het
ontwikkeld en het in SourceForge opgenomen wordt.
-
Overleg met hergebruikstuurgroep
Voordat een project tijd en geld investeert in het ontwikkelen van een
herbruikbaar artefact, moet dit eerst worden voorgelegd aan de
hergebruikgroep. Hierbij moeten de requirements en het ontwerp van het
artefact goedgekeurd worden voordat het ontwikkeld wordt. Tevens moet
er een business case 16 worden opgesteld waarin de kosten voor het
ontwikkelen van het herbruikbare artefact worden verantwoord.
-
Voldoen aan standaarden
Indien de software engineers toegang hebben tot broncode moeten de
herbruikbare artefacten voldoen aan algemene standaarden en richtlijnen
voor het programmeren, ontwerpen en documenteren en aan eventuele
standaarden die binnen een specifiek domein gelden. Voor TNO-D&V
BU2 zijn er programmeerstandaarden voor Ada, C, C++ en Java of
richtlijnen voor het modelleren met bijvoorbeeld UML.
-
Compleetheid & Correctheid
Herbruikbare artefacten moeten compleet zijn. D.w.z. het bieden van de
beloofde functionaliteiten en aanwezigheid van de documentatie volgens
het template in Tabel 24. Met deze documentatie moet een herbruikbaar
artefact zichzelf in voldoende mate beschrijven om hergebruikt te kunnen
16 Een business case voor een herbruikbaar artefact is een financiële verantwoording
voor de ontwikkeling van het artefact. Het geeft een schatting van de kosten voor
het ontwikkelen van het artefact en ligt toe hoe deze kosten terugverdiend gaan
worden.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
116
worden. Indien de documentatie niet aanwezig is vormt dit een flinke
drempel om het te hergebruiken.
-
Interoperabiliteit
Het artefact moet met andere artefacten kunnen communiceren. Ook met
artefacten die in andere talen zijn ontwikkeld of op andere platforms
draaien. Bij BU2 geldt dit zowel voor simulator componenten als gehele
simulators, die in gedistribueerde simulaties opgenomen worden. Om
artefacten met elkaar te laten communiceren is het ook noodzakelijk dat ze
qua dataformaat en services met elkaar overweg kunnen.
Deze interoperabiliteit kan in een artefact zelf voorzien zijn, bijvoorbeeld
door gebruikmaking van design patterns (observer-observable patroon is
een goed voorbeeld) of overerving. Een andere mogelijkheid is middleware
om de interoperabiliteit tussen artefacten te realiseren.
Voor interoperabiliteit tussen simulators zijn er drie standaarden die in
NAVO verband worden gebruikt; DIS (IEEE 1278:1993), ALSP en HLA
(IEEE 1516). Van deze standaarden worden DIS en ALSP uitgefaseerd ten
behoeve van HLA. HLA is door DoD en door de NATO omarmd als
interoperabiliteitsstandaard voor simulaties. Hiermee is een industriële
ondersteuning ook gegarandeerd [LAN02].
Voor interoperabiliteit tussen simulator componenten kan er gebruik
worden gemaakt van verschillende technieken, bijvoorbeeld van
middleware zoals Corba en de HLA Componenten Architectuur. Binnen
het EBF is hiervoor reeds een framework ontwikkeld, namelijk TSA.
5.2.4
Black box en white box hergebruik
Een absolute keuze voor black box of white box hergebruik is te zwart-wit. Vanuit
economisch en beheerstechnisch oogpunt heeft black box hergebruik de voorkeur,
maar software engineers willen toch altijd toegang hebben tot de broncode. Dit
zowel om inzicht te verkrijgen in het artefact als om zelf fouten te verhelpen of
extra functionaliteit toe te kunnen voegen.
Probeer naar black box hergebruik te streven maar sluit de mogelijk voor white box
hergebruik niet uit. Laat dit een rationele keuze zijn op basis van een kosten/baten
analyse. Indien ervoor wordt gekozen om het artefact als white box te hergebruiken
moet het artefact wel als een lokale copy behandeld worden, eventuele bugfixes of
toevoegingen moeten bij de beheerder van het herbruikbare artefacten gemeld
worden.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
117
5.3
Gewenste hergebruikorganisatie en processen
Deze paragraaf beschrijft de benodigde nieuwe organisatie voor de systematische
toepassing van hergebruik van software artefacten.
5.3.1
Organisatiestructuur
Om de knelpunten die in hoofdstuk 4 zijn geïdentificeerd te verhelpen zijn
wijzigingen in de huidige organisatie en processen noodzakelijk. Een aantal punten
zijn hier noodzakelijk, namelijk:
- sturing over de projecten heen op de ontwikkeling van en met herbruikbare
software artefacten,
- de financiering van projectoverschrijdende kosten door hergebruik,
- de opvang en het beheer van de herbruikbare artefacten,
Er moet binnen M&S een entiteit komen die over de projectteams heen stuurt en
deze ondersteunt bij de productie en consumptie van herbruikbare artefacten. Deze
entiteit moet hiervoor ook de macht en financiën hebben om dit te kunnen doen.
Tevens moet het beheer van de herbruikbare artefacten projectoverschrijdend
ingericht worden.
In de theorie zijn er een viertal opties besproken, zie § 3.5.3. Geen van deze
structuren is echter direct toe te passen. Een van deze structuren, de ‘pool
producer’ structuur, komt al voor binnen M&S (Moses project). Deze structuur is
echter onhandig aangezien het vooral voor samenwerking tussen enkele projecten
is bedoeld en geen lange termijn hergebruikstrategie ondersteunt. De ‘team
producer’ structuur vormt, na enige aanpassing voor M&S, de beste oplossing.
De ‘team producer’ structuur zoals die bij HP wordt gehanteerd centraliseert de
productie en het beheer van de herbruikbare software artefacten. Bij de
geanalyseerde best practices kwamen dergelijke structuren ook voor. Voor M&S is
deze structuur een goede manier om de kennis over de herbruikbare artefacten te
centraliseren. Voor de ontwikkeling van herbruikbare artefacten is deze structuur
binnen M&S ook geschikt, maar dan met de uitzondering dat deze eenheid enkel
stuurt op de ontwikkeling van herbruikbare software artefacten. De volwassenheid
van het softwareontwikkelproces binnen M&S is beperkt en er wordt binnen
verscheidene applicatiedomeinen software ontwikkeld. M&S heeft niet de ‘massa’
om voor elk applicatiedomein een eigen ‘team producer’ eenheid op te zetten en
veel herbruikbare artefacten binnen M&S zijn ook niet domeinspecifiek.
Figuur 29 toont de opzet van de gewenste organisatiestructuur voor hergebruik. In
deze organisatiestructuur blijft de projectstructuur intact, de enige verandering is de
toevoeging van de hergebruikstuurgroep en de toewijzing van software engineers
aan herbruikbare artefacten voor het beheer en de ondersteuning.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
118
Sturing en coördinatie hergebruik activiteiten
Hergebruikstuurgroep
Sturing
productie en
consumptie
Support voor
de
Projectteams
Beheer &
evolutie
Certificatie
Artefacten
Hulp bij ontwikkelen van
en met herbruikbare
artefacten
Projectteams
Ontwikkelen van
herbruikbare artefacten
Herbruikbare
artefacten
Ontwikkelen met
herbruikbare artefacten
- Opslag herbruikbare artefacten
in SourceForge na goedkeuring
- Onderhoud en beheer
herbruikbare artefacten
SourceForge
- Opslag
- Beheer
- Zoeken & downloaden
herbruikbare artefacten.
- Doorgeven bugs &
change Requests
Figuur 29 - Organisatiestructuur voor hergebruik binnen M&S.
Het voordeel van deze aangepaste ‘team producer’ structuur is dat de projecten het
daadwerkelijke werk blijven doen en de hergebruikstuurgroep dit bij wijze van
spreke dirigeert. Tevens voorziet deze structuur in het projectoverschrijdende
karakter van hergebruik, wat nu nog niet geregeld is binnen M&S. Door deze
structuur verdwijnt er wel een deel van de vrijheid van de projecten en software
engineers omdat zij herbruikbare artefacten moeten gaan ontwikkelen en
gebruiken. Software engineers zullen hiertegen het argument gebruiken dat een
deel van de creativiteit verloren gaat. Dit is echter niet valide. Het biedt de software
ontwikkelaars juist een kans om minder tijd kwijt te zijn aan ‘standaard’ aspecten.
De drie entiteiten in Figuur 29, de hergebruikstuurgroep, de projectteams en
SourceForge worden in het restant van deze paragraaf besproken.
5.3.2
Projectteams
De projectteams blijven primair verantwoordelijk voor het ontwikkelen van
software voor de opdrachtgevers. Dit is hun taak en hergebruik dient enkel om een
positieve bijdrage te leveren aan dit proces. Door hergebruik veranderen er twee
belangrijke aspecten voor de projectteams. Zij gaan namelijk herbruikbare
artefacten ontwikkelen en ontwikkelen met herbruikbare artefacten.
1 Productie van herbruikbare artefacten.
Herbruikbare artefacten kunnen op drie manieren worden verkregen, via domein
engineering, re-engineering en via externe bronnen. Tevens kan dit op drie
momenten plaatsvinden, voor, tijdens of na een project. Gezien de geringe omvang
van het aantal software engineers en de heterogeniteit in de softwareontwikkeling,
is het systematisch toepassen van domein engineering een riskante optie. In de
theorie wordt het wel aangedragen als een belangrijke factor voor hergebruik, het
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
119
wordt echter ook beschreven als een riskante en dure methode. Om die reden wordt
het vooral toegepast in grotere organisaties met een gedegen mate van
softwareontwikkeling en een hoge mate van homogeniteit in de softwareproducten
die ontwikkeld worden.
Domein analyses en engineering voor de ontwikkeling van herbruikbare software
artefacten is slechts beperkt toepasbaar binnen M&S. M&S is binnen verschillende
applicatiedomeinen actief en binnen deze domeinen bestaat er vaak ook nog weinig
homogeniteit in de ontwikkelde software producten. Het zou een zeer kostbare
aangelegenheid zijn om binnen elk van deze applicatiedomeinen domein
engineering toe te passen. Hergebruik zal binnen M&S daarom nog steeds veelal
op basis van re-engineering plaats blijven vinden. De productie van herbruikbare
artefacten moet daarom tijdens de projecten uitgevoerd worden. Dit kan op twee
manieren opgestart worden.
Ten eerste via een opdracht vanuit de hergebruikstuurgroep aan een project. Door
software architecten uit de hergebruikstuurgroep deel te laten nemen aan een
project gedurende de system engineering fase, waarin het SSS en SSDD worden
geschreven, kunnen zij inzicht krijgen in de opbouw van het systeem en mogelijke
herbruikbare artefacten die ontwikkeld kunnen worden binnen dat project. Op deze
manier hebben zowel het project als de hergebruikstuurgroep baat bij de productie
van het herbruikbare artefact. De overhead die wordt gemaakt voor het produceren
van het herbruikbare artefact wordt vergoed door de hergebruikgroep. Hiervoor
wordt op basis van de eisen en functionaliteit van het herbruikbare artefact een
schatting gemaakt van de benodigde tijd en dus kosten.
Ten tweede kan een projectteam ook zelf een kans voor hergebruik identificeren en
een herbruikbaar artefact ontwikkelen. Het is hierbij echter wel belangrijk dat het
project, voordat het begint met het ontwerpen en implementeren van het
herbruikbare artefact, contact opneemt met de hergebruikgroep en een document
van eisen voorlegt (SRS) en, indien dit wordt goedgekeurd, ook een ontwerpplan
van het artefact (SDD). Het is immers niet wenselijk dat de projectteams een grote
verzameling aan herbruikbare artefacten gaan produceren die niet hergebruikt
worden en dus niet meer terugverdiend kunnen worden. Indien de
hergebruikstuurgroep instemt met het ontwikkelen van het herbruikbare artefact
wordt er wederom, door de hergebruikstuurgroep, een schatting gemaakt van de
benodigde uren en wordt het project hierin gecompenseerd.
Figuur 30 toont de verschillende stappen in het productieproces en de rol van de
hergebruikstuurgroep en de projectteams.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
120
Figuur 30 - Productieproces voor een herbruikbaar artefact.
Door het artefact in een projectteam te laten ontwikkelen, waar de behoefte voor
een dergelijk artefact reeds bestaat, ontstaat er een soort ‘just in time’-constructie
waarbij het herbruikbare artefact wordt geproduceerd op het moment dat de
behoefte ervoor bestaat.
Binnen de afdeling M&S wordt er ook gebruikt gemaakt van open-source software
en commerciële software. Bij de keuze voor een ‘extern’ software artefact dient er
rekening gehouden te worden met de kosten ten op zichte van het zelf ontwikkelen
en de mogelijke ondersteuning en betrouwbaarheid van het component. Het is aan
te bevelen om, waar mogelijk, het gebruik van de commerciële pakketten te
standaardiseren. Software pakketten zoals LuciadMap zijn redelijk complex en het
kost daarom ook veel manuren om ermee te kunnen werken.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
121
2 Consumptie van herbruikbare artefacten.
De beslissing om bepaalde herbruikbare software artefacten te hergebruiken komt
tussen de projecten en de hergebruikstuurgroep te liggen. Het mag niet zo zijn dat
een projectteam unilateraal beslist om niet(s) te hergebruiken terwijl er wel
duidelijke mogelijkheden voor zijn. Tevens moeten de projectteams consequent,
reeds vanaf het offertetraject, rekening houden met hergebruik. Op welk precieze
moment er voor een bepaald herbruikbaar artefact wordt gekozen is afhankelijk
van het type artefact. Zo moet de keuze voor een bepaalde architectuur of
framework in een vroeg stadium genomen worden. In deze fase van het proces is er
echter nog geen goed inzicht in de precieze samenstelling van de
softwareapplicatie en kan er dus ook nog geen uitspraak worden gedaan over
eventueel hergebruik van de kleinere software artefacten.
In de ontwerpfase, nadat het systeem uiteen is getrokken in de verschillende
subsystemen en de relaties ertussen bekend zijn, kan er gekeken worden naar de
‘normale’ herbruikbare componenten, bijvoorbeeld naar de statemachine, de
monitor of de Orbat Browser. Hergebruik van software artefacten van nog kleinere
granulariteit zoals stukken code of classes, zoals bij adhoc hergebruik veel
voorkomt, wordt hier niet meegenomen. Het zal ongetwijfeld blijven bestaan, maar
er is geen noodzaak aanwezig om dit te reguleren. De opbrengsten ervan staan in
geen verhouding tot het hergebruiken van de grotere software artefacten.
Figuur 31 toont de verschillende fasen van het softwareontwikkelproces en de
keuzes voor bepaalde type herbruikbare artefacten. Over het algemeen geldt dat
hoe eerder er wordt nagedacht over hergebruik hoe groter de mogelijke voordelen
ervan zijn.
Om hergebruik reeds vroeg in het softwareontwikkelproces te borgen, moet er een
review procedure gehanteerd worden met betrekking tot de keuze voor hergebruik.
In deze reviewprocedure moeten de projectteams toelichten welke herbruikbare
artefacten zij denken te gaan hergebruiken en waarom zij bepaalde keuzes maken,
zoals het niet hergebruiken van een bepaald herbruikbaar artefact waar dit wel
mogelijk en wenselijk zou zijn. De plannen voor hergebruik worden beoordeeld
door de hergebruikstuurgroep en deze kan het projectteam adviseren en aanspreken
op bepaalde keuzes. Indien een projectteam bij de gemaakte keuzes blijft is het
natuurlijk ook volledig verantwoordelijk indien het project hierdoor vertraging of
budgetsoverschrijding oploopt.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
122
Keuze voor grotere herbruikbare artefacten
zoals architecturen een TBM of een
framework. Keuze genomen door
projectleider i.s.m. hergebruikstuurgroep
Offertetraject
Analysis
Keuze voor de herbruikbare artefacten zoals
een statemachine, monitor etc. Keuze door
projectteam
Design
Implementation
Keuze voor de kleine herbruikbare artefacten
zoals open source tools, javabeans of libraries
en kleine componenten uit eerdere projecten.
Keuze genomen door individuele
ontwikkelaar
Testing
Maintenance
Tijdlijn
Figuur 31 - Fasen in het softwareontwikkelproces en keuzes voor hergebruik.
Hergebruik heeft een grote invloed op het budget en de planning van een project.
In de huidige situatie wordt tijdens de software-offertetrajecten op basis van
schattingen door software engineers het benodigde budget en de looptijd
vastgesteld. Dit is dus gebaseerd op ervaring en eigen inzicht, er zijn geen
historische gegevens voorhande. Indien M&S systematisch gaat hergebruiken moet
er bij het vaststellen van het budget en de looptijd rekening worden gehouden met
hergebruik van software artefacten. Hiervoor moet er een duidelijk beeld bestaan
van het te ontwikkelen systeem en de subsystemen hierin. Dit betekent dus ook dat
er al een keuze moet worden gemaakt om bepaalde herbruikbare artefacten wel of
niet te hergebruiken. Het komt echter voor dat er al in het offerteproces een budget
en planning worden opgesteld zonder dat er een degelijk vooronderzoek is gedaan.
Het is dan moeilijk om de keuze voor hergebruik in een dergelijke werkwijze te
integreren aangezien er beperkt inzicht is in het te ontwikkelen systeem
Mogelijke voordelen bij de
keuze voor hergebruik van
software
Inzicht in de applicatie en
mogelijkheden voor hergebruik
Tijd / fase in het
softwareontwikkelproces
Figuur 32 - Hergebruikdilemma: mogelijke voordelen vs. inzicht.
Dit creëert een dilemma: enerzijds moet er reeds bij het vaststellen van de planning
en het budget voor een project rekening worden gehouden met hergebruik van de
grote artefacten. Anderzijds is er in deze fase nog geen inzicht in de opbouw en
samenstelling van het te ontwikkelen systeem. Figuur 32 geeft een indicatie van dit
dilemma.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
123
Voor de afdeling Modelling & Simulation is het belangrijk om in te zien dat er een
groot verschil bestaat in de producten die ontwikkeld worden, van demo’s en
prototypes tot operationele systemen. Voor de kleinere opdrachten is het niet reëel
om te zeggen dat hergebruik een besparing kan opleveren, het komt er meer op
neer dat door middel van hergebruik, voor dezelfde prijs, sneller een uitgebreider
product kan worden geleverd. Het vormt dus bij kleiner projecten vooral een
productiviteitsverbetering.
Bij de grotere projecten kan hergebruik wel degelijk voor besparingen zorgen. Om
dit te realiseren is het echter wel absoluut noodzakelijk dat er bij het opstellen van
het budget al rekening wordt gehouden met hergebruik. Hiervoor is het ook
noodzakelijk dat er redelijk nauwkeurig kan worden bepaald wat het voordeel per
hergebruikt artefact zal zijn. In de huidige manier van werken zal dit heel moeilijk
zijn en zal het voordeel enkel op basis van grove schattingen bepaald worden.
Indien er bij het opstellen van het budget echter geen rekening wordt gehouden met
de mogelijke voordelen zal hergebruik niet neerkomen op een besparing maar
enkel op een productiviteitsverbetering aangezien de tijdswinst door hergebruik zal
worden gebruikt als buffer voor andere zaken. Figuur 33 geeft een indicatie van
wat hergebruik voor kleine en grote projecten binnen M&S kan betekenen.
Zonder hergebruik
Met hergebruik
Gelijkblijvende
functionaliteit lagere
prijs
Prijs
Prijs
Gelijkblijvende prijs
meer functionaliteit
Kleine projecten
Grote projecten
Functionaliteit
Functionaliteit
Figuur 33 - Betekenis van hergebruik binnen M&S.
5.3.3
Hergebruikstuurgroep
De hergebruikstuurgroep moet de projectteams kunnen sturen in het produceren en
consumeren van herbruikbare artefacten. Daarom is het noodzakelijk dat de
hergebruikstuurgroep de autoriteit heeft om dit te kunnen doen. Momenteel bestaat
er reeds een hergebruikgroep, bestaande uit software engineers en projectleiders.
De hergebruikstuurgroep staat hier los van, het is een nieuwe groep. Gezien de
taken van de hergebruikstuurgroep, zoals het sturen van de productie & consumptie
en het onderzoeken van het domein op mogelijk herbruikbare artefacten, is het
noodzakelijk dat de groep is opgebouwd uit personen in hogere functies met meer
zeggenschap over de projecten en personen die een zeer goed inzicht hebben in de
softwareproducten die er binnen de afdeling M&S worden ontwikkeld en (sterk)
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
124
voorstander zijn van hergebruik. De technologietrekker en het afdelingshoofd
lijken hier geschikte kandidaten voor de sturing van de projecten, zie ook § 4.2.3.
Het afdelingshoofd moet erbij betrokken worden omdat hij degene is die de
samenstelling van de projectteams verzorgt en op deze manier een borging en
verspreiding van de kennis over de herbruikbare artefacten kan realiseren. De
verdere invulling moet bestaan uit senior software engineers en software
architecten die de projecten bijstaan bij de keuze voor hergebruik.
De hergebruikstuurgroep heeft vier globale taken.
1. Sturing projectteams
De afdeling M&S voert circa 20 softwareprojecten op jaarbasis uit. Dit zijn
zowel grotere projecten waarin operationele systemen worden gebouwd op
specificatie van klanten, als softwareproducten die vanuit een kennisbehoefte
en visie van TNO worden ontwikkeld tot kleine projecten voor demo´s en
prototypen.
Aangezien er op jaarbasis slechts een beperkt aantal softwareprojecten, met
kansen op hergebruik, worden gestart is het noodzakelijk dat de kansen tot
hergebruik worden benut. Het is immers kapitaalvernietiging om elke keer het
wiel opnieuw uit te vinden. In § 5.6 wordt doormiddel van een business case
voor hergebruik een indicatie gegeven van de financiële aspecten.
Voor de productie geldt dat er een goede grip op de ontwikkeling van de
herbruikbare artefacten moet worden gehouden. De gedane investeringen voor
het ontwikkelen van herbruikbare artefacten moeten immers ook terugverdiend
worden. M&S heeft niet de homogeniteit in de ontwikkelde software en
‘massa’ qua softwareontwikkeling om hergebruik ongestuurd te laten.
Sturing productie van herbruikbare software artefacten
In de theorie worden verschillende manieren van sturing beschreven, zie
§ 3.5.2. Om de projectteams de herbruikbare artefacten te laten ontwikkelen
kan de hergebruikgroep een combinatie van een facilitaire en rationeel
empirische of facilitaire en directieve sturing toepassen. Met andere woorden,
het (financieel) ondersteunen van die projecten die herbruikbare software
artefacten ontwikkelen in combinatie met overleg of dwang. In sommige
gevallen zal een project in goed overleg met de hergebruikstuurgroep dus een
herbruikbaar software artefacten ontwikkelen en in andere gevallen kan de
hergebruikstuurgroep dit opleggen. In de huidige situatie heeft het ontwikkelen
van herbruikbare software artefacten, financieel gezien, een nadeling effect op
het project. Dit wordt met deze facilitaire sturing ondervangen.
De hergebruikstuurgroep houdt door twee maatregelen grip op de ontwikkeling
van nieuwe herbruikbare software artefacten. Ten eerste doordat de
hergebruikstuurgroep de ontwikkeling van een herbruikbaar software artefact
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
125
moet goedkeuren. De hergebruikstuurgroep bepaalt of er behoefte aan is en of
het niet reeds in een andere vorm beschikbaar is. Hierbij moet ook een business
case worden ontwikkeld waarin een verantwoording wordt gegeven van de
benodigde investering voor het ontwikkelen van het herbruikbare artefact. Om
te kunnen bepalen wat wel en wat niet herbruikbaar moet worden gemaakt
moet de hergebruikstuurgroep een goed inzicht hebben in de software die
wordt ontwikkeld binnen de afdeling Modelling & Simulation. Hiervoor kan de
hergebruikstuurgroep gebruik maken van domeinkennis en technisch inzicht en
van wensen en behoeften van de projectteams m.b.t. herbruikbare artefacten.
Projecten kunnen dus zelf aangeven als ze iets herbruikbaar willen maken en
de hergebruikstuurgroep kan deze opdracht geven. De tweede maatregel is dat
de hergebruikstuurgroep de herbruikbare artefacten beoordeelt nadat deze zijn
ontwikkeld, het certificatieproces. Door deze twee maatregelen heeft de
hergebruikstuurgroep grip op de ontwikkeling van herbruikbare artefacten.
De hergebruikstuurgroep bepaalt dus of er behoefte is aan specifieke
herbruikbare artefact en of het ontwikkelen ervan financieel verantwoord is.
Tevens bepaalt de hergebruikstuurgroep of het uiteindelijke resultaat in
overstemming is met de vooraf gestelde eisen en of het dus, gecertificeerd, in
SourceForge wordt opgenomen.
Deze opzet voldoet ook aan de wensen die binnen M&S leven. Tijdens de
groepssessie, zie Bijlage I, bleek dat een meerderheid achter een stricte sturing
op ontwikkeling van herbruikbare artefacten staat. Belangrijke punten die
hierbij naar voren kwamen waren de dialoog tussen de hergebruikstuurgroep
en de projectteams en de kosten van de ontwikkeling. Met het bekostigen van
deze ontwikkelingskosten en de mogelijkheid tot overleg met de
hergebruikgroep zijn deze tegenargumenten goed opgevangen.
Sturing consumptie
Bij de sturing van de consumptie bestaan dezelfde keuzes als bij de productie
van herbruikbare artefacten. Dus beloning, dwang en advisering. Beloning is
hier ongepast aangezien een projectteam al voordeel haalt uit het hergebruiken
van de bestaande software artefacten. Een sturing puur gebaseerd op dwang zal
veel weerstand veroorzaken bij de projecten. Dit bleek ook tijdens de
groepsessie, zie Bijlage I. Een combinatie van dwang en advisering is de beste
keuze. Bij sommige herbruikbare artefacten zal er immers weinig discussie
bestaan of een project het kan en zou moeten hergebruiken. Bij andere
herbruikbare artefacten, waar dit niet direct vaststaat, zal een afweging
gemaakt moeten worden tussen de voordelen en consequenties voor het
project.
De sturing van de consumptie gebeurt op basis van de reviewprocedure. Bij
aanvang van een nieuw project moet het projectteam met een voorstel komen
van de opzet van het te ontwikkelen softwareproduct. Hierbij moet duidelijk
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
126
aangegeven worden welke onderdelen met herbruikbare artefacten worden
ingevuld en wat nieuw ontwikkeld gaat worden. Hiervoor moet het projectteam
ook terecht kunnen bij de hergebruikstuurgroep voor advies. Het voorstel van
de projectleider over de samenstelling van zijn applicatie wordt beoordeeld
door de hergebruikstuurgroep, waarbij er wordt gekeken naar de
gebruikmaking van bestaande herbruikbare artefacten of COTS-producten. In
deze beoordeling geeft de hergebruikstuurgroep een advies, deels vrijblijvend
deels dwingend, over de keuze van het projectteam.
2. Support voor de projectteams
Niet alle software engineers en projectleiders zijn bekend met hergebruik of de
beschikbare herbruikbare artefacten. Daarom is het belangrijk dat de
hergebruikstuurgroep ook support biedt aan de projectteams. De ondersteuning
voor de projectteams omvat verschillende activiteiten, namelijk:
-
advisering bij de keuze voor hergebruik,
ondersteuning bij de productie van herbruikbare artefacten,
ondersteuning bij het hergebruiken van herbruikbare artefacten.
De leden van de hergebruikstuurgroep kunnen zelf de projectteams
ondersteunen bij de keuze voor hergebruik en specifieke herbruikbare
artefacten. Software architecten met kennis van de verzameling herbruikbare
artefacten kunnen in de offertefase en of ontwerpfase van een project helpen
bij de keuze voor herbruikbare software artefacten.
Ook voor de andere twee activiteiten kunnen software engineers ingeschakeld
worden. Het verstandig om bij de ondersteuning van een herbruikbaar artefact
de ontwikkelaar of verantwoordelijke, twee rollen die waarschijnlijk door
dezelfde persoon worden uitgevoerd, in te schakelen. Om de projectteams te
ondersteunen bij het ontwikkelen van herbruikbare software artefacten kan de
hergebruikstuurgroep ervaren software engineers inschakelen om het
projectteam te ondersteunen. Dit is onderdeel van de facilitaire sturing.
De hergebruikstuurgroep kan onmogelijk zelf de ondersteuning bij het gebruik
van alle herbruikbare artefacten op zich nemen. Daarom is de
hergebruikstuurgroep ook verantwoordelijk voor het organiseren van
ondersteuning bij herbruikbare artefacten. De hergebruikstuurgroep moet
hiervoor de bevoegheid hebben individuele software engineers toe te wijzen
aan een herbruikbaar artefact. Over het algemeen is het aan te raden de
ontwikkelaar van het herbruikbare artefact verantwoordelijk te maken. Het
moet echter niet zo zijn dat software engineer X die verschillende projecten
heeft geholpen bij het produceren van herbruikbare artefacten verantwoordelijk
wordt voor een gehele verzameling van herbruikbare artefacten. Dit zou een te
grote belasting van enkele software engineers tot gevolg kunnen hebben. Er
moet dus voor worden gezorgd dat er een brede ondersteuning ontstaat voor de
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
127
herbruikbare artefacten. Op deze manier wordt ook het gebruik van de
herbruikbare software artefacten beter geborgd.
Indien een software engineer M&S verlaat, mag het niet zo zijn dat
ondersteuning en beheer van de herbruikbare artefacten, die onder zijn hoede
vielen, wegvallen. Dit kan op verschillende manieren verholpen worden.
Indien het artefact door meerdere personen is ontwikkeld is dit geen probleem,
één van de andere ontwikkelaars wordt aangewezen om het artefact te beheren.
Een andere mogelijkheid is om enkele software engineers, uit projecten die het
artefact hergebruiken, bekend te laten worden met het herbruikbare artefact
zodat ook zij ondersteuning kunnen bieden aan toekomstige hergebruikers.
Deze structuur waarbij de (groepjes) software engineers verantwoordelijk zijn
voor het beheer en de ondersteuning van de herbruikbare artefacten wordt ook
gesteund binnen M&S, zie Bijlage I. Afhankelijk van het herbruikbare artefact
is dit één persoon of een groep personen. De beheerders vormen een concreet
aanspreekpunt voor snelle ondersteuning en support.
3. Beheer & evolutie van de herbruikbare artefacten
Voor systematisch hergebruik van software artefacten is het noodzakelijk dat
er een aantal processen zijn geregeld. De relevante processen zijn:
-
configuratie management en versiebeheer,
problem and change management.
Voor veel van deze processen heeft TNO-D&V reeds procedures opgesteld die
ook gehanteerd kunnen worden voor hergebruik. Zo zijn er voor configuratie
management en problem and change management reeds TNO-D&V wijde
Codes of Practice beschikbaar.
Net zoals de verantwoordelijkheid voor de ondersteuning bij de productie en
consumptie van herbruikbare artefacten, is de hergebruikstuurgroep ook
verantwoordelijk voor het beheer en onderhoud van de herbruikbare artefacten.
Wederom is de hergebruikstuurgroep niet in staat deze taken zelf uit te voeren,
daarom worden deze taken toegewezen aan de software engineers. Dezelfde
persoon of groep personen die verantwoordelijk is voor de ondersteuning van
het software artefact is ook verantwoordelijk voor het beheer ervan.
Configuratie Management en Versiebeheer
De Code of Practice die voor Configuratie Management is gedefinieerd door
het IT/QA kan goed gehanteerd worden voor hergebruik van software. In de
huidige situatie is het niet uniek dat er problemen voorkomen als gevolg van
verschillende wensen aan een specifiek herbruikbaar artefact. In het MOSES
project komt het voor dat er gedeelde objecten uit de repository worden
aangepast waardoor andere projecten er niet meer mee kunnen werken. Een
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
128
andere voorbeeld zijn de herbruikbare artefacten die binnen Kibowi MP zijn
ontwikkeld. Deze componenten worden al in andere projecten hergebruikt
terwijl ze formeel nog puur onderdeel zijn van Kibowi MP. Nu komt het voor
dat er change requests worden ingediend die ervoor kunnen zorgen dat het
artefact binnen Kibowi MP niet meer werkt. Onafhankelijk van hoe dit
georganiseerd wordt, blijven dit soort kwesties bestaan. Conflicten door change
requests zijn inherent verbonden aan hergebruik aangezien de herbruikbare
artefacten door verschillende projecten in verschillende contexten hergebruikt
worden. Gezien deze mogelijke conflicten is het belangrijk om vast te leggen
op basis waarvan de beslissing genomen wordt om een bepaalde wijziging wel
of niet te verwerken. Dit wordt verder besproken bij Problem and Change
Management.
Deze diversiteit in wensen aan een herbruikbaar artefact kan leiden tot
verschillende branches. Een branch van een herbruikbaar artefact is een
aftakking van het originele herbruikbare artefact.
In principe zijn branches van herbruikbare artefacten onwenselijk, er moet
immers een apart configuratie management proces voor bestaan en hoe verder
de branches uit elkaar groeien hoe meer werk erin gaat zitten aan
ondersteuning, onderhoud en configuratie management en dergelijke. Dit kan
opgelost worden door een herbruikbaar artefact gelocked te laten, dat wil
zeggen dat er geen branches mogen ontstaan. Indien een project toch persé het
artefact op een andere wijze wil gebruiken kunnen zij het lokaal gebruiken, dus
echt beperkt tot dat project. Het lokale artefact mag echter niet in andere
projecten verder hergebruikt worden. Daarvoor dient de originele branche
gehanteerd te worden. Het nadeel van deze optie is, dat indien er een nieuwe
versie van het originele herbruikbare artefact wordt gereleased het project met
de lokale versie elke keer de afweging moet maken om hier wel of niet in mee
te gaan.
Problem and Change Management
Onderhoud en evolutie hangen natuurlijk samen met het Problem and Change
management aangezien de fouten en gewenste wijzigingen die hierbij gemeld
worden via onderhoud en verdere ontwikkeling verholpen worden. Net zoals
de COP voor Configuratie Management kan hier de COP voor Problem and
Change Management gehanteerd worden. SourceForge biedt de mogelijkheid
een problem report of change request te melden bij de verantwoordelijke van
het herbruikbare artefact.
Fouten dienen natuurlijk zo snel mogelijk verholpen te worden. De
projectteams moeten hiervoor direct terecht kunnen bij de beheerder van het
artefact. Aangezien de broncode beschikbaar is kan een projectteam ook zelf
de bug verhelpen. De bugfix moet wel teruggekoppeld worden aan de
beheerder zodat hij dit kan verwerken in het, onder beheer zijnde, herbruikbare
artefact. Het kan natuurlijk voorkomen dat er fouten optreden doordat het
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
129
herbruikbare artefact op een manier wordt gebruikt waarvoor hij niet bedoeld
is. In dit geval kan de afhandeling van het problem report op dezelfde manier
worden behandeld als een change request, Figuur 34 geeft dit proces weer.
Hergebruik heeft een impact op het change request proces. Bij het proces
‘configuratie management’ is er reeds kort gesproken over conflicterende
wensen aan herbruikbare artefacten. Hiermee worden change requests bedoeld
die, in het geval dat ze worden gerealiseerd, tot gevolg hebben dat een andere
partij het artefact niet meer kan gebruiken. Om hier goed mee om te kunnen
gaan zou de beheerder van het herbruikbare artefact inzicht moeten hebben in
alle projecten die dit artefact hergebruiken. Hij moet immers inzicht hebben in
de manier waarop het artefact in die projecten wordt hergebruikt en een
afweging kunnen maken van de impact die de wijziging zal hebben op de
werking van het artefact in die projecten. Deze aanpak is voor korte tijd ook
gehanteerd binnen het EBF. Er is echter vanaf gestapt aangezien het een zeer
zware belasting vormde op het configuratie management van de herbruikbare
artefacten.
Figuur 34 - Proces voor Change Requests bij een herbruikbaar artefact.
Omdat projectteams zelf de toegang hebben tot de broncode kunnen zij ook
extra functionaliteit toevoegen of wijzigingen aanbrengen. Deze aangepaste
artefacten zijn echter lokale versies. Het projectteam kan de wijzigingen
voorstellen bij de beheerder van het artefact. De beheerder beslist of het ook
wordt opgenomen in het centraal beheerde artefact. De beheerder(s) van het
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
130
herbruikbare artefact beoordeelt dus de problem & change requests. Indien er
grote conflicten ontstaan kan de beheerder in overleg met de
hergebruikstuurgroep tot een besluit komen over het change request. Dit proces
wordt weergegeven in Figuur 34.
4. Certificatie van de herbruikbare artefacten
Hergebruiken van kwalitatief slechte herbruikbare artefacten is volgens de
theorie een belangrijke faalfactor, zie § 3.2.2. Ook binnen M&S vormt gebrek
aan vertrouwen in de herbruikbare artefacten een belangrijke factor om een
artefact zelf te ontwikkelen. Daarom is het noodzakelijk om de herbruikbare
artefacten die voor beheer worden opgenomen in SourceForge eerst worden
getoetst aan een aantal eisen.
De eisen waaraan het getoetst wordt staan vermeld in § 5.2.3. De belangrijkste
factoren waaraan het getoetst moet worden zijn:
-
is er overlegd met de hergebruikstuurgroep en is er een business case
ontwikkeld,
voldoet het artefact aan de gewenste standaarden,
is de documentatie compleet,
is het herbruikbare artefact naar behoren getest?
Indien het artefact niet voldoet aan de gestelde eisen is de ontwikkelaar zelf
verantwoordelijk voor correctie van de geconstateerde afwijkingen. Indien de
ontwikkelaar de gewenste correcties heeft aangebracht kan hij het artefact
opnieuw indienen bij de hergebruikstuurgroep. Indien het artefact wordt
goedgekeurd wordt het als herbruikbaar artefact opgenomen in SourceForge.
Artefacten die dus niet zijn goedgekeurd mogen niet worden opgenomen in
SourceForge.
Binnen het EBF is hiervoor reeds een COP opgesteld, Verificatie, Validatie en
Accreditatie, oftewel certificatie. Deze COP beschrijft de werkwijze met
betrekking tot de ontwikkeling van nieuwe EBF-componenten. Dit is ook
toepasbaar op de herbruikbare artefacten.
5.3.4
SourceForge
Binnen BU2 is er reeds een repository aanwezig waarin de herbruikbare artefacten
centraal kunnen worden opgeslagen, beheerd en gedistribueerd, namelijk
SourceForge. SourceForge is gekoppeld met de tool CVS zodat
configuratiemanagement en versiebeheer ook uitgevoerd kunnen worden.
SourceForge biedt ondersteuning bij verschillende aspecten van hergebruik:
-
centrale opslag van herbruikbare artefacten,
opslag en ordening van documenten bij een herbruikbare artefact,
toewijzen van taken aan personen,
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
131
-
melden van probleem of change request,
opslag van de broncode van een herbruikbaar artefact in CVS,
het beheren van file-releases,
discussieforum binnen een project,
het toewijzen van verschillende rollen aan leden van een project.
SourceForge is georganiseerd in projecten. Er is echter nog geen mogelijkheid om
de projecten te classificeren of sorteren. Dit betekent dat in SourceForge
momenteel de reguliere projecten en projecten voor herbruikbare artefacten door
elkaar heen zijn opgeslagen. Met ruim honderdtien projecten in SourceForge, circa
tien voor herbruikbare artefacten, is er geen duidelijk onderscheid tussen reguliere
projecten en projecten voor herbruikbare artefacten. Dit bemoeilijkt het inzicht in
de herbruikbare artefacten. Tevens zijn momenteel een aantal projecten van
herbruikbare artefacten afgeschermd, dat wil zeggen dat alleen de projectleden
toegang hebben. SourceForge biedt wel de mogelijkheid om binnen de projecten te
zoeken op aspecten zoals projectnaam, projectleden, nieuws, discussies e.d. maar
dit heeft ook weinig nut m.b.t. hergebruik.
VA Software, de leverancier van SourceForge, heeft voor SourceForge 4.3 een reuse portal en Wiki integratie op het programma staan. In de huidige versie, 4.2, is
dit nog niet beschikbaar. Wiki integratie en een reuse portal maken SourceForge
wel geschikter voor hergebruik. Voor zover als het er nu naar uitziet bevat deze
reuse portal wel de functionaliteit om categorieën aan te maken en om hierop te
zoeken. Verder kunnen gebruikers ook feedback geven over de herbruikbare
artefacten en daarmee een waardering toekennen. De precieze invulling van deze
reuse portal is echter nog onbekend.
Opslag & Beschikbaarheid van de herbruikbare artefacten
SourceForge is de spil in de opslag en verspreiding van herbruikbare artefacten.
Indien een hergebruiker iets zoekt moet hij hier terecht kunnen. Momenteel zijn
niet alle herbruikbare artefacten in SourceForge opgenomen, wat tot gevolg heeft
dat het bestaan ook niet altijd bekend is. Verder zijn veel van de in SourceForge
opgeslagen herbruikbare artefacten niet vrij toegankelijk en ontbreekt het ook aan
een omschrijving ervan. Er zijn dus twee aspecten in de huidige situatie die
verbeterd moeten worden om hergebruik van software te stimuleren:
-
toegang tot herbruikbare componenten,
informatie over de beschikbare herbruikbare componenten.
Een goed voorbeeld van hoe een herbruikbaar artefact moet worden opgeslagen in
SourceForge is de ORB Kernel, en wel om de volgende redenen:
-
open toegankelijk,
duidelijk aanspreekpunt beschikbaar,
projectnieuws beschikbaar,
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
132
-
ontwerp documentatie en gebruikershandeleiding zijn beschikbaar,
zowel gecompileerd als ongecompileerd (broncode) beschikbaar,
er is een overzicht van de gedane wijzigingen per versie,
het biedt inzicht in de ontwikkeling van het artefact doordat er inzicht is in
de openstaande bugs en change requests,
het biedt de mogelijkheid om een probleem of change request te melden.
Zoals in Figuur 30 is te zien worden herbruikbare artefacten alleen in SourceForge
opgenomen indien ze zijn goedgekeurd in het certificatie proces. Er zijn dus enkel
final releases beschikbaar, uitgekristaliseerde versies voorzien van de benodigde
documentatie. Indien de herbruikbare artefacten vrij toegankelijk zijn binnen
SourceForge en de broncode dit ook is moet er wel rekening worden gehouden met
security issues. Zo kan het onwenselijk zijn dat ingehuurde software engineers van
externe organisaties toegang hebben tot de broncode.
Er bestaat in de huidige situatie geen inzicht in welke herbruikbare artefacten er
beschikbaar zijn binnen de afdeling M&S. In § 4.2 is een opsomming te vinden van
een aantal herbruikbare software artefacten maar het is onbekend of deze ook
helemaal compleet is. Verder is er nog geen centraal punt waar deze informatie
beschikbaar is. Weten wat er beschikbaar is voor hergebruik is natuurlijk wel
essentieel om te kunnen hergebruiken. Met SourceForge is hier een eerste stap in
gezet, maar het moet ook zo zijn dat alle herbruikbare artefacten hierin worden
opgenomen. Tevens moet er een manier zijn om een overzicht te krijgen van de
herbruikbare artefacten die in SourceForge beschikbaar zijn. Momenteel is dit nog
niet mogelijk, in toekomstige versies van SourceForge wellicht wel. In de
tussentijd is het aan te raden om een aparte intranetsite te creëeren voor de
herbruikbare artefacten. Op deze intranetsite moet een overzicht beschikbaar zijn
van alle herbruikbare artefacten met een korte beschrijving per artefacten. Hierin
moet zijn beschreven waarvoor het artefact kan worden gebruikt, in welke taal het
ontwikkeld is, wie het aanspreekpunt is en mogelijk een indicatie van de
geïnvesteerde ontwikkeluren. Deze sites met informatie over de herbruikbare
software artefacten moeten ook een directe link naar de locatie van het software
artefact in SourceForge bevatten.
SourceForge biedt ook de mogelijkheid om via monitoring op de hoogte te worden
gebracht van wijzigingen in de projecten van herbruikbare artefacten. Hierbij kan
een hergebruiker zelf bepalen of hij op de hoogte wil blijven van nieuwe versies,
change requests etc.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
133
5.4
Financiering van hergebruik
Hergebruik van software brengt verschillende kosten met zich mee. In § 3.1.3 is
een opsomming gegeven van de verschillende mogelijke kostenposten. Deze
paragraaf bekijkt welke kostenposten voor M&S relevant zijn en geeft een
overzicht van de manier waarop de verschillende kosten worden gefinancierd.
Deze paragraaf geeft geen kwantificatie van deze kostenposten, in § 5.6 worden
wel schattingen gegeven van deze waarden.
5.4.1
Baten van hergebruik
De baten van hergebruik liggen puur bij de projectteams en worden derhalve samen
beschreven. Hergebruik brengt voor de afdeling M&S verschillende voordelen met
zich mee, zie § 3.1.2 voor meer informatie over de voordelen door hergebruik.
-
Kostenbesparing door het hergebruiken van bestaande software artefacten
Kostenbesparing op het onderhoud van hergebruikte software
Betere kwaliteit van de ontwikkelde software
Hogere productiviteit
5.4.2
Lasten van hergebruik
De kosten van hergebruik worden door drie groepen binnen de afdeling M&S
gemaakt. Per groep worden de verschillende kosten toegelicht in Tabel 25 .
Kosten Projectteams
Toelichting
Ontwikkelingskosten van de
herbruikbare artefacten
Onderhoudskosten van de als
white box hergebruikte
artefacten
Dit omvat zowel de kosten voor het analyseren, ontwerpen,
ontwikkelen, testen en documenteren van herbruikbare artefacten.
Dit zijn de kosten die een project moet maken indien er een fout
wordt ontdekt (danwel door het projectteam zelf danwel door de
artefactverantwoordelijke in het originele artefact) en deze aangepast
moet worden in het aangepaste herbruikbare artefact.
Dit zijn de kosten die een project moet maken voor het testen van
herbruikbare artefacten die zijn aangepast (white box).
Kosten voor het testen van
aangepaste herbruikbare
artefacten
Kosten/baten analyse per
herbruikbaar artefact
Kosten voor het zoeken en
verkrijgen van herbruikbare
artefacten
Kosten voor het integreren van
herbruikbare artefacten
Kosten voor het updaten van
hergebruikte artefacten in het
geval van een nieuwe versie
Kosten voor het maken van een kosten/baten analyse bij de keuze om
een herbruikbaar artefact te ontwikkelen of her te gebruiken.
Dit zijn de kosten voor het zoeken en verkrijgen van een
herbruikbaar artefact. Let wel, het verkrijgen van de herbruikbare
artefacten, in de zin van het mogen hergebruiken, is kostenloos.
Kosten voor het integreren van het herbruikbare artefact in de
nieuwe applicatie.
Kosten voor het integreren van de nieuwe versie van het
hergebruikte artefacten. Keuze om mee te gaan met een nieuwe
versie ligt altijd bij het hergebruikende project.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
134
Kosten
hergebruikstuurgroep
Toelichting
Verkenning van mogelijkheden
voor de ontwikkeling van
herbruikbare artefacten
Sturing van de projectteams
Certificering van ontwikkelde
herbruikbare artefacten
Kosten voor het verkrijgen van inzicht in de softwareontwikkeling
binnen de afdeling M&S om op basis daarvan potentiële herbruikbare
artefacten te identificeren.
Kosten voor het sturen van de projectteams betreffende de
ontwikkeling van herbruikbare artefacten.
Kosten voor het adviseren van de projectteams betreffende het
hergebruiken van herbruikbare artefacten (reviewprocedure).
Kosten voor het verifiëren, valideren en accrediteren van de
ontwikkelde herbruikbare artefacten.
Kosten beheerders
Toelichting
Beheren van het herbruikbare
artefact in SourceForge
Kosten voor opslag en beheer van het herbruikbare artefact, de
bijbehorende documentatie en informatievoorziening. Dit omvat ook
het afhandelen en beoordelen van problem en change requests. Het
daadwerkelijk aanpassen van het artefact valt buiten deze kostenpost.
Kosten voor het onderhouden van de herbruikbare artefacten. Kan
opgestart worden naar aanleiding van een melding van een
hergebruiker en dienen als preventief of perfectief onderhoud.
Kosten voor het aanpassen en uitbreiden van het herbruikbare
artefact op verzoek van een projectteam.
Kosten voor het adviseren en ondersteunen van de projectteams over
het hergebruiken van een specifiek herbruikbaar artefact.
Advisering van de projectteams
Onderhoud van de herbruikbare
artefacten
Uitvoeren van change requests
Advisering en ondersteuning
aan de projectteams
Tabel 25 - Kostenposten door hergebruik voor M&S.
Veel van de genoemende kostenposten worden echter al meegenomen in de
berekening van de besparing van hergebruik. De theorie stelt dat het 20% van de
moeite kost om een artefact als black box te hergebruiken en dat het 67% van de
moeite kost om een artefact als white box te hergebruiken. Dit in vergelijking met
het zelf opnieuw ontwikkelen van het artefact. In deze percentages zijn kosten
opgenomen zoals:
-
kosten/baten analyse per herbruikbaar artefact,
kosten voor het zoeken en verkrijgen van herbruikbare artefacten,
kosten voor het integreren van herbruikbare artefacten,
onderhoudskosten van de als white box hergebruikte artefacten,
kosten voor het testen van aangepaste of geintegreerde herbruikbare
artefacten,
kosten voor het updaten van hergebruikte artefacten in het geval van een
nieuwe versie.
Om deze kosten te kunnen bepalen is het voor M&S noodzakelijk deze aspecten te
registreren. Hierbij is het belangrijk om duidelijk te definiëren wat er geregistreerd
moet worden en om een onderscheid te maken tussen de normale activiteiten en
activiteiten die specifiek voor hergebruik zijn. Indien er geen gegevens
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
135
geregistreert worden zal het zeer moeilijk zijn om, met enige mate van
nauwkeuringheid, te bepalen wat de kosten en opbrengsten van hergebruik zijn. Dit
zal echter binnen M&S een lastig processen blijken te zijn aangezien het niveau
van volwassenheid van het softwareontwikkelproces hier niet toereikend is. M&S
bevindt zich op CMM niveau 1 á 2 en het registreren van deze aspecten komt pas
voor in CMM niveau 3 á 4.
5.4.3
Verrekening van de baten en lasten van hergebruik
Zojuist zijn de verschillende kostenposten besproken en is aangegeven door wie
deze kosten worden gemaakt.
Kostenpost
Projectteams
Kostendrager
Ontwikkelingskosten van de herbruikbare artefacten
Onderhoudskosten door white box hergebruik
Kosten voor het testen van aangepaste herbruikbare artefacten
Kosten/baten analyse per herbruikbaar artefact
Kosten voor het zoeken en verkrijgen van herbruikbare artefacten
Kosten voor het integreren van herbruikbare artefacten
Kosten voor het updaten van hergebruikte artefacten in het geval
van een nieuwe versie
De hergebruikstuurgroep
Het project
Het project
Het project
Het project
Het project
Het project
hergebruikstuurgroep
Sturing van de projectteams
Advisering van de projectteams
Verkenning van mogelijkheden voor de ontwikkeling van
herbruikbare artefacten
Certificering van ontwikkelde herbruikbare artefacten
De hergebruikstuurgroep
De hergebruikstuurgroep
De hergebruikstuurgroep
De hergebruikstuurgroep
Artefactverantwoordelijke
Beheren van het herbruikbare artefact in SourceForge
Onderhoud van de herbruikbare artefacten
Behandelen van change requests
Uitvoeren van change requests
Advisering en ondersteuning aan de projectteams betreffende de
toepassing het herbruikbare artefact
De hergebruikstuurgroep
De hergebruikstuurgroep
De hergebruikstuurgroep
Het project
Het project
Tabel 26 - Overzicht van de kostenposten en de financiering hiervan.
Voor zover mogelijk worden de kosten die direct op een project zijn te boeken, ook
daadwerkelijk op het betreffende project geboekt. Dit creëert een eerlijke
verbintenis tussen de leverancier en afnemer van de geleverde dienst. Voor enkele
activiteiten is dit simpelweg niet mogelijk aangezien de kosten niet zijn toe te
wijzen aan specifieke projecten, bijvoorbeeld het correctieve of preventieve
onderhoud of de extra ontwikkelingskosten van een herbruikbaar artefact.
De kosten voor hergebruik worden, zoals uit Tabel 26 blijkt, uit twee bronnen
gefinancieerd. Enerzijds uit het bestaande budget van de projectteams, anderszijds
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
136
uit het budget van de hergebruikstuurgroep. Het budget voor de
hergebruikstuurgroep is noodzakelijk om te functioneren. Dit budget zal echter wel
ergens vandaan moeten komen. Het zou wenselijk zijn om de baten van hergebruik
deels te reserveren voor de hergebruikstuurgroep. Dit is echter praktisch
onmogelijk binnen M&S doordat ten eerste het inzicht in de hergebruikkosten
ontbreekt en ten tweede het zeer moeilijk is voor M&S om de baten van hergebruik
inzichtelijk te maken. Met het huidige niveau van softwareontwikkeling, CMM
niveau 1, is dit niet nauwkeurig te doen.
In de theorie, § 3.5.4, zijn een aantal methode beschreven om de kosten voor
hergebruik te verrekenen:
-
-
-
Overhead funding
Kosten voor hergebruik worden boven het budget van de projecten
verrekent als overhead.
Tax funding
Elk softwareproject staat een bepaald, vast of variabel, percentage van het
budget af voor de financiering van hergebruik.
Pay for use
Bij deze methode krijgt ieder herbruikbaar artefact een prijs dat het
hergebruikende project moet betalen.
De manier van verrekenen is een heel lastig punt binnen M&S, er is geen optimale
oplossing. M&S heeft zowel projecten op basis van nacalculatie als fixed-price. In
het geval van nacalculatie hebben de klanten inzicht in de prijsopbouw waar
hergebruik een invloed op heeft. Een keuze moet dus ook aan de klant te verkopen
zijn.
Pay for use is een eerlijke manier richting de klant om hergebruik te financieren.
Het project betaalt immers alleen voor datgene dat het hergebruikt. Binnen M&S
zal dit echter een flinke drempel vormen om te gaan hergebruiken, de projecten
moeten dan immers betalen voor de artefacten die ze hergebruiken. Dit levert
waarschijnlijk eindeloze discussies op over het bedrag dat men ervoor zou moeten
betalen aangezien iedereen de herbruikbare artefacten op een andere manier en met
een andere intensiteit hergebruikt. Tevens zal het, in het geval van vaste bedragen,
niet voor ieder project financieel mogelijk zijn om de artefacten te hergebruiken.
Bij tax funding wordt er een vast of variabel bedrag of percentage van de budgetten
van de software projecten gereserveerd voor hergebruik. De projectteams betalen
dus altijd mee, ongeacht of ze nu hergebruiken of niet. Binnen het EBF is deze
methode ook voor korte tijd toegepast. Hierbij betaalde de projecten die gebruik
maakten van het EBF een vast bedrag voor de faciliteit. Door ongelijke
betalingsverhoudingen is deze methode echter weer stopgezet.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
137
Uit de analyse van de huidige situatie leek ook naar voren te komen dat projecten
die financieel ‘gedwongen’ worden om te hergebruiken dit ook doen (case: Scope
project). Hierbij is het hergebruiken van de software artefacten wel gratis.
Het is dan ook aan te raden een minimumpercentage van de budgetten van de
projecten te reserveren voor financiering van de hergebruikstuurgroep en
ontwikkeling van herbruikbare software artefacten. Projecten die dus helemaal
niets kunnen hergebruiken betalen slechts een miniem percentage mee. Voor de
andere projecten kan een percentage, afhankelijk van bijvoorbeeld de hoeveelheid
hergebruik en het budget, gehanteerd worden. Om het simpel te houden kan er
bijvoorbeeld voor worden gekozen om drie niveaus van percentages te hanteren;
laag, middel en hoog. In § 5.6.3 is te zien dat de instandhouding van een
verzameling herbruikbare software artefacten die circa 10.000 ontwikkeluren
vertegenwoordigen plus de activiteiten van de hergebruikstuurgroep op jaarbasis
zo’n € 200.000 kosten. Dit is gemiddeld 5% van het budget van project, uitgaande
van een totaal budget van € 4.000.000,- op jaarbasis.
De keuze voor een percentage moet worden gemaakt in overleg met het
afdelingshoofd, de projectleider en de hergebruikstuurgroep.
Met de hierboven uitgestippelde verrekening van de verschillende activiteiten
worden de projectteams sterk gepushed om te hergebruiken. Enerzijds doordat zij
sowieso een percentage van hun budget moeten afstaan, onafhankelijk of ze er
uiteindelijk wel of niet hergebruiken, en anderzijds doordat de projectteams door
de hergebruikstuurgroep via de reviewprocedure worden geadviseerd over de
mogelijkheden van de herbruikbare artefacten binnen hun project.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
138
5.5
Stappenplan voor hergebruik
Deze paragraaf geeft een stappenplan voor de concrete invoering van hergebruik
van software artefacten. Het stappenplan is opgedeeld in drie perioden:
Korte termijn:
Middellange termijn:
Lange termijn:
nu – ½ jaar
½ jaar – 2 jaar
2 jaar – 5 jaar
De korte termijn beschrijft de opstartfase en een aantal concrete actiepunten, de
middellange termijn beschrijft globale actiepunten en de lange termijn beschrijft
een aantal mogelijkheden voor hergebruik.
5.5.1
Korte termijn – Opstartfase
Deze periode omvat de voorbereidingen voor de systematische toepassing van
hergebruik op de middellange termijn. Hierin is het essentieel om de
hergebruikstuurgroep op te richten, de bestaande verzameling herbruikbare
artefacten te inventariseren, de verzameling hergebruikklaar te maken en er
beheerders aan toe te kennen. Om opstartproblemen bij het hergebruiken van de
herbruikbare artefacten te voorkomen is het belangrijk dat deze zijn voorzien van
een API en een voorbeeld van gebruik of een demo en een beschrijving van wat
ermee gedaan kan worden. Dit kost een aantal uren, voorzover dit niet al is gedaan
bij de bestaande herbruikbare artefacten, maar bespaart tegelijkertijd een flink
aantal uren aan benodigde support.
Overzicht van alle actiepunten:
- oprichten van de hergebruikstuurgroep,
- vastleggen van de rechten en plichten van de hergebruikstuurgroep en
beheerders,
- inventariseren van de huidige verzameling herbruikbare artefacten,
- opname van de herbruikbare artefacten in SourceForge,
- toewijzen beheerders aan de herbruikbare artefacten,
- klaarmaken van de huidige verzameling,
- intranetsite met informatie over de verzameling herbruikbare artefacten,
- informatievoorziening binnen M&S over hergebruik en de komende
veranderingen,
- informeren offertemanagers over pilots en bedoeling/impact van
hergebruik,
- starten van pilotprojecten waarbij de hergebruikstuurgroep meeloopt in het
offertetraject t.b.v. de advisering,
- vaststellen benodigde budget voor hergebruikstuurgroep,
- definiëren van concrete eisen waaraan de herbruikbare software artefacten
moeten voldoen,
- inventariseren van de mogelijkheid tot urenregistratie van
hergebruikspecifieke activiteiten,
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
139
-
inventariseren van de wensen voor SourceForge 4.3 indien de reuse portal
wordt gerealiseerd.
Extra aandachtspunt:
Tijdens deze scriptie is gebruik gemaakt van diverse wetenschappelijke bronnen
om de literatuurstudie uit te voeren. Voor zover mogelijk is hier ook gebruik
gemaakt van best practices en standaarden. Binnenkort komt de IEEE 1517
standaard beschikbaar binnen TNO-D&V. De huidige Codes of Practice van het
IT/QA zijn gebaseerd op de DoD-STD-2167a / MIL-STD-498. Deze standaarden
liggen ten grondslag aan de IEEE/EIA 12207 standaard. Deze IEEE/EIA 12207
standaard beschrijft de ‘software life cycle processes’. De IEEE 1517 standaard
breidt deze IEEE/EIA 12207 standaard uit met hergebruik processen.
-
onderzoek de IEEE 1517 standaard op de toepasbaarheid binnen TNOD&V.
5.5.2
Middellange termijn – Systematische toepassen
Nadat de voorbereidingen en pilotprojecten uit de opstartfase succesvol zijn
afgerond kan M&S beginnen met de systematische toepassing van hergebruik van
software artefacten. De software architecten en engineers uit de
hergebruikstuurgroep gaan deelnemen aan de offertetrajecten van de
softwareprojecten om te sturen op de ontwikkeling van en met herbruikbare
artefacten.
Overzicht van alle actiepunten:
- inventariseren van mogelijke gebreken in huidige verzameling
herbruikbare artefacten,
- sturen van de productie van herbruikbare artefacten,
- sturen van de consumptie van herbruikbare artefacten,
- registreren hergebruikspecifieke aspecten.
5.5.3
Lange termijn – Uitbreiding scope & professionalisering
Indien hergebruik binnen de afdeling M&S een succes blijkt te zijn kan TNO-D&V
gaan nadenken over het verder standaardiseren van de software ontwikkelingen
binnen de verschillende domeinen. Tevens kan TNO-D&V de
hergebruikactiviteiten uitbreiden naar andere vestigingen zoals TNO Soesterberg of
TNO Rijswijk of zelfs andere business units. Hierbij zal de opzet van de
hergebruikorganisatie wel moeten veranderen. Momenteel is SourceForge, daar
waar de herbruikbare software artefacten worden opgeslagen en beheerd, al binnen
deze vestigingen toegankelijk. Een aandachtspunt kan het verrekenen van de
hergebruikspecifieke kosten over vestigingen heen zijn.
Overzicht van de mogelijke ontwikkelingen en keuzes:
- verkoop van generieke (niet domeinspecifieke) componenten buiten TNO,
- uitbreiden van het hergebruik naar andere afdelingen, vestigingen of
business units,
- verdere standaardisatie binnen domeinen via domeinspecifieke
architecturen & frameworks.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
140
5.6
Hergebruik als business case
Deze paragraaf schetst een beeld van wat hergebruik binnen de afdeling M&S op
financieel gebied kan betekenen, een soort business case voor hergebruik van
software artefacten. De uitkomsten vormen een schatting op basis van enkele harde
cijfers, kengetallen uit de theorie en een aantal schattingen.
5.6.1
Scenario’s
In deze business case wordt er vanuit gegaan dat de aanbevelingen uit dit
hoofdstuk worden opgevolgd. Nu kunnen er diverse scenario’s behandeld worden
waarin verscheidene factoren kunnen variëren: van de mate van hergebruik, de
verhouding tussen black box en white box hergebruik tot de levensduur van de
herbruikbare software artefacten aan toe. Dit zou echter een zeer groot aantal
scenario’s opleveren die verder weinig toegevoegde waarde hebben. Daarom
worden de meeste aspecten als vast verondersteld en worden slechts enkele
factoren als variabel beschouwd. De variabele factoren zijn:
-
hergebruikpercentage,
verhouding tussen black box en white box hergebruik,
mate van productie van herbruikbare software artefacten,
5.6.2
Opbrengsten van hergebruik voor M&S
Hergebruik kan verschillende effecten hebben, denk bijvoorbeeld aan een
kostenverlaging, verlaging in de doorlooptijd of kwalitatief betere software en
betere documentatie. A priori is het heel lastig om hier een nauwkeurige
kwantitatieve schatting voor te geven. Dit is immers ook afhankelijk van het feit of
er meer projecten door worden aangetrokken. Door hergebruik kunnen immers
projecten uitgevoerd worden die eerst niet haalbaar waren bij een gegeven budget
of doorlooptijd.
Er wordt verondersteld dat de (aantoonbare) opbrengsten van hergebruik bestaan
uit de vermeden ontwikkelkosten en de vermeden kosten voor het onderhoud
ervan. Het is zeer moeilijk om een accurate schatting te geven van de besparing die
M&S kan realiseren door hergebruik aangezien er op softwareontwikkelgebied
heel weinig gegevens worden geregistreerd. Er zijn geen cijfers voorhanden over
de mate waarin er gebruik wordt gemaakt van de herbruikbare artefacten, hoeveel
besparing dit per project oplevert, hoeveel fouten er normaliter in de herbruikbare
artefacten worden ontdekt, hoeveel tijd dit gemiddeld kost om ze te verhelpen etc.
Het is aan te raden deze gegevens binnen het softwareontwikkelproces te
registreren ten einde een goed inzicht te verkrijgen in het softwareontwikkelproces,
hergebruik en de resultaten ervan. Hier worden deze factoren geschat om toch een
indicatie te kunnen geven van het mogelijke resultaat door hergebruik.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
141
Gehanteerde definities en formules
In Bijlage J zijn de formules, uitleg bij de gehanteerde schattingen en berekeningen
van de verschillende scenario’s te vinden.
DCA, development cost avoidance, bestaat uit de bespaarde ontwikkeluren door
hergebruik van bestaande software artefacten. Dit is afhankelijk van het totale
aantal ontwikkeluren binnen een organisatie, het percentage hergebruik dat wordt
gerealiseerd en de verhouding tussen black box en white box hergebruik.
SCA, service cost avoidance, is opgebouwd uit de bespaarde uren voor onderhoud
doordat het onderhoud van de herbruikbare software artefacten centraal plaats
vindt. Hierdoor hoeft een fout maar één keer gevonden en opgelost te worden.
Binnen de projecten die de software artefacten hergebruiken hoeft dit onderhoud
niet meer gedaan te worden, enkel de oplossing moet geïmplementeerd worden. De
besparing is afhankelijk van het percentage hergebruik en de verhouding tussen
black box en white box hergebruik.
In Tabel 27 worden de waarden van DCA en SCA geschat bij verschillende
hergebruikpercentages. Het hergebruikpercentage is hier gemeten in tijd, dus
manuren. Indien het hergebruikpercentage bijvoorbeeld 20% is, dan is dit 20% van
het totaal aantal manuren binnen Modelling & Simulation. Binnen Modelling &
Simulation zijn er 25 software engineers, samen vertegenwoordigen die 40.000
manuren op jaarbasis. Bij een hergebruikpercentage van 20% betekent dit dat er op
jaarbasis voor 8.000 manuren aan herbruikbare software wordt hergebruikt. Zie
Bijlage J voor een nadere toelichting.
Aspect
DCA
SCA
20% hergebruik
602.400
-28.000
30% hergebruik
903.600
8.000
40% hergebruik
1.204.800
44.000
Tabel 27 - DCA en SCA bij stijging hergebruikpercentage.
In Tabel 27 is er vanuit gegaan dat er 90% black box wordt hergebruikt en 10%
white box. Zoals is te verwachten nemen de opbrengsten toe bij een stijgend
hergebruikpercentage. Tevens is te zien dat het SCA stijgt en positief wordt. Dit is
te verklaren doordat er vanuit is gegaan dat onderhoud op jaarbasis 10% kost van
de origineel geïnvesteerde ontwikkeluren in de herbruikbare artefacten. Ongeacht
of ze hergebruikt worden of niet. Bij weinig hergebruik heeft dit dus een nadelig
effect op het resultaat.
Aspect
DCA
SCA
BB:WB 90 - 10
903.600
8.000
BB:WB 60 - 40
734.400
-16.000
BB:WB 30 - 70
565.200
-40.000
Tabel 28 - DCA en SCA bij variatie ratios blackbox & whitebox hergebruik.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
142
In Tabel 28 is het effect van de verhouding tussen black box en white box
hergebruik te zien bij een gelijkblijvend hergebruikpercentage van 30%. Er is te
zien dat de opbrengsten flink afnemen naarmate er minder black box en meer white
box wordt hergebruikt. Het SCA daalt ook sterk doordat de besparing op het
centrale onderhoud afneemt naarmate white box hergebruik toeneemt.
De totale opbrengst door hergebruik, RCA (reuse cost avoidance), is dus
afhankelijk van het hergebruikpercentage en van de verhouding tussen het black
box en white box hergebruik.
Voor M&S wordt er vanuit gegaan dat de verhouding tussen black box en white
box hergebruik circa 90 tegenover 10 procent is. Dit levert dan de volgende totale
opbrengsten op bij een variërend hergebruikpercentage, zie Tabel 29.
Aspect
DCA
SCA
RCA
20% hergebruik
602.400
-28.000
€ 574.440
30% hergebruik
903.600
8.000
€ 911.600
40% hergebruik
1.204.800
44.000
€ 1.248.800
Tabel 29 - RCA bij verschillende hergebruikpercentages.
5.6.3
Kosten van hergebruik voor M&S
§ 5.4.2 somt de verschillende kostenposten door hergebruik van software op:
-
ontwikkelingskosten van de herbruikbare artefacten,
sturing op de productie van herbruikbare artefacten,
sturing op de consumptie van herbruikbare artefacten,
certificering van ontwikkelde herbruikbare artefacten,
beheer en onderhoud van de herbruikbare artefacten in SourceForge,
advisering en ondersteuning aan de projectteams.
De kosten zijn hier afhankelijk van het aantal projecten dat software artefacten
hergebruikt en van het deel van het totale aantal manuren dat wordt besteed aan de
ontwikkeling van nieuwe herbruikbare software artefacten. Voor de schatting van
de ontwikkelingskosten wordt er een percentage van het totaal aantal manuren van
de software engineers gehanteerd. Bij bijvoorbeeld 2,5% zou dit met 25 software
engineers die 1600 uur per jaar werken, 2,5% van 40.000 uur, 1000 uur zijn. Ter
vergelijking: het EBF is jaarlijks aan ontwikkeling van nieuwe functionaliteit circa
150 uur kwijt. Het EBF management kost circa 80 uur.
De overige activiteiten worden afhankelijk van het aantal projecten gesteld en op
die manier berekent. Anders worden de berekeningen te complex en nog meer op
grove schattingen gebaseerd. De cijfers in Tabel 30 laten zien dat de kosten voor
hergebruik sterk afhankelijk zijn van de investeringen in de ontwikkeling van
nieuwe herbruikbare software artefacten.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
143
Investering
Aspect
Totale Kosten
0%
2,5%
5%
7,5%
10%
€ 96.000
€ 196.000
€ 296.000
€ 396.000
€ 496.000
Tabel 30 - Totale kosten hergebruik bij variërende investeringen.
De percentages in Tabel 30 geven weer hoeveel procent van het totale aantal
ontwikkeluren van de software engineers binnen M&S wordt besteed aan het
ontwikkelen van nieuwe herbruikbare artefacten. De kosten voor sturing van de
productie en consumptie en ondersteuning zijn afhankelijk van het aantal projecten.
Ter illustratie; stel dat de levensduur van een herbruikbaar artefact 5 jaar is en dat
de huidige verzameling circa 10.000 ontwikkeluren vertegenwoordigd. Bekend is
dat het ontwikkelen van een herbruikbaar artefact 150% van de normale
inspanning, gemeten in uren, kost. Aangezien de projecten zelf de ontwikkeling
van de software artefacten voor hun rekening nemen en de hergebruikstuurgroep de
overhead, dus de extra 50%, betaalt is de investering enkel deze 50% overhead. Op
een verzameling herbruikbare artefacten van 10.000 ontwikkeluren betekent dit dus
dat er per 5 jaar, gezien de levensduur van de herbruikbare artefacten, een derde
(50/150) geïnvesteerd moet worden om de verzameling in stand te houden. Dit is
dus circa 3300 ontwikkeluren. Per jaar is dit dus circa 700 uur. Met 25 software
engineers die elk 1.600 uur per jaar werken is dit een kleine 2% van het totaal
aantal ontwikkeluren. Ter vergelijking; indien er structureel 10% zou worden
geïnvesteerd zou men uitkomen op een verzameling ter grootte van zo’n 50.000 á
60.000 ontwikkeluren.
5.6.4
Eindbalans van hergebruik voor M&S
Tabel 31 geeft de verschillende mogelijkheden voor het nettoresultaat van
hergebruik weer indien de hergebruikpercentages en de investeringen in de
ontwikkeling van nieuwe herbruikbare software artefacten tegenover elkaar gezet
worden. Hierbij is 90% black box en 10% white box hergebruik aangenomen.
Aspect
2,5 %
5
7,5 %
10 %
20% hergebruik
€ 378.440
€ 278.440
€ 178.440
€ 78.440
30% hergebruik
€ 715.600
€ 615.600
€ 515.600
€ 415.600
40% hergebruik
€ 1.052.800
€ 952.800
€ 852.800
€ 752.800
Tabel 31 - Nettoresultaat van hergebruik.
Op basis van deze schattingen levert hergebruik de afdeling M&S een positief
resultaat op. De schattingen van het resultaat variëren van circa € 100.000,- tot
€ 1.000.000,- op jaarbasis onder de gemaakte aannames, afhankelijk van de
hoeveelheid hergebruik en de investeringen in nieuwe software artefacten. Indien
men uitgaat van een hergebruikpercentage van circa twintig á dertig procent met
een investering in de ontwikkeling van herbruikbare artefacten van circa twee á vijf
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
144
procent dat ligt het resultaat in de orde van grootte van circa driehonderdduizend
tot zevenhonderdduizend euro. Dit zijn ongeveer twee á vijf complete mensjaren.
Concreet zal hergebruik voor TNO-D&V een verbetering in de concurrentiepositie
betekenen door enerzijds een productiviteitsstijging en anderzijds een
kostenbesparing, zoals dit reeds in § 5.3.2, Figuur 33 is toegelicht. In deze business
case is geen rekening gehouden met extra opbrengsten door projecten die extra
uitgevoerd kunnen worden waar dit zonder hergebruik niet mogelijk zou zijn
geweest en de verbeterde kwaliteit van de software en documentatie. Tevens is er
geen rekening gehouden met de invloed van de investeringen, en dus de grootte
van de verzameling herbruikbare software artefacten, op de mate van hergebruik.
M&S heeft op hergebruikgebied wel een vliegende start doordat er al een flinke
verzameling aan herbruikbare software artefacten beschikbaar is.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
145
6.
Advies aan TNO-D&V
Deze scriptie bespreekt de toepassing van hergebruik van software artefacten
binnen de afdeling Modelling & Simulation. Hierbij ligt de nadruk op hoe
hergebruik van software procesmatig en organisatorisch is ingericht en welke
software artefacten er worden hergebruikt. De doelstelling voor deze scriptie is als
volgt geformuleerd:
Het doen van aanbevelingen op het gebied van het softwareontwikkelproces en de
inrichting van de organisatie daar omheen, met betrekking tot de invoering en
bevordering van hergebruik van software artefacten.
Dit hoofdstuk beantwoordt de onderzoeksvragen en formuleert de aanbeveling
voor Modelling & Simulation.
6.1
Conclusie
De conclusie van deze scriptie is dat hergebruik van software binnen de afdeling
Modelling & Simulation hoofdzakelijk op adhoc niveau plaatsvindt. Hierdoor
bestaan er diverse knelpunten in de toepassing van hergebruik die ertoe leiden dat
zowel software engineers als projectleiders, onbewust en bewust, niet
hergebruiken.
De software artefacten die hergebruikt worden zijn hoofdzakelijk applicatiedomein
onafhankelijk. Hierbij is hergebruik vooral gebaseerd op white box code
hergebruik. De software artefacten die hergebruikt worden omvatten zowel tools
als componenten en frameworks. De software artefacten zijn vaak niet specifiek
ontworpen om hergebruikt te worden en de documentatie is veelal beperkt.
Het eerste belangrijke aandachtspunt is dat er niets is geregeld voor de ontwikkelde
herbruikbare software artefacten. Er is geen opvang en beheer van de herbruikbare
artefacten nadat het project, waarin het is ontwikkeld, afloopt. Hierdoor is het
bestaan van het herbruikbare artefact vaak ook onduidelijk voor andere software
engineers. Dit vormt een belangrijk knelpunt. De huidige organisatie is gespitst op
de aparte projecten en heeft geen oog voor projectoverschrijdende processen die
voor hergebruik van software nodig zijn. Processen voor de herbruikbare software
artefacten zoals configuratiemanagement en versiebeheer of problem and change
management of ondersteuning zijn nu, buiten de projecten, niet formeel geregeld.
Tevens worden de herbruikbare artefacten niet getoetst aan kwaliteitseisen. Het
gebrek aan ondersteuning bij een herbruikbaar artefact en het gebrek aan
vertrouwen in de kwaliteit en herbruikbaarheid vormen voor de software engineers
belangrijke knelpunten. Soms worden deze processen op informele basis
uitgevoerd door toegewijde software engineers maar vaak is er geen aanspreekpunt
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
146
of beheerder bekend. Het EBF vormt hier een uitzondering op en is dan ook de best
practice binnen TNO-D&V. Hier zijn deze processen namelijk wel ingericht.
Een ander belangrijk aandachtspunt is de sturing op hergebruik. Dit omvat zowel
de sturing op de ontwikkeling van nieuwe herbruikbare software artefacten als de
sturing op de ontwikkeling van software met deze herbruikbare artefacten. Aan
beide processen is nog geen invulling gegeven.
Hierdoor vindt de ontwikkeling van herbruikbare software artefacten beperkt plaats
en ontbreekt veelal de visie of strategische keuze om bepaalde software artefacten
herbruikbaar te maken. Vanuit de projectleiders bestaat er ook weerstand tegen het
ontwikkelen van herbruikbare artefacten in zijn of haar project aangezien dit extra
kosten met zich meebrengt. Als gevolg hiervan wordt de ontwikkeling van
herbruikbare artefacten vaak geremd en is de ontwikkeling gebaseerd op reengineering. Het software artefact wordt hierbij over verschillende projecten steeds
verder ontwikkeld. Dit proces is zowel afhankelijk van toeval en toewijding van
software engineers als van het inzicht van de resourcemanager. De
resourcemanager heeft immers invloed op hergebruik omdat hij de verdeling van
software engineers over de projecten regelt. Op deze manier wordt hergebruik van
kennis uit voorgaande projecten geborgd in de nieuwe projecten.
Het gebrek aan sturing op het gebruik van de herbruikbare software artefacten leidt
er mede toe, dat software engineers en projectleiders om diverse redenen ervoor
kiezen om een software artefact zelf opnieuw te ontwikkelen. De redenen variëren
van het gebrekkige inzicht in het bestaan van de herbruikbare artefacten, de mening
dat het niet 100% aan de wensen voldoet tot aan het verkeerd beoordelen van de
moeite die het kost om een dergelijk software artefact zelf te ontwikkelen.
Ondanks de weerstand die er tegen hergebruik bestaat, zijn er binnen Modelling &
Simulation ook concrete succesgevallen te zien. De baten van hergebruik zijn
echter niet inzichtelijk en het effect van hergebruik is daarom moeilijk te
kwantificeren. Voorbeelden van projecten die aanzienlijk baat hebben gehad zijn
onder andere het SCOPE project en projecten die gebruik hebben gemaakt van het
EBF.
Om de kansen voor hergebruik binnen Modelling & Simulation beter te benutten
moeten er een aantal aspecten geregeld worden die de knelpunten verhelpen. Dit
moet ervoor zorgen dat hergebruik ook daadwerkelijk gebeurt indien dit mogelijk
is. Hiervoor is het belangrijk dat er een projectoverschrijdende groep wordt
ingericht om de kennis van de herbruikbare software artefacten te concentreren.
Deze groep kan de projecten sturen op de ontwikkeling van herbruikbare software
artefacten en de ontwikkeling van software met deze herbruikbare software
artefacten. Tevens moet het onderhoud en beheer van de herbruikbare artefacten
worden geregeld. Deze aspecten zijn ook te zien bij de best practices uit de
literatuur en gedeeltelijk bij de best practice binnen TNO-D&V zelf. De best
practices uit de literatuur hanteren ook een aparte organisatie voor de concentratie
van kennis over de herbruikbare artefacten. Op deze manier kunnen ze de
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
147
ontwikkeling van herbruikbare software artefacten sturen en ook het gebruik ervan
stimuleren en afdwingen. Binnen het EBF is de kennis over de herbruikbare
artefacten ook geconcentreerd en zijn het beheers- en onderhoudsprocessen
geregeld. Om deze veranderingen te realiseren is overtuiging en betrokkenheid van
het management essentieel.
Het kwantificeren van de mogelijke opbrengsten en kosten door hergebruik is geen
doel binnen deze scriptie. Er is echter wel een schatting gemaakt van de mogelijke
resultaten door hergebruik indien de aanbevelingen, die in deze scriptie worden
gedaan, worden opgevolgd. Uit deze schattingen blijkt dat hergebruik van software
artefacten de afdeling Modelling & Simulation een substantieel resultaat kan
opleveren in de vorm van productiviteitsverbeteringen en kostenbesparingen. Het
resultaat ligt in de orde van grote van enkele mensjaren. In deze schattingen
bestaan de opbrengsten uit de bespaarde ontwikkel- en onderhoudsuren. De kosten
worden gevormd door de investeringen in de (nieuwe) herbruikbare artefacten en
projectoverschrijdende kosten. Deze projectoverschrijdende kosten bestaan uit de
kosten voor sturing, onderhoud en beheer, certificatie en ondersteuning aan de
projectteams.
6.2
Aanbevelingen
Om de toepassing van en resultaten door hergebruik te verbeteren, worden hier
voor Modelling & Simulation een aantal aanbevelingen geformuleerd die zijn
gebaseerd op de voorgaande conclusies.
Organiseren en concentreren
Richt een groep op die verantwoordelijk is voor de projectoverschrijdende
hergebruikprocessen. In deze groep zou het inzicht in, en de kennis van, de
verzameling herbruikbare artefacten moeten hebben om de softwareprojecten
hierop te kunnen sturen.
Sturen
De nieuwe groep zou de bevoegdheid moeten hebben om tijdens het offertetraject
de projecten te adviseren en elke offerte te beoordelen op de mogelijkheid om
bestaande software artefacten te hergebruiken. Hierdoor kan de groep een schatting
gegeven van de besparing door hergebruik. Tevens kan de groep aangeven welke
software artefacten zodanig ontwikkeld moeten worden dat deze hergebruikt
kunnen worden.
Herbruikbare artefacten
Om optimaal gebruik te maken van de aanwezige software zou de huidige
verzameling van herbruikbare artefacten geïnventariseerd moeten worden.
Hier heeft de afdeling Modelling & Simulation een vliegende start aangezien er al
een flinke verzameling aan herbruikbare software artefacten beschikbaar is. Zorg er
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
148
wel voor dat deze herbruikbare artefacten zijn getest en voorzien van documentatie
om ervoor te zorgen dat hergebruik positief wordt ervaren. Modelling &
Simulation zou zich bij de ontwikkeling van nieuwe herbruikbare software
artefacten moeten richten op hoogwaardige herbruikbare artefacten. Dit kan zowel
losse componenten als frameworks omvatten.
Beheren
Om ervoor te zorgen dat de herbruikbare software artefacten buiten de projecten
om worden beheerd en onderhouden, zou de nieuwe groep de bevoegdheid moeten
hebben om software engineers hiervoor verantwoordelijk te maken. Dit kunnen
zowel individuele software engineers zijn als groepjes van software engineers,
afhankelijk van de grote en complexiteit van het herbruikbare software artefact. Op
deze manier wordt ook de kennis van de herbruikbare artefacten verspreid onder de
software engineers die ook aan de projecten deelnemen.
Financieren
De nieuwe groep zou een budget moeten hebben waarmee het de
projectoverschrijdende kosten en de kosten voor de ontwikkeling van (nieuwe)
herbruikbare artefacten kan financieren. Dit kan worden gedaan door alle
softwareprojecten een bepaald percentage van hun budget af te laten staan aan de
nieuwe groep. Op deze manier worden de projecten ook gedreven om hun voordeel
te doen met de beschikbare herbruikbare software artefacten.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
149
7.
Reflectie
In dit hoofdstuk geef ik een beschouwing over mijn afstudeerperiode bij TNOD&V. Hierbij ga ik in op de gehanteerde aanpak, het leerproces en de aspecten die
ik achteraf anders zou hebben aangepakt.
De aanpak
De gehanteerde aanpak van theorieonderzoek, empirisch onderzoek en gewenste
situatie voor TNO-D&V is voor mij een duidelijke en logisch opzet. Voor het
empirische onderzoek bleken de interviews en gesprekken een zeer goede bron van
informatie te zijn. Verder is de terugkoppeling van de theorie en bevindingen uit
het empirische onderzoek richting de software engineers en het management van
TNO volgens mij een goede manier om de mensen betrokken te houden bij het
onderwerp. Voor de aanbevelingen heb ik een GFR-sessie gehouden waarin ik mijn
belangrijkste aanbevelingen heb getoetst aan de visie van enkele software
engineers, projectleiders en het afdelingshoofd. Dit is mij zeer goed bevallen omdat
ik op deze manier terugkoppeling krijg op mijn visie en de deelnemers op deze
manier toch weer meedenken over het onderwerp. Voor de lezer oogt de opbouw
van de scriptie sequentieel. Het schrijven van deze scriptie is echter een
stapsgewijs leerproces geweest met een sterk incrementeel karakter.
Incrementeel scriptie schrijven
Mijn inzicht in de materie is stapsgewijs tot stand gekomen en periodiek
bijgestuurd door de input van de begeleiders van de UT en TNO. Hierdoor ben ik
veel tijd kwijt geweest aan het continue updaten en verbeteren van stukken in mijn
verslag. Tevens merk ik dat ik moeite heb met het compact formuleren van datgene
wat ik wil schrijven. Indien ik, op basis van de kennis die ik nu heb, opnieuw mijn
scriptie zou schrijven zou deze compacter en meer to the point zijn.
Omgevallen boekenkast
Ik heb voor mezelf geen goede afbakening gemaakt voor de tijd en inhoud van het
literatuuronderzoek. Dit kwam omdat het onderwerp mij inhoudelijk niet helemaal
duidelijk was. Hierdoor ben ik tot ver in mijn afstuderen bezig geweest met de
theorie. Terugkijkend had ik in een vroeg stadium meer met de software engineers
en begeleiders moeten spreken om hier een beter inzicht van te krijgen. Tevens had
ik in het begin meer boeken moeten lezen in plaats van artikelen. De boeken over
hergebruik geven een duidelijker inzicht in het totaalplaatje terwijl de artikelen
vaak zijn gericht op zeer specifieke onderwerpen. Naar mijn mening is dit verslag
op literatuurgebied een omgevallen boekenkast geworden.
Interviews
Qua interviews geldt hetzelfde als voor de theorie, ik had in een vroeg stadium
meer met de mensen binnen TNO moeten spreken om een duidelijker beeld te
krijgen van datgene wat ik tijdens de interviews zou willen achterhalen. Ik heb ook
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
150
gemerkt dat de interviews betere informatie opleverde naarmate ik meer interviews
had gehouden. Na de formele interviews heb ik ook nog met veel personen binnen
M&S gesproken indien ik vastliep of bepaalde punten of vragen onbeantwoord
bleven. Op deze manier heb ik nog veel informatie boven water gehaald.
Totaalbeeld
Zelf ben ik tevreden over mijn functioneren tijdens deze afstudeerperiode. De
gemaakte afspraken zijn mijns inziens goed nagekomen en de gemaakte planning is
redelijk goed aangehouden. Ik denk dat ik, gezien de uiteenlopende wensen en
opvattingen van de vier begeleiders, een product heb afgeleverd waar alle
begeleiders tevreden over zijn.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
151
8.
[BAR91]
[BAS88]
[BAS97]
[BRA98]
[BRI97]
[DAV94]
[DOB96]
[DOD98]
[DON05]
[DOU97]
[DUS95]
[EZR02]
[FAF94]
[FEN97]
[FIC01]
[FRA95]
Referenties
Barnes, B.H., Bollinger, T.B., (1991), Making Reuse CostEffective, IEEE Software, Vol. 8 No. 1, pp. 13-24.
Basili, V.R., Caldiera, G., Rombach, H.D., (1994), The Goal
Question Metric Approach, http://www.cs.umd.edu/users/
mvz/handouts/gqm.pdf, (Januari 2005)
Bassett, P.G., (1997), Framing Software Reuse – Lessons from the
Real World, Eerste druk, New York: Prentice Hall.
Brassé, M., (1998), Code of Practice - Verificatie, Validatie &
Accreditatie in het kader van EBF Ontwikkeling, TNO Fysisch en
Elektronisch Laboratorium, Den Haag.
Briand L.C., Differding, C.M, Rombach, H.D., (1997), Practical
Guidelines for Measurement-Based Process Improvement in M.
Ezran, M. Morisio, C. Tully, Practical Software Reuse, Eerste
druk, Londen: Springer-Verlag, pp. 112-116
Davis, T., (1994), The Reuse Capability Model, Software
Productivity Consortium, http://www.stsc.hill.af.mil/
crosstalk/1994/03/xt94d03d.asp (December 2004)
Dobler, H., Mittelmann, A., (1996), Development of an OO Energy
Management System using the ami Approach, http://www.artmfriends.at/am/publications/Eaug96_Paper.pdf, (Februari 2005)
U.S. Department of Defense, (1998), High-Level Architecture
Rules Version 1.3, www.openskies.net/files/HLA-rules1-3.pdf
(mei 2005).
Dondertman, B., Kamstra, M., (2005), Programmeurshandleiding
ORB-simulatiekernel, TNO Fysisch en Elektronisch Laboratorium,
Den Haag.
Doublait, S., (1997), Standard Reuse Practices: Many Myths vs. a
Reality, StandardView June 1997, Vol.5 No. 2, pp. 84-91.
Dusink, L., Katwijk, J. van, (1995), Reuse Dimensions, ACM
1995, pp. 137-149.
Ezran, M., Morisio, M., Tully, C., (2002), Practical Software
Reuse, Londen: Springer-Verlag.
Fafchamps, D., (1994), Organizational factors and reuse, IEEE
Software, Vol. 11 No. 5, pp. 31-41.
Fenton, N.E., Pfleeger, S.L., (1997), Software Metrics - a rigorous
& practical approach, Tweede druk, Boston: PWS Publishing
Company.
Fichman, R.G., Kemerer, C.F., (2001), Incentive Compatibility and
Systematic Software Reuse, Journal of Systems and Software 2001,
Vol. 57 No. 1, pp. 45-94.
Frakes, W.B., Fox, C.J., (1995), Sixteen questions about software
reuse, Communications of the ACM June 1995, Vol. 38 No. 6, pp.
75-87
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
152
[FRA96]
[HAL97]
[HAR98]
[HUL92]
[JAC97]
[JEN97]
[KAL01]
[KOL91]
[KON96]
[KRU92]
[LAN02]
[LYN98]
[MIL02]
[MCC95]
Frakes, W.B., Terry, C., (1996), Software Reuse: Metrics and
Models, ACM 1996, Vol. 28 No. 2, pp. 415-435.
Hallsteinsen, S., Paci, M., (1997), Experiences in Software
Evolution and Reuse – Twelve Real World Projects, Research
Reports Esprit - Project 9809 Volume 1, Berlijn: Springer.
Hars, A., Im, I., (1998), Knowledge Reuse – Insights from software
reuse, Americas Conference on Information Systems (AMCIS),
August 1998, Baltimore, Maryland
Hulshof, M., (1992), Leren Interviewen – het mondeling
verzamelen van informatie, Eerste druk, Groningen: WoltersNoordhoff.
Jacobson, I., Griss, M., Jonsson, P., (1997), Software Reuse Architecture, Process and Organization for Business Success,
Eerste druk, New York: ACM Press.
Jense, H., Kuijpers, N., Elias, R.J., (1997), Electronic Battlespace
Facility for Research, Development and Engineering,
http://citeseer.ist.psu.edu/cache/papers/cs/16366/http:zSzzSzwww
pa.win.tue.nlzSzkuijperszSzpublicationszSzsiwsep97.pdf/jense97e
lectronic.pdf (April 2005).
Kallio, P., Niemelä, E., (2001), Documented Quality of COTS and
OCM Components, 4th ICSE Workshop on Component-Based
Software Engineering 2001, www.sei.cmu.edu/pacc/
CBSE4_papers/Kallio-CBSE4-2.pdf (April 2005).
Koltun, O., Hudson, A., (1991), A Reuse Maturity Model, in H.
Mili, et al., Reuse-Based Software Engineering – Techniques,
organization and measurement, first edition, New York: John
Wiley & Sons INC., pp. 81-82.
Kontio, J., Caldiera, G., Basili, V.R., (1996), Defining Factors,
Goals and Criteria for Reusable Component Evaluation, Presented
at the CASCON '96 Conference, Toronto Canada.
Krueger, C.W., (1992), Software Reuse, ACM Computing
Surveys, Vol. 24 No. 2, pp. 131-183.
Langeslag, P.J.H., Gouweleeuw, R.G.W., Fiebelkorn, S., (2002),
Familievorming simulators KL deelrapport ontwikkelingen in
binnen- en buitenland, TNO Fysisch en Elektronisch
Laboratorium.
Lynex, A., Layzell, P.J., (1998), Organizational considerations for
software reuse, Annals of Software Engineering 1998, Vol. 5, pp.
105-124.
Mili, H., et al. (2002), Reuse-Based Software Engineering –
Techniques, organization and measurement, Eerste druk, New
York: John Wiley & Sons INC.
McClure, C., (1995), Experiences in organizing for software reuse,
Extented Intelligence Inc. Chicago.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
153
[MOR00]
[MOR02]
[NOL00]
[PAN98]
[PAU93]
[POU97]
[POU98]
[PRE00]
[PRI93]
[PUL96]
[RAV03]
[ROT99]
[SLU04]
[SMI94]
[SOM04]
Morisio, M., Tully, C., Ezran, M., (2000), Diversity in Reuse
Processes, IEEE Software July, August 2000, pp. 56-63.
Morisio, M., Ezran, M., Tully, C., (2002), Success and Failure
Factors in Software Reuse, IEEE Transactions on Software
Engineering april 2002, Vol. 28 No. 4, pp. 340-357.
Nolan Norton Institute (2000), Beheersing en besturing van
complexiteit in het netwerktijdperk, architectuur als
managementinstrument, in T. Thiadens, Beheer van ICTVoorzieningen – Infrastructuren, applicaties en organisatie, vierde
herziene druk, Schoonhoven: Academic Service, pp. 52-53.
Pan, D., (1998), Software Reuse, University of Calgary,
Department of Computer Science, sern.ucalgary.ca/courses/
seng/693/W98/pand/reuse_lv.html (December 2004).
Paulk, M.C., et al, (1993), Capability Maturity Model for Software,
Versie 1.1, Software Engineering Institute,
http://www.sei.cmu.edu/cmm/, (December 2004).
Poulin, J.S., (1997), Fueling Software Reuse with Metrics,
http://home.stny.rr.com/jeffreypoulin/Papers/Object_Mag_Metrics
/oometrics.html, (april 2005).
Poulin, J.S., (1998), Selling Software Reuse to Management,
Fourth Joint Conference on Infromation Sciences,
http://home.stny.rr.com/jeffreypoulin/Papers/JCIS98/
sellingreuse.html, (Mei 2005).
Pressman, R.S., Ince, D., (2000), Software Engineering – A
Practitioner’s Approach, Vijfde editie, Maidenhead: McGrawHill.
Prieto-Díaz, R., (1993), Status Report: Software Reusability, IEEE
Software, Vol.10 No. 3, pp. 61-66.
Pulford, K., Kuntzmann-Combelles, A., Shirlaw, S., (1996), A
quantitative approach to Software Management – The Ami
Handbook, Addison-Wesley, Wokingham.
Ravichandran, T., Rothenberger, M.A., (2003), Software Reuse
Strategies and Component Markets, Communications of the ACM
August 2003, Vol. 46 No. 8, pp. 109-114.
Rothenberger, M.A., Kulkarni, U.R., Hershauer, J.C., (1999),
Software Reuse Success Factors: A Qualitative Assessment of
Developers’ perception, American Conference on Information
Systems (AMCIS), Milwaukee
Sluimer, R.R., et al. (2004), Familievorming trainingssimulators
KL: richtlijnen, TNO Technische Menskunde en TNO Fysisch en
Elektronisch Laboratorium, Den Haag.
Smith, L., (1994), Software Reuse – Technologies and
Applications, http://www.stc-online.org/cdrom/cdrom2000/stsc/Reports/Reuse.pdf, (December 2004).
Sommerville, I., (2004), Software Engineering, seventh edition,
Addison-Wesley Publishers & Pearson Education, Harlow.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
154
[THI02]
[TNO03]
[TUR99]
[VER04]
[VAD98]
[VIL95]
[WIT02]
Thiadens, T., (2002), Beheer van ICT-Voorzieningen –
Infrastructuren, applicaties en organisatie, Vierde herziene druk,
Academic Service, Schoonhoven.
TNO-D&V (2003), The Cornerstone of building quality Software,
IT/QA forum, Den Haag.
Turrell, C., (1999), High Level Architecture, Simulation
Technology Vol 1. Issue 4. 1999, http://www.sisostds.org/
webletter/siso/iss_18/art_149.htm (april 2005).
Verschuren, P., Doorewaard, H. (2004), Het ontwerpen van een
onderzoek, Derde druk, Utrecht, Lemma BV.
Vadapalli, A., Nazareth, D.L., (1998), Software Reuse
Management: Development of a Model in the Context of the
Capability Maturity Model, Americas Conference on Information
Systems (AMCIS), Baltimore
Villalba, J.M., (1995), Final Report – Implementation and
Evaluation of a Software Reuse Methodology,
http://www.esi.es/VASIE/Reports/All/10936/Report/index.htm,
(Januari 2005).
Witberg, R.R., (2002), Memorandum ORB Simulatie Kernel, TNO
Fysisch en Elektronisch Laboratorium, Den Haag.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
A.1
Bijlage A
Kosten en opbrengsten van hergebruik
Figuur 35 toont de verschillende mogelijke kosten en opbrengsten van hergebruik
van software artefacten. De kosten kunnen opgesplitst worden naar de ‘design for
reuse’ (Producer Costs) en de ‘design with reuse’ (Consumer Costs) activiteiten.
Figuur 35 - Kosten en Opbrengsten van hergebruik [FIC01].
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
B.1
Bijlage B
Dimension
of Maturity
Motivation/Culture
Initial/Chaos
(1)
Reuse is
Reuse Maturity Framework
Monitored
(2)
Coordinated
(3)
Reuse is encouraged
Reuse is incentivized
discouraged
Planned
(4)
Ingrained
(5)
Reuse is
Reuse is “the way we
indoctrinated
do business”
Planning for reuse
Nonexistent
Grassroots activity
Targets of opportunity
Business Imperative
Part of a strategic plan
Breadth of reuse
Individual worker
Work group
Department
Division
Enterprise
Individual worker
Shared initiative
Dedicated individual
Dedicated Group
Corporate Group
Process by which
Reuse process
Reuse questions
Design emphasis
Focus on
All software products
reuse is leveraged
chaotic; unclear
raised at design
placed on reuse of
developing families
genericized for future
where reuse comes
review (after the
off-the-shelf part
of products
reuse
in
fact)
Reuse Inventory
Salvage yards (no
Catalog Identifies
Catalog organized
Catalog includes
Planned activity to
(assets)
apparent structure
Language-and
along application-
generic data
acquire or develop
to collection)
platform specific
specific lines
processing functions
missing pieces in
Involvement
Responsibility for
making reuse
happened
parts
catalog
Classification
Informal,
Multiple
Single Scheme,
Some domain
Formal, complete,
Activity
individualized
independent
catalog published
analyses performed
consistent, timely
schemes for
periodically
to determine
classification
classifying parts
categories
Technology
Personal Tools, if
Lots of tools, e.g,
Classification aids
Electronic Library
Automated support
Support
any
configuration
and synthesis aids
separate from devel-
integration with
management, but
opment
development system
not specialized to
environment
reuse
Metrics
No Metrics on level
Number of lines of
Manual tracking of
Analyses performed
All system utilities,
of reuse, payoff, or
reused code
reuse occurrences of
to identify expected
software tools, and
cost of reuse
factored into cost
catalog parts
payoffs from
accounting mecha-
developing reusable
nisms instrument to
models
parts
track reuse
Legal, contractual,
Inhibitor to getting
Internal accounting
Data rights and
Royalty scheme for
Software treated as
accounting
started
scheme for sharing
compensation issues
all suppliers and
key capital asset
costs, allocating
resolved with
customers
benefits
customer
consideration
Tabel 32 - Reuse Maturity Framework [KOL91].
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
C.1
Bijlage C
Toelichting op de AMI methode
AMI is een variatie op het GQM. AMI staat voor Application of Metrics in
Industry en voor Assess/Analyse, Metricate and Improve [DOB96]. Deze methode
is gebaseerd op de GQM methode en het CMM. Het biedt een gestructureerde
manier om aspecten binnen het softwareontwikkelproces te kwantificeren. De
methode is opgedeeld in vier aparte fasen, Assess – Analyse – Metricate – Improve.
Naast deze vier activiteiten is AMI opgebouwd uit twaalf stappen. In Tabel 33
worden deze stappen weergegeven.
Fase
Assess
Analyse
Metricate
Improve
Nr.
1
2
3
4
5
6
7
8
9
10
11
12
Stap
Assess your Environment
Define primary management goals
Check the goals against the assessment
Break down management goals into sub-goals
Check consistency of resulting goal tree
Identify metrics from sub-goals
Write and validate measurement plan
Collect primitive data
Verify primary data
Distribute, analyse and review measurement data
Validate the metrics
Relate the data to the goals and implementation actions
Tabel 33 - De 12 stappen van de AMI methode [PUL96][DOB96].
Fase ‘Assess’
Stap 1
De eerste stap in deze fase is het beoordelen van de huidige situatie om op basis
daarvan realistische doelen te kunnen stellen. Het doel van deze stap is om inzicht
te krijgen in probleemgebieden en onderwerpen die aandacht nodig hebben (binnen
het softwareontwikkelproces). Bij het analyseren van deze gebieden kan er door
een aantal gezichtspunten gekeken worden, namelijk vanuit een proces-, productof communicatie gericht gezichtspunt. Het is belangrijk niet direct te hoog
gegrepen doelen te stellen. Start met een simpel programma en probeer het
langzaam uit te bouwen.
Stap 2
Nu er een beginsituatie gedefinieerd is en de aandachtsgebieden bekend zijn,
kunnen de primaire doelen van de metingen vastgesteld worden. Er zijn hierbij
twee soorten doelen te onderscheiden; het kennisdoel en het prestatiedoel. Het
kennisdoel dient ter verbetering van inzicht in dat wat er gemeten wordt. Het
prestatiedoel wordt gebruikt indien men weet waar de gebreken liggen en men deze
wil verhelpen. De keuze voor een aantal doelen is afhankelijk van het budget en de
ervaring met het meten zelf. Het CMM kan hier worden gebruikt om
verbeterdoelen vast te stellen. Een voorbeeld van een doel is ‘To gain better
understanding of the product quality’. Elk doel heeft ook een eigen ‘time-scale’, dit
is de periode waarin het doel bereikt dient te worden. Het is aan te raden geen
lange termijn of te algemene doelen te stellen.
TNO-rapport
ERROR! REFERENCE SOURCE NOT FOUND.
C.2
Error! Reference source not found.
Bijlage C
Stap 3
De laatste stap in deze fase betreft het valideren van de gestelde doelen met de
uitkomsten van de beoordeling van de huidige situatie, de ‘time-scale’ en het
budget voor de metingen.
Fase ´Analyse’
Stap 4
De gestelde doelen kunnen slechts zelden direct beantwoord worden. Om
beantwoording mogelijk te maken is het noodzakelijk de doelen op te delen in
subdoelen waarvoor het wel mogelijk is metingen op te stellen. Door de opsplitsing
van doelen naar subdoelen ontstaat er een ‘goal-tree’. Het is belangrijk de
verschillende betrokken participanten te betrekken aangezien zij allen een ander
beeld hebben van de belangrijke aspecten in een dergelijk doel.
Stap 5
In de vorige stap is het eerste deel van de zogenaamde ‘goal-tree’ gemaakt. De
primaire doelen zijn met behulp van de verschillende stakeholders uitgesplitst naar
subdoelen. In deze stap wordt gekeken of deze ‘goal-tree’, met andere woorden de
combinatie primaire doelen en subdoelen, in balans en consistent is. Qua
consistentie is het belangrijk om te kijken of de subdoelen daadwerkelijk de
primaire doelen beantwoorden en of er geen contradicties bestaan tussen
verschillende subdoelen. Het is verstandig om hierbij wederom de verschillende
stakeholders te betrekken aangezien zij ook kunnen helpen de subdoelen te
verbeteren.
Stap 6
De ‘goal-tree’ is in de vorige twee stappen opgesteld en geverifieerd. In deze stap
worden de subdoelen vertaald naar concrete metingen. De subdoelen dienen op een
dusdanig laag niveau te zitten dat de entiteiten waar het om gaat tastbaar en de
attributen meetbaar zijn. In deze stap is het de taak de juiste attributen te
identificeren die gemeten dienen te worden. De metingen kunnen zowel objectief
als subjectief van aard zijn. Objectieve metingen zijn gemakkelijk kwantificeerbaar
en corresponderen over het algemeen met de attributen van een entiteit. Subjectieve
metingen zijn kwalitatief en hebben geen absolute waarde, ze worden dan ook
uitgedrukt in zelfgedefinieerde schalen. Het is goed om beide soorten metingen te
gebruiken, houd de metingen echter wel simpel en vermijd ingewikkelde
subjectieve metingen.
Fase ‘Metricate’
Stap 7
In deze fase wordt op basis van de opgestelde metingen een meetplan gemaakt. Dit
plan omvat de volgende onderdelen (volgens de AMI template). In Tabel 34 is de
AMI template voor metrics opgenomen.
- Doel van het meetplan
ERROR! REFERENCE SOURCE NOT FOUND.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
C.3
-
-
Gedetailleerde samenvatting van stap 1 tot nu. De context, assessment en
doelen zijn essentieel voor correcte definities van de metingen en
exploitatie van de data.
Definities van de meting en analyse procedure
Dit beschrijft positie in de ‘goal-tree’, wie hem analyseert en wie de
resultaten ontvangt. Tevens wordt beschreven hoe de meting is opgebouwd
(uit één of meerdere metingen) en hoe en door wie de data wordt
verzameld. AMI levert hier ook een template voor.
Verantwoordelijkheden en planning
Dit beschrijft de verschillende verantwoordelijkheden en milestones.
Verwijzingen
Eventuele extra informatie.
Logboek voor metingactiviteiten
Log-procedure voor monitoring en analyse van het meetprogramma.
Deel A: Definitie van de meting en analyse procedure
Naam
Naam van de metric en eventuele synoniemen.
Definitie
De relevante attributen die nodig zijn voor deze metric. De manier waarop
de metric wordt berekend en de primitieve metrics waaruit deze metric is
opgebouwd.
Doel
Beschrijft waarom deze metric wordt gebruikt.
Analyse Procedure
Beschrijft hoe deze metric gebruikt dient te worden. Eventuele
precondities, modellen en technieken en tools worden ook beschreven.
Verantwoordelijkheden
Beschrijft wie verantwoordelijk is voor het verzamelen van de data, het
voorbereiden van de reporten en het analyseren van de uitkomsten.
Benodigde training
Beschrijft welke training/kennis noodzakelijk is voor de toepassing en
interpretatie van deze metric.
Deel B: Definitie van primitieve metingen en verzamelprocedures
Naam
Naam van de primitieve meting.
Definitie
Eenduidige beschrijving van de metric.
Verzamelprocedure
Beschrijving van de procedure tot het verkrijgen van de metric. Data
verzamel tools en technieken. Het moment waarop de data wordt
verzameld, het verificatie proces en de plaats waar de data wordt
opgeslagen.
Verantwoordelijkheden
Beschrijving wie er verantwoordelijk is voor het verzamelen, verifiëren en
opslaan van de data.
Tabel 34 - Metric template [PUL96].
Stap 8
Nu het meetplan is opgesteld en de verantwoordelijkheden en procedures zijn
vastgelegd, kan het verzamelen van data beginnen. Onafhankelijk van de manier
waarop de data wordt verkregen, is het verstandig te bekijken hoe dit proces
verloopt. Het doel hiervan is het verminderen van de benodigde moeite en het
verbeteren van de accuraatheid van de metingen.
TNO-rapport
ERROR! REFERENCE SOURCE NOT FOUND.
C.4
Error! Reference source not found.
Bijlage C
Stap 9
De laatste stap in deze fase is de verificatie van de verzamelde data. Er zijn hier
een aantal aspecten die minimaal gecontroleerd dienen te worden:
- controleer de verzamelde data op compleetheid en accuraatheid,
- controleer op herhalende patronen die verkeerd gebruik aantonen,
- controleer op ongebruikelijke uitkomsten en probeer een verklaring te
vinden.
Fase ‘Improve’
Stap 10
Nu de data voorhanden is kan de analyse en verwerking ervan beginnen. Het is aan
te raden simpele grafische representaties te hanteren voor de presentatie van de
resultaten. Bij het analyseren van de data is het ook belangrijk de achtergrond
informatie te gebruiken en de betrokkenen te raadplegen om de uitkomsten in de
juiste context te kunnen plaatsen. De uitkomsten van de verwerkte data kunnen
middels rapporten regelmatig verspreid worden. Op deze manier blijven de
personen die betrokken zijn bij de metingen geïnformeerd en ook toegewijd bij het
meetprogramma.
Stap 11
Nu de data is verwerkt kan het valideren ervan beginnen. Hierbij wordt gekeken of
er trends aanwezig zijn en of deze te verklaren zijn, of er genoeg data is om
überhaupt trends te identificeren, of er ongebruikelijke of onverwachte resultaten
zijn en of de resultaten ‘passen’ bij processen en hoe ze overeenkomen met de
verwachtingen van de betrokkenen (subjectieve analyse). De uitkomsten van deze
analyse dienen ook in het meetrapport opgenomen te worden.
Stap 12
In de laatste stap van de AMI methode worden de uitkomsten gerelateerd aan de
initieel gestelde doelen. De organisatie dient zich te realiseren dat de uitkomsten
slecht aanwijzingen zijn voor potentiële problemen en niet een volledig bewijs
leveren. Het doel van deze analyse is het bekijken waar de aandacht nu op gericht
kan worden. Het is een voorbereiding op stap 1 van de AMI methode.
Terugblik
De AMI methode biedt een framework voor het kwantificeren van gewenste
aspecten uit het softwareontwikkelproces. Hierbij wordt op een systematische
manier een deductie uitgevoerd van onmeetbare primaire doelen naar specifieke
aspecten die wel meetbaar zijn. Per stap wordt gevalideerd of de afleiding correct
is. AMI biedt verschillende templates voor meetplannen en definities van metingen
en beschrijft de benodigde organisatorische aspecten.
ERROR! REFERENCE SOURCE NOT FOUND.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
D.1
Bijlage D
Best practices Sodalia and Eliop
In deze bijlage kunt u nadere informatie vinden over de tweede behandelde best
practices, Sodalia en Eliop [EZR02][MOR00][VIL95][DOU97].
Sodalia
Software Engineers
Circa 300
Software Proces
CMM 3
Maturity
ISO 9001
Bijzonderheden
Sodalia is na haar oprichting binnen een periode van 4 jaar tot CMM niveau 3
opgeklommen en ISO 9001 gecertificeerd. Na de oprichting werd de nieuwe groep
werknemers (veelal goed opgeleide jonge werknemers met een sterke achtergrond in object
technologieën) snel samengesteld. Om deze heterogene groep tot een eenheid te smeden
vond Sodalia het noodzakelijk om een set formele procedures te hanteren om het
softwareontwikkelproces te ondersteunen. Dit heeft ook sterk bijgedragen aan het snel
bereiken van het CMM niveau 3.
Markt
Telecommunicatie Software Producten, bijvoorbeeld Telecom Netwerk Management
(TNM) Systemen. Sodalia heeft verschillende geïdentificeerde productfamilies. In zo’n
productfamilie worden de specifieke producten aangepast aan de wensen en context van de
klant. Binnen de productfamilie TNM hebben de producten verschillende serviceniveaus
en functionaliteiten.
Aantal Klanten
Beperkt, hoofdzakelijk Telecom Italia en Bell Atlantic.
Potentie voor
Het doel van Sodalia is het ontwikkelen van software applicaties die voor de verschillende
hergebruik
klanten aangepast kunnen worden (de productfamilies). Mede gezien het domein en het feit
dat Sodalia één programmeertaal gebruikt (C++), is de conclusie dat de potentie voor
hergebruik zeer groot is.
Methoden,
Object georiënteerde analyse en ontwerp gebruikmakend van UML. De ontwikkeling
technieken en
geschiedt op basis hiervan in C++ waarbij design patterns en CORBA vaak worden
technologie
gebruikt.
Scope
Maakt gebruik van applicatie frameworks waarin de verschillende applicaties ontwikkeld
worden [HAL97]. In deze frameworks worden zowel algemene als domein georiënteerde
componenten verwerkt.
Doelen van
Het verbeteren van de softwareontwikkelingproductiviteit.
hergebruik
Het vergroten van de flexibiliteit in het productaanbod.
Aanwezigheid
-
Management support: Aanwezig, het management ziet hergebruik als een belangrijk
kritieke
onderdeel van de bedrijfsstrategie. Er is ook een budget vrijgemaakt om een groep van
succesfactoren
12 analisten, architecten en softwareontwikkelaars de verschillende issues met
hergebruik aan te laten pakken.
-
Hergebruik processen: Aanwezig, er is een apart proces voor de productie van
-
Aanpassing niet-hergebruik processen: Overal, volledige integratie hergebruik in
-
Anticiperen op menselijke factoren: Niet nodig, geen weerstand. Vanaf de oprichting
herbruikbare artefacten en ondersteuning voor hergebruik.
normale software ontwikkelactiviteiten.
van Sodalia is er reeds nadruk gelegd op hergebruik van software artefacten en nieuwe
ERROR! REFERENCE SOURCE NOT FOUND.
TNO-rapport
ERROR! REFERENCE SOURCE NOT FOUND.
D.2
Error! Reference source not found.
Bijlage D
werknemers accepteren dit, tevens zijn er trainingen en bewustzijnsinitiatieven (zie
onderdeel weerstand).
-
Incrementele invoering: Hergebruik is in vier fasen ingevoerd. (zie incrementele
-
Repository: Zelf ontwikkelde repository, Sodalia Assets Library Management System
invoering van hergebruik bij Sodalia onder Tabel 35)
(SALMS).
Herbruikbare
Objecten
Artefacten
Vanuit het management wordt het aangemoedigd artefacten vanuit alle fasen van het
softwareontwikkelproces her te gebruiken.
In de praktijk komt dit vooral neer op de volgende artefacten:
-
Frameworks
-
Class libraries
-
Componenten
De herbruikbare artefacten bevatten over het algemeen code, analyse en
ontwerpdocumentatie en testcases.
Intern/Extern
Artefacten (horizontaal & verticaal) worden zowel intern als extern verkregen waarbij
horizontale componenten typisch extern verworven commerciële producten zijn.
Processen
Productie
Herbruikbare artefacten worden op drie manieren verzameld. Ten eerste worden
voorafgaand aan de projecten door middel van domein analyse herbruikbare (verticale)
artefacten geproduceerd. Ten tweede worden hergebruik specialisten soms tijdelijk in een
project geïntegreerd om een herbruikbaar artefact te ontwikkelen. Tot slot is er een
centraliseerde inkoop van externe herbruikbare artefacten. Dit vindt plaats binnen de Reuse
Support Organization (RSO).
Ondersteuning
Het RSO is verantwoordelijk voor de ondersteuning. Dit omvat het beheer en onderhoud
van de herbruikbare artefacten, methodologische ondersteuning aan hergebruikers (op het
gebied van UML of object georiënteerd ontwerpen) en kwalificatie van herbruikbare
artefacten. Sodalia heeft een kwaliteitsteam die validatie en verificatie activiteiten alsmede
formele audits uitvoert op de herbruikbare artefacten voordat ze in de repository
opgenomen worden.
Consumptie
Het consumeren van herbruikbare artefacten is geïntegreerd in de normale
softwareontwikkelprocessen.
Management
Zetten van doelen, vrijmaken van resources en budgetten, realiseren benodigde
organisationele structuur.
Organisatie
Rollen
Reuse leader:
De reuse leader is verantwoordelijk voor het coördineren en bijhouden van alle hergebruik
activiteiten. Hij ondersteunt de projecten bij het hergebruiken en helpt ook bij de
identificatie van hergebruikmogelijkheden. Hij stemt de prioriteiten hier ook op af
(productie herbruikbare artefacten).
Reuse support engineer:
ERROR! REFERENCE SOURCE NOT FOUND.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
D.3
De reuse support engineer ondersteunt de projecten op zowel methodologisch gebied
(UML, CORBA) als bij het gebruik van herbruikbare artefacten.
Reusable asset developer:
De reusable asset developer is verantwoordelijk voor het ontwikkelen van herbruikbare
artefacten.
Reusable assets repository manager:
De reusable assets repository manager is verantwoordelijk voor het beheren van SALMS.
Structuur
In Figuur 36 is de organisatie van Sodalia m.b.t hergebruik te zien. Het RSO is
verantwoordelijk voor de productie van de herbruikbare artefacten en de productie en
consumptie van de herbruikbare artefacten is zo goed als ontkoppeld van elkaar. Dit komt
overeen met de Team Producer Structuur. Hierbij is het RSO het producer team.
Wat betreft de ontwikkeling van de applicatie frameworks is gebruik gemaakt van een
team bestaande uit ontwikkelaars van verschillende projecten waar dit framework gebruikt
kan worden. De ontwikkelaars zijn hier dus ook de potentiele gebruikers, dit verzekert ten
eerste dat de requirements van de huidige en mogelijk toekomstige applicatie vervuld
worden en tevens dat de gebruikers bekend zijn met het framework. De relatie tussen dit
team en het RSO is onbekend.
Verrekening
Er is geen beloningssysteem om hergebruik van herbruikbare artefacten aan te moedigen
(te complex en fraudegevoelig). De overhead van hergebruik is inzichtelijk gemaakt door
de structurele scheiding tussen ontwikkeling voor hergebruik en ontwikkeling met
hergebruik. Voor het RSO is er een bepaald budget beschikbaar.
Tools
De repository (SALMS).
Weerstand
Doordat Sodalia relatief kort bestaat en hergebruik meteen vanaf het begin in de processen
is verweven, was de weerstand tegen hergebruik nihil. Het management heeft ook een
sterke invloed gehad door de getoonde betrokkenheid (presentaties, briefings, newsletters,
trainingen).
Meten
Er zijn geen metrics gedefinieerd om bepaalde aspecten te kwantificeren. Er zijn wel
studies geweest voor metrics in de repository maar er zijn nog geen metingen operationeel.
In navolging van CMM niveau 3 is het wel noodzakelijk om metrics te definiëren. De
volgende stap is dan ook om deze metrics ook op hergebruik aspecten toe te passen.
Resultaten
Er zijn geen kwantitatieve resultaten omdat de benodigde metingen hiervoor op het gebied
van proces efficiency, economische gevolgen en ROI’s ontbreken.
De resultaten dienen bekeken te worden aan de hand van de gestelde doelen van het
hergebruik-initiatief. Het hergebruikniveau lag door de toepassing van de
applicatieframeworks wel hoog, nieuwe applicaties die gebouwd zijn op basis van de
frameworks bevatten circa 20-30% aan nieuwe applicatie specifieke code. Dit betekent dat
70-80% hergebruikt is.
Tabel 35 - Eigenschappen en hergebruikfactoren bij Sodalia.
ERROR! REFERENCE SOURCE NOT FOUND.
TNO-rapport
ERROR! REFERENCE SOURCE NOT FOUND.
D.4
Error! Reference source not found.
Bijlage D
Incrementele invoering van hergebruik bij Sodalia:
- Fase 1
Projecten zijn zelf verantwoordelijk voor de verwerving van herbruikbare
componenten. Als gevolg hiervan vindt hergebruik bijna exclusief in het project
zelfs plaats, of in sterk verbonden projecten. De rol van het RSO is hierbij het
ondersteunen in de methodologie en het beheer van de repository waarin de
herbruikbare artefacten worden opgeslagen.
- Fase 2
Het RSO wordt verantwoordelijk voor de verwerving van horizontale
artefacten. Projecten blijven verantwoordelijk voor de verwerving van verticale
artefacten. Hergebruik wordt projectoverschrijdend.
- Fase 3
Het RSO is nu volledig operationeel en verantwoordelijk voor het verwerven
van alle type artefacten. Het RSO wordt georganiseerd in productlijnen die elk
een eigen groep projecten ondersteunen.
- Fase 4
Deze fase vormt een optimalisatie van fase 3. De RSO is nu onafhankelijk van
projecten en is opgedeeld in ‘factories’. Deze structuur is stabiel over langere
perioden en vergroot de kwaliteit van de herbruikbare artefacten doordat skills
geconcentreerd worden.
Coördineren en tracken van alle hergebruik activiteiten
Reuse Support Organization
Sturing van
de
projectteams
Support voor
de
projectteams
Beheer van
de
herbruikbare
artefacten
Productie
herbruikbare
artefacten
Projectteams
Productie
software producten
Hulp met UML en
herbruikbare artefacten
Opslag in SALMS na goedkeuring
door Kwaliteitsteam
Management en onderhoud
herbruikbare artefacten
SALMS (repository)
Opslag
Herbruikbare
artefacten
- Zoeken en verkrijgen
herbruikbare artefacten
- Evaluatie gebruikte
herbruikbare artefact
Figuur 36 - Globaal overzicht hergebruikorganisatie Sodalia
ERROR! REFERENCE SOURCE NOT FOUND.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
D.5
Eliop
Software Engineers
Circa 30 van de 100 medewerkers
Software Proces
ISO 9001
Maturity
Bijzonderheden
Hergebruik van software is uitgevoerd als onderdeel van een Software Process
Improvement programma. Eliop ziet goede kwaliteit van zowel de processen als de
geproduceerde software als noodzakelijk om hergebruik systematisch uit te kunnen
voeren.
Markt
Industriële controle systemen inclusief software voor standaard computers en embedded
software. Eliop ontwikkelt software voor remote telecontrol, proces automatisering en
energie management. Deze software is een belangrijk onderdeel van de toegevoegde
waarde van Eliop.
Aantal Klanten
Onbekend.
Potentie voor
Veel van de systemen die Eliop ontwikkeld zijn real-time. Een ander punt van aandacht
hergebruik
zijn de vele verschillende omgevingen waarvoor de software wordt ontwikkeld. Veel van
de projecten die uitgevoerd worden, zijn upgrades van voorgaande versies. De software
producten die door Eliop worden ontwikkeld vallen binnen een beperkt aantal applicatie
domeinen. Het potentieel voor hergebruik is dan ook zeker aanwezig.
Methoden, technieken
Eliot heeft object georiënteerde technieken gehanteerd en is daarbij tot de conclusie
en technologie
gekomen dat deze voordelen hebben, maar zeker niet essentieel zijn. Momenteel wordt
er gebruik gemaakt van structured analysis, C en een assembly taal.
Scope
Er werd binnen Eliop reeds hergebruik van algemene herbruikbare artefacten toegepast
(ad-hoc). Aangezien Eliop slechts in een klein aantal domeinen werkt en er ook
applicatie specifieke artefacten hergebruikt kunnen worden, heeft eliop ervoor gekozen
dit ook te doen.
Doelen van
Het vergroten van de betrouwbaarheid (door gebruikmaking goed geteste herbruikbare
hergebruik
artefacten)
Het verlagen van de ontwikkeltijd (speciaal voor coderen en testen)
Het verlagen van de kosten (geschatte realiseerbare besparing á 30%)
Aanwezigheid kritieke
-
succesfactoren
Management support: Eliop acht management support essentieel om een
hergebruik programma te kunnen uitvoeren, zowel voor de cultuurverandering, de
organisatieverandering als de koppeling aan de bedrijfsstrategie. Er dient voor
hergebruik verder gekeken te worden dan alleen naar de lopende projecten.
-
Hergebruik processen: Eliop heeft twee processen specifiek voor hergebruik
toegevoegd. Dit zijn de domein analyse in de projecten om herbruikbare verticale
artefacten te produceren en de validatie van deze herbruikbare artefacten voordat ze
in de repository opgeslagen mogen worden.
-
Aanpassing niet-hergebruik processen: Eliop hanteert een klassieke levenscylcus
van requirements analyse, ontwerp, implementatie, testen en onderhoud. Alle
processen in deze fasen zijn bekeken met het oog op hergebruik en hierop
aangepast.
-
Anticiperen op menselijke factoren: Eliop identificeert drie zeer belangrijke
onderwerpen. Volledige betrokkenheid van de software ontwikkelaars (ze moeten
inzien wat het profijt van hergebruik is), begrijpen van de herbruikbare artefacten
(alleen de artefacten van wiens functionaliteit, interface en beperkingen bekend zijn
ERROR! REFERENCE SOURCE NOT FOUND.
TNO-rapport
ERROR! REFERENCE SOURCE NOT FOUND.
D.6
Error! Reference source not found.
Bijlage D
kunnen succesvol hergebruikt worden) en training van de software ontwikkelaars
(zie Opzet van de trainingen bij Eliop onder Tabel 36).
-
Incrementele invoering: Een evolutionaire introductie heeft voor Eliop de voorkeur
-
Repository: Vanwege het niet kunnen vinden van een geschikte commerciële tool
ten opzichte van een revolutionaire aanpak.
is er een standaard database management systeem gebruikt om informatie in op te
slaan over de beschikbare herbruikbare artefacten. Deze herbruikbare artefacten
zelf zijn opgeslagen in een aparte repository (gebruikmakend van een
configuratiemanagement systeem).
Herbruikbare
Objecten
Artefacten
Bij Eliop wordt er onderscheid gemaakt naar twee typen herbruikbare artefacten:
herbruikbare artefacten gepland voor hergebruik en ongepland voor hergebruik. Dit
onderscheid komt voort uit het moment en de manier waarop het herbruikbare artefact
gemaakt is.
Type herbruikbare artefacten:
-
broncode,
-
specificaties,
-
ontwerpdocumenten,
-
test procedures.
Intern/Extern
De herbruikbare artefacten worden alleen in-house ontwikkeld. Eliop heeft white-box
hergebruik als de standaard. Eliop gaat er vanuit dat white-box lagere kosten met zich
meebrengt en minder eisen stelt aan de organisatie.
Tevens wordt er zowel hergebruik van horizontale als verticale herbruikbare artefacten
toegepast.
Eliop heeft als doel de herbruikbare artefacten te standaardiseren door de toepassingen
van templates voor documenten en coding rules voor broncode.
Processen
Productie
Eliop maakt onderscheid tussen geplande en ongeplande productie van hergebruik.
Geplande productie van herbruikbare artefacten is het doormiddel van domein
engineering tijdens projecten produceren van deze herbruikbare artefacten. Dit is voor
Eliop ook de normale manier om herbruikbare artefacten te verkrijgen. De andere optie
is het verkrijgen van herbruikbare artefacten vanuit bestaande softwareproducten. Deze
aanpak werd noodzakelijk geacht dor Eliop om een kritieke massa te kunnen creëren van
herbruikbare artefacten zodat de ontwikkelaars ook daadwerkelijk iets zouden hebben
om her te gebruiken. Deze methode bestond uit drie stappen.
(1) Evalueren van de artefacten op herbruikbaarheid (criteria: algemene kwaliteit,
voldoet het aan de in-house standaarden, bruikbaarheid, onderhoudbaarheid,
algemeenheid en volwassenheid).
(2) Pas de artefacten aan zodat ze herbruikbaar zijn.
(3) Voeg ze toe aan de repository.
Ondersteuning
Er is geen formeel orgaan voor ondersteuning, doormiddel van trainingen en voorlichting
probeert Eliop dit onnodig te maken.
Consumptie
ERROR! REFERENCE SOURCE NOT FOUND.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
D.7
Zelfde als bij Sodalia.
Management
Zelfde als bij Sodalia.
Organisatie
Rollen
Reuse leader:
Algemene verantwoordelijkheid voor het succes van hergebruik. Vergelijkbare invulling
als bij Sodalia.
Reuse task group:
Bestaat uit de reuse leader, project managers en senior engineers. Ze zijn
verantwoordelijk voor de domein analyse en de validatie van de herbruikbare artefacten
voordat ze worden opgenomen in de repository.
Library manager:
De library manager beheert de ‘repository’ van Eliop. Hij zorgt ervoor dat het DBMS en
het CMS consistent blijven en is verantwoordelijk voor de toevoeging van goedgekeurde
herbruikbare artefacten hierin.
Structuur
Eliop heeft heel weinig aan de bestaande structuur gewijzigd om de overgang zo
makkelijk mogelijk te laten verlopen. Wel is er een Reuse Task Group (RTG) opgericht
voor de domein analyse en validatie van de herbruikbare artefacten. In deze RTG zitten
de reuse leader, projectmanagers en enkele senior engineers. Figuur 37 geeft een globaal
overzicht. Door de opname van de projectmanagers in de RTG is de sturing van de
projectteams ook geborgd. De projectmanagers zijn in de projecten zelf verantwoordelijk
voor de verdere uitdraging van hergebruik.
Verrekening
Geen informatie beschikbaar, waarschijnlijk op basis van overhead funding.
Tools
De repository is een combinatie van een Database Management Systeem (informatie
over de herbruikbare artefacten) en een Configuratie Management Systeem (opslag
herbruikbare artefacten zelf). Elk herbruikbare artefact heeft een identificatie, een
omschrijving, bepaalde keywords, informatie over in welke projecten het is gebruikt en
welke relaties en afhankelijkheden er zijn met andere herbruikbare artefacten. Tevens is
er informatie beschikbaar indien het herbruikbare artefact bepaalde beperkingen oplegt
zoals een realtime beperking.
Verder heeft de repository 3 niveau’s voor de gebruikers (user, superuser en
administrator) waarbij bepaalde operaties alleen door de administrator gedaan kunnen
worden (toevoegen of reviewen van herbruikbaar artefact).
Weerstand
Oorzaak
Er bestond enige weerstand tegen het hergebruik initiatief, maar deze bleek vooral
gevoed te worden door de gebrekkige prestaties en interface van de beschikbare
repository.
Andere negatieve houdingen t.o.v. hergebruik hadden de volgende redenen:
-
weerstand om te veranderen,
-
slechte ervaring met hergebruik (als gevolg van het hergebruiken van kwalitatieve
slechte herbruikbare artefacten of omdat er geen systematische processen of
procedures aanwezig waren).
ERROR! REFERENCE SOURCE NOT FOUND.
TNO-rapport
ERROR! REFERENCE SOURCE NOT FOUND.
D.8
Error! Reference source not found.
Bijlage D
Oplossing
Dit heeft Eliop opgelost doormiddel van de verschaffing van informatie en trainingen.
Vooral presentaties over de eerste pilots bleken een efficiënte manier om acceptatie te
verkrijgen. Tevens acht Eliop correct management processen belangrijk, dit betreft
vooral de procedures over het opslaan van een herbruikbaar artefact in de repository en
het vastleggen van systematische processen en methoden.
Meten
Eliop heeft gekozen voor de ami methode voor het opstellen van metingen. Deze
methode leidt aan de hand van bepaalde doelen een set van metingen af. Voor Eliop
vormen metingen een essentieel onderdeel van het proces om terugkoppeling te creëren
op de effecten van de veranderingen en om deze te kunnen sturen. Eliop acht het hierbij
belangrijk om de metingen zo eenvoudig mogelijk te houden. De belangrijkste metingen
zijn:
-
extra kosten van herbruikbare artefacten,
-
mate van gebruik van de herbruikbare artefacten,
-
foutenregistratie (fouten worden hierbij gewogen naar de ernst en de fase waarin
ze naar voren kwamen)
Resultaten
Het blijkt voor Eliop dat het produceren van een herbruikbaar artefact 60% duurder is
dan normaal. Echter reeds bij de eerste keer dat het hergebruik wordt zijn de kosten
slechts 20% van de normale kosten en daarna raamt Eliop het op 10%.
First
Second
Third
use
use
use
Fourth use
Accumulated Costs
160%
180%
190%
200%
Average Costs per
160%
90%
63%
50%
use
Reeds bij de tweede keer dat het hergebruikt wordt zijn de kosten dus al 10% lager dan
bij het zelf opnieuw bouwen. Hierbij wordt er wel vanuit gegaan dat het alternatief
helemaal geen hergebruik is.
De belangrijkste doelen voor Eliop waren productiviteit en betrouwbaarheid. Grote
productiviteitsverbeteringen zijn niet gerealiseerd maar worden ook onwaarschijnlijk
geacht. De kwaliteit is wel verbeterd en dit is voor Eliop ook belangrijker. Exacte cijfers
zijn echter nog niet beschikbaar.
Tabel 36 - Eigenschappen en hergebruikfactoren bij Eliop.
Opzet van de trainingen bij Eliop:
Eliop acht het trainen van de werknemers belangrijk en heeft hiervoor een
trainingsplan opgesteld dat bestaat uit drie fasen:
- Fase 1
Tijdens de start van een project worden ontwikkelaars, die normaliter in een
specifiek gebied werkzaam zijn, inzichten geboden in de verschillende
gebieden binnen Eliop om een betere visie te krijgen van de mogelijkheden tot
horizontaal hergebruik. Indien de ontwikkelaars hier bekend mee zijn
verschuift de nadruk naar verticaal hergebruik.
- Fase 2
ERROR! REFERENCE SOURCE NOT FOUND.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
D.9
-
Gedurende het project wordt essentiële kennis over hergebruik verspreid: de
doelen van het project m.b.t. hergebruik, de huidige status van het project en
de verschillende methoden en tools die gebruikt kunnen worden.
Fase 3
Bespreking van de uitkomsten van het project, nieuwe metingen en
procesveranderingen om verdere acceptatie te realiseren. Om dit te bereiken
achtte Eliop het belangrijk om actieve participatie en een open discussie aan te
moedigen.
Reuse Task Group
Herbruikbare
artefacten
vanuit
Planned
Reuse
Planned
Reuse:
Domein
analyse
Sturing van
de
projectteams
Validatie van herbruikbare
artefacten (Planned + Unplanned
Reuse)
Coördineren en
tracken van alle
hergebruik
activiteiten
Projectteams
Productie
software producten
Herbruikbare artefacten
vanuit Unplanned Reuse
Opslag goedgekeurde
herbruikbare artefacten
Repository (DBMS + CMS)
Opslag
Herbruikbare
artefacten
Zoeken en verkrijgen van
herbruikbare artefacten
Figuur 37 - Globaal overzicht hergebruikorganisatie Eliop.
ERROR! REFERENCE SOURCE NOT FOUND.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
E.1
Bijlage E
Interviewopzet
Interviews vormen een goede aanpak voor het verkrijgen van informatie. Voor het
verkrijgen van de gewenste informatie dienen echter wel de juiste vragen aan de
juiste personen gesteld te worden [HUL92]. De interviews worden hier binnen
Business Unit 2, de voormalige divisies “Operationele Research en
Bedrijfsvoering” en “Command Control & Simulatie” gehouden.
Doel
Het doel van de interviews met de verschillende stakeholders is het verkrijgen van
inzicht in een drietal onderwerp.
1) De huidige situatie van hergebruik van software artefacten met betrekking
tot de: objecten, processen en organisatie.
2) Problemen of knelpunten voor de verschillende stakeholders met
betrekking tot de invoering en toepassing van hergebruik van software
artefacten.
3) Inzicht krijgen in de awareness en visies van de betrokkenen over
hergebruik van software artefacten.
Opzet
Voor de voorbereiding van het interview en de verwerking van de uitkomsten is
circa één dag uitgetrokken. Voor de interviews zelf wordt er circa 30 à 90 minuten
uitgetrokken, afhankelijk van het type stakeholder. Hergebruik van software
artefacten brengt voor de stakeholders verschillende problemen met zich mee. Er
zijn drie globale groepen te identificeren die als aparte stakeholdersgroepen
gekenmerkt kunnen worden.
-
-
-
Ontwikkelaars
Dit zijn de personen die de architect- en programmeerwerkzaamheden
binnen een project uitvoeren. Zij krijgen vooral te maken met de
technische aspecten van hergebruik.
Projectleiders
Dit zijn de personen die de projecten leiden en verantwoordelijk zijn voor
de keuzes die daarin gemaakt worden. Hergebruik heeft o.a. een impact op
hun verantwoordelijkheid en budget.
Management
Indien hergebruik formeel erkend wordt binnen TNO-FEL en daar
wijzigingen voor worden gemaakt is het management
eindverantwoordelijk voor het succes ervan. Tevens zijn zij
verantwoordelijk voor het zetten van doelen voor hergebruik en het
vrijgeven van budgetten.
Voor de interviews worden er verschillende stakeholders gekozen zodat de
problemen die in de verschillende stakeholdersgroepen spelen allemaal aan bod
TNO-rapport
ERROR! REFERENCE SOURCE NOT FOUND.
E.2
Error! Reference source not found.
Bijlage E
komen. Tabel 37 geef een overzicht van de stakeholders en het aantal personen die
geïnterviewd zijn binnen die groep. Personen kunnen ook tot twee stakeholdergroepen behoren, bijvoorbeeld zowel projectmanager als software engineer.
Stakeholdersgroep
Aantal
Ontwikkelaars
Projectmanagers
Technologietrekker/manager
Management
5
3
2
1
Tabel 37 - Overzicht van het aantal interviews per stakeholdergroep.
Interviewvragen voor de ontwikkelaars
In Tabel 38 wordt de relatie tussen de interviewvragen voor de ontwikkelaars en de
theorie weergegeven. Niet alle vragen zijn direct of duidelijk in één van de
categorieën in te delen. Onder de tabel staan de interviewvragen zelf opgesomd.
Interviewvraag
Hergebruik
Algemeen
1
X
2
X
Objecten
Processen
Organisatie
Metingen
Weerstand
3
X
4
X
5
X
6
X
7
X
8
X
9
X
10
X
X
11
12
13
X
X
X
X
14
X
15
X
16
X
17
X
18
X
Tabel 38 - Relatie interviewvragen ontwikkelaars en theorie.
1
2
Wat verstaat u onder hergebruik binnen het softwareontwikkelproces?
Denkt u dat hergebruik van software artefacten ook systematisch toepasbaar is
binnen TNO-FEL?
a. Wat zijn dan de randvoorwaarden die hergebruik van software artefacten
binnen TNO-FEL mogelijk maken (csf)?
b. Om welke redenen zou hergebruik van software binnen TNO-FEL niet
toepasbaar zou zijn?
c. Wat ziet u als voordelen van hergebruik van software artefacten?
ERROR! REFERENCE SOURCE NOT FOUND.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
E.3
3
4
d. Wat ziet u als nadelen van hergebruik van software artefacten?
Wat ziet u als mogelijke weerstanden tegen de systematische toepassing van
hergebruik van software artefacten?
a. Bent u bekend met de term “Not invented here”?
b. Wat is dit volgens u?
c. Speelt dit ook binnen TNO-FEL m.b.t. hergebruik?
Welke softwareontwikkelprocessen zijn er aanwezig om hergebruik van software
mogelijk te maken?
Bij hergebruik van software artefacten wordt er een splitsing gemaakt tussen het ontwerpen
voor hergebruik en het ontwerpen met hergebruik. Hieronder zal eerst ingegaan worden op
het ‘design for reuse’ en daarna op het ‘design with reuse’. Overkoepelende activiteiten
zoals management processen of ondersteuning komen hierna aan bod.
5
6
7
8
9
Wat voor herbruikbare software artefacten worden er gemaakt binnen TNO?
Bij het produceren van herbruikbare artefacten kan er gebruik worden gemaakt
van reeds bestaande artefacten (re-engineering) of kan het herbruikbare artefact
nieuw ontwikkeld worden.
a. Op welke manier worden deze herbruikbare artefacten geproduceerd?
b. Zijn hiervan procesomschrijvingen aanwezig?
c. Hoe re-engineert u een bestaand software artefact zodat het een
herbruikbaar software artefact wordt?
d. Hoe ontwikkelt u een herbruikbaar software artefact indien het vanuit
niets gemaakt wordt?
Hoe is de productie van herbruikbare software artefacten georganiseerd?
Vindt er sturing plaats bij de productie van herbruikbare software artefacten?
a. Zoja, hoe wordt er bepaald wat er herbruikbaar gemaakt wordt?
b. Zonee, acht u deze sturing wel noodzakelijk of zijn de software engineers
in staat dit zelf bepalen?
i. Wat zou een software engineer nodig hebben om hier wel toe in
staat te zijn?
Denkt u dat er een verschil bestaat in documentatie van herbruikbare software
artefacten en niet herbruikbare producten en zoja, welk verschil is dit dan?
a. Welke documentatie acht u noodzakelijk voor een herbruikbaar software
artefact?
b. Welke zou u bereid zijn te leveren mocht u herbruikbare software
artefacten produceren?
Hieronder staan de vragen die betrekking hebben op ‘design with reuse’.
10 Maakt u, bij de ontwikkeling van nieuwe software producten, gebruik van
bestaande software artefacten die niet specifiek voor het nieuwe product gecreëerd
zijn?
a. Wat voor software artefacten (her)gebruikt u op deze manier?
b. Hoe komt u aan deze herbruikbare software artefacten (bronnen)?
c. Ziet u dit ook als hergebruik?
11 Hoe wordt bepaald of het gekozen software artefact daadwerkelijk her te
gebruiken is bij de ontwikkeling van het nieuwe software product (welke criteria
hanteert u)?
12 Bij hergebruik van software artefacten zijn er twee uitersten aanwezig, namelijk
black box hergebruik en white box hergebruik. Bij de toepassing van black box
hergebruik worden de software artefacten ‘as-is’ gebruikt in het nieuwe software
product. Bij white box hergebruik kunnen de herbruikbare software artefacten nog
worden aangepast.
TNO-rapport
ERROR! REFERENCE SOURCE NOT FOUND.
E.4
Error! Reference source not found.
Bijlage E
Zijn de software artefacten die zijn ontwikkeld en worden hergebruikt binnen
TNO bedoelt voor blackbox of whitebox hergebruik? M.a.w. mogen ze aangepast
worden door de hergebruikers?
13 Hoe is het proces voor het gebruik van een herbruikbaar software artefact
ingericht?
14 Een belangrijke tool t.b.v. hergebruik is een centrale opslagplaats van de
herbruikbare componenten. Binnen TNO-FEL zal SourceForge deze rol vervullen.
a. Hoe wordt SourceForge gebruikt voor hergebruik van software
artefacten?
b. Zijn er ook nog andere tools die worden gebruikt bij toepassing van
hergebruik van software artefacten?
c. Zijn er nog functionaliteiten die niet gedekt worden door de huidige
beschikbare tools?
Hieronder staan de overkoepelende vragen.
15 Hoe zijn de reeds genoemde ‘hergebruik processen’ geïntegreerd in het normale
softwareontwikkelproces?
16 Twee andere belangrijke processen binnen softwareontwikkeling m.b.t. hergebruik
zijn de ondersteuning en managementprocessen.
a. Hoe zijn zaken zoals onderhoud, certificering, bugfixing en
configuratiemanagement en versiebeheer voor herbruikbare artefacten nu
geregeld?
b. Is er ‘management van hergebruik’ aanwezig? M.a.w. zijn er doelen,
plannen en budgetten aanwezig?
17 De productie van herbruikbare software artefact is vaak duurder dan de productie
van een normaal software artefact.
a. Hoe worden deze productiekosten verrekend?
b. Hoe worden andere kosten verrekend, zoals kosten voor onderhoud en
ondersteuning?
18 Worden er in het softwareontwikkelproces kwantitatieve gegevens bijgehouden
(metingen) van aspecten zoals kosten, kwaliteit, productiviteit?
a. Zoja, vindt dit ook plaats voor softwareontwikkelprocessen die te maken
hebben met hergebruik van software artefacten?
b. Zonee, acht u dit mogelijk en wenselijk?
Interviewvragen voor de projectleiders
In Tabel 39 wordt de relatie tussen de interviewvragen voor de projectleiders en de
theorie weergegeven.
Interview Hergebruik Objecten Processen Organisatie Metingen
vraag
algemeen
1
X
2
X
3
X
4
X
5
X
6
X
7
X
8
X
ERROR! REFERENCE SOURCE NOT FOUND.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
E.5
9
X
10
X
11
X
Tabel 39 - Relatie interviewvragen Projectleiders en theorie.
De interviewopzet is zowel bedoeld voor de interviews met de projectleiders van
één van de cases als wel voor de projectleiders in het algemeen. Voor de case
studies worden de interviewvragen specifiek op die case toegepast. Indien er een
projectleider wordt geïnterviewd die niet bij de case studies betrokken is, worden
de intervragen niet specifiek op de case studies gericht.
1.
2.
3.
Wat is hergebruik van software volgens u?
In hoeverre heeft u er mee te maken in projecten?
Denkt u dat hergebruik van software artefacten systematisch toepasbaar is binnen
TNO-D&V?
a. Wat zijn randvoorwaarden waaraan voldaan moet zijn om het mogelijk te
maken?
b. Wat zijn voor u de voordelen van hergebruik van software artefacten?
c. Wat zijn voor u de nadelen, problemen of consequenties van hergebruik
van software artefacten?
4. Hoe wordt er bepaald of een software artefact herbruikbaar wordt gemaakt?
a. Wie is verantwoordelijk voor deze keuze?
b. Op welk moment wordt dit bepaald? Gebeurt dit voor, tijdens of na het
project waarin het originele artefact is geproduceerd?
5. Hoe maak je als projectleider de afweging om een herbruikbaar artefact te gaan
hergebruiken. Welke aspecten worden er in deze beslissing meegenomen?
6. Zijn de activiteiten zoals Configuratie Management, onderhoud, versiebeheer,
bugfixing geregeld voor de herbruikbare artefacten?
a. Is dit ook nog geregeld na de afloop van het project waarin het
herbruikbare artefact is ontwikkeld?
i. Zoja, hoe wordt het geregeld?
ii. Zonee, waarom niet en wat is hiervoor nodig?
7. Stuurt u als projectleider op de productie of consumptie van herbruikbare
artefacten?
a. Zoja, hoe doet u dit?
b. Zonee, gebeurt dit uberhaubt?
8. Stel dat er iets uit uw project wordt hergebruikt in een ander project. Dit andere
project heeft verder geen relatie tot jouw project. Hoe staat u hier tegenover?
9. Stel dat uw project iets kan hergebruiken uit een ander project. Hoe staat u hier
tegenover?
10. De productie van herbruikbare software artefacten is over het algemeen duurder
dan de productie van een normaal software artefact.
a. Wat gebeurt er met deze (extra) kosten?
b. Hoe wordt er omgegaan met de hergebruik-specifieke kosten van
bijvoorbeeld onderhoud of change-requests van herbruikbare software
artefacten?
11. Worden er in het softwareontwikkelproces kwantitatieve gegevens bijgehouden
van aspecten zoals kosten en kwaliteit?
a. Zoja, gebeurt dit ook voor hergebruik en hoe dan?
b. Zonee, hoe bepaal je dan bijvoorbeeld de kosten van een herbruikbaar
artefact?
TNO-rapport
ERROR! REFERENCE SOURCE NOT FOUND.
E.6
Error! Reference source not found.
Bijlage E
Interviewvragen voor de BU manager
De onderstaande interviewopzet is bedoeld voor Manager Operations van BU2. Hij
is op de hoogte van het onderwerp naar aanleiding van de presentatie over
hergebruik van software artefacten drie weken eerder.
1.
2.
3.
4.
Wat is het belang van softwareontwikkeling voor TNO-D&V als kennisinstituut?
Wat voor rol kan hergebruik van software binnen BU2 spelen volgens u?
a. Acht u hergebruik van software wenselijk?
b. Zoja/Zonee, waarom wel/niet?
Wat zou er volgens u geregeld moeten worden om hergebruik van software
mogelijk te maken binnen BU2, ziet u het als een puur technische aangelegenheid
of spelen er volgens u ook andere factoren een belangrijke rol?
Wat zou voor u een belangrijk doel zijn van hergebruik? Kwaliteitsverbetering,
kostenverlaging of een productiviteitsverbetering (kortere doorlooptijd)?
Uit de theorie en geanalyseerde best practices op het gebied van systematisch
hergebruik blijkt dat het noodzakelijk is dat er een orgaan is die over de projecten heen
hergebruik coördineert, zie Figuur 29. Hierin blijft de projectstructuur gehandhaafd en
maken en gebruiken de projectteams de herbruikbare artefacten onder sturing van de
hergebruikgroep. Naar mijn mening zijn er een aantal organisatorische aspecten nodig
om hergebruik van software gemeengoed te kunnen laten worden binnen BU2,
namelijk sturing, beheer en financiering.
5.
6.
Is het mogelijk om projecten een taak op te leggen om een specifiek component
herbruikbaar te maken?
a. Zoja, hoe zou dat volgens u gedaan moeten worden?
b. Zonee, waarom niet? Wat zijn de belemmeringen?
Is het mogelijk om de keuze voor hergebruik deels uit de projecten te trekken en
neer te leggen bij de hergebruikgroep
a. Zoja, hoe zou dat volgens u gedaan moeten worden?
b. Zonee, waarom niet? Wat zijn de belemmeringen?
Het beheer van de herbruikbare artefacten, taken zoals onderhoud, Configuratie
Management, Problem and Change management en ondersteuning, kan neergelegd
worden bij de hergebruikstuurgroep maar je kan ook individuele software engineers
verantwoordelijk maken voor een bepaald herbruikbaar artefact.
7.
Hoe denkt u dat het beheer van de herbruikbare artefact binnen TNO-D&V het
beste geregeld kan worden?
Een belangrijk vraagstuk is natuurlijk de financiering van de activiteiten voor
hergebruik. Hergebruik zou in principe zelfvoorzienend moeten zijn. Maar vanuit de
theorie blijkt dat er altijd een investering vooraf gedaan moet worden om bepaalde
faciliteiten op te zetten of om herbruikbare artefacten te ontwikkelen. Verder zijn er
altijd projectoverschrijdende activiteiten die gefinancieerd moeten worden.
8.
Hoe denkt u dat dit het beste gefinancierd kan worden?
ERROR! REFERENCE SOURCE NOT FOUND.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
F.1
Bijlage F
Codes of Practice binnen TNO-D&V
Deze bijlage geeft een overzicht, zie Figuur 38 en Tabel 40, van de Codes of
Practice die binnen TNO-D&V zijn opgesteld. De Codes of Practice is een set
documenten en templates waarbij elke Code of Practice (COP) een element uit het
software engineering proces beschrijft.
Er worden drie categorieën COP’s onderscheiden:
1. Management COP’s
Biedt een template voor de condities waaronder een project wordt
uitgevoerd, bijvoorbeeld het Software Development Plan (SDP).
2. Procedurele COP’s
Beschrijft hoe een specifiek proces uitgevoerd zou moeten worden,
bijvoorbeeld het Configuratie Management (CM) of Problem & Change
Management (PCM).
3. Technische COP’s
Template voor de documentatie van de applicatie die wordt ontwikkeld,
bijvoorbeeld de Software Design Description.(SDD) of de Software User
Manual (SUM).
Figuur 38 - COP’s t.o.v. de fasen waarin een softwareproject kan verkeren.
TNO-rapport
ERROR! REFERENCE SOURCE NOT FOUND.
F.2
Error! Reference source not found.
Bijlage F
Category
Procedural
Procedural
Procedural
Procedural
Procedural
Technical
Technical
Procedural
Technical
Technical
Technical
Technical
Technical
Technical
Technical
Technical
Procedural
Procedural
Procedural
Procedural
Procedural
Procedural
Technical
Management
Technical
Technical
Procedural
Technical
Technical
Technical
Technical
Management
Technical
Technical
Technical
Technical
Technical
Technical
Code
AUD
CM
CPSL
CR
CSL
DBDD
EAR
ECP
IDD
IRS
ITD
ITR
OCD
PADA
PC
PCPP
PCM
PR
QER
REV
RFD
RFW
SDD
SDP
SDF
SPS
SFMAP
SRS
SSDD
SSS
STD
STP
STR
SVD
SUM
SYSTD
SYSTR
TDF
Document title
Audit procedure
Configuration Management procedure
Change Proposal Status List
Change Request
Configuration Status List
DataBase Design Description*
Engineering Analysis Report
Engineering Change Proposal
Interface Design Description *
Interface Requirements Specification *
Internal Test Description
Internal Test Result
Operational Context Description *
Programming in Ada (style guide)
Programming in C (style guide)
Programming in C++ (style guide)
Problem and Change Management procedure
Problem Report
Quality Evaluation Record
Review procedure
Request For Deviation
Request For Waiver
Software Design Description *
Software Development Plan *
Software Development File
Software Product Specification *
IT/QA Activity Mapping to SourceForge
Software Requirements Specification *
System Subsystem Design Description *
System Subsystem Specification *
Software Test Description *
Software Test Plan
Software Test Report *
Software Version Description *
Software User Manual *
System Test Description *
System Test Report *
Test Detail Form
Tabel 40 - Overzicht van Code of Practices (COPS) binnen TNO-D&V.
* Authentic document according to MIL-STD-498 Data Item Descriptions (DID's).
ERROR! REFERENCE SOURCE NOT FOUND.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
G.1
Bijlage G
Componenten uit het Kibowi MP Framework
In Tabel 41 wordt per component een korte toelichting van de functionaliteit
gegeven.
Laag
Applicaties
Phoenix
Element uit laag
Control, Observer,
Entity Editor, Otas
Editor, Administrator,
Evaluator
Kibowi Applicatie
Kibowi Gui
Permissions
Database definitions
Messages
ModelParameters
Events
Computer
GenericGui
Simulation
Environment
Generic Application
Database Management
Toelichting
Dit zijn applicaties die gebruikt worden door en voor
Kibowi MP.
Basis framework voor een Kibowi MP applicatie. In
dit framewerk wordt bijvoorbeeld een database
manager gemaakt, het mail systeem opgestart, de
properties bestanden ingelezen enz. Kortom, al het
noodzakelijke voorwerk om een Kibowi applicatie te
maken gebeurt hier. De daadwerkelijke applicatie
start als het ware ‘binnen’ dit framewerk en wordt
door het framework ‘ge-kickstart’.
Specialisatie van GenericGUI voor Kibowi.
Gebaseerd op Java Security Permissions. Specifiek
voor Kibowi gemaakt. Hierdoor is het mogelijk om
authorisaties per object/attribuut op te geven voor
een bepaalde fase, status en actie. Permissions zijn
gedefinieerd per rol. Omvat ook de competenties
voor het kunnen uitvoeren en opgeven van orders.
De database definities voor Kibowi
De definities van de Kibowi berichten tussen de
verschillende applicaties.
Definitie van de parameters zoals met name in de
Evaluator gebruikt worden bij de simulatie
modellen.
Kibowi events. Pop ups, rook e.d.
Een algemeen framework waarin user interfaces
kunnen worden gemaakt. Het algemene framewerk
biedt een standaard lay-out met een ‘takenlijst’ links
op het scherm. Aan iedere taak hangt een scherm
met daaraan vast een menu. De schermen en
bijbehorende menu’s kunnen door de gebruiker
worden opgegeven, het framewerk zorgt voor de
coördinatie en dergelijke.
Generieke laag voor het opstart gedeelte van
applicaties.
DB Managers, Object definitions, Constanten,
UnitConversions etc.
TNO-rapport
ERROR! REFERENCE SOURCE NOT FOUND.
G.2
Error! Reference source not found.
Bijlage G
Coordinates
GLF
Graph
GIS
TNO
System
API’s
Mail
State Machine
ORB Kernel
Monitor
Expressions
Helpers
Versioning
Berekeningen snijpunten met cirkels, ellipsen e.d.
Graphic Layers Framework. Handige java tools voor
menu’s en andere graphics
Berekeningen voor kortste pad algoritmes e.d.
Geografisch informatie systeem. Is opgebouwd uit
verschillende delen: View, Control, Terrain queries,
Terrain Model en Coordinate math. Het biedt user
interface componenten, visualiteit van het terrein
etc.
Een algemeen pakket waarmee applicaties in een
netwerk onderling (op inhoudelijk niveau) kunnen
communiceren. Het pakket maakt het mogelijk
kanalen te definiëren waarop kan worden
uitgezonden en geluisterd. Applicaties melden zich
door middel van RMI aan. Het pakket schermt met
name netwerkprotocollen en unicast, multicast of
broadcast zaken voor de gebruiker af.
Een pakket waarmee met name synchronisatie van
werkzaamheden kan worden beheerd. De gebruiker
kan zelf state machines bouwen door zelf de states,
signals en state transitions op te geven. Aan de states
en aan de transities kunnen vervolgens events
worden gehangen. De State Machine draait in een
eigen thread (en dus asynchroon van de gebruiker).
De ORB kernel maakt het mogelijk event based om
time scheduled simulaties uit te voeren. De ORB
kernel verzorgt met name de juiste scheduling van
activiteiten en het beheer van de tijd.
Een algemeen pakket waarmee monitor informatie
van deelsystemen kan worden opgevraagd en in een
aparte module overzichtelijk kan worden
weergegeven. Met name handig om systemen ook
run-time te kunnen volgen.
Een pakket waarmee het mogelijk is logische
expressies te bouwen en te evalueren.
Extensies op java.
Bijhouden van een versienummer op package
niveau.
Tabel 41 - Toelichting bij de componenten uit het Kibowi MP Framework.
ERROR! REFERENCE SOURCE NOT FOUND.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
H.1
Bijlage H
Stroomschema voor gebruik Electronic
Battlespace Facility
Figuur 39 toont een flowchart die bij het EBF wordt gehanteerd voor gebruikers
van de faciliteit.
Figuur 39 - Stroomschema voor het gebruik van het EBF.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
I.1
Bijlage I
Uitkomsten Group Facility Room Sessie
De onderstaande data is afkomstig van de groepssessie van 6 juni 2005. Hierbij is
een presentatie gegeven van de bevindingen van de huidige situatie en zijn er een
viertal aanbevelingen besproken. Per aanbeveling is er een presentatie gegeven met
verschillende keuzemogelijkheden en de afwegingen. Daarna is per aanbeveling
anoniem gestemd. Deelnemers: 11. Het afdelingshoofd, 4 projectleiders en 9
software engineers (2 personen zijn zowel projectleider als software engineer).
Aantal deelnemers
Stelling 1:
Hanteer een strikte, centrale sturing op de ontwikkeling van
herbruikbare artefacten.
Eens
7
Oneens
4
Response: Eens
Opmerkingen:
-
-
-
-
Duidelijke regel maar afwijken moet kunnen
Eens, maar een artefact hoeft niet een al bestaande s/w component te zijn.
De ontwikkeling van herbruikbare artefacten staat haaks op het projectbelang, wat
binnen een bepaalde tijd, met een hoeveelheid geld een resultaat moet hebben. De
enige manier om dat belang te weerstaan is centrale sturing.
Eens, maar dat mag de voortgang niet teveel in de weg staan
Het moet wel een dialoog blijven ipv. eenrichtingsverkeer
Eens, maar die centrale groep moet wel dicht bij mij in de organisatie zitten (geen
ICD)
Ik vraag me af wat dit in de praktijk gaat betekenen. Als PL zul je altijd defensief gaan
reageren als iemand van buiten een project je iets gaat opleggen. Zal dus vooral in een
situatie werken waarin geruild kan worden.
Eens: Bij een decentrale sturing zullen projecten steeds het eigen belang voor zetten.
Alleen met centrale sturing kan een goede verzameling componenten worden
onderhouden en vernieuwd. De centrale groep moet wel het projectbelang minstens
net zo zwaar laten meewegen als het hergebruik belang.
Eens, want de projectleiders kunnen adviezen eenvoudig naast zich neer leggen.
Eens: als ieder project zelf bepaalt wat herbruikbaar wordt ontstaat er een wildgroei
van herbruikbare componenten
Eens, echter het moet wel in samenspraak gaan met de ontwikkelaars van de
componenten
Ik zou verwachten dat tijdens het maken van het ontwerp een architect moet kunnen
bepalen wat uit de repository kan worden gebruikt. Hier kunnen dan ook meteen
kansen voor nieuwe componenten worden geïdentificeerd. Het blijft vervolgens dan
een dialoog.
Response: Oneens
Opmerkingen:
-
-
Oneens: Stricte aansturing onderdrukt initiatieven en creativiteit, en leidt tot een
passieve houding. Gevolg: geen ontwikkeling van herbruikbare componenten, tenzij
expliciet opdracht daartoe gegeven.
Oneens. In theorie zou strikte aansturing kunnen werken, maar waarschijnlijk leidt het
tot veel problemen (projectbelangen tegenover 'TNO-belangen') en is advisering een
betere aanpak.
TNO-rapport
ERROR! REFERENCE SOURCE NOT FOUND.
I.2
Error! Reference source not found.
Bijlage I
-
-
Niet mee eens omdat wij een sterke projectorganisatie hebben.
De projecten moeten onderling de interface helder krijgen
Ik vind dat de projecten de eindverantwoordelijkheid hebben. Het zijn de projecten die
uitmaken of voor hen de kosten voor hergebruik redelijk zijn. Afdwingen kan leiden
tot te dure projecten.
Oneens, projectbelangen moeten altijd meegewogen worden en dit gebeurd
waarschijnlijk niet goed genoeg in strikte aansturing.
Aantal deelnemers
Stelling 2:
Eens
De hergebruikgroep beslist bij aanvang van een project welke
software artefacten er hergebruikt gaan worden, in overleg met
het betreffende projectteam.
3
Oneens
8
Response: Eens
Opmerkingen:
-
-
-
Eens: Als er een hergebruikstuurgroep is (bestaande uit software architecten?) dan zal
deze standaardisatie moeten kunnen bevorderen
Eens, zelfde verhaal als eerder. Moet een dialoog zijn waarin organisatiebelang en
projectbelang wordt meegenomen. Dit geldt ook weer voor de kosten (ruilen dus).
Verder moeten we commerciële doelstellingen niet uit het oog verliezen waardoor
sommige zaken wel en/of niet te verkopen zijn.
Wat ik nog wel even iets vind is dat ik deze rol eerder wil toedichten aan een systeem
architect dan aan een team buiten het project. Dat alle systeem architecten hier op een
of andere wijze del van uitmaken lijkt me dan wel weer logisch.
Eens. Ik stel me voor dat een (centrale) architect met kennis van de bestaande
artefacten meedenkt waar de kansen voor hergebruik liggen. Tevens kunnen er
afspraken gemaakt worden over potentieel nieuw te ontwikkelen artefacten. De
financiële gevolgen voor dit project zouden eigenlijk apart bekeken moeten worden.
Response: Oneens
Opmerkingen:
-
-
-
-
Oneens, want het is niet nodig. Hergebruik betekent lagere kosten en snellere
ontwikkeling: daar is toch iedereen voor.
Gedwongen winkelnering is vragen om vastlopen van het proces. Er moet een drive
zijn voor de centrale groep om de componenten marktconform te houden
Oneens, want sturing betekent tegenwerking.
Oneens, maar de centrale groep dient daarentegen heel duidelijk te maken wat er
mogelijk is en daar de middelen voor te hebben. Het projectteam moet
beargumenteren waarom geen gebruik wordt gemaakt.
Oneens, het projectteam/management is verantwoordelijk voor het project en de
keuzes die hierin worden gemaakt. Een hergebruikgroep kan hierin slechts een
adviserende rol spelen.
Oneens: Projectteam, verantwoordelijk voor het resultaat, moet zelf meest geschikte
oplossing kunnen bepalen. Hierbij moet natuurlijk wel goed gekeken worden naar al
beschikbare componenten. Kortom: advisering.
Wanneer er ook nog voordeel kleeft aan hergebruik (naast 'goed voor TNO') zou dit
goed kunnen werken.
Oneens, de hergebruikgroep moet een adviserende rol hebben. Het voordeel van
hergebruik moet hier "verkocht" worden.
Oneens, advisering is de beste manier, waarbij uiteindelijk de projectleider wel de
doorslag geeft. Als een projectleider van mening is dat de component niet goed
genoeg is voor zijn/haar project is dat prima.. blijkbaar wordt dan een betere
component ontwikkeld in dat project.
ERROR! REFERENCE SOURCE NOT FOUND.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
I.3
-
Oneens: het is wel nodig dat de hergebruikgroep de artefacten die hergebruikt kunnen
worden aanreikt, maar opleggen zorgt voor weerstand
Oneens, maar altijd dialoog.
Oneens: Advisering is beter. Bij de beslissing om componenten te hergebruiken wordt
ook het ontwerp van het project beïnvloed. De controle hierover moet altijd bij het
projectteam liggen, zij kunnen de voordelen van hergebruik afwegen tegen de te halen
doelstellingen.
Aantal deelnemers
Stelling 3:
Eens
Oneens
Maak individuele software engineers verantwoordelijk voor
het beheer en de ondersteuning van de herbruikbare
artefacten.
9
2
Response: Eens
Opmerkingen:
-
-
-
-
-
Eens: bevordert betrokkenheid, inzet en enthousiasme. Wel nadenken over de
middelen die je de SE'er ter beschikking stelt.
Eens, te veel rompslomp met aparte aanspreekpuntgroep. Individuele software
engineers kunnen gemakkelijk in projecten worden opgenomen en daarmee zijn de
kosten van aanpassingen/incorporeren ook meteen meegenomen.
Eens, dit zorgt voor de noodzakelijke afstemming tussen project en SE'er.
Eens, de individuele SEer ziet wat er met zijn/haar component gebeurt (over de
projecten heen) en kan gemakkelijk de voortgang, benodigde aanpassingen, etc.
overzien
Eens. Als een betrokken ontwikkelaar herbruikbare code onderhoud, beheert en
ondersteund, dan bevorderd dit de kwaliteit.
Eens: maar deze verantwoordelijke software engineers moeten sturing krijgen vanuit
de centrale hergebruik groep. De groep kan dan in geval van bv. afwezigheid een
ander inzetten om problemen op te lossen. Ook zal de groep een controle moeten
uitvoeren over het werk van de engineer.
Eens, al moet niet alle kennis over een component bij een persoon komen te liggen
Eens, als er maar een s/w engineer is die de totale regie over de component heeft
(Open source model).
Eens. Ga er van uit dat degene die de eerste draft heeft ontwikkeld het beste kan
schatten welke change-requests wenselijk zijn. Uiteraard zijn er meerdere
ontwikkelaars die hun suggestie posten.
Eens, zorgt voor minder rompslomp bij aanpassingen.
Response: Oneens
Opmerkingen:
-
-
Oneens, zo versplinter je het zicht weer op de componenten. Laat het beheer liggen bij
de groep die ook adviseert/dwingt.
Oneens, software die opgehangen is aan personen is een extra risico (beschikbaarheid,
nukken). Er moet een beheergroep komen die zich verantwoordelijk stelt voor de
componenten
Is een rol en niet zozeer een persoonsgebonden activiteit. Daarom al niet mee eens.
Echter wel een concreet POC benoemen om snel ondersteuning/ support te kunnen
bieden. Is dit eens of oneens?
verder punt is dat de POC's dan wel het grotere en bredere belang moeten kunnen
onderkennen. Ik zou verwachten dat dit dus per type component kan verschillen (grote
ingewikkelde veelgebruikte hebben een CCB, kleinere simpelere een individueel
persoon)
TNO-rapport
ERROR! REFERENCE SOURCE NOT FOUND.
I.4
Error! Reference source not found.
Bijlage I
Aantal deelnemers
Stelling 4:
Eens
Reserveer bij alle softwareprojecten een standaard-percentage van het
budget voor hergebruik om de projectoverschrijdende kosten van
hergebruik te financieren.
Oneens
5
6
Response: Eens
Opmerkingen:
-
-
-
-
Eens, maar wel een flexibel percentage wat afhangt van o.a. gebruik van bestaande
componenten.
Eens, denk aan een bepaald percentage van het voordeel dat ermee behaald wordt,
oftewel ontwikkelkosten minus integratiekosten.
Eens. Het klinkt hetzelfde als belasting. Niemand vindt het leuk, maar het is wel nodig
om project(individu) overschrijdende acties te bekostigen. Oppassen dat het geen
zwart gat wordt.
Eens. Projectoverschijdende kosten zullen projectoverschijndend betaald moeten
worden. Heb wel wat problemen met een vast percentage, daar zou wat meer
onderhandelingsruimte in moeten zitten.
Eens: Dit is de enige methode om te zorgen voor een stabiele financiele basis voor
hergebruik. Maar een vast percentage is misschien te hard. Wellicht is een minimum
percentage beter. Projecten die veel hergebruiken moeten dan meer betalen op basis
van bv. de hoeveelheid en grote van de componenten.
Eens: maar er moet dan ook betaald worden aan de projecten voor de gebouwde
herbruikbare componenten.
Response: Oneens
Opmerkingen:
-
-
-
-
-
-
Oneens, doet geen recht aan de verschillende soorten projecten waarin wel of niet
sprake is van hergebruik. Van de andere kant is het voor een PL dan wel extra
motiverend om nog iets terug te krijgen voor hetgeen hij toch al heeft betaald.
Oneens. Voor sommige projecten wellicht wel bruikbaar idee, maar wel afhankelijk
van budget en financieringsvorm. Beter: per project bekijken wat de beste oplossing
is, maar linksom of rechtsom moet het onderhoud natuurlijk wel gefinancierd worden.
Oneens: er zouden baten uit hergebruik berekend moeten worden en deze zouden
deels de pot in moeten. Hoe anders kan ons mgt. enthousiast worden/blijven over
hergebruik?
Oneens, de componenten zijn al ontwikkeld en hoeven dus niet meer te worden
gefinancierd. Wanneer deze kunnen worden hergebruikt is dit mooi meegenomen.
Ik zou zelf vooral voor pay for use zijn omdat je daarmee een eerlijkere prijsstelling
krijgt en ik zou willen meenemen dat je ook geld terugkrijgt voor de investering die je
evt. doet om juist nieuwe componenten op te leveren cq. bestaande componenten te
verbeteren.
Oneens, alleen projecten die gebruik maken van herbruikbare componenten dienen
een bedrag af te staan aan de beheerdergroep van herbruikbare s/w componenten. Dit
bedrag kan gebruikt worden voor beheer en bekostigen nieuwe herbruikbare
componenten.
Oneens. Andere projecten die 'jouw' componenten hergebruiken moeten betalen voor
incorporeren van component in hun project (als dit kosten met zich meebrengt) en ook
betalen voor aanpassingen (door direct de betrokken personen uren te laten schrijven
op het project). Als de component direct gebruikt kan worden, betalen andere
projecten dus niks. Soms heb je er voordeel van (als je kan hergebruiken) en soms zal
je zelf voor een herbruikbare component zorgen (en kost het je project geld).
ERROR! REFERENCE SOURCE NOT FOUND.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
J.1
Bijlage J
Financiële scenario’s hergebruik voor
M&S
In deze bijlage zijn de gehanteerde formules, uitleg, input en berekeningen te
vinden.
Te hanteren cijfers
Tabel 42 toont een overzicht van de kengetallen die in deze business case
gehanteerd worden. Tabel 43 toont een overzicht met de schattingen die zijn
gehanteerd.
Kengetal
Waarde
Softwareprojecten op jaarbasis
Fulltime software engineers
20 (zowel grote als kleine)
25 (1600 uur per jaar per medewerker)
(45 in totaal binnen M&S)
Uurtarief software engineer
100 EURO per uur (Integrale kostprijs)
Kosten van black box hergebruik 20%
Kosten van white box hergebruik 67%
Kosten herbruikbaar ontwikkelen 150%
Bron
TNO-D&V
TNO-D&V
TNO-D&V
Theorie § 3.3.4
Theorie § 3.3.4
Theorie § 3.3.4
Tabel 42 - Gehanteerde (harde) kengetallen in de 'hergebruik business case'.
Aspect
Toelichting
Kosten
onderhoud &
beheer
Dit zijn de kosten voor onderhoud en beheer, oftewel bugfixing en
CM + Versiebeheer. Binnen het EBF is dit circa 600 uur op
jaarbasis. Hier wordt er vanuit gegaan dat het afhankelijk is van
verzameling herbruikbare artefacten.
Kosten
Dit zijn de kosten die worden gemaakt bij de sturing van de
sturing
consumptie. De reviewprocedure en de tijd die software architecten
consumptie
kwijt zijn bij het meelopen binnen de projecten.
Dit zijn de kosten die worden gemaakt bij de sturing van de
Kosten
productie. De uren die de software architecten en engineers van de
sturing
hergebruikstuurgroep kwijt zijn bij het meekijken binnen de
productie
projecten en het opstellen en beoordelen van SRS’s en SDD’s.
Totale
Dit is het aantal ontwikkeluren van de totale verzameling
verzameling herbruikbare artefacten. Dit wordt o.a. gebruikt om de kosten voor
onderhoud en beheer te schatten.
Kosten
Benodigde tijd om de projecten te ondersteunen bij hergebruik.
ondersteuning Naarmate er meer ervaring ontstaat met de artefacten zal dit dalen.
Er wordt vanuit gegaan dat circa 50% van de projecten
ondersteuning nodig heeft. Afhankelijk van de mate van hergebruik
binnen een project wordt er 8 uur als gemiddelde tijd aangenomen.
Tabel 43 - Gehanteerde schattingen in de 'hergebruik business case'.
Schatting
10% op
jaarbasis van de
originele
ontwikkeluren.
16 uur
gemiddeld per
project
24 uur per
gemiddeld
project
10.000 uur
50% van 16 uur
is 8 uur
ondersteuning
per project.
ERROR! REFERENCE SOURCE NOT FOUND.
J.2
Bijlage J
Gehanteerde formules
Aspect
Identifier
Aantal software engineers
Kosten Black box hergebruik (%)
Kosten White box hergebruik (%)
Ontwikkeluren van de totale verzameling herbruikbare artefacten (uren)
Onderhoud herbruikbare artefacten (% van geïnvesteerde ontwikkeluren)
Overhead ratio voor kosten onderhoud bij white box hergebruik
Investering in ontwikkeling herbruikbare artefacten (% van aantal SE-uren)
Tarief software engineer (Euro’s per uur)
Aantal werkzame uren per software engineer ( uren op jaarbasis)
Hergebruikpercentage (percentage t.o.v. normale softwareontwikkeling)
Percentage black box hergebruik (percentage van totale hergebruik)
Percentage white box hergebruik (percentage van totale hergebruik)
Aantal projecten (op jaarbasis)
Kosten voor sturing consumptie (uren)
Kosten voor sturing productie (uren)
Kosten voor ondersteuning aan projecten (uren)
SE
KBB
KWB
TU
PO
OR
IHG
KSE
X2
X3
X4
X5
X6
X7
X8
X9
DCA
Deze besparing komt voor uit de besparing op black box hergebruik en de
besparing op white box hergebruik. De urenbesparing van beide opgeteld keer
het uurtarief van de software engineer vormt de besparing op de
ontwikkelkosten.
DCA = (SE*X2*X3*X4*(1-KBB) + SE*X2*X3*X5*(1-KWB))*KSE
Een voorbeeld:
DCA = (25*1600*30%*90%*(1-0,2) + 25*1600*30%*10%*(1-0,67))*100
DCA = (8640 + 396) * 100 = € 903.600
SCA
De besparing op het onderhoud wordt gevormd een percentage van de
bespaarde uren minus de onderhoudsuren van de gehele verzameling en een
overhead die afhankelijk is van de hoeveelheid hergebruik en de verhouding
tussen black box en white box hergebruik. Indien een project meer white box
hergebruik toepast zal het immers ook meer werk kosten om een fout op te
sporen en te verhelpen. De volgende ratio’s worden gehanteerd:
10% overhead voor BB:WB 90:10
30% overhead voor BB:WB 60:40
50% overhead voor BB:WB 30:70
Deze overhead ratio wordt aangeduid met OR
SCA = (((SE*X2*X3)*PO) – (TU*PO+(SE*X2*X3)*PO*OR))*KSE
ERROR! REFERENCE SOURCE NOT FOUND.
Afstudeerscriptie - Hergebruik van software artefacten bij TNO Defensie en Veiligheid
J.3
Een voorbeeld:
SCA = (25*1600*20%*10%– (10.000*10%+25*1600*20%*10%*10%))*100
SCA = (800 – (1.000 + 80)) * 100
SCA = € 28.000 negatief
Reuse Costs
De kosten voor hergebruik bestaan uit de ontwikkelingskosten voor nieuwe
herbruikbare software artefacten en de kosten van de activiteiten van de
hergebruikstuurgroep. De uren voor de activiteiten van de
hergebruikstuurgroep zijn redelijk ruim, zoals is te zien in Tabel 43.
Ontwikkelingsuren nieuwe herbruikbare artefacten
Sturingsuren productie per project
Sturingsuren consumptie per project
Ondersteuningsuren per project
+
Totaal aantal uren
Reuse Costs = ((SE*X2*IHG) + ((X7+X8+X9)*X6)) * KSE
Een voorbeeld:
Reuse Costs = ((25*1600*2,5%) + ((16 + 24 + 8)*20)) * 100
Reuse Costs = (1.000 + 960) * 100
Reuse Costs = € 196.000,Scenario 1 – 20% - 30% - 40% hergebruik op DCA en SCA
Black box - white box ratio = 90:10
DCA = (25*1600*20%*90%*(1-0,2) + 25*1600*20%*10%*(1-0,67))*100
DCA = 602.400
DCA = (25*1600*30%*90%*(1-0,2) + 25*1600*30%*10%*(1-0,67))*100
DCA = 903.600
DCA = (25*1600*40%*90%*(1-0,2) + 25*1600*40%*10%*(1-0,67))*100
DCA = 1.204.800
SCA = (25*1600*20%*10%– (10.000*10%+25*1600*20%*10%*10%))*100
SCA = -28.000
SCA = (25*1600*30%*10%– (10.000*10%+25*1600*20%*10%*10%))*100
SCA = 8.000
SCA = (25*1600*40%*10%– (10.000*10%+25*1600*20%*10%*10%))*100
SCA = 44.000
Scenario 2 – 90-10 / 60-40 / 30-70 ratio Black box en White box
Hergebruikpercentage is 30%
DCA = (25*1600*30%*90%*(1-0,2) + 25*1600*30%*10%*(1-0,67))*100
DCA = 903.600
ERROR! REFERENCE SOURCE NOT FOUND.
J.4
Bijlage J
DCA = (25*1600*30%*60%*(1-0,2) + 25*1600*30%*40%*(1-0,67))*100
DCA = 734.400
DCA = (25*1600*30%*30%*(1-0,2) + 25*1600*30%*70%*(1-0,67))*100
DCA = 525.600
SCA = (25*1600*30%*10%– (10.000*10%+25*1600*30%*10%*10%))*100
SCA = 8.000
SCA = (25*1600*30%*10%– (10.000*10%+25*1600*30%*10%*30%))*100
SCA = -16.000
SCA = (25*1600*30%*10%– (10.000*10%+25*1600*30%*10%*50%))*100
SCA = -40.000
Scenario 2 – Invloed investeringen op totale hergebruikkosten
Invloed van de investeringen in de ontwikkeling van nieuwe herbruikbare
software artefacten op de totale kosten.
Reuse Costs = ((25*1600*0%) + ((16 + 24 + 8)*20)) * 100
Reuse Costs = 96.000
Reuse Costs = ((25*1600*2,5%) + ((16 + 24 + 8)*20)) * 100
Reuse Costs = 196.000
Reuse Costs = ((25*1600*5%) + ((16 + 24 + 8)*20)) * 100
Reuse Costs = 296.000
Reuse Costs = ((25*1600*7,5%) + ((16 + 24 + 8)*20)) * 100
Reuse Costs = 396.000
Reuse Costs = ((25*1600*10%) + ((16 + 24 + 8)*20)) * 100
Reuse Costs = 496.000
Toelichting op het hergebruikpercentage
Een praktisch voorbeeld; stel dat er van de 20 projecten 5 zijn die een
daadwerkelijke besparing van 3500 manuren realiseren door de frameworks en
componenten van Kibowi MP of het EBF her te gebruiken. Stel dat er nog zo’n 5
projecten zijn die enkele herbruikbare artefacten hergebruiken en mogelijk ook het
framework maar hier een besparing door realiseren van circa 1000 uur. De overige
10 projecten zijn van dusdanige geringe omvang dat de besparing door hergebruik
circa 100 á 200 uur zou zijn. De gemiddelde besparing in uren per project is dan:
5×3500 + 5×1000 + 10×150
20
= 1200
En de totale besparing over de 20 projecten is circa 24.000 uur. Dit is echter
gemeten naar de geinvesteerde ontwikkeluren. Het is bekend dat het ontwikkelen
van herbruikbare software circa 150% van de normale inspanning, hier gerekend
als manuren, kost. De besparing is dus circa 24.000 / 1,5 = 16.000 manuren. Nu is
het niet zo dat alle herbruikbare artefacten volledig worden hergebruikt, het
resultaat zal mogelijk dus lager liggen. Maar het toont wel aan dat hergebruik een
flink resultaat realiseert.
ERROR! REFERENCE SOURCE NOT FOUND.
Distributielijst
1.
Universiteit Twente, Dhr. Th. J. G. Thiadens
2.
Universiteit Twente, Dhr. K.G. van den Berg
3.
Universiteit Twente, Dhr. T. Hartog
4.
Universiteit Twente, Bureau Onderwijs Zaken EWI
5.
Universiteit Twente, Secretariaat Software Engineering
6.
Archief TNO-FEL, in bruikleen aan Dhr. H.J. Borgers
7.
Archief TNO-FEL, in bruikleen aan Mevr. D. keus
Indien binnen de krijgsmacht extra exemplaren van dit rapport worden gewenst door personen of
instanties die niet op de verzendlijst voorkomen, dan dienen deze aangevraagd te worden bij het
betreffende Hoofd Wetenschappelijk Onderzoek of, indien het een K-opdracht betreft, bij de Directeur
Wetenschappelijk Onderzoek en Ontwikkeling.
*) Beperkt rapport (titelblad, managementuittreksel, RDP en distributielijst).