Gruppe 18. Forprosjektrapport. Hovedprosjekt 2014 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus

Transkript

1 Forprosjektrapport Hovedprosjekt 2014 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus 1

2 Innholdsfortegnelse 1. Presentasjon Sammendrag Dagens situasjon Mål og rammebetingelser Prosjektmål: Rammebetingelser: Funksjonalitet: Løsninger og alternativer Fordeler og ulemper Analyse av virkninger Rollefordeling Risikoplan Risikoanalyse Risikostyring

3 1. Presentasjon Vår gruppe består av de fem medlemmene Jardar Høyland, Bilal Ahmad, Tamas Czipri, Benedicte Paulsen og Marit Berntsen, som alle studerer Anvendt datateknologi ved Høyskolen i Oslo og Akershus. Vi har påtatt oss et oppdrag fra Norges idrettshøyskole, NIH, der IKT-avdelingen i samråd med driftsansvarlig for svømmehallen ønsker en ny IT-plattform for loggføring av måledata som utføres flere ganger daglig. I dag føres måledataene, som består av blant annet temperatur, PH og klorverdier, inn i et manuelt papirbasert system, som av brukerne blir sett på som en tungvendt løsning, særlig med tanke på å hente ut eldre data, eller å sammenstille data når det er nødvendig. Ved en ny løsning ønskes det at data lagres i en database basert på MS SQL Server og med et WEB-basert brukergrensesnitt, men dette kan diskuteres. Det skal være enkelt å skrive ut rapporter, systemet skal være brukervennlig og universelt utformet, og det må være solid og lett vedlikeholde, samt drifte. Våre kontaktpersoner ved NIH er; - Hans Olav Krogsæter, IKT-sjef, h.o.krogsater@nih.no, Mob: Tore Sundby, Formann, tore.sundby@nih.no, Mob: Hans Olav Krogsæter er IKT-sjef ved NIH, og hovedansvarlig for prosjektet, og kontaktperson vedrørende det tekniske. Tore Sundby er ansvarlig for driften av svømmehallen, og er kontaktperson vedrørende utformingen og bruken av systemet. Vår interne veileder er Geir Skjevling: Postadresse: Pb 4 St. Olavs plass, 0130 Oslo Besøksadresse: Pilestredet 35 Tlf: / Fax: E-post: Geir.Skjevling@hioa.no 3

4 2. Sammendrag Vi skal på vegne av NIH lage en ny IT-plattform for loggføring av måledata fra høyskolens badebasseng. I første omgang ønskes det en web-applikasjon som man enket kan skrive inn data fra målingene, samt hente dem ut igjen i form av rapporter. Siden disse målingene gjøres av flere brukere, må det også være mulig å logge seg inn med ID og passord, samt sette begrensninger slik at det blant annet kun er en administrator som kan overskrive eksisterende data. Ut over dette har vi også sett på mulighetene for å automatisere systemet. Her har vi funnet et arduino-kretskort av typen YUN. Dette er elektronikk basert på program- og maskinvare, ved åpen kildekode og ulike sensorer, kan vi tilpasse denne løsningen til ønsket bruk; måling av temperatur, PH og klor. En web-applikasjon vil gjøre brukernes oppgaver mye enklere å gjennomføre. Da ikke minst når det kommer til å hente ut eldre data, ettersom dagens løsning er papirbasert og svært tungvint. Ved å automatisere målingene i tillegg blir jobben enda enklere. Det er viktig for både oss og oppdragsgiver at dette blir et system som kan bygges videre på samt tilpasses ved behov etter hvert som tiden går. I dag er et av kravene at målingene skal skje manuelt, dog vil en automatisk måling kunne understreke måleresultatene. Denne lovgivning vil på sikt kunne komme til å endre seg. Slik det er i dag har NIH to bassenger. Men de planlegger å rive hele anlegget å da heller bygge et større basseng. Vi synes det derfor er viktig at systemet som lages tar høyde for potensielle endringer. Får vi til dette på best mulig måte vil systemet potensielt også være godt egnet for andre anlegg i fremtiden. 4

