Kap. 2 Prosessen. Utviklingsmodeller -2. Utviklingsmodeller. Utviklingsmodeller -4. Utviklingsmodeller - 3. Software Engineering - definisjoner

Transkript

1 Software Engineering - definisjoner Kap. 2 Prosessen Utviklingsprosessen Modeller for utvikling Bauer: Etablering og bruk av gode ingeniørmessige prinsipper for å fremskaffe økonomisk programvare som er pålitelig og arbeider (virker) effektivt på reelle maskiner. IEEE: 1. Anvendelse av en systematisk, disiplinert, kvantifiserbar fremgangsmåte for utvikling, bruk (operation) og vedlikehold av programvare, dvs. anvendelse av engineering på programvare. 2. Studie av framgangsmåter som i 1. Systemutvikling Kap.2. Prosessen 1 Systemutvikling Kap.2. Prosessen 2 Utviklingsmodeller Fellestrekk for alle modellene: 1. Definisjonsfase 2. Utviklingsfase 3. Vedlikeholdsfase Utviklingsmodeller Definisjonsfase - fokus på hva Kartlegge: Informasjon Funksjoner som ønskes utført Systemoppførsel Grensesnitt Rammebetingelser for konstruksjon Valideringskriterier Systemutvikling Kap.2. Prosessen 3 Systemutvikling Kap.2. Prosessen 4 Utviklingsmodeller Utviklingsfase - fokus på hvordan Datastrukturer Funksjoner - programkonstruksjon, arkitektur Prosedyredetaljer Grensesnitt Kodekrav Testprosedyrer Fasen vil inneholde konstruksjon koding testing Utviklingsmodeller Vedlikeholdsfase Korreksjon Adapsjon: endringer i omgivelser/plattform fører til endringer - konvertering Utvidelser og forbedringer Preventivt vedlikehold: sw reengineering - forbedringer som gjør programmet lettere å vedlikeholde. Systemutvikling Kap.2. Prosessen 5 Systemutvikling Kap.2. Prosessen 6

2 Metoder Metoder viser hvordan systemutviklingen skal foregå: Prosjektplanlegging Estimering System og sw kravanalyse Konstruksjon av datastrukturer/databaser programarkitektur algoritmer/prosedyrer Koding Testing Vedlikehold Verktøy CASE-verktøy (Computer Aided Software Engineering) - støttesystem for systemutvikling Systemutvikling Kap.2. Prosessen 7 Systemutvikling Kap.2. Prosessen 8 Paraplyaktiviteter Foregår i alle faser, gjennom hele prosjektet: Prosjektadministrasjon Formelle gjennomganger Kvalitetssikring (SQA) Konfigurasjons-administrasjon Dokumentproduksjon Adm. av gjenbruk Målinger Risikoanalyse 2.4 Den lineære sekvensielle modellen Denne modellen kalles også den klassiske livssyklusen eller fossefallsmodellen. Det finnes flere varianter av modellen. System/informasjon analyse Systemutvikling Kap.2. Prosessen 9 Systemutvikling Kap.2. Prosessen 10 Alternativ fossefallsmodell Forprosjekt Analyse kalles også kravspesifikasjon Analyse Konstruksjon Koding Testing Vedlikehold System/information engineering og modellering System/information engineering og modellering omfatter det vi vanligvis gjør i et forprosjekt (forstudie, forandringsanalyse): Finne svakheter og mangler i dagens system. Definere mål for (eventuelt) nytt system. Se på løsningsalternativer (Kjøpe hyllevare eller egen utvikling) Lage (overordnet/grov)plan for prosjektet. Programvare er alltid del av et større system eller forretningsvirksomhet. Derfor starter utviklingen med å kartlegge krav for alle deler av systemet. Noen av delene er programvare, men de har grensesnitt mot de andre systemdelene som kan være maskinvare, personell og databaser. System engineering omfatter innsamling av krav på systemnivå, og noe analyse og konstruksjon på øverste nivå. Information engineering omfatter innsamling av krav på et overordnet (forretningsmessig, strategisk) nivå, og på de enkelte forretningsområdene Systemutvikling Kap.2. Prosessen 11 Systemutvikling Kap.2. Prosessen 12

