Failing to plan is planning to fail

Software engineering is het maken of aanpassen van programma’s aan de veranderde eisen van een klant Is zo’n opdracht groot dan zal al snel een team op deze taak gezet worden. Dat team heeft een duidelijke taakverdeling om het project tot een goed einde te brengen

Een project is: een verzameling unieke werkzaamheden Uitgevoerd in een tijdelijk samenwerkingsverband Om binnen een vooraf bepaald tijdsbestek Een van tevoren gespecificeerd doel te bereiken

Ontwikkelen of aanpassen van software is: duur tijdrovend vraagt veel overleg is onderhoudsgevoelig (korte life cycle) heeft gevolgen voor: de organisatie als geheel het personeel

Daarom is het belangrijk: duidelijke afspraken te maken over: Kwaliteitseisen (CMM-norm) Bezetting van het team Wijze van rapporteren Tijdplanning (mijlpalen) Kosten Standaards Verantwoordelijkheden Producteisen

1. initial 2. repeatable 3. defined 4. managed 5. optimizing

Capability Maturing Model In 5 stappen kan een softwarehuis de perfectie bereiken CMM 1: initial (startniveau) ( verg. ISO 9000-norm ) CMM 2: repeatable (herhaalbaar) CMM 3: defined (standaards binnen de org. Maatwerk) CMM 4: managed (processen meten) CMM 5: optimizing (blijvend innoveren)

Afspraken over de manier van rapporteren: Waterval-model Spiraal-model V-model RAD-model

Document van eisen Globaal ontwerp Detail ontwerp Programmateksten Unit-test Moduletest Integratietest Systeemtest w m l a d a v r e t o e l Implementatie

Waterval model

Boehm’s spiraal

DvE specificaties ontwerp programmateksten Unit-test Module test Integratie-test Systeemtest V-Model

Het MOSCOW-model

Wat de klant: Must have O Should have Could have O Won’t have

Voordelen: De klant wordt bij de productie betrokken Fixed prices projecten mogelijk Er is snel een prototype

Life cycle van een softwareproduct: behoefte (aan verandering) ontstaat analyse van het probleem ontwikkeling en implementeren testen invoeren aanpassen, uitbreiden gedurende ongeveer 5 jaar daarna is het voordeliger een nieuw programma te ontwikkelen

CR PR Programma van eisen Start project SOW Work breakdown basisontwerp detailontwerp implementatie Test TPS, TAR integratie installatie acceptatie PIR

Change request: het bedrijf heeft behoefte aan een aanpassing van een bestaand programma, (evolutionair ontwikkelen) uitbreiding of update of aanpassing aan *ander platform *andere hardware *andere software

Problem Report: het bedrijf heeft behoefte aan een nieuw programma. (revolutionair ontwikkelen) Oorzaak: *er moet een geheel nieuwe functionaliteit komen *de bestaande software is niet meer aan te passen omdat het programma dan te traag of te ingewikkeld wordt

Preliminary Investigation Report (haalbaarheidsonderzoek) In nauwe samenwerking onderzoeken klant en softwarededrijf de mogelijkheden voor automatiseren. Het MOSCOW-model dient vaak als leidraad. De klant maakt een kostenplaatje (altijd te laag)

Statement of work (programma van eisen ) De klant weet nu wat hij wil, in het SOW wordt contractueel vastgelegd a. wat wordt gevraagd b. welke software gebruikt wordt c. hoe gecommuniceerd wordt d. wie waarvoor verantwoordelijk is e. planning (nu reëel) etc

Work breakdown: Het werk wordt opgesplitst in kleine brokken (probleemanalyse) en wordt gekoppeld aan tijd, personeel en apparatuur 1. Wie rapporteert wanneer? 2. Welke kennis is nodig en hoe verkrijgen we die? 3. Welke apparatuur is nodig (oa voor testen) en hoe komen we eraan?

Basisontwerp: Wat is de plaats van de nieuwe functionaliteit in: * De reeds bestaande systemen in het bedrijf * de systemen buiten het bedrijf, waarmee gecommuniceerd moet worden?

detailontwerp Een volledige beschrijving van de functionaliteit Een volledige beschrijving van de interface

Probleemanalyse, basisontwerp en detailontwerp zijn samen Het functioneel ontwerp (FO)

De realisatie en de invoering zijn samen Het technisch ontwerp (TO)

Realisatie Het plan wordt uitgewerkt door o.a de software-architect en de programmeurs. Dit is het eigenlijke programmaschrijven

Invoering Het inpassen van de software in de bestaande systemen. Begeleiding en instructie van personeel

Verdeling in tijd

testen De alpha-test wordt in house gedaan, soms m.b.v. simulatieprogramma’s als de apparatuur waarop getest moet worden, niet ter plekke beschikbaar is. Al tijdens de ontwikkelfase zijn in ieder stadium de testen geproduceerd die het programma moet ondergaan.

De bèta-test (bij algemene programmatuur) bestaat er meestal uit dat het programma aan bevriende relaties gegeven wordt om “uit te proberen”. Alle commentaar wordt verwerkt voordat de definitieve systeemtest (bij de klant) wordt gedaan.

Test Acceptence Report (TAR) Meldt de uitkomst van de testen: de data, de tijd dat getest is, de machines,

Gemeente Eindhoven Pleincollege Eckart Eindhoven 21 september 2000

Onderhoud Perfectief (50%) Adaptief (25%) Correctief (20%) Rest (5%) Verbeteren Aanpassen aan nieuwe hardware Fouten herstellen

Evaluatie Een goed softwarehuis zal nu nagaan wat de sterke en zwakke punten uit het project zijn geweest en zal daar lering uit trekken a. wat is de situatie? b. wat is het risico? c. wat moet de actie zijn volgende keer?

© Frank Stalpers Pleincollege Eckart