Laste ned presentasjonen
1
Forstudiet + Analysefasen
Høst 2006
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? Hvem er brukere?
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
Kravspesifikasjon (3) Skjema for kravspesifikasjon
42
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
43
Modellering DFD – strukturert analyse UML – objektorientert analyse
44
Prototyping Brukermedvirkning
45
Valg av alternative løsninger
Flere modeller
46
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
47
Systemkrav - spesifikasjon
En logisk beskrivelse Skal være bygd opp rundt en logisk modell av systemet skal dekke alle brukerkravene (vis knytning) Skal inneholde krav til forvaltning og brukerstøtte Skal IKKE inneholde implementasjonsavhengige detaljer Hva ikke hvordan Flere formelle ”dokumenter” Ulike aspekter i ulike dokumenter Bruk en mal!!
48
Systemkrav - eliminasjon av feil:
Systemkravene skal gjennomgås av: Brukere ? Databaseeksperter Utviklere Driftspersonell Bruk formelle inspeksjoner
Liknende presentasjoner
© 2024 SlidePlayer.no Inc.
All rights reserved.