forelesning imt2243 7. februar 2006
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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”
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. ”
KravspeksifikasjonenVed 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.
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)
Kravspesifiseringsprosessen
Feasibilitystudy
Requirementselicitation and
analysisRequirementsspecification
Requirementsvalidation
Feasibilityreport
Systemmodels
User and systemrequirements
Requirementsdocument
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
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”
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
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.)
Viewpoints identification
Querybalance
Gettransactions
Cashwithdrawal
Transactionlog
Machinesupplies
Cardreturning
Remotesoftwareupgrade
Ordercheques
Userinterface
Accountinformation
Messagelog
Softwaresize Invalid
userSystem cost Printe
r Security
Cardretention
Stolencard
Orderstatement
Remotediagnostics
ReliabilityUpdateaccount
Fundstransfer
Messagepassing
Cardvalidation
Customerdatabase
Manager
Accountholder
Foreigncustomer
Hardwaremaintenance
Bankteller
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
Viewpoint service information
FOREIGNCUSTOMER
Withdraw cashQuery balance
Service list
Withdraw cashQuery balanceOrder chequesSend messageTransaction listOrder statementTransfer funds
Service list
Run diagnosticsAdd cashAdd paperSend message
Service list
ACCOUNTHOLDER
BANKTELLER
Detaljert kravanalyse
Requirementsvalidation
Domainunderstanding
Prioritization
Requirementscollection
Conflictresolution
Classification
Requirementsdefinition andspecification
Processentry
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.
Strukturert analyseMetoden 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.
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
Eksempel på en SYSTEMMODELL :
Klient
Kontoransatt
Tannlege
1. Registereklient
2. Mottatimebestilling
Klientregister
4. Genereredagsrapport
Klinikkdata
5. Registrereklinikkinfo 3. Generere
tjenestestatistikk
Timeregister
Timeforespørsel
Personalia
Klientinfo
KlientkodeTimer_idag
Kapasitet
Klinikkinfo
Klinikkinfo
Tjenesterapportgrunndata
Tjenesteliste
Timehistorikk
Tjenesteforespørsel
Dagsforespørsel
Dagsinforamsjon
Dagsrapportgrunndata
Timetilbakemelding
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
DFD
Prosess (funksjon)
Bearbeider/manipulerer input om til output
En prosessboble for hver funksjon i systemet
Navngis ut fra hva den ”gjør”
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
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
DFD
Terminator / Ekstern enhet
Viser kilder til / mottaker av informasjonsflyt i vårt system Kan være roller, interessenter, andre systemer etc.
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
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
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