Oppdragsgiver: Statsbygg Kontaktperson: May Liss Urang. Veileder: Norun-Christine Sanderson, HiO

LISENSSYSTEMET 29.01.2010 Forprosjektrapport Oppdragsgiver: Statsbygg Kontaktperson: May Liss Urang Veileder: Norun-Christine Sanderson, HiO Skrevet av prosjektgruppe 10-24 Nam Nguyen, s148093 Ingolf Nistad, s148174 Huan Duong, s148210 Nhi Doan, s148107

SAMMENDRAG Dette dokumentet skal gi deg en oversikt over resultatene av analysearbeidet som gruppen har utført. De viktigste konklusjonene er: Systemet må forholde seg til Adobe-produkt lisensavtalen. Systemet skal utvikles i ASP.Net og C#. Vi skal bruke Visual Studio 8 som utviklingsverktøy. Det skal ikke koste noe å implementere systemet, men Statsbygg må sette opp en Windows server og en Oracle database for gruppen. Vi har valgt Unified Process som utviklingsmetode. Gruppen har laget en enkel use-case og en liste over de viktigste funksjonene i systemet og dette er i samsvar med oppdragsgiverens krav og ønsker. Vi har også drøftet suksessfaktorer, laget samarbeidsavtale, arbeidsplan og fremdriftsplan for å sikre at vi får en god utviklingsprosess. Vi kaller systemet vårt for Lisenssystemet. 1

INNHOLDSFORTEGNELSE Sammendrag... 1 1 Presentasjon... 4 1.1 Oppdragsgiver & kontaktperson... 4 1.2 Veileder... 4 1.3 Gruppe... 5 2 Mål & rammebetingelser... 6 2.1 Bakgrunn... 6 2.2 Prosjektmål... 6 2.2.1 Effektmål... 6 2.2.2 Resultatmål... 6 2.3 Rammebetingelser... 7 2.3.1 Økonomi... 7 2.3.2 Tid... 7 2.3.3 Utviklingsverktøy... 7 2.3.4 Avtaler... 7 3 Prosjektbeskrivelse... 8 3.1 Dagens situasjon... 8 3.2 Svakheter i det gamle systemet... 9 4 Løsning & alternativer... 9 4.1 Løsning... 9 4.2 Omfang... 10 4.3 Enkel Use-case... 10 4.4 Utviklingsmiljø... 10 4.5 Avgrensninger... 11 4.6 Andre alternativer... 11 5 Organisering... 12 5.1 Organisasjonskart... 12 5.2 Rollefordeling... 12 5.3 Ansvarsforhold... 12 5.3.1 Generell... 12 5.3.2 Gruppen... 13 6 Metodevalg... 13 6.1 Drøfting av prosessmetoder... 13 6.2 Prosjektets varighet og midler... 14 6.3 Endelig Valg... 14 2

6.4 Faser i prosjektet... 14 7 Planlegging, oppfølging & rapportering... 15 7.1 Veiledermøte... 15 7.2 Gruppemøte... 15 8 Kvalitetssikring... 16 8.1 Møteregler... 16 8.2 Dokumenthåndtering... 16 8.3 Timelister... 16 8.4 Arbeidstid... 16 9 Suksessfaktorer... 17 9.1 Mennesker... 17 9.2 Produkt... 17 9.3 Teknologi... 17 9.4 Prosess... 18 10 Plan for gjennomføring... 18 10.1 Milepæler... 18 10.2 Fremdriftsplan... 18 10.3 Arbeidsplan... 18 Vedlegg 1: Prosjektskisse Vedlegg 2: Samarbeidsavtale Vedlegg 3: Lisensavtale Vedlegg 4: Møtereferat standard Vedlegg 5: Gruppeavtale Vedlegg 6: Fremdriftsplan Vedlegg 7: Arbeidsplan 3

1 PRESENTASJON 1.1 OPPDRAGSGIVER & KONTAKTPERSON Statsbygg er statens sentrale rådgiver i bygge- og eiendomssaker, byggherre, eiendomsforvalter og eiendomsutvikler. Statsbygg er en statlig forvaltingsbedrift. Bedriftens oppgave er å tilby gode og funksjonelle lokaler til statlige virksomheter, og å realisere vedtatte samfunnspolitiske mål i forhold til arkitektur, statlige planinteresser, kulturminnevern og miljø. Vår kontaktperson hos bedriften er May Liss Urang. Hun er underdirektør for IKT seksjonen i Statsbygg og er leder for IT-support. Det mest kjente navnet for denne enheten er Teknotorget. Det hele navnet for Teknologitorget. IT-support er en av tre enheter i IKT avdelingen. De to andre er Drift og System. Teknotorget er frontlinje som møter bedriftens brukere hyppigst og gjør det de kan for å støtte dem gjennom teknologiens til tider utfordrende arbeidsdag. Bildene under illustrerer bedriftens struktur. Det første bildet er tatt fra bedriftens intranettsider. Det andre har vi laget i Word. IKT IT-Support (Teknotorget) IT-Drift IT-System Systemet vi skal implementere skal betjenes av Teknotorget. Vi beskriver problemet og løsningen mer detaljert i prosjektbeskrivelsen. 1.2 VEILEDER Vår veileder er Norun Christine Sanderson. Hun er førsteamanuensis ved institutt for data, Høgskolen i Oslo. 4

