Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

10.07.2014Kravspesifikasjon1 Kravspesifikasjon: Pensum definert gjennom forelesningene (Powerpoint filer) Mye overlapp med IT-strategi delen Vi har tidligere.

Liknende presentasjoner


Presentasjon om: "10.07.2014Kravspesifikasjon1 Kravspesifikasjon: Pensum definert gjennom forelesningene (Powerpoint filer) Mye overlapp med IT-strategi delen Vi har tidligere."— Utskrift av presentasjonen:

1 Kravspesifikasjon1 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.

2 Kravspesifikasjon2 Bakgrunn IT prosjekter har vært plaget av: Budsjettoverskridelser Tidsoverskridelser Mange fiaskoer Uklarhet om mål er oppnådd Ofte legger en skylden på uklare kravspesifikasjoner Med kravspesifikasjonen ønsker en: Bedre styring Fastere former Kontroll over budsjett og tid Systemer som dekker kundens behov

3 Kravspesifikasjon3 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 Kan starte med en vag ide ”hei, vi har et problem med å lage en ordreplan”

4 Kravspesifikasjon4 Her skal vi I stor grad se på mer formell kravspesifikasjon Kunnskap om dette er viktig da enkelte organisasjoner krever dette Men, vi skal også se på andre måter å lage en kravspesifikasjon på Kravspesifikasjonen blir viktig for store systemer

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

6 Kravspesifikasjon6 Problemer Upresise mål Kravspesifikasjonen beskriver ikke brukernes virkelige behov Spesifikasjonene er inkonsistente og ikke komplette Spesifikasjonene er for detaljerte (låser utviklerne), mange punkter, svak overordnet forståelse Misforståelser mellom bruker, de som utvikler spesifikasjonene og utviklerne Kravspesifikasjonen forutsetter en stabil verden, det har vi sjelden Kravspesifikasjonen tar ikke hensyn til at visse mål er vanskelig å oppnå Hva når de egentlige kravene endres over tid?

7 Kravspesifikasjon7 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 Kritiske brukere Meget store vedlikeholdskostnader Dårlig tilpassning til andre systemer Systemet blir fort avleggs Indirekte kostnader (jobben blir ikke gjort)

8 Kravspesifikasjon8 Ofte Store kostnader til utvikling og tilpassning Systemet blir tatt i bruk Det virker Men uklart om en har oppnådd noe F.eks. (fra en vit. artikkel): It is therefore very unlikely that any ERP implementation can simply be asserted to be a success or a failure Men det er selvfølgelig systemer som er en åpenbar suksess eller en åpenbar fiasko

9 Kravspesifikasjon9 Kravspesifikasjonsprosessen Hvordan man håper at denne skal gå!

10 Kravspesifikasjon10 Aktiviteter

11 Kravspesifikasjon11 Kravspesifikasjonsdokumentet inneholder:

12 Kravspesifikasjon12 IEEE/ANSI (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

13 Kravspesifikasjon13 Hvem bruker kravspes. dokumentet?

14 Kravspesifikasjon14 Guidelines:

15 Kravspesifikasjon15 Prosessen

16 Kravspesifikasjon16 Data

17 Kravspesifikasjon17 Aktivitetsmodell elicitation – å få fram, synliggjøre

18 Kravspesifikasjon18 Tradisjonell modell Waterfall model

19 Kravspesifikasjon19 Mer moderne

20 Kravspesifikasjon20 Utvikling, først når vi vet hva vi skal lage: Utvikling av systemet (detaljspesifikasjon, programmering…) Denne fasen er lite formalisert, åpen, med mange usikkerhetet Denne fasen bør være formalisert, entydig og sikker

21 Kravspesifikasjon21 Hvem er involvert?

22 Kravspesifikasjon22 Roller

23 Kravspesifikasjon23 Verktøy for å understøtte kravspesifikasjonsprosessen:

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

25 Kravspesifikasjon25 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

26 Kravspesifikasjon26 ”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

27 Problemer med modellen Mange softwareutviklere bruker en ad hoc modell (nivå 1) med stor suksess Eksempler: Microsoft, Google, Facebook, Apple Men dette kan sies å falle innenfor kreativ softwareutvikling, mens “maturity” modellen kanskje er ment for mer rutinepreget virksomhet?

28 Kravspesifikasjon28 Forenklet modell for kravspesifikasjon

29 Kravspesifikasjon29 Best practices

30 Kravspesifikasjon30 Requirement Elicitation

31 Kravspesifikasjon31 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å

32 Kravspesifikasjon32 Problemer Application domain 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?

33 Kravspesifikasjon33 ”Elicitation” og analyse

34 Kravspesifikasjon34 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

35 Kravspesifikasjon35 Mål Skal fortelle oss hva vi skal oppnå, hensikten (”rationale”) Disse kan brukes når vi må ta avgjørelser underveis (f.eks. for å velge mellom brukervennlighet og effektivitet) Målene blir viktige når systemet skal evalueres

36 Kravspesifikasjon36 Oversikt

37 Kravspesifikasjon37 Analyse /forhandlinger

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

39 Kravspesifikasjon39 SSM – 7 faser:

40 Kravspesifikasjon40

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

42 Kravspesifikasjon42 Prototyping Alternativer: 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 Gir utviklerne tidlige kunnskaper om metoder, tidsbruk m.m.

43 Kravspesifikasjon43 Prototype Av hele systemet, prototypen kan da bli systemet (ref. Oshaug) Av deler av systemet: Brukergrensesnitt Komplekse tekniske løsinger Tidsaspekt Det er smart å konsentrere seg om ukjente deler først. Prototyper kan hjelpe oss her.

44 Kravspesifikasjon44 Analyse av kravspesifikasjon, sjekkliste

45 Kravspesifikasjon45 Validering Sjekker for: Kompletthet Konsistens Nøyaktighet Avsluttende fase i arbeidet

46 Kravspesifikasjon46 Input & Output

47 Kravspesifikasjon47 Reviews Reviews (gjennomgang), teknikk for å verifisere kravspesifikasjonen

48 Kravspesifikasjon48 Sjekkliste

49 Kravspesifikasjon49 Prototyping Validering gjennom prototyping: Velg testpersoner Utvikle testscenario Utfør scenario Mange krav kan best testes gjennom prototype: Opplæring Brukervennlighet Effektivitet (delvis)

50 Kravspesifikasjon50 Prosess

51 Kravspesifikasjon51 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?

52 Kravspesifikasjon52 Testing Kan kravene testes? 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?

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

54 Kravspesifikasjon54 Behovet for endringer

55 Kravspesifikasjon55 Identifisering av krav

56 Kravspesifikasjon56 Lagringsstruktur for krav

57 Kravspesifikasjon57 Versjonskontroll (faser)

58 Kravspesifikasjon58 Versjonskontroll (prosess)

59 Kravspesifikasjon59 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?

60 Kravspesifikasjon60 Typer av sporing

61 Kravspesifikasjon61 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

62 Kravspesifikasjon62 Små systemer – store systemer Mange av de konkrete eksemplene vi har brukt tidligere har vært for små systemer Små systemer har mange fordeler: Oversiktlige Begrenset arbeidsmengde Få brukere, få installasjoner Da kan vi få en betydelig reduksjon av arbeidet med: Kravspesifikasjon Testing Opplæring Med store systemer blir alt annerledes, spesielt om de utvikles under en detaljert kravspesifikasjon


Laste ned ppt "10.07.2014Kravspesifikasjon1 Kravspesifikasjon: Pensum definert gjennom forelesningene (Powerpoint filer) Mye overlapp med IT-strategi delen Vi har tidligere."

Liknende presentasjoner


Annonser fra Google