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
Forprosjekt Bacheloroppgave 2012
1. 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
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 2012.
3
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
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
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
○ 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
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 08.00 16.00. 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
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
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 1 – 10. Utfallet blir da basert på den matematiske formelen:
Type
Sannsynlig
Konsekvens
Risiko
Sykdom innad i gruppen
2.0
7.0
28, 6 %
Feil på utstyr
1.5
9.0
16.6 %
Komplekst design
2.0
7.0
28,5 %
Deler av applikasjon møter ikke kravspesifiksjonen
2.5
8.5
29, 4 %
Liten kompetanse innad i gruppen
3.0
9.0
33,3 %
Dårlige estimater
2.0
7.5
26,6 %
10
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
6. Plan for gjennomføring
6.1 Gannt-skjema
12
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