Systemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006

Like dokumenter
Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

GJENNOMGANG UKESOPPGAVER 7 REPETISJON

Oppgave 1. Finn krav. Finn krav. Finn test

UNIVERSITETET I OSLO

GJENNOMGANG UKESOPPGAVER 9 TESTING

Eksamen i fag TDT4140 Systemutvikling. Tirsdag 27. mai 2004 kl

Eksamen i fag TDT4140 Systemutvikling. 22. mai, 2008 kl

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?

UML 1. Use case drevet analyse og design Kirsten Ribu

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG

UKE 9 Prosesser og prosessmodeller inkludert smidige metoder. Gruppetime INF1055

Løsningsforslag Sluttprøve 2015

Prosessmodeller og smidig programvareutvikling. INF1050: Gjennomgang, uke 02

Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling

Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling

Inf1055 Modul B 26 april 2017:

Forfattere: Daníelsdóttir, Drífa Meland, Maiken Mijalkovic, Biljana Svendsen, Simen H. Gruppelærer: Zarei, Amir Hossein. 5.

1. Mer om iterative utviklingsprosesser

Eksamen i fag TDT4140 Systemutvikling. 27. mai, 2011 kl

Eksamen INF

UNIVERSITETET I OSLO

Hensikten med denne delen av kurset. Objektorientering hva er det? Objektets egenskaper. Best practises ved programvareutvikling

Modellering av krav. INF1050: Systemutvikling 11. februar Universitetslektor Yngve Lindsjørn

Del - leveranse Del 2. Inf 2120 fredag Gruppe 1 Knut Johannes Dahle

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl Fakultet for fysikk, informatikk og matematikk

Kap 11 Planlegging og dokumentasjon s 310

Modellering av krav. INF1050: Systemutvikling 07. februar Førstelektor Yngve Lindsjørn

UNIVERSITETET I OSLO

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

Gruppenavn. Prosjektnavn Beskrivelse av design For Navn på systemet. Versjon <1.0>

Universitetet i Oslo Institutt for informatikk. Eskild Busch. UML hefte

Grunnleggende testteori

Eksamen i fag SIF8018 Systemutvikling. Fredag 25. mai 2001 kl

11 Planlegging og dokumentasjon

Forside. Eksamen i IN1030 for Våren Ingen hjelpemidler tillatt.

Oppsummering. Thomas Lohne Aanes Thomas Amble

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004

Systemutviklingen er ferdig når et system er operativt. Med operativt menes når systemet blir brukt av brukerne på et faktisk arbeidssted.

Prøveeksamen INF1050: Gjennomgang, uke 15

=Systemutviklingsprosjekt - WATCH - Gruppe 208=

Software Development Plan. Software Development Plan. Forum / Nettverkssamfunn Team 2

Innholdsfortegnelse INNHOLDSFORTEGNELSE... 2 REVISJONSOVERSIKT...4 INTRODUKSJON MED FORUTSETNINGER... 5

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

UKE 11 UML modellering og use case. Gruppetime INF1055

Testplan (Software Test Plan)

UKE 13 Mer UML modellering. Gruppetime INF1055 Julie Hagen Nilsen & Maria Stolinski

Eksamen i fag TDT4140 Systemutvikling. 6. juni, 2006 kl

Løsningsforslag: Oblig 1. INF1050: Gjennomgang, uke 12

Kravhåndtering. INF1050: Gjennomgang, uke 03

Kravspesifikasjon med UML use case modellering. Erik Arisholm

Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store. Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson

Læringsmål og pensum. Utvikling av informasjonssystemer. Oversikt. Systemutvikling Systemutvikling i seks faser Femstegs prosedyre for programmering

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?

Eksamen 2013 Løsningsforslag

TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS

Aktivitetskart. Fremdriftsplan: denne prosessen: Peder Sundbø. ferdigstilt uke 8. fastslåing av prosjekt. Magnus Eriksen. Uke 8.

1. Hvilke type krav angår sikkerhet og pålitelighet?

prosjektarbeid Forelesning 3 - INF1050 Systemutvikling

prosjektarbeid Forelesning 3 - INF1050 Systemutvikling Eksempel Evolusjonære modeller Utviklingsprosesser Evolusjonære modeller Foranalyse

Systemutviklingsmetoder

UML-Unified Modeling Language

Vakt og lønnssystem - Rema 1000

Oppfølgingsdokument. Kode januar 2004 GymPack. D Oppfølgingsdokument. Periode 009 Forfatter. Hanne Johnsen

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

Systemutviklingssprosesser, prosjektarbeid Forelesning 3 - INF1050 Systemutvikling 1. feb.2010

EKSAMEN 05HBINDA, 05HBINFA, 05HBISA, 05HBMETEA, 06HBINFA. Tom Røise. INNFØRING MED PENN, evt. trykkblyant som gir gjennomslag

Modellering IT konferanse

Programvareutvikling (store systemer)

Fra krav til modellering av objekter

INF1400. Tilstandsmaskin

INF Oblig 2. Hour Registration System (HRS)

Validering og verifisering. Kirsten Ribu

Objektorientering og UML. INF1050: Gjennomgang, uke 06

Inception Elaboration Construction Transition Bemanning 1 1,5 2 2 Varighet i uker Antall iterasjoner (lengde i uker i parentes) Tabell 1

Grunnleggende testteori

Oppgave 1 Multiple Choice

Databaser og moderne systemutvikling - dag én

Konfigurasjonsstyring. INF1050: Gjennomgang, uke 11

Test i Praksis. NTNU Februar Copyright 2014 Accenture All Rights Reserved.

Kap. 2 Prosessen. Utviklingsmodeller -2. Utviklingsmodeller. Utviklingsmodeller -4. Utviklingsmodeller - 3. Software Engineering - definisjoner

Introduksjon,l SCRUM. EB og TMG

Eksamen INF1050: Gjennomgang, uke 15

Oppgaver uke 42. Systemutvikling

Grunnleggende testteori. Etter Hans Schaefer

UNIVERSITETET I OSLO

INF2120 Prosjektoppgave i modellering. Del 1

Gruppenavn. Prosjektnavn Kravdokument For Navn på systemet. Versjon <1.0>

Mellom barken og veden Smidig testing i krevende terreng TTC 2015

Arne Maus, Ifi. med takk til Gerhard Skagstein(Ifi), Rune Steinberg, (Visma), Jo Hannay (Ifi), Ian Sommerville m. fl. for lån av gamle foiler

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO

UML- Use case drevet analyse og design. Domenemodeller Sekvensdiagrammer Use case realisering med GRASP patterns Klassediagram - designmodeller

Testing av programvare

INF 5120 Obligatorisk oppgave Nr 2

INF1400. Tilstandsmaskin

Use Case-modellering. INF1050: Gjennomgang, uke 04

SCRUM EB og TMG 2010

Prosjektrettet systemarbeid

Transkript:

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.