Forprosjekt Coop Oppgaveplanlegger

Transkript

1 Forprosjekt Coop Oppgaveplanlegger Atle Orm, Daniel Gausetvik og Therese Thorkildsen February 21,

2 Contents 1 Mål og rammer Bakgrunn Prosjektmål Rammer Omfang Oppgavebeskrivelse Problemstilling Bakgrunn for problemstilling Avgrensning Prosjektorganisering Ansvarsforhold og roller Rutiner og regler i gruppa Gruppedeltakere Kompetanse og bakgrunn Grupperegler Planlegging, oppfølging og rapportering Hovedinndeling av prosjektet Plan for statusmøter og beslutningspunkter Research Sprinter og aktiviteter Organisering av kvalitetssikring Dokumentasjon, standardbruk og kildekode Konfigurasjonsstyring Teknologi Risikoanalyse (identifisere, analysere, tiltak, oppfølging) Plan for gjennomføring Milepæler

3 1 Mål og rammer 1.1 Bakgrunn Gitek AS Gitek AS ble etablert i 1992 og er lokalisert i Gjøvik. Bedriften består av fire ansatte som alle er aktive eiere. I tillegg til dette har Gitek har gode samarbeidspartnere som bidrar med sin kapasitet. Selskapet har siden oppstarten drevet med lønnsomhet og har utviklet produkter og tjenester med egne midler. Gitek er en liten, men effektiv bedrift med svært kort vei frem til folk som kan gi bistand. Kunden når frem og får hjelp meget raskt. Dette gjør at Gitek har kunder i en rekke bransjer som de har etablert varige gode relasjoner til. 1 GITEK jobber blant annet med å utvikle programvare for effektiv oppfølging av kjeder av butikker og restauranter. Det gjelder kundeundersøkelser, butikkvalitet, (Mysteri shoppers), internkontroll, dokumenthåndtering osv. For tiden jobber vi med å utvikle App for registrering av driftsstatus og med lagring av situasjonsfoto og sammenligning med målbilde og automatisk etablering av handlingsplan for en stor aktør i dagligvarebransjen. Alt pakket inn i en driftsportal for butikksjefen/driftssjefen. Coop Norge SA Coop er navnet på den samlede virksomheten til forbrukersamvirket i Norge. under Coop-navnet finner vi 117 samvirkelag, deres fellesorganisasjon Coop Norge SA med datterselskaper, deriblant vareforsyningsselskapet Coop Norge Handel AS og eiendomsselskapet Coop Norge Eiendom AS som de to største, samt Smart Club AS. Cirka mennesker har i dag Coop som sin arbeidsplass og nesten én av fire handleposer kommer fra en Coop-butikk. Coop Norge SA, stiftet 27. juni 1906, er samvirkelagenes fellesorganisasjon og eid av samvirkelagene gjennom medlemskap. som andelslag har Coop Norge varierende medlemstall og varierende andelskapital. Fellesorganisasjonen bygger sin virksomhet på samvirkeprinsippene. På samvirkelagenes vegne skal Coop Norge ivareta sentrale fellesoppgaver som innkjøp, vareforsyning og kjededrift slik at det dannes et grunnlag for god drift i lagene og konkurransekraft i markedet. En berøringsskjerm er en elektronisk skjerm som kan oppdage tilstedeværelsen og plassering av en berøring i displayet. Begrepet refererer vanligvis til å berøre skjermen på enheten med en finger eller hånd. Berøringsskjermer kan også ane andre passive objekter, som for eksempel en pekepenn. Berøringsskjermer er vanlig i enheter som spillkonsoller, alt-i-ett-maskiner, tablets og smarttelefoner. HTML5 er en kommende standard for strukturering av nettsider. Den er bygd opp på samme måte som vanlig HTML, 1 Hentet fra 3

