Kap. 11 Analysemodeller og -prinsipper Analysis Concepts and principles

Transkript

1 Kap. 11 Analysemodeller og -prinsipper Analysis Concepts and principles 11.1 Kravanalyse (kravspesifikajon) 11.2 Kommunikasjonsteknikker 11.3 Analyseprinsipper 11.4 Prototyping 11.5 Spesifikasjon 11.6 Spesifikasjonsgjennomgang Systemutvikling Kap. 11 Analysemodeller og -prinsipper Kravanalyse Kravanalysen skal være et bindeledd mellom systemnivå og programkonstruksjon. Innhold: 1. Spesifisere programfunksjoner og ytelse 2. Definere grensesnitt mot andre systemelementer. 3. Spesifisere rammebetingelser som programvaren må oppfylle. 4. Lage modeller av prosessen, data og omgivelser Edbsystem utviklng Programvar kravanalyse Programvare konstruksjon Fig Overlapp av analyseoppgaver Systemutvikling Kap. 11 Analysemodeller og -prinsipper Kravanalyse -2 Vi lager en representasjon av informasjon og funksjon som kan oversettes til konstruksjon av: Data Arkitektur Prosedyrer 11.1 Kravanalyse -3 Kravanalysen kan deles i 5 tema: 1. Problemkartlegging 2. Evaluering og syntese (sammensetning) 3. Modellering 4. Spesifikasjon 5. Gjennomgang (review) Systemutvikling Kap. 11 Analysemodeller og -prinsipper 3 Systemutvikling Kap. 11 Analysemodeller og -prinsipper Kravanalyse -4 Først studeres systemspesifikajonen for å forstå systemet og gjennomgå omfanget av programvaren og grunnlaget for planestimatene. Deretter må analytikeren (systemereren) arbeide for å forstå problemet. Det må opprettes kontakt mellom ledelsen og teknisk personale hos brukerens/kundens organisasjon, og utviklingsorganisasjonen. Prosjektlederen sørger for å etablere kommunikasjonsveiene. Målet med analysen er å kartlegge de fundamentale (viktigste) problemene slik bruker/kunde oppfatter dem. Problemevaluering og løsning er neste hovedinnsatsområde Kravanalyse -5 Systemereren må: Evaluere flyt og innhold av informasjon Definere og detaljutforme programfunksjonene Forstå programmets oppførsel som følge av hendelser som påvirker systemet Definere systemgrensesnitt Avdekke konstruksjonsbegrensninger Alt dette gjøres for å beskrive problemet slik at en total løsning (tilnærming) kan settes sammen (syntetiseres). Eks. Lagerkontrollsystem for bildeler:. Systemutvikling Kap. 11 Analysemodeller og -prinsipper 5 Systemutvikling Kap. 11 Analysemodeller og -prinsipper 6