5 3. Dagens situasjon Ved NIH har de to bassenger. Antallet utvides i skrivende stund. Det vil si at det er flere bassenger som trenger oppsyn og dagens metode for registrering av bassengverdier er på ingen måte optimal. NIH ønsker seg derfor et bedre system for å føre inn og holde orden på dataene fra alle bassengene. Hovedansvaret for anlegget har Tore Sundby. Han deler arbeidsoppgavene med 3 andre ansatte. De er ansvarlige for blant annet å gjøre målingene av forskjellige verdier i bassengene og videre notere ned disse. Verdiene som i dag måles er: Fritt klor, Bundet klor, Total klor og PH. For å enklere holde orden på dataene, fulgte det med en applikasjon da bassenget først kom. Applikasjonen var veldig enkel, men så klønete å holde styr på at dataene har alltid blitt ført for hånd. Applikasjonen har en viktig funksjon og det er muligheten til å hente automatisk data fra sensorer. Men, lovverket hindrer det å kun bruke disse målingene. Slik det er i dag brukes disse verdiene kun for å være til sammenligning med de manuelt målte verdiene. Ettersom det er lovpålagt med manuelle målinger, blir dagens data skrevet i en tabell på et ark. Innføringen av data er enkel, ettersom alle de ansatte er vant med å skrive for hånd. Det som derimot er tungvint er organiseringen av dataene. Ark tar fysisk plass, og man må legge dem et sted man husker. Hvis man så ønsker å se gjennom dataene må man lete gjennom haugen med ark. Hvis man ikke har sortert arkene effektivt, kan denne prosessen være tidkrevende og frustrerende. I verstefall kan man miste dataene ved denne løsningen. Eksempelvis kan man risikere å miste arkene i bassenget, de vil nødig være leselige lenger da. Dagens løsning fungerer, men den er ineffektiv. Ark krever fysisk sortering og en samlet forståelse for sorteringen hos de ansatte. Til sammenligning er en database logisk sortert, og med en ferdigprogrammert logikk, vil programmet gjøre sorteringen for deg. En database er også mulig å søke igjennom. Istedenfor å lete gjennom 100 ark, kan man finne det man leter etter ved et enkelt søk. Bruker man database vil dataene også være 100% trygge, dette fordi man kan programmere automatisk backup til en ekstern enhet eller server. 5

6 4. Mål og rammebetingelser 4.1 Prosjektmål: Det skal utvikles ett system som holder oversikt over verdier av målinger i henhold til bassenger hos NIH. Systemet skal være enkelt å administrere og mulighet for å videreutvikle i ettertid, det skal lages i henhold til NIH sin plattform, som er Windows 7 64bit. Løsningen skal gjøre det mindre tungvint å sammenstille data i rapporter, som for eksempel pdf, eller på webformat direkte på nettsiden. Det skal også være mulig for brukerne av systemet å få se målingene over en bestemt periode i diagrammer. 4.2 Rammebetingelser: Systemet skal utvikles som en web-applikasjon. Dataene skal lagres i en database som er basert på Microsoft Sql server. Front end: Twitter bootstrap, HTML 5, CSS 3 og javascript. Back end: Php (Rammeverket: Laravel) og Microsoft sql. Utviklingsverktøy: Notepad++. Versjonshåndteringsystem: github Web- applikasjonen skal være universell utformet. Lagring av prosjektstyringsdokumenter: Intern lagring, dropbox og google docs. 4.1 Funksjonalitet: Innloggingsfunksjon basert på Active directory. Legge inn måledata. Mulighet for å redigere og slette måledata. Brukeren kan hente ut data for et tidsperiode og se dataene i tabellform, for deretter å ha mulighet til å lagre disse i excel eller pdf. Brukeren har mulighet til å hente ut data knyttet til spesifikke verdier til de ulike målingene. Brukeren kan sortere målingene basert på måletype, stigende og synkende Det skal være mulig å vite hvem av de ansatte som har lagret en spesifikk måling. 6