4 men kommer til å ta over for både HTML4 og XHTML. HTML5 inkluderer nye funksjoner og mulighet som visning av lyd, video og vektorgrafikk og er bedre egnet til visning av multimedia. Det er forventet at HTML5 på sikt kan ta over for Flash. CSS3 er en videreutvikling av CSS2 og inkluderer mange nye funksjoner for penere visning og layout av nettsider. Animasjoner, skygger og overganger er sentrale i bruken av CSS3 og tar bort behovet for lange og kompliserte JavaScritp-koder. 1.2 Prosjektmål Effektmål - konsekvensen av prosjektet Etter prosjektet jobber GITEK videre med systemet. GITEK står for kommunikasjon mellom programvaren og serveren som skal brukes og sørger for at programvaren er klar for implementering på maskinvaren Coop anskaffer. Den ferdige programvaren vil bli implementert i det nye systemet i Coop sine butikker. Dette vil føre til bedre oversikt over rutiner og arbeidsoppgavene som skal utføres i butikkene. Dette gir arbeidsgiverne bedre kontroll over hvilke rutiner og oppgaver som har blitt utført og hvem de har blitt utført av. Programvaren vil implementeres på de trykkfølsomme skjermene butikkkjeden velger å sette opp. Arbeidsoppgaver vil være lett synlig og hver ansatt kan velge å få oversikt over sine oppgaver for å lettere kunne utføre disse. Kommentarsystemet vil åpne en ny kommunikasjonskanal mellom de ansatte og arbeidsgiveren slik at det blir lettere å gi beskjed om eventuelle avvik. Resultatmål - prosjektet som leveres Det leverte prosjektet skal bestå av en programvareløsning som kan planlegge oppgaver og føre til bedre effektivitet i arbeidsoppgavene hos kjeden Coop. Programvaren skal være designet for bruk på trykkfølsomme skjermer slik at de lett kan plasseres på ønskede plasser i butikken. Den skal være brukervennlig og skal ikke stille krav til omfattende opplæring i bruk. Programvaren skal kunne implementeres på tvers av dagens plattformer, så løsningen vil være en såkalt WebApp basert på HTML5, CSS3, JavaScript og PHP. Oppdragsgiver har valgt å bruke nettbrett som plattform, så her må vi forholde oss til plattformene ios og Android. Applikasjonene skal også kunne lastes ned fra Apple AppStore og Android Marked. Læringsmål Spesifikke læringsmål I løpet av bacheloroppgaven skal studenten: 4

5 Få økt innsikt i hvordan smarttelefoner/lesebrett kan benyttes som hjelpemiddel for å utføre komplekse oppgaver som tidligere har krevd spesialdesignet verktøy og instrumenter Ta i bruk kunnskap fra bachelorstudiet og flette dette inn i prosjektet Få en større innsikt i teknologier som HTML5, CSS3, JavaScript og PHP Sette seg inn i og lære Sencha Touch Mobile Skape applikasjoner som er effektive og brukervennlige til berøringsskermer Generelle læringsmål Emnebeskrivelsen for IMT3912 Bacheloroppgave IMT beskriver følgende læringsutbytte: Kunnskaper Ny kunnskap innen en selvvalgt del av sitt fagområde Forståelse for metodisk arbeid, evne til refleksjon og evne til systematisk/vitenskapelig vurdering Kompetanse til å planlegge og utføre en selvstendig oppgave, formulere problemstillinger og analysere disse med utgangspunkt i både teoretisk og empirisk materiale og å gjennomføre en oppgave på en metodisk tilfredsstillende måte Ferdigheter Ferdigheter i å utarbeide konkrete problemstilling av samfunnsmessig interesse innen fagområdet, under veiledning Ferdigheter i å identifisere og vurdere litteratur som er relevant for problemstillingen, under veiledning Ferdigheter i å gå i dybden på avgrensede problemstillinger og utarbeide konkrete løsningsalternativer på problemet Ferdigheter i å dokumentere og formidle resultatene fra prosjektarbeidet på en systematisk/vitenskapelig måte 5

