1 / 25

Forelesning IMT2243 7. Februar 2006

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

isabel
Download Presentation

Forelesning IMT2243 7. Februar 2006

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related