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.

Presentatie over: "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."— Transcript van de presentatie:

1 Failing to plan is planning to fail

2 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

3 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

4 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

5 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

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

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

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

9 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

10 Waterval model

11 Boehm’s spiraal

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

13 Het MOSCOW-model

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

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

16 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

17

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

19 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

20

21 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

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

23 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

24 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?

25 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?

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

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

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

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

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

31 Verdeling in tijd

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

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

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

35 Gemeente Eindhoven Pleincollege Eckart Eindhoven 21 september 2000

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

37 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?

38 © Frank Stalpers Pleincollege Eckart