6 Generell kompetanse Få innsikt i vitenskapelig redelighet og forståelse for etiske problemstillinger som er av relevans for problemstillingen Bevissthet om problemstillingens og arbeidets konsekvenser for enkeltmennesker, bedrift og samfunn 1.3 Rammer Offentlig rammer Rammene for oppgaven er tidsfristene som finnes på hjemmesiden til HiG. Disse tidsfristene finnes under retningslinjene for bacheloroppgaver. Faget utgjør 20 studiepoeng for hver av gruppedeltakerne. Det er beregnet at en student ved høgskolen bruker 45timer i uken på skole - 20 studiepoeng utgjør 30 av disse timene. Prosjektet må avgrenses etter disse forutsetningene. Teknologiske rammer Det er en forutsetning at applikasjonen skal kunne videreutvikles av Gitek etter ferdigstilling. Det skal benyttes HTML5 i kombinasjon av CSS3, JavaScript og PHP. Prosjektgruppen får tilsendt data fra Gitek for lokaltesting av applikasjonen for testing og utvikling. 2 Omfang 2.1 Oppgavebeskrivelse Kjeden Coop ønsker bedre oppgaveplanlegging i sine butikker. GITEK har blitt forespurt om å lage en oppgaveplanlegger bestående av trykkfølsomme skjermer som plasseres rundt i kjedens butikker. GITEK har igjen forespurt oss om å utføre denne oppgaven. Ønsket er å få spesifisert og utviklet en prototyp for å bruke berøringsskjerm for å kunne velge oppgaver og knytte oppgaver til roller på et skift, daglige og repeterende oppgaver. Ansatte skal kunne redigere og kvittere for utført oppgave ved å berøre skjermen. Det skal også være mulig å kunne utsette enkelte oppgaver. Hvis en oppgave blir utsatt til neste dag, skal den komme opp på oppgavelista denne dagen. Brukeren skal selv skrive inn eget navn, da det er upraktisk å ha navn på alle de ansatte i databasen. Driftssjefen som har ansvar for flere butikker skal kunne se status for alle butikkene og 6

7 se hvilke butikker som har behov for ekstra oppfølging. Programvaren skal også inneholde en nettbasert administrasjonsdel. Her skal arbeidsgivere og driftssjefen kunne logge seg inn og administrere oppgaver og kontrollere at disse blir utført, samt lese av eventuelle kommentarer som legges til av de ansatte. Programvaren som skal utvikles skal kunne implementeres på alle plattformer. Kunden har avgjort at programvaren skal implementeres på en eller flere typer nettbrett og ikke trykkfølsomme skjermer som er koblet opp mot en ekstern datamaskin. Aktuelle plattformer er Android og ios. Programmering Studentene vil ha innflytelse på valg av teknologi og grensesnitt for den aktuelle modulen. Gitek bruker i dag Programmeringsspråk: JavaScript, HTML5, CSS3 og PHP Serverkommunikasjon: Ajax med J-son som datautvekslingsformat Sencha Touch Mobile: JavaScript bibliotek/rammeverk - Databaser: MS-Sql Server og Oracle Funksjonsoversikt i grove trekk Oppsett, valg av aktiv portal (gyldig adresse kommer fra fast server) Pålogging / tilgangsfunksjon: 3 nivåer/ roller Valg av aktiv butikk butikker, Gps-koordinater, søke, velge mine butikker. Lage grensesnitt for: Å legge til/slette/redigere oppgaver og roller Kalenderfunksjon for dags/uke/mnd/år Å knytte oppgaver til rolle og markere når oppgaven skal gjennomføres Vise oppgaver pr. rolle med mulighet for: Å redigere in-line Å markere status (utføres/utsatt/utført) Å skrive kommentarer 7

