Systemutvikling - oppsummering Alexander Nossum alexander@nossum.net blog.eksplisitt.net 22. mai 2006
INNHOLD 2 Innhold 1 Utviklingsprosessmodeller 3 1.1 Fossefall/waterfall................................ 3 1.2 Spiral...................................... 3 1.3 Inkrementell/iterativ.............................. 3 1.4 Unified Process (UP).............................. 3 1.5 XP........................................ 3 1.6 Figurer til Utviklingsprosessmodeller..................... 5 2 Use-case 6 2.1 Definisjon.................................... 6 2.2 Tekstlig vs. diagram.............................. 6 3 klasser/klassediagram 6 3.1 Klassediagram og prosjektfaser........................ 6 3.1.1 Overgang fra tidlig fase til designfase................. 6 3.2 Tilstandsdiagram for klasser.......................... 6 4 Kostnad-/tidsestimering 7 4.1 Work Breakdown Structure (WBS)...................... 7 4.2 Ganttdiagram.................................. 7 5 Risikoanalyse 7 6 Testing 7 6.1 Enhetstesting vs. systemtesting........................ 8 6.2 Begreper i testing................................ 8 7 Arkitektur og patterns 8 7.1 Arkitekturer................................... 8 7.2 Patterns..................................... 9
1 Utviklingsprosessmodeller 3 1 Utviklingsprosessmodeller 1.1 Fossefall/waterfall Fossefallmodellen baserer seg på utvikling fra a til b. Konsept analyse/kravanalyse Analyse Design Implementasjon Enhetstesting Integrasjon Systemtesting Vedlikehold Dette er en lite foretrukket metode siden man ikke har mulighet for å gå bakover i prosessen. Hvis en feil oppstår og ikke blir oppdaget i en tidlig fase er faren for at den ikke blir oppdaget før i en sen, og kanksje for sen, fase stor. Kostnadene for å rette opp slike feil er svært stor! Punktene i fossefallsmetoden er forøvrig svært gode. 1.2 Spiral Spiralmetoden er i prinsippet den samme som fossefallsmetoden bortsett fra at alle delene i prosessen gjentar seg. Altså man går i spiral inn mot ett fullstendig produkt. I praksis vil dette si at man går igjennom kravanalysen, design, implementasjon og testing flere ganger. 1.3 Inkrementell/iterativ Inkrementell/iterativ utvikling er en videreføring av konseptet til spiral- og fossefallsmodellen. For hver del (iterasjon) av prosjektet gjentar man alle delene i fossefallsmodellen. Dette medfører en hyppig oppdatering av alle dokumenter og hver del er (i prinsippet) en garantert ferdig del. Som igjen fører til at feil blir oppdaget i en tidlig fase og kan dermed rettes opp uten noen store kostnader. Se figur [1]. 1.4 Unified Process (UP) UP baserer seg på inkrementell utvikling og er en metode for å strukturere arbeidsmengden som blir lagt ned i de forskjellige sekvensene i hver iterasjon. Se figur [2] og [3] 1.5 XP extreme Programming er en metode for å øke hastigheten på utviklingsprosessen. Under XP er mye av det formelle dokumentarbeidet lagt til side og det er et sterkt fokus på det som fungerer bra og det som faktisk bidrar til noe kunden kan få. Et eksempel er istedenfor å lage Use case i form av diagrammer og skjemaer legges det mer vekt på brukerhistorier.
1.5 XP 4 XP baserer seg på iterativ utvikling med svært korte inkrementer. Det som fungerer best gjøres så ofte som overhodet mulig! For eksempel hvis testing fungerer bra gjøres dette hver eneste dag. Kundeinteraksjon er sentralt i XP, ofte er en representant fra kunden med som prosjektdeltaker. Merk at dette ikke nødvendigvis trenger å være en som har utviklingserfaring men kan godt være en av de som faktisk skal bruke systemet. Et hovedprinsipp i XP er å gi kunden et produkt fortest mulig. Produktet trenger ikke være ferdigstilt, men kan godt være en hoveddel av produktet. I implementasjonsfasen er parprogrammering ofte brukt. Dette vil si at to mennesker sitter foran en pc og skriver kode. Dette har vist seg å være veldig effektivt selvom antall kodelinjer går ned vil kvaliteten på kodelinjene være mye bedre. Menneskelige hensyn må selvfølgelig taes med i betraktningen her. Fordeler ved XP er at kunden får tilbakemelding ekstremt fort. For eksempel en fungerende GUI uten funksjoner. Dermed kan kunden gi tilbakemeldinger på om dette fungerer bra eller ikke. Dette fører til at det ferdigstilte produktet er noe som er skreddesydd til kunden. Noe det ikke nødvendigvis blir ved en tradisjonell metode.
1.6 Figurer til Utviklingsprosessmodeller 5 1.6 Figurer til Utviklingsprosessmodeller Figur 1: Inkrementell utvikling Figur 2: UP-matrise Figur 3: UP s seks syn på systemet
2 Use-case 6 2 Use-case 2.1 Definisjon Et use-case diagram beskriver hvilke funksjoner som blir brukt ved et brukerscenario. For eksempel kravet/brukerscenarioet legg til ny bruker, bruker en rekke funksjoner. Usecaset beskriver hvilke funksjoner som blir brukt og hvem som bruker de. 2.2 Tekstlig vs. diagram Use-case-diagram er en grafisk framstilling av hva som skjer under et brukerscenario. Dette er ganske overordnet, men mer konkret enn et brukerscenario. Use-case-diagram er ofte nyttig for et første møte med kunden for at kunden og utvikler kan få en bedre felles forståelse av kravene. Dette forutsetter at kunden har noe bakgrunn i systemutvikling/ddatatenkning. Tekstlig use-case er en konkretisering av use-case-diagrammet. Her tar man for seg hvilken tilstand systemet er i, hva som skjer ved feil osv.. Tekstlig use-case er nyttig har stor nytte for utvikleren men liten til ingen nytte for normalekunden. For at kunden skal ha nytte av dette bør han ha en stor innsikt i systemutvikling/programmering. 3 klasser/klassediagram 3.1 Klassediagram og prosjektfaser Klassediagrammet forandrer seg iløpet av de forskjellige prosjektfasene. I begynnelsen er det ikke nødvendig med et fullstendig diagram, da holder det med de viktigste klassene og eventuelt samhandlingen mellom dem. Etter hvert må klassediagrammet bli mer detaljert med typisk de viktigste klassene og de viktigste metodene/attributtene. Før implementasjon må klassediagrammet være fullstendig med alle klasser/metoder/attributter. Denne metoden for å utvikle klassediagram er mest beregnet på store og omfattende systemer. Ved utvikling av de aller fleste små systemer vil man lage et fullstendig diagram helt i starten. 3.1.1 Overgang fra tidlig fase til designfase CRC-metoden CRC-metoden beskriver hva klassen skal være ansvarlig for, hva den skal hente hos andre klasser og hvilke metoder den trenger. Iterativ metode Bruker use-case (tekstlig og diagram) og sekvensdiagrammer for å bestemme hvilke metoder og attributter som trengs. 3.2 Tilstandsdiagram for klasser Klasser har dynamisk og statisk oppførsel, derfor kan det være nyttig å lage et diagram over hvilken tilstand en klasse er i under en gitt situasjon. Dette kan også være nyttig å vise kunde slik at han kan få en bedre forståelse av hva som blir laget.
4 Kostnad-/tidsestimering 7 4 Kostnad-/tidsestimering 4.1 Work Breakdown Structure (WBS) Work breakdown structure er en metode for å bryte ned arbeidspakker til mindre pakker slik at løvnodeneblir så små at de man lett kan ha oversikt over de, og tildele ansvar til pakkene. Det er også en fin måte å definere mer konkret hvilke aktiviteter som skal gjøres under en iterasjon. WBS blir framstilt som et tre. Typisk er rotnoden hele prosjektet, barnene til rotnoden er iterasjonene og videre er hva som skal gjøres under de forskjellige iterasjonene. Hver node har et beskrivende navn, dato for ferdigstillelse (deadline), tidsestimat og eventuelt hvem som har ansvaret for denne aktiviteten. 4.2 Ganttdiagram Ganttdiagram er et diagram for å dele opp og strukturere arbeidet i forhold til tiden. Slik at planleggingen av hva som skal gjøres når og hvem som skal gjøre det er klart definert. Det er også lettere å få oversikt over hvor mye tid man faktisk har tilgjengelig. Diagrammet er som oftest en tabell med tidsbolker og aktiviteter som i tabell 1. uke1 uke2 uke3 uke4 Aktivitet 1 2 2 (karen ferie) 2 1 Aktivitet 2 3 2 3 4 Team size 5 4 5 5 Tabell 1: Eksempel på ganttdiagram 5 Risikoanalyse Risikoanalyse går ut på å identifisere hva som kan gå galt, veie de opp mot hverandre (typisk skala 1 til 10) og finne ut hvor sannsynlig det er at det faktisk skjer. Deretter må det lages en retirement plan altså en plan for hva som skal gjøres hvis en risiko faktisk skjer. En retirement plan kan godt være: Avslutt prosjektet. Det viktige er at det eksisterer og at det har vært tenkt igjennom i begynnelsen av prosjektet. En god risikoanalyse for et prosjekt kan i tidlig fase være avgjørende for om vi faktisk skal gjennomføre det eller ikke. 6 Testing Konseptet med en test er å sjekke om systemet gjør det som er spesifisert i kravene. Alle krav må være oppfylt hvis ikke det er en særdeles god, og dokumentert grunn til at det ikke er oppfylt. Testen bør ta for seg alle mulige måter systemet kan fungere og hvordan det kan feile. Ved bevisst testing på feiling, for eksempel ved feil input fra bruker eller lignende, bør systemet gjøre noe fornuftig, for eksempel gi en tilbakemelding. Det bør ikke krasje helt, eller gi brukeren en stacktrace av noe kryptisk noe.
6.1 Enhetstesting vs. systemtesting 8 Testing bør lages ut i fra kravene Testene bør være basert på sunn fornuft og god systemutviklingsskikk Testene bør teste feilsituasjoner 6.1 Enhetstesting vs. systemtesting Enhetstesting Enhetstesting er når man tester en del (enhet) av systemet. Det kan for eksempel være en uavhengig modul, men det kan like godt være en klasse som avhenger av andre klasser. I så fall må testen sørge for å lage dummyklasser og input slik at man kan spore tilbake hva som faktisk skjer. Systemtesting Systemtesting er en full test av hele systemet. Det er ikke nødvendigvis slik at enhetene samarbeider sammen, selv om de har passert enhetstestingen. Ved full systemtest er det viktig å teste mest mulig av det som kan skje. Det er særdeles tidkrevende å teste alle mulige hendelser som kan skje med et system, derfor er det viktig å ha en god og strukturert plan over hva som skal testes og hva som ikke skal testes. Systemtesten kjøres naturligvis etter integrering av enheter. 6.2 Begreper i testing Brukervennlighet Hvor lett er det å lære seg systemet og hvor lett er det å gjøre de oppgavene man skal gjøre i systemet? En testmetode her er et praktisk eksperiment med brukere som er på forskjellige faglige nivåer. Hva gjør de? Var det hensikten? osv... Robusthet Systemet skal tåle alt. Det vil si, det skal tåle/hindre at brukeren gir feil input, feil i software/hardware skal ikke skade informasjonen som ligger der og det skal ikke være mulig for brukeren å krasje systemet. Dette er i praksis nesten umulig å få til og her gjelder det å sikte mot stjernene for å treffe bakken. Igjen er fornuftig testing noe som holder robustheten på et akseptabelt nivå. Vedlikeholdbarhet Er systemet lett å vedlikeholde? Er dette et system som skal vedlikeholdes? Hvor lett er det å finne/rette feil og hvor lett er det å gjøre endringer i systemet. Stabilitet Hvor stabilt er systemet i forhold til endringer? Vil funksjonaliteten bevares hvis det legges til nye funksjoner? Testbarhet Er det lett å gjennomføre tester på systemet? 7 Arkitektur og patterns 7.1 Arkitekturer Trelagsarkitektur Hovedideen er å abstrahere systemdelene på en logisk måte slik at de forskjellige delene kan virke mer eller mindre uavhengig av hverandre. En typisk trelagsarkitektur er å skille gui, logikk og lagring fra hverandre (se tabell 2). Dette fører til at man kan bytte lagringsmedium ved å endre kun på lagringspakken, altså at resten
7.2 Patterns 9 av systemet ikke merker noe. I praksis krever dette nokså generell programmering noe som lønner seg kun etter en liten stund. GUI Logikk Lagring (DB) Tabell 2: Eksempel trelagsarkitektur 7.2 Patterns Facade Hver pakke har en klasse som alene styrer kommunikasjonen mellom pakken og andre pakker/klasser. For eksempel DB klasser som er relativt uavhengige av hvilken DBMS som brukes. Factory En slags fasadeklasse for å lage nye objekter av klasser. Slik at brukeren ikke trenger å huske på alle de forskjellige klassene.