3 Kravspesifikasjon (analyse) Samle inn krav til programvaren Identifisere info-domenet til programvaren Definerer krav til funksjoner, ytelse, grensesnitt (brukergrensesnitt osv.). Kravene til systemet og programvaren dokumenteres og gjennomgås med kundene Kravene bør nummereres slik at en kan henvise til dem senere i utviklingsprosessen. Konstruksjon (design) Konstruksjon av: Datastrukturer og databaser (E-R-diagram osv..) Programarkitektur Detaljert konstruksjon (innholdet i prosedyrene) Grensesnitt (GUI...) Konstruksjonen må dokumenteres slik at den kan kvalitetskontrolleres før koding starter. Den bør ha henvisning til kravspesifikasjonen. Systemutvikling Kap.2. Prosessen 13 Systemutvikling Kap.2. Prosessen 14 Koding (programmering) Koding kan foregå i et tradisjonelt språk som Pascal C++ Java. Eller utføres med 4.generasjonsverktøy. Testing Fokus i testingen er programmets logiske egenskaper: All kode skal testes! Ytre funksjonalitet (input gir rett output, d.v.s. oppfyller kravspesifikasjonen) Systemutvikling Kap.2. Prosessen 15 Systemutvikling Kap.2. Prosessen 16 Vedlikehold Rette feil Tilpasning til nye omgivelser Nye krav til forbedret funksjonalitet og ytelse Ulemper med fossefallsmodellen 1. Virkelige prosjekter følger sjelden den sekvensielle flyten i modellen. Det vil alltid forekomme iterasjoner (tilbakehopp, løkker). 2. Det er vanskelig for kunden å spesifisere alle krav eksplisitt. 3. Kunden må være tålmodig. Programmet er ikke tilgjengelig for kunden før til slutt (når testen er gjennomført). 4. Alvorlige feil oppdages sent. De er da vanskelig og kostbare å rette. 5. Det går lang tid fra kravspesifikasjonen er godkjent til levering, og kravene kan da ha endret seg. Men (varianter av) den klassiske livssyklus -modellen inneholder alt som må utføres i systemutviklingen, derfor er den mye brukt. Systemutvikling Kap.2. Prosessen 17 Systemutvikling Kap.2. Prosessen 18

4 2.5 Prototyping Det lages en forenklet modell av systemet (programvaren). Dette kan være: 1. PC-basert modell av brukergrensesnittet (for eksempel i Visual Basic) 2. En modell som inneholder deler av funksjonene som kreves i programmet 3. Et eksisterende program som utfører deler eller alle funksjonene som kreves, men som har egenskaper som må forbedres. Fremgangsmåte: 1. Innsamling av krav fra kunden. Def. overordnet mål. Snakk med Lag/revider 2. Rask konstruksjon av de kunden viktigste egenskapene. prototype 3. Lag første prototype 4. Evaluer prototypen (kunde/brukere) 5. Presisering/forbedring av kravene. Man går flere runder med forbedring av prototypen. Kundetest av prototypen Systemutvikling Kap.2. Prosessen Prototyping Prototypen brukes til å identifisere krav. Hva skjer med prototypen når den har tjent sin hensikt med hensyn til å identifisere krav? To alternativ: 1. Kast prototypen (anbefales av mange)! 2. Prototypen settes i drift som første versjon av programmet. Med gode verktøy kan mye av det som er laget i prototypen brukes i det endelige systemet (brukergrensesnitt, funksjonene osv.). Prototyping er velegnet og brukes mye i studentprosjekt! Systemutvikling Kap.2. Prosessen RAD-modellen RAD - Rapid Application Development (Rask utvikling av applikasjoner) er en lineær, sekvensiell utviklingsprosess som legger vekt på en svært kort utviklingssyklus. Man utnytter komponentbasert konstruksjon. Hvis kravene er klare, og prosjektområdet er begrenset, vil RAD prosessen gjøre at ei prosjektgruppe lager et fullt funksjonelt system på svært kort tid (60-90 dager). RAD brukes først og fremst i administrative systemer (information system application) RAD-modellen Analyse Delsystem 1 Delsystem Delsystem n Analyse Applikasjonsgenerering Prosessmodellering Datamodellering Applikasjonsgenerering Prosessmodellering Datamodellering dager Testing og overlevering Testing og overlevering dager Systemutvikling Kap.2. Prosessen 21 Systemutvikling Kap.2. Prosessen RAD-modellen 2.7 Evolusjonær systemutvikling Følgende faser inngår i RAD (se fig. 2.6): 1. Kartlegging (modellering) av forretningsområdet. Informasjonsflyten kartlegges. 2. Datamodellering. Dataobjekter (med attributter), relasjoner mellom dem (E-R- diagram). 3. Prosessmodellering. Det lages prosessbeskrivelser for å legge til, modifisere slette og hente frem dataobjekter. 4. Applikasjonsgenerering 5. Testing og overlevering (til kunden). I tilfeller der den linære modellen ikke passer kan en bruke modeller som tar hensyn til at produktet utvikler seg over tid (evolve..) De evolusjonære modellene er iterative (løkker). Det utvikles stadig mer komplette modeller. Systemutvikling Kap.2. Prosessen 23 Systemutvikling Kap.2. Prosessen 24

