Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Programvare- prosesser In 140 forelesning nr. 3 Sommerville kap. 3.

Liknende presentasjoner


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

1 Programvare- prosesser In 140 forelesning nr. 3 Sommerville kap. 3

2 Mål Forstå programvareprosessen som ide og som modell. Forstå forskjellige modeller og når de kan brukes. Forstå i store trekk prosessmodeller for kravspesifikasjon, utvikling, testing og evolusjon. Bli kjent med CASE-teknologi som støtter softwareprosessen.

3 Introduksjon Rep. def. –Aktiviteter og resultater som fører til utviklingen av et programvareprodukt –Fra scratch eller mer vanlig – utvidelse av eksisterende systemer –Komplisert intellektuell prosess – avhengig av menneskelig skjønn og skaperkraft. –Vanskelig å automatisere. Derfor begrenset bruk av CASE. –Også fordi det utviklingsprosessen endrer seg med organisasjon og prosjekt.

4 Introduksjon forts. Alle programvareprosessene er satt sammen av fire aktiviteter –Spesifikasjon –Utforming og utvikling –Validering –Evolusjon Det finnes ingen ideell prosess, men –Store muligheter for forbedring i mange organisasjoner. –Man bør bruke det beste som finnes. –Mye bruk av Ad hoc –Forbedring er mulig ved standardisering innføring av nye metoder

5 Prosessmodeller Fossefallsmodellen –Tar aktivitetene spesifikasjon, utvikling, validering og evolusjon som separate faser Evolusjonær utvikling –Stadig gjentagelse av aktivitetene. Et forenklet produkt lages fort fra en spesifikasjonsskisse. Dette systemet forbedres med stadige innspill fra kunden. Resultatet er til slutt et system som tilfredsstiller kundens behov Formell utvikling –Matematisk systemspesifikasjon som transformeres med matematiske metoder til et ferdig produkt. Gjenbruksbasert utvikling –Med nok gjenbrukbare komponenter, kan vi bygge dem sammen til et ferdig produkt.

6 Fossefallsmodellen Hentet fra andre greiner av engineering Fossefall også kjent som livssyklusmodellen

7 Trinn i fossefallsmodellen –Kravanalyse og definisjon Samtale med brukerne. Tjenester, mål og avgrensninger defineres nøyaktig og blir spesifikasjon. –System- og programvareutforming. Kravene splittes opp og fordeles. Systemarkitektur. –Implementering og deltesting Utforming realiseres som en mengde programmer eller programdeler. Deltesting fastslår om hver del følger sin spesifikasjon. –Integrasjon og systemtesting Delene settes sammen til et hele og testes. Er kravene oppfylt? Leveramse til kunde. –Drift og vedlikehold Lengste livsfase. Vedlikeholdet retter feil og tilpasser systemet til nye krav.

8 Fossefallsmodellen Resultatet av hver fase er dokumentasjon som blir godkjent. Ny fase startes ikke før forrige er fullført I praksis noe overlapping p.g.a. feil i tidligere faser -> Iterasjon Kostnaden for iterasjon med stadig ny dokumentasjon, gjennomgang og godkjenning er stor. –Få iterasjoner før fastlegging –Problemer forblir uløst, utsettes eller man "går rundt" –Systemet blir ikke godt nok for brukeren. –Kan gi dårlig struktur. Evolusjon kan løse noen av problemene.

9 Fossefallsmodellen - Hovedproblem er mangel på fleksibilitet. Tidlige bestemmelser Takler ikke endrede krav Bør bare brukes hvis det er klare krav Brukes fortsatt en del i praksis særlig når det utvikles deler av større system.

10 Evolusjonær utvikling Starte med et sterkt forenklet system som kan utvikles fort. Lage stadig nye versjoner etter innspill fra kunden helt til et tilstrekkelig system er utviklet. Spesifikasjon, utvikling og validering er ikke separate faser, men gjøres om igjen og om igjen, med stadig tilbakemelding.

11 To muligheter –Utforskende utvikling der målet er å lage et ferdig system. en kommer fram til det ferdige systemet ved å utforske brukerens krav Starter med å lage det kunden vet at han vil og legger til ny funksjonalitet etter kundens ønske. –Utvikling av prototyper som kastes Målet er å forstå hva brukeren vil ha og slik lage en bedre kravspesifikasjon. Vi lager bare prototyper på uforståelige deler av kravspesifikasjonen.

12 Evolusjonær systemutvikling Systemet utvikles samtidig med at kundens forståelse av problemet utvikles. Spesifikasjonen utvikler seg trinnvis.

