Prosjektmål, Risikoanalyse og Fremdriftsplan

Transkript

1 Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Prosjektmål, Risikoanalyse og Fremdriftsplan Prosjektrettet systemarbeid LN314D-A 11H (1) Gruppe A Prosjektmål, Risikoanalyse og Fremdriftsplan Prosjektrettet systemarbeid Gruppe 1

2 Innhold 1. INTRODUKSJON HENSIKTEN MED DOKUMENTET BAKGRUNN FOR PROSJEKTET BESKRIVELSE AV PROBLEMER OG BEHOV Behov KORT OM DAGENS SYSTEMER OG RUTINER PROSJEKTMÅL EFFEKTMÅL RESULTATMÅL PROSESSMÅL PROSJEKTETS OMFANG PROSJEKTETS MILEPÆLER OG HOVEDAKTIVITETER RAMMEBETINGELSER KRITISKE SUKSESSFAKTORER RISIKOANALYSE RETNINGSLINJER OG STANDARDER KRAV TIL DOKUMENTASJON KRAV TIL KVALITETSGJENNOMGANGER KRAV TIL STANDARDER OG METODER Navnestandarder Programmeringsstandarder Dokumentmaler Utviklingsverktøy Databaseverktøy TEST OG AKSEPTANSE MÅL FOR TESTINGEN MÅL FOR DET OPERATIVE TESTARBEIDET TESTER SOM INNGÅR I TESTLØPET GODKJENNINGSTEST Forutsetninger Ikke godkjenning av løsningen

3 1. Introduksjon hensikten med dokumentet Dette dokumentet beskriver prosjektet Design og utvikling av system for registrering av utlån og innlån av sportsutstyr. Formålet med dokumentet er å gi alle involverte parter i prosjektet forståelse av: Målet med prosjektet Omfanget for prosjektet Avgrensninger Tidsestimat Milepæler og tidsplan Risikoanalyse Kommunikasjonsplan Akseptansekriterier for leveranser 2. Bakgrunn for prosjektet 2.1. Beskrivelse av problemer og behov AS SportUtleie er lokalisert i leide lokaler i Oppdal, bedriften driver med utleie og salg av tilhørende tjenester som dagskort til enkeltpersoner evt. en gruppe av personer. Virksomheten begrenser seg i dag til utleie av sykler og kano med tilhørende sikkerhetsutstyr og muligheter for instruksjon i sommersesongen, samt skiutstyr, sikkerhetsutstyr og skiopplæring om vinteren. Utleie er kun tilgjengelig på dagsbasis pr dags dato. Det er ikke mulig å bestille tjenester fra bedriften elektronisk da den ikke har webside, så alle bestillinger må skje ved telefonhenvendelse eller e-post/brev, og det er ikke et aktivt kunderegister i bedriften. Selskapet er i vekst og ønsker å ekspandere med flere tilbud og tjenester som blant annet produktpakker sammensatt ut fra kundebehov og kortidsutleie av utstyr. Dette er pr i dag ikke mulig da alle rutiner for utleie, og lagerlister, er manuelle lister som krever en kontinuerlig oppfølging. Manuell oppfølging er tidkrevende, lite effektivt, lite fleksibelt og kan være en feilkilde som i verste fall kan koste bedriften kunder og markedsandeler Behov For å kunne nå dette målet er det avgjørende å ha et fleksibelt, sikkert og enkelt databasesystem med et godt brukergrensesnitt som kan benyttes av alle ansatte, fra lagerpersonellet i forhold til logistikk til verktøy som blant annet beregner avanse for selgere. Systemet må inneholde data som er avgjørende i forhold til kundebase, oversikt over tilgjengelig utstyr og tilgjengelige ressurser på andre relevante områder. Systemet skal inneholde informasjon om tilgjengelig utstyr, oversikt over utstyr som er leid ut til hvem /hvor lenge, oversikt over utstyr som er til reparasjon, som er kassert og hvorvidt det finnes skader på eksiterende utstyr. Det planlegges en utstrakt pleie av eksisterende kunder ved å kunne blant annet tilby skreddersøm av pakkeløsninger ut fra kundebehov og ønsker, så et kunderegister som inneholder kundedata som adresse, bestillingsinformasjon og bestillingshistorikk er nødvendig. Systemet må kunne benyttes til å beregne tilbud med rabattkoder, alternative tilbud med pris og ha beregninger av avanse som en fast post. Det skal være mulig å ta ut ulike typer statistikker, og andre relevante rapporter. Utskrifts funksjonalitet er nødvendig. 3

