1. Introduksjon. Glis 13/02/2018

Transkript

1 SDP GLIS Espen Buø

2 Innholdsfortegnelse 1. Introduksjon Gruppebeskrivelse og ansvarsområder Risikoanalyse Hardware og softwarekrav for brukeren Behov for prosjektet Utviklingsmetode Work breakdown structure Framdriftsplan Nyttige lenker

3 1. Introduksjon Inspirert av Kahoot, og sparket i gang av et ønske om å lage et spill som kan gjøre læring mer interaktivt i skolen. «Glis» som vi midlertidig har døpt prosjektet, ønsker vi skal være en brukervennlig platform for å opprette og gjennomføre quizzer. En registrert bruker skal kunne sette opp en rekke spørsmål med svaralternativer, og generere en kode som andre kan logge inn med for å delta. Deltakerne i quizzen skal kunne gjøre dette samtidig. Forhåpentligvis vil dette bidra til å engasjere og mulighens aktivere konkurranseinstinket hos et bredere antall elever enn under klassisk undervisning. Prosjektet foregår over en periode på omtrent 17 uker, og har frist til 8/ Det skal også gjennomføres en presentasjon av programmet helt i slutten av prosjektperioden. 2

4 2. Gruppebeskrivelse og ansvarsområder I et prosjekt hvor det skal utvikles et «Spillbasert læringssystem» kreves et team med forskjellige evner. Kunnskap og kreativitet som kan både designe og realisere et attraktivt produkt er ønskelig. Mest sentralt er likevel evnen til å jobbe strukturert mot et felles mål, noe som vi i Glis mener er vår fellesnevner. I skrivende stund er vi: - Cecilie D. Gløsmyr, 20 år fra Skien, utnevnt team leader for hele prosjektet. Hun har som hovedoppgave å designe og veilede all utvikling. I de første fasene av prosjektet blir hennes kreative lederrolle mest tydelig, ettersom senere arbeid vil fokusere mer på ferdig definerte mål. - Espen Buø, 23 år fra Kristiansand, har hovedansvaret for databasen. Er det spørsmål om bruk av SQL er det han som skal undersøke dette. Espen er administrator for Glisgames på VSTS. - Henrik Lie, 22 år fra Momoen, har hovedansvar for kryptering. I tillegg skal research rundt ASP.NET være hans ekspertområde. Arbeidstimer skal være jevnt fordelt så lenge dette lar seg gjøre. Dokumentasjon blir skrevet like mye av alle medlemmer, selv om dette kan føre til at språket blir noe inkonsekvent. Ansvar-/ekspertsområder som kan blir delegert senere: - C# - PHP - HTML + CSS - Serversikkerhet - Testing - Brukeropplevelse 3

5 3. Risikoanalyse Dette prosjektet utsetter hverken utviklere, sluttbrukere eller andre for noen fysisk risiko. Under prosjektperioden på ca 17 uker er det ikke usannsynlig at medlemmer i teamet midlertidig blir opptatt med andre prosjekter, lider av sykdom eller annet som hindrer deltakelsen i utviklingen av «Glis». Fordi hele prosjektet bare består av tre personer kan dette føre til betydelige mangler i arbeidskraft. Det er derfor viktig at prosjektet avgrenses fornuftig, og i verste fall et brukbart produkt blir levert. Scrum-metoden for utvikling av programvare vil i stor grad sikre at sluttproduktet holder vann og har fått implementert en mengde av de funksjoner vi ønsker det skal ha. Tekniske problemer med en PC kan skape uforutsette forsinkelser i utviklingen. Testing av software i god tid bør hindre de fleste av disse problemene blir kritiske. Tap av filer skal ikke være en kilde til bekymring så lenge alt backes opp etter utførte endringer i VSTS. Datasikkerhet for database vil tas hensyn til etter behov. I utgangspunktet skal ingen personlig eller annen sensitiv data lagres i sammenheng med Glis. Likevel er det verdt å nevne at både epost-adresse og passord skal lagres, men sistnevnte ikke i klartekst. 4

6 4. Hardware og softwarekrav for brukeren Dette punktet er fortsatt under diskusjon. - PC med nettleser. - Mobiltelefon med nettleser. Ikke prioritert, men kan implementeres hvis hovedfunksjoner allerede er på plass. 5

7 5. Behov for prosjektet Hvert medlem i prosjektet må ha: - PC med Windows 7/8/10 - Microsoft Visual Studio - Microsoft Word Minst ett medlem i prosjektet må ha: - Microsoft Visual Studio Enterprise SQL Server + Management Studio eller liknende - Microsoft Visio - GanttProject - Erwin modeller Andre ønsker: - Server som kan kjøre SQL server og serverklient 24/7 med internett-tilkobling. Fildeling og versjonkontroll: - OneDrive mappe som eies av Henrik, men alle medlemmer har tilgang til. Brukes til uformelle og midlertidige dokumenter. - VSTS satt opp med Scrum-metoden brukes både til versjonkontroll og fildeling. Er konfigurert til å bruke VSTS egen versjonkontroll. Se kapittel 9. 6

8 6. Utviklingsmetode Etter Scrum-metoden skal ukentlige mål settes opp og gjennomgåes hver tirsdag og fredag. Fristen for ukentlige mål er tirsdag klokken 10:15. Hvordan arbeidet skal fordeles er opp til teamleder, og gjøres rett etter tirsdagsmøtet. 7

9 7. Work breakdown structure WBS-diagram som forenklet viser hovedstadiene i software-utvikling horisontalt, og sentrale oppgaver usortert nedover.(figur 1) Figur Første utkast av WBS. Tar ikke for seg inndeling av arbeid fra og med implementering. 8

10 8. Framdriftsplan Gantt-diagramet viser oversiktlig hvor mye tid som skal brukes på hver oppgave. (Figur 2) Arbeidsoppgaver viser bare veiledende tidspunkt, mens milepæler er fastsatt. Figure Gantt-diagram 9

11 9. Nyttige lenker VSTS, for offisiell dokumentasjon og versjonkontroll. Onedrive til bruk av midlertidige og uformelle dokumenter. F161096_usn_no%2FDocuments%2FSystemutvikling%20Gruppe%203 10