Problemdefinisjon. Læremål denne uka og de to neste. Problemanalyse og kravspesifikasjon Marakas kap 2-4. Marakas kap 2: So what is the problem?

Transkript

1 1 2 Guttorm Sindre Problemanalyse og kravspesifikasjon Marakas kap 2-4 Marakas kap 2: So what is the problem 3 4 Læremål denne uka og de to neste Prinsipp for problemdefinisjon (kap 2) Forstå forskjell på problem og symptom Kunne bruke PICS-rammeverket Forstå forskjell på åpne og lukka system (livssyklus: hopper over antas kjent fra før) Prinsipp for å velge og gjennomføre IS-prosjekt (kap 3) Forstå ulike avveininger og verdivurderinger (prosjektplanlegging og gjennomføring antas kjent fra før) Forstå forskjell på logiske og fysiske modeller Kravspesifikasjon (kap 4 ++) Forstå prinsipper for hvordan krav formuleres Vanlige teknikker for kravinnhenting Kjenne til ulike teknikker, kunne velge riktige teknikker etter kontekst Trening i å kunne bruke noen vanlige teknikker (Ø-opplegg to neste uker) Problemdefinisjon Problem = forskjell mellom faktisk og ønsket tilstand Kan ikke løse et problem uten å ha forstått det Hva med metoder som foreslår tidlig programmering (f.eks P) Må iallfall da ha forstått såpass av problemet at man er sikker på at ny programkode er løsningen, og at denne koden best kan lages, ikke kjøpes eller leies Symptom = ytre manifestasjon av et problem Problemet er årsak, symptomet virkning Risk ved mangelfull problemforståelse Løse feil problem Kun behandle symptomet, ikke problemet Lage en dårlig løsning Mål: en løsning som er god nok Ikke alltid mulig å finne den beste, jfr avsnittet om Bounded rationality

2 5 PICS-rammeverket 6 PICS, eksempel (fig 2-3) Symptom Management reports often not received on time P I x C S Production line throughput below expected standards x Hensikt: kategorisere symptomer for å finne fram til underliggende problemer Performance: trege responstider, dårlig gjennomstrømning Information: manglende info, dårlig info-kvalitet conomics: for høy kostnad (f.eks ved arbeidsprosess) Control & security: for lite kontroll og sikkerhet (eller for mye) fficiency: sløsing med tid / materialer Service: systemet gir for dårlige tjenester, vanskelig å bruke, for lite fleksibelt, dårlig samhandling med andre systemer Product rework is high Inventory control reports are inaccurate xceptions occur frequently, must be processed by hand Production time is higher than industry average Orders often canceled due to excessive delivery times Required info to process order not available on demand Organizational data redundancy is high Production lines often down for repair / maintenance Line personnel often not aware of production quota Data transferred from production to sales system by hand Several incidents of system sabotage recorded Total Oppgave 8 It s learning med PICS Symptom P I C S Sett dere sammen i grupper på 2-3 pers. og: Identifiser symptomer på ting dere evt. er misnøyd med i It s learning (eller evt. misnøye / problemer dere har hørt om / lest om) Prøv å kategorisere disse problemene ihht PICS Total

3 9 10 Åpne og lukka system (fig 2-5) System = en mengde relaterte element, med en identifiserbar grense, som virker sammen for å nå et felles mål Prinsipper for god IS-utvikling Involver brukerne (og andre interessenter) Systemanalyse er problemløsning IS-investeringer må rettferdiggjøres akkurat som andre investeringer Gode ideer kan endre seg til dårlige ideer t prosjekt kan revurderes og termineres på ethvert stadium Dokumenter! Splitt og hersk! (dekomponering) Hvordan prioritere IS-prosjekt Marakas kap 3: Identification and selection of development projects I en stor organisasjon kan det til en hver tid finnes mange mulige / foreslåtte IS-prosjekt Ikke nok ressurser til alle Hvilke skal prioriteres Ulike evalueringskriterier Potensielle organisasjonelle fordeler Strategisk tilpasning Ressursbruk Verdikjede-analyse NB: Marakas kap 3 har klare sammenhenger med P&S-boka F.eks kap 2 og 6

4 13 Verdikjede og IS (fig 3-3) 14 Valg av IS-prosjekt (fig 3-4) Hvilke typiske evalueringsresultater vil føre til Accept / Reject / Redefine / Postpone / PoC Logiske og fysiske modeller (fig 3-6) Marakas kap 4: System Requirements Determination Pluss en del tilleggsstoff

5 17 Innledende motivasjon Tre typer krav: funksjonelle, ikke-funksjonelle, begrensninger Hva er forskjellen på disse Tre I er for kravanalyse Impertinence (nesevishet) Impartiality (upartiskhet) Insight (innsikt) Fire vanlige feil i kravanalyse Anta et funksjonelt system (silo-perspektiv) Og anta at brukerne vet hvilke krav de har For mye bruk av 1:1-intervjuer Stille feil spørsmål Ikke ta høyde for prøving og feiling 18 Hvordan er et godt krav formulert Testbart / verifiserbart Presist, korrekt Utvetydig Konsistent Forståelig, modifiserbart Sporbart ( traceable ) + Realistisk 19 Diskusjon: r nedenstående gode krav hvorfor / ikke 20 Krav: hva slags detaljnivå (++) Det skal være mulig for kunden å legge inn flere alternative leveringsadresser. Samme data må kun lagres ett sted i systemet. Responstiden på et produktsøk skal være max 5 sek. Kunderegistreringsfunksjonen må være bedre enn i det gamle systemet. Kunden skal kunne sende inn ordre ved å klikke en grønn Send -knapp plassert oppe i høyre hjørne av skjermbildet. Systemet må være brukervennlig. Brukere med tidligere erfaring med Windows-systemer skal i snitt ikke bruke mer enn 3 timer på å sette seg inn i de funksjonene de skal benytte i sitt daglige arbeid. Systemet skal sikre bedriften en økning i markedsandel på minst 30%. Ulike nivåer av krav (Lauesen, 2002) Mål-nivå: estimater skal max ha 5% feilmargin Domene-nivå: støtte prisanslag med erfaringsdata Produkt-nivå: funksjoner for registrering og gjenfinning av erfaringsdata Design-nivå: skjermbilder som vist i appendiks Typiske måter å gjøre krav på Tradisjonell: produkt-nivå Rask: domene-nivå To-stegs: domene-nivå + design-nivå Valg avh. av prosjekttype

6 21 Prosj.typer og krav (Lauesen, 2002) (++) = god = tvilsom = dårlig * = variabel pris Prosjekttype Intern utvikling (in-house) Produktutvikling (massevare) Timepris Anskaffe hyllevare forretningsappl. Anskaffe hyllevare teknisk verktøy Anbudskrav (med hyllevare) Anbudskrav (skreddersøm) Kontrakt (med hyllevare) Kontrakt (skreddersøm) Subkontraktør-utvikling Vedlikehold Krav-modeller Trad Rask * * Tostegs * * 22 Task & Support tabeller (Lauesen) Ligner på use cases, men Domene-nivå heller enn produkt-nivå mangler presis bruker-system dialog Lar leverandøren foreslå alternativer Format: Overordnet oppgave beskrevet øverst Venstre kolonne: del-oppgaver, inkl Forklaring av tidligere problemer Varianter Høyre kolonne: eksempelløsning ller, i anbud: foreslått løsning Og, for kontrakt: avtalt løsning 23 Referanser Søren Lauesen: Software Requirements: Styles and Techniques, Addison-Wesley, 2002 Forelesning i morgen: Dataflytdiagrammer