3 Prosessdokumentasjon

Transkript

1 3

2 Side 51 av 155

3 1 Forord Denne prosessdokumentasjonen er skrevet som en del av et hovedprosjekt for avsluttende studie dataingeniør og informasjonsteknologi, ved Høgskolen i Oslo og Akershus. en beskriver prosessen og refleksjonene bak utviklingen av AppenesApp. Vi vil ta for oss, hva som har vært vanskelig, hvilke utfordringer vi har støtt borti, og hvordan det var vært for oss, som studenter å få muligheten til å teste ut arbeidslivet. Denne rapporten er ment for Microsoft Norge, sensor og for personer, som ønsker å sette seg inn i utviklingsprosessen for AppenesApp. Side 52 av 155

4 Side 53 av 155

5 Innholdsfortegnelse 1 Forord Introduksjon Om Oss Microsoft Norge Bakgrunn for oppgaven Visjon og Mål Utviklingsprosessen Planleggingsprosessen Produksjonsfasen Testing Kravspesifikasjon Sammenligning av produkt og krav Scrum Risikoanalyse Teknisk arkitektur N-Lagsarkitektur(hele løsningen) MVC (Webapplikasjon) MVVM (Nettbrett applikasjon) ISO-standard Design Teknologi & Verktøy XAML JSON HTML & CSS Bootstrap Entity Framework Visual Studio Online Microsoft Powerpoint Microsoft Visual Studio Microsoft Blend Photoshop CS Google Calendar Side 54 av 155

6 8.12 Microsoft Azure - Skyteknologi Google Docs OneNote Microsoft Word Dropbox Skype Facebook Wordpress Konklusjon Gruppesamarbeidet Utfall Kilder Side 55 av 155

7 2 Introduksjon Som avgangselever ved Høgskolen i Oslo og Akershus var det dags for å finne oppdragsgiver for avsluttende hovedprosjekt. Etter kontakt med forskjellige bedrifter kom vi i kontakt med Microsoft Norge, som vi fikk tilbudt en god oppgave av. Denne oppgaven gikk ut på å lage en Windows 8.1 applikasjon med en administrerende del i.net. I denne delen av rapporten kommer våre erfaringer og refleksjoner av prosjektet frem. Side 56 av 155

8 2.1 Om Oss Vi er gruppe 3, «AppenesApp». Gruppe 3 er en kombinasjon av linjene Dataingeniør og Informasjonsteknologi. Athavan Subramaniam Dataingeniør Disha Sangar - Informasjonsteknologi Samjutha Sritharan - Dataingeniør Det å forme denne gruppen var ikke vanskelig; enkelt, fordi vi har arbeidet sammen siden første året, i alle prosjekter hittil og samarbeidet har vært på topp i løpet av de tre siste årene, og derfor var det naturlig å også være en gruppe for hovedprosjektet. Navn Styrker Svakheter Ansvarsområdet Disha Samarbeidsvillig Pratsom Jobber godt under press Sosial/humørbombe Lett distrahert Backend Dokumentasjon Samjutha Hardtarbeidende Stress Frontend, Strukturert Overarbeidede Backend Ansvarlig Dokumentasjon Forståelsesfull Athavan Ansvarsfull Stress Frontend Pliktig Rastløs Dokumentasjon Hardtarbeidende. Side 57 av 155

9 2.2 Microsoft Norge Microsoft er et amerikansk firma, som er verdens ledende programvareselskap. Dette selskapet ble stiftet og grunnlagt av Bill Gates og Paul Allen i Microsoft er kjent for operativsystemene Windows og MS-DOS, Microsoft Office, spillkonsollen XBOX og blant annet er de også kjent for brukertjenester som Skype, MSN, Windows Phone og Surface. I de seneste årene har utviklingen av Windows operativsystemer fortsatt å utvikle seg til nytt og nyere, det nyeste operativsystem fra Microsoft er Windows 8. Dette er da den mest relevante oppdateringen i Windows sin historie, da de for første gang utviklet et operativsystem, som ikke har vært likt og gjenkjennbar, slik som sine tidligere operativsystemer. Windows 8.1, som da var en oppdatering etter Windows 8, er da også den mest relevante for oss, siden vi er nødt til, for best mulig resultat, å benytte oss av Windows 8.1, for å utvikle produktet vi skal for Microsoft. Microsoft har per dags dato ingen oversikt over hvilke norske applikasjoner og utviklere, som er tilgjengelige på markedet. Dette gjelder da spesifikt etter at Windows 8 ble lansert. I dag benyttes «Market Place», som er Windows sin nettbutikk, der man kan handle applikasjoner, for både mobil, nettbrett og pc. Derfor ønsker Microsoft Norge å få en innføring i hvilke norske utviklere og applikasjoner, som er tilgjengelige på Market Place, ved å utvikle en egen versjon av nettbutikken, som vi har fått i oppgave å ta for oss. Side 58 av 155

