INNHOLDSFORTEGNELSE. PJ 501 Vedlegg NITH. Gruppe 15 1 av 145

Transkript

1 INNHOLDSFORTEGNELSE 1.0 PROSESSDUMENTER PRESENTASJON AV FORSKNINGSPROSJEKTET BEDRE DIALOG UTOPIDUMENT Utopidokument per Vurdering av utopidokument opp mot prosjektoppgave og oppdragsgiver per ARBEIDSKONTRAKTER Opprinnelig arbeidskontrakt ( ) Revidert arbeidskontrakt ( ) PROSJEKTORGANISERING ADRESSELISTE MED ROLLER OG ANSVARSOMRÅDER PROSJEKTPLANER Overordnet prosjektplan Iterasjon Iterasjon Iterasjon Iterasjon Iterasjon Iterasjon Iterasjon 7 del Iterasjon 7 del Iterasjon STATUSRAPPORTER Statusrapport iterasjon Statusrapport iterasjon Statusrapport iterasjon Statusrapport iterasjon Statusrapport iterasjon Statusrapport iterasjon Statusrapport iterasjon Statusrapport iterasjon TIMELISTER Timeliste for Mette Andersen Timeliste for Jørgen Fundingsrud Timeliste for Tor-Morten Grønli Timeliste for Irjan Javo Timeliste for Kenneth Lilleaas Antall timer gruppemedlemmene har arbeidet i de ulike iterasjonene SKAPT VERDI Beregningsmodell for skapt verdi MØTEINNKALLELSER OG REFERATER Referat prosjektmøte 13. januar Innkalling prosjektmøte Referat prosjektmøte Innkalling, prosjektmøte Referat prosjektmøte 02. mai RISIKODEFINERING Risikoliste for hele prosjektet Iterasjon 1 (13. januar 22. januar 2004) Iterasjon 2 (27. januar 05. februar 2004) Iterasjon 3 (10. februar 19. februar 2004) Iterasjon 4 (24.februar 04. mars 2004) Iterasjon 5 ( ) Iterasjon 6 (01. mars mars 2004) Iterasjon 7 (15. mars - 23.april 2004) Iterasjon 8 (26.april 07. mai 2004) DE NI INNTRUFNE RISIKO I PROSJEKTPERIODEN Feil tidsestimering av en aktivitet (6) Sykdom inntil to dager for systemerere (5) Problemer med programvare (4) Gruppe 15 1 av 145

2 Sykdom over lengre tid for programmerer (3) Utvikling av systemet krever mer enn vi hadde forventet (2) Mangel på motivasjon (2) Problemer på grunn av manglende kunnskaper (2) Sykdom over lengre tid for systemerere (1) Sykdom inntil to dager for programmerere (1) RETNINGSLINJER FOR INTELLEKTUELL REDELIGHET VED NITH REFLEKSJONSNOTATER Refleksjonsnotat for Mette Andersen Refleksjonsnotat for Jørgen Fundingsrud Refleksjonsnotat for Tor-Morten Grønli Refleksjonsnotat for Irjan Javo Refleksjonsnotat for Kenneth Lilleaas Felles refleksjonsnotat ARKITEKTUR MODELLER DOMENEMODELL LAGDELING VERSJON BRUKSTILFELLE MODELLER Administrer kontakt Generer rapport versjon Generer rapport versjon SEKVENSDIAGRAMMER Ny kontakt Hente ut kontakter TESTDUMENTER DATABASETEST ENHETSTESTING OG SKRIVEBORDSTESTING Testskjema for aktivitet Testskjema for aktivitet Test for aktivitet Testskjema for kontaktperson Testskjema for kontaktperson Testskjema for kontaktperson Testskjema for kontaktperson Test for kontaktperson Testskjema for kontakt Testskjema for kontakt Testskjema for kontakt Testskjema for kontakt Test for kontakt Testskjema for konkurrent Testskjema for konkurrent Testskjema for konkurrent AKSEPTANSETEST Akseptansetest Akseptansetest Akseptansetest SYSTEMTEST SYNTAKS FOR KODE I TROJA.NET KRAVSPESIFIKASJON FOR BRUKERGRENSESNITTET BAKGRUNNHISTORIE OM DEN TROJANSKE HESTEN CRM FOR SMÅBEDRIFTER, REFERAT FRA ARTIKKEL SKREVET AV WILLY VERWOERD FOR PC WORLD NORGE (2003) ACT! HANSA OFFICE/ MAMUT CRM & SALES PROFESSIONAL Gruppe 15 2 av 145

3 7.4 VEGA SMB FEILLISTE DATABASEN Lagring av fil til aktivitet Sletting av fil i activityfull tilknyttet aktivitet Sletting av hovedkontor og dets underkontorer Feilhåndtering DIVERSE Sletteknappen i personcontactfull Tab Index Sorteringsknappene Postnummer Eksport av rapport til.pdf eller.html format ANBEFALINGER FOR VIDERE ARBEID BRUKERGRENSESNITT Marker hvor i systemet brukeren er Underliste Undermenyene bør midtstilles DATABASEN Dataflyt til og fra databasen Lagring mot databasen DIVERSE Registrering direkte fra kontaktskjema eller aktivitetbildet Hjemmeside/e-post link Postnummer med mer enn fire siffer Et underkontor bør og kunne være et hovedkontor Lagring Søkevindu DATAPERSPEKTIV FIGURLISTE Figur 1, faseplan...13 Figur 2, prosjektplan for iterasjon Figur 3, prosjektplan for iterasjon Figur 4, prosjektplan for iterasjon Figur 5, prosjektplan for iterasjon Figur 6, prosjektplan for iterasjon Figur 7, prosjektplan for iterasjon Figur 8, prosjektplan for iterasjon 7, nummer Figur 9, prosjektplan for iterasjon 7, nummer Figur 10, prosjektplan for iterasjon Figur 11, timeliste for Mette...35 Figur 12, timeliste for Jørgen...37 Figur 13, timeliste for Tor-Morten...40 Figur14, timeliste for Irjan...42 Figur 15, timeliste for Kenneth...45 Figur 16, antall arbeidstimer per iterasjon...46 Figur 18, beregningsmodell...47 Figur 19, skapt verdi graf...48 Figur 20, risikoliste for hele prosjektet...54 Figur 21, risikoliste for iterasjon en...57 Figur 22, risikoliste for iterasjon to...57 Gruppe 15 3 av 145

