Design Erosion & Preservation - Utrecht University · 4/28/2004 · Ontwikkelaar van embedded...

22 maart 2002

Design Erosion & PreservationJilles van Gurp

Sjaak Brinkkemper

Jan Bosch

28 april 2004

Design Erosion & Preservation

2

Waar ga ik over pratenErosie slijtage verval & preservation

– Woorden die veel zullen vallen

Case study bij Baan– Het waarom van de case study

– Hoe: onderzoeks methode

– Resultaten & Lessen die hieruit geleerd kunnen worden

Bredere context van het verhaal– Relevantie voor software producerende bedrijven

– Relevantie voor software consumerende bedrijven

28 april 2004


3

Maar eerst iets over mezelf …Hier, in Utrecht, gestudeerd ‘94-’98Naar Zweden verhuisd voor een promotieIn 2000 verhuisd naar GroningenGepromoveerd op het gebied van Software Engineering in 2003

Tot begin dit jaar postdocNu werkzaam bij ….

28 april 2004


4

… <GX>Snel groeiend bedrijfSinds half jaren 90 actief in de contentmanagement sector

Eigen product: <GX> Webmanager– Vormgeving & content wijzigen via browser– Laagdrempelig & gebruikersvriendelijk– Schaalbaar– Flexibel

20 a 30 maatwerk projecten per jaar op basis van <GX> Webmanager

28 april 2004


5

Klanten van GXINDUSTRIE

– Mercedes-Benz, Unilever, Akzo, KEMA, Hartman, Advanta

ONDERWIJS– Katholieke Universiteit Nijmegen, Vrije Universiteit Amsterdam,

Hogeschool voor de Kunsten Utrecht

KOEPELORGANISATIES & KENNISCENTRA– VNO-NCW, VSNU, Unicef, NIBRA

(SEMI)OVERHEID– regionale en landelijke politie, provincies, verschillende

gemeenten, de Europese Commissie

SPORTWERELD – Ajax, PSV, Voetbal International, Runnersworld

UITGEVERS– WPG, Planet Internet, de Volkskrant, Zwijsen, Swets & Zeitlinger,

Telefoongids Media

28 april 2004


6

Een paar GX websiteswww.kpn.comwww.planet.nlwww.goudenkoffer.nlwww.levob.nlwww.vi.nlwww.ajax.nl

28 april 2004


7

OK, wat is design preservation (DP)?Behoud van software over langere tijdVoorkomen van verouderings verschijnselenHet zolang mogelijk weerstaan van slijtage door– Onderhouds werkzaamheden

– Veranderende markt eisen

– Waan van de dag

– Onvoorziene omstandigheden

– ….

28 april 2004


8

Waarom DP?Software systemen worden steeds

– Groter

– Ouder

– Complexer

– Belangrijker

Software is cumulatieve investering– Over jaren

28 april 2004


9

Waarom ….Economische waarde software is gigantischSoftware kan niet op korte termijn vervangen worden

Software verandert voortdurend– Bugfixes

– Aanpassingen in functionaliteit

– Optimalisatie

– Nieuwe technieken, methodes en hypes

28 april 2004


10

Daarom dus:Software is de motor van een modern bedrijfIedere aantasting van de software bedreigd het bestaan van de eigenaar

Als u nu tot de ontdekking komt dat uw software verouderd is en niet te repareren hebben uw concurrenten nog jarenlang vrij spel

28 april 2004


11

VeranderingenHet is onmogelijk bij veranderingen rekening te houden met alle mogelijke toekomstige veranderingen

Veranderingen werken cumulatief en zijn vaak min of meer onherroepbaar

Nieuwe veranderingen worden beperkt door het bestaande systeem

28 april 2004


12

Software Erosie – SymptomenVerminderde flexibiliteit

– Uitbreidingen worden lastig

Afname code kwaliteit– Meer defects

Toenemende complexiteit– Veranderingen duren langer

– Er worden meer fouten gemaakt

28 april 2004


13

Software Erosie – RedenenTijdsdruk

– Time to market

– Project deadlines

– Release deadlines

Gebrek aan kennis– Nieuwe technieken

Personeel verloopKleine en grotere menselijke fouten…

28 april 2004


14

Stelling 1

Alle software is onderhevig aan design erosion

Ook die van jullie!

28 april 2004


15

Stelling 2

Design erosion is niet te voorkomen, onafwendbaar en fataal als je niks doet

Ook bij jullie!

28 april 2004


16

Netscape, hoe het niet moetNetscape † zomer 2003

– 1996/97 Netscape Communicator 4.0, ontwikkeling 5.0 begint– Kapitalen waard op de beurs, gouden bergen, euforische stemming bij

introductie

– 1997/98 Internet explorer 4.0 concurreert heel sterk– Netscape heeft een groot probleem en verliest snel marktaandeel

– 1998 Netscape gooit handdoek in de ring– Mozilla wordt geboren

– 1998/1999 Mozilla ontwikkelaars besluiten tot herontwikkeling– 1999-2002 Herontwikkeling, mislukte Netscape 6 versie