13 Ulemper med evolusjonær systemutvikling. Prosessen er ikke synlig. Det er ikke kosteffektivt å dokumentere versjonene. Det er derfor vanskelig å si hvor langt man er kommet og hvor mye som gjenstår. Systemene er ofte dårlig strukturert Stadig forandring korrumperer strukturen i systemet Spesielle verktøy og metoder. Ikke kompatible med andre verktøy Spesialkompetanse

14 Fossefall vs. evolusjonær Evolusjonær best på små systemer < linjer kode Store systemer med lang levetid egner seg best for fossefallsmetoden > linjer kode – for store problemer med evolusjonær metode. Kombinasjoner –Fossefall der spesifikasjonen er klar –Evolusjonær prototyper der spesifikasjonen krever klargjøring –Utvikle brukergrensesnittet evolusjonært. Fossefallsmetoden er enklest å administrere.

15 Formell systemutvikling Kravspesifikasjonen forfines til en detaljert formell spesifikasjon med bruk av matematisk notasjon Denne spesifikasjonen transformeres i flere trinn der flere og flere detaljer legges til helt til det dannes et ferdig eksekverbart system. For hvert trinn sjekkes det at transformasjonen ikke har innført feil Det er flere transformasjoner å velge mellom. Valget krever ekspertise Har vært testet i praksis og gitt systemer med få defekter uten høyere pris Det er mulig å vise at systemet vil operere innenfor visse krav til pålitelighet. Passer dårlig til utvikling av brukerdialoger, som for de fleste programmer er den dominerende utviklingsaktiviteten. Passer best til å utvikle systemer der det stilles spesielle krav til pålitelighet, trygghet eller sikkerhet.

16 Gjenbruksorientert utvikling Gjenbruk er ikke nytt. Komponentbasert utvikling setter gjenbruk i system Gjenbruk også basert på COTS. Store komponentbiblioteker. En struktur å sette komponentene inn i

17 Trinnene i gjenbruksprosessen Kravspesifikasjon Komponentanalyse (Søk) Kravmodifikasjon Systemutforming med gjenbruk. –Noe nytt må kanskje lages Utvikling og integrering Validering

18 Gjenbruk – fordeler og ulemper Fordeler –Mindre å utvikle. Lavere pris og risiko. Raskere levering Ulemper –Kravkompromisser –Lite kontroll over videreutviklingen av innkjøpte komponenter

19 Iterasjonsmodeller Hybride modeller som kan brukes sammen med en kombinasjon av de fire klassiske. Modellene støtter iterasjon, det vil si en stadig gjentagelse av spesifikasjon og påfølgende faser To hovedtyper: Inkrementell og spiral. Strir mot innkjøpsmodellen til mange store organisasjoner.

20 Inkrementell (trinnvis) utvikling Mellom fossefalls- og evolusjonsmodellen Prioritert oversikt over tjenestebehov Definisjon av leveringstrinn Detaljert spesifikasjon til første trinn Trinnet utvikles, integreres og leveres. Samtidig videre behovsanalyse for neste trinn Trinnet tas umiddelbart i bruk og gir grunnlag for klarere spesifikasjon av de neste trinnene og en eventuell ny spesifikasjon for det som allerede er levert. Et trinn kan utføres som fossefall eller evolusjonært

21 Fordeler med inkrementell utvikling –Kunden har nytte av systemet fra trinn en. –Kunden kan bruke tidlige trinn som prototyp –Lavere risiko for total fiasko i prosjektet. –Bedre tid og innsikt gir bedre spesifikasjon på senere trinn. –Ettersom de høyest prioriterte tjenestene leveres først, får de også best testing.

22 Problemer med inkrementell utvikling Trinn bør ikke være større enn linjer, men må inneholde noe funksjonalitet og da kan det bli vanskelig å dele inn. Fellestjenestene kan bli vanskelige å planlegge

23 Spiralmodellen (Boehm 1988) Utviklingsprosessen ses som en spiral, der hver runde er en fase i utviklingsprosessen. I hver runde passeres fire sektorer –Målsetting med mål og begrensninger for fasen, samt styringsplan. Risikoer identifiseres og alternative strategier vurderes. –Risikoanalyse og reduksjon. For alle risikoer gjøres en detaljert analyse. Man forsøker å redusere risikoen. –Utvikling og validering. En utviklingsmodell blir valgt –Planlegging. Prosjektet blir gjennomgått og det besluttes om man skal kjøre en runde til. I så fall planlegges neste runde. Dette er en risikodrevet modell. Modellen kan brukes sammen med en av de fire klassikerne.

24 Boehms spiralmodell.


Laste ned ppt "Programvare- prosesser In 140 forelesning nr. 3 Sommerville kap. 3."

Liknende presentasjoner


Annonser fra Google