7 Det skal være mulig å legge til flere måletyper. Dersom noen har glemt å legge inn de daglige målingene skal det sendes en varsel mail en spesifikk epost-adresse. 5. Løsninger og alternativer Hos oss vil det eksistere flere løsninger på det aktuelle problemet, løsninger som vi har diskutert med oppdragsgiver har som nevnt vært å opprette en web-applikasjon med mulighet for å legge inn og hente ut data. Denne løsningen vil forenkle eksisterende løsninger som er tatt i bruk ved oppdragsgiver per i dag, som da er å gjøre dette for hånd. Løsninger tatt i bruk ved nyere bassenger har mer automatikk når det gjelder denne type målinger, dog disse metode kan være svært kostbare da gode sensorer som krever lite vedlikehold kan koste opp imot 1000 USD eller mer. Ett av våre alternative løsninger er å ta i bruk slik automatikk ved å brukte et arduino kretskort, som er en plattform for prototyping av elektronikk basert på program- og maskinvare med åpen kildekode. Dette gir mulighet for å koble til forskjellige sensorer til arduino'en. Vi har tenkt å ta i bruk en arduino av typen YUN da denne har innebygget trådløst nettverk, og dette vil forenkle lagringen av målingene i en database, og man slipper en ekstra kabel. Bildet under viser dataflyten i systemet: Her kan man også se at vi har tatt med arduino'en selvom det egentlig bare er en ekstraløsning, men selv uten det vil ikke diagrammet være forskjellig utenom at den hadde vært borte. 7

8 5.1 Fordeler og ulemper Fordelene med vår løsning er at det tilbyr en simpel mulighet til å lagre og hente ut data som per dags dato gjøres for hånd. Kontra papirbasert løsning så blir ikke dataene her borte om man mister arket med målingene, brukeren kan enklere sammenstille data, filtrere ut disse dataene basert på spesifikke kriterier og aggregere dem for å se på de hvordan de forandrer seg over tid. Fordelene med arduino er at hele denne prosessen blir automatisert, slik at man ikke behøver personell for å utføre målinger og innlegging av målinger og på den måte fokusere på andre arbeidsoppgaver. Ulemper med vår løsning er at dersom databasen eller intranettet går under en stund så utgjør dette en utfordring om man skal gjøre noe mot de aktuelle dataene. Når det gjelder arduino så er det et par ulemper man bør se på bla. Batteritid: om enheten ikke er koblet til ekstern strøm så vil den før eller senere gå tom for batteri (selv om den er programmert til å kun fungere x antall ganger per dag og sove ellers). Videre det er også mulig at arduino'en returnerer upresise målinger grunnet en bug eller dårlig sensor o.l, dette kan være problematisk da den automatisk legger data inn databasen og det kan gå litt tid før dette er lagt merke til. Det blir å finne løsninger slik at man unngår slike problemer. 6. Analyse av virkninger Systemet skal bidra til å gjøre det enklere for Norges Idrettshøgskole å utføre målinger for å se om verdier samsvarer med loven når det gjelder deres bassenger kontra dagens metodikk som innebærer penn og papir. Dette vil fri opp arbeidskraft og man vil få pålitelige målinger, løsningen vil også bli mulig å distribuere videre til bassenger i Norge der det fortsatt ikke er implementert automatikk. Usikkerheten vil være til stede helt til systemet settes ut i drift, systemet betraktes som ett sluttprodukt, men det skal legges til rette for at løsningen kan videreutvikles. 8

