Hergebruik van software artefacten bij de ... · 2.0.0.0 16-06-2005 Tim Hartog Scriptie Hergebruik...

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

Afstudeercommissie: dr. mr. ir. Th.J.G. Thiadens Bedrijf Bestuur en Technologie dr. ir. K.G. van den Berg Elektrotechniek Wiskunde & Informatica ir. D. Keus TNO Defensie en veiligheid ir. H.J. Borgers TNO Defensie en veiligheid Den Haag, juni 2005 Technische Universiteit Twente Faculteit Informatica, BedrijfsInformatieTechnologie

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.

Hergebruik van software artefacten bij de kennisorganisatie TNO Defensie en Veiligheid

Tim Hartog


4

Management samenvatting

Aanleiding Deze scriptie bespreekt de toepassing van hergebruik van software binnen TNO-D&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 ontwikkelen 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.


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 BedrijfsInformatie-Technologie 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


7

Versiebeheer

De tabel hieronder geeft aan welke wijzigingen zijn gemaakt in dit document.

Versie Datum Auteur Wijziging 0.0.0.0 01-12-2004 Tim Hartog Eerste versie document. 0.0.1.0 14-12-2004 Tim Hartog Verwerking PVA versie 1.1 0.0.2.1 16-12-2004 Tim Hartog Invoeging theorie § 3.1 + 3.2 + 3.3 0.0.2.2 24-12-2004 Tim Hartog Feedback bespreking UT verwerkt 0.0.3.1 21-01-2005 Tim Hartog Invoeging theorie § 3.4 + 3.5 0.0.3.2 25-01-2005 Tim Hartog § 3.6 Best Practice Sodalia toegevoegd. 0.0.3.3 02-02-2005 Tim Hartog Verwerking feedback dhr. Van den Berg –

Interviewopzet + toevoeging § 3.6 Eliop 0.0.3.4 24-02-2005 Tim Hartog Feedback n.a.v. bijeenkomst 27-01-2005 verwerkt 0.1.0.0 27-02-2005 Tim Hartog § 3.7 toegevoegd, 1ste Concept Versie Theorie 0.1.1.0 28-03-2005 Tim Hartog § 3.8 Theoretisch raamwerk toegevoegd 0.1.2.0 04-04-2005 Tim Hartog Eerste opzet Huidige Situatie 0.2.0.0 28-04-2005 Tim Hartog Feedback n.a.v. bijeenkomst 12-04-2005 verwerkt 0.2.5.0 08-05-2005 Tim Hartog Algemene verbeteringen & correcties 0.3.0.0 24-05-2005 Tim Hartog Gewenste Situatie toegevoegd 1.0.0.0 25-05-2005 Tim Hartog 1ste Concept versie verslag 2.0.0.0 16-06-2005 Tim Hartog Scriptie Hergebruik van Software Artefacten


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


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


10

Lijst van gebruikte afkortingen ALSP Aggregate Level Simulation Protocol AMI Application of Metrics in Industry ASF Advanced Simulation Framework BOAI Beleidstudies, Operationele Analyse en Informatievoorziening BU Business Unit CBD Component-Based Software Development CCS Command Control & Simulatie CDE Collaborative Development Environment CMM Capability Maturity Model CORBA Common Object Request Broker Archicture COP Code of Practice COTS Commercial-Off-the-Shelf DIS Distributed Interactive Simulation D&V Defensie en Veiligheid EBF Electronic Battlespace Facility ELSTAR European Low-cost Simulators for Training of Armed Forces GQM Goal-Question-Metric HLA High Level Architecture IT/QA IT Quality Assurance ITEMS Interactive Tactical Environment Management System J-Roads Joint Research on Air Defence Simulation KL Koninklijke Landmacht KLU Koninklijke Luchtmacht KM Koninklijke Marine LOC Lines of Code M&S Modelling & Simulation MDA Model Driven Architectures MOSES Maritime Operations Simulation and Evaluation System MP Multi Platform NIH Not Invented Here ORB Operationele Research en Bedrijfsvoering PLF Platform Framework RCM Reuse Capability Model RSO Reuse Support Organization RTG Reuse Task Group RTI Runtime Infrastructure RCI Runtime Communication Infrastructure SALMS Sodalia’s Asset Library Management System SDD Software Design Description SE Software Engineering SEI Software Engineering Institute SF SourceForge SPC Software Productivity Consortium SRS Software Requirements Specification


11

SSDD System Subsystem Design Description SSS System Subsystem Specification TBM Terrein Bewerking Module TNO Nederlandse Organisatie voor toegepast-natuurwetenschappelijk

onderzoek TNO-D&V TNO Defensie en Veiligheid TNO-FEL TNO Fysisch en Elektronisch Laboratorium TSA TNO Simulation Architecture TOPICS Tactical Operations in Confined and Shallow waters UML Unified Modeling Language VVA Verificatie Validatie en Accreditatie


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


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


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).

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.

TNO

Kwaliteit van het leven

Defensie en Veiligheid

Industrie en Techniek

Bouw en Ondergrond

Informatie- en communicatietechnologie

Waarnemings-systemen

Beleidsstudies Operationele Analyse en Informatie-voorziening

Bescherming, Munitie en

Wapens

Biologische en Chemische

Bescherming

Gedrag, Training en

Prestatie

Operationele Analyse

Command Control en Informatievoorziening

Modelling & Simulation

Beleid en Strategie


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 softwareontwikkel-proces, 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.


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.


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?


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.

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.

Theorie Hergebruik

Theoretisch Model

voor Hergebruik

b c a

Huidige Situatie

M&S

Artefacten

Processen

Organisatie

Aanbevelingen

en conclusies

Artefacten

Processen

Organisatie

Metrics

Gewenste Situatie

M&S

Artefacten

Processen

Organisatie

d

Best Practices


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, verantwoordelijk-heden, 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.


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 TNO-D&V zelf kan onderzoeken.


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”

[BAS97]

“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”

[MIL02]

“Futher use or repeated use of an artifact, typically software artifacts are designed for use outside of their original context to create new systems”

[JAC97]

“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.”

[DUS95]

“Software reuse, the use of existing software artifacts or knowledge to create new software”

[FRA96]

“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”

[MOR02]

Tabel 1 - Definities uit de literatuur van ‘Software Reuse'


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.


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.


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.


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 herge-bruik 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].


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


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 projecten 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.


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.


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.


30

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 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.

Historie Beschrijft de evolutie van het artefact. Tevens wordt er aandacht besteedt aan situaties waarin dit artefact eerder is hergebruikt.

Functionele specificatie Beschrijft de inputs, outputs en aangeboden functionaliteit van het artefact in detail.

Interfaces Beschrijft de aangeboden en gewenste interfaces van het artefact.

Certificatie 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,

Legenda relatie aggregatie

specialisatie


31

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.

Installatie handleiding 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].

Beperkingen Beschrijft alle zaken die de ontwikkelaar beperken. Denk hierbij aan interface beperkingen, de benodigde hardware en software.

Aanpasbaarheid 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 Beschrijft de omgeving waarin het artefact is getest, welke data

hiervoor is gebruikt, eventuele test cases en methoden en de resultaten.

Ondersteuning 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 Zie http://java.sun.com/docs/codeconv/ 5 Zie http://www.doc.ic.ac.uk/lab/cplus/c++.rules/


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.


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.


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).


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.

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.

Artefact v1.0 Artefact v1.2

Artefact v1.1.1

Artefact v1.1.2

Artefact v1.3.1

Artefact v1.3.2

Artefact v1.3.3