8 2.2 Problemstilling Hvordan kan en enkel og brukervennlig applikasjon for trykkfølsomme skjermer hjelpe en av Norges største butikkjeder til å bedre kunne planlegge oppgaver i sine butikker, samt kontrollere at disse utføres til riktige tidspunkt? 2.3 Bakgrunn for problemstilling Problemstillingen er et naturlig resultat av hva oppdragsgiver har av ønsker og mål for applikasjonen. Oppdragsgiver ønsker mye fokus på brukergrensersnitt, og det er derfor viktig for oss å fokusere på en enkel og intuitiv løsning som inviterer til enkel bruk. 2.4 Avgrensning GITEK ønsker at programvaren skal kunne implementeres på de mest populære nettbrettene. Dette inkluderer nettbrett som er basert på plattformene ios og Android. Det skal legges til rette for at programvaren skal kunne lastes ned fra AppStore og Android Marked. Applikasjonen i seg selv kan kunne betjenes helt og fullt ut kun ved hjelp av trykkfølsomme skjermer. Det administrative systemet skal fungere på lignende måte som en nettside der arbeidsgivere kan logge inn og administrere oppgaver og ansatte. Nettbrettene skal til en hver tid være koblet opp mot trådløst nett, slik at kommunikasjon mellom nettbrettet og serveren kan foregå når nødvendig. Om nettet faller ut skal nettbrettet lagre data lokalt og sende disse til serveren når nettet kommer tilbake. Applikasjonen og det administrative nettstedet skal utvikles ved hjelp av XHTML, HTML5, CSS2, CSS3, PHP og JavaScript. Selve applikasjonen programmeres i HTML og CSS og settes opp på lignende måte som en nettside. Ved hjelp av PhoneGap skal dette implementeres på både ios og Android. Det skal ikke programmeres med språk som X-Code, C++ eller Java. 3 Prosjektorganisering 3.1 Ansvarsforhold og roller Oppdragsgiver Gitek Veileder: Steinar Dalby Monica Strand 8

9 Gruppemedlemmer: Atle Orm Daniel Gausetvik Therese Thorkildsen Rollen som prosjektleder rullerer mellom gruppemedlemmene, vi ønsker å dele slik at hvert medlem har rollen en sprint av gangen. Om det skulle være nødvendig har prosjektlederen ansvar for å delegere oppgaver til de andre medlemmene fra dag til dag. 3.2 Rutiner og regler i gruppa Arbeidsrutiner Arbeidsgruppen består av tre studenter fra samme klasse, arbeidstidene vil derfor i utgangstpunktet være like. Det avtales ny møtetid etter hver arbeidsøkt. Arbeidet skal være av slik mengde at kravet om 30 arbeidstimer per uke per person overholdes. Det skal være jevnlige møter med arbeidsgiver (GiTek) Det skal føres møtereferat ved samtidlige av møtene med GiTek Det skal avholdes møter annen hver uke med veileder. Dersom gruppen skulle føle behov for mer, kan veilder kontaktes. Dersom gruppen av en eller annen grunn ikke føler behov for veiledningsmøte, må dette avlyses i god tid (minst 24 t.) i forveien, dette anbefales ikke. Ideelt sett deles det inn i oppgaver for hvert gruppemedlem for hver uke, skulle et medlem ikke klare å bli ferdig med sin oppgave innen fristen skal dette meldes i fra om til de andre medlemmene. 3.3 Gruppedeltakere Gruppen består av tre deltakere: Daniel Gausetvik Kontaktinformasjon: daniel.gausetvik@hig.no /tlf: Therese Thorkildsen Kontaktinformasjon: therese.thorkildsen@hig.no /tlf: Atle Orm kontaktinformasjon: atle.orm@hig.no / tlf:

10 3.4 Kompetanse og bakgrunn Alle gruppedeltakerne er tredjeårsstudenter på Bachelor i Medieteknologi ved Høgskolen i Gjøvik, og har god kjennskap til mobilteknologi da det inngår mye i studiene. Fra tidligere har Daniel Gausetvik allmennfaglig utdanning med fordypning i økonomi og administrerende fag ved Romsdal vidregående skole, han har også tatt årsstudium i idrett ved Høgskolen i Molde. Therese Thorkildsen har fra tidligere studiespesialisering med realfag ved Kvadraturen skolesenter. Atle Orm har fra tidligere allmennfaglig utdanning med fordypning i økonomi og språk ved Kirkeparken videregående skole. Senere har han gått multimedia ved Rønningen folkehøgskole og utført førstegangstjenesten ved HMKG. Før han startet med høyere utdanning, jobbet han som assistent i hjemmesykepleien ved Moss kommune i 4 år. 3.5 Grupperegler 1. Hvis det oppstår uenighet, styrer flertallet, skulle det være helt uenighet, og ingen flertall, er det prosjektleder som har det siste ordet. 2. Dersom det påløper kostnader, skal disse deles likt mellom gruppemedlemmene. 3. Alle gruppemedlemmene står selv ansvarlig for å føre logg etter endt arbeidsøkt. 4. Ved behov må gruppemedlemmene være villige til å stille opp med ekstra arbeidstimer. 5. Hvis et gruppemedlem ikke har utført sin oppgave/noe arbeid i løpet av en uke, uten grunn, vil dette være grunnlag for avskjedigelse. For at dette skal skje må veileder kontaktes. 6. Nettsiden skal oppdateres minst 1 gang i uken. 7. Om man ikke rekker å møte på skolen til avtalt tid (ink. pluss minus 5-10min), skal man melde i fra til resten av gruppen. 4 Planlegging, oppfølging og rapportering 4.1 Hovedinndeling av prosjektet Når vi skulle ta stilling til hvilken systemutviklingsmodell vi skulle utvikle etter, følte vi det var viktig å finne en modell som tilbyr fleksibilitet i forhold til utviklingsprosessen. Vi ønsker å jobbe tett på oppdragsgiver, og det kan dermed være viktig for oss å ha en modell som tar høyde for endringer og innspill underveis. 10