4 Systemet må være enkelt å benytte, kreve en lav opplæringsterskel, være intuitivt, og ha gode vedlikeholds muligheter og avtaler. Databasen (e) skal kunne benyttes opp mot et webgrensesnitt med tanke på at bedriften på sikt ønsker en webløsning på internett som kan benyttes av potensielle brukere med og uten kundeforhold. Det er et krav av valgte løsning skal være en Windows basert applikasjon til bruk for de ansatte Kort om dagens systemer og rutiner Ansatte, Lokaliteter og utstyr: Antall ansatte er 16 fordelt på daglig leder, en sekretær, 11 selgere, og 3 lagerarbeidere / montører., instruktører leies inn ved behov Har kontorer og lager i et utleiebygg som pr nå er maksimalt utnyttet, alt av utstyr er lokalisert på samme plass. Fører oversikt over alt tilgjengelig utstyr i Excel lister, alt er manuelle rutiner som tar tid og er sårbare. Mangel på logistikk rundt utstyr som hører sammen er et problem som gjør bedriften sårbar. Bestillingsrutiner: Kun manuelle rutiner, ingen administrative systemer i bruk på dette området. Bedriften har ikke egen webløsning, alle bestillinger mottas via telefon og e-post og siden bedriften pr i dag ikke har kundelister må alle kundens data oppgis hver gang. Det er kun åpnet for døgnutleie, da det ikke er mulig i dagens system å leie ut på timebasis. Alle utleieavtaler føres i en egen utleieliste. Denne oppdateres med data om hva, når og hvem. Å sjekke ut hvorvidt utstyr eller instruktører er tilgjengelig gjøres i samme liste noe som er tidkrevende. Å få på plass en god løsning som kan løse de utfordringene som lokaliteter og manglende logistikk i lagerføring gir er avgjørende for videre vekst. Bedriften er i vekst og har et stort potensiale for videre vekst på omtrent 12 % årlig dersom det investeres i et godt verktøy som kan gi støtte for så vel produkthåndtering, kundebehandling og administrative rutiner Som en konsekvens av økt effektivitet kan det bli aktuelt å redusere antall selgere fra 11 til 9 uten at dette skal medføre økt arbeidsbelastning på den enkelte. Dette er et ønsket mål for bedriften. 4

5 3. Prosjektmål Prosjektets mål er grunnlag for : Å bli enige med oppdragsgiver om hva som skal bli resultatet av prosjektet Å kunne planlegge og styre Å kunne vurdere i ettertid om resultatet av prosjektet ble slik som avtalt med oppdragsgiver Å få en felles forståelse i prosjektgruppa for hva jobben går ut på. Når vi har formulert målene har vil lagt vekt på at målene er: 1. Operasjonelle, de må være: Målbare, det må i ettertid være mulig å registrere om målet ble nådd Styrbare, de må være veiledende i valg av handlingsalternativ 2. Klart formulert, det må være rimelig sikkert at alle som leser målene leser det samme. (Vi kan si at det motsatte er poetiske mål, hensikten med poesi er å skape assosiasjoner slik at den enkelte kan bringe frem sine egne bilder og stemninger) Vi finner det hensiktsmessig å skille mellom tre typer mål: effektmål, resultatmål og prosessmål Effektmål Effektivisere arbeidsprosessene som inngås under registrering av utlån og innlån av sportsutstyr Oppnå mer struktur og oversikt over firmaets utleie av sportsutstyr Forenkle administrasjonen over firmaets utleie av sportsutstyr Forenkle oppsett av tilbud på pakkeløsninger som kan også inkludere opplæring i bruk av sportsutstyr og andre relevante tjenester Redusere ressursbehovene som ligger i salg og administrasjon ved firmaet slik at det er tilstrekkelig med 9 selgere Forenkle bestillinger av skiutstyr og pakkeløsninger Resultatmål Det skal utvikles et IT-system som gjør det lettere for AS SportUtleie sine ansatte å administrere skiutleie og behandle kundeordrer. Funksjoner som systemet må ha: o Vise relevant statistikk over ordrene som ligger i en database o Et grafisk brukergrensesnitt som er intuitivt for brukerne av systemet o Muligheten til å legge inn nye ordre inn i en database o Muligheten til å legge inn slette ordre som ligger i en database o Muligheten til å utrede pakkeløsninger ut til kundene o Muligheten til å behandle eksisterende ordrer som ligger i en database Systemet skal være ferdig implementert 11.mai 2012 Systemets utviklingskostnader vil være på rundt 1120kr per time, per systemutvikler. Antatt totale arbeidstimer på prosjektet vil være ca 250 timer. Den totale utviklingskostnaden vil derfor være på kr. Bare autoriserte brukere til dette systemet skal ha aksess til systemet 3.3. Prosessmål Oppnå bedre forståelse for hvordan et systemutviklingsprosjekt fungerer i praksis 5

