onderzoek naar een projectaanpak voor reengineering door ... · in de portfolio analyse wordt een...

IJsselstein, 18 april 2005

Vernieuwbouw bij Centric Onderzoek naar een projectaanpak voor

reengineering

door

Sebastiaan Eilander

Versie: 0.9

Vernieuwbouw bij Centric Onderzoek naar een projectaanpak voor

reengineering

‘We can't solve our problems using the same mind we used to create them’ Albert Einstein (1879-1955)

Student Dhr. Ing. S. Eilander Universiteit Twente Master Business Information Technology Specialisatie: ICT & Innovatie Afstudeerorganisatie Centric Information Engineering B.V. Einsteinweg 12 Postbus 246 3400 AE IJsselstein Afstudeercommissie 1e begeleider: mevr. Dr. P.M. Wognum (Universiteit Twente, Faculteit BBT, Leerstoel T&O) 2e begeleider: dhr. Dr. Ir. K.G. van den Berg (Universiteit Twente, Faculteit EWI, Leerstoel SE) 3e begeleider: dhr. Ing. L. Blom (Centric Information Engineering B.V.)

Voorwoord

Voorwoord

Met dit verslag rond ik mijn studie Bedrijfsinformatietechnologie (BIT) aan de universiteit van Twente af. Uiteraard was het een en ander niet mogelijk zonder de steun van een aantal personen. Ik maak graag van deze gelegenheid gebruik voor het bedanken van deze personen. Ik wil Leen Blom graag bedanken voor het mogelijk maken van mijn afstuderen binnen de organisatie Centric, het intern zorgen voor draagvlak voor het onderzoek en aanbieden van de verschillende bronnen binnen en buiten Centric. Ook wil ik graag Nel Wognum en Klaas van den Berg bedanken voor de steun en richting die zij hebben gegeven gedurende mijn onderzoek. Zonder de bijsturingen was het verslag niet op het niveau gekomen, waar het nu op is. Ook wil ik graag Albert Terrahe, Eef Gerritsen en Rudschen Rijke bedanken voor de commentaren en discussies die hebben bijgedragen aan nieuwe inzichten binnen mijn onderzoek. Binnen de literatuur is er al relatief veel geschreven over verschillende mogelijkheden en aanpakken voor reengineering. Er is echter weinig case materiaal en beschrijvingen van dergelijke projecten. (Bisbal et al, 1999) Deze zijn nodig om inzicht te verkrijgen in de legacy problematiek in het algemeen en de aanpak hier van in het bijzonder. Ik hoop hier met deze case beschrijving en conclusies ook aan bij te hebben gedragen. Sebastiaan Eilander

V

Samenvatting

Samenvatting

Centric is een ICT dienstverlener met ongeveer 3000 medewerkers. Ze biedt diensten aan van het ontwikkelen van maatwerkapplicaties, tot het in beheer nemen van applicaties. Doordat Centric proactief in de markt wil staan, willen zij diensten aanbieden, waar de klant een meerwaarde in ziet. Een van deze diensten is Legacy Renovation. Er is echter een behoefte aan een juiste positiebepaling betreffende de terminologie en de mogelijke aanpakken voor een dergelijk project. Dit onderzoek is gestart om een antwoord te geven op deze twee vragen. Applicaties zijn onderhevig aan veranderingen, waarvan een substantiële hoeveelheid uit nieuwe vereisten. Dit is debet aan de aansluiting van een applicatie op een constant veranderende organisatie. Door deze veranderingen en de daardoor toenemende complexiteit en kosten, ontstaat er een ongewenste onderhoudssituatie (applicatie is te complex om aan te passen, kosten voor onderhoud zijn te hoog, et cetera). Als mogelijkheden om deze situatie te verbeteren, kan er gekozen worden voor een nieuwbouw project of een Legacy Renovation project. Nieuwbouw is vaak een dure oplossing, waarmee ook nog extra risico’s worden gelopen zoals het verlies van bedrijfslogica uit de applicatie. Legacy Renovation is een alternatief voor nieuwbouw, waarbij de bestaande applicatie verbeterd wordt zonder de functionaliteit te veranderen. Een betere term voor Legacy Renovation is reengineering; bestaande gegevens worden geabstraheerd, op een hoger niveau geherstructureerd en geïmplementeerd in de nieuwe vorm. Een reengineering project heeft een laaggemiddelde complexiteit, een normaal tot hoog tempo en een hoge onzekerheid. De projecten moeten daarom relatief informeel gemanaged, met veel communicatie. Het gebruik van procedures is in mindere mate nodig. Een reengineering-projectleider moet wel technisch onderlegd zijn en het team moet bestaan uit ervaren professionals. Ook heeft een reengineeringproject een lage grijpbaarheid, dit houdt in dat er gekeken moet worden naar een structurerende werkstijl. In het algemeen moet onzekerheid niet volgebouwd worden met instrumenten. Verschillende proces stappen kunnen worden uitgevoerd voor het uitvoeren van een reengineering project, te beginnen met een portfolio analyse. In de portfolio analyse wordt een afweging gemaakt tussen de waarde die de applicatie voor het bedrijf heeft en het risico dat deze applicatie geeft. Een hoog technisch risico en een hoge bedrijfswaarde wijst een reengineering kandidaat aan. In een software reengineering assesment kan vervolgens verder gekeken worden naar de technische kwaliteit op verschillende onderdelen. Op basis van de resultaten wordt een advies gedaan met betrekking tot welke strategie(en) zouden moeten worden uitgevoerd. Voor de activiteiten in de uitvoering van het project kan gebruik gemaakt worden van de Renaissance methode. Deze heeft een viertal stadia met activiteiten, die incrementeel doorlopen kunnen worden. Voor de planningsfase is het stappenplan van de Risk Managed Modernization gehanteerd, waarmee een volwaardig plan van aanpak gemaakt kan worden. Voor de daadwerkelijke migratie kan er gekozen worden voor een incrementele aanpak (geleidelijk), een big-bang aanpak (ineens) of een parallele aanpak (verschillende systemen tegelijkertijd). Voor deze fase kan gebruik gemaakt worden van de iterative reengineering aanpak. De risico’s die zich tijdens een project kunnen voordoen bestaan uit een groot aantal die door verschillende auteurs zijn genoemd. Ook vanuit de praktijk zijn een aantal van deze risico’s waargenomen en hun belang benadrukt. Met behulp van tools kunnen complexe onderdelen die risicovol zijn om te reengineeren worden gevonden en geanalyseerd.

VII

Vernieuwbouw bij Centric – Onderzoek naar een projectaanpak voor reengineering

Het maken van een economische afweging voor reengineering, bestaat uit het bepalen van de bedrijfswaarde van een applicatie, de kosten van de reengineering inspanning en de jaarlijkse onderhoudskosten voor en na het reengineering project. Het bepalen van de specifieke kosten kan gedaan worden met het COCOMO 2 calculatiemodel. Dit model kent verhoudingen voor hergebruik van code en voor automatische vertaling. Tools kunnen bij deze methode helpen om de grootte van de applicatie in regels code of in functie punten te achterhalen. Belangrijke productfactoren voor een reengineeringproject zijn het begrip dat te verkrijgen is van het systeem en de kennis die er is van het doelsysteem. Een ervaren onderhoudsteam van de applicatie, de aanwezigheid van de oorspronkelijke ontwikkelaars en de kwaliteit van het systeem (architectuur, code, database en documentatie) spelen hier een belangrijke rol. Voor het doelsysteem is het belangrijk het team met voldoende ervaring te hebben en eventueel trainingen en cursussen te geven. Het gebruik van tools kan in het bijzonder helpen bij het verkrijgen van begrip van de bestaande applicatie. Hiervoor zijn verschillende technieken die een inzicht in de applicatie kunnen geven. Centric heeft een reengineering project uitgevoerd bij SBA Artsenpensioenfondsen. Middels het bestuderen van documentatie, het houden van enquêtes en interviews, is er een inzicht verkregen in de uitvoering van dit project. Hierdoor kon het project worden vergeleken met de theorie van reengineering. In dit project is het projectmanagement uitgevoerd zoals voorgeschreven op basis van werkstijl. Het project had een lage grijpbaarheid en heeft voldoende gescoord op zowel structurerende werkstijl als doelgerichte werkstijl. Er zijn weinig instrumenten gebruikt, of door de medewerkers ervaren als instrumenten. Een portfolio analyse en een software reengineering assesment zijn niet uitgevoerd. Het project is begonnen met de aanvraag van de klant samen met de kennis binnen Centric. Bij het uitvoeren van een portfolio analyse, was de applicatie niet uitgekomen als een reengineering kandidaat. Hierom is een aangepaste set criteria voorgesteld. Het uitvoeren van een software reengineering assesment is uitgekomen op dezelfde strategieën als in de praktijk zijn uitgevoerd. Er zijn wel een aantal vragen die niet overeenkomen met de praktijkervaringen, waardoor resulaten kunnen afwijken door verkeerde antwoorden. Deze vragen zouden facultatief gemaakt kunnen worden. Voor de daadwerkelijke uitvoering is er gebruik gemaakt van een incrementele ontwikkeling, waarbij de overgang naar het nieuwe systeem op het laatst ineens heeft plaatgevonden. Omdat er geen verandering is geweest in het bestaande platform, konden deze wijzigingen als onderhoudsstappen worden doorgevoerd. Stappen die vanuit de praktijk zinnig zijn om door te voeren in de aanpak zijn het uitvoeren van een prioritering van de deelprojecten en het inschalen van tijd voor het maken van specifieke tools. Door de risico’s aan de medewerkers voor te laten leggen, konden deze gewaardeerd worden op impact en waarschijnlijkheid. De risico’s die zich hadden voorgedaan zijn logisch verklaarbaar geweest en hadden geen verhoogde impact of waarschijnlijkheid. Deze lijst kan nu gebruikt worden als checklist en als inzicht in het gevaar van de risico’s van een reengineering project. Deze lijst kan gebruikt worden met de bestaande risico-analyse van Centric. Voor de economische waardering zijn er geen daadwerkelijke besparingen geconstateerd na het reengineering project. Wel is er de notie dat er effectiever en efficiënter gewerkt kan worden. Een aanbieding van Centric voor het beheer van de applicatie zou op basis van de kwaliteit van het systeem echter rond de 25% moeten uitkomen. De kosten die uit de COCOMO 2 berekening voortkomen, geven een marge ten opzichte van de daadwerkelijke kosten van het project.

VIII

Samenvatting

De tools die zijn ingezet in het project zijn positief ervaren door de medewerkers en zijn gekoppeld aan de technieken waarin tools kunnen voorzien. Hiernaast zijn de technieken gewaardeerd op de waarde die ze voor een reengineering project kunnen hebben. Met de waardering van deze technieken, ligt hier een basis voor verdere toolselectie. Concluderend zijn de volgende stappen aan te raden voor het uitvoeren van een reengineering project:

1. Gebruik van de aangepaste reengineering portfolio analyse voor het identificeren van reengineering kandidaten.

2. Technische applicatie beoordeling en strategie bepaling op basis van aangepaste Software Reengineering Assesment.

3. Economische afweging met behulp van voorgestelde economische model en COCOMO 2, naast expert en bottom-up inschattingen.

4. Voor de uitvoering kan gekeken worden naar de stappen van Renaissance, RMM en iterative reengineering, maar ook naar een incrementele oplossing, wanneer de complexiteit en risicofactoren dit toelaten.

5. Bij voorbereiding en tijdens uitvoering van het plan kan de SarBachets analyse gebruikt worden met als toevoeging de lijst risico’s voor reengineering en de waarderingen hiervoor.

6. Voor het inschalen van tools, ligt er een basis voor toolselectie. Tools kunnen geselecteerd worden op basis van belang en de mate waarin ze hierin voldoen. Voor Progress en/of Visual Basic omgevingen voldoen BIS, MTP en FDS aan een groot gedeelte van de kennisvergaring.

7. Gedurende het project een structurerende en doelgerichte werkstijl hanteren en weinig instrumenten inzetten.

De aanbevelingen die voortvloeien uit dit onderzoek spitsen zich toe op het verkrijgen van meer gegevens, om hiermee de voorgestelde aanpak te kunnen verfijnen. In eerste instantie zou de aanpak zoals hier voorgelegd moeten worden geïntegreerd in de bestaande aanpak. Hiertoe zijn de verschillende onderdelen in de context van de Centric Project Aanpak gezet. Er zouden hierna metrieken moeten worden vastgesteld die kunnen worden gekoppeld aan de inspanning van strategieën en activiteiten binnen de aanpak. Hierdoor zouden in de toekomst op basis van deze metrieken betere schattingen gedaan kunnen worden over de doorlooptijd en kosten. Als basis metrieken zijn hiervoor een aantal voorgesteld, er zou een verder onderzoek gestart kunnen worden om de beste metrieken te bepalen voor een reengineering project. Om tools te selecteren is het niet alleen zinnig om te kijken naar de verschillende technieken die gewaardeerd zijn, maar ook naar andere factoren als bijvoorbeeld prijs, performance, portabiliteit, etc. Om hier een goede selectie in te maken, zou een verder onderzoek naar toolselectie kunnen plaatsvinden. Verder moeten er meer projecten uitgevoerd worden, zodat al deze gegevens verzameld kunnen worden en de beschreven aanpak aangepast en verfijnd kan worden, waar nodig. Tot slot moet er naar de ontwikkeling van de huidige technieken gekeken bleven worden. Concepten als MDA – ADM die in ontwikkeling zijn, kunnen revolutionaire gevolgen hebben voor het vakgebied.

IX

Summary

Summary

Centric is a ICT service contractor with about 3000 employees. Offered services vary from the development of custom applications to application management. Because Centric wants to be a proactive player in the market, they want to deliver services in which the customer can identify an added value. One of these services is Legacy Renovation. However, there is a need for positioning this service in determining the various terms and possible approaches for a project. To give an answer to these two questions, this research was started. Applications are constantly changing, with a substantial part of this change consisting of new requirements. This is due to the applications connection with a constant changing organisation. Because of these changes and the increasing complexity and costs that are a result of them, an unwanted maintenance situation (the application is too complex to change, too expensive to maintain, et cetera) exists. Solutions for enhancing this situation are a complete redevelopment of the application, or a Legacy Renovation project. Redevelopment is often an expensive solution, also adding additional risks like the loss of business logic. Legacy Renovation is an alternative for redevelopment, enhancing the existing application without changing its functionality. A better term for Legacy Renovation is reengineering. Existing data is abstracted, restructured at a higher level and implemented in its new form. A reengineering project has a low to average complexity, a normal to high pace and a high uncertainty. Therefore, projects have to be managed relatively informal, with a lot of communication. There is less need for the use of procedures. A reengineering projectmanager has to be technically skilled and the team must exist out of experienced professionals. Reengineering projects also have a low level of controllability, which entails that there has to be worked in a structured style. In general, uncertainty should not be mitigated by the application of projecttools. Several proces steps can be executed for a reengineering project, starting with a portfolio analysis. In a portfolio analysis, the technical quality of an application is compared to the business value it delivers. A high technical risk and a high business value indicate that the application is a potential reengineering candidate. Further analysis of the technical quality on several application parts, can be achieved by executing the software reengineering assesment. The results of the questionnaires, advise on the strategy for reengineering. For the activities in the execution of a reengineering project, the Renaissance method can be used. This method has four phases with activities, that can be executed incrementally. For the planningsphase, the method ‘Risk Managed Modernization’ is proposed, with which a complete project proposal can be created. The actual migration of the application can be achieved by an incremental approach, a big-bang approach (all at once) or a parallel approach (different systems running in parallel). The migration phase can be supported by the iterative reengineering method. Many of the risks that can occur during a project, are described by several authors. In practice, several of these risks are experienced and their importance is emphasized. With the use of tools, complex parts that can pose a risk in the reengineering project, can be found and analysed. Making an economical analysis for a reengineering effort, consists of determining the business value of the application, the costs of reengineering and the annual maintenance costs before and after the project. Determining the costs for the reengineering effort the COCOMO 2 calculation model can be used. This model can use the factors ‘automatic translation’ and ‘reuse’ that are important for reengineering. Tools can be used in the economical analysis for the determination of the size of the application. This can be in lines of code or function points.

XI


Important productfactors for a reengineering project are the understanding that can be created from the existing system and the knowledge of the target system. An experienced maintenance team of the application, the presence of the original developers and the quality of the system (architecture, code, database and documentation) are key contributors to this knowledge. It is important to have sufficient experience and the possibility for training to gain knowledge in the target system. Centric has executed a reengineering project at SBA, a pension fund for physicians. By studying the documentation of this project, having interviews and taking surveys, an insight in the reengineering execution has been obtained. This way, the project could be compared with the theory on reengineering. In this project, projectmanagement has been performed consistently with the theory on workstyles. The project had a low controllability and there were high scores on structured workstyle and objective-oriented workstyle. The use of projecttools was minimal or at least experienced as such. Neither a portfolio analysis nor a software reengineering assesment were performed in the reengineering project. The project was started based on the request from a customer and expert-judgement. Executing the portfolio analysis has led to results were the technical risk was not high enough for classifying the application as a reengineering candidate. Therefore, an adjusted set of criteria is suggested. The software reengineering assesment results were consistent with the strategies that were executed in practice. There was however, a number of questions in this analysis that could not be related to daily practice by Centric. Results could vary if these questions are answered with different interpretations. These questions should therefore be optional in the questionnaire. For the actual execution of the project, there has been made use of incremental development, with the complete migration at the end of the project. Because there was no platform change, these changes could be executed as regular maintenance. Based on practice, steps for prioritizing subprojects and steps for creating tools for the development process, can be added. By letting the project members evaluate the different risks, the risks could be valued on impact and probability. The risks that had become operational were logically explicable and did not have a relatively high impact or probability. The list of risk with their associated impact and probability can be used as a checklist and for an insight into the risks of a reengineering project. This list can be used together with the existing risk-analysis used by Centric. For the economical analysis there were no actual cost reductions achieved after the reengineering project. There is however the notion that work after the reengineering project is more efficient and effective. A pricing for application management from Centric, based on the difference in quality of the application amounted to 25%. The costs that were calculated by the COCOMO 2 model, were are slightly higher than the actual costs of the reengineering project. The tools that have been used in the project, were positively rated by the project members. These tools have been associated with techniques in which these tools can provide support. The techniques have been appreciated by the projectmembers in the amount of added value for a reengineering project. These appreciations provide a basis for toolselection.

XII

Summary

Concluding, there are the following advised steps for executing a reengineering project:

1. Use of the adapted portfolio analysis for identifying reengineering candidates. 2. Technical application assesment and strategy determination based on the adapted Software

reengineering assesment. 3. Economical assesment using the suggested model and COCOMO 2, associated with expert- and

bottom-up estimation 4. For the execution, the methods Renaissance, Risk Managed Modernization and iterative

reengineering can be used, as well as incremental solutions when the complexity and riskfactors allow it.

5. In the preparation and during execution, the risks for reengineering and their appreciation can be used together with the Centric SarBachets risk analysis.

6. For selecting tools, there is a basis for tool selection. Tools can be selected based on their contributing techniques and the sufficience in contributing. The BIS, MTP and FDS tools provide a large part of the knowledge gathering for progress and / or Visual Basic environments.

7. During the project, there is a need for structuring and objective oriented workstyles en the little use of projecttools

The recommendations that come forth from this research are specifically aimed at gathering more information, to adjust the suggested projectapproach. Firstly, the approach presented here should be integrated in the existing approach. To this end, the several parts of this approach are put into context of the Centric Project Approach. After this, a set of metrics should be made, that can be coupled to activities in the approach and to the different strategies. By doing this, better predictions can be made about time and costs for future projects. Several basic metrics are suggested for this purpose, conducting a research to determine the best set of metrics is advised. To select tools, it is not only sensible to look at the different valued techniques which it will support, but also other factors like price, performance, portability, etcetera. To obtain a good set of criteria and to establish a tool for tool selection, further research is advised. Furthermore, Centric should execute more projects. By collecting data of these projects, the suggested approach can be adapted and tuned where necessary. Finally, the development of new techniques should be closely watched. Concepts in progress, like MDA – ADM, can have revolutionairy consequences in the field of reengineering.

XIII


Inhoudsopgave

VOORWOORD V

SAMENVATTING VII

SUMMARY XI

1 INLEIDING 1 1.1 BEDRIJFSINFORMATIE 1 1.2 PROJECTKADER EN AANLEIDING 2 1.3 PROBLEEMSTELLING EN DOEL 2 1.4 ONDERZOEKSOPZET 2 1.5 ONDERZOEKSVRAGEN 3 1.6 ONDERZOEKSAANPAK 4 1.7 ONDERZOEKSVELD 5 1.8 ONDERZOEKSHAALBAARHEID 6 1.9 OPBOUW VAN HET VERSLAG 6

2 VAN LEGACY RENOVATION NAAR REENGINEERING 7 2.1 DE SOFTWARE LIFECYCLE 7 2.2 ONDERHOUD EN EVOLUTIE 8 2.3 LEGACY EN REENGINEERING 10 2.4 CONCLUSIES 14

3 PROJECTFACTOREN VOOR REENGINEERING 15 3.1 PROJECTMANAGEMENT VOOR REENGINEERING 15 3.2 PROCES VAN REENGINEERING 19 3.3 PRODUCT VAN REENGINEERING 33 3.4 CONCLUSIES 34

4 EEN REENGINEERING PROJECT AANPAK 37 4.1 PROCES VAN REENGINEERING 37 4.2 PRODUCT VAN REENGINEERING 40 4.3 CONCLUSIES 42

5 OPERATIONALISERING ONDERZOEK 45 5.1 ONDERZOEKSAANPAK 45 5.2 VERZAMELING GEGEVENS 48 5.3 ONTWERP VAN HET INTERVIEW 48 5.4 ONTWERP VAN DE ENQUÊTE 49 5.5 CONCLUSIES 50

6 HUIDIGE REENGINEERING PROJECT AANPAK BIJ CENTRIC 51 6.1 CENTRIC PROJECT AANPAK 51 6.2 CASESTUDY: SBA 53 6.3 CONCLUSIES 68

XIV

Summary

7 REENGINEERING PROJECT AANPAK VOOR CENTRIC 71 7.1 PROJECTMANAGEMENT VOOR REENGINEERING 71 7.2 PROCES VAN REENGINEERING 72 7.3 PRODUCT VAN REENGINEERING 76 7.4 CONCLUSIES 77

8 CONCLUSIES 80

9 AANBEVELINGEN 86

REFERENTIES 89

AFKORTINGEN 93

INTERNE REFERENTIES 95

LIJST VAN FIGUREN 97

LIJST VAN TABELLEN 99

BIJLAGE 1 TERMINOLOGIE OVERZICHT 101

BIJLAGE 2 SAMENVATTING VERGELIJK STEPWISE 103

BIJLAGE 3 INDICATOREN VAN AKEN 105

BIJLAGE 4 VRAGENLIJSTEN SOFTWARE REENGINEERING ASSESMENT 107

BIJLAGE 5 RENAISSANCE METHODE 117

BIJLAGE 6 COCOMO 2 FACTOREN EN INSCHALING 119

BIJLAGE 7 VERWERKING INVLOEDSFACTOREN TILLEY (1995) 121

BIJLAGE 8 RISICOFACTOREN DOOR VERSCHILLENDE AUTEURS 123

BIJLAGE 9 STAPPENPLAN ITERATIVE REENGINEERING 125

BIJLAGE 10 VERWERKING RISICO’S ONDERKEND BIJ SBA VOOR RISICO-LIJST. 127

BIJLAGE 11 AFWIJKING THEORETISCH MODEL IN ENQUÊTE / INTERVIEW 129

BIJLAGE 12 ENQUETE OPZET EN INTERVIEWLIJSTEN MEDEWERKERS SBA 131

BIJLAGE 13 SRA ANTWOORDEN VOOR SBA 139

BIJLAGE 14 AANLOOP DUPLO PROJECT 141

XV

Hoofdstuk 1: Inleiding

1 Inleiding

Aanleiding van dit onderzoek is de vraagstelling hoe er met legacy renovation omgegaan moet worden. In dit hoofdstuk zal dit probleem uiteengezet worden. In de eerste paragraaf zal worden ingegaan op de bedrijfsinformatie, om context te geven aan het probleem. In paragraaf 2 wordt het projectkader en de probleemstelling verder uitgewerkt, zodat er in paragraaf 4 en 5 gekeken kan worden naar de onderzoeksopzet en vragen. Hoe de antwoorden op deze vragen verkregen worden wordt vervolgens behandeld in paragraaf 6. In paragraaf 7 wordt het onderzoeksveld besproken, waarna in paragraaf 8 gekeken wordt naar de haalbaarheid van het onderzoek. De inleiding wordt afgesloten met een beschrijving van de opbouw van het verslag.

1.1 Bedrijfsinformatie

Met bijna 3000 medewerkers verleent Centric ruim 10 jaar ICT-diensten. Centric richt zich op organisaties in diverse branches zoals: lokale en centrale overheid, financiële dienstverlening, woningcorporaties, groothandel, techniek, zorginstellingen, industrie, autolease en de reiswereld. Verder is Centric actief op het gebied van netwerk- en kantoorautomatisering, opleidingen, softwareontwikkeling, e-toepassingen, detachering, het ontwerp en beheer van ICT-omgevingen en standaardapplicaties, waarbij Centric zowel standaard- als maatwerkoplossingen biedt. In figuur 1.1 is een organigram opgenomen van Centric.

figuur 1.1; organigram Centric

Centric werkt vanuit bovenstaande drie divisies; Managed ICT Services, Centric IT Solutions en Centric Software Engineering. Managed ICT services biedt oplossingen op het gebied van kantoorautomatisering. Onder andere ICT-beheer, trainingen en helpdeskservices worden door deze dochter aangeboden. IT Solutions biedt standaardpakketten voor branchespecifieke processen (gezondheidszorg, woningbouw, lokale overheid, etc.) tevens worden integraties van deze pakketten in de bestaande infrastructuur aangeboden. Tot slot is er Software Engineering. Hier worden diensten voor maatwerk applicatie ontwikkeling en applicatie-integratie aangeboden. De focus ligt vooral op de reiswereld en de financiële dienstverlening. Centric Information Engineering, onderdeel van de divisie Software Engineering, ontwikkelt, implementeert en beheert softwaresystemen en technische informatiesystemen. Daarnaast biedt Centric Information Engineering resultaatverantwoordelijke dienstverlening, waaronder beheerconcepten voor applicatiebeheer. Centric Information Engineering opereert landelijk. Het onderzoek wordt uitgevoerd bij Centric Information Engineering en er zal voortaan in het verslag volstaan worden met het noemen van Centric. Het onderzoek wordt uitgevoerd binnen de Research & Development afdeling van Centric Information Engineering.

1


1.2 Projectkader en aanleiding

De afgelopen jaren is er een redelijk continue vraag geweest naar ICT-diensten. De laatste twee/drie jaar is de vraag hiernaar echter beduidend minder geworden door onder meer een recessie. Centric is gewend om in een markt te staan waarin veel vraag is en waar Centric aan deze vraag kan voldoen. Ook zijn klanten kritischer naar de IT-investeringen gaan kijken. Deze kritische blik resulteert in minder grote projecten zoals complete nieuwbouw van systemen. Er is een grotere markt gekomen waarin gekeken wordt naar aanvullingen op de bestaande systemen en het verlengen van de levensduur van oudere systemen. Doordat de vraag momenteel lager en kritischer is, wil Centric zich een proactieve houding aanmeten. Zij wil producten aanbieden, waarin de klant een meerwaarde ziet. Centric ziet een markt voor het product Legacy Renovation en heeft in het kader van Legacy Renovation al een aantal offertes gedaan en een project uitgevoerd. Dit project is uitgevoerd naar tevredenheid, er is echter geen duidelijkheid hoe een dergelijk project het beste aangepakt kan worden. In eerste instantie zou Centric graag een inzicht krijgen in de verschillende termen die gehanteerd worden voor Legacy Renovation. Doordat er veel termen door elkaar gebruikt worden is er een behoefte aan uniformiteit in de terminologie. Ten tweede zou Centric graag een inzicht krijgen in de verschillende aanpakken die mogelijk zijn voor een dergelijk traject en zou graag een soort van stappenplan of template kunnen gebruiken om richting te geven aan projecten die in het kader van Legacy Renovation vallen.

1.2.1 Legacy Renovation Legacy Renovation is een vage term, die op veel manieren kan worden opgevat. Onderdeel van het vaststellen hoe Legacy Renovation kan worden aangeboden, zal ook een verkenning van deze terminologie zijn. Vooralsnog wordt verstaan onder Legacy Renovation: “Legacy Renovation is about application use and reuse, building on the strengths of the past by combining them with the opportunities that present and future technologies offer.” (Butler Group, 2000)

1.3 Probleemstelling en doel

De probleemstelling van dit onderzoek is: “Op welke manier kan Centric succesvol een Legacy Renovation project plannen en uitvoeren?” Het doel dat hieruit voortkomt, kan als volgt verwoord worden: “Het doen van aanbevelingen met betrekking tot de verschillende werkwijzen voor Legacy Renovation door een vergelijking te maken tussen de huidige werkwijze van Centric en de verschillende factoren uit de literatuur en deskundigen vanuit het vakgebied.”

1.4 Onderzoeksopzet

In figuur 1.2 is het onderzoeksmodel opgenomen.

2


figuur 1.2 - onderzoeksmodel

In figuur 1.2 is een overzicht opgenomen van de verschillende vragen en het uiteindelijke doel. Uit de literatuur van projectmanagement, Legacy Renovation Proces en Legacy Renovation Product worden projectfactoren bepaald. Door gesprekken met deskundigen en een inventarisatie van tools worden de secundaire invloedsfactoren gevonden. Door deze projectfactoren en secundaire factoren samen te evalueren, kan er een gewenste projectstructuur worden bepaald. Hiernaast wordt door het bestuderen van de huidige Centric aanpak en de huidige Centric werkwijze gekeken wat de huidige projectstructuur is. Door de huidige projectstructuur (praktijk) te vergelijken met de gewenste projectstructuur (theorie) kan worden geconcludeerd wat de aanbevelingen betreffende deze projectstructuur zijn. Er wordt vanuit gegaan dat de samenhang van de methoden en werkwijzen nauw verbonden is aan de hulpmiddelen. Daarom is er niet gekozen om de hulpmiddelen en de werkwijzen apart te toetsen aan de literatuur, maar de complete projectstructuren met elkaar te vergelijken.

1.5 Onderzoeksvragen

Onderstaand zijn de onderzoeksvragen die zijn heb afgeleid van de probleemstelling. Samen geven ze antwoord op de vraag hoe Centric succesvol een Legacy Renovation traject kan doorlopen.

1. Welke projectfactoren vanuit de theorie zijn relevant voor het succesvol uitvoeren van een Legacy Renovation project?

a. Wat wordt er verstaan onder Legacy Renovation? b. Welke invloeden op projectmanagement zijn te onderkennen door Legacy Renovation,

vanuit de projectmanagementliteratuur? c. Wat zijn de mogelijke inrichtingen voor de belangrijkste projectfactoren in een legacy

renovation proces? d. Wat is de impact van de input en output op de uitvoering van het Legacy Renovation

project?

3


2. Welke projectaanpak kan gehanteerd worden voor Legacy Renovation? a. Wat is de impact van het gebruik van tools op de projectfactoren? (vanuit vraag 1) b. Welke impact op de projectfactoren hebben overige factoren die worden onderkend

door deskundigen?

3. Hoe verhoudt de huidige aanpak voor Legacy Renovation bij Centric zich tot de theorie? a. Wat zijn de belangrijkste verschillen en overeenkomsten tussen de theorie en praktijk

ten aanzien van het projectmanagement van Legacy Renovation? b. Wat zijn de belangrijkste verschillen en overeenkomsten tussen de theorie en praktijk

ten aanzien van het proces van Legacy Renovation? c. Wat zijn de belangrijkste verschillen en overeenkomsten tussen de theorie en praktijk

ten aanzien van het product van Legacy Renovation.?

4. Wat is de aan te bevelen Legacy Renovation-aanpak voor Centric? a. Wat zijn in het licht van de vergelijking de aanbevelingen ten aanzien van het

projectmanagement van Legacy Renovation? b. Wat zijn in het licht van de vergelijking de aanbevelingen ten aanzien van het proces

van Legacy Renovation? c. Wat zijn in het licht van de vergelijking de aanbevelingen ten aanzien van het product

van Legacy Renovation?

1.6 Onderzoeksaanpak

In figuur 1.3 is het onderzoek uitgezet in een materie overzicht. Er wordt in het Legacy Renovation proces gekeken naar de kennis die nodig is voor het beheersen van een Legacy Renovation traject. De input in dit proces is over het algemeen een legacy systeem en de output is een systeem volgens nieuwe(re) architecturen. Er is ook kennis nodig van de tooling die beschikbaar is voor Legacy renovation. Samen met overige invloedsfactoren is deze kennis ook relevant voor het reengineering proces. Voor de aansturing van het proces en algemene factoren wordt gekeken naar kennis uit het gebied van project management.

`

Project Management

(1b)

Legacy Renvation

Proces (1c)

Overige Factoren (2b)

Tools voor Legacy

Renovation (2a)

Input (1d) Output (1d)

Literatuur

vergelijk (4) Project Management

(3a)

Legacy Renovation Proces (3b)

Overige Factoren (3e)

Tools voor Legacy

Renovation (3d)

Input (3c) Output (3c)

Centric

figuur 1.3 - onderzoeksgebieden

In het figuur is per gebied gerefereerd naar de onderzoeksvragen in de voorgaande paragraaf. De aanpak van het onderzoek zal verder als volgt zijn: in eerste instantie zal er een theoretisch kader opgesteld worden. Vervolgens zal er een bestudering van de praktijk plaatsvinden. Vervolgens zal de kennis met elkaar geconfronteerd worden, teneinde een advies aan te kunnen dragen met betrekking tot de Centric aanpak voor reengineering. Dit proces kan meerdere malen doorlopen worden (iteratief), om gebruik te maken van nieuwe inzichten en deze te verwerken in het verslag.

4


De wijze waarop kennis bijdraagt aan de doelstelling van het onderzoek is grafisch weergegeven in figuur 1.4.

figuur 1.4 - onderzoeksaanpak

De verdieping in de praktijk zal bestaan uit de documentatie van de Centric Project Aanpak, de specifieke casestudy van een uitgevoerd reengineering traject (SBA) en het een en ander aan gegevens uit voortrajecten waar geen projecten uitgekomen zijn. Ook zullen er enquêtes gehouden worden onder de ontwikkelaars van het uitgevoerde reengineering traject. Ook zullen er een aantal semi-gestructureerde interviews gehouden worden met deskundigen in het vakgebied en zal er informatie betrokken worden uit seminars en/of presentaties. Op deze manier kan de mening van deskundigen betrokken worden.

1.7 Onderzoeksveld

Het onderzoeksveld beslaat grofweg twee gebieden: projectmanagement en legacy renovation. Deze zijn hieronder kort toegelicht. Tot slot wordt een aantal termen toegelicht, om verwarring te voorkomen.

1.7.1 Projectmanagement De literatuur van het projectmanagement heeft veel focus gehad op het gebruik van instrumenten voor sturing en management. Het orgaan dat kennis verzamelt en onderzoek stimuleert is de PMI (Project Management Institute). Deze heeft een Guide to the Project Management Body of Knowledge uitgebracht, waar de algemene kennis in is opgenomen. Deze wordt gezien als een standaardwerk. De overige literatuur op het gebied van projectmanagement is ontzettend uitgebreid. Over elk aspect dat komt kijken bij een project is wel wat geschreven. Van Aken (2002) concludeert echter dat er veel gekeken wordt naar instrumentarium en dat het wellicht zinnig is om ergens anders te gaan kijken, omdat veel projecten nog steeds mislukken. In zijn onderzoek probeert hij een correlatie te vinden tussen projectsucces en werkstijl, instrumentarium en de aard van projecten. Verder heeft Shenhar (2003) een bijdrage aan de literatuur gedaan, door een viertal dimensies vast te leggen. Deze dimensies kunnen vervolgens gebruikt worden om projecten mee te typeren, vervolgens kan dan met deze typering conclusies getrokken worden over het besturen van een dergelijk project.

1.7.2 Legacy renovation Het Legacy Renovation vakgebied is langzamerhand ontstaan. Doordat applicaties constant onderhoud nodig hebben, veroudert de applicatie en zal deze op den duur aan vervanging nodig zijn. Chikofsky en Cross (1990) hebben de standaard in dit vakgebied, waarin zij een taxonomie opzetten van het gebied Legacy Renovation. Er is echter nog steeds veel verwarring en onregelmatigheid in het gebruik van de termen.

5


Er zijn een beperkt aantal auteurs dat geschreven heeft over methoden om een dergelijk project aan te pakken. De voornaamste zijn Warren (1999), die hierover heeft geschreven in het kader van een internationaal kennis project en Seacord et al (2003) die gelieerd is aan het Software Engineering Institute. Verder is veel kennis over reengineering gefragmenteerd terug te vinden in de literatuur. Een andere auteur die zich toch redelijk consistent bezig houdt met reengineering is Sneed (1991; 1995; 1999). Hij heeft geschreven over risico’s en kosten, en voornamelijk uit eigen ervaring.

1.7.3 Onderscheid instrumentarium en tools Er wordt binnen dit verslag gesproken over tools en instrumentarium. Feitelijk zou hier hetzelfde onder verstaan kunnen worden; het een is een vertaling van de ander. Deze twee worden in het verslag echter onderscheiden, op basis waarvoor ze gebruikt worden; Instrumentarium is de verzameling hulpmiddelen die ondersteunend zijn voor het projectmanagement. Hieronder vallen technieken en methoden die sturing geven aan het project. Hierbij zijn bekende voorbeelden: planningen, begrotingen, brainstormen, controlelijsten, et cetera. Tools zijn de ondersteunende middelen voor het primaire proces. Onder de reengineering tools wordt software verstaan, die acties of bewerkingen uitvoert op de bestaande applicatie, om op deze manier het proces van Legacy Renovation te ondersteunen.

1.8 Onderzoekshaalbaarheid

De onderzoekshaalbaarheid wordt bepaald door de mate waarin de literatuur en de praktijk voldoende informatie kunnen bieden binnen de tijd die voor dit onderzoek staat. De literatuur is redelijk uitgebreid op het gebied en de tijd die beschikbaar is, is 8 maanden. Ook moet er rekening gehouden worden met het feit dat er momenteel beperkt materiaal voor casestudy beschikbaar is. Enerzijds is dat een reden voor het onderzoek, anderzijds beperkt het natuurlijk de uitkomsten. Ook de beschikbaarheid van de te interviewen programmeurs zou een bottleneck kunnen zijn. Wanneer van tevoren ingepland, zou dit echter geen probleem moeten zijn. Dit alles meegenomen wordt de onderzoekshaalbaarheid positief geschat.

1.9 Opbouw van het verslag

De hoofdstukindeling is gebaseerd op een logische verwerking van de onderzoeksvragen. In het volgende hoofdstuk zal worden gekeken naar de betekenis van de termen binnen het Legacy Renovation gebied. Er zal dan eerst gekeken worden naar de software, hoe problemen ontstaan en wat voor een oplossing Legacy Renovation nou eigenlijk is. In het derde hoofdstuk zal worden ingegaan op de projectfactoren voor Legacy Renovation. Er wordt gekeken naar projectfactoren, het Legacy Renovation proces en de input en output van het proces. Hoofdstuk vier handelt over de tools die ingezet kunnen worden bij Legacy Renovation trajecten en behandelt overige invloedsfactoren, wat resulteert in een aan te bevelen aanpak. In hoofdstuk vijf wordt het onderzoek geoperationaliseerd. Hierin wordt beschreven hoe met de theorie naar de praktijk gekeken wordt. Hoofdstuk zes draait om de aanpak die bij Centric de standaard is. Deze aanpak wordt in het algemeen behandeld, maar ook de casestudy als specifieke aanpak van Legacy Renovation wordt hier bekeken. Vervolgens zal er een vergelijk tussen de praktijk en de theorie plaatsvinden in hoofdstuk zeven, waarna wordt afgesloten met een hoofdstuk voor conclusies en aanbevelingen in hoofdstukken acht en negen.

6

Hoofdstuk 2: Van Legacy Renovation naar Reengineering

2 Van Legacy Renovation naar Reengineering

Dit hoofdstuk verkent het gebied van Legacy Renovation. In de eerste paragraaf wordt daarom ingaan op de software lifecycle. In de tweede paragraaf wordt vervolgens verder gekeken naar onderhoud en evolutie. De legacy die voortkomt uit constante evolutie, wordt behandeld in de derde paragraaf. Ook wordt hier gekeken naar de renovatie mogelijkheden die er vervolgens zijn. Afsluitend wordt in de conclusies een antwoord op de vraag “Wat is Legacy Renovation?” gegeven. Binnen dit hoofdstuk zullen de definities in het engels gehanteerd blijven. Dit om ze zo accuraat mogelijk te houden.

2.1 De Software Lifecycle

Software heeft net als alle producten een life-cycle die het doorloopt. Deze lifecycle staat beschreven in de ISO/IEC 12207 standaard (Singh, 1997). Deze lifecycle bestaat uit primaire, organisatorische en ondersteunende processen. Deze paragraaf dient context te geven aan onderhoud en daarom wordt alleen ingegaan worden op de primaire processen van ISO/IEC 12207. De primaire processen zijn acquisitie, levering, ontwikkeling, gebruik en onderhoud. In onderstaande figuur zijn deze processen in hun context weergegeven.

figuur 2.1 - ISO/IEC 12207 Software Lifecycle (Singh, 1997)

De processen vallen in een zogenaamde plan-, do-, check-, act-cyclus en zijn iteratief van aard. Het startpunt voor acquisitie en het eindpunt na operationeel, onderhoud of ontwikkeling zijn hetzelfde punt. De verschillende processen kunnen door verschillende partijen worden uitgevoerd, maar dit hoeft niet. Het acquisitie proces is het proces van de verkrijger van de dienst. Hier vindt de vraag naar een softwareproduct of dienst plaats en komen de behoeftes en vereisten van de gebruiker van de software naar voren. Het leveringsproces betreft vervolgens het proces van de leverancier. Het wordt gestart door een beslissing om een request for proposal voor een andere partij te maken. De te verlenen dienst kan het ontwikkelen van een product zijn, maar ook bijvoorbeeld het onderhoud van een softwareproduct. De ontwikkeling behandelt de activiteiten van de ontwikkelaar van de software. Hiermee wordt zowel het maken van nieuwe software als het maken van aanpassingen op bestaande software bedoeld. Dit proces kan gebruikt worden als methode voor het ontwikkelen van prototypes of het bestuderen van de vereisten en het ontwerp van het product of als een proces voor het maken van producten. Het operationele proces behelst de activiteiten van de partij die het systeem in gebruik houdt. Het gebruik van de software valt binnen het gebruik van het totale systeem. Tot slot het onderhoud proces. Dit proces betreft de activiteiten en de taken van de onderhouder. Wanneer er aanpassingen aan de code en de gekoppelde documentatie moeten plaatsvinden, door een fout, een gebrek een probleem of de behoefte voor verbetering of aanpassing, wordt dit proces gestart. Wanneer er een aanpassing moet plaatsvinden, wordt het ontwikkelingsproces gestart. Het proces stopt wanneer het systeem uit productie wordt genomen (retirement van het systeem). Het bestaat uit de volgende activiteiten: Proces implementatie; probleem en aanpassing analyse; aanpassing implementatie; onderhoud review en acceptatie, migratie en software retirement. Het onderhoud proces is verder uitgewerkt in de standaard ISO/IEC 14764.

7


De context van het onderhoudproces en de beknopte inhoud er van is nu bekend. In de volgende paragraaf wordt ingaan op het onderhoud, om te kijken naar de impact en de gevolgen hiervan op een applicatie.

2.2 Onderhoud en Evolutie

Onderhoud is altijd een ondergeschoven onderdeel van de software life-cycle geweest (Sommerville, 2004; Warren, 1999; Abran et al, 2004). Sinds de problematiek van de jaar 2000 conversie is geweest, is er een inzicht gekomen dat er meer aandacht aan het onderhoud besteed moet worden. Uit verschillende studies (Sommerville 2004 naar Erlikh) blijkt dat de kosten van onderhoud een relatief groot onderdeel van de totale kosten zijn. Koskinen (2003) geeft zelfs een kort overzicht van verschillende studies, waaruit naar voren komt, dat het percentage alleen maar stijgt door de jaren. Het laatst gebruikte onderzoek door zowel Sommerville (2004) als Koskinen (2003), is die van Erlikh (2000) waaruit naar voren komt dat het percentage van de onderhoud kosten ten opzichte van de totale informatiesysteem kosten 90% zijn. Deze kosten geven een beeld van de huidige stand van zaken. De verhouding is van een dergelijke aard dat geconcludeerd kan worden dat de initiële kosten niet representatief zijn voor de daadwerkelijke kosten. Het moet echter duidelijker gemaakt worden wat onderhoud precies is, om hier verder op in te gaan. In de eerste paragraaf zal een opdeling gegeven worden, in de tweede paragraaf zal ingegaan worden op het proces.

2.2.1 Onderhoud: Een typologie Boehm (1981) geeft wellicht de meest expliciete opdeling van software onderhoud. Doordat een aantal vormen van onderhoud ook zijn gekwantificeerd, lijkt deze opdeling ook het meest duidelijk. Software onderhoud wordt gedefinieerd als: “The process of modifying existing operational software while leaving its primary functions intact.” Hieronder vallen:

Redesign en redevelopment van kleinere gedeelten (minder dan 50% nieuwe code) van een bestaand software product;

Design en ontwikkeling van kleinere interacterende gedeeltes, die wat redesign benodigen (minder dan 20%) van de bestaande applicatie;

Aanpassingen van de code, documentatie of database structuur van het bestaande software product.

De meetbaarheid van deze verdeling is slecht toe te passen, twee aanpassingen na elkaar van 49% van de code zal immers kunnen resulteren in hetzelfde effect als complete nieuwbouw. Ook een procentuele verandering van de architectuur is moeilijk meetbaar. Toch wordt hier gevoelsmatig wel een beeld geschetst van veranderingen die onder onderhoud zouden vallen. Verder kan het software onderhoud worden geclassificeerd in twee categorieën:

Software update; dit resulteert in nieuwe functionele specificaties voor het software product Software repair; dit behoudt de bestaande functionele specificatie.

Vervolgens kan software repair worden opgedeeld in drie subcategorieën:

1. Corrective maintenance (het verhelpen van verwerking-, performance- of implementatie fouten);

2. Adaptive maintenance (veranderingen in de verwerking- of dataomgeving); 3. Perfective maintenance (voor het optimaliseren van de performance of onderhoudbaarheid);

Door ISO 14764 is hier vervolgens nog een vierde aan toegevoegd (Abran et al, 2004): 4. Preventive maintenance ( het veranderen van een software product, om latente fouten te

herkennen en voorkomen, voordat het effectieve fouten worden)

8


Abran et al. (2004, naar ISO 14764) zet hier de verschillende vormen van maintenance uit als verbetering/correctie versus proactief en reactief:

Correctie Verbetering

Proactief Preventief Perfectief

Reactief Correctief Adaptief.

tabel 2.1 - overzicht soorten onderhoud (Abran, 2004)

Het is opvallend te noemen dat er met deze opdeling niet wordt ingegaan op het toevoegen van functionaliteiten. Op basis hiervan en de verwarring waar bovenstaande termen vaak voor zorgen heeft Sommerville (2004) zelfs een nieuwe opdeling voorgesteld. Dit is wellicht overdreven, maar het is wel zaak dat de verhoudingen kenbaar zijn: 65% van het onderhoud bestaat uit nieuwe vereisten, 18% bestaat uit aanpassingen voor de omgeving (adaptief/perfectief) en 17% gaat naar daadwerkelijke foutcorrectie (correctief/preventief).

2.2.2 Onderhoud en evolutie Doordat er onderhoud op onderhoud wordt gepleegd op de software, ontwikkelt de software verder en verder. Dit concept is opgevat als software evolutie. Een pionier op het gebied van software evolutie is Lehman. Hij heeft een achttal wetten opgesteld waaraan de software evolutie onderhevig is (Lehman, 1997). Deze wetten zijn de volgende: 1. Continue verandering; een programma dat wordt gebruikt, moet constant worden aangepast,

anders zal het progressief minder naar tevredenheid werken. 2. Groeiende complexiteit; Naar mate een programma evolueert, zal de complexiteit vergroten, tenzij

er werk wordt verricht het te onderhouden of te verkleinen. 3. Zelf regulering; het evolutie proces is zelfregulerend. 4. Conservering van de organisationele stabiliteit; de algemeen gemiddeld effectieve

activiteitsbesteding aan een evoluerend systeem blijft gedurende de product levenstijd hetzelfde. 5. Conservering van bekendheid; gedurende het actieve leven van een software product, is de inhoud

van opeenvolgende releases statisch hetzelfde. 6. Continue groei; Functionele inhoud zal constant moeten groeien om de gebruikers tevredenheid

gedurende de levenstijd van een product te bewaren. 7. Dalende kwaliteit; Tenzij het systeem rigoureus wordt aangepast om veranderingen in de omgeving

in acht te nemen, zal de kwaliteit minder worden naar mate het evolueert. 8. Feedback – systeem; het evolutie proces hanteert op meerdere niveaus en meerdere iteraties een

feedbacksysteem. De aanpassingen en verbeteringen dienen hier rekening mee te houden om succesvol te zijn.

Zoals in bovenstaande wetten ook zichtbaar wordt: door continu onderhoud (in al haar verscheidenheid) worden er nieuwe functies toegevoegd, fouten verbeterd, preventieve aanpassingen doorgevoerd en aanpassingen aan de omgeving doorgevoerd. Het is nu duidelijk wat onderhoud is en dat er evolutie plaats vind. Maar wat is nu precies het onderscheid? Kemerer (1999) hanteert evolutie naar een document van Lehman: “The dynamic behaviour of programming systems as they are maintained and enhanced over their life times”. Dit houdt in dat evolutie zou kunnen worden samengevat als het totaal van onderhoud. Weiderman, Bergey, Smith en Tilley (1997) maken een onderscheid tussen software onderhoud en evolutie. Onder onderhoud verstaan ze fijne, kortere termijn activiteiten die gefocused zijn op lokale veranderingen. Het Y2K probleem wordt hier bijvoorbeeld door hen onder geschaard. Met dit software onderhoud, blijft de structuur van het systeem relatief constant en zorgen de veranderingen voor weinig economische en strategische voordelen. Systeem evolutie is dan grover van aard, op een hoger niveau en is een structurele vorm van verandering, die de software systemen kwalitatief makkelijker maakt om te onderhouden. Evolutie laat het systeem voldoen aan nieuwe vereisten en nieuwe mogelijkheden.

9


Sommerville (2004) stelt dat wanneer de ontwikkeling van software niet naadloos is opgevolgd door evolutie, er sprake is van onderhoud. Dit gebeurt bijvoorbeeld als een applicatie is opgeleverd door een ontwikkelaar aan het bedrijf en de documentatie is niet voldoende. Ook wanneer een bedrijf besluit het onderhoud te gaan uitbesteden en de documentatie is niet op orde, wordt er teruggevallen in het onderhoud. Bennet (2000a) onderkent ook een dergelijke dichotomie: evolutie en servicing (onderhoud) Na de initiële ontwikkeling is er een versie die onderhevig is aan evolutie. Op een bepaald punt verliest het team dat verantwoordelijk is voor het onderhoud kennis, of de architectuur verliest samenhang. De applicatie komt dan in de servicing stage (onderhoud). In de servicing stage worden alleen kleine patches uitgevoerd en kleine veranderingen aan de code. Hierna komt de applicatie in het phase-out stadium. De applicatie is dan nog in productie, maar er moet om bekende gebreken heen gewerkt worden. Uiteindelijk is er een closedown van de applicatie. In het ‘version staged model’ wordt de versie van de applicatie na de initiële ontwikkeling meteen naar servicing gezet. Alle substantiële veranderingen (die dus onder evolutie vallen) worden in een nieuwe release geïmplementeerd. In het onderstaande figuur is dit model te zien. Het verschil tussen evolutie en onderhoud is hier ook grafisch zichtbaar: evolutie is de verticale lijn naar beneden en onderhoud is te zien als de schuine takken opzij. Na servicing wordt de phase-out ingezet. Er wordt alleen nog onderhoud gedaan om het draaiende te houden. Er komt vervolgens een close-down, wat het einde van die versie inhoudt.

figuur 2.2 - Version Staged Model (Bennet 2000)

De opdeling van Weiderman et al (1997) is gelijk aan die van Bennet. Ook Bennet onderkent grove (evolutie) en kleinere (onderhoud) veranderingen. Dit wordt voornamelijk duidelijk in een apart artikel (Bennet, 2000b) van hem, waarin hij evolutie koppelt aan releases van software en onderhoud aan patches. Voor een product als MS - Windows houdt dit bijvoorbeeld in dat er regelmatig een nieuwe release is (evolutie) en af en toe een service pack / hot-fix (onderhoud). In de volgende paragraaf wordt ingaan op de problemen die voortkomen uit de besproken software evolutie.

2.3 Legacy en Reengineering

We zien dus dat een systeem verandert. De omgeving van het bedrijf verandert, er zijn nieuwe technologieën en nieuwe vereisten voor het systeem. Het systeem evolueert en wordt steeds complexer. Warren (1999) noemt dit het legacy dilemma: Een legacy systeem dat bedrijfskritiek is, moet operationeel blijven in een bepaalde vorm in de organisatie. Het doorzetten van onderhoud is echter duur en de scope voor het effectief doorvoeren van veranderingen, is zwaar beperkt. Bovendien zijn de kosten voor het opnieuw bouwen van het systeem, te hoog.

10


In de eerste paragraaf wordt ingegaan op wat legacy betekent. De verschillende mogelijkheden om er mee om te gaan worden in de tweede paragraaf uitgelicht. Er zal daarna specifiek op reengineering als mogelijkheid worden ingegaan, waarna tot slot de overgebleven termen zullen worden behandeld.

2.3.1 Legacy: wat houdt het precies in? Er zijn verschillende definities voor het concept Legacy. Gold (1998) heeft aan de definitie van legacy systemen een speciaal artikel gewijd, waarin hij de meest bekende evalueert. Vanwege de uitvoerigheid van dit werk en de overlap met veel bronnen binnen dit verslag, wordt daarom volstaan met zijn definitie. Gold (1998) stelt dat veel eigenschappen die toegekend worden aan Legacy software, niet onderscheidend zijn; ze zijn bijvoorbeeld niet allemaal groot, monolithisch of in 1 taal geschreven. Daarom dient er op een hoger niveau onderscheidende eigenschappen gedefinieerd te worden. Gold (1998) komt uit op de volgende definitie: “Legacy Software is critical software that cannot be modified efficiently”. Hij plaatst dit concept legacy software binnen een legacy systeem. Hiermee wordt duidelijk dat het niet alleen om de software gaat, maar dat legacy ook binnen de organisatie zit. Hierdoor wordt zijn definitie van een legacy systeem: “A socio-technical system containing legacy software”. Nu er het besef is wat legacy is, waarom het er is en waarom het een probleem is, kan er gekeken worden naar hoe er het best mee omgegaan kan worden.

2.3.2 Legacy: wat zijn de oplossingen? Warren (1999) stelt dat onderhoud een van de drie strategieën is om met verandering om te gaan. Deze drie strategieën zijn:

Gecontinueerd onderhoud; het onderhouden van het systeem zoals het traditionele ontwikkelen onderhoud procesmodel doorlopen wordt. Zie hiervoor paragraaf 2.1

Reengineering; “The systematic transformation of an existing system into a new form to realize quality improvements in operation, system capability, functionality, performance or evolvability at a lower cost, schedule, or risk to the customer.” (Warren naar Tilley, 1995) Deze definitie zal nog duidelijker worden gemaakt in de volgende paragraaf.

Replacement; het vervangen van een systeem. Olsem (1998) onderkent ook nog:

Retirement: het uit productie halen van een systeem. Reengineering kan gezien worden als een strategie, zoals Warren (1999) doet. Daarna wordt echter teruggegaan naar de fase ‘continued maintenance’. Het is een tijdelijke inspanning met resultaten die langblijvend zijn, maar geen proces dat een alternatief biedt voor maintenance. De software zal in maintenance blijven. Warren bedoelt eigenlijk met continued maintenance: niets doen en het systeem laten degraderen. Er zijn nog alternatieven om legacy systemen weer te gebruiken in een veranderde omgeving. Het toepassen van wrapping-technieken en screen-scrapers geeft bijvoorbeeld de mogelijkheid om een nieuwe schil om legacy systeem te gebruiken. Ook het toepassen van Enterprise Application Integration (EAI) kan er voor zorgen dat de legacy ontsloten en gebruikt kan worden door andere applicaties. Deze methoden worden echter niet behandeld in dit verslag, aangezien dit geen oplossingen zijn voor het legacy probleem (het onderhoud wordt niet goedkoper en de applicatie niet flexibeler).

2.3.3 Reengineering: Het Framework van Chikofsky en Cross Over de term reengineering zijn binnen dit kader wellicht het grootst aantal verschillende definities te vinden. Chikofsky (1990) heeft de standaard gezet met de eerste definitie: “the examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form” Tilley (1995) vult dit feitelijk aan, door hier nog het voordeel van deze transformatie bij te voegen: “Reengineering is the systematic transformation of an existing system into a new form, to realize quality improvements in operation, system capability, functionality, performance, or evolvability at a lower cost, schedule, or risk to the customer”.

11


Reengineering vindt niet alleen plaats om legacy systemen te verbeteren. Het kan ook gebruikt worden om onderdelen van de applicatie te hergebruiken, het onderhoud te vergemakkelijken, integratie met andere systemen mogelijk te maken of om documentatie op te leveren. Binnen het kader van reengineering constateert Warren (naar Arnold (1994)) een zestal vormen van reengineering1: 1. Broncode vertaling; het een op een vertalen van de code van de applicatie, naar een andere taal, of

door een andere compiler. 2. Programma restructuring; het herstructureren van een programma, door gebruik te maken van

modernere programmeer constructies. 3. System restructuring; op een globaal niveau naar de software architectuur kijken en de structuur

expliciet maken. Er wordt gekeken naar modules en het verbeteren van deze architectuur gebeurd meestal met de hand, omdat er een begrip nodig is van de verantwoordelijkheid van functies.

4. Data reengineering; behelst het analyseren en reorganiseren van de data structuren van een systeem en in sommige gevallen ook de waarden van de data.

5. Reverse engineering; het proces van het analyseren van software met het doel om het ontwerp en de specificatie te herstellen.

6. Retargeting; het migreren van een bestaand systeem naar een nieuw hardware platform. Het Department of Defense (1997) voegt hier nog de mogelijkheid van Redocument aan toe:

7. Redocument; “The process of analyzing the system to produce support documentation in various forms, including user manuals and reformatting the systems source code listings.”

De samenhang tussen de verschillende termen is nu nog niet duidelijk. Chikofsky en Cross (1990) hebben daarom een heldere uiteenzetting gemaakt van een groot aantal van de termen die in het veld actief zijn. Er wordt een onderscheid gemaakt in de abstractieniveaus: requirements, design en implementatie. Wanneer er een stap hoger in abstractie gemaakt wordt, is dit reverse engineering, een stap omlaag is forward engineering. Een verandering / optimalisering op lokaal niveau is restructuring en het geheel van stappen is reengineering. Voor de duidelijkheid worden onderstaand de definities gegeven: Forward Engineering:

“The traditional process of moving from high level abstractions and logical implementation-independent designs to the physical implementation of a system.”

Restructuring “The transformation from one representation form to another, at the same relative abstraction level, while preserving the subject system’s external behavior. (functionality and semantics)”

Reverse engineering

“The process of analyzing a subject system to identify the systems components and their interactions and to create representations of the system in another form or a higher level of abstraction.”

tabel 2.2 - terminologie Chikofsky en Cross (1990)

Reverse engineering onderkent weer twee subgebieden: Redocumentation is een vorm van reverse engineering: “the creation or revision of a semantically equivalent representation within the same relative abstraction level.” Design Recovery: “a subset of reverse engineering in which domain knowledge, external information and deduction or fuzzy reasoning are added to the observations of the subject system, to identify meaningful higher level abstractions beyond those obtained directly by examining the system itself” In onderstaand figuur zijn de verschillende onderdelen van Reengineering uitgezet:

1 Deze beschrijvingen zijn in het Nederlands, aangezien Warren geen definities geeft.

12


figuur 2.3 - reengineering framework (Chikofsky & Cross, 1990)

Er worden drie abstractieniveaus / ontwikkelstadia onderkend. In principe is dit een vereenvoudigde weergave van de werkelijkheid. Het gaat in dit figuur om de context van de termen die door Chikofsky en Cross (1990) zijn neergezet. Wanneer er een niveau omhoog wordt gegaan, is er sprake van reverse engineering, een niveau omlaag is forward engineering en veranderingen op hetzelfde abstractie niveau vallen onder restructuring.

2.3.4 Reengineering Life-cycle Reengineering is dus voortgekomen als oplossing uit het legacy probleem dat is veroorzaakt door continu onderhoud. Het is echter belangrijk om een onderscheid te maken tussen reengineering, onderhoud en ontwikkeling. Op deze manier kan namelijk gekeken worden naar aandachtspunten voor reengineering. Bergey, Hefley, Lamia en Smith (1995) propageren een life-cycle voor reengineering projecten. Ze hebben het gebied van reengineering apart onderkend van onderhoud en ontwikkeling. In onderstaand schema is reengineering op het continuüm van nieuwe ontwikkeling en onderhoud gezet.

figuur 2.4 - reengineering verhouding met onderhoud en ontwikkeling (Bergey, 1995)

13


Activiteiten voor nieuwe ontwikkeling maken gebruik van nieuwe computer middelen en nieuwe technologieën, waar onderhoudsactiviteiten voornamelijk gebruik maakt van de Legacy systeem onderdelen. Geconstateerd kan worden dat reengineering onderdelen van nieuwe ontwikkeling en onderdelen van onderhoud in zich heeft.

2.4 Conclusies

Er kan nu antwoord gegeven worden op de deelvraag: “Wat wordt er verstaan onder Legacy Renovation?” Een van de fasen van het leven van software is de onderhoudsfase. Deze fase is niet onbelangrijk, want het grootste gedeelte van de IT budgetten gaat naar onderhoud. Hiernaast heeft het grootste gedeelte van het onderhoudswerk betrekking op nieuwe eisen en wensen. De software wordt complexer en verandert continue conform de wetten van Lehman. Wanneer er geen sprake is van evolutie en het ontwikkelen voor evolutie, degradeert de applicatie langzamerhand. Deze wordt minder handelbaar, inflexibel en duur te onderhouden. We hebben dan Legacy software. Een methode om dit aan te pakken is Legacy Renovation. Legacy Renovation wordt vanaf nu reengineering genoemd. Reengineering is de overkoepelende term van het abstraheren van gegevens, deze op een hoger niveau te herstructureren en deze opnieuw te implementeren. Veel termen zijn geïntroduceerd door auteurs en voornamelijk bedrijven, zonder te kijken naar de bestaande terminologie. Dit heeft geresulteerd in veel termen die hetzelfde betekenen of specifieke termen die onder een algemenere term binnen reengineering geschaard kunnen worden. De terminologie van Chikofsky en Cross (1990) zal daarom als leidraad worden gehouden. De verschillende reengineering strategieën die door anderen worden onderscheiden kunnen binnen dit model gehanteerd worden. In Bijlage 1 is een overzicht van de termen opgenomen. Reengineering kan gezien worden als een vorm van evolutie en kan gepositioneerd worden tussen onderhoud en nieuwe ontwikkeling in en heeft het facetten van beide activiteiten. Nu reengineering als concept duidelijk is gekregen, kan er gekeken worden naar de verschillende factoren die invloed hebben op een reengineeringproject. Deze worden behandeld in het volgende hoofdstuk.

14

Hoofdstuk 3: Projectfactoren voor Reengineering

3 Projectfactoren voor Reengineering

Hoofdstuk 2 gaf een antwoord op de vraag wat reengineering nu eigenlijk is en waar het vandaan komt. In dit hoofdstuk wordt gezocht naar een antwoord op de onderzoeksvraag welke projectfactoren belangrijk zijn voor een reengineering traject. In de eerste paragraaf wordt gekeken naar projectmanagement en welke aspecten belangrijk zijn voor reengineering projecten. Het tweede deel zal gaan over de inrichting van het reengineering proces, met een focus op activiteiten, kosten en risico’s. Paragraaf 3 behandelt respectievelijk de legacy die input is voor het proces en de nieuwe architecturen die output zijn van het proces, ofwel het product van reengineering. In de laatste paragraaf worden de conclusies opgesomd.

3.1 Projectmanagement voor Reengineering

In deze paragraaf zal worden ingegaan op projectmanagement, om een aantal factoren voor projecten vast te stellen die worden beïnvloed door het concept reengineering. Project management is een breed vakgebied, waar een brede sectie literatuur aan verbonden is. Binnen dit vakgebied wordt een onderscheid gemaakt tussen project-, programma- en portfoliomanagement. Een programma is een verzameling van projecten die gecoördineerd worden uitgevoerd om voordelen te behalen die niet worden behaald als ze onafhankelijk gemanaged worden. Portfolio management is de selectie en ondersteuning van project of programma investeringen. Deze investeringen worden dan gestuurd door de strategische plannen en de beschikbare middelen van de organisatie. De scope van dit verslag ligt op de projectaanpak ten behoeve van de sturing en inrichting door een projectleider. Er zal daarom alleen gekeken worden naar projectmanagement. Productie en projecten zijn de twee verschillende manieren om werk uit te voeren. Deze verschillen voornamelijk in het feit dat productie doorlopend en herhalend is, terwijl projecten tijdelijk en uniek zijn. Een project kan dus gedefinieerd worden door deze twee karakteristieken: een project is een tijdelijke actie die ondernomen wordt om een uniek product of service te creëren. Tijdelijk betekent hier dat het een definitief begin en een definitief einde heeft. Uniek houdt in dat het project op een manier verschilt van elk ander project. (PMI, 2000) Projectmanagement betreft dan het aanwenden van kennis, kunde, instrumenten, en technieken voor project activiteiten om de project vereisten te bereiken. Om verder te kijken naar de projectfactoren die van belang zijn voor projectmanagement van een Reengineering project, zijn een aantal instrumenten nodig die gebruikt kunnen om deze factoren te achterhalen. Er worden er in dit verslag twee gehanteerd. De eerste is de dissertatie van Teun van Aken (2002), waarin hij een aantal verbanden voor projectsucces vastlegt. De tweede is een raamwerk van Shenhar en Dvir (2003), dat een classificatie voor projecten en bijhorende richtlijnen geeft. Deze studies zijn gestaafd op respectievelijk 41 en 600 projecten en worden besproken in de volgende paragrafen.

3.1.1 De weg naar projectsucces volgens van Aken Van Aken (2002) heeft een onderzoek gedaan naar projectsucces. Hij was benieuwd naar redenen voor falen van veel projecten, ondanks de uitgebreide kennis van management en instrumentarium (projecthulpmiddelen). Zijn onderzoek richtte zich op de factoren: aard van projecten, instrumentarium, en werkstijl. Er is gekeken wat deze factoren voor invloed hadden op het projectsucces. Deze factoren zullen hieronder besproken worden en er wordt afgesloten met de conclusies van van Aken en de koppeling met het begrip Reengineering. Er zijn definities voor harde en zachte projecten. Harde projecten zijn projecten met tastbare eindresultaten en zachte zijn projecten met niet tastbare eindresultaten. Van Aken vindt dit niet afdoende, aangezien er bijvoorbeeld een verschil zit tussen het bouwen van een brug of satelliet, maar de tastbaarheid niet anders is.

15


Daarom heeft hij een definitie van grijpbaarheid opgesteld. Deze definitie is: “de mate waarin de projectmanager invloed kan uitoefenen op zowel inhoud als verloop van een project.” Hij deelt deze vervolgens in drie dimensies:

1. Tastbaarheid (levert een project een tastbaar resultaat op of niet?) 2. Belanghebbenden (zijn er veel of weinig verschillende partijen betrokken bij de definitie of

specificatie van het eindproduct of bij de wijze waarop het project moet worden uitgevoerd?) 3. Betrokken disciplines. (Veel of weinig vakinhoudelijk disciplines)

Van Aken heeft hier een schaal voor gehanteerd, waarin er een waarde gekoppeld kan worden aan de grijpbaarheid. Deze schaal is opgenomen in Bijlage 3 . Het instrumentarium heeft van Aken (2002) ingedeeld volgens de leercyclus van Kolb. Deze bestaat uit denken, beslissen, doen en bezinnen. In Bijlage 3 zijn de instrumenten te vinden die onderkend zijn in zijn onderzoek. Werkstijl is door van Aken in twee factoren opgesplitst. Er zijn structurerende en doelgerichte werkstijlen. Om te bepalen welke gehanteerd worden, heeft van Aken voor beide een reeks contrastparen opgesteld. Deze zijn tevens opgenomen in Bijlage 3 . Een doelgerichte werkstijl wordt bepaald door de mate van directiviteit, strakheid in leidinggeven, en richtinggevend versus lassez-faire. Een structurerende stijl houdt in dat er structuur wordt aangebracht in het werk en de uitvoering. Het gaat hier voornamelijk om de beheersing van het werk. Projectsucces definiëren in termen van tijd, geld en opbrengst, zoals getracht door van Aken, loopt vast op het gegeven dat geen enkel project aan het eind datgene blijkt te zijn, in vergelijking met de ideeën bij de start, zelfs niet als alle overeengekomen wijzigingen onderweg worden meegenomen. De tevredenheid van de opdrachtgever is ook niet goed als maatstaf, deze zal immers tijdens het project ingrijpen om zijn belangen veilig te stellen. Daarnaast dient afgevraagd te worden of er sprake is van projectsucces wanneer de opdrachtgever tevreden is, maar de gebruikers niet. Uiteindelijk heeft van Aken een actordefinitie gebruikt, waarbij meerdere partijen een relatief belang in de schaal leggen van projectsucces. Deze actoren en hun criteria zijn opgenomen in Bijlage 3 Van Aken komt tot de conclusie dat het gebruik van methoden, technieken en instrumenten om projecten te beheersen, niet de prominente rol speelt voor het bereiken van succes, die de projectmanagementliteratuur wil toekennen. Van Aken vindt zelfs een negatieve correlatie tussen het gebruik van instrumenten en succes. Inzet van instrumenten en een structurerende werkstijl moeten situationeel gekozen worden: als doelgericht wordt gewekt, zijn instrumenten minder nodig en structurerend werken in grijpbare projecten is precies verkeerd. Ofwel; niet alles hoeft worden geregeld, gepland of beheerst; een zekere mate van chaos is nodig voor een goed lopend veranderingsproces. En mensen doen niet zonder meer wat een leider zegt, maar doen dat alleen als ze daar zelf de zin van inziet. Leiders die teveel beheersinstrumentarium inzetten zullen veelal contraproductief zijn, zeker wanneer ze een doelgerichte werkstijl hanteren. Het succes van leidinggeven wordt niet bepaald door het inzetten van veel beheersinstrumentarium. Het situationeel inzetten van beheersinstrumenten voegt van Aken dan ook toe aan de managementvaardigheden. Concreet noemt van Aken ook problemen met planning, risicoanalyse, budgettering en fasering in een adem. Deze hebben veel te maken met instrumenten Bij projecten waar deze problemen blijven moet er een analyse van de werkstijl op doelgerichtheid plaatsvinden. Als er doelgerichtheid is, zal er gekeken moeten worden naar het gebruik ervan. Wanneer de projectleider dit zelf veelvuldig doet, dan maakt hij de fout het allemaal zelf te willen regelen. Bij een doelgerichte werkstijl kan immers de inzet overgelaten worden aan de projectmedewerkers en uitvoerders.

16


Toegepast op reengineering kan nu nog slechts gekeken worden naar de grijpbaarheid (werkstijl en succes zijn niet generiek voor reengineering projecten). En dan is er sprake van de volgende eigenschappen bij een reengineering project: Een gemiddeld reengineering project zal een aantal verschillende disciplines hebben (Warren, 1999):

Project manager; Functionele expert van Legacy systeem; Legacy systeem ontwikkelaar; Ontwerper; Software Architect; Software ontwikkelaar; Tester.

Leggen we dit op de schaal van grijpbaarheid (zie Bijlage 3 ), dan zal dit op een ‘midden’ score uitkomen. Vervolgens kan gekeken worden naar de tastbaarheid van het resultaat. Deze is erg laag. Tot slot het aantal betrokken partijen dat in de categorie ‘midden’ valt. Er zal in het geval van wellicht gekeken kunnen worden naar een partner in dit soort projecten, wat dan uitkomt op een totaal van maximaal 3 of 4 komt voor een dergelijk project. Uiteindelijk komt hier voor een reengineering project op dit moment een score van 14 uit. Dit houdt in dat doordat er een relatief lage grijpbaarheid is, er bij voorkeur een structurerende werkstijl gekozen kan worden.

3.1.2 Projectclassificering volgens Shenhar en Dvir Shenhar en Dvir (2003) geven aan dat er behoefte is aan een classificatie voor projecten. De definitie van projecten (PMI, 2000) geeft namelijk al weer dat elk project anders is. De literatuur gaat er voornamelijk van uit dat projecten toch allemaal hetzelfde werken. Shenhar en Dvir stellen op basis van 600 projecten dat projectsucces zwaar leunt op de goede project management stijl en het aanpassen van die stijl aan het project. Er moet worden gekeken naar een aantal contingentiefactoren en Shenhar noemt hiervoor de factoren onzekerheid, complexiteit en tempo. De belangrijkste invloeden op deze factoren zijn de omgeving (intern en extern), het product (wat doet het, hoe doet het dat, etc.) en de taken (welk werk en welke deliverables zijn benodigd.) Om een goede projectmanagement stijl uit te kiezen, moet eerste de omgeving, product en taken gewaardeerd, vervolgens moet het project geclassificeerd worden naar onzekerheid, complexiteit en tempo en tot slot de juiste managementstijl gekozen worden. Er worden drie frameworks onderscheiden voor verschillende behoeften. Een op het strategische niveau, een op het project management niveau en een op project team niveau. Het projectmanagement niveau zal hier verder uitgewerkt worden, dit is namelijk relevant voor dit onderzoek.

Nieuwheid

Complexiteit

Tempo

Technologie

Blitz/Kritiek

Snel / Competitief

Normaal

Doo

rbra

ak

Pla

tform

Afg

elei

de

Super-H

igh-Tech

High-Tech

Medium

Tech

Low Tech

Array

Systeem

Assemblage

figuur 3.1 - framework Shenhar en Dvir (2003)

17


Het projectmanagement framework wordt neergezet in de vier dimensies; nieuwheid, complexiteit, onzekerheid en tempo. Deze zijn weer in meerdere vlakken te verdelen: Complexiteit Voor de mate van complexiteit hebben Shenhar en Dvir (2003) een drietal niveaus onderkend:

Assemblage projecten: projecten waarbij een aantal elementen, onderdelen of entiteiten worden samengevoegd in een geheel dat een functie kan uitvoeren.

Systeem projecten: projecten met betrekking tot een complexe verzameling van interactieve elementen en subsystemen, die samen een groot aantal functies kan uitvoeren.

Array-projecten: betreft grote, wijdverspreide verzamelingen van systemen. Voorbeelden zijn nationale lucht afweer systemen, telecommunicatie infrastructuren, etc.

Reengineering valt hier onder een systeem project; er zijn meerdere te koppelen onderdelen en er is een interactief geheel. Ook moet de oude en nieuwe applicatie naar alle waarschijnlijkheid een veelheid aan functies volbrengen. Het is wel relatief klein voor een system project. Er is dan vaak sprake van een veelvoud aan onderaannemers en duizenden activiteiten. De management stijl moet wat bureaucratischer en formeler opgesteld worden dan bij assemblage projecten. Ook zijn er veel financiële en planningpreviews met klanten en derde partijen. Nieuwheid De mate van nieuwheid is ingedeeld in afgeleide, platform en doorbraak producten. Binnen de theorie wordt de oorsprong en impact van de factor ‘nieuwheid’ niet genoemd. Ook wordt de nieuwheid van het product alleen gekoppeld aan markt doelen (marketing, product definitie, gegevens van de markt) en niet aan projectmanagement. Daarom zal deze factor hier niet verder meegenomen worden. Technologische onzekerheid De grootste onzekerheid is vaak de technologische onzekerheid en daarom wordt deze hier besproken. Een hogere mate van onzekerheid zorgt voor langere ontwikkelingsfasen, meer ontwerpcycli, meer testen en het laat bevriezen van het ontwerp. Er zijn de volgende typeringen:

Low-tech projecten: zijn gebaseerd op bestaande, doorontwikkelde technologie. (constructie, bouw)

Medium-tech projecten: gebruiken bestaande technieken, maar ook nieuwe technologie of mogelijkheden die hiervoor niet gebruikt zijn.

High-tech projecten: projecten waarin de meeste technologieën nieuw zijn, maar al wel bestaan op het moment dat het project begint.

Super High-tech projecten: projecten die gebaseerd zijn op nieuwe technologieën die nog niet bestaan bij de start van het project.

Reengineering kan in de categorieën medium-tech en high-tech geplaatst worden. Voor een reengineering project kan het noodzakelijk zijn om specifieke tools te maken. De technologie bestaat dan al, maar er is een nieuwe toepassing. Het project is dan High-tech. Wanneer reengineering uitgevoerd wordt met de middelen die beschikbaar zijn valt het eerder onder medium-tech projecten. Voor medium-tech projecten geld dat veranderingen aan het ontwerp beperkt moeten blijven en het ontwerp moet redelijk snel worden bevroren. De stijl die gehanteerd zou moeten worden bij initiëren van het project zou flexibel moeten zijn, aangezien er nog veranderingen kunnen komen. Later zal moeten worden voorkomen dat er veranderingen komen, dus zal het management wat strakker moeten zijn. Motto is hier: “beperk veranderingen tot een minimum en bevries het ontwerp zo snel mogelijk”. Er moet meer gecommuniceerd worden dan bij low-tech projecten en er moet ietwat informeel gecommuniceerd worden. De manager moet wat technische bekwaamheid hebben en er moet een zekere mate van professionals betrokken zijn. High-tech projecten zijn gekenmerkt door een langere periode van ontwerp, ontwikkeling, testen en redesign. Het bevries stadium zou moeten worden neergezet op de helft of ¾ van het project. De management stijl moet een flexibelere insteek hebben, aangezien de verschillende ontwerpen kunnen zorgen voor meer verandering. Er zal meer communicatie langs meerdere wegen moeten gaan, vooral veel informele communicatie. De projectmanager zal hier behoorlijk technisch onderlegd moeten zin, er zullen veel professionals betrokken zijn.

18


Tempo Voor het tempo worden drie varianten onderscheiden:

Normaal: Tijd is niet kritiek voor het slagen van het project. Vaak betreft dit projecten met een lange termijn of infrastructuur doeleinde.

Competitief: De meest gangbare projecten zijn competitief. Zijn bedoeld om een markt mogelijkheid te benutten, een strategische positie te benutten, of een nieuwe richting in te slaan met het bedrijf.

Blitz/ Kritiek: Urgente tijdkritische projecten. Het behalen van planning is kritiek en vertraging betekent dat het project faalt. Het redden van de apollo 13 bemanning wordt door Shenhar en Dvir als voorbeeld gebruikt.

Reengineering inspanningen zullen in een normaal tempo vallen. Het voornaamste doel van reengineering is kostenbesparing en het verkrijgen van flexibiliteit. Het kan echter ook naar competitief / kritisch neigen. Wanneer er een verandering in de applicatie nodig is om het bedrijf te laten draaien, heeft een reengineering project een behoorlijk kritische deadline. Dit punt is dus bijzonder afhankelijk van de motivatie van een reengineering inspanning. Voor een inspanning die in een normaal tempo uitgevoerd wordt, kan er gesteld worden dat er minder procedures benodigd zijn. Wanneer het project tijdkritisch is, mag er geen bureaucratisch geheel zijn, snelle beslissingen moeten snel door gevoerd kunnen worden. Verder geven Shenhar en Dvir (2003) duidelijk aan dat een project uniek is en dat ieder project een andere managementstijl nodig heeft. Doordat er echter veel voorbeelden gebruikt worden en de definities ook bijzonder concreet zijn, is het echter moeilijk om diensten te classificeren. Reengineering is hierbij altijd maatwerk en is daarom nog lastiger om generiek in te vullen. Ook is de methode van Shenhar en Dvir er een die erg afhankelijk is van de persoon die de inschatting doet en hierdoor niet 100% zuiver te noemen. Er valt wel te stellen dat naar mate een factor groeit, er gevolgen zijn voor de managementstijl: meer onzekerheid heeft een flexibelere stijl van management nodig. Doordat de basis echter 600 projecten betreft, wordt het raamwerk toch als waardevol gezien. Er is nu vastgesteld hoe het projectmanagement van een reengineeringproject zou moeten zijn. In de volgende paragraaf zal ingegaan worden op de inrichting van het proces.

3.2 Proces van Reengineering

Het reengineering proces is door een aantal auteurs beschreven. De eerste die een aanpak formuleerde is het Departement of Defense geweest. Deze was echter alleen voor het inschalen van de huidige systemen en het bepalen van de relevantie voor een bepaalde strategie. In 1999 heeft er een ESPRIT (een EU informatie technologie programma) project plaats gevonden dat beoogde een methode op te zetten voor reengineering in zijn geheel. Deze methode is vervolgens Renaissance gedoopt. Tot slot is er in 2003 een methode door de Software Engineering Institute (SEI) opgezet, die een lange historie hebben met reengineering. De kernfactoren om op te concentreren binnen het reengineering proces zijn ingegeven door een vergelijk van de praktijkcase met de software cyclus van StepWise. (een samenvatting hiervan is gegeven in Bijlage 2 ) Hieruit kwam naar voren dat er specifieke aandacht nodig was voor risico, activiteiten indelingen en kosten. Dit is ook bevestigd door de opdrachtgever. Daarom zullen ook de volgende paragrafen ingaan op respectievelijk activiteitenindelingen, kosten, opbrengsten en risico’s.

3.2.1 Activiteiten Voor het behandelen van de activiteiten kan er eerst ingegaan worden op de portfolioanalyse die door veel auteurs benoemd wordt (Boreel en Franken, 1997; Warren, 1999; DoD, 1997; Seacord et al., 2003) Vervolgens wordt gekeken naar een verdere selectie van reengineeringactiviteiten zoals beschreven door het Departement of Defense (1997). Vervolgens worden respectievelijk de methoden Renaissance, Risk Managed Modernization en een aantal Implementatietechnieken langsgelopen. 3.2.1.1 REENGINEERING PORTFOLIO ANALYSE

19


Om een inzicht te hebben in de applicaties binnen een bedrijf, biedt een reengineering portfolio analyse (RPA) een uitkomst. Een uitgebreide RPA vraagt echter om veel data die in de organisatie aanwezig is. Deze informatie is er vaak niet. Sneed (1991) geeft een lijst van attentiepunten voor applicaties om te kijken of ze wellicht in aanmerking voor vervanging komen. Hiermee kan dan een eerste selectie worden gemaakt van mogelijke kandidaten voor reengineering. De volgende applicaties zouden in overweging genomen moeten worden:

Er komen vaak fouten voor in de applicatie; De code is meer dan 7 jaar oud; Programma structuur en logische flow zijn te complex; Programma’s zijn geschreven voor voorgaande hardware versies; Programma’s draaien in emulators; Module of unit routines zijn excessief groot geworden; Grote hoeveelheden resources zijn nodig om het systeem te laten draaien; Hardgecodeerde parameters moeten veranderd worden in het onderhoud; Het aanhouden van de onderhoudsmensen wordt moeilijk; Documentatie is niet up-to-date; Ontwerp specificaties zijn verloren of niet compleet/verouderd.

Om ook het belang van de applicatie voor het bedrijfsproces mee te nemen, kan er naar een RPA gekeken worden. Boreel (1996) biedt hiervoor een simpele analyse op basis van technisch(e) waarde/risico en de bedrijfswaarde. In onderstaande tabel kan worden gekeken naar het technische risico.

Hoog Risico (10 punten)

Gemiddeld Risico (5 punten)

Laag risico (0 punten)

Leeftijd > 15 jaar 5 tot 15 jaar < 5 jaar Percentage aangepast 30% 10% tot 30% < 0% Architectuur Batch On-line host Client/Server Onderhouds ratio >20% 10% tot 20% <10% Ontwikkeltaal Assembler Cobol 4GL, C, C++, Java Database laag Flat File of geen Netwerk/Hiërarchisch RDBMS Aantal hard-wired interfaces >5 3 tot 5 < 3 Applicatie kennis beschikbaar Bron Code Oorspronkelijke

ontwikkelaars Complete documentatie

tabel 3.1 - portfolio analyse: technisch risico (Boreel, 1996)

Voor de bedrijfswaarde kan gekeken worden naar andere waarden: Veel kansen (10

punten) Gemiddelde kansen (5

punten) Lage kansen ( 0

punten)

Kansen voor omzetstijging Directe rol Ondersteunende rol Geen rol Decibel niveau van aanvragen Must-have Want-to-have Nice-to-have of geen Frequentie van aanvragen Een keer in de week of

meer Een keer in de maand Eens per jaar of nooit

Hoogste aanvrager Directie Management Werkvloer Hoeveelheid BPR in de omgeving van de applicatie

Multi miljoenen reengineering

Organisationele verandering

Weinig tot geen

tabel 3.2 - portfolio analyse: bedrijfswaarde (Boreel, 1996)

20


Als de scores van de antwoorden zijn opgeteld, kunnen de technische kwaliteit en bedrijfswaarde tegen elkaar worden uitgezet in een figuur:

figuur 3.2 - portfolio analyse (Boreel, 1996)

De vervangingskandidaten moeten bovenaan de prioriteitenlijst worden neergezet en nader worden bekeken om te reengineeren. De werkers kunnen blijven draaien in de organisatie. Dit zijn stabiele applicaties met weinig risico met een toegevoegde waarde voor de organisatie. De tijdbommen zijn applicaties die technisch risicovol zijn en voor relatief weinig bedrijfswaarde zorgen. Deze zouden bijvoorbeeld goede kandidaten zijn voor outsourcing. De componentmogelijkheden zijn applicaties die technisch gezond zijn en onbenut potentieel kunnen hebben. Hierbij kunnen standaard applicaties worden ingezet en modules worden vervangen om beter aan te sluiten. Uiteraard is deze waardering niet volledig en biedt deze geen garantie dat een applicatie vervangen moet worden. Talen als PL/I, SAS en JCL worden niet meegenomen, vele tussenmogelijkheden worden niet bekeken, maar globaal geeft het wel een basis om een verdere analyse te doen. Op basis van de kandidaten die voortkomen uit een dergelijke analyse, kan gebruik gemaakt worden van de assesment methode die aanbevolen wordt in de Software Reengineering Assesment Handbook (Departement of Defense, 1997). 3.2.1.2 SOFTWARE REENGINEERING ASSEMENT De Software Reengineering Assement (SRA) is ontwikkeld door het ministerie van defensie van de Verenigde Staten (Departement of Defense, 1997). Deze methode biedt voornamelijk een methodiek om systemen te prioriteren en te selecteren en de vorm van reengineering te kiezen. De methode bestaat uit de volgende onderdelen:

1. Reengineering Technical Assesment (RTA); dit betreft de technische waardering van de verschillende software die gezien wordt als kandidaat voor reengineering strategieën.

2. Reengineering Economical Assesment (REA); de evaluatie van de verschillende strategieën en de selectie op basis van economische factoren.

3. Reengineering Management Decision process (RMD); uiteindelijke waardering van technisch, economisch en andere factoren.

Reengineering Technical Assesment De reengineering technical assesment wordt uitgevoerd volgens de volgende stappen: 1. Het waarderen van het voorbereidingsniveau van de organisatie om te reengineeren;

In deze eerste stap is het nalopen van een checklist met verschillende vragen, die op een drie puntsschaal worden gewaardeerd. Wanneer het gemiddelde hoger is dan 2, is de organisatie gereed voor het uitvoeren van een verandertraject.

21


2. Identificeren van kandidaat-software; deze identificatie wordt globaal verricht op basis leeftijd, onderhoudbaarheid, verouderde taal, etc. Deze stap is in principe al uitgevoerd door het uitvoeren van de reengineering portfolio analyse zoals besproken in de vorige paragraaf. De SRA geeft hiervoor ook een aantal beperkte indicatoren.

3. Beperken van de lijst om de haalbaarheid voor reengineering te bepalen; alle software die niet voldoet aan de volgende eisen dient van de lijst gehaald te worden:

a. Resterende levensduur is minder dan drie jaar; b. Kandidaat software is niet belangrijk genoeg (checklist voor aanwezig); c. Kandidaat software is minder dan 5 jaar geleden ontwikkeld; d. De kandidaat-software ondersteund een bedrijfsproces dat momenteel gereengineerd

wordt. 4. Vragenlijsten doorlopen en de strategieën bepalen;

De verschillende toepassingen van reengineering die door de SRA worden onderkend hebben elk een vragenlijst. Dit zijn retargeting, redocumenting, broncode vertaling en data reengineering. De vragenlijsten hiervan worden wederom in een driepuntsschaal weergegeven. Wanneer het gemiddelde onder de 1,7 uitkomt, luidt het devies om een strategie niet uit te voeren. Tussen de 1,7 en 2,4 moet het overwogen worden en wanneer er meer dan 2,4 als resultaat uitkomt, zal het definitief plaats moeten vinden. Deze vragenlijsten zijn opgenomen in Bijlage 4 .

5. Overwegen van alternatieve en extra strategieën; hieronder vallen de strategie reverse engineering, redevelopment en continued maintenance (status quo) Reverse engineering wordt hier apart genomen door de SRA omdat het gezien wordt als een erg kostbare strategie, die slechts in drie gevallen uitgevoerd moet worden:

a. wanneer er meerdere strategieën uitgevoerd moeten worden, waarbij reverse engineering een sterk ondersteunende rol kan spelen

b. wanneer de werking van de huidige programmatuur te ondoorzichtig is. Op basis van de gemiddelde 70% van het proces die nodig is voor het software begrip, kan het dan verantwoord zijn om reverse engineering toe te passen om sneller duidelijkheid te verkrijgen.

c. Wanneer het hergebruik van software een kern doel is bij het project. Doordat er gedeeltes kunnen worden opgeslagen en inzichtelijk gemaakt kunnen worden, kan deze informatie ook gebruikt worden bij het hergebruik van de onderdelen van de legacy.

De reden waarom deze strategie als kostbaar wordt gezien komt door de definitie die gehanteerd wordt. Er wordt uitgegaan dat het ontwerp op een niveau hoger kan worden gerepresenteerd, maar ook in een dergelijke vorm dat er op dat niveau wijzigingen kunnen worden doorgevoerd. Redevelopment valt in principe buiten het kader van reengineering. De applicatie is hier zo vervallen dat er gekeken moet worden naar het compleet herontwikkelen van de applicatie. Wanneer er drie strategieën aangemerkt worden om uit te voeren en de nog te verwachten levensduur is meer dan 5 jaar, wordt geadviseerd om redevelopment te overwegen. Dit advies geld sterker naar mate de kosten van reengineering in de buurt komen van redevelopment.

6. Documenteren van de RTA Binnen deze stap wordt het een en ander vastgelegd als document en wordt deze fase afgerond.

Reengineering Economical Assesment Het doel van de REA is niet perse om nauwkeurige kostenschattingen te maken. Het voornaamste doel is dat er informatie geboden wordt, op basis van welke er een beslissing gemaakt kan worden. Het biedt dus voornamelijk een waardering die voor prioritering van de kandidaten onderling inzicht geeft. Omdat de REA geen concrete kostenmethode voorstelt, zal er apart ingegaan worden op de kostenberekening in paragraaf 3.2.2. Deze kan dan in plaats van de REA gebruikt worden. Reengineering Management Decision Dit gedeelte voorziet in de documentatie en de daadwerkelijke beslissing van de SRA en bestaat uit de volgende stappen:

22


1. Voorbereiden management rapport; 2. Selecteren van reengineering projecten en vaststellen van project prioriteiten; 3. Implementeren en documenteren van de RMD.

Deze methode is voorzien van veel documenten, checklists en vragenlijsten. Hierdoor is het gebruik van deze methode heel sturend. Op basis van al deze gegevens kan een beslissing genomen worden om een van de verschillende vormen van reengineering te kiezen, zoals onderscheiden door deze handleiding. Wanneer er een strategie is gekozen met behulp van de SRA, kan er gekeken worden naar welke activiteiten er uitgevoerd moeten worden. In de volgende paragrafen zal daarom gekeken worden naar de Risk Managed Modernization (RMM) en de Renaissance methode. 3.2.1.3 RISK MANAGED MODERNIZATION (SEACORD ET AL, 2003) Seacord, Plakosh en Lewis (2003) hebben een methode opgesteld om het legacy probleem op te pakken. Deze methode hebben zij Risk Managed Modernization (RMM) gedoopt. Deze methode stuurt op risico en geeft een aanpak vanaf een portfolio analyse tot uitvoering, dus concentreert zich voornamelijk op de planning. Alvorens de stappen doorlopen worden wordt er een portfolio analyse uitgevoerd zoals al eerder besproken in dit hoofdstuk. Vervolgens is hier een grote overlap met de Renaissance methode, maar wordt er nadruk gelegd op de stakeholders, vereisten en het begrip. In het kort bestaat de methodiek uit de volgende stappen: 1. Het identificeren van de stakeholders;

De verschillende stakeholders zullen de uitkomst en impact van de reengineering inspanning bepalen. Het is daarom belangrijk dat eerst vastgesteld wordt wie de stakeholders zijn.

2. Begrip krijgen van de vereisten; Het duidelijk krijgen van de vereisten op gebied van gebruikers, systemen, beperkingen en non-functionaliteit zorgt voor een vermindering van het risico.

3. Het maken van de business case; De business case moet de beslissing maken ondersteunen. Om een goed beeld te geven, zouden er verschillende mogelijkheden moeten aangedragen worden en tegen elkaar uitgezet worden.

4. Begrip krijgen van de legacy/ begrip krijgen van de doeltechnologie; Het begrip van het legacy systeem is een essentieel onderdeel voor het succes van de reengineering inspanning. De uitdaging ligt hier in de efficiënt, planningsgericht en kosteneffectieve manier van het begrip krijgen. Hiervoor maakt Seacord et al (2003) gebruik van het horseshoe-model. Dit model wordt verder uitgewerkt in paragraaf 3.3.1Begrip verkrijgen van de doeltechnologieën is ook essentieel aangezien dit ook een vaste variabele is (kosten, tijd en kwaliteit kunnen onderling uitgewisseld worden. Doel technologie en legacy software staan echter vast). Op deze technologieën zal verder worden ingegaan in 3.3.2.

5. Evalueren v/d technologie; In deze stap kunnen de verschillende technologieën vergeleken worden. Wanneer de oplossingen elkaar overlappen, moet er gekeken worden naar de kwaliteit die ze bieden. In deze stap worden de onderdelen bepaald die deel gaan uitmaken van de architectuur.

6. Bepalen van de doel architectuur; De doelarchitectuur moet een technische weergave zijn van het toekomstige systeem. Bij incrementele implementaties zal er plaats zijn van voortschrijdend inzicht in de legacy en zal de doelarchitectuur dan ook herevalueerd moeten worden.

23


7. Bepalen van de modernisatie strategie; De modernisatie strategie bepaald hoe er van de legacy over wordt gegaan naar het deelsysteem. Aangezien dergelijke reengineering inspanningen lang kunnen duren, is het niet raadzaam om een groot risico te lopen met een revolutionaire overgang. Daarom zijn de overgangen vaak incrementeel en dient hier een gedegen plan voor te zijn. Tegelijkertijd moet er gekeken worden naar het minimaliseren van de kosten, maximaliseren van de kwaliteit, etc.

8. Terugkoppelen met de behoeften van de stakeholders; Gezien de verschillende belangen van de stakeholders, is het relevant om de modernisatie strategie kort te sluiten met hen. De afweging van de verschillende aspecten kan misschien anders ingepakt worden (bijvoorbeeld een snellere afronding ten koste van kwaliteit).

9. Inschatten van de resources; Hier worden de kosten en de inzet door mensen bepaald. Wanneer deze stap goedgekeurd wordt, kan het proces beginnen. Wanneer het niet goedgekeurd wordt, kan het nodig zijn sommige stappen opnieuw door te lopen.

Uiteindelijk is dan het plan klaar en kan het modernisatie traject starten. Er zal dan verder gekeken moeten worden naar de volgende stappen, die na de planning aan bod komen. Deze stappen worden in de volgende paragraaf besproken bij de Renaissance methode. 3.2.1.4 RENAISSANCE (WARREN, 1999) De renaissance methode geeft een schema voor het doorlopen van evolutie, en voor het handhaven van evolutie van software. De fasen planning, implementatie, oplevering en uitrol worden hierin gedefinieerd. Elke fase heeft zijn activiteiten. In Bijlage 5 staat deze methode grafisch weergegeven. De fasen van Renaissance worden hieronder kort doorlopen. Evolutie planning In het eerste stadium wordt een portfolioanalyse uitgevoerd als in paragraaf 3.2.1.1. De startup van de methode geeft de gelegenheid om de methode aan te passen aan de organisatie. Activiteiten kunnen veranderd of anders geordend worden en de uitvoering van de verschillende activiteiten kan aangepast worden. Er moet gekeken worden naar de bedrijfsdoelen en naar de noodzaak van evolutie. Ook moet er informatie vergaard worden over het legacy systeem. Gelijktijdig moet er begrip komen voor het bedrijfsproces dat ondersteund wordt door de aanwezige legacy. Hierdoor kan het risico worden ontlopen dat er proceskennis verloren gaat tijdens het uitvoeren van de reengineering. Vervolgens kan het huidige systeem geanalyseerd worden. Deze analyse kan op detail niveau of hoog niveau plaatsvinden, op basis van de balans tussen kosten en risico. Tot slot kan er een analyse gemaakt worden van de verschillende reengineering alternatieven die onderkend worden. Deze alternatieven moeten worden afgewogen op risico, kosten en baten. De output van deze fase is een evolutie strategie, met kennis van de huidige situatie en een gekozen alternatief voor de toekomst. Implementatie De eerste activiteit hier betreft het plannen van het reengineering traject. Hieronder valt het inzetten van mensen, onderkennen van taken en afhankelijkheden, et cetera. In dit gedeelte moet ook rekening gehouden worden met de risico’s en de kosten zoals later besproken wordt. (paragraaf 3.2.2 en 3.2.3) Er zijn verschillende taken afhankelijk van de gemigreerde data. Het is daarom verstandig om ook een teststrategie parallel te ontwikkelen. Bij het ontwerpen van het doel van reengineering kan er een context en een technisch model gemaakt worden. In deze ontwerpen moet ook rekening gehouden worden met de hoeveelheid hergebruik (op basis van de gekozen reengineering richting). Vervolgens kan het uitvoeren en testen iteratief plaats gaan vinden. Parallel aan deze stappen moet het voorbereiden van de doelomgeving plaatsvinden. Dit is een activiteit die weinig tijd in beslag neemt, tenzij er sprake is van een overstap van mainframe naar pc-servers. Oplevering, uitrol en in gebruikname Tijdens deze fasen geeft de evolutiestrategie doorslag op welke manier het een en ander aan activiteiten wordt uitgevoerd. Er zijn drie mogelijke opleveringen:

24


1. Incrementeel; tijdens het reengineering van een component, wordt een nieuwe systeemversie gemaakt die het betreffende component integreert.

2. Gelijktijdig bestaan van legacy en doel; wanneer er overgestapt wordt op een andere implementatietechnologie is het meestal niet haalbaar om optie 1 te hanteren. Er zijn dan twee mogelijkheden: a) Incrementeel vervangen van het legacy systeem met doelsysteem onderdelen; bij deze

methode draaien twee incomplete systemen naast elkaar. Wanneer alle doelcomponenten klaar zijn, kan de legacy vervangen worden.

b) Parallel laten draaien van legacy en doel systeem; Deze optie verschilt van a, doordat er geen bestaande legacy componenten worden vervangen, alleen het doelsysteem wordt langzamerhand opgebouwd.

Beide opties hebben als gevolg dat het consistent houden van de data een kwestie is. 3. Big Bang; hierbij wordt het legacy systeem uitgeschakeld en het nieuwe systeem ingezet. Het

nadeel hiervan is, dat er altijd een periode is waarin er geen ondersteuning van het systeem is. Omdat het onderscheid nogal nauw luistert, zijn deze methoden grafisch weergegeven in figuur 3.3.

figuur 3.3 - verschillende vormen van migratie

Voor het continu in dienst blijven van het systeem is de eerste mogelijkheid ‘incrementeel’ de meest aan te raden methode. Bij herstructurering van de code zou deze methode goed bruikbaar zijn. Wanneer overgegaan wordt naar een andere technologie (andere taal, of platform) is deze methode echter niet te handhaven. Wanneer het verschil tussen legacy en doelsysteem te groot is, kan optie 2 een goede strategie zijn. Dit geldt voornamelijk wanneer het systeem veel berichtenverkeer heeft, waardoor er gemakkelijk subsystemen te onderscheiden zijn. Een inkoop module kan dan bijvoorbeeld op het nieuwe systeem draaien, terwijl de voorraadmodule nog op het legacy systeem draait. Wanneer het systeem onderling te afhankelijk is, kan er gekozen worden voor Big Bang uitrol. Een goede planning moet dan zorgen voor een minimale verstoring bij deze migratie. Als het een en ander uitgerold is, is er sprake van een evolutionair systeem volgens de methode. Er moet proactief worden ingesprongen op vernieuwingen en de veranderingen in de organisatie en systeem moeten gedocumenteerd worden voor de verdere evolutie. Tot slot is er een evaluatie van het systeem door de gebruikers, waar de feedback van meegenomen moet worden voor de volgende versie in de evolutie. De renaissance methode leunt tot slot zwaar op een document management systeem, waarbij alle documenten centraal worden opgeslagen en bijgewerkt. Voor dit onderzoek valt dit buiten de scope, daarom zal er hier niet verder op ingegaan worden. De stap implementatie en uitrol behoeven meer specifieke informatie en daarom zal in de volgende paragraaf ingegaan worden op de verschillende methoden die hiervoor bruikbaar zijn.

25


3.2.1.5 IMPLEMENTATIETECHNIEKEN Brodie en Stonebraker (1993) onderkennen twee vormen van migratie, namelijk de evolutionaire en revolutionaire variant. Deze worden respectievelijk Chicken Little en Cold Turkey genoemd. Bij Cold Turkey wordt uitgegaan van de nieuwbouw van de bouw van een applicatie binnen een nieuw technologisch kader, waarna er een datamigratie is (bijvoorbeeld in het weekend) en vervolgens de nieuwe applicatie functioneel is. Dit lijkt een aardige methodiek, maar herbergt een veelvoud aan risico’s. Deze aanpak is feitelijk gelijk aan de strategie: ‘herontwikkelen’ van Warren. Voor de ontwikkelmethode worden een veelvoud aan problemen onderkend: er moet nieuwe functionaliteit toegezegd worden, de bestaande applicatie verandert tijdens het proces, specificaties van het systeem ontbreken, etc. Door bovenstaande risico’s is het vaak niet raadzaam om een dergelijk revolutionair pad te volgen. Daarom is de Chicken Little aanpak bedacht. Deze methode is een aanpak voor de 2e methode (mogelijkheid a) van Warren. Bij een reengineering inspanning volgens de Chicken Little methodiek, zal de ondersteuning van het bedrijfsproces een bepaalde tijd verzorgd worden door het legacy-systeem en het nieuwe systeem samen. Dit samengestelde systeem bestaat dan uit onderdelen van het legacy systeem en onderdelen uit het nieuwe systeem. Deze worden aan elkaar gekoppeld met behulp van gateways. Tijdens het reengineeren zal het onderhoud op oude onderdelen doorgaan totdat het onderdeel is vervangen. Ook gerealiseerde onderdelen moeten worden aangepast om te reageren op veranderingen in de omgeving. Gateways schermen de verschillende componenten af, zorgen voor de communicatie tussen componenten en coördineren verschillende componenten. Hierdoor kunnen onderdelen ingevoegd worden, zonder dat andere onderdelen moeten veranderen. Omdat er uitgegaan wordt van een jarenlange planning is het niet zinnig om een gedetailleerd ontwerp te maken. Daarom wordt gekozen voor een globale planning met detailontwerpen voor deelopleveringen. Door Wu et al (1997) is een vernieuwde methode opgezet. Zij constateerden hetzelfde gebrek aan de ‘Chicken Little’ methodiek en hiernaast de complexiteit van de verschillende gateways die gemaakt moeten worden. Hierom is de methode van Wu et al (1997) opgezet zonder gateways. Het hoofddoel van de methode is dan ook dat het de behoefte weghaalt om tegelijkertijd het doelsysteem als het legacy systeem te benaderen. En hierom hoeft de consistentie ook niet bewaard te blijven. De methode is: ‘The butterfly methodology’ gedoopt. Teneinde zonder gateways te werken, moeten er een aantal nieuwe concepten geïntroduceerd te worden. Deze zijn de data-access-allocator (DAA) en de data-transformatie-tool. Om nieuwe componenten te kunnen ontwikkelen in de doelomgeving, kan er een representatieve set data al in een tijdelijke opslag worden opgezet in de doeldatabase. Wanneer de migratie begint, wordt de legacy data bevroren en wordt het een alleen lezen dataopslag. Alle transacties die er op worden uitgevoerd, worden door de DAA herplaatst naar enkele series van Tijdelijke Opslagplekken (TS1 tot TSn). Door de DAA wordt de data in de laatste tijdelijke opslag opgeslagen, en uit de goede tijdelijke opslag verkregen. Een data-transformeer-tool zet de legacy data naar het doelsysteem. Deze tool is verantwoordelijk voor het correct omzetten van de oude data naar het nieuwe databaseschema. Eerst zal alle data worden overgezet vanuit de bevroren legacy data opslag. Tijdens deze migratie, schrijft de DAA alle veranderingen naar de eerste tijdelijke opslag. Wanneer alle data is gemigreerd, kan de eerste tijdelijke opslag worden bevroren en kan deze worden overgezet. De DAA schrijft dan de transacties naar de tweede tijdelijke opslag. Tijdens het herhalen van dit proces, wordt de tijdelijke opslag steeds kleiner. Als het kleiner is dan een bepaalde grenswaarde, kan het systeem tijdelijk uit de lucht gehaald worden, zonder ernstige gevolgen te hebben voor de core-business.

26


In 2003 is er door Bianchi et al (2003) gekeken naar de verschillende bestaande methodieken en is er vastgesteld dat de bestaande methoden gebreken hebben. De methode is gelijk aan de chicken little en de butterfly methodologie, in de zin dat het gebruik maakt van stappen en het proces in delen wordt doorlopen. Dit zorgt er bij alle methoden voor dat het gebruik van het systeem niet onderbroken hoeft te worden tijdens het reengineeringproces en dat het onderhoud dat moet plaatsvinden aan de applicatie, kan plaatsvinden, behalve aan het component dat op het moment reengineerd wordt. De auteurs wijzen Chicken Little van de hand, omdat bij deze methodiek er een gelijktijdig bestaan is van legacy data en doel data. Hiernaast geeft Chicken Little geen specifieke data reengineering aanpak, waardoor er mogelijkheden zijn voor data in de nieuwe database als in de oude. Dit houdt in dat de data zowel uit de legacy database als uit de doel database gehaald moet worden en dat er dus 2 database benaderd moeten worden. Ook zijn veel complexe functies die in huidige databases (triggers, consistency contraints, etc.) zitten, niet aanwezig in Legacy databases en kunnen dus niet door nieuwe applicaties gebruikt worden. Dit zorgt ervoor dat het lastiger wordt om de consistentie te bewaren. De butterfly methodologie heeft als nadeel dat er een bevroren database is en een database waarin verschillende mutaties in bijgehouden worden. Dit zorgt tevens voor het benaderen van verschillende databases en kan zorgen voor een performance verlaging. Ernstiger is echter dat deze methode geen mogelijkheid geeft om de legacy functionaliteiten gelijktijdig te laten bestaan met de nieuwe/reeengineerde componenten. De iterative reengineering aanpak heeft oplossingen voor bovenstaande problemen; 1. Er is geen sprake van dubbele waarden in databases, hiervoor draagt de ‘DataBanker’ zorg. 2. De reegineerde data bevindt zich in een doelsysteem, dat voorzien is van moderne technologie, ook

al wordt deze niet ondersteund door het legacy systeem 3. Zowel het legacy systeem als het reengineerde systeem kunnen functies en data delen. In figuur 3.4 is de architectuur weergegeven van de iterative reengineering aanpak, terwijl een reengineering inspanning wordt uitgevoerd. De user interface voert de requests van de gebruikers door naar het juiste component dat aangesproken moet worden. De legacy componenten hebben een direct contact met de legacy databases. Voor de herstelde componenten (de componenten met oude structuur en nieuwe koppeling naar databanker) en voor de nieuwe en gereengineerde componenten, is er een interface met de databanker. Deze heeft beschikking over metadata. In deze metadata is de structuur en de locatie van de data aangegeven. Wanneer componenten de databanker aanroepen, zal deze met behulp van deze de data ophalen vanuit de nieuwe database. Wanneer het data betreft vanuit de oude of tijdelijke database, zal het de aanvraag doorsturen naar data locator, die de data zal verkrijgen.

figuur 3.4 - architectuur iterative reengineering (Bianchi et al, 2003)

27


De belangrijkste voordelen van deze aanpak zijn dat zowel de reengineerde componenten en legacy componenten kunnen gelijktijdig bestaan en werken. Hiernaast is de data gereengineerd, in plaats van alleen gemigreerd. Er kan geconcludeerd worden dat er vooruitgang is in de inzichten met betrekking tot de verschillende aanpakken voor een reengineeringtraject. Het nadeel aan de verschillende methoden is dat er weinig case-materiaal en dus weinig empirisch bewijs voor deze methoden bestaat. Logischerwijs zitten in de argumenten een verbetering van cold turkey naar chicken little, naar butterfly methodology, naar iterative reengineering. De laatste zal dan ook gehanteerd worden als houvast en aan te raden aanpak. Het stappenplan van deze methodiek is opgenomen in Bijlage 9 .

3.2.2 Kosten en opbrengsten voor reengineering Olsem en Sittenauer (1992) kijken in 1992 al naar het verschil dat in de kosten zal moeten optreden doordat er bij reengineering geen sprake is van nieuwe vereisten. Hierdoor blijven ze de verhouding onderkennen tussen ontwerp bouw en testen. De verhouding ontwerp-bouw-test is dan 40-20-40. Er wordt echter niet veel verder gekeken en een kosten model komt hier nog niet uit de verf. Voor het justificeren van een software reengineering project, zal er feitelijk aangetoond moeten worden dat de software beter te onderhouden is, makkelijker aan te passen en een hogere betrouwbaarheid heeft. Hiervoor moeten de huidige kwaliteit, huidige onderhoudskosten en huidige bedrijfswaarde bepaald worden. Later zullen deze eigenschappen vergeleken moeten worden met de nieuwe eigenschappen. Voor dit traject zou idealiter eerst een metriekenplan opgezet moeten worden. (Sneed 1991, 1995) Kostenbesparingen Voor de besparingen zijn er empirische gegevens waarbij COBOL programma’s restructured zijn en reengineered (Sneed, 1991). Bij restructuring zijn er onderhoudsbesparingen van 18% en 21% voor respectievelijk adaptief en perfectief onderhoud geconstateerd. Ook was er impact op het onderhoud van andere onderdelen (24% en 29%). Tot slot werd er geconstateerd dat hierdoor ook 36% minder fouten zijn ingevoerd door het onderhoud. De resultaten van besparing voor reengineering zijn nog hoger: 42% besparing op adaptief onderhoud en 32 % op perfectief onderhoud. Ook zijn er metrieken getrokken vanuit het programma dat is blijven bestaan en het programma dat is reengineered. Na reengineering is de complexiteit (cyclomatic complexity alswel de data complexity) lager. Uiteindelijk is er een resultaat geboekt waarin er met 33% minder inzet de applicatie onderhouden kan worden. Besparingen die ook dienen meegenomen te worden in de onderhoudsbesparingen zijn:

Lagere kosten door besparen van tijd en inspanning per onderhoudstaak; Lagere kosten door het vervangen van senior personeel door junior personeel; Lagere kosten door een beperking van de tijd die fouten in beslag nemen (downtime); Lagere kosten voor het inhuren en trainen van nieuw personeel; Lagere kosten van verloren kansen, doordat capaciteit vrijgemaakt wordt van onderhoud;

De kostenbesparingen zijn niet altijd even goed meetbaar. Naast reengineering kan het ook komen door een verhoging van de kwaliteit van de medewerkers, betere methoden, of het Hawthorne effect: dingen die bestudeerd zijn verlopen beter. Kosten van Reengineering Kostenschattingen kunnen op een aantal wijzen verricht worden (Musser, 2002). Deze methoden zijn:

Top-down schatting ( op basis van algemene karakteristieken) Bottom-up schatting (op basis van tijd voor activiteiten) Expert Schatting (op basis van ervaring van projectleden)

28


Analogie (op basis van eerder verrichte projecten) Priced to Win (op basis van concurrenten opgaven) Parametrisch / Algoritmisch (op basis van een model)

De eerste vier hebben allen in een bepaalde mate ervaring en expertise nodig. De priced-to-win methode geeft niet al te veel houvast, daarom wordt hier ingegaan op een model waarbij gebruik wordt gemaakt van een parametrische methode (COCOMO) Sneed (1991) stelt dat de kosten van reengineering onder de onderhoudskosten vallen, die op hun beurt weer onder de engineeringkosten vallen. De kosten worden bepaald door de software (complexiteit, hoeveelheid en kwaliteit), maar ook door de factoren personeel en omgeving. Bij personeel speelt naast de mate van talent ook de hoeveelheid domeinkennis een rol. Een persoon die al jaren een applicatie onderhoud, zal sneller de fout kunnen vinden dan een talentvoller persoon zonder die voorkennis. De organisatie is belangrijk in die zin dat een gestructureerde manier effectiever is voor onderhoud en dat er een vorm van wijziging en verandermanagement moet zijn. Om inzicht te krijgen in de kosten van reengineering kan er gekeken worden naar de verschillende componenten van een systeem. Per component kan een analyse gedaan worden naar de inspanning die nodig is voor het reengineeren van het systeem. Dit zou gedaan moeten worden op basis van resultaten die in het verleden behaald zijn. Deze inspanning moet dan vermenigvuldigd worden met een complexiteit factor van het component. Uit de praktijkervaring van Sneed maakt hij op dat de meeste kosten na conversie kwamen. Dit kwam door de hoge kosten van het testen, die bijna hoger waren dan de kosten van de renovatie zelf. Met betrekking tot de kosten van het uitvoeren van reengineering op zichzelf, constateert Sneed (1991) steeds lagere kosten voor reengineering. Door het automatiseren van taken zijn in verloop van tijd, deze kosten 30 maal lager gaan liggen. Deze automatisering en impact hiervan is geconstateerd tussen 1984 en 1991. Er kan daarom aangenomen worden dat er al tegen nog lagere kosten gewerkt kan worden, hier zijn echter geen actuele cijfers van. In tabel 3.3 zijn de kostenfactoren opgenomen die Sneed (1995) onderscheid voor de berekening van kosten en baten van een reengineering project.

Factor Betekenis

P1 Huidige jaarlijkse onderhoudskosten

P2 Huidige jaarlijkse operation kosten

P3 Huidige jaarlijkse business waarde

P4 Voorspelde jaarlijkse onderhoudskosten na reengineering

P5 Voorspelde jaarlijkse operation kosten na reengineering

P6 Voorspelde jaarlijkse business waarde na reengineering

P7 Geschatte reengineering kosten

P8 Geschatte reengineering tijd

P9 Reengineering risico factor

P10 Voorspelde jaarlijkse onderhoudskosten na nieuwbouw

P11 Voorspelde jaarlijkse operation kosten na nieuwbouw

P12 Voorspelde jaarlijkse bedrijfswaarde van het nieuwe systeem

P13 Geschatte nieuwbouw kosten

P14 Geschatte nieuwbouw tijd

P15 Nieuwbouw risico factor

P16 Geschatte levensduur van het systeem

tabel 3.3 - kostenfactoren Sneed(1995)

De voordelen voor reengineering trajecten wordt als volgt bepaald volgens Sneed (1995): Voordeel voor het behouden van de status-quo wordt dan:

VoordeelO = [P3 – (P1 + P2)] * P16 Voordeel voor het herontwikkelen van de applicatie:

VoordeelH = [(P12 – (P10 + P11)) * (P16 – P14) – (P13 * P15)] – VoordeelO

29


Voordeel voor reengineering van de applicatie: VoordeelR = [(P6 – (P4 + P5)) * (P16 – P8) – (P7 * P9)] – VoordeelO

Een oplossing kan nooit los gezien worden van zijn alternatieven en dus is het zinnig om het voordeel van reengineering in context van voortdurend onderhoud en nieuwbouw te zien. Dat is in bovenstaande voorbeelden gedaan. Sneed geeft een overzicht van de verschillende factoren waarop bespaard kan worden. Ook geeft hij een methode om het voordeel van reengineering tegenover het herontwikkelen en onderhouden te stellen. Om specifieker te kijken naar de kosten van reengineering onderscheiden Warren (1999) en Department of Defense (1997) drie kostengroepen en onderkennen hiermee ook nog eventueel overgebleven legacy onderdelen:

Reengineering investering kosten; Dit zijn de kosten die gemaakt moeten worden om de specifieke reengineering strategie te implementeren. Inclusief personeelskosten voor ontwikkeling, ontwerp, training en hardware kosten.

Operationele en onderhoudskosten voor gereengineerde componenten; De kosten van het geïmplementeerde / gereengineerde systeem. Inclusief licenties, hardware onderhoud en software evolutie kosten.

Operationele en onderhoudskosten voor legacy componenten; Het onderhouden van het legacy systeem zal tijdens de reengineering inspanning moeten gebeuren. Deze kosten worden hieronder geteld. Wanneer een bepaald onderdeel van de legacy blijft bestaan, zullen de onderhoudskosten hiervan ook geteld worden.

Warren stelt dat bestaande rekenmodellen gebruikt kunnen worden, met een aanpassing voor reengineering. Hij gaat uit van een systeem van delivered source instructions (DSI). Er worden nieuwe DSI geïmplementeerd, bestaande DSI herontwikkelt en bestaand DSI hergebruikt. Tot slot wordt er bestaande software aangepast. Dit zijn de Adapted DSI. Deze moeten met een Adaption factor (AAF) worden vermenigvuldigd. Deze optelling staat weergegeven in figuur 3.5.

Nieuwe software

Bestaande software

Bestaande software

Bestaande software

Nieuwe functionaliteit

Onbruikaar moet herontwikkelt

worden

Hergebruik hoeft niet aangepast

Hergebruikte, aangepaste code (vermenigvuldigt

met AAF)

Nieuwe DSI

Bestaande DSI

Totaal DSI

figuur 3.5 - kostenopbouw Warren (1999)

De adaptation factor geeft het percentage ontwerp, coderen en integratie aan voor het reengineering project. Deze factor moet voorzichtig ingeschaald worden en ook op basis van ervaring gemaakt worden. Een kostenmethode die het een en ander verder kan uitwerken moet voldoen aan een brede gebruiksbasis en aan een dergelijke in te vullen aanpassingsfactor. Op basis van deze twee criteria is uitgekomen op COCOMO 2 (Boehm, 1995). Naast deze criteria hebben andere modellen (SEER-SEM, PRICE-S, etc) geen open rekenmodel, waardoor deze niet kosteloos geëvalueerd kunnen worden. COCOMO 2 is tot slot een aangepaste versie van de veelgebruikte methode COCOMO.

30


Zowel Warren (1999) als Sneed (1991; 1995) gaan uit van parametrische modellen en sluiten aan op COCOMO 2. Warren heeft het ook over het percentage integratie inspanning, code verandering en ontwerp verandering. Deze factoren komen ook direct terug in COCOMO 2. Er is rekening gehouden met hergebruik van code, wat in principe niet bij de oude COCOMO versie mogelijk was. Om concreet vorm te geven aan hergebruik zijn er een aantal percentages geïntroduceerd, waarmee aangegeven kan worden hoeveel verandering er plaats vind. De formule voor de inspanning is in ESLOC (geschatte inspanning in regels code):

ASLOC is hier het aantal aan te passen regels bron code. DM is het percentage ontwerp aanpassing, CM is het percentage code aanpassingen en IM is het percentage van de inspanning om de hergebruikte onderdelen te integreren. Voor het verkrijgen van inzicht in de code is de factor SU (sofware understanding) toegevoegd en voor inzicht in de inspanning van het zoeken en documenteren van nieuwe onderdelen, de factor AA (assimilation and adaptation). De factor UNFM geeft de bekendheid met de software aan. De afleiding van deze drie zijn in Bijlage 6 toegelicht. Specifiek voor reengineering moet de factor AT worden toegevoegd (de automatische vertaling) dat is namelijk het grote verschil tussen normaal hergebruik en hergebruik binnen het kader van reengineering. Hiervoor zijn de volgende vertalingen onderkend met het percentage automatische vertaling en dus kostenbesparing:

Batchverwerking 96% Batchverwerking met sorteer algoritmes 90% Batchverwerking met DBMS 88% Batchverwerking met DBMS en sorteer algoritmes 82% Interactief 50%

AT is dan het percentage waarmee het totale aantal code regels voor de inspanning mee verlaagd dient te worden. Dit kan uiteraard ook per module of component verrekend worden. COCOMO 2.0 kan gebruikt worden met regels code (LOC), maar ook met functiepunten. Beide zijn goede eenheden voor het meten van productiviteit. (Verhoef, 2002) Kosten en opbrengsten blijven een lastig onderdeel binnen de software ontwikkeling en dus ook binnen de reengineering praktijk. Veel bedrijven hebben geen meetgegevens en kunnen hierdoor ook niet bepalen of de kosten omlaag gaan of stabiel zijn. Bij reengineering is dit ook het geval, ook al is hier de mogelijkheid om een beter beeld te krijgen van het eindproduct doordat er een halffabrikaat ligt. Bij een reengineering traject moet er sprake zijn van lagere kosten. Er wordt zelfs gesteld dat als het niet voor de helft of minder kan, dat het project dan geen doorgang zou moeten hebben (Sneed, 1995). Zoals gezegd, zijn er meerdere besparingen, naast de besparing op de ontwikkelingskosten. Onder andere besparingen op inleertijd en onderhoud zijn hier belangrijk. Sneed (1991) gaat voornamelijk in op de gevolgen die reengineering biedt voor onderhoud. Hij gaat echter niet verder in op andere toekomstige besparingen. Wanneer een reengineering project goed uitgevoerd wordt en er wordt een herstructurering op een hoger abstractieniveau uitgevoerd, dan zullen de kosten van nieuwe onderdelen die toegevoegd kunnen worden, ook lager worden. Delen van de kosten zijn wel en delen zijn niet te kwantificeren. Voor de laatste moeten dan meetprogramma’s opgezet worden teneinde het een en ander meetbaar te maken.

31


3.2.3 Risico beheersing Er zijn wellicht zoveel risico’s als activiteiten in een project, als het niet meer zijn. Er wordt hier dan ook geen poging gedaan om een lijst van risico’s op te nemen die volledig is. Volledigheid betrachten hierin is namelijk een illusie. Wat wel getracht wordt, is het achterhalen van de belangrijkste risico’s. Hiervoor worden verschillende auteurs langsgelopen. Rosenberg (1996) heeft een redelijk uitputtende lijst met risico’s samengesteld, waar de verschillende andere auteurs (Bergey 1999; Warren 1999; Sneed 1999) naast gelegd zijn (zie Bijlage 7 ). De meeste risico’s die genoemd worden zijn algemene risico’s die met kennis van het concept reengineering te onderkennen vallen. Sneed (1999) noemt echter een aantal interessante operationele risico’s op basis van de projecten die hij heeft uitgevoerd. Het zijn niet alleen risico’s die hij ziet als bedreigend, maar redenen waardoor hij verschillende projecten daadwerkelijk heeft zien falen. Deze worden onderstaand kort benoemd:

Performance loss bij het migreren naar een andere omgeving of programmeertaal; Doordat de performance omlaag is gegaan, was het eindresultaat niet acceptabel voor de opdrachtgever. Deze performance loss kan zich voordoen bij automatische vertaling, downsizen van bijvoorbeeld mainframe naar server of het omzetten van flatfile bestanden naar een relationeel systeem.

Project vertragingen door mismatch in architectuur; Onder architecturale mismatch wordt hier verstaan: de situatie die zich voordoet wanneer eigenschappen van de een niet passen bij de eigenschappen van de ander. Een voorbeeld hiervan is een code constructie die niet direct van de ene taal naar de andere gemapped kan worden. Dergelijke mismatches moeten worden onderkend in een planningsstadium en kunnen anders voor ernstige vertragingen zorgen.

Project vertragingen door test bottlenecks en gebrek aan test data; Dit was de grootste kostenpost voor 12 van de 13 projecten (zelfs minstens 50%). Dit komt onder ander doordat er inconsistenties in de omgeving kunnen zijn (waardoor dingen als string-manipulatie anders gaan), verborgen fouten die aan het licht komen en de tijd die geïnvesteerd moet worden om testdata te maken. Er is bijna nooit adequate testdata beschikbaar.

Het falen in het behalen van kwaliteitsdoelen, door slechte definiëring van deze doelen; Een van de grootste voordelen van reengineering en een van de hoofdargumenten ervoor is dat het systeem flexibeler, beter onderhoudbaar, testbaar en bruikbaar wordt. Dit is echter lastig aan te tonen. Het kan zijn dat de opdrachtgever verwacht dat er een daling in het onderhoudspersoneel komt, of een verlaging van het aantal fouten dat zich voordoet. Meestal vragen deze voordelen echter enige tijd om hun geld terug te verdienen.

Verwerpen van de resultaten door de programmeurs bij de klant. Er zijn twee kernredenen waarom de programmeurs het nieuwe systeem zullen verwerpen. De eerste is dat ze niet zijn betrokken bij het reengineeringproces. De tweede reden is dat ze de nieuwe code niet begrijpen. Vaak vallen deze redenen samen. In de ervaring van Sneed komt naar voren dat de projecten die het beste werden geaccepteerd samen met de programmeurs van de opdrachtgever werd ontwikkeld. Op de tweede plek kwamen projecten waarbij het onderhoud na de reengineering werd uitbesteed aan een derde partij. Ook al waren die programmeurs niet betrokken bij het reengineeren, maar ze hadden ook geen emotionele binding met de programmatuur. In deze paragraaf is ingegaan op de verschillende stappen binnen het proces, de mogelijke benaderingen van de kosten en baten en de mogelijke risico’s. In de volgende paragraaf zal worden gekeken naar het product van reengineering en het belang hiervan.

32


3.3 Product van Reengineering

In deze paragraaf wordt verder ingegaan op het product van reengineering. Onder het product wordt de input (legacy) en de output (het doelsysteem) verstaan. Zowel Warren (1999) als Seacord et al(2003) vertalen de impact van deze input en output, naar het belang van kennis van legacy systemen en doelsystemen. In figuur 3.6 is deze kennis uitgezet en opgedeeld in algemene en specifieke kennis. In de komende paragrafen worden respectievelijk het legacy begrip en het begrip van de doeltechnologie behandeld.

figuur 3.6 - begrip van legacy en doeltechnologie

3.3.1 Begrip legacy systemen In eerste instantie heeft het een positief effect om een algemeen begrip te hebben van legacy systemen. Hieronder wordt een begrip verstaan van drie inhoudelijke gebieden die relevant zijn binnen de reengineering literatuur: architectuur, code en database. Op een specifiek niveau kan er naar de daadwerkelijke instanties van de architectuur, code en database gekeken worden. Zo kan er bijvoorbeeld sprake zijn van een monolithische applicatie die is ontwikkeld in PL/I en voor dataopslag gebruik gemaakt wordt van flatfiles. Hiernaast bepaalt de kwaliteit van de legacy, de snelheid en mate waarin er begrip verkregen kan worden (Sneed, 1991). In de ideale situatie waarin is het ontwikkelteam al uitvoerig bekend met de legacy. Dit kan zich voordoen doordat bijvoorbeeld de onderhoudsprogrammeurs mee ontwikkelen of omdat het een intern reengineering project is. Het belang hiervan is al aangeduid door Bennet (2000a) in zijn version staged model (zie paragraaf 2.2.2) , waarin hij aangeeft dat een applicatie minder makkelijk aan te passen wordt, als of de programmeurs weggaan, of de architectuur ernstig vervalt.

3.3.2 Begrip doeltechnologie Ook voor het begrip krijgen van doeltechnologieën maak ik een onderscheid tussen algemeen begrip en specifiek begrip. Onder de algemene kennis kan hier kennis verstaan worden van nieuwere architecturen, waarbij sprake is van bijvoorbeeld objectoriëntatie, Component Based Development, web services en xml berichtenverkeer. De mogelijkheden van deze technologieën moet begrepen worden om deze serieus te overwegen voor het doelsysteem. Als specifieke kennis versta ik dan de kennis van een specifieke taal, middleware of database management systeem. Een manier om de kennis te vergroten van doeltechnologieën is uiteraard om hier trainingen, cursussen of workshops voor te volgen. Seacord et al. (2003) hebben hierom in hun boek twee keer zoveel pagina’s gewijd aan het bespreken van de doeltechnologieën als aan het krijgen van begrip van de huidige software. Het is uitermate belangrijk om op de hoogte te zijn van de verschillende technologieën, omdat een toekomstige technologie er voor kan zorgen dat huidige inspanningen overbodig worden.

33


De voornaamste concepten binnen nieuwere architecturen zijn de gedistribueerde systemen. Er wordt veel ontwikkeld in objectgeoriënteerde talen en er wordt gebruik gemaakt van Component Based Development(CBD). Hierbij worden deelapplicaties ontwikkeld, die los van elkaar te implementeren zijn. Feitelijk zijn het objecten op een grotere schaal. Het valt buiten het kader om ver in te gaan op deze ontwikkelingsmethodiek. Voor meer informatie verwijs ik dan graag naar Ulrich (2002) die hier een hoofdstuk aan wijdt om het in simpele termen uit te leggen. Er zijn geen bijzondere eigenschappen van deze architectuur en denkwijze die er voor zorgen dat er beperkingen op de uitvoering van reengineering zijn. CBD is juist zo opgezet dat het modulair is, makkelijk uit te breiden, etc. Sneed (1999) stelt wel dat het belangrijk is, rekenschap te nemen van het feit dat alle pogingen (in zijn studie) om objectgeoriënteerde mogelijkheden te introduceren in procedurele omgevingen, zijn gestuit op bittere weerstand van de onderhoudsprogrammeurs, die onbekend zijn met object georiënteerde concepten. Nu vastgelegd is hoe de verschillende projectfactoren zich verhouden tot reengineering, kan in de volgende paragraaf onderzoeksvraag 1 beantwoord worden.

3.4 Conclusies

Er kan aan het eind van dit hoofdstuk een antwoord gegeven worden op de vraag: Welke projectfactoren zijn relevant voor het succesvol uitvoeren van een Legacy Renovation project? Onderscheiden zijn de factoren projectmanagement, proces en product: Deelvraag b: Welke invloedsfactoren op projectmanagement zijn te onderkennen door reengineering, vanuit de projectmanagement literatuur? Volgens de theorie van Shenhar en Dvir, komt een reengineering project in het algemeen uit op een normaal tot snel project, met een hogere onzekerheid, en een laaggemiddelde complexiteit. Dit houdt in totaal in dat projecten relatief informeel gemanaged moeten worden met veel communicatie. Het gebruik van procedures is in mindere mate nodig. Een reengineering-projectleider moet wel technisch onderlegd zijn en het team moet bestaan uit ervaren professionals. Binnen de theorie van van Aken(2002) kan er vastgesteld worden dat reengineering relatief lage grijpbaarheid heeft. Dit houdt in dat er gekeken moet worden naar een structurerende werkstijl. In het algemeen moet onzekerheid niet volgebouwd worden met instrumentarium. Deelvraag c: Welke projectfactoren zijn belangrijk in een legacy renovation proces? Deze zijn de volgende: 1. Activiteiten:

Portfolio Analyse (optioneel) SRA (met als economische analyse de kostenschatting in punt 2.) Renaissance aanpak (Hierbij is de fase van Planning vervangen door het opstellen van het plan

van RMM.) Implementatie volgens Iterative Reengineering

2. Kostenschatting. Methodiek van Sneed (1995) voor besparingen en voordeel t.o.v. nieuwbouw/onderhoud en COCOMO 2 voor specifieke reengineering kosten.

3. Risico’s (lijst in Bijlage 7 ) Zoals weergegeven in bovenstaande lijst wordt hier een samensmelting voorgesteld van de twee aanpakken. Ik hanteer de Renaissance aanpak en breidt deze uit, door in de planningfase de stappen van RMM te zetten. De RMM aanpak start na een portfolio analyse en eindigt met een bruikbaar plan voor het uitvoeren van modernisatie inspanningen. De stappen van RMM kunnen dan gebruikt worden als de planning fase van Renaissance (aangezien RMM uitgebreider is voor het opstellen van de planning).

34


Voor deze planning kunnen de portfolioanalyse en de SRA worden uitgevoerd. De portfolio analyse kan worden uitgevoerd alvorens het opstellen van het plan gebeurd. In de fase ‘maken van de business case’, kan de SRA gebruikt worden om te bepalen welke vormen van reengineering van toepassing kunnen zijn. De stap ‘Bepalen modernisatie strategie’ kan vastleggen wat de preciezere activiteiten zijn op implementatieniveau. Er kan hier gebruik gemaakt worden van de methodiek ‘iterative reengineering’ De lijst met risico’s die is opgenomen in Bijlage 7 , kan gelden als een bruikbare lijst met risico’s die kunnen worden meegenomen in de voorbereiding en uitvoering van een project. Sommige risico’s zijn minder belangrijk geworden omdat de methodes hier ingebouwde activiteiten voor hebben ontwikkeld. Zo beschrijft renaissance de activiteit “begrip krijgen bedrijfsprocessen” om hier het risico “proceskennis gaat verloren door reengineering” het hoofd te bieden. Wat betreft kostenmethodiek ligt hier nu COCOMO 2.0, dat een verrekening heeft voor reengineering projecten. Deze methodiek kan met functiepunten of met regels code gebruikt worden. Deze kan gebruikt worden bij het opstellen van de business case in de planningsfase van het traject. De raad van Tilley (1995) moet echter wel ter hand genomen worden: elke organisatie is uniek en er kan niet vertrouwd worden op standaard verhoudingen voor kosten. Koskinen et al (2004) hebben de verschillende aanpakken en kostenmethoden voor reengineering geëvalueerd met behulp van een meta-framework en hieruit komen COCOMO 2, de benadering van Sneed, Renaissance en RMM als bruikbare methodieken voor reengineering uit de bus. Deelvraag d: Wat zijn de eigenschappen en invloeden van het product van een Legacy Renovation proces? De belangrijkste impact van zowel de legacy als van de doeltechnologieën, is de eis voor de kennis hiervan. De kwaliteit van een bestaande legacy applicatie bepaalt in welke mate en met welke snelheid het begrip verkregen kan worden. Voor kennis van het legacy systeem geeft het positief effect wanneer er oorspronkelijke ontwikkelaars beschikbaar zijn of medewerkers die al lange tijd het systeem beheren. Voor de kennis van doeltechnologieën zou gekeken kunnen worden naar de beschikbare kennis in een organisatie, of naar trainingen en studiemateriaal. Concepten die voorlopig bijzonder relevant zijn voor reengineering zijn voor Legacy de concepten mainframe en COBOL en voor nieuwe architecturen J2EE, .NET en component based development. In dit hoofdstuk is de vraag beantwoord, welke projectfactoren belangrijk zijn vanuit de literatuur. In het volgende hoofdstuk wordt gekeken naar de invloedsfactoren en tools, om zo een gewogen beeld te krijgen van een goede aanpak voor een reengineering project.

35

Hoofdstuk 4: Een Reengineering Project Aanpak

4 Een Reengineering Project Aanpak

In dit hoofdstuk zullen de invloedsfactoren en de tools binnen een reengineeringproject worden behandeld. Deze zullen worden behandeld voor het proces (in paragraaf 1) en het product (in paragraaf 2). De invloedsfactoren zijn van toepassing op processtappen, de inzet van tools is terug te leiden naar proces en product. Er zal daarom niet verder ingegaan worden op projectmanagement. Uiteraard is er een oneindig aantal invloedsfactoren. Deze zijn beperkt tot de punten die Tilley (1995) noemt. Hiernaast heeft er een gesprek plaatsgevonden met de Software Improvement Group (SIG) en ben zijn er gegevens verzameld van een aantal seminars geweest waar verschillende aandachtspunten zijn aangereikt. In de laatste paragraaf worden de resultaten samengevoegd met de factoren uit hoofdstuk 3, om zo tot een voor te stellen project aanpak te komen.

4.1 Proces van reengineering

4.1.1 Toolinzet De invloed van tools zal in twee gedeeltes worden behandeld. Eerst zal ingegaan worden op de inzet van tools in het voortraject (portfolio analyse en reengineering assesment) en vervolgens zal ingegaan worden op tool-inzet ten behoeve van kosten en risico’s. Portfolio analyse / Reengineering Assesment Gebruik van tools kan in het analyse stadium worden toegepast door een impactanalyse uit te voeren, zoals deze beschreven is door Kuipers en Piek (2004) en Deursen (2003). Bij een organisatie kan dan een scan uitgevoerd worden op meerdere systemen, waardoor er een inzicht ontstaat in de complexiteit van de applicaties. Er zijn een achttal aspecten onderkend die worden geanalyseerd bij dit proces:

1. Technische architectuur; deze wordt geanalyseerd om naar de langere termijn van de levenscyclus te kijken.

2. Modulariteit; richt zich op een laagniveau van het systeem. Een goed modulair ontwerp verhoogt de flexibiliteit en de effectiviteit van het onderhoud.

3. Technische complexiteit; kijkt naar de begrijpbaarheid van de code. 4. Omvang; geeft complexiteit in een zekere mate aan: groter is complexer. 5. Testen; testanalyse richt zich op de teststrategie. Geeft een inzicht in de te verwachten fouten in

de programmatuur. 6. Performance; let op de tijdsefficiency en resource-efficiency van het systeem. Deze hebben een

impact op de kosten en bruikbaarheid. 7. Documentatie; actualiteit en volledigheid van documentatie verlengt de levensduur van een

systeem. 8. Beheer en onderhoud; de manier waarop het onderhoud plaats vind aan het systeem geeft een

inzicht in de kwaliteit van het systeem. Bij deze analyse kan gebruik gemaakt worden van verschillende (technische) metrieken als de cyclomatische complexiteit, het aantal databasebenaderingen, hoeveelheid sockets die geopend worden, enzovoort. Voor grote hoeveelheden code in verschillende talen kan er een scan gemaakt worden waarbij bijvoorbeeld de functiepunten uitgezet worden tegen de cyclomatische complexiteit. Hierdoor kan er meteen gekeken worden naar systemen die uitschieten in complexiteit of functiepunten. Door een verdere analyse kan dan gekeken worden naar de exacte oorza(a)k(en). Wanneer dit vaker is uitgevoerd, zou er een database samengesteld kunnen worden, waar de assesments tot die tijd in worden opgeslagen. Deze gegevens kunnen dan per branche als benchmark dienen.

37


Het scannen van de code en hier conclusies uit trekken kan op zichzelf niet als een afdoende techniek worden beschouwd. Er dienen ook workshops gehouden te worden om uit de organisatie informatie te verkrijgen en weerstand te vermijden. Hiernaast kan interne documentatie worden bestudeerd. Deze indirecte feiten kunnen samen met de directe feiten uit een broncode scan worden gebruikt om een oordeel te vellen over de huidige technische kwaliteit en bedrijfswaarde. Kosten en Risico’s Met betrekking tot de kosten kan een methode als backfiring bruikbaar zijn. Backfiring is een techniek die gebruikt kan worden in combinatie met broncode-scanning, waarmee op basis van de bestaande broncode functiepunten kunnen worden achterhaald. Omdat deze techniek niet altijd betrouwbaar is gebleken (Verhoef, 2002) moeten er geen beslissingen gemaakt worden op alleen de resultaten van backfiring. Ook zijn er inmiddels initiatieven ontwikkeld, waarbinnen er gekeken wordt naar realistischere code naar functiepunten conversies (Software Improvement Group, 2005) Deze functiepunten kunnen vervolgens gebruikt worden om een schatting te maken van de kosten die gemoeid zijn met een reengineering traject. Het enige gegeven dat hier dan mist is de productiviteit (inspanning per functiepunt). Voor het onderkennen van risico’s die zich tijdens de ontwikkeling kunnen voordoen, kan ook gebruik gemaakt worden van gegevens over de complexiteit en andere aspecten, zoals die worden geanalyseerd door een tool. Dit betreft dan concrete risico’s voor de ontwikkeling zoals erg complexe modules en vaak aangeroepen of gekoppelde modules. Deze resultaten zijn dus niet slechts inzetbaar voor portfolio analyse en assesment voor reengineering, maar kunnen ook helpen bij het inschalen van risico’s voor het reengineering project. Dat tools essentieel zijn voor reengineering en de manier waarop er een toegevoegde waarde gecreëerd wordt, is hierboven besproken. In de volgende paragraaf wordt ingegaan op de verschillende overige invloeden die zijn gevonden.

4.1.2 Proces van reengineering – Invloedsfactoren De invloedsfactoren zijn ingedeeld naar de fases binnen het proces. De eerste paragraaf behandelt de portfolio analyse en de reengineering assesment. De tweede behandelt de aanpak en uitvoering. De laatste twee factoren handelen over kosten en risico’s. Portfolio analyse / Reengineering Assesment Met betrekking tot het voortraject van een reengineering project zijn de volgende invloeden op te merken. Microfocus is de meest vooraanstaande tool-vendor voor de COBOL omgeving. Microfocus (2005)

hanteert een suite voor het ontwikkelen van COBOL applicaties, waardoor er tegenwoordig ontwikkeld kan worden voor mainframe, Unix, Linux of Windows. Ook kan ontwikkeling voor het mainframe plaatsvinden op een andere omgeving (door emulatie) waardoor het mainframe minder belast hoeft te worden. Ook zijn er aan COBOL allerhande uitbreidingen toegevoegd, zoals XML berichtuitwisseling, het inzetten van webservices, et cetera. Hiernaast is er ook een COBOL versie beschikbaar voor het gebruik onder het .NET framework, waardoor het gebruik kan maken van alle voordelen van dit framework. Zo kan er bijvoorbeeld ontwikkeld worden voor webpagina’s in COBOL. (Microfocus, 2005) Hiernaast biedt bijvoorbeeld IBM ook aangepaste nieuwe omgevingen voor het gebruik van PL/I. (IBM, 2004)

Volgens organisaties als PinkRoccade, Belastingdienst en KPMG (Pink Seminar, 2004), blijft het mainframe een goed product en is er geen concrete noodzaak om er vanaf te gaan. Er voornamelijk beroepen op de kwaliteit en de kosten van het onderhoud van een mainframe versus een serverpark. Ook wordt 80% van alle bedrijfsgegevens nog steeds beheerd door mainframes, wat als een indicatie van kwaliteit kan worden opgevat. Uiteraard zijn de kosten van een mainframe niet altijd te dekken, waardoor er een omslagpunt is, waar de voordelen van mainframes ten opzichte van servers lonen.

38


Deze twee punten nuanceren het belang om applicaties die gebaseerd zijn op mainframe en oude(re) talen, meteen te scharen onder legacy en te opteren voor reengineering. Dit houdt in dat de portfolio analyse en reengineering assesment met enige nuance op dit gebied uitgevoerd moeten worden. De factor in welke mate de omgeving nog ondersteund wordt door de leverancier, moet goed geëvalueerd worden. Deze kan namelijk naast tegenvallen, ook nog meevallen. Aanpak en uitvoering Met betrekking tot de aanpak en de uitvoering van het project, zijn de volgende punten als invloed op te merken. Bij een reengineering inspanning is een van de belangrijkste tips om de database te migreren

alvorens de applicatie over te zetten naar het doelsysteem. (SIG, 2004) De theorie hierachter is het motto: “Data survives logic”. De bedrijfslogica en processen veranderen door de jaren heen, maar de data blijft relatief constant en is een kernwaarde voor het bedrijf. Deze mening wordt ook gedeeld door Bianchi et al (2003).

Bij het overgaan naar een nieuwe omgeving is het van belang dat de onderhoudsorganisatie hiermee om kan gaan. Er moet dus niet gekozen worden voor een objectgeoriënteerde insteek, wanneer de organisatie hier niet op getraind is. (SIG 2004; Sneed 1999)

Zelfs bij simpelere vormen of delen van reengineering is het raadzaam om het onderhoudspersoneel erbij te betrekken. Bij bijvoorbeeld redocumentation kan er al weerstand zijn van hen, omdat zij het niet nodig achten om het overzicht zo overduidelijk in de code te hebben. (SIG, 2004)

Er is een nieuw concept in ontwikkeling door de Object Management Group (OMG). Dit is een open consortium dat standaarden ontwikkelt en beheert. Onder andere UML en CORBA zijn door de OMG neergezet. Een van de recentere ontwikkelingen, is het ontwikkelen van de Model Driven Architecture (MDA). Deze architectuur beoogt om de implementatie details van de bedrijfsprocessen en de modellering te scheiden. Hiervoor is een meta model ontwikkeld, waardoor er platformonafhankelijke modellen geïmplementeerd kunnen worden op verschillende platformen. Concreet kan met een model dan automatisch code gegenereerd worden voor AS/400, .NET, J2EE of een willekeurig andere omgeving. Een ontwikkeling die hier op gebaseerd is, is Architecture Driven Modernization (ADM). Deze methode gaat uit van een meta model voor systeembegrip, waarna de informatie uitwisselbaar is en platformonafhankelijk is gemaakt. Vervolgens kunnen hier dan integraties, herstructureringen en implementaties op volgen. (OMG, 2004) ADM is opgedeeld in 7 deelproducten, en op het moment van schrijven is er begonnen met product 1. De planning is dat er medio 2005 begonnen kan worden met deelproduct 4, dus de volledige standaard zal naar alle waarschijnlijkheid niet voor 2006 het licht zien. Hierna moet dan door het bedrijfsleven voor deze standaard ontwikkeld worden, wat nog enige tijd kan duren.

Deze invloeden houden voor de aanpak concreet in dat er een extra overweging plaats zou moeten vinden voor het tijdstip van overzetten van de data, er extra gelet moet worden op de betrokkenheid van het onderhoudspersoneel en het concept ADM in de gaten gehouden zal moeten worden. Kosten Met betrekking tot de kosten zijn onderstaande constateringen gedaan:

Microfocus heeft de besparing berekend van een documentatie generatie systeem door te kijken naar de gemiddelde tijdsbesparing per actie voor het onderhoud. Vervolgens is gekeken naar het gemiddelde aantal acties, waarvoor de tool gebruikt werd, en werd het aantal start-ups van de tools bepaald. Op deze manier kon met een simpele vermenigvuldiging een schatting gemaakt worden van het systeem. Dit kan gebruikt worden als een techniek om de besparing te evalueren. (Microfocus, 2005)

39


LogicaCMG biedt projecten aan voor renovatie. Intern is een project uitgevoerd waarbij een Access database is omgezet naar een .NET applicatie. In verhouding met een nieuwbouw applicatie is dit project 40% sneller en 35% goedkoper uitgevallen. (Donath, 2004)

OmNext stelt in het algemeen dat reengineering op hun manier 25% van de tijd van nieuwbouw inhoud. Dit vertalen ze in een kostenbesparing van 66%. (Omnext, 2004)

Deze gegevens bieden een methode om onderhoudsbesparing te meten en een referentiewaarde voor de kosten van vernieuwbouw. Risico’s De verschillende risico’s van Sneed (1999) zijn als eerste indicatie voorgelegd aan de ervaren medewerkers bij de SIG (2004). Hieruit zijn onderstaande beoordelingen gekomen. Performance verlies;

Dit is een herkenbaar probleem, voornamelijk wanneer er een puur automatische conversie plaats vind. Een waargenomen voorbeeld is automatische conversie (van flatfile naar relationeel) waar de performance verslechterd was, omdat er niet gekeken is naar indices.

Architecturale mismatch; in dit kader is het belangrijk om ook te zorgen voor de juiste mensen op de juiste plek. (voor objectgeoriënteerd ontwerp ook objectgeoriënteerde ontwerpers inzetten)

Testen problematiek; het goed inrichten van het testproces is bijzonder belangrijk. Niet alleen aan het eind, maar continu unit en integratietesten. Deze zijn belangrijk omdat anders op het eind er een bottleneck kan ontstaan waarin veel tijd en kosten worden gemaakt. Onder meer om deze reden ontwikkelt de SIG intern met behulp van eXtreme Programming.

Weerstand bij de programmeurs van het probleemhoudende bedrijf. Een belangrijk risico is dat er veel overleg moet zijn met de gebruikers en voornamelijk de onderhoudsafdeling van de gebruikers. Er moet een draagvlak zijn voor het traject van reengineering en hiervoor moeten de onderhoudsprogrammeurs worden betrokken. Ook bij risk assesments, middels workshops en het collectief aankaarten van een probleem. Dit moet gebeuren zonder iemand of een groep als zondebok aan te wijzen. Weerstand bij de programmeurs is ook herkenbaar. Dit wordt bij DocGen (Documentatie Generatie Tool) al waargenomen. De tool inzet is volgens de programmeurs niet nodig, zij weten immers al hoe een applicatie in elkaar zit. De SIG probeert daarom ook de programmeurs aan het begin er bij te betrekken en de noodzaak en voordelen van het gebruik van een tool als DocGen, in te laten zien.

Het feit dat deze risico’s worden bevestigd door de SIG, geeft aan dat deze extra belangrijk zijn om in de gaten te houden tijdens en bij de voorbereiding van een project. Voornamelijk het risico van weerstand bij de huidige programmeurs wordt als uitermate kritiek beschouwd.


Voor het product van reengineering is het relevant om naar de tooling te kijken. Tools zijn meer dan alleen relevant voor reengineering. Ze zijn de grootste enabler van reengineering. Zonder tools is het namelijk vaak niet mogelijk om gemakkelijk bestaande specificaties te achterhalen, kunnen snelle restructuringmechanismen (zoals het verwijderen van GOTO’s) niet worden uitgevoerd en zijn de totaalkosten van de reengineeringsinspanning niet significant lager dan bij nieuwbouw. Voor een overzicht van een veelvoud van gebieden waarop tools ingezet kunnen worden en een lijst met leveranciers van dergelijke tools, is een overzicht te vinden in Ulrich (2002) Voor de aanpak zijn er tools voor elk van de fasen die onderkend zijn door Chikofsky en Cross(1990). Seacord et al (2003) hebben technieken opgesomd die een bijdrage kunnen leveren aan het begrip van een legacy systeem. Zij hanteren hiertoe een gekantelde versie van het figuur van Chikofsky en Cross (1990). Dit model is het ‘horseshoe’ model gedoopt en de verschillende technieken worden hieronder toegelicht per onderkend representatie niveau.

40


Code Structuur Representatie Dit betreft een representatie van het systeem op het implementatie niveau (het laagste niveau).

Handmatig code lezen; kan uitgevoerd worden tot een bepaalde graad. Een goede software engineer kan dan ongeveer 50.000 LOC onder zijn hoede nemen.

Artifact Extraction; het vinden en documenteren van elementen en relaties onder de elementen in code-structuurvormige representaties van het systeem.

Statische analyse; betreft het parsen van de broncode van applicaties om een variëteit aan gegevens te kunnen verkrijgen. Hieronder vallen call-graphs, data en control flows, etc. De meeste reverse engineering tools bieden een veelheid aan deze mogelijkheden.

Dynamische analyse; analyse methoden die de programma uitvoering in productie of simulatie waarnemen. Technieken hiervoor zijn profiling (het verzamelen van call-sequences en dataflow), snooping (inzicht bieden in interacties, door gegevens en parameters te monitoren wanneer ze door grenzen van een component gaan), code instrumentation (het achterhalen van code uitvoering en het veranderen van data waarden)

Slicing; familie van programma decompositie technieken. Statements die relevant zijn voor een berekening worden geselecteerd, ook al zitten deze door de gehele applicatie heen.

Functieniveau Representatie Betreft een representatie op een hoger niveau, hier komt het ontwerp naar voren. Voor deze technieken kan gebruik gemaakt worden van de output van technieken van de codestructuur representatie. Representaties op functie niveau beschrijven de relaties tussen functies, data en bestanden. Er zijn hiervoor verschillende technieken beschikbaar:

Semantische en gedragspatronen matching; Patronen worden geïdentificeerd door code componenten te ontdekken die een specifieke dataflow, controlflow of dynamische(executie gerelateerde) relaties delen.

Redocumentation; betreft tekstuele vormen van de code, bijvoorbeeld pseudo-code. Kan echter ook worden vormgegeven als gelinkte teksten, webpagina’s en grafische weergaven van de systeem artefacten.

Plan herkenning; programma plannen zijn abstracties van broncode fragmenten. Door instanties van een programma plan te vergelijken kunnen gelijke plannen worden herkend en worden geconsolideerd.

Aggregatie hiërarchieën: deze hiërarchieën worden gemaakt door stukken legacy code aan elkaar te koppelen. Hierdoor kan er een object hiërarchie gemaakt worden

Refactoring; is het proces van code naar code conversie, waarbij het externe gedrag hetzelfde blijft, maar de interne code herstructureert wordt.

Architectuur Representatie Dit niveau betreft het hoger niveau ontwerp en de oorspronkelijke gebruikersvereisten zijn hierin terug te vinden. Maakt gebruik van gegevens uit voorgaande fases.

Structurele Patronen Koppelen; Bestaande ontwerp patronen worden tegen de code patronen aangelegd, die verkregen zijn met statische analyse. Hierdoor kunnen module afhankelijkheden gevonden worden.

Concept toekennen en redenatie; betreft het vinden van mens georiënteerde concepten in een programma. Dit kan uitgevoerd worden door bijvoorbeeld een persoon stukken code te koppelen aan een concept in het applicatie domein.

Architecture & Structure Identification; het onthullen van de huidige architectuur. Het kan zijn dat er een legacy systeem is, dat geen architectuur had als ontwerp. Van dit soort systemen kan het onmogelijk zijn om een architectuur weer te geven. Deze stap heeft veel informatie nodig uit voorgaande technieken die zijn gebruikt.

41


Om begrip te krijgen van een legacy systeem zijn alle bovenstaande technieken bruikbaar. Deze technieken hoeven niet alle ingezet te worden, maar kunnen situationeel ingezet worden naar aanleiding van plannen hoe het systeem omgezet moet worden. Ook kunnen deze technieken gedeeltelijk of geheel worden geautomatiseerd. Hierdoor is duidelijk welke bijdrage tools kunnen leveren aan begripsvorming. Er zijn ook tools beschikbaar die de implementatie kunnen verzorgen. Voor forward engineering kan bijvoorbeeld gebruik gemaakt worden van standaard modeleer tools (voor bijvoorbeeld UML), CASE tools en andere ontwikkelgereedschappen waar nieuwbouw projecten ook op kunnen leunen. Omdat deze ook in reguliere nieuwbouwprojecten ingezet kunnen worden, zal er hier niet verder op ingegaan worden. Tot slot kunnen verschillende tools gemaakt worden voor specifieke fasen in een eenmalig reengineeringproject. In de Butterfly methode (Wu et al, 1997) wordt gebruik gemaakt van een data-access-allocator en een data-transformatie-tool, Chicken Little leunt op het maken van specifieke gateways en de iterative reengineering methodiek kent een databanker en data-locator. Voor alle methoden geldt dat deze tools gebouwd worden voor een specifiek traject. Hiernaast kan per fase een afweging gemaakt worden of het maken van een tool een toegevoegde waarde biedt voor het traject.

4.3 Conclusies

Het overzicht van de verschillende projectfactoren in combinatie met hun invloedsfactoren en de mogelijke inzet van tools, geeft de mogelijkheid om hier een projectstructuur neer te zetten. Deze kan als raamwerk dienen om de huidige aanpak van Centric naast te zetten. Dit geeft antwoord op de vraag: “Welke projectaanpak kan gehanteerd worden voor Legacy Renovation?” In eerste instantie moet gesteld worden: het gebruik van tools maakt het grote verschil tussen reengineering en nieuwbouw. Primaire taken die ondersteund worden zijn reverse-engineering, redocumentation, restructuring en forward engineering. Tools maken het ook mogelijk om portfolio analyse, reengineering assesment, risico inschatting en kosten inschatting gemakkelijker en/of uitgebreider uit te voeren. Tools vinden dus hun weerslag in het volledige proces. In figuur 4.1 is de samenhang aangegeven: de verschillende procesonderdelen zijn weergegeven en de onderlinge fasen waar ze invloed op hebben. Voor het product is relevant dat tools begrip creeeren en ook in de andere fasen inzetbaar zijn. Projectmanagement is relevant over het gehele proces.

figuur 4.1 - theoretisch model voor reengineering

42


PROJECTMANAGEMENT De complexiteit en onzekerheid zijn relatief hoog en het tempo gemiddeld. Dit vereist veel communicatie van het projectmanagement, een team met veel (ervaren) professionals en gemiddeld formele communicatiestijl. De grijpbaarheid van reengineering is laag. Daarom is er voor reengineeringprojecten een hogere mate van structurering nodig dan bij engineering projecten. Voor deze structurering kan het best een structurerende werkstijl gehanteerd worden. Als er doelgericht gewerkt wordt, kan de projectleider met weinig instrumenten toe om succesvol te zijn. PROCES De portfolio analyse en SRA zijn in principe facultatieve stappen. Deze zijn niet nodig wanneer de klant een oplossing aandraagt voor een applicatie. De stappen kunnen wel gebruikt worden om deze wens te valideren, wanneer nodig. De stappen binnen het proces zijn genummerd weergegeven in figuur 4.1. 1. Portfolio analyse

Hierbij kan naast de eenvoudige en heldere tool van Boreel ook gebruik gemaakt worden van een tool of een derde partij die problemen kan constateren in de code op basis van metrieken. Het systeem van Boreel moet genuanceerd worden met de notie dat legacy niet strikt gekoppeld is aan het mainframe in combinatie met COBOL. Dit geld ook voor de SRA.

2. Software Reengineering Assesment In geval van het gebruik van broncode scan tools kan hier ook gebruik gemaakt worden van het risico dat geschat wordt op basis van de code. Dit risico kan dan bekeken worden en er kan gekeken worden welke oplossing het probleem het best aanpakt. Hiernaast blijven de lijsten van de SRA goed bruikbaar, ook zonder het gebruik van tools. Op basis van deze lijsten kan er gekeken worden in welke mate de verschillende mogelijkheden van reengineering nodig zijn (data-reengineering, restructuring, redocumenting, etc.)

3. Projectaanpak Reengineering De Renaissance methode kan gehanteerd worden voor de activiteitenindelingen. De RMM methode is ingevoegd voor het benadrukken van de belangen het plannen van het traject. Hierbij ligt meer nadruk op het afstemmen van de vereisten en belangen. De verantwoording voor de gekozen methode wordt hierin gedeeltelijk voorzien door de portfolio analyse en de SRA.

Aandachtspunten: Er moet rekening gehouden worden met het feit dat er voor evolutie ontwikkeld wordt. Anders

ontstaat er wederom een legacy systeem. Verder moeten er duidelijke afspraken gemaakt worden over welk niveau van documentatie opgeleverd wordt. Eventueel is er de mogelijkheid om tools aan te bieden voor continue realtime documentatie. (Warren, 1999; SIG, 2004)

Bij voorkeur wordt een project uitgevoerd zonder het toevoegen van nieuwe functionaliteiten. Deze nieuwe functionaliteiten kunnen dan later worden toegevoegd. Wanneer er nieuwe functionaliteiten worden toegevoegd ontstaat er een situatie waarbij niet meer te vergelijken is of een systeem een goede vervanging van het oude systeem is. (Tilley, 1995)

Eventueel kan een project wel worden uitgevoerd met nieuwe functionaliteiten, er dient dan rekening gehouden te worden met een late bevriezingstijd van het ontwerp en veranderingen en met koersveranderingen halverwege. Het risico van requirements creep wordt dan ook belangrijker: nieuwere eisen vergroten de complexiteit en schroeven de kosten omhoog. (Tilley 1995)

Bij nieuwe functionaliteiten is het zinnig om middels rapid-prototyping in de eerste stadia de vereisten te filteren en te valideren. (Tilley, 1995)

Er moet zorg gedragen worden voor voldoende beschikbaarheid van onderhoudspersoneel van de betreffende applicatie. Wanneer hier niet aan voldaan wordt, geldt dit als risico voor het project. (Tilley, 1995)

43


4. Kosten Voor de kosten berekening van het reengineering traject zou gekeken kunnen worden naar de toegevoegde regels code en de mate van aanpassing hiervan. COCOMO 2.0 geeft hier een goede opzet voor. Bij de kosten moet ook gedacht worden aan de verschillende kosten die zich kunnen voordoen door het gebruik van tools, aparte testomgevingen, nieuw gebruik van de onderhoudsomgeving, et cetera. Ook is het belangrijk dat wanneer de kosten zijn bepaald er een inschatting gemaakt wordt van de opbrengsten en er een kosten/baten analyse plaats vind. Deze kan gemaakt worden door te kijken naar de methodiek van Sneed in paragraaf 3.2.2. Ook moeten hier de verschillende strategieën vanuit de SRA, op basis van kosten tegenover elkaar gezet worden. Op basis van deze inschatting kan een GO-NOGO gegeven worden voor het project. Het is zinnig een set van metrieken in te voeren om de productiviteit en besparingen te achterhalen. Kostenmetrieken kunnen niet zomaar overgenomen worden uit de literatuur zonder getoetst te worden aan de organisatie. Iedere organisatie zit anders in elkaar en heeft daardoor een andere productiviteit.

5. Risico’s

Tijdens het doorlopen van de stappen kan gekeken worden naar de lijst met risico’s die nagelopen moeten worden in verschillende fasen van het project. Deze is opgenomen in Bijlage 7 . Het is ook verstandig om van te voren duidelijk te hebben welke risico’s wanneer een rol spelen.

Aandachtspunt: Het risico bestaat dat onschuldige lijkende onderdelen van het legacy systeem showstoppers

kunnen worden. Voorbeelden waarbij aan gedacht moet worden zijn het gebrek aan datascheiding en het gebrek aan documentatie van het berichten verkeer. (Tilley, 1995)

PRODUCT Voor het product zijn begrip van het bestaande en doelsysteem de belangrijke factoren. Aandachtspunten:

Bij veel nieuwe technologieën moet rekening gehouden worden met de leertijd. Deze kan gemakkelijk uit de hand lopen en tot drie keer de tijd innemen die nodig is voor het reengineeren. Dit risico moet gedragen worden door het management van de opdrachtgever, anders moet er een keuze gemaakt worden voor doel systeem waarvoor de beschikbare kennis afdoende is. (Tilley, 1995)

Er zal constant geëvalueerd moeten worden welke nieuwe technologieën beschikbaar, bruikbaar en effectief zijn. Nieuwe concepten als ADM kunnen bestaande technieken overbodig maken.

De stap van het uitrollen moet niet onderschat worden. Kosten kunnen hoog oplopen door deze stap op een ad hoc basis uit te voeren. (Tilley, 1995)

Voor begripsvorming van het bestaande product kan gebruik gemaakt worden van een veelvoud aan technieken die zijn voorgesteld binnen het ‘horseshoe’-model. Deze kunnen deels of geheel geautomatiseerd worden en als tool ingezet worden. Met betrekking tot de tools moet er gesteld worden dat ze veel werk uit handen nemen, maar het zijn geen wonderoplossingen. Vooral tools die automatische vertalingen uitvoeren, vallen in dit kader tegen. Aandachtspunt:

Verschillende gevoelige onderdelen van de doelomgevingen en legacy omgevingen kunnen lastig zijn voor de tools om mee om te gaan. Er moet altijd rekening gehouden worden met meer handmatige codewijzigingen dan geschat. (Tilley, 1995)

Samen met hoofdstuk 3 biedt dit hoofdstuk dan een projectstructuur voor reengineering. Op basis van deze structuur zal naar de praktijk gekeken worden. Het vaststellen van de factoren die in de praktijk bekeken worden vind plaats in hoofdstuk 5, de operationalisering van het praktijkonderzoek.

44

Hoofdstuk 5: Operationalisering onderzoek

5 Operationalisering onderzoek

De theorie is vastgelegd in hoofdstuk 3 en 4. Op basis van deze theorie wordt naar de praktijk gekeken. Het praktijkonderzoek beslaat twee delen: de algemene Centric aanpak en de uitvoering van het SBA project. De eerste wordt bestudeerd door documentatie en de tweede wordt bestudeerd door interview en enquêtes. Om deze theorie naast de uitvoering bij SBA te leggen, moet deze geoperationaliseerd worden. In paragraaf 1 wordt de onderzoeksaanpak besproken met de verschillende vragen die beantwoord moeten worden. In paragraaf 2 en 3 volgen logischerwijs het interview ontwerp en het enquête ontwerp.

5.1 Onderzoeksaanpak

Onderstaand in figuur 5.1 is een Goal – Question – Metric (GQM) boom (Fenton en Pfleeger, 1997) opgenomen. Deze methode wordt gebruikt om het doel te ontleden en inzichtelijk te maken. Deze boom geeft het doel, de vragen en de metrieken aan. Onder een doel wordt het uiteindelijke te verkrijgen resultaat verstaan. Een vraag vervuld samen met het antwoord geheel of gedeeltelijk een doel. Tot slot zijn er een of meerdere metrieken per vraag. Een metriek is een meetbare eenheid. In figuur 5.1 is de samenhang tussen het doel, vragen en metrieken weergegeven.

figuur 5.1 - aanpak praktijkonderzoek

Het hoofddoel is het achterhalen van de uitgevoerde case aanpak. Om naast een evaluatie van de theorie ook een ontwerp aan te kunnen bieden, wordt ook gekeken naar de expertmeningen van de medewerkers aan het project. Vraag 1 voert terug op het projectmanagement, vraag 2 en 3 op het proces en vraag 4 en 5 op het product. In de volgende paragrafen wordt per vraag de relevantie naar het doel behandeld en de metrieken verklaard.

5.1.1 Hoe is het projectmanagement uitgevoerd? Het projectmanagement wordt geëvalueerd volgens de theorie van Aken (1997). Voor deze vergelijking zijn de factoren grijpbaarheid, werkstijl en instrumentgebruik nodig. Om meer inzicht te krijgen in het instrumentgebruik, worden naast de gebruikte instrumenten ook de waardering voor deze instrumenten achterhaalt. Op basis van deze gegevens en de theorie kan er een advies gedaan worden voor het projectmanagement. De volgende metrieken moeten dus zorgen voor het antwoord op deze vraag:

Grijpbaarheid (wordt bepaald door meting van Aken (2002), zie paragraaf 3.1.1)

45


Werkstijl Deze wordt vastgesteld door de contrastparen van van Aken (1997) voor te leggen. Voor de bepaling van deze waarden zie paragraaf 3.1.1

Instrumentgebruik Instrument ingezet

Dit betreft de opsomming van de verschillende instrumenten die ingezet zijn. Waardering toegevoegde waarde inzet van het instrument

Per instrument kan er een waardering op een vijfpunts ordinale schaal gegeven worden.

Het vragen naar de toegevoegde waarde van de inzet van de instrumenten, is om te kijken welke instrumenten eerder achterwege gelaten kunnen worden als het raadzaam lijkt om minder instrumenten te hanteren. Van Aken (1997) telt in zijn dissertatie slechts de instrumenten, vandaar deze verdieping. De resultaten van deze vraag worden behandeld in paragraaf 6.2.2.

5.1.2 Wat zijn de risico’s van een project? Op basis van de theorie van risico management (PMI, 2000), wordt een risico bepaald door de impact (de schade die het aanricht wanneer het zich voordoet) en de waarschijnlijkheid (de kans dat het zich voordoet). Wanneer deze metrieken achterhaald worden per risico, kan een overzicht gemaakt worden van de belangrijkste risico’s. Zowel impact als waarschijnlijkheid zal gemeten worden op een ordinale vijfpuntsschaal. Ook kan gezien worden welke risico’s zich hebben voorgedaan tijdens het project, om deze te kunnen benadrukken ten opzichte van de andere risico’s Hiernaast worden potentiële andere risico’s achterhaald die een impact op een reengineering project hebben. De risico resultaten worden behandeld in paragraaf 6.2.4.

5.1.3 Wat zijn de kosten en baten van een project? Om voor de aan te bevelen projectaanpak een begrotingsmethodiek voor te stellen, wordt enerzijds de COCOMO methodiek geëvalueerd en anderzijds de daadwerkelijke kosten en baten achterhaald. Er wordt hier een beperking gelegd op eenvoudig te kwantificeren kosten en baten, aangezien een volledige kosten en baten analyse te uitvoerig zou worden voor dit onderzoek. De evaluatie van de COCOMO benadering moet leiden tot een positief of negatief advies met betrekking tot het gebruik hiervan. De vaststelling van kosten en baten kunnen meegenomen worden naar een kostenberekening en kunnen ook aandachtspunten geven ten opzichte van de theorie. De metrieken voor de COCOMO berekening zijn dan de volgende: SU (Software begrip)

Wordt gemeten op basis van COCOMO verwerkingstabel voor SU. Hiervoor moeten structuur, applicatie duidelijkheid en zelfbeschrijvendheid worden gewaardeerd op een vijfpuntsschaal. Deze drie inzichten zijn vertaald naar architectuurkwaliteit, codekwaliteit en documentatiekwaliteit, zoals besproken in paragraaf 3.3.1.

UNFM (Onbekendheid met de software) Wordt gemeten op basis van COCOMO verwerkingstabel voor UNFM. Hiervoor wordt de bekendheid op een zespuntsschaal gemeten. Deze kan vervolgens worden omgezet naar een factor van 0 tot 1.

DM - Percentage Aangepast Ontwerp Wordt gemeten in percentages (ratio schaal)

CM - Percentage Aangepaste Code Wordt gemeten in percentages (ratio schaal)

IM - Percentage Inspanning benodigd voor Integratie Wordt gemeten in percentages (ratio schaal)

AA – Mate waarin er sprake is van aanpassing

46


Wordt gemeten op basis van COCOMO verwerkingstabel voor AA. Hiervoor wordt de inspanning vertaald naar een vijfpuntstschaal die resulteert in een waarde van 0 tot 8.

KLOC – Het aantal regels code Wordt absoluut gemeten (ratio schaal)

De verwerking en uitwerking van deze kostengegevens is te vinden in paragraaf 6.2.5.

5.1.4 Wat is de impact van het product? Omdat de variabele factor in een reengineeringproject het bestaande product is, moet het uitgevoerde SBA project in de context van het product gezet worden. De impact wordt bepaald door de kennis die nodig is voor het project. Deze is binnen het theoretische kader in vier delen opgedeeld. Hiernaast is uiteraard de kwaliteit van het bestaande systeem relevant om de context te zien. Kwaliteit van de legacy software.

Er is hierin een onderscheid gemaakt in de kwaliteit van 4 factoren: Architectuur Code Documentatie Database

De kwaliteit van deze 4 onderdelen kan gemeten op een ordinale vijfpuntsschaal. Kennis van het team m.b.t. technologieën voor software.

Er is hierin onderscheid gemaakt in de factoren: Architectuur Algemeen Architectuur Specifiek (voor betreffende architectuur) Code Algemeen Code Specifiek (voor betreffende programmeertaal) DBMS Algemeen DBMS Specifiek (voor betreffende DBMS)

Al bovenstaande metrieken kunnen gemeten worden in jaren ervaring (ratio schaal). Kennis van het team m.b.t. de specifieke doeltechnologie(en) voor de software.

Deze kennis is op dezelfde wijze op te delen als de kennis met betrekking tot bestaande technologieën.

Ervaring van het team met de legacy software. Deze factor is gelijk getrokken met de factor UNFM van de COCOMO methodiek. Dit betreft een zespuntsschaal (ordinaal) voor ervaring met de applicatie.

De relatieve product impact is te herleiden naar het begrip van het bestaande systeem, de kennis van de legacy omgeving door het team en de kennis van het team van de doeltechnologie (= architectuur, code en data). Wanneer deze drie zijn vast te stellen, kan er gekeken worden in welke mate er een verhoogd risico is (bijvoorbeeld een slechte kwaliteit en slechte kennis van team is een slechte beginsituatie voor reengineering) er van uitgaande dat er als resultaat uit de enquête geconcludeerd kan worden dat deze situatie niet bij het project van toepassing was. De uitwerking van de product factoren wordt behandeld in paragraaf 6.2.6

5.1.5 Wat is de impact van tools? De output van deze vraag moet een basis voor toolselectie geven, door een inzicht te verschaffen in de impact die tools kunnen hebben op een reengineeringproject. Het voornaamste nut van tools is het verkrijgen van begrip van het legacy systeem. Door aan de verschillende vormen van begripcreatie een belang te hechten en vervolgens te categoriseren in welke van deze fasen een tool voldoende scoort, kan bepaald worden welke impact een tool heeft op een project. Hiernaast wordt een inzicht verkregen in het belang van de technieken.

47


Hiervoor zijn de verschillende fasen in het ‘horseshoe’ model (zie paragraaf 3.3.1) bruikbaar als technieken waarin een tool kan volstaaan. Om het belang van een tool te meten kan dan gekeken worden naar de volgende metrieken: Belang aan fase binnen ‘horseshoe’ model

Deze waardering kan op een ordinale vijfpuntsschaal gemeten worden. Voldoende inzet van tool in fase

Deze waardering betreft een schaal met twee mogelijkheden: voldoende of onvoldoende. De manier hoe tools en bij welke activiteiten deze zijn ingezet kunnen niet achterhaald worden met behulp van metrieken. De resultaten van deze laatste vraag worden behandeld in paragraaf 6.2.7.

5.2 Verzameling gegevens

Voor het achterhalen van de informatie, wordt gebruik gemaakt van drie methoden van gegevensverzameling: documentatie, interview en enquêtes. Met betrekking tot de documentatie van het project is gebruik gemaakt van het projectmanagement plan, het projectplan, verschillende presentaties en audits van het systeem door derde partijen. De beschikbare plannen waren opgezet voor de tweede fase van het project. Deze zijn gebruikt om een eerste inzicht te verkrijgen en als naslagwerk voor verheldering. Voor het achterhalen van de algemene aanpak van Centric (CPA) en de verschillende stappen en activiteiten binnen de case, wordt ook gekeken naar de documentatie die hierop betrekking heeft. Deze documentatie wordt benoemd in de interne referenties. Hiernaast wordt gebruikt gemaakt van enquêtes voor de medewerkers, om zo de verschillende ervaringen en expertmeningen makkelijker te kunnen middelen. Hierdoor kunnen deze ervaringen concreter meegenomen in de beschrijving. Er is voor gekozen om bij het afnemen van de enquêtes aanwezig te zijn. Hierdoor kunnen er vragen gesteld worden en kunnen er eventuele opmerkingen meegenomen worden. Ook kunnen vragen eventueel verduidelijkt worden. Het voordeel van anonimiteit valt hiermee echter weg. Tevens zal er een interview met de projectleider plaatsvinden, om op deze manier hiaten en onvolkomenheden in de documentatie te achterhalen. Ook zijn er verschillende vragen die niet door projectmedewerkers, maar wel door de projectleider te beantwoorden zijn. In de volgende paragrafen wordt respectievelijk het ontwerp van het interview en het ontwerp van het interview besproken.

5.3 Ontwerp van het interview

Voor het interview is er gekozen voor een semi-gestructureerd interview. Hierdoor kunnen zowel nieuwe inzichten alsook vooropgestelde factoren naar voren komen. De volgende vragen worden in het interview behandeld, teneinde de projectaanpak verder te verduidelijken. Hoe is het proces verlopen? Welke stappen zijn er gedaan in het reengineering project (voor hiaten in documentatie en

toespitsing op theoretische methodiek.) Wanneer de oude situatie van SBA wordt geëvalueerd met behulp van de portfolio analyse en SRA,

wat zijn dan de uitkomsten? (geeft inzicht in inzetbaarheid van deze technieken) Wat zijn de kostenfactoren ten opzichte van het project? De gegevens die verkregen moeten worden vanuit het interview, moeten een beeld geven van de daadwerkelijke kosten en besparingen. Functiepunten / KSLOC van PAS. Kosten in daadwerkelijke uren.

48


Besparingen (Waar zijn deze geconstateerd, zijn de besparingen uit de theorie gezien in de praktijk?)

Wat is de toolimpact geweest op het voortraject? Is er gebruik gemaakt van tools voor het bepalen van de te kiezen strategieën? Waar zijn eventuele tools voor gebruikt in het voortraject?

De uitgewerkte interviewvragen zijn opgenomen in Bijlage 12 .

5.4 Ontwerp van de enquête

Onderstaand worden de hoofdvragen van het praktijkonderzoek en de verwerking hiervan in de enquête behandeld. Bij het opstellen is gebruik gemaakt van de richtlijnen van McNamara (1999). 1. Op welke wijze is het projectmanagement uitgevoerd? Opgenomen in de enquête zijn: Werkstijl contrastparen (van Aken, 2002) Instrumenten en waardering

De grijpbaarheid wordt hier niet behandeld, omdat dit in principe geen ervaringscijfer aangeeft, maar een typering van het project. Deze is daarom buiten de enquête vastgelegd. 2. Welke mogelijke risico’s zijn er bij een reengineering project? De volgende factoren zijn per risico bevraagd: Voorgekomen (ja / nee) Impact Waarschijnlijkheid van voorkomen

Naast de risico’s uit de literatuur(zie Bijlage 7 ), zijn ook de risico’s die in het SBA projectplan stonden verwerkt in de uiteindelijke lijst voor de enquête (zie Bijlage 10 ) Er zijn een aantal specifieke risico’s uit de enquête gelaten en toegevoegd bij het interview met de projectleider. Deze en een aantal overige schijnbare inconsistenties met de literatuur zijn besproken en verantwoord in Bijlage 11 . Gevolg van de succesvolle uitvoering van het project is dat er geen tot nauwelijks risico’s operationeel zijn geworden. Om te evalueren in welke mate de verschillende risico’s van belang zijn, is in de enquête gekeken naar de waarschijnlijkheid en de impact van belangen. Deze belangen zijn feitelijk risico’s die in positieve vorm zijn omgezet. De waarschijnlijkheid dat een belang zich voordoet is hier dan omgezet naar de waarschijnlijkheid dat een risico zich voordoet en is dus omgekeerd (is een het voordoen van een belang waarschijnlijk, dan het voordoen van een risico niet en vice versa). 3. Wat zijn de kostenfactoren ten opzichte van het project? De kostenfactoren worden bepaald door de COCOMO metrieken te vragen in de enquête: SU, UNFM, DM, IM, CM, AA, KLOC.

Deze fatoren worden niet verder toegelicht. Zie hiervoor paragraaf 5.1.3. 4. Wat is de impact van de product factoren geweest op de uitvoering van het project? De verschillende factoren die betrekking hebben op kennis en kwaliteit kunnen hiervoor bevraagd worden:

Kennis van het bestaande systeem (COCOMO – UNFM factor) Kwaliteit van de bestaande situatie (architectuur, code, DBMS, documentatie) Kennis van het doelsysteem(architectuur algemeen, architectuur cbd, etc.) Kennis van de huidige systemen

49


Deze kennis is niet meegenomen, aangezien de huidige situatie hetzelfde aan kennis betrof, minus CBD architecturen.

5. Wat is het belang van het toolgebruik geweest? Hiervoor zijn de vragen opgenomen:

Waardering van de technieken horseshoemodel Waardering gebruikte tools ten opzichte van technieken

De enquêtevragen zijn opgenomen in Bijlage 12 .

5.5 Conclusies

In dit hoofdstuk is op basis van een GQM-boom (Fenton & Pfleeger, 1997) een ontwerp gemaakt voor het praktijkonderzoek. De gegevens zullen verkregen worden door het bestuderen van documentatie, het houden van een interview en het afnemen van enquêtes. Op basis van de te beantwoorden vragen zijn een interviewontwerp en een enquêteontwerp gemaakt. Vanwege de uitvoerigheid en mogelijke complexiteit is besloten om bij het afnemen van de enquêtes aanwezig te zijn. In het volgende hoofdstuk zal de informatie die betrokken is uit de documentatie, interviews en enquêtes worden verwerkt in een beschrijving en evaluatie van de huidige projectaanpak van Centric.

50

Hoofdstuk 6:Huidige Reengineering Project Aanpak bij Centric

6 Huidige Reengineering Project Aanpak bij Centric

In dit hoofdstuk wordt ingegaan op de aanpak die bij Centric gehanteerd wordt. Enerzijds betreft dit een beschrijving van de algemene projectinrichting, anderzijds betreft dit de informatie uit de casestudy van een uitgevoerd project, op basis van de operationalisering in het vorige hoofdstuk. Aan het eind van elke subparagraaf wordt een korte conclusie getrokken worden hoe deze uitvoering zich tot de theorie verhoudt. In de laatste paragraaf worden tot slot de conclusies gegeven.

6.1 Centric Project Aanpak

De core business van Centric is het uitvoeren van ICT projecten. In de jaren waarin Centric projecten heeft uitgevoerd, zijn er lessen geleerd die kunnen helpen bij het uitvoeren van nieuwe projecten. Deze zijn samengevoegd in de Centric Project Aanpak (CPA) en de Centric Beheer Aanpak (CBA). De beheersaanpak wordt buiten beschouwing gelaten in dit verslag, aangezien deze aanpak is ingesteld op het inrichten van een proces en niet een project.

De CPA bestaat uit vier hoofdfasen: Bid Management, Project voorbereiding, Project Uitvoering en Project Afsluiting. Per fase zijn er technieken en richtlijnen. In

figuur 6.1 is deze aanpak in fases weergegeven.

figuur 6.1 - CPA overzicht (Interne referenties, CPA)

Fase Bid-management In de fase bid-management komt een lead binnen. Deze lead wordt beoordeeld door een team dat bestaat uit een commercieel manager, de directeur en het projectbureau. Wanneer de lead een ‘GO’ krijgt, start de uitvoeringsfase van het bid-management. In de uitvoeringsfase van het bid-management staat het projectvoorstel centraal. Na interne reviews en klant reviews wordt het goedgekeurd en zal de afsluitingfase van het bid-management plaatsvinden. Dit betreft evaluatie, kennisborging, decharge en overdracht van het bidproces. Hulpmiddelen voor het bid-management zijn een begrotingstool, het gebruik van functie punt analyse en de SarBachets risico analyse.

51


Fase Voorbereiding De fase voorbereiding kan vervolgens gestart worden. In deze fase staat het plan van aanpak centraal. Dit plan van aanpak heeft een basis in het projectvoorstel. Samen met de klant wordt dit plan van aanpak opgesteld. Het bevat alle afspraken en regelingen die relevant voor het project moeten zijn. Hiernaast worden er procedures en regelingen vastgelegd over de beheersing van het project. Aan het begin van elke nieuwe fase binnen de uitvoeringsfase zal het plan van aanpak aangepast worden en ter goedkeuring aan de opdrachtgever worden aangeboden. Na de eerste goedkeuring, zal de project-startup plaats vinden. In deze fase vinden alle voorbereidingen plaats die in het plan van aanpak staan aangegeven. Er zijn vervolgens interne procedures voor het inregelen van kwaliteit en het verkrijgen van resources. Fase Uitvoering De daadwerkelijke uitvoering wordt ondersteund door procedures voor escalatie, wijzigingen, risico en issue logging en voortgangsrapportages. In het geval dat een project gefaseerd word aangeboden, zal er ook een stuk voorbereiding zijn voor de nieuwe fase, met aanpassingen of vernieuwende plannen van aanpak. Fase Afsluiting De projectafsluiting bestaat uit een interne en externe evaluatie. Hierna vind decharge plaats en wordt het projectdossier afgerond. Tijdens alle fasen wordt de documentatie bijgehouden in het offertedossier, wat na de fase bidmanagement het projectdossier wordt. Ook is er binnen de CPA een document ‘Applicatieontwikkeling’. In dit document zijn de richtlijnen beschreven voor de fasering en indeling van een ontwikkel traject volgens het watervalmodel. De onderzoek scope op de CPA zal zijn op de dienstgerelateerde producten en aanpak, aangezien de overige procedures geen invloed ervaren van project specifieke eigenschappen. Dit houdt in dat de aanpak op het gebied van communicatie met het projectbureau en de sturing hiervan met procedures niet de aandacht krijgt, maar de aanpak betreffende de fasering en sturing van deze fasen.

6.1.1 Proces - Risico’s De CPA is uitgerust voor het onderkennen van high-level project risico’s. Hiervoor is een analyse methode genaamd ‘SarBachets’ geadopteerd. De methode heeft 5 gebieden waar het op richt; projectorganisatie, projectomgeving, projectomvang, techniek en automatiseringervaring. Voor elk van deze gebieden wordt een vragenlijst ingevuld, waarbij de antwoorden de impact weergeven. Deze impact wordt met een per vraag vastgestelde wegingsfactor vermenigvuldigt, waardoor per gebied een risico indicatie in procenten verkregen wordt. Vervolgens kan op basis van de percentages het totale risico procentueel worden weergegeven. Op basis van de percentages kan bepaald worden of een van de 5 gebieden nader geanalyseerd moet worden. Bij het totale project kan gekeken worden of er een acceptabel risico gelopen wordt. Hiernaast wordt de mogelijkheid gegeven om risico’s te onderkennen op basis van ervaring. Deze risico’s worden uitgezet tegen de impact (hoog, midden, laag) en kans(hoog, midden, laag). Vervolgens kan per risico de aard en de maatregel bepaald worden (veelal in overleg met de klant). De SarBachets analyse wordt meestal uitgevoerd in de fase Bid-management en wordt voornamelijk uitgevoerd bij nieuwe klanten. Bij al bestaande klanten wordt er vaak door de opdrachtgever vertrouwd op resultaten die in het verleden behaald zijn, en de expertinschatting van de risico’s door Centric.

6.1.2 Proces - Kosten Met betrekking tot kostenberekeningen zijn voor de CPA uitgebreide Excel sheets met begrotingsgegevens beschikbaar. Ook kan de functiepunt analyse (FPA) van Centric gebruikt worden om een schatting te maken van de tijd die benodigd is voor de realisatie van een nieuwbouw systeem.

52


Bij grotere projecten wordt er naast de FPA ook een equivalent van de FPA gebruikt; de Walvis Punten Analyse (WPA). Deze heeft een standaard verhouding tot de FPA en wanneer er een afwijking is tussen deze twee kan er gekeken worden welke inschattingen wellicht niet betrouwbaar zijn.

6.2 Casestudy: SBA

In dit gedeelte wordt ingegaan op de casestudy, het reengineeringproject dat is uitgevoerd bij SBA. Eerst zal de aanleiding en context van het project beschreven worden, waarna per paragraaf een onderdeel van het theoretische kader wordt behandeld

6.2.1 Context en aanleiding Walvis Software is een softwarebedrijf dat gespecialiseerd is in Progress en EDI oplossingen. In 2001 is Walvis overgenomen door Centric. In hetzelfde jaar heeft Walvis een project bij SBA uitgevoerd onder de noemer ‘reconstructie’. Later is dit concept vernieuwbouw gedoopt. SBA Artsenpensioenfondsen is de organisatie die belast is met de uitvoering van de pensioenregelingen van de Stichting Pensioenfonds voor Huisartsen en de Stichting Pensioenfonds Medische Specialisten. Bij SBA wordt gebruik gemaakt van de applicatie PAS (Pensioenen Administratie Systeem). Deze applicatie was verouderd geraakt door aanpassingen en onderhoud en was niet flexibel aan te passen en moeilijk te onderhouden. Mede hierdoor was het geheel van de producten, het proces en de applicatie PAS, een legacy probleem geworden. In 1997 is de applicatie bij Walvis in onderhoud genomen. Omdat SBA in 2002 actief en flexibel wilde inspelen op de behoeftes van de klant, andere producten wilde aanbieden en moest voldoen aan nieuwe vereisten naar aanleiding van nieuwe wetgeving, kwam dit legacy probleem naar voren. Er is hiervoor gekeken naar een nieuwbouw applicatie. Nieuwbouw was echter een dure oplossing. Walvis heeft een alternatief voorgesteld onder de noemer: ‘reconstructie’. De nieuwe applicatie wordt dan ook RePAS genoemd. Op basis van de operationalisering zoals neergelegd in hoofdstuk 5, wordt in de volgende paragrafen ingegaan op de verschillende projectfactoren.

6.2.2 Projectmanagement voor Reengineering SBA heeft een externe projectmanager aangesteld die dit project moest aansturen. De structuur van het project bestaat uit een projectgroep die verschillende werkgroepen aanstuurt. In figuur 6.1 is deze structuur ingevoegd:

figuur 6.2 - organisatie SBA project

De projectgroep betreft de vertegenwoordiging van de directie, de projectmanager en de verschillende werkgroepleiders. De groep ‘systeemontwikkeling RePAS’ betreft de werkgroep van Walvis. Hieronder valt dus niet alleen systeemontwikkeling, maar ook ontwerp, realisatie en testen (het proces van systeemontwikkeling). Het bulk en performance testen ten opzichte van het totale eindsysteem zijn de verantwoordelijkheid van de werkgroep ‘Testen’. Verder zijn er een drietal externe partijen betrokken bij het project.

53


Er is binnen het kader projectmanagement gekeken naar het projectmanagement binnen de groep Systeem Ontwikkeling RePAS. Hiervoor is gekozen omdat dit gedeelte binnen het kader van het feitelijke reengineering valt. De scope van dit onderzoek strekt zich niet uit naar business proces reengineering, waar binnen de organisatie feitelijk sprake was. Voor het projectmanagement gedeelte wordt de waardering van van Aken (2002) over genomen.Voor de werkstijl telt een kruisje links voor 2 punten, in het midden voor 1 punt en geheel rechts voor 0 punten. De paren 1,2,3,4,6,8,9 kunnen opgeteld worden voor een structurerende werkstijl. De paren 5,10,11,12,13,14 kunnen worden opgeteld voor een doelgerichte werkstijl. De score van beide valt dus maximaal uit op 14 (alle kruisjes links) en minimaal 0 (alle kruisjes rechts). Het midden van de schaal is dus 7. Wanneer deze scores worden bekeken bij het SBA project, dan krijgen we het volgende overzicht:

Enquête nr. 1 2 3 4 5 6

Score Structurerend 12 10 8 11 12 12

Score Doelgericht 11 9 10 8 10 10

tabel 6.1 - enquête resultaten werkstijl

Uit deze tabel komt een gemiddelde structurerende werkstijl van 10,8 en een gemiddelde doelgerichte werkstijl van 9,6. Beide zijn ruim boven middelste score van 7. Wanneer er gekeken wordt naar de uitvoering van het SBA project, kan er gesteld worden dat zowel de structurerende stijl als de doelgerichte stijl in voldoende mate aanwezig was. Hiernaast is de grijpbaarheid van het project bepaald en deze net als in hoofdstuk 3 laag ingeschat. Hierdoor is er behoefte aan meer structurerende werkstijl dan bij grijpbaardere projecten. Het projectmanagement komt dan ook overeen met de theorie en is goed uitgevoerd. De waardering voor de verschillende instrumenten is opgenomen in tabel 6.2.

Onderdeel Waardering (mediaan) N

Planning 4,5 (hoog – zeer hoog) 6

Begroting 3,5 (gemiddeld - hoog) 6

Voortgangsrapportages 4,5 (hoog – zeer hoog) 6

Risico analyse 2,5 (laag – gemiddeld) 6

MS – Project (PERT, GANT) 4 (hoog) 1

Presentaties / walkthroughs 4 (hoog) 1

Kick off bijeenkomst 4 (hoog) 1

Projectoverleg 5 (zeer hoog) 1

ISO 9001 kwaliteitssysteem 5 (zeer hoog) 1

tabel 6.2 - instrumentenwaardering project

Dit geeft een totaal van 9 instrumenten die zijn ingezet. De software tools worden weggelaten omdat deze niet onder de definitie vallen van instrumenten. MS-Project is wel hierbij toegevoegd omdat deze naast het hanteren van de planning ook heeft gezorgd voor GANT en PERT charts. Er kan hierbij opgemerkt te worden dat de risicoanalyse relatief laag is gewaardeerd. Dit is in ieder geval gedeeltelijk terug te voeren op het feit dat niet alle werknemers hiermee te maken hebben gehad. De projectleider(s) waardeerden de risico analyse ook hoger dan de medewerkers. Een hogere inschaling van de verschillende stuurmiddelen en het toevoegen van stuurmiddelen door de projectleiders, doet concluderen dat de medewerkers minder bewust zijn van de stuurmiddelen dan de projectleiders. Er kunnen hier twee mogelijke oorzaken voor zijn:

1. De medewerkers ervaren niet alle stuurmiddelen als stuurmiddelen; Een voorbeeld hiervan zou kunnen zijn de ISO standaard, die als standaard werkwijze wellicht niet als een apart stuurmiddel wordt ervaren.

54


2. De medewerkers ervaren niet alle stuurmiddelen; Een voorbeeld hiervan zou de risicoanalyse kunnen zijn. De medewerkers hebben aangegeven dat

ze niet betrokken zijn geweest bij het opzetten van de risicoanalyse. Uit nieuwere projecten is naar voren gekomen dat het werk van reengineering enerzijds uitdagend is, maar ook gedeeltelijk weinig inspirerend. Onderdelen waarbij code verzameld moet worden en weer ingedeeld moet worden in nieuwe onderdelen is een weinig creatief proces. Ook belangrijk hierbij is om op basis van de complexe en wat meer routine onderdelen, de medewerkers ook moeten worden ingedeeld naar ervaring en karakter.

6.2.3 Casestudy SBA: Proces van Reengineering In deze paragraaf zal de portfolio analyse, software reengineering assesment en uitvoering van dit project worden behandeld. 6.2.3.1 REENGINEERING ACTIVITEITEN Bij het SBA traject was er geen sprake van een preventief traject. Er is geen reengineering portfolio analyse uitgevoerd, omdat de opdrachtgever zich bewust was van een probleem met de huidige software. De software was dus feitelijk al ingeschaald in de categorie van een hoog technisch risico en een hoge bedrijfswaarde, zonder een analyse hiervoor uit te voeren. Walvis heeft hier de optie aangedragen voor reconstructie. Nieuwbouw was te duur, een standaardpakket zou teveel maatwerk nodig hebben. Er is dus gekozen voor de optie van reconstructie. Wanneer de portfolio analyse zou worden uitgevoerd zoals deze vastgelegd is in het theoretische kader (paragraaf 3.2.1.1), komt deze uit op een hoge bedrijfswaarde (>35), maar een laag technisch risico (+/-15). Hieruit zou een beoordeling komen van componentmogelijkheden. Dit houdt in dat de applicatie vervangen zou kunnen worden door modules apart te zetten en over te gaan op standaardpakketten. De hoge bedrijfswaarde is bevestigend voor de goede van deze eerste inschatting. Op basis van het technische risico, komt echter dat het model niet voldoet, of dat het project beter niet uitgevoerd had kunnen worden. Om de bruikbaarheid van de SRA te evalueren is deze ingevuld door de projectleiders, uitgaande van de bestaande situatie aan het begin van het project. De vragenlijsten zijn al opgenomen in Bijlage 4 . In Bijlage 13 zijn de antwoorden opgenomen die gegeven zijn op deze vragen. In tabel 6.3 zijn hier de resultaten van opgenomen en zullen hier verder besproken worden. De waarden die voortkomen uit de vragenlijsten hebben als resultaat een gemiddelde tussen 1 en 3. Score Indicatie van strategie Resterende levensduur applicatie (jaren) 8 Ja

Leeftijd applicatie (jaren) 10 Ja

Voorbereiding (1-3) 1,79 Nee

Belang van reengineering (1-3) 2,33 Ja

Onderhoudsomgeving (1-3) 1,60 Nee

Redocument (1-3) 2,40 Misschien

Restructure (1-3) 2,10 Misschien

Broncode Vertaling (1-3) 1,86 Misschien

Data reengineer (1-3) 1,60 Nee

Retargeting (1-3) 1,25 Nee

Reverse engineering Ja

Redevelopment Nee

Status Quo Nee

tabel 6.3 - overzicht SRA strategieën voor SBA case

55


Eerst zullen vier waarden besproken worden die niet gerelateerd zijn aan de vragenlijsten: 1. De resterende levensduur is op voldoende jaren gesteld om door te gaan (meer dan 5). Het

betreft immers de kernapplicatie bij de opdrachtgever, die alleen in aanmerking zou komen voor vervanging voor nieuwbouw (redevelopment).

2. Reverse engineering is positief beoordeeld in de zin dat redocumentation hier een vorm van is. Aangezien er alleen sprake is van herstructureren en herdocumenteren is het niet nodig om een abstracter model te verkrijgen met behulp van reverse-engineering.

3. Redevelopment is negatief beoordeeld. Dit is wel als alternatief gewaardeerd, maar is te duur geoffreerd om mee door te gaan.

4. Status Quo behouden is ook geen haalbaar alternatief geweest, aangezien er wijzigingen moesten plaatsvinden om de bedrijfskritische processen draaiende te houden.

In bovenstaande assesment komt naar voren dat de strategieën ‘Redocument’, ‘Restructure’ en ‘Broncodevertaling’ overwogen zouden moeten worden. Bij het SBA project was er sprake van het uitvoeren van voornamelijk een restructuring project. Er wordt niet overgegaan naar een andere programmeertaal, ander platform (hardware of OS) en er wordt niet overgegaan naar een andere database. Wel worden de verschillende onderdelen (broncodes en data) geherstructureerd en opnieuw vastgelegd. Ook is er een volledig nieuwe documentatie opgeleverd. De strategieën restructure en redocument komen daarom overeen. Verder vallen de volgende aspecten voornamelijk op: - Voorbereiding krijgt een negatieve beoordeling voor het reengineering traject;

Aangezien het project toch succesvol is verlopen en de waarde redelijk dicht tegen de 2.00 aanligt, is er gekeken naar de vragen. Vanuit deze vragen moet er ten eerste geconcludeerd worden dat in het handboek (Departement of Defense, 1997) een pagina mist, waardoor een aantal vragen niet meegenomen worden. Het weglaten van vragen beïnvloed het antwoord alleen in de mate dat het minder genuanceerd is (het gemiddelde wordt door minder vragen bepaald) Er is daarom geconcludeerd dat het weglaten van de vragen geen ernstige invloed op de uitkomst zal hebben. Verder zijn 5 van de 6 ‘1’-waarden veroorzaakt worden door vragen over CMM en over metrieken. Zonder deze vragen zou er een ruime waarde boven de 2.00 gerealiseerd worden.

- De onderhoudsomgeving is geen extra argument voor reengineering; Dit is niet een gebrek, maar zou een eventuele extra stimulans kunnen zijn voor het reengineering project. Er zijn geen bijzondere of afwijkende vragen / antwoorden gevonden voor deze resultaten.

Ook zou een broncode vertaling overwogen moeten worden. Dit is opvallend, aangezien er geen behoefte was aan een verandering qua taal en dat waarschijnlijk eerder problemen zou geven dan oplossingen. Daarom is hier ook naar de vragen gekeken. Hier is geconstateerd dat er maar 1 hoge waarde uitkomt, en dat is op de vraag of het personeel getraind is in de doeltaal. Dit is uiteraard met ‘ja’ beoordeeld, omdat deze dezelfde taal was als de oorspronkelijke taal. Wanneer deze op ‘nee’ gezet wordt (voor een willekeurige andere taal), zou hier een negatief advies uitvolgen voor de broncode vertaling. Tot slot zijn er een aantal opmerkingen gemaakt met betrekking tot de vragen uit de vragenlijst: - Er is geen kennis van de cyclomatische of essential complexiteit van de software binnen Centric; - De verhouding CSU ten opzichte van Functiepunten strookte niet met de praktijk van Centric; De factor die bepaald wordt door deze vragen is restructuring. Wanneer alle relevante vragen hierbinnen echter zouden worden weggelaten, zou deze score zelfs hoger uitkomen. Voor de uitvoering was het project gepland voor een jaar, van 1 januari 2001 tot en met 31 december 2001. Het project is opgedeeld in vier fasen. Het voornaamste onderdeel van dit proces betreft Fase 2: Reconstructie en aanpassing. Dit betreft de daadwerkelijke uitvoer van het project. Fase 1 is de onderzoeksfase, fase 3 de implementatie fase. Fase 4 is buiten beschouwing gelaten binnen deze case beschrijving. Deze fase betreft namelijk verdere stappen binnen het onderhoud / nieuwbouw gedeelten en is daarom niet relevant voor het kader reengineering.

56


Voor het uitvoeren van fase 2 zijn werkzaamheden opgezet die ontleend zijn aan de aanpassing van het datamodel en werkzaamheden die verricht moeten worden voor de aanpassing van het systeemmodel. Deze werkzaamheden zijn gecategoriseerd en toebedeeld aan deelprojecten. Uiteindelijk zijn hieruit 13 deelprojecten geformuleerd. Deze deelprojecten zijn geprioriteerd volgens de Moscow methode van DSDM en zijn ondergebracht in prioriteit Must-have, Should-have en Could-have. Er is vastgelegd dat er per deelproject een ontwerpdocument wordt voorgelegd aan de projectgroep met de beschrijving van de aanpassingen aan het datamodel en de programmatuur en de beschrijving van eventueel de ontwikkelen hulpmiddelen voor de testfase. In de testfase zijn er per deelproject functionele, component en integratie testen uitgevoerd. Al deze activiteiten tezamen en het incrementele karakter van deze aanpak zijn weergegeven in figuur 6.3.

Ontwerp

Test

Aanpassen datamodel

Aanpassen Programmatuur

Ontwikkelen conversie

programmatuur

Ontwikkelen hulpmiddelen tbv

testfase

FASE 1 - ONDERZOEK, ANALYSE, VASTLEGGEN

FASE 2 - RECONSTRUCTIE

Overzetten ontwikkelomgeving ->

productieomgeving

Aanpassen en maken documentatie

FASE 3 - IMPLEMENTATIE

Vastleggen proces en productmodel

Analyse PAS

Data- en Systeemmodel RePAS

Acceptatie en performance testen

figuur 6.3 - stappen in uitvoering SBA project

Het uitvoeren van de tweede fase is incrementeel uitgevoerd. Ieder project is afgerond, waarna er met een nieuw project is begonnen. Nadat alle projecten zijn getest, zijn deze achter elkaar doorgevoerd op de testomgeving, zijn deze door de acceptatie test gegaan bij SBA en is het systeem vervolgens in productie genomen. De testen bij Walvis zijn uitgevoerd met een beperkte testset, waardoor SBA uiteindelijk ook een aantal testen zou moeten uitvoeren. Dit betrof bulktesten, performance en acceptatie testen. Voor het uitvoeren van deze testen, heeft SBA aan het begin van het traject een apart team opgesteld. Dit team is echter later ontbonden en vervangen door medewerkers van SBA, omdat er bij het testen de nodige kennis van het pensioendomein nodig was. SBA heeft het testen ook uitgesteld tot het eind, omdat de organisatie niet ingeregeld was voor het testen. Tijdens het project zijn er concessies gedaan om het project binnen de afgesproken tijd te houden. Er is hiervoor een deelproject geschrapt. Dit deelproject is het jaar daarop alsnog uitgevoerd. Hiernaast zijn er op een lager niveau ontwerpwijzigingen doorgevoerd voor sturing. Als eindproduct is er een werkend systeem opgeleverd. Bij de afsluiting van het project heeft er een formele overdracht plaats gevonden naar de opdrachtgever en er is een specifieke planning opgesteld voor de volgende fase binnen het project, namelijk de onderhoudsfase. Door de opdrachtgever is er opdracht verstrekt voor een audit van RePAS door twee onafhankelijke partijen. Deze audits zijn beide positief over de vernieuwde applicatie in verhouding tot de kosten.

57


Wanneer de aanpak vergeleken wordt met de theoretische aanpak komen de fase ‘Onderzoek, Analyse en Vastleggen’ uit het project overeen met de fase ‘Plannen van Evolutie’. De fase ‘Reconstructie’ is over te zetten naar de fase ‘Implementatie’ en de fase ‘Migratie’ is over te zetten naar de renaissance fase ‘Oplevering’ en ‘Uitrol en gebruik’. De afwijking met het RMM onderdeel van de aanpak (de concrete invulling voor de renaissance planningsfase), is dat er geen specifieke business case is gemaakt, waarin de investering wordt gerechtvaardigd. Eigenlijk is deze business case intern bij SBA gemaakt op basis van de aanbieding van Walvis. Verder komen de stappen overeen met die in de RMM planning zitten. Er is een begrip gecreëerd van de bestaande applicatie (het doen van een analyse van PAS) de architectuur waar naar toe gegaan werd is bepaald (Component Based Development) en er is gekeken op basis van deze gegevens, welke stappen uitgevoerd moesten worden en welke impact dit maakte op de resources. De voornaamste verschillen die zijn geconstateerd, zijn de volgende:

Renaissance hanteert geen expliciet stadium voor het maken van tools voor de conversie / migratie.

De deelprojecten zijn geprioriteerd in het SBA project. Deze prioritering heeft bewezen toegevoegde waarde te hebben. Omdat niet alle deelprojecten gerealiseerd konden worden, kon met behulp van de prioritering bepaald worden welk deelproject uitgesteld kon worden.

Hiernaast zijn er de volgende opmerkingen te plaatsen: Bij het SBA project is er geen opleiding voor beheerders of voor gebruikers. Dit is echter niet een

gebrek, dit is een uitgangspunt die aan het begin van het traject zijn vastgelegd. Er zijn door Walvis geen acceptatietesten uitgevoerd. Dit was ook opgenomen als uitgangspunt.

SBA zelf zou de acceptatietesten en integratietesten uitvoeren. Hiernaast heeft SBA de testsets voor het apart testen van elk component gegeven.

Feitelijk is de PAS applicatie in delen opnieuw gebouwd, met hergebruik van de oude code. Deze deelprojecten zijn gezamenlijk op het eind doorgevoerd, waarna het gehele performance en acceptatie testen door SBA nog moest plaats vinden. In de laatste drie maanden zijn alle onderdelen overgegaan naar de nieuwe situatie. Er is dus bij het SBA traject gekozen voor een incrementele migratie. De onderdelen zijn echter op het eind achter elkaar doorgevoerd, waardoor de laatste fase veel lijkt op een big-bang overgang. Dit is een relatief risicovolle aanpak, omdat de impact van onverwachte problemen groter wordt. Zo kan het zijn dat de go-live van de nieuwe applicatie niet goed gaat, waardoor er weer teruggevallen moet worden op de oude applicatie. Omdat er geen sprake is van een situatie van parallel draaien, is het niet perse noodzakelijk om een aanpak te hanteren als iterative reengineering. Een verder vergelijk is daarom ook niet zinnig. In de volgende paragraaf zal verder gegaan worden met de risico’s die bevraagd zijn.

6.2.4 Proces - Risico’s Bij het specifieke traject zijn er verschillende risico’s onderkend in het plan van aanpak. In eerste instantie is er een lijst die is opgesteld door Walvis voor hun aandeel in fase 2. Al deze risico’s zijn opgenomen in de risico’s die zijn onderkend in het projectmanagementplan. Deze lijst is opgenomen in Bijlage 10 De bijzonder belangrijke risico’s van Sneed (1995) en bevestigd door SIG (2004), zijn allen gepareerd:

Performance loss: is ingeschaald in het projectplan als risico en zou worden gecompenseerd met een mindere mate van flexibiliteit en onderhoudsvriendelijkheid wanneer nodig. Hiernaast was er geen sprake van een situatie waarin dit risico extra zou wegen, zoals een migratie naar een andere taal. Ook is er nieuwe hardware gekomen, waardoor de performance een impuls heeft gehad.

Project vertragingen door mismatch in architectuur: was niet van toepassing, doordat er gebruik is gemaakt van dezelfde programmeertaal en DBMS.

Project vertragingen door test bottlenecks en gebrek aan testdata: Dit heeft Walvis afgeschermd door SBA verantwoordelijk te maken voor de aan te leveren testdata en het uitvoeren van performance en bulktesten.

58


Het falen in het behalen van de kwaliteitsdoelen; Speciaal hiervoor had SBA een Quality Assurance werkgroep opgezet, die voor de verschillende partijen de kwaliteit en het behalen hiervan in de gaten hield.

Verwerpen van de resultaten door de onderhoudsprogrammeurs; de programmeurs die verantwoordelijk waren voor het onderhoud, waren medewerkers van Walvis. Er is daarom ook geen sprake van een weerstand in het algemeen en specifiek bij de opdrachtgever.

Een overzicht van alle verschillende risico’s en hun score voor impact en waarschijnlijkheid is opgenomen in tabel 6.4. Hierin zijn de risico’s genummerd opgenomen, samen met of het risico zich heeft voorgedaan bij SBA (ja/nee) en de mediaan van de impact (I) en mediaan van de waarschijnlijkheid (W). In principe hebben overal 5 medewerkers gereageerd, indien anders staat het aantal reacties tussen haakjes vermeld achter de waarde.

Nr. Risico SBA I W

Ja Nee

I (Projectmanagement)

1 Er is onvoldoende configuratie management 0 5 5 2

2 Er is geen, of een gebrek aan kwaliteits borging of bewaking 0 5 5 2

3 Er is gebrek aan of helemaal geen metriekenprogramma 2 2 2(4) 2(4)

4 Vernieuwbouw wordt uitgevoerd zonder kennis en hulp van lokale applicatie experts

1 4 4 3

5 Er is een slechte definiëring van de kwaliteitsdoelen. 0 4 4 3

6 Er is geen adequate planning voor het project. 1 4 4 3

7 Legacy functionaliteit raakt achterhaald voor de vernieuwbouw inspanning is afgerond.

2 3 4 2(4)

8 Er waren test bottlenecks en / of een gebrek aan test data. 1 4 5 3

9 Voor en tijdens het project vertrekt er ervaren onderhoudspersoneel. 0 4 4 3

II (Product)

10 Er is sprake van een achterhaalde / overbodige operationele omgeving. 1 4 4,5(4) 2,5(4)

11 Het systeem voldoet niet aan de evolutievereisten (kan niet goed een vernieuwbouw proces ingaan)

1 4 4 3

12 De organisatie heeft het legacy systeem niet onder controle. 1 4 4 3

13 Er is een gebrek aan kennis en / of kunde voor het doelsysteem. 1 3 4,5(4) 3(4)

14 Er is een gebrek aan kennis van het huidige systeem. 2 3 4 4

15 Er is inadequate / inconsistente documentatie. 5 0 3 4

16 Er is sprake van een niet te realiseren doelsysteem performance eis. 0 4 4 3

17 Er wordt gebruik gemaakt van een onvolwassen technologie voor het doelsysteem. 1 4 4(4) 2

18 De operationele organisatie is niet verbonden aan het geven en volgen van trainingen.

3 1 2(4) 4(4)

19 Bestaande bedrijfskennis die vastgelegd is in de broncode, raakt verloren. 1 4 4 3

20 Het reengineerde systeem werkt niet naar behoren. 0 5 5 2

21 Er wordt te veel (dure) documentatie geproduceerd. 1 4 4 3

22 In de bestaande applicatie worden wijzigingen doorgevoerd tijdens de bouw van de nieuwe applicatie, die ook meegenomen moeten worden in de nieuwe.

5 0 4 3

23 Onduidelijkheid over overige applicaties die gebruikt worden, waardoor functionaliteit niet volledig achterhaald kan worden. (mensen houden bijvoorbeeld excel-lijstjes naast de applicatie aan)

3 2 4 3

III (Proces)

24 Subsystemen zijn verkeerd gekozen voor de vernieuwbouw benadering. 0 5 4 3

25 De Vernieuwbouw technologie is niet toereikend voor het bereiken van de doelen. 1 4 4 3

26 Er zijn hoge kosten door onderdelen die handmatig vernieuwbouwt moeten worden.

1 0 3 (3) 3(4)

27 De vernieuwbouw inspanning verschuift / Er is geen sprake van een apart ‘vernieuwbouw proces’

1 4 4 3

28 Nieuwe vereisten en functionaliteit worden toegevoegd tijdens het vernieuwbouw proces

5 0 4 3

59


Nr. Risico SBA I W

29 Modellering vindt nog plaats tijdens de bouw, waardoor delen van de programmatuur opnieuw gedaan moeten worden.

2 3 4 4

30 Mate van voorbereiding en reverse engineering is onvoldoende. 0 4 4 3

31 Achterhaalde informatie is niet bruikbaar of wordt niet gebruikt. 1 4 4 3

32 Objecten worden incompleet of verkeerd vastgelegd tijdens verkrijgen van het ontwerp.

0 5 3 3

33 Vastgelegde objecten integreren niet in het nieuwe systeem. 0 5 4 3

34 Moeilijkheden met het migreren van de bestaande legacy data. 1 4 3 3

35 Performance verlies door het migreren naar een andere omgeving of programmeertaal.

0 4 4 3

36 De organisatie maakt op een verkeerde manier gebruik van consultants en externe partijen (laat het over aan externe experts en is zelf niet tot weinig betrokken)

1 4 4 3

37 Project vertragingen door mismatch in architectuur (van programmeertalen en dbms)

2 2 4 4

IV (Tools) 3

38 BIS: Taal is niet ontworpen om de abstracte informatie weer te geven die nodig is voor de vereisten en ontwerp specificaties.

3 2 3 3

39 BIS: Moeilijk om veel ontwerp en requirements te verkrijgen uit de code. 1 4 4 (4) 3

40 Gebrek aan tool ondersteuning in het algemeen. 1 4 3,5 (4) 3

SBA JA: Aantal respondenten die opteerden voor ja SBA NEE: Aantal respondenten die opteerden voor ‘nee’ I: Mediaan van score op impact op ordinale schaal (1 t/m 5) W: Mediaan van score op waarschijnlijkheid op ordinale schaal (1 t/m 5) (nr) : Aantal respondenten. Wanneer geen nummer is het aantal respondenten 5.

tabel 6.4 - risico waardering projectmedewerkers

Om te kijken naar risico’s die zich hebben voorgedaan tijdens het traject, wordt een drempelwaarde van drie medewerkers gehanteerd voor een risico dat zich heeft voorgedaan, omdat hiermee de antwoorden betrouwbaarder worden. Wanneer als drempelwaarde 1 medewerker gehanteerd wordt, zijn er namelijk 29 voorgedane risico’s, bij een drempelwaarde van 3 slechts 7. De risico’s zijn onderstaand opgenomen met de impact die ze hebben gehad op het project.

15; Er is inadequate / inconsistente documentatie. (gemiddeld) 18; De operationele organisatie is niet verbonden aan het geven en volgen van trainingen.

(weinig) 22; In de bestaande applicatie worden wijzigingen doorgevoerd tijdens de bouw van de nieuwe

applicatie, die ook meegenomen moeten worden in de nieuwe. (hoog) 23; Het gebruik van derde applicaties (zoals excel-lijstjes is onbekend, zodat niet alle

functionaliteiten achterhaald kunnen worden. (hoog) 28; Nieuwe functionaliteiten en vereisten worden toegevoegd tijdens het vernieuwbouw proces.

(hoog) 38; BIS: Taal van de tool is niet ontworpen om abstracte informatie weer te geven die nodig is

voor de vereisten en ontwerpspecificaties. (gemiddeld) Om het belang van de risico’s die zich hebben voorgedaan te bepalen, kunnen deze het best naast de overig geëvalueerde risico’s geplaatst worden. Om deze te vergelijken zijn in figuur 6.4 alle verschillende risico’s op impact gesorteerd (links) en op waarschijnlijkheid (rechts). Een pijl van punt A naar punt B houdt hier in: “B heeft een hogere risico waarde dan A”.

60


figuur 6.4 - ordening risico's op impact en waarschijnlijkheid

In figuur 6.4 is de ordening verlopen per factor. De twee factoren moeten echter samen geëvalueerd worden. In eerste instantie is sortering verlopen met als belangrijkste variabele impact en als tweede waarschijnlijkheid. Dit geeft echter geen duidelijke classificatie voor bijvoorbeeld risico 14 (impact is 4, waarschijnlijkheid is 4) versus 8 (impact is 5, waarschijnlijkheid is 3). Er is daarom gekozen voor een partiele ordening, deze is weergegeven in figuur 6.5.

figuur 6.5 - partiele ordening van de risico's

Uit de partiele ordening (Fenton en Pfleeger, 1997) komt naar voren dat de risico’s 8, 13, 14, 29, 37 het hoogst scoren. Hiernaast hebben risico’s 1 en 2 een hoge impact en een heel lage waarschijnlijkheid en risico 14 een gemiddelde impact en een hoge waarschijnlijkheid. Op te merken valt dat groep ‘X’ het grootste gedeelte van de risico’s betreft en een hoog op impact scoort en een gemiddeld op waarschijnlijkheid. Er zijn dus maar een aantal risico’s die bijzonder hoog of laag scoren.

61


De voorgedane risico’s bij het SBA project scoren niet hoog op deze ordening. Dit is ook verwacht, aangezien het project succesvol verlopen is en daardoor niet veel impact van risico’s gehad kan hebben. Risico’s 15 en 18 zijn de enige die op de factor waarschijnlijkheid boven de groep ‘X’ scoren. Bij de partiele ordening valt alleen risico 15 naast groep ‘X’ uit. Beide risico’s zijn logisch binnen de context: De inadequate documentatie (risico 15) had weinig impact hebben doordat er gebruik werd gemaakt van de BIS tool (zie paragraaf 6.2.7) en tot slot waren er geen trainingen benodigd, omdat er geen uiterlijke veranderingen aan de applicatie waren (risico 18). Aan de projectleider zijn de risico’s voorgelegd die niet beantwoordbaar geacht (zie Bijlage 11 ) zijn door projectmedewerkers. Deze risico’s zijn namelijk gekoppeld aan inzicht in de werknemers en inzicht in de managementbeslissingen bij de probleemhoudende organisatie. Deze risico waarderingen zijn opgenomen in tabel 6.5.

Nr. Risico I W

1 Het personeel heeft niet de juiste competenties en ervaring in vernieuwbouw 1 4

2 Er is onvoldoende managementcommitment voor de voortdurende vernieuwbouw inspanning

4 2

3 Het management neemt vooraf technische beslissingen 2 3

4 Het management heeft een korte termijn visie met onduidelijke tussendoelen 3 3

5 De aanpak die gekozen is, sluit niet goed aan bij de bedrijfsdoelen, budget of planning

3 3

6 De doelen zijn niet realistisch waardoor er snel concessies gedaan moeten worden. 3 3

7 Er wordt een overhaaste beslissing genomen om het volledige systeem te vernieuwbouwen.

4 2

8 De organisatie kiest na onvoldoende afweging een verkeerde, incomplete strategie. 3 2

I = Score op impact (ordinale schaal 1 t/m 5) W = Score op waarschijnlijkheid (ordinale schaal 1 t/m 5)

tabel 6.5 - risico waardering projectleider

Van deze risico’s is er geen enkel operationeel geworden bij het SBA project. Ook zijn hier geen bijzondere risico’s die er uitspringen. Opvallend is dat het niet belangrijk maar wel zeer waarschijnlijk wordt geacht dat personeel geen ervaring heeft in vernieuwbouw. Deze score komt wellicht voort uit het feit dat er niet eerder dergelijke projecten zijn uitgevoerd. Tot slot is bij verschillende gelegenheden gemeld dat de klant bijzonder betrokken was en dat dit een uitermate positieve impact had op het project. De klant had een daadwerkelijk probleem en was ook bereid om echt tijd te steken in het oplossen hiervan. Dit bleek bijvoorbeeld direct uit het feit dat er samen met pensioenexperts is gekeken naar de verschillende procedures en rekenregels. Op basis hiervan wordt dit risico ook meegenomen als een zwaarwegend risico. Deze weging is niet vertaald naar een waarde op 5 puntsschaal, maar moet zonder waardering meegenomen worden.

6.2.5 Proces – Kosten In de vooronderzoeksfase van het SBA traject is het project afgebakend op basis van de onderdelen / modules van de applicatie die aangepast moesten worden. Dit is met behulp van de tools gedaan die zijn beschreven in paragraaf 6.2.7. Van de businesslogica in de afgebakende onderdelen is in het modelleringstool MTP een nieuw ontwerp/model gemaakt. Hierdoor is er een overzicht ontstaan van de te vernieuwbouwen componenten. Er is gebruik gemaakt van een expert schatting met ondersteuning door het BIS tool. Hiermee is in de broncode gezocht, waar de betreffende functionaliteit van de te reengineeren componenten zich bevindt (een impactanalyse die aangeeft op hoeveel plaatsen functionaliteit zit die met de betreffende component te maken heeft).

62


Aan deze impactanalyse zijn schattingen gekoppeld. Door per onderdeel te kijken waar er aanpassingen nodig zijn en hoeveel een aanpassing zou kosten, kan een totaal aan uren geschat worden. In feite is dit een expertschatting zoals die normaal altijd bij begrotingen gemaakt wordt. Dit is voor alle deelprojecten gedaan. De som van de deelprojecten is de projectbegroting van de bouwfase. De andere projectactiviteiten (ontwerp, test, projectleiding, etc.) zijn relatief ten opzichte van de bouw bepaald. Het totaal van de kostenschatting komt hiermee voor fase 2 op een inschatting van 6 FTE in totaal voor een 40 urige werkweek, gedurende 30 weken. Dit komt uit op 7200 uur voor fase 2. De gerealiseerde kosten zijn voor het totale project: 1150 uur (1e fase) + 8200 uur (fase 2) + 2800 (fase 3) = 12150 uur. Besparingen door Reengineering Om de bruikbaarheid van de kostenberekening volgens de methodiek van Sneed (1995), te evalueren aan de hand van de SBA case, wordt het gebrek aan meetgegevens al snel hinderlijk. Waarden die hier gemist worden zijn bijvoorbeeld de huidige en toekomstige bedrijfswaarde. Er wordt daarom alleen ingegaan op de besparingen en kosten. Besparingen die zijn opgetreden zoals verkorte opleidingstijden zijn niet geconstateerd of in ieder geval niet meetbaar. Het meest concreet zou er wellicht gekeken kunnen worden naar de uren aan onderhoud. Dit was 1,5 FTE en is dit nu nog steeds. Er is wel de notie dat het oplossen van problemen en het toevoegen van nieuwe functionaliteiten gemakkelijker en sneller verloopt, er zijn alleen geen concrete cijfers voor dit gevoel. Dit zou in moeten houden dat de productiviteit hoger is, hier zijn echter ook geen cijfers voor. Om toch een beeld te krijgen van mogelijke besparingen, is er gekeken naar wat Centric voor beheer aan zou bieden op basis van een quick-scan van de toenmalige situatie en de huidige situatie. Hiermee zou de jaarlijkse besparing bij uitbesteding van beheer meetbaar moeten worden. Deze onderhoudskosten zijn weergegeven in tabel 6.6.

Optie Kosten

Status Quo behouden 2982 uur

Reengineering 2232 uur

Nieuwbouw 5381 uur

tabel 6.6 - indicatie onderhoudskosten SBA

De wijzigingen die zijn doorgevoerd in het model van de quickscan, om te komen tot een verschil tussen reengineering en de status-quo behouden, is een verlaging van het aantal uur per functiepunt en een verhoging van de kwaliteit. De kwaliteit is afgeleid uit de beoordeling van de enquêtes, 15% productiviteitsverhoging op basis van de opmerkingen dat er sneller en gemakkelijker onderhoud gepleegd kan worden. We zien dan dat het onderhoud op basis van het model dat Centric aanhoudt voor het aanbieden van onderhoud 25% lager ligt voor het reengineerde systeem. Opvallend aan deze gegevens is dat na de nieuwbouw de onderhoudskosten eerst hoog zullen zijn, omdat een systeem dat vanaf de grond is opgebouwd ook meer bugs zal hebben. Deze kosten zullen na een tijd omlaag gaan en als het goed is, lager zijn dan de onderhoudskosten van een reengineerd systeem. Na verloop van tijd, zullen de kosten dan weer stijgen van het systeem. Dit staat ook wel bekend als de ‘bathtub curve’. (Department of the Air Force, 2000) Kosten van Reengineering Voor het schatten van de kosten van een reengineeringproject kan als leidraad worden gekeken naar het aantal functiepunten of het aantal regels code. Hierbij kunnen de kosten van derde tools worden opgeteld. Het gebruik is te automatiseren, doordat er gebruik gemaakt kan worden van back-firing, waardoor de functiepunten achterhaald kunnen worden van de bestaande code. Vervolgens kan met deze hoeveelheid functiepunten een COCOMO vergelijking gemaakt worden.

63


Voor het opstellen van de COCOMO vergelijking kunnen de waarden van de inspanningen gemiddeld uit de enquête genomen worden, aangezien het hier percentages betreft. Van de AA factor kan de mediaan genomen worden. De resultaten zijn ingevoegd in tabel 6.7.

Factor Enquête resultaat N

Percentage code aangepast (CM) 33,75 % 5

Percentage ontwerp aangepast (DM) 36,67 % 5

Percentage integratie inspanning (IM) 33,33 % 5

Evaluatie inspanning (AA) 1 5

Enquête resultaten zijn gemiddelden van percentages N = aantal respondenten

tabel 6.7 - enquête resultaten COCOMO factoren

Bij het evalueren van de inspanning voor het reengineering project, was er onduidelijkheid over het percentage gemodificeerde code. Deze onduidelijkheid kwam doordat er niet bekend was op welk niveau dit percentage gemeten moest worden. Wanneer er bijvoorbeeld de naam van een variabele, verandert, telt dan de hele regel als aangepast? Of als er een regel wordt aangepast, telt dan de hele methode / procedure als aangepast? Er is op dat moment besloten om te kijken op procedure niveau, dus bij 1 of meerdere regels verandert, is de procedure veranderd. De factor AAF kan berekend worden en geeft als resultaat 34,5. Op basis hiervan moet gekozen worden voor de eerste variant van de verdere COCOMO berekening:

ESLOC = ASLOC * (AA + SU + AAF)/100 De factor SU wordt bepaald door de transparantie van de code, architectuur en documentatie, daarvoor wordt de mediaan van de gegevens over het bestaande product genomen. Deze gegevens zijn in tabel 6.8 opgenomen.


Architectuur 3 (Gemiddeld) 5

Code 3 (Gemiddeld) 5

Documentatie 1 (Zeer slecht) 5

Database 3 (Gemiddeld) 5

Waardering is mediaan op ordinale schaal 1 t/m 5. N = aantal respondenten

tabel 6.8 - enquête resultaten waardering PAS

Op basis van deze tabel, is waarde ‘30’ (zie Bijlage 6 ) het best van toepassing is voor de factor SU. De enige factor die afwijkt, is namelijk documentatie en dit rechtvaardigt niet het bijstellen van de gehele factor. Een afronding van de factor, komt dan op een percentage uit van 32,75%. Dit is de verhouding ten opzichte van nieuwbouw van de applicatie. Voor nieuwbouwkosten in een project bij J2EE of .NET (de meest gangbare projecten) wordt bij Centric gerekend met een percentage van 7,5 uur/fp. Voor vernieuwbouw zou er met COCOMO dan een factor uitkomen van 2,45 fp/uur. De daadwerkelijke kosten voor het SBA project waren 12150 uur. Het aantal functiepunten voor de applicatie PAS is niet bekend. Wanneer een marge aangehouden wordt voor backfiring van 70 – 100 regels code per functie punt en 550.000 regels code dan komt de verhouding uit tussen de 1,54 uur per functiepunt en 2,20 uur per functiepunt. De parametrische COCOMO benadering, de daadwerkelijke uitvoering (minimaal en maximaal), en de referentie van een nieuwbouwproject staan uitgelicht in figuur 6.6.

64


Kostenverhoudingen Reengineering

7,50

2,461,55

2,21

0,001,002,003,004,005,006,007,008,00

Ure

n pe

r fun

ctie

punt

NieuwbouwSBA COCOMO 2Walvis Project minWalvis Project max

figuur 6.6 - overzicht kosten reengineering ten opzichte van nieuwbouw

In het overzicht is te zien dat de kosten die gemaakt worden voor reengineering hier ongeveer op 1/3 van nieuwbouw uitkomen. Ook is te zien dat deze COCOMO schatting redelijk dicht bij de maximale inspanning van het daadwerkelijke project ligt en nog een marge biedt.

6.2.6 Product van Reengineering De applicatie die gereengineerd moest worden, betrof een pensioenapplicatie. Deze applicatie is nieuw ontwikkeld in 1991. Destijds is deze applicatie ontwikkeld in Progress (code en DBMS) en er zijn delen gegenereerd met Trend 5 software tools. Het onderhoud is in 1997 overgegaan naar Walvis, waarbij later 1 programmeur is betrokken die heeft ontwikkeld aan PAS sinds de nieuwbouw. Onderstaand wordt ingegaan op de kennis van de huidige omgeving en doel omgeving, de bekendheid met het specifieke systeem en de kwaliteit van het systeem. Ervaring met huidige omgeving & Ervaring met het doel platform Omdat de doelomgeving dezelfde was als de bestaande omgeving (Progress taal & Progress DBMS) kan er volstaan worden met de ervaring met de huidige omgeving. In onderstaande tabel is de gemiddelde ervaring van de ontwikkelaars gegeven. Hierbij moet uitgegaan worden dat dit de gegevens zijn van 5 van de ontwikkelaars die meegewerkt hebben aan het project. In totaal waren deze verantwoordelijk voor 4 FTE van de 6 FTE in de reconstructie fase.

Onderdeel Gemiddelde ervaring in jaren N

Architectuur algemeen 8 5

Architectuur Component Based Development 1,25 5

Code Algemeen 12,4 5

Code Progress 9,6 5

DBMS Algemeen 11,8 5

DBMS Progress 9,6 5

N = aantal respondenten

tabel 6.9 - enquête resultaten ervaring medewerkers

Mate van bekendheid met het legacy systeem Deze variabele kan worden gemeten op een 0 tot 1 schaal, zoals gedaan wordt bij de factor UNFM in COCOMO. Om hier naar over te kunnen gaan, is er in de enquête ook een 6 puntsschaal gehanteerd. De resultaten van de enquête waren behoorlijk eenduidig: binnen het project was er niemand bekend met de bestaande applicatie, op een medewerker na. Deze medewerker had ook geholpen bij de ontwikkeling van deze applicatie en is dus sinds het begin betrokken bij dit project. Kwaliteit van het legacy systeem Het begrip van legacy wordt bepaald door de waardering van inzichtelijkheid in database, code en architectuur en documentatie. Onderstaand is de mediaan van de waardering genomen voor de verschillende onderdelen.

65



Architectuur 3 (Gemiddeld) 5

Code 3 (Gemiddeld) 5

Documentatie 1 (Zeer slecht) 5

Database 3 (Gemiddeld) 5


tabel 6.10 - enquête resultaten waardering PAS

Kwaliteit van het doelsysteem Omdat er sprake is van een afgerond traject, kan er ook gekeken worden naar de kwaliteit zoals die wordt gewaardeerd door de ontwikkelaars na afloop van het project. Dit geeft een inzicht in het bereikte resultaat en schept context informatie.


Architectuur 4 (Goed) 5

Code 4 (Goed) 5

Documentatie 4 (Goed) 5

Database 4 (Goed) 5


tabel 6.11 - enquête resultaten waardering RePAS

Er kan geconstateerd worden dat er op alle gebieden een positieve impact te zien is. Zowel de kwaliteit van het systeem als de kennis van het team is hoog. Bovendien is er beschikking over een van de oorspronkelijke ontwikkelaars.

6.2.7 Product – Tools Tijdens het project is er gebruik gemaakt van een aantal software tools. Dit betreft het Broncode Informatie Systeem (BIS), de Modellering Tool Pensioenen (MTP), de Component Test Bank (CTB) en het Functionele Documentatie Systeem (FDS). Deze zullen hieronder beknopt besproken worden, behalve de CTB, deze applicatie is namelijk niet een specifiek reengineering tool en valt daarom buiten de scope van het onderzoek. Het BIS is een tool dat de verschillende procedures, functies, variabelen, tabellen en velden in kaart brengt. Op deze manier kan er snel een inzicht komen waar belangrijke koppelingen zitten en waar scheidingen aan te brengen zijn, maar ook hoe functionaliteit over verschillende delen van de applicatie verspreidt ligt. Het MTP (modellering tool pensioenen) is een tool dat rekenregels modelleert. Met behulp van een pensioenexpert zijn de rekenregels voor de verschillende producten en diensten ingevoerd in deze tool. Er kon vervolgens getest worden of met deze modellering er bij een bepaalde input de goede output gegenereerd werd. Ook kon met behulp van deze tool meteen code gegenereerd worden die de implementatie van deze rekenregel was. Deze code is niet gebruikt voor het genereren van de code, maar wel voor het identificeren van bepaalde code die deze functionaliteit aangaf. Dit betrof feitelijk niet een tools zoals is vastgelegd (het is niet specifiek voor reengineering bruikbaar) en is daarom in de enquête vervangen door het FDS tool. Het FDS is ontwikkeld tijdens de derde fase van het project. Er was geconstateerd dat er nog een veelvoud aan documentatie gemaakt moest worden, wat niet haalbaar zou zijn met de beschikbare bezetting in de beschikbare tijd. Hiervoor is het FDS gebouwd.

66


Het FDS kan voor elk scherm in de applicatie vastleggen welke mogelijkheden er zijn (welke velden zijn beschikbaar, welke gegevens mogen in welk veld, et cetera) en legt dit vast in een database. Deze gegevens kunnen dan samen met een schermafdruk worden bewerkt door de ontwikkelaar. Er kunnen dan opmerkingen worden toegevoegd, en koppelingen naar andere schermen en functionaliteiten. Hierdoor wordt er een workflow model gecreëerd, dat goed is te benaderen als documentatie. In tabel 6.12 zijn de resultaten van deze vragen opgenomen.

Techniek Waardering (mediaan)

N

Begrippen ontrekken 5 (Heel veel) 5

Statische analyse 4 (Veel) 5

Dynamische analyse 3 (Gemiddeld) 5

Slicing 4 (Veel) 5

Semantische en gedragspatronen matching 3 (Gemiddeld) 5

Redocumentation 4 (Veel) 5

Plan Herkenning 4 (Veel) 5

Aggregatie hiërarchieën 3 (Gemiddeld) 5

Refactoring 3 (Gemiddeld) 5

Structurele patronen koppelen 2 (Laag) 5

Concepten toekennen en redenatie 4 (Veel) 5

Architectuur en structuur identificatie 3 (Gemiddeld) 5


tabel 6.12 - waardering begripsvormingtechnieken tools

Ten behoeve van de tools zijn eerst de verschillende specifieke mogelijkheden die ze bieden geëvalueerd. Vervolgens worden de tools BIS en FDS geëvalueerd door te kijken in hoeveel fasen deze voldoende werken.

Technieken Waardering (mediaan)

BIS FDS

Begrippen onttrekken Heel veel X (5)

Aggregatie hiërarchieën Gemiddeld X (5)

Redocumentation Veel X (3)

X = Tool voldoet aan techniek in voldoende mate (nr) = Aantal respondenten

tabel 6.13 - enquête resultaten tooling SBA project

De enige twee resultaten die unaniem zijn benoemd is de voldoende ondersteuning van BIS voor het onttrekken van begrippen en het verzorgen van Redocumentation door FDS. Ook zijn er een drietal medewerkers die de BIS tool vonden volstaan in het maken van aggregatie hiërarchieën. Uit het afnemen van de enquêtes kwam verder naar voren dat de BIS en MTP tool samen zijn gebruikt voor een slicing-techniek. Naast deze factoren is er ook naar voren gekomen tijdens het project, dat er gebrek was aan kennis van het pensioendomein. De pensioenmaterie bleek weerbarstiger dan verwacht en hierdoor is ook het algemene testteam (van een derde partij) vervangen door medewerkers van SBA. Walvis is bijgestaan door pensioenexperts bij het evalueren van de verschillende rekenregels. De medewerkers en projectmedewerkers hebben aangegeven dat deze kennis essentieel was voor het succesvol uitvoeren van het project.

67


6.2.8 Betrouwbaarheid onderzoeksresultaten Kijkend naar de betrouwbaarheid van de onderzoeksresultaten, dan komen de volgende belangrijkste punten naar voren:

Correctie van de antwoorden; door de interactie met de ondervraagden, konden wat vragen afgestemd worden voor de overige ondervraagden.

Verduidelijking vraagstelling; bepaalde vragen waren niet duidelijk en konden worden verduidelijkt, waardoor het antwoord betrouwbaarder is.

Onvolledigheid; sommige antwoorden zijn niet door alle medewerkers gegeven, hierdoor ligt niet dezelfde basis aan een beoordeling van bijvoorbeeld een risico.

Productwaardering; de betrouwbaarheid van deze resultaten zou in twijfel getrokken kunnen worden omdat de programmeurs in feite zichzelf beoordelen. Op basis van de audit (Interne referentie: Stal, 2001) kan hetzelfde oordeel echter worden getrokken. In de audit is er een beoordeling gemaakt van correctieve onderhoudbaarheid, herbruikbaarheid en wijzigbaarheid.

Verder geld voor dit onderzoek dat het slechts een enkel project betreft. Van dit project zijn wel veel medewerkers bevraagd, maar niet alle (6 van 8). Hiernaast zijn de interviews geïnterpreteerd door de auteur waarvan de interbeoordelaar-betrouwbaarheid laag kan zijn. Om een gevalideerde beschrijving te krijgen, zijn de gegevens wel goedgekeurd door de geïnterviewde.

6.3 Conclusies

Om het antwoord op de vraag: “Hoe verhoudt de huidige aanpak voor Legacy Renovation bij Centric zich tot de theorie?” te geven is er gekeken naar het projectmanagement, procesverloop, productimpact en tools. De antwoorden op de subvragen worden hieronder gegeven: Deelvraag a: Wat zijn de belangrijkste verschillen en overeenkomsten tussen de theorie en praktijk ten aanzien van het projectmanagement van Legacy Renovation? Centric hanteert voor alle projecten de CPA standaard. Deze voorziet niet in directe richtlijnen voor projectmanagementstijl, productspecifieke activiteiten en in het algemeen richtlijnen voor reengineering. De aanpak van het SBA project laat wel zien hoe een dergelijk project is aangepakt. Er zijn relatief weinig instrumenten ingezet of zijn niet ervaren als een instrument. De werkstijl is ruim bovengemiddeld beoordeeld, op zowel structurerend als doelgericht. Dit betekent dat de werkstijl aansloot op het project, op basis van de lage vastgestelde grijpbaarheid. Hiernaast is aangedragen dat er zorggedragen moet worden voor een goede taakverdeling en selectie van personeel, vanwege de verschillende karakters van het werk (van creatief tot routine werk). Deelvraag b: Wat zijn de belangrijkste verschillen en overeenkomsten tussen de theorie en praktijk ten aanzien van het proces van Legacy Renovation? De portfolio analyse wijkt af bij een analyse op de technische kwaliteit ten overstaan van het SBA project. Bij een uitvoering van de SRA wordt gescoord op een restructuring en een redocumentation strategie, die ook zijn uitgevoerd tijdens het project. De uitvoering van de activiteiten komt in grote delen overeen met de theorie. Een aantal afwijkingen is terug te brengen op afbakeningen binnen het plan van aanpak. Het prioriteren van deelprojecten en het onderkennen van een fase voor het maken van tools is niet terug te vinden binnen de theorie. DE besparingen die in de theorie genoemd worden zijn niet teruggekomen in de praktijk. Deze zijn althans niet tastbaar te maken. Er is wel de notie dat er sneller en gemakkelijker gewerkt kan worden. Wanneer gekeken wordt naar een quickscan met het beheermodel van Centric, komt het onderhoud op een besparing van ongeveer 25%.

68


De kosten zijn bepaald op basis van een expert schatting. Er is in totaal voor de 2e fase een inspanning van 7200 uur geschat. Uiteindelijke kosten van het gehele traject zijn uitgekomen op 12150 uur. In uren per functiepunt komt de COCOMO berekening op een score van 2,45 en de daadwerkelijke uitvoering maximaal op 2,2. Hieruit kan geconcludeerd wordt dat dit project lage kosten had. Meegenomen dat de tools zijn ontwikkeld en verhaald op het project, geeft aan dat de feitelijke kosten nog lager zijn. Ook doordat er sprake was van een restructuring en redocumentation project, zijn de kosten lager dan bij een complex(er) project. De tools zijn tijdens de kostenberekening ingezet om de expertschatting te ondersteunen. Het aantal activiteiten en daaraan gekoppelde uren kon bepaald worden door de verschillende codeonderdelen te analyseren en op afhankelijkheden te controleren. Er zijn geen risico’s geconstateerd die zich hebben voorgedaan en een bovengemiddeld risico vormen. De risico’s die hoger uitkwamen dan de meerderheid konden simpel verklaard worden op basis van afbakening en projectkarakteristiek. Een belangrijk risico dat benoemd is door verschillende medewerkers is gebrek aan commitment van de klant. Zonder deze ondersteunende en bijdragende houding, was het niet mogelijk geweest om het project tot een succesvol einde te brengen. Deelvraag c: Wat zijn de belangrijkste verschillen en overeenkomsten tussen de theorie en praktijk ten aanzien van het product van Legacy Renovation.? De applicatie die is gereengineerd, werd op gebied van kwaliteit als ‘gemiddeld’ gewaardeerd door de ontwikkelaars, de documentatie werd gewaardeerd als ‘zeer slecht’. Gemiddeld hadden de ontwikkelaars relatief veel ervaring, behalve op het gebied van Component Based Development. Daarnaast was er 1 ontwikkelaar die bijzonder bekend was met de applicatie, voor de anderen was de applicatie onbekend. De impact die deze kwaliteit en kennis moet hebben op het project is dat het project gemakkelijker en tegen minder kosten verloopt. Dit is in lijn met de kosten en de succesvolle afronding van het project. Naast inhoudelijke kennis van architecturen, code en database en de kwaliteit van de systemen, speelde domeinkennis een grote rol bij het project. Het testen moest hiervoor worden uitgesteld worden en de inzet van pensioenexperts is hierdoor benadrukt. De inzet van tools is tijdens het project als bijzonder belangrijk gewaardeerd. Drie van de meest gewaarde technieken voor begripsvorming worden vervuld door de tools BIS en FDS die zijn ingezet. Het BIS en het MTP zijn hiernaast samen nog ingezet voor het uitvoeren van een ‘slicing’ techniek, die ook een hoge waardering heeft. Samenvattend kunnen de volgende bevindingen meegenomen worden naar het volgende hoofdstuk: Factor Bevindingen Projectmanagement Bij SBA is het project succesvol verlopen met een hoge waarde voor

doelgericht en structurerende werkstijl. Alleen de risicoanalyse werd onder-gemiddeld gewaardeerd.

Activiteiten

Reengineering Portfolio Analyse Deze analyse bleek niet doeltreffend te zijn. De technische beoordeling voor het systeem is niet ingesteld op de verschillende vormen van reengineering.

Software Reengineering Assesment

Was de SRA uitgevoerd voor het SBA project, dan was hier een goed advies uitgekomen. Wel kan er getwijfeld worden over de bruikbaarheid van individuele vragen.

Implementatie activiteiten De aanpak van het SBA project verliep in grote lijnen volgens de fasen uit de literatuur. Voornaamste punten zijn dat er bij Walvis is gekozen voor een prioritering van deelprojecten en een fase voor het ontwikkelen van hulpmiddelen. Doordat er geen sprake is van een ‘complex’ project, was er geen behoefte aan complexe oplossingen.

69


Risico’s Bijzonder belangrijk risico waarnaar gekeken moet worden is de commitment van de klant. Deze wordt als onmisbaar geacht. Hiernaast zijn er veel risico’s die meegenomen zouden moeten worden in een risicoanalyse.

Kosten De kosten bij het uitvoeren van het SBA project waren lager dan de calculatie volgens het COCOMO model. Besparingen zijn niet daadwerkelijk geconstateerd, maar zouden fictief op 25% van het onderhoud komen

Product De kwaliteit van de bestaande applicatie is gewaardeerd als gemiddeld door de projectmedewerkers. Het eindproduct als hoog. Er was veel kennis aanwezig binnen het team en er was ook een van de oorspronkelijke ontwikkelaars in het team. Naast productkennis is het ook essentieel dat er voldoende domeinkennis aanwezig is.

70

Hoofdstuk 9: Aanbevelingen

71

7 Reengineering Project Aanpak voor Centric

Op basis van de conclusies van het vorige hoofdstuk kan nu gekeken worden welke projectstructuur het best ingericht zou kunnen worden voor reengineering projecten voor Centric. Door theorie (hoofdstuk 3 en 4) en praktijk (hoofdstuk 6) samen te laten komen, kan hier een antwoord gegeven worden op onderzoeksvraag 4. In de eerste paragraaf zal worden ingegaan op de aanbevelingen ten aanzien van het projectmanagement, gevolgd door het reengineering proces en reengineering product. Er wordt afgesloten met conclusies.

7.1 Projectmanagement voor Reengineering

Volgens de theorie van Shenhar en Dvir (2004) zou er op basis van de technische onzekerheid en het tempo van een gemiddeld reengineering project gekozen moeten worden voor een flexibele projectmanagementstijl, veel communicatie en voornamelijk informele communicatie. Daarnaast zijn er weinig procedures benodigd. De managementstijl die wordt aangereikt op basis van complexiteit is een iets formelere en bureaucratischere. Hiernaast zou de projectleider technisch onderlegd moeten zijn voor een dergelijk project en het team moet bestaan uit ervaren professionals. Voor het instrumentgebruik wordt gekeken naar de huidige inzet van de CPA. Dit is een instrument op zich en wanneer het volledig ingezet wordt, kan er sprake zijn van een hoog instrumentgebruik. Het heeft namelijk meerdere instrumenten in zich (voortgangsrapportages, begroting, planning, etc.) De mate waarin het gebruikt wordt is echter afhankelijk per project, vanwege de flexibele structuur van de CPA. Voor projecten moet rekening gehouden worden met een groter belang voor de werkstijl dan aan het instrumentgebruik (van Aken, 1997). Dat de CPA veel instrumenten kan hanteren hoeft niet in te houden dat er bij projecten ook altijd veel en strikt gebruik gemaakt wordt van deze instrumenten. Ook worden niet alle instrumenten ervaren als instrumenten, wat ook een positieve impact heeft op een dergelijk project. Wanneer er te veel instrumenten ingezet worden, zal dit een negatieve invloed hebben op het project. Om dit te voorkomen zouden alleen de hoognodige instrumenten gebruikt moeten worden en zouden instrumenten moeten worden toegevoegd op basis van hun waardering. Hiervoor kunnen de waarderingen gehanteerd worden die voortkwamen uit de enquêtes; planning en voortgangsrapportages worden meer gewaardeerd dan begrotingen en risicoanalyses. Er kan op basis van deze uitkomsten geen conclusie gedaan worden dat eventueel begrotingen of risicoanalyses buiten het project gehouden moeten worden, dit is namelijk niet haalbaar. Er kan wel geconcludeerd worden dat het niet bewust hanteren of opmerken van instrumenten positief is, omdat dit ook niet zorgt voor hogere score voor instrumenten. Een doelgerichte werkstijl is altijd goed voor het projectsucces en aangezien reengineering projecten niet hoog scoren op grijpbaarheid is ook een structurerende werkstijl een goede inbreng. Een doelgerichte werkstijl wordt bepaald door de mate van directiviteit, strakheid in leidinggeven, en richtinggevend versus lassez-faire. Een structurerende stijl houdt in dat er structuur wordt aangebracht in het werk en de uitvoering. Het gaat hier voornamelijk om de beheersing van het werk. Vanuit de praktijk is aangedragen dat er goed gekeken moet worden naar individuele kwaliteiten en motivaties. Het herstructureren van code is niet altijd opgevat als leuk werk, maar ook meer dan eens als geestdodend.


7.2 Proces van Reengineering

De reengineering portfolio analyse en de SRA zijn methoden om te waarderen welke applicaties aan vervanging toe zijn en welke strategie aan te bevelen valt. Dit kan binnen de CPA gebruikt worden met de fase bid-management, waarin een projectvoorstel gedaan wordt op basis van een probleemstelling. Binnen een dergelijk projectvoorstel zijn zowel de portfolio analyse alswel de Software Reengineering Assesment inzetbaar. In de verdere fases van planning en uitvoering kunnen de methoden van Renaissance, RMM en de specifiekere technieken gebruikt worden, zonder dat hiervoor speciale aanpassingen nodig zijn voor deze methoden. Om hier verder op in te gaan, kijk in de volgende paragrafen respectievelijk naar de reengineering portfolio analyse, de software reengineering assesment, de uitvoering van reengineering, de kosten en de risico’s. Er wordt afgesloten met een conclusie hoe het proces ingericht zou moeten worden.

7.2.1 Reengineering Portfolio Analyse Het model van de reengineering portfolio analyse moet anders gebruikt worden. Het model houdt simpelweg geen rekening met verschillende vormen van reengineering, zoals restructuring, redocumentation, e.d. Ook zou in het model niet perse een veroordeling van COBOL en het mainframe moeten zitten. De lijst van Sneed (1991) kan dan wellicht zinniger zijn om snel de technische kwaliteit van het systeem te beoordelen, deze criteria geven ook restructuring en redocumentation argumenten:

Er komen vaak fouten voor in de applicatie; De code is meer dan 7 jaar oud; Programma structuur en logische flow zijn te complex; Programma’s zijn geschreven voor voorgaande hardware versies; Programma’s draaien in emulators; Module of unit routines zijn excessief groot geworden; Grote hoeveelheden resources zijn nodig om het systeem te laten draaien; Hardgecodeerde parameters moeten veranderd worden in het onderhoud; Het aanhouden van de onderhoudsmensen wordt moeilijk; Documentatie is niet up-to-date; Ontwerp specificaties zijn verloren of niet compleet/verouderd.

Wanneer een drietal of meer van deze situaties van toepassing zijn, in combinatie met een hoge bedrijfswaarde, zou verder gekeken kunnen worden naar de software reengineering assesment voor de betreffende applicatie. Op deze wijze zou ook het SBA project in een verder traject komen. Voor de bepaling van de bedrijfswaarde kan wel een redelijke inschatting gemaakt worden met de reengineering portfolio analyse. Er kan vervolgens worden gekeken naar de Software Reengineering Assesment.

7.2.2 Software Reengineering Assesment Uit het vergelijk van deze tool met de praktijk, kan gesteld worden dat de lijsten een redelijk goed advies geven. Ze sluiten in ieder geval goed aan bij het uitgevoerde SBA project. Bij het invullen van de SRA, geven de resultaten een advies voor restructuring, broncode vertaling en redocumentation. In het SBA project is er sprake geweest van restructuring en redocumentation. Het afwijkende advies van broncode vertaling komt door een hoog positieve beoordeling van de kennis van de doeltaal. Deze was in dit specifieke geval echter dezelfde taal, en niet van toepassing. Een ander bijzonder gegeven is dat de organisatie waar de applicatie operationeel is, niet voldoende had gescoord voor de voorbereiding. Dit is voornamelijk debet aan een groot aantal CMM vragen in deze lijst. Ook een aantal andere lijsten hadden vragen die niet van toepassing leken.

72


73

De SRA heeft in deze setting bewezen een goede richtlijn te zijn. Er moet alleen een manier gevonden worden om te voorkomen dat vragen die geen betekenis voor de gebruiker hebben, een effect hebben op de uitkomst. De mogelijkheid om vragen niet te laten meewegen in het eindoordeel lijkt hiervoor een goede maatregel, aangezien de beoordelingen hierdoor wel goed uitkwamen. Voor de beoordeling van strategie kunnen de lijsten van de SRA op deze manier gebruikt worden. Het uitvoeren van een volledige assesment zoals in het document van Departement of Defense (1997) vastgelegd is niet aan te raden. Er wordt gebruik gemaakt van veel formulieren en neigt naar een zwaar bureaucratisch geheel. Deze kritiek is ook door deskundigen uit de praktijk geuit. Wanneer er zoals voorgesteld alleen gebruik gemaakt wordt van de vragenlijsten is deze methodiek echter goed bruikbaar. Samen met een economische afweging voor een reengineeringkandidaat kan er dan afgewogen welke activiteiten ondernomen moeten worden.

7.2.3 Reengineering Activiteiten De Renaissance aanpak met het RMM onderdeel kwamen grotendeels overeen met de praktijk. De meeste activiteiten waren over te zetten en wanneer deze niet over te zetten waren, was hier een duidelijke verklaring voor. Zo was het trainen van de beheerders niet opgenomen, omdat deze geparticipeerd hadden in de ontwikkeling en was er geen gebruikerstraining, omdat dit in het projectplan was afgebakend en niet nodig was vanwege onveranderde werking. Kijkend naar de manier van werken ten opzichte van de theorie, dan kan er gesteld worden dat het een positief effect heeft op de ontwikkeling om het in deelprojecten te realiseren. Dit gedeelte sluit ook nauw aan bij de renaissance methode en de theorie die een incrementele benadering voorschrijft. Oorzaak voor de niet stapsgewijze implementatie waren organisatorische veranderingen waardoor de opdrachtgever niet vanaf het begin af aan had kunnen testen. Hierdoor was de enige mogelijkheid om deze acceptatietesten en implementatie op het eind te doen. Mede door het flexibele karakter van een methode als de Renaissance methode, kan hierdoor volstaan worden met een tweetal toe te voegen (facultatieve) activiteiten. Dit betreft in de planningsfase het prioriteren van de verschillende deelprojecten en in de uitvoeringsfase het ontwikkelen van eventuele tools voor reengineering of testen. Bij de uitvoeringsfase van een project zijn verschillende migratiestrategieën mogelijk. Zoals gezien in de SBA praktijk kan er incrementeel overgegaan worden in een omgeving die het toelaat (zelfde ontwikkelomgeving, platform en database). Deze methode wordt ook aangeraden in de theorie, omdat deze voor een minimale verstoring van het systeem zorgt. Wanneer er echter gebruik gemaakt moet worden van twee parallelle systemen kan er beter gebruik gemaakt worden van de methodiek ‘iterative reengineering’. Deze methode is de meest verfijnde op het moment van schrijven en hiervan is ook een uitvoerige case-beschrijving van beschikbaar (i.t.t. tot de andere methodieken) Bij een overgang naar een andere architectuur of platform, moet er gezorgd worden dat de organisatie daar klaar voor is en bekend is met de technologie. In andere gevallen is het verstandiger op de huidige architectuur of technologie te hanteren. Ook moet er rekening gehouden worden met een eventuele leertijd in het geval van nieuwe technologieën. Bij voorkeur worden er bij een reengineering traject geen functionaliteiten toegevoegd. Als dit wel nodig is, kan dit het best middels rapid-prototyping en met in achtbare van een hoger risico plaatsvinden.

7.2.4 Risico’s Voor een eerste gebruik van de risico’s zal gekeken worden naar de integratie met de SarBachets analyse. Met betrekking tot de categorieën projectomvang, projectomgeving en projectorganisatie zijn de risico’s die genoemd worden in de SarBachets analyse niet tegenstrijdig met de lijst zoals opgenomen in Bijlage 8 , maar eerder aanvullend.


In de categorie automatiseringervaring beginnen er zich wel conflicten voor te doen; afwijkingen ten opzichte van een regulier ontwikkelingstraject worden als risico gezien en het model is in het algemeen gestaafd op standaard ontwikkelingsprojecten. Eenzelfde gebrek aan afstemming wordt gezien in de in de categorie techniek, waar er van hoog risico wordt gesproken als er nieuwe software gebruikt moet worden (gebruik van reengineering tools), terwijl het gebruik van hulpmiddelen erg belangrijk is bij reengineering projecten. Concreet zullen om deze redenen voor een reengineeringproject in ieder geval de volgende vragen niet moeten meewegen in de analyse:

Zal het project afwijken van de standaardprocedures en richtlijnen voor systeemontwikkeling? In hoeverre is er training noodzakelijk voor eindgebruikers om het nieuwe informatiesysteem te

kunnen gebruiken? Zal algemene hulpprogrammatuur worden gebruikt? (Bijv. Rapportgenerator, statistische

programma's, grafische programma's, hogere programmeertalen, enz.) Verder zijn uiteraard veel reengineering risico’s niet meegenomen, of wordt er te kort naar gekeken. Daarom zouden reengineeringrisico’s nog moeten worden toegevoegd. Al deze risico’s kunnen in een lijst worden samengevat, met hun respectievelijke impact en waarschijnlijkheid als factoren die het daadwerkelijke risico bepalen. De SarBachets methodiek heeft hiervoor de factoren ‘risico factor’ en ‘risico waarde’. De belangrijkste risico’s, die in ieder geval zouden geëvalueerd moeten worden, zijn vanuit de enquêtes:

Er waren test bottlenecks en / of een gebrek aan test data. Er is een gebrek aan kennis van het huidige systeem. Bestaande bedrijfskennis die vastgelegd is in de broncode, raakt verloren. Project vertragingen door mismatch in architectuur (van programmeertalen en dbms)

Onderstaande risico’s kunnen aan deze lijst worden toegevoegd. Deze risico’s zijn binnen het project vermeden, maar wel belangrijk op basis van Sneed (1995) en SIG (2004).

Performance Loss; Falen in het behalen van kwaliteitsdoelen door een slechte definiëring; Verwerpen van de resultaten door de onderhoudsprogrammeurs;

Tot slot is een van de grootste risico’s het gebrek aan commitment van de klant. Klantbetrokkenheid wordt als erg positief ervaren, juist omdat de applicatie nauw verbonden is met het proces en product. In principe betreft dit geen specifiek reengineering risico, maar vanwege de extra nadruk wordt deze wel hier opgenomen.

7.2.5 Kostenberekening Op basis van de kostenanalyse is geconcludeerd dat het SBA project tegen een laag tarief is uitgevoerd. Extra moet vermeldt worden dat de tools tijdens het project zijn gemaakt en dat dit betekent dat de kosten eigenlijk nog lager zijn. Verklarend voor de lage kosten kan hier tegenover staan dat het project een restructuring en redocumenting project betrof en er geen complexe benaderingen nodig waren voor broncode vertaling en platformwisselingen. Ook was de relatieve kwaliteit van de legacy software hoog ten opzichte van de kwaliteit na reengineering. Wanneer gekeken wordt naar de verhoudingen met andere aanbieders en met een aanbieding van Centric die complexer was (zie Bijlage 14 ), zien we dat deze laatste dan naar alle waarschijnlijkheid te laag is ingezet.

74


Kostenverhoudingen Reengineering met 'vendor quotes'

7,50

4,88

2,48 2,461,55

2,21 1,875

0,001,00

2,003,004,00

5,006,00

7,008,00

Ure

n p

er f

un

ctie

pun

t

NieuwbouwLogicaCMG (Prognose)Omnext (Prognose)SBA COCOMO 2Walvis Project minWalvis Project maxAanbieding Centric

figuur 7.1 - kostenverhoudingen reengineering

Besparingen zijn wel geconstateerd in de praktijk, maar zijn niet uit te drukken in aantallen. Een quickscan laat een mogelijke 25% aan onderhoudskosten verlaging zien, maar dit is erg oppervlakkig bepaald. De factoren waarop bespaard kunnen worden zullen getoetst moeten worden in nieuwe projecten. De kostenberekening kan het best op zoveel mogelijk manieren uitgevoerd worden. Er kan gebruik gemaakt worden van een expertschatting, een bottom-up schatting en een benadering middels het behandelde COCOMO model in dit onderzoek. De eerste is op basis van ervaring en zal moeten groeien, de laatste twee staan hieronder aangegeven. Parametrisch / COCOMO Er kan geconstateerd worden dat de kostenberekening van COCOMO redelijk in de buurt komt van de projectuitvoering van Walvis. Ook de Omnext prognose ligt hier dicht tegen aan. Ook valt te zien dat de aanbieding die gedaan is door Centric redelijk laag uitvalt. Er moeten bij deze benadering wel een aantal kanttekeningen gezet worden:

De COCOMO benadering is niet specifiek uitgerust voor verschillende soorten van reengineering projecten. Als voorbeeld: een project met redocumentation valt dus net zo duur uit als een project zonder.

De percentages code zijn in de SBA case opgevat als het percentage procedures. Bottom-up Doordat naast de COCOMO methode een aantal activiteiten gedefinieerd kunnen worden volgens de Renaissance methode en aanvullende migratietechnieken, kan er ook een Bottom-up gemaakt worden door te kijken naar de tijd die benodigd is per activiteit. Concreet voor de uitvoering van een iterative reengineering project, zijn er kosten bekend van een uitgevoerde case. Deze geeft een verhouding in uren aan ten opzichte van de elkaar op volgende fasen. De kosten van het herstellen van de documentatie zijn hierin niet meegenomen, omdat deze per onderdeel zijn uitgevoerd en deze activiteit daardoor niet viel te isoleren. Deze gegevens kunnen een inzicht bieden bij een bottom-up en expertschatting naast de COCOMO benadering. De relatieve kosten zijn in tabel 7.1 opgenomen.

75


Stap Kosten

Analyseren Legacy Systeem 6

Classificeren van de Data 10

Herontwerpen van de Database 17

Aanpassen legacy componenten 10

Migreren van data 3

Equivalentie testen (herstellen) 9

Rework (hertstellen) 9

Herontwerp functies 23

Equivalentietesten (reengineering) 9

Rework (reengineering) 4

Totaal 100%

tabel 7.1 – relatieve kosten per iterative reengineering – activiteit

Deze kostenberekeningen kunnen ingezet worden binnen een evaluatie van de bedrijfswaarde, onderhoudskosten en reengineeringkosten, zoals uitgewerkt door Sneed (1991) en behandeld in paragraaf 3.2.2.


In de praktijk was er sprake van veel ervaring van de bestaande en doelomgeving. Deze ervaring wordt aangeraden in verschillende bronnen van reengineering. Bijzondere bijkomstigheid was een oorspronkelijke ontwikkelaar die aanwezig was, een factor die al in de literatuur benoemd wordt bij de factor evolutie(Bergey, 1997). De twee factoren die bijzonder veel hebben bijgedragen aan het projectsucces en lage kosten waren de mate van begripsvorming die mogelijk was, de hoge kwaliteit van het systeem en de relatief eenvoudige strategie. Er is in het bijzonder vermeldt dat het erg veel gemak biedt dat er een oorspronkelijke ontwikkelaar aanwezig is. Waar mogelijk zouden deze betrokken moeten worden. Hieraan toegevoegd moet ook de mate van domeinkennis worden toegevoegd als relevante factor. Zonder deze kennis, zouden veel hindernissen binnen het project niet genomen kunnen worden.

7.3.1 Tools De CPA staat het gebruik van software-tools voor reengineering niet in de weg, noch biedt het standaard tools / scripts hiervoor. Er is gebruik gemaakt van twee zelfontwikkelde tools, MTP en BIS om een impact analyse te maken. Op basis van deze impactanalyse is gekeken wat de activiteiten zouden zijn en hoeveel tijd er ongeveer per activiteit nodig zou zijn, dus voor planning en begroting. Voor het gebruik tijdens de reengineering, is de BIS tool gebruikt voor het inzichtelijk maken van de bestaande applicatie en MTP voor het inzichtelijk maken van het proces. Samen zijn ze gebruikt om de applicatie opnieuw op te zetten. Hiernaast zijn er per fase conversie tools gemaakt. Ook zijn er tools gemaakt om automatisch te testen per fase. Er is geen aanbeveling met betrekking tot tools vanuit de literatuur. Daarom is er in de enquête gevraagd welke technieken het meest gewaardeerd en welke tools voldoen aan welke technieken. Hieruit kan geëvalueerd worden of de tools inzetbaar moeten zijn. In tabel zijn de waarderingen opgenomen en is er alvast een bepaling gegeven van in welke van deze technieken BIS en FDS voldoen. Hierbij moet rekening gehouden worden dat BIS en FDS vooralsnog alleen inzetbaar zijn voor Visual Basic en Progress.

76


77

Technieken Waardering BIS FDS Begrippen onttrekken Erg veel X Statische Analyse Veel

Redocumentation Veel X Plan herkenning Veel

Slicing Veel Concepten toekennen en redenatie Veel

Aggregatie hiërarchieën Gemiddeld X Dynamische Analyse Gemiddeld

Semantische en gedragspatronen matchen Gemiddeld Refactoring Gemiddeld

Architectuur en structuur identificatie Gemiddeld Structurele patronen koppelen Weinig

X = Tool verzorgd techniek in voldoende mate

tabel 7.2 - overzicht waardering technieken begripsvorming

De kwaliteit van de tools is van een hoog niveau. De tools zijn gemaakt tijdens het uitvoeren van het project en specifiek voor dit project. De tools zijn wel relatief generiek gemaakt en kunnen nu ook voor andere applicaties ingezet worden. Voor Progress en Visual Basic projecten zijn deze tools goed inzetbaar. Voor projecten waar nieuwe tools gekozen moeten worden, kan er gebruik gemaakt worden van bovengenoemde waardering als basis voor een eerste evaluatie. Voor de technieken ‘plan herkenning’, ‘concepten toekennen en redenatie’ en statische analyse kan nog gekeken worden naar tools om te zorgen voor een nog betere begripsvorming.

7.4 Conclusies

Voor het antwoord op de vraag: Wat is de aan te bevelen Legacy Renovation aanpak voor Centric? zullen hieronder de deelvragen van deze onderzoeksvragen beantwoord worden. Deelvraag a: Wat zijn in het licht van de vergelijking de aanbevelingen ten aanzien van het projectmanagement van Legacy Renovation. Het projectmanagement moet uitgevoerd worden met een hoge mate van doelgerichtheid en gestructureerdheid voor reengineeringprojecten. Er moet voorzichtig omgegaan worden met het gebruik van instrumenten en wanneer de inzet te groot wordt van instrumenten, zal gekeken moeten worden welke instrumenten het minst als zinnig ervaren worden. Wanneer er weinig instrumenten ervaren worden, is dit ook positief. Hiernaast moet er veel en informeel gecommuniceerd worden en worden dit soort projecten idealiter uitgevoerd door een technische onderlegde projectleider en ervaren projectleden. Met betrekking tot het personeel moet er goed gekeken worden naar de verschillende capaciteiten van medewerkers en hun karakter en of dit aansluit op het werk. Het werk bij reengineering loopt nogal uiteen van creatief naar routine, waardoor medewerkers niet willekeurige op een taak gezet moeten worden. Deelvraag b: Wat zijn in het licht van de vergelijking de aanbevelingen ten aanzien van het proces van Legacy Renovation? Activiteiten Doordat het SBA project een restructuring en redocumenting project betrof, is het relatief eenvoudig gebleven. Dit heeft ook een positieve impact op de kosten en op het projectsucces gehad


De reengineering portfolio analyse komt niet uit op een goed resultaat, wanneer deze wordt ingevuld voor het SBA project. Dit is debet aan de technische kwaliteitsbeoordeling die uitgaat van bijzonder oude legacy voor reengineering en geen rekening houdt met verschillende strategieën voor reengineering. Hiervoor zijn nieuwe criteria opgesteld. De software reengineering assesment komt uit op een goed resultaat, en de afwijkingen kunnen tegengegaan worden door de mogelijkheid op te nemen om vragen open te laten. De fasen van de Renaissance aanpak en het RMM gedeelte komen redelijk over met de aanpak van het SBA project. De volgende toevoegingen kunnen vanuit de praktijk nog worden bijgevoegd: - De MoSCoW methode kan blijken een toegevoegde waarde te hebben voor het prioriteren. Een

voordeel van incrementeel ontwikkelen is namelijk dat onderdelen voorrang kunnen krijgen. Hiervoor is echter een prioritering nodig en deze kan gevonden worden in een methode als MoSCoW. (DSDM, 2005)

- Het inplannen van een activiteit voor het maken van specifieke tools per stap is een zinnige toevoeging zijn aan de stappen. Wanneer er ervaring is met bestaande tools, kunnen deze wellicht ingezet worden. Er kan dan volstaan worden met de kosten inschalen van de tooling. Wanneer ze specifiek gemaakt moeten worden, moet hier tijd voor ingeschaald worden.

De applicatie is incrementeel opgebouwd, maar is deze wel in een keer overgegaan. Er is hierdoor maar gedeeltelijk sprake van een incrementele aanpak en de risico verlaging die deze beoogt. Volgens een ideale aanpak zou ook de implementatie incrementeel moeten verlopen. Voor projecten waarbij een incrementele benadering niet mogelijk is zoals bij het SBA project, is de techniek van ‘iterative reengineering’ de meest vooraanstaande en de aanbevolen activiteiten opdeling. Er moet wanneer mogelijk en realistisch niet geprobeerd worden om over te stappen op een nieuwe programmeertaal. Dit kan namelijk veel problemen geven en talen zijn niet zo snel afgeschreven als ze lijken. Zo is er nog volop ontwikkeling in het COBOL segment en het PL/I segment. Doordat deze talen ondersteuning blijven krijgen, ligt de drempel hiervoor hoger om over te gaan op een andere taal. Risico’s Er hebben zich weinig risico’s voorgedaan tijdens het SBA project, wat niet vreemd is aangezien het een project betrof dat succesvol was. De belangrijkste risico’s die meegenomen moeten worden bij toekomstige projecten zijn:

Er waren test bottlenecks en / of een gebrek aan test data. Er is een gebrek aan kennis van het huidige systeem. Bestaande bedrijfskennis die vastgelegd is in de broncode, raakt verloren. Project vertragingen door mismatch in architectuur (van programmeertalen en dbms) Performance Loss; Falen in het behalen van kwaliteitsdoelen door een slechte definiëring; Verwerpen van de resultaten door de onderhoudsprogrammeurs;

Kosten Voor de kosten kan gebruik gemaakt worden van de COCOMO methodiek om een inzicht te geven in de mogelijke kosten. Kosten: Kosten kunnen door inrichten van Renaissance methode ook berekend worden op basis van

activiteiten (bottom-up) Hierbij kan voor het uitvoeren van iterative reengineering ook gekeken worden naar de kostenverdelingen die daarbij zitten.

Er zijn in de case geen daadwerkelijke kostenverlagingen geconstateerd in het onderhoud. Op basis van een quickscan zou het echter ongeveer 25% van de onderhoudskosten kunnen schelen.

De COCOMO inschatting van de kosten is redelijk accuraat in de zin dat deze een ruimere marge geeft dan de maximale Walvis inschatting. Deelvraag c: Wat zijn in het licht van de vergelijking de aanbevelingen ten aanzien van het product van Legacy Renovation?

78


79

Het voornaamste punt is dat de reengineering inspanning bij het SBA project relatief simpel is gebleven. Er is geen vertaling gemaakt naar een ander platform, programmeertaal of database. Hiernaast was er veel kennis intern aanwezig en was er beschikking over 1 van de oorspronkelijke ontwikkelaars. Ook was de applicatie in een gemiddelde staat. Al deze factoren hebben alle bijgedragen aan een succesvol(ler) en gemakkelijk(er) traject dan waar de literatuur meestal vanuit gaat. Tools moeten worden ingezet op basis van het belang dat aan de onderliggende techniek gehangen wordt. Met betrekking tot het begrip krijgen zijn BIS en FDS positief beoordeeld en is er een lijst met techniekwaarderingen, die gebruikt kan worden als basis voor het selecteren van tools voor een project. Deze tools waren bijzonder succesvol tijdens het project, mede omdat deze specifiek voor het project zijn ontwikkeld. Deze conclusies leiden tot de volgende aan te bevelen projectaanpak: Bij het voorstel voor een aan te bevelen reengineering aanpak, moet rekening gehouden worden een aantal zaken. Ten eerste is het vergelijk gebaseerd op slechts 1 case. Hiernaast is de case een specifieke vorm van reengineering en daardoor niet altijd representatief. Tot slot zijn er slechts 6 van de 8 mensen van het project benaderd voor de informatie. Dit alles in ogenschouw nemend, raad ik de volgende aanpak aan:

1. Gebruik van de aangepaste reengineering portfolio analyse. 2. Technische applicatie beoordeling op basis van aangepaste Software Reengineering Assesment 3. Economische afweging voor project uitvoeren met behulp van voorgestelde economische model

en COCOMO 2, naast expert en bottom-up inschattingen. 4. Voor de uitvoering kan gekeken worden naar iterative reengineering, maar ook naar een

incrementele oplossing, wanneer de complexiteit en risicofactoren dit toelaten. 5. Bij voorbereiding en tijdens uitvoering van het plan kan de SarBachets analyse gebruikt worden

met als toevoeging de lijst risico’s voor reengineering en de waarderingen hiervoor. 6. Voor het inschalen van tools, ligt er een basis voor toolselectie. Tools kunnen geselecteerd

worden op basis van belang en de mate waarin ze hierin voldoen. Voor Progress en/of Visual Basic omgevingen voldoen BIS en MTP aan een groot gedeelte van de kennisvergaring.

7. Gedurende het project een structurerende en doelgerichte werkstijl hanteren en zo weinig mogelijk instrumentarium inzetten.

De aanpak zoals vastgelegd in dit hoofdstuk is samengevat in een document ‘Reengineering Aanpak’ dat gebruikt kan worden om deze indeling binnen de CPA uit te voeren.


8 Conclusies

In dit hoofdstuk worden de conclusies behandeld. Deze zijn terug te voeren op het inzicht dat Centric graag wil verwerven in de terminologie en de mogelijke aanpak van een reengineering project. De probleemstelling was: “Op welke manier kan Centric succesvol een Legacy Renovation project plannen en uitvoeren?” Vanuit deze probleemstelling zijn de onderzoeksvragen geformuleerd die samen een antwoord geven op de probleemstelling. Deze vragen worden achtereenvolgens beknopt behandeld: Onderzoeksvraag 1: Welke projectfactoren vanuit de theorie zijn relevant voor het succesvol uitvoeren van een Legacy Renovation project? In eerste instantie wordt hiervoor gekeken naar de betekenis van Legacy Renovation: Een van de fasen in de levenscyclus van software is de onderhoudsfase. Deze fase is niet onbelangrijk, want het grootste gedeelte van de IT budgetten gaat naar onderhoud. Hiernaast heeft het grootste gedeelte van het onderhoudswerk betrekking op nieuwe eisen en wensen. De software wordt complexer en verandert continue (Lehman, 1996). Wanneer er geen sprake is van evolutie en het ontwikkelen voor evolutie, degradeert de applicatie langzamerhand. Deze wordt minder handelbaar, inflexibel en duur te onderhouden. We hebben dan Legacy software. Een methode om dit aan te pakken is Legacy Renovation. Reengineering is een betere term voor Legacy Renovation. Reengineering is de overkoepelende term van het abstraheren van gegevens, deze op een hoger niveau te herstructureren en deze opnieuw te implementeren. Veel termen zijn geïntroduceerd door auteurs en voornamelijk bedrijven, zonder te kijken naar de bestaande terminologie. Dit heeft geresulteerd in veel termen die hetzelfde betekenen of specifieke termen die onder een algemenere term binnen reengineering geschaard kunnen worden. De verschillende reengineering strategieën die door anderen worden onderscheiden kunnen binnen deze term gehanteerd worden. In Bijlage 1 is een overzicht van de termen opgenomen. Reengineering kan gezien worden als een vorm van evolutie, kan gepositioneerd worden tussen onderhoud en nieuwe ontwikkeling in en heeft facetten van beide activiteiten. Projectmanagement van Reengineering Volgens de theorie van Shenhar en Dvir (2003), komt een reengineering project in het algemeen uit op een normaal tot snel project, met een hogere onzekerheid, en een laaggemiddelde complexiteit. Dit houdt in totaal in dat projecten relatief informeel gemanaged moeten worden met veel communicatie. Het gebruik van procedures is in mindere mate nodig. Een reengineering-projectleider moet wel technisch onderlegd zijn en het team moet bestaan uit ervaren professionals. Binnen de theorie van van Aken (2002) kan er vastgesteld worden dat reengineering relatief lage grijpbaarheid heeft. Dit houdt in dat er gekeken moet worden naar een structurerende werkstijl. In het algemeen moet onzekerheid niet volgebouwd worden met instrumenten. Proces van Reengineering Er zijn voor het proces een aantal activiteiten vastgesteld die uitgevoerd zouden moeten worden binnen een reengineering project. Hiernaast is er gekeken naar kostenmodellen en risico’s voor een reengineering project. De volgende stappen worden dan binnen een reengineering project uitgevoerd:

1. Portfolio Analyse Een porftolio analyse concludeert op basis van technisch risico en organisatorisch belang of een applicatie een kandidaat is voor reengineering.

2. Software Reengineering Assesment (SRA) De SRA geeft een diepgaandere technische kwalificatie van de reengineeringkandidaat. Hierbij wordt gekeken voor welke specifieke reengineering strategieën de kandidaat in aanmerking komt.

80


81

3. Renaissance aanpak De Renaissance aanpak is een cyclisch model dat flexibiliteit geeft in het toevoegen en weglaten van verschillende stappen. Het model geeft de verschillende stappen van een reengineering project weer. Binnen deze aanpak is Risk Managed Modernization (RMM) geadopteerd voor het maken van een planning volgens deze aanpak. RMM is hier namelijk vollediger en uitgebreider in.

4. Implementatie volgens Iterative Reengineering. De iterative reengineering methode wordt aangehouden voor het uitvoeren van complexe reengineering projecten, waarbij oude en nieuwe systemen parallel moeten draaien. Deze methode geeft richting aan verschillende activiteiten en technieken.

Voor de kostenschattingen is een model van Sneed (1995) overgenomen, waarin de bedrijfswaarde en besparingen moeten opwegen tegen de eenmalige kosten en de jaarlijkse kosten. Deze vergelijking moet worden gemaakt voor de mogelijkheid van niets doen, een nieuwe applicatie ontwikkelen of een reengineering project starten. Voor het schatten van kosten van een reengineering project, kan een calculatie-model gehanteerd worden, waarbij COCOMO 2 de meest gebruikte is met een publiekelijk beschikbaar rekenmodel en verhoudingen voor reengineering. Tot slot is er een veelvoud aan specifieke risico’s voor reengineering traject gevonden binnen de literatuur. Deze zijn beschreven door verschillende auteurs, en samengevoegd in Bijlage 8 Product van Reengineering De belangrijkste impact van zowel de legacy als van de doeltechnologieën, is de eis voor de kennis hiervan. De kwaliteit van een bestaande legacy applicatie bepaalt in welke mate en met welke snelheid het begrip verkregen kan worden. Voor kennis van het legacy systeem geeft het een positief effect, als er oorspronkelijke ontwikkelaars of medewerkers die al lange tijd het systeem beheren, beschikbaar zijn. Voor de kennis van doeltechnologieën zou gekeken kunnen worden naar de beschikbare kennis in een organisatie, of naar trainingen en studiemateriaal. Concepten die voorlopig bijzonder relevant zijn voor reengineering zijn voor Legacy de concepten mainframe en COBOL en voor nieuwe architecturen J2EE, .NET en component based development. Er is nu een vastgestelde definitie van legacy renovation / reengineering en een inzicht in de factoren projectmanagement, proces en product. Onderzoeksvraag 2 gaat verder in op de invloeden van een reengineering project. Onderzoeksvraag 2: Welke projectaanpak kan gehanteerd worden voor Legacy Renovation? De aanpak zoals vastgelegd in het antwoord op onderzoeksvraag 1 kan ondersteund worden met tools in de verschillende fasen. Primaire taken die ondersteund worden zijn: reverse-engineering, redocumentation, restructuring en forward engineering. Tools maken het ook mogelijk om portfolio analyse, reengineering assesment, risico inschatting en kosten inschatting gemakkelijker en/of uitgebreider uit te voeren. Tools vinden dus hun weerslag in het volledige proces. Voor de portfolio analyse en de software reengineering assesment kan gebruik gemaakt worden van technische analyses op de broncode. Dit kan input zijn voor de technische kwaliteit van het systeem en kan de knelpunten aantonen. Dergelijke resultaten kunnen ook een inzicht geven in mogelijke risico’s die tijdens het project kunnen voordoen. Begrip krijgen van de legacy kan ook ondersteund worden met tools. Hiervoor zijn technieken onderkend door Seacord et al (2003). Voor het bepalen van de kosten, kan middels tooling het aantal functiepunten of een andere maat van grootte achterhaald worden. Tot slot zijn er voor het proces van reengineering een aantal invloeden te onderkennen. Deze zijn opgenomen in Bijlage 7


Onderzoeksvraag 3: Hoe verhoudt de huidige aanpak voor Legacy Renovation bij Centric zich tot de theorie? Met de vastgestelde projectaanpak en invloeden hierop wordt gekeken naar Centric aanpak. Op basis van de doelen, vragen en metrieken zijn er enquêtes en een interview opgesteld. Samen met documentatie geven deze een inzicht in de factoren projectmanagement, proces en product: Projectmanagement Centric hanteert voor alle projecten de CPA standaard. Deze voorziet niet in directe richtlijnen voor projectmanagementstijl, productspecifieke activiteiten en in het algemeen richtlijnen voor reengineering. De aanpak van het SBA project laat wel zien hoe een dergelijk project is aangepakt. Er zijn relatief weinig instrumenten ingezet of zijn niet ervaren als een instrument. De werkstijl is ruim bovengemiddeld beoordeeld, op zowel structurerend als doelgericht. Dit betekent dat de werkstijl aansloot op het project, op basis van de lage vastgestelde grijpbaarheid. Hiernaast is aangedragen dat er zorggedragen moet worden voor een goede taakverdeling en selectie van personeel, vanwege de verschillende karakters van het werk (van creatief tot routine werk). Proces Bij het uitvoeren van de portfolio analyse voor het project bij SBA, komt de betreffende applicatie niet naar voren als reengineeringkandidaat. Deze afwijking is terug te leiden naar de beoordeling van de technische kwaliteit. Bij een uitvoering van de SRA wordt gescoord op een restructuring en een redocumentation strategie, die ook zijn uitgevoerd tijdens het project. De uitvoering van de activiteiten komt in grote delen overeen met de theorie. Een aantal afwijkingen is terug te brengen op afbakeningen binnen het plan van aanpak. Het prioriteren van deelprojecten en het onderkennen van een fase voor het maken van tools is niet terug te vinden binnen de theorie. De besparingen die in de theorie genoemd worden zijn niet direct gezien in de praktijk. Er is wel de notie dat er sneller en gemakkelijker gewerkt kan worden. Wanneer gekeken wordt naar een quickscan met het beheermodel van Centric, komt het onderhoud op een besparing van ongeveer 25%. De kosten zijn bepaald op basis van een expert schatting. Er is in totaal voor de 2e fase een inspanning van 7200 uur geschat. Uiteindelijke kosten van fase 2 zijn uitgekomen op 8200 uur en de totale kosten op 12150 uur. In uren per functiepunt komt de COCOMO berekening op een score van 2,45 en de daadwerkelijke uitvoering maximaal op 2,2. Hieruit kan geconcludeerd wordt dat dit project lage kosten had. Meegenomen dat de tools zijn ontwikkeld en verhaald op het project, geeft aan dat de feitelijke kosten nog lager zijn. Ook doordat er sprake was van een restructuring en redocumentation project, zijn de kosten lager dan bij een complex(er) project. De tools zijn tijdens de kostenberekening ingezet om de expertschatting te ondersteunen. Het aantal activiteiten en daaraan gekoppelde uren kon bepaald worden door de verschillende codeonderdelen te analyseren en op afhankelijkheden te controleren. Er zijn geen risico’s geconstateerd die zich hebben voorgedaan en een bovengemiddeld risico vormen. De risico’s die hoger uitkwamen dan de meerderheid konden simpel verklaard worden op basis van afbakening en projectkarakteristiek. Een belangrijk risico dat benoemd is door verschillende medewerkers is gebrek aan commitment van de klant. Zonder deze ondersteunende en bijdragende houding, was het niet mogelijk geweest om het project tot een succesvol einde te brengen. Product De applicatie die is gereengineerd, werd op gebied van kwaliteit als ‘gemiddeld’ gewaardeerd door de ontwikkelaars, de documentatie werd gewaardeerd als ‘zeer slecht’. Gemiddeld hadden de ontwikkelaars relatief veel ervaring, behalve op het gebied van Component Based Development. Daarnaast was er 1 ontwikkelaar die bijzonder bekend was met de applicatie, voor de anderen was de applicatie onbekend. De impact die deze kwaliteit en kennis moet hebben op het project is dat het project gemakkelijker en tegen minder kosten verloopt. Dit is in lijn met de kosten en de succesvolle afronding van het project.

82


83

Naast inhoudelijke kennis van architecturen, code en database en de kwaliteit van de systemen, speelde domeinkennis een grote rol bij het project. Het testen moest hiervoor worden uitgesteld worden en de inzet van pensioenexperts is hierdoor benadrukt. De inzet van tools is tijdens het project als bijzonder belangrijk gewaardeerd. Drie van de meest gewaardeerde technieken voor begripsvorming worden vervuld door de tools BIS en FDS die zijn ingezet. Het modelleertool MTP in combinatie met BIS is hiernaast nog ingezet voor het uitvoeren van een ‘slicing’ techniek, die ook een hoge waardering heeft. Op basis van deze conclusies en die van onderzoeksvraag 2, kan een antwoord gegeven worden op de laatste onderzoeksvraag. Onderzoeksvraag 4: Wat is de aan te bevelen Legacy Renovation aanpak voor Centric? Projectmanagement Het projectmanagement moet uitgevoerd worden met een hoge mate van doelgerichtheid en gestructureerdheid voor reengineeringprojecten. Een structurerende werkstijl kenmerkt zich door ordelijkheid, zorgvuldig werken en het vastberaden te werk gaan. Bij een doelgerichte werkstijl kan er meer overgelaten worden aan de medewerkers, waarbij onderwerpen als coaching en motivatie een rol spelen. Er moet voorzichtig omgegaan worden met het gebruik van instrumenten en wanneer de inzet te groot wordt van instrumenten, zal gekeken moeten worden welke instrumenten het minst als zinnig ervaren worden. Wanneer er weinig instrumenten ervaren worden, is dit ook positief. Hiernaast moet er veel en informeel gecommuniceerd worden en worden dit soort projecten idealiter uitgevoerd door een technische onderlegde projectleider en ervaren projectleden. Met betrekking tot het personeel moet er goed gekeken worden naar de verschillende capaciteiten van medewerkers en hun karakter en of dit aansluit op het werk. Het werk bij reengineering loopt nogal uiteen van creatief naar routine, waardoor medewerkers niet willekeurig op een taak gezet moeten worden. Proces De reengineering portfolio analyse komt niet uit op een goed resultaat, wanneer deze wordt ingevuld voor het SBA project. Dit is debet aan de technische kwaliteitsbeoordeling die uitgaat van bijzonder oude legacy voor reengineering en geen rekening houdt met verschillende strategieën voor reengineering. Hiervoor zijn nieuwe criteria opgesteld. De software reengineering assesment komt uit op een goed resultaat, en de afwijkingen kunnen tegengegaan worden door de mogelijkheid op te nemen om vragen open te laten. De fasen van de Renaissance aanpak en het RMM gedeelte komen redelijk over met de aanpak van het SBA project. De volgende toevoegingen kunnen vanuit de praktijk nog worden bijgevoegd: - De MoSCoW methode heeft bewezen toegevoegde waarde te hebben voor het prioriteren. Een

voordeel van incrementeel ontwikkelen is namelijk dat onderdelen voorrang kunnen krijgen. Hiervoor is echter een prioritering nodig en deze kan gevonden worden in een methode als MoSCoW. (DSDM, 2005)

- Het inplannen van een activiteit voor het maken van specifieke tools per stap is een zinnige toevoeging aan de stappen. Wanneer er ervaring is met bestaande tools, kunnen deze wellicht ingezet worden. Er kan dan volstaan worden met de kosten van de tooling. Wanneer ze specifiek gemaakt moeten worden, moet hier tijd voor ingeschaald worden.

De applicatie is incrementeel opgebouwd, maar is deze wel in een keer overgegaan. Er is hierdoor maar gedeeltelijk sprake van een incrementele aanpak en de risico verlaging die deze beoogt. Volgens een ideale aanpak zou ook de implementatie incrementeel moeten verlopen. Voor projecten waarbij een incrementele benadering niet mogelijk is zoals bij het SBA project, is de techniek van ‘iterative reengineering’ de meest vooraanstaande en de aanbevolen activiteiten opdeling.


Wanneer mogelijk moet geprobeerd worden om niet over te stappen op een nieuwe programmeertaal. Dit kan namelijk veel problemen geven en talen zijn niet zo snel afgeschreven als ze lijken. Zo is er nog volop ontwikkeling in het COBOL segment en het PL/I segment. Doordat deze talen ondersteuning blijven krijgen, ligt de drempel hiervoor hoger om over te gaan op een andere taal. Er hebben zich weinig risico’s voorgedaan tijdens het SBA project. De belangrijkste risico’s die meegenomen moeten worden bij toekomstige projecten zijn:

Test bottlenecks en / of een gebrek aan test data; Een gebrek aan kennis van het huidige systeem; Bestaande bedrijfskennis die vastgelegd is in de broncode, raakt verloren; Project vertragingen door mismatch in architectuur (van programmeertalen en dbms); Performance Loss; Falen in het behalen van kwaliteitsdoelen door een slechte definiëring; Verwerpen van de resultaten door de onderhoudsprogrammeurs;

Voor de kosten kan gebruik gemaakt worden van de COCOMO methodiek om een inzicht te geven in de mogelijke kosten. De COCOMO inschatting van de kosten is redelijk accuraat in de zin dat deze een ruimere marge geeft dan de kosten die gemaakt zijn in de case. Kosten kunnen door inrichten van Renaissance methode ook berekend worden op basis van activiteiten (bottom-up) Hierbij kan voor het uitvoeren van iterative reengineering ook gekeken worden naar de kostenverdelingen die zijn vermeld. Er zijn in de case geen daadwerkelijke kostenverlagingen geconstateerd in het onderhoud. Op basis van een quickscan zou het echter ongeveer 25% van de onderhoudskosten kunnen schelen. Product De reengineering inspanning bij het SBA project komt overeen met kenmerken van een succesvol project uit de theorie. Er is geen vertaling gemaakt naar een ander platform, programmeertaal of database. Hiernaast was er veel kennis intern aanwezig en was er beschikking over 1 van de oorspronkelijke ontwikkelaars. Ook was de applicatie in een gemiddelde staat van kwaliteit. Al deze factoren hebben alle bijgedragen aan een succesvol traject. De literatuur biedt hiernaast nog veel richtlijnen voor projecten waarbij deze kenmerken niet of minder aanwezig zijn. Tools moeten worden ingezet op basis van het belang dat aan de onderliggende techniek gehangen wordt. Met betrekking tot het begrip krijgen zijn BIS en FDS positief beoordeeld en is er een lijst met techniekwaarderingen, die gebruikt kan worden als basis voor het selecteren van tools voor een project. Deze tools waren samen met MTP bijzonder succesvol tijdens het project, mede doordat deze specifiek voor het project zijn ontwikkeld. Deze conclusies leiden tot de volgende aan te bevelen projectaanpak: Bij deze aanpak, moet rekening gehouden worden een aantal zaken. Ten eerste is het vergelijk gebaseerd op slechts 1 case. Hiernaast is de case een specifieke vorm van reengineering en daardoor niet altijd representatief. Tot slot zijn er slechts 6 van de 8 mensen van het project benaderd voor de informatie. Dit alles in ogenschouw nemend, raad ik de volgende aanpak aan:

1. Gebruik van de aangepaste reengineering portfolio analyse. 2. Technische applicatie beoordeling op basis van aangepaste Software Reengineering Assesment 3. Economische afweging voor project uitvoeren met behulp van voorgestelde economische model

en COCOMO 2, naast expert en bottom-up inschattingen. 4. Voor de uitvoering kan gekeken worden naar de stappen van Renaissance, RMM en iterative

reengineering, maar ook naar een incrementele oplossing, wanneer de complexiteit en risicofactoren dit toelaten.

5. Bij voorbereiding en tijdens uitvoering van het plan kan de SarBachets analyse gebruikt worden met als toevoeging de lijst risico’s voor reengineering en de waarderingen hiervoor.

84


85

6. Voor het inschalen van tools, ligt er een basis voor toolselectie. Tools kunnen geselecteerd worden op basis van belang en de mate waarin ze hierin voldoen. Voor Progress en/of Visual Basic omgevingen voldoen BIS en MTP aan een groot gedeelte van de kennisvergaring.

7. Gedurende het project een structurerende en doelgerichte werkstijl hanteren en zo weinig mogelijk instrumentarium inzetten.


9 Aanbevelingen

In dit gedeelte zijn de aanbevelingen opgenomen, die aansluiten op de eerder behandelde conclusies. De verschillende aanbevelingen zijn genummerd weergegeven en zouden in chronologische volgorde uitgevoerd moeten worden. 1. Opnemen en verwerken projectaanpak/onderdelen in CPA Integratie van de voorgestelde aanpak kan binnen de CPA. De plaats waar nu het document ‘Applicatie ontwikkeling’ richting geeft aan de aanpak van nieuwbouw projecten, zo zou hier ook een document gebruikt kunnen worden om richting te geven aan reengineering trajecten. Dit document kan een beknopte versie van dit verslag zijn. Op de langere termijn is het de bedoeling dat Centric overgaat naar een model waarin gekozen kan worden voor een traject en dat de relevante technieken en middelen per fase hieraan worden toegewezen. De onderdelen uit de reengineering aanpak kunnen dan ook geïntegreerd worden. Ten behoeve hiervan is een suggestie voor integratie binnen de CPA opgenomen in figuur 9.1.

figuur 9.1 - reengineering aanpak binnen CPA

Onderin het figuur zijn de bestaande CPA technieken opgenomen. De stappen en technieken die uitgevoerd moeten worden voor reengineering zijn binnen de fasen bid-management, voorbereiding en uitvoering toegevoegd. In het voortraject heeft het zin om een portfolio analyse en software reengineering assesment uit te voeren. Voor fase bid-management kan een risico analyse en begroting middels COCOMO gemaakt worden. Deze kan dan eventueel verfijnd worden in de fase project voorbereiding. Hierin kan RMM een richting geven aan het opzetten van het plan en Renaissance en iterative reengineering voor de activiteiten en daadwerkelijke uitvoering. 2. Vaststellen van metrieken voor de activiteiten binnen deze aanpak De kennis die opgedaan wordt bij projecten zou bruikbaar moeten worden voor projecten in de toekomst. Hiervoor zijn metrieken inzetbaar en zou er een aantal metrieken vastgesteld moeten worden. Koskinen (2004) stelt dat er een veelvoud aan metrieken gebruikt worden, maar dat er een grote hoeveelheid aan invloedsfactoren is, die vaak helemaal niet relateren aan deze metrieken. Om hier toch een eerste houvast te krijgen, kunnen een aantal basis metrieken gebruikt worden. De volgende metrieken worden bij deze voorgesteld:

- SLOC ( het aantal regels broncode) - Het aantal functiepunten - Data Complexity - Cyclomatic Complexity

86


87

De benodigde inspanning per activiteit van de uiteindelijke uitvoering en de verschillende strategieën (vanuit de SRA) die uitgevoerd worden kunnen op deze manier gekoppeld worden aan de verschillende meetwaarden en hun onderlinge verhouding. Hierdoor onstaat een inzicht in de doorlooptijd en kosten. Ten behoeve van de besparingen zouden een aantal relatief makkelijk te achterhalen gegevens kunnen worden verzameld:

Besparingen van tijd en inspanning per onderhoudstaak; Besparingen door het vervangen van senior personeel door junior personeel; Besparingen door een beperking van de tijd die fouten in beslag nemen (downtime); Besparingen op het inhuren en trainen van nieuw personeel; Besparingen op kosten van verloren kansen, doordat capaciteit vrijgemaakt wordt van

onderhoud; Om deze besparingen te gebruiken als argument, moeten deze vergeleken worden met de huidige situatie. Dit zal niet in alle situaties mogelijk zijn (bij nieuwe klanten bijvoorbeeld). Voor applicaties die momenteel in beheer zijn is dit echter wel een mogelijkheid. Deze gegevens zouden dan ook kunnen dienen als referentie op basis van bijvoorbeeld applicatiedomein, platform of grootte van de organisatie. Metrieken kunnen dus uiterst behulpzaam zijn. Er zou hier verder onderzoek naar gedaan kunnen worden (welke metrieken, in relatie met welke factoren, et cetera). Er dient wel acht geslagen te worden op het feit dat 80% van de invoeringen van meetprogramma’s mislukt (Verhoef, 2002) daarom moet er over een dergelijke invoering niet te licht gedacht worden. 3. Uitvoeren en evalueren van reengineering projecten. De aanpak moet ingezet worden bij nieuwe projecten en dient bij en na gebruik geëvalueerd te worden. De basis van de aanpak is nu gestaafd op literatuur en 1 specifiek reengineering traject. Aanpassingen zouden gedaan kunnen worden door vragen toe te voegen en / of te verwijderen uit de portfolio analyse en SRA, nieuwe activiteiten toe te voegen aan de aanpak, etc. Als vanzelfsprekend kan dit alleen op basis van nieuwe projecten en nieuw verworven kennis. De metrieken kunnen hier ook een referentie geven. 4. Opstellen van een model voor toolselectie Toolselectie kan op basis van waardering van technieken en het voldoen in een techniek van een tool. Dit is al vastgelegd in dit verslag. Deze waardering kan ook in andere projecten gemeten worden, en hierdoor kan deze waardering verfijnd worden. De resultaten van projecten, waarbij meer dan restructuring en redocumentation wordt uitgevoerd, kunnen hier belangrijke gegevens toevoegen. Verder onderzoek / analyses naar verschillende tools kan uitgevoerd worden op basis van een grotere set criteria. Dit verslag biedt een basis voor de selectie en zou verder uitgebreid moeten worden in een verder onderzoek. 5. Constante evaluatie van het reengineering vakgebied Ook al bestaat het onderzoeksgebied al een tijd, de technologie gaat snel vooruit en hierdoor verouderen methoden en aanpakken. Het is daarom van belang om op de hoogte te blijven van de ontwikkelingen in het gebied van reengineering. Concreet zou daarom gekeken moeten worden naar de ontwikkeling van het vakgebied via de verschillende symposia en naar de ontwikkeling van het Architecture Driven Modernization binnen de Model Driven Architecture, als zijnde een veelbelovend concept.

Referenties

Referenties

Aken, T., van. (2002) De weg naar projectsucces. Eerder via werkstijl dan via instrumenten. (3e druk). Reed Business Information, Den Haag.

Abran, A., Moore, J. (Eds.). (2004). A Guide to Software Engineering Body of Knowledge. Los Alamitos, California: IEEE Computer Society

Bennet, K.H., Rajlich, V.T. (2000a). Sofware Maintenance and Evolution: a Roadmap. In: A.Finkelstein (Ed.), The Future of Software Engineering", ACM Press 2000

Bennet, K.H., Rajlich, V.T. (2000b). A Staged Model for The Software Life Cycle. Computer, July 2000. Bergey,J., Hefley, W., Lamia, W., Smith, D. (1995). A Reengineering Process Framework, Pitsburgh,

Carnegie Mellon University: Software Engineering Institute. Bergey, J., Smith, D., Tilley, S., Weiderman, N. (1997). Approaches to Legacy system evolution.

Pitsburgh, Software Engineering Institute, Carnegie Mellon University Bergey, J., Smith, D., Tilley, S., Weiderman, N. (1999). Why Reengineering Projects Fail. Pitsburgh,

Carnegie Mellon University: Software Engineering Institute Bianchi, A., Caivano, D., Marengo, V., Visaggio, G., (2003). Iterative Reengineering of Legacy Systems.

IEEE Transactions on Software Engineering. Vol. 29, No. 3. Bisbal, J., Lawless, D., Wu, B., Grimson, J. (1999). Legacy Information Systems: Issues and Directions.

IEEE Software, vol. 16, no. 5, pp. 103-111 Boehm, B. W. (1981). Software Engineering Economics.. Englewood Cliffs, New Jersey: Prentice-Hall

Inc. Boehm, B., Clark, B., Horowitz, E., Westland, C. (1995). An Overview of the COCOMO 2.0 Software Cost

Model., Software Technology Conference. April, 1995. Verkregen op 10-11-2004 van http://sunset.usc.edu/research/COCOMOII/cocomo_main.html

Boreel, M., Franken, P., (1997). Gevangen tussen verleden en toekomst, legacy systemen in het informatietijdperk. Verkenningsinstituut Nieuwe Technologie; Diemen

Brodie, M., Stonebraker, M., (1993). DARWIN: On the Incremental Migration of Legacy Information Systems. College of Software Engineering, University of California, Berkeley.

Butlergroup (2000). Legacy Renovation Management Guide. Verkregen op 1-8-2004 van: http://www.migration-technologies.com/MT_Downloads/ButlerGroup%20Renovating%20Legacy%20Apps.pdf

Chikofsky, E.J., Cross, J.H. (1990). Reverse Engineering and Design Recovery: A Taxonomy. IEEE Software, vol. 7, no. 1, pp. 13-17.

Department of Defense (1997). Software Reengineering Assesment Handbook, version 3.0. Verkregen op 10-10-2004 van http://www.stc-online.org/cd-rom/cdrom2000/stsc/Reports/Srahv30.pdf

Department of the Air Force (200). Guidelines for Succesfull Acquisition and Management of Software-Intensive Systems. version 3.0. Verkregen op 10-03-05 van http://www.stsc.hill.af.mil/resources/tech_docs/gsam3/chap12.pdf

Deursen, A. van, Kuipers, T., (2003) Source-based Software Risk Assessment. In proceedings of the International Conference on Software Maintenance.pp 385-388

Donath, P. (2004). Living tomorrow with todays legacy – In de praktijk. Verkregen op 10-12-2004 van: http://www.omnext.net/downloads/

DSDM, (2004). Moscow Rules. Verkregen op 20-3-2005 van http://na.dsdm.org/en/about/moscow.aspErlikh, L., (2000). Leveraging Legacy System Dollars for E-business, IT-Pro, May/June 2000. Fenton. E.N., Pfleeger, S.L. (1997). Software Metrics. Boston: PWS Publishing Company. Gold, N. (1998). The meaning of Legacy Systems., Centre for Software Maintenance, University of

Durham, UK. Hughes, B., Cotterell, M. (1999) Software Project Management, (2nd Ed.). Maidenhead, England,

McGraw-Hill Publishing. IBM (2004). Visaual Age PL/I for Windows. Verkregen op 10-12-2004 van http://www-

306.ibm.com/software/awdtools/pli/pliwin/Kemerer, C.F., Slaughter, S. (1999). An Empirical Approach to Studying Software Evolution. IEEE

Transactions on Software Engineering. Vol. 25 nr. 4, July/August 1999.

89

http://sunset.usc.edu/research/COCOMOII/cocomo_main.html

http://www.migration-technologies.com/MT_Downloads/ButlerGroup%20Renovating%20Legacy%20Apps.pdf

http://www.migration-technologies.com/MT_Downloads/ButlerGroup%20Renovating%20Legacy%20Apps.pdf

http://www.stc-online.org/cd-rom/cdrom2000/stsc/Reports/Srahv30.pdf

http://www.stsc.hill.af.mil/resources/tech_docs/gsam3/chap12.pdf

http://www.omnext.net/downloads/

http://na.dsdm.org/en/about/moscow.asp

http://www-306.ibm.com/software/awdtools/pli/pliwin/

http://www-306.ibm.com/software/awdtools/pli/pliwin/


Koskinen, J. (2003). Software Maintenance Costs. University of Jyväskylä: Information Technology Research Institute. Verkregen op 12-08-2004 van http://www.cs.jyu.fi/~koskinen/smcosts.htm

Koskinen J., Lintinen H., Sivula H. and Tilus T.,(2004). Evaluation of Software Modernization Estimation Methods Using NIMSAD Meta Framework, Information Technology Research Institute, University of Jyväskylä, Jyväskylä, Finland. Verkregen op 30-11-2004 van: http://www.titu.jyu.fi/eltis/julkaisut.html

Kuipers, T., Piek, C.M., (2004). Kwaliteit van Software: Niet Langer een Black-Box door gebruik van Softwareanalyse. Compact, Februari 2004.

Lehman, M.M. (1996). Laws of Software Evolution Revisited. In Proceedings of the 5th European Workshop on Software Process Technology. pp 108-124

McNamara, C., (1999). Basic Business Research Methods. Management Assistant Program for Non-Profits. Verkregen op 15-12-2005 van http://www.mapnp.org/library/research/research.htm

MicroFocus (2005). Leverage and Extend. Verkregen op 11-01-2005 van http://www.microfocus.com/solutions/leverageandextend/

Musser, J., (2002). Software Project Management Resource Center. Columbia University. Verkregen op 7-3-2005 van http://www.columbia.edu/~jm2217/Q7503_4post.ppt

Olsem, M.R. (1998). An incremental Approach to Software Systems Re-engineering. Journal of Software Maintenance: Research and Practice. 10, 181-202.

Olsem, M.R., Sittenauer, C., (1992). Back to the Future through Reengineering, The Santa Barbara I Workshop. Crosstalk, Journal of Defense Software Engineering (November 1992, Vol. 38)

OMG, ADM Task Force (2004). Architecture Driven Modernization Roadmap. Verkregen van http://adm.omg.org op 10-12-2004

Omnext (2004). Nuclis .NET Userguide version 2.0 (Intern Centric Beschikbaar) Pink Seminar (2004). Presentaties met betrekking tot TCO verlaging t.o.v. Mainframes; van

Belastingdienst, KPMG, PinkRoccade. Project Management Institute (2000) A Guide to The Project Management Body Of Knowledge., PMI

Publishing Division, Pennsylvania. Rosenberg, L., Hyatt, L. (1996) Re-engineering. Software Assurance Technology Center, Unisys Federal

Systems, NASA. Verkregen van: http://satc.gsfc.nasa.gov/support/reengrpt.PDF op 2-11-2004Seacord, R.C., Plakosh, D., Lewis, G.A. (2003) Modernizing Legacy Systems; Software Technologies,

Engineering Processes and Business Practices. Boston, Massachussets: Pearson Education. Shenhar, A.J., Dvir, D. 2003. How Projects Differ, and What to Do About It. In J.K. Pinto, P.W.G. Morris,

(Eds.), The Wiley Guide to Managing Projects. New York, NY, John Wiley & Sons Inc. Singh, R. (1997). International Standard ISO/IEC 12207 Software Life Cycle Process, Federal Aviation

Administration, Washington, USA. Sneed, H. M. (1991). Economics of Software Re-Engineering. Journal of Software Maintenance:

Research and Practice. Vol. 3, 163-182 Sneed, H. M. (1995). Planning the Reengineering of Legacy Systems. IEEE Software, January 1995, pp.

24-34. Sneed, H. M. (1999). Risks involved in Reengineering Projects. In proceedings of Working Conference

on Reverse Engineering (WCRE ’99), IEEE Computer Society Press, Atlanta, Oct. 1999, pp. 204-212

Software Improvement Group (2005). InSIGht Nieuwsbrief. Verkregen op 3-3-2005 van www.sig.nlSommerville, I. (2001). Software Engineering. (6th ed.). Harlow, Essex: Addison-Wesley Publishers. Sommerville, I. (2004). Software Engineering. (7th ed.). Harlow, Essex: Addison-Wesley Publishers Stal, C.P. (2001). Audit Onderhoudbaarheid RePAS. Van Aetsveld Management Groep Tilley, S.R. (1995). Perspectives on Legacy Reengineering. Draft: Version 0.3. Software Engineering

Institute, Carnegie Mellon University. Ulrich, W.M. (2002). Legacy System Transformation Strategies. Upper Saddle River, NJ, USA: Prentice

Hall PTR Verschuren, P., Doorewaard, H. (2003), Het ontwerpen van een onderzoek. (3rd Ed.) Utrecht: Uitgeverij

Lemma BV. Verhoef, C. (2002). Quantitative IT Portfolio Management. Science of Computer Programming. Vol. 45,

2002, pp. 1-96. Warren, I. (1999). The Renaissance of Legacy Systems, Method support for Software-system Evolution.

London: Springer – Verlag.

90

http://www.cs.jyu.fi/%7Ekoskinen/smcosts.htm

http://www.titu.jyu.fi/eltis/julkaisut.html

http://www.mapnp.org/library/research/research.htm

http://www.microfocus.com/solutions/leverageandextend/

http://www.columbia.edu/%7Ejm2217/Q7503_4post.ppt

http://adm.omg.org/

http://satc.gsfc.nasa.gov/support/reengrpt.PDF%20op%202-11-2004

http://www.sig.nl/

Referenties

Wu, B., Lawless, D., Bisbal, J., Richardson, R., Grimson, J., Wade, V., O’Sullivan, D.,(1997). The Butterfly Methodology: A Gateway-free Approach for Migrating Legacy Information Systems. Proceedings of the 3rd Conference of Complex Computer Systems, Villa Olmo, Italy. (Pp 200-205)

91

Afkortingen

Afkortingen

Onderstaand is een overzicht opgenomen van de verschillende afkortingen die binnen het verslag gehanteerd worden. Afkorting Betekenis / Uitleg AA Adaptation & Assimiliation

ADM Architecture Driven Modernization ASLOC Adapted Source Lines of Code

BIS Broncode Informatie Systeem

CBA Centric Beheer Aanpak CBD Component Based Development

CM Code modification COCOMO Constructive Cost Model

CMM Capability Maturity Model CPA Centric Project Aanpak

CTB Component Test Bank CSU Computer Software Unit (= kleinste samenhangende

eenheid die apart testbaar is.)

DM Design Modification DSI Delivered Source Intstructions

EDI Electronic Data Interchange ESLOC Estimated Source Lines of Code

FDS Functionele Documentatie Systeem FPA Functie Punten Analyse

IM Integration modification ISO International Organization for Standardization

KLOC Kilo Lines of Code MDA Model Driven Architecture

MTP Modelerings Tool Pensioenen OMG Object Management Group

PAS Pensioenen Administratie Systeem REPAS Reconstructie PAS (naam voor doelsysteem)

RMM Risk Managed Modernization SBA Stichting Artsenpensioenfonds

SIG Software Improvement Group SLOC Source Lines of Code

SRA Software Reengineering Assesment SU Software Understanding

UNFM Unfamilliarity with Software

93

Interne Referenties

Interne referenties

Onderstaand zijn de interne referenties toegevoegd. Deze zijn geraadpleegd binnen het onderzoek. De verschillende bronnen zijn niet openbaar verkrijgbaar, maar intern bij Centric verkrijgbaar via het intranet, danwel het projectbureau. Documenten met beschrijving Centric Project Aanpak CPA – Template Kwaliteit en Project Borgingsprocedures versie 3.1 CPA – Template Projectvoorstel versie 3.0 CBA – Template Beheervoorstel versie 1.0 CPA – Plan van Aanpak Teksten versie 1.6 CPA – Checklist project start-up CPB naar PM CPA – Checklist project start-up CPB CPA – Procedure escalatie CPA – Template Log Bestand versie 3.0 CPA – Template Plan van Aanpak versie 3.01 CPA – FPA Template CPA – Projectadministratie CPA – Risico Analyse Documenten SBA aanpak Walvis ISO-9001:2000 Kostenplanning RePAS Onderhoudsplan SBA Projectaanpak SBA Projectmanagement plan RePAS Workshops (presentaties met commentaar):

Reconstructie PAS 25-01-01 (Technisch) Productmodellering RePAS 13-02-01 Reconstructie PAS 22-02-01 (Fasering) Systeemmodel RePAS 12-03-01 Reconstructie PAS Deelproject O&P – 22-05-01 Systeemmodel RePAS – Hoe nu verder? 20-03-04 Terugblik Reconstructie PAS 31-10-04

95

Lijst van Figuren

Lijst van Figuren

figuur 1.1; organigram Centric ........................................................................................................1 figuur 1.2 - onderzoeksmodel..........................................................................................................3 figuur 1.3 - onderzoeksgebieden .....................................................................................................4 figuur 1.4 - onderzoeksaanpak ........................................................................................................5 figuur 2.1 - ISO/IEC 12207 Software Lifecycle (Singh, 1997) .............................................................7 figuur 2.2 - Version Staged Model (Bennet 2000)............................................................................10 figuur 2.3 - reengineering framework (Chikofsky & Cross, 1990) ......................................................13 figuur 2.4 - reengineering verhouding met onderhoud en ontwikkeling (Bergey, 1995) ......................13 figuur 3.1 - framework Shenhar en Dvir (2003) ..............................................................................17 figuur 3.2 - portfolio analyse (Boreel, 1996) ...................................................................................21 figuur 3.3 - verschillende vormen van migratie ..............................................................................25 figuur 3.4 - architectuur iterative reengineering (Bianchi et al, 2003)................................................27 figuur 3.5 - kostenopbouw Warren (1999)......................................................................................30 figuur 3.6 - begrip van legacy en doeltechnologie ...........................................................................33 figuur 4.1 - theoretisch model voor reengineering...........................................................................42 figuur 5.1 - aanpak praktijkonderzoek............................................................................................45 figuur 6.1 - CPA overzicht (Interne referenties, CPA).......................................................................51 figuur 6.2 - organisatie SBA project ...............................................................................................53 figuur 6.3 - stappen in uitvoering SBA project.................................................................................57 figuur 6.4 - ordening risico's op impact en waarschijnlijkheid ...........................................................61 figuur 6.5 - partiele ordening van de risico's ...................................................................................61 figuur 6.6 - overzicht kosten reengineering ten opzichte van nieuwbouw ..........................................65 figuur 7.1 - kostenverhoudingen reengineering...............................................................................75 figuur 9.1 - reengineering aanpak binnen CPA ................................................................................86

97

Lijst van Tabellen

Lijst van Tabellen

tabel 2.1 - overzicht soorten onderhoud (Abran, 2004)......................................................................9 tabel 2.2 - terminologie Chikofsky en Cross (1990) .........................................................................12 tabel 3.1 - portfolio analyse: technisch risico (Boreel, 1996) ............................................................20 tabel 3.2 - portfolio analyse: bedrijfswaarde (Boreel, 1996) .............................................................20 tabel 3.3 - kostenfactoren Sneed(1995) .........................................................................................29 tabel 6.1 - enquête resultaten werkstijl ..........................................................................................54 tabel 6.2 - instrumentenwaardering project ....................................................................................54 tabel 6.3 - overzicht SRA strategieën voor SBA case........................................................................55 tabel 6.4 - risico waardering projectmedewerkers ..........................................................................60 tabel 6.5 - risico waardering projectleider.......................................................................................62 tabel 6.6 - indicatie onderhoudskosten SBA...................................................................................63 tabel 6.7 - enquête resultaten COCOMO factoren............................................................................64 tabel 6.8 - enquête resultaten waardering PAS ...............................................................................64 tabel 6.9 - enquête resultaten ervaring medewerkers......................................................................65 tabel 6.10 - enquête resultaten waardering PAS .............................................................................66 tabel 6.11 - enquête resultaten waardering RePAS..........................................................................66 tabel 6.12 - waardering begripsvormingtechnieken tools .................................................................67 tabel 6.13 - enquête resultaten tooling SBA project.........................................................................67 tabel 7.1 – relatieve kosten per iterative reengineering – activiteit....................................................76 tabel 7.2 - overzicht waardering technieken begripsvorming ............................................................77

99

Bijlagen

Bijlage 1 Terminologie overzicht

In deze bijlage zal een overzicht gegeven worden van de verschillende termen die binnen het gebied reengineering worden gehanteerd: Term Betekenis Legacy Software Legacy Software is critical software that cannot be modified efficiently

(Gold, 1998) Evolutie The dynamic behavior of programming systems as they are maintained

and enhanced over their life times. Kemerer (1999).

(Continued) Maintenance/Onderhoud

The process of modifying existing operational software while leaving its primary functions intact (Boehm, 1988)

Reengineering “The examination and alteration of a subject system to reconstitute it in a new form and the subsequent implementation of the new form” (Chikofsky en Cross, 1990)

“the process of analyzing a subject system to identify the systems components and their interactions and to create representations of the system in another form or a higher level of abstraction.” (Chikofsky en Cross, 1990)

Reverse engineering

Redesign “a subset of reverse engineering in which domain knowledge, external information and deduction or fuzzy reasoning are added to the observations of the subject system, to identify meaningful higher level abstractions beyond those obtained directly by examining the system itself” (Chikofsky en Cross, 1990)

Redocumentation “The creation or revision of a semantically equivalent representation within the same relative abstraction level” (Chikofsky en Cross, 1990)

Restructuring “the transformation from one representation form to another, at the same relative abstraction level, while preserving the subject system’s external behavior. (functionality and semantics)” (Chikofsky en Cross, 1990)

System restructuring

Op een globaal niveau naar de software architectuur kijken en de structuur expliciet maken. Er wordt gekeken naar modules en het verbeteren van deze architectuur gebeurd meestal met de hand, omdat er een begrip nodig is van de verantwoordelijkheid van functies. (Warren, 1999)

Program restructuring

het herstructureren van een programma, door gebruik te maken van modernere programmeer constructies. (Warren, 1999)

Data reengineering

Behelst het analyseren en reorganiseren van de data structuren van een systeem en in sommige gevallen ook de waarden van de data. (Warren, 1999)

Forward engineering

“the traditional process of moving from high-level abstractions and logical implementation-independent designs to the physical implementation of a system” (Chikofsky en Cross, 1990)

Replacement Betreft alle alternatieven waarbij het huidige systeem niet behouden wordt (opnieuw ontwikkellen, terugtrekken van het systeem, enz.)

Hantering binnen het verslag Om een consistente term te hanteren voor het verslag, zal er voortaan over reengineering gesproken worden wanneer het concept vernieuwbouw wordt besproken. Deze term wordt het meest gebruikt en de alternatieven zijn voornamelijk geïntroduceerd door de commercie (reclamation, renovation en transformation) en daardoor minder waardevol. Ook moet opgemerkt worden dat reengineering een apart onderscheiden vakgebied is, waardoor het gebruik van andere termen dan reengineering alleen verwarring oplevert.

101


Alle overige termen kunnen in principe worden ondergebracht als een manier van reengineering of een bepaalde fase van reengineering. Zo zijn refactoring (het om zetten van code naar code), migratie (het overzetten van het systeem naar een andere omgeving), retargeting (het overzetten van het systeem naar een ander hardware platform), allen vormen van restructuring. Deze termen kunnen uiteraard gebruikt worden om een specifieke techniek of methode aan te duiden, maar zijn niet volledig om het hele traject te definiëren. Bij het hanteren van een ‘vernieuwbouw’ traject in de gebruikelijke zin, dient wel opgemerkt te worden dat er naast reengineering ook het verwijderen van onderdelen en nieuwbouw (toevoegen van nieuwe functionaliteiten) plaats kan vinden, wat dus niet onder de noemer reengineering valt. Alleen het daadwerkelijke proces om van de oude programmatuur nieuwe te maken, wordt Reengineering genoemd. Er kan op drie manieren met het legacy probleem omgegaan worden. De eerste is continued maintenance, wat inhoudt dat het probleem eigenlijk wordt genegeerd. Het andere uiterste is het opnieuw ontwikkelen van de applicatie of te vervangen met COTS (commercial of the shelf) applicaties. Het alternatief is reengineering, wat het vernieuwen van de applicatie inhoudt. Dit bestaat uit drie stappen, waaronder alle varianten van reengineering zijn onder te brengen: reverse engineering, restructuring en forward engineering. Dit overzicht van terminologie kan dan grafisch als volgt gegeven worden:

Hiernaast is het zinnig om hier de vervoegingen van het engelse werkwoord ‘to reengineer’ te geven voor het Nederlands (Nederlandse Taalunie, 2005): Tegenwoordige tijd: Ik reegineer Jij reengineert Hij / Zij reengineert Wij reengineeren Verleden tijd: Ik reengineerde Jij reengineerde Wij / Zij reengineerden Voltooid dlw: Gereengineerd

102

Bijlagen

Bijlage 2 Samenvatting vergelijk StepWise

In deze bijlage wordt beknopt een eerste vergelijk van de StepWise methode met de CPA behandeld. Een Software Project Methode: StepWise De StepWise methode (Hughes, 1999) biedt een stappenplan aan om het project te plannen. Deze methode is gekozen omdat het een praktische insteek biedt (een stappenplan) en het een veel gebruikte bron is. Het stappenplan staat hieronder grafisch weergegeven en in de tabel ernaast worden de verschillende stappen kort toegelicht.

Conclusies vergelijk StepWise met CPA en SBA case StepWise geeft een aantal stappen aan die doorlopen moeten worden, maar geeft geen oordeel over de kwaliteit van deze stappen. Dit houdt in dat de enige echte houvast die er is, is of een stap wel of niet is doorlopen. Onderstaand een overzicht waar CPA en de SBA aan voldoen: StepWise CPA SBA case Step 0 Bid Management Onbekend

Step 1 Bid Management / Project Voorbereiding PJM / Projectplan

Step 2 Bid Management / Project Voorbereiding PJM / Projectplan Step 3 Bid Management / Project Voorbereiding PJM / Projectplan

Step 4 Project Voorbereiding PJM / Projectplan

Step 5 Project Voorbereiding Niet uitgevoerd

Step 0: Select Project

Step 3: Analyseer Project

karakteristieken

Step 1: Identificeer project scope en

doelen

Step 2: Identificeer project infrastructuur

Step 4: Identificeer de producten en

activiteiten

Step 5: Schatting inspanning voor

activiteit

Step 6: Identificeren van activiteit risico’s

Step 7: Toewijzen middelen

Step 8: Review/ Publiceer plan

Step 9: Uitvoering plan

Step 10: Lager niveau planning

Review

Voor elke activiteit

Lager detail niveau

Stap: 0: Project Selectie Punt waarop besloten wordt dat het project het waard is om te starten 1: Onderkennen van scope en doelen Vaststellen doelen, project autoriteit vaststellen & stakeholder analyse 2: Onderkennen van de project infrastructuur Bepaling relatie project en strategie, vastlegging standaarden en team organisatie 3: Analyse van project kenmerken Projectaard en kwaliteitseisen vastgesteld, Risico’s worden ingeschat 4: Onderkennen van project producten en activiteiten Vastleggen activiteiten en taken. Productflows en Work-Breakdown Structures kunnen hierbij helpen 5: Inschatten inspanning voor iedere activiteit Bottom-up inschattingen voor betere activiteitverdelingen. 6: Onderkennen van activiteiten risico’s Per activiteit onderkennen van risico’s en maatregelen 7: Toewijzen van middelen Resource toewijzingen & wijzigingen aan het plan op basis hiervan 8: Herzien / Publiceren van het plan Sturendheid en kwaliteit plan wordt herzien. 9: Uitvoering plan en 10: Lagere niveaus van planning Tijdens het project worden plan en planning bijgesteld

103


Step 6 Project Voorbereiding Niet uitgevoerd

Step 7 Project Voorbereiding PJM / Projectplan Step 8 Project Voorbereiding PJM / Projectplan

Step 9 Project Uitvoering Niet vast te stellen Step 10 Project Uitvoering Niet vast te stellen

Step 9/10 Project Uitvoering PJM / Projectplan Vergelijk StepWise <-> CPA CPA is een uitgebreid skelet waarin veel vrijheid is voor het invullen van het project op verschillende manieren. Het is mogelijk verschillende ontwikkelmethodieken te hanteren en onderdelen toe te voegen of onderdelen weg te laten. Op deze manier kan bijvoorbeeld een project dat volgens CPA wordt uitgevoerd, ook Prince2 conform zijn. In het vergelijk met StepWise komt dit ook naar voren. Aspecten die niet expliciet in de CPA genoemd worden, kunnen wel beschreven worden. De methode StepWise zou goed binnen de CPA kunnen worden uitgevoerd. StepWise zelf onderkent ook in meer of mindere mate facultativiteit in zijn stappen. Vergelijk StepWise <-> SBA Er wordt in principe vanuit gegaan dat het SBA project succesvol is geweest. Dit op basis van 2 onafhankelijke audits en hoe er binnen Centric tegen het project aangekeken wordt. In het kader van de StepWise van Hughes (1999), voldoet de aanpak van de SBA casus niet om een succesvol project te garanderen. Er worden geen maatstaven voor doelen, geen stakeholders, geen activiteiten risicos, activiteiten planningen, activiteiten begrotingen, medewerkers per activiteit, en onderlinge activiteit relaties bepaald. Toch is het SBA project een geslaagd project. Dit wringt. Dit neigt naar een conclusie waaruit komt dat SBA een uitzondering was, omdat het is uitgevoerd met een ‘oneindig’ budget. Voorlopige conclusies / stellingen Het onderscheid tussen engineering en reengineering bevestigt de onzekerheid binnen het SBA project en de CPA. Er is bij een reengineering project onzekerheid over:

- Indeling van activiteiten (doorlooptijden, opvolging) Dit komt voornamelijk naar voren uit de SBA case.

- Opstellen van begroting (FPA beperkt bruikbaar, indeling van activiteiten onzeker) Komt naar voren in de case van de pensioenverzekeraar

- Opstellen van de risico’s (SarBachets beperkt bruikbaar, indeling activiteiten onzeker) Dit komt naar voren uit de twee voorgaande conclusies.

Doordat er een onderscheid gemaakt kan worden tussen reengineering projecten en engineering projecten, zijn er ook delen van de CPA die minder goed gebruikt kunnen worden omdat ze zijn toegespitst op engineering projecten. Een voorbeeld hiervan is SarBachets risico analyse die geen rekening houdt met specifieke risico’s en niet aanwezig risico’s nog wel hanteert.

104

Bijlagen

Bijlage 3 Indicatoren van Aken

In de theorie van van Aken worden een aantal factoren gebruikt. Hoe deze gewaardeerd moeten worden, wordt in deze bijlage uitgewerkt. In onderstaande tabel wordt de grijpbaarheid van projecten geoperationaliseerd door drie factoren tegen elkaar uit te zetten en gewicht te verlenen (betrokken partijen = 3, disciplines = 1, tastbaarheid = 2)

Betrokken Partijen (G=3)

Laag (S=1) Midden (S=2) Hoog (S=3)

Betrokken Disciplines (G=1)

L (1) M (2) H(3) L(1) M (2) H(3) L(1) M(2) H(3)

Hoog 6 7 8 9 10 11 12 13 14

Mid-den

8 9 10 11 12 13 14 15 16

Tastbaarheid resultaat (G=2)

Laag 10 11 12 13 14 15 16 17 18

De denkinstrumenten die van Aken (2002) onderscheid staan in onderstaande tabel uiteengezet in de verschillende fasen van de leercyclus van Kolb. Denk instrumenten Beslis Instrumenten Doe Instrumenten Bezin

Instrumenten Probleem Analyse Sterkte / Zwakte analyses Brainstormen Scenario’s

BesluitvormingsmethodiekRisico analyse Project statuut / handvest Programma van Eisen

Formeel Startschot Gesystematiseerde Activiteitenplanning (PERT, Gant) Resourceplanning Budgettering Informatieplanning

Voortgangsrapport Monitoring Evaluatie formulieren

Onderstaande contrastparen worden door van Aken gebruikt om de werkstijl te bepalen die gehanteerd wordt.

Contrastparen Doelgerichte werkstijl: Strenge werkdiscipline versus De kantjes er van aflopen Adequate overlegstructuren versus Inefficiente overlegstructuren Veel sturing versus Geen sturing Grote saamhorigheid/groepsgeest versus Geen saamhorigheid Doelgericht versus Afwachtend Goede organisatie versus Chaotische organisatie Snel/Vlot versus Traag

Contrastparen Structurerende werkstijl: Zorgvuldig versus Slordig Vastgelegde procedures versus Ad Hoc procedures Regels in acht genomen versus Regels werden zelden in achtgenomen Ordelijk versus Ongeordend Discreet versus Indiscreet Alles werd gecontroleerd versus Niets werd gecontroleerd Vastberaden versus Aarzelend

105


Succesmeting Van Aken gebruikt voor het meten van succes een actor definitie met de bijbehorende criteria voor elke actor. Hoe hoger het getal van de groep, hoe kleiner het succesbelang is. Groep 1: Gebruikers Groep 2: Opdrachtgever Projectmanager Projectteam Lijn management Directe belangengroeperingen Groep 3: Projectuitvoerders Indirecte belangengroeperingen Maatschappelijke groeperingen De criteria waar de partijen de mate van tevredenheid op baseren, zijn meegenomen maar niet geanalyseerd. (Het ging immers om de mate waarin men tevreden was, niet in de basis van tevredenheid.) De volgende criteria worden in ieder geval genoemd:

Kosten Tijd Kwaliteit Verloop Arbeidstevredenheid Gebruiksnut Hinder Eigen belang Expertcriteria Politiek

106

Bijlagen

Bijlage 4 Vragenlijsten Software Reengineering Assesment

De verschillende vragenlijsten zoals deze zijn uitgevoerd binnen het onderzoek, zijn opgenomen in deze bijlage en zijn achtereenvolgens opgenomen.

Voorbereiding a Nee

b Ja, maar ze zijn onduidelijk of niet bekend bij iedereen

c Ja

1. Zijn de doelen voor reengineering vastgelegd voor dit reengineering project?

a Nee

b Ja, maar met reserveringen of er Is het beeld dat alle onderhoudsproblemen weg zullen gaan

c Ja

2. Ondersteund het management deze reengineering inspanning?

a Niet belangrijk

b Gemiddeld

c Kritiek

3. Hoe belangrijk is dit project voor de organisatie?

a weinig tot geen

b Enigzins, maar niet voldoende

c Ja, er is voldoende ondersteuning

4. Is er financiele ondersteuning voor deze inspanning?

a Nee

b Voornamelijk

c Ja

5. Is het project consistent met de overall bedrijfsstrategie?

a Nee, of niet alle groepen zijn gereprensteerd in dit team

b Ja, maar ze zijn niet full-time vastgelegd op dit project

c Ja.

6. Is er een reengineering team vastgesteld?

a Nee

b Ja, maar alleen in algemene termen

c Ja, maar alleen in algemene termen

7. Is er een nieuw onderhoudsproces op een heldere manier vastgelegd?

a Nee

b Ja, maar is verder onbekend

c Ja.

8. Is er een organisationele CMM assesment uitgevoerd?

a een 9. Het CMM level van de organisatie is

b twee

107


c drie of meer

a Nee

b Ja, er is een tactisch plan

c Ja, het plan wordt uitgevoerd

10. Is er een tactisch plan om het CMM level te verhogen van de onderhouds organisatie?

a Nee

b

11. Zijn er ontwikkel / onderhouds metrieken vastgelegd in de organisatie?

c

Ja, maar deze zijn niet gebaseerd op proces verbetering of op bedrijfsdoelen

Ja, maar deze zijn niet gebaseerd op proces verbetering of op bedrijfsdoelen

a Nee

b

12. Worden de software metrieken regulier gebruikt?

c

Ja, maar het is niet bekend hoe het precies wordt toegepast

Metrieken spelen een belangrijke rol in het vormen van onderhoudsbeslissingen.

a Niet

b

13. Hoe zullen de metrieken gebruikt worden tijdens het reengineering proces?

c

Wordt nog vastgelegd, of is niet bekend

Metrieken zullen uitslag geven of het project succesvol was.

a Niet overwogen

b

14. Hoe zal de gereengineerde software gevalideerd worden?

c

De huidige validatie / test suite zal hiervoor gebruikt worden

Gedetailleerd test plan, inclusief functionele traceability

a Nee

b Er wordt getest, maar het meeste is ad hoc of black-box

15. Wordt er in de nieuwe onderhoudsomgeving ook getest?

c Testen is een integraal onderdeel van de nieuwe omgeving

a Nee, of niet bekend

b

16. Zijn er tools beschikbaar (voor het automatiseren van reengineeringtaken) voor het doel platform en doel broncode?

c

Ja, maar moet in grote mate aangepast worden

Ja.

a Weinig tot geen van het reengineering team zijn getrained

b Enkele

17. Hoeveel huidige reengineering kennis / training is er binnen de onderhoudsorganisatie?

c Bijna alle zijn getrained in reengineering, tools en doel omgeving.

a Training is niet overwogen

b 18. Wie is getraind in welke richting?

c

training is een onderdeel van het reeningeering traject, maar er wordt niet in detail gegaan

Mensen zijn toegewezen en er zijn specifieke lessen voor verschillende mensen.

Nee 19. Is er een gefundeerd plan om het reengineering team te trainen in nieuwe technieken of tools die gebruikt worden?

a

108

Bijlagen

b Ja, maar minder dan 10% van het reengineering budget

c Training is 10% of meer van het reengineering budget.

Belang van de software a Minimaal

b

1. In welke mate draagt de software direct bij aan de missie van de klant?

c Enigzins

Significant

a Weinig of geen schade

b

2. Wat zou het effect zijn van niet werkende software?

c Significante schade

Gigantische schade (grote financiele verliezen, doden)

a Ja, of niet nodig.

b

3. Is er een noodplan (direct) aanwezig dat gehanteerd kan worden wanneer de software niet werkt?

c

Ja, maar lastig uitvoerbaar en groot verlies van efficiency bij toepassing

Nee

a Weinig of geen effect op andere missie kritische systemen of data bestanden

b

4. Wanneer de software niet werkt, tast dit andere missie-kritische systemen of databases aan?

c

Significante intregeling van andere missie kritieke systemen en / of databestanden

Permanente schade, grote financiele consequenties, of verlies van levens door het ontregelen van systemen of data bestanden

a Nee

b

5. Is de software belangrijk voor het management van de organisatie?

c

Enigzins of niet bekend

Ja

a Nee

b 6. Is de software belangrijk voor de klant?

c Enigzins of niet bekend

Ja

a Nee, de gebruikers hebben kleine systemen of handmatige processen ontwikkeld om de functie van de software te vervangen

b

7. Wordt de software gebruikt?

c

In enige mate, maar er zijn valide klachten over de functionele tekortkomingen van de software.

Ja, de software voert de bedrijfsfuncties uit die het geacht wordt uit te voeren.

a Nee

b

8. Heeft de software een achtergebleven onderhoudsstaat?

c Ja, maar is stabiel of vermindert

Ja, en wordt groter

a Weinig

b

9. Karakteriseer het verandergedrag van de software binnen het afgelopen jaar.

c Gemiddeld

Veel

109


Redocument a Compleet en actueel

b

1. De documentatie van de software is het best te typeren als:

c Incompleet en niet actueel

Niet bestaand of misleidend

a Altijd

b

2. Wordt de documentatie bijgewerkt na iedere verandering?

c Soms

Amper of nooit

a Ja, de onderhoudsmedewerkers kunnen gemakkelijk de documentatie gebruiken om de kandidaatsoftware te gebruiken

b

3. Is de technische documentatie bruikbaar en wordt deze gebruikt tijdens onderhoudswerkzaamheden?

c

Het gebruiken van de documentatie kan veel tijd kosten

Nee, de documentatie bestaat niet of is te lastig om zinnig te gebruiken.

a Ja

b

4. Is de documentatie vastgelegd volgens een standaard formaat?

c

Ja, maar de standaard is vaag of de documentatie komt niet overeen

Er is geen standaard

a Ja

b

5. Is er tijdens de levensduur van de applicatie een proces geweest dat zorgdroeg voor het consequent volgen van de documentatie standaarden?

c

Het proces wordt niet consistent toegepast

Er is geen dergelijk proces

Broncode vertaling

a Geavanceerde hogere programeertalen als C++, Java, etc.

b

1. Wat is de hoofdtaal van de software?

c

Hogere orde talen als COBOL, Fortran, C, Pascal, etc.

Assembly talen

a 1

b

2. Hoeveel programmeertalen gebruikt de software?

c 2

3 of meer

a geen behoefte aan

b

3. Is er een behoefte om de broncode te consolideren of te vertalen?

c Nog niet , maar wordt snel verwacht

Sterke noodzaak door een externe factor (bijvoorbeeld stoppen van ondersteuning) of om de doelen van reengineering te bereiken.

a Nee

b 4. Is er personeel getrained in de doeltaal?

c

Nee, maar er is een plan om mensen in te huren of te trainen

Ja

Ja, voor de huidige taal zijn er configuratie management tools, ontwikkel tools, onderhouds tools, analyse tools, en een varieteit aan compilers

6. Zijn er voldoende ondersteunende tools beschikbaar voor de taal die momenteel gebruikt wordt door de software?

a

110

Bijlagen

b Er is een gelimieteerd aantal ondersteundende tools voor de huidige taal. Sommige eventueel inhouse ontwikkeld.

c Nee, er zijn erg weinig tools beschikbaar voor deze taal

a Erg hoog 7. Wat is de portabiliteit van de huidige taal? b Er is portabiliteit maar er zijn routines die niet over te zetten

zijn

c Slecht.

a de taal is geschreven in het meest actuele dialect

b

8. Is de taal die gebruikt wordt door de software geschreven in een verouderd dialect?

c

Er is een mix van dialecten die worden gebruikt

Er wordt gebruik gemaakt van een verouderd dialect.

Data reengineering a Data wordt beheerd door een moderne databestand

organisatie (bijvoorbeeld relationeel of OO)

b

1. Karakteriseer de data bestanden

c

Sommige data wordt beheerd door een modern systeem, andere gebruiken oudere formaten (VSAM e.d.)

Data wordt voornamelijk beheerd door oude systemen (flat file, VSAM, etc.)

a Ja

b

2. Zijn de relaties tussen de data elementen goed gedefinieerd?

c Niet consistent

Data relaties zijn niet duidelijk gedefinieerd of niet goed begrijpelijk

a Minder dan drie jaar

b 3. Hoe oud zijn de data bestanden?

c Drie tot 5 jaar

Meer dan 5 jaar

a 1 tot 3

b

4. Hoe veel verschillende data bestanden zijn er?

c drie tot 5

meer dan 5

a Nee

b

5. Hindert de database de migratie naar een gevanceerdere technologie?

c

Sommige bestanden veroorzaken een probleem

Ja

a Ja

b

6. Worden er data bestanden gebruikt door andere systemen?

c

Ja, maar er zijn maar een of twee bestanden die gedeeld worden door meerdere systemen

Nee, de bestanden die data reengineered moeten worden zijn exclusief voor een enkel systeem.

a Onderhoudafdeling verandert normaliter de bestaande modules

b Onderhoudsafdeling verandert soms bestaande modules, en voegt soms nieuwe toe.

7. Worden er door de onderhouders modules verandert, of worden er nieuwe gemaakt wanneer er nieuwe functionaliteiten komen?

c Onderhoudsafdeling maakt nieuwe modules.

111


a Ja

b

8. Gebruikt de organisatie een standaard data dictionary?

c

Ja, maar wordt niet strict nageleefd en dus niet actueel

Geen standaard data dictionary

a 1 tot 3

b

9. Hoeveel verschillende programma’s zijn er binnen de software?

c 3 tot 7

meer dan 7

a Niet significant, of geen impact

b Minimale impact

10. Wanneer recentelijk reengineered of herontwikkelde software de data bestanden gebruikt, wat is dan de impact op de data bestanen?

c Data bestand is kritiek voor het dosftware en zal veel impact hebben van het reengineering project

Retargeting

a Hoog

b

1. Wat is de portabiliteit van de huidige software taal?

c

Hoog, maar er zijn routines die niet over te zetten zijn

Slecht

a Software is sterk verbonden met een groter systeem

b

2. Is de software stand-alone of is het onderdeel van een groter systeem?

c

Software is verbonden aan een groter systeem, ,maar kan geisoleerd worden met een goede interface

Nee, het is een stand-alone systeem.

a Minder dan 3 jaar oud

b

3. Wat is de leeftijd van het hardware platform?

c Drie tot zes jaar oud

Meer dan zes jaar oud

a Nee

b Niet bekend, of verschillen zijn niet groot en zijn gemakkelijk te onderhouden.

4. Moet de organisatie verschillende duplicaten van dezelfde software aanhouden omdat er versies draaien op verschillende hardware platformen?

c Ja

a Nee

b Nog niet, maar zal binnenkort waarschijnlijk naar CASE tools gaan

c Ja

5. Vereist de nieuwe omgeving het gebruik van CASE tools?

a Nee

b

6. Heeft het huidige hardware platform ernstige operationele fouten?

c Ja, maar niet vaak

Ja

a Ja

b

7. Is er garantie voor de leverancier ondersteuning van het huidige hardware platform?

c

Nee, maar support verlies is onwaarschijnlijk

Nee en dit is een probleem.

112

Bijlagen

a Nee

b Enigzins

8. Limiteert het huidige platform de uitbreiding van de toekomstige ontwikkelactiviteiten?

c Ja, verder uitbreiding, toekomstige ontwikkeling of nieuwe technologische mogelijkheden zijn beperkt door het bestaande hardware platform.

Restructure a minder dan 50

b tussen de 50 en 200

1. Wat is het gemiddeld aantal SLOC (source lines of code) per Computer Software Unit (= kleinste samenhangende eenheid die apart testbaar is.)

c meer dan 200

a minder dan 500

b

2. Wat is het gemiddelde aantal functie punten per CSU?

c tussen de 500 en 2500

meer dan 2500

a tien of minder

b

3. Wat is de gemiddelde cyclomatische complexiteit per module?

c tussen de tien en twintig

meer dan twintig

a vijf of minder

b

4. Wat is de gemiddelde essential complexiteit per module?

c tussen de vijf en tien

meer dan tien

a Strict gehanteerd werd

b

5. De software is ontwikkeld met behulp van een proces dat:

c

Af en toe gevolgd werd

Niet gevolgd werd, of niet bestaat

a strict opgelegd

b

6. De procedure voor het veranderen van software is

c licht opgelegd

ad hoc, of bestaat niet

a weinig of niet significant

b

7. Karakteriseer de verandering van de afgelopen 12 maanden

c gemiddeld

veel

a Onderhoud wordt meestal uitgevoerd door het implementeren van nieuwe modules.

b

8. Is de software onderhoudafdeling betrokken bij het veranderen van modules of het maken van nieuwe modules?

c

Onderhoud gebruikt ongeveer net zo veel nieuwe alsveranderende modules

Onderhoud bestaat meestal uit het veranderen van modules

a Nee

b

9. Is de technologie beschikbaar voor de analyse van de software (complexiteit, FPA, etx.)

c

Weet niet, of is niet volledig beschikbaar

Ja

a Onderhoud man-uren per SLOC is laag en constant 10. Is er behoefte aan meer man-uren per aan te passen SLOC geconstateerd over de afgelopen 2 jaar?

b Onderhoud man-uren per SLOC is langzaam aan het stijgen

113


c Onderhoud man-uren per SLOC is sterk aan het stijgen.

Onderhoudsomgeving 1. Zal de omvang van het onderhoudsteam stabiel blijven?

a Ja

b Er worden kleine veranderingen verrwacht.

c Grote veranderingen staan op punt te gebeuren

a Ja, genoeg voor snel onderhoud en tevreden gebruikers

b Huidig aantal van onderhoudspersoneel is meestal voldoende met soms wat achterstallig onderhoud.

2. Zijn er genoeg onderhoudsprogrammeurs voor de software?

c Nee, er is veel achterstallig onderhoud en ontevreden gebruikers.

a Ja

b

3. Is er voldoende onderhoudspersoneel met veel ervaring met de software?

c

Ja, maar er kan wat vertrekken binnen afzienbare tijd

Nee

a Stabiele groep van onderhoudspersoneel

b

4. Karakteriseer het onderhoudspersoneel verloop per jaar

c Een aantal vertrekken ieder jaar

Hoog verloop

a Ja

b

5. Zin de oorspronkelijke ontwikkelaars beschikbaar voor consult?

c

b) Ja, maar de software is oud of de ontwikkelaars zijn niet gemakkelijk te benaderen.

Nee

a a) Ja 6. Wanneer er onderhoudspersoneel vertrekt, worden deze dan vervangen?

b b) Een zeker natuurlijk verloop is een doel van de onderneming

c c) Nee

a a) Minder duur dan gemiddeld

b

7. Is de software duur te onderhouden in vergelijk met andere software in de organisatie?

c b) Ongeveer gemiddeld

c) Duurder dan gemiddeld

a a) Verbeterend, of naar tevredenheid

b

8. Hoe zien de gebruikers de kwaliteit van de software?

c

b) Blijft het zelfde en is amper tolereerbaar

c) Verslechterend

a a) weinig, als er al fouten worden gevonden

b

9. Karakteriseer de MTBF (mean time between fixes) voor de software. (ofwel: hoe vaak wordt er een fout gevonden)

c b) gemiddeld aantal fouten

c) Veel fouten en een groei na iedere aanpassing

a a) fouten worden snel verholpen 10. Karakteriseer de MTTR (mean time to repair) van de software, wanneer er een fout is gevonden.

b b) fouten worden bij het achterstallig onderhoud gevoegd en binnen een redelijke tijd gefixed

114

Bijlagen

c) het achterstallig onderhoud vereist veel tijd voordat er toegekomen wordt aan de fout die gemeld wordt.

c

115

Bijlagen

Bijlage 5 Renaissance methode

In deze bijlage is een grafische weergave van de Renaissance methode opgenomen. Activiteiten die in de fases naast elkaar staan worden tegelijkertijd uitgevoerd. Wanneer ze met pijlen naar elkaar verwijzen binnen een rechthoek worden ze iteratief uitgevoerd. Een pijl geeft de beheersing en de dataflow aan.

Implementatie Uitrol en gebruik

Bepalen Teststrategie

Voorbereiden Doel

Plan Evolutie

Ontwerpen Doel

TestTrans-

formeer

Documenteren herziene

bedrijfs-proces

In gebruik name

Opleiden beheerders

Vervangen Legacy systeem

Planning Evolutie

Beschrijven Bedrijfsproces

Startup Methode

Analyse huidige situatie

Context Legacy

Modelleren

Doel Selecteren

Context Modelleren

Planning Evolutie

Plannen van uitrol

Installeren Systeem

Migreren van Data

Acceptatie testen

117

Bijlagen

119

Bijlage 6 COCOMO 2 Factoren en inschaling

In deze bijlage zullen de verschillende COCOMO factoren en hun waardering worden besproken. In onderstaande tabel is een overzicht gegeven van de waardering van de bestaande code. Deze factor is binnen de COCOMO vergelijking de SU factor. Heel Laag Laag Nominaal Hoog Heel Hoog Structuur Samenhang

minimaal, Hoge koppeling, spaghetti-code

Lage samenhang, hoge koppeling

Redelijk gestructureerd, enkele zwakke plekken

Hoge samenhang, lage koppeling

Sterke modulariteit, information hiding in de data en beheersstructuren

Applicatie duidelijkheid

Geen aansluiting tussen programma en applicatie view

Enige correlatie tussen programma en applicatie view

Gemiddelde match tussen programma en applicatie view

Goede correlatie tussen programma en applicatie view

Heldere en duidelijke match tussen applicaite en programma.

Zelf beschrijvendheid

Slechte code, documentatie mist, onduidelijk of weg.

Enkele commentaren en headers, iets aan documentatie

Redelijke documentatie, code commentaren en headers

Goede code commentaren, goede headers, enkele zwakke plekken

Zelf beschrijvende code, documentatie is actueel, met ontwerp verklaringen

SU tov AAF 50 40 30 20 10

Er is ook een factor die meegenomen moet worden voor de aanpassingen. Dit is de factor AA: AA Optelling Niveau van AA inspanning 0 Geen 2 Basis module zoeken en documentatie

4 Module testen en evaluatie, documentatie 6 Behoorlijke module test en evaluatie, documentatie

8 Uitvoerige module test en evaluatie, documentatie

De factor UNFM (bekendheid met de software) kan als volgt geschaald worden: Bekendheid Factor Compleet bekend met de applicatie 0.0

Grotendeels bekend met de applicatie 0.2

Enigzins bekend met de applicatie 0.4 Weinig bekend met de applicatie 0.6

Grotendeels onbekend met de applicatie 0.8 Volledig onbekend met de applicatie 1.0

Bijlage 7 Verwerking invloedsfactoren Tilley (1995)

In de onderstaande lijst zijn de invloedsfactoren opgenomen die zijn onderkend door Tilley (1995), en hun verwerking in het verslag. Invloedsfactor Verwerking Proces

Rapid Prototyping van de interfaces in de eerste stadia van vereisten-filtering en validatie fase is een grote aanwinst in het snel verkrijgen van gebruikersgoedkeuring van de mogelijkheden en capacatiteiten van het reengineerde systeem.

Toegevoegd aan activiteitenplanning

Onderhoudspersoneel heft een grote bekendheid met het system en zijn de primaire bron van kennis van het system. De tijd die ze moeten opbrengen zal groot zijn en dit zal een impact hebben op hun routine en productiviteit

Toevoegevoegd aan de projectplanning en eventueel als risico/

Een van de meest onderschatte aspecten van reengineering is het uitrollen en overzetten van het systeem naar operationeel gebruik. Upward compatibiliteit wordt ook meestal aangepakt op ad hoc basis en wordt niet adequaat aangepakt.

Toegevoegd aan toekomstige architecturen.

Toevoegevoegd aan de planning bij de keuze voor doelarchitectuur en eventueel als risico.

Het is erg moeilijk om planningen te maken voor reengineering projecten, wanneer er veel leertijd voor nieuwe producten en platformen mee gemoeid is. Het kan gemakkelijk drie keer de verwachte tijdschattingen overschrijden. Het management moet het risico willen accepteren en door willen zetten met continue ondersteuning om resultaten te verkrijgen.

Nieuwe functionaliteit toevoegen is een belangrijke motivatie voor reengineering. Fout correctie is meestal niet voldoende motivatie om te reengineeren. Andere redenen die genoemd worden voor reengineeirng zijn performance problemen, schaalbaarheidsissues, en overbodigheid van het systeem

Reengineering is gesteld als proces zonder nieuwe functionaliteiten. Ook onderkent door Sneed. Toegevoegd aan planning van traject.

“Requirements creep” komt altijd voor. Iedere nieuwe functioneel eis vergroot de complexiteit en schroeft de kosten omhoog. Het project plan moet voorzien in deze ‘mid-course’ aanpassingen.

Toegevoegd aan flexibiliteit van projectmanagement, ook RMM voorziet hierin.

Kritieke succesfactoren zijn (naast conformiteit met gebruikers wensen) een betere performance en functionaliteit, geen nadelige impact voor de gebruikers, en een hogere klantwaarde dan mogelijk door een nieuwbouw traject. De technologie basis van de gebruikers heeft een grote impact op de vereisten voor een reengineeringinspanning.

Meegenomen in planning, kosten, risico’s, technologiebasis meegenomen bij impact toekomstige architecturen

Er is geen consensus op wat voor documentatie idealiter bij het gereengineerde system moet worden opgenomen, of wat een minimale documentatie is.

Toegevoegd aan activiteitenplanning

Technologische evolutie kan het complete legacy systeem overbodig maken. Het is belangrijk om de infrastructuur van de gebruikers te begrijpen, zodat voorkomen wordt dat een non-relevant legacy systeem gereengineered wordt.

Reeds meegenomen in activiteitenplanning.

Het meest uitdagende probleem van alle is hoe er omgegaan zou moeten worden met constant onderhoud en verbeteringen aan het legacy systeem, terwijl het gelijktijdig gereengineerd wordt.

Reeds meegenomen in migratie strategieen.

De helft van de inspanning die besteed wordt aan reengineering gaat in de documentatie zitten. De moeilijkheid zit er in om de drie verschillende views op het systeem (architectureel, functioneel en code) samen in coherente en gesynchroniseerde manier bij elkaar te houden.

Wordt niet meegenomen, mogelijkheden voor automatische documentatie is reeds mogelijk. Functionele documentatie neemt naar alle waarschijnlijkheid geen siginificant deel van de tijd in.

Kostenmodellen

Het schatten van de kosten en planning voor het reengineeren van een systeem is een non-triviale taak. Een diepte analyse van het reengineering systeem is vereist voor het plannen van een reengineering inspanning en productiviteit.

Reeds meegenomen door voorstellen kosten methoden, behandeling tool-support. Vervalt.

18 april 2005 Pagina 121 van 157


Toegevoegd aan model, bij kostenschattingen.

Kosten modellen voor reengineering falen over het algemeen om de totaliteit van systeem elementen mee te nemen. (software ontwikkel omgevingen, integratie test omgevingen, simulatie faciliteiten, logistieke ondersteuningsfaciliteiten, nieuwe systemen deployment, etc). Deze elementen hebben meestal ook significante reengineering inspanning nodig en spelen een grote rol in de reengineering afweging en in het beslisproces

Reengineering projecten moeten voorzien worden van resources, maar niet alleen voor het omzetten van legacy code, maar ook voor het testen en een periode van beide activiteiten. Projecten moeten ingepland worden voor voldoende tijd, inspanning en uitrustuing voor deze voorwaarde.

Is reeds meegenomen door testrisico Sneed.

Belangrijke software en project metrieken die voor nieuwbouw gelden, zijn anders dan die voor onderhoud en ook weer anders dan die ovor reengineering trajecten. Er moet goed gekeken worden naar de jusite set van metrieken die bruikbare performance indicatorren opleveren.

Toegevoegd bij de kostenschattingen.

Toegevoegd bij de kostenschattingen. Het is erg risicovol om metrieken tussen organisaties onderling te vergelijken. Verschillende applicatie domeinen en verschillende technologische infrastructuren maken een vergelijking in getallen niet bruikbaar. Elke organisatie moet zijn eigen metrieken en data vergaren en op deze manier huidige performance met vorige performance meten.

Risico’s

Testen kan veel tijd in beslag nemen van het onderhoudsproces, mede omdat er een noodzaak is om het gehele systeem te testen na iedere ‘kleine’ verandering. Ook hebben ze proportioneel meer tijd nodig voor testen dan nieuwbouw projecten.

Is reeds meegenomen door testrisico Sneed (1999)

Toegevoegd aan risico’s Sommige karakteristieken van de legacy code kunnen in eerste instantie onschuldig lijken, maar blijken later ‘show-stoppers’ en kunnen het succesvolle reengineering van een systeem in de weg staan. Specifieke voorbeelden zijn het gebrek aan data-scheiding en het gebrek aan documentatie van het berichtenverkeer

Toegevoegd aan risico’s De meeste reengineering inspanningen gaan uit van een reengineering oplossing, in de zin dat het geen integral onderdeel is van een evolutionair ontwikkelingsproces. Bij het opleveren van het systeem, kan het zijn dat het nieuwe systeeem niks beter is dan het legacy systeem. Het enige wat er dan gewonnen is is beter begrip van het systeem.

Het overzetten van nieuwe technologieen die gebruikt zijn bij reengineering, naar de onderhouds organisatie is moeilijk. Men moet hier veel weerstand verwachten.

Is reeds meegenomen door weerstand risico van Sneed (1999)

Tools

Er zijn bruikbare ge-automatiseerde tools die kunnen assisteren in het navigeren door de legacy code om structurele informatie eruit te halen, om executiepadne langs te lopen en taalconversie te doen. Er zijn echter geen ‘silver bullets’.

Toegevoegd aan impact van tools op reengineering.

Is reeds meegenomen bij risico Performance verlies van Sneed (1995), ook specifiek toegevoegd bij impact van tools op reengineering

De meerderheid van projecten die gepoogd hebben om een vertaling naar een andere taal te realiseren, hebben beperkt succes geboekt. De meest voorkomende reden is dat vertaal tools niet de mogelijkheid hebben om de hoog-niveau heuristieke constructies die toepasbaar zijn voor een taal te vertalen naar een andere. De resultaten zijn vaak niet naar tevredenheid vanuit leesbaarheid, performance, en andere kwaliteitsfactoren.

Idiosyncratische onderdelen van de legacy (OS, compilers, dbms, communicatie faciliteiten, etc.) zijn erg lastig voor bestaande tools om mee om te gaan. Derhalve dient er rekening gehouden te worden met extra handmatige conversie en bekendheid met de omgeving en doeltechnologie.

Toegevoegd aan impact van tools op reengineering

Er zouden objectieve waarderingen, metingen, analyses en evaluaties gemaakt moeten worden van de legacy code en andere artifakten. Verschillende tools bestaan er om hiervor zinnige informatie te ontrekken. De overweging reengineering vs. Nieuwbouw zou op basis hiervan genomen moeten worden.

Reeds meegenomen in impact van tools op reengineering

Verstandig gebruik van tools en technologie in het doelsysteem kan een effectieve impact hebben op reengineering. COTS tools en technologieen zijn echter maar middelen en geen wonderen.

Reeds meegenomen als ‘silver bullet’ punt.

122

Bijlage 8 Risicofactoren door verschillende auteurs

In deze bijlage zijn de risico’s verzameld die door de verschillende auteurs benoemd zijn.

Rosenberg (1996) Bergey (1999) Warren (1999) Sneed (1999)

Extreem hoge handmatige reengineering kosten

Kosten baten niet gerealiseerd in tijdspanne

Re-engineering inspanning verschuift

Gebrek aan management commitment voor voortdurende reengineering inspanning

Subsystemen zijn verkeerd gekozen voor de reengineering benadering.

Inadequaat configuratie management

Gebrek aan kwaliteit verzekering

Gebrek of geen metrieken programma.

Reengineering zonder lokale applicatie experts.

Reengineered systeem werkt niet naar behoren

Massa’s dure documentatie wordt geproduceerd.

Reengineering technologie is inadequaat voor het bereiken van de doelen.

Legacy functionaliteit raakt achterhaald voor de reengineering inspanning is afgerond.

Taal is niet ontworpen om de abstracte informatie weer te geven die nodig is voor de vereisten en ontwerp specificaties.

Moeilijk om veel ontwerp en requirements te verkrijgen uit de code.

Objecten worden incompleet of verkeerd vastgelegd.

Bestaande bedrijfskennis die vastgelegd is in de broncode, raakt verloren

Achterhaalde information is niet bruikbaar of wordt niet gebruikt.

Er is geen sprake van een apart ‘reengineering process’

Er is een inadequate planning of gebrek aan discipline om de plannen te volgen.

Management maakt van tevoren technische beslissingen.

De organisatie heeft het legacy systeem niet onder controle.

Het team wordt verplicht met oude technologieen en niet afdoende trainingen te werken.

Software architectuur wordt niet als primair onderdeel van reengineering meegenomen.

Te weinig filtering en validatie van de vereisten.

De organisatie maakt op een verkeerde manier gebruik van consultants en externe partijen (laat het over aan externe experts)

De organisatie neemt onnadenkend een slechte of incomplete strategie.

Management heeft geen lange termijn commitment

Achterhaalde/overbodige operationele omgeving.

Systeem voldoet niet aan evolutie vereisten

Vertrek van ervaren onderhoudspersoneel

Gebrek aan kunde voor doel technologie.

Gebrek aan kennis van het systeem

Onvoorstelbare doelsysteem performance

Onvolwassen technologie voor het doelsysteem

Operationele organisatie is niet verbonden aan training

Verlies van interne business rules

Inadequate of inconsistente documentatie

Fouten introduceren tijdens evolutie

Gebrek aan tool ondersteuning

Project vertragingen door mismatch in architectuur

Project vertragingen door test bottlenecks en gebrek aan test data

Het falen in het behalen van kwaliteitsdoelen, door slechte definieering van deze doelen

Verwerpen van de resultaten door de programmeurs bij de klant.

Performance loss bij het migreren naar een andere omgeving of programmeertaal


Nieuwe vereisten en functionaliteit wordt toegevoegd.

Vastgelegde objecten integreren niet in het nieuwe system.

Moeilijkheden met het migreren van de bestaande legacy data.

Mate van voorbereiding en reverse engineering is onvoldoende.

Personeel zonder juiste competenties en ervaring in reengineering.

Programmeurs die minder effectief werken om een onpopulair reengineering project minder effectief te laten lijken.

Afhankelijkheid van tools die niet werken zoals beloofd.

Tools zijn nieuw, onvolwassen, en hebben vaak incomplete functionaliteit.

Volwassenheid en stabiliteit van de toolverkoper en de toolkwaliteit.

Voorbarige commitment voor een reengineering oplossing voor een volledig system.

Het niet hebben van lange termijn visie met tussendoelen.

Breekbare, onrealistische doelen

Aanpak die gekozen is, sluit niet aan bij bedrijfsdoelen, budget of planning.

Geen plan voor het gebruiken van reengineering tools.

uw bij Centric – Onderzoek naar een projectaanpak voor reengineering

124

Vernieuwbo

Vernieuwbouw bij Centric – Een onderzoek naar de projectaanpak voor reengineering

Bijlage 9 Stappenplan Iterative Reengineering

Onderstaand zijn de stappen en samenhang opgenomen van de iterative reengineering aanpak. Stappen: 1. Analyseer het legacy systeem; het systeem wordt in componenten opgedeeld om te veranderen,

waarbij in ogenschouw wordt gehouden dat er zo min mogelijk afhankelijkheden per component worden gehouden.

2. Klassificeren van data; de data wordt geanalyseerd en geinterpreteerd. Aan het eind van deze fase is er een overzicht van de verschillende data, welke soort data, enzovoort.

3. Herontwerpen van de database; op basis van de voorgaande fase wordt gekeken welke data opgenomen moet worden in de nieuwe database, welke in de tijdelijke database en welke data als metadata opgeslagen moet worden.

4. Herstellen Legacy Componenten; de programma’s worden compatible gemaakt met de gereengineerde data. Hierom moeten alle instructies die data benaderen geevalueerd moeten worden gekoppeld aan de databanker.

5. Migreren van de data; op basis van het herontwerp van de database wordt de data gemigreerd naar de nieuwe en tijdelijke database.

6. Reengineer procedures; In deze fase worden de herstelde componenten omgezet naar reengineerde componenten. Hier wordt de daadwerkelijke kwaliteit verbeterd van de verschillende componenten.

7. Equivalentie testen; in deze stap wordt gekeken of het verbouwde systeem dezelfde functionaliteiten heeft, als het oude systeem. Deze stap is benodigd na het herstellen van componenten, reengineeren van componenten en het migreren van de data.

8. Legen van de tijdelijke DB; data die niet meer benodigd is door herstelde of legacy componenten uit de tijdelijke database, kan verwijderd worden wanneer de data in het nieuwe systeem zit.

9. Itereren; wanneer de iteratie succesvol is verlopen kan er vervolgd worden met een nieuwe iteratie. 10. Opschonen metadata; Als het gehele systeem is gereengineerd, kan de metadata opgeschoond

worden van alle data die gerelateerd is aan het tijdelijke en legacy systeem. 11. Reconstrueren Documentatie; aan het eind van het proces kan de documentatie gecreeerd en

geupdate worden. In onderstaand figuur zijn deze stappen opgenomen in hun onderlinge context.

Analyseren Legacy Systeem

Classificeren Data

Herontwerpen Database

Herstellen Legacy Componenten Migreren Data

Equivalentie Testen

Equivalentie Testen

Reengineer Procedures

Legen Tijdelijke Database

Opschonen MetadataReconstrueren Documentatie



Bijlage 10 Verwerking Risico’s onderkend bij SBA voor risico-lijst.

Onderstaand zijn de risico’s opgenomen vanuit het projectplan van SBA, en de verwerking hiervan in de risicolijst van de enquête. De risico’s zijn geclassificeerd als niet specifiek reengineering risico, wanneer er sprake was van een algemeen projectrisico (bijvoorbeeld organisatorisch risico) of een risico dat ook van toepassing zou kunnen zijn bij een nieuwbouw project. Aangezien deze risico’s niet specifiek voor reengineering gelden, worden deze niet meegenomen in de enquête. Wanneer het risico al in de lijst met risico’s staat opgenomen, wordt er verwezen naar het risico dat al in de enquête is opgenomen

Risico Opgenomen in

Belang van de projectorganisatie strookt niet met het belang lijnorganisatie; Niet specifiek reengineering probleem

Overlap in verantwoordelijkheden binnen de projectorganisatie; Niet specifiek reengineering probleem

Het risico bestaat dat de reconstructie uitloopt, waardoor het project niet tijdig klaar is. Niet specifiek reengineering probleem

Het risico bestaat dat de reconstructie te veel beïnvloedt wordt door het europroject, waardoor extra vertraging ontstaat.

Niet specifiek reengineering probleem

De PAS projecten zoals Euro en overname portefeuille V.V.A.A. (Vereniging Van Artsen Automobilisten) zijn bij het aanbreken van fase 2 (op het moment dat de “overige”aanpassingen van PAS in de “wacht” gezet moeten worden) nog niet af.

Niet specifiek reengineering probleem

Het risico bestaat er tijdens de ontwikkeling van RePAS nog te veel wijzigingen in PAS worden aangebracht, die in RePAS overgenomen moeten worden.

Toegevoegd

De onduidelijkheid omtrent het gebruik van spread-sheets naast de reguliere productie, waardoor retro-analyse van PAS niet volledig mogelijk zal zijn;

Toegevoegd

De analyse of de af te scheiden ‘overige niet te wijzigen code’ herbruikbaar is in het nieuwe gereconstrueerde PAS;

Reeds in lijst (mismatch architectuur)

Toegevoegd De productmodellering loopt nog door gedurende de eerste maand van fase 2 (tot begin mei). Het risico bestaat dat door de intussen verdergaande productmodellering reeds uitgevoerde aanpassingen geheel of gedeeltelijk opnieuw gedaan moeten worden.

Reeds in lijst (Ontevreden over performance)

Het risico bestaat dat de performance van het nieuwe op componenten gebaseerde en via tabellen gestuurde systeemmodel onvoldoende is voor gebruik in een productieomgeving.

Reeds in lijst (Ontevreden over performance)

Het uniformeren van software kan onbedoeld een negatieve invloed hebben op de responsetijden. Bij selectie van het onderliggend platform kan hier al rekening mee gehouden worden, en enige reserve ingebouwd worden. Verder zal per specifiek geval geanalyseerd worden hoe en met hoeveel energie de performance verbetert kan worden.

Het tijdig beschikbaar hebben van de gegevens die door de deelprojectgroep verrijking en de deelprojectgroep conversie geleverd moeten worden;

Toegevoegd bij proces (activiteiten)

Geen specifiek reengineering risico. Wordt toch meegenomen vanwege aanbeveling literatuur. Staat hierom reeds in lijst (test-bottlenecks)

Als SBA geen of niet tijdig testsets kan aanleveren bestaat het gevaar dat pas in het teststadium door SBA allerlei problemen geconstateerd worden die, indien ze in het ontwikkelstadium worden geconstateerd, minder tijd vergen om aan te passen. Een testset is zinvol voor de test bij WALVIS teneinde te verifiëren of de toepassing voldoet aan het verwerken van op een productiesituatie gebaseerde gegevens. Dit punt zal vooral invloed hebben op de kwaliteit van het gerealiseerde systeem en de doorlooptijd van de nazorgfasen.

De (on)mogelijkheid de inspanningen van WALVIS en SBA zonodig op te schalen om de onderkende fasen tijdig te realiseren;

Niet specifiek reengineering risico

Onvoldoende beschikbaarheid van resources (kwaliteit en kwantiteit); Niet specifiek reengineering risico

Persoonsgebonden kennis; Reeds in lijst (kennis doel en bestaand systeem)

Levering en implementatie van de infrastructuur; Niet specifiek reengineering risico

(Nog) niet onderkende fouten (bugs) in nieuwe technologie (hard- en software); Reeds in lijst (doeltechnologie niet volwassen)

Als de (tussen)versies niet tijdig door SBA beoordeeld en goedgekeurd kunnen worden en de realisatie wordt in verband met de voortgang toch voortgezet bestaat het risico dat tijdens de realisatie naar aanleiding van de (te late) beoordeling nog allerlei (structurele) aanpassingen met terugwerkende kracht doorgevoerd moeten worden.

Niet specifiek reengineering risico



Bijlage 11 Afwijking theoretisch model in enquête / interview

In deze bijlage wordt ingegaan op de verschillende afwijkingen die in de enquête en interview zitten ten opzichte van het theoretisch kader. Dit wordt per onderdeel hieronder toegelicht: Kosten Factor SU: is niet meegenomen: is af te leiden uit de productkwaliteit (structuur = code kwaliteit, Applicatie duidelijkheid = architectuur kwaliteit, zelfbeschrijvendheid = up-to-date documentatie) Factor UNFM is niet meegenomen: is af te leiden uit de bekendheid met het legacy product. Risico’s: De volgende risico’s zijn weggelaten uit de enquête omdat het antwoord een vertekend beeld zou kunnen geven van de daadwerkelijke realiteit van het risico: - Volwassenheid en stabiliteit van de toolverkoper en de toolkwaliteit./ Afhankelijkheid van tools die

niet werken zoals beloofd. (De tools zijn gemaakt door Walvis zelf, dus vraag is niet relevant en de antwoordbetrouwbaarheid wordt laag ingeschat.)

- Programmeurs die minder effectief werken om een onpopulair reengineering project minder effectief te laten lijken. (Betreft de onderhoudsprogrammeurs van de klant. Aangezien Walvis de applicatie reeds onderhield, is deze vraag niet meer ter zake doende.)

- Fouten introduceren tijdens evolutie - Verwerpen resultaten door de programmeurs van de klant. - Personeel zonder juiste competenties en ervaring in reengineering

Geen mogelijkheid om te vragen aan de programmeurs zelf, vanwege antwoordbetrouwbaarheid -> Wel aan projectleider

(Deze risico’s worden hierom niet binnen de prioritering betrokken en zullen apart genoemd blijven) De volgende risico’s zijn alleen voorgelegd aan de projectleider, omdat de impact hiervan niet voldoende te bepalen is door de projectleden. Hierbij is aangenomen dat de projectleden niet op de hoogte waren van de belangen, werking en sturing van de organisatie van de opdrachtgever.

Personeel zonder juiste competenties en ervaring in reengineering Gebrek aan management commitment voor voortdurende reengineering inspanning Management maakt van tevoren technische beslissingen. Het niet hebben van lange termijn visie met tussendoelen. Aanpak die gekozen is, sluit niet aan bij bedrijfsdoelen, budget of planning. Breekbare, onrealistische doelen Voorbarige commitment voor een reengineering oplossing voor een volledig systeem. De organisatie neemt onnadenkend een slechte of incomplete strategie.



Bijlage 12 Enquete opzet en Interviewlijsten medewerkers SBA

Interview Portfolio Analyse en Reengineering Assesment 1. Hoe is de keuze voor vernieuwbouw ontstaan?

Is er een afweging gemaakt tussen de technische waarde van de applicatie en de bedrijfswaarde van de applicatie?

Hoe is deze technische waarde bepaald? Heeft het BIS hier een rol in gehad? Is hiervoor een checklist gehanteerd?

Hoe is de bedrijfswaarde geëvalueerd? Is hiervoor een checklist gebruikt? Langslopen van de Portfolio Analyse en Reengineering Asssement vragen met projectleider. Migratie 1. Wat is het onderscheid geweest tussen de WFM groep en de Walvis groep voor ontwikkeling? 2. Is er een aanpak gebruikt om stapsgewijs over te gaan of in een keer?

In het geval van een Big Bang overgang: Is het traject hierdoor minder beheersbaar geweest? Hoe stonden de gebruikers tegenover de plotse overgang?

3. Het overzetten van de data heeft eerst plaatsgevonden. Hoe is dit aangepakt?

Welke mijlpalen zijn er onderkent? In welke mate is het incrementeel doorgelopen? Is er een tool gemaakt als conversie programmatuur? Is de database geleidelijk afgebouwd en opgebouwd? Voor welke stappen zijn applicaties ontwikkeld?

Kostenschatting Langslopen calculatiemodel vragenlijst CBA (variabel voor en na = omvang & kwaliteit) 1. Hoeveel functiepunten of SLOC of andere grootheid besloeg de applicatie? 2. Zijn er besparingen opgetreden op de volgende gebieden:

Besparing van tijd en inspanning per onderhoudstaak? (door beter begrip) Besparing door senior personeel te vervangen naar junior personeel? (door beter begrip) Besparing door beperking van tijd die fouten in beslag nemen?? (downtime) Besparing van kosten voor personeel inhuur en training van nieuw personeel. Lagere kosten van verloren kansen, doordat capaciteit vrijgemaakt wordt van onderhoudsafdeling Lagere kosten van nieuwe ontwikkelingen door flexibele basis.

Tools Impact Analyse middels BIS

Wat hield deze impact analyse precies in? Zijn hier ook risico’s mee geconstateerd / aangepakt? is deze impact analyse gestructureerd, of is deze gedaan op een expertmanier (dwz. Niet

automatiseerbaar) Is deze analyse in het vooronderzoek gedaan, of pas tijdens fase 2? Is de impact de uiteindelijke inspanning geweest? (maw was de inspanning juist?) Waar heeft deze afgeweken ?

Zijn de tools ontwikkelt tijdens het project? Zijn de kosten hiervan verhaalt op het project? Zijn er tijdsbesparingen gemeten van de tools?

Voor elk deelproject is een ontwerp gemaakt, maar is er ook gekeken naar het automatiseren van conversie en het maken van testtools. Zijn hier nog generieke tools uitgekomen, of zijn deze alleen maar inzetbaar geweest tijdens een betreffend deelproject?

Risico’s



Voornaamste risico’s langslopen en bepalen of deze bewust zijn voorkomen: Performance Loss; (heeft zich voorgedaan, hiervoor zijn nog aanpassingen gedaan) Vertraging door mismatch in architectuur; specifiek hiervoor is MTS ingezet Test bottlenecks en gebrek aan testdata; gedeelte verantwoordelijkheid is afgestaan aan opdrachtgever,

daarnaast was er een aparte testgroep Geen definiëring van doelen in termen van kwaliteit; Resultaat verworpen door programmeurs bij de klant; geen programmeurs bij de klant (was Walvis zelf)

Enquete Werkstijl gedurende SBA Project Onderstaand zijn een aantal paren opgenomen die tegenover elkaar staan. Wanneer u de linker waardeert als kenmerkend voor de werkstijl tijdens het project, zet dan een kruisje links. Vind u de rechter beter passen bij de werkstijl, zet dan een kruisje rechts. Wanneer u geen van beide van toepassing vind, zet dan een kruisje in het midden.

1 Zorgvuldig Slordig

2 Vastgelegde procedures Ad hoc procedures3 Regels werden in acht genomen Regels werden zelden in acht genomen

4 Ordelijk Ongeordend5 Strenge werkdiscipline De kantjes werden er vanaf gelopen

6 Discreet Indiscreet7 Alles werd gecontroleerd Niets werd gecontroleerd

8 Vastberaden Aarzelend9 Veel sturing Geen sturing

10 Adequate overlegstructuren Inefficiënte overlegstructuren11 Grote saamhorigheid / teamgeest Geen saamhorigheid

12 Doelgericht Afwachtend13 Goede organisatie Chaotische organisatie

14 Snel / vlot Traag

De volgende project hulpmiddelen zijn in ieder geval ingezet tijdens het SBA project. Zou u de bijdrage aan het projectsucces per hulpmiddel kunnen geven op een vijfpuntschaal (1 = weinig, 5 = veel). Ook is er de mogelijkheid om zelf een hulpmiddel toe te voegen2 , aangevuld met de bijdrage aan succes van dit hulpmiddel. Onderdeel 1 2 3 4 5 Weinig Veel Planning

Begroting Voortgangsrapportages

Risico analyse ………………………………………………….

………………………………………………….

Product van SBA project

2 Mogelijke hulpmiddelen zijn bijvoorbeeld: brainstormen, probleem analyse, sterkte/zwakte analyse, formeel startschot, PERT/ GANT charts, besluitvormingsmethodiek, et cetera.

132


Onderstaand staat een tabel met eigenschappen van software. Hierbij staat de kwaliteit aangegeven van 1 (slecht) tot 5 (goed). Zou u deze tabel in kunnen vullen voor de situatie zoals de PAS software was, voor de reconstructie?

Nr. Onderdeel 1 2 3 4 5 Slecht Goed

1 Architectuur inzichtelijkheid / kwaliteit PAS 2 Code inzichtelijkheid / kwaliteit PAS

3 Up-to-date Documentatie PAS 4 Database structuur kwaliteit PAS

Zou u dezelfde gegevens kunnen ingeven voor de eigenschappen van de software na afloop van het project, oftewel van de RePAS applicatie? Nr. Onderdeel 1 2 3 4 5 Slecht Goed 1 Architectuur inzichtelijkheid / kwaliteit PAS

2 Code inzichtelijkheid / kwaliteit PAS 3 Up-to-date Documentatie PAS

4 Database structuur kwaliteit PAS

Zou u voor de onderstaande kennis over het PAS systeem kunnen aangeven in welke mate deze kennis bij de start van het project aanwezig was? (1 = volledig afwezig, 2 = volledig aanwezig) Nr. Onderdeel 1 2 3 4 5 Afwezig Aanwezig 5 Kennis van de applicatie architectuur in de

organisatie

6 Kennis van de applicatie code van PAS in de organisatie

Waren hiernaast de oorspronkelijke ontwikkelaars van het PAS systeem nog aanwezig in de organisatie? Ja Nee

7 Oorspronkelijke ontwikkelaars van PAS aanwezig

Hoeveel jaren ervaring had u bij de start van het project met betrekking tot: Nr. Onderdeel Jaren

ervaring9 Architectuur algemeen 10 Architectuur : Component Based Development

11 Programmeren algemeen 12 Programmeren Progress

13 Database algemeen 14 Database specifiek Progress

Kennis bestaande systeem In welke mate was u reeds bekend met de bestaande PAS software, bij SBA? (slechts 1 antwoord mogelijk) Mate van bekendheid



Compleet bekend met de applicatie

Grotendeels bekend met de applicatie Enigzins bekend met de applicatie

Weinig bekend met de applicatie Grotendeels onbekend met de applicatie

Volledig onbekend met de applicatie Gebruik van vernieuwbouw tools Onderstaand zijn een aantal methoden opgenomen die helpen om begrip te verkregen van een bestaande applicatie. Zou u op basis van uw ervaringen met het SBA project, per methode kunnen aangeven in welke mate deze methode zou kunnen bijdragen aan de begripsvorming van een onbekende applicatie? (1 = erg weinig, 5 = erg veel) Nr. Onderdeel 1 2 3 4 5 Weinig Veel

Code Begrip 1 Begrippen onttrekken; het vinden en ontdekken van elementen

en de relatie tussen deze elementen. Hieronder vallen bijvoorbeeld procedures, functies, tabellen, etc.

2 Statische analyse; het parsen van de broncode van applicaties om een variëteit aan gegevens te kunnen verkrijgen. Hieronder vallen call-graphs, data en control flows, etc.

3 Dynamische analyse; analyse methoden die de programma uitvoering in productie of simulatie waarnemen.

4 Slicing; Statements die relevant zijn voor een berekening worden geselecteerd en samengevoegd vanuit de gehele applicatie.

5 Semantische en gedrags patronen-matching; Deze techniek wordt gebruikt om dynamisch gedrag te achterhalen. Patronen worden geïdentificeerd door code componenten te ontdekken die een specifieke data-flow, control-flow of dynamische(executie gerelateerde) relaties delen.

6 Redocumentation; betreft het maken van tekstuele vormen van de code, bijvoorbeeld pseudo-code. Kan echter ook worden vormgegeven als gelinkte teksten, webpagina’s en grafische weergaven van de systeem artefacten.

Functie begrip 7 Plan herkenning; programma plannen zijn abstracties van

broncode fragmenten. Deze broncode fragmenten kunnen worden herkend als gelijksoortig (door het herkennen van programmeertaal constructies). Deze code kan dan geconsolideerd worden.

8 Aggregatie hiërarchieën: deze hiërarchieën worden gemaakt door vanuit de code elementen aan elkaar te koppelen. Hierdoor kunnen er objecten geidentificeerd worden en kunnen deze in een hiërarchie geplaatst worden.

9 Refactoring; is het proces van code naar code conversie, waarbij het externe gedrag hetzelfde blijft, maar de interne code herstructureert wordt.

134



Architectuur begrip

10 Structurele Patronen Koppelen; Bestaande ontwerp patronen worden tegen de code patronen aangelegd, die verkregen zijn met statische analyse. Hierdoor kunnen bijvoorbeeld module afhankelijkheden gevonden worden, die niet gevonden kunnen worden door statische code analyse.

11 Concepten toekennen en redenatie; betreft het vinden van mens georiënteerde concepten in een programma. Dit kan uitgevoerd worden door stukken code te koppelen aan een concept in het applicatie domein. (bijvoorbeeld een stuk code koppelen aan het concept ‘Afsluiten van een verzekeringspolis’)

12 Architectuur & Structuur Identificatie; het verkrijgen van een representatie van de huidige architectuur.

Zou u kunnen aangeven in welke van deze bovenstaande methoden de tool BIS in voldoende mate heeft bijgedragen? Nummers:

Zou u kunnen aangeven in welke van deze bovenstaande methoden de tool MTS in voldoende mate heeft bijgedragen?

Nummers: Inspanning De volgende factoren geven een inzicht in het verschil dat is opgetreden van de overgang van PAS naar RePAS. Voor een nieuwbouw project zouden deze percentages 100% zijn. Zou u een schatting van deze percentages voor het SBA project kunnen geven? Onderdeel Percentage Percentage code dat aangepast is Percentage ontwerp dat aangepast is

Het percentage inspanning dat vereist is voor het integreren van de aangepaste software in een geheel product en het testen hiervan.

Het hergebruik van code zorgt ook voor een extra inspanning. Deze inspanning betreft het evalueren van verschillende code onderdelen (modules) voor het integreren in de totale applicatie. Ook het documenteren hiervan ten behoeve van de totale applicatie speelt hierin een rol. Zou u in onderstaande tabel de optie die het meest van toepassing was voor het SBA project willen aanvinken? Niveau van evaluatie inspanning

Geen Modules zoeken en documentatie verzorgen

Module testen en evaluatie, documentatie verzorgen Behoorlijke module test en evaluatie, documentatie verzorgen

Uitvoerige module test en evaluatie, documentatie verzorgen


Belang van situaties Onderstaand zijn een aantal situaties opgenomen die een positieve invloed kunnen hebben op een project. Wanneer een situatie zich tijdens het SBA project heeft voorgedaan, kan u een kruisje in de ‘ja’ kolom zetten, wanneer het zich niet heeft voorgedaan in de ‘nee’ kolom. Wanneer de situatie zich heeft voorgedaan, kan u het daadwerkelijke belang (mate van positief effect) voor het project op deze schaal aangeven en de verwachte waarschijnlijkheid (de kans dat het van toepassing is) voor een vernieuwbouw project. Wanneer de situatie zich niet heeft voorgedaan, zou ik graag een schatting krijgen van het door u verwachte belang en verwachte waarschijnlijkheid van dit belang. De schaal verdeling voor zowel belang als waarschijnlijkheid is: (1 – Heel klein, 2 – Klein, 3 – Gemiddeld, 4 – Groot, 5 – Heel groot) Nr. Belang SBA

voorgedaan Mate van belang Waarschijnlijkheid

Ja Nee 1 2 3 4 5 1 2 3 4 5

Klein Groot Klein Groot

I (Projectmanagement) 1 Er is een goed ingericht configuratiemanagement 2 Er is een goede kwaliteitsborging of bewaking 3 Er wordt gebruik gemaakt van een metriekenprogramma 4 Vernieuwbouw wordt uitgevoerd met behulp van de lokale applicatie experts 5 Er is een goede definieering van de kwaliteitsdoelen 6 Er is een adequate planning voor het project. 7 De vernieuwbouw inspanning is afgerond voordat er legacy functionaliteit achterhaald

raakt.

8 Het testen verloopt op schema en er is voldoende testdata. 9 Het ervaren onderhoudspersoneel is beschikbaar tijdens het gehele traject. II (Product) 10 Er is sprake van een up-to-date operationele omgeving. 11 Het systeem voldoet aan de evolutievereisten (kan goed een vernieuwbouw proces

ingaan)

12 De organisatie heeft het legacy systeem goed onder controle. 13 Er is veel kennis en / of kunde voor het doelsysteem. 14 Er is veel kennis van het huidige systeem.

136


15 Er is een volledige en toereikende documentatie. 16 De doelsysteem performance-eis is te realiseren in het project. 17 Er wordt gebruik gemaakt van bewezen, volwassen technologie voor het doelsysteem. 18 De operationele organisatie is erg verbonden aan het geven en volgen van trainingen. 19 De bestaande bedrijfskennis die in de broncode zit, kan volledig meegenomen worden

naar de nieuwe applicatie.

20 Het reengineerde systeem werkt naar behoren. 21 Er wordt een adequate hoeveelheid documentatie gecreeerd (niet te veel, niet te

weinig)

22 Alle wijzigingen in de bestaande applicatie zijn doorgevoerd, voordat het systeem daadwerkelijk vernieuwbouwd wordt.

23 Het gebruik van derde applicaties (zoals bijvoorbeeld excel-lijstjes) is bekend, zodat de functionaliteiten volledig achterhaald kunnen worden.

III (Proces) 24 De subsystemen zijn goed gekozen voor de vernieuwbouw benadering. 25 De Vernieuwbouw technologie is volledig toereikend voor het behalen van de doelen. 26 De kosten van de onderdelen die handmatig vernieuwbouwt moeten worden, vallen

laag uit.

27 De vernieuwbouw inspanning is een apart project, dat gefocused blijft op het vernieuwbouwen.

28 Nieuwe functionaliteiten en vereisten worden toegevoegd buiten het vernieuwbouw proces.

29 De modellering is klaar voordat de bouw begint. 30 Mate van voorbereiding en reverse engineering is voldoende. 31 Achterhaalde informatie is bruikbaar en wordt goed gebruikt. 32 Objecten worden compleet en correct vastgelegd tijdens verkrijgen van het ontwerp. 33 Vastgelegde objecten integreren goed in het nieuwe systeem. 34 Het migreren van de bestaande legacy data verloopt soepel. 35 De performance blijft hetzelfde, ondanks migratie naar een andere omgeving of

programmeertaal.


uw bij Centric – Onderzoek naar een projectaanpak voor reengineering

138

36 De organisatie maakt op een goed manier gebruik van consultants en externe partijen (laat het advies over aan externe experts maar is zelf ook erg betrokken)

37 Het project loopt volgens schema, ondanks een mismatch in de architectuur (van bijvoorbeeld programmeertaal of dbms)

IV (Tools) 38 Taal van de tool is ontworpen om de abstracte informatie weer te geven die nodig is

voor de vereisten en ontwerp specificaties.

39 Met behulp van de tool kan gemakkelijk veel ontwerp en requirements verkregen worden vanuit de code.

40 Voldoende toolondersteuning gedurende het hele proces.

Wanneer u nog andere belangen heeft waargenomen, of vindt dat deze meegenomen moeten worden, kunnen deze onderstaand worden toegevoegd en ingevuld. Nr. Risico Mate van impact Waarschijnlijkheid

Ja Nee 1 2 3 4 5 1 2 3 4 5

Klein Groot Klein Groot

X1 X2 X3 X4

Vernieuwbo


Bijlage 13 SRA antwoorden voor SBA

In onderstaande tabel zijn de verschillende antwoorden voor de SRA vragenlijsten opgenomen, zoals deze gegeven zijn voor het SBA project, door de projectleider. Lijst Antwoorden Belang van reengineering 1c, 2b, 3a, 4a, 5c, 6c, 7c, 8c, 9b Voorbereiding 1c, 2c, 3c, 4c, 5B, 6C, 7A, 8A, 9a, 10a, 11a, 12a, 13a, 14c, 15c, 16a,

17a, 18a, 19a

Onderhoudsomgeving 1a, 2b, 3a, 4b, 5b, 6a, 7b, 8a, 9b, 10b Restructuring 1b, 2a, 3b, 4b, 5b, 6c, 7b, 8b, 9b, 10c

Retargeting 1b, 2a, 3b, 4a, 5a, 6a, 7a, 8a Data reengineering 1a, 2b, 3b, 4a, 5b, 6b, 7b, 8b, 9a, 10a

Broncode vertaling 1b, 2a, 3a, 4c, 5b, 6b, 7b Redocument 1b, 2b, 3c, 4c, 5c



Bijlage 14 Aanloop DUPLO Project

Deze bijlage beschrijft een geanonimiseerd project, dat geen doorgang heeft gehad, maar waar wel informatie over een voorgestelde aanpak is. Op basis van ervaringen met het SBA traject, is er een aanbieding gedaan aan een verzekeringsmaatschappij voor het doorlopen van een reengineering traject. Dit betrof een reengineering inspanning in samenwerking met de Software Improvement Group (SIG). De probleemstelling was afkomstig van een verzekeringsmaatschappij die een 20 jaar oude pensioenapplicatie vernieuwd wilde hebben. Deze applicatie bestond uit delen COBOL, SAS, Assembler en JCL. In totaal betrof het 700.000 lines of code (LOC). De applicatie moest herbouwd worden zodat het gebruikt kon worden door de nieuwe SAP omgeving. Hiervoor ontbraken de detailspecificaties. Deze moesten achterhaald worden voor de nieuwbouw of verbouw van de applicatie. De klant heeft een proefweek voorgesteld waarin een drietal aanbieders kunnen laten zien wat de aanpak en resultaten zal zijn. De doelen hiervan waren:

Aantonen van de mogelijkheid om de huidige situatie te kunnen documenteren. Aantonen van de mogelijkheid om toekomstige aanpassingen op de bestaande functionaliteit en

architectuur te kunnen verwerken. Voorstel voor vervolgtraject kunnen doen, met een tweetal strakke data voor oplevering. Een indicatie kunnen geven van de kosten van het vooronderzoek.

Voor deze proefweek kregen alle aanbieders twee cases.

Case 1 betrof een geïsoleerde functionaliteit, waarvan de documentatie (functioneel en technisch) beschikbaar was.

Case 2 betrof een geïsoleerde functionaliteit waarvan de documentatie niet beschikbaar was. Wel was hier alleen broncode die reverse engineered worden om de specificaties naar boven te halen.

De inschatting van de totale inspanning voor case 1, is gemaakt op basis van de beschikbare documentatie. Tijdens het project was er 1 dag waar er toegang was gegeven tot de volledige documentatie. Door de documentatie die gebruikt is in de proefweek af te zetten tegen de documentatie die bestaat, is er een inschatting gedaan. Deze inspanning is ingeschat op 360 mandagen (1,8 manjaar). De inspanning is ook berekend naar aanleiding van case 2. Deze berekening is uitgevoerd op basis van het aantal LOC (lines of code). Deze is afgezet tegen de LOC van het totale systeem. Vervolgens is op basis hiervan een inschatting van de inspanning gedaan. Deze inspanning is geschat op 20-25 manjaar. De inschatting van het totale project is nooit officieel gedaan, maar is intern op basis van gevoel voor de materie geschat op een kwart van de inspanning van een regulier ontwikkel traject. Op deze manier is de inspanning beraamd door de functiepunten te vermenigvuldigen met de uren en dit te delen door 4 ((10.000 * 7,5) / 4). Deze schatting kwam uit op plus minus 12 manjaar.


onderzoek naar een projectaanpak voor reengineering door ... · in de portfolio analyse wordt een...

Documents