Forprosjektsrapport MMS - MakeSpace Management System BO19-G03

Transkript

1 Forprosjektsrapport MMS - MakeSpace Management System BO19-G03 Andreas Harnes Celina Marie Kristiansen Magnus Klerck Morten Offerdal Kvigne 21. januar

2 Innhold 1 Prosjektgruppen 3 2 Oppdragsgiver MakerSpace Oppdraget Mål Leveranser Metode Prosjektplan Gantt-diagram Aktivitetsoversikt Risikovurdering Risiko nivå Risiko prioritisering Gjennomføring Oppdragsgiver Veileder Roller

3 1 Prosjektgruppen Bachelorgruppen består av følgende fire IT-studenter: Andreas Harnes. Informatikkstudent med interesse for nettverk og backendprogrammering. Celina Marie Kristiansen. Informatikkstudent med erfaring innen databaser og stordata. Hun har tidligere vore utplassert hos Logiq der hun har brukt Databricks til å bearbeide data. Magnus Klerck. Informasjonssystemstudent med bakgrunn som dataelektroniker der han arbeidet med IT-drift og reparasjon av maskinvare. Han har i tillegg interesse for datasikkerhet. Morten Offerdal Kvigne. Informatikkstudent med bakgrunn fra studiespesialisering med valgfag innen blant annet IT. Han er interessert i programmering og datasikkerhet. 2 Oppdragsgiver Informasjonsteknologiforeleser og MakerSpace-ansvarlig Michael Andersen Lundsveen er oppdragsgiver for prosjektet. 2.1 MakerSpace MakerSpace driftes per dags dato av Michael og 4 studentassistenter. MakerSpace er en avdeling på Høgskolen i Østfold hvor studenter kan utforske teknologi. MakerSpace er et prosjektrom hvor studenter får tilgang til diverse teknologier for å hjelpe dem å bygge deres prosjekter. På MakerSpace blir studentene tilbudt en rekke variert mengde teknologier for å hjelpe dem med prosjektene. Disse teknologiene kan være innenfor flere felter som for eksempel elektronikk, programmering, 3D-printing. På sommeren bruker også MakerSpace å holde kurs for barn slik at de kan lære seg grunnlegene programmering. 3 Oppdraget For øyeblikket finnes det ingen skriftlig oversikt over utstyr og verktøyt på MakerSpace. All informasjon om utstyr og verktøy man finner der er det student assistentene vet hvor er og kan hjelpe deg med å finne. Når det ikke er noen student assistenter er det ingen måte å finne ut om MakerSpace har utstyret eller verktøyet du trenger. For utlån finnes det et analogt system. Det blir tatt i bruk en bok hvor alt av utlånt utstyr skal bli skrevet ned. 3

4 Dette systemet har vist seg å ikke fungere som det skal siden studenter og ansatte ikke bruker systemet ved utlån. Det MakerSpace ønsker seg er et system som gir Michael og student assistentene tilgang til en oversikt over alt utstyr og verktøy som finnes på MakerSpace. Dette systemet skal være modulært slik at det lettere kan videre utvikles i senere tid. I tillegg til dette inventarsystemet ønsker de også en utlåns modul som gjør det lettere å registrere utlån av utstyr og verktøy. Det vi planlegger å utvikle er et modulært inventarsystem og en utlåns modul ved å ta i bruk teknologi som er tatt i bruk i dagen næringsliv. 3.1 Mål Hovedmalet med prosjektet er å utvikle en datastruktur for inventar med en utlånsmodul 3.2 Leveranser Dato Leveranse 18/01 Forprosjektrapport 08/03 Første versjon av hoveddokumemnt 23/04 Andre versjon av hoveddokumemnt 16/05 Ferdig hoveddokument med vedlegg 3.3 Metode Prosjektarbeidet kommer til å bruke den velkjente metoden for arbeid kalt SCRUM. SCRUM er et agile rammeverk for styring av prosjekt. Den har en spesiell spisselse på Software development. SCRUM passer grupper fra tre til ni arbeidere, disse arbeiderene deler opp arbeidsoppgaver så de kan bli ferdig gjort igjennom Sprints. Disse Sprints skal ikke ta lengre enn en måned, men det er mest vanlig at de varer i to uker. Etter dette så blir progressjonen gjennomgått og evaluert og planlagt hva som skal gjøres videre i 15 minutters stand-up meetings som blir kalt daily scrums. 4

