Ida750 IT Strategi - Kravspesifikasjon

Presentasjon om: "Ida750 IT Strategi - Kravspesifikasjon"— Utskrift av presentasjonen:

1 Ida750 IT Strategi - Kravspesifikasjon
Pensum definert gjennom forelesningene (Powerpoint filer) Mye overlapp med IT-strategi delen Vi har tidligere sett på hvordan organisasjoner kan få maksimalt ut av alle sine IT systemer, her ser vi på kravene til ett system Denne forelesningen kan også fungere som en oppsummering av mye av det vi tidligere har snakket om Referansebok: Del I av Kotonya, G. & Sommerville, I., Requirements Engineering, Wiley, 1997. Få fram at det er fellestrekk mellom strategiarbeid og kravspesifikasjon. I det første ser vi på bedriften under ett, kanskje i et 3-10 års perspektiv. I kravspesifikasjon ser vi på en deloppgave. Hvor store likhetstrekk vi har vil være avhengig av type deloppgave. I noen tilfeller vil disse være klart spesifisert (delsystem). Da har vi færre fellestrekk. I andre vil vi ha en identisk jobb til kravspesifikasjon - å finne ut hva bedriften egentlig trenger. Oshaug: Om bedriften. Utvikle administrativt system (komme tilbake til dette). Ble under dette arbeidset introdusert til en avdeling som ferdigstilte (slipte, målte, ISO kontrollerte) propellblad. Store problemer: formann (overbelastet), Excel (kun av formann, begrenset ISO kontroll, tungv. Å bruke). Lage nytt system som kunne brukes av flere (Access). Utgangspunkt i regneark. Intervjuer. Være i bedriften. Oppdaget andre problem: Enkelte propellere var vanskelig å kontrollere (vis hvordan regneark virker). Manglende standard for koordinatsystem. Tungv. Å lage dokumentasjon. Dekke begge deler. Systemet kostet kun å utvikle. Betale seg inn i løpet av en måned. 150% produktivitetsøkning, mindre bruk av innleide tjenester, bedre lev. Sikkerhet. Styref. Påpekte at en kunne se i regnskapet når systemet kom inn. Ikke unntak. Ofte oppdrag for inst. Uten eget utviklingspersonale. Vide horisonter. Demo PPK. Kravspesifikasjon

2 Bakgrunn IT prosjekter har vært plaget av:
Budsjettoverskridelser Tidsoverskridelser Mange fiaskoer Ofte legger en skylden på uklare kravspesifikasjoner Med kravspesifikasjon ønsker en: Bedre styring Fastere former Kontroll over budsjett og tid Systemer som dekker kundens behov Kravspesifikasjon

3 Kravspesifikasjon kan være mangt…
Et formelt dokument, en juridisk bindende kontrakt, mellom kunde og utvikler om hva som skal gjøres En prototype En liste av mål for systemet, samt en skisse til løsning Vag målsetting ”hei, vi har et problem med å lage en ordreplan” Kravspesifikasjon

4 Her skal vi I stor grad se på mer formell kravspesifikasjon
Kunnskap om dette er viktig da enkelte organisasjoner krever en formell spesifikasjon Men, vi skal også se på andre måter å lage en kravspesifikasjon på Kravspesifikasjon

5 Forskjellige typer av krav kan inngå:
Generelle Funksjonelle Krav til implementasjon Effektivitet Brukervennlighet Kravspesifikasjon

6 Problemer Upresise mål
Kravspesifikasjonen beskriver ikke brukernes virkelige behov Spesifikasjonene er inkonsistente og ikke komplette Spesifikasjonene er for detaljerte (låser utviklerne) Misforståelser mellom bruker, de som utvikler spesifikasjonene og utviklerne Kravspesifikasjonen forutsetter en stabil verden, det har vi sjelden Kravspesifikasjon

