Forprosjektrapport. Capcount Gruppe BO19-G07. Mats Løvstrand Berntsen, Herman Johan Dragland, Jim-Alexander Berger Gundersen og Marius Moe Olsen

Transkript

1 Forprosjektrapport Capcount Gruppe BO19-G07 Mats Løvstrand Berntsen, Herman Johan Dragland, Jim-Alexander Berger Gundersen og Marius Moe Olsen 18. januar 2019

2 Prosjektgruppen Gruppen besta r av tre informatikkstudenter og en dataingeniørstudent. Alle i gruppen har kjennskap til de ulike omra dene som berøres i oppgaven, men alle har minst ett felt hvor de har bredere kompetanse. Pa grunn av va re ulike interesser og kunnskaper innen IT fa r gruppen i sin helhet dekt flere kompetansefelt. Gruppen har jobbet sammen i andre prosjekter tidligere. Det har medført at gruppen har godt samhold, god kommunikasjon og vet hvordan eventuelle konflikter skal ha ndteres pa en god ma te Mats Løvstrand Berntsen Mats er informatikkstudent ved Høgskolen i Østfold. Han er en kompetent webutvikler innen Wordpress, PHP, Javascript og jquery. Han har erfaring innen androidprogrammering, Java og.net. Ved siden av studiene har han laget og er deleier av nettbutikken erjinterior.no. Det siste a ret har han jobbet deltid som utvikler i Miles To Go AS Herman Johan Dragland Herman er en informatikkstudent med dybde innen design og utvikling av webapplikasjoner. Han jobber na deltid som Designer og Front-end utvikler hos Miles To Go AS, og som studentassistent i Grafisk design kurset pa høgskolen. Før studiet har han bakgrunn fra Medier og Kommunikasjon hvor han tilegnet seg erfaring innen design og brukerkommunikasjon. Han er kjent med webteknologier slik som Javascript, Node.js, Sass, PHP, Wordpress, jquery og SQL. 1

3 0.0.3 Jim-Alexander Berger Gundersen Dataingeniørstudent ved Høgsklen i Østfold. Han har jobbet en del med mikrokontrollere som arduino og ESP32 pa fritiden og i fagene industriell IT og datateknikk. Han jobber ogsa mye med algoritmer og datastrukturer, og har vært med pa flere internasjonale programmeringskonkurranser. Det siste a ret har han jobbet som studentassistent pa skolens makerspace, et arbeidsrom hvor studenter kan jobbe med hardwarerelaterte prosjekter Marius Moe Olsen Informatikkstudent med hovedfokus pa frontend-utvikling. Gjennom fag han har tatt og prosjekter han har gjort pa fritiden har jeg tilegnet meg erfaring innen webutvikling, Javacript, PHP, Vue.js, C# og Java. Han har jobbet som studentassistent ved Høgskolen i Østfolds MakerSpace. Oppdragsgiver Capgemini er ett internasjonalt konsulent-konsern med i overkant av ansatte fordelt pa over 40 land. De omsetter for 12,8 milliarder euro pa verdens basis. Capgeminis forretningsmodell er at de skal bista bedrifter med utvikling i forretning og teknologi. De har Capgemini Consulting som hjelper bedrifter med management consulting, utformer og integrerer teknologiløsninger og outsourcer kunders IT-ressurser til en tredjepart. Capgemini driver ogsa med programvaretesting via Sogeti, og design via Idean, begge selskapene er en del av Capgemini-konsernet. 2