Artefact v1.1

Artefact v1.3


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): Het artefact dat binnen een applicatie een bepaalde functie

vervuld en daarvoor een bepaalde service wenst van een ander artefact.

Leverancier (server): Het artefact dat aangeroepen wordt via één van zijn methode om een bepaalde service te leveren.

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’.

Scenario 1 Scenario 2

Gebruiker Leverancier

Wrapper Scenario 3


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].


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.

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 modelleringsvaardig-heden 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].

View Controller

Model

Update Display

Application calls Notifications State data

User input


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.

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.

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

Consumptie Selecteren, analyseren, modificeren, integreren Producten

Product requirements en bestaande software

Technologische ontwikkelingen,

toekomstige klantwensen en lopende projecten


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. Pre-Project In-Project Post-Project A priori Domain analysis

1. Pre-project domain analysis

2. In-project domain analysis

A posterioiri Generalization

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.


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.


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.


43

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].

Artefact v1.0

Artefact v1.1

Artefact v2.0

Artefact v1.2

Artefact v2.1

Artefact v3.0

Artefact v2.2


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.


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.


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].


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.

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? Planning Wordt er structureel rekening gehouden met hergebruik? Of is het puur toeval dat het

gebeurt? Betrokkenheid Wordt hergebruik alleen door individuele software engineers uitgevoerd, gebeurt het

over afdelingen of is het bedrijfswijd? Driver Wie zorgen ervoor dat hergebruik plaatsvindt? Zijn dit ontwikkelaars, een werkgroep of

is er ook vanuit het management betrokkenheid? Proces Waar komt hergebruik het proces in en in hoeverre zijn de processen gestandaardiseerd? Inventaris In hoeverre is de verzameling gestructureerd? Helemaal niet of langs productlijnen of

wordt er zelfs op basis van missende delen in de inventaris ontwikkeld? Classificatie In welke mate is de verzameling gestructureerd en geclassificeerd? Technologische ondersteuning

In hoeverre wordt hergebruik ondersteund d.m.v. tools? Helemaal niet, via enkele tools of is er een electronische bibliotheek beschikbaar?

Metingen In welke mate wordt hergebruik gekwantificeerd? Helemaal niet of zeer drastisch om de impact van hergebruik te volgen en daarop te sturen?

Contractuele en verrekenings-overwegingen

Vormen rechtsmatige, contractuele of financiële aspecten een drempel om te hergebruiken of zijn er hier oplossingen voor ontwikkeld m.b.t. hergebruik?

Tabel 5 - Dimensies van volwassenheid van het Reuse Maturity Framework.

CMM Stage Initial Repeatable Defined Managed Optimized

Reuse Management Stage Ad-Hoc Coordinated Planned


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.


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.


50

Manieren van Sturing

Directief 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.

Rationeel-empirische strategie

Bij deze strategie worden mensen via rationele communicatie en voorlichting ertoe bewogen de veranderingen of werkzaamheden te accepteren.

Normatief-reëducatieve strategie

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.

Facilitaire strategie

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.


51

Sturing Rol hergebruikmanager Proces Niveau 1 Geen N.v.t. Niet gedefinieerd. Niveau 2

Sturing op mensen Rol toegekend Proces is gedefinieerd per project of domein

Niveau 3

Sturing op proces Verantwoordelijk voor proces Afstemming tussen projecten en domeinen

Niveau 4

Sturing op basis van resultaten en alignment

Verantwoordelijk voor resultaten

Geïntegreerd proces centraal gecoördineerd

Niveau 5

Sturing op continue verbetering

Initieert innovaties en verbeteringen

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.


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.

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.

Management

Productie Ondersteuning Consumptie


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.

Figuur 11 - Lone Producer structuur [FAF94][MIL02].

Afwegingen bij de Lone Producer structuur Voordelen - 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. Nadelen - 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.

Project Team A

Project Team B

Lone producer

Project Manager

Project Manager

Level 2 Manager

Legenda

Primaire lijn van verantwoording Secundaire lijn van verantwoording


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.

Figuur 12 - Nested Producer structuur [FAF94][MIL02].

Afwegingen bij de Nested Producer structuur Voordelen - 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.

Nadelen - Dubbele verantwoording, de ‘nested producer’ moet zowel aan de

Nested Producer A

Nested Producer B

Project Team A

Project Team B

Project Manager

Project Manager

Level 2 Manager

Hergebruikmanager


55

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 ‘nested-producers’ met alle herbruikbare artefacten bekend te laten worden.

Aanbevelingen - 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.

Figuur 13 - Pool Producer structuur [FAF94][MIL02].

Project Team A

Project Team B

Project Manager

Project Manager

Level 2 Manager

Project Team C

Project Manager

Project Team D

Project Manager

Pool Producers


56

Afwegingen bij de Pool Producer structuur Voordelen - Geen veranderingen in de organisatiestructuur nodig.

- Kosten en baten voor hergebruik worden op een natuurlijke wijze verrekend binnen de projecten.

Nadelen - 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.

Aanbevelingen - 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.


57

Figuur 14 - Team Producer structuur [FAF94][MIL02].

Afwegingen bij de Pool Producer structuur Voordelen - 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.

Nadelen - 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. Aanbevelingen - 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.

Project Team A

Project Team B

Project Manager

Project Manager

Level 2 Manager

Team Producenten

Hergebruik Manager


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.


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.


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.


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.

Figuur 15 - Verschillende fasen volgens de AMI methode [PUL96].

Asses

Analyse

Metricate

Improve

Environment Management Objectives

Current Practices Customer Requirements

Reference to Goals

Primary Goals

Metrics Specification

Measurement Data

Reference to Assessment

Resources Processes Products


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 ad-hoc 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.


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

Hergebruik- manager

Er is geen inzicht in de mate waarin er hergebruikt wordt.

2 Evalueren De kosten Herbruikbare artefacten

Projectmanager 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’.

Figuur 16 - Goaltree voor de intensiteit van hergebruik

Het evalueren van de intensiteit van hergebruik binnen een organisatie

In welke mate wordt de repository gebruikt?

Goal:

Questions:

Metrics: 1. Aantal herbruikbare artefacten in de repository

2. Aantal hits per periode (geen downloads)

3. Aantal downloads van herbruikbare artefacten per periode

4. Aantal mislukte zoekpogingen per periode

5. Cumulatief aantal malen hergebruik per artefact

6. Cumulatief aantal malen hergebruik van alle artefacten

In welke mate wordt er gebruik gemaakt van de beschikbare

herbruikbare artefacten?

1. Percentage nieuwe code 2. Percentage onaangepaste

herbruikbare code 3. Percentage aangepaste

herbruikbare code


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].

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.

Het evalueren van de netto kosten van hergebruik voor een project

Wat zijn de financiële baten van hergebruik van software?

Goal:

Questions:

Metrics: 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. Kosten voor kosten/baten analyse 2. Kosten voor zoeken 3. Kosten voor bestuderen 4. Kosten voor integreren 5. Kosten voor modificeren 6. Kosten voor testen 7. Kosten voor ondersteuning bij

gebruik van de herbruikbare artefacten

8. Kosten voor onderhoud van aangepaste herbruikbare artefacten


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 Kosten besparing bij het ontwikkelen van software Definitie 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


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.

A2 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


67

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.

A3 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.

A4 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.

A5 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.

A6 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.

B1 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.

B2 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].

B3 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


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

1 2 3 4 5 6 7

B2 30 32 31 28 35 30 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


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.


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 Toelichting Artefacten

