4
Side 83 av 155
Innholdsfortegnelse 1 Kravspesifikasjon... 86 2 Kravspesifikasjon 2.0... 92 3 Domenemodell... 98 4 UseCase Diagram Oversikt... 102 6 Detaljert beskrivelse av UseCase Diagram... 106 Webapplikasjon... 108 Nettbrett applikasjon... 109 7 Sekvensdiagrammer... 110 Webapplikasjon Normal hendelsesflyt... 112 Webapplikasjon Avvikende hendelsesflyt... 113 Nettbrett applikasjon Normal hendelsesflyt... 113 Nettbrett applikasjon avvikende hendelsesflyt... 114 8 SWOT Analyser... 116 SWOT analyse av Webapplikasjon... 118 SWOT-analyse av Nettbrett applikasjon... 119 9 Sprint Reviews... 120 Sprint 1-17.02.14 28.02.14... 122 Sprint 2-03.03.14 16.03.14... 124 Sprint 3-19.03.14 31.03.14... 126 Sprint 4 03.04.14 11.04.14... 128 Sprint 5 15.04.14 19.05.14... 129 10 Skisser... 130 Admin... 132 Nettbrett applikasjon... 134 11 Brukermanualer... 140 Side 84 av 155
Side 85 av 155
: 1 Kravspesifikasjon Side 86 av 155
Side 87 av 155
Side 88 av 155
Side 89 av 155
Side 90 av 155
: 2 Kravspesifikasjon 2.0 Side 92 av 155
Side 93 av 155
Kravspesifikasjon Versjon 2.0 1. Krav til applikasjonene 1.1 Systemkrav Generelt hele applikasjon for web- og nettbrett løsning Windows 8.1 som operativsystem Windows Surface nettbrett som utgangspunkt for nettbrett 1.2.A) Generelle Funksjonelle krav Applikasjonen skal la brukeren se hva som er nytt, hva som er populært, hva som har høyest karakter, og hva som er anbefalt fra Microsoft. 1.2.B) Funksjonskrav Administrasjonsportal/web Mulighet til å legge inn/endre/slette nye utviklere Mulighet til å legge inn/endre/slette nye applikasjoner Mulighet til å administrere/opprette/endre/slette brukere Mulighet for å liste disse ut i applikasjonen på nettbrett 1.2.C) Funksjonskrav AppenesApp nettbrett Det skal ikke ta mer enn 3 klikk for å komme seg frem til en applikasjon Mulighet til å klikke på kategorier og bla seg rundt Mulighet til å klikke på applikasjoner og se informasjon Mulighet til å viderekobles til Marketplace for å kjøpe bestemt applikasjon 1.2.D) Ikke-funksjonelle krav Side 94 av 155
Blogg, der det dokumenteres Løsningen skal lages i C# og ASP.NET Webløsningen skal kunne kjøres i alle type nettlesere (Best optimalt til Chrome og Internett Explorer) Hele løsningen skal være på norsk (programmering og koden i bakgrunnen kan være engelsk) Det skal lages brukermanualer for web og applikasjon, hver for seg. 1.3 Tekniske krav Utviklingsverktøy: Visual Studio 2013 Programmeringsspråk: C#,.NET og XAML (Applikasjonen) Andre språk til utforming: JSON, SQL, HTML5, CSS3 Dropbox og Google disc til fildeling og back-up 1.4 Krav til Design og Respons Appen skal følge de til enhver tid gjeldende retningslinjer for design(https://design.windows.com/). I utgangspunktet skal vi selv utarbeide designet og i samråd med Microsofts sine veiledere. Designet skal også godkjennes tidlig før det igangsettes arbeid med tilhørende kode I tråd med Microsofts generelle retningslinjer for Windows apper finnes det krav til responstider. Applikasjonen skal ikke utføre operasjoner som blokkerer brukergrensesnittet, da dette medfører en dårligere opplevelse for forbrukeren. Administrasjonsgrensesnitt på web skal ikke bruke over ett sekund på å levere en side. 1.5 Kvalitetskrav Side 95 av 155
Applikasjonens kvalitet vil bli vurdert mot ISO9601 Standard for Software. Denne standarden er nylig blitt revidert, men til dette formålet er 9601 mer enn god nok. Informasjon om ISO9601 og hva som vurderes kan finnes i følgende artikkel på Wikipedia: http://en.wikipedia.org/wiki/iso/iec_9126 1.6 Krav til utviklingsverktøy Microsoft Visual Studio Ultimate 2013 Windows Azure Visual Studio Online Office 365 Photoshop 1.7 Fremtidig utvidelse av systemet Applikasjonen skal lages med hensyn til at det skal være mulig å gjøre endringer i fremtiden, i form av kode, design og oppdateringer. Windows phone som utgangspunkt for mobil løsning som var et nedprioritert krav, men ikke ble nådd. Kjapp responstid, kravet om kort responstid ble ikke nådd og vil da bli en mulighet til å arbeide på videre. 1.8 Krav til arbeidsmetode Scrum skal benyttes som arbeidsmetode Det skal være sprinter med deadline hver 14 dag. Det skal holdes review-møter og avtale om møter med ekstern veileder skal skje hyppig Det skal blogges igjennom hele utviklingsprosessen, som vil regnes som en del av dokumentasjon og logg for ekstern veileder. 1.9 Krav til arkitektur og oppbygning MVVM Side 96 av 155
N-lagsarkitektur Side 97 av 155
: 3 Domenemodell Side 98 av 155
Side 99 av 155
Side 100 av 155
Side 101 av 155
: 4 UseCase Diagram Oversikt Side 102 av 155
Side 103 av 155
Side 104 av 155
Side 105 av 155
: 6 Detaljert beskrivelse av UseCase Diagram Side 106 av 155
Side 107 av 155
Webapplikasjon Beskrivelse Oppretting av apper: Hovedaktør: Administrator Sekundær aktør: Entity framework/cloud, database. Trigger: En admin ønsker å oppdatere applisten, med en ny app Prebetingelse: Enheten krever tilkoblet internett, administrator-pålogging, lagt inn utvikler informasjon om bestemt app. Postbetingelse: Enheten skal oppdateres med en ny app i listen og vises Normal hendelsesflyt: 1. Administrator ønsker å legge til en ny applikasjon 2. Administrasjonsportalen ber administratoren om å fylle ut av felter for en ny applikasjon 3. Administratoren lagrer applikasjonsinformasjon 4. Systemet sjekker om applikasjonsinformasjon er utfylt riktig 5. Applikasjonen blir satt inn i databasen 6. Applikasjonen er tilgjengelig i systemet Variasjoner/Avvik: 4.) Systemet forteller administrator at applikasjonsinformasjon ikke er utfylt riktig. 4.1) Systemet går tilbake til punkt 2 i den normale hendelsesflyten. Side 108 av 155
Nettbrett applikasjon Beskrivelse Visning av apper: Hovedaktør: Bruker Sekundær aktør: Marketplace Trigger: Brukeren ønske å se informasjon og kjøpe en bestemt app Prebetingelse: Enheten krever tilkoblet internett og installert appen på RT Postbetingelse: Skal kunne viderekobles til Marketplace for å kjøpe ønsket app Normal hendelsesflyt: 1.) En bruker ønsker å kjøpe en applikasjon 2.) Brukeren velger kategori 3.) Systemet lister opp alle applikasjoner tilhørende valgt kategori 4.) Brukeren velger applikasjon 5.) Systemet viser applikasjonsinformasjon 6.) Brukeren trykker på «Marketplace» -knappen 7.) Systemet videresender brukeren til Marketplace. Variasjon/Avvik: 1.1) Brukeren hopper over 2) og 3) og går direkte til 4) Side 109 av 155
: 7 Sekvensdiagrammer Side 110 av 155
Side 111 av 155
Webapplikasjon Normal hendelsesflyt Dette sekvensdiagrammet viser brukstilfellet: Legg til ny applikasjon, som også er presentert ved bruk av Use Case tidligere. Legg til ny applikasjon Normal hendelsesflyt 1. Administrator ønsker å legge til en ny applikasjon 2. Administrasjonsportalen ber administratoren om å fylle ut av felter for en ny applikasjon 3. Administratoren lagrer applikasjonsinformasjon 4. Systemet sjekker om applikasjonsinformasjon er utfylt riktig 5. Applikasjonen blir satt inn i databasen 6. Applikasjonen er tilgjengelig i systemet Side 112 av 155
Webapplikasjon Avvikende hendelsesflyt Dette sekvensdiagrammet viser brukstilfellet: Legg til ny applikasjon med avvikende hendelsesflyt, som også er presentert ved bruk av Use Case tidligere. Legg til ny applikasjon Variasjoner/Avvik 4.) Systemet forteller administrator at applikasjonsinformasjon ikke er utfylt riktig. 4.1) Systemet går tilbake til punkt 2 i den normale hendelsesflyten. Nettbrett applikasjon Normal hendelsesflyt Dette sekvensdiagrammet viser brukstilfellet: kjøp applikasjon, som også er presentert ved bruk av Use Case tidligere. Side 113 av 155
Kjøpe Applikasjon Normal hendelsesflyt 1.) En bruker ønsker å kjøpe en applikasjon 2.) Brukeren velger kategori 3.) Systemet lister opp alle applikasjoner tilhørende valgt kategori 4.) Brukeren velger applikasjon 5.) Systemet viser applikasjonsinformasjon 6.) Brukeren trykker på «Marketplace» -knappen 7.) Systemet videresender brukeren til Marketplace. Nettbrett applikasjon avvikende hendelsesflyt Dette sekvensdiagrammet viser brukstilfellet: kjøp applikasjon avvikende hendelsesflyt, som også er presentert ved bruk av UseCase tidligere. Side 114 av 155
Kjøpe Applikasjon Avvik/ Variasjon 1.2) Brukeren hopper over 2) og 3) og går direkte til 4) Side 115 av 155
: 8 SWOT Analyser Side 116 av 155
Side 117 av 155
SWOT analyse av Webapplikasjon I N T E R N Strength Pen og ryddig portal, med god oversikt Funksjonaliteten fungerer slik det ønskes Sammenkobling mellom Web og App fungerer Badges legges inn og det finnes en automatisering i det Koden er lett å forstå Weakness Nedlastninger for hver app, må registreres manuelt og oppdateres en gang i måneden. Microsoft har ikke API, som apper kan hentes fra, disse på legges inn manuelt E K S T E R N Opportunities Webløsningen har store muligheter for videreutvikling og endringer, der sikkerhet bør prioriteres Webløsningen kan effektiviseres i samarbeid med appen rask responstid Webløsningen kan utvides for Windows Phone Threats Dataangrep Nedetid på server Programmet opprettholdes ikke Side 118 av 155
SWOT-analyse av Nettbrett applikasjon I N T E R N Strength Selvforklarende applikasjon Lett å bruke Godt design gjenkjennbar, følger Microsoft design guidelines Bruker nytt utseende - hubdesign Weakness Finnes en kjent «store» på forhånd Ukjent responstid E K S T E R N Opportunities Det kan legges inn flere kategorier Mer «brukerinput», legge igjen kommentarer under applikasjonen Hubsection skal i fremtiden kunne benyttes på en enklere måte Threats Uønskelig applikasjon Får/ingen nedlastninger Vanskelig å endre på brukergrensesnittet. Side 119 av 155
: 9 Sprint Reviews Dette vedlegget vil ta for seg alt, som har blitt diskutert under «Sprint Review»-møtene. I våre «Sprint Review»- møter har vi diskutert om, hvorfor «burndown»-grafen ser ut som den gjør, hva gikk bra, hva gikk dårlig og hvordan kan dette forbedres. Side 120 av 155
Side 121 av 155
Sprint 1-17.02.14 28.02.14 Figur 1: Burndown for Sprint 1 Analyse av Sprint 1 Denne sprinten handlet om å komme i gang med prosjektet. Her skulle back-end løsningen planlegges, altså administrasjonsportalen. Noen av arbeidsoppgavene var: Å lage et layout som alle er fornøyde med Opprette Controllers, Models og views Opprette database for brukernavn og passord Ha på plass en Azure server Dette er noen av de få oppgavene, vi skulle jobbe med. Ikke så avansert, hvis man har dette under fingra og vet, hva man skal. Vi derimot, måtte grave litt dypere. Ut ifra «Burndown» kan vi se, at denne sprinten ikke var ideell. Vi startet på sprinten samme dag som vi planla den, men rakk ikke den bestemte arbeidsmengden og slik hopet grafen seg oppover. Dette var da en lærepenge for oss, dette er slik en «Burndown» ikke skal se ut. Vi nådde ikke å bli ferdig med sprinten, selv om «burndown»-grafen ser ut som vi nådde i mål. Dette skyldes misforståelser om at vi ble fortalt at man så skulle flytte over de «Product Backlog Items», som ikke var ferdige til neste sprint. Det vi derimot ikke visste, var at, vi ikke skulle gjøre det, den samme dagen sprinten avsluttet, men etter sprintavslutningen, dette er grunnen til at grafen ikke viser den reelle arbeidsmengden. Side 122 av 155
Vurdering av sprint 1 Bra I denne sprinten har vi lært en del om layout, hvordan azure fungerer, planlegging av Scrum samtidig som vi har lært værktøyene Visual Studio Online og Visual studio at kjenne. Vi har i teamet vært veldig hjelpsomme og kommunisert bra i gruppa. Da vi så, at det ville bli vanskelig å nå målet med «burndown»-grafen ga hele gruppen noe ekstra og jobbet i helgen også, for å ikke forskyve mange PBI er til neste sprint. Dårlig Vi har hatt noe sykdom, en av gruppemedlemmene har vært syke, samtidig som vi var veldig dårlige til å planlegge sprinten. Vi følte oss avhengig av svar fra ekstern veileder, men det var ikke ofte vi fikk disse svar og det skapte frustrasjon i gruppa, da det var nytt for oss å bruke værktøyet, Visual Studio Online i sammenheng av Scrum. Forbedring Vi må bli bedre til å planlegge en sprint. Vi må prøve oss frem selv om ekstern veileder ikke svarer, fordi vi bortkaster tid på å vente på svar. Side 123 av 155
Sprint 2-03.03.14 16.03.14 Figur 2: Burndown for Sprint 2 Analyse av sprint 2 Over helgen like etter slutt av sprint 1, startet vi sprint 2, den samme dagen som vi planla den. Vi fikk ikke fylt opp tiden, som vi hadde til rådighet i sprinten, samtidig som vi hadde stadig problemer med å estimere tiden. Vi har overestimert vår egen kapasitet til å gjennomføre, og underestimert tiden som oppgavene tar. Vi fikk da 04.03.2014 hjelp av vår veileder Simen til å estimere litt bedre. Det var mange PBI er og «tasks» vi ikke hadde fått med. Grunnet dette ser starten på «Burndown»-grafen ikke så fin ut, men vi fikk det til å gå nedover inntil 11.03.2014, hvor vi skulle til å begynne på nettbrett applikasjonen. Dette var vanskelig, da vi aldri hadde programmet i XAML, og fordi vi ikke var klar over, hvordan vi skulle få databasen (AppContext) til å snakke med applikasjonen. Men vi lagde litt «research» på nettet og fant ut av at vi skulle lage API er, hvilket også var noe nytt for oss. Dermed endte det med at etter den 11.03.2014 gikk det bare langsomt fremover og umulig for oss å nå i mål. Vi hadde underestimert tiden, på hvor lang tid det ville ta oss for å lage en side med innhold fra databasen. Side 124 av 155
Vurdering av sprint 2 Bra Mye av administrasjonsportalen er ferdig og vi har starta på nettbrett applikasjonen. Vi har lest en del om Windows 8.1 applikasjoner og fått en bedre forståelse av hvordan vi skal starte å utvikle nettbrett applikasjonen. Dårlig Vi har underestimert det å utvikle en nettbrett applikasjon, vi burde ha tatt i betraktning at vi aldri har utviklet i XAML og å lære dette kommer til å ta noe tid, og generelt underestimert alle «tasks». Derutover må vi bli flinkere til å planlegge og ikke sitte fast i samme problem alle sammen. Forbedring Noe vi absolutt må lære av til neste sprint, at det er nesten bedre å overestimere tiden enn å underestimere tiden for diverse tasks. For hvis vi får gjort oppgavene (PBI ene) fortere er det bare å trekke inn nye PBI. Side 125 av 155
Sprint 3-19.03.14 31.03.14 Figur 2: Burndown for Sprint 3 Analyse av Sprint 3 Vi har før denne sprinten brukt 2 dager til planlegging (17. mars og 18.mars). Grunnen til dette er fordi, at vi har sett, at vi ikke klarer å planlegge og estimere riktig, så derfor prøvde vi å planlegge så mye som mulig selv d. 17. mars og d.18. mars skulle intern veileder hjelpe oss med å se hva vi har estimert riktig og feil så at vi denne gangen kunne rette opp på de feil vi har gjort hittil i de forrige 2 sprintene. Sprint 3 s «burndown» ser betydelig bedre ut enn de tidligere, dette kommer som et resultat av god planlegging og bedre gjennomføring av tasker. I begynnelsen av sprinten virket det som vi igjen kommer til å få en ujevn graf. Grunnen til at arbeidsmengden gikk opp i begynnelsen av sprinten var fordi, vi ikke visste, hvordan vi skulle få automatisering av «badges» til å fungere på administrasjonsportalen. Vi ventet da på svar på e-post fra Microsoft, i håp om å vite om det fantes noen «API'er» der vi kunne hente data direkte, som for eksempel om nedlastninger og ratings. Vi fikk svar ganske sent og fikk ikke ordentlig informasjon om at Microsoft ikke hadde API'er, så vi måtte lage og ordne dette selv. Vi var også på møte hos Microsoft den 27.03.14, for en demo av Sprint 2 og vise Pedro, det vi har gjort hittil i sprint 3. Vi fikk tilbakemelding om at vi ikke skal bruke listview for appen, og heller skulle bruke «hubview». Dette var et tilbakeslag for oss, selv om grafen ikke viser dette. Vi nådde å innhente det, fordi vi hadde valgt å overestimere litt, fordi vi hadde forutsett problemer med XAML, siden dette var et ukjent område for oss. Side 126 av 155
Vurdering av sprint 3 Bra Det at vi brukte 2 dager på planlegging av veldig bra, fordi dette viser seg i hvordan grafen har utformet seg, denne er betydelig bedre enn de forrige. Vi har lært en masse nytt om utvikling i XAML og generelt om nettbrett applikasjonens funksjoner. Dårlig Det dårlige ved denne sprinten var vel at vi bortkasta litt tid på å vente på mail fra oppdragsgiver, for å høre om Microsoft har noen API er til MarketPlace som gjør det mulig å hente ut informasjon om nedlastinger og ratings. Oppdragsgiver hadde ikke fortalt oss, at de ønsket Hubview til nettbrett applikasjonen. Forbedring Vi ville ønsket, at vi hadde fått vite tidligere eller at det var nevnt i kravspesifikasjonen, at vi måtte bruke Hubview til å lage applikasjonen. Side 127 av 155
Sprint 4 03.04.14 11.04.14 Figur 3 Burndown for Sprint 4 Analyse av Sprint 4 Validering tok tid å finne ut av, derfor gikk grafen opp den 04.03.14, det fantes validering, men denne ville ikke dukke opp på websiden, når den kjørtes. Den 08.03.14 gikk den drastisk ned, da det gikk veldig fort å rette opp i «validation», da vi endelig visste, hvordan dette skulle løses. Vi fikk også løst uthenting av ratings veldig raskt. Generelt har sprinten vært veldig grei, taskene har blitt løst til tide. Vurdering av Sprint 4 Bra Dette har vært vår beste sprint hittil. Vi har jobbet godt å nådd i mål med alle «tasks» uten de store problemene. Dårlig I denne sprinten har det ikke vært så mye dårlige ting, utover at vi brukte litt tid på «validation», men ellers har det godt veldig bra. Forbedring Vi burde ha eksperimentert litt med «validation», så hadde vi kanskje fått det til litt fortere, fordi det viste seg å være kjempe lett å få til, da vi skjønte det. Side 128 av 155
Sprint 5 15.04.14 19.05.14 Analyse av Sprint 5 Dette har vært vår perfekte sprint og også vår siste sprint. Grunnen til at vi har fått en så lang sprint er, fordi vi måtte begynne å skrive dokumentasjon, før vi rakk å bli ferdige med utviklingen av produktet. Dermed la vi inn fridager til dokumentasjonsskriving, samtidig som at vi kunne få tid til å fullføre den siste finpussen på produktet før levering. I denne sprinten skulle vi sørge for at bindingen mellom applikasjonen og webløsningen fungerer knirkefritt. Det er et tilbakeslag, at Azure har utløpt, slik at vi ikke kan se resultatet lengere. Alt i alt har sprinten vært perfekt, alle arbeidsoppgaver har blitt nådd og annet enn klage på Azure, har det ikke vært mye annet å sette en negativ finger på. Vurdering av Sprint 5 Bra Det har gått veldig bra, og det har vært god stemning i gruppen, nå som vi nærmer oss slutten på prosjektet. Dårlig Det eneste dårlige i denne sprinten har vært at Azure hadde utløpt, så vi måtte spørre om ny azurepass og dette funket ikke på den kontoen vi hadde fra før. Forbedring Det kunne vært bedre om vi kunne hatt en lettere løsning med «Azure-problemet». Side 129 av 155
: 10 Skisser Side 130 av 155
Side 131 av 155
Admin Side 132 av 155
Side 133 av 155
Nettbrett applikasjon Skisse 1 - Splashscreen Skisse 2 - Mainpage utkast 1 Side 134 av 155
Skisse 3 Mainpage utkast 2 Skisse 4 - Kategoriside utkast 1 Side 135 av 155
Skisse 5 Kategoriside utkast 2 Side 136 av 155
Skisse 6 Applikasjonsside del 1 & 2 Side 137 av 155
Skisse 7 Applikasjonsside del 3 Side 138 av 155
Side 139 av 155
: 11 Brukermanualer Side 140 av 155
Side 141 av 155