Programvare- prosesser - del2 In 140 Forelesning nr. 4 Sommerville kap. 3.

Presentasjon om: "Programvare- prosesser - del2 In 140 Forelesning nr. 4 Sommerville kap. 3."— Utskrift av presentasjonen:

1 Programvare- prosesser - del2 In 140 Forelesning nr. 4 Sommerville kap. 3

2 Programvarespesifikasjon n Hvilken funksjonalitet er nødvendig n Hva er avgrensingene n Meget kritisk aktivitet

3 Fasene i kravspesifikasjon n Forstudie –Kan problemet løses? –Er det økonomisk forsvarlig? –Bør vi arbeide mer med dette? n Faktainnsamling og behovsanalyse –Studie av eksisterende løsning –Samtale med brukere –Utvikling av systemmodeller –Hensikten er å forstå systemet som skal utvikles

4 Fasene i kravspesifikasjon forts. n Kravspesifikasjonen –Omdanne forståelse av problemet til et dokument som stiller krav til systemet. –Brukerkrav er hva brukeren krever av systemet –Systemkrav er detaljerte krav til hvilken funksjonalitet systemet må inneholde n Kravvalidering sjekker kravspesifikasjonen –Er den realistisk? –Er den konsistent? –Er den komplett? –Feil som oppdages fører til endring i kravspesifikasjon. n Prosessen er ikke strengt sekvensiell.

5 Programvareutforming og -utvikling n Forvandle en kravspesifikasjon til et eksekverbart system. n En systemarkitektur er en beskrivelse av data, grensesnitt mellom komponentene og kanskje algoritmene n Endelig utforming gjennom skrittvis prosess n Utvikle flere stadig mer detaljerte modeller av systemet n Feil oppdages og må rettes i tidligere trinn n Hver aktivitet gir spesifikasjon for neste trinn

6 Trinnene i utformingsprosessen n Arkitekturutforming –Dokumentasjon av subsystemer og forholdet mellom dem n Abstrakt spesifikasjon –Subsystemenes tjenester og rammer n Grensesnittutforming –Grensesnitt mellom subsystemer utformes og dokumenteres. –Store krav til klarhet

7 Trinnene i utformingsprosessen n Komponentutforming –Oppdeling av funksjonalitet og grensesnittspesifikasjon n Datastrukturutforming –Detaljert spesifikasjon av datastruktur n Algoritmeutforming –Nødvendige algoritmer n Generell modell, som kan være annerledes i praksis. F.eks kan de siste to bli slått sammen

8 Programvareutforming og utvikling

9 Utformingsmetoder n Ad Hoc –uformell utforming –Lite løpende oppdatering av utforming –Koding gir system som avviker fra utforming. n Strukturerte metoder = notasjon og retningslinjer –Structured design (Yourdon & Constantine) –Unified software development process (Rumbaugh & Jacobson) –En rekke andre –CASE verktøy

10 Strukturerte metoder n Vanlige modeller –Dataflytmodeller –E-R Diagrammer –Strukturert modell over systemkomponenter og deres samspill –Objektorienterte metoder inneholder modeller som dekker Arv Sammenheng mellom objekter Samspill mellom objekter n Mulige modeller –Tilstandsdiagrammer –Livsløpsdiagrammer for entiteter

11 Strukturerte metoder n Datakatalog anbefales ofte n Uformelle retningslinjer n Man tar det som passer inn n Metodene er standardnotasjon og god praksis n Bør gi en brukbar utforming n Kreativitet likevel nødvendig

12 Programmering og debugging n Normalt noe samtidig med utforming n CASE gir skjelett n Store forskjeller i framgangsmåte –kjent/ukjent –kode/datastruktur n Feilsøking og retting n Feil-> Hypotese om årsak-> Fjerne mulig årsak -> Feilen borte? n Hjelpemidler –Trace –Inspeksjon av variable underveis –Brakepoints –Stack –Assertions

13 Programvarevalidering n Hensikten er å vise at systemet følger spesifikasjon og oppfyller kundens forventninger –Inspeksjon og gjennomgang underveis. –Testing av fungerende system. –Inkrementell vs monolittisk testing.

14 Programvarevalidering Akseptansetest = alfatest Betatest gjelder prøveleveranse til et antall kunder Testteam utarbeider testplaner

15 Testprosessen n Enhetstest –uavhengig testing av enkeltfunksjoner n Modultest –testing av et sett funksjoner eller et objekt n Subsystemtest –testing av et subsystem satt sammen av moduler. Avdekker grensesnittproblemer n Systemtest –Test av systemet som helhet. Samspillsproblemer. Funksjonelle og ikke funksjonelle systemkrav etter spesifikasjon. n Godkjenningstest –Test med reelle data. Kan finne feil i spesifikasjonen. Vil også vise evt. ytelsesproblemer.

16 Om testteam n Functional tests or system tests should be developed by a separate small team whose only job is testing. This team should take a black-box view of the system and take particular delight in finding bugs. (Sinister moustaches and crackling laughs are optional but desirable) fra UML-Distilled av Martin Fowler

17 Programvareevolusjon Mer og mer vedlikehold Mer og mer blanding av gammelt og nytt Glidende overgang Programvare/maskinvare

18 Automatisert støtte for programvareprosessen (CASE) n Automatisering av aktiviteter og rapporterting n Støttbare aktiviteter –Utvikling av grafiske systemmodeller –Datakatalog –Grafisk bygging av brukergrensesnitt –Debuggingsstøtte –Automatisk oversettelse til nyere programmeringsspråk –Kodegenerering n Effektivisering ~ 40%, mye mindre enn ventet. –Begrenset av Kreativitet lar seg ikke automatisere (AI en fiasko her - hittil) Samarbeidsintens aktivitet. Ikke støttet av CASE

19 CASE- klassifisering n Funksjonelt perspektiv n Prosessperspektiv n Integrasjonsperspektiv CASE-verktøy klassifisert etter funksjon PlanleggingsverktøySpråkprossesseringsverktøy EditeringsverktøyProgramanalyseverktøy ForandringsadministrasjonTestverktøy KonfigurasjonsadministrasjonFeilsøkingsverktøy PrototypingsverktøyDokumentasjonsverktøy MetodestøtteverktøyRe-engineering verktøy

20 Verktøy, Arbeidsbenk, Utviklingsmiljø