Systemutvikling

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

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

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. 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. 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. 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. ’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. 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. 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. 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. 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. 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 selvoppfyllendeprofetier: • Estimatet bestemmer budsjettet • produktet justeres for å holde budsjettet

13. Bottom-up vs. Top-down • Bottom-up estimering begynner med komponentene på laveste nivå, og det lages et estimat for hver del. • Bottom-uptilnæ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. Prosentvis bottom-up estimering basert på empiri • Prosjektledelse 20% • Analyse: 15% • Design: 20% • Koding: 25% • Testing 15% • Systemintegrasjon 5% • Totalt 100%

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. 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. 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. 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. 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. 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. Takk for nå! • Gruppetime i dag og fredag • Lykke til med innleveringen! • Hva betyr

22. Løsning • Rebus: Kvinnenavn M