10 2.3 Bakgrunn for oppgaven Høsten 2013 fikk vi introduksjon til informasjon om hovedprosjektet Bacheloroppgave. Vi fikk med oss, at valgmulighetene var enorme; siden vi stod fritt til å velge oppgave og oppdragsgiver helt selv. Vi skrev ned en liste med oppdragsgivere, som virket tiltrekkende. Vi ringte rundt og spurte, om det var noen som var villige til å ta inn 3 studenter for sin bacheloroppgave. Noen av de, vi tok kontakt med, var: Accenture, Bekk, Unit4Agresso, UNICEF, Google og diverse andre selskaper. Av de overnevnte var det kun UNICEF, som tok kontakt og viste interesse. Vi dro på et møte med Kyrre Andersen, som var ansvarlig hos UNICEF. Dette møtet ga oss inntrykket, om at de virkelig ønsket å utvikle et produkt i samarbeid med oss, men etter gjentatte forsøk på å nå UNICEF igjen, uten respons, bestemte vi oss for å fortsette å søke. Vi startet søket etter en oppdragsgiver allerede i september, og hadde søkt flere oppdragsgivere uten noe hell. Til sist bestemte vi oss bare for å ringe rundt og høre, om noen ville ta oss inn. I november kom vi i kontakt med Anita Samuelsen ved Microsoft Norge, som inviterte oss på et møte. Den 6. Desember undertegnet vi en kontrakt med Microsoft Norge AS og avsluttet endelig søket etter den perfekte oppdragsgiver. Da noe så stort som Microsoft ikke kunne toppes for oss. 2.4 Visjon og Mål Microsoft er, som sagt, verdens største programvareselskap 1, og derfor følte vi oss beæret, for at få en oppgave fra et slikt selskap. Det første vi klarte å tenke på, var at, dette er noe, vi skal jobbe hardt for, og at vi skal levere et godt resultat. Vårt mål var, at vi ønsket å fullføre og kunne gi oppdragsgiver et produkt, de kunne være fornøyde med, og samtidig et produkt, de kunne ønske å benytte seg av selv. Det var veldig lett å glemme, at dette også skulle være noe, vi selv skulle få karakter av, men dette så vi på som noe positivt, fordi vi hadde riktig innstilling; å gi alt for å nå det ønskede mål. Vår visjon har vært å kunne lære mer om utvikling innenfor Microsoft sitt rammeverk og sette oss inn i skyteknologien, for dette er det stor etterspørsel etter Side 59 av 155

11 3 Utviklingsprosessen I dette kapitlet vil det bli fortalt om, hvordan planleggingsfasen i prosjektet har vært. 3.1 Planleggingsprosessen Planleggingen av prosjektet begynte etter at vi i tidlig desember 2013, fikk utlevert kravspesifikasjon av vår oppdragsgiver. Denne kravspesifikasjonen hadde noen punkter, oppdragsgiveren ønsket vi skulle fokusere på: - Kvalitetsstandard - Design - Scrum - Responstid Annet enn disse 4 punktene, stod kravspesifikasjonen åpen til forandring og selvtolkning av, hvordan vi ønsket å løse oppgaven. Dette var vår første konflikt, som studenter har vi alltid fått utlevert en oppgave, med klare instruksjoner på hvordan oppgaven skal løses. Det er retningslinjer, hjelp og mulighet for å se liknende eksempler. Dette skulle da bli første gang, der vi skulle løse en ganske så stor oppgave på egenhånd, uten erfaring. Det vi visste om oppgaven generelt, var at Microsoft Norge ønsket en applikasjon med en administrasjonsstyrt «back-end løsning», og en «front-end», som vil liste ut applikasjoner, som er utviklet av norske utviklere. Det lå også et ønske om «gamification» av applikasjonen, men utseendet og alle andre detaljer var opp til oss å bestemme. Etter utlevering av kravspesifikasjonen, ønsket vi å gjøre litt «research» på punktene, som var nevnt derunder. Det viktigste punktet, vi måtte fokusere på, var SCRUM. Dette var et begrep, vi hadde hørt om i faget systemutvikling, men ikke noe vi hadde prøvd ut i praksis før. Grunnen til at dette var et viktig punkt, var fordi dette var en bestemt måte å arbeide på, som krevde en god del planlegging og møter. Vi gikk igjennom kravspesifikasjonen i juleferien for å møte opp forberedt til semesterstart. Med litt «research» av kravspesifikasjonen, fikk vi et bredere bilde av oppgaven, men allikevel følte vi oss ikke noe klokere på f.eks. hvordan man planlegger SCRUM. Planleggingsprosessen for prosjektet AppenesApp var veldig lang og vanskelig, siden vi måtte forstå hvordan, vi skulle bruke SCRUM i praksis. Det var ikke lett å lage «product backlog items», fordele Side 60 av 155