11 Vi har tittet litt på modellene nedenfor før vi bestemte oss for hvilken vi ville bruke. Evolusjonær utvikling Inkrementell utvikling Fossefallsmodellen Spiralmodellen SCRUM XP Fossefallsmodellen er en av de klassiske utviklingsmodellene som vi valgte å se på. Den har en detaljert kravspesifikasjon, og en fastlagt kjøreplan som står i sentrum. Integrasjon og testing opp mot andre systemer gjøres ofte mot slutten av prosjektet. Og fossefallsmetoden består av 5 faser, her er det slik at hver fase må avsluttes og dokumenteres før man kan bevege seg videre til neste fase. Men sett at vi ønsker å bruke en modell som tar høyde for endringer, vil fossefallsmodellen falle bort. Valget vårt falt til slutt på en blanding av den inkrementelle utviklingsmodellen og Scrum. Scrum tilbyr mye kontakt med oppdragsgiver, tidsbaserte sprinter og muligheter til underveis øke antall gjennomganger og forbedringer av prosjektet. Som du ser på figuren nedenfor tilbyr Scrum noe som kalles for en sprit-kø, altså en liste over arbeidsmål. Vi føler at for å kunne jobbe bra og strukturert er dette en fordel for oss å bruke i prosjektet. Det vi derimot velger å ta litt avstand fra innenfor Scrum er rollefordelingen, her er det produkteier, scrum-master og et eller flere scrum-team. Grunnen til at vi også vil ta i bruk den inkrementelle utviklingsmodellens hovedmetodikk er fordi den gir oss en strukturert og forholdsvis fleksibel arbeidsform, som vi mener passer bra for vårt prosjekt. Det er ønskelig at vi, som nevnt ovenfor, drar inn prinsipper fra Scrum, slik som sprint-køer/, slik at alle gruppemedlemmene til en hver tid har en oppgave - på den måten er det lettere for oss, og evt for oppdragsgiver å se fremdriften i prosjektet. Ved endt sprint vil vi holde et statusmøte, for å se hva vi har prestert så langt, hvorfor vi har tatt de valgene vi har gjort, og om det er noen ting som bør forandres. Ved disse møtene skal det skrives statusrapporter som vil brukes som dokumentasjon til hovedrapporten. 4.2 Plan for statusmøter og beslutningspunkter Statusmøter Gruppen avholder statusmøter ved oppstart av hver nye uke, for å få en pekepinne på hvor man ligger an i forhold til Gantt-planen og fasene. 11

