Forelesning IMT2243 7. Februar 2006

1. Forelesning IMT22437. 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 1 - ..) • 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