2 11.1 Kravanalyse -6 Under evaluering og syntese fokuserer systemereren på hva/hvilke (ikke hvordan): Hvilke data produseres/konsumerer systemet? Hvilke funksjoner må systemet utføre? Hvilke rammebetingelse (begrensninger) settes? Under evaluerings- og løsningsprosessen lager systemereren modeller av systemet. Modellen er grunnlag for kravspesifikasjon og programvarekonstruksjon Det kan også lages en prototype som del av kravanalysen. Kravspesifikasjonen lages i fellesskap av utviklerne og kunder. Den må gjennomgås og forbedres Innsamling av krav til programvare (Requirement elicitation for software) Før vi kan utføre analyse og lage modeller, må kravene samles inn. Prosessen starter ved at en kunde har et problem (som kan løses med programvare). Utvikler (person/firma) svare med (ofte med å si at dette skal nok gå bra!!) I kravanalysen er det først og fremst kommunikasjon mellom kunden og systemereren. Systemutvikling Kap. 11 Analysemodeller og -prinsipper 7 Systemutvikling Kap. 11 Analysemodeller og -prinsipper Initialisering av prosessen Kontakten starter med et innledende møte der målet er å få en fundamental forståelse av problemene. Systemereren starter med en del generelle spørsmål som fokuserer på kunden, det overordnede mål og fordeler, f.eks: Hvem står bak forespørselen om oppdraget? Hvem vil bruke systemet (løsninga)? Hvilke økonomiske fordeler har løsninga? Er det andre kilder til løsninga som du har behov for? Initialisering av prosessen -2 Neste sett spørsmål er for å få bedre forståelse av problemet og kunden, og få kundens synspunkter på en løsning: Hvordan beskriver du gode resultater (output) fra en vellykket løsning? Hvilke problemer løses med denne løsning? Kan du beskrive miljøet der denne løsningen kan brukes? Er det spesielle ytelsesforhold eller begrensninger som påvirker løsningsmåten? Disse spørsmålene identifiserer alle som vil ha interesse av systemet ( Steakholders - interessenter ) De identifiserer også målbare fordeler av en vellykket implementering, og eventuelle alternativer til egen utvikling (hyllevare). Systemutvikling Kap. 11 Analysemodeller og -prinsipper 9 Systemutvikling Kap. 11 Analysemodeller og -prinsipper Initialisering av prosessen -3 Det siste sett spørsmål fokuserer på effektiviteten av møtet. Dette kalles metaspørsmål som f.eks: Er du rette person til å svar på dette spørsmålet? Er dine svar offisielle? Er mine spørsmål relevante for problemene du har? Stiller jeg for mange spørsmål? Er det andre som kan gi tilleggsinformasjon? Er det noe mer jeg bør spørre deg om? Disse spørsmålene brukes innledningsvis for å komme i gang. På senere møter er møteformen kombinasjoner av problemløsning, forhandlinger, og spesifikasjon FAST - Facilitated Application Specification Techniques (Spesifikasjonsteknikker) Målet med teknikkene og metodene er å unngå misforståelser og at viktig informasjon utelates. FAST er en gruppeorientert teknikk for å samle inn krav. Den brukes i de tidlige stadier av analyse og spesifikasjon. Det dannes en gruppe (et team) med representanter for kunder og systemerere som skal arbeide sammen om å identifisere problemet foreslå deler av løsninga foreslå og vurdere forskjellige løsninger spesifisere et foreløpig sett med krav til løsningen De starter med et møte (gjerne flere dager) på et sted der de kan arbeide uforstyrret. Systemutvikling Kap. 11 Analysemodeller og -prinsipper 11 Systemutvikling Kap. 11 Analysemodeller og -prinsipper 12

