Forstudiet + Analysefasen

Presentasjon om: "Forstudiet + Analysefasen"— Utskrift av presentasjonen:

1 Forstudiet + Analysefasen
Høst 2007

2 Vår modell i PRS Forstudium Analyse Utform og realiser Innføre mål
rammer kost/nytte risiko analyse planer og ressurser behov/problemer brukerkrav valg løsning systemkrav arkitektur database programmering testing dokumentasjon opplæring/støtte endre rutiner endre organisasjon installere ta i bruk Forstudium Analyse Utform og realiser Innføre Skal prosjektet gjennomføres? Hva slags prosjekt skal gjennomføres? Er løsningen realisert i henhold til spesifikasjonene Vil den spesifiserte løsningen tilfredsstille brukerkrav Er kostnadene akseptable

3 Forstudiet - forankring
Mål Rammer Plan Organisasjon lønnsomhet Behov Ide Forstudiet Analyse JA NEI - STOPP

4 Identifisere og velge et prosjekt
Hvor mye innsats skal det være i forstudiet? Oppdragsgiver gir rammen. Hvilke kriterier legges til grunn for valg av et prosjekt? Om det skal gjennomføres et prosjekt Hva slags prosjekt Hva som trengs av tid og ressurser

5 Fordeling av arbeidsinnsats
· Forstudiet 10% · Analysen 35% – 40% · Design og programmering 45% - 50% · Innføring 5% - 10%

6 Oppstart av prosjektet
Etablere et prosjektteam Rammeplan for prosjektet Beste estimat for Prosjektomfang Kost/nytte – lønnsomhet Risikoanalyse Ressursbehov Arbeidsbeskrivelse Et dokument beregnet for kunden/sponsor Beskriver resultatet av prosjektet og hva det skal levere

7 Hensikten med denne fasen
Prosjektets mål basert på en vurdering av brukers behov sett i relasjon til dagens system Lønnsomheten av prosjektet Strategi og overordnede planer for gjennomføringen av prosjektet Tids og ressursbehov for gjennomføringen

8 Resultater fra forstudiet
Dagens situasjon – bakgrunn for prosjektet Prosjektmål Prosjektets omfang Konsekvenser for organisasjonen Rammebetingelser Kritiske suksessfaktorer Risikoanalyse Kost/nytte analyse Forslag til prosjektorganisasjon Retningslinjer og standarder Aktivitets- og ressursplan Anbefaling om videre arbeid.

9 Viktigste oppgaver

10 Prosjektmål Effektmål Resultatmål Prosessmål
Hvilken effekt ønskes oppnådd i organisasjonen ved å gjennomføre prosjektet (for eksempel økt lønnsomhet, bedre arbeidsmiljø) Resultatmål Hva skal gjøres i prosjektet for å oppnå den ønskede effekten (for eksempel å utvikle et system). Prosessmål Hvilken effekt vil det å arbeide i prosjektet ha på prosjektdeltagerne (for eksempel å gi økt kompetanse i et spesielt utviklingsverktøy).

11 Prosjektets omfang Dette er et supplement til prosjektmålene og utdyper og presiserer hva prosjektet skal gjøre og hva det ikke skal gjøre slik at det ikke skal oppstå misforståelser. Beskrivelsen kan være i form av enkle modeller av funksjoner og data, i kombinasjon med, eller som tekst.

12 Rammebetingelser Absolutte krav til prosjektets gjennomføring og resultat Absolutte krav til ferdigdato Absolutte krav til kostnadsramme Myndighetskrav Drifts- og utviklingsmiljø Etc.

13 En klassisk prosjektorganisasjon
Referanse- gruppe Kvalitets- kontroll Styrings-komite Prosjekt- leder Prosjektgruppe

14 Kost/nytte Beregnbar nytte - effektmål Ikke beregnbar nytte
Bortfall kostnader som vi har idag Eks. drift gammelt system Innleie ekstrahjelp Utviklingskostander Driftskostander

15 Kostnader Utviklingskostnader – hva koster systemet vårt
Driftskostnader – vanligvis 10%-20% årlig av utviklingskostnadene

16 Sammenstilling kost/nytte

17 Risikoanalyse Finne frem til uønskede hendelser (risikofaktorer) som prosjektet må beskytte seg imot Bedømme sannsynligheten for at de skal inntreffe Analysere konsekvensene hvis de inntreffer Vurdere tiltak Presentere resultatet

18 Uønskede hendelser Generelle – alle prosjekter har disse
mister nøkkelkompetanse Prosjektspesifikke – gjelder dette prosjektet avhengighet av et annet prosjekt Frivillige tar i bruk nytt verktøy Ufrivillige dårlig datakvalitet Ufrivillige Frivillige Generelle Spesifikke

19 Boehms liste Personell – samarbeid og kvalifikasjoner
Urealistiske planer og estimater Feil system (!) Feil brukergrensesnitt Hyppige endringer av krav Komponenter levert av andre – dårlig kvalitet og forsinkelser Innkjøpte komponenter – dårlig kvalitet og forsinkelser Kapasitetsproblemer Ny og uprøvd teknologi – feil teknologi

20 Risikoanalyse 9 Risiko Konsekvenser 10 6 5 4 3 2 1 8 7

21 Om rammebetingelser Rammebetingelser betyr signifikant økning av risikoen i et prosjekt Prøv å bli kvitt dem! Typiske rammebetingelser: Tid Kostnad Krav til ytelse Teknologi Personell

