Struktureret ProgramUdvikling MM 5

Præsentationer af emnet: "Struktureret ProgramUdvikling MM 5"— Præsentationens transcript:

1 Struktureret ProgramUdvikling MM 5

2 Modul placering

3 Andre væsentlige Software discipliner
Reviews konsekvent gennemført Projektstyring Programdokumentation Konfigurationsstyring Vedligeholdelse Projektgruppe sammensætning/Team building

4 ANSI/IEEE Standards(Gamle!)

5 Faser i SPU-modellen

6 V-model

7 SPU-Valuering

8 Holdning til test(Boris Beizar)
Fase 0 holdning : Ingen forskel mellem test og debug Fase 1 holdning : Viser blot at software virker Fase 2 holdning : Viser at software ikke virker(Fjenden) Fase 3 holdning : Test skal reducere risikoen, Der vil være fejl Fase 4 holdning : Holdning der tænker test ind i design og implementation. Denne holdning reducere testarbejdet og gør programmerne testbare. Thinking = holdning

9 Test design ( Boris Beizar)
Explicit testdesign: ikke: Design, kode, desk chesk, test and debug men: Design, testdesign, kode, test kode, programexpection, test inspektion, test debugging, test execution, program debugging testing

10 Endnu et formål ( Boris Beizar)
Formålet med test er at vise at der er fejl Formålet med debug er at finde årsagen til fejlen og designe og implementere programændringer som retter fejlen

11 Mennesker laver fejl(Meizer)
Ligegyldigt hvor godt vi koncentreret os og ligegyldigt hvor gode vi er til struktureret programmering, ligegyldigt hvilke værktøjer vi har tilrådighed, så laver vi fejl. DERFOR: Test og testdesign er midlet til at få foretaget ordentlige og grundige afprøvninger inden afleveringen (release) Har I eksempler på at ovenstående ikke er udført i tilstrækkeligt omfang???

12 Testvurdering Program kvalitet og pålidelighed er tilstrækkelig
Testen er utilstrækkelig til at finde fejl Testfasen og dens planlægning er vigtig fordi: Design af test skal have den højest mulige sandsynlighed for at finde fejl, med den mindst mulige anstrengelse.

13 Testbarhed Operabilitet: Jo bedre det virker, jo mere effektivt kan det testes Observerbarhed: Hvad du ser er hvad du tester Kontrollerbarhed: Jo bedre vi kan kontrollere programmet, jo bedre kan vi automatisere eller optimere testen Dekomponerbarhed: Giver mulighed for hurtig isolation af og giver mulighed for smartere tests Simplicitet: Jo mindre der er at teste jo hurtigere kan det gøres Stabilitet: Ændringer foretaget på p.g.a. Fejl ændre ikke tidligere værdien af tidligere foretagne testprocedurer Forståelighed: Jo større forståelse for programmet jo smartere test

14 Fejlfordeling(Boris Beizer)
Requirements % Egenskaber og funktionalitet % Struktur fejl % Data definition/adgang % Implementation % Integration % System Software arkitektur % Test definition/udførelse % Andet %

15 Testplanlægning/afvikling
Program Fejl Korrektion Test Vurder Debug Fejl rate Testresultat Testprogram Pålideligheds model Prædikteret pålidelighed

16 Typer af test White Box: Lad os kontrollere det inden i
Black Box: Lad os se om det virker systemmæssigt Event handling: Lad os se om data fra alle mulige events behandles og bringer os(vore processer) i ønskede tilstande

17 Testtid ved 100% gennemløb
Loop<=20 Hver statement 0,1msek Testtid???

18 Basis sti-testning

19 Flow-graf præsentation

20 Fra Psedosprog til flowgraf
Procedure average; {Initialiseringer} i=1; total.input=total.valid=sum=0; DO WHILE value[i] <> stop AND total.input < 100 i++; IF value[i] >= minimum AND value[i] <= maximum THEN total.valid++; sum = sum + value[i]; ELSE skip ENDIF ENDDO IF total.valid>0 THEN average = sum/ total.valid; ELSE average = stop; END average

21 Sløjfe typer

22 Eksempel på Modultest

23 Integrations rækkefølge
Bottom up integration kræver drivere Top down integration kræver stuppe 2 enheder kædes ikke sammen uden at den ene er testet Enheder føjes til en efter en – godt for grænseflade kontrol

24 Proces-test

25 Proces-integrationstest

26 Realtids test Processererne er testede enkeltvis (White,Black box)
Hændelser og typer af hændelser testes ordnet derefter i vilkårlig rækkefølge for den enkelte proces Proceskommunikation gennem køer eller datalager testes Testene øges til direkte stress-tests

27 Dogmer for nye IT-projekter
Forslagene er udtrykt som 10 dogmer for offentlige IT-projekter. Det er tanken, at efterlevelsen af disse dogmer kan reducere risikoen for skandaler og øge udbyttet af de offentlige IT-kroner. De 10 dogmer har følgende overskrifter: Foranalyse og planlægning Ansvarlig og kvalificeret kontraktindgåelse Modulopdelte projekter Konsulentkvalifikationer Kundens kvalifikationer Realistiske mål med politisk accept Projektansvar Standardkontrakter og udbudsregler Valg af system Organisatorisk implementering Dogmerne er beskrevet med en kort uddybende forklaring og forslag til konkrete initiativer.