4 Vårt prosjekt vil være i samarbeid med Fredrikstad-kontoret til capgemini hvor det jobber omkring 70 ansatte. Berzi Wasfy er gruppens kontaktperson gjennom prosjektperioden. Oppdraget Capgemini avd Fredrikstad ønsker et system som skaper en tydelig oversikt over antall personer i lokalet på et gitt tidspunkt. Dette er for å ha kontroll på hvor mange som er i lokalitetene, så bedriften kan føre statistikk over innhentet data. Denne oversikten skal være grafisk framstilt, og tilgjengelig for ansatte i bedriften. Dataene som registreres av systemet skal ligge til grunn for predikering av antall personer i lokalet. Persongjenkjenningen må bli lagt opp på en måte som tar hensyn til personvern. Det er ønske om å kartlegge de ansattes tilfredshet gjennom arbeidsdagen. Capgemini avd Fredrikstad per januar 2019 har kun en etasje, men er i en utvidelsesprosess til enda en etasje. Til hovedetasjen benyttes kun en inngang, men det finnes også en uteplass med tilgang til lokalitetene. De benytter en ID-kortløsning for adgangskontroll, som ikke anvendes til persontelling. Derfor er det utfordrende å vite hvor mange som befant, befinner, og kommer til å befinne seg i lokalet Forslag til løsning Det skal leveres et system som kan telle antall personer som går inn og ut av kontoret og lagre statistikk på dette. Systemet skal benytte en sensor som automatisk følger med om en person går inn eller ut av kontoret uten at personen skal måtte interagere med systemet. Det er også viktig at sensoren ikke kan gjenkjenne personer som går inn eller ut av kontoret, dette kan lede til komplikasjoner med henhold til personvern. Når sensoren registrer at en person har gått inn eller ut av lokalet, vil den sende en oppdatering til serveren som vil registrere dette. For at sensoren skal kunne sende informasjon til serveren vil det bli laget et API som den, og fremtidige sensorer kan interagere med. Serveren har ansvar for å ta imot informasjon, lagring av statistikk og gjøre statistikk tilgjengelig ved hjelp av ett API. Serveren vil også tilby en webapplikasjon for å grafisk fremstille statistikk, og fungere som en portal hvor brukeren kan interagere med dataene (se Figur 1). Ved lokalitetenes utganger skal det plasseres et fysisk grensesnitt som rangerer ansattes tilfredshet. Løsningen er skalerbar, og kan implementeres i et hvert kontorlandskap. Mål Et system som registrerer tilstedeværelse i lokalet. Delmål Predikere antall ansatte i lokalene og effektivisere bruk av utstyr. Delmål Kartlegge tilfredshet hos de ansatte. 3

5 Figur 1: Rikt bilde. Figuren viser kommunikasjonen mellom systemets komponenter. Leveranser Forprosjektsrapport En rapport som gir et helhetlig bilde av hvordan prosjektet er tenkt til å bli gjennomført. Fullstendig system Planlagt dato på når utviklingsperioden avsluttes og gruppen har et ferdig produkt. Hoveddokument Førsteversjon Andreversjon Fullstendig rapport :00 Refleksonsnotater Individuelle refleksjonsnotater som skal leveres som vedlegg til hoveddokumentet. Prosjektplakat Plakat som inneholder hva gruppen har fått til og funnet ut iløpet av prosjektet Metode For utviklingsdelen av dette prosjektet skal gruppen benytte elementer hentet fra smidige arbeidsverktøy - i hovedsak Scrum [Sommerville et al., 2016, p ]. Det skal benyttes et Gantt-diagram for overordnet prosjektstyring. Alle frister gjennom prosjektperioden samt større milepæler er listet opp med tilhørende planlagt start- og sluttdato. 4

6 Utforsking og forberedelse I første prosjektfase skal intervjuer med oppdragsgiver skal gi gruppen en forståelse av hvordan oppgaven kan løses og hvilke teknologier som kan oppfylle oppdragsgivers ønsker. Ved å sammenligne programmeringsspråk og utviklingsverktøy skal gruppen finne og presentere de mest aktuelle for oppdragsgiver. I andre fase skal de konkrete kravene til produktet defineres i samarbeid med oppdragsgiver. Det skal lages en kravspesifikasjon inndelt i funksjonelle, ikke-funksjonelle og eksterne krav. Av disse kravene skal det utarbeides en backlog som skal danne grunnlaget for prosjektets sprints. Digitale verktøy som Microsoft Azure, Microsoft Teams og Trello skal settes opp og klargjøres. Gruppen skal også bestemme seg for hvilke programmeringsspråk, hvilken sensor og hvilken database-løsning som skal benyttes under utviklingen av prosjektet. Utvikling Utviklingen av produktet begynner i fase tre. Dette er den desidert lengste fasen i prosjektet. Hver uke vil gruppen møtes for å utarbeide neste sprint. En sprint skal fylles med oppgaver hentet fra prosjektets backlog. Når en sprint er over skal den evalueres av gruppa, og deretter presenteres for oppdragsgiver. Dersom en oppgave ikke er løst på en tilfredstillende måte vil den enten måtte endres i samarbeid med oppdragsgiver, eller tas med i neste sprint. Slik fortsetter prosessen til samtlige krav i backloggen er oppfylt (se figur 2). Figur 2: The Scrum sprint cycle [Sommerville et al., 2016, p. 86] I tillegg den smidige arbeidsmetoden har gruppen satt konkrete datoer for når de forskjellige iterasjonene av produktet (Alpha, Beta, og Release) skal være ferdige. Dette er for å hindre at prosjektet stopper opp eller blir 5

