SLUTTRAPPORT HOVEDPROSJEKT VÅR 2013

Størrelse: px
Begynne med side:

Download "SLUTTRAPPORT HOVEDPROSJEKT VÅR 2013"

Transkript

1 SLUTTRAPPORT HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD GRUPPE 36 FORFATTERE: N O RDENGEN, THOMAS LA R S E N, GLE N R UB E N E. S TEEN, SEB AS T IE N -J EROME

2 PROSJEKT NR Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo HOVEDPROSJEKT TILGJENGELIGHET Begrenset Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Knowit CvReg Tilbud DATO ANTALL SIDER / BILAG 117 PROSJEKTDELTAKERE Glenruben Engen Larsen s Thomas Nordengen s Sebastien-Jerome Steen s INTERN VEILEDER Steinar Johansen Tor Krattebøl OPPDRAGSGIVER Knowit KONTAKTPERSON Sigmund Nilssen SAMMENDRAG Knowit er et konsulentfirma med kontorer over hele Norge. Selskapet har nylig utviklet et nytt web applikasjon for intern bruk som het CvReg. Målet med applikasjonen er å enklere håndtere CV-ene til utviklerne som jobber for selskapet. Knowit ønsker å få applikasjonen videre utviklet for å kunne utvide bruket av CvReg i selskapet. Målet for oppgaven er å utviklet en ny modul, CvReg Tilbud, som skal gi mulighet for selgere å legge til nye oppdrag, eller tilbud, fra klienter i en sentral database, og enklere tildele utviklere til de forskjellige tilbudene. 3 STIKKORD Database Web applikasjon Grails

3

4 INNHOLDSFORTEGNELSE HOVEDPROSJEKT... I. SAMMENDRAG... II. PRODUKTRAPPORT... III. PROSESSRAPPORT... IV. VEDLEGG... V.

5 II. SAMMENDRAG Gruppen Gruppen er satt sammen av tre tredje års-studenter fra Høgskolen i Oslo og Akershus. Thomas Nordengen studerer Informasjonsteknologi, Glenruben Engen og Sebastien-Jerome Steen studerer Anvendt datateknologi. Ingen av gruppemedlemmene har jobbet sammen før eller kjente hverandre før hovedprosjektet. Gruppen ble mer eller mindre tilfeldigvis sammensatt etter i høsten 2012 etter noen raske samtaler i felles e-postgruppen til faget. Oppdragsgiveren Knowit er et ledende konsulentfirma i Skandinavia. Knowit Norge består av 1800 IT spesialister med kontorer over hele landet som har noen av landets største selskaper som kunder. Til prosjektet stilte Knowit med 3 veiledere: Øyvind Marthisen, Sigmund Nilssen og Jon Marius Håkedal. Alle tre er erfarne IT konsulenter med flere års erfaring innenfor drift og utvikling av IT systemer. Gruppen fikk kontakt med oppdragsgiveren gjennom en privat kjenning i firmaet. Vi la frem premissene for bacheloroppgaven for han og etter diskusjon innad i firmaet fant de en oppgave de mente at ville passe for oss. Innen en uke hadde vi vært på innledende møte med Knowit, og blitt enige om en preliminær struktur på oppgaven. Bakgrunn for prosjektet Knowit startet å utvikle CvReg med to mål i sikte: det første var for å lage en sentral CV database som var enklere å håndtere enn en fellesmappe med Word eller PDF dokumenter, det andre var å la utviklerne prøve å lage en applikasjon i Grails - dette er det første prosjektet avdelingen gjør i dette rammeverket, så mye av motivasjonen for prosjektet er å bygge kompetanse blant de ansatte i moderne teknologier for utvikling. Selve arbeidet på CvReg startet som et sommerprosjekt i 2012 og når prosjektet viste seg å være vellykket ble det rullet ut innad i Oslo-avdelingen til Knowit for å koordinere CV-ene til sine cirka 400 ansatte.

6 Et ønske fra salgsdivisjonen i bedriften var muligheten til å sette sammen en gruppe ansatte, via deres registrerte CV-er i systemet. Denne sammensetningen av CV-er kalles et Tilbud, som da representerer et planlagt prosjekt. Dette gjøres for å få en oversiktlig måte å samle de personer som skal inkluderes i et fremtidig oppdrag. Introduksjon til CvReg Tilbud Med mulighet for å utvikle CvReg videre så var det viktig å definere konkrete mål for prosjektet som kunne utføres i løpet av våren. Knowit hadde vurdert å implementere en ny modul for å samle CV-er i pakkeløsninger som skulle brukes til planlegging av fremtidige prosjekter. Utviklerne på Knowit kom aldri så langt med å implementere Tilbud siden inn i CvReg applikasjonen og vi ble tilbudt å utvikle denne modulen for dem. Vi ønsker å takke veilederne våre: Steinar Johansen og Tor Krattebøl, arbeidsgiveren Knowit, der under Øyvind Marthinsen, Sigmund Nilssen og Jon Marius Håkedal.

7 III. PRODUKTRAPPORT HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD GRUPPE 36 FORFATTERE: N O RDENGEN, THOMAS LA R S E N, GLE N R UB E N E. S TEEN, SEB AS T IE N -J EROME 1

8 FORORD Denne rapporten er skrevet for personer med kompetanse innenfor informasjonsteknologi og beskriver de tekniske aspektene av modulen CvReg Tilbud i sin helhet. Denne rapporten er ment for personer som skal benytte seg av CvReg Tilbud generelt, videreutvikle modulen eller av andre grunner ønsker å sette seg inn i systemet. Det kan være fordelaktig å ha kjennskap til rammeverket Grails med alle teknologiene det benytter eller et annet fullstack MVC rammeverk, men det er ikke noe absolutt krav. 2

9 INNHOLDSFORTEGNELSE FORORD BESKRIVELSE AV APPLIKASJONEN CVREG MÅL OG RAMMEBETINGELSER Mål for prosjektet CvReg Tilbud Rammebetingelser Kravspesifikasjon Endring i kravspesifikasjon Avvik fra kravspesifikasjonen MVC RAMMEVERK MODULENS STRUKTUR Oppbygning Domeneklasser ER-diagram over de genererte tabellene i databasen Språk i koden DESIGN OG FUNKSJONALITET CV view Legg til tilbud fra CV view Liste over tilbud Slette et tilbud Opprette et tilbud Tilbud-view Detaljvisning Legg til CV i tilbud Redigere tilbud Tilbud-klasse (domain class) Tilbud-kontroller Tilbud i koden Slette tilbud

10 5.13 RemoteFunction RenderDetails ØVRIG DOKUMENTASJON Brukermanual Testrapport UTVIDELSESMULIGHETER BESKRIVELSE AV APPLIKASJONEN CVREG Knowit Oslo har per i dag et eksisterende system hvor ansatte kan fylle ut sine CV-er. Det er en web-applikasjon for å registrere arbeidserfaring, kompetanseområder, styrker, svakheter og informasjon om hver enkelt ansatt. Dette på en måte som er enkel, søkbar og lett tilgjengelig både for utviklere og selgere. CV-ene kan eksporteres som PDF, ODT eller DOCX format, for så å kunne sendes ut til potensielle kunder, eller brukes internt i bedriften. Det er to grupper av brukere i dette systemet: Brukere: Utviklere (ansatte i Knowit), registrerer sine CV-er etter en universelt utformet mal, som gir en felles standard for de registrerte CV-ene i systemet. De ansattes personalia fylles inn i systemet som lager en pent formatert CV. De ansatte vil kunne se hvilke tilbud de er oppført i, og hva dette tilbudet går ut på og CV-ene kan lastes ned som PDF dokumenter direkte fra siden. Administratorer: De som oppretter, setter sammen og administrerer tilbudene. Dette kan for øvrig også være vanlige ansatte som har fått tildelt administrator rettigheter. Administratorrollen er implementert gjennom systemet i sin helhet, så disse kan redigere andres CV-er, legge til kategorier for fagfelt etc. I dette dokumentet blir ordet CV brukt for å indikere bruker eller profil. Dette fordi det er CV-ene som er essensiell for applikasjonen, og det er brukerens CV som inneholder informasjonen og knytter andre relevante moduler sammen. 4

11 2.0 MÅL OG RAMMEBETINGELSER 2.1 Mål for prosjektet CvReg Tilbud Knowit så potensialet i applikasjonen CvReg og ønsket å utvide den med ytterligere funksjoner. Et av ønskene fra salgsdivisjonen i bedriften var muligheten til å sette sammen en gruppe ansatte, via deres registrerte CV-er i systemet. Denne sammensetningen av CV-er kalles et Tilbud, som da representerer et planlagt prosjekt. Dette gjøres for å få en oversiktlig måte å samle de personer som skal inkluderes i et fremtidig oppdrag. Et tilbud består da av: Navnet på prosjektet En beskrivelse av hva prosjektet går ut på Hvem som er ansvarlig for dette prosjektet (selger) En liste over hvilke deltakere prosjektet har. En startdato En sluttdato Hvert tilbud har verdien aktiv eller ikke aktiv. Verdien blir satt utfra hvorvidt prosjektets sluttdato er nådd, og hvorvidt prosjektets startdato er nådd. Hvis dags dato er imellom disse to, er prosjektet aktivt. Disse tilbudene skal kunne opprettes, redigeres og slettes i en modul som blir kalt CvReg Tilbud. 5

12 2.2 Rammebetingelser CvReg er utviklet i rammeverket Grails, som generelt benytter seg av programmeringsspråket Groovy, som er en avart av standard Java. Videre er brukergrensesnittet i applikasjonen utviklet ved hjelp av Twitter Bootstrap. Twitter Bootstrap er en gratis samling av verktøy for utvikling av nett applikasjoner. Hovedsakelig er dette en samling av HTML og CSS maler, men som også kan utvides med valgfrie JavaScript utvidelser. Dette satte dermed rammen for hvordan brukergrensesnittet til den nye modulen ble utviklet. 2.3 Kravspesifikasjon En kravspesifikasjon har blitt utviklet i samråd mellom Knowit og gruppen fra Høgskolen tidlig i prosjektet. Knowit har klare mål for hva som er ønsket at skal være med i modulen CvReg Tilbud og hvordan brukergrensesnittet skal se ut. Denne kravspesifikasjonen er å finne som vedlegg 1 i dette dokumentet. Kravspesifikasjonen som forelå var delt inn i to deler: Milepæl 1 og Milepæl 2. Milepæl 1 var ment som et minimumskrav til hva som skulle bli levert ved prosjektets slutt, og Milepæl 2 var ment som en mulig utvidelse, hvis tid og ressurser tillot det. Kun milepæl 1 ble nådd under dette prosjektet, som også var minimumskravet. Det er noen elementer i sluttproduktet som mangler fra kravspesifikasjonen. Dette er noen mindre funksjoner eller detaljer som er definert i kravspesifikasjonen milepæl 2. Ellers ble alle punktene i den første milepælen oppnådd. Alle kravene er testet og bekreftet gjennomførte ved prosjektets leveringsdato. Den andre milepælen ble ikke oppfylt. Dette står nå på listen over utvidelsesmuligheter. 6

13 2.4 Endring i kravspesifikasjon Kravet om at en timeoutfunksjon skal endre tilbudets status fra aktiv til inaktiv etter en tid, ble revaluert underveis i utviklingen. Denne funksjonen eksisterer nå som en metode som evaluerer hvorvidt tilbudets sluttdato har passert, og hvorvidt startdatoen er nådd. Hvis en av disse to er tilfelle, vil tilbudet vises som inaktivt, og hvis dags dato ligger mellom disse to verdiene er tilbudet aktivt. 2.5 Avvik fra kravspesifikasjonen Responstiden for enkelte handlinger i applikasjonen har tidvis gjennom utviklingsprosessen vært lengre enn kravet på maksimalt tre sekunder. Dette har skyldtes tunge databasekall og dårlig optimalisert databasehåndtering på systemet som kjører lokalt på våre utviklingsmaskiner. Det gjelder spesielt visning av tilbudsdetaljer, hvor responstiden har overskredet 8 sekunder i noen tilfeller. Etter noen justeringer i koden er den nede på 3,5 sekunder, og når applikasjonen kjøres på en fullverdig webserver vil denne være ytterligere forbedret. I slutten av rapporten finnes det en liste over utvidelsesmuligheter for senere iterasjoner, som baserer seg på milepæl del to. Dette er de målene som ikke ble nådd i dette prosjektet. 7

14 3.0 MVC RAMMEVERK Figur 3.1: MVC Rammeverk MVC (Model - View - Controller), er et rammeverk som deler applikasjonen inn i data modeller og brukergrensesnitt view, slik at utformingen av brukergrensesnittet ikke har noen innvirkning på hvordan dataen i applikasjonen blir håndtert, eller motsatt. Denne typen rammeverk benyttes veldig ofte i forbindelse med objekt orientert programmering, der dataene er definert i klasser som igjen er utgangspunktet for genererte objekter. Illustrasjonen over illustrerer forholdet mellom presentasjonslaget, businesslaget og dataaksesslaget. Dataaksesslaget behandler klasser og forholdene definert mellom dem, og oppretter tabeller og restriksjoner 8

15 i databasen uten behov for direkte innvirkning fra utvikleren. Dataaksesslaget er også ansvarlig for å opprette og håndtere objekter som kan kalles på fra businesslaget. Objektene er en umiddelbart manipulerbar representasjon av datamodellen man forholder seg til under applikasjonsutviklingen. Businesslaget er ansvarlig for å håndtere forholdet mellom logikken vi skriver i kontrolleren, og klassene som eksisterer i datalaget. Mye av dette skjer under panseret og er en del av fullstack-applikasjonen som er ferdig konfigurert til CvReg som system. Presentasjonslaget består av controllers og views. Controlleren fungerer på en måte som en veiviser for datastrømmen mellom brukeren og systemet. Der opprettes objekter etter behov og data fra skjema og bruker fylles inn der det skal. Controlleren brukes både til å lagre og presentere data og til å bestemme hva som skal returneres til view. Viewet er filen som Grails bruker til å generere kode til nettleseren. I viewet brukes Groovy tags til å representere data og generere skjema, og man kan bruke variabler og returnert data fra applikasjonen til å lage dynamisk genererte websider på en fleksibel måte. I Grails er det vanlig at domeneklasser ofte benytter en kontroller og et view med samme navn som klassen selv. Dette gjør det lett å forholde seg til de forskjellige elementene i programmet. I tillegg til at kontrolleren ofte benytter samme navn som klassen, har de også alltid suffikset Controller, som gir et tydelig navn skille mellom de to entitetene. Tilsvarende er det det samme med views. Hver view som tilhører en kontroller, ligger da også ofte i en mappe med samme navn som kontrolleren og klassen. Utenom dette er det vanlig at subklasser, det vil si klasser som utvider andre klassers egenskaper, ikke alltid trenger å ha egne kontrollere eller egne views. Dette kan være klasser som enten, ikke har data som skal presenteres, men som heller blir brukt til utregninger eller lignende, eller har data som blir presentert 9

16 gjennom andre klasser og kontrollere. Noen av disse har funksjoner som skal være tilgjengelig overalt i løsningen og som dermed ikke nødvendigvis har noen spesiell tilhørighet. 10

17 4.0 MODULENS STRUKTUR 4.1 Oppbygning Løsningen som er utviklet er i korte trekk en tilleggsmodul i CvReg. Den er integrert i systemet i den forstand at det brukes eksisterende klasser og datamodeller i tillegg til de vi har supplert, for å skape en ny funksjonalitet i CvReg. Modulen CvReg Tilbud henter data fra Bruker-klassen og dens tilhørende klasser for å presentere data om brukeren, og for å binde dem sammen med Tilbudsklassen som vi har laget. CvReg Tilbud er også en tett integrert del av systemet i sin helhet, da rammeverket som dette ligger i er veldig modulært og dynamisk - det har en høy grad av granularitet med mange separate moduler som snakker sammen. Dette gjør det lett å få en god flyt i applikasjonen, og gjør at det er lettere å bruke en funksjon mange ganger i form av objekter og instanser. Lagdelingen i applikasjonen gjør det mulig å gjøre endringer ett sted uten store konsekvenser andre steder, så lenge man holder seg innenfor standardene satt av applikasjonen. Denne illustrasjonen beskriver hvordan tilleggsmodulen CvReg Tilbud føyer seg inn i applikasjonen som helhet: 11