uiteindelijk een mozilla 1.0– 2002- nu Mozilla marktaandeel groeit heel langzaam maar

internet explorer (versie 6 inmiddels) domineert– GX ondersteunt Mozilla

– 2003, AOL trekt de stekker uit Netscape. Mozilla gaat door als stichting

28 april 2004


17

Axis, een goed voorbeeldOntwikkelaar van embedded hardware

– Succesvolle productlijn op basis van eerste product– Een printserver voor printers

– Steeds meer ondersteuning voor andere randapparatuur– CDROMs, scanners, cameras

– Half jaren 90– Ombouwen readonly filesystem van cdroms naar read/write enabled

filesystem blijkt onmogelijk– Er is een sterke vraag naar producten die zip drives, cdbranders, etc.

kunnen ondersteunen

– Er wordt besloten tot herontwikkeling– Traject van 2 jaar– Weinig nieuwe producten gedurende traject– Parallel aan onderhoud van oude software

– Traject slaagt en Axis bestaat nog steeds– Inmiddels is deze productlijn nogmaals vervangen, dit maal door linux

28 april 2004


18

Dus DP!Zorgen dat de ‘gezondheid’ van een software systeem dusdanig blijft dat noodzakelijke aanpassingen in de toekomst kosten effectief kunnen worden doorgevoerd

•Identificeren van erosie problemen•Oplossen van deze problemen•Voorkomen van verdere problemen

28 april 2004


19

Case StudyBij een bedrijf met eigen software productMet veel LOCMet lange geschiedenisGroot ontwikkel team

Kortom Baan

28 april 2004


20

DoelstellingenBeter begrip evolutie software systemen

– Verbetering bestaande praktijk aan de hand van dingen die goed en fout gingen in case studie

– Vehoging kennisniveau ontwikkelaars

Beter inzicht redenen design erosie– Voorkomen potentiele problemen

Formuleren van effectieve design preservation strategie– Voorkomen dure aanpassings trajecten

– Tijdig herkennen en onderkennen van erosie problemen

28 april 2004


21

OnderzoeksvraagHoe gaan bedrijven, zoals Baan, om met design preservation– Erosie symptomen

– Identificatie van erosie

– Oorzaken voor erosie problemen

– Herstel van geerodeerde software

– Preventie

28 april 2004


22

Case selectieTwee verschillende componenten uit de Baan produkt lijn– Query Processor QP

– Purchase & Sales Schedules PSS

Uit verschillende lagen– QP: infrastructuur laag

– PSS: applicatie laag

28 april 2004


23

Baan Architectuur

DBMSDBMS DriverOperating SystemBaan Shell VMData AccessLayerApplication LogicUser InterfaceApplicationEngineMiddlewareBaan3rd PartyOtherApplications

28 april 2004


24

Case 1: Query Processor (QP)EvolutieProblemenOplossingen

28 april 2004


25

Voor introductie QP

Baan Applications

Baan Shell

C-ISAM API

Informix Database

Users loggen in op mainframe

Baan Shell gebruikt CISAM voor db access

28 april 2004


26

Client/ServerDB toegang geslitst in C/S gedeelte

Baan Applications

Baan Shell

BDB/C BDB/S

client server

Generic DB-Driver DB Specific Driver

Database

dbcalls & transactions

28 april 2004


27

Client side SQL supportVertaling van SQL naar db calls aan client kant

Baan Applications

Baan Shell

BDB/C BDB/S

client server


Database


QP/C

28 april 2004


28

Server side SQL support

Baan Applications

Baan Shell

BDB/C

BDB/S

client server


Database API


dbcalls&

transactionsQP/C QP/Ssql

SQL over netwerk is efficient, vertaling aan server kant

28 april 2004


29

Omschakeling naar volledig SQL

Baan Applications

Baan Shell

BDB/C BDB/S

client server


Database APItransactions

transactionsQP/C

sql

QP/Ssql

sql

SSTStransactionssql

dbcalls

Server spreekt SQL, geen db calls meer

28 april 2004


30

Problemen (1)Verschuiving van volledig CISAM naar volledig SQL

Veel problemen met betrekking tot complexiteit en kwaliteit– Defecten zijn lastig op te lossen

– Toevoegen van nieuwe (SQL) features blijkt bijzonder lastig te zijn

Oorspronkelijke ontwikkelaars/ontwerpers werken niet meer voor Baan

28 april 2004


31

Problemen (2)Er is geen ontwerp documentatie

Documentatie voor developers onvolledig

Bugs in QP geven aanleiding tot afhankelijkheden in applicatie code omdat ontwikkelaars om de bugs heen programmeren

ca. 100 openstaande defecten/nieuwe features– waarschijnlijk nog meer in de toekomst

28 april 2004


32

OplossingenHerontwikkeling van QP/C en QP/S

– kostenschatting laat zien dat dit economisch verantwoord is

– overige componenten zijn behouden gebleven

– gefaseerde ontwikkeling succesvol uitgevoerd

Expliciet ontwerp - documentatie = specificatie

Regression tests

Betere modularisatie door toepassing OO technieken

28 april 2004


33

Case 2: Purchase & Sales SchedulesEvolutieProblemenOplossingen