Type artefacten Wat voor type artefacten worden er daadwerkelijk hergebruikt? - Requirements - Ontwerpen - Broncode - Componenten - Architectuur - Frameworks - Testdata & plannen - Documentatie - Anders

Manier van gebruik Wat is het beoogde gebruik van de herbruikbare artefacten? - Black box - White box

Documentatie Is er begeleidende documentatie bij het herbruikbare artefact? - Ja (beschrijf wat de documentatie omvat) - Nee

Intensiteit van hergebruik

Wat is de intensiteit van hergebruik? - Horizontale artefacten - Verticale artefacten - Applicatie frameworks

Processen Moment van productie Op welk moment worden de herbruikbare artefacten geproduceerd?

- Pre-project - In-project - Post-project

Manier van productie Op welke manier worden de herbruikbare artefacten verkregen? - Domein engineering - Re-engineering


71

- Verkregen via externe partij Ondersteuning 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 Configuratie Management

Is er iemand die het configuratie management van het herbruikbare artefact uitvoert?

- Ja - Nee

Problem & Change Management

Is er iemand die het problem & change management van het herbruikbare artefact uitvoert?

- Ja - Nee

Certificatie Hoe worden de herbruikbare artefacten gecertificeerd? - Niet - Informeel, op basis van bijvoorbeeld gebruikerservaringen

en aantal malen hergebruik - Formeel

Sturing Productie Hoe wordt de productie van herbruikbare artefacten gestuurd? - Geen sturing - Adviserende en faciliterende sturing - Dwingende sturing

Sturing Consumptie Hoe wordt de consumptie van herbruikbare artefacten gestuurd? - Geen sturing - Adviserende en faciliterende sturing - Dwingende sturing

Metingen 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

Is er een aanspreekpunt en verantwoordelijke voor de ondersteuning bij de herbruikbare artefacten aangewezen?

- Nee - Informeel - Formeel

Verantwoordelijkheid voor het beheren van herbruikbare artefacten

Is er iemand verantwoordelijk voor taken zoals onderhoud, configuratiemanangement en change en problem management?

- Nee - Informeel - Formeel

Sturing Productie Is er een organisatie eenheid ingericht voor de coördinatie van de


72

productie van herbruikbare artefacten? - Ja - Nee

Sturing Consumptie Is er een organisatie eenheid ingericht voor de coördinatie van de consumptie van herbruikbare artefacten?

- Ja - Nee

Niveau van sturing 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

Top Management Commitment

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)

Voorschriften Zijn er voorschriften voor hergebruik specifieke activiteiten? - Ja (beschrijf welke voorschriften dit zijn) - Nee

Inrichting Productie Hoe is de productie van het herbruikbare artefact georganiseerd? - Geïntegreerd in de projecten - Losstaande eenheid

Inrichting Ondersteuning

Hoe is de ondersteuning van het herbruikbare artefact georganiseerd?

- Niet georganiseerd - Losstaande eenheid

Financiering productie 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 Financiering beheer 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. Financiering ondersteuning

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


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.


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 Sodalia Eliop Artefacten

Type artefacten Domein modellen, applicatie frameworks (rond 10.000 functie punten), libraries en componenten

Broncode, specificaties en ontwerpmodellen, testprocedures

Manier van gebruik Hoofdzakelijk black box White box hergebruik

Documentatie Ontwerp- en testdocumentatie, gebruikershandleidingen

Onbekend welke documentatie.

Intensiteit van hergebruik

Applicatie Frameworks met algemene en domein specifieke componenten

Hergebruik van algemene en domein specifieke artefacten

Processen Moment van productie Pre-project & In-project In-project, next-project

Manier van productie Domein Engineering Domein Engineering & Reengineering

Ondersteuning Ja Nee, wel training software engineers in hergebruik technieken.

Configuratie Ja Nee


75

Management Problem & Change Management

Ja Nee

Certificatie Formeel via audits (en validatie en verificatie)

Geen (wel validatie voordat herbruikbare artefacten worden toegevoegd aan repository)

Sturing Productie Dwingende sturing Dwingende sturing

Sturing Consumptie Faciliterende en adviserende sturing Faciliterende en adviserende sturing / dwingende sturing.

Metingen Enkele repository metingen (aantal malen hergebruik per artefact)

Mate van hergebruik, kosten herbruikbare artefacten en kwaliteit herbruikbare artefacten

Organisatie Verantwoordelijkheid voor ondersteuning bij herbruikbare artefacten

Formeel via Reuse Support Organization (RSO)

Informeel via hergebruik specialisten.

Verantwoordelijkheid voor het beheren van herbruikbare artefacten

Formeel via Reuse Support Organization (RSO)

Reuse Task Group (RTG). Bestaat uit Reuse Manager en Projectmanagers.

Sturing Productie Ja (RSO) Ja (RTG) Sturing Consumptie Ja (RSO) Ja (RTG) Niveau van sturing Centraal, geïntegreerd proces over

projecten en domeinen Per project/domein afzonderlijk

Top Management Commitment

Ja, hergebruik is opgestart en opgelegd door het top management.

Ja, systematisch hergebruik initiatief is ook opgestart vanuit management.

Voorschriften Ja, voor de verschillende processen met inachtneming van hergebruik.

Ja, coding standards en documenttemplates (voor standaardisatie van herbruikbare artefacten)

Inrichting Productie Losstaande eenheid (RSO) + soms in projecten

Losstaande eenheid (RTG) + in projecten


Losstaande eenheid (RSO) Geen

Financiering productie Indirecte verrekening (apart budget) Niet bekend Financiering beheer Indirecte verrekening (apart budget) Niet bekend Financiering ondersteuning

Directe verrekening Niet bekend

Repository 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


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.


77

- 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.

Eliop

- Standaardisatie van herbruikbare artefacten doormiddel van programmeer-standaarden 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.


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.


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.

Figuur 18 - Stakeholders bij hergebruik van software artefacten

Hergebruik van software artefacten

Software Engineers

Klanten (extern)

Management Project Leiders


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 Intern/extern Extreem Operationeel Intern/extern Hoog Onderzoeksmodel Intern Goed Prototype Intern/extern Matig Tools Intern Gemiddeld

Tabel 18 - Overzicht type systemen, klanten en benodigde kwaliteit [TNO03].


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.

Othello Optimalisatietool voor 11de Lucht Mobiele Bridage (11LMB) om op bataljon niveau helicoptervluchten te plannen.

Kibowi MP 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 Moses levert een framework voor de ontwikkeling van applicaties en modellen voor ‘underwater warfare’. Dit kan variëren van ‘Anti-Submarine Warfare’, ‘Mine Countermeasures’, ‘Torpedo Defence Systems’ tot onbemande onderwater voertuigen.

Topics Simulatie model voor ‘anti submarine warfare’.

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.

Figuur 19 - Algemene Projectstructuur binnen BU2.

Project A

- Projectleider - Software Engineers

Project B

- Projectleider - Software Engineers

Project C

- Projectleider - Technisch projectleider - Software Engineers

Technologietrekker

Resource Mananager / Afdelingshoofd

Mananager


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.


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.

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 Artefact

Bron Functionaliteit Ontwikkeluren

Database Store + Manager

Kibowi IDM

Component voor storages & retrieval van data uit de databases. 750 uur

Hergebruikgroep

2003 2004 2005

Workshops SE’rs

Source Forge

1ste Stagiair Source Forge voor hergebruik

Stagiair Tim Hartog

Hergebruik zichtbaarder

Tijd


84

Statemachine Kibowi 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.

150 uur

CSE (Computer Simulation Environment)