7 hengende for langt etter planlagt tid. Gruppen skal benytte Git for versjonskontroll av kildekode under hele prosjektperioden. Testing og justeringer I fase fire, som omhandler testing, er hensikten å finne eventuelle feil i systemet. Testingen deles inn i 2 deler, lukket og åpen testing. Den lukkede testingen gjøres ved at systemet settes opp i et begrenset lokale. Da kan gruppen kontrollere hvor mange som går inn og ut, og verifisere om dataene blir lagret på riktig måte i systemet. Etter den begrensede testingen er ferdig, settes systemet opp et sted med mer fottrafikk. Da får vi testet hvordan systemet fungerer i et reelt miljø, og får avslørt eventuelle feil. Dokumentering Gruppen vil arbeide med hovedrapporten gjennom alle fasene av prosjektet. Alle erfaringer, beslutinger, kildekode og uforutsette hendelser skal dokumenteres. I prosjektets avsluttende del skal dette struktureres og hovedrapporten skal ferdigstilles. Prosjektplakaten og presentasjonen skal baseres på den ferdige hovedrapporten. Prosjektplan Prosjektet vil som nevnt bestå av seks faser, utforsking av teknologier, forberedelser, utvikling, testing, justeringer og dokumentering. Som en kan se fra figur: 3 vil vår lengste fase være utvikling som strekker seg fra februar helt til starten av april. Gruppen er klar over at denne planen vil kunne endres underveis i prosjektet, og at planen som den står er hovedsaklig veiledende. Det er også viktig å påpeke at selvom det er satt av en egen fase til dokumentering, vil rapportskriving bli gjort gjennom hele prosjektiden. Det er avsatt tid mot slutten til mer fokusert rapportskriving. Figur 3: Gantt diagram over de ulike fasene i prosjektet. 6

8 Gjennomføring Som tidligere nevnt skal gruppen benytte elementer hentet fra smidige arbeidsteknikker. Disse skal utføres i form av ukentlige strategimøter, kortere statusmøter og utforming av relevante brukerhistorier (user stories). Disse scenarioene skal presenteres for oppdragsgiver underveis i prosessen. Dette for å sikre at produktets ønskede funksjonalitet og kvalitet innfris, og skal være grunnlaget for produktets funksjonelle krav i kravspesifikasjonen. Det skal opprettes en backlog hvor alle nødvendige oppgaver listes opp. Disse oppgavene skal fordeles i ukentlige sprints, hvor den neste bygger på den foregående. Oppgavene som settes i hver sprint avhenger av hvor vellykket de tidligere sprintene har vært og tilbakemeldinger fra oppdragsgiver. På denne måten ønsker gruppen å kunne imøtekomme og tilpasse seg eventuelle endringer eller uforutsette problemer gjennom prosjektperioden. Alle møter dokumenteres med referat som beskriver hva som ble diskutert, beslutninger som ble tatt og hvem som var til stede. Gruppen møtes ukentlig med veileder for tilbakemeldinger på arbeid og råd til prosessen videre. Strategimøter med veileder og oppdragsgiver skal meldes på forhånd i form av en møteinnkalling med oversikt over planlagte tema og problemstillinger som skal diskuteres. Istedenfor å velge én prosjektleder for hele perioden har gruppen valgt å rullére på lederrollen under tittelen Møteleder. Denne rollen endres hver andre uke slik at alle i gruppen får erfaringen. Møteleder har ansvaret for å utarbeide og sende ut møteinnkalling, samt kontrollere at alle avtalte punkter er blitt tatt opp. Under hvert møte skal det være én sekretær. Rollen som sekretær rulléres ukentlig. Noen roller er det imidlertid hensiktsmessig å holde statiske, derfor er Jim-Alexander gruppens kontaktperson for veileder og oppdragsgiver. Mats har hovedansvaret for Backloggen og Scrum og er gruppens Scrum-master. Hvert medlem i gruppen skal også føre timelister. Alle arbeidsøkter skal dokumenteres med hva som ble gjort, når og hvor lenge økten varte - her inngår også gruppemøter. Gruppen har inndelt utviklingen av produktet i fire ansvarsområder, og hver av medlemmene har ett slikt område som hovedansvar: 1. Sensor - Jim-Alexander Berger Gundersen 2. Database - Mats Løvstrand Berntsen 3. API og server- Herman Johan Dragland 4. Nettside - Marius Moe Olsen Uenigheter og problemer skal i første rekke behandles innad i gruppa. Ved gjentatte avvik eller brudd på gruppekontrakten skal veileder kontaktes. 7