3 Requirements Gathering Facilitated Application Specification Techniques Gruppering av kvalitetsfunksjoner (Quality Function Deployment) Software Engineering Group Customer Group Gruppering av kvalitetsfunksjoner (QFD - Quality Function Deployment) er en kvalitetsledelsesteknikk som overfører kundens behov til tekniske krav til programvare. Teknikken er utviklet i Japan på 70-tallet, og fokuserer på maksimal kundetilfredshet. QFD legger vekt på å forstå hva som er av verdi for kunden, og grupperer (fordeler) disse verdiene gjennom utviklingsprosessen. Systemutvikling Kap. 11 Analysemodeller og -prinsipper 13 Systemutvikling Kap. 11 Analysemodeller og -prinsipper Gruppering av kvalitetsfunksjoner (Quality Function Deployment) -2 QFD påviser 3 typer krav: 1. Normale krav. Mål for produkt eller system spesifiseres i møter med kunden. Kunden er fornøyd hvis disse kravene er oppfylt (krav til display, funksjoner, ytelse). 2. Forventede krav. Krav som er implisitt for produktet eller systemet, og som er så fundamentale (selvfølgelige) for kunden, at de ikke spesifiseres eksplisitt. Fravær av slike egenskaper vil føre til betydelig misnøye. Slike krav kan være brukervennlighet, virker korrekt og pålitelighet, og lett å installere. 3. Forbedrende krav. Dette er egenskaper utover kundens forventning, og som er svært tilfredsstillende når de er tilstede. (Ekstrafunksjoner) Systemutvikling Kap. 11 Analysemodeller og -prinsipper Analyseprinsipper Det er mange forskjellige analyse- og spesifikasjonsmetoder. Hver metode har sin notasjon (symbolbruk) og fremgangsmåte. Alle analysemetoder bygger på et sett av felles, fundamentale prinsipper: 1. Informasjonsdomenet for et problem må representeres og forstås (Hva er systemet, omgivelser, grensesnitt?) 2. Funksjonene som systemet skal utføre må defineres. 3. Systemets oppførsel (virkemåte, som følge av eksterne hendelser), må representeres. 4. Modellene som avbilder informasjon, funksjoner, og oppførsel må deles opp på en slik måte at detaljer avdekkes på en lagdelt eller hierarkisk måte. 5. Analyseprosessen går fra essensiell (logisk) informasjon mot implementasjonsmessige detaljer. Systemutvikling Kap. 11 Analysemodeller og -prinsipper Analyseprinsipper -2 I tillegg til analyseprinsippene, anbefales følgende rettledende prinsipper: Forstå problemet før du starter med å lage en analysemodell. Lag prototyper som gjør brukeren i stand til å forstå hvordan menneske - maskin interaksjon vil foregå. Registrer opprinnelsen og årsaken til hvert krav. Vis flere synsvinkler på kravene. Prioriter kravene. Arbeid for å fjerne tvetydighet Informasjonsdomenet Programvare prosesserer data: Data overføres ( P- prosesseres) fra en form (I - input) til en annen (O - output) Programvare prosesserer hendelser (events). En event representerer et aspekt av systemkontroll, ofte logiske (boolske) størrelser (av/på, true/false), f.eks. trykksensorer og termostater slås av (eller på) når en kritisk verdi nås. Både data (tall, tegn, bilder, lyd osv.) og kontroll (events) er innenfor (en del av) informasjonsdomenet til problemet. I P O Systemutvikling Kap. 11 Analysemodeller og -prinsipper 17 Systemutvikling Kap. 11 Analysemodeller og -prinsipper 18

4 Informasjonsdomenet -2 Informasjonsdomenet har 3 forskjellige synspunkt på data og kontroll når de prosesseres av et program: 1. Informasjonsflyt 2. Informasjonsinnhold 3. Informasjonsstruktur Vi skal se nærmere på hver av de tre Informasjonsdomenet -3 Informasjonsflyt representerer måten data og kontroll endrer seg på når de beveger seg gjennom systemet (fig. 11.3). Transformasjonene er funksjoner eller subfunksjoner som programmet utfører. Data og kontroll som beveger seg mellom to transformasjoner (funksjoner) definerer grensesnittet til hver funksjon. Informasjonsinnholdet representerer de individuelle data og kontrollenhetene (items) som utgjør en større informasjonsenhet. F.eks. flere felt settes sammen til en post (navn, adr ), en bitstreng definerer systemstatus, der hver bit representer status for en enhet (av/på). Systemutvikling Kap. 11 Analysemodeller og -prinsipper 19 Systemutvikling Kap. 11 Analysemodeller og -prinsipper Informasjonsdomenet -4 Informasjonsstruktur representerer den interne organisering av forskjellige data og kontrollenheter (items). F.eks. n-dimensjonal tabell eller hierarkisk trestruktur Relasjoner mellom informasjonsenheter Kan all info representeres i en struktur, eller må det være flere spesielle? Hvordan er relasjonene mellom informasjonsstrukturene? Datastrukturer refererer til konstruksjon og implementasjon av info-strukturer med programvare Modellering Vi lager modeller for å få bedre forståelse av enheten vi skal bygge. Modeller av programvare må vise informasjonen som skal transformeres, funksjonene som utfører transformasjonene, og oppførselen til systemet mens transformasjonene foregår. I kravanalysen lager vi modeller av systemet som fokuserer på hva systemet skal utføre. Vi bruker grafiske beskrivelser som viser informasjon, prosessering, systemoppførsel og andre karakteristikker med bestemte symboler (ikoner). I tillegg brukes tekstbeskrivelse, enten med naturlig språk, eller med spesielle språk for kravspesifikasjon. Systemutvikling Kap. 11 Analysemodeller og -prinsipper 21 Systemutvikling Kap. 11 Analysemodeller og -prinsipper Modellering -2 De neste to analyseoperasjonene er å lage: Funksjonelle modeller. Funksjoner kan deles i input, prosessering og output (-funksjoner). Modellen starter med en enkel overordnet modell (kontekst, bare navn på funksjonene). Gjennom flere iterasjoner vises flere detaljer, inntil en nøyaktig tegning/modell der alle funksjonene er representert. Modeller av oppførsel (virkemåte) viser hvordan systemet reagerer på ytre påvirkning. Et program er alltid i en tilstand (venter, beregner, skriver, ber om info osv.). Det skifter tilstand som følge av ytre hendelser (events). Modellen viser en representasjon av systemets tilstander, og hendelsene som fører til endring av tilstand Modellering -3 Modellene som lages under kravanalysen har flere viktige roller: Hjelper til forståelse av informasjon funksjoner oppførselen til systemet Modellen brukes til gjennomganger (reviews), og er derfor nøkkelen til å avgjøre om systemet er: komplett konsistent (ingen selvmotsigelser) nøyaktig i forhold til spesifikasjon. Systemutvikling Kap. 11 Analysemodeller og -prinsipper 23 Systemutvikling Kap. 11 Analysemodeller og -prinsipper 24