1.3 GRUPPE Gruppen består av fire avgangsstudenter. Vi har kjent hverandre siden første klasse på Høgskolen. I de tre siste semestrene har vi hatt mange fellesfag. Det har gitt oss mulighet til å samarbeide og bli bedre kjent med hverandre. Det er ikke et tilfeldig at vi har valgt å jobbe sammen i hovedprosjektet. Vi samarbeider fordi vi stoler på hverandre. Vi kjenner hverandres arbeidskapasitet og ambisjoner. Vi vet at vi kan være den andres energi- og inspirasjonskilde, og omvendt. Nhi og Ingolf har god kompetanse innenfor systemutvikling. Nam og Huan har solide kunnskaper innenfor programmering. Vi har hatt fag som universell utforming og menneske-maskin interaksjon. Vi er en enhet som jobber mot et felles mål! Gruppemedlem: Ingolf Nistad Studieretning: Anvendt datateknologi Alder: 25 år Favoritt Adobe-produkt: Acrobat Gruppemedlem: Nhi Doan Studieretning: Anvendt datateknologi Alder: 22 år Favoritt Adobe-produkt: PhotoShop ver.7 Gruppemedlem: Huan Duong Studieretning: Informasjonsteknologi Alder: 24 år Favoritt Adobe-produkt: Photoshop CS3 Gruppemedlem: Nam Nhat Le Nguyen Studieretning: Informasjonsteknologi Alder: 25 år Favoritt Adobe-produkt: Flash Professional CS5 Vi skal beskrive oppgave og rolle til hvert enkelt gruppemedlem i kapittel 5 om gruppeorganisering. 5

2 MÅL & RAMMEBETINGELSER 2.1 BAKGRUNN Som nevnt i presentasjonsdelen består IKT avdelingen hos Statsbygg av Teknotorget, Driftseksjonen og Systemseksjonen. Teknotorget er en supportseksjon og de holder styr på Adobe produkter og lisenser. Per i dag bruker Teknotorget Excel regneark for å bevare Adobe lisenser. De synes dette er en dårlig løsning. Regnearket er verken koblet mot deres systemer eller relasjonsbasert. Det er både vanskelig og tidkrevende å håndtere dataene. Teknotorget har behov for et system som kan vise lisensene på en enkel og oversiktlig måte. Nam er vikar på Teknotorget og jobber en gang i uken. I fasen hvor vi skulle finne en prosjektoppgave fortalte han oss om Lisenssystemet som Teknotorget ville utvikle. Vi syntes det var en spennende oppgave og kontaktet Teknotorget. De gav oss tillatelse til å utvikle Lisenssystemet som vårt hovedprosjekt. Prosjektskissen og samarbeidsavtalen er den formelle bekreftelsen på at Statsbygg vil gi oss rett til å utvikle Lisenssystemet. Se vedlegg 1 og 2. 2.2 PROSJEKTMÅL 2.2.1 EFFEKTMÅL For Statsbygg Bedriften trenger et system som kan holde styr på Adobe lisenser. Det innebærer at løsningen må kunne vise hvem som har fått lisens og hvilken maskin som har lisens. Systemet må kunne implementeres i dagens infrastruktur i Statsbygg. For prosjektgruppen Prosjektet skal gi gruppemedlemmene relevant erfaring og mulighet til å bruke det vi har lært i løpet av studiet, samt videreutvikle kunnskaper innenfor programmering og systemutvikling. 2.2.2 RESULTATMÅL For Statsbygg Systemet skal implementeres som en intern nettside. Løsningen må være koblet mot katalogtjenesten Active Directory for å hente inn brukeropplysninger. Dataene skal lagres i en Oracle database. En god dokumentasjon må utvikles for vedlikehold og drift av systemet. For prosjektgruppen Vårt mål er å implementere et brukervennlig system som bedriften kan bruke når prosjektet er ferdig. Vi skal utarbeide en god dokumentasjon. 6