4 Figur 23, risikoliste for iterasjon tre...58 Figur 24, risikoliste for iterasjon fire...58 Figur 25, risikoliste for iterasjon fem...59 Figur 26, risikoliste for iterasjon seks...60 Figur 27, risikoliste for iterasjon sju...60 Figur 28, risikoliste for iterasjon åtte...61 Figur 29, risikoer inntrufne i prosjektperioden...62 Figur 30, domenemodell...76 Figur 31, lagdeling modell versjon Figur 32, brukstilfelle administrer kontakt...79 Figur 33, brukstilfelle beskrivelse administrer kontakt...81 Figur 34, brukstilfelle generer rapport versjon Figur 35, brukstilfelle generer rapport versjon Figur 36, brukstilfelle vis rapporter over aktiviteter...84 Figur 37, brukstilfellebeskrivelse for vis rapporter over aktiviteter...86 Figur 38, brukstilfelle vis rapport over kontakter...86 Figur 39, brukstilfellebeskrivelse for vis rapport over kontakter...88 Figur 40, brukstilfelle vis rapport over kontaktpersoner...88 Figur 41, brukstilfellebeskrivelse for vis rapport over kontaktpersoner...89 Figur 42, brukstilfelle vis rapport over konkurrenter...89 Figur 43, brukstilfellebeskrivelse for vis rapporter over konkurrenter...90 Figur 44, sekvensdiagram ny kontakt...91 Figur 45, sekvensdiagram getcontact...92 Figur 46, test av databasen Figur 47, enhetstest av aktivitet Figur 48, enhetstest aktivitet Figur 49, enhetstest av aktivitet Figur 50, enhetstest av kontaktperson Figur 51, enhetstest av kontaktperson Figur 52, enhetstesting av kontaktperson Figur 53, enhetstesting av kontaktperson Figur 54, enhetstest av kontaktperson Figur 55, enhetstesting av kontakt Figur 56, enhetstesting av kontakt Figur 57, enhetstesting av kontakt Figur 58, enhetstesting av kontakt Figur 59, enhetstest av kontakt Figur 60, enhetstesting av konkurrent Figur 61, enhetstesting av konkurrent Figur 62, enhetstest av konkurrent Figur 63, akseptansetest for hele systemet Figur 64, akseptansetest for hele systemet Gruppe 15 4 av 145

5 1.0 Prosessdokumenter Prosessdokumenter består av dokumenter som beskriver prosessen. 1.1 Presentasjon av forskningsprosjektet Bedre dialog I forbindelse med vårens hovedprosjekt 2004 gjennomføres et forskningsprosjekt, Bedre dialog i oppdragsprosjektene!", med noen utvalgte studentgrupper. Forskningsprosjektet har som mål å legge til rette for at relasjonene mellom studenter og oppdragsgiver og mellom NITH og næringslivet kan bli styrket. Studentgruppene deltar på workshoper basert på fremtidsverkstedsprinsipper. Dette er et verktøy som går ut på at studentene settes inn i et strukturert opplegg for å kunne jobbe med å finne ut av egne interesser og ønsker for det videre arbeidet med hovedprosjektet. Det gir også grunnlag for å utvide og utvikle egen faglighet og selvstendighet som profesjonelle IT-medarbeidere, som ledere og som individer. Med dette får studentene et grunnlag for å bygge et eget faglig og personlig nettverk. Gjennom arbeidet i fremtidsverkstedet blir studentene bevisst sitt eget ståsted. De blir også forberedt på hva de kan bidra med for å formidle erfaringer og teori mellom høgskolen og oppdragsgiveren. For å videreutvikle dialogen mellom partene vil det i samarbeid med studentene arrangeres ytterligere workshoper der andre ressurspersoner, inklusive oppdragsgivere, kan bli invitert til å delta. Oslo Eva Schwencke høgskolelektor, NITH 1.2 Utopidokument I forhold til PJ500 har vi gjennom en workshop og flere møter kommet fram til dette utopi dokumentet. Dokumentet presenterer områdene vi ønsker å sette fokus på, i tillegg til å beskrive hva slags type krav som er viktige for oss å få oppfylt Utopidokument per Gruppa ser for seg å gjøre et prosjekt som har som mål å utvikle en applikasjon. Dette kan gjerne være en selvstendig applikasjon, men vi har ikke dette som noe absolutt krav. Dette Gruppe 15 5 av 145

6 fordi vi ser at de fleste bedrifter har eksisterende systemer som de ønsker å bygge videre på. Applikasjonen ser vi helst at utvikles i Java, da programmererne i gruppa har sin fordypning innenfor dette feltet. Alternativet til dette er å benytte seg av VB.Net. Vi ser også for oss at det gjennom prosjektet vil bli nødvendig å tilegne seg ytterligere kunnskap innenfor applikasjonsutvikling for å kunne løse oppgaven. Det ser vi på som ønskelig og vi tror der er en fordel for oss. Vi har blitt enige om noen stikkord som preger oppgaven vår: - Utfordrende - Lærerik - Nyskapende - Nettverkbyggende Med disse stikkordene mener vi at oppgaven skal utvide vår kunnskap. I tillegg er det et krav at oppgaven har elementer som er ukjente for oss på forhånd, for at vi skal kunne tilegne oss kunnskap for å løse oppgaven. Dette vil gjøre at oppgaven føles utfordrende å løse. Nyskapende er et stikkord som vi håper å kunne bruke om oppgaven. Ved å gjøre et nyskapende prosjekt, kan det kunne øke vår sjanse for å få en jobb på bakgrunn av prosjektet. Vi ser allikevel at det er vanskelig å definere en oppgave som nyskapende på forhånd, men at det er noe vi håper på å kunne oppnå gjennom utviklingen. Til slutt har vi som mål med prosjektet at det skal kunne gi oss et nettverk, eller gi oss en begynnelse på et nettverk. Med dette mener vi at vi håper på å kunne knytte kontakter som vi kan benyttes senere. Det være seg både ITrelaterte og ikke IT-relaterte personer/bedrifter. Oppdragets utvikling håper vi kan styres med extreme programming(xp) som verktøy. Vi er klar over at dette er noe som først kan bli bestemt i samråd med bedriften, da XP krever tett oppfølging. Dersom bedriften ikke har mulighet til å ha så tett oppfølging, vil vi vurdere om XP skal tilpasses innenfor de gitte rammene, eller om vi skal bytte til Rational Unified Process (RUP) som prosesstyringsverktøy. Bedriften vi skal jobbe mot skal være imøtekommende. Med dette mener vi at bedriften skal verdsette det oppdraget vi gjør og at vi skal føle at bedriften synes det er nyttig å ha oss hos dem. En imøtekommende bedrift vil også være i en god dialog med oss når det gjelder arbeidsforhold, utstyr og oppgave. Arbeidslokaler ønsker vi å ha innen bedriftens lokaler. Vi krever ikke kontorplass til alle gruppemedlemmer, men minst til halvparten. En bedrift som tilbyr kontorplass til alle vil ha et fortrinn. I tillegg kommer et krav om utstyr. Det vi minimum ser for oss er tilgang til Internett for alle gruppemedlemmer, samt tilgang på printer. Arbeidsmiljøet i bedriften skal være bra. Vi har dessverre liten mulighet til å finne ut av dette på forhånd, men inntrykkene våre fra de bedriftene vi er på intervju hos må telle mye. Dersom vi kommer i en bedrift med et godt sosialt miljø tror vi våre sjanser for å etablere nettverk stiger. Det ideelle hadde vært å kunne lage en ressurspool av IT relaterte kontakter som vi kunne benytte ved seinere anledninger. Gruppe 15 6 av 145