5 Modellering -4 Modellen er grunnlaget for konstruksjon, da den gir en representasjon av programvaren som kan avbildes ( mappes ) inn i implementasjonen. Vi skal presentere modelleringsmetoder i det følgende Oppdeling (Partitioning) Problemer er ofte så store og kompliserte at de ikke kan forstås som en helhet. Slike problemer deles derfor opp i deler som lett kan forstås. Deretter definerer vi grensesnitt mellom delene, slik at den totale funksjonen kan utføres. Informasjonen eller funksjonen kan deles opp hierarkisk: 1. Vertikalt ved å vise økt detaljering ved å gå nedover i hierarkiet. 2. Funksjonell dekomponering av problemet ved å bevege seg horisontalt i hierarkiet. Fig viser kontrollpanel med tastatur, display og kontroll-lamper. Fig viser horisontal dekomponering. Fig viser vertikal dekomponering av monitorering av sensorer. Systemutvikling Kap. 11 Analysemodeller og -prinsipper 25 Systemutvikling Kap. 11 Analysemodeller og -prinsipper Prototyping (Software Prototyping) Analyse må utføres uansett utviklingsmodell, og formen på analysen kan variere. F. eks. kan en bruke generelle (grunnleggende) analyseprinsipper, og lage en papirspesifikasjon av programvaren som et grunnlag for konstruksjon. I andre sammenhenger kan en bruke FAST eller andre brainstormings-teknikker (kreative teknikker). Deretter kan det bygges en prototype som er en modell av programvaren. Prototypen forbedres gradvis i samarbeid mellom utvikler og kunde i retning av produksjonsprogramvare. Prototyping kan kombineres med andre analysemetoder Valg av prototyping (Selecting the Prototyping Approach) Vi kan velge mellom to prototypingsmåter: 1. Prototypen kastes etter bruk. Den brukes bare til å påvise krav. 2. Evolusjonær prototyping. Her brukes prototypen som første del av en analyseaktivitet som vil fortsette inn i konstruksjon og implementering, og blir første versjon av det ferdige system. Vi velger prototypingsstrategi ut fra anvendelsesområde, kompleksitet, kundekarakteristikk og prosjektkarakteristikk. Det er også viktig at kunden 1) setter av tid til evaluering og forbedring av prototypen, og 2) er i stand til å ta beslutninger om kravene i rett tid (fortløpende). Systemutvikling Kap. 11 Analysemodeller og -prinsipper 27 Systemutvikling Kap. 11 Analysemodeller og -prinsipper Prototypingsmetoder og -verktøy Rapid prototyping (rask prototyping) Det er tre metoder og verktøy som brukes: 1. Fjerdegenerasjonsteknikker (-språk): Basert på databasesystem med spørre- og rapporteringsspråk. Program- og applikasjonsgeneratorer Høynivå ikke-prosedyreorienterte språk Vanligst for administrative anvendelser Prototypingsmetoder og -verktøy Gjenbruk av programmoduler (reusable software components). Modulene settes sammen. De kan være: Databaser (strukturer) Programkomponenter Prosedyrer Modulene må kunne brukes uten kjennskap til interne detaljer. Dette krever bibliotek og kataloger over programkomponenter. ( reusable er et motebegrep!) Et eksisterende program kan også brukes som prototype. Systemutvikling Kap. 11 Analysemodeller og -prinsipper 29 Systemutvikling Kap. 11 Analysemodeller og -prinsipper 30

