Systemutvikling Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2004 1
Ulike typer prosessmodeller De røde er viktige i kurset: Evolusjonær (prototyping) Inkrementell (RUP) XP fossefall gjenbruksbasert spiral-modellen 2
Prosessmodell - faser Forstudium/ Feasability study (Hvilke muligheter har vi?) Kravspesifikasjon (Hva skal systemet gjøre?) Design (Hvordan skal systemet lages?) Programmering (Lage systemet) V&V (Validering og verifikasjon) / Testing Har vi bygd riktig system/produkt? (validering) Har vi bygd systemet/produktet riktig? (verifikasjon) Videreutvikling/Vedlikehold/Endring 3
Utviklingsmodeller En modell er en oversikt over utviklingsarbeidet Modellen beskriver hvilket arbeid som skal gjøres hvordan arbeidet skal inndeles i faser og aktiviteter og arbeidstrinn Det finnes mange forskjellige utviklingsmodeller Valg av modell er avhengig av: hvor store deler av systemutviklingsarbeidet modellen omfatter hvordan faser og aktiviteter er delt inn hvor fleksibel modellen er hvordan ansvaret og organiseringen skal gjøres 4
Oversikt over aktiviteter 5
Inkrementell utvikling 6
Inkrementell utvikling - fordeler Viktig funksjonalitet kan leveres tidlig Tidlige inkrementer kan være prototyper som avdekker krav for senere inkrementer Mindre risko for at prosjektet skal feile og ingenting leveres Funksjonalitet med høyest prioritet blir testet best. 7
Fossefallmodellen Requirements definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance Lite fleksibel inndeling i fastlagte steg Vanskelig å etterkomme kundens skiftende krav Modellen er bare anvendelig dersom kravene er tydelige og godt dokumenterte, og lette å forstå. 8
Evolusjonær utvikling Explorativ (utforskende) utvikling Arbeidet foregår sammen med kunden med å utvikle et ferdig produkt utfra et utkast til kravspesifikasjon Må starte med veldefinerte krav Prototyping Målet er å forstå systemkravene. Brukes når kravene er uklare, (for å tydeliggjøre kravene) Anvendbarhet: For små eller mellomstore systemer For deler av større systemer (f.eks brukergrensesnittet) For systemer med kort levetid. 9
Evolusjonær prototyping : fordeler og ulemper Fordeler: Raskere leveranse av systemet Brukerengasjement under utviklingen av systemet Systemet oppfyller brukerkravene, og brukerne blir mer dedikerte (føler eierskap til systemet) Ulemper Ofte dårlig strukturerte systemer Dårlig dokumentasjon 10
Extreme programming - XP En ny tilnærming til utvikling basert på utvikling og leveranse av svært små inkrementer (deler) Rask og kontinuerlig koding Brukermedvirkning i utviklingsteamet Parprogrammering Anvendbarhet: For mindre systemer 11
Best practises ved programvareutvikling Iterativ utvikling Håndtering av krav Bruk av komponentbasert arkitektur Visuell modellering Kontinuerlig verifisering av programvarekvaliteten Kontrollerte endringer i programvaren 12
The Rational Unified Process Prosessmodell som kombinerer best practises i software utvikling: Iterativ livssyklus Risikodrevet utvikling UP består av 4 faser: Inception gjennoførbarhetsanalyser, tidlige estimater Elaboration iterativ implementering av basisarkitektur, løsning av høyrisiko faktorer, identifikasjon av mesteparten av kravene Construction iterativ implementering av lavrisiko-elementer og forberedelser til innføring av systemet Transition beta-test og innføring 13
Oversikt over prosessen. Inception Elaboration Construction Transition Idefase Utdypning Konstruksjon Overgang Idefasen: Krav, omfang, lønnsomhet Utdypning: planlegging, krav, arkitektur, risiko, prototyping Konstruksjon: konstruksjon, implementering, testing Overgangsfasen: kvalitetskontroll, brukeropplæring 14
Grunnleggende UML Use case modellen Beskriver kravene til systemet Beskriver systemet sett fra kundens perspektiv Beskriver hva som skjer, ikke hvordan det skjer Use case er ikke objekt-orienterte, men beskrivelser av hendelsesforløp 15
Pre- og postbetingelser, triggere Prebetingelse: Må være sant før use caset starter (testbart). F.eks: Bruker er logget inn, bruker er registrert i systemet Postbetingelse: Testbar tilstand når use caset er ferdig. F.eks: Bruker har mottatt en e-post, eller Skjema er opprettet. Trigger: En hendelse som setter i gang use caset. F.eks: Kunde ønsker å bestille time 16
Use case modellering Use case modellen består av diagram og tekstlige beskrivelser som viser stegene i use caset Hvert use case steg beskriver en enkelthandling (transaksjon) mellom bruker og systemet Et komplett use case består av flere ulike hendelsesforløp (flyt, scenarier) 17
Detaljering i iterasjoner En overordnet use case modell består av diagram og en kort beskrivelse av alle use case En uformell modell har main success scenarier på de viktigste use case Variasjoner og feilsituasjoner (alternativ oppførsel) finnes ved hjelp av brainstorming Use casene detaljeres ut i flere iterasjoner til alle er komplette 18
Sekvensdiagrammer: fra krav til design Et UML sekvensdiagram viser hendelsesflyten i et use case viser interaksjoner (samarbeid) mellom objekter i systemet viser rekkefølgen på beskjedene som sendes mellom objektene kan brukes til å identifisere metodene til objektene i systemet 19
Domenemodell Domenemodellen tilhører analysefasen og er en representasjon av objekter i domenet. Domeneklassene gjenspeiler objekter i den virkelige verden, ikke systemkomponenter Lages i parallell med use case modellen Typisk informasjon om objektene: Assosiasjoner Attributter Multiplisitet 20
Designmodell - Design En designmodell viser systemklasser, ikke konseptuelle klasser som i domenemodellen Typisk informasjon er: Klasser, assosiasjoner, attributter, multiplisitet Grensesnitt Metoder Avhengigheter 21
Use case realisering En betegnelse fra Rational Unified Process (RUP) Beskriver forbindelsen mellom kravene uttrykt i use casene og objektdesignet som oppfyller disse kravene Beskriver hvordan scenariene i et use case realiseres gjennom objekter som samarbeider Illustreres med sekvensdiagrammer 22
Ikke-funksjonelle krav Eksempler på ikke-funksjonelle krav er krav til sikkerhet, ytelse, responstid, kostnader detaljer rundt hvilke hardware eller software komponenter som skal brukes Ikke-funksjonelle krav som gjelder et spesielt use case kan skrives i det use caset Ikke-funksjonelle krav som gjelder flere use case eller hele systemet beskrives i et eget dokument. 23
Objektdesign GRASP mønstre: Patterns of General Principles in Assigning Responsibilites: Ekspertprinsippet: La det objektet som har kunnskapen (dataene) også behandle den (Eksempel Spørreskjema ) Kontrollobjektprinsippet: Velg objekt som håndterer systemhendelser (Eksempel: SpørreskjemaHåndterer use case kontrollobjekt) Skaperprinsippet: Legg ansvar for å opprette et nytt objekt i klassen som må vite om det nye objektet (Eksempel: SpørreskjemaGenerator ) Høy kohesjon Et objekt skal bare ha ansvar for relaterte ting Lav kobling Et objekt skal ha samarbeid med et begrenset antall andre objekter 24
Kostnadsestimering Ingen enkel oppgave: Tidlige estimater baserer seg på ufulstendig informasjon i kravspesifikasjonen Man må kanskje benytte ny teknologi Det kan være ukjente folk i prosjektteamet Estimater kan være selvoppfyllende profetier: Estimatet bestemmer budsjettet produktet justeres for å holde budsjettet 25
Bottom-up vs. Top-down Bottom-up estimering begynner med komponentene på laveste nivå, og det lages et estimat for hver del. Bottom-up tilnærmingen setter sammen estimering av enkelttdeler til høynivå estimater. Top-down estimering begynner med det overordnede produkt Estimater for enkeltdelene regnes ut som deler (prosenter) av estimatet for hele systemet. 26
Prosentvis bottom-up estimering basert på empiri Prosjektledelse 20% Analyse: 15% Design: 20% Koding: 25% Testing 15% Systemintegrasjon 5% Totalt 100% 27
Hva er et brukergrensesnitt? Alle produkter har et brukergrensesnitt Eks: Pantemaskinen i butikken: Lys lyd, bevegelse Bil: menneske/maskin grensesnittet PC: Mer enn skjermbildet: mus, tastatur, og skjerm med diverse knapper for lys og lydkontroll 28
Brukerens rolle Utfordringer: å kjenne brukeren og dennes oppførsel Brukermedvirkning er viktig! I alle systemer er det brukeren som avgjør hvorvidt et system er en suksess eller ikke. God ide å bruke prototyping ved utforming av skjermbilder 29
Validering og verifikasjon hvorfor? Å sørge for at et datasystem tilfredsstiller brukerens behov For å kunne vurdere hva vi gjør og hvorfor vi gjør det Behov for verifikasjon øker med størrelsen på systemet Ca 1/3 av utviklingstiden brukes å testing, noen ganger opp til 50% Systemutvikling er en industriell prosess! 30
V&V: Validering: Bygger vi det riktige systemet? Snakke med brukerne Bruke use case modellen Verifikasjon: Bygger vi systemet riktig? Manuelle inspeksjonsmetoder Automatisert testing 31
Inspeksjon Dokumentgjennomgang Gjennomgang av dokumenter med formål å finne feil og mangler Hvem bør gjennomgå dokumentet? De som skal ha systemet De som skal bruke dokumentet De som har vært delaktige i utformingen av dokumentet Eksperter (rollen / forretningsområdet) Gjennomgang av kildekoden for å finne feil og mangler Funksjonelle feil (avvik fra design og kravspesifikasjon) Avvik fra kodestandard og retningslinjer (for eksempel navngiving av klasser) Tekniske feil Testbarhet (for eksempel dokumentasjonsmangler, muligheten for isolasjon, etc) 32
Typer testing Enhetstest Tester at komponenten (klassen) virker isolert Integrasjonstest Tester at komponenten (klassen) virker sammen med andre komponenter Betatest Utvalgte kunder tar i bruk systemet før offisiell lansering Akseptansetest Tester at systemet lar brukerne gjøre det de trenger Tester med reelle data Utføres gjerne i samarbeid mellom kunder og testere Systemtest Tester at systemet oppfører seg korrekt i samspill med omgivelsene 33
Type testing forts. Ytelsestest (tester ytelse = hastigheten på én transaksjon) Stresstest (overbelastningstest) (tester skalerbarhet = hastigheten på mange samtidige transaksjoner) Recoverability-test (tester systemets håndtering av uforutsette avbrudd) 34
Black- og white-box testing Komponent Inndata Utdata Black box: Gir input forventet output? Komponent Inndata Xxxxx xxxxx Utdata White box: Følger hvert trinn i komponenten. Midlertidige utskrifter. 35
Testing med use case ne Bruk use case beskrivelsene som test cases. Viktig: At use casene oppdateres ved alle endringer Test pre- og postbetingelsene Test at all beskrevet funksjonalitet er på plass ved gå gjennom hvert use case Test alle feilsituasjoner og alternativ oppførsel 36
Hva er konfigurasjonsstyring Konfigurasjonsstyring disiplin for å håndtere endringer og ulike versjoner av komponenter Konfigurasjonsstyringsverktøy støtter håndtering av versjoner av komponentene og i å konfigurere (sette sammen) et system Hvordan håndtere versjoner og releaser? Hvordan håndtere endringer? Merk: Nye versjoner av et programsystem lages etter hvert som det endres Konfigurasjonsstyring støtter evolusjon av systemer på en kontrollert måte Helt avgjørende i nærmest all industriell programvareutvikling Likevel finnes nesten ingen kompetanse om dette hos nyutdannete kandidater fra universitet/høyskole (Unntak: Hio! ) 37
Takk for nå! Ingen undervisning neste uke, men lærer er tilgjengelig. Lykke til med innleveringen! 38