5 4 Prosjektplan Gruppen har drøftet og satt sammen 4 milepæler som de mener er viktig å ha for å kunne fullføre oppdragsgivers oppgave. Vær milepæle har en eller flere aktiviteter som skal følges. Både milepælene og aktivitetene er ført inn i et gantt-diagram som vist nedenfor. 4.1 Gantt-diagram 5

6 6

7 7

8 8

9 4.2 Aktivitetsoversikt Milepæle 1: Core Development Beskrivelse: Gruppen setter seg sammen for å bygge inventarsystemet for prosjektet. Denne skal brukes av administratorbrukeren(e). Aktivitet 1: Wireframes Aktivitet 2: Inventarstruktur Aktivitet 3: Nettside Bemanning: WorkShop(gruppen jobber sammen) Leveranse: Inventarsystem Start: Slutt: Milepæle 2: Utlånsmodul Beskrivelse: Dette blir en modul til programmet som gjør det mulig å ha utlån av utstyr som adminstratorbrukeren(e) kan legge til i inventarsystemet. Aktivitet 1: Lage modell for modul Aktivitet 2: Utvikling av modul Bemanning: WorkShop(gruppen jobber sammen) Leveranse: Utlånsmodul som gjør det mulig å legge til produkter i inventarsystemet. Start: Slutt: Milepæle 3 Bruketest av system Beskrivelse: Gruppen skal lage en brukertest til systemet for å se om de kan finne eventuelle hull eller feil i systemet. Gruppen finner testpersoner ved høgskolen som kan være aktuelle til å bruke et slikt system som skal utvikles. Aktivitet 1: Lage bruketest Aktivitet 2: Gjennomføre bruketest Aktivitet 3: Resultat/endring Bemanning: WorkShop(gruppen jobber sammen) Leveranse: Brukertest Start: Slutt:

10 Milepæle 4: Siste innspurt Beskrivelse: Gruppen setter seg ned og finpusser hovedokumentet og gjør det klart til levering. Denne fristen er også satt 1 uke før den ordinære firsten for levering. Aktivitet 1: Legge inn vedlegg Aktivitet 2: Kvalitetssikkre Aktivitet 3: Siste skriving Bemanning: WorkShop(gruppen jobber sammen) Leveranse: Ferdig sluttraport Start: Slutt:

11 5 Risikovurdering Risk-ID Risiko Beskrivelse R-01 Programvare mangler Ett eller flere programmer prosjektet tar i bruk kan mangle støtte for funksjonalitet. Som kan føre til at deler av produktet ikke vil ende opp med den funksjonaliteten som trengs eller ønskes. R-02 R-03 Mangel på kunnskap Sykdom Mangel på kunnskap kan føre til at gruppen kan bruke for mye tid på å undersøke og lære seg nye ting. Dette kan forskyve på aktiviteter og milpæler. Det kan også føre til kvalitets mangler på arbeidet. Sykdom kan føre til forsinkelser på arbeid og sette deler av prosjektet i fare. Gruppen må da delegere oppgaver på færre medlemmer noe som kan skape store forsinkelser. R-04 Mangel på utstyr Gruppen trenger hardware til prosjektet og dette kan komme for sent eller at utstyret blir ødelagt eller ikke passer bruken til prosjektet. R-05 Ødelagt utstyr For å sørge for at produktet fungerer, så skal det testes. Under testing kan det oppdages uforventede problemer eller at noe av utstyret blir ødelagt ved uhell. 11

12 R-06 Lovendring Prosjektet utvikles for MakerSpace Halden, som er en del av Høgskolen i Østfold. Og faller innenfor skolens reglement. Hvis staten stemmer for nye lovendringer i form av personvern eller universal utforming så må produktet støtte dette. Eller ha mulighet for fremtidig utvikling og støtte for lovendringer. R-07 Kompleksitet Gruppen kan undervurdere kompleksiteten av prosjektet og enkelte deler eller moduler kan ta lengre tid enn antatt. Dette kan føre til store forsinkelser og kan sette deler av prosjektet i fare. 12