12 Veiledninger Som nevnt i arbeidsrutinene skal det holdes veiledningsmøter hver andre uke. Skulle det være behov, og veileder har tid og mulighet kan man ta kontakt om det skulle være behov for mer, evt melde i fra i god tid om det skulle være unødvendig med et møte. Møte med oppdragsgiver For å holde en god dialog med oppdragsgiver er det viktig å avholde regelmessige møter. I oppstartsfasen vil vi avholde møter hver uke. Når prosjektet er i gang og rutiner etablert vil det være tilstrekkelig med møte hver andre uke. Oppdragsgiver er åpen for å avholde ekstra møter om dette er nødvendig.skulle det også være at møtet ikke skulle være nødvendig en uke, må dette meldes i fra om, senest 24 timer før. 4.3 Research Det vil være aktuelt å drive en del research før vi begynner med programmering og utvikling. Det finnes allerede løsning som opererer på lignende måte til touchskjerm. Det finnes også uttallige oppgaveplanleggere til smarttelefoner o.l. Det vi må er å tilegne oss den kunnskapen som trengs rundt disse løsningene, for å kunne gjennomføre oppgaven. Det vil også være aktuelt for oss å sette oss inn Sencha, Jquery, LaTex o. For å tilegne oss kunnskap om hvordan slike løsninger fungerer i praksis vil vi teste andre produkter som har løst lignende oppgaver på samme måte. Dette kan for eksempel være NSB sine billettmaskiner, skjermer for kjøp av snus, tobakk, kondomer o.l. i butikker, eller skjermer på selvbetjente bensinpumper. Ved å sjekke allerede eksisterende oppgaveplanleggere tilegner vi oss nødvendig kunnskap om hva disse bør inneholde. Her må det sjekkes hvilke elementer som skal være med, både de kunden har ønsket og de vi mener bør være med i tillegg. For å være godt forberedt til selve utviklingsprosessen må vi tilegne oss kunnskap om teknologiene vi skal benytte oss av. Vi er godt kvalifiserte når det gjelder bruk av HTML, CSS, PHP. JavaScript er et mye større programmeringsspråk hvor det finnes mange forskjellige biblioteker og hjelpemidler. Eksempel på aktuelle JavaScript-biblioteker er JQuery og Sencha. Disse er forhåndsskrevne script som forenkler kodeprosessen, slik at en utvikler bedre kan fokusere på målet med oppgaven. 4.4 Sprinter og aktiviteter 12

13 Sprinter og aktiviteter Tidsrom Sprint 0: Forprosjekt Første utkast av forprosjektrapport Få tilbakemelding fra veider Endelig innlevering Prosjektavtalen Lage veiledningsplan Etablere nettsted Finne kritiske faktorer Sprint 1: Informasjon Kartelle for hvilke type kunnskaper vi trenger før vi begynner prosjektet Innhente informasjon om tidligere prosjekter som ligner vårt Innhente informasjon om applikasjoner som benyttes på trykkfølsomme skjermer Anskaffe nødvendig utstyr Sprint 2: Teknisk Sette opp en server vi kan jobbe mot Sette opp wireframes til layout Implamentere løsning på server Sprint 3: Påske Skrive om resultater til hovedrapporten Sprint 4: Testing Test prototyp opp mot server og korrigere feil Teste kommunikasjonsytelse over WIFI Teste lokallagring om nettet skulle fallet ut Utvidet testing og forbedring av programvare og administrasjonssystem Sprint 5: Drøfte Drøfte resultater Sprint 6: Avsluttende arbeid Oppsummering og siste diskusjoner Ferdigstille figurer for presentasjon av resultater Første utkast av hovedrapporten Ferdigskrive rapporten Sprint 7: Presentasjonsforberedelser Forberede til muntlig presentasjon Lage A3 plakater Sprint 8: Presentasjon Siste forberedelser til presentasjon Holde muntlig presentasjon 13