9 7. Rollefordeling Når det gjelder fordeling av roller innad i gruppen så forsøker vi å fokusere på at folk kan ta tak i de (del)oppgaver som de har lyst til selv så vidt det lar seg gjøre. Vi er jo tross alt en gruppe på fem personer, noe som gjør at vi har ett lite mangfold når det gjelder forskjellige roller under utførelsen av prosjekter. Enkelte utfører skriving mye bedre enn andre, mens andre er flinke for eksempel på den tekniske biten. Som man også kan se om man tar en titt på fremdriftsplanen så har vi fordelt rollene på den måte at to fokuserer på design/dokumentajson, to på koding både backend og frontend og siste mann skal se nærmere på en automatisert løsning basert på en mikrokontroller og vårt system i bunn av det. Dette er noe som lar oss yte bedre da flere forskjellige oppgaver blir løst på en gang og vi unngår at for mange personer blir satt på å løse samme oppgave. Det handler i grunn bare om å kunne bruke arbeidskraften mest mulig effektivt, sluttresultatet er også som regel bedre da noen få kan sette seg skikkelig inn i det som må gjøres. Fremfor at hele gruppen raser gjennom en og en ting om gangen. Kort oppsummert får vi det til å fungere med fem personer ved å fordele oppgaver på en måte som gagner alle når det gjelder hva som må gjøres og hvordan utførelsen av hva som må gjøres skal skje (der det er mulig), flere personer tilbyr flere roller og godt fordelt unngår man at gruppen blir for opphengt i en oppgave samt gir oss muligheten til å ta flere i parallell. 8. Risikoplan Ved et prosjekt vil det alltid foreligge potensielle risikoer, det er derfor flere ting man burde ha i bakhodet fra det sekundet man starter med prosjektplanleggingen. En ting er finansiering, har man et budsjett å overholde, og/eller er det flere parter som er involvert i form av at de får fortjeneste på prosjektet (ikke nødvendigvis på samme stadier)? Eller har man en endelig deadline på et prosjekt hvor det er vanskelig å forutsi hvor mye tid man kommer til å trenge? I dette prosjektet har vi faktiske «stakeholders» å forholde oss til i og med at «kunden» (Norges idrettshøyskole) legger tid og energi produktet vi skal utvikle. Vi har også en 9

10 deadline å forholde oss til i form av endelig innleveringsfrist. Ved å ikke overholde denne vil det gå utover vår endelig karakter, noe vi som gruppe ikke ønsker skal forekomme. En risiko ved prosjektet er muligheten for å miste et eller flere av gruppemedlemmene. Enten det skulle forekomme sykdom, eller en eller flere av gruppemedlemmene skulle bestemme seg for å droppe ut av kurset, er det alltid en risiko for at noen forsvinner. Det er derfor viktig at alle hele tiden holder seg oppdaterte på de andre gruppemedlemmenes ansvarsområder. Vi har derfor valgt å ta i bruk fil delings-siden dropbox, slik at man kan legge ut relevant informasjon/dokumenter på et felles område etter gruppemøter eller selvstendig arbeid. I arbeidsavtalen har vi blitt enige om at dette skal gjøres etter hver gang man jobber med prosjektet. Om noen av gruppemedlemmene skulle av en eller annen grunn måtte forlate prosjektet vil det bli mer arbeid på de andre. Derfor er det hele tiden viktig at ingen sitter på oppgaver ene og alene slik at de andre får liten innsikt i arbeidet som foreståes. Om denne situasjonen ville ha oppstått ville de gjenværende på gruppa fort komme til å slite med å ta igjen evet arbeid som avgående gruppemedlem da hadde tatt med seg. Noe man er nødt til å ta stilling til er muligheten for uhell. Vi jobber hele tiden med PC-er og lagrer naturligvis alt arbeidet der, dette gjelder alt av kode og andre dokumenter. Om det da skulle skje et uhell med maskinen etter at arbeid kun er lagret der, som for eksempel at datamaskinen blir ødelagt, går arbeidet tapt for alltid. Dette er enda en grunn for at det er veldig viktig at ingen på gruppen ene og alene sitter på relevant arbeid for prosjektet. Dette er også en god grunn for alltid å laste opp arbeidet på felles bruker-område, her har vi altså valgt å foreta oss dropbox. Når ting ligger ute på dropbox vil man alltid ha tilgang til det. Om man virkelig skulle ha uflaks og dropbox også skulle kræsje har gruppa blitt enige om at man skal lagre ting når de er ferdige på fronter, er man ferdig med for eksempel et av HTML- arkene, eller er blitt ferdig med større arbeid som man vil få mye jobb med å skulle gjenopprette er det greit at man laster det opp på github som vi bruker til versjonshåndtering. For en gruppe er det ikke alltid like lett å få til gruppemøter som passer for alle. Noen har jobb, og ikke alle har forelesninger på de samme tidspunktene. Noe som også kan skje er at det oppstår sykdom som gjør at enkelte ikke kan være med fra tid til annen. Vi har derfor forsøkt å legge det opp til at det er enkelt å gjøre ting på egenhånd, i den grad at vi alltid sørger for å ha produktive gruppemøter hvor vi planlegger grundig og informerer hverandre om ting man evet skulle ha kommet over, eller ting man kan ha gjort siden sist. For at ingen 10

