Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006

Transkript

1 Forstudierapport Magne Rodem og Jan-Erik Strøm 18. juni 2006

2 Innhold 1 Introduksjon 3 2 Bakgrunn for prosjektet Beskrivelse av problemer og behov Kort om dagens systemer Prosjektmål Effektmål Resultatmål Prosessmål Prosjektets omfang Rammebetingelser 4 5 Kritiske suksessfaktorer 4 6 Risikoanalyse Risikodiagram Beskrivelse av hver risiko Konklusjon Kost/nytte-analyse 10 8 Retningslinjer og standarder Krav til dokumentasjon Krav til kvalitetsgjennomganger Krav til standarder og metoder Prosjektorganisering Anbefaling om videre arbeid Revisjonshistorie 11 2

3 1 Introduksjon I forstudierapporten ønsker man at oppdragstaker og oppdragsgiver skal få en felles oppfatning av hvilke tekniske problemer prosjektet vil møte. Man ønsker samtidig å finne ut om prosjektet skal gjennomføres, og eventuelt gi en overordnet beskrivelse av hva slags system som skal utvikles. 2 Bakgrunn for prosjektet 2.1 Beskrivelse av problemer og behov Telenor Mobil tilbyr i dag tjenesten ProffNett til sine bedriftskunder. Denne tjenesten fungerer som en hussentral på mobilen som blant annet gir brukerne økt fleksibilitet og mulighet til å styre egen tilgjengelighet. Brukerne kan selv stille inn hvordan innkommende anrop skal behandles når de er opptatt eller ikke tilgjengelig. Dette kan gjøres via Internett, WAP eller på mobiltelefonen. En administrator kan ved hjelp av et en web-basert løsning melde medlemmer inn og ut av bedriftens ProffNett, og hver enkelt bruker kan administrere sitt eget abonnement ved å benytte Telenor Mobils webside. Hver bruker i ProffNett får sitt eget internnummer (3-7 siffer), og brukerne har da en nettsentrisk adressebok for oppslag. Denne ønsker man at brukeren skal kunne aksessere direkte fra telefonen. En bruker skal kunne slå opp i adresseboka for å hente ned kontakter som brukeren deretter kan ringe til. Det vil i denne sammenheng også være nyttig for en bruker å kunne lagre kontakten i sin lokale adressebok. 2.2 Kort om dagens systemer ProffNett har allerede en nettsentrisk adressebok som er tilgjengelig via et web-basert grensesnitt. Da brukerne av ProffNett ikke alltid har tilgang til PC med Internettoppkobling, vil det være hensiktsmessig å kunne aksessere adresseboken fra telefonen via en J2ME-applikasjon. De fleste av dagens mobiltelefoner har støtte for GPRS eller 3G, som blant annet gir økt overføringshastighet og en kontinuerlig oppkobling mot datanettverket. Dette har den fordelen at brukeren slipper å ringe opp for hver gang han ønsker å aksessere Internett. Dermed kan en J2ME-applikasjon raskt og enkelt koble seg opp mot en adressebok som gjøres tilgjengelig på Internett. 3 Prosjektmål 3.1 Effektmål Oppdragsgiver ønsker å se en J2ME-applikasjon med et godt og brukervennlig brukergrensesnitt som vil fungere som en prototyp og dermed demonstrerer hvilke muligheter en slik applikasjon har med tanke på å tilfredsstille bedriftskunder som ønsker mer avanserte telefonløsninger. 3

4 3.2 Resultatmål Det skal utvikles en applikasjon for mobiltelefoner som ved å koble seg opp mot en nettsentrisk adressebok skal kunne hente ned kontakter som er registrert i et register over bedriftens ansatte. Applikasjonen skal fungere på et utvalg av mobiltelefoner. 3.3 Prosessmål Prosjektmedlemmene ønsker økt kompetanse innenfor programmering i Java (J2ME) og systemutviklingsmetoder. Spesielt ønsker vi å ta i bruk og lære mer om extreme Programming og dets idiomer. Gruppa ønsker å lære av å oppleve resultatene og konsekvensene av de beslutninger som tas. Gruppa ønsker å oppnå høyeste karakter (A) på hovedprosjektet. 3.4 Prosjektets omfang Den ferdige applikasjonen skal ikke erstatte dagens system, men være et supplement til dagens webbaserte adresseboktjeneste. 4 Rammebetingelser Systemet skal være ferdigstilt innen 31. mai Applikasjonen skal utvikles i programmeringsspråket Java. Omfanget av prosjektet er beregnet til å være 450 timer. Avvik på mer enn 10% bør ikke forekomme. 5 Kritiske suksessfaktorer Faktorer som vil være kritisk avgjørende for prosjektets utfall: Godt samarbeid innad i prosjektgruppa. God dialog med oppdragsgiver. Ikke bruke for mye tid på små, urelevante ting, men se mer på helheten og sørge for å bli ferdig i tide. Gruppa må tilegne seg nødvendig kunnskap underveis. God modularisering. 4

5 6 Risikoanalyse Gruppas risikoanalyse består av flere ulike punkter, der man for hvert punkt vurderer sannsynlighet, konsekvens, akseptnivå, prioritering og tiltak. Sannsynligheten for at en risiko skal inntreffe graderes med en skala fra 0-1, konsekvensen vurderes på en skala fra 1-5 og akseptansenivået tilsvarer produktet av sannsynligheten og konsekvensen. Vurdering av kostnader utelates i analysen, da dette ikke er relevant i dette prosjektet. Gruppa har kommet fram til at følgende risiki vil være relevante i forhold til prosjektet: 1. Utvikling av feil system. 2. Hyppig endring av krav underveis. 3. Bruk av ny og uprøvd teknologi. 4. Gold-plating. 5. Urealistisk tidsplan. 6. For mye annet arbeid. 7. Mangel på kritisk kunnskap. 8. Lengre fravær. 9. Datahavari. 5

6 6.1 Risikodiagram 6

7 6.2 Beskrivelse av hver risiko I dette avsnittet vil hver risiko bli beskrevet nærmere, og det tas vurderinger angående tiltak og en eventuell risikoreduksjon. 1. Utvikling av feil system Dersom utviklerne misforstår deler av oppgaven, kan dette medføre at sluttresultatet avviker fra hva oppdragsgiver faktisk ønsker. Sannsynlighet: 0.2. Konsekvens: 5. Akseptnivå: 1. Prioritering: Middels. Risikoreduksjon: Kontinuerlig kontakt med oppdragsgiver. Utarbeidelse av prototyper. Tiltak: Prøve å rette opp det som har blitt gjort feil. 2. Hyppig endring av krav underveis Hvis det til en hver tid skulle komme nye krav, kan det oppstå at en av kravene bryter med et tidligere krav/arkitektur. Dette vil dermed føre til økt tidsforbruk, og i verste fall at systemet ikke kan ferdigstilles i tide. Sannsynlighet: 0.4. Konsekvens: 4. Akseptnivå: 1.6. Prioritering: Middels/høy. Risikoreduksjon: Avdekke krav av kritisk betydning så tidlig som mulig. Tiltak: Vurdere viktigheten av det nye kravet. Hvis det kan utelates, vurder konsekvens. Eventuelt vurder tidsforbruket for å likevel implementere det nye kravet. 3. Bruk av ny og uprøvd teknologi Utviklerne vil i mange tilfeller bli nødt til å sette seg inn i ny og uprøvd teknologi. Dette kan få konsekvenser dersom den nye teknologien er for omfattende. Sannsynlighet: 0.6. Konsekvens: 3. Akseptnivå:

8 Prioritering: Høy. Risikoreduksjon: Risikoen kan reduseres ved å teste ut den nye teknologien på et tidlig tidspunkt, slik at overraskelser unngås. Tiltak: Enten bruke tid på å lære den nye teknologien, eller finne mulige alternativer. 4. Gold-plating Det hender ofte at utviklerne eller oppdragsgiver blir fristet til å tilføre nye funksjoner til systemet som egentlig ikke er nødvendige. Dette kalles gjerne gold-plating. I tillegg er gruppa på nåværende tidspunkt litt usikre på hvilke funksjonaliteter som skal implementeres, samt hvordan dette kan avgrenses slik at arbeidsmengden ikke blir for stor. Sannsynlighet: 0.4. Konsekvens: 2. Akseptnivå: 0.8. Prioritering: Middels/lav. Risikoreduksjon: Fornuftig prioritering av implementasjoner. De viktigste funksjoner implementeres først, mens de mindre viktige tas til slutt. Tiltak: Fjerne eller akseptere de unødvendige funksjonene. 5. Urealistisk tidsplan I starten av et prosjekt er det vanskelig å beregne nøyaktig hvor lang tid arbeidet vil ta. Dette kan medføre at det settes opp en urealistisk tidsplan. Sannsynlighet: 0.6. Konsekvens: 4. Akseptnivå: 2.4. Prioritering: Høy. Risikoreduksjon: Unngå gold-plating og sørge for å ha gode rutiner slik at man kan være mest mulig produktiv. Tiltak: Analysere tidsplanen og finne ut hva som kan gjøres for å bruke mindre tid. 6. For mye annet arbeid Prosjektgruppa består av studenter som har en del andre gjøremål i forbindelse med studiene. Dette kan føre til at gruppa får mindre tid til prosjektet enn det som er ønskelig. Sannsynlighet:

9 Konsekvens: 4. Akseptnivå: 1.2. Prioritering: Middels. Risikoreduksjon: Unngå gold-plating og nedprioritere andre fag. Tiltak: Jobbe mer, og kanskje bruke helger og kvelder til prosjektjobbing. 7. Mangel på kritisk kunnskap Dersom gruppa mangler kunnskap som er kritisk for gjennomføringen av prosjektet, kan dette blant annet føre til overskridelse av tidsplan. Gruppemedlemmene må da bruke tid på fylle dette kunnskapshullet. Sannsynlighet: 0.3. Konsekvens: 3. Akseptnivå: 0.9. Prioritering: Middels/lav. Risikoreduksjon: Sørge for å ha mest mulig kunnskap på plass før prosjektet starter. Tiltak: Jobbe mer for å få nødvendig kunnskap. 8. Lengre fravær Fravær i prosjektgruppa er noe man sjelden kan forutse. Lengre fravær kan for eksempel skyldes alvorlig sykdom. I en liten prosjektgruppe kan dette få betydelige konsekvenser. Sannsynlighet: 0.2. Konsekvens: 5. Akseptnivå: 1.0. Prioritering: Middels. Risikoreduksjon: Denne risikoen er vanskelig å forhindre. Tiltak: Skaffe en kompetent erstatter. 9. Datahavari Noen ganger kan det oppstå uventede ting med maskinvare eller programvare i forbindelse med et prosjekt. Man kan miste data, programkode og dokumenter, eller maskiner og tjenere kan plutselig slutte å fungere. Sannsynlighet: 0.2. Konsekvens: 5. 9

10 Akseptnivå: 1.0. Prioritering: Middels. Risikoreduksjon: Sørge for å hyppig lage sikkerhetskopier av det arbeidet som er blitt gjort. Tiltak: Akseptere tapet og prøve å gjøre det beste ut av situasjonen. 6.3 Konklusjon Risikoanalysen viser at risikofaktorene 3 og 5 vil være kritiske. Dette medfører at gruppa må forberede seg på å møte problemer i forbindelse med disse. For hvert av disse punktene bør man fokusere på risikoreduksjon og å forberede tiltak. 7 Kost/nytte-analyse Oppdragsgiver ønsker ikke en kost/nytte-analyse, da det på nåværende tidspunkt ikke eksisterer direkte kostnader tilknyttet prosjektet. 8 Retningslinjer og standarder 8.1 Krav til dokumentasjon Hoveddokumentene som skal leveres i løpet av prosjektperioden er: Forstudierapport Kravdokument Designdokument Sluttrapport Whitepaper (arkitekturskisse) Javadoc Godt organisert, lesbar programkode 8.2 Krav til kvalitetsgjennomganger Veileder vil vurdere og gi tilbakemelding på de dokumenter som gruppa utarbeider etter hvert som de blir gjort tilgjengelige. Dette gjelder forstudierapporten, kravrapporten, designdokumentet og sluttrapporten. I tillegg vil systemet gjennomgå en akseptansetest hvis utfall vil gi en indikasjon på om oppdragsgiver er fornøyd. Dette vil gjennomføres i forbindelse med en prototyp som skal demonstrers 10

11 for oppdragsgiver. Her ønsker man å sjekke kvaliteten på de mest viktige funksjonene. Dette er måha-funksjoner som er selve kjernen i systemet. I vårt tilfelle vil dette være søking, ringing, og sending av tekstmelding fra J2ME-klienten. 8.3 Krav til standarder og metoder Koden skal følge Java Code Conventions 9 Prosjektorganisering Kontaktperson for oppdragsgiver (Telenor Mobil) er Jan Erik Wold. Veileder for prosjektet er Mildrid Ljosland. Oppdragstakere er Magne Rodem og Jan-Erik Strøm. Oppdragsgiver og oppdragstakere vil fylle rollen som styringskomité og ha ansvar for å vurdere kvaliteten på resultatet. Når det gjelder prosjektleder så deler oppdragstakerne på den oppgaven, siden det er så få personer på gruppa. Arbeidsfordelingen vurderes etter hvert som oppgavene klargjøres. 10 Anbefaling om videre arbeid Prosjektet anbefales videreført med de rammene og planene som er lagt fram i forstudierapporten. 11 Revisjonshistorie Dato Versjon Beskrivelse Første utgave Revidert etter tilbakemelding fra veileder Retting av diverse skrivefeil La til informasjon om kost/nytte og kvalitetsgjennomgang Gjort dokumentet klart for innlevering 11