Kibowi Een framework voor simulatiemodellen. Vormt een schil over de diverse herbruikbare Kibowi MP componenten (generieke GUI, generieke applicatie, database manager etc.).

400 uur

Monitor Kibowi 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.

200 uur

TNO Mailserver Kibowi IDM

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.

400 uur

ORB kernel Searoads 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.

500 uur

TBM Kibowi Tool die kan worden gebruikt om terreinen te ontwikkelen of importeren uit bestanden.

1200 á 1400 uur

ORBAT Browser

EBF 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).

Onbekend

ASF (Advanced Simulation Framework)

EBF 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.

Onbekend

PLF (Platform Framework)

EBF 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)

Onbekend

Stealth EBF Component die het mogelijk maakt om vanuit verschillende viewpoints in een synthetische omgeving mee te kijken.

Onbekend

Visual EBF 3D module voor de visualisering van de omgeving (oppervlak, hoogte, sculpturen) en entiteiten in deze omgeving.

Onbekend

VR-Link EBF Toolkit inclusief 3D Stealth, Packet Server en Datalogger. Deze toolkit biedt ondersteuning voor de ontwikkeling van DIS 2.0.4 compliant applications.

Onbekend

Doelmodellen EBF Real-Time geometrische modellen Onbekend Terreindatabases EBF Er zijn een aantal terreindatabases beschikbaar Onbekend EBF SimCore EBF 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.)

Onbekend

TSA (TNO Simulation Architecture)

EBF 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,

Onbekend


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 Ontwikkelomgeving voor het visualiseren van infanterie. http://www.bdi.com/content/sec.php?section=diguy

N.V.T.

STK COTS Commercieel pakket voor 3D visualisatie voor bijvoorbeeld satelliet- of raketbanen. http://www.agi.com/products/desktopApp/stkFamily/

N.V.T.

LuciadMap COTS Geografisch Informatie Systeem (2D) (library) N.V.T. Visual OMT COTS Visual editor voor het maken van HLA Object Model Templates N.V.T. ITEMS

COTS Tool voor het generen Computer Generated Forces in een taktische omgeving. ITEMS biedt tevens de mogelijkheid om via DIS met andere simulatiefaciliteiten te interacteren.

N.V.T.

CASLOGGER COTS After Action Module. Slaat enkele de informatie die over het DIS-netwerk wordt verstuurd op zodat het later met een andere applicatie teruggespeeld kan worden.

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


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


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.

Figuur 21 - Productie van herbruikbare artefacten binnen BU2 van TNO-D&V.

Tijdslijn

Ontwikkelen code/componenten

Project - A

Re-engineren beschikbaar component t.b.v. herbruikbaarheid

Project - B

Re-engineren code/component uit ander

project t.b.v. herbruikbaarheid en

toepasbaarheid in project B

Herbruikbaar Artefact Herbruikbaar Artefact


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.


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


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.


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/


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 TNO-FEL 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.

Planning for reuse

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.

Breadth of reuse involvement

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.

Responsibility for making reuse happen

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.

Process by which reuse is leveraged

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.

Reuse inventory SourceForge biedt momenteel nog geen classificatiemogelijkheden. De projecten voor herbruikbare artefacten staan dan ook tussen de reguliere softwareprojecten. Er is geen structuur aanwezig.

Classification activity

Niet aanwezig.

Technology support

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.

Metrics Niet aanwezig. Legal, contractual, accounting consideration

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.


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].

Figuur 22 - Typische architectuur van een simulatie-model [WIT02].

GUI Verzorgt de interactie met de gebruikers. RunController Stuurt één of meerdere simulatie-runs aan Parser Leest de simulatie-file in. Kernel Stuurt de simulatie aan (dit is het hart van de simulatie). Model Bevat de simulatie-objecten. Externe Observers 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/

Parser RunControllerKernelExternal Observers Input File

GUI

Output File

Model


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.


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/the_command_and_staff_tra/


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.

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

Mail* State Machine*

Monitor* Expressions*

ORB Kernel* Helpers*

Versioning*

TNO System API’s

Generic GUI* Database Management*

Generic Application*

Coordinates

*

GLF

GIS*

Graph

Computer Simulation

Environment

Kibowi Application Kibowi GUI*

Database definitions Messages

Permissions

ModelParameters Events

Phoenix

Control Entity Editor Observer Otas Editor Administrator EvaluatorApplicaties

De componenten uit deze twee lagen zijn

applicatie onafhankelijk. De

componenten met een * zijn als black box

hergebruikt in SCOPE.

Het component uit deze laag met een * is

als white box hergebruikt in SCOPE.


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


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


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.

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

Simulator Application

Advanced Simulation Framework (ASF)

Platform Framework

(PLF)

Audio 3D Visual

I/O Support


100

bruggen. De Environment bevat ook de events die worden uitgewisseld tussen de objecten en applicaties. De ObjectServer is verantwoordelijk voor de uitwisseling van objecten event informatie met andere ObjectServer instanties en voorziet de Environment met up-to-date informatie over de gevechtsomgeving.

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.

Application

Environment

ObjectServer

DIS ObjectServer HLA ObjectServer

HLA/RTI Compliant DIS compliant Network

User defined simulation model

Advanced Simulation Framework


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-


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.


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.

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.

EBF Management

Gebruikersgroep TNO-FEL

Gebruikersgroep Krijgsmacht

EBF Kwaliteitszorg

EBF Beheer

EBF Ontwikkeling


104

CASES KENMERKEN

ORB Kernel

KIBOWI MP

EBF

Artefacten Type artefact(en) Component Architectuur,

componenten en broncode

Architectuur en componenten

Manier van gebruik Black Box Black Box & White Box Hoofdzakelijk Black Box Documentatie Gebruikers handleiding

& Javadoc Javadoc Interface beschrijvingen,

gebruikershandleidingen Intensiteit van hergebruik

Domein specifiek artefact

Applicatie framework met algemene componenten

Applicatie framework met algemene en domein specifieke componenten

Processen Moment van productie Pre-project & In-project In-project In-project Manier van productie Domein Kennis +

Re-engineering Domein Kennis + Re-engineering

Domein Kennis + Re-engineering

Ondersteuning Informele ondersteuning via informeel verantwoordelijke

Informeel ondersteuning via de maker van het herbruikbare artefact

Formeel ondersteuning vanuit EBF-team

Configuratie Management

Ja Ja (binnen KIBOWI) Ja

Problem & Change Management

Ja Ja (binnen KIBOWI) Ja

Certificatie Geen certificatie Geen certificatie Verificatie Sturing Productie N.V.T. Geen sturing Faciliterend/adviserende

rol van het EBF-team Sturing Consumptie Informeel

faciliterend/adviserend Geen sturing Faciliterend/adviserende

rol van het EBF-team Metingen Geen metingen Geen metingen Geen metingen Organisatie Verantwoordelijkheid ondersteuning bij herbruikbaar artefact

Informeel Nee EBF-Team

Verantwoordelijkheid beheer herbruikbaar artefact

Informeel Nee EBF-Team

Sturing Productie Nee Nee EBF-Team Sturing Consumptie Nee Nee EBF-Team Niveau van sturing Per project afzonderlijk

door software engineer Geen sturing aanwezig Afstemming tussen

projecten door EBF-Team Top Management commitment

Nee Nee Nee

Voorschriften Geen Geen EBF-beheersvoorschriften Inrichting Productie N.v.t. Geïntegreerd in project Geïntegreerd in projecten

+ EBF team


105


Niet formeel aanwezig Niet formeel aanwezig Formeel aanwezig binnen EBF team