2.3 RAMMEBETINGELSER 2.3.1 ØKONOMI Det skal ikke koste noe å utvikle systemet. Vi får utviklingsverktøy fra skolen. Ingen andre utgifter eller kostnader skal settes på vår eller skolens regning. 2.3.2 TID Vi trenger en virtuell server og en Oracle database. Vi er litt usikre på kostnaden, men det skal bedriften ordne for oss. Teknotorget kan låne oss en eller to datamaskiner. Vi har ingen kapital å budsjettere i dette prosjektet. Prosjektperioden strekker seg fra november 2009 til slutten av mai 2010. Ukene i 2009 ble brukt til å finne oppdragsgiveren og klargjøre prosjektet, slik at gruppen kan starte for fullt i januar 2010. Disse ukene er egentlig ikke med i tidsrammen, men vi tar dem med for å vise helheten. Prosjektet starter fra og med 04.januar 2010 og varer fram til 31.mai 2010. Det vil si at vi har 24 uker. Hvis vi trekker i fra eksamensuken i februar, påskeferien i april og andre hellige dager så har vi omtrent 21 uker til disposisjon. 2.3.3 UTVIKLINGSVERKTØY IKT avdelingen setter ingen spesielle krav til utviklingsverktøy. Teknotorget ønsker at vi skal utvikle systemet i Java eller ASP.Net miljøet. Det gir oss frihet til å velge verktøy. Vi har valgt å kode systemet i ASP.Net og C# og bruker Visual Visual Studio 8 som utviklingsverktøy. Teknotorget vil at vi skal lagre dataene i en Oracle Database. Denne databasen får vi av bedriften sammen med den virtuelle serveren. 2.3.4 AVTALER Det er to avtaler som systemet og gruppen må forholde seg til. Den ene avtalen er kravene som bedriften har satt opp. Kravspesifikasjonen som gruppen senere skal utarbeide er en formell kontrakt for denne avtalen. Det eksisterer en lisensavtale mellom Adobe produsenten og Statsbygg. Gruppen og systemet vi utvikler må derfor også forholde seg til denne avtalen. Lisensavtalen er skrevet på engelsk og ligger på Adobes nettsider. 1 For å gjøre kontrakten mer tilgjengelig så har vi kopiert den inn i Word og lagt den i vedlegg 3. Vi skal oversette avtalen i kravspesifikasjonen. 1 Adobe lisensavtale: http://www.adobe.com/products/eulas/ 7

3 PROSJEKTBESKRIVELSE 3.1 DAGENS SITUASJON IKT avdelingen har per i dag gode systemer for å registrere samt bevare lisenser på alle produkter med unntak av Adobe produkter. Teknotorget bruker Excel regneark for å holde styr på Adobe lisenser. Denne seksjonen har ansvar for følgende produkter: Creative Suite 4.0 Adobe Professional 9.0 Adobe Professional Extended 9.0 PhotoShop Elements 5.0 IKT avdelingen har inngått en bedriftsavtale med produsenten Adobe. Avtalen går ut på at Statsbygg får kun en lisensnøkkel på hvert produkt, selv om de har kjøpt flere lisenser av produktet. Denne avtalen skal bidra til et lettere administrasjonsarbeid for de ansatte. Teknotorget bruker et regneark på hvert produkt. For hvert produkt må lisensnøkkelen registreres og antallet tilgjengelige lisenser. Hver rad i regnearket tilsvarer en lisens. Ved tildeling av lisens må det legges inn navnet til en ansatt og de maskinene som ansatten skal bruke. Vi viser i figuren under et eksempel på hvordan Statsbygg bruker regneark i Microsoft Excel som lisensoversikt. Dette illustrerer at bedriften har 5 lisenser som gjelder for produktet Creative Suite versjon 4.0. Administratoren Jens har gitt brukeren Kari Nordmann en lisens. To maskiner deler på denne lisensen og de er SB1234 og SB4321. Bedriften står igjen med fire lisenser. 8

3.2 SVAKHETER I DET GAMLE SYSTEMET De to største problemene med regnearket er: ikke-relasjonsbasert visning av data (flat data) ingen tilknytning til eksisterende system Det vi mener med ikke-relasjonsbasert visning av data er at dataene ligger i en enkel side eller et regneark. Det er vanskelig å kombinere regnearkene sammen for å se den totale oversikten. Eksempel 1: Det er nesten umulig å liste opp alle produktene som en bestemt ansatt har fått. De ansatte må i dette tilfellet lete gjennom regnearkene. Eksempel 2: Det vil være like ille som i eksempel 1 hvis Teknotorget skal liste opp alle produkter som har blitt installert på en bestemt maskin. Excel arkene er ikke koblet til noe system hos Statsbygg. Det blir problematisk for Teknotorget å detektere om sluttbrukere har fått lisens. Dette fordi Excel programmet ikke kan gi beskjeder eller advarsler hvis endringer blir gjort på brukerkontoer i Active Directory. Bruk av Excel regneark gir flere ulemper: dårlige søkemuligheter datasettet blir uhåndterlig hvis produktmengden øker Dette tyder på Excel regnearket ikke lenger egner seg som datastruktur i lengden. Vi mener at Teknotorget trenger et bedre og mer relasjonsbasert system, slik at det er lettere å behandle og kontrollere lisensene. Dette er drivkraften som igangsetter vårt prosjekt. 4 LØSNING & ALTERNATIVER 4.1 LØSNING Vår løsning er å utvikle et nettbasert system. Det er et krav fra bedriften at dataene skal lagres i en Oracle database. Vi skal sette opp databasen som en relasjonsdatabase. Slik blir det lettere å se relasjonen mellom bruker, maskin og produkt. 9