18 Figur 4.1: Oversiktsdiagram av CvReg Man ser et omriss av dataflyten i systemet, og selv om modellen er forenklet viser den både eierskapsforhold mellom CV-er og tilbud, og rollen til administratorer i applikasjonen. Senere i dokumentasjonen blir det presentert en spesifikk use-case for å illustrere hvordan en handling forløper seg for brukeren. Videre i rapporten skal vi dykke dypere inn i systemet og se på kildekoden som ligger bak, og hvordan dette fullstack-systemet behandler forespørselen. 4.2 Domeneklasser Under vises et utsnitt av domeneklassenes avhengigheter og hvilke domeneklasser som har noe med hverandre å gjøre: 12

19 Figur 4.2: Relasjonsdiagram Som vist på diagrammet over kan en se at det er hver enkelt persons CV som er det mest essensielle i applikasjonen. Hver enkelt CV er knyttet til alle de andre forskjellige aspektene ved applikasjonen. Ytterst i applikasjonen ligger hver persons bruker i systemet. Denne brukeren er igjen knyttet til tre forskjellige elementer: Profil, Tilbud og CV. Det at CV-klassen er knyttet til resten av applikasjonens egenskaper fremfor Bruker-klassen, er fordi det er hver enkeltes CV som representeres i applikasjonen, og det er denne informasjonen som er benyttet til visningen av hver enkelt deltagers profil. 13

20 Det vil kun bli drøftet og forklart kode for de forskjellige delene av applikasjonen som er utviklet av studentene selv, og ikke kode som eksisterte fra før i applikasjonen. 4.3 ER-diagram over de genererte tabellene i databasen Merk at ER-diagrammet under er en oversikt over de genererte tabellene i MySQL databasen, basert på klassene som eksisterer i applikasjonen. I klassen proposal har vi for eksempel en verdi med navn proposalmanager. Denne er av typen User i klassen. I den genererte tabellen i databasen får denne datatypen integrer, og et navn som indikerer at den refererer til verdien id i tabellen user. I tillegg til dette blir verdien oppført som en fremmednøkkel mot tabellen user. Slike endringer blir håndtert automatisk av Grails, basert på et sett med predefinert konvensjoner. Figur 4.3: ER-Diagram 14

21 4.4 Språk i koden All koden og alle variabler er etter industristandard skrevet på engelsk. Klassen for Tilbud får navnet Proposal, klassen for bruker får navnet User, etc. Dette er for at hvem som helst skal kunne bruke koden uten å måtte slå opp i noen ordbok. Det er også mye lettere å være konsekvent på navngiving av variabler når alt forblir på engelsk. For å gjøre applikasjonen mest mulig fleksibel benytter CvReg seg av den godt utbygde internasjonaliseringsfunksjonen i Grails. Her lager man et dokument med egendefinerte tagger som korresponderer til en tekststreng. I koden kan man kalle på denne taggen, og få presentert teksten den korresponderer med. Dette kommer virkelig til sin rett når man har mange språkfiler med gode oversettelser - ved å endre på en enkel variabel kan man vise hele siden nøyaktig like godt uansett hvilket språk brukeren ønsker. 15

22 5.0 DESIGN OG FUNKSJONALITET CvReg Tilbud har en rekke egendefinerte funksjoner som legger seg til de eksiterende funksjonen fra CvReg. Disse er implementert sømløst i applikasjonen, enten via den nye siden som heter Tilbud eller innenfor selve CV siden. 5.1 CV view Figur 5.1: CV-View 16

23 Over vises et view, som viser en oversikt over brukerens eksisterende CV-profil. Denne oversikten vil brukeren selv være nødt til å fylle ut, men det er ikke nødvendig for at tilbudsmodulen som vi har utviklet skal fungere. I bildet så er både lenken til den nye Tilbud siden og nye Tilbud knappen på CV siden synlige. Disse representerer implementeringen av CvReg Tilbud i CvReg applikasjonen. 5.2 Legg til tilbud fra CV view Figur 5.2: CV-View-Legg til CV 17

24 Det er mulig å legge CV-er inn i tilbud fra CV-view. Dette kan enkelt gjøres ved å klikke på + Tilbud til venstre i CV menyen. Dette vil hente fram et poppup vindu med muligheten for å bla i en drowdown liste over alle som jobber i Knowit. Dette vinduet lister også opp hvilke eksisterende tilbud CV-en (som er valgt) er deltager i. 5.2 Liste over tilbud Figur 5.3: Vis tilbud Listen over tilbudene registrert i applikasjonen (som vist over), fungerer også som en meny - når man holder musepekeren over en av linjene i listen endrer den farge. Når den klikkes på, lastes detaljert informasjon om tilbudet inn i det høyre feltet av skjermbildet. 18

25 Listen er delt opp i tre faner øverst i visningen, for å gjøre det lettere å sortere tilbudene. Her kan man velge om alle tilbud skal vises, eller så kan kun de aktive vises, eller kun de inaktive. 5.3 Slette et tilbud På høyre ende av hver linje finner vi en knapp for å slette det relevante tilbudet. Når den trykkes på kommer det en bekreftelsesmelding på skjermen som forklarer at tilbudet vil slettes, og at ingen CV-er blir fjernet fra systemet. Den ser slik ut: Figur 5.4: Slett tilbud Når brukeren så trykker på den røde knappen, blir tilbudet fjernet fra listen, og siden lastes inn på nytt. 5.4 Opprette et tilbud Nederst på siden, under opplistingen av alle eksisterende tilbudene ligger knappen for å opprette et nytt tilbud, + Nytt tilbud. Denne knappen vil laste inn et skjema i høyre del av skjermbildet, som lar deg registrere et nytt tilbud. Dette view ser slik ut: 19

26 Figur 5.5: Legg til tilbud Dette skjemaet er veldig enkelt. De eneste kravene som stilles er at: navn, start og slutt dato er utfylt. 20

27 5.5 Tilbud-view Dette er hovedsiden for tilbudsmodulen. Det er her mesteparten av alle operasjoner angående tilbud finner sted. Denne siden viser en oversikt over alle de eksisterende tilbudene. Denne listen er delt inn i tre kategorier: Alle eksisterende tilbud, Aktive tilbud og inaktive tilbud. Under er lite utsnitt av _form.gsp. Figur 5.6: _form.gsp utsnitt Denne koden er en del av koden som utgjør brukergrensesnittet for opprettelse av et nytt tilbud. Her ser vi koden som viser et tekstfelt med en tilhørende merkelapp (label). <div class= controll-group >: Bestemmer hva slags type kode den påfølgende koden er, som da vil gi denne koden visse egenskaper definert i Twitter Bootstrap (beskrevet tidligere i dokumentet). <label for= new-proposal-name >: Standard HTML kode for opprettelse av overskrift for et element med tilhørende navn. 21

28 <input type=, id=, name=, placeholder=, value=, class= >: Definerer at det skal vises et innputt felt av typen tekst, at dette feltet skal ha id-en new-proposal-name. Placeholder= definerer hvilken forhåndsbestemt tekst som skal vises i tekstfeltet. I dette tilfellet er det benyttet en globalisert tekst behandling. Dette åpner for muligheten til enkelt å kunne velge språket applikasjonen skal presenteres i, uten at en trenger å endre på noe kode i applikasjonen. 5.6 Detaljvisning Når brukeren trykker på et tilbud - hele linjen fungerer som en knapp - så lastes detaljer om tilbudet inn dynamisk på høyre del av nettsiden. Det høyre feltet brukes til både å se detaljer om et tilbud, å opprette et nytt tilbud og til å redigere eksisterende tilbud i applikasjonen. Først tar vi for oss detaljvisningen: Figur 5.7: Detalj-visning av tilbud 22

29 Detalj-visningen av tilbudet inneholder navnet på tilbudet, fra- og til-datoene, en mer utfyllende beskrivelse av tilbudets art og omfang, samt en liste over de som er med i tilbudet. Nederst fins det en knapp for å gå til redigeringsiden der tilbudsinformasjonen kan endres hvis nødvendig. Listen over personer som er inkludert i tilbudet har to interaktive funksjoner. Første funksjonen er selve navnene er lenker til den aktuelle personens CV i dette systemet. Dette gjør det enkelt å få mer informasjon om den ansatte. Den andre funksjonen er en slette-knapp på høyre siden av listen. Denne knappen fjerner den aktuelle personen fra tilbudet. Det kommer ikke opp noen bekreftelses boks når denne trykkes på. Dette er utelatt da det er enkelt nok å legge til personen på nytt, samt vanskelig nok å slette mer enn en person i vanvare. Når man trykker på denne sletteknappen for å fjerne en person fra tilbudet, blir personen fjernet uten at hele siden lastes inn på nytt - kun boksen med presentasjonen lastes inn igjen. 23

30 Under vises et utdrag av koden som gir en del av skjermbildet (henvisning til skjermbilde nr.) Figur 5.8: Detalj-visning kode Dette er veldig mye vanlig HTML kode, men er tatt med her for å beskrive hvordan en kan bruke Groovy kode direkte i et view (.gsp filer). Øverst i koden markert i gult, er det blitt benyttet en if test midt i koden: <g: if test= ${user?.isadmin} >. Det er mulig å benytte Groovy-kode ved å skrive: <g: etterfulgt av Groovy kode. Alle slike tags avsluttes med en respektiv </g:> tag, slik som det er gjort i bunnen av denne kodesnutten. Det denne kodesnutten faktisk gjør, er at den kjører en spørring på klassen user sin isadmin funksjon. Denne funksjonen returener en tru eller false verdi basert på om brukeren er administrator eller ikke. Det samme er gjort for den delen av koden som er markert i blått. Forskjellen på disse to kodesnuttene er at den siste i blått i tillegg til å benytte seg av en allerede eksisterende variabel fra klassen Proposal (proposals automatisk genererte id felt), og så lagrer denne verdien i en hiddenfield. Grails sender med alle verdier som eksisterer innenfor formremote-taggene tilbake til kontrolleren. 24

31 5.7 Legg til CV i tilbud Figur 5.9: Legg til CV i tilbud For å legge til en CV i tilbudet, kan man velge et navn fra nedtrekks menyen i detaljvisningssiden. Når man trykker på knappen merket legg til, vil denne delen av siden lastes inn på nytt for å reflektere endringen. Knappen merket rediger tar brukeren med til en ny side, for å redigere tilbudet. Dette skjemaet er det samme som brukes til å legge til et nytt tilbud, men med den eksisterende tilbudsdataen lagt inn. 25

32 5.8 Redigere tilbud Figur 5.10: Rediger tilbud Å redigere et tilbud er veldig enkelt. All tidligere registrerte data hentes inn i formen, og alle endringer av feltene i formen vil bli lagret i databasen. 26

33 5.9 Tilbud-klasse (domain class) Domain class filen er selveste Modellen i MVC-rammeverket, og er det som definerer datastrukturen i programmet. Klassedefinisjonen spesifiserer hvilke verdier som skal kunne lagres i databasen. I tillegg til de vi har opprettet her, genererer også DBHS felt for id og version som begge auto-inkrementeres når felter i databasen legges til eller endres. Figur 5.11: Domain class Over ser du et utsnitt av domeneklassen for Proposal. En domene klasse inneholder en rekke datafelter, som representerer verdier eller egenskaper en ønsker at et objekt skal ha. I Grails er en domene klasse også en definisjon på en tabell i databasen som tilhører prosjektet. Dette fordi Grails automatisk oppretter disse 27

34 tabellene basert på den informasjonen som blir gitt i domene klassen. Dette betyr at hele applikasjonen bygger på hvilke domene klasser som eksisterer, og hvilke relasjoner disse har til hverandre. Videre følger en forklaring på koden i bildet over. Kode: class Proposal: Definerer navnet på klassen, og utgjør navnet på tabellen i databasen. Date date_ended: Definerer tilbudets slutt dato. Denne datoen benyttes i applikasjonen for å bestemme hvilke tilbud som er aktive og inaktive. Date date_started: Definerer tilbudets start dato. Start dato har i prinsippet kun en informativ hensikt, da dens eneste hensikt er å informere brukerne om når et fremtidig tilbud er tiltenkt. String description: Er datafeltet som inneholder beskrivelsen til tilbudet. Denne informasjonen er tekst lagret i en String. String name: Inneholder navnet på tilbudet. User proposalmanager: Er datafeltet som bestemmer hvilken ansatt som har ansvaret for et bestemt tilbud. Alle tilbud kan ha en ansvarlig, men dette er ikke et krav. Videre i koden har vi det som kalles for relasjonsbestemmelsene for klassen: static belongsto = CV: Er en deklarasjon som bestemmer at denne klassen Proposal, skal være et barn child av CV-klassen. static hasmany = [cvs: CV]: Bestemmer at disse klassene er i et mange til mange forhold med hverandre. Disse to deklarasjonene bestemmer da også relasjonene mellom tabellene i databasen. Til slutt har vi datafeltenes begrensninger: 28