Financiering productie Indirecte verrekening Geen Indirecte verrekening Financiering beheer Directe verrekening Geen Indirecte verrekening Financiering ondersteuning

Directe verrekening Directe verrekening Directe verrekening

Repository 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 TNO-D&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


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.


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.

Figuur 28 - Indicatie van de resultaten per case studie.

Resultaat in ontwikkeluren

4000

3000

2000

1000

ORB

ORB

Cumu-latieve

besparing

Kibowi MP

Ontwikkel

uren

Kibowi MP

Framework &

Compo-nenten

Cumulatieve

besparing (geheel 1x +

enkele componenten

in 5 projecten)

EBF

Ontwikkeluren

EBF

Framework &

Compo-nenten

Cumulatieve

besparing

(reeds vele malen

hergebruikt)

5000

Case studies


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.


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,


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.


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


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 navigatie

Dit betreft simulators voor training van taken die betrekking hebben op transportfuncties ter land, zee of in de lucht.

Doelopsporings-simulators

Dit betreft simulators voor training van taken die betrekking hebben op verkenning en het verzamelen en overbrengen van informatie over doelen, schade aan objecten en andere tactische of strategische informatie.

Bedienings- en schiet-technische simulators

Dit betreft simulators voor training van taken die betrekking hebben op doelacquisitie en doelbestrijding ter land, ter zee en in de lucht.

Tactische proceduretrainers en staftrainers

Dit betreft simulators voor training van taken die betrekking hebben op Command en Control vanaf individuele platforms tot op divisie niveau. Het betreft de planning, 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.


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].


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

- Naam van het artefact - Keywords voor de categorie van het artefact - Bron van het artefact (intern / extern) - Beschrijving van het artefact

Software User Manual (SUM)

Historie Beschrijft de wijzigingen per versie vanaf de eerste versie die gereleased is.

Software User Manual

Interfaces Beschrijft de aangeboden en gewenste interfaces van het artefact. Bij javacode of componenten kan hiervoor gebruik worden gemaakt van Javadoc.

Javadoc & Interface Design Description(IDD)

Certificatie Beschrijft aan welke eisen dit artefact is getoetst en voor welke situaties/context het ontwikkeld is.

Apart document in SourceForge of extra in SUM.

Gedetailleerde Informatie Technische details 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.

Installatie handleiding

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].

Beperkingen 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.

Aanpasbaarheid Beschrijft hoe dit artefact aangepast kan worden. In geval van black box beschrijft dit bijvoorbeeld hoe het artefact via parameterisatie



115

afgesteld kan worden of waar de expliciete extentiepunten zitten. Overige Informatie Testen Beschrijft hoe dit artefact is getest. Hierbij kan verwezen worden

naar de STD, STP en STR documenten. Software User Manual

Ondersteuning Beschrijft de procedure betreffende de ondersteuning bij dit artefact. Aanspreekpunt voor bugs, change requests of ondersteuning bij gebruik.


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.


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.


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.


118

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

Projectteams Hergebruikstuurgroep

SourceForge - Opslag - Beheer

Beheer & evolutie

Certificatie Artefacten

Support voor de

Projectteams

Sturing productie en consumptie

- Zoeken & downloaden herbruikbare artefacten.

- Doorgeven bugs & change Requests

- Opslag herbruikbare artefacten in SourceForge na goedkeuring

- Onderhoud en beheer herbruikbare artefacten

Hulp bij ontwikkelen van en met herbruikbare artefacten

Herbruikbare artefacten

Ontwikkelen van herbruikbare artefacten

Ontwikkelen met herbruikbare artefacten

Sturing en coördinatie hergebruik activiteiten


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.


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.


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.


122

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

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.

Analysis

Design

Implementation

Testing

Maintenance

Keuze voor de herbruikbare artefacten zoals een statemachine, monitor etc. Keuze door

projectteam

Keuze voor grotere herbruikbare artefacten zoals architecturen een TBM of een framework. Keuze genomen door

projectleider i.s.m. hergebruikstuurgroep

Keuze voor de kleine herbruikbare artefacten zoals open source tools, javabeans of libraries en kleine componenten uit eerdere projecten.

Keuze genomen door individuele ontwikkelaar Tijdlijn

Offertetraject

Tijd / fase in het softwareontwikkelproces

Mogelijke voordelen bij de keuze voor hergebruik van

software

Inzicht in de applicatie en mogelijkheden voor hergebruik


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.

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)

Prijs

Kleine projecten Functionaliteit

Grote projecten Functionaliteit

Prijs

Gelijkblijvende prijs meer functionaliteit

Gelijkblijvende functionaliteit lagere

prijs

Zonder hergebruikMet hergebruik


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


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


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


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


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


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


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,


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 re-use 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,


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.


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

Dit omvat zowel de kosten voor het analyseren, ontwerpen, ontwikkelen, testen en documenteren van herbruikbare artefacten.

Onderhoudskosten van de als white box hergebruikte 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.

Kosten voor het testen van aangepaste herbruikbare artefacten

Dit zijn de kosten die een project moet maken voor het testen van herbruikbare artefacten die zijn aangepast (white box).

Kosten/baten analyse per herbruikbaar artefact

Kosten voor het maken van een kosten/baten analyse bij de keuze om een herbruikbaar artefact te ontwikkelen of her te gebruiken.

Kosten voor het zoeken en verkrijgen van herbruikbare artefacten

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 herbruikbare artefacten

Kosten voor het integreren van het herbruikbare artefact in de nieuwe applicatie.

Kosten voor het updaten van hergebruikte artefacten in het geval van een nieuwe versie

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.


134

Kosten hergebruikstuurgroep

Toelichting

Verkenning van mogelijkheden voor de ontwikkeling van 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.

Sturing van de projectteams Kosten voor het sturen van de projectteams betreffende de ontwikkeling van herbruikbare artefacten.

Advisering van de projectteams Kosten voor het adviseren van de projectteams betreffende het hergebruiken van herbruikbare artefacten (reviewprocedure).

Certificering van ontwikkelde herbruikbare artefacten

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.

Onderhoud van de herbruikbare artefacten

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.

Uitvoeren van change requests Kosten voor het aanpassen en uitbreiden van het herbruikbare artefact op verzoek van een projectteam.

Advisering en ondersteuning aan de projectteams

Kosten voor het adviseren en ondersteunen van de projectteams over het hergebruiken van een specifiek herbruikbaar artefact.

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


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 Kostendrager Projectteams Ontwikkelingskosten van de herbruikbare artefacten De hergebruikstuurgroep Onderhoudskosten door white box hergebruik Het project Kosten voor het testen van aangepaste herbruikbare artefacten Het project Kosten/baten analyse per herbruikbaar artefact Het project Kosten voor het zoeken en verkrijgen van herbruikbare artefacten Het project Kosten voor het integreren van herbruikbare artefacten Het project Kosten voor het updaten van hergebruikte artefacten in het geval van een nieuwe versie

Het project

hergebruikstuurgroep Sturing van de projectteams De hergebruikstuurgroep Advisering van de projectteams De hergebruikstuurgroep Verkenning van mogelijkheden voor de ontwikkeling van herbruikbare artefacten

De hergebruikstuurgroep