6 Prototypingsmetoder og -verktøy Formell spesifikasjon- og prototypingsmiljø er basert på formelle spesifikasjonsspråk og -verktøy: 1. Systemereren lager (interaktivt) en språkbasert spesifikasjon av systemet (programvaren). 2. Bruker automatiske verktøy som oversetter spesifikasjonen til eksekverbar kode. 3. Brukeren kjører prototypen, og forbedringer skrives inn i spesifikasjonen (i språket) Spesifikasjon Kvaliteten på løsninga er avhengig av spesifikasjonen. Forskjellige former for spesifikasjon: Dokument (på papir) Maskinbasert (med CASE-verktøy) Grafisk beskrivelse (Dataflytdiagram etc..) Tekstbeskrivelse (vanlig språk) Prototype - en eksekverbar spesifikasjon Formelle spesifikasjoner skrevet i spesifikasjonsspråk Systemutvikling Kap. 11 Analysemodeller og -prinsipper 31 Systemutvikling Kap. 11 Analysemodeller og -prinsipper Spesifikasjonsprinsipper Boka viser 7 prinsipper for god spesifikasjon: 1. Hold spesifikasjon og implementasjon adskilt. 2. Lag en modell av systemets (ønskede) oppførsel som omfatter data og funksjonelle responser på forskjellige stimuli fra omgivelsene. 3. Bestem konteksten (sammenhengen) som systemet opererer i, ved å spesifisere hvordan systemet interagerer (kommuniserer) med andre systemkomponenter. 4. Definer miljøet (omgivelsene) som systemet virker i, og påvis hvordan systemet skal reagere på stimuli fra omgivelsene Spesifikasjonsprinsipper Lag en kognitiv (kunnskapsbasert, abstrakt) modell, (ikke en konstruksjons- eller implementasjonsmodell). 6. Systemspesifikasjonen må være tolerant for ufullstendighet, og den må kunne utvides. Den er en modell, en abstraksjon av en reell situasjon. Modellen vil ha flere detaljeringsnivå. Ingen spesifikasjon er komplett! 7. Lag innhold og struktur i spesifikasjonen slik at det er lett å gjøre endringer. Systemutvikling Kap. 11 Analysemodeller og -prinsipper 33 Systemutvikling Kap. 11 Analysemodeller og -prinsipper Representasjon Generelle retningslinjer: 1. Representasjonsformatet og innhold må være relevant for problemet. Man kan ha en generell disposisjon for en kravspesifikasjon, men den må alltid tilpasses anvendelsesområdet. 2. Informasjonen i spesifikasjonen må (bør) være hierarkisk (eller lagdelt), slik at leseren kan velge relevant detaljeringsnivå. Samme informasjon må representeres på forskjellig detaljnivå. 3. Diagrammer og andre notasjonsformer må begrenses i antall og konsistent i bruk. Symbolet har forskjellig tolkningsmuligheter: Representasjon Representasjonen må være reviderbar. Innholdet i spesifikasjonen vil alltid bli endret!! CASE-verktøy bør være tilgjengelig for å oppdatere all representasjon som påvirkes av hver endring (administrere versjoner). Symbolbruk og utforming påvirker forståelsen. Hver utvikler (systemerer) har sine preferanser. Systemutvikling Kap. 11 Analysemodeller og -prinsipper 35 Systemutvikling Kap. 11 Analysemodeller og -prinsipper 36