9 Eventuell sykdom eller andre årsaker som hindrer et gruppemedlem i å utføre avtalte oppgaver skal løses i samarbeid med oppdragsgiver og veileder. 8

10 Bibliografi [Sommerville et al., 2016] Sommerville, I. et al. (2016). Software engineering. Harlow: Pearson. 9

11 .0.7 Utforsking av teknologier I utforskningsfasen er hovedformålet til gruppen å få ett overblikk over hvilke teknologier som allerede finnes på markedet som kunne være relevante for prosjektet. Figur 4: Gantt diagram over utforskingfasen. Aktivitet 1: Utforske lignende løsninger Beskrivelse: Finne og dokumentere de forskjellige systemene som allerede finnes på markedet. Varighet: 3 Uker Bemanning: Marius Leveranse: Kortfattet dokument Aktivitet 2: Utforske sensorer Beskrivelse: Finne og dokumentere de forskjellige sensorene som finnes på markedet som kan brukes til vårt formål. Varighet: 3 Uker Bemanning: Jim-Alexander Leveranse: Kortfattet dokument Aktivitet 3: Utforske backendløsninger Beskrivelse: Finne og dokumentere de forskjellige backend programmeringspråkene som kan være aktuelle for vårt prosjekt Varighet: 3 Uker Bemanning: Herman Leveranse: Kortfattet dokument Aktivitet 4: Utforske databaseløsninger Beskrivelse: Finne og dokumentere forskjellige databaseløsninger som kan være aktuelle for vårt prosjekt Varighet: 3 Uker Bemanning: Mats Leveranse: Kortfattet dokument Aktivitet 5: Utforske frontendløsninger Beskrivelse: Se på forskjellige rammerværk som kan brukes til å utvikle en grafisk fremstilling av tellerdataene Varighet: 3 Uker Bemanning: Herman Leveranse: Muntlig rapport 10

12 .0.8 Forberedelser I forberedelsesfasen vil hovedformålet være å få alt klart til å kunne begynne med prosjektet. Kommunikasjons-platformer og utviklings-platformer skal være oppe og kjøre. Det skal også være klart formålet og kravene til oppgaven. Figur 5: Gantt diagram over forberedelsesfasen. Aktivitet 6: Sette opp utviklingsmiljø Beskrivelse: Sette opp værktøyene vi skal bruke underveis i prosjektet. Azure, Azure devops, Microsoft teams og Trello Varighet: 5 dager Bemanning: Herman, Mats Leveranse: utviklingsmiljø for alle gruppemedlemmene Aktivitet 7: User stories Beskrivelse: Skrive user stories for prosjektet Varighet: 1 dag Leveranse: Dokument med user stories Aktivitet 8: Kravspesifikasjon Beskrivelse: Utifra user stories skal det skrives en kravspesifikasjon som inneholder krav til hva prosjektet skal inneholde Varighet: 1 dag Leveranse: Kravspesifikasjon som dokument Aktivitet 9: Lage backlog Beskrivelse: Utifra kravspesifikasjonen kan vi begynne å lage en backlog med oppgaver som skal utføres Varighet: 3 dager Leveranse: Backlog i Trello Aktivitet 10: Lande på løsning av teknologier Beskrivelse: Sammen med oppdragsgiver skal vi bli enige om hvilke teknologier som vi skal jobbe på i løpet av prosjektet Varighet: 1 dag Leveranse: Felles enighet om hvilke teknologier vi skal bruke Aktivitet 11: Handleliste 11

