Forstudiet + Analysefasen Høst 2007

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

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

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

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

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

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

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.

Viktigste oppgaver

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).

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.

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

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

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

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

Sammenstilling kost/nytte

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

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

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

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

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

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

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

3 trinn i analysefasen Brukerkrav Alternativ vurdering Systemkrav

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

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

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

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

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

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

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

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”

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

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

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

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

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

Nyere metoder Joint Application Design – JAD Prototyping Kontinuerlig brukermedvirkning eXtremprogrammering

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

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

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

Modellering DFD – strukturert analyse UML – objektorientert analyse

Prototyping Brukermedvirkning

Valg av alternative løsninger Flere modeller

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