7 Kan føre til… Forsinket leveranse Fordyret leveranse
Behov for store endringer etter installasjon Systemet blir benyttet galt, lite eller ikke i det hele tatt Systemet kan være upålitelig Meget store vedlikeholdskostnader Dårlig tilpassning til andre systemer Systemet blir fort avleggs Kravspesifikasjon

8 Kravspesifikasjonsprosessen
Hvordan man håper at denne skal gå! Kravspesifikasjon

9 Aktiviteter Kravspesifikasjon

10 Kravspesifikasjonsdokumentet inneholder:
Kravspesifikasjon

11 IEEE/ANSI 830-1993 (standard):
Introduction Purpose Scope of the product Definitions References Overview of document General description Product perspective Product functions User characteristics General constraints Assumptions and dependencies Specific requirements functional, non-functional, interface, performance, database and network requirements, etc. Index Kravspesifikasjon

12 Hvem bruker kravspes. dokumentet?
Kravspesifikasjon

13 Guidelines: Kravspesifikasjon

14 Prosessen Kravspesifikasjon

15 Data Kravspesifikasjon

16 Aktivitetsmodell elicitation – å få fram, synliggjøre 27.12.2018
Kravspesifikasjon

17 Tradisjonell modell Waterfall model Kravspesifikasjon

18 Mer moderne Kravspesifikasjon

19 Utvikling, først når vi vet hva vi skal lage:
Utvikling av systemet (detaljspesifikasjon, programmering…) Kravspesifikasjon

20 Hvem er involvert? Kravspesifikasjon

21 Roller Kravspesifikasjon

22 Verktøy for å understøtte kravspesifikasjonsprosessen:
Kravspesifikasjon

23 CMM – Capability Maturity Model
SEI, Software Engineering Institute i Pittsburgh bruker disse 5 nivåene. Kravspesifikasjon

24 Nivåer av utvikling mht softwareutvikling:
Initial: Udisiplinerte prosesser, individer bestemmer hvordan ting skal gjøres og hvilke teknikker som skal brukes Repeatable level: Grunnleggende prosesser for budsjettering og planlegging av utviklingsprosesser er beskrevet og kan repeteres Defined level: Dokumentasjon, standardisering Managed level: Kvalitetskontroll Optimizing level: Kontinuerlig prosess for forbedring, objektive målinger Kravspesifikasjon

25 ”in” å karakterisere organisasjoner på denne måten
Mest anvendelig for store softwarehus Har mange prosjekter Ofte store prosjekter Mange prosjektdeltagere Formalisering er nødvendig for å få oversikt og kontroll Kravspesifikasjon

26 Forenklet model for kravspesifikasjon
Kravspesifikasjon

27 Best practices Kravspesifikasjon

28 Requirement Elicitation
Kravspesifikasjon

29 Fire dimensjoner Application domain understanding
Forstå institusjonen, området der systemet skal anvendes. Hvem er brukerne, hva er brukernes bakgrunn. Hvilke holdninger eksisterer… Problem understanding Hva er målene for systemet, hvilke problemer skal vi løse… Business context Systemet skal (som oftest) bidra til utvikling av organisasjonen, hvordan passer systemet inn med andre, med overordnede strategier Stakeholder needs and constraints Hva er deres motivasjon, hva ønsker de å oppnå Kravspesifikasjon

30 Problemer Application domain understanding Problem understanding
Informasjon om dette er ikke samlet på ett sted, mange kilder, også muntlige, eksplisitt og implisitt Problem understanding De har et problem, men akkurat hva dette går ut på og hvordan det skal løses må vi ofte finne ut selv. De vi skal arbeide med er ofte opptatt… Business context Hvordan fungerer organisasjonen, er overordnede mål og strategier uttalte? Stakeholder needs and constraints Stakeholders kan ha sine (ofte gode) personlige motivasjoner i et prosjekt, hva er disse? Kravspesifikasjon

31 ”Elicitation” og analyse
Kravspesifikasjon

