Forelesning IMT Februar 2006

Presentasjon om: "Forelesning IMT Februar 2006"— Utskrift av presentasjonen:

1 Forelesning IMT2243 7. Februar 2006
Tema : Kravspesifisering : produktet og prosessen Viewpoint – en ”myk” tilnærming, gunstig i den innledende runde med brukerkrav Tradisjonell analysemetode : Strukturert Analyse En arbeidsmetode som går dypere inn i spesifiseringen Pensum : Kap. 7 i Sommerville, Art.saml. ”SASD-modellen”

2 Kravspesifisering Kravspesifisering = arbeidet med å få frem en beskrivelse av oppdragsgiverens / kundens samlede krav til den nye programvaren på en strukturert, oversiktlig og forståelig måte. Beskrivelsen skal være på en form som blir forstått av de som skal utvikle løsningen. Målformuleringern i emnebeskrivelsen viser at dette temaet er svært sentralt i emnet : ”Studentene skal ha forståelse for grunnleggende administrative og teknologiske aspekter ved spesifisering, utvikling, innføring og vedlikehold av datasystemer.  De skal være i stand til å reflektere over IT-systemenes betydning for verdiskapningen i virksomheter og ulike tilnærmingsmåter i systemutviklingsprosesser. De skal kunne anvende metoder og teknikker for kravspesifisering og analyse. ”

3 Kravspeksifikasjonen
Ved utarbeidelsen av kravspesifikasjonsdokumentet står man overfor en avveining mellom å lage beskrivelser som er lesbare for mange interessenter og relativt raske å sette opp anvende strengt formalistiske spesifikasjonsteknikker som gir utvetydige krav Svært ofte praktiserer man bruk av ”Strukturert naturlig språk” i kombinasjon med anvendelse av enkelte grafiske notasjoner innen deler av spesifikasjonen.

4 Forts. Kravspesifikasjonen
Kravspesifikasjonsdokumentet bør dekke : Funksjonelle krav Ikke-funksjonelle krav (operasjonelle) Grensesnitt mot brukere, andres systemer og enheter Avgrensninger Dokumentet er sentralt som : Beslutningsgrunnlag for evt. videreføring av prosjektet. Vedlegg til en kontrakt mellom kunde og leverandør Utgangspunkt for alt designarbeid. I design finner man ut ”HVORDAN” beskrivelsene i kravspesifikasjonen best løses. Grunnlag for all testing (Planlegging, Utforming, Gjennomføring og oppfølging)

5 Kravspesifiseringsprosessen

6 Involverte i prosessen
Det er mange involverte parter i selve analysearbeidet - sluttbrukere, utviklere, ledere, leverandører - en analyseekspert bør ”dra i trådene” De involverte har et sterkt varierende forhold til og kunnskap om data Stor variasjon i motivasjonen hos deltagerne Arbeid i grupper, kombinert med individuell forberedelse Kreativitet innen et strukturert rammeverk en utfordring

7 Viewpoints – en “myk” spesifiseringsmetode
En arbeidsmetode der man forsøker å finne flest mulige aktuelle perspektiver på den nye løsningen For hvert viewpoint (perspektiv) forsøker man å identifisere dette viewpointet’s krav til programvaren God måte å få i gang arbeidet på, da fokusen er så intuitiv at alle kan delta konstruktivt uten ”forkunnskaper”

8 Fremgangsmåte for Viewpoints
1. Identifisere ulike viewpoints 2. Strukturere viewpoints Gruppere i viewpoint Avdekke overlapp og konflikter i viewpoints Lage hierarki 3. Dokumentere med viewpointbeskrivelser Metoden egner seg som en oppstart før man går dypere inn i en Strukturert Analyse eller Objektorientert Analyse

9 Steg 1 : Identifisering Brainstorming for å komme opp med ulike forhold rundt løsningen Se etter interessenter, brukergrupper, tjenester, komponenter, personer, organisasjonsenheter, hendelser, tilstander osv. rundt systemet Forsøk deretter å finne ut hvilke av disse som er viewpoints. Grupper / kategoriser også de andre ”idéene” som er dukket opp (ønskede tjenester, operative krav, komponenter, tilstander osv.)

10 Viewpoints identification

11 Steg 2 : Strukturering Gruppér de ulike viewpoints, se etter overlappinger Knytt de aktuelle tjenester til det enkelte viewpoint Gi en kortfattet beskrivelse av viewpointet Sett opp et viewpoint-hierarki