22 Kravanalyse og spesifikasjon
Logisk beskrivelse av systemet (modeller, spesifikasjoner) Pris Konsekvenser Mål Rammer Plan Organisasjon Kravanalyse og spesifikasjon Design og koding JA Skal vi bygge dette systemet Ja, med modifikasjoner NEI - STOPP

23 Hva er analysen i et prosjekt?
Vi skal bestemme: Hva systemet skal gjøre Hvordan det skal virke Hvordan det skal se ut

24 3 trinn i analysefasen Brukerkrav Alternativ vurdering Systemkrav

25 Brukerkrav Krav til funksjoner - hva brukeren skal kunne gjøre ved hjelp av systemet Krav til data - hvilken informasjon systemet skal behandle Krav til egenskaper sikkerhet, adgangskontroll, revisjon tidsfrister, gjennomløpstider, svartider brukeregenskaper flyttbarhet mellom teknologiske plattformer pålitelighet vedlikeholdbarhet kapasitet kompatibilitet sikkerhetskopi og rekonstruksjon Restriksjoner på løsning Krav til støtte og forvaltning

26 Vær oppmerksom på Bruker vet ikke alltid hva han vil ha
Bruker og systemutvikler snakker ikke samme språk Bruker kan bli overskjørt av systemutviklers ekspertise Beslutningsgrunnlaget som legges frem er for abstrakt til å se konsekvensene av

27 Detektivarbeid Spør om alt mulig
I utgangspunktet er alt mulig, bryt med tradisjoner Gå inn i detaljene – en mangel kan få alvorlige konsekvenser Vær kreativ – se nye veier

28 Problemanalyse Brukernes informasjonsproblemer
Informasjonen finnes ikke Informasjonen kommer for seint Brukerne får for mye informasjon Effektiviteten er dårlig Kvaliteten på dataene er ikke god nok Informasjonen er dårlig sikret Konkurrentene har bedre systemer

29 Kartleggingsteknikker(1)
Problemstillinger, brukerønsker og kravspesifikasjon er umulig å sette opp fornuftig uten at vi som konsulenter lager en beskrivelse av nåværende system og organisasjonen

30 Kartleggingsteknikker(2)
Datainnsamling Intervjuer/ gruppearbeid Spørreskjema Observasjon Skrevet materiale (representativt utvalg) Utredninger/litteraturstudier av området Litteratursøk (internett) Ekskursjoner

31 Intervju (1) Planlegging Lage spørsmålsliste Avtale tidspunkt
Heller flere korte intervjuer enn et langt Helst på arbeidsplassen til intervjuobjektet

32 Intervju (2) En god intervjuer: Lytter nøye Snakker enkelt
Respekterer intervjuobjektets øvrige avtaler/ planer Styrer unna sladder/personlige forhold Har påkledning som ”passer”

33 Spørreskjema (1) Konstruksjonsprinsipper
Fritt format- enkle og få setninger Spørsmål med rangerte svaralternativer Flervalg Avkrysning

34 Spørreskjema (2) Fordeler: Ulemper Stort antall objekter Anonyme svar
Rask og effektiv Ulemper Begrenset type spørsmål Oppfølgingsspørsmål Tidkrevende Vanskelig å stille gode spørsmål

35 Observasjon Avstandsobservasjon eller delta i jobben selv?
Sørg for god informasjon til alle berørte uansett!

36 Skrevet materiale(representativt utvalg) 1
Beskrivelse av firma, politikk, rapporter, årsberetninger, vedtekter Rutinebeskrivelser og jobbinstruksjoner Brukerveiledning for eksisterende system Arbeidsbeskrivelser Rutinemessige utarbeidete rapporter, statistikker

37 Skrevet materiale(representativt utvalg) 2
Skjemaer (Blanketter/formularer) Hva er hensikten, hva brukes det til Hvem skriver inn data? Hvem er mottakere?

38 Nyere metoder Joint Application Design – JAD Prototyping
Kontinuerlig brukermedvirkning eXtremprogrammering

39 Kravspesisfikasjon (1)
Når kartlegging og datainnsamling/avgrensing er gjennomført har vi kunnskaper nok til å sette opp en kravspesifikasjon Skal så konkret som mulig vise hvilke egenskaper brukerne og virksomheten forventer av et nytt eller forbedret system Er et styringsdokument for prosjektet

40 Kravspesisfikasjon (2)
Følgende momenter bør være med: Kort om formålet Hva systemet bør kunne utføre for aktuelle brukergrupper Rammer for prosjektet Begrensinger som (tid, økonomi, lover, avtaler, it-plattform Krav til funksjoner Hva systemet skal utføre av arbeidsoppgaver Brukervennlighet, ventetid, kommunikasjon med andre systemer Krav til andre egenskaper

41 Brukerkrav - dokumentasjon
Det utarbeides et formelt kravdokument en presis og konsistent beskrivelse av hva bruker forventer av løsningen og av alle restriksjoner på løsningen krav til brukerstøtte og til forvaltning er med i brukerkravene Alle brukerkrav skal ha en identifikator Kravdokumentet vedlikeholdes og er underlagt versjonskontroll

42 Modellering DFD – strukturert analyse UML – objektorientert analyse

43 Prototyping Brukermedvirkning

44 Valg av alternative løsninger
Flere modeller

45 Systemkrav Detaljerte, tekniske spesifikasjoner som omfatter:
automatiserte funksjoner, funksjonslogikk, inndata og utdata manuelle rutiner skjermbilder Grensesnitt mot andre systemer Logisk datamodell og beskrivelse av alle dataelementer spesifikasjon av egenskaper spesifikasjon av krav til sikkerhet Spesifikasjonen skal være så detaljert at vi kan gi den til en annen gruppe og forvente at de lager ”riktig” system