11 skal komme seg unna med å ikke bidra til prosjektet har vi gjort det til et punkt i samarbeidsavtale at man skal være forberedt til gruppemøtene, ikke nødvendigvis at man skal ha gjort en hel masse, men at man skal gjøre det man har tatt på seg ansvaret for å gjøre. Videre skal man holde seg oppdatert på det de andre gjør i form av å følge med på dropbox og fellesdokument i google docs. Det er videre viktig at vi hele tiden har en god kommunikasjon oss gruppemedlemmer imellom, slik at om de skulle forekomme uforutsette hindre så kan man informere de andre. Dette gjør det mulig å drøfte problemene uten at man nødvendigvis må vente til neste avtalte gruppemøte. 8.1 Risikoanalyse Det er flere uforutsette hendelser som kan skape problemer for oss i forbindelse med prosjektarbeidet. Hovedpunktene er: Sykdom Problemer med kommunikasjon Miste ett eller flere gruppemedlemmer Mangel på motivasjon Mangel på informasjon og/eller data Tidsmangel Problemer med teknologi/lagring I skjemaet under er det redegjort for de forskjellige punktene. 11

12 8.2 Risikostyring Tabellen nedenfor kan utvides/tilpasses ved behov Risiko: Hva kan oppstå? Sykdom Kommunikasjonssvikt Frafall av et eller flere gruppemedlemmer Sannsynlighet? Middels Lav Lav Strategi: Hvordan løse problemet dersom det oppstår? Sykdom kan forekomme når som helst og kan forsinke prosjektarbeidet. For å minske skaden sykdom påfører prosjektet bruker vi dropbox for å dele filer slik at vi kan holde oss oppdatert på hverandres arbeid fortløpende. Videre vil god planlegging samt klar fordeling av arbeidsoppgaver tillate medlemmene å jobbe hjemmefra. Dette gjør at at sykdom er en minimal risiko. Kommunikasjonssvikt innad i gruppen kan føre til at flere gjør samme oppgaver, at individuelt arbeid ikke passer sammen og at fristene ikke blir fulgt. For å hindre kommunikasjonssvikt har vi en klar arbeidsfordeling samtidig som vi møtes ofte. Videre har vi hverandres telefonnummer og facebook/skype slik at alle gruppemedlemmer hele tiden er i dialog. Utenom dette møtes vi også i forbindelse med andre fag, hvor vi gjerne også snakker om gruppeprosjektet. Det er også ønskelig å finne på noe sosialt utenom skolen, for å få et godt samhold. Man vet aldri om man kan komme til å miste et gruppemedlem, konsekvensene kan være at resterende gruppemedlemmer får ekstra arbeid. Videre kan man, dersom man ikke har lagret arbeidet på felles områder, også miste viktig arbeid. For å forebygge at noen faller fra må vi sørge for å skape et godt gruppemiljø slik at ingen forsvinner fordi de ikke trives. Dersom noen skulle forsvinne grunnet andre årsaker er det viktig at de resterende medlemmene kan 12