12 Viewpoint service information

13 Detaljert kravanalyse

14 Metodebruk i analysen Vi skal gjennomgå to hovedretninger av metoder til bruk i analysefasen : Strukturert Analyse (SA) Objektorientert Analyse (OOA) Metodebruk ”strammer inn” arbeidet i analysefasen, og brukt riktig vil resultatet bli en økt forståelse for oppgaven og et bedre spesifikasjonsdokument for hva som skal inngå i løsningen.

15 Strukturert analyse Metoden går ut på å anvende et sett teknikker i arbeidet med å lage gode systemmodeller /beskrivelser under spesifiseringsarbeidet. SA ble utformet på en tid der fossefall-modellen hadde utstrakt anvendelse, og man ofte hadde rasjonalisering som hovedmål ved utvikling av nye IT-systemer. Metoden er fortsatt relevant å anvende i spesifiseringsarbeid spesielt når man arbeider etter en sekvensiell utviklingsmodell. Særlig gjelder dette utvikling av ”funksjonsfokuserte” og transaksjons-orienterte løsninger der kravene er stabile over tid.

16 Strukturert analyse Metoden går ut på å anvende et sett teknikker i arbeidet med å lage gode systemmodeller/beskrivelser : Dataflytdiagrammer DataDictionary Datamodeller Strukturert språk (Structured Definition Language) Beslutningstrær SA er en funksjonsorientert metode : - finne funksjonene i systemet - kartlegge informasjonsflyten rundt funksjonene

17 Eksempel på en SYSTEMMODELL :

18 DataFlytDiagram En teknikk (innen Strukturert Analyse) som benyttes til å lage en systemmodell Funksjoner Informasjonsflyt Omgivelser Tegning av DFD er den første og mest sentrale aktiviteten i en Strukturert Analyse En systemmodell representert i et DFD gir en god oversikt og er forståelig for alle

19 DFD Prosess (funksjon) Bearbeider/manipulerer input om til output
En prosessboble for hver funksjon i systemet Navngis ut fra hva den ”gjør”

20 DFD Dataflyt (informasjonsflyt)
Viser hvordan data/informasjon flyter i systemet. Vi fokuserer på logiske modeller og flyt av modeller. DFD anvendes også til å vise flyt av ”fysiske elementer”. Modellen viser ikke rekkefølgen på flytene, bare retning Navngis Detaljspesifiseres i DataDictionary

21 DFD Datalager / register
Viser en samling av data som må ligge lagret i systemet Viser ikke hvordan dataene skal lagres Dataene ligger passive inntil de blir kalt opp Unngå registre uten ”inn” og ”ut” flyt Lengst mulig ned i DFD-strukturen

22 DFD Terminator / Ekstern enhet
Viser kilder til / mottaker av informasjonsflyt i vårt system Kan være roller, interessenter, andre systemer etc.

23 Nivåhåndteringen i DFD
Kontekstdiagram Viser omgivelsene til vårt system. Sentral informasjonsflyt til og fra systemet modelleres, og vil bidra til å klarlegge kravene til alle eksterne grensesnitt for vår løsning Nivå 0 Bryter ”systemboblen” fra kontekstdiagrammet ned i enkeltprosesser som samlet viser den sentrale funksjonalitet i systemet. DFD x (tall fra ) Er en detaljering av de mer komplekse dataprosessene på nivå 0

24 Tips ved utarbeidelse av DFD
1. Hold modellen på en side 2. Velg gode og meningsfulle navn - roller fremfor navn - navn på prosess = et verb + et objekt 3. Ikke lag modeller med mange elementer - mindre enn 10 prosesser - få registre (vi driver IKKE databasedesign her) 4. Ikke forsøk å ”si alt” med modellen, vis det viktige - lesbart og forståelig

25 Stegene videre innen Strukturert Analyse
Gå ikke videre med de andre teknikkene før dere har utarbeidet gode DFD’er på flere nivåer I de påfølgende stegene anvendes teknikker som : Data Dictionary – settes opp på Registre og Informasjonsflyter Strukturert Språk som detaljspesifiserer hver Prosess Beslutningstabeller som detaljspesifiserer beregninger etc. Datamodell (Semantisk) som viser forhold mellom informasjonselementer