28 april 2004


34

PSS Sales SchedulePlanned InformationOrder InformationPurchase ScheduleForecast, plannedorder quantitiesImmediate and firm calloffEnterprise Planning(MRP)Assembly Line, Shop,Floor, WarehouseRequestApprove & SendReleaseSupplierProcessesSupplierCustomerimmediatefirmplannedshipping schedulematerial releasePush SchedulingPull Scheduling

28 april 2004


35

PSS Baan IVSupport voor Sales Order Delivery Schedules

Noodzaak voor het Just In Time (JIT) principe en Original Equipment Manufacturer (OEM) relaties geidentificeerd

28 april 2004


36

PSS Pilot projectIn samenwerking met DAF worden requirements geformuleerd

Een concept oplossing werd ontworpen en een prototype hiervan werd opgeleverd

Aflevering gescheduled voor iBaan ERP 5.0c

28 april 2004


37

PSS1Feedback van DAF en andere klanten brengen nieuwe

requirements aan het licht

Implementeren requirements is problematisch aangezien het ontwerp niet geschikt is voor deze nieuwe requirements

Integratie met overige baan componenten blijkt problematisch

PSS is niet op tijd klaar voor release en er wordt besloten om iBaan 5.0c met het PSS prototype op de markt te brengen. – Het prototype is alleen beschikbaar voor een select groepje klanten

Project wordt met een jaar verlengd

28 april 2004


38

Herstructurering PSS2Aanpassingen op basis van feedback

Beta in iBaan ERP ERP 5.1a

Klanten zoals Boeing spelen een grote rol in het project

28 april 2004


39

Release PSS2Nu een onderdeel van iBaan ERP 6Al 2 jaar zonder noemenswaardige problemen in gebruik bij diverse klanten

28 april 2004


40

Problemen tussen PSS1 en PSS2Code kwaliteitGebruik database infrastructuurVeel lastig te repareren defecten in het prototype

Performance & Documentatie problemen

Het ging niet goed met PSS!

28 april 2004


41

OorzakenVeranderingen RequirementsCommunicatie problemen

– er werd op verschillende locaties ontwikkeld

Process enforcement issues– Bestaande processen werden niet altijd nageleefd

Verschillen in ervaring– Verschillen binnen en tussen de diverse teams waren aanzienlijk

Constante druk van baan produkt releases

28 april 2004


42

OplossingenEerst interne evaluatie

Refactoring & integratie met bestaande systemen– twee derde tijd gereserveerd voor refactoring

– herstel project geslaagd

Intensieve samenwerking met klant– veel feedback gedurende ontwikkeling

– Voor beide partijen belangrijk

Beter afdwingen van bestaande processen– minder onnodige fouten, betere kwaliteits controle

28 april 2004


43

Antwoord op de onderzoeksvragen

28 april 2004


44

SymptomenCode kwaliteitOnzekerheid over specificatiesOplossingen voor problemen introduceerden nieuwe problemen

Problemen met het gebruik van het systeem

Relatief veel defecten (ten opzichte van andere componenten)

28 april 2004


45

IdentificatieDefect density wordt standaard gemeten op een zeer fijnmazige manier binnen Baan

Evaluaties van problemenKostenschattingen voor nieuwe requirementsVerandering van staf over tijd brengt nieuwe inzichten mee

28 april 2004


46

OorzakenGrote onzekerheid over historie van het systeem en eerdere ontwerpbeslissingen (kokervisie in de tijd)

Gebrek aan kennis van de orginele ontwerpen en context van het systeem

Opeenstapeling van minder gelukkige beslissingen

Veranderingen in requirementsVeranderingen in kennisniveau

28 april 2004


47

OplossingenHerontwikkeling van componentenRefactoringMeer focus op ontwerp en requirementsTechnologische verbeteringen

– OO, modularisatie

28 april 2004


48

PreventieMeer automatisch testen

– QP case is een successtory

Besluit op basis van goede informatieGeen ongedocumenteerde veranderingenMeer focus op naleven bestaande processenComponent evolutie word gepland in context produkt releases

Team samenstelling– Juiste mix ervaring & kennis

28 april 2004


49

Wat voor lessen kunnen hier uit getrokken worden?

Alertheid op symptomen– Problemen komen niet uit de lucht vallen maar zijn vaak al bekend bij personen

Identificatie van problemen– Het onderkennen van problemen is de eerste stap naar de oplossing

Oorzaken begrijpen– Probeer te begrijpen waarom er problemen zijn

28 april 2004


50

… LessenZie case voor oplossingen

– Geen silver bullets

Neem oorzaken weg– Voorkom dat je de zelfde fouten maakt

– Leer van wat er goed en slecht gaat binnen je organizatie

28 april 2004


51

Meer informatiewww.jillesvangurp.com/publicationswww.rug.nl/informatica/search

[email protected]

22 maart 2002

Vragen??

Design Erosion & Preservation - Utrecht University · 4/28/2004 · Ontwikkelaar van embedded...

Documents

Transcript of Design Erosion & Preservation - Utrecht University · 4/28/2004 · Ontwikkelaar van embedded...