Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2005 Systemutvikling Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2005

Ulike typer prosessmodeller De røde er viktige i kurset: Evolusjonær (prototyping) Inkrementell (RUP) XP fossefall gjenbruksbasert spiral-modellen

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

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

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.

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

’Best practises’ ved programvareutvikling Iterativ utvikling Håndtering av krav Bruk av komponentbasert arkitektur Visuell modellering Kontinuerlig verifisering av programvarekvaliteten Kontrollerte endringer i programvaren

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

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

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

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

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

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.

Prosentvis bottom-up estimering basert på empiri Prosjektledelse 20% Analyse: 15% Design: 20% Koding: 25% Testing 15% Systemintegrasjon 5% Totalt 100%

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!

V&V: Validering: “Bygger vi det riktige systemet?” Snakke med brukerne Bruke use case modellen Verifikasjon: “Bygger vi systemet riktig?” Manuelle inspeksjonsmetoder Automatisert testing

Typer testing Enhetstest Integrasjonstest Betatest Akseptansetest 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

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)

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

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

Takk for nå! Gruppetime i dag og fredag Lykke til med innleveringen! Hva betyr

Løsning Rebus: Kvinnenavn M