6 Å oppnå bestått i faget Prosjekt i informatikk Bygge opp kompetanse innenfor systemutvikling, generell programutvikling i Visual Basic.NET og i SQL. Bygge opp kompetanse i samarbeid og kommunikasjon 3.4. Prosjektets omfang Prosjektet vil bli delt opp i milepæler og hovedaktiviteter i en egen framdriftsplan (se framdriftsplan) Under og etter utviklingen av systemet så vil utviklingsteamet ikke drive med brukeropplæring. Systemet vil være intuitivt nok til at dette ikke vil være nødvendig Prosjektets utvikling av systemet vil bestå av hovedsaklig fire deler: 1. Utredning og planlegging av system 2. Implementasjon av system 3. Testing av system 4. Retting av system Prosjektet vil følge en "rask" systemutviklingsmetodikk som heter RAD som baserer seg på iterativ utvikling og programvare-testing Prosjektets milepæler og hovedaktiviteter Prosjektets milepæler og hovedaktiviteter angis i vedlagt fremdriftsplan. Aktiviteter / Oppgaver Arbeidskontrakt Prosjektmål,risikoanalyse og fremdriftsplan Utarbeide brukerkrav og prototype Utarbeide utkast til systemkrav Oppdatere systemkrav,realiser program.utarbeide brukerdokumentasjon Testperiode Utarbeide sluttrapoort Innlevering 4. Rammebetingelser Her beskriver vi absolutte krav som stilles til prosjektets gjennomføring og til resultatet og som vil ha avgjørende innflytelse på planer og valg i prosjektet. Dato for endelig ferdigstillelse er Utkast til prosjektmål,risikoanalyse og fremdriftsplan leveres Første prototype leveres Utkast til brukerkrav leveres Utkast til systemkrav leveres Leveres til test Sluttrapport godkjennes

7 5. Kritiske suksessfaktorer Her beskriver vi faktorer som vil være kritisk avgjørende for om prosjektets resultat vil bli vellykket eller ikke. Hensikten med å få frem slike faktorer er å sikre tilstrekkelig fokus på kritisk viktige forhold hos både oppdragsgiver og systemutvikler. Kritiske suksessfaktorer er faktorer som helst må inntreffe for å kvalitetssikre prosjektets progresjon. Dersom kritiske suksessfaktorer ikke inntreffer, kommer de med høy sannsynlighet til å forhindre at prosjektet kan avsluttes med vellykket resultat. For dette prosjektet framhever vi disse kritiske suksessfaktorene: Prosjektet må være forankret så høyt oppe som mulig hos oppdragsgiveren, firmaet AS SportUtleie. Prosjektet må ha høy prioritet og firmaets ledelse støtter prosjektet til hundre prosent. Eierskapet til prosjektet ligger hos firmaet AS SportUtleie. Eierskapsforholdet er fast og det skal ikke herske tvil eller usikkerhetsmomenter rundt eierskapet. Prosjektet må være ønsket fra brukernes side. Dette nås ved at de ansatte involveres så tidlig som mulig slik at de kan bidra til innholdet, for eksempel utforming av brukergrensesnittet, kan formidle sine ønsker og behov, og forstår nytteverdien det nye systemet vil få for dem. Prosjektlederen og prosjektmedarbeiderne har signert en arbeidskontrakt. Prosjektet har høy prioritet og kan ikke legges på is på grunn av uventete situasjoner. Prosjektets framdrift følger tidsplanen og en prioritert rekkefølge av oppgaver. Omfang til oppgavene skal ikke underestimeres- Det settes av tilstrekkelig tid og ressurser til alle faser av prosjektet. I tilfelle endringer skal man legge inn en buffer med henblikk på tid og ressurser. Prosjektet utvikles iterativt, involverer brukerne og deres behov best mulig, det tas høyde for endringer i brukerbehov underveis. Nødvendige endringer implementeres når behovet oppdages. Planlegging av nok tid og ressurser til brukeropplæring. Planlegging av hvem som skal få ansvar for forvaltning, drift og vedlikehold av systemet. 6. Risikoanalyse Et prosjekt er alltid knyttet til risiko. Vi skal derfor bruke verktøyet Risikoanalyse for å kunne vurdere om risikoen skal tas eller ikke. Meningen med å gjøre en risikoanalyse er å finne risikokilder, vurdere sannsynligheten for at en uønsket hendelse inntreffer, anslå konsekvensene dette medfører, samt å planlegge og iverksette tiltak for å redusere eller utelukke uønskete hendelser. Det følger en risikoanalyse som lister opp faktorer knyttet til utviklingen av datasystemet, sannsynligheten for at disse inntreffer, konsekvensene av hendelsene og hvor høyt disse prioriteres. Analysen inneholder et poengsystem mellom 0 (lavest) og 1 (høyest). F.eks. betyr det at en risikofaktor x med sannsynlighet = 0,1 og konsekvens = 0,8 inntreffer sjeldent, men medfører store konsekvenser for prosjektet. Denne matrisen er en forenklet metode som ikke fanger opp alle nyanser i de faktiske forhold. Noen faktorer kan forårsake tidsforsinkelse. Andre kan resultere i et ferdig system som sannsynligvis ikke blir noen suksess, fordi det ikke oppfyller kravene og forventningene oppdragsgiveren har til systemet. En del faktorer fører til økt ressursbruk 7

8 underveis i prosessen. Vi har valgt å vurdere risikofaktorer som bare fører til at systemet blir forsinket eller dyrere, men som kan rettes opp underveis i prosessen, mildere enn risikofaktorer som fører til at systemet i praksis blir ubrukbart. Risikofaktor Sannsynlighet Konsekvenser Mulige tiltak (1) Manglende kvalifikasjoner 0,2 Lavt, fordi faget har noen minstekrav 0,7 Framdriften og kvaliteten på prosjektet reduseres Fordele oppgavene tilsvarende kunnskapsnivået og erfaring (2) Samarbeidsproblemer mellom gruppemedlemme ne 0,3 Ikke så høyt, alle har interesse av et vellykket samarbeid og har samtykket en arbeids-kontrakt 0,8 Dårlig arbeidsmiljø, framdriften påvirkes, organisering blir vanskelig Megling, konflikthåndteringstiltak (3) Noen må slutte, for eks. på grunn av sykdom, ny jobb, div. forandringer i livet osv. 0,5 Middels, prosjekt går over 4 måneder 0,8 Merarbeid på de resterende, gruppa mister individets kvalifikasjoner Evt. finne en erstatning (4) Prosjektet viser seg til å være mer omfattende/ komplisert enn forventet 0,4 Ganske høyt, prosjektgruppa har forskjellig grad av erfaringer med utvikling av tilsvarende systemer 0,7 Prosjektet blir forsinket eller kvaliteten blir dårligere enn forventet Justeringer underveis, Omfordeling av oppgavene (5) Utvikling av feil system; utvikling av komponenter som ikke er kompatible med hverandre 0,3 Lavt, oppdragsgiveren har bestemt hvilke teknologier som skal brukes 0,9 Deler av eller i verste fall hele systemet blir ubrukbart, komponenter må erstattes, forsinkelser, evt. et system som aldri kommer til å fungere Bruke kontrollmekanismer underveis, prototype, modellering, simulering (6) Dårlig tilpasset brukergrensesnitt, System blir ikke 0,6 Prosjektgruppen kjenner ikke brukerne, har bare 0,5 Det tar lengre tid å venne seg til det nye systemet, Brukerbehovsundersøke lser 8

9 så brukervennlig som forventet en vag beskrivelse av dem misnøye blant brukerne kan oppstå (7) Forgylling: Flere komponenter enn egentlig nødvendig, for mye vekt på det visuelle 0,8 Ganske høyt, oppdragsgiveren ha r ikke definert hvor grensene går 0,2 Tidsforbruk blir for høyt, prosjektet blir dyrere Brukerkrav må prioriteres, kost-nytteanalyse, fortløpende kontroll i prosjektfasene (8) Hyppige endringer av kravene underveis 0,1 Lavt, forventes ikke i det prosjektet, Kravene er nedlagt i prosjektbeskrivelsen 0,7 Deler av arbeidet må forkastes, det brukes mer tid enn planlagt Formell endringshåndtering, iterativ og modul vis utvikling Risikofaktorene er plottet inn i et koordinat: 1 K o n s e k v e n s 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0, ,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 Sannsynlighet 9

10 7. Retningslinjer og standarder I dette kapitlet skal vi kortfattet ta med de retningslinjene og standardene som prosjektet må forholde seg til Krav til dokumentasjon Her beskrives kort hvilke hoveddokumenter som skal produseres i løpet av prosjektet, når de skal foreligge, på hvilken form de skal foreligge og rutiner for godkjenning og revisjon av dokumentene. Følgende dokumentasjonen skal leveres: Prosjektdefinisjon med prosjektmål, risikoanalyse og fremdriftsplan leveres Skjermbilder av GUI leveres EER-modell leveres Brukerkrav leveres Systemkrav leveres Testplan leveres til Dokumentasjon leveres til Testlogg leveres til Sluttrapport leveres Sluttdokumenter skal leveres på prosjektets dokumentmal, og skal godkjennes av styringsgruppen før leveranse. Innhold under utarbeidelse legges tilgjengelig i wiki eller prosjektets filområde på Assembla, med mulighet for kommentar. Eventuelle forbedringer kan diskuteres i gruppemøter Krav til kvalitetsgjennomganger Følgende resultater som skal ha kvalitetsgjennomganger, og skal godkjennes enstemmig i styringsgruppen: Brukerkrav Systemkrav Brukergrensesnitt Logisk databaseutforming Databasekonstruksjon 7.3. Krav til standarder og metoder Her referer vi til de konkrete standarder, metoder, verktøy som prosjektet må benytte Navnestandarder Variablnavn 1) Starter med små bokstaver 2) Mellomrom eller bindestrek skal ikke brukes i variabelnavn 3)Beskrivende navn 4) Kan bruke tall i variabelnavn, men variabler må starte med en bokstav 10

11 5) Kan ikke bruke spesialtegn som komma, punktum, skigard (#) og liknende Prefix Tekstboks: txtnavn Label: lblnavn Button: btnnavn Form: frmnavn Database: dbnavn String: strnavn Tab: tbnavn Datamodell definerer prefix på entitetnavn Programmeringsstandarder 1. Informasjon fra skjerm skal legges i variabler før videre behandling. 2. Det skal velges gode, beskrivende variabelnavn. 3. Datatype skal angis for de variablene som deklareres. 4. Lokale variabler skal brukes hvis det er mulig. 5. Konstanter brukes med måte. 6. Implisitt konvertering unngås med mindre man er helt sikker på at det blir riktig. 7. Koden rykkes inn slik at den blir oversiktlig å lese for andre. Ekstra linjeskift brukes der det er mest naturlig Dokumentmaler Dokumentmal ligger tilgjengelig på prosjektets filområde i Assembla Utviklingsverktøy Visual Studio benyttes som utviklingsmiljø. Subversion integrert med Assembla benyttes som kodedepot. Delatagere kan fritt velge lokal klient for Subversion Databaseverktøy MS Access er prosjektets databaseverktøy. 11

12 8. Test og akseptanse 8.1. Mål for testingen Formålet med testing er å fremskaffe informasjon om løsningen som leveres. Denne informasjonen kan deles inn i to kategorier: a) Informasjon om feil og svakheter i løsningen. Denne typen av informasjon rapporteres til Prosjektleverandør fortløpende etter hvert som de avdekkes. b) Bekreftelse på at løsningen svarer til kravene, som er beskrevet i kravspesifikasjoner og akseptansekriterier. Denne informasjonen brukes for å avgjøre om systemet kan godkjennes og er klart for driftssetting. Det vil aktivt brukes informasjonen fra alle tester, for å forsikre seg om at utviklingsprosessen leder frem til forventet resultat. Informasjonen kan blant annet indikere at visse risikoer er i ferd med å slå til. Tiltak kan da iverksettes tidlig for å redusere risikoen Mål for det operative testarbeidet a) Finne så mange feil som mulig så tidlig som mulig, i programmer, design, spesifikasjoner og annen dokumentasjon. b) Finne de viktigste feilene og kontrollere at disse blir rettet og at valgte løsning fungerer Tester som inngår i testløpet Testene utføres på forskjellige testnivå og i henhold til V-modellen. (fig 1) Testing planlegges ovenfra og ned, og gjennomføres nedenfra og opp. Testarbeidet foregår parallelt med utvikling av systemet. Testplanlegging skal starte straks det foreligger krav- og løsningsspesifikasjoner og testgjennomføring skal starte med test av små moduler. All testing skal dokumenteres. Fig 1. V-modellen Kort beskrivelse av testløpene og ansvarshavende: 1. Brukertester, brukere skal teste prototype, samt teste mellom systemtest og akseptansetest (kunde/ Prosjektet(utviklere)) 2. Modultest, Prosjektet(utviklere)) 12

13 3. Systemtest, Prosjektet(utviklere) tester systemet 4. Sikkerhetstest, Prosjektet(utviklere) tester systemet (bistand fra kunde) 5. Installasjonstest, Prosjektet(utviklere) tester systemet (bistand fra kunde) 6. Akseptansetest, kunde tester systemet (bistand fra Prosjektet(utviklere)) 7. Godkjenningstest, Kunde tester systemet (bistand fra Prosjektet(utviklere)) 8.4. Godkjenningstest Forutsetninger Akseptansetesten er godkjent av Kunde og løsningen er installert i produksjonsmiljøet. Det skal kontrolleres at løsningen som er installert i produksjonsmiljø har de samme egenskaper som den hadde i akseptansetest. Godkjenningskriteriene for leveransen er følgende: Systemet skal fungere som en helhet i henhold til krav og spesifikasjoner som er godkjent av kunde i analyse og designfasen. Godkjenning av avtalt dokumentasjon vil være basert på en vurdering av kompletthet og at dokumentasjonsstandarder er fulgt. Testdekning skal være min 95 %, og det skal ikke være gjenstående feil til feilretting av 1,2 og 3. ( 1 er alvorlige kritiske feil, 2 er alvorlige feil og 3 er ikke alvorlige men brukermessig uakseptable feil. Feil som er klassifisert i nivå 4 eller 5 kan flyttes til en retteplan etter avtale mellom partene.) Planen for retting av kjente feil av alle alvorlighetsgrader er akseptert av begge parter. Med gjenstående feil menes feil som er meldt men som ikke er ferdigbehandlet. Kunden skal før utløpet av godkjenningsperioden sende Leverandøren en skriftlig melding om resultatet av undersøkelsen, og om leveransen anses å være i samsvar med det avtalte og dermed kan godkjennes, eller ikke. Er slik melding ikke sendt innen utløpet av godkjenningsperioden anses leveransen likevel som godkjent (ved passivitet) Ikke godkjenning av løsningen Dersom kontraktselementer ikke er oppfylt innen overtakelsesperiodens utløp kan dette gi sanksjoner som er skissert i prosjektets kontrakt. Det være seg tilbakelevering av systemet, utsatt frist med økonomiske årsaker eller en reforhandling av kontrakt. 13