7 Beliggenheten til bedriften er et sentralt punkt for oss. Da et av gruppemedlemmene har små barn, er vi avhengige av at bedriften ligger i nærheten av sentrum. Vi har satt som grense at det skal være innenfor 45 minutters reise fra sentrum. Med tanke på dagens situasjon på arbeidsmarkedet innenfor IT-bransjen, vil en bedrift som tilbyr muligheten for ansettelse etterpå stå sterkt i vår vurdering. Ovenfor bedriften ønsker vi å legge vekt på at vi ikke bare utfører et prosjekt til null kostnad for dem, men også at vi tilfører bedriften det siste av kompetanse innenfor IT siden vi kommer rett fra skolebenken. De enkelte sine rettigheter innad i gruppa nedfeller vi i en arbeidskontrakt som alle ved signering forplikter seg til å overholde. Vi vil i denne kontrakten sette rammene for jobbing i prosjektet, oppmøte og konsekvenser ved brudd på kontrakten. Vi vil ha arbeidskontrakten som et overordnet styringsdokument. Vi er på forhånd innstilt på en åpen og ærlig dialog oss i mellom. Vi ønsker å ha god takhøyde for ulike meninger og synspunkter Vurdering av utopidokument opp mot prosjektoppgave og oppdragsgiver per Under følger en vurdering av de enkelte påstandene i utopidokumentet opp mot prosjektoppgaven vi fikk, og oppdragsgiveren. Applikasjonen ser vi helst at utvikles i Java. Alternativet til dette er å benytte seg av VB.Net. Gruppen lager en selvstendig applikasjon ved bruk av VB.NET Vi ser også for oss at det gjennom prosjektet vil bli nødvendig å tilegne seg ytterligere kunnskap innenfor applikasjonsutvikling for å kunne løse oppgaven. Programmererne har måttet tilegne seg nye kunnskaper innen.net mm Med disse stikkordene (utfordrende, lærerik, nyskapende, nettverksbygging) mener vi at oppgaven skal utvide vår kunnskap. I tillegg er det et krav at oppgaven har elementer som er ukjente for oss på forhånd, for at vi skal kunne tilegne oss kunnskap for å løse oppgaven. Dette vil gjøre at oppgaven føles utfordrende å løse. Vi erfarer at vi får problemer underveis på grunn av manglende kunnskaper, vi må sette oss i nye ting daglig. Ufordrende Lærerikt prosjekt Oppgaven er mer komplisert enn forutsett Nyskapende Gruppe 15 7 av 145

8 Til slutt har vi som mål med prosjektet at det skal kunne gi oss et nettverk, eller gi oss en begynnelse på et nettverk. Med dette mener vi at vi håper på å kunne knytte kontakter som vi kan benyttes senere. Vi har ikke fått oppbygget ett så stort nettverk som ønsket, fordi Dialogplan AS kun har 3 ansatte. Med tanke på dagens situasjon på arbeidsmarkedet innenfor IT-bransjen, vil en bedrift som tilbyr muligheten for ansettelse etterpå stå sterkt i vår vurdering. Det er mulighet for ansettelse av en person etter prosjekt slutt Det ideelle hadde vært å kunne lage en ressurspool av IT relaterte kontakter som vi kunne benytte ved seinere anledninger. Dialogplan AS er en liten bedrift bestående av fire personer. Et stort nettverk er det ikke Oppdragets utvikling håper vi kan styres med extreme programming(xp) som verktøy. Har endret mening om dette, prosjektet styres av RUP, ved nærmere ettertanke ble gruppen enig om at RUP skulle brukes pga erfaring. Når kun en hadde tatt faget XP ble det mye å sette seg inn når ingen hadde kjørt et prosjekt med XP tidligere Bedriften vi skal jobbe mot skal være imøtekommende. Arbeidslokaler ønsker vi å ha innen bedriftens lokaler. Er fornøyd med oppdragsgiver, har god kontakt med veiledere og daglig leder, har daglig kontakt og samtaler Beliggenheten til bedriften er et sentralt punkt for oss. Da et av gruppemedlemmene har små barn, er vi avhengige av at bedriften ligger i nærheten av sentrum. Vi har satt som grense at det skal være innenfor 45 minutters reise fra sentrum Arbeidslokalen ligger sentralt, har maskiner og det som er nødvendig for prosjektet De enkelte sine rettigheter innad i gruppa nedfeller vi i en arbeidskontrakt som alle ved signering forplikter seg til å overholde. Vi vil i denne kontrakten sette rammene for jobbing i prosjektet, oppmøte og konsekvenser ved brudd på kontrakten. Vi vil ha arbeidskontrakten som et overordnet styringsdokument. Vi er på forhånd innstilt på en åpen og ærlig dialog oss i mellom. Vi ønsker å ha god takhøyde for ulike meninger og synspunkter. Vi skrev en arbeidskontrakt før prosjekt start. Denne ble revidert i iterasjon tre. 1.3 Arbeidskontrakter En arbeidskontrakt ble utarbeidet før prosjektstart. Dette for å ha noen retningslinjer for å håndtere eventuelle problemsituasjoner under prosjektperioden. I iterasjon tre erfarte Gruppe 15 8 av 145