12 oppgaven i sprinter, og lage en plan over, hvordan vi skulle få til å utføre prosjektet med et bra sluttresultat. Vi bestemte oss for å bare kaste oss selv i uti det og fokusere på å få gjort noe, samtidig som vi ønsket å lære om dette. Uheldigvis bestod ikke planleggingsfasen av bare planlegging av prosjektet. Vi skulle også levere en forprosjektrapport, og i tillegg til det hadde gruppen eksamen i februar, som måtte fokuseres på. Med mye å lære på veldig kort tid, var det mye som måtte godkjennes, vi trengte bekreftelser på, at det vi gjorde, var riktig, for å kunne vite, at vi var på rett vei. Vi kom frem til, at en sprint skal vare i ca. 14 dager, og satte at arbeidskapasiteten per person på gruppen var 3 timer per dag, som minste kapasitet. Dette skulle da føres opp på Visual Studio Online 2, et verktøy vi også måtte bruke tid på å bli kjent med. Med nesten 8 ukers planlegging av Scrum, skulle vi også tenke på, hvordan vi ønsket å sette opp produktet, her trengtes det ER-modeller, UseCase og Sekvensdiagrammer til hjelp. All erfaring med både ER-modeller, UseCase og sekvensdiagrammer har vært relatert skoleoppgaver tidligere, der disse skulle lages for eksisterende løsninger. Når vi, med ingen aning om hvordan produktet skulle bli, måtte sette oss ned å planlegge dette, kom vi på, at det kanskje er lurt å lage skisser og finne ut av, hvordan vi ønsket å bruke systemet. Skisser, UseCase og Sekvensdiagrammer som ble laget under planleggingsfasen finnes under vedlegg. Etter hvert som vi skjønte at, dette kunne bli en krevende oppgave på grunn av manglende erfaring og kunnskap om utvikling av et slikt produkt, innså vi veldig raskt, at det var lurt å spørre om å nedprioritere en mulig Windows Phone applikasjon. Vi ønsket først å fremst å kunne få til en løsning som var funksjonell, og at vi i det hele tatt kunne få lagt frem et produkt. Det var selvfølgelig aktuelt å begynne å planlegge, hvordan webløsningen skulle være. Her tok vi noen runder på internett og søkte litt inspirasjon. Vi listet opp det, vi ønsket, webapplikasjonen skulle ha av funksjonalitet og begynte å tenke litt på utformingen. Før vi begynte på noe annet, hadde vi også fått et ønske fra Microsoft om å skrive en blogg, som ville fungere på samme måte som en prosjektdagbok, men denne ville være offentlig og ville gi både oss og Microsoft et godt utbytte av, hvordan vi trivdes med det vi gjorde, og hvordan de kunne forbedre seg selv. Bloggen ( har vært en veldig viktig del av vår hverdag. Vi har ikke vært flinke nok til å oppdatere denne, men de gangene vi har oppdatert denne, har det handlet om våre interne møter, møter med Microsoft og hvordan vi føler vi har hatt det. 2 Kapitel 8, Visual Studio Online Side 61 av 155

13 Dessverre ble planleggingsprosessen vår mye lengere, enn det vi selv ønsket, den skulle bli. Planleggingsfasen strakk seg fra begynnelsen av desember, til slutten av februar. Først ved begynnelsen av mars kom vi i gang med ordentlig koding. Vi vil påstå, at vi kunne klart å komme i gang tidligere, hvis det ikke hadde vært for mye usikkerhet og lite kjennskap til arbeidsmåten. 3.2 Produksjonsfasen En sprint er en bestemt tidsperiode, med bestemt arbeidsmengde. AppenesApp har hatt totalt 5 sprinter, med hver sprint på ca dager hver. AppenesApp Sprint 1 begynte 17.Februar og var satt til den, 28.Februar. Siden vi ikke hadde noe tid eller måte å teste ut, hvordan en sprint fungerer, ble dette en virkelig og en «prøve-sprint» for oss. En sprint inneholder en liste med «Product backlog items» med «Tasks», som skal gjøres innen fristen til sprinten utløper. Visual Studio Online beregner hvor mange timer sprinten behøver, ut ifra hvor stor arbeidskapasitet, som er blitt lagt inn på hver av gruppemedlemmene. Vi hadde for eksempel på vår første sprint lagt inn, at arbeidskapasiteten per dag for en person på gruppen er 6,5 timer. Med helgene fri og 7 arbeidsdager totalt, var vår første sprint beregnet til 45,5 timer per person, det vil si 136,5 timer totalt for hele sprinten. «Product backlog items» består av bestemte underoppgaver, «tasks». Disse arbeidsoppgavene får en tidsramme, altså en frist å løses på, som skal utgjøre en hel sprint. Timeantallene, som settes på oppgavene, skal med andre ord gjøres innenfor den tidsrammen en hel sprint er satt på, i vårt tilfelle 136,5 timer. Ut ifra disse timene, genereres også en ideell «Burndown chart», på neste side ses «burndown charten» for vår første sprint. Side 62 av 155

14 Skjermbilde 1 - Burndown chart - Sprint 1 Dette er en graf Visual Studio Online genererer, som viser hvordan den ideelle arbeidsmengden skal løses med best resultat, ut ifra de timeantallene som er satt. På bildet over ser vi at den ideelle utviklingen av sprint 1 vises med en svart strek, og det blå område viser, hvordan den reelle utviklingen var. En perfekt sprint er, når det blå område følger med den svarte streken. For å se utviklingen av våre sprinter fra 1 5 se vedlegg: Sprint Reviews. Vi planla våre sprinter med et møte, som kalles «sprint planning meeting». Et planleggingsmøte holdes med en utvalgt Scrum-master, og som regel med produkteier tilstede. I vårt tilfelle ble det slik at «sprint planning meeting» ble holdt uten produkteier tilstede, men han fikk våre møtereferat tilsendt per e-post. I et slikt møte snakker man kort om hvilke forventninger, man har til sprinten, hvilke «Product backlog items» skal være med, og hvordan man løser oppgaven innen gitt tidsfrist. Det holdes også «sprint review» etter at en sprint er fullført, og her skal man snakke om ting, som har gått bra, dårlig og ting, man skal unngå eller forbedre. I tillegg til at vi skulle diskutere forbedringer og finne ut av hva som gikk bra, så skulle vi også finne ut av hva «jeg» har gjort bra eller dårlig, hva «teamet» har gjort bra eller dårlig og hva som er godt eller vondt i den generelle verden. Denne skal være anonym, selvfølgelig. Dette er fordi, ingen av de andre i gruppen skal kunne «etterlikne» den andre, eller bare kunne være ærlig om, hva som kan forbedres. For hver «Sprint review» lagde vi et skjema på OneNote og fylte det ut sammen og har skrevet logg og referat om hva som har vært gjort underveis. Disse finnes under vedlegg: «Sprint Reviews». Side 63 av 155

15 De første 2 sprintene var de to vanskeligste og de to mest krevende sprintene. Disse ble ikke nådd til tide, det er fordi vi overvurderte vår kapasitet og undervurderte oppgavene. Det var en vanskelig prosess å finne en balanse mellom oppgavene, og hvor mye vi selv rekker. Vi skjønte, at til tross for, at vi mener, vi kan jobbe 6,5 timer helt målrettet og fokusert med en bestemt oppgave, er det ikke nødvendig, at man allikevel skal klare å kunne løse denne. Vi hadde ikke regnet med toalettbesøk, spisepauser, slappe dager og bare dager, der man er umotivert. I tillegg til det hadde vi ikke tatt høyde for problemer, som kan oppstå i koden, mens man programmerer. Det var først til den 3 sprinten at vi begynte å forstå hvordan SCRUM og sprinter henger sammen. Her hadde vi satt ned vår kapasitet til 4 timer for å kunne fokusere på feil, som dukket opp og klare å fullføre «backlog items», som vi har satt opp. Videre kan man lese mer om, hvordan hver av sprintene var under vedlegg: «Sprint Reviews». 3.3 Testing Siden dette var en veldig stor oppgave, der vi hadde 2 applikasjoner å utvikle, fikk vi ikke tid til å teste. Produkteier var klar over, at dette kom til bli en stor oppgave, så testing var ikke en prioritet, men dette var et ønske fra vår side. Hvis vi hadde hatt mer tid, så hadde vi enhetstestet produktet. Side 64 av 155

16 4 Kravspesifikasjon I dette kapitlet vil vi ta for oss kravspesifikasjonen, som finnes under vedlegg som Kravspesifikasjon 2.0, og hvordan vi har nådd målene i forhold til produktet. 4.1 Sammenligning av produkt og krav Vi har under hele prosjektet prøvd å forholde oss til kravspesifikasjonen. Vi mener, at vi har utfylt de fleste krav. Nettbrett applikasjonens brukergrensesnitt derimot er ikke helt etter Microsofts designprinsipper, fordi det har vært fokus på det funksjonelle igjennom hele prosessen. Men da funksjonaliteten på begge applikasjonene tilfredsstiller kravspesifikasjonen, er det enklere å jobbe med brukergrensesnittet. Etter samtale med ekstern veileder, kom vi frem til at utseendet kan jobbes med videre, og derfor er det ikke så farlig, at utseendet ikke tilfredsstiller kravspesifikasjonen, da den kan jobbes med etter innlevering. Hvis vi hadde hatt mer tid hadde vi ønsket å utvikle Windows Phone applikasjonen, derutover hadde vi lagt til en kommentar-funksjon på applikasjonen, så det vil være mer interaksjon med brukere. Side 65 av 155

17 5 Scrum Vi syntes, det var vanskelig med Scrum på starten, da vi ikke var vant til å planlegge oppgaver. Det tok oss 2 måneder, før vi kom inn i Scrum. Så de første 2 burndowns var ikke veldig gode. Etter hvert som vi ble vant til å planlegge gikk prosessen ganske bra, som de andre burndowns viser. Siden Scrum er en agil-metode å arbeide på, har dette vært veldig bra for oss som førstegangsutviklere, da denne arbeidsmåten gjør rom for endring. Det har vært interessant for oss å prøve ut Scrum, og vi er veldig fornøyde med at oppdragsgiver hadde Scrum, som et krav i kravspesifikasjonen, fordi dette er en etterspurt utviklingsmetode i arbeidsmarkedet. Vi føler, at vi står sterkere enn før, fordi vi har tilegnet oss litt erfaring med Scrum. 5.1 Risikoanalyse Risiko Konsekvens Tiltak Sykdom Oppgavene blir ikke gjort Dele oppgaven til resterende medlemmer Forsovelse Utløpelse av Azure Lite tilstedeværelse Gratis Passasjer Dårlig start på dagen, Dårlig humør gruppen Applikasjonen fungerer ikke som den skal Gruppemedlemmer er ikke oppdatert og man må bruke unødvendig tid på å fylle medlemmene med informasjon. De andre gruppemedlemmer for mye å gjøre og gratis passasjeren får kreditt for noe vedkommende ikke har gjort Gruppemedlemmer skal legge seg tidligere å møte opp akkurat som de skulle vært på jobb Sende mail til veileder hos Microsoft om å få sendt en Azurepass Planlegge fraværet tidlig, slik at det ikke må brukes mer tid til å formidle informasjon. Gruppemedlemmet blir kasta ut Skrive dagbok hvor sannheten står Advarsel Side 66 av 155

18 Nedgangstid på databasen Misforståelser i gruppen Mangle arbeidsrom Vi får ikke hentet ut informasjonen, som er lagret på databasen Oppgaver blir ikke gjort Dårlig kommunikasjon Bortkastet tid på å finne sitteplass med stikk-kontakt Informere ekstern veileder og forskyve sprinten Snakke ut om problemene Booke rom i forkant Under prosjektperioden har det vært noe sykdom, og dette har vi løst ved å dele ut oppgavene til de resterende gruppemedlemmer, eller jobbet hjemme fra over Skype. Azure har utløpt og vi har hatt problemer med å få et nytt Azurepass, som virker for å aktivere abonnementet. Vår eksterne veileder fant en bra løsning på dette, og dette resulterte dessverre, i at vi må sitte å vente på å få en løsning på dette. Vi har hatt misforståelser i gruppen, og dette har gått utover motivasjonen i gruppa. Dette fikk vi løst ved å snakke ut om problemene. Derutover har vi hatt problemer med å finne arbeidsplass, dette har ført til at vi har bortkastet flere timer på å finne et sted å sitte på skolen. Vi har løst dette de fleste gange ved å booke rom i forkant, men det var ikke alltid mulig å booke rom, selv om man var tidlig ute. Side 67 av 155

19 6 Teknisk arkitektur Dette prosjekt er bygget opp med N-lagsarkitektur, noe som gjorde det enkelt å fordele de ulike lagene av prosjektet. Prosjektet består av både nettbrett applikasjon og webapplikasjon. Nettbrett applikasjonen har brukt en typisk Model-View-ViewModel(MVVM) lagdeling, mens webapplikasjonen har brukt Model-View-Controller(MVC). Lagdelingen av hele prosjektet har gjort det enklere for oss å se, hvordan de ulike komponentene henger sammen. 6.1 N-Lagsarkitektur(hele løsningen) Skjermbilde 2 - N-lagsarkitektur Vår N-lags arkitektur består kun av de lagene ovenfor. Tjeneste laget og «Cross-Cutting laget» har bare blitt påført uten å ha blitt brukt. Vi mener N-lagsarkitekturen var hjelpsom med å skille de ulike komponentene i hele prosjektet. Det tok tid til å forstå, hvor de ulike komponentene skulle være. Som nevnt tidligere ble hele løsningen lagdelt etter N-lagsarkitekturen, samtidig som at webapplikasjonen ble bygget opp med MVC og at nettbrett applikasjonen ble bygget opp med MVVM. 6.2 MVC (Webapplikasjon) I webapplikasjonen har vi brukt lagdelingen Model-View-Controller(MVC), da dette var den letteste måte å dele en webapplikasjon på. Dette var ikke noe problem siden vi tidligere har hatt erfaring med MVC fra faget webprosjekt. Side 68 av 155

20 Skjermbilde 3 - Model View Controller fra AppenesApp 6.3 MVVM (Nettbrett applikasjon) Model-View-ViewModel(MVVM) ble brukt til å bygge opp nettbrett applikasjonen vår. Vi syntes, at MVVM var nyttig for vår applikasjon, men samtidig vanskelig å forstå. Det tok oss tid med å komme oss inn i det. Til å starte med visste vi ikke at vi kunne bruke MVVM, og dette førte til, at det ble vanskelig å få frem elementene ved hjelp av «databinding». Så det endte opp med at vi fordelte lagene i nettbrett applikasjonen og fikk til MVVM. Skjermbilde 4 - Model-View-ViewModel fra AppenesApp På neste side ses 2 tegninger: Den første viser, hvordan vi har lagdelt løsningen og den andre består av hvordan lagdelingen egentlig skulle ha vært. Side 69 av 155

21 Bildet under viser hvordan vi har gjort lagdelingen i vårt prosjekt Skjermbilde 5 Arkitekturen for AppenesApp Bildet under hvordan lagdelingen egentlig skulle ha vært. Skjermbilde 6 - N-lagsarkitektur Feilen som vi gjorde var, at vi plasserte elementene, som skulle være i datalaget i forretningslaget. Side 70 av 155

22 Vi syntes, det ble mye lagdeling gjennom hele prosjektet. Dette er et såpass stort prosjekt, at vi ble nødt til å dele opp slik som vi har gjort, for å få bedre oversikt. Lagdelingen var frustrerende på starten, fordi vi ikke skjønte, hvordan lagene skulle henge sammen. Det ble lettere, etterhvert som vi satt oss inni det. Tilslutt så fant vi ut at dette var essensielt for at hele prosjektet skulle fungere sammen i en helhet. Vi vet dessverre ikke om det er en bedre lagdeling, enn det vi har brukt, siden vi har fulgt det vi fikk vite av Microsoft. 6.4 ISO-standard Vi har i dette prosjektet tatt i bruk ISO-standarden for programvareutvikling. Denne standarden har retningslinjer på, hva som skal tas hensyn til når man utvikler applikasjoner. Vi ble bedt av veilederen vår hos Microsoft om å bruke denne standarden. Vi syntes, at denne standard har veiledet oss til å føre applikasjonene i en riktig retning med tanke på funksjonalitet, sikkerhet, brukervennlighet og opprettholdelse av applikasjonene. Side 71 av 155

23 7 Design Da vi fikk dette prosjektet hadde vi noen ideer på hvordan applikasjonen kunne se ut, men vi var usikre på, hva vi skulle følge som retningslinjer. Vi fikk da vite av vår veileder hos Microsoft, at de hadde retningslinjer på, hvordan en applikasjon skal bygges opp. Disse retningslinjene var til stor nytte. Microsoft ønsker, at applikasjonene deres skal være simple samt elegante, så vi måtte selvfølgelig tilpasse oss etter deres ønske. I starten av prosjektet lagde vi skisser til «storyboard» for hvordan vi ønsket at applikasjonene skulle se ut, disse kan finnes under vedlegg: Skisser. Vi tenkte, at det var viktig å bruke så mange farger med tanke på at dette skulle være applikasjoner, som skal fremvise mange forskjellige logoer og bilder. For webapplikasjonen var det ikke noe særlig retningslinjer på, hvordan nettstedet skulle se ut. Her har vi bare valgt en mal som fulgte med i.net. Grunnet dette står vi bak utseende av webapplikasjonen. Vi har prøvd å gjøre webapplikasjonen og applikasjonen identiske, altså med tanke på utseendet og dets farger. Eneste måten å fremme dette på, var ved å velge riktige farger. Vi har brukt svart og hvitt for begge applikasjonene, fordi det vil være mange fargerike applikasjoner, som listes ut. For å unngå at det skal være altfor mange farger, så har vi valgt to enkle farger som svart og hvitt. Vi er fornøyde med utseendet med tanke på så tidspresset, vi har hatt. Vi er klar over, at utseendet kunne ha blitt bedre, hvis vi hadde hatt tid hadde vi litt mer på utseendet, men funksjonalitetene til applikasjonene har vært første prioritet. Webapplikasjonen skal brukes av Microsoft Norge internt, og derfor trengs det ikke å jobbes noe særlig med utseendet av denne, men nettbrett applikasjonen derimot trenger noe finpussing. Vi vil prøve å finpusse den før den leveres til produkteier, fordi den skal ut på «Marketplace». Vi utført en demonstrasjon av produktet til produkteier, og han er enig i at applikasjonen bør finpusses før den lastes opp på «Marketplace», men utseendet til webapplikasjonen er de tilfreds med. Side 72 av 155

24 8 Teknologi & Verktøy 8.1 XAML XAML er et språk utviklet av Microsoft, og benyttes for å definerer objekter i.net rammeverket. Vi har brukt XAML for utvikling av nettbrett applikasjonen, og dette har ikke vært lett. Vi hadde ingen erfaring med XAML, og derfor tok dette lang tid for oss å sette oss inn i, men med tiden har vi lært å bruke XAML og det har blitt enklere å forstå, hvordan det henger sammen. 8.2 JSON JSON brukes til datautveksling. Vi har i prosjektet brukt JSON til å få informasjon fra databasen ved hjelp av API til nettbrett applikasjonen. Dette har vært veldig nemt å lære. 8.3 HTML & CSS Både HTML og CSS er noe vi har hatt kjennskap til fra før, og det var ikke noe problem å jobbe med. 8.4 Bootstrap Bootstrap er et rammeverk for front-end utvikling, som muliggjør responsivt design på en enklere måte. Vi har i prosjektet brukt dette rammeverk til webapplikasjonen, hvilket betyr at vår webapplikasjon tilpasser seg, alt etter hvilken skjerm som brukeren har. 8.5 Entity Framework Entity Framework(EF) er et objekt relasjonell rammeverk (ORM). Dette gjør det mulig for utviklere av.net til å skape relasjonelle data, altså gjenstander, som er domenespesifikke. 3 Vi har brukte EF under hele prosjektet, før vi skulle overføre det til Azure, dette fordi databasen er lettere å håndtere, når man er i gang med utviklingen Side 73 av 155

25 8.6 Visual Studio Online Visual Studio Online(VSO), tidligere kalt Team Foundation Server(TFS), ble lansert i 2012 av Microsoft. Det er et online verktøy for administrering og organisering av smidig systemutvikling, altså et prosjektstyringsverktøy, i tillegg til at det har et kildekontroll system. 4 Dette er første gang, vi skulle bruke VSO. Vi opplevde VSO på en positiv måte, og dette har vært veldig hjelpsomt med tanke på planlegging og utførelse av SCRUM. VSO ga oss en oversikt over arbeidsoppgavene vi skulle løse, samt ga oss kildekontroll for løsningen. Det tok oss tid for å lære VSO på starten av prosjektet, men med engang vi forsto hvordan tingene fungerte, kom vi hurtig i gang. Vi hadde noen problemer med VSO med opplasting av løsningen grunnet nedetid, men ellers har det fungert knirkefritt. 8.7 Microsoft Powerpoint 2013 Microsoft Powerpoint brukes til å lage bildepresentasjoner, som skal vises på en skjerm eller prosjektor. Man kan lage, redigere og fremvise presentasjoner med tekst, bilder, lyd og video ved hjelp av dette programmet. 5 Microsoft Powerpoint er en del av Microsoft Office-pakken. I prosjektet, AppenesApp ble dette programmet brukt til å lage «storyboards», som kunne kobles til «product backlog items» i Visual Studio Online. 8.8 Microsoft Visual Studio 2013 Visual Studio er Microsofts integrerte utviklingsmiljø (IDE). Ved hjelp av dette programmet kan man utvikle programmer for Windows plattformer, som Windows Forms, websider, Silverlight og Windows mobile enheter. Visual Studio støtter kildekontrollsystemer og forskjellige programmeringsspråk, som f.eks. C#, Visual C++ og Visual Basic, derutover støttes også HTML, XML, CSS og JavaScript. Dette programmet må kjøpes, men er gratis for alle studenter med tilgang til DreamSpark Side 74 av 155

26 Dette er et utviklingsverktøy, som vi tidligere har brukt i faget Webapplikasjoner, derfor tok det ikke lang tid for oss å sette oss inn i det. Derimot har det vært nye egenskaper som vi har kunne tilegne oss. 8.9 Microsoft Blend 2013 Microsoft Blend for Visual studio er utviklet av Microsoft. Microsoft Blend er et designverktøy inkludert i Visual Studio 2013, som en hjelp for å lage brukergrensesnitt til applikasjoner Photoshop CS6 Photoshop er laget av Adobe Systems og er et viderekommen bilderedigeringsprogram. Dette programmet har blitt brukt til å lage logo og badges i prosjektet Google Calendar Google Calendar, som selvforklarende, er en gratis kalender laget av Google, men for å benytte seg av kalenderen, må man ha en googlekonto. Med denne kalenderen er det mulig å ha flere kalendere, og se disse i samme «view» og dele kalendrene. Alt blir lagret online og er derfor praktisk, siden du kan få se kalenderen din, uansett hvor du er, og samtidig kan kalendrene synkroniseres med telefonen, så du har den tilgjengelig på telefon. Denne kalenderen har vi brukt til å organisere hvilket grupperom vi hadde for dagen, møter med veilederen, fri dager og jobben ved siden av skolen, så at alle i gruppen kunne oppdatere seg om hvor folk er og hvor vi bør være Microsoft Azure - Skyteknologi Microsoft Azure er Microsofts skyteknologi. Nettskyen gjør det mulig å bygge, distribuere og administrere applikasjoner og tjenester gjennom et stort nettverk av datasentre, administrert av Microsoft. Backenden for AppenesApp ligger på nettskyen. Dette har vært veldig vanskelig, da vi bare hadde prøvetid på denne, som varte 3 måned. Etter dette må vi få tildelt Azurepass fra ekstern veileder, for at få aktivert en ekstra måned, etter denne ekstra måneden var det ikke mulig å forlenge gratis tid på Azure. Azure er i bunn og grunn lettanvendelig, men det eneste som har gitt oss hodebry er, at det var litt problematisk å få gratis prøve tid på hele bachelor perioden. Side 75 av 155

27 8.13 Google Docs Google Docs er en gratis online kontorpakke laget av Google. Pakken inneholder tekstbehandling, regneark og presentasjoner, og tillater brukere å opprette og redigere dokumenter online. Det spesielle ved Google Docs er at det er mulig for flere personer å samtidig redigere i et dokument, og endringene vises «real-time», altså med en gang for de andre brukerne. 6 Dette har blitt brukt i starten av prosjektet til forprosjekt rapporten og andre små dokumentskrivingsoppgaver OneNote 2013 OneNote er laget av Microsoft og er et program for notater og informasjon, som samles et sted. På OneNote er det mulig at flere kan få adgang og skrive i notatene, og det lagres online, så du kan få tak i det hvor som helst. Det krever, derimot ikke at du har internett tilgang for å skrive, da man kan skrive i offlinemodus og synkronisere senere. Under prosjektet AppenesApp har dette programmet blitt benyttet til å ta notater under møter og holde orden i all informasjon, som f.eks. kilder til eksempler på kode og dokumentasjon Microsoft Word 2013 Microsoft Word er et tekstbehandlingsprogram produsert av Microsoft. Microsoft Word er en del av Microsoft Office-pakken. Dette programmet har blitt brukt for dokumentering Dropbox Dropbox er et fildelingsprogram, som lagrer filene i skyen, hvor man kan dele filer med andre eller ha mapper for seg selv. Dropbox har kontroll på versjonen, slik at det er lett å gjenopprette en gammel utgave. Vi har brukt Dropbox til å dele og lagre dokumenter og tegninger, som ikke var en del av kildekoden Side 76 av 155

28 8.17 Skype Skype er et IP-telefoni dataprogram, hvor det er mulig å ha gruppesamtale med video. Dette er praktisk fordi du kan dele din skjerm med de andre. Vi har hatt noen møter over internettet, hvor vi har benyttet oss av Skype. Dette har vært et alternativ, de gange gruppemedlemmene ikke har kunne møte opp grunnet sykdom eller annet Facebook Facebook er et sosialt nettverk online, hvor brukere kan kommunisere med hverandre med en profil, lage grupper og sider. Utover mobil har vi hovedsakelig hatt kontakt over Facebook, da dette gjorde det mulig å ha gruppesamtaler Wordpress Wordpress er et verktøy for å lage blogger. Vi har brukt Wordpress til å lage bloggen, der vi har blogget om vår reise med Microsoft. Vi har skrevet om hverdagen vår og om de ulike teknologiene, som har blitt brukt, og hva som var det gode og dårlige med det. Side 77 av 155

29 9 Konklusjon I slutten av 2013 startet vi å planlegge prosjektet, vi så for oss at vi kanskje skulle utvikle noe i.net, da vi var i gang med faget Webapplikasjoner, og hadde lært mye om.net. Dette vekket stor interesse hos gruppen, vi prøvde å få et prosjekt innenfor.net, men det viste seg at det ikke var så lett å finne en oppdragsgiver, og derfor kunne vi heller ikke være kresen på hvilket språk vi ønsket å utvikle noe i. Vi endte opp med å få vår store drøm oppfylt i form av både oppdragsgiver og utviklingsspråk. Microsoft ga oss en utfyllende og krevende oppgave. Denne oppgaven gikk ut på å lage et «norsk» tillegg til den eksisterende «store». Selv om denne oppgave virket stor, følte vi at denne oppgaven ville gi oss et spring i IT-karrieren, da dette var et stort selskap, samtidig som vi trodde, det var en uoppnåelig drøm. Vi gjorde vårt beste for å nå så langt med oppgaven som mulig, vi nådde å bli ferdige med det funksjonelle. Det har ikke vært enkelt, men vi føler, vi har nået det vi satte for oss i starten av prosjektet. Det mangler noe oppusning på brukergrensesnittet, men dette vil vi ordne før vi leverer det ferdige produkt til oppdragsgiver, fordi vi ønsker å levere et fullstendig produkt. 9.1 Gruppesamarbeidet Dette er en gruppe, som har kjent hverandre i lang tid, og samarbeidet i gruppen, har alltid fungert bra. Dette prosjektet har vært svært betydningsfullt for oss, da dette var en ganske stor og krevende oppgave. Vi følte, at en slik mulighet er noe vi ikke ønsker å gå glipp av, derfor ville vi 3 sammen, ta på oss denne utfordringen. Vi var derfor nødt til å gi alt for å kunne fokusere på oppgaven i hele prosjektperioden. Det har gjennom hele prosjektet vært stort engasjement i gruppen, medlemmene har vært initiativrike og ofret mye av deres egen fritid, for å få denne oppgaven løst på en best mulig måte, også mange av helgene har blitt brukt på å sitte igjen med arbeid. Det har oppstått veldig få problemer internt i gruppen, men som alle andre grupper har vi også hatt vår del av diskusjoner og argumenter. Ingen på gruppa bærer heldigvis nag til hverandre, og konfliktene har blitt løst ved å kommunisere og snakke åpent om problemene som har oppstått. Det har vært til vår fordel, at vi har kjent hverandre på forhånd. Det har gjort det enklere for gruppen å kunne snakke til hverandre, stå for sine meninger og være med på å diskutere, hva som er best for produktet. Det er også en fordel at gruppen kjenner til hverandres svake og sterke sider, Side 78 av 155

30 som har kommet i bruk under diverse situasjoner, der man f.eks. kan bruke en av medlemmene til å si sine meninger. Dette prosjektet har utviklet oss, gjort oss sterkere, og i stand til å takle situasjoner som kan oppstå i arbeidslivet. Prosjektet har lært oss å kjenne hverandre, og hvordan du selv er som person. Siden vi har kjent hverandre lenge så har det vært enkelt i dette prosjektet, men det vil nok være annerledes når vi skal ut i arbeidslivet og bli kjent med nye folk. Vi tar med oss alle erfaringer vi har gjort under prosjektperioden, både positive og negative, for å kunne stille sterkere og kunne bruke erfaringen vi har gjort oss, til noe nyttig. Side 79 av 155

31 9.2 Utfall AppenesApp har resultert i et sluttprodukt, som ønsket fra oppdragsgiver. Det eksisterer en funksjonell webapplikasjon for administratorer og det finnes en "front-end", i form av en nettbrett applikasjon for Windows 8.1. Utviklingen av produktet har overgått all forventning, med tanke på at vi var bekymret for å ikke klare å nå prosjektet i tide. Erfaringsmessig hadde vi ingen anelse om hva utfallet av prosjektet kommer til å bli. Vi var ganske sikre på, at vi skulle klare å få på plass en webløsning i C# og.net, siden dette er noe, vi på forhånd hadde jobbet litt med, i faget webapplikasjoner. Det vi derimot ikke var sikre på var, om vi kommer til å klare, å lage nettbrett applikasjonen, i XAML. Vi har aldri før kodet en eneste linje i XAML, men allikevel klart å få til å lage en applikasjon. Dette er noe vi er veldig stolt av selv, og noe vi vet vår oppdragsgiver er stolt av. Dette har vi fått konkret tilbakemelding på av vår eksterne veileder, som mente, at han er utrolig imponert over, at vi har klart å tilegne oss så mye nytt, på veldig kort tid. Til tross for at applikasjonen fyller alle krav om funksjonalitet og produktet kan vises ved demoer, har oppdragsgiver klart og tydelig sagt ifra om at designet på produktet må finpusses. Alt i alt er oppdragsgiveren fornøyd med utfallet av produktet, men den trenger litt finpuss, før det eventuelt kan legges ut til nedlastning på Marketplace. Dette er også noe Microsoft har sagt, at de veldig gjerne ønsker å få applikasjonen ut på markedet og derfor er det veldig viktig at produktet ser og er fullstendig og presentabelt. Derfor vil vi som en gruppe fortsette å jobbe videre på applikasjonen, selv om innleveringsfristen utløper. Vi ønsker på samme måte som Microsoft, å kunne tilby en ny og unik applikasjon, og derfor er det veldig viktig for oss å kunne få frem et godt resultat. Vi er personlig, veldig stolte av det vi har fått til og ser ikke bort ifra at, det kan lønne seg å gi litt ekstra. Side 80 av 155

32 10 Kilder what-are-3-layer-n-layer-mvc-mvp-and-mvvm_200.html Side 81 av 155