4.2 OMFANG Vi skal implementere følgende funksjoner i Lisenssystemet: registrere nytt produkt se lisensoversikt liste opp brukere og maskiner på et bestemt produkt registrere lisens til bruker og maskin se alle lisenser til en bruker se alle lisenser til en maskin slette lisens fra bruker og maskin registrere ny maskin detektere sluttbrukere og varsle Teknotorget Disse funksjonene er et resultat av analysearbeidet som gruppen har gjort i henhold til de krav og ønsker som Statsbygg har uttrykt i prosjektskissen. Vi skal beskrivelse funksjonene mer grundig og detaljert i kravspesifikasjonen. 4.3 ENKEL USE-CASE Vi har tegnet et enkelt Use-case diagram for å vise oversikt over de hovedfunksjonene. 4.4 UTVIKLINGSMILJØ Statsbygg ønsket at vi skulle utvikle systemet i programmeringsspråket Java. Slik at det er lettere for dem å vedlikeholde og utvide systemet. Nhi og Ingolf kan bare grunnleggende programmering i Java. Gruppen diskuterte med bedriften og vi fikk tillatelse til å implementere i ASP.Net og C#. Vi kunne bruke Visual Studio som utviklingsverktøy. 10

4.5 AVGRENSNINGER Foreløpig har vi tilfredstilt alle kravene fra oppdragsgiveren. Teknotorget ville at systemet skulle først og fremst registrere og håndtere Adobe produkter, men de ønsket også at vi kunne utvide systemet slik at det skal være mulig å legge inn andre produkter og lisenser. Vi skal utvikle denne funksjonaliteten, hvis vi har tid. 4.6 ANDRE ALTERNATIVER Vi er klar over at vårt system er ikke den eneste løsningen for Statsbygg. Det finnes minst to mulige alternativer som bedriften kan vurdere. Vi skal liste opp de to mulighetene og drøfte dem. Teknotorget kan: bruke Microsoft Access til å lagre dataene Registrering og modifisering av data i Access er omtrent lik som i Excel. Dette er en klar fordel, siden Teknotorget alltid har brukt Excel regnearkene som datastruktur. Andre fordeler som er verdt å nevne er: + Dataene i Access kan være relasjonsbasert, siden det er mulig å koble flere tabeller sammen. + En annen fordel er at Teknotorget kan kjøre effektive spørringer for å sortere og filtrere data. + Det er mulig å generere rapporter basert på dataene og vise dem i flere ulike formater. + Teknotorget kan også opprette websider for å presentere data med skrivebeskyttelse, eller for å få tilgang til data i et oppdaterbart format. Ulempen er at: - Det er ikke mulig å detektere sluttbrukere. Dette fordi Access ikke er koblet til Active Directory og programmet har ikke funksjon til å sende ut e-poster. - Administratoren må modifisere dataene direkte i Access. Dette kan føre til at dataene blir inkonsistens. Vi ser at Access gir mange fordeler i forhold til Excel. Det største problemet er at programmet kan ikke detektere sluttbrukere. Det gjør at Access er en bra løsning, men ikke bra nok! bestille et ferdiglaget system Denne løsningen er både enkel og rask. Det vil sikkert koste noe, men til gjengjeld får bedriften et system med svært mange fordeler og muligheter. Statsbygg valgte ikke den sistnevnte løsningen, selv om den så ut til å være den beste løsningen. Bedriften har i stedet valgt vår løsning fordi de vil bidra til læring og faglig utvikling hos studenter. De vil gi oss som studenter mulighet til å lære gjennom arbeid med realistiske og relevante arbeidsoppgaver. 11

5 ORGANISERING 5.1 ORGANISASJONSKART Nam leder Huan kontroller Nhi dokumentasjonsansvarlig Ingolf webansvarlig 5.2 ROLLEFORDELING Leder skal: være en megler hvis det oppstår konflikter i gruppen eller med oppdragsgiveren styre gruppemøtene beslutte hvis det oppstår uenigheter Kontroller skal: passe på at gruppen overholder innleveringsfrister passe på at gruppen følger samarbeidskontrakten som gruppen har signert minne gruppen på innleveringsfrister Dokumentasjonsansvarlig skal ta backup av alle dokumenter kvalitetskontrollere dokumenter sørge for at dokumenter følger en standard Webansvarlig skal være loggfører på alle møter oppdatere hjemmesiden jevnlig sørge for at alle få med seg oppdateringer Alle har fått sitt ansvarsområde i dette prosjektet, men vi setter ingen klare grenser mellom områdene. Det er lov å hjelpe andre, og det er lov å spørre om hjelp. 5.3 ANSVARSFORHOLD 5.3.1 GENERELL Norum-Christine Sanderson May Liss Urang Nam Nguyen veileder fra Høyskolen i Oslo kontaktperson og veileder fra Statsbygg gruppeleder 12