13 Beskrivelse: En handleliste over hva vi trenger til prosjektet som sendes til oppdragsgiver Varighet: 1 dag Leveranse: Handleliste som sendes til oppdragsgiver.0.9 Utvikling Under utviklingsfasen vil formålet være å få selve prosjektet ferdig. Utviklingen er delt inn i tre deler, alpha, beta og release. Alpha skal være en minimumsløsning til oppgaven. Systemet skal grovt være oppe og gå, men med mye av funksjonaliteten mangelende. Beta fasen skal fokuset være på å fylle ut der prosjektet er manglende, og systemet skal nå være brukelig for oppdragsgiver. Systemet har muligens noen mangler, men oppgavebeskrivelsen er besvart. I release uka vil resterende oppgaver fra backlog settes opp i en prioritert liste og implementeres siste rest. Figur 6: Gantt diagram over utviklingsfasen. Aktivitet 12: Enkelt API koblet til database Beskrivelse: Database med mulighet for uthenting av data til ett basic API Varighet: 6 Uker Bemanning: Herman, Mats Aktivitet 13: Enkel nettside med data fra API Beskrivelse: Nettside som viser basic informasjon med basic layout Varighet: 6 Uker Bemanning: Marius Aktivitet 14: Mikrokontroller kommunikasjon med API Beskrivelse: mikrokontroller skal kunne kommunisere med API Varighet: 6 Uker Bemanning: Jim-Alexander Aktivitet 15: Sensor kommunikasjon med mikrokontroller Beskrivelse: mikrokontroller skal kunne kommunisere med sensor, men enda ikke fullt detektere menneskers bevegelser Varighet: 7 Uker Bemanning: Jim-Alexander 12

14 Aktivitet 16: Mer utfyllende API endepunkter Beskrivelse: Database skal ha mulighet til å hente ut tidsbegrenset data Varighet: 4 Uker Bemanning: Herman, Mats Aktivitet 17: Nettside med grafer og design Beskrivelse: Nettsiden skal være ha friskt design, og vise grafer over spesifikketidsrom (siste uke, måned eller år) Varighet: 4 Uker Bemanning: Herman, Marius Aktivitet 18: Sensor skal nå kunne beregne mennesker posisjon Beskrivelse: Sensor skal kunne spore mennesker og oppdatere databasen utifra bevegelse Varighet: 4 Uker Bemanning: Jim-Alexander Aktivitet 19: Implementere siste rest av backlog Beskrivelse: Backlog som blir skrevet underveis, skal denne uken implementeres det viktigste som vi rekker. Varighet: 1 Uke.0.10 Testing Under testing vil hovedformålet være å sette opp systemet i ett reelt scenario, her vil vi da kunne finne eventuelle svakheter i systemet som en helhet. Figur 7: Gantt diagram over testingfasen. Aktivitet 20: Sette opp systemet Beskrivelse: I to uker vil vi sette opp systemet fullt, for å finne eventuelle feil med systemet som en helthet Varighet: 2 Uker.0.11 Justeringer Under justeringsfasen vil hovedformålet være å fjerne alle potensielle feil som dukket opp under testingfasen. Aktivitet 21: Rette opp eventuelle systemfeil Beskrivelse: Alle feil vi finner underveis i testingen vil nå settes opp i en prioritert liste og rettes opp i. 13

15 Figur 8: Gantt diagram over justeringfasen. Varighet: 2 Uker Aktivitet 22: Tester skrevet underveis må nå være i orden Beskrivelse: Underveis i prosjektet skal det også skrives tester, disse må nå være i orden Varighet: 2 Uker.0.12 Dokumentering I dokumenteringfasen vil hovedmålet være den første uken å fulføre hovedrapporten. Hovedrapporten vil bli skrevet underveis, men her vil sistefinpuss bli gjort. Etter dette faller fokuset over på prosjektplakat og presentasjonen av prosjektet. Figur 9: Gantt diagram over dokumenteringsfasen. Aktivitet 23: Prosjektplakat Beskrivelse: Utarbeide en prosjektplakat Varighet: 2 Uker Leveranse: Prosjektplakat Aktivitet 24: Presentasjon Beskrivelse: Utarbeide en Powerpoint presentasjon og en demonstrasjon av systemet til presentasjon av prosjektet Varighet: 3 uker Leveranse: Demonstrasjon og Powerpoint Presentasjon Aktivitet 25: Avslutning av Hovedrapport Beskrivelse: Fullføring av hovedrapport Varighet: 1 uke Leveranse: Hovedrapport 14

16 15