13 fortsette arbeidet. Dette sikrer vi ved å bruke dropbox, her skal alt av arbeid legges ut. I tillegg benytter vi google docs og vi har en egen gruppe på Facebook. Mangel på motivasjon Mangel på informasjon og/eller data Middels Lav Det er mange ting som kan gi redusert motivasjon, og det kan skje den beste. Motivasjonsmangel kan virke smittende og vi ønsker å få det ut av verden med en gang dersom det skulle skje oss. Dersom ambisjonsnivået blant gruppemedlemmene er i høy grad varierende kan det hende at samarbeidet i gruppen svikter. For å forebygge dette gjør vi hverandre klar over hvilke ambisjoner alle på gruppen har. Vi har laget en gruppekontrakt som samsvarer med disse. Dersom problemet fortsatt ikke forsvinner må de resterende gruppemedlemmene hjelpe den/de umotiverte med oppgavene og være åpne for å lytte til han/hun. Vi sørger også for å møtes treffes såpass ofte at det merkes raskt dersom noen er på vei til å falle fra. Alle må bygge hverandre opp. Et flertall i gruppa har myndighet til å «si opp» et medlem som ikke innfrir kravene som er satt i gruppekontrakten. Det kan oppstå problemer ved innhenting av informasjon eller data. For å forebygge at man mangler informasjon eller data er det eneste man kan gjøre å gjøre grundig research. Hvis det oppstår mangel på informasjon eller data skal informasjonsansvarlig melde fra til gruppen som kan prøve å hjelpe med å finne en løsning. Vi har allerede god dialog med oppdragsgiver og de er svært behjelpelige med alt vi har av spørsmål. Dette innebærer at vi også allerede har fått masse informasjon som gir godt grunnlag for videre arbeid. Videre har vi også forskjellige kontaktpersoner til de forskjellige oppgavene i prosjektarbeidet. Denne risikoen er derfor å anse som minimal. 13

14 Tidsmangel Backup Stor Lav Tidsmangel er noe de fleste grupper opplever en eller annen gang i løpet av prosjektet. For å forebygge dette best mulig er det viktig å sette frister og videre opprettholde disse. Det er også lurt å sette seg oppnåelige mål. Hvis tidsproblemer oppstår er det viktig at hele gruppen hjelper til med å få prosjektet på rett spor igjen. For å sikre oss ekstra på dette punktet har vi valgt å lage tidsplanen litt romsligere når våren kommer. Vi regner med at vi trenger all ekstra tid vi kan få når innleveringsfristen nærmer seg. I tillegg er vi enige om at 20 studiepoeng blir i overkant av 25 timer med arbeid i uken. Vi skal jobbe tilsvarende hver uke fra starten av. Vi velger å sette stor risiko her ettersom mange tidligere studenter opplevde dårlig tid mot slutten. Ettersom vi legger inn mange arbeidstimer helt fra starten av har vi forebygget problemet. Men vi regner likevel med at muligheten for dette er stor. Det er alltid en viss sannsynlighet for at tekniske problemer oppstår. Harddisker, minnepinner og datamaskiner kan lett bli ødelagt og med dette kan data gå tapt. Derfor er det viktig å ta backup. Dette gjør vi ved å benytte oss av dropbox, da ligger alt av på en webserver. Vi supplerer også med google docs. I tillegg lagrer en av gruppemedlemmene alt arbeid på sin personlige lagringsenhet. 14