5.3.2 GRUPPEN Nam skal sette opp databasen, opprette forbindelse mot Active Directory. Huan skal kode brukergrensesnittet. Nhi og Ingolf skal designe brukergrensesnittet til systemet. De skal også ha ansvar for dokumentasjonen. Alle skal implementere systemet. Vi skal fordele funksjonene på gruppen når kravspesifikasjonen er ferdig. Dette er en foreløpig ansvarsplan. Vi har enda ikke begynt på prosjektet for alvor. Da er det vanskelig å bestemme omfang og arbeid i hver av de oppgavene. Vi må etter hvert kanskje endre på en eventuell skjev arbeidsfordeling innad i gruppen. 6 METODEVALG 6.1 DRØFTING AV PROSESSMETODER Gruppen har vurdert å benytte seg av en rekke forskjellige prosessmetoder. Til slutt kom vi frem til at Unified Process passer best til dette prosjektet. Fossefallsmetoden kunne til dels ha vært benyttet ettersom den baserer seg på trinnvis utvikling på følgende måte: Behovsundersøkelser/analyser design implementasjon integrering og testing Fossefallsmetoden er svært risikabel ettersom risikoer kan dukke opp underveis når man har gjort ferdig det forrige trinnet, og prosjektet kan måtte begynne på nytt. Gruppen skal innom disse stegene underveis i utviklingsprosessen, men det blir nok ikke like rigid som fossefallsmetoden tilsier. En annen metode som har vært vurdert kalles Cleanroom Software Engineering. Den går ut på at produktet skal kunne være sertifisert som å være stabilt og pålitelig. Dette er ikke et krav, selv om det er åpenbart at gruppens sluttprodukt må være til å stole på og være stabilt. Derfor har vi ikke valgt denne prosessmetoden. Vi har også sett på SCRUM, ettersom den er populær i mange IT-bedrifter nå om dagen. Likevel blir dette prosjektet for liten skala til at SCRUM kan benyttes av oss. Våre iterasjoner kan være lignende de såkalte «sprints» som man finner i SCRUM, samt at noen av rollene (Pig, Team leader, osv.) kan relateres til gruppemedlemmenes rolle innad i gruppen. Iterative metoder, det vil si en prosessmetode med flere iterasjoner (sykluser) kan bli vårt valg. Slike metoder går ut på: Førplanlegging planlegging krav analyse/design implementasjon. Hvis prosjektets produkt er tilfredsstillende, noe det sannsynligvis ikke er etter en halv iterasjon, iverksettes innfasingen. Valget må falle på en prosessmetode der det underveis i prosjektets gang er rom for endringer i krav, ansvarsområder og resultat. Gjerne en modell som begynner med planlegging. Vi har fått utdelt krav fra Statsbygg, og disse må selvfølgelig oppfylles, selv om vi har fått dispensasjon fra enkelte av dem. Dispensasjonen gjelder blant annet at systemet må være utviklet i programmeringsspråket Java, slik at Statsbygg har muligheten til å videreutvikle eller forbedre systemet. 13

6.2 PROSJEKTETS VARIGHET OG MIDLER Dette er et relativt lite prosjekt, som skal vare i rundt fem måneder. Vi kan si at deler av gruppen utgjør forskjellige grupper; med to hovedsaklig programmerere fra Informasjonsteknologi og to gruppemedlemmer fra Anvendt Datateknologi. Disse rollene er i konstant forandring ettersom ansvaret endres underveis samtidig som medlemmene tilegner seg ny kunnskap. Enkelte profesjonelle krav i systemutviklingsmetoden, for eksempel økonomirelaterte slike samt budsjetter kan utgå, ettersom alt teknisk utstyr og programvare som vi behøver gjøres tilgjengelig av Høgskolen i Oslo og Statsbygg. 6.3 ENDELIG VALG Gruppen har valgt å benytte seg av Unified Process. Dette er en omfattende systemutviklingsmetode, men den kan tilpasses våre behov. Inndelingen av utviklingen i faser passer til gangen i vårt hovedprosjekt. Unified Process (UP) er en objektorientert utviklingsmetode. Den blir gradvis innført i utviklingsmiljøene i IT-bedrifter over hele verden. En prosess er beskrevet som hvem (utviklere) som gjør hva (artefakter/delprodukter), hvordan (aktiviteter) og når (arbeidsflyt). 6.4 FASER I PROSJEKTET Idéfasen kan vi relatere til forprosjektet. Vi avslutter med denne fasen med en forprosjektrapport, som skal bli levert inn i slutten av januar. Denne fasen skal ikke ta lang tid. Gruppen setter opp prosjektomfang, med overordnet kravspesifikasjon og en enkel Use-Case-modell. I tillegg skal vi blant annet sette opp gruppeorganisering, oppfølgingsplan fra veileder og oppdragsgivere og kvalitetssikringen internt i gruppen. Unified Process inneholder også økonomiske spørsmål, men vi ser bort fra disse. Dette er lønnsomhetsvurderinger. Forprosjektrapporten er denne rapporten som du leser nå. Utdypningsfasen begynner uken etter innleveringen av forprosjektrapporten. Her skal vi tegne diagrammer og planlegge utviklingen. Kravspesifikasjonen kan kunne måtte endres. Use-casene blir utviklet, klassediagrammer og sekvensdiagrammer blir skissert. I tillegg planlegger vi å lage vi flere prototyper av systemet. Tegning av skisser på papir kan bli aktuelt, samt å bruke programvaren Axure RP til å lage digitale prototyper av systemets brukergrensesnitt. I denne fasen har vi også tenkt å bruke til å bli kjent med Statsbygg sine systemer, og å lære oss eller utvikle kunnskapen innenfor forskjellig programvare og programmeringsspråk. Ettersom gruppemedlemmene har forskjellige roller får vi forskjellige ansvarsområder. Dette fører til at enkelte av oss kan kunne måtte lære seg eller videreutvikle deres kjennskap til for eksempel Oracle databasespørringer og Adobe PhotoShop. I tillegg skal vi utvikle vår kunnskap innenfor programmeringsspråket C# og utviklingsverktøyet Microsoft Visual Studio. Konstruksjonsfasen kan vi si blir tiden etter at gruppemedlemmene er ferdig med konteeksamen. Det er i slutten av februar. I denne fasen må tegning av diagrammer og skisser være ferdigstilt, og vi må ha dannet oss et bilde av hvordan systemet burde fungere og se ut. Gruppen må ferdigstille flere delleveranser i løpet av dette stadiet. Regelmessige møter kan gjøre at små milepæler blir gjennomført fortløpende. Iblant kan nok resultatet bli tilfredsstillende etter første iterasjon, men mange milepæler må sannsynligvis gjennom flere iterasjoner i konstruksjonsfasen. 14

