Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

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

Liknende presentasjoner


Presentasjon om: "1 Systemutvikling Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2005."— Utskrift av presentasjonen:

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

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

3 3 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

4 4 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

5 5 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.

6 6 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

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

8 8 Oversikt over prosessen Idefasen: Krav, omfang, lønnsomhet Utdypning: planlegging, krav, arkitektur, risiko, prototyping Konstruksjon: konstruksjon, implementering, testing Overgangsfasen: kvalitetskontroll, brukeropplæring …………. Inception Elaboration Construction Transition Idefase Utdypning Konstruksjon Overgang

9 9 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

10 10 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

11 11 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

12 12 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

13 13 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.

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

15 15 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!

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

17 17 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

18 18 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)

19 19 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

20 20 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

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

22 22 Løsning Rebus: Kvinnenavn M


Laste ned ppt "1 Systemutvikling Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2005."

Liknende presentasjoner


Annonser fra Google