32 4 kritiske aktiviteter:
Mål Beskriv målene for systemet, oversikt over problemet, hvorfor et nytt system kan være nødvendig, begrensninger som budsjett… Bakgrunnskunnskap Organisasjon, anvendelsesområde, andre systemer… Organisering Organiser data og informasjon samlet inn til nå, prioriter mål Brukerkrav Hva er brukernes krav til det nye systemet Kravspesifikasjon

33 Oversikt Kravspesifikasjon

34 Analyse /forhandlinger
Kravspesifikasjon

35 Teknikker Samle bakgrunnsstoff (strategiplaner, årsrapporter….)
Intervjuer Scenarioer Soft system methodology (SSM) Syv faser (se neste slide) Kravspesifikasjon

36 SSM – 7 faser: Kravspesifikasjon

37 Kravspesifikasjon

38 Etnografisk undersøkelse
Observasjon av brukerne i arbeid, intervjuer, video, ”de-briefing” hvor vi trekker ut verdifull informasjon Kravspesifikasjon

39 Prototyping Alternativer: Mange fordeler: Bruk og kast
Evolusjonær prototyping (mer aktuell nå med bedre verktøy) Mange fordeler: Kan vise hvordan systemet vil bli, inklusiv ”look and feel” Håndfast Lettere for brukerne å forholde seg til en prototype enn en spesifikasjon, mer og bedre tilbakemeldinger Hurtigere utvikling Understøtter utvikling i faser Kravspesifikasjon

40 Analyse av kravspesifikasjon, sjekkliste
Kravspesifikasjon

41 Validering Sjekker for: Avsluttende fase i arbeidet Kompletthet
Konsistens Nøyaktighet Avsluttende fase i arbeidet Kravspesifikasjon

42 Input & Output Kravspesifikasjon

43 Reviews Reviews (gjennomgang), teknikk for å verifisere kravspesifikasjonen Kravspesifikasjon

44 Sjekkliste Kravspesifikasjon

45 Prototyping Validering gjennom prototyping:
Velg testpersoner Utvikl testscenario Utfør scenario Mange krav kan kun testes gjennom prototype: Opplæring Brukervennlighet Effektivitet (delvis) Kravspesifikasjon

46 Prosess Kravspesifikasjon

47 Modellvalidering Vi kan ha detaljerte modeller av systemet, for eksempel for dataflyt Er disse i orden? Inkluderer de all relevant informasjon? Konfliktfritt? Er de konsistent med andre modeller? Beskriver de brukernes behov? Kravspesifikasjon

48 Testing Kan kravene testes? Eksempel: Hvilket krav er testbart?
Kan vi gjøre en eller flere tester i det ferdige systemet for å vise at kravet er oppfylt Eksempel: Systemet skal være lett å lære? 95% av brukerne skal kunne benytte systemet etter 10 minutter? Hvilket krav er testbart? Kravspesifikasjon

49 Requirements management
Her er vi opptatt av: Stabile og dynamiske krav Identifisering av krav, lagring Versjonskontroll Sporing (traceability) Kravspesifikasjon

50 Behovet for endringer Kravspesifikasjon

51 Identifisering av krav
Kravspesifikasjon

52 Lagringsstruktur for krav
Kravspesifikasjon

53 Versjonskontroll (faser)
Kravspesifikasjon

54 Versjonskontroll (prosess)
Kravspesifikasjon

55 Sporing Vi ønsker å kunne spore endringer begge veier.
Hvilke underordnede krav kan bli berørt av endringen i dette kravet? I hvilke overordnede krav inngår kravet som er endret? Kravspesifikasjon

56 Typer av sporing Kravspesifikasjon

57 Oppsummering Følgende må være på plass:
Det er viktig å vite målsettingene for systemet Vi må ha en god og utarbeide idé av systemfunksjonaliteten Brukergruppene må være kjent Vi må ha valgt metodikk Vi må vite hvordan systemet skal implementeres Koplinger til andre systemer må være kjent Installasjonsfasen må være beskrevet Før vi starter utviklingen av systemet Kravspesifikasjon