Gruppen skal teste systemet internt i slutten av denne fasen. Da må vi utføre integrasjonstesting, det vil si å sette sammen enhetene til et helhetlig system. Når resultatet er tilfredsstillende skal vi teste systemet sammen med vår veileder. Det neste steget blir å gjøre såkalt in-house systemtesting hos Statsbygg med flere av deres ansatte til stede. Dette blir begynnelsen på overgangsfasen. I overgangsfasen finpusses systemet, og vi retter opp eventuelle småfeil som er funnet i sluttfasen av konstruksjonsfasen. Vi setter systemet i drift når feilene er rettet opp. Vi har laget bildet for å vise fasene i prosjektet. Idefase Utdypningsfase Konstruksjon Overgang 7 PLANLEGGING, OPPFØLGING & RAPPORTERING Det skal lages et møtereferat for hvert møte. Møtereferater skal lastes opp på hjemmesiden. Vi har utarbeidet en standard på føring av møtereferat, slik at det er lettere å få med seg viktige beslutninger og frister i hvert møte. Møtereferatstandarden ligger i vedlegg 4. Hjemmesiden til prosjektet må oppdateres jevnlig for å gi gruppen, veilederen og oppdragsgiveren et nøyaktig bilde av gangen og framdriften i prosjektet. 7.1 VEILEDERMØTE Vi skal møte veilederen hver tirsdag, kl 12 30 på hennes kontor ved Høyskolen i Oslo. Vi skal snakke om hva gruppen har gjort og fått til i den uken som har gått. Veilederen kan også bruke denne tiden til å gi tilbakemeldinger på arbeid eller rapporter som gruppen har levert inn på forhånd. 7.2 GRUPPEMØTE Vi møter fast hver tirsdag, etter veiledermøtet, for å diskutere prosjektets fremdrift, lage planer og fordele arbeidsoppgaver. Blant annet må vi sammenligne timelister slik at hver enkelt vet hvor mye arbeid vedkommende har gjort i forhold til de andre i gruppen for uken som har gått. I tillegg kan vi løse konflikter hvis de skulle oppstå underveis. 15

8 KVALITETSSIKRING 8.1 MØTEREGLER Alle møter presis til møter som har blitt avtalt på forhånd. Vi skal være forberedt og forholde oss saklig. Å være forberedt betyr at du har lest gjennom relevante dokumenter, sett på oppgaver eller tenkt på saker som skal tas opp. Møtene er hellige! Mobiltelefonen skal være av. Vi har utarbeidet en gruppeavtale hvor reglene er mer formelt skrevet. 8.2 DOKUMENTHÅNDTERING Alle dokumenter sendes til dokumentasjonsansvarlig. Nhi har denne rollen. Han har ansvaret for å ta backup av dokumenter. Les mer om oppgaven til dokumentasjonsansvarlig på punkt 4.3 under rollefordeling. Dokumenter som legges på hjemmesiden skal være i PDF-format eller i et format som ikke er mulig å redigere. Ingen Word-dokumenter skal legge på nettet. Dette skal sikre at ingen misbruke vårt arbeid. 8.3 TIMELISTER Alle skal ha ansvar for å loggføre sitt arbeid og oppdatere timelisten. Dette skal vises under gruppemøter. 8.4 ARBEIDSTID Dagene vi skal jobbe sammen: Mandag: 09 00-16 00 hos Statsbygg, Byporten. Tirsdag: 09 00-16 00 på skolen Onsdag: 12 30-16 00 på skolen Fredag: 09 00-15 00 på skolen Vi samarbeider nesten hver dag. Hver av oss har gjennomsnitt arbeidstid på 22 timer. Gruppen jobber ikke sammen på torsdager. Dette fordi noen av oss har forelesninger og Nam er på jobb den dagen. Vi planlegger å møtes hver torsdag etter 16 00 for å spise sammen. 16