Certificering van ontwikkelde herbruikbare artefacten De hergebruikstuurgroep Artefactverantwoordelijke Beheren van het herbruikbare artefact in SourceForge De hergebruikstuurgroep Onderhoud van de herbruikbare artefacten De hergebruikstuurgroep Behandelen van change requests De hergebruikstuurgroep Uitvoeren van change requests Het project Advisering en ondersteuning aan de projectteams betreffende de toepassing het herbruikbare artefact

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


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.


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.


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: nu – ½ jaar Middellange termijn: ½ jaar – 2 jaar Lange termijn: 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,


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 TNO-D&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.


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.


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 20% hergebruik 30% hergebruik 40% hergebruik DCA 602.400 903.600 1.204.800 SCA -28.000 8.000 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 BB:WB 90 - 10 BB:WB 60 - 40 BB:WB 30 - 70 DCA 903.600 734.400 565.200 SCA 8.000 -16.000 -40.000

Tabel 28 - DCA en SCA bij variatie ratios blackbox & whitebox hergebruik.


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 20% hergebruik 30% hergebruik 40% hergebruik DCA 602.400 903.600 1.204.800 SCA -28.000 8.000 44.000 RCA € 574.440 € 911.600 € 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.


143

Investering

Aspect 0% 2,5% 5% 7,5% 10%

Totale Kosten € 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 20% hergebruik 30% hergebruik 40% hergebruik 2,5 % € 378.440 € 715.600 € 1.052.800 5 € 278.440 € 615.600 € 952.800 7,5 % € 178.440 € 515.600 € 852.800 10 % € 78.440 € 415.600 € 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


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.


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


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 re-engineering. 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


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 ontwikkelen 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


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.


149

7. Reflectie

In dit hoofdstuk geef ik een beschouwing over mijn afstudeerperiode bij TNO-D&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


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.


151

8. Referenties

[BAR91] Barnes, B.H., Bollinger, T.B., (1991), Making Reuse Cost-Effective, IEEE Software, Vol. 8 No. 1, pp. 13-24.

[BAS88] 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)

[BAS97] Bassett, P.G., (1997), Framing Software Reuse – Lessons from the Real World, Eerste druk, New York: Prentice Hall.

[BRA98] Brassé, M., (1998), Code of Practice - Verificatie, Validatie & Accreditatie in het kader van EBF Ontwikkeling, TNO Fysisch en Elektronisch Laboratorium, Den Haag. [BRI97] 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

[DAV94] Davis, T., (1994), The Reuse Capability Model, Software Productivity Consortium, http://www.stsc.hill.af.mil/ crosstalk/1994/03/xt94d03d.asp (December 2004)

[DOB96] Dobler, H., Mittelmann, A., (1996), Development of an OO Energy Management System using the ami Approach, http://www.artm-friends.at/am/publications/Eaug96_Paper.pdf, (Februari 2005)

[DOD98] U.S. Department of Defense, (1998), High-Level Architecture Rules Version 1.3, www.openskies.net/files/HLA-rules1-3.pdf (mei 2005). [DON05] Dondertman, B., Kamstra, M., (2005), Programmeurshandleiding

ORB-simulatiekernel, TNO Fysisch en Elektronisch Laboratorium, Den Haag.

[DOU97] Doublait, S., (1997), Standard Reuse Practices: Many Myths vs. a Reality, StandardView June 1997, Vol.5 No. 2, pp. 84-91.

[DUS95] Dusink, L., Katwijk, J. van, (1995), Reuse Dimensions, ACM 1995, pp. 137-149.

[EZR02] Ezran, M., Morisio, M., Tully, C., (2002), Practical Software Reuse, Londen: Springer-Verlag.

[FAF94] Fafchamps, D., (1994), Organizational factors and reuse, IEEE Software, Vol. 11 No. 5, pp. 31-41.

[FEN97] Fenton, N.E., Pfleeger, S.L., (1997), Software Metrics - a rigorous & practical approach, Tweede druk, Boston: PWS Publishing Company.

[FIC01] 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.

[FRA95] 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


152

[FRA96] Frakes, W.B., Terry, C., (1996), Software Reuse: Metrics and

Models, ACM 1996, Vol. 28 No. 2, pp. 415-435. [HAL97] Hallsteinsen, S., Paci, M., (1997), Experiences in Software

Evolution and Reuse – Twelve Real World Projects, Research Reports Esprit - Project 9809 Volume 1, Berlijn: Springer.

[HAR98] Hars, A., Im, I., (1998), Knowledge Reuse – Insights from software reuse, Americas Conference on Information Systems (AMCIS), August 1998, Baltimore, Maryland

[HUL92] Hulshof, M., (1992), Leren Interviewen – het mondeling verzamelen van informatie, Eerste druk, Groningen: Wolters-Noordhoff.

[JAC97] Jacobson, I., Griss, M., Jonsson, P., (1997), Software Reuse - Architecture, Process and Organization for Business Success, Eerste druk, New York: ACM Press.

[JEN97] 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:zSzzSzwwwpa.win.tue.nlzSzkuijperszSzpublicationszSzsiwsep97.pdf/jense97electronic.pdf (April 2005).

[KAL01] 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).

[KOL91] 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.

[KON96] 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.

[KRU92] Krueger, C.W., (1992), Software Reuse, ACM Computing Surveys, Vol. 24 No. 2, pp. 131-183.

[LAN02] 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.

[LYN98] Lynex, A., Layzell, P.J., (1998), Organizational considerations for software reuse, Annals of Software Engineering 1998, Vol. 5, pp. 105-124.

[MIL02] Mili, H., et al. (2002), Reuse-Based Software Engineering – Techniques, organization and measurement, Eerste druk, New York: John Wiley & Sons INC.

[MCC95] McClure, C., (1995), Experiences in organizing for software reuse, Extented Intelligence Inc. Chicago.


153

[MOR00] Morisio, M., Tully, C., Ezran, M., (2000), Diversity in Reuse Processes, IEEE Software July, August 2000, pp. 56-63.

[MOR02] 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.

[NOL00] Nolan Norton Institute (2000), Beheersing en besturing van complexiteit in het netwerktijdperk, architectuur als managementinstrument, in T. Thiadens, Beheer van ICT-Voorzieningen – Infrastructuren, applicaties en organisatie, vierde herziene druk, Schoonhoven: Academic Service, pp. 52-53.

[PAN98] 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).

[PAU93] 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).

[POU97] Poulin, J.S., (1997), Fueling Software Reuse with Metrics, http://home.stny.rr.com/jeffreypoulin/Papers/Object_Mag_Metrics

/oometrics.html, (april 2005). [POU98] 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).

[PRE00] Pressman, R.S., Ince, D., (2000), Software Engineering – A Practitioner’s Approach, Vijfde editie, Maidenhead: McGraw-Hill.

[PRI93] Prieto-Díaz, R., (1993), Status Report: Software Reusability, IEEE Software, Vol.10 No. 3, pp. 61-66.

[PUL96] Pulford, K., Kuntzmann-Combelles, A., Shirlaw, S., (1996), A quantitative approach to Software Management – The Ami Handbook, Addison-Wesley, Wokingham.

[RAV03] 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.

[ROT99] 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

[SLU04] Sluimer, R.R., et al. (2004), Familievorming trainingssimulators KL: richtlijnen, TNO Technische Menskunde en TNO Fysisch en Elektronisch Laboratorium, Den Haag.

[SMI94] Smith, L., (1994), Software Reuse – Technologies and Applications, http://www.stc-online.org/cd-rom/cdrom2000/stsc/Reports/Reuse.pdf, (December 2004).

[SOM04] Sommerville, I., (2004), Software Engineering, seventh edition, Addison-Wesley Publishers & Pearson Education, Harlow.


154

[THI02] Thiadens, T., (2002), Beheer van ICT-Voorzieningen –

