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

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.

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.

Introduksjon 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 organsasjoner. Man bør bruke det beste som finnes. Mye bruk av Ad hoc Forbedring er mulig ved standardisering innføring av nye metoder

Prosessmodeller Fossefallsmodellen Evolusjonær utvikling Tar aktivitetene spesifikasjon, utvikling, validering og evolusjon som separate faser Evolusjonær utvikling Stadig gjentagelse av aktivitetene. Et forenklet produkt er 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.

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

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 spesifikajson. Integrasjon og systemtesting Delene settes sammen til et hele og testes. Er kravene oppfyltt? Leveramse til kunde. Drift og vedlikehold Lengste livsfase. Vedlikeholdet retter feil og tilpasser systemet til nye krav.

Fossefallsmodellen Resultatet av hver fase er dokumentasjon som blir godkjent. Ny fase startes ikke før forrige er fullført I praksis noe overlapping pga.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.

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.

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.

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 prototype på uforståelige deler av kravspesifikasjonen.

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

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

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

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.

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

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

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

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.

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

Fordeler med inkrementell utvikling Kunden har nytte av systemet fra trinn en. Kunden kan bruke tidlige trinn som prototype 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.

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

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. Risiki identifiseres og alternative strategier vurderes. Risikoanalyse og reduksjon. For alle risiki 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.

Boehms spiralmodell.

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

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

Fasene i kravspesifikasjon 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 Kravvalidering sjekker kravspesifikasjonen Er den realistisk? Er den konsistent? Er den komplett? Feil som oppdages fører til endring i kravspesifikasjon. Prosessen er ikke strengt sekvensiell.

Programvareutforming og utvikling