9 SUKSESSFAKTORER For å lykkes i dette prosjektet er det fire dimensjoner som vi må ta hensyn til: mennesker, produkt, teknologi og prosess. 9.1 MENNESKER Gruppemedlemmer er dimensjonen som vil påvirke produktiviteten i prosjektet mest. For å sikre produktiviteten har vi lagt vekt på følgende faktorer: Motivasjon Alle medlemmer i gruppen syntes prosjektet virket interessant og bestemte selv å jobbe med det. Vi satser derfor på at prosjektarbeidet i seg selv er kilde til inspirasjon og motivasjon hos den enkelte. Lagånd Vi skal sitte sammen og jobbe med prosjektoppgaven. Det er viktig å ha god kontakt med de andre i gruppen. Alle må respektere gruppeavtalen. Jobbtilpasning Vi fordeler arbeidsoppgavene etter kvalifikasjonene til den enkelte. Arbeidsmengden må ikke bli for stor. Vanskelighetsgraden skal være litt utfordrende, men ikke alt for krevende. Selvutvikling Vi hjelper hverandre med å finne oppgaver vi kan lære noe av. Arbeidsmiljø Vi sørger for at alle stortrives i gruppen. Dette kan vi få til med åpenhet og toleranse. Vi har skrevet en gruppeavtale der alle gruppemedlemmene har signert under. Hensikten med avtalen er så sikre at vi får et godt arbeidsmiljø. Avtalen ligger i vedlegg 5. 9.2 PRODUKT Vi må fokusere på produktets størrelse og karakteristikk hele tiden. Gruppen må rådføre seg med veilederen hvis oppdragsgiveren ønsker å legge til andre funksjoner. Vi kan ikke godta store endringer i systemet, fordi det vil koste oss ekstra tid og arbeid. Endringer kan påvirke prosjektplanleggingen på en negativ måte. 9.3 TEKNOLOGI Det er viktig å velge riktig teknologi og utviklingsverktøy. Vi må velge verktøy og utviklingsspråk som vi behersker. Ved å gjøre riktige valg kan prosjektet oppnå høyere utviklingshastighet, som igjen vil skape motivasjon og arbeidsglede. Som vi har nevnt tidligere, i punkt 3.4 om utviklingsmiljø, vil Statsbygg at vi skal implementere systemet i Java, fordi de har flest ekspanderingsmuligheter dersom vi bruker dette programmeringsspråket. Hvis vi velger å implementere systemet i Java kan vi regne med å få masse hjelp og råd fra disse ansatte. 17

Problemet er at det er kun to av oss som kan programmere i Java. Utviklingsarbeidet kan bli stort hvis vi har bare to programmerer. For at alle skal bidra i utviklingsprosessen og prosjektet så har vi valgt å programmere i ASP.Net og C#. Fordi alle i gruppen kan programmere i disse språkene. 9.4 PROSESS Prosessen er like viktig som menneskedimensjonen. For å sikre oss en god prosess i prosjektet har vi fokusert på følgende faktorer: Risikohåndtering Oppdragsgiverstilpasning Unngå å gjøre ting to ganger Levere delleveranser med riktig kvalitet Overholde frister 10 PLAN FOR GJENNOMFØRING 10.1 MILEPÆLER Statusrapport fred. 30. okt. 2009 kl. 15 00 Prosjektskisse fred. 04. des. 2009 kl. 15 00 Forprosjekt fred. 29. jan. 2010 kl. 15 00 Prosjektrapport man. 31. mai 2010 kl. 12 00 Presentasjonen 14-17. juni 2010 10.2 FREMDRIFTSPLAN Se vedlegg nr. 6 10.3 ARBEIDSPLAN Se vedlegg nr. 7 18

Vedlegg til forprosjekt Vedlegg 1: Prosjektskisse Vedlegg 2: Samarbeidsavtale Vedlegg 3: Lisensavtale Vedlegg 4: Møtereferat standard Vedlegg 5: Gruppeavtale Vedlegg 6: Fremdriftsplan Vedlegg 7: Arbeidsplan

Vedlegg 1 Prosjektskisse Forprosjekt

Vedlegg 2 Samarbeidsavtale Forprosjekt

Vedlegg 2 Samarbeidsavtale Forprosjekt