Infrastructuren, applicaties en organisatie, Vierde herziene druk, Academic Service, Schoonhoven.

[TNO03] TNO-D&V (2003), The Cornerstone of building quality Software, IT/QA forum, Den Haag.

[TUR99] 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).

[VER04] Verschuren, P., Doorewaard, H. (2004), Het ontwerpen van een onderzoek, Derde druk, Utrecht, Lemma BV.

[VAD98] 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

[VIL95] 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).

[WIT02] Witberg, R.R., (2002), Memorandum ORB Simulatie Kernel, TNO Fysisch en Elektronisch Laboratorium, Den Haag.


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].


B.1

Bijlage B Reuse Maturity Framework

Dimension of Maturity

Initial/Chaos (1)

Monitored (2)

Coordinated (3)

Planned (4)

Ingrained (5)

Motivation/Culture Reuse is

discouraged Reuse is encouraged Reuse is incentivized Reuse is

indoctrinated Reuse is “the way we do business”

Planning for reuse Nonexistent Grassroots activity Targets of opportunity Business Imperative Part of a strategic plan Breadth of reuse Involvement

Individual worker Work group Department Division Enterprise

Responsibility for making reuse happened

Individual worker

Shared initiative

Dedicated individual

Dedicated Group

Corporate Group

Process by which reuse is leveraged

Reuse process chaotic; unclear where reuse comes in

Reuse questions raised at design review (after the fact)

Design emphasis placed on reuse of off-the-shelf part

Focus on developing families of products

All software products genericized for future reuse

Reuse Inventory (assets)

Salvage yards (no apparent structure to collection)

Catalog Identifies Language-and platform specific parts

Catalog organized along application-specific lines

Catalog includes generic data processing functions

Planned activity to acquire or develop missing pieces in catalog

Classification Activity

Informal, individualized

Multiple independent schemes for classifying parts

Single Scheme, catalog published periodically

Some domain analyses performed to determine categories

Formal, complete, consistent, timely classification

Technology Support

Personal Tools, if any

Lots of tools, e.g, configuration management, but not specialized to reuse

Classification aids and synthesis aids

Electronic Library separate from devel-opment environment

Automated support integration with development system

Metrics

No Metrics on level of reuse, payoff, or cost of reuse

Number of lines of reused code factored into cost models

Manual tracking of reuse occurrences of catalog parts

Analyses performed to identify expected payoffs from developing reusable parts

All system utilities, software tools, and accounting mecha-nisms instrument to track reuse

Legal, contractual, accounting consideration

Inhibitor to getting started

Internal accounting scheme for sharing costs, allocating benefits

Data rights and compensation issues resolved with customer

Royalty scheme for all suppliers and customers

Software treated as key capital asset

Tabel 32 - Reuse Maturity Framework [KOL91].


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 Nr. Stap

Assess 1 2 3

Assess your Environment Define primary management goals

Check the goals against the assessment Analyse 4

5 6

Break down management goals into sub-goals Check consistency of resulting goal tree

Identify metrics from sub-goals Metricate 7

8 9

Write and validate measurement plan Collect primitive data Verify primary data

Improve 10 11 12

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-, product- of 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

ERROR! REFERENCE SOURCE NOT FOUND.

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


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.


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 Maturity

CMM 3 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 hergebruik

Het doel van Sodalia is het ontwikkelen van software applicaties die voor de verschillende 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, technieken en technologie

Object georiënteerde analyse en ontwerp gebruikmakend van UML. De ontwikkeling geschiedt op basis hiervan in C++ waarbij design patterns en CORBA vaak worden 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 hergebruik

Het verbeteren van de softwareontwikkelingproductiviteit. Het vergroten van de flexibiliteit in het productaanbod.

Aanwezigheid kritieke succesfactoren

- Management support: Aanwezig, het management ziet hergebruik als een belangrijk onderdeel van de bedrijfsstrategie. Er is ook een budget vrijgemaakt om een groep van 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 herbruikbare artefacten en ondersteuning voor hergebruik.

- Aanpassing niet-hergebruik processen: Overal, volledige integratie hergebruik in normale software ontwikkelactiviteiten.

- Anticiperen op menselijke factoren: Niet nodig, geen weerstand. Vanaf de oprichting van Sodalia is er reeds nadruk gelegd op hergebruik van software artefacten en nieuwe

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 invoering van hergebruik bij Sodalia onder Tabel 35)

- Repository: Zelf ontwikkelde repository, Sodalia Assets Library Management System (SALMS).

Herbruikbare Artefacten

Objecten 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:


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.

TNO-rapport



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.

Figuur 36 - Globaal overzicht hergebruikorganisatie Sodalia

Reuse Support Organization

Sturing van de

projectteams

Support voor de

projectteams

Beheer van de

herbruikbare artefacten

Productie herbruikbare

artefacten

Projectteams

Productie software producten

SALMS (repository)

Opslag Herbruikbare

artefacten

Opslag in SALMS na goedkeuring door Kwaliteitsteam

Hulp met UML en herbruikbare artefacten

Management en onderhoud herbruikbare artefacten

- Zoeken en verkrijgen herbruikbare artefacten - Evaluatie gebruikte herbruikbare artefact

Coördineren en tracken van alle hergebruik activiteiten


D.5


Eliop Software Engineers Circa 30 van de 100 medewerkers Software Proces Maturity

ISO 9001

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 hergebruik

Veel van de systemen die Eliop ontwikkeld zijn real-time. Een ander punt van aandacht 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 en technologie

Eliot heeft object georiënteerde technieken gehanteerd en is daarbij tot de conclusie 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 hergebruik

Het vergroten van de betrouwbaarheid (door gebruikmaking goed geteste herbruikbare 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

TNO-rapport



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 ten opzichte van een revolutionaire aanpak.

- Repository: Vanwege het niet kunnen vinden van een geschikte commerciële tool 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 Artefacten

Objecten 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


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).

TNO-rapport



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 use

Second use

Third use

Fourth use

Accumulated Costs 160% 180% 190% 200% Average Costs per use

160% 90% 63% 50%

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


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.

Figuur 37 - Globaal overzicht hergebruikorganisatie Eliop.

Reuse Task Group

Planned Reuse:

Domein analyse

Sturing van de

projectteams

Validatie van herbruikbare artefacten (Planned + Unplanned

Reuse)

Projectteams

Productie software producten

Repository (DBMS + CMS)

Opslag Herbruikbare

artefacten

Coördineren en tracken van alle hergebruik activiteiten

Herbruikbare artefacten vanuit Unplanned Reuse

Herbruikbare artefacten vanuit Planned Reuse

Opslag goedgekeurde herbruikbare artefacten

Zoeken en verkrijgen van herbruikbare artefacten


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 architecten 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 stakeholder-groepen behoren, bijvoorbeeld zowel projectmanager als software engineer. Stakeholdersgroep Aantal Ontwikkelaars 5 Projectmanagers 3 Technologietrekker/manager 2 Management 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 Objecten Processen Organisatie Metingen Weerstand

1 X 2 X 3 X 4 X 5 X 6 X 7 X 8 X 9 X

10 X X X 11 X 12 X 13 X 14 X 15 X 16 X 17 X 18 X

Tabel 38 - Relatie interviewvragen ontwikkelaars en theorie.

1 Wat verstaat u onder hergebruik binnen het softwareontwikkelproces? 2 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?


E.3

d. Wat ziet u als nadelen van hergebruik van software artefacten? 3 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?

4 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 Wat voor herbruikbare software artefacten worden er gemaakt binnen TNO? 6 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? 7 Hoe is de productie van herbruikbare software artefacten georganiseerd? 8 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? 9 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



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 vraag

