HIO: AVDELING FOR INGENIØRUTDANNING YFL Norway Webpage Hovedprosjekt våren 2011 Atle Smenes # Hasan Mahammed Sheekh # Ian Kris Abarquez Co
PROSJEKT NR. 11-32 Studieprogram: Dataingeniør Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo HOVEDPROSJEKT TILGJENGELIGHET Åpen Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKTETS TITTEL YFL Norway Webpage DATO 31.05.2011 ANTALL SIDER / BILAG xx PROSJEKTDELTAKERE Atle Smenes, S156158 Hassan Mahammed Sheekh, S148134 Ian Kris Abarquez Co, S156160 INTERN VEILEDER Tor Kratebøl OPPDRAGSGIVER YFL NORWAY KONTAKTPERSON Brion Lance Caguait - Leder SAMMENDRAG Dette er bacheloroppgaven til tre studenter på ingeniørutdanningen ved Høgskolen i Oslo. Oppgaven er skrevet i tidsrommet januar-mai 2011, og er utarbeidet for, og i samarbeid med YFL Norway. Websiden vi har utviklet for organinisasjonen består av nyhetsformidling, bildevisning, medlemsregistrering, aktiviteter og annen nyttig informasjon. Rapporten tar for seg utviklingsprossesen og hva som ble gjennomført for å ferdigstille produktet. Websiden er overlevert til YFL Norway som står fritt til å bruke og/eller videreutvikle systemet til eget bruk hvor en av gruppens medlemmer, Ian Kris Abarquz Co, vil fortsette som webmaster på fritiden. God lesning. 3 STIKKORD PHP MYSQL HTML MYSQL 2
Forord Denne rapporten er resultatet av et hovedprosjekt som er gjennomført ved Høgskolen i Oslo, avdeling for ingeniørutdanning. Rapporten tar for seg utviklingen av webside steg for steg. Vi ønsker å takke alle de involverte i vårt prosjektet. Takk til YFL Norway for et godt samarbeid de fem månedene prosjektet har pågått, og til vår veileder Tor Krattebøl ved Høgskolen i Oslo for god hjelp, veiledning, tilbakemeldinger og faglig kompetanse. 3
Innholdsfortegnelse Innledning... 5 Mål... 6 Resultatmål... 6 Effektmål... 7 Kravspesifikasjon... 8 Systembeskrivelse... 9 Valg av metode... 10 Metode... 10 Hvorfor forssefallsmetoden... 10 Beskrivelse av de 5 fasene... 10 Prosjektplanlegging... 11 Fremdriftsplan... 11 Risikoanalyse... 11 Moteplan... 11 Prototyping... 13 Papirprototype... 13 Designprototype... 14 ER diagram... 15 Verktoyene vi har brukt... 16 Litt om verktoyene... 16 Implementasjon... 18 Websiden... 18 Administrator... 19 Sammendrag... 21 Konklusjon... 22 Kilder... 23 Vedlegg... 24 Vedlegg 1 Kravspesifikasjon... 25 Vedlegg 2 Fremdriftsplan... 26 Vedlegg 3 Risikoplan... 27 Vedlegg 4 Prototype... 29 Vedlegg 5 Moteplan... 34 4
Innledning Hovedprosjektet har blitt gjennomført ved Høgskolen i Oslo, avdelingen for ingeniørutdanning. Målet med oppgaven var at vi skulle utvikle en webside for medlemmene til YFL Norway. Selve hjemmesiden vil gjøre organisasjonen mer tilgjengelig for de allerede eksisterende medlemmene, nye medlemmer og andre interesserte. Websiden inneholder flere deler som vil lette arbeidet til de som leder organisasjonen blant annet med registrering og påmelding, kunngjøring av nyheter med mer. Det stilles store krav til brukervennlighet. Alt tekst på siden er skrevet på engelsk. 5
Mål Resultatmål Målet med vår prosjektoppgave er å lage en webside som gjør organisasjonen YFL Norway mer tilgjengelig for de eksiterende medlemmene og potensielle nykommere. Det er tre delmål vi skiller her mellom ledelsen, de som allerede er medlem og potensielle nye medlemmer. For det første skal nettsiden lette arbeidet for de som styrer organisasjonen. Det vil si at YFL får en digital brukerdatabase. Videre vil påmelding til de planlagte aktivitetene foregår automatisk via nettsiden og det vil gjøre kunngjøringene mer tilgjengelig for medlemmene. For de som allerede er medlemmer skal nettsiden sørge for bedre tilgjengelighet. Medlemmene skal kunne melde seg på aktiviteter og holde seg oppdatert med nyheter og bilder som blir lagt ut. Nettsiden skal også kunne gi potensielle nykommere bedre informasjon. Det skal være synlig for alle som besøker nettstedet hvordan man kommer i kontakt med YFL Norway. Organisasjonens hjemmeside skal gi et oversiktlig bilde over hva som foregår og hvordan man blir medlem. 6
Effektmål Bakgrunn for selve effektmålet: YFL Norway er en internasjonal katolsk ungdomsgruppe som ble grunnlagt på Filippinene. Formålet til YFL er å skape et miljø for ungdommer som vil bli bedre kjent med Gud. YFL oppmuntrer ungdommer til å leve et ydmykt og hellig liv, inspirere og bli inspirert til å tilbringe tid med familien, fellesskapet og Kirken. De arrangerer flere treff og aktiviteter i året, men hovedsamlingen heter Youth Camp som er en tredagersleir hvor ungdommene kan bli bedre kjent med seg selv og Gud. YFL Norway ønsker seg økt rekruttering til organisasjonen og ikke minst økt aktivitet. Nettsiden vil minske arbeidsmengden til de som arrangerer treff og sosiale samlinger, samtidig som den vil formidle nyheter til de allerede eksiterende medlemmene. Konkret effektmål: Effektmålet er å øke brukermassen og aktivitetshyppigheten ved å gjøre organisasjonen bedre tilgjengelig. 7
Kravspesifikasjonen Kravspesifikasjon er et formelt dokument som beskriver spesifikk hva prosjektet skal inneholde ofte brukte som en juridisk bindende kontrakt mellom kunde og utvikler. En god kravspesifikasjon setter klare mål for prosjektet og beskriver hvordan kunden og utvikler ser for seg det endelig produktet. Kravspesifikasjonen ble først utarbeidet av de tre gruppemedlemmene fra HiO og senere godkjent av arbeidsgiveren. Kravspesifikasjonen er beregnet for de medvirkende i prosjektet oppdragsgiver, gruppemedlemmene og veileder i tillegg til sensor som skal evaluere og bedømme prosjektet. Nettsidens funksjonalitet, spesifikasjoner og rammebetingelser er beskrevet i dokumentet, som en instruks for hvordan systemet skal fungere. Utover dette står gruppen veldig fritt til å legge på/gjøre egne valg når det gjelder websiden. Store endringer eller tillegg må selvfølgelig konfronteres med YFL først. Se vedlegg 1 (Kravspesifikasjon) 8
Systembeskrivelse Dette bildet viser et overordnet bilde av systemet 9
Valg av metode Metode Fossefallsmetoden er en metode innenfor systemutvikling som går ut på at man deler opp prosjektet i faser. Fasene utføres i den rekkefølgen fasene er satt opp, og det er veldig viktig at en fase gjøres ferdig før man begynner på den neste. Vårt fossefallsdiagram: Hvorfor fossefallsmetoden? Vi har valgt å bruke fossefallsmetoden fordi denne er god å bruke på mindre prosjekter hvor man har klare krav og godt dokumentert planlegging. Hvis man jobber på større prosjekter der mange er involvert og kravene endres ofte, er ikke fossefallsmetoden den beste utviklingsmetoden. Beskrivelse av de fem fasene vi har satt opp: Oppstart: I denne fasen legger vi mest vekt på gruppens strukter og hvordan vi skal ta for oss forprosjektet. Vi snakker med arbeidsgiver og danner et grunnlag for det som venter. Forprosjekt: Denne fasen legger vi mest vekt på kravspesifikasjonen, og det planlegges hvordan systemet skal utvikles. Det lages også en prototype som bestemmer hovedtrekkene på websiden. 10
Utvikling: Her programmer vi websiden og lager tekniske løsninger for de ulike funksjonene som står beskrevet i kravspesifikasjonen. Testing/Dokumentasjon: I denne fasen blir prosjektet ferdigstilt og testet samtidig skrives dokumentasjonen til den endelige sluttrapporten. Presentasjon: I denne siste fasen blir prosjektet finpusset og avslutningspresentasjonen blir ferdigstilt. 11
PROSJEKTPLANLEGGING Fremdriftsplan Fremdriftsplan er en oversikt over arbeidsoppgaver individuelt og i gruppen som viser de ulike tidsrammene for hele prosjektet. Dokumentet viser oss når milepælene i prosjektet skal være ferdig, og det gir også en grov fordeling av arbeidsoppgaver. Se vedlegg 2 (Fremdriftsplan) Risikoanalyse Risikoanalysen brukes til å kartlegge problemer under et prosjekt eller i en prosess. Dokumentet brukes som en veiledning hvis det skulle oppstå problemer underveis. Risikoanalysen gjennomføres grovt sett ved å svare på tre grunnleggende spørsmål: 1. Hva kan gå galt? 2. Hva er sannsynligheten for at de uønskede hendelsen inntreffer? 3. Hvilke konsekvenser kan de uønskede hendelsene medføre? Se vedlegg 3 (Risikoanalyse) Møteplan Møteplan er en oversikt over hvilke møter som skal gjennomføres. Vi har brukt dette som langsikting planlegging slik at gruppen samles ofte. Målet ved prosjektstart var at vi skulle møtes cirka tre ganger i uken i tillegg det individuelle arbeidet. Denne ble oppdatert cirka to uker før hvert møte det vil si at alle gruppemedlemmene hadde tid til å melde i fra om de ikke kunne. Se vedlegg 4 (Møteplan) 12
PROTOTYPING Papirprototype En papirprototype er på mange måter en tegning av kravene til systemet. Det er viktig at papirprototypen får frem litt av funksjonaliteten til systemet slik at man kan få et innblikk i hvordan brukerne oppfatter websiden. Da kan man få et innblikk og eventuelt nye ideer på hvordan websiden fungerer og hva som må forbedres. Vi valgte å lage en papirprototype av systemet for å planlegge enkel design, og hvordan webfunksjonene skal se ut i grove trekk. Her sto gruppen fritt til å velge hvordan det skulle se ut, men YFL Norway ville ha jevnlige tilbakemeldinger. Her et et eksempel (Activities resten av skissene ligger i vedlegg 4): 13
Etter utvikling av papirprototype Når papirprototypene var ferdige tok vi kontakt med arbeidsgiver og lot de komme med på innspill. De var fornøyde med nettsiden og ga tilbakemelding om at det var enkelt og forstålig for alle de hadde forhørt seg med. Designprototype Desingprototype er en prototype hvor det legges vekt på hvordan websiden skal se ut for de besøkende av siden. Funksjonaliteten er ikke mest vektlagt her, derimot hvordan designet på brukergrensesnittet er. Vi laget en designprototype av websiden og dens ulike menyvalg som vi videresendte til YFL Norway de var utelukkende positive. Her er et av bilde av HTML-skissen vår (menylinjen ble senere utvidet i høyden): 14
ER-Diagram Et ER-diagram er en illustrasjon av databasen. Denne illustrasjonene viser tabellene i databasen, dets felt, og tilhørende datadyper og hvordan de interagerer hverandre. Her er vårt ER-diagram: 15
Verktøyene vi har brukt Vår samarbeidspartner har opplyst oss om at vi står fritt til å bruke de løsningene vi synes passer best til å utvikle denne websiden. Vi har valgt å utvikle websiden primært i PHP (verktøy: Netbeans) siden dette er et programmeringsspråk som alle på gruppen er kjent med. HTML ble brukt i startfasen gjennom DreamWeaver til å lage rammevilkårene for wedsiden. Fargene, fontstørrelsene, bakgrunnen og det som hører med websidens layout ble programmert i CSS. MySQL bruker vi til å lage databasen hvor også MAMP (inkluderer phpmyadmin) benyttes som lokal server. Litt om verktøyene: HTML ( HyperText Markup Language ) er et scriptspråk å lage nettsider. I et slikt dokument kan man legge til den informasjonen som skal vises på en nettside. Vi bruker dette språket til å utvikle nettsiden. PHP ( Hypertext Preprocessor ) er et skriptspråk som brukes til å utvikle dynamiske nettsider. PHP er programkode som kjøres på serveren og ikke på brukerens maskin. Dette vil si at når du som bruker besøker en nettside vil koden bli kjørt på serveren du kontakter, mens resultatet av denne kjørte koden blir sendt til deg. PHP gjør det mulig og koble nettsiden din opp mot database og kan motta input fra bruker og gjøre operasjoner på dataen. Vi har valgt å bruke PHP i vårt prosjekt fordi det er et pråk som vi har vært borti før og vi har kjennskap til dens muligheter innen nettsidekreasjoner. CSS ( Cascading Style Sheets ) brukes til å forme design og utseende til en nettside. Nettsidene er skrevet i HTML. Vi bruker CSS for nettopp dette formål, det å kunne forme nettsiden etter YFL Norways designkrav. MySQL ( Structured Query Language ) er det mest populære databasehåndteringssystemet i dag med åpen kildekode (open source). Grunnen til dette er at databasen kan kjøres på de fleste operativsystemer og kan kobles til ved hjelp de aller fleste programmeringsspråkene. Det er dette vi har utviklet databasen med. Adode Dreamweaver CS4 brukes til å designe og utvikle websider. Der kan man jobbe visuelt eller direkte i kode. Vi brukte dette til HTML-koding og i startfasen også til PHP. Vi gikk senere over til Netbeans for PHP-programmering (se nedenfor). 16
Netbeans (7.0) brukes til å utvikle PHP og mange andre språk deriblant Java, C++ osv. Vi gikk som sagt over til Netbeans fordi vi hadde enkelte problemer med PHP-programmering i Adode Dreamweaver CS4, først og fremst fordi det var lite brukervennlig i utviklingsfasen. Netbeans har bedre funksjonalietet når det gjelder å finne enkle feil i PHP da disse kommer opp allerede i verktøyet. Adode Photoshop CS4 er et fotoredigeringsprogram. Det bruker vi til bilderedigering og vi har blant annet laget hovedbildet på websiden med det programmet. MAMP ( Macintosh, Apache, Mysql and PHP ) er Macs svar på Windows Wamp det har vi brukt for å kjøre websiden gjennom lokalhost. MAMP inkluderer også phpmyadmin hvor vi har laget databaen i tillegg til MySQL naturligvis. PhpMyAdmin har blitt brukt til å utføre administrasjonsarbeidet for MySQL. MySQL workbench er et virtuelt databasedesignverktøy som inkluderer SQL, administrasjon og databasedesgin. Det benyttet vi for å lage ER-diagram og andre nyttige databasetegninger i forkant av prosjektet. Dette verktøyet kunne også blitt brukt til å administrere MySQL. Dropbox er et web og serverbasert fildelingsprogram for synkronisering av filer og alt annen data som blir brukt i forbindelse med dette prosjektet. Vi har brukt dette systemet aktivt det vil si at vi hele tiden har lagret dataene på tre ulike maskiner (tre gruppmedlemmer) i tillegg til vår webserver på dropbox.com. Vi har ikke kjøpt ekstra lagringsplass, fordi vi aldri har hatt behov for noe mer enn 2 gigabyte totalt. I tillegg til dette har vi naturligvis Word (2007) og PDF-creator til å lage dokumentasjonen. 17
Implementasjon Websiden Her vil vise en utvalgt del av websiden. Membership: Her kan brukerne som ikke allerede er medlemmer registrere seg. Det er åtte skjemaer som må fylles ut for at brukeren kan få godkjent registreringen. Hvis det skjemaet ikke fylles ut riktig vil det skrives ut feilmeldinger. Dersom registreringen var vellykket i databasen skrives det ut en melding til brukeren om dette. Koden under illustrerer dette: 18
Administrator Under vises en utvalgt del av administratordelen. Admin for nyhet: Hvis en adminbruker logger inn kommer man rett til admindelen av siden. Der kan man første velge om man vi laste opp bilder eller administrere nyheter. 19
Hvis administratorbrukeren fyller ut dette skjema etter beskrivelsen på høyre siden vil nyheten bli publisert ute på hovedsiden til YFL Norway under Home/News. Resten av websiden og adminstratordelen ligger på CD. 20
SAMMENDRAG Oppgaven vi fikk av YFL Norway gikk ut på å lette arbeidsmengden og effektivisere arbeidet til de personene som leder organisasjonen, gjøre YFL mer tilgjengelig og øke interessen blant de allerede eksisterende medlemmene og ikke minst gjøre organisasjonen mer synlig for potensielle nye trofaste medlemmer. Vi valgte å løse denne oppgaven ved å lage en enkel og oversiktlig webside hvor lederne lett kan administrere organisasjonen samt at medlemmene får mye informasjon via nettet noe organisasjonen ikke hadde tidligere. Kravene til websiden ble utviklet i samarbeid med YFL Norway, men vi sto ganske fritt til å utvikle løsningen så det lenge det ferdige produktet var i henhold til kravspesifikasjonen. Websiden ble utviklet i PHP, HTML og MySQL. Gruppens medlemmer hadde alle vært borti disse elementene tidligere. Gruppen brukte mye tid i starten på å komme i gang, men etter hvert fikk vi mer erfaring og rutine da gikk økte også arbeidsmengdene per uke. Resultatet av produktet står i sammenheng med kravspesifikasjonen og oppfyller YFL Norways ønsker - hvor en av gruppens medlemmer, Ian Kris Abarquz Co, vil fortsette som webmaster på fritiden. 21
KONKLUSJON Vi laget en webside som dekker de behovene YFL Norway ønsket. Disse behovene ble belyst i kravspesifikasjonen som ble utarbeidet i samarbeid med bedriften i oppstarten av prosjektet. Websiden fremstår ved prosjektets slutt som klar til publisering på nett. Det endelige produktet består av en hovedside hvor brukerne kan holde seg oppdatert på nyheter, aktiviteter og i tillegg logge inn ved hjelp av brukernavn og passord. Medlemmene (med forbehold om at de er innlogget) kan melde seg på aktiviteter. Ved hjelp av noen få museklikk kan nye besøkende lese om YFL og registrere seg hvis det skulle være interesse for det. Websiden inneholder også et bildegalleri hvor de som administrerer websiden kan laste opp bilder. Websiden er overlevert til YFL Norway som står fritt til å bruke og/eller videreutvikle systemet til eget bruk - hvor en av gruppens medlemmer, Ian Kris Abarquz Co, vil fortsette som webmaster på fritiden. 22
Kilder PHP: - http://no.wikipedia.org/wiki/php - http://keithdevens.com/software/php_calendar - http://php.net/manual/en/index.php - http://www.youtube.com/results?search_query=php+tutorial&aq=0&oq=php+tu - Lærebok: Webprogrammering i PHP (2.utgave) MySQL: - http://en.wikipedia.org/wiki/mysql - Lærebok: Databasesystemer HTML: - http://www.w3schools.com/html/default.asp - http://www.youtube.com/results?search_query=html+tutorial&aq=0s&oq=html+tur GENERELL INFO: - https://www.iu.hio.no/data/hovedprosjekt/ 23
Vedlegg 24
Vedlegg 1 : Kravspesifikasjon 1. Funksjonelle krav til websiden 1.1 Kalender 1.1.1 Alle besøkende skal kunne skifte måned. 1.2 Login 1.2.1 Registrerte brukere skal kunne logge inn ((brukernavn/passord). 1.2.2 Det skal være opplyst hvordan man blir medlem ved loginboksen. 1.3 Nyheter/Home 1.3.1 Alle besøkende skal kunne lese nyheter. 1.4 Medlemskap 1.4.1 Besøkende som vil bli medlem skal kunne fylle ut skjemaet og få tilbakemelding når man trykker registrer. 1.4.2 Skjemaet skal inneholde: Firstname, Lastname, Adress, Telephone, Date of Birth, E-mail, Password og Confirm password. 1.5 Bildegalleri 1.5.1 Alle besøkende kan se bildene. 1.5.2 Bildene må kunne forstørres. 1.6 About us/contact us og links 1.6.1 Skal inneholde relevant og ryddig tekst/informasjon som vi får tilsendt fra YFL Norway. 1.6.2 YFL Norways facebook-gruppe skal være synlig under minst en av disse punktene. 1.7 Admin 1.7.1 Administratoren skal kunne logge inn på samme måte som brukerne (brukernavn/passord). 1.7.2 Deretter kommer administratorbrukeren rett inn på admin-panelet hvor det skal være mulig å opprette/lagre og slette nyheter i tillegg til å laste opp bilder. 1.7.3 Det skal kun være en adminbruker; Denne fastsettes i databasen. 2. Diverse 2.1 Design 2.1.1 Det skal være enkle farger. YFL Norway og et illustrasjonsbilde skal alltid være synlig for de besøkende. 2.1.2 Kalender og login/du har logget inn skal være synlig under alle menyvalgene. 25
Vedlegg 2: Fremdrifsplan Uke Prosjektfase Milepæler Felles Atle Smenes Ian Kris Co Hasan Mahammed Sheekh 1-24 - Informere Møtelogg - Oppdatere prosjektside 2010 Oppstart - Finne arbeidsgiver - Skrive nødvendig dokumentasjon 1 2 Forprosjekt - Analyse av prosjekt/skisse av det ferdige produktet - HTMLskisse 3 - Fremdriftsplan - Ansvarlig for forprosjektdokumentasjon 4 - Kravspesifikasjon 5 6 Utvikling - HTML 7 8 - PHP-oppstart 9 - Login/medlemskap 10 - Bildegalleri 11 12 - Aktiviteter 13 - Nyheter 14 - Oppsamling. 15 Utarbeidet et ferdig produkt 16 Testing/ Dokumentasjo n - Kommunisere jevnlig med YFL. - MySQL/Database - Klargjøre brukertest - Finne testpersoner - Kalender 17 - Utføre tester - Analysere testene 18 19 - Rette opp feil 20 - Hovedansvar dokumentason 21 22 Ferdig med dokumentasjon 23 Presentasjon - Klargjøre presentasjonen - 24 Avholde presentasjonen
Vedlegg 3: Risikoplan Oversikt over potensielle risikoer: Risiko Sannsynlighet Følger Sykdom Veldig høy Moderat Ikke rekke deadline for levering Moderat Katastrofalt Tekniske Problemer Moderat Alvorlig Faglige problemer Høy Akseptabelt Motivasjon/Enkelte medlemmer gjør ikke oppgavene sine Endringer i prosjektet underveis Liten Moderat Alvorlig Akseptabelt Tap av gruppemedlem Veldig lav Alvorlig Hvordan forebygge/håndtere risikoene: Risiko Sykdom Ikke rekke deadline for levering Tekniske problemer Strategi Viktig med jevnlige møter sånn at vi får vite det fortest mulig. Vedkommende må fortelle med en gang at han er syk, og i så fall for syk til å gjøre sitt arbeid, da må det bli delt imellom resterende gruppemedlemmer. Gruppen setter alltid interne tidsfrister som oftest en uke i forkant - for å forebygge mot dette faremomentet. Om noen av gruppemedlemmene eller gruppen som helhet fortsat, ikke har rukket å gjøre sitt arbeid, så har de par dager ekstra til den endelig leveringen Det vil alltid være en risiko for at data går tapt, menn vi har hele tiden dataene våre på tre forskjellige maskiner i tillegg til prosjekthjemmesiden.
Faglige problemer Motivasjon/Enkelte medlemmer gjør ikke oppgavene sine Endringer i prosjektet underveis Tap av gruppemedlem(mer) Det er veldig viktig å følge med på undervisningene og stille jevnlige fagaktuelle spørsmål til veileder - som kan hjelpe oss i tilfelle noe er uklart. Det blir viktig å holde jevnlige møter for å holde motivasjonen oppe, og slippe gratispassassjerer. Sørge for å dele oppgavene rettferdige er også viktig. Medlemmer som ikke gjør sitt vil skape problemer for seg selv, og derfor er sannsynligheten lite for at det skjer. Det kan hende vi finner ut at dette blir for mye, eller dette skal vi ikke ha med. Derfor er det viktig å ha et ordentlig møte før vi starter selve prosessen hvor vi gjør klart hva som må gjøres, hvor mye tid det kommer til å ta og så videre. Dette er selvfølgelig leit, og sannsynligheten for at det skjer er veldig lav. Hvis det derimot skjer så blir strategien følgende; Vi må bare fordele oppgavene til medlemmet gjennom de resterende. Det blir selvfølgelig ekstraarbeid, men dette er det eneste alternativet 28
Vedlegg 4: Prototype 29
30
31
32
33
Vedlegg 5: Møteplan Beskrivelse: Dag: Starttidspunkt (gruppeleder vil være tilstede fra) Slutt (Romnummer) Uke 3: Mandag: 1215 (1030) - 1430 Onsdag: 1415 - (Tor Krattebøl) (Møtes utenfor kontoret hans i 3. etasje) Torsdag: 1215 (1030) 1430 Uke 4: Mandag: 1215 (1030) - 1430 Onsdag: 1415 - (Tor Krattebøl) (Møtes utenfor kontoret hans i 3. etasje) Fredag: 1215 (1030) 1430 Uke 5: Mandag: 1215 (1030) 1430 (PE238) Onsdag: 1415 - (Tor Krattebøl) (Møtes utenfor kontoret hans i 3. etasje) Fredag: 1230 (1030) 1430 (PE322) Uke 6: Mandag: 1230 (1030) 1430 (PI232) Onsdag: 1415 - (Tor Krattebøl) (Møtes utenfor kontoret hans i 3. etasje) Fredag (avgjøres onsdag): 1230 (1030) 1430 Uke 7: Mandag: 1230 (1030) 1430 Onsdag: 1415 - (Tor Krattebøl) (Møtes utenfor kontoret hans i 3. etasje) Fredag: 1230 (1030) 1430 (PI232) Uke 8: Mandag: 1230 (1030) 1430 (PI237) Onsdag: 1415 - (Tor Krattebøl) (Møtes utenfor kontoret hans i 3. etasje) Torsdag/Fredag: 1230 (1030) 1430 Uke 9: Mandag: 1230 (1030) 1430 (?) Onsdag: 1415 - (Tor Krattebøl) (Møtes utenfor kontoret hans i 3. etasje) Torsdag: 1230 1230 1630 (PI334) Uke 10: Mandag: 1000 Gruppearbeid i tillegg til veiledermøte 1300 (Tor Krattebøl). Onsdag: Kort møte fra 1430-1530. Fredag: 1230 (1030) 1430 (?) 34
Uke 11: Tirsdag: 1230 (1030) 1430 (?) Onsdag: 1415 - (Tor Krattebøl) (Møtes utenfor kontoret hans i 3. etasje) Uke 12: Tirsdag: 1230 (1030) 1430 (?) Onsdag: 1415 - (Tor Krattebøl) (Møtes utenfor kontoret hans i 3. etasje) Fredag: 1230-1600 (?) Uke 13: Mandag: 1200 (1030) 1500 (?) Tirsdag: 1200 (1030) 1500 (?) Onsdag: 1415 - (Tor Krattebøl) (Møtes utenfor kontoret hans i 3. etasje) Fredag: 1200-1600 (PI230) Uke 14: Mandag: 1200 (1030) 1500 (Pi336) Onsdag: 1415 - (Tor Krattebøl) (Møtes utenfor kontoret hans i 3. etasje) Torsdag: 1200-1600 (Pi336) Uke 15: Mandag: 0900 1530 (Pi335) Tirsdag: 1230-1500 (Pi336) Onsdag: 1415 - (Tor Krattebøl) (Møtes utenfor kontoret hans i 3. etasje) Torsdag: 1230-1500 (Pi336) Uke 16: Påskeferie Uke 17: Tirsdag: 1230-1500 (?) Onsdag: 1415 - (Tor Krattebøl) (Møtes utenfor kontoret hans i 3. etasje) Fredag: 1230 1600 (PE322) Uke 18: Mandag: 0900 1400 (Arbeidsdag) (PE238 reservert fra 1000 (møtes 0900) til 1400) Onsdag: 1415 - (Tor Krattebøl) (Møtes utenfor kontoret hans i 3. etasje) Torsdag: 1230 1500 (PE321) Fredag: 1230 1500 (PE321) 35
Uke 19: Mandag: 1230-1500 (Pi335) Onsdag: 1300 - (Tor Krattebøl) (Møtes utenfor kontoret hans i 3. etasje) Fredag: 1300-1600 (PI335) Uke 20: Mandag og tirsdag (fridager). Onsdag: Arbeidsdag 0830-1500 (+ møte med Tor 1300) Torsdag: 1230-1500 (?) Fredag: 1230-1500 (Pi336) Uke 21: Mandag: 1230-1500 (?) Tirsdag: Dokumentasjonen skal leveres og skrives ut. Torsdag: 1230-1500 (?) Uke 22: Mandag: 1230-1500 (?) Tirsdag: Frist for levering av dokumentasjon og CD med ferdig produkt. Uke 23 -> Prosjektfremføring 16.6. 36