Vedlegg 3 Lisensavtale Forprosjekt ADOBE PRODUCT LICENSE AGREEMENTS Home use of Macromedia branded products Notwithstanding the terms of the product license agreement included within a Macromedia branded product, when such a product is licensed through Adobe s Open Options licensing program (not including Student Licensing, Site Licensing, and Term Licensing), the primary user of the computer on which such software is lawfully installed may install a second copy of such software for his or her exclusive use on either a portable computer or a computer located at his or her home, provided that the software on the portable or home computer is not used at the same time as the software on the primary computer.

Vedlegg 4 Møtereferat standard Forprosjekt

Vedlegg 5 Gruppeavtale Forprosjekt

Vedlegg 5 Gruppeavtale Forprosjekt

Vedlegg 6 Fremdriftsplan Forprosjekt

Vedlegg 7 Arbeidsplan Forprosjekt Arbeidsplan Ansvarlig Alle Nam Nam Huan og Nhi Ingolf Aktivitet Forklaring Antatt startdato Antatt utført dato Finne gruppe danne en gruppe mellom 3-4 pers. 05.10.2009 Finne prosjektoppgave finne oppgaven til hovedprosjekt 06.10.2009 26.10.2009 Statusrapport En beskrivelse av hva vi har gjort for å få tak i et prosjekt 26.10.2009 29.10.2009 Prosjektskisse Beskrivelse/skisse av prosjektet 02.11.2009 30.11.2009 Samarbeidsavtale Datainnsamling Enkel use-case modell Overordnet kravspesifikasjon Arbeidsplan Fremdriftsplan en formell avtale mellom arbeidsgiveren og HiO om prosjektet ANALYSE møter veilederen og kontaktpersoner hos arbeidsgiveren lage use case over de viktigste funksjoner avtale med oppdagsgiver om hva som skal gjøres lister opp de viktigste aktivitetene i prosjektprosessen og bestemmer en frist for dem bruker Gantt-diagram til å planlegge prosjektarbeidet 04.01.2010 22.01.2010 uke 2 uke 4 uke 2 uke 4 uke 2 uke 4 uke 3 uke 4 uke 3 uke 4 Alle Forprosjektrapport analyse mål og rammebetingelser uke 2 uke 4 UTDYPNING Alle Detaljeres Use Case utarbeider use case beskrivelser uke 4 uke 7 Nam Detaljeres kravspesifikasjon detaljerer funksjonskravene uke 5 uke 7 Nhi og ER-diagram grafisk framstilling av strukturen til uke 6 uke 7 Huan databasen Nam Ingolf Huan, Nhi og Ingolf Nam Nam Ingolf, Huan og Nhi Nam UML-diagram Risikohåndtering Grensesnitt Databaseoppsett Serveroppsett Implementere grensesnittet Implementere systemet tegne klassediagram, sekvensdiagram, use case diagram vurderer og forebygger risikoer som kan inntreffe utarbeider et utkast av brukergrensesnittet KONSTRUKSJON kobler til Oracle databasen, samt skriver script for å lage tabeller setter opp IIS og installerer MS Visual Studio koder grensesnittet som gruppen har designet i utdypningsfasen, bruker CSS og ASP.NET kontroller koder systemet I C# og kjører Oracle spørringer uke 5 uke 7 uke 6 uke 7 uke 4 uke 7 uke 9 uke 9 uke 9 uke 9 uke 9 uke 19 uke 9 uke 20

Vedlegg 7 Arbeidsplan Forprosjekt TESTING Alle Skrivebordstest manuell kodelesing, kvalitetskontroll og lesbarhets-kontroll en annens kode uke 11, 15 uke 11, 15 Alle Alle Huan og Nhi Alle Alle Integrasjonstest Beta-testing Browsertesting Enhetstest Idriftsettelse enhetene settes til et system og tester at de virker sammen gruppen skal demontere systemet for veileder og oppdragsgiver sjekker at systemet virker i nettleser som IE, Chrome og Firefox alle må teste sin enhet under programmeringen OVERGANG uke 15 uke 17 uke 16 uke 17 uke 18 uke 19 uke 9 uke 20 kobler systemet til Statsbygg intranett uke 18 uke 19 Nam Alle Feilretting i integrasjonstest Styringsdokumentasjon retter opp feil i som oppdages i betatesting DOKUMENTASJON inneholder prosjektskisse, prosjektdagbok, forprosjektrapport, arbeidsplan, fremdriftsplan og kravspesifikasjon uke 18 uke 20 uke 3 uke 7 Ingolf Prosessdokumentasjon beskriver prosjektprosessen uke 2 uke 20 Nhi og Huan Testdokumentasjon inneholder testresultater uke 11 uke 20 Nhi og Huan Brukerdokumentasjon inneholder brukermanual uke 17 uke 20 Nam Produktdokumentasjon beskriver systemets egenskaper og funksjonalitet uke 18 uke 20 Alle Stifte dokumentene sammen uke 21 uke 21