35 static constrinats = {: Er en definisjon som sier at de påfølgende linjene inneholder begrensinger for de respektive datafeltene nevn. date_ended size: , nullable: false: Bestemmer at verdiene i datafeltet kun kan ha en verdi på størrelse mellom 0 og 500 tegn Tilbud-kontroller Kontrolleren er da det mellomliggende elementet mellom brukergrensesnittet og domene klassen, som bestemmer hvordan dataene i klassen skal bli representert i brukergrensesnittet. Dette gjøres ved å definere funksjoner med kode som behandler de dataene som eksisterer i klassen, og om de skal bli sendt med til view-et. Under følger et utsnitt av kontrolleren til Proposal klassen, og en dypere forklaring på koden. Figur 5.12: Proposal Controller Kode: def index() : Er en standard metode (funksjon), som fungerer helt likt som en konstruktør i klassisk Java. Index metoden automatisk blir kalt på om den inneholder noen kode. Det er mest vanlig i denne metoden å definere hvilket view en ønsker at skal bli lastet inn først i applikasjonen, men en kan også på denne måten 29

36 bestemme hvilken kode i kontrolleren som skal utføres i det et view blir vist på skjermen. I dette tilfellet er denne metoden ikke benyttet. def create(): Er metoden som blir kalt når en i applikasjonen oppretter et nytt tilbud (som beskrevet i brukermanualen). Fra _form.gsp (et tilhørende view), blir all informasjonen om det nye tilbudet sendt og kan benyttes i denne metoden. Proposal proposal: Definerer at det skal eksistere en instans av klassen Proposal, med navnet proposal. proposal = new Proposal(): Er kode som oppretter en ny instans av klassen Proposal med de verdiene som er definert innenfor denne metoden. name: params.proposalname: Sier at feltet name (som er et datafelt i klassen, og da også en rad i den tilhørende tabellen Proposal i databasen), skal ha verdiene som finnes i params.proposalname. Params er en Groovy funksjonalitet som inneholder alle verdiene tilsendt av et view. Her betyr dette at params inneholder alle verdiene for både: name, description, date_started og date_ended. Viewet til hovedsiden for tilbudsmodulen ser slik ut: 30

37 Figur 5.13: Tilbudsmodul Her opprettes de tre fanene som deler opp tilbudene i aktive og ikke aktive tilbud - og en tredje fane med begge blandet og sortert etter navn. Nederst i koden ser vi en Grails tag som rendrer et template view som heter container. Dette viewet har ikke behov for å kalle på noen controller action, men er kun et statisk skjelett for innholdet i siden Tilbud i koden Listen over tilbud ligger i koden som en vanlig tabell med felter for navn, start dato, slutt dato og til slutt en knapp for å slette tilbudet - men den synes kun om man er logget inn som administrator. 31

38 For hver av tilbudene som applikasjonen finner i databasen, lages det et ny linje i tabellen. Den ser slik ut i proposal viewet, og er en del av _list.gsp, som igjen ble rendret i _container.gsp, som ble kalt på i index filen som nevnt i forrige avsnitt. Figur 5.14: Proposal form 5.12 Slette tilbud Knappen for å slette hele tilbudet lages av en Grails render tag, som henter opp en feles klasse for å generere en slett-dialog. Knappen vises kun for innloggede brukere som passerer testen isadmin, som returneres til viewet gjennom Main-controlleren. Denne slette klassen tar et par innparametere for å avgjøre hva som skal slettes, som igjen da sendes tilbake til controller. Vi har en controller action som heter delete(), som ser slik ut som dette: 32

39 Figur 5.15: Slette kode For å slette et proposal må man først fjerne alle tilhørigheter mellom proposal og cv. Disse opprettes av GORM (Grails object relationship manager), som er bindevevet mellom applikasjonen og DB. GORM håndterer data som objekter i minnet, og det er mange praktiske snarveier man må være oppmerksom på når man skal bruke GORM til å håndtere databaserelasjoner. Fordelene er mange, men det er noen begrensinger som vanskeligjør databehandlingen. I dette tilfellet må det opprettes et array bestående av alle medlemmene av et proposal, for å så be GORM fjerne hver av deltagerne i arrayet. Løsningen unngår problemer med at det blir konflikt mellom dataobjekter i minnet og datastruktur i databasen. Til slutt, når det ikke er flere restriksjoner i databasen som hindrer admin-brukeren i å slette proposal, så blir proposal.delete utført, med (flush:true) på slutten for å være sikre på at endringen blir videreført til databasen RemoteFunction Hver linje i tabellen med listen over de eksisterende tilbudene har en onclick-funksjon som gir tabellen funksjonalitet som en navigeringsknapp. Når linjen klikkes på eksekveres denne koden: 33

40 Figur 5.16: remotefunction remotefunction er en Grails-tag som generer et AJAX-kall for oss. Den tar innparametre om hvilken action i controlleren som skal kjøres, hvilke parametere som skal sendes med fra view og hvor i nettsiden endringen skal utføres. Den er fleksibel nok til å utføre mange forskjellige oppgaver, men dette var bruksområdene vi hadde i denne sammenhengen RenderDetails Figur 5.17: renderdetails Controller actionen som kalles på her heter renderdetails. Den bruker vi til å hente ut et objekt av typen Proposal. Dette inneholder alle datafeltene i klassen, i tillegg til en del metainformasjon og generert data som vi kan benytte oss av. Gjennom modellen gjør vi den tilgjengelig med nøkkelnavnet proposal. Vi sender også med elementet user, for å forsikre oss om at administratorstatusen kan valideres i neste view. 34

41 Use Case Administrator legger til CV i et Tilbud For å gå mer i dybden hva angår applikasjonens virkemåte og logikken som ligger bak den, presenteres det her et use case med tilhørende diagrammer for å illustrere en isolert funksjon i applikasjonen. Dette er både et eksempel på hvordan metodekall brukes og på hvordan et mange-til-mange forhold løses i applikasjonen. Funksjonen det fokuseres på ligger tilgjengelig i presentasjonen av Tilbudet og har som oppgave å legge til en forbindelse mellom et gitt tilbud og en CV, slik at CV-en blir inkludert i tilbudet. I presentasjonen av Tilbudet velges en CV i en rullegardinmeny. I listen i menyen finner vi navnet på alle personene som har en CV registrert i systemet. Når ønsket person er valgt, trykker brukeren på knappen merket 'legg til i tilbud.' Siden lastes inn på nytt, med den valgte brukeren lagt til i oversikten over inkluderte CV-er. Figur 5.18: Use Case Diagram Use case scenario er beskrevet i vedlegg 4. 35

42 Dette er en grunnleggende funksjon i applikasjonen, men bak den ligger fortsatt mye kode. I kontrolleren opprettes det to objekter av typene CV og Proposal. Minner igjen om at koden er på engelsk, Proposal omtales ellers som Tilbud. Illustrasjon av hvordan CV legges til i Tilbud, i controlleren: Figur 5.19: Proposal Parameteren med navn PersonInclude hentes fra nedtrekks listen i skjemaet på nettsiden. Den brukes for å hente inn et nytt objekt av typen CV med verdien som korresponderer med parameteren. ProposalId brukes for å identifisere det aktuelle tilbudet, og hentes inn fra et annet, skjult skjemaelement på siden. Igjen opprettes et nytt objekt, denne gang av typen Proposal (tilbud). Neste linje bruker en funksjon i Grails som genererer dynamiske metoder. Dynamiske metoder er en måte å gjøre kall på objekter uten å eksplisitt skrive selve kallet. Man skriver en verbal instruks til hva programmet skal hente eller behandlet, og Grails genererer alle de nødvendige metodene. Dynamiske metoder har begrenset med funksjonalitet, men kan være veldig kraftige. I dette tilfellet brukes det for å instruere GORM til å legge til CV til Proposal - enkelt og greit ved å skrive "CV.addToProposal(proposal)". 36

43 Til sist lastes detalj-visningen i nettsiden inn på nytt med kommandoen redirect. Vi gir innparameteret action: renderdetails for å fortelle kontrolleren hvilken Action vi skal bruke for å laste inn siden på nytt, og sender med ID-verdien til tilbudet for at denne Action skal vite hvilket tilbud den skal laste inn på nytt. En mer detaljert oversikt over hvordan dette spesifikke kallet gjennomføres på serveren er forklart i vedlegget nummer 5 Dette vedlegget illustrerer steg for steg veien kallet som har blitt forklart her tar igjennom applikasjonsstacken. 37

44 6.0 ØVRIG DOKUMENTASJON 6.1 Brukermanual En brukermanual er blitt utredet som beskriver de grunnleggende funksjonene i CvReg Tilbud modulen. Brukermanualen finnes som Vedlegg 2 i sluttrapporten 6.2 Testrapport En testrapport ble også utredet under og ved slutten av utviklingen for å kvalitetssikre CvReg Tilbud. Testrapporten finnes som Vedlegg 3 i sluttrapporten. 38

45 7.0 UTVIDELSESMULIGHETER Flere funksjoner i modulen CvReg Tilbud kan utvikles videre eller utbedres. Noen av dem er konkrete funksjoner som er listet her. Kalenderfunksjon: kode for bruk av Bootstrap kalenderfunksjon i CvReg Tilbud modulen har blitt lagt til i filen som heter _date.gsp, men den er ikke aktiv på grunn av problemer med implementering. En versjon av Grails sitt kalenderfunksjon er i bruk per dags dato i modulen. Funksjonelt så virker kalenderfunksjon som den skal i modulen, men følger ikke design mønsteret til resten av CvReg applikasjonen. Da ingen av målene for milepæl to ble utviklet under prosjektet, inngår disse i listen over elementer som kan utvikles i senere iterasjoner. - Advarsel om at en CV allerede er blitt inkludert i ett annet aktivt tilbud. - Funksjon for å laste opp vedlegg til et tilbud (pdf, bilder, video, etc ) - Funksjon for å laste ned alle CV-er i et tilbud som zipfil - Utvidet sortering av tilbudene i tilbuds viewet, som f.eks. sortering på navn, start og slutt dato. - Konvertere fra Grails egen date picker til Bootstrap DatePicker. - Multi seleksjon for å legge til CV-er i et tilbud. - sende e-post til CV bruker når CV er lagt inn i tilbud 39

46 Hovedprosjekt Prosessrapport IV. PROSESSRAPPORT HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD GRUPPE 36 FORFATTERE: N O RDENGEN, THOMAS LA R S E N, GLE N R UB E N E. S TEEN, SEB AS T IE N -J EROME 1

47 Hovedprosjekt Prosessrapport FORORD I denne prosessrapporten beskriver vi arbeidet gruppen har gjort i forbindelse med det avsluttende hovedprosjektet ved datalinjene på Høgskolen i Oslo og Akershus, vår For å få utbytte av denne rapporten er det en forutsetning å ha satt seg inn i materialet som er presentert i Produktrapporten for prosjektet. Der blir teknologier og løsninger gjennomgått i detalj, så for å unngå unødvendig repetisjon vil det fra tid til annen være utelatt beskrivelser og introduksjon av noen temaer i denne rapporten, som er dekket i Produktrapporten. 2

48 Hovedprosjekt Prosessrapport INNHOLDSFORTEGNELSE Forord FORBREDELSER Utgangspunkt for prosjektet Faglige utfordringer Behovsanalyse Kartlegging av kompetanse Arbeidsplan ORGANISERING AV ARBEIDET Gruppearbeid Verktøy til kommunikasjon med oppdragsgiver FAGLIGE BETINGELSER FOR UTVIKLINGEN Teknologier Groovy & Grails Twitter Bootstrap MySQL Læringsverktøy Prosjektverktøy Google Apps Git Eclipse IntelliJ IDEA PLANLEGGING AV LØSNINGEN Utredning av prosjektet - Planleggingsfasen Design av CvReg Tilbud UTVIKLINGSFASEN Første sprint (uke 5-6) Andre sprint (uke 7-8) Tredje sprint (uke 9-10) Fjerde sprint (uke 11-12)

49 Hovedprosjekt Prosessrapport 5.5 Femte sprint (uke 13-14) Sjette sprint (uke 15-16) Syvende sprint (uke 17-18) Åttende sprint (uke 19-20) Niende Sprint (uke 21-22) UTFORDRINGER OG UFORUTSETTE SITUASJONER Omorganisering av gruppen Utfordringer underveis i utviklingen Problemer med inkompatibilitet i MySQL-databasen Vanskeligheter med å få fjernet koblinger Problemer med slette tilbud OPPSUMERING Funksjonell Evaluering Faglig oppsummering LITTERATURLISTE

50 Hovedprosjekt Prosessrapport 1.0 FORBREDELSER 1.1 Utgangspunkt for prosjektet Det tok litt tid før gruppen fant en oppdragsgiver. Det var ikke før i begynnelsen av januar at vi kom i kontakt med Knowit og fikk tilbudt prosjektet CvReg Tilbud fra dem. I de innledende møtene med Knowit fikk vi konkrete krav om hva de ønsket å få ut av CvReg Tilbud, og vi ble gitt de nødvendige tilgangene til applikasjonen CvReg og serverne for å kunne videreutvikle den. Versjonshåndtering ble gjort over Knowit sin Git server og vi ble autentisert med RSA nøkler. 1.2 Faglige utfordringer De to største utfordringene i prosjektet kan oppsummeres slik: Å utvikle og tilpasse en ny modul i en allerede eksisterende applikasjon. Å utvikle i et rammeverk ingen av medlemmene hadde kjennskap til i fra før. Disse utfordringene ble sett på som positive utfordringer for gruppen, da det ga oss sjansen til å lære oss et nytt rammeverk, og bli kjent med hvordan det er å jobbe i en profesjonell utviklingssammenheng. For Knowit ble prosjektet også en ny erfaring, da de aldri hadde jobbet med en skolegruppe før. Dette ga dem en mulighet til å prøve en ny type samarbeid med oss. 5

51 Hovedprosjekt Prosessrapport 1.3 Behovsanalyse Knowit hadde allerede hatt flere interne samtaler og møter på tvers av avdelingene om hvilke funksjoner og retninger de ønsket at CvReg skulle ta. Dette gjorde det enkelt for Knowit å bestemme hvilke funksjoner de ønsket at tilbuds-modulen skulle ha. Siden Knowit hadde klare krav til oss, ble lite av forarbeidet brukt på tradisjonell forprosjekts arbeid, som markedsanalyse eller behovsanalyse. Det ble derfor mer fokus på å tolke oppgaven Knowit hadde gitt oss i starten. 1.4 Kartlegging av kompetanse Da oppgaven var bestemt var det på tide å finne ut hvilken kompetanse vi hadde, som var relevant for prosjektet. Det viste seg at både Thomas og Glenruben hadde studert Java programmering tidligere, men det hadde ikke Sebastien eller fjerdemannen. Det vil si at under planleggingsfasen de første ukene, var det desto viktigere for de to siste medlemmene å lære seg det grunnleggende rundt Java programmering i tillegg til Grails. Glenruben og Thomas hadde hatt faget Webapplikasjoner tidligere, som tar for seg utvikling av applikasjoner i ASP.NET. Dette ga oss et lite fortrinn når det kom til å sette seg inn i Grails rammeverket. 1.5 Arbeidsplan Etter å ha hatt et møte med Knowit for å bli bedre kjent med kildekoden og måten de hadde bygd CvReg opp på, kunne vi starte med brainstorming av idéer på hvordan vi kunne utvikle CvReg Tilbud. I begynnelsen tegnet vi whiteboard skisser for å fine en funksjonell og designmessig riktig implimentasjon av det som skulle bli CvReg Tilbud. I tillegg gjorde vi en datamodellering ved å tegne kart over dataflyten og nødvendige metoder og klasser, vi behøvde for å oppnå de resultatene vi ønsket. 6

52 Hovedprosjekt Prosessrapport Figur 1.1: Prototype1 Figur 1.2: Prototype 2 Med en grov skisse på hvor mye arbeid vi antok at det krevdes for å lage CvReg Tilbud, satte vi opp et gantt diagram, som ga oss et anslått tidsperspektiv over hele utviklingsperioden. 7

53 Hovedprosjekt Prosessrapport Figur 1.3: Gantt diagram 8

54 Hovedprosjekt Prosessrapport 2.0 ORGANISERING AV ARBEIDET Arbeidsforholdene endret seg etter hvilken fase av prosjektet vi var i. Under konseptutviklingen og planleggingsfasen jobbet gruppen mye sammen på skolen. Vi var avhengige av å jobbe med sentrale konsepter, skisser og andre idéer som kom frem under øktene. I programmeringsfasen hadde gruppen gått over til en mer delvis selvstendig arbeids form. Alle medlemmene jobbet med prosjektet på forskjellige tider av døgnet. Derfor var det vanskelig å få møttes for å få jobbet sammen. De dagene det var mulig å jobbe i gruppe, kunne gruppen treffes på skolen eller hos en av gruppemedlemmene. Når gruppen arbeidet sammen, debugget vi, og hadde regelmessig gjennomgang av den koden som var produsert. Ofte ble Skype brukt som kommunikasjonsmiddel for å koordinere arbeidet. Et så varierende samarbeid krevde mer av gruppen, enn om gruppen hadde jobbet sammen på skolen hver dag. Dette gjorde at Skype-samtaler var til stor hjelp for den interne kommunikasjonen i gruppen. Derfor var det viktig at vi fra begynnelsen av, satte rammer for hvordan vi skulle arbeide sammen som gruppe. 2.1 Gruppearbeid For å kunne fungere effektivt som gruppe over lengre perioder, uten alltid å ha muligheten til å jobbe sammen, trengte vi en effektiv utviklingsmetode. Vi endte opp med å benytte Scrum som metode. Med Scrum fikk vi muligheten til å planlegge forskjellige sprinter i ukes eller to ukers intervaller, der vi enkelt kunne fordele arbeidet mellom oss. For å øke fleksibiliteten på hvordan vi skulle jobbe med de forskjellige sprintene, benyttet vi sprintfunksjonaliteten i Jira. Arbeidsgiver benyttet allerede Jira til å 9

55 Hovedprosjekt Prosessrapport håndtere sprintene sine. Det falt oss dermed naturlig å fortsette bruken av dette verktøyet til å håndtere våre egne sprinter og til å fordele arbeidsoppgaver mellom gruppemedlemmene. På kortere sprinter jobbet vi mer selvstendig enn på de lengre sprintene. På sprintmøtene i slutten av uken, kunne vi omfordele arbeidet og sette fokus på eventuell backlogg eller andre større problemer som hadde dukket opp. Fremdriftsplanen fordelte sprintene i lengder på to uker av gangen, som konkluderte med et sprintmøte med Knowit i slutten av hver andre uke. Der presentere vi løsningene vi hadde utviklet i løpet av sprintene, og fikk konstruktive tilbakemeldinger fra Knowit. 2.2 Verktøy til kommunikasjon med oppdragsgiver Oppdragsvier har satt opp både mailingliste via Google Apps og tilgang til Jira siden deres. Dette forenklet samarbeidet både innad i gruppen og mellom gruppen og oppdragsgiver, da alle kunne holde seg oppdaterte på prosjektstatusen og eventuelle problemer og løsninger via de felles verktøyene. Med jevnlige Scrum møter var det enklere for gruppen å tilpasse arbeidet i henhold til prosjektets fremgang. For å få bedre oversikt over arbeidsoppgavene, brukte gruppen som nevnt Jira. Jira er et dynamisk web basert system for prosjekthåndtering. En av funksjonen i Jira er sprinthåndtering, som gir en god og solid oversikt over sprintene som eksisterer. Det at vi benyttet deres egen lokale Jira, ga Knowit mulighet til å holde et øye med fremgangen vi hadde, og om ønskelig fra deres side kontrollere det som ble gjort. Vi benyttet oss av Git til versjonshåndtering. Knowit har en egen Git server, som vi brukte for å håndtere revisjoner av kildekoden. Dette var en effektiv måte å jobbe på som også ga Knowit innsikt i vår kode om det skulle være behov for det. Det betyr naturligvis ikke at vi kommuniserte mindre med arbeidsgiver under utviklingsprosessen, snarere tvert om. Dette sørget for at vi veldig enkelt kunne få rask og effektiv hjelp hvis det var nødvendig. Det å se på koden og sprintoversikten ga ikke nødvendigvis arbeidsgiver et korrekt bilde av situasjonen prosjektet var i til enhver tid. Jevnlig 10

56 Hovedprosjekt Prosessrapport kommunikasjon over epost og ved sprintmøter var nødvendig for å opprettholde både vår egen og deres oppfatning av prosjektets status. 11

57 Hovedprosjekt Prosessrapport 3.0 FAGLIGE BETINGELSER FOR UTVIKLINGEN CvReg er en allerede eksisterende applikasjon som ble utviklet internt av Knowit, derfor må gruppen tilpasse seg til de allerede fastlagte rammene som eksisterer for applikasjonen til videreutviklingen av den. Dette begrenser hvilken løsningene vi kan bruke og hvordan vi kan videreutvikle den. Hovedsakelig må vi forholde oss til språket applikasjonen er opprinnelig laget i. I tillegg så har Knowit en del hjelpemidler for utvikling og dokumentasjon de ønsker at vi bruker under utviklingen for å sikre at de har den dokumentasjonen og loggføring de trenger når de skal ta over prosjektet. Fordelen er at vi kan forholde oss til ferdig satt opp miljøer og slipper derfor å finne på egne løsningen for en del av tjenestene vi trenger under utviklingen. Ulempen er at ikke alle verktøyene er kjent for oss, eller ikke nødvendigvis hadde vært førstevalg for gruppen hvis vi hadde mulighet til å sette opp vårt eget utviklingsmiljø. 3.1 Teknologier Siden CvReg Tilbud skal implementeres i den allerede eksisterende applikasjonen CvReg er det viktig at de er sømløst integrert med hverandre. Det er derfor viktig å utvikle CvReg-Tilbud i samme språk som den opprinnelige applikasjonen. Dette har satt strenge begrensninger på hva gruppen kan bruke som løsning for å løse oppgaven. I praksis har dette lagt begrensning på hvor mye evaluering av design, brukergrensesnitt og sikkerhet vi har hatt behov for å gjøre. Vi har kanskje hatt mindre frihet til å ta i bruk ulike verktøy og metoder for systemutvikling når vi har hatt en mal å følge, men det har også lettet arbeidet vårt å slippe å analysere og etterprøve egne valg i disse 12

58 Hovedprosjekt Prosessrapport GROOVY & GRAILS CvReg er kodet i et rammeverket Grails, som benytter Groovy som programmeringsspråk. Groovy i seg selv en variant av Java programmeringsspråket. Både Glenruben og Thomas har Java programmering fra HiOA, men ingen hadde jobbet med Grails før prosjektet. Derfor ble det et krav for alle medlemmene i gruppen å sette seg inn i rammeverket fra begynnelsen av prosjektet, for å lære å programmere og jobbe med applikasjonen. Dokumentasjon og opplæringsressurser ble viktig under denne fasen, og en del dokumenter, websider og bøker ble samlet i en fellesmappe så gruppen hadde nok ressurser til å lese seg opp i Grails rammeverket. TWITTER BOOTSTRAP Twitter Bootstrap er et Javascript-bibliotek for å lage dynamiske nettsider på en måte som konfirmerer etter etablerte designstandarder på web, på en enkel og dynamisk måte. Typografi og designelementer i nettsiden er delvis basert på bootstrap. Dette forenklet designprosessen for gruppen da CvReg allerede var etablert med en mal for sidene. Det gruppen skulle fokusere på da var implementering av de nye funksjonene med samme design som selve siden. Alle var kjent med JavaScript og CSS generelt, og derfor vi klarte å tilpasse oss lett til Bootstrap sine funksjoner. MYSQL Databasen i bruk er kjøres på en MySQL server. Databasesystemet er et kraftig og velutviklet verktøy som kan håndtere flere avanserte spørringer samtidig. Samtlige medlemmer i gruppen har erfaring med databaser generelt og MySQL spesifikt. Under utviklingen av applikasjonen har vi kjørt databasen lokalt på utviklermaskinen så vi ikke har vært avhengige av tilgang til en ekstern database for å kjøre applikasjonen, men å endre databasetilkoblingen i Grails er trivielt. 13

59 Hovedprosjekt Prosessrapport 3.2 Læringsverktøy En stor del av prosjektet har bestått i å lære ny teknologi og å bli kjent med nye løsninger, konvensjoner og konsepter. Et fremmed fullstack web-rammeverk kan være ganske omfattende, og det å sette seg inn i alle særegenheter og detaljer i et slikt er et tidkrevende prosjekt som det er mye jobb bak å gjøre mer eller mindre på egen hånd. I andre fag med tilsvarende arbeidsmengde og scope har man kontinuerlig veiledning og gjennomgang av ideer, konsepter og teknikker. Vi har lært alt selv. Samtidig har vi naturligvis fått hjelp. Det finnes mange gode kilder til informasjon og kunnskap på nettet, i den tekniske litteraturen og fra veilederne våre har vi også fått uvurderlig hjelp - og et par kjepper i hjulene, for å holde det hele interessant. Spesielt har Øyvind Marthinsen vært veldig verdifull i det å utføre oppgaven etter beste praksis. Han hjalp oss blant annet med å refaktorere koden midt i prosjektet, til en langt finere granulitet og en mer oppdelt programstruktur. Gjennom å jobbe med denne refaktoreringen var det mye lettere å se "Grails-måten" å gjøre ting på. Vi har funnet svar på mange kryptiske feilmeldinger og mystiske stack-traces på nettsiden StackOverflow. Det er en risiko forbundet med å lytte blindt til rådene fremmede er glade i å overlevere på internett - de har ikke nødvendigvis alltid rett - men det er også mange enormt kompetente utviklere som gir gode råd til lærevillige studenter. Den offisielle dokumentasjonen til Grails (The Grails Framework, 2013) har imidlertid vært den aller viktigste kilden i arbeidet og læringen vår. På nettsiden grails.com finner vi både en grundig og konsis forklaring av alle tags, biblioteker, funksjoner og lure løsninger i rammeverket. Alt er godt forklart og har eksempler og illustrasjoner der det trengs, og det er godt sortert og søkbart. På den samme siden kan man også finne en brukermanual som forklarer mer abstrakte begreper og sammenhenger i dette systemet. Ulike uforutsigbare særegenheter eller "gotchas" som de kalles, er også godt dekket i dette materialet. 14

60 Hovedprosjekt Prosessrapport Det finnes også en håndfull godt skrevne bøker som tar for seg Grails og umiddelbart omliggende teknologier. Ulempen med trykte medier i forbindelse med dette systemet er at det utvikles raskere enn det gis ut bøker. Informasjonen i mange av bøkene er ofte utdatert innen det er kommet ut av trykkpressen, og når det har gått et år etter trykking er mye av informasjonen så gammel at den er ubrukelig, eller skaper mer problemer enn den løser. Dette kan kanskje sies om informasjon man finner på nettet også. Man må være nøye på å lese når ting har blitt skrevet, og ta høyde for at rammeverket kan ha blitt drastisk endret siden den gang. Løsninger på problemer som tidligere var innfløkte og krevde mye arbeid og innsats for å implementere og forstå, kan nå ha blitt løst av utviklerne av rammeverket slik at den "moderne" løsningen enten bare er en enkelt kommando, eller at den er blitt en del av konvensjonen og at problemet aldri oppstår i første omgang. Bøker vi har brukt under utviklingsarbeidet: Groovy and Grails Recipes (Abdul-Jawad, 2008) The Definitive Guide to Grails 2 (Brown, 2013) The Pragmatic Programmer: From Journeyman to Master (Hunt, 1999) 3.3 Prosjektverktøy En del programvarer har blitt tatt i bruk for å utvikle CvReg Tilbud, de fleste er enkle programvarer for logistikk og organisasjon av arbeidet som. Øvrige programmer har vært mer kritiske og har ført til både fordeler og ulemper som har hatt noe påvirkning på selve prosjektet. 15

61 Hovedprosjekt Prosessrapport GOOGLE APPS. Kommunikasjon med oppdragsgiver har vært kritisk under hele utviklingen. Spesielt siden gruppen ikke kjente til Grails i begynnelsen av prosjektet så har det vært viktig å kunne ha enkel tilgang til veilederne på Knowit for å kunne samarbeide i startfasen. Heldigvis visste det seg at både medlemmene i gruppen og Knowit bruke Google sine kontorløsninger fra før. Med løsningen fikk vi lage en mailingliste mellom Knowit og gruppen som tillot en åpen dialog under hele prosjektet og møteplanlegging via Google Docs. Den løsningen har derfor vært kritisk for å sikre det kontinuerlig samarbeidet mellom oppdragsgiver og gruppen. GIT Knowit har også en Git server allerede satt opp for sine prosjekter, blant annet for CvReg. De har laget en gren for CvReg Tilbud prosjektet. Med et felles miljø har Knowit hatt mulighet til å følge med utviklingen til gruppen og holde CvReg oppdatert på tvers av prosjektene da noen av konsulenter jobber med andre prosjekter for applikasjonen. Til tross for fordelene så har Git presentert noen ulemper for gruppen da vi har opplevd flere ganger problemer med å holde commitene synkronisert og noen ganger opplevd at den ene gruppemedlemmet endte opp med en versjon av CvReg Tilbud som ikke virket som det skulle. Gruppen kunne ha valgt en annen løsning men da hadde vi også mistet den direkte tilbakemeldingen vi får fra Knowit, og de den komplette loggføringen til utviklingen av CvReg Tilbud. ECLIPSE Gruppen var friere i valget på utviklingsmiljø. Arbeidsgiver satte ingen krav til utviklingsverktøy og vi stod fritt til å bruke hva vi ville. Opprinnelig valgte vi Groovy & Grails Tool Suite som er en ferdig satt opp versjon av Eclipse for Grails utvikling. Den er laget av utviklerne av Grails for å forenkle introduksjonen til rammeverket for nye brukere og kommer 16

62 Hovedprosjekt Prosessrapport med den nyeste versjon av både programmeringsspråket Groovy og alle filer som trengs for å kompilere Grails prosjekter, med unntak av et Java utviklingsmiljø. Den hadde alle de grunnleggende funksjonene og Git integrasjon nødvendig for prosjektet men det visste seg ved slutten av utviklingsfasen at noen av ulempene til dette programmet var mer omfattende enn det vi så for oss i begynnelsen. INTELLIJ IDEA Omtrent halvveis ut i prosjektet kom vi over et utviklingsmiljø som etter noe utprøving viste seg å være langt overlegent Eclipse på de aller fleste områder, når det kom til Grails utvikling i den situasjonen vi var i. IntelliJ IDEA har bedre kodefullføring, bedre minnehåndtering innad i programmet, raskere ytelse, langt bedre håndtering av versjonskontroll, bedre grensesnitt og en lang, lang rekke små, snedige funksjoner som gjør det mindre arbeidskrevende å skrive effektiv kode. Vi testet dette programmet noe før vi raskt konkluderte med at det var verdt å bytte over til dette miljøet, og så oss ikke tilbake. 17

63 Hovedprosjekt Prosessrapport 4.0 PLANLEGGING AV LØSNINGEN 4.1 Utredning av prosjektet - Planleggingsfasen Ut ifra kravspesifikasjonen (vedlegg ##) utformet vi en forprosjektrapport, som forklarte hva målet med prosjektet skulle være. Et viktig poeng i kravspesifikasjonen og i forprosjektrapporten, var at vi skulle dele prosjektet i to milepæler. Første milepæl skulle være selve utviklingen av de grunnleggende funksjonene for CvReg Tilbud. Denne milepælen ble målet for selve prosjektet, og vi var nødt til å fullføre denne for at prosjektet skulle være vellykket. Ved vellykket utføring av milepæl én, skal CvReg Tilbud kunne implementeres i CvReg applikasjonen, og ha de viktigeste funksjonene implementert. Disse funksjonene er å kunne legge nytt tilbud med prosjektleder og medlemmer; kunne redigere og slette tilbudet; og legge til et medlem i tilbudet via CV siden. Milepælen ble definert for å være enkel nok, slik at gruppen skulle klare å implementere den innenfor fristen, men samtidig avansert nok til at Knowit fikk et nytt, komplett og fungerende verktøy, deres selgere kunne bruke. Basert på hvor vellykket milepæl 1 skulle bli, og hvor mye kompetanse gruppen klarte å bygge opp underveis i utviklingen, ble det dannet en milepæl 2. Denne milepælen var ikke et krav fra Knowit sin side at måtte bli fullført, men fungerte heller som en pekepinn for den eventuelle videre utviklingen av applikasjonen. Det var i uke 5, siste uken i januar, at vi hadde vårt første interne Scrum møte innad i gruppen. Dette for å kartlegge det som skulle være første sprint. 18

64 Hovedprosjekt Prosessrapport 4.2 Design av CvReg Tilbud Rammene for designet for CvReg Tilbud var ganske klare. Da modulen skulle implementeres i den allerede eksiterende CvReg applikasjonen. Til designet av modulen vi utviklet, benyttet vi de grunnleggende grafiske funksjonene som: knapper, oppsett, søkefelter ol, som allerede var integrert i applikasjonen via Bootstrap. Lokale justeringer var nødvendig for å tilpasse de eksiterende CSS og Bootstrap filene til selve CvReg Tilbud modulen, men ingen nye grafiske elementer har vært implementert i applikasjonen under utvikling. 19

65 Hovedprosjekt Prosessrapport 5.0 UTVIKLINGSFASEN Vi benyttet oss av en forenklet versjon av utviklingsmetoden Scrum. Dette var først og fremst et ønske fra Knowit sin side, da dette var den metoden de selv hadde benyttet i sin utvikling fra før av. De ble veldig glade da de lærte at det var nettopp denne metoden vi selv foretrakk å jobbe etter også. Generelt sett klarte vi bra å følge denne metodens prinsipper. Vi brukte Jira flittig til å definere pakkene som skulle utføres. Hver pakke i Jira er definert med blant annet et navn, en beskrivelse, en dato for når den skal vøre ferdig, eventuelt hvem det er som skal utføre den og hvilken type pakke det var. Til tider hadde vi veldig god flyt i arbeidet vårt, kanskje aller mest i starten av prosjektet og mot slutten av prosjektet. Dette har nok en sammenheng med at vi hadde noen kommunikasjonsproblemer med et medlem en stund ute i prosjektet, og at en del av tiden vår gikk med på å løse denne konflikten som oppstod. Når en ser på fremdriftsplanen klarte vi ikke å følge ene 100 prosent. Da vi av og til ikke hadde like gode muligheter for å jobbe sammen, ble noen av sprintene litt mer flyende, og gli noe over i hverandre. Vi lærte etter hvert at det ikke alltid trenger å gå helt etter planen, og at det kan straffe seg senere i prosjektet om en er for unøyaktig med å forholde seg til det planlagte. Vi ble hengende noe etter fremdriftsplanen vi hadde utformet i planleggingsfasen (se figur ##), som resulterte i en mer hektisk periode mot slutten av prosjektet. Under følger en forkortet beskrivelse av de sprintene vi hadde i løpet av prosjektet. Vi har prøvd å trekke frem de mest essensielle delene for hver sprint. 20

66 Hovedprosjekt Prosessrapport 5.1 Første sprint (uke 5-6) I risikoplanen vi lagde under planleggingsfasen, vi så at sykdom (på grunn av sesongen og været), og manglende kompetanse på grunn av ukjent rammeverk, kunne være de største utfordringene i begynnelsen av utviklingen. Vi brukte første sprint til å lære oss Grails og bli bedre kjent med koden av CvReg applikasjonen. Samtidig fikk vi også jobbet med bedre kjente miljøer som MySQL DB, generell Java syntax, HTML, CSS for å nevne noen. 5.2 Andre sprint (uke 7-8) Glenruben og Thomas, som kunne objekt orientert programmering fra før, kunne starte med utviklingen av CvReg Tilbud allerede under sprint to. De fikk lagt til CvReg Tilbud i applikasjonen CvReg og opprettet nødvendige klasser, som genererte de nye tabellene i databasen. I mellomtiden fortsatte Sebastien og sistemann på gruppen (før personen forlot gruppen), med å lære seg Grails og generelt sette seg i programmeringen av applikasjonen. 5.3 Tredje sprint (uke 9-10) Sprint 3 ble brukt til designet av CvReg Tilbud. Det var viktig at de nye funksjonene skulle blende seg sømløst inn i CvReg applikasjonen, for å beholde en konsistens gjennom hele brukergrensesnittet. Det var også under denne sprinten (da vi fortsatt drev med grunnleggende programmering), at vi merket at fjerdemann begynte å ligge lenger bak i forståelsen av applikasjonen, og i forståelsen av programmeringsspråkene vi benyttet i den, enn resten av gruppen. Han ble mindre og mindre tilgjengelig og slet med å følge med under utviklingen. Dette skapte problemer for gruppen generelt da deler av arbeidet som var forventet utført under sprinten, ikke ble gjort. Det var ikke kritisk ennå i 21

67 Hovedprosjekt Prosessrapport forhold til prosjektet i sin helhet, men vi visste at det var kritisk å forsikre oss om at han holdt seg aktiv og klarte å følge med. 5.4 Fjerde sprint (uke 11-12) Vi tok situasjonen som oppstod med det ene gruppemedlemmet videre, der vi ga ham mindre oppgaver for å lette litt på trykket, for å hjelpe han med å bli bedre kjent med applikasjonen. Dessverre allerede i midten av denne uken så vi de samme tegnene av mangel på arbeid, forståelse for applikasjonen og større fravær gjenta seg. Derfor, da vi hadde møte med veileder uken før påske, forklarte vi situasjonen vi hadde havnet i. Han anbefalte oss å hjelpe han en gang til etter å ha hatt en samtale med han. Denne uken fikk vi hjelp fra Knowit, ved at de pushet en hjelpebrach til oss i Git, slik at vi fikk svar på noen av de spørsmålene vi hadde i forhold til noe av programmeringen. Dette var i all hovedsak noen problemer vi hadde hatt med å få vanlige AJAX kall til å fungere. 5.5 Femte sprint (uke 13-14) Lite ble gjort under Sprint 5 som påskeukene. Vi brukte en del av tiden til å hjelpe sistemann med å komme i gang igjen med prosjektarbeidet. Vi stilte noen spesifikke krav til hva vi forventet av han under sprinten for å kunne fortsette som et medlem i gruppen. Hele denne situasjonen ville vært mye enklere om vi bare hadde laget en konkret arbeidsavtale helt i starten av prosjektet. Dette har vi nok alle fire lært av. Dessverre var ikke de siste forsøkene på å hjelpe den fjerde deltageren inn i gruppa igjen vellykkede. Det var i grunn ikke bare kunnskap og ferdigheter som avgjorde utfallet av konflikten. Men ett alt for stor fravær og for lite deltakelse, gjorde at personen selv valgte å trekke seg fra samarbeidet. Videre denne sprinten endret vi på hele strukturen i koden vår. Dette gjaldt da kontrollerne og klassene tilknyttet CvReg Tilbud. Samtidig endret vi på klassenes relasjoner til hverandre, slik at databasen også 22

68 Hovedprosjekt Prosessrapport ble oppdatert og tilpasset for den nye strukturen. Vi oppdaget også forøvrig en feil i DB scriptet vårt, som poppulerte databasen vår med testdata. 5.6 Sjette sprint (uke 15-16) Med under to måneder igjen til fristen var det viktig å organisere gruppen for å fordele resten av arbeidet mellom medlemmene. Glenruben og Thomas tok seg av storparten av CvReg Tilbud siden, mens Sebastien jobbet med implementering av tilbud funksjonen i CV siden av CvReg applikasjonen. 5.7 Syvende sprint (uke 17-18) Etter møtet med Knowit, fikk vi satt strengere mål for sprintene, for å sikre oss at vi skulle klare å fullføre milepæl én innen fristen som var om cirka en måned. Vi fikk ferdiggjort det meste som hadde med å opprette, endre og slette proposals Åttende sprint (uke 19-20) Vi hadde frist 12. mai for å fullføre koden, dette var i midten av denne sprinten. Vi klarte å bli ferdige med de viktigeste funksjonene av milepæl 1, men det var fortsatt noen deler av applikasjonen som trengte forbedring. Vi begynte å jobbe med dokumentasjonen parallelt i løpet av denne sprinten. 5.9 Niende Sprint (uke 21-22) Siste uken før innlevering ble brukt til å jobbe med prosjektrapportene. Siste sprintmøte med Knowit og endelig presentasjon av arbeidet med applikasjonen var onsdag 22. mai. Siden det fortsatt var noen 23

69 Hovedprosjekt Prosessrapport smådeler av koden som måtte forbedres, jobbet som regel en av medlemmene med koden mens de to andre skrev rapportene. Rapporten ble fullført i løpet av helgen. 24

70 Hovedprosjekt Prosessrapport 6.0 UTFORDRINGER OG UFORUTSETTE SITUASJONER 6.1 Omorganisering av gruppen En viktig del av dokumentasjonen som ble oversett i begynnelsen av prosjektet var arbeidsavtalen. Dette burde ha vært spesielt viktig for en gruppe sammensatt av personer som ikke kjente hverandre fra før. Siden gruppen ble formet så sent i forhold til prosjektet (ikke før desember rett før semesterslutt), fokuserte vi mer på å finne oss et prosjekt og overså hele arbeidsavtaledelen. Selv under risikoplanleggingen anså vi frafall som en lav risiko, og det var noe vi ikke var spesielt bekymret over så tidlig i prosjektet. Da problemene med det ene gruppemedlemmet inntraff, hadde vi ingen konkret ramme for hvilke krav hvert enkelt medlem skulle oppfylle med tanke på arbeidsmengde, ytelse og bidragsformer. Situasjonen endte opp med et frafall etter samtaler mellom medlemmene og gruppens veileder fra skolen. Dette viser definitivt hvor viktig det er med arbeidsavtaler, selv i mindre prosjekter. Frafall i gruppen betyr også en person mindre til å utføre arbeidet som var planlagt for fire. Derfor var det viktig for gruppen å tilpasse arbeidsmengden for de resterende gruppemedlemmene. Vi gjennomgikk utviklingsplanen for å forhindre at prosjektet ble forsinket. Dessverre var dette noe som ikke helt gikk som vi hadde ønsket. Selve kodingen av prosjektet var tyngre å få fullført enn det vi hadde sett for oss, og da med ett gruppemedlem mindre tok dette en del lengre tid. 25

71 Hovedprosjekt Prosessrapport 6.2 Utfordringer underveis i utviklingen Under de forskjellige fasene av utviklingen kom vi over noen større og mindre utfordringer. Siden vi jobbet med et nytt rammeverk, måtte vi brukte mye tid på å lære oss konvensjonene i Grails. Disse krevde at vi strukturerte kode på en annen måte enn det vi i utgangspunktet hadde sett for oss når vi startet prosjektet. Å finne assistanse og alternative løsninger i ressursene vi hadde samlet inn, var essensielt for læringsutbyttet av prosjektet. Det var i grunn da vi møtte de største utfordringene vi lærte mest. Selv om det kunne ta en hel dag å løse en gitt problemstilling og vi ikke fikk noe brukbar kode ved endt arbeidsdag, hadde vi fortsatt lært mye. Det kan trygt sies at det var når vi møtte de store problemene at kunnskapen kom på plass. 6.3 Problemer med inkompatibilitet i MySQL-databasen I en periode på to uker i midten av mars stod vi fullstendig fast i utviklingen. Vi var kommet så langt at vi fikk opprettet tilbud, fikk presentert dem i nettleseren, og bekreftet at dataene lå i databasen. Imidlertid var det langt vanskeligere enn vi trodde å få Grails sitt databasehåndteringssystem til å generere mange-til-mange forhold mellom CV-er og Tilbud slik vi ville ha det. Grails bruker Hibernate, et kraftig rammeverk til å håndtere databasegenerasjon og struktur. Tabeller og relasjoner bygges ut ifra konvensjoner og konfigurasjon i klassene. For å få til et sant mange-til-mange forhold måtte vi konfigurere Grails på en helt spesifikk måte, og mye av dokumentasjonen vår var selvmotsigende når det kom til dette punktet. Når vi trodde vi hadde alt på plass og hadde konfigurert alt riktig, fikk vi imidlertid denne feilen hver gang vi prøvde å skape en kobling mellom de to tabellene: ERROR 1452: Cannot add or update a child row: a foreign key constraint fails (CvReg_utv.cv_proposals, CONSTRAINT FK17D946F55677A672 FOREIGN KEY (cv_id) REFERENCES CV (id)) 26

72 Hovedprosjekt Prosessrapport Etter mange lange kvelder med debugging, feilsøking og diskusjoner fant vi til slutt ut at denne feilen var forårsaket av et test-datasettet. Den hadde vi fått av oppdragsgiver for å populære databasen som applikasjonen bygger lokalt. Det visste seg at den hadde feil format på enkelte datafelter. Felter som Grails oppretter i databasen blir per standard generert i InnoDB formatet. I et tidligere prosjekt hadde utvikleren vi var i kontakt med hos arbeidsgiver, riktignok benyttet seg av MyISAM strukturen i sin database. All testdataen vi fikk fra han var dermed i dette formatet. Det fungerte uten feilmeldinger, helt frem til vi skulle forsøke å binde en tabell i InnoDB sammen med en tabell i MyISAM - da ble det en konflikt mellom formatene. Vi brukte mye tid på å lokalisere denne feilen. 6.4 Vanskeligheter med å få fjernet koblinger Når vanskelighetene rundt å legge til CV-er som medlemmer i et tilbud var løst, gjenstod utfordringen med å fjerne koblingene mellom tilbud og CV. Dette tok heldigvis noe kortere tid å løse. I et 1-til-n forhold kan man bruke en enkel kommando for å endre en verdi på et datafelt i objektet for å fjerne koblingen. I et mange-til-mange forhold har man en koblingstabell som blir generert av Grails, og som det ikke er mulig å påvirke direkte. Vi prøvde utallige varianter av "CV.Proposal.Delete" og "CV.remove(Proposal)" før vi til slutt fant ut at løsningen igjen lå i dynamiske metoder. I dokumentasjonen blir de imidlertid bare referert til som dynamiske kall, så dette sendte oss på avveie. Vi fant til slutt ut at løsningen var å beskrive handlingen i kontrolleren som "CV.removeFromProposal(Proposal)" løste problemet og fjernet koblingen uten problemer. Se use casen i produktdokumentet for et eksempel på hvordan et slikt kall genereres. 6.5 Problemer med slette tilbud Når vi hadde løst utfordringen med å fjerne relasjonen mellom en CV og et tilbud, gjenstod utfordringen med å fjerne hele tilbudet. Relasjonsdatabasen er satt opp slik at et tilbud som har noen koblinger til en annen tabell ikke kan slettes. Dette er en konsekvens av at vi har valgt den noe tornete 27

73 Hovedprosjekt Prosessrapport ruten å la Hibernate-rammeverket håndtere mange-til-mange relasjonene våre. I et 1-til-n forhold kan man sette opp klassen med noe som heter "cascading deletes". Dette innebærer at når man sletter et "child"-element, slettes alle relasjoner til dette i samme operasjon, forutsatt at man utfører operasjonen riktig. Dette er det understreket mange ganger igjennom all dokumentasjon at ikke er mulig å gjøre i et mange-til-mange forhold, fordi det ville blitt forsvinnende lett å fjerne hele databasen bare med en skrivefeil. Dermed stod vi igjen med spørsmålet "Jammen, hvordan skal vi få det til da?" Det var klart at vi måtte bruke en "foreach" løkke for å oppnå dette resultatet. Vi trengte da å gå gjennom en liste med alle oppføringene av en CV som hadde tilhørighet til et tilbud, og fjerne tilhørigheten en etter en. Problemet var at hvis vi gjorde dette på den mest innlysende måten - bare med en foreach-løkke - så ble operasjonen kun utført på det første elementet i listen, før det stoppet opp med en feilmelding om at datarepresentasjonen i minnet ikke stemte overens med representasjonen i databasen. Løsningen var å finne på en godt bortgjemt bloggpost som en av utviklerne av Grails hadde skrevet. Vi var nødt til å lage et nytt array, legge til alle de relevante CV-ene, og iterere igjennom dette arrayet. Dermed ble det ingen feilrepresentasjon i GORM sin håndtering av objekter siden objektene lå i et separat array, og alle koblingene ble fjernet fra databasen. Deretter kunne det tomme tilbudet slettes. 28

74 Hovedprosjekt Prosessrapport 8.0 OPPSUMERING 8.1 Funksjonell Evaluering Etter nesten 3 måneder med arbeid har gruppen klart å implementere CvReg Tilbud modulen i CvReg applikasjonen. Modulen ble presentert for Knowit i løpet av uke 21 for å bekrefte den vellykkede implementeringen av koden i CvReg applikasjonen. Det var under møtet at vi fikk vite at selve applikasjonen skulle lanseres på nasjonalt nivå i løpet av sommeren, og dermed skal CvReg Tilbud settes i drift om kort tid. Selv om CvReg Tilbud kan brukes i sin nåværende form, fant vi ut under møtet at det fortsatt finnes rom for nye funksjoner og andre forbedringer. Informasjonen ble lagt inn i produktrapporten som blir videresendt til Knowit sine interne utviklere. Vi ser for oss at modulen er et godt grunnlag for Knowit å videreutvikle applikasjonen med, og forenkle hverdagen til sine ansatte. 8.2 Faglig oppsummering Oppgaven i seg selv endte opp med å være mer krevende enn opprinnelig forventet i begynnelsen av prosjektet. Den krevde mye av kunnskapen vi hadde tilegnet oss de siste tre årene, men krevde enda mer av læreevnene våre for å klare å mestre Grails på så kort tid. 29

75 Hovedprosjekt Prosessrapport Uansett klarte vi å nå hovedmålet vårt, som var milepæl én, og vi lærte oss et nytt rammeverk, med en delvis helt ny programeringssyntaks. Muligheten vi fikk til å jobbe tett med et profesjonelt IT konsulent firma, ga oss et verdifullt innblikk i et profesjonelt programmeringsmiljø, som vi lot oss bli inspirert av. 30

76 Hovedprosjekt Prosessrapport 9.0 LITTERATURLISTE The Grails Framework - Reference Documentation. San Mateo, CA: GoPivotal, Inc. < [Lesedato ] Abdul-Jawa, Bashar (2008). Groovy and Grails Recipes (Expert s Voice in Open Source). New York, NY: Apress. Brown, Jeff Scott & Rocher Graeme (2013). The Definitive Guide to Grails 2. New York, NY: Apress. Hunt, Andrew & Thomas, David (1999). The Pragmatic Programmer: From Journeyman to Master. Boston MA: Addison-Wesley Professional. 31

77 V. VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD GRUPPE 36 FORFATTERE: N O RDENGEN, THOMAS LA R S E N, GLE N R UB E N E. S TEEN, SEB AS T IE N -J EROME 1

78 INNHOLDSFORTEGNELSE VEDLEGG 1 KRAVSPESIFIKASJON VEDLEGG 2 BRUKERMANUAL VEDLEGG 3 TESTRAPPORT VEDLEGG 4 USE CASE VEDLEGG 5 - SEKVENSDIAGRAM

79 VEDLEGG 1 KNOWIT CVREG GRUPPE 36 K R A V S P E S I F I K A S J O N H O V E D P R O S J E K T VÅR 2013 FORFATTERE: N O RDENGEN, THOMAS LA R S E N, GLE N R UB E N E. S TEEN, SEB AS T IE N -J EROME [ F R AFALT MEDLEM] V.3 D AT O:

80 Innhold 1. Prosjektbeskrivelse Innledning Om hovedprosjektet Om Bedriften Innføring i hovedprosjektet Arbeidsmetodikk Rammebetingelser Suksesskriteria Antagelser Kravspesifikasjon Funksjonelle krav Ikke funksjonelle krav krav til dokumentasjon Krav til kvalitetssikring Mål og videre utvikling Milepæl Øvrige milepæler

81 5

82 1. Prosjektbeskrivelse Hovedprosjekts tittel: Utvikling av CvReg Beskrivelse: Videreutvikle og implementere nye funksjoner i Knowit sin egenutviklede ansattdatabase, CvReg Prosjektgruppe: Gruppe 36 Prosjektdeltakere: Glenruben Engen glenruben@gmail.com Thomas Nordengen metalthomas@gmail.com Sebastien-Jerome Steen sebastien.steen@gmail.com [Frafalt medlem] Veileder: Steinar Johannesen steinar.johannesen@hioa.no 6

83 Oppdragsgiver: Knowit Kontaktpersoner: Sigmund Marius Nilssen Øyvind Marthinsen Jon Marius Håkedal 7

84 2. Innledning 2.1 Om hovedprosjektet Hovedprosjektet ved Høgskolen i Oslo og Akershus er et fag på slutten av bachelorstudiene til de forskjellige datalinjene for å sette i praksis kunnskapen studentene har ervervet under de tre årene med utdanning. Gruppe 36 er formet av tre studenter fra anvendt datateknologi og én fra Informasjonsteknologi. De har fått anledningen til å jobbe sammen med IT konsulentfirmaet Knowit, der de skal videreutvikle en databasebasert webside Knowit har utviklet til eget bruk. 2.2 Om Bedriften Knowit er et av de ledende konsulentfirmaene i nordeuropa med over 1700 ansatte spredt over fem land. Siden sin stiftelse i Sverige i 1990 har Knowit spesialisert seg på informasjonsteknologi og digitale tjenester. Knowit Norge har over 300 ansatte og har i de siste årene klart å utvide seg i fire byer rundt i Norge og jobbe sammen med noen av Norges største bedrifter og organisasjoner. 2.3 Innføring i hovedprosjektet Knowit Norge har et eksisterende system for registrering av ansattes CV er. Det er et webinterface for å registrere arbeidserfaring, kompetanseområder og informasjon om hver enkelt ansatt på en måte som er enkelt søkbart og lett tilgjengelig både for utviklere og selgere. Disse kan eksporteres som PDF, ODT eller DOCX format, for å sendes ut til potensielle kunder eller brukes internt i bedriften. Det er altså to grupper av brukere i dette systemet: Brukere: Utviklere registrerer sine CV er med detaljer som skal være likt formulert for alle ansatte. Forskjellig informasjon fylles inn i et system som lager en pent formatert CV. Administratorer: Selgere søker på relevante kompetanse og erfaringer og hente ut alle CV ene de trenger til et tilbud til en ekstern aktør. Dette gjøres i dag manuelt. 8

85 I dag eksisterer det ingen funksjonalitet i dette systemet for å samle sammen flere CV er til et team, eller et tilbud. Dette må gjøres manuelt, noe som gjør det vanskelig å ha oversikt over hvilke ansatte som er tilgjengelige, det gjør det tungvint for enkeltpersoner å ha oversikt over hvem som er inkludert i et tilbud, og ekstra tungvint å knytte personer til et tilbud, og presentere og sende dette rundt internt i bedriften. 2.4 Arbeidsmetodikk I og med at prosjektet er en skoleoppgave i regi av HiOA, som omfatter arbeidsverktøy som er i daglig drift og bruk hos Knowit, er det viktig å balansere både den akademiske tilnærmingen ved oppgaveskrivingen og den praktiske utviklingen av Knowit sin webapplikasjon. Vi har derfor valgt å organisere prosjektet ved hjelp av Scrum rammeverket, da det skal gi oss mulighet til å følge opp utviklingen både i henhold til oppgaven for høyskolen, og som del av kommunikasjon og kartlegging av utviklingen med Knowit. 3. Rammebetingelser 3.1 Suksesskriteria Under følger en liste over kriterier som er nødvendige for at prosjektet skal bli vellykket: - Oppdragsgiver må stille nødvendige ressurser tilgjengelig i alle de de forskjellige fasene av prosjektet - Prosjektmedlemmene må opprettholde aktiv kommunikasjon internt - Prosjektmedlemmene må holde seg til de mål og aktiviteter som gjelder i det gitte tidsrommet - Minimale endringer i forhold til planlegging 9

86 - Opprettholde aktiv dialog med oppdragsgiver og veileder 3.2 Antagelser Forutsetning: - Det forutsettes at kunden gir tilgang til kildekoden - Det forutsettes at funksjonene integreres i det eksisterende systemet - Tilgang til databasen for å implementere funksjonene korrekt - Løsningen skal utformes med plattformuavhengighet i fokus - Detaljert kravanalyse frem til design - Løsningen må være 100% web-basert - Oppdatering av eksisterende rutiner er ikke en del av prosjektet - Tidsfrist for fullført prosjekt er 26. mai - Arbeidet skal dokumenteres nøye i form av dokumenter og data-modeller, slik at systemet enkelt kan videreutvikles av andre i fremtiden - Det må lages gode testrutiner for funksjonaliteten, for å sjekke at alt virker og å se at det fungerer godt sammen med eksisterende funksjoner Begrensninger: CvReg bygger på Groovy og Grails, Javascript og LessCSS som sine hovedkomponenter. Det er også brukt HTML utvidet med spesielle «tags» for Grails. CvReg knytter seg mot MySQL og Crowd for henholdsvis database og brukere. Arbeidsmiljøet blir også begrenset til bruken av Windows 7 og Grails sin tilpasset versjon av Eclipse så medlemmene lettere kan hjelpe hverandre under utviklingen. 10

87 Knowit sine systemer og servere blir brukt for mye av arbeidsdokumnteringen. Dette forsikrer at prosjektet alltid har en fullverdig back-up av kildekode og dokumentasjon, og at arbeidsgiver har fullt innsyn i arbeidet. Gruppen har totalt 1600 arbeidstimer til rådighet for planlegging, utvikling og produksjon av prosjektrapporten, fordelt på 4 medlemmer og 20 arbeidsuker. 4. Kravspesifikasjon 4.1 Funksjonelle krav -Kun administrator skal kunne endre, slette, deaktivere og opprette Tilbud -Alle brukere skal ha mulighet til å lese alle tilbud -En bruker skal enkelt få en oversikt over alle tilbudene han er oppført i -Systemet skal kunne liste alle eksisterende, (aktive og inaktive) tilbud -Administratorer skal også kunne legge til og fjerne CV fra tilbud -Et tilbud skal ha følgende egenskaper: *Navn *Beskrivelse *Oppstartsdato *Sluttdato for tilbudet *Ansvarlige personer for tilbudet ved navn, (én til mange i CvReg) *En timeoutfunkjson som setter tilbudet inaktivt etter ønsket tid. 4.2 Ikke funksjonelle krav - Systemet må ha en tilgjengelighet på 99,5% - Responstid for nøkkelhandlinger bør ikke overstige 3 sekunder 11

88 - Web-grensesnittet må fungere mot Internett Explorer 9.0, Firefox 18.0, Google Chrome , og Opera Safari er ikke med i kvalitetssikringen, men skal være dekket av Google Chrome da begge bruker WebKit - Datasystemet skal sikres mot innsyn av uautoriserte personer 12

89 4.3 krav til dokumentasjon - Planlegging, organisasjon og oppfølging skal dokumenteres i Jira - Praktiske dokumentasjoner og veiledninger skal dokumenteres i Confluence - Kildekode og historikk skal dokumenteres via Git - All systemdokumentasjon skal lagres og oppbevares på Knowit sine servere 4.4 Krav til kvalitetssikring - Der det er hensiktsmessig skal det under utvikling skrives enhetstester for ny og endret kode - Prosjektgruppen utfører funksjonell testing underveis, minst før hvert demomøte og før milepælsleveranser - Prosjektgruppen gjennomfører demomøter for Knowit som avslutning av hver sprint - Knowit utfører akseptansetest og code-review etter milepælsleveranser 5. Mål og videre utvikling 5.1 Milepæl Vi har lagt opp en konkret plan på hva som skal utføres i løpet av de neste ukene. Dette er det absolutte minimumskravet for at prosjektet skal anses som vellykket, men skal ikke anses som en begrensning av utviklingen. Hvis milepælen kan bli nådd i god tid og med nok ressurser, vil prosjektet utvides med nye milepæler og oppgaver. Hovedmålet er å utforme en ny variabel kjent som «Tilbud» som skal integreres i databasen sammen med de andre funksjonene: Et Tilbud skal minimum inneholde: o o Navn på tilbudet Beskrivelse av tilbudet 13

90 o o o Oppstartsdato Sluttdato (Når tilbudet skal inaktiveres?) CVer inkludert i tilbudet En CV (bruker) skal være ansvarlig for tilbudet. Systemet skal kunne utføre følgende handlinger: o o o o o o Liste over opprettede tilbud: skal være synlig for alle. Sorteres i: Aktive, inaktive, alle med Aktive som default. Evnt: Lage pen presentasjon med kort oppsummering av tilbudet & bilder av personer som er inkludert. Legg til nytt tilbud: Synlig for Admin Knapp på liste over tilbud knapp i alle popup-lister over tilbud på ernkeltcv og CVliste Redigere tilbud: Synlig for Admin endre navn på tilbud endre hvem som er ansvarlig for tilbud Deaktiver tilbud: Synlig for Admin Kun tilgjengelig på tilbudssiden Legg CV til tilbud: Synlig for admin Knapp på hver enkelt CV Knapp på liste over tilbud Knapp på liste over CVer Fjern CV fra tilbud: Synlig for admin 5.2 Øvrige milepæler Så lenge første milepæl ikke skaper større utfordringer enn forventet, skal gruppen ha kapasitet til å utvide funksjonalitet utover hovedmålene. Hovedoppgaven utvikles med fokus på å gjøre fremtidig utvikling smidig. Følgende er tjenester som har blitt vurdert å implementeres hvis tid og ressurser tillater det: - Advarsel om at CV allerede er inkludert i annet, aktivt tilbud. - Funksjon for å laste opp vedlegg til et tilbud (pdf, bilder, video, etc ) 14

91 - Funksjon for å laste ned alle CVer i et tilbud som zipfil - Disse og andre mulige løsninger, endringer eller forbedringer som kan bli utviklet under prosjektet, blir eventuelt kartlagt under sprintmøter og dokumentert derfra. 15

92 16

93 VEDLEGG 2 KNOWIT CVREG GRUPPE 36 B R U K E R M A N U A L H O V E D P R O S J E K T VÅR 2013 FORFATTERE: N O RDENGEN, THOMAS LA R S E N, GLE N R UB E N E. S TEEN, SEB AS T IE N -J EROME 17

94 FORORD Dette er e brukermanual for Cv-Reg, og da hovedsakelig for tilbudsmodulen som vi har utviklet, men denne manualen vil også ta for seg andre skjermbilder som er vesentlige for denne modulen. 18

95 INNHOLDSFORTEGNELSE forord BRUKERMANUAL Innlogging i systemet Liste over alle eksisterende tilbud Sortere tilbud Opprette nytt tilbud Vise detaljer Slette en deltager Legge til en deltager Redigerer et tilbud Endre ansvarlig for tilbud Slette et tilbud Legge en CV inn i et tilbud

96 BRUKERMANUAL 1.0 Innlogging i systemet Figur 1.1: Innlogging Det første skjermbildet en møter er innloggings skjermen, denne er veldig enkel, og tilbyr brukeren å taste inn en brukernavn og ett passord. Det er ingen egen innlogging for administratorer. Administratorer logger inn på samme måte, men deres ekstra administrator funksjoner vil ikke være synlig inne i systemet for vanlige brukere. Figur 1.2: Oversikt over CV 20

97 Når korrekt brukernavn og passord er tastet inn, vil brukeren bli sendt til siden som vist over. Dette er CV-oversikten til brukeren. I fra denne side er det mulig via knappen: + Tilbud øverst til venstre i menyen, kunne legge til den respektive CV-en til i et tilbud. Dette vil bli videre beskrevet senere i dokumentet. 2.0 Liste over alle eksisterende tilbud For å navigere seg videre til tilbuds-modulen, trykker en på Tilbud fanen, helt øverst menyen. Figur 2.1: Liste over tilbud Brukeren befinner seg nå i tilbuds-modulen, som gir en oversikt over alle eksisterende tilbud registrert i systemet. 21

98 Figur 2.2: Sortering 3.0 Sortere tilbud Over ser du et bilde av de tre sorteringsmulighetene som denne modulen har. Det er mulig å liste ut tilbud på tre hoved kategorier: Vis alle fanen vil gi deg en liste over alle eksisterende tilbudene, uavhengig om de er aktive eller ikke. Videre er det mulig å sortere på aktive og inaktive. Figur 3.1: Nytt tilbud 22

99 4.0 Opprette nytt tilbud For å opprette et nytt tilbud benyttes Nytt tilbud knappen. Denne vil laste inn en ny side venstre i skjermbildet. Dette er en oversikt over de alternativene denne funksjonen har. Figur 4.1: Nytt tilbud form For å opprette et nytt tilbud er brukeren nødt til å fylle ut de nødvendige feltene i registreringsformen. Foreløpig er det kun navn, startdato og sluttdato som er påkrevd for at et tilbud skal kunne bli opprettet. Klikk Legg til knappen, eller Avbryt knappen for å fortsette. 23

100 5.0 Vise detaljer Figur 5.1: Tilbud detaljer For å få opp informasjon om et tilbud, eller om du ønsker å redigere et tilbud, trykker en på et av tilbudene i oversikten. Dette vil laste inn informasjonen om det valgte tilbudet, samt å tilby brukeren å redigere den informasjonen som finnes om tilbudet. 6.0 Slette en deltager For raskt å lunne slette en deltager fra et tilbud, er et en veldig enkel måte å gjøre dette på. Det er ikke nødvendig å måtte gå inn på redigerings siden for å gjøre dette. En kan enkelt trykke på fjern knappen, som befinner seg til venstre for hvert deltagernavn. Denne knappen vil raskt fjerne en deltager fra tilbudet. Figur 6.1: Legg CV inn i tilbud 24

101 7.0 Legge til en deltager For å legge til en deltager i et valgt tilbud, er det bare å velge navnet til en person i listen, ved å trykke på pil ned tasten, som vist på bildet over. Der etter velger markerer du et ønsket navn ved å klikke på det. Til slutt trykker du på knappen: Legg til i tilbudet. Om litt vil listen over deltager oppdateres automatisk, og den nye personen vil være lagt til i tilbudet. 8.0 Redigerer et tilbud Figur 8.1: Rediger tilbud For å redigere et tilbud, trykk på Rediger tilbud knappen som vist over. 25

102 Figur 8.2: Rediger tilbud form I Rediger Tilbud siden vil du finne den totale oversikten over et tilbud, samt muligheten for å kunne endre på den informasjonen som er ønskelig. De feltene som kan være blanke om dette skulle være ønskelig er: Beskrivelse av tilbudet og tilbudsansvarlig. Resten, navn og fra og til dato kan ikke være blanke. Denne nødvendig informasjonen vil automatisk bli fylt inn i det du befinner deg på Rediger Tilbud siden. 26

103 9.0 Endre ansvarlig for tilbud Figur 9.1: Rediger ansvarlig For å velge tilbudsansvarlig, klikk på pil ned tasten under: Tilbudsansvarlig og marker så navnet til personen du ønsker at skal være den ansvarlige for tilbudet. Nå all ønskelig informasjon er oppdatert, klikk på enten: Oppdater eller Avbryt knappen for å gå videre Slette et tilbud Figur 10.1: Slett tilbud For å slette et tilbud trenger brukeren kun å befinne seg i hovedvinduet for modulen. Uavhengig av hvilken fane du befinner deg i, vil du kunne finne en slett knapp, til venstre i tabellen for hvert enkelt tilbud, (som vist i bildet over). 27

III. PRODUKTRAPPORT HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD

III. PRODUKTRAPPORT HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD III. PRODUKTRAPPORT HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD GRUPPE 36 FORFATTERE: NORDENGEN, THOMAS LARSEN, GLENRUBEN E. STEEN, SEBASTIEN-JEROME 1 FORORD Denne rapporten er skrevet for personer med

Detaljer

IV. PROSESSRAPPORT HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD

IV. PROSESSRAPPORT HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD IV. PROSESSRAPPORT HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD GRUPPE 36 FORFATTERE: NORDENGEN, THOMAS LARSEN, GLENRUBEN E. STEEN, SEBASTIEN-JEROME 1 FORORD I denne prosessrapporten beskriver vi arbeidet

Detaljer

VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD

VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD GRUPPE 36 FORFATTERE: NORDENGEN, THOMAS LARSEN, GLENRUBEN E. STEEN, SEBASTIEN-JEROME 1 INNHOLDSFORTEGNELSE VEDLEGG 1 KRAVSPESIFIKASJON... 03 VEDLEGG 2

Detaljer

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

Bachelorprosjekt 2015

Bachelorprosjekt 2015 Bachelorprosjekt 2015 Høgskolen i Oslo og Akershus Tam Ha (s171513) Arslan Yousaf (s189135) Gabriel Noraker Alfarrustad (s161910) Eivind Lund (s180381) Phillip Padiernos Næss (s162951) Forprosjekt Prosjektets

Detaljer

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 2 Hovedprosjekt 2014, Høgskolen i Oslo og Akershus 1 INNHOLD 2 Presentasjon... 2 2.1 Gruppen medlemmer... 2 2.2 Oppgave... 2 2.3 Oppdragsgiver... 2 2.4 Veileder... 2 3 Sammendrag...

Detaljer

1 Forord. Kravspesifikasjon

1 Forord. Kravspesifikasjon [Type text] [Type text] 3/5 Hovedprosjekt ingeniørutdanningen 09 Kravspesifikasjon Tittel på hovedprosjektet Tarantell Dashboard Gruppe 28 Bjørn Ove Pedersen Stian Dalviken Antall sider 6 Intern veileder

Detaljer

1 Del I: Presentasjon

1 Del I: Presentasjon 1 Del I: Presentasjon 2 Forord Denne sluttrapporten er skrevet av gruppe 12 som består av 4 studenter som studerer ved Høgskolen i Oslo og Akershus. Vi studerer Anvendt datateknologi og denne rapporten

Detaljer

Produktrapport Gruppe 9

Produktrapport Gruppe 9 Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette

Detaljer

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas Prosjekt nr. 2011 22 Testrapport Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s156159 Jørgen Rønbeck s135779 Dato

Detaljer

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk Produktdokumentasjon Madison Møbler Administrasjonsside og Nettbutikk 1 1. Forord 1.1 Dokumentasjonen Dette er en teknisk dokumentasjon på produktet som er utviklet. Denne er tiltenkt personer med teknisk

Detaljer

Dokument 1 - Sammendrag

Dokument 1 - Sammendrag Dokument 1 - Sammendrag Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Innholdsfortegnelse Sammendrag 1 1. Innledning 1 2. Om

Detaljer

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni.

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. KRAVSPESIFIKASJON Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. Prosjektgruppe: 27 Prosjektmedlem: Ole Almenning Stenhaug Veileder.

Detaljer

Testrapport. Studentevalueringssystem

Testrapport. Studentevalueringssystem Testrapport Studentevalueringssystem 1 Forord 1.2 Forord Dette prosjektet er et hovedprosjekt i data ved Høgskolen i Oslo, avdeling for ingeniørutdanning, og gjennomføres i samarbeid med Ingeniøravdeling

Detaljer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016 Pillbox Punchline Gruppe 8 André Østhagen Bye, s198607 Annika Hammervoll, s198611 Hanne Rygge, s198613

Detaljer

FORPROSJEKT KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK

FORPROSJEKT KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK 2017 FORPROSJEKT BACHELOROPPGAVE 2017 KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK PRESENTASJON OPPGAVE: Oppgaven er å lage en webapplikasjon som kan hjelpe bachelor

Detaljer

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav.

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav. Kravspesifikasjon I dette kapittelet foreligger kravspesifikasjonen som ble utformet tidlig i prosjektprosessen. Dette er den opprinnelige kravspesifikasjonen. Det har igjennom prosjektprosessen vært naturlig

Detaljer

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1 1 FORORD Dette dokumentet er brukerveiledningen, og skal være en veiledning

Detaljer

SiteGen CMS. Innføringsmanual

SiteGen CMS. Innføringsmanual SiteGen CMS Innføringsmanual Copyright Barlind Solutions AS 2008 Hva er SiteGen CMS? SiteGen CMS er et såkalt content-management-system; eller med litt andre ord et publiseringssystem. Det kan brukes til

Detaljer

HOVEDPROSJEKT I DATA VÅR 2011

HOVEDPROSJEKT I DATA VÅR 2011 PROSJEKT NR. 18 TILGJENGELIGHET åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT I DATA

Detaljer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 207 Digitalisering av Sentralen UNG Gründer Gruppe 34 Kenneth Di Vita Jensen, s236745 Frank Arne Bjørkmann

Detaljer

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress Sist oppdatert 05.06.2015 Innholdsfortegnelse 1. Hva er Wordpress?... 3 2. Hvordan logger jeg inn i kontrollpanelet?...

Detaljer

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer...

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer... Side 1 1. Forord Dette dokumentet er en kravspesifikasjon og har blitt utarbeidet av arbeidsgiver og prosjektgruppen. Dokumentet består av ni kapitler. Det vil først bli presentert hvem prosjektgruppen

Detaljer

Forprosjektrapport. Gruppe Januar 2016

Forprosjektrapport. Gruppe Januar 2016 Forprosjektrapport Gruppe 22 22. Januar 2016 Innholdsfortegnelse Innholdsfortegnelse Presentasjon Sammendrag Dagens situasjon Mål og rammebetingelser Mål Rammebetingelser Løsninger og alternativer Løsning

Detaljer

Stikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client.

Stikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client. Stikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client. Studenter: Magnus Skomsøy Bae, Marius Eggen, Magnus Krane Klasse: 3ING, Systemutvikling Produserer redaksjonelle

Detaljer

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen.

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen. Artist webside Innhold Artist webside...1 Gruppe medlemmer...1 Oppdragsgiver...1 Kontaktperson...2 Veileder...2 Oppgaven...2 Muligheter...2 Sammendrag...2 Dagens situasjon...2 Mål og rammebetingelser...3

Detaljer

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo,

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, Kravspesifikasjon Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 12.01.2013 Public 2013 Aker Solutions Page 1 of 7 Table of Contents Forord... 3 Om bakgrunnen... 3 Presentasjon...

Detaljer

Del IV: Prosessdokumentasjon

Del IV: Prosessdokumentasjon 1 2 Forord Dette dokumentet omhandler detaljert beskrivelse av vår arbeidsprosess gjennom hele perioden med prosjektet. Prosessdokumentasjonen er en viktig del av sluttrapporten, og er delt opp i følgende

Detaljer

Oblig 5 Webutvikling. Av Thomas Gitlevaag

Oblig 5 Webutvikling. Av Thomas Gitlevaag Oblig 5 Webutvikling Av Thomas Gitlevaag For oppgave 1 og 2 skal dere levere en funksjonell webside på deres hjemmeområde. Dere skal også levere alle phps-filene slik at man for en hver side kan slenge

Detaljer

HTML5. Skjemaer på nettsider. Skjemaer med. Informasjonsteknologi 1 og 2. Gløer Olav Langslet Sandvika VGS

HTML5. Skjemaer på nettsider. Skjemaer med. Informasjonsteknologi 1 og 2. Gløer Olav Langslet Sandvika VGS Skjemaer med HTML5 Gløer Olav Langslet Sandvika VGS Leksjon 10 Informasjonsteknologi 1 og 2 Skjemaer på nettsider I denne leksjonen skal vi se litt nærmere på bruk av skjemaer på nettsider. Du har sett

Detaljer

1. Forord 2. Leserveiledning

1. Forord 2. Leserveiledning KRAVSPESIFIKASJON 1 1. Forord Hensikten med kravspesifikasjonen er at den skal fungere som et styringsdokument under prosessen og definere rammer og betingelser rundt hovedprosjektet. Den er utviklet etter

Detaljer

Mamut Open Services. Mamut Kunnskapsserie. Kom i gang med Mamut Online Survey

Mamut Open Services. Mamut Kunnskapsserie. Kom i gang med Mamut Online Survey Mamut Open Services Mamut Kunnskapsserie Kom i gang med Mamut Online Survey Kom i gang med Mamut Online Survey Innhold MAMUT ONLINE SURVEY... 1 KOM I GANG MED MAMUT ONLINE SURVEY... 3 MAMUT-BRUKERE: OPPRETT

Detaljer

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Sluttrapport Høgskolen i Oslo Student: Martin Oppegaard Gruppe: 07-12 Dato: 25. mai 2007 Veileder ved HIO: Eva Vihovde Oppdragsgiver: Bekk Consulting

Detaljer

Testrapport for Sir Jerky Leap

Testrapport for Sir Jerky Leap Jasmine Garry (s135600) Line Sørensen (s135590) Fredrik Hoem Grelland (s135595) Tor Anders Gustavsen (s127668) 1 1. Forord Dette dokumentet inneholder informasjon og redegjøring av tester foretatt i forbindelse

Detaljer

Forprosjektrapport. Presentasjon. Oslo, den 29. Januar Gorm Eirik Svendsen Nicolai Mellbye Marius Auerdahl Per Gustav Løwenborg

Forprosjektrapport. Presentasjon. Oslo, den 29. Januar Gorm Eirik Svendsen Nicolai Mellbye Marius Auerdahl Per Gustav Løwenborg Forprosjektrapport Presentasjon Tittel Bakerman AS Website Oppgave Utvikle ett websted for Bakerman AS der hvor de kan promotere seg selv og kommunisere med kundene sine. Periode 4. Januar 2010 til 17.

Detaljer

Brukermanual. Studentevalueringssystem

Brukermanual. Studentevalueringssystem Brukermanual Studentevalueringssystem 1 Forord 1.1 Forord Denne brukermanualen innholder beskrivelse av systemets funksjonalitet og introduserer systemet for brukeren. Brukermanualen er delt inn i tre

Detaljer

Gruppe 44. Bachelorprosjekt ved Institutt for informasjonsteknologi, våren Høgskolen i Oslo og Akershus,

Gruppe 44. Bachelorprosjekt ved Institutt for informasjonsteknologi, våren Høgskolen i Oslo og Akershus, Bachelorprosjekt ved Institutt for informasjonsteknologi, våren 2017 Høgskolen i Oslo og Akershus, 19.01.2017 Gruppe 44 Håkon Andre Sylte Garnes, Tobias Hallèn, Gaurab J. Gurung Forprosjektrapport Presentasjon

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Forord Kravspesifikasjonen skal gi en oversikt og forståelse over det planlagte systemets funksjonalitet. Dokumentet skal gi både utviklere og oppdragsgivere innblikk i hvordan og hva systemet skal levere.

Detaljer

Bachelorprosjekt i informasjonsteknologi, vår 2017

Bachelorprosjekt i informasjonsteknologi, vår 2017 Bachelorprosjekt i informasjonsteknologi, vår 2017 Gruppe 29: Marthe Janson Skogen, s236357, Ingeniørfag - data Odd Einar Hoel, s236313, Ingeniørfag - data Forprosjektrapport Rapporten inneholder presentasjon,

Detaljer

Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008

Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008 1.Forord I dette dokumentet skal vi gi et bildet av de kravene som er satt til prosjektet. Dokumentet er hovedsakelig beregnet som et styringsdokument

Detaljer

3. Kravspesifikasjon. Experior - rich test editor for FitNesse -

3. Kravspesifikasjon. Experior - rich test editor for FitNesse - 3. Experior - rich test editor for FitNesse - 3.1. Forord Dette dokumentet inneholder krav til funksjonalitet i Experior og hvordan denne skal integreres inn i selve FitNesse. I tillegg spesifiseres krav

Detaljer

Del VII: Kravspesifikasjon

Del VII: Kravspesifikasjon 1 2 Forord Dette dokumentet inneholder retningslinjer for gruppen vår og beskrivelse av betingelsene for utviklingen av vårt prosjekt. Vår gruppe benyttet dette dokumentet som et styringsdokument for å

Detaljer

CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA

CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA Sist oppdatert 18.02.2010 INNHOLD INNHOLD... 1 HVA ER CABINWEB... 2 HVA KAN DU BRUKE CABINWEB TIL?... 3 HVA ER NYTT I CABINWEB VERSJON 2.0...

Detaljer

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet Kravspesifikasjon Hovedprosjekt 2014 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Tittel: Oppgave: Gruppemedlemmer: Digitalt Helsekort for Gravide Utvikle en prototype

Detaljer

Hovedprosjektet i Data Høgskolen i Oslo våren 2010

Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Kevin Holmvik s147777 Nikolai Godager s147790 Einar Drivdal s147782 Chau Quoc Quo Do s147792 PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi

Detaljer

Gruppe 43. Hoved-Prosjekt Forprosjekt

Gruppe 43. Hoved-Prosjekt Forprosjekt Gruppe 43 Hoved-Prosjekt Forprosjekt Mobil Applikasjon Utvikling HiOA Bacheloroppgave forprosjekt våren 2017 Presentasjon Gruppen består av: Gebi Beshir Ole-Kristian Steiro Tasmia Faruque s182414 s189141

Detaljer

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Testrapport Høgskolen i Oslo Student: Martin Oppegaard Gruppe: 07-12 Dato: 25. mai 2007 Veileder ved HIO: Eva Vihovde Oppdragsgiver: Bekk Consulting

Detaljer

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634 Forprosjekt Presentasjon Gruppe 19: Event-planlegger Andreas Berglihn s169991 Harald R. Svendsen s127142 Gruppe Gruppe 19 Andreas Berglihn, s169991 Harald R. Svendsen s127142 Oppgave Eventplanlegger Utvikle

Detaljer

VEDLEGG 1 KRAVSPESIFIKASJON

VEDLEGG 1 KRAVSPESIFIKASJON VEDLEGG 1 KRAVSPESIFIKASJON INNHOLDSFORTEGNELSE Forord... 2 1 Systembeskrivelse... 2 2 Mål for systemet... 3 3 Funksjonelle krav... 4 4 Ikke-funksjonelle krav... 5 5 Use-case diagram... 6 6 Rammekrav...

Detaljer

Kandidat nr. 1, 2 og 3

Kandidat nr. 1, 2 og 3 Kandidat nr. 1, 2 og 3 Rapport 1 IT202E Bacheloroppgave i Informatikk Vår 2011 Mobilapplikasjonsutvikling med Scrum 1 Innhold Innledning... 3 Overordnet Prosjektplan... 3 Produktbacklog... 5 Sprint planning

Detaljer

Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008

Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Skrevet av Ole Myrbakken, Fadima Mohamoud, Orji Okoroafor, Karen Arrendondo Side 1 PRESENTASJON Prosjekt tittel: Prosjektperiode: MetaGen 7.jan

Detaljer

HOVEDPROSJEKT. Telefon: Telefaks: Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo. 25.mai 2007.

HOVEDPROSJEKT. Telefon: Telefaks: Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo. 25.mai 2007. PROSJEKT NR. 2007-16 TILGJENGELIGHET Åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL DATO Panther

Detaljer

Studentdrevet innovasjon

Studentdrevet innovasjon Studentdrevet innovasjon Hovedprosjekt 2013 Høgskolen i Oslo og Akershus Forprosjektrapport av Gruppe 11 Karoline Sanderengen, Mona Isabelle Yari og Randi Ueland 25.01.2013 Studentdrevet innovasjon 9 Innhold

Detaljer

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5 Testrapport Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 24.5.2013 Public 2013 Aker Solutions Page 1 of 5 Innledning I denne rapporten vil vi skrive om testingen som

Detaljer

>>21 Datamodellering i MySQL Workbench

>>21 Datamodellering i MySQL Workbench 21 MYSQL WORKBENCH 207 >>21 Datamodellering i MySQL Workbench I dette kapittelet vil du lære hvordan man lager datamodeller i MySQL Workbench hvordan man overfører en modell til MySQL I tillegg til å være

Detaljer

Dette dokumentet er en produktrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen.

Dette dokumentet er en produktrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen. 1 Sammendrag Dette dokumentet er en produktrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen. Vår oppdragsgiver, ABTF hadde et ønske om en større web

Detaljer

Hei verden Introduksjon Swift PDF

Hei verden Introduksjon Swift PDF Hei verden Introduksjon Swift PDF Introduksjon Swift er et programmeringsspråk laget av Apple og er etterfølgeren til Objective-C. Med Swift kan du lage apper for ios og OSX. For å gjennomføre dette kurset

Detaljer

2 Om statiske variable/konstanter og statiske metoder.

2 Om statiske variable/konstanter og statiske metoder. Litt om datastrukturer i Java Av Stein Gjessing, Institutt for informatikk, Universitetet i Oslo 1 Innledning Dette notatet beskriver noe av det som foregår i primærlageret når et Javaprogram utføres.

Detaljer

Om du allerede kjenner Scratch og har en Scratchbruker kan du gå videre til Steg 1.

Om du allerede kjenner Scratch og har en Scratchbruker kan du gå videre til Steg 1. Pingviner på tur Skrevet av: Geir Arne Hjelle Kurs: Scratch Tema: Blokkbasert, Spill Fag: Programmering Klassetrinn: 1.-4. klasse, 5.-7. klasse, 8.-10. klasse Introduksjon Velkommen til Scratch. Vi skal

Detaljer

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet Produktrapport Hjelpemiddel portal for Parkinsonforbundet 1 Innhold: Forord ------------------------------------------------------------------------------------------------------2 Planlegging og arbeidsmetode

Detaljer

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon.

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon. Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon Møtereferat: 1. møte med veileder I dette møtet presenterte vi oss for

Detaljer

Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus, våren Camilla Kaasi(s188070) Roza Moustafa(s188113)

Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus, våren Camilla Kaasi(s188070) Roza Moustafa(s188113) Forprosjektrapport Gruppe 14 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus, våren 2015 Sted: Høgskolen i Oslo og Akershus Dato: 23.01.2015 Tittel: Gruppemedlemmer: Oppgave: Oppdragsgiver:

Detaljer

Forprosjektrapport. Utvikle en plattform for digitalisering av foosballbord.

Forprosjektrapport. Utvikle en plattform for digitalisering av foosballbord. Forprosjektrapport Tittel Oppgave Periode Openfoos Utvikle en plattform for digitalisering av foosballbord. 3. januar til 15. juni Gruppemedlemmer Amir Ghoreshi Marcel Eggum Neberd Salimi Valentin Rey

Detaljer

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD Forprosjektrapport Feilsøkingsverktøy for Homebase AS INNHOLD Presentasjon Sammendrag Om bedriften Dagens situasjon Mål og rammebetingelser Funksjonelle krav: Ikke-funksjonelle krav: Løsninger Analyse

Detaljer

Brukermanual. Itpays W3 Publish. Sette opp, logge inn og komme i gang. Redigert den 23. mai 2005. http://www.itpays.no/produkter/publisering/

Brukermanual. Itpays W3 Publish. Sette opp, logge inn og komme i gang. Redigert den 23. mai 2005. http://www.itpays.no/produkter/publisering/ Brukermanual Itpays W3 Publish Sette opp, logge inn og komme i gang Redigert den 23. mai 2005 http://www.itpays.no/produkter/publisering/ Innholdsoversikt: 1 Generelt om Itpays w3 publish Side 3 2 Sette

Detaljer

Forprosjekt. Høgskolen i Oslo, våren

Forprosjekt. Høgskolen i Oslo, våren Forprosjekt Høgskolen i Oslo, våren 2011 ------------------------------------------ Presentasjon Tittel: Oppgave: Database og nettside for Nor Dagligvarer Import AS Utvikle et databasesystem for bedriften

Detaljer

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1 KRAVSPESIFIKASJON Gruppe 2 Hovedprosjekt, Høgskolen i Oslo og Akershus Våren 2014 KRAVSPESIFIKASJON 1 CONTENTS 1. Forord... 3 2. Presentasjon... 3 2.1 Gruppens medlemmer... 3 2.2 Oppdragsgiver... 3 2.3

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den

Detaljer

Hovedprosjekt. Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport. K-skjema og ferie kalender

Hovedprosjekt. Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport. K-skjema og ferie kalender Hovedprosjekt Høgskolen i Oslo data/informasjonsteknologi våren 2011 Forprosjektrapport Presentasjon Sted og dato Oslo, Jan 9, 2011 Prosjekt tittel Periode K-skjema og ferie kalender Utvikle et registreringssystem

Detaljer

Forprosjektrapport Gruppe 30

Forprosjektrapport Gruppe 30 Forprosjektrapport Gruppe 30 Gruppemedlemmer: Eyvind Nielsen s177748 Ullvar Brekke s236375 Kristoffer Pettersen s239404 Innhold Presentasjon... 3 Sammendrag... 3 Dagens situasjon... 3 Mål... 3 Rammebetingelser...

Detaljer

Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus. Forprosjektrapport. Bravo Booking App

Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus. Forprosjektrapport. Bravo Booking App Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus Forprosjektrapport Bravo Booking App 1 Presentasjon 2 1.1 Gruppe 2 1.2 Oppdragsgiver 2 1.3 Kontaktpersoner 2 1.4 Oppgave 3 2 Dagens

Detaljer

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester.

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester. 1 Forord Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg prosjektets rammer

Detaljer

KOMME I GANG 2. Logge på 2. I redigeringsvinduet 3 OVERSIKT OVER KNAPPENE SOM LIGGER ØVERST I REDIGERINGSVINDUET 5

KOMME I GANG 2. Logge på 2. I redigeringsvinduet 3 OVERSIKT OVER KNAPPENE SOM LIGGER ØVERST I REDIGERINGSVINDUET 5 Innhold KOMME I GANG 2 Logge på 2 I redigeringsvinduet 3 OVERSIKT OVER KNAPPENE SOM LIGGER ØVERST I REDIGERINGSVINDUET 5 Lukk 6 Ny 6 Flytt opp/ Flytt ned 6 Klipp 7 Kopier 7 Lim inn (krysspubliser, ny,

Detaljer

Brukerveiledning. Madison Møbler Administrasjonsside

Brukerveiledning. Madison Møbler Administrasjonsside Brukerveiledning Madison Møbler Administrasjonsside 1 1. Forord 1.1 Produktet Produktet blir konstruert som et nytt produkt da kunde/bruker ikke har noe eksisterende løsning, derfor er dette den nåværende

Detaljer

WordPress. Brukerveiledning. Kjære kunde. Innlogging:

WordPress. Brukerveiledning. Kjære kunde. Innlogging: Brukerveiledning WordPress Sist oppdatert: 26.02.2014 Kjære kunde Her er en liten guide for å hjelpe deg gjennom det grunnleggende i Wordpress. Denne veilederen vil ta deg gjennom: Innlogging - s.1 Kontrollpanel

Detaljer

Vedlegg LMC intranett

Vedlegg LMC intranett Vedlegg LMC intranett H12D02 Jarl-Håvard Holen Ole-Martin Larsen Fredrik Sethne-Andersen André Ritari Vedlegg 1 Resultater av kortsortering. Kortsortering Bruker 1, Salg: Kortsortering Bruker 2, Teknisk:

Detaljer

Vedlegg Brukertester INNHOLDFORTEGNELSE

Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester... 1 Testrapport Wireframe... 2 1. INTRODUKSJON... 2 1.1 Systemoversikt... 2 1.2 Meningen med testen... 2 2 TESTPLAN... 2 2.1 Funksjoner som

Detaljer

Utvikling av et nettbasert CMS med tilhørende nettsted for Axel Bruun Sport AS

Utvikling av et nettbasert CMS med tilhørende nettsted for Axel Bruun Sport AS Utvikling av et nettbasert CMS med tilhørende nettsted for Axel Bruun Sport AS Håkon Bogsrud Anders Høye Karlsen Alexander Borgen Saxevik Bacheloroppgave vår 2012 IT-støttet bedriftsutvikling Oppgavenummer:

Detaljer

Båtforening på nett. Produktrapport

Båtforening på nett. Produktrapport Båtforening på nett Hovedprosjekt våren 2009, Høgskolen i Oslo Prosjektgruppe 36 Vegard Skipnes, Rade Vuckovic & Frode Sørensen Produktrapport 1 Sammendrag Denne rapporten er en del av Hovedprosjektet

Detaljer

Kravspesifikasjonsrapport

Kravspesifikasjonsrapport Kravspesifikasjonsrapport JobCrawl Ledige jobber representert i kart for IBM Gruppe 9 Bachelorprosjekt ved Oslo Metropolitan University Gruppemedlemmer: Kim Smedsrud Chris-Thomas Lundemo Grenness Lars

Detaljer

Forprosjektrapport. Gruppe 34. Magnus Dahl Hegge s153549

Forprosjektrapport. Gruppe 34. Magnus Dahl Hegge s153549 Forprosjektrapport Gruppe 34 Bjørn Bergan Abdi Baisa Mads Larsen s161593 s156140 s156151 Magnus Dahl Hegge s153549 Presentasjon Hovedprosjektgruppe 34 består av 4 elever som nå gjennomfører sitt siste

Detaljer

Rapportmodulen i Extensor 05

Rapportmodulen i Extensor 05 Rapportmodulen i Extensor 05 [Oppdatert 13.6.2012 av Daniel Gjestvang] Extensor 05 inneholder egen rapporteringsmodul som muliggjør at virksomheten kan lage sine egne rapporter ut fra alle registrerte

Detaljer

Høgskolen i Oslo og Akershus. Bachelorprosjekt Hacking Cristin. (midlertidig tittel) Forprosjektrapport

Høgskolen i Oslo og Akershus. Bachelorprosjekt Hacking Cristin. (midlertidig tittel) Forprosjektrapport Høgskolen i Oslo og Akershus Bachelorprosjekt 2017 Hacking Cristin (midlertidig tittel) Forprosjektrapport Innholdsfortegnelse: 1.0 Presentasjon s. 3 2.0 Sammendrag s. 3 3.0 Dagens situasjon s. 4 4.0 Mål

Detaljer

Forprosjektrapport. Gruppe 31

Forprosjektrapport. Gruppe 31 Forprosjektrapport Gruppe 31 1 Presentasjon Oppgave: Finne et kodespråk som kan være med på å forbedre kundetilfredsheten og brukervennligheten ved bruk av Telenor sine websider. Periode: 14. januar til

Detaljer

FORPROSJEKT RAPPORT PRESENTASJON

FORPROSJEKT RAPPORT PRESENTASJON FORPROSJEKT RAPPORT PRESENTASJON Tittel: Oppgave: Appenes App Utvikle en Windows 8.1 Applikasjon for Tablet, og en Windows 8 Phone App og en backend. Periode: 06.01.2013-27.05.2013 Gruppemedlemmer: Athavan

Detaljer

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort Forprosjektrapport Presentasjon Tittel: Oppgave: Gruppemedlemmer: Prosjektgruppe: Veileder: Hovedoppdragsgiver: Kunde av oppdragsgiver: Ansvarlig for gruppen: Faglig veileder hos BEKK: Android app for

Detaljer

Administrering av SafariSøk

Administrering av SafariSøk Administrering av SafariSøk Administrering av SafariSøk Revisjonshistorie Revisjon $Revision: 1.6 $ $Date: 2003/08/05 12:44:02 $ Innholdsfortegnelse 1. Om programmet... 1 Generelt... 1 2. Fremgangsmåter...

Detaljer

WWW.POLARPRODUKSJON.NO

WWW.POLARPRODUKSJON.NO GUIDE RSHL.NO Av Fredrik Mediå Oppgraderingen av nettstedet RSHL.NO har ført til at det kan oppstå en del spørsmål og forvirringer rundt hvordan forskjellige elementer fungerer. Denne guiden skal fungere

Detaljer

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 INNHOLDSFORTEGNELSE 1. PRESENTASJON 2. SAMMENDRAG 3. DAGENS SITUASJON 4. MÅL OG RAMMEBETINGELSER 5. LØSNINGER \ ALTERNATIVER 6. ANALYSE AV

Detaljer

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell Forprosjektrapport Presentasjon Tittel: Oppgave: utforming Periode: Gruppemedlemmer: Hafnor Prosjektgruppe: Veileder: Oppdragsgiver: Kontaktperson: Nettside for gruppa: Universelt LæringsVerktøy (ULV)

Detaljer

Brukerdokumentasjon Prosjekt nr. 2011-16 PayEx Logistics

Brukerdokumentasjon Prosjekt nr. 2011-16 PayEx Logistics Side 1 av 17 Payex Logistics Brukermanual Ver. 1.0 31.05.2011 Gruppe 16 Høgskolen i Oslo Side 2 av 17 1 Innledning Denne brukerdokumentasjonen forklarer bruken av logistikksystemet som er laget for PayEx.

Detaljer

System Dokumentasjon. Team2. Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk

System Dokumentasjon. Team2. Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk System Dokumentasjon Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk System Dokumentsjon 23/04/2018 Systemutvikling og dokumentasjon/ia4412

Detaljer

Forord Dette er testdokumentasjonen skrevet i forbindelse med hovedprosjekt ved Høgskolen i Oslo våren 2010.

Forord Dette er testdokumentasjonen skrevet i forbindelse med hovedprosjekt ved Høgskolen i Oslo våren 2010. TESTDOKUMENTASJON Forord Dette er testdokumentasjonen skrevet i forbindelse med hovedprosjekt ved Høgskolen i Oslo våren 2010. Dokumentet beskriver hvordan applikasjonen er testet. Dokumentet er beregnet

Detaljer

Kravspesifikasjon. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23

Kravspesifikasjon. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23 Utvikling av moduler til CMS for bonefish.no Gruppe 08-23 Kravspesifikasjon for hovedprosjektet utvikling av moduler til CMS for bonefish.no ved Høgskolen i Oslo, avdeling for Ingeniørutdanning våren 2008.

Detaljer

Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad

Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad Forprosjektrapport Presentasjon Tittel: Oppgave: Infront SSO Utvikle en Single Sign-on løsning for Infront Periode: 8/1-2013 28/5-2013 Gruppemedlemmer: Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini

Detaljer

Forprosjekt. Oppgdragsgiver Unikia, Lille grensen 7, 0159 Oslo, Kontaktperson Anders Kose Nervold,

Forprosjekt. Oppgdragsgiver Unikia, Lille grensen 7, 0159 Oslo, Kontaktperson Anders Kose Nervold, Hovedprosjekt i data/informasjonsteknologi Høgskolen i Oslo og Akershus Forprosjekt Prosjekttittel Unikia Android applikasjon Gruppe 13 Markus Bugge-Hundere s188909 Morten Wold Aksel Wiig s236326 s232324

Detaljer

Innføring i BrandMaker Markedsplanlegger https://mp.mam.no. Media Asset Management AS http://www.mam.no

Innføring i BrandMaker Markedsplanlegger https://mp.mam.no. Media Asset Management AS http://www.mam.no Innføring i BrandMaker Markedsplanlegger https://mp.mam.no Media Asset Management AS http://www.mam.no Innholdsfortegnelse: Innholdsfortegnelse:... 2 Hva er BrandMaker Markedsplanlegger?... 3 Hva trenger

Detaljer

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker.

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker. Logg 22 oktober 2013 Vi skriver status rapport og starter også med å skrive logg idag. Vi har vært i kontakt med mange firmaer uten alt for mye interesse fra deres side. Vi fortsetter å søke etter oppgave.

Detaljer