7 Kravspesifikasjon Kravspesifikasjonen er sluttproduktet av analysen (På norsk kalles ofte hele fasen for kravspesifikasjon). Den må inneholde: Komplett informasjonsbeskrivelse Detaljert funksjonell beskrivelse Ytelseskrav Konstruksjonsbegrensninger Valideringskriterier osv... Mange organisasjoner (f.eks. IEEE, DOD, ESA m.fl..) har egne formater/innholdsfortegnelse for kravspesifikasjon. Vi viser en norsk versjon fra Håndbok i systemarbeid Hvert krav bør nummereres, slik at det er lett å henvise til i det videre arbeidet. Innhold i kravspesifikasjon (Håndbok i systemarbeid) 1. Innledning Beskrivelse av hvem som er oppdragsgiver, styringsgruppe, prosjektgruppe, brukere m.m. Organisering av dokumentet 2. Overordnet systembeskrivelse 2.1 Hensikten med systemet Nye systemer Oppgradering av eksisterende kapasitet Fjerning av eksisterende begrensninger Fjerning av unødvendige operasjoner 2.2 Kort overordnet beskrivelse av det nye systemet Oversiktsfigur som viser delsystemer og dataflyt 2.3 Organisatoriske og personellmessige konsekvenser Beskrivelse av endringer i organisasjon, oppgaver, ansvar m.m. og begrunnelse for disse. Systemutvikling Kap. 11 Analysemodeller og -prinsipper 37 Systemutvikling Kap. 11 Analysemodeller og -prinsipper 38 Innhold i kravspesifikasjon Rammekrav Tilgjengelighet Datasikkerhet Kapasitet Fremtidige utvidelser Brukervennlighet Nøyaktighet 4. Systemets funksjonelle egenskaper For hvert delsystem gis en detaljert beskrivelse av funksjoner. For hver av disse spesifiseres: Hva funksjonen skal gjøre Eksempel på skjermbilder og rapporter Inndata med beskrivelse av felter Inndatavolum Utdatavolum Antatt bruksfrekvens Krav til behandlingstider 5. Logisk datamodell En beskrivelse av den logiske sammenhengen mellom datasettene ved hjelp av datamodeller. Systemutvikling Kap. 11 Analysemodeller og -prinsipper 39 Innhold i kravspesifikasjon Krav til systemkonstruksjon Beskrivelse av eksisterende utstyr som skal benyttes Krav til nytt utstyr Servicekrav Antall og plassering av utstyr Basis programvare som operativsystem, databasesystem, kommunikasjonsprogramvare m.m. 7. Krav til dokumentasjon En beskrivelse av krav til brukerdokumentasjon, operatørdokumentasjon og systemdokumentasjon. 8. Krav til manuelle funksjoner Detaljert beskrivelse av manuelle funksjoner knyttet til det nye systemet. For hver funksjon spesifiseres: Hva som skal gjøres Eksempel på blanketter eller rapporter som skal brukes Hvem som er ansvarlig Beskrivelse av inn- og utdata Behandlingstid Frekvens Systemutvikling Kap. 11 Analysemodeller og -prinsipper 40 Innhold i kravspesifikasjon Krav til brukeropplæring Angi forutsatt kunnskapsnivå, kurstyper, kursinnhold, antall kursdeltagere m.m. 10.Regler for godkjenningsprøve Funksjonell kontroll Dokumentasjonskontroll 11.6 Spesifikasjonsgjennomgang Specification Review Gjennomgangen utføres av utviklere og kunder. Spesifikasjonen er grunnlaget for utviklingsfasen. Vi starter med et overordnet (makroskopisk) perspektiv (nivå) som viser at spesifikasjonen er: Komplett Konsistent Nøyaktig Når gjennomgangen er fullført, signeres den, og er dermed en kontrakt for det videre arbeid (utviklingen). Systemutvikling Kap. 11 Analysemodeller og -prinsipper 41 Systemutvikling Kap. 11 Analysemodeller og -prinsipper 42