13 5.1 Risiko nivå 5.2 Risiko prioritisering Prioritisering R-ID Risiko Sannsynlighet Konsekvens Skade R-01 Programvare mangler Mulig Høy L R-02 Mangel på Mulig Høy M kunnskap R-03 Sykdom Mulig Moderat M R-04 Mangel på Mulig Høy H utstyr R-05 Bruker testing Høy Liten L R-06 Lovendring Mulig Moderat/Høy L/M/H R-07 Kompleksitet Mulig Høy H 13

14 6 Gjennomføring Gjennomføring av prosjektet vil bestå av minst to (2) dager i uken med Workshop, hvor gruppen jobber sammen kontinuerlig gjennom dagen. Dette gjøres for å maksimere effektivitet og minimere problemer. Alle vil være til stede for å bidra til prosjektet men også som hjelp til andre i gruppen. Utover dette så vil det bli delegert oppgaver til gruppens medlemmer når de ikke er samlet. Dette arbeidet vil ha tidsfrister som vil bli satt til neste gruppe møte eller Workshop. Prosjektet vil bli dokumentert på en akademisk måte og bruke APA 6th til kildehenvisning. Prosjektet vil bruke Overleaf som skriveprogram. Overleaf er et skriveprogram som vil gjøre det mulig å skrive i sanntid for hele gruppen i ett dokument og holde kontroll på hva som blir gjort. 6.1 Oppdragsgiver Arbeidsgiver står sentralt for prosjektet. Det skal bli utviklet noe som arbeidsgiver skal ha nytte av. Det er da vesentlig med gode tilbakemeldinger og regelmessig kontakt. Det er planlagt å ha ett møte i uken med arbeidsgiver. Det vil bli ca. 15 minutters møte for oppsummering av det som er blitt gjort og om Arbeidsgiver har noen ønsker eller meninger om hva arbeidsgiver forventer videre av prosjektet. Oppdragsgiver har gitt et ønske om å holde det til 15 minutter. Ettersom oppdragsgiver kan være svært opptatt, men med mulighet for lengre møter hvis det trengs. Arbeidsgiver skal også være tilgjengelig på mail eller Skype (El. lignende) hvis et personlig møte ikke er mulig. 6.2 Veileder Gruppen vil ha et møte med veileder en gang i uken hvis det er mulig. Hvis veileder ikke er tilgjengelig så skal kontakt skje med mail. Veileder skal være en ressurs for gruppen hvor det er mulig å få tilbakemelding på arbeidet gruppen gjør på prosjektet. Tilbakemelding på prosjektet er svært viktig for å få best mulig resultat og veileder har har den nødvendige kunnskapen og erfaringen til å hjelpe gruppen med dette. 14

15 6.3 Roller Gruppen har bestemt at det skal være faste roller fremfor rullerende roller. Gruppen mener rollefordelingen blir mer produktiv da hvert gruppemedlem vet hva som forventes av dem. I tillegg mener gruppen det er enklere å ha oversikt over hvilket ansvar den enkelte har da gruppen ser hva den enkeltes rolle er i prosjektet. Vi har delegert følgende roller i gruppen: Backendutvikler: Andreas Harnes. Han er ansvarlig for at backend tilbyr de tjenestene frontend trenger for å fungere, og at tjenestene opererer på en sikker måte. Databaseutvikler: Celina Marie Kristiansen. Hun er ansvarlig for å sette opp databasen slik at den kan lagre nødvendig informasjon som trenges av de respektive modulene på en sikker måte. Dokumentorganiseringsansvarlig: Morten Offerdal Kvigne. Han er ansvarlig for å holde relevant dokumentasjon organisert slik at det er tilgjengelig. Frontendutvikler: Magnus Klerck og Morten Offerdal Kvigne. De er ansvarlige for utviklingen av brukergrensesnittet brukere skal samhandle med og at dette brukergrensesnittet oppfyller krav til universell utforming. Kontaktperson: Andreas Harnes. Han er kontaktperson for gruppen mellom veileder og oppdragsgiver. Prosjektleder: Magnus Klerck. Han er ansvarlig for å holde kontroll på gruppen og arbeidet som gjøres. Han skal sørge for at arbeidet blir gjort til gitt tid og at alle på gruppen har en konkret arbeidsoppgave. Sekretær: Celina Marie Kristiansen. Hun er ansvarlig for å skrive møtereferat for alle møter gruppen har. 15