5 2.7.1 Den inkrementelle modellen Den inkrementelle modellen kombinerer elementer fra den linære, sekvensielle modellen (som brukes flere ganger), med den iterative filosofien til prototyping (se fig. 2.7) Hver linære sekvens produserer en ny versjon av programmet. Hver runde kan inneholde prototyping. Første versjon er ofte et kjerneprodukt med de viktigste funksjoner. Dette blir satt i drift hos kunden. Det lages en plan for neste versjon med endringer (feilrettinger etc.) og utvidelser (nye funksjoner). Det leveres ny versjon etter hvert inkrement. Dette fortsetter til produktet er komplett. Den inkrementelle modellen Utvikling av 1. versjon Utvikling av 2. versjon Levering av 1. versjon Utvikling av 3. versjon Levering av 2. versjon Levering av 3. versjon Tid Systemutvikling Kap.2. Prosessen 25 Systemutvikling Kap.2. Prosessen Den inkrementelle modellen Forskjellen fra prototyping er at hvert inkrement resulterer i en versjon som settes i drift hos kunden. Versjonene blir også evaluert av kunden. Modellen er godt egnet der det ikke er tilgjengelig nok personell til å lage et komplett system innen tidsfristen for prosjektet. Tidlige versjoner kan leveres med færre prosjektdeltagere i arbeid. Hvis første versjon blir godt mottatt, kan det settes på flere personer (hvis nødvendig) til å implementere neste versjon. Versjoner kan ta hensyn til teknisk risiko ved levering av nye maskiner. Vi lager første versjon for eksisterende maskiner, og neste versjon for nye. Systemutvikling Kap.2. Prosessen Spiralmodellen Spiralmodellen er en evolusjonær utviklingsmodell som kopler den iterative naturen til prototyping med de kontrollerte og systematiske egenskaper til den linære modellen. Den tilbyr rask utvikling av inkrementelle versjoner. De tidlige modellene kan være papirmodeller eller prototyper. De senerer versjoner er mer fullstendige. Modellen er delt inn i en rekke hovedaktiviteter ( framework activities ) som kalles task regions (oppgaveområder, sektorer). Det kan være fra 3 til 6 områder (sektorer). Systemutvikling Kap.2. Prosessen 28 Spiralmodellen Planlegging Spiralmodellen Kundekommunikasjon Innsamling av krav Prosjektstart Evaluering av kunde/ bruker Konstruksjon Risikoanalyse Engineering Fig. 2.8 viser en modell med 6 sektorer: 1. Kommunikasjon med kundene (og brukerne) 2. Planlegging: Målformulering, ressursfordeling, tids/ prosjektplan, alternativer og begrensninger. 3. Risikoanalyse (tekniske og prosjekt/administrative risiki). Analysere alternativer Identifisere risiki (forutse problemer) Planlegge tiltak 4. Engineering - prosjektere neste versjon (nivå) av produktet. 5. Konstruksjon og overlevering av produktet til kunden (testing, installasjon og brukerstøtte). 6. Kundeevaluering Systemutvikling Kap.2. Prosessen 29 Systemutvikling Kap.2. Prosessen 30

6 2.7.2 Spiralmodellen I hver sektor utføres et sett med oppgaver som er tilpasset det aktuelle prosjektet (små prosjekt: færre oppgaver, mindre formelt, store prosjekt: Flere oppgaver og mer formelt) I alle tilfeller utføres paraplyaktivitetene. Når prosessen starter, beveger prosjektet seg langs spiralen i klokkeretninger, innenfra og utover. Første runde kan resultere i utvikling av kravspesifikasjon. Andre runde kan være en prototype. Slik fortsetter en flere runder mot et mer ferdig produkt. I hver runde i planleggingssektoren justeres prosjektplanen (kostnader, tid, antall runder) Spiralmodellen Fig. 2.8 viser en startpunktakse der hver kube representerer startpunktet for forskjellige prosjekttyper. Kjernen (Concept Development Project) starter i sentrum og går nødvendige antall runder til konseptet er komplett. Neste kube: Prosjekt for utvikling av nytt produkt Et prosjekt kan ha hvileperioder, og så reaktiveres når det er behov for endringer Systemutvikling Kap.2. Prosessen 31 Systemutvikling Kap.2. Prosessen Sammensetning av komponenter Komponentbasert utvikling. Denne modellen brukes i objektorientert utvikling (kap. 20) Spiralmodellen Brukerkommunikasjon Innsamling av krav Planlegging Risikoanalyse Ja Hent komp. i bibliotek Identifiser Kandidatkomponenter Er komp. i bibliotek? Nei Lag ny Komp. Legg ny komp. i bibliotek Evaluering av kunde Konstruer n-te versjon av systemet Implementering Systemutvikling Kap.2. Prosessen 33 Systemutvikling Kap.2. Prosessen Fjerdegenerasjonsteknikker Automatisk generering av kode ut fra spesifikasjoner i et spesifikasjonsspråk. Bruker fjerdegenerasjonsspråk (4GL) Status for 4GL: Velegnet for administrative anvendelser (databaser etc., f.eks utviklet i Access) Redusert utviklingstid for små og middels store administrative systemer. Lite å vinne i store prosjekt p.g.a. omfattende kravspesifikasjon, konstruksjon og testing. Systemutvikling Kap.2. Prosessen 35