14 5 Organisering av kvalitetssikring 5.1 Dokumentasjon, standardbruk og kildekode For å sikre god kvalitet i prosjektet opprettholder gruppemedlemmene en god kommunikasjon både seg i mellom, med oppdragsgiver og med veileder. Det føres logg slik at oppdragsgiver og veileder kan vurdere om det jobbes på fornuftig måte og komme med innspill om dette er nødvendig. Gruppens nettside fungerer som publiseringskanal for prosjektets dokumentasjon og gjør dette lettere tilgjengelig. Både oppgavebeskrivelsen og forprosjektrapporten må godkjennes av veilederen før prosjektet kan starte formelt. 5.2 Konfigurasjonsstyring Konfigurasjonsstyring omhandler styring av innhold, endringer og statuser på delt informasjon i et prosjekt. Vi setter fokus på å versjonskontroll, og er oppmerksomme på at det hele tiden er riktige, og oppdaterte filer i de forskjellige versjonene og subversjonene. 5.3 Teknologi Oppdragsgiver ønsker en løsning som skal fungerer på en berøringsskjerm - uansett hva slags plattform som ligger bak. Vi har derfor valgt å utvikle applikasjonen ved bruk av HTML5, CSS3, JavaScript og PHP. Det vil også bli tatt i bruk en SQL database til lagring av data. Vi vil bruke PhoneGap som er rammeverk, og på denne måten kan vi programmere til flere plattformer samtidig, og slipper dobbeltarbeid. Det som også er med PhoneGap, er at vi kan bruke kjente teknologier som HTML5, CSS3, JavaScript og PHP - noe som igjen er plattformuavhengig. For oss i prosjektgruppen er dette en fordel da vi ser flere mulige løsninger ved bruk av disse kjente teknologiene, samtidig som vi må lære oss å bruke dem på nye måter, samt tilpasse dem til applikasjonen. Forretningsmessig vil det også være en fordel å bruke PhoneGap, å ta i bruk for eksempel Java for Android, vil være ekstremt tungvindt i forhold, med tanke på at man låser seg så veldig til plattform, og teknologi. 5.4 Risikoanalyse (identifisere, analysere, tiltak, oppfølging) 14

15 Beskrivelse av risiko Arbeidsmengden blir for stor i forhold til antall gruppemedlem Vi mister data fordi vi er dårlige på å ta backup Sannsynlighet Konsekvens Om dette skulle skje vil det helt klart gå ut over det endelige resultatet, og vi vil i verste fall ikke rekke å bli ferdig. 2 Mister vi data må vi begynne på nytt. Gruppemedlemmer blir uvenner/uenige Feil disponering av tid, og vi rekker ikke bli ferdig Det oppstår problemer med oppdragsgiver Vi greier ikke tilegne oss nok kunnskap til å utføre oppgaven godt 2 Om dette skulle skje må man møte med veileder, evt. kan man jobbe hver for seg. 3-4 Om dette skulle skje må man kutte ned omfanget av oppgaven 1 Om dette skulle skje kan det få fatale følger for prosjektet. Vi må jobbe videre med oppgaven uten oppdragsgiver. 2 Dette går utover kvaliteten til prosjektet og resulterer i at kunden ikke blir fornøyd. Større kostnader kan beløpe seg på oppdragsgiver. Strategi Jobbe etter Gantt-planen og skulle det bli behov for å ty til mer arbeidstimer har gruppemedlemmene avklart på forhånd at de må kunne ofre det. Begge gruppemedlemmene har gått teknologi i snart 3 år, og kjenner godt til det å miste data. Vi har derfor valgt å bruke eksterne lagringsplasser - i tillegg til lokal. Gruppereglene er satt, og vi tror det skal mye til for at vi blir uvenner utover det. Vi jobber hardt, sammenhengende og i forhold til Ganttplanen for å unngå dette. Vi sørger for god kommunikasjon med oppdragsgiver slik at vi oppdager tildlig om det skulle bli problemer. Vi begynner tidlig med å kartlegge hvilke kunnskaper vi må tilegne oss og går tidlig i gang med research. 15

16 6 Plan for gjennomføring Se vedlegg. 6.1 Milepæler Hva? Første utkast av forprosjektrapport Ha nettsted som er oppe og går Endelig innlevering av forprosjektrappor Prosjektavtale Første utkast kravsspesifikasjon Ferdigstille kravspesifikasjon Fungerende prototype av systemet Statusrapport 1 Gjennomført testing og feilretting Systemet fungerer som planlagt Statusrapport 2 Første utkast av endelig rapport Levering av bacheloroppgaven Levering av plakat Fremføring av bacheloroppgaven Når? 15. februar 15. februar 20. februar 20.februar 9. mars 16. mars 30.mars 6. april 13.april 20. april 27. april 5. mai 23. mai 30. mai juni 16