9 gruppen at det var et behov for å revidere arbeidskontrakt da vi ikke fulgte denne til punkt å prikke Opprinnelig arbeidskontrakt ( ) Mål Gruppens hovedmål er avlevering av kode til Dialogplan AS innen 1. mai 2004, samt innlevering av kode og rapport til Dialogplan AS og Norges Informasjonsteknologiske Høgskole innen 7. mai Rapporten skal innleveres etter retningslinjer gitt av Norges Informasjonsteknologiske Høgskole. Det er gruppens mål å minimum oppnå karakter B. Microsoft Project skal brukes som verktøy hvor det skal lages en prosjektplan som jevnlig skal oppdateres av prosjekt leder. Roller Ved oppstart av Diplomoppgave i faget PJ501 gjennomgås medlemmenes ulike roller. Det forventes at avtalte kriterier for hver rolle blir oppfylt av medlemmene. Prosedyrer Alle prosjektdeltakere skal møte hver tirsdag, onsdag og torsdag. Arbeidsdagen vill vare fra klokka til Kontorlokaler til Dialogplan AS benyttes som møtested. Mette Andersen har innvilget fleksitid morning og ettermiddag på grunn av levering og henting av barn. Alle er selv ansvarlig for å følge faglig relatert stoff og tilegne seg nødvendig kunnskap for å kunne løse oppgaven. Tildelte arbeidsoppgaver skal være utført innen de avtalte tidsrammer. Kan ikke milepæler overholdes må dette bli gitt beskjed om til prosjektleder. Beslutninger tas i plenum, men ved uoverensstemmelser vil flertallet avgjøre. Blir det ikke et flertall, vil prosjektleder ta en endelig avgjørelse. Ved konflikter vil en muntlig advarsel gis, deretter en skriftelig. Ved en advarsel vil vedkommende få en uke til å vise en bedring i arbeid og oppførsel. For en eventuelt endelig utestengelse fra gruppen, må skolen godkjenne dette. Møtene ledes av prosjektleder som har en oversikt over hva som er gjort og hva som skal gjøres. Alle arbeider utifra dette. Ved fravær forventes det at det blir gitt beskjed om dette før møtet. Totalt fem dager i semesteret er akseptert av fravær. Vi forventer likevel at gruppemedlemmet gjør sine oppgaver. Forsinkelser på mer enn 10 minutter må meldes til prosjektleder via telefon. Ved hvert møte skal det gis tilbakemelding på medlemmenes ulike arbeidsoppgaver. Alle gruppemedlemmer er forpliktet til å behandle alle innvolverte parter i Diplomprosjektet PJ501 med respekt, tålmodiget og forståelse. Hvis det er et ønske fra minimum et gruppemedlem om at arbeidskontrakten skal revideres, skal alle sette seg ned og gjennomgå kontrakten på nytt. Interpersonlige spørsmål Prosjektrelaterte, individuelle og personlige problemer er saker som kan tas opp på møter. Prosjektrelaterte tilbakemeldinger skal gis ved hvert møte. De skal være kritiske, konstruktive og bli gitt så nær hendelsespunktet som mulig. Gruppe 15 9 av 145

10 1.3.2 Revidert arbeidskontrakt ( ) Mål Gruppens hovedmål er avlevering av kode til Dialogplan AS innen 1. mai 2004, samt innlevering av kode og rapport til Dialogplan AS og Norges Informasjonsteknologiske Høgskole innen 7. mai Rapporten skal innleveres etter retningslinjer gitt av Norges Informasjonsteknologiske Høgskole. Det er gruppens mål å minimum oppnå karakter B. Microsoft Project skal brukes som verktøy hvor det skal lages en prosjektplan som jevnlig skal oppdateres av prosjekt leder. Roller Ved oppstart av Diplomoppgave i faget PJ501 gjennomgås medlemmenes ulike roller. Det forventes at avtalte kriterier for hver rolle blir oppfylt av medlemmene. Prosedyrer Alle prosjektdeltakere skal møte hver tirsdag, onsdag og torsdag. Arbeidsdagen vil i utgangspunktet vare fra klokka til Ved behov er det mulig å benytte seg av en fleksitid fra Mette Andersen har innvilget fleksitid morning og ettermiddag på grunn av levering og henting av barn. Kontorlokaler til Dialogplan AS benyttes som møtested. Alle er selv ansvarlig for å følge faglig relatert stoff og tilegne seg nødvendig kunnskap for å kunne løse oppgaver. Tildelte arbeidsoppgaver skal være utført innen de avtalte tidsrammer. Kan ikke milepæler overholdes må dette bli gitt beskjed om til prosjektleder. Beslutninger tas i plenum, men ved uoverensstemmelser vil flertallet avgjøre. Blir det ikke et flertall, vil prosjektleder ta en endelig avgjørelse. Ved konflikter vil en muntlig advarsel gis, deretter en skriftelig. Ved en advarsel vil vedkommende få en uke til å vise en bedring i arbeid og oppførsel. Før en eventuelt endelig utestengelske fra gruppen, må skolen godkjenne dette. Møtene ledes på rullerende omgang av alle prosjektdeltakere som skal ha en oversikt over hva som er gjort og hva som skal gjøres. Ved fravær forventes det at det blir gitt beskjed om dette før møtet. Ved hvert møte skal det gis tilbakemelding på medlemmenes ulike arbeidsoppgaver. Ved sykdom vil resterende gruppedeltakere ta over den sykes arbeidsoppgaver og fordele disse seg imellom slik at de blir gjort. Forsinkelser på mer enn 10 minutter må meldes til prosjektleder via telefon. Alle gruppemedlemmer er forpliktet til å behandle alle involverte parter i Diplomprosjektet PJ501 med respekt, tålmodighet og forståelse. Hvis det er et ønske fra minimum et gruppemedlem om at arbeidskontrakten skal revideres, skal alle sette seg ned og gjennomgå kontrakten på nytt. Interpersonlige spørsmål Prosjektrelaterte, individuelle og personlige problemer er saker som kan tas opp på møter. Prosjektrelaterte tilbakemeldinger skal gis ved hvert møte. De skal være kritiske, konstruktive og bli gitt så nær hendelsespunktet som mulig. Gruppe av 145

11 1.4 Prosjektorganisering I forkant av prosjektet valgte gruppen å melde seg på et privat forskningsprosjekt i regi av Eva Schwenke (viser til vedlegg s. 5). Forskningsprosjektet har som formål å styrke studentenes bevissthet rundt seg selv, oppgaven og oppdragsgiveren på et tidlig tidspunkt, og måle effektene av dette. I tillegg er retningslinjene fra skolen fulgt (viser til retningslinjer for intellektuell redelighet s. 64). Oppstart hos Dialogplan AS var 13.januar Prosjektroller ble fordelt i henhold til RUP. (viser til s. 11). Overordnede planer for fremgang og gjennomføring ble umiddelbart utarbeidet. I henhold til planene skal hver arbeidsdag utgjøre åtte timer inkludert 30 minutters spisepause (viser til arbeidskontrakt s. 8 og prosjektplaner fra s.13). Ved behov vil alle prosjektdeltagere jobbe overtid. Totalt vil dette gi et samlet timeforbruk på 1875 timer gjennom hele prosjektet. Med en timepris på 200 kroner vil dette utgjøre en total sum på kroner. Det tas her forbehold om endringer av arbeidstiden, som nevnt over. Frist for innlevering av kildekode til oppdragsgiver er satt til 1.mai 2004 og frist for innlevering av rapport er satt til 7. mai Adresseliste med roller og ansvarsområder Rollene er fordelt etter evner og ønsker: Prosjektleder, systemutvikler: Mette Andersen Adresse: mette-a@runbox.no Telefon : Programmerer: Irjan Javo Adresse: javirj@nith.no Telefon : Programmerer: Tor-Morten Grønli Adresse: grntor@nith.no Telefon : Programmerer: Jørgen Fundingsrud Adresse: jorgen@fundingsrud.net Telefon : Systemutvikler, tester: Kenneth Lilleaas Adresse: lilken@nith.no Telefon : Gruppe av 145

12 Ansvarsområder: Mette Andersen Innledning Teori Metode Analyse og utforming Vurdering av prosjekt Begrepsliste Referanser Statusrapporter Risikolister Irjan Javo Tor-Morten Grønli Programmering av kontakt Etablering av utviklingsmiljø Programmering av konkurrent, rapporter og kontakt Vedlikehold og videreutvikling av databasen Kort beskrivelse av løsning Vurdering av løsning Jørgen Fundingsrud Programmering av aktivitet Opprettelse av databasen Kenneth Lilleaas Testing Brukermanual Vurdering av nytte for oppdragsgiver Prosjektplaner Timelister Skapt verdi Gruppe av 145

13 1.6 Prosjektplaner Overordnet prosjektplan Figur 1, faseplan Gruppe av 145

14 1.6.2 Iterasjon 1 Figur 2, prosjektplan for iterasjon 1 Gruppe av 145

15 1.6.3 Iterasjon 2 Figur 3, prosjektplan for iterasjon 2 Gruppe av 145

16 1.6.4 Iterasjon 3 Figur 4, prosjektplan for iterasjon 3 Gruppe av 145

17 1.6.5 Iterasjon 4 Figur 5, prosjektplan for iterasjon 4 Gruppe av 145

18 1.6.6 Iterasjon 5 Figur 6, prosjektplan for iterasjon 5 Gruppe av 145

19 1.6.7 Iterasjon 6 Figur 7, prosjektplan for iterasjon 6 Gruppe av 145

20 1.6.8 Iterasjon 7 del 1 Figur 8, prosjektplan for iterasjon 7, nummer 1 Gruppe av 145

21 Iterasjon 7 del 2 Figur 9, prosjektplan for iterasjon 7, nummer 2 Gruppe av 145

22 1.6.9 Iterasjon 8 Figur 10, prosjektplan for iterasjon 8 Gruppe av 145

23 1.7 Statusrapporter Prosjektet besto av til sammen åtte iterasjoner hvor det til hver iterasjon ble skrevet en statusrapport som beskrev målsetting, status og kommunikasjon for iterasjonen Statusrapport iterasjon 1 Start:13. januar 2004 Slutt: 22. januar 2004 Antall arbeidsdager: 6 Målsetting Målsetting for iterasjon en gikk ut på å bli ferdig med idefasen. Dette omhandlet blant annet å lage en overordnet prosjektplan for hele prosjektet, lage et forretnings brukstilfelle, lage brukstilfeller, sette opp utviklingsmiljø, skrive innledning, skrive en kravspesifikasjon og foreta undersøkelser om Customer Relationship Management (CRM) systemer i forbindelse med prosjektoppgaven. (For den komplette listen henvises det til prosjektplan s. 14). Status Vi kom fort godt i gang med idefasen og dens gjøremål. Oppgaver nevnt under målsetting ble alle jobbet med. Innledning, brukstilfeller, metoder og kravspesifikasjon vil bli iterert i neste iterasjon. Vi hadde en del endringer i forhold til planen om hva som skulle gjøres når. Vi har ikke sett på dette som veldig negativt da vi har valgt å følge prinsippet omfavn endringer fra Extreme programming. Vi vil likevel prøve å jobbe mer strukturert i neste iterasjon. Vi har i idefasen startet på arbeidsoppgaver som i utgangspunktet skal gjøres i iterasjon to. Dette da vi så at det var helt nødvendig å sette seg inn kunnskap om markedsføring og CRM systemer for å kunne starte med oppgaver planlagt i iterasjon en. Risiko - og prosjektplan er laget for iterasjon to, (for nærmere dokumentasjon om risikoplan og logg se s.56, prosjektplan se s. 13) Ved oppstart av prosjektet ble gruppen enig om å starte med åtte - timers arbeidsdager, vi vil ved hver iterasjon evaluere eventuelle endringer. Iterasjon en gikk bra med åtte - timers arbeidsdager slik at iterasjon to også vil planlegges med samme antall arbeidstimer. Vi har en enighet om at alle er pålagt ved behov å bruke en time til forberedelse til hver arbeidsdag. Kommunikasjon Arbeidsmiljø og kommunikasjonen innad i gruppen fungerer meget bra. Vi har god erfaring med prosjektarbeid fra tidligere år. Fire av gruppens medlemmer arbeidet et år i samme prosjekt og har god erfaring å bygge videre på. Vi prøver å ha en spesielt hyggelig Gruppe av 145

24 lunsj hver torsdag. Vi har hatt kjeks en dag og stekt vafler en annen dag. Vafler steker vi nok ikke igjen da dette tok for lang tid Statusrapport iterasjon 2 Start: 27. januar Slutt: 5. februar 2004 Antall arbeidsdager: 6 Målsetting Målsetting for iterasjon to omhandlet flere viktige oppgaver. Noen av de itererte fra forrige iterasjon. Dette gjaldt innleding, brukstilfeller, metoder og kravspesifikasjon. Nye modeller som skulle lages til arkitekturdokumentet var design diagram, komponent diagram og sekvens diagram. Andre mål var å lage databasen samt programmere kunde klassens og dens funksjoner. (For den komplette listen henvises det til prosjektplan s.15). Status Vi jobbet bra i iterasjon to, men ble noe hemmet på grunn av sykdom. Vi itererte som nevnt noen oppgaver fra iterasjon en. Vi er etter denne iterasjonen ferdig med brukstilfeller, metoder og kravspesifikasjon. Når det gjelder innledning føler vi ikke at vi på dette tidspunkt sitter inne med nok kunnskap til å fryse denne. Vi må bruke mer tid på forskning av problemstilling før vi vil si oss ferdig med den. Innledningen vil bli revidert på et senere tidspunkt. Det ble laget nye modeller til arkitekturdokumentet. Disse vil iterere i flere iterasjoner. Databasen ble laget og levert veileder hos oppdragsgiver. Vi fikk noen kommentarer men er fornøyd med denne. Programmeringen av kunde er ikke ferdig, den er planlagt ferdig om en uke i iterasjon tre. Vi hadde to syke programmerere denne iterasjonen, dette er årsaken til at kunde ikke er ferdig programmert. Risikolisten er oppdatert, sannsynligheten for sykdom over to dager er økt (for nærmere dokumentasjon se risikoplan og logg s.57). Prosjektplan og statusrapport er skrevet (for nærmere dokumentasjon se prosjektplan s. 15 og statusrapport s.24). I iterasjon tre vil vi fortsette med åtte-timers uker. Vi har en enighet om at alle er pålagt ved behov å bruke en time til forberedelse til hver arbeidsdag. Kommunikasjon Kommunikasjonen er i gruppen er god. Vi jobber tett sammen og snakker om de ulike arbeidsoppgavene flere ganger daglig og gir hverandre konstruktiv kritikk. Prosjektleder har tatt med karameller og kjærligheter som litt ekstra snacks innimellom øktene. Vi avsluttet iterasjon to med kanelboller til lunsj. Gruppe av 145

25 1.7.3 Statusrapport iterasjon 3 Start: 10. februar Slutt: 19. februar Antall arbeidsdager: 6 Målsetting Målsetting for iterasjon tre inkluderte koding av funksjonene til kunde/kontakt på serversiden samt koding av brukergrensesnitt for kontakt på klientsiden. Modeller skulle itereres. Et eget dokument for brukergrensesnittet skulle lages med argumenter for de valg som er tatt samt skisser over hvordan brukergrensesnittet skal se ut. Som i de andre iterasjonene skulle det også lages en statusrapport, risikolisten skulle oppdateres, samt en ny prosjekt plan skulle utarbeides for neste iterasjon. (For den komplette listen henvises det til prosjektplan s. 16). Status I starten av iterasjon tre ble det holdt et møte om databasen med oppdragsgiver. Det ble foretatt noen endringer som medførte noe ekstra koding. Klassen kunde har endret navn til kontakt. Koding av kontakt er ca 80 % ferdig og vil bli ferdig første uke i iterasjon fire. Klassen aktivitet og person er påbegynt og er ca 25 % ferdig. Under utarbeidelse av designmodellen startet vi med en objektorientert tankegang. Vi modellerte og startet med noe koding på bakgrunn av dette prinsippet. Vi valgte derimot i denne iterasjonen å endre på dette ved å fjerne domenelaget og gå over til et enklere design. Dette fordi vi så at designet hadde blitt unødvendig komplisert. En komplisert designmodell er vanskeligere å beskrive på en forståelig måte ovenfor oppdragsgiver enn en enkel en. I tillegg er en enkel modell naturligvis enklere å implementere i kode. Viser til designmodellen i kapittel analyse og utforming. Brukergrensesnittet er skissert, dette gjelder skjermbilder, lagdeling og interaksjoner mellom skjermbilder. Koding av kontakt på klientsiden er påbegynt men på grunn av noe dårlige kunnskaper av bruk av Visual Basic vil denne oppgaven bli forskjøvet til neste iterasjon. Det er ikke skrevet et dokument om valg i forbindelse med brukergrensesnitt, dette vil bli forskjøvet til iterasjon fire. Alle modeller som skal lages er påbegynt og kommentert. Noen av de vil fortsatt måtte itereres. Innledning og problemstilling er endret og vil stå stille inntil videre. Det er blitt forsket og skrevet mer på teori delen som også vil stå stille inntil videre. Risikoplanen er oppdatert, her ble det en økning på sannsynligheten for sykdom i to dager da vi har hatt dette problemet også i denne iterasjonen (for nærmere dokumentasjon se risikoplan og logg s. 58). Prosjektplan for iterasjon fire er laget og detaljert mer enn tidligere, dette for å lettere estimere hvordan vi ligger an (for nærmere dokumentasjon se prosjektplan s.16). Vi ser at vi har estimert noe for lang tid på flere oppgaver og det ser derfor ikke ut som vi har tatt skade av sykdom. Etter iterasjon tre konkluderer vi med at vi ligger godt an tidsmessig med de ulike arbeidsoppgaver. I iterasjon fire vil vi fortsette med åtte-timers uker. Vi hadde tidligere en avtale om at alle var pålagt ved behov å bruke en time til forberedelse til hver arbeidsdag. Dette ble tidligere ikke ført. Vi skal nå føre alle eventuelle ekstra timer i timelista. Gruppe av 145

26 Kommunikasjon Ved slutt av iterasjon tre hadde gruppen et møte. Vi reviderte deler av arbeidskontrakten samt tok opp saker vi følte ikke fungerte tilfredstillende. En av sakene gjaldt det å være kritisk til hverandres arbeid. Vi ble enige om å prøve å gi hverandre mer kritiske og raskere tilbakemeldinger. På grunn av en del bruk av Internett ble vi enige om å minske ned på dette. Vi tok også opp en sak om det å være ansvarlig for faglig relatert stoff. Vi diskuterte om faglig relatert stoff til en arbeidsoppgave skal leses i arbeidstiden eller om det skal forventes at vedkommende må lese faglig stoff på egenhånd. Vi ble enige om at det kan brukes noe tid i arbeidstiden, samt noe tid på fritiden. På møter med oppdragsgiver rullerer vi på å være møteleder og referent. I arbeidskontrakten står det at prosjektleder skal lede møtene, men vi ble enige om å revidere dette punktet i kontrakten. Det står også i arbeidskontrakten at det aksepteres fem dager fravær. Dette punktet ble slettet. Av erfaring i tre iterasjoner med en del sykdom ble vi enige om at vi ikke ville ha et spesifikt antall dager spesifisert. Ved sykdom ble vi enige om at arbeidsoppgaver til den syke skal gjøres av resterende deltakere slik at oppgavene blir gjort så fort som mulig. Den siste saken vi tok opp gjaldt arbeidstiden. I arbeidskontrakten står det at arbeidstiden er fra men på grunn av en del forsinkelser ble vi enige om å innføre fleksibelt oppmøte tidspunkt fra Det vil være opp til hver enkelt om de ønsker å ta igjen forsømt tid hjemme eller på jobb. Viser til revidert arbeidskontrakt og referat fra møtet. Gruppen føler ellers generelt at stemningen er god og at samarbeidet fungerer bra Statusrapport iterasjon 4 Start: 24. februar Slutt: 4. mars Antall dager: 6 Målsetting Målsetningene for iterasjon fire ble laget meget detaljerte i prosjektplanen. Dette for å kunne gjøre en bedre tidsestimering. Implementasjonsperspektivet, utplasseringsperspektivet, iterering av arkitektur, skriving av rapport, vurdering av alternative løsninger, og løsning var mål for systemererne. Koding av funksjonaliteten for person, aktivitet og konkurrent som gjaldt innsetting, sletting og endring på serversiden var mål for to av programmererne. Koding av funksjonalitet for kontakt på klientsiden var mål for programmerer nummer tre. Det skulle skrives et brukergrensesnitt dokument med argumenter for de valg som skal tas, et risikodokument skulle oppdateres og det skulle fortsettes med testing. (For den komplette listen henvises det til prosjektplan s.17). Status Ved å estimere detaljerte arbeidsoppgaver har det vært lett å se positive og negative resultater av estimeringen. Det er derimot et problem å estimere hvor lang tid programmeringen av brukergrensesnittet vil ta. Vi har derfor i iterasjon fem ikke detaljert programmeringen like mye som i iterasjon fire (for nærmere dokumentasjon om prosjektplan for iterasjon fem se s.18). Gruppe av 145

27 Kapittelet analyse og utforming er nesten ferdig. Alle perspektivene er modellert, kommentert og iterert. Disse vil iterere også i neste iterasjon. Vurdering av alternative løsninger er påbegynt og vil bli skrevet ferdig i iterasjon fem. Kapittelet løsning vil derimot bli forskjøvet til iterasjon sju. Dette da denne oppgaven vil bli gjort av en programmerer som på det tidspunkt har mer tid. Koding av funksjonalitet for person, aktivitet og konkurrent er forholdsvis ferdig på serversiden. Skjermbilder er tegnet slik at det letter arbeidet med koding av brukergrensesnittet. På klientsiden arbeides det med å kode kontakt. Denne er ikke ferdig og vil bli forskjøvet til neste iterasjon, og vil mest sannsynligvis bli ferdig første uke i iterasjon fem. Det har vært mye nytt å sette seg inn i, ingen hadde tidligere erfaring med ASP noe som har medført ekstra tid. Det er skrevet et brukergrensesnittdokument med argumenter for de valg vi tar. Annen testing er ikke foretatt i denne iterasjon. Det var estimert for mye tid på testing. Vi hadde sykdom en dag, men på grunn av feil estimering ble ikke dette et problem da det skulle vært testet denne dagen. I uke to av iterasjonen hadde gruppen et møte med Cat Holten, vår veileder fra NITH. Hun kom med gode konstruktive tilbakemeldinger på arbeidet som var gjort. Gruppen har som tidligere et møte med oppdragsgiver hver torsdag hvor status gjennomgås. Risikodokument er oppdatert med små endringer (viser til risikodokument s. 59), statusrapport er skrevet og prosjektplan er oppdatert for iterasjon fem (viser til prosjektplan s. 18). Kommunikasjon Kommunikasjonen med oppdragsgiver er fortsatt god. Veiledere og programmerere har daglig kontakt hvor erfaringer utveksles om ulike programmeringsoppgaver. Etter møtet forrige iterasjon har kommunikasjonen og tonen i gruppen vært god. Vi er flinkere til å gi hverandre kritiske og raskere tilbakemeldinger. Vi følger de nye punktene i arbeidskontrakten. Vi har en ny avtale på at vi skal rullere med å ta med noe ekstra godt å spise til alle hver torsdag Statusrapport iterasjon 5 Start: 9. mars Slutt: 18. mars Antall dager: 6 Målsetting Målsetting for iterasjon fem inkluderte å bli ferdig med koding av kontakt på serversiden samt fortsettelse av koding av brukergrensesnittet. Vi hadde ikke detaljert hvor mye av brukergrensesnittet som skulle programmeres da det var veldig vanskelig å forutsi. Når det gjelder selve rapporten skulle teori, innledning, organisatorisk løsning og vurdering av nytte for oppdragsgiver skrives ferdig. Foregående punkter skulle gjøres ferdig, men det vil likevel gjenstå for resterende gruppe deltagere å lese nøye gjennom dokumentene å godkjenne de. Testing er annet viktig punkt som skulle gjøres. Det skulle foretas enhetstesting og akseptansetesting. Arkitekturen skulle også itereres for eventuelle endringer. For den komplette listen henvises til prosjektplanen. (For den komplette listen henvises det til prosjektplan s. 18). Gruppe av 145

28 Status Iterasjon fem har ikke hatt noen sykedager og alle gruppedeltakere har arbeidet godt og effektivt. Kontakt er ferdig programmert og rapporter er påbegynt på serversiden. Brukergrensesnittet var som nevnt noe vanskelig å estimere og er blitt oppdatert i prosjektplanen ved slutt av iterasjon fem. Aktivitet og personcontact er programmert ca 80% ferdig. Uke to oppsto det problemer ved en overgang fra å bruke dataset til dataviw, noe som måtte gjøres på grunn av en sortering. Problemene oppsto på bakgrunn av for lite kompetanse på området. Dette medførte liten fremgang på klientsiden i løpet av to dager. Etter en akseptanse test med oppdragsgiver ble også 50-60% av koden til aktivitet endret. Når det gjelder rapporten ble alle ovenstående mål i målsetting ferdig. Testing er essensielt i forbindelse med programmeringen. Det ble foretatt en enhetstest og en akseptanse test. Av arkitektur ble sekvens diagram og design modell oppdatert (viser til kapittel 4.0 s. ). Det ble også laget to nye sekvensdiagram fra UML 2.0. Disse vil modelleres ferdig i iterasjon seks. Disse har tatt en del tid da UML 2.0 er nytt fagstoff. Risiko og prosjektplan er laget for iterasjon seks (viser til risikoplan s. 60 og prosjektplan s. 19) Kommunikasjon Kommunikasjonen med oppdragsgiver er fortsatt god. Veiledere og programmerere har daglig kontakt hvor erfaringer utveksles om ulike programmeringsoppgaver. Kommunikasjonen innad i gruppen er god. Gruppen har avtalt middag hos prosjektleder i iterasjon seks Statusrapport iterasjon 6 Start: 23. mars Slutt: 6. april Antall dager: 8 Målsetting Målsettinger for iterasjon seks inkluderte å fortsette med programmeringen av aktivitet og kontakt, samt koding av rapporter. Databasen skulle oppdateres og koden skulle også testes. Spesielt viktig var en akseptanse teste med kunde. Et nytt kapittel til rapporten skulle påbegynnes Vurdering av metode, verktøy og prosjektgjennomføring. (For den komplette listen henvises til prosjektplanen s. 19). Status I iterasjon seks har vi igjen vært preget av å ha mye sykdom. Vi har hatt to personer som har vært syke til sammen fire dager, dette har medført store forsinkelser på enkelte oppgaver. Fraværet har hovedsakelige forsinket rapportskrivingen. Vi ble enige om at programmererne ikke skulle ta over de sykes oppgaver da de hadde nok å gjøre med programmeringen. Vi avtalte at de som hadde mulighet skulle jobbe to dager i påskeferien. 3 gruppedeltakere jobbet to dager i påsken. Mye av denne tiden ble brukt til å gjøre klar rapporten for innlevering av første utkast. Første utkastet ble utsendt onsdag 7. april. Gruppe av 145

29 Vi har erfart at prosjektoppgaven er mer komplisert enn antatt. Dette har ført til at programmeringen har vært vanskelig å estimere, da det har vært mye nytt for programmererne å sette seg inn. Kodingen har vært estimert på et overordnet plan og ikke veldig detaljert. Programmeringen av rapporter er kodet ferdig ca 50%, aktivitet ca 80% og kontakt ca 90%. Resterende koding vil bli foretatt i iterasjon sju. Gruppen har kontinuerlig testet koden. Dette er gjort med enhetstesting, integrasjons testing og akseptansetesting. Feil blir rettet opp etter hvert som de blir oppdaget. Noen små feilhåndteringer ble endret etter akseptansetestingen. På grunn av fraværet har deler av rapportskrivingen blitt noe forskjøvet. Men, alle kapittel til rapporten er nå generelt påbegynt. Alle kapittel vil itereres i iterasjon sju og åtte. Risiko- og prosjektplan er laget for iterasjon sju (viser til risikoplan s. 60 og prosjektplan s. 19). Gruppen har kommet frem til at iterasjon sju og åtte må bli noe lenger enn de foregående. Iterasjon sju vil bestå av åtte dager og iterasjon åtte vil bestå av ti dager. Dette på grunnlag av at gruppen ønsker å kunne levere et godt sluttprodukt. Kommunikasjon Kommunikasjonen med oppdragsgiver er fortsatt god. Veiledere og programmerere har daglig kontakt hvor erfaringer utveksles om ulike programmeringsoppgaver. Alle gruppedeltakere er enige om at det må jobbes ekstra dager frem mot leveringsdato 7.mai Statusrapport iterasjon 7 Start: 13. april Slutt: 22. april Antall dager: 8 Målsetting Målsettinger for iterasjon sju gjaldt i store trekk for programmererne å bli ferdig med all kode. Det var ønskelig å være ferdig med programmeringen fredag 22. april, men hvis krise ville det være mulig å utsette fristen til tirsdag 27. april. Det skulle foretas en akseptansetest samt integrasjonstesting. Brukermanualer skulle også påbegynnes. Når det gjelder rapporten skulle flere kapittel itereres for siste gang. Vurdering av løsning opp imot teori skulle også gjøres. (For den komplette listen henvises til prosjektplanen s. 19). Status Iterasjon sju har vært preget av at en programmerer har vært syk hele perioden. Dette har ført til at gruppen har følt seg ekstra stresset for å bli ferdig i tide med prosjektoppgaven. Programmeringen er ikke ferdig ved iterasjonsslutt men skal avsluttes tirsdag 27. april. For å oppnå dette må programmererne jobbe ekstra timer og dager. Det har blitt foretatt integrasjonstesting, men ikke akseptansetest med oppdragsgiver, denne er blitt utsatt til første uke i iterasjon åtte. Kode vil bli overlevert til oppdragsgiver torsdag 30. april. Brukermanualen har oppdragsgiver kommet med innspill på hvordan de ønsker skal se ut, denne er påbegynt. Når det gjelder rapporten er flere kapitler ferdigstilt. Dette gjelder kapitlene; innledning, metode og teori. Kapittel 6.0, vurdering av løsning og prosjekt, er ikke ferdig. Dette på grunn av feil estimering av tid til retting av kommentarer fra veileder Gruppe av 145

30 og gruppemedlemmer. Det ble avholdt et møte med intern veileder fra skolen som kom med nyttige kommentarer til første utkastet. Det er ikke holdt formelle møter med oppdragsgiver denne iterasjonen da vi ikke har hatt et stort behov for dette. Vi har hatt en meget god tone med oppdragsgiver med daglige samtaler. Risikoplanen for iterasjon åtte har fått to nye iterasjoner. Disse er PC og nettverkssystem svikter og Dårlig oversikt over prosjektets fremgang (for nærmere dokumentasjon om risikoplanen se s. 61). Prosjektplan er også skrevet for iterasjon åtte (se prosjektplan s. 22). Kommunikasjon Kommunikasjonen med oppdragsgiver er fortsatt god. Veiledere og programmerere har daglig kontakt hvor erfaringer utveksles om ulike programmeringsoppgaver. Kommunikasjonen innad med programmererne har vært noe vanskelig til tider på grunn av sykdom hos en programmerer. Alle gruppedeltakere er enige om at det må jobbes ekstra dager og timer frem mot leveringsdato 7.mai Statusrapport iterasjon 8 Start: 26. april Slutt: 7. mai Antall dager: 10 Målsetting Målsetting for iterasjon åtte var å bli ferdig med programmering, rapport og brukermanual. Programmering skulle leveres innen 1. mai til oppdragsgiver og resterende skulle leveres til oppdragsgiver og skole innen 7. mai Prosjektplanen ble ikke detaljert av den grunn at det var vanskelig å si hva som skulle gjøres hver dag. Rapporten skulle kommenteres og korrekturleses av gruppedeltagere og veileder.det kommer frem i rapporten at det skal jobbes 5 dager hver uke med 7,5 timer hver dag. Dette er misvisende da vi alle var enige om å jobbe overtid begge ukene for å ha mulighet til å oppnå ønsket ambisjonsnivå. (For den komplett listen henvises til prosjektplanen s. 14). Status I løpet av en integrasjonstest test fredag 30. april ble det oppdaget et par feil rett før innlevering (viser til test s. 121), oppdragsgiver kom da med et forslag om å levere koden mandag 3. mai istedetfor 1. mai som avtalt. Koden ble fikset i løpet av helgen og ble overlevert mandag 3. mai. Oppdragsgiver var fornøyd ut i fra gitte krav og tidsrammer. Forskyvning av overlevering medførte ikke praktiske endringer i prosjektplanen. I løpet av iterasjonen ble ikke planen detaljert. Gruppemedlemmer og veileder kom med kommentarer som medførte endringer i hele rapporten. Prosjektleder skrev detaljerte lister for hvert gruppemedlem over hvilke oppgaver som skulle gjøres til enhver dag. Dette med forutsetninger om at hvert gruppemedlem jobbet dager og kvelder. Som det kommer frem av timelistene har siste iterasjon flere timer enn tidligere planlagt. Dette for å oppnå ønsket ambisjonsnivå. Gruppe av 145

31 Kommunikasjon Kommunikasjonen innad i gruppen har vært kjempefin hele iterasjonene. Alle har jobbet meget bra for å nå skolen og oppdragsgiverens mål. Gruppen har også et eget ambisjonsnivå med et stort ønske om å kunne oppnå karakter A. Gruppe av 145

32 1.8 Timelister Timeliste for Mette Andersen Uke januar Møte, metoder og research 7,5 14. januar Møte, research, 7,5 referanedokument og kravspek. 15. januar Prosjektplan, metoder, ikke 7,5 funksjonelle krav, domenemodell Uke 4 Innledning januar Teori (hjemme, kvelden) 21. januar Innledning, kravspek., teori 6,5 22. januar Ferdigstille iterasjon 1 6 Prosjektplan, innledning, rapporten generelt for iterasjon 1 Uke 5 Møte m/cat, prosjektplan januar 28. januar Innledning, metoder, ikke 8,5 funksjonell beskrivelse 29. januar Tegning av modeller i Rose, 7,5 møte med Dialogplan AS Uke 6 Innledning, research, 7,5 3. februar sekvensdigrammer i rose 4. februar Arkitektur 7,5 5. februar 7,5 Uke 7 Teori Sykt barn, men jobbet inn 10. februar timene 11. februar Teori 11,5 12. februar Innledning, research 10,5 Uke 8 Oppdaterte sekvensdiagram, 7,5 17. februar leste ny UML bok 18. februar Arkitektur, leste Uml and 7,5 patterns 19. februar Oppdaterte design diagram, 7,5 komponentdiagram, lagde lagdelingsdiagram, risikodokument Uke 9 Gruppemøte, reviderte februar kontrakt 24. februar Oppdatert use case, laget 6,5, jobb utplasseringsdiagram, finpuss 2, hjemme på kommentarer til arkitektur, revidert kontrakt 25. februar Kommentert desingmodell og 6, jobb Gruppe av 145