Hergebruik algemeen

Objecten Processen Organisatie Metingen

1 X 2 X 3 X 4 X 5 X 6 X 7 X 8 X


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. Wat is hergebruik van software volgens u? 2. In hoeverre heeft u er mee te maken in projecten? 3. 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



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. Wat is het belang van softwareontwikkeling voor TNO-D&V als kennisinstituut? 2. 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?

3. 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?

4. 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. 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?

6. 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?


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 Code Document title Procedural AUD Audit procedure Procedural CM Configuration Management procedure Procedural CPSL Change Proposal Status List Procedural CR Change Request Procedural CSL Configuration Status List Technical DBDD DataBase Design Description* Technical EAR Engineering Analysis Report Procedural ECP Engineering Change Proposal Technical IDD Interface Design Description * Technical IRS Interface Requirements Specification * Technical ITD Internal Test Description Technical ITR Internal Test Result Technical OCD Operational Context Description * Technical PADA Programming in Ada (style guide) Technical PC Programming in C (style guide) Technical PCPP Programming in C++ (style guide) Procedural PCM Problem and Change Management procedure Procedural PR Problem Report Procedural QER Quality Evaluation Record Procedural REV Review procedure Procedural RFD Request For Deviation Procedural RFW Request For Waiver Technical SDD Software Design Description * Management SDP Software Development Plan * Technical SDF Software Development File Technical SPS Software Product Specification * Procedural SFMAP IT/QA Activity Mapping to SourceForge Technical SRS Software Requirements Specification * Technical SSDD System Subsystem Design Description * Technical SSS System Subsystem Specification * Technical STD Software Test Description * Management STP Software Test Plan Technical STR Software Test Report * Technical SVD Software Version Description * Technical SUM Software User Manual * Technical SYSTD System Test Description * Technical SYSTR System Test Report * Technical TDF 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).


G.1

Bijlage G Componenten uit het Kibowi MP Framework

In Tabel 41 wordt per component een korte toelichting van de functionaliteit gegeven.

Laag Element uit laag Toelichting Applicaties Control, Observer,

Entity Editor, Otas Editor, Administrator, Evaluator

Dit zijn applicaties die gebruikt worden door en voor Kibowi MP.

Kibowi Applicatie 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’.

Kibowi Gui Specialisatie van GenericGUI voor Kibowi. Permissions 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.

Database definitions De database definities voor Kibowi Messages De definities van de Kibowi berichten tussen de

verschillende applicaties. ModelParameters Definitie van de parameters zoals met name in de

Evaluator gebruikt worden bij de simulatie modellen.

Phoenix

Events Kibowi events. Pop ups, rook e.d. GenericGui 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.

Generic Application Generieke laag voor het opstart gedeelte van applicaties.

Computer Simulation Environment

Database Management DB Managers, Object definitions, Constanten, UnitConversions etc.

TNO-rapport

ERROR! REFERENCE SOURCE NOT FOUND. G.2 Error! Reference source not found. Bijlage G


Coordinates Berekeningen snijpunten met cirkels, ellipsen e.d. GLF Graphic Layers Framework. Handige java tools voor

menu’s en andere graphics Graph Berekeningen voor kortste pad algoritmes e.d. GIS 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.

Mail 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.

State Machine 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).

ORB Kernel 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.

Monitor 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.

Expressions Een pakket waarmee het mogelijk is logische expressies te bouwen en te evalueren.

Helpers Extensies op java.

TNO System API’s

Versioning Bijhouden van een versienummer op package niveau.

Tabel 41 - Toelichting bij de componenten uit het Kibowi MP Framework.


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.


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: Eens Oneens Hanteer een strikte, centrale sturing op de ontwikkeling van herbruikbare artefacten.

7 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 Oneens De hergebruikgroep beslist bij aanvang van een project welke software artefacten er hergebruikt gaan worden, in overleg met het betreffende projectteam.

3 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.


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 Oneens Reserveer bij alle softwareprojecten een standaard-percentage van het budget voor hergebruik om de projectoverschrijdende kosten van hergebruik te financieren.

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).


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 Bron Softwareprojecten op jaarbasis 20 (zowel grote als kleine) TNO-D&V Fulltime software engineers 25 (1600 uur per jaar per medewerker)

(45 in totaal binnen M&S) TNO-D&V

Uurtarief software engineer 100 EURO per uur (Integrale kostprijs) TNO-D&V Kosten van black box hergebruik 20% Theorie § 3.3.4 Kosten van white box hergebruik 67% Theorie § 3.3.4 Kosten herbruikbaar ontwikkelen 150% Theorie § 3.3.4

Tabel 42 - Gehanteerde (harde) kengetallen in de 'hergebruik business case'.

Aspect Toelichting Schatting 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.

10% op jaarbasis van de originele ontwikkeluren.

Kosten sturing consumptie

Dit zijn de kosten die worden gemaakt bij de sturing van de consumptie. De reviewprocedure en de tijd die software architecten kwijt zijn bij het meelopen binnen de projecten.

16 uur gemiddeld per project

Kosten sturing productie

Dit zijn de kosten die worden gemaakt bij de sturing van de productie. De uren die de software architecten en engineers van de hergebruikstuurgroep kwijt zijn bij het meekijken binnen de projecten en het opstellen en beoordelen van SRS’s en SDD’s.

24 uur per gemiddeld project

Totale verzameling

Dit is het aantal ontwikkeluren van de totale verzameling herbruikbare artefacten. Dit wordt o.a. gebruikt om de kosten voor onderhoud en beheer te schatten.

10.000 uur

Kosten ondersteuning

Benodigde tijd om de projecten te ondersteunen bij hergebruik. 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.

50% van 16 uur is 8 uur ondersteuning per project.

Tabel 43 - Gehanteerde schattingen in de 'hergebruik business case'.

ERROR! REFERENCE SOURCE NOT FOUND. J.2

Bijlage J


Gehanteerde formules

Aspect Identifier Aantal software engineers SE Kosten Black box hergebruik (%) KBB Kosten White box hergebruik (%) KWB Ontwikkeluren van de totale verzameling herbruikbare artefacten (uren) TU Onderhoud herbruikbare artefacten (% van geïnvesteerde ontwikkeluren) PO Overhead ratio voor kosten onderhoud bij white box hergebruik OR Investering in ontwikkeling herbruikbare artefacten (% van aantal SE-uren) IHG Tarief software engineer (Euro’s per uur) KSE Aantal werkzame uren per software engineer ( uren op jaarbasis) X2 Hergebruikpercentage (percentage t.o.v. normale softwareontwikkeling) X3 Percentage black box hergebruik (percentage van totale hergebruik) X4 Percentage white box hergebruik (percentage van totale hergebruik) X5 Aantal projecten (op jaarbasis) X6 Kosten voor sturing consumptie (uren) X7 Kosten voor sturing productie (uren) X8 Kosten voor ondersteuning aan projecten (uren) 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


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.

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

Ontwikkelingsuren nieuwe herbruikbare artefacten Sturingsuren productie per project Sturingsuren consumptie per project Ondersteuningsuren per project + Totaal aantal uren

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:

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.

5×3500 + 5×1000 + 10×150 20

= 1200

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).

Hergebruik van software artefacten bij de ... · 2.0.0.0 16-06-2005 Tim Hartog Scriptie Hergebruik...

Documents

Transcript of Hergebruik van software artefacten bij de ... · 2.0.0.0 16-06-2005 Tim Hartog Scriptie Hergebruik...