Forprosjekt Bacheloroppgave 2012

Transkript

1 Forprosjekt Bacheloroppgave 2012 Dette dokumentet inneholder beskrivelse av prosjektet, rammer, mål og systemutviklingsmodell Skrevet av Lap To, Håvard Andreas Heggheim og Tobias Moe Thorstensen 1

2 Forprosjekt Bacheloroppgave Mål og rammer 1.1 Bakgrunn 1.2 Prosjektmål 1.3 Rammer 2. Omfang 2.1 Problemområde 2.2 Avgrensninger 2.3 Oppgavebeskrivelse 2.4 Programvare som vil bli benyttet under prosjektperioden 3. Prosjektorganisering 3.1 Ansvar og roller Oppdragsgiver Veileder Prosjektleder Webansvarlig Delt ansvar 3.2 Rutiner og regler i gruppa 4. Planlegging, oppfølging og rapporterting 4.1 Utviklingsmetodikk 4.2 Plan for statusmøter og beslutningspunkt 5. Kvalitetssikring 5.1 Dokumentasjon, standardbruk og kildekode 5.2 Konfigurasjonsstyring 5.3 Risikoanalyse Risikohåndtering 6. Plan for gjennomføring 6.1 Gannt-skjema 6.2 Forklaring på Gannt-skjemaet 2

3 1. Mål og rammer 1.1 Bakgrunn Høgskolen har i samarbeid med Gjøvik kommune tidligere gjennomført forskningsprosjektet AKTIVe (Aktiverings- og KommunikasjonsTeknologi Innen Velferdstjenester for Eldre) med støtte fra Regionalt Forskningsfond Innlandet. Dette prosjektet skal benyttes som en veiledning for spesifikasjoner og krav underveis i bacheloroppgaven, men det vil være muligheter for å gjøre endringer i samtale med oppdragsgiver. Vår oppgave er å videreføre prosjektet. I løpet av prosjektets levetid skal spesifiseringen av kravene fullføres, samt utviklingen av applikasjonen som forbedrer kommunikasjon mellom de pleietrengende hjemmeboende og kommunens omsorgstjeneste. Gjøvik kommune ønsker å være en fremtredende aktør blandt landets kommuner, som tilbyr lett håndterlige elektroniske tjenester tilegnet kommunens pleietrengende. 1.2 Prosjektmål Målet med AKTIVe er å forenkle kommunikasjonen mellom omsorgstjenesten og hjemmeboende pasienter. AKTIVe skal kunne brukes mellom pasientene som en sosial kommunikasjonsplattform. Ved å lette kommunikasjonen mellom helsepersonell og pasienter, vil man kunne spare omsorgstjenesten for mye arbeid. Hjelpepersonell bruker i dag mye tid på å kjøre til og fra pasienter, noe som er veldig ressurskrevende, ineffektivt, og lite miljøvennlig. Applikasjon skal spesielt være utviklet for Android baserte nettbrett. En ferdig utviklet og stabil versjon skal være ferdig innen utløpet av mai

4 1.3 Rammer Applikasjonen skal utvikles for Android-baserte nettbrett Nettbrettet må ha kamera Brukervennlighet som er beregnet på en eldre brukergruppe Video- og samtalekommunikasjon er en essensiell bit i applikasjonen Sensitiv informasjon som overføres skal holdes til et minimum. 2. Omfang 2.1 Problemområde Gjøvik kommune i samarbeid med Høgskolen i Gjøvik ønsker å forbedre tilbudet for eldre i kommunesektoren. Samfunnet i dag blir mer og mer teknologibasert, bruken av nettbrett og smarttelefoner har effektivisert, og forenklet mange oppgaver i samfunnet. Denne nye teknologien er det mange eldre som ikke ser nytteverdien av, fordi denne generasjonen besitter liten erfaring med bruk av slike verktøy. Dagens applikasjoner og verktøy kan raskt bli for avansert og krevende i bruken for de eldre, da de ofte kommer med kompliserte brukergrensesnitt, mange opsjoner og innstillinger. Dette kan øke læringskurven for mange brukere som ikke er vant med slike tjenester. 2.2 Avgrensninger Applikasjonen skal tilby hjelpepleiere mulighet for kommunikasjon med pasienter ved hjelp av lyd og video. Pasientene skal også kunne kommunisere seg i mellom. Påminnelsestavle er også en tjeneste som skal være til stede, slik at sluttbrukeren har en totaloversikt over kommende avtaler. Programvaren skal ha et enkelt grensesnitt som er brukervennlig for målgruppen. Applikasjonen skal først og fremst utvikles og optimaliseres for Android baserte enheter, men det blir sett på muligheten for støtte på andre platformer. 4

5 Applikasjonen er ikke ment for å behandle sensitiv informasjon. Den skal heller ikke kunne lagre slike data. Sikkerheten blir derfor begrenset til en autentiserings-server som krever brukernavn og passord når applikasjonen blir kjørt. På klientsiden vil applikasjonen kunne automatisk huske brukernavn og passord da denne ikke skal innholde noe sensitiv informasjon om brukeren. Strømming av video og lyd vil foregå uten noen form for mellomlagring. 2.3 Oppgavebeskrivelse Oppgaven er å utvikle en applikasjon som er lett i bruk, med et enkelt grensesnitt. Den eldre generasjon går glipp av mange unike muligheter som den nye teknologien gjør tilgjengelig. Disse verktøyene/applikasjonene har muligheten til å forenkle livet deres. En enkel oppgave som å lese avisen kan gjøres lettere på en håndholdt enhet. Man reduserer behovet for fysiske bevegelser, ved å unngå å gå til butikken for å kjøpe avisen. Hvis man er veldig engasjert i en nyhetssak har man også muligheten til å dele sine meninger, så hele verden kan lese, reflektere og kommentere deres tanker og ideer. Teknologiske verktøy er også en portal for underholdning. Både Bingo og Yatzy kan spilles med mange tusen personer fra hele verden. Det skal utvikles en applikasjon som spesielt er tilegnet for eldre. Med tanke på at i dag lever mange alene uten mulighet for å kunne komme seg ut og sosialisere seg med andre. Det blir da et stort behov for at ansatte fra hjemmetjenesten kan komme og prate litt med dem f.eks når en god venn har gått bort. Ønsket er å tilby en høyteknologisk enkel, og sosial løsning som letter arbeidet for hjemmetjenesten, og samtidig sprer glede hos eldre, der de får større muligheter til sosialere seg i omgangskretsen sin. Ønsket funksjonalitet er video- og samtalekommunikasjon, en påminnelsesavtale, og en løsning for meldingsutveksling. Det skal også vurderes muligheter for å integrere programvare som finnes tilgjengelig på Android Market i totalløsningen. Applikasjonen skal underveis testes blant ansatte og beboere i Gjøvik kommune og videreutvikles basert på tilbakemeldiger fra sluttbrukerne. Mye av utfordringen i prosjektet ligger 5

6 ikke bare i utviklingen av kjernefunksjonaliteten, men et godt og intuitivt brukergrensesnittet skal også være på plass. 2.4 Programvare som vil bli benyttet under prosjektperioden Gruppen vil benytte seg av ulike programvarer for å kunne utføre oppgaven. Subclipse Programvare for å holde versjonskontrollering av kildekoden som blir produsert innad i gruppen. Dette verktøyet har vi brukt tidligere og har gode erfaringer med bruken. Google Docs Cloud-basert teksteditor for samkjøring av rapport og forprosjekt. Dette verktøyet viser seg å være veldig bra når flere personer skal jobbe på samme dokument samtidig. Det siste året har formateringsmulighetene i Google Docs blitt veldig bra, noe som gjør at vi slipper mye av samkjøringsproblematikken når vi alle skriver på samme dokument. ArgoUML Open Source programvare for å modellere programvaren. Typisk Use Case og klassediagram. Dette verkøyet har vi erfaringer med fra tidligere, og det fungerer bra nok for vår bruk. Eclipse Integrated Development Enviroment for utviklingen av selve programvaren. Dette er et utviklingsverktøy vi har erfaringer med fra Java programmering tidligere, men det fungerer også greit til andre programmeringspråk. Eclipse har et veldig bra community bak seg, som gjør det lett å få hjelp på forum og lignende tjenester. Eclipse har også støtte for mange gode utvidelser og verktøy, som er lett og installere. Trello Cloud-basert oppslagstavle for å holde orden på oppgaver innad i en sprint. Dette blir brukt som et alternativ til en tavle-basert oppslagstavle. Gantt Project Program for å opprette og vedlikeholde et Gannt-skjema. Dette har enkelte av gruppemedlemmene erfaringer med fra tidligere, og det er Open Source. TortoiseSVN 6

7 Brukes for å administrere SVN repository vår. Vi bruker Subclipse for versjonshåndtering, men der er begrenset med muligheter for sletting av filer og/eller andre prosjekter. Dette fikser vi med TortoiseSVN om det skulle bli problemer. TeXnicCenter Applikasjon for å skrive i LaTex, et typesetting språk utviklet av Bjarne Stroustrup for utarbeidelse av lengre dokumenter. TeXnicCenter vil være programvaren LaTeX blir skrevet i. 3. Prosjektorganisering 3.1 Ansvar og roller Oppdragsgiver Oppdragsgiver er Høgskolen i Gjøvik i samarbeid med Gjøvik Kommune. Representant fra høgskolen er Tom Røise. I tillegg vil Tommy Karlstad og Einar Malmedal fra Gjøvik kommune bidra til å svare på teoretiske spørsmål angående oppgaven. Veileder Kontaktpersonen vår er Frode Haug. Han vil være vår største ressurs når det kommer til spørsmål knyttet til oppgaveskrivingen. Prosjektleder Gruppen har bestemt at et selvstyre eller en tilnærming til autonomisk styreform passer best. Om det oppstår konflikter innad i gruppen vedrørende avgjørelser er det Håvard Andreas Heggheim som har siste ordet. Webansvarlig Webansvarlig i prosjektet vil være Tobias Moe Thorstensen. Oppgaven til webansvarlig vil være å oppdatere hjemmesiden, skrive nyhetsartikler og legge ut dokumenter. Delt ansvar Gruppemedlemmene blir enig innad i gruppen om mindre oppgaver som må utføres. Hvis det oppstår uenigheter eller andre problemer vil det være prosjektlederens ansvar å ta styring. 7

8 3.2 Rutiner og regler i gruppa Hver deltager på gruppen har signert en kontrakt hvor det har blitt enighet om å dedikere minst 30 timer i uken på prosjektet. Vi sitter på skolen og jobber i vårt tildelte grupperom fra Noen av gruppemedlemmene har forelesningstimer som vil foregå i dette tidsrommet, men resten av tiden blir brukt på å jobbe med prosjektet. Se vedlagt dokument om grupperegler for mer utfyllende informasjon om regler i gruppen. 4. Planlegging, oppfølging og rapporterting 4.1 Utviklingsmetodikk Gruppen har hatt en diskusjon på hvilken utviklingsmodell som skal følges under prosjektets levetid. Konklusjonen ble at fokuset vil bli holdt på en smidig utviklingsmodell, da slike modeller legger til rette for at kravspesifikasjonen kan bli endret underveis i prosjektet. De gjentagende prinsippene i slike modeller er iterasjoner, kontinuitet og hyppige utgivelser. Utviklingsmodellene som ble trukket frem var XP og Scrum, begge er gode alternativer, med sine gode og dårlige sider. extreme Programming(XP) har på like linje med Scrum hyppige utgivelser og iterasjoner, men forskjellig terminologi. extreme Programming skiller seg fra andre utviklingsmodeller ved å innføre prinsippet parprogrammering. Dette er en arbeidsmetodtikk som legger til rette for at to personer skal kunne sitte sammen og utvikle kode. Dette er et prinsipp som fungerer meget bra, men da gruppen består kun av tre personer kan dette bli vanskelig å gjennomføre. Et annet aspekt ved parprogrammering er at tiden blir lite effektivt benyttet og med tanke på arbeidsmengden som gruppen skal utføre, viser dette seg å være et problem. Som eneste gjenstående alternativ, falt valget på Scrum. Denne utviklingsmodellen er som kjent en smidig utviklingsmodell som legger til rette for endring i kravene fra interessenten. I startfasen av prosjektet vil oppdragsgiver komme med krav til programvaren, dette kalt Product Backlog. Grunnpilaret i scrum er sprinter. I forkant av en sprint vil det bli holdt et møte med oppdragsgiver, kalt sprint planning meeting. Dette møtet fører til en Sprint Backlog som beskriver funksjonaliteten som skal implementeres i applikasjonen i løpet av sprinten. Valgt funksjonalitet skal være i tråd med beskrevet funksjonalitet i product backlog. Etter et slikt møte vil gruppen sette seg ned i 14 dager, skjermet fra interessenten og implementere ønsket funksjonalitet. Den eneste aktøren i gruppen som kan prate med oppdragsgiver under en sprint, 8

9 er Scrum master. Vedkommende som vil ha denne rollen er prosjektlederen i gruppen. Da sprinten er i sluttfasen vil gruppen holde et sprint retroperspectiv møte hvor sprinten vil bli vurdert innad i gruppen. Før neste sprint startes vil interessenten bli presentert for arbeidet som er blitt gjort under et sprint review meeting. Metodikken nevner ikke hvordan kravspesifikasjonen skal utformes, gruppen har derfor valgt å trekke inn deler fra andre systemutviklingsmodeller som beskriver denne fasen bedre. 4.2 Plan for statusmøter og beslutningspunkt Da gruppen benytter seg av utviklingsmetodikken Scrum er vi avhengig av å planlegge hver sprint. Under et slikt møte vil det bli diskutert med oppdragsgiver hvilken funksjonalitet som skal implementeres. Dette møtet medfører dokumentet sprint backlog. Denne vil bli publisert på hjemmesiden til prosjektet. Etter hver endte sprint vil gruppen vise frem til oppdragsgiver hva som har blitt gjort, også kalt sprint review meeting. Det skal også utarbeides tre statusrapporter, som også vil bli tilgjengelig på internett. Gruppen vil være i ukentlige møter med veileder for å oppdatere status, samt motta innspill på videre arbeid. 5. Kvalitetssikring 5.1 Dokumentasjon, standardbruk og kildekode Skriftlige dokumenter blir skrevet i Google docs og i andre tekstredigeringsprogrammer. Det er opprettet en felles gruppelogg på Google docs, problemstillinger som måtte dukke opp og viktige avgjørelser som blir tatt i gruppen blir også notert her. Mye av den samme informasjonen blir også lagt ut på fremsiden av nettsiden vår. Alle medlemmene på gruppen har også sin egen logg hvor timeantall og en beskrivelse av hva som har blitt gjort nedtegnes. ASDoc vil bli benyttet for å autogenerere en enkel og pen dokumentasjon basert på kommentarer i kildekoden. Denne dokumentasjonen blir generert som et oversiktlig HTML-dokument. Hvert gruppemedlem plikter seg til å kommentere koden, på en ryddig og god måte. 9

10 5.2 Konfigurasjonsstyring Subclipse blir benyttet for å versjonskontrollere kildekoden. Gruppen har benyttet denne programvaren tidligere, og besitter erfaring med denne applikasjonen. Oppdateringer av kildekoden vil bli gjort regelmessig, slik at hvert medlem på gruppen alltid jobber på siste tilgjengelige versjon. 5.3 Risikoanalyse Tabellen under gir et inntrykk av risikoen til prosjektet. Koeffisientene som blir oppgitt under er oppgitt i en skala fra Utfallet blir da basert på den matematiske formelen: Type Sannsynlig Konsekvens Risiko Sykdom innad i gruppen , 6 % Feil på utstyr % Komplekst design ,5 % Deler av applikasjon møter ikke kravspesifiksjonen , 4 % Liten kompetanse innad i gruppen ,3 % Dårlige estimater ,6 % 10

11 Risikohåndtering For å overkomme problemet med manglende kompetanse vil det gå med tid til å sette seg inn i dokumentasjon og ulike APIer. Det er en betydelig risiko at applikasjonen som blir utviklet ikke er tilegnet brukergruppen, noe som fører til at applikasjonen ikke vil bli brukt. For å redusere denne risikoen, vil det bli utført tester på sluttbrukerne underveis i utviklingsfasen. Ved å ha god kommunikasjon med oppdragsgiver kan risikoen for at applikasjon ikke møter kravspesifikasjonen reduseres. Manglende erfaring med utvikling på mobile plattformer kan bli en kritisk faktor. For å sørge for at det ikke blir noen konsekvenser av dette, må det passes ekstra på hvilke deler av applikasjonen vi utvikler først. Dette kan unngås ved at oppdragsgiver prioriterer de viktigste funksjonalitetene under møtet hvor sprint backlog blir utarbeidet. Dette er en fase hvor det er naturlig å komme med innspill til interessenten. 11

12 6. Plan for gjennomføring 6.1 Gannt-skjema 12

13 6.2 Forklaring på Gannt-skjemaet Prosjektfasen starter med forprosjektet og et innledene møte med oppdragsgiver for å få en overordnet beskrivelse av hva som skal utvikles. Deretter følger kravspesifiseringen, hvor funksjonaliteten i applikasjonen blir utarbeidet. Gannt-skjemaet viser at det vil bli utført syv sprinter, hvor hver sprint starter med sprint backlog meeting. Deretter følger det to uker med utvikling. Hver sprint avsluttes med et sprint review meeting, hvor arbeidet blir presentert for oppdragsgiver. Det har blitt estimert at det vil være fornufting å avholde tre eksterne testfaser, hvor sluttbrukerne tester programvaren. Rapporten skal utarbeides gjennom hele prosjektfasen, denne aktiviteten avsluttes 18. mai. Applikasjonen som blir utviklet vil bli sluppet som en beta versjon nøyaktig én måned før prosjektet avsluttes, dette for å rette eventuelle feil. En offisiell utgivelse vil bli utgitt 21. mai. Rapporten skal leveres to dager senere, og den muntlige presentasjonen vil finne sted første uken i juni. 13