Prosjektplan v1.3 (final)

Like dokumenter
Prosjektplan v1.7 (Revidert utgave 2)

SLUTTRAPPORT. gruppe 42 Nils-Kristian Liborg, Bente Brevig, Tom Olav Bruaas, Eirik Lied og Hege Lid Pedersen. 25. november 2002

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004

Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store. Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson

Kravspesifikasjon. 14. oktober 2002

Leveranse 2. September 27, 2002

Godkjenning av møteinnkalling

DRIFTSANALYSER 2012/2013 FORELØBIGE RESULTATER

INF Obligatorisk prosjektarbeid

Målet med dette notatet er å dokumentere at det er funnet løsmasser ved grunnen og å dokumentere miljøgiftkonsentrasjonen i sedimentene.

Offentlig utvalg for punktskrift, OUP Norsk standard for 8-punktskrift punktskrift 24. oktober 2004 sist endret

INF Obligatorisk prosjektarbeid INNHOLD:

Handi-Lift EA7 Målskjema

Kravspesifisering (2): Validering av kravspek er

INF Obligatorisk prosjektarbeid INNHOLD:

Godkjenning av møteinnkalling

Tegn og tekst. Et representert tegn kan vises på flere måter. Noen definisjoner. Enda noen definisjoner. \yvind og ]se N{rb}? a a a.

Testobservator for kjikvadrattester

Handi-Lift EA7 Målskjema

Alle har en kreativ muskel

Målskjema. Serie nr.: Bruker Navn: Adresse: Kontaktpersoner. E-post: E-post: Levering Adresse:

STRATEGOS B. Målskjema. Serie nr.: Bruker Navn: Adresse: Kontaktpersoner. E-post: E-post: Levering Avd. Bruker Annet: Adresse:

Oppsummering : IMT2243 Systemutvikling. Hensikt med kurset. Innfallsvinkel : Tom Røise IMT2243 : Systemutvikling 1

Perceived semantic. quality. Semantic quality. Syntactic. quality. guttens alder er grønn: gutt.alder = grønn

Ã Ô ½ Ë Ð Ô Ø Ô Ø Ð ØÖÙ ØÙÖ

'f( '?jfj(f{) Pa vegne av styret i Lenningen L(Ilypelag. Til Andelseiere og sponsorer i Lenningen L0ypelag!

Dagens tema INF1070. Vektorer (array er) Tekster (string er) Adresser og pekere. Dynamisk allokering

Ì ÊÁË ÈÖÓ Ö Ñ ÜÔÐÓÖ Ö Ë ÓÒ ËØ ØÙ Ê ÔÓÖØ ÏÓÐ Ò Ë Ö Ò Ö ÏÓÐ Ò ºË Ö Ò ÖÖ º Ùº Ø Ê Ö ÁÒ Ø ØÙØ ÓÖ ËÝÑ ÓÐ ÓÑÔÙØ Ø ÓÒ ÊÁË µ ÂÓ ÒÒ Ã ÔÐ Ö ÍÒ Ú Ö ØÝ Ä ÒÞ Ù ØÖ

Kravspesifikasjon med UML use case modellering. Erik Arisholm

Î Ö ØØ Ò Ú Ö

Godkjenning av møteinnkalling

Innkalling er sendt til: Namn Funksjon Representerer

Efficiency, Integrity, Reliability, Surviveability, Usability. Correctness, Maintainability, Verifiability

P ² Ö³, ƒ. ƒ μ² 1,. ƒô Ï,. Ô² Ô ³ 2. ƒ ŒŒ - Š ˆ ˆ ƒ ˆ Ÿ. ˆ Š œš ˆ ƒ. ƒ Š. ² μ Ê ² μ ± Ö ² μ Éμ Ö

Vektorer. Dagens tema. Deklarasjon. Bruk

Unicode. Unikt vakkert eller unisont håpløst? En vandring gjennom tegnkodingens historie. Dag Lamgmyhr, Ifi/UiO Ark 1 av 23

Uttrykkskraft for konseptuelle modelleringsspråk Metamodellering, ontologi

PDF created with pdffactory Pro trial version

Dagens tema: INF2100. Utvidelser av Minila array-er. tegn og tekster. Flass- og Flokkode. prosedyrer. Prosjektet struktur. feilhåndtering.

L ; D = B M B N I < G H = D = F C M E N < D ; <? ; < = H M = < F E < M B = B C O P E < E F D < Q K

Tegn og tekst. Om tegn og glyfer. Tegnkoder og kodetabeller Kode Noe som representerer noe annet. Et representert tegn kan vises på flere måter

PDF created with pdffactory Pro trial version

Ã Ô Ø ÐÚ Ö ÑÓ ÐÐ Ò Ó ØÓÖÑÓ ÐÐ Ö Ã Ô ØØ Ð

PDF created with pdffactory Pro trial version

I# w ,F3<#""" wxy2t {r u v$ 0 Y 4 } ~ Â ` - é$8 UX#' ] d Ñ \ ] J. I \ ] O,+R:,!" {%O DM%M5#' ] J*CO!

ˆ ˆŠ Œ ˆ ˆ Œ ƒ Ÿ Ÿ Œ œ ˆ ˆ Š Œ. .. ³μ. μ ± Ë ²Ó Ò Ö Ò Í É Å ˆˆ Ô± ³ É ²Ó μ Ë ±, μ, μ Ö Œ Œ ˆˆ 79 ˆ Š ˆ

Ó³ Ÿ , º 6Ä7(176Ä177).. 823Ä Œ. Œ ²±μ,,.. É ²,.. μ ²Ó,.. Íμ,.. ŠÊÉÊ μ,.. μ ±μ,.. ÒÏ

Handi-Lift ML7 Målskjema

P Šμ ²ÓÎʱ 1,.. μë μ 1,.. μ μ 2, Œ. ƒ. μ ±μ 2, ƒ. Œ. ± É 1 Œˆ Œ Œˆ Œˆ. ² μ Ê ² Diamonds and Related Materials ³ É, Ê

t Institutt for informatikk Erik Arisholm 13. mai 2009 INF1050-oppsummering-1

Dagens tema INF1070. Vektorer (array-er) Tekster (string-er) Adresser og pekere. Dynamisk allokering

r t = S t r t ; s = ½ T T

Netlife Sans er vår egen skrifttype. Den inneholder alle de visuelle elementene til identiteten vår. Den er tegnet i fire vekter, med en egen vekt

LED arbeidslys. Katalog Kontakt: Rakkestad Stavanger Side 1 12/02/17

ﺪ ﻩ ﻋﺍ ﻮﹶ ﻭ ﻗ ﻪ ﹾﻘ ﹾﻟ ﻔ ﺍ ﹺﻝ ﻮ ﹸﺃ ﺻ ﹸ ﻣ ﺔ ﻮﹸ ﻈ ﻣ ﻨ $ ﺡﺮﺷ! " ' (# $% & )*! +,!* -

SPPR Software Project Progress Report Uke 38-39

Innkalling er sendt til: Namn Funksjon Representerer

ˆ ˆŒˆ ˆŸ Š Œ ƒˆˆ 60Ä1000 ŒÔ ˆ ˆŠ ˆŸ Ÿ ˆ ˆ ˆ ˆ Š ˆ Š ˆŠˆ

Business modelling is not process modelling Gordijn/Akkermans/van Vliet. : Den fysiske ytring med kontekst og referanse

USER GUIDE. RRD Silencioso

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

ÒÒÓÙÒ Ö Ñ Û Ø Ö Ù Ò ÝÐ ØØ Ò ÝÒ ÖÓÒ Þ ÌÖ Ò Ø ÓÒ ØÓÛ Ö Ø ÙÒ Ð Ø Ö Ð Ô Ö ÒØ Ö Þ Ö ÒØ º Ö Þ Ò ºÞ ÒØ Ö ÓÖ ÓÒÓÑ Ê Ö Ò Ö Ù Ø Ù Ø ÓÒ Ó ÖÐ ÍÒ Ú Ö ØÝ Þ Æ Ø ÓÒ Ð

UML-Unified Modeling Language

(a 1, a 2, a 3, a 4 ) ³Æ s 10. a 1 a 2 a 3 a 4 a 1 a 2 a 3 a 4. ( a 1 a 2 a 3 a 4 a 1 a 2 a 3 a 4) (a 1 a 2 a 3 a 4 a 1 a 2 a 3 a 4)

Dagens tema. C-programmering. Nøkkelen til å forstå C-programmering ligger i å forstå hvordan minnet brukes.

Ã Ô ½ Ë Ð Ô Ø Ô Ø Ð ØÖÙ ØÙÖ ¹ ÁÒ Ò ØØ

Avdeling for Ingeniørutdanning Høgskolen i Oslo. Prosjektplan. Systemutvikling (lo138a) Høst Taxisentral. Forfattere:

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?

ý òó"bêë1 êë # åådeø "bêë 1 êë " 7 òó ë ;!!E(m(%$ % åådeøg} " råd

ST0202 Statistikk for samfunnsvitere

Šˆ Ÿ Š Œ ˆˆ Ÿ ˆ Š ˆ Ÿ

1 Introduksjon til designmodellen - del B 2

UML-Unified Modeling Language. Prosess-oversikt. Use case realisering

AlgDat 12. Forelesning 2. Gunnar Misund

Tom Heine Nätt og Christian F. Heide. Datasikkerhet

! " # $ % & ^Pv`!$ x âîv7ç È'Ç È b j k Æ' z{3 b jkæ b ÇÈÉÊ&( )! c q r É. xy+ - Êlm l D E ` &! D E â î #" ' #$ '#! v( D/Ev A B x y&?

v2w x y z { v2~ x x z x x x ƒ S F< E: >U V A C U C > h G T : U E T AAC > H C A r

Oppfølgingsdokument. Kode januar 2004 GymPack. D Oppfølgingsdokument. Periode 009 Forfatter. Hanne Johnsen

Ã Ô ½ Ò Ò ÐÐ ØÖ

Produktrapport Gruppe 9

Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store. Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson

Use Case-modell. Vurdering av oppdragsgivers krav

Ë < # ;<z O < HSCÉ XÚÎ

PROSJEKTPLAN FOR INF 3120-PROSJEKT: <PROJECT HOSPITAL 2005>

C C H. Forklar trippelbindingen ved betraktning av hybridisering av karbonatomene og atom- og molekylorbitaler.

Ë Ð Ô Ø Ä Ð Ö ÑÑ Ö ÑÐ ØØ Ò Ó ÓÖ Ò ÓÒ Ã Ô ØØ Ð ½ Ó ¾

Ò Ø Ø Ì Ð Ô Ó ÙØ ÝØØ ÍØ ÝØØ ÐÐ Ö Ø Ð Ô Ë ØØ ÙÐ ÑÔ Ö Ñ ÙØ ÝØØ Ú Ò Ò Ø Ó ØØ Ð ÒØ ÐÐ Ö Ð ÙØ ÐÐ Ö ÓÐ Ë Ò Ð Ö Ò Ñ ÙØ Ð Ò ÔÓÐ Ø

SPPR Software Project Progress Report Uke

ˆ ˆŠ Œ ˆ ˆ Œ ƒ Ÿ Ï Ìμ μ. Ñ Ò É ÉÊÉ Ö ÒÌ ² μ, Ê

P ²Êϱ 1,..Šμ ² ±μ 1,.. μ Î 1,2 ˆ ˆŸ. ² μ Ê ² μ Ì μ ÉÓ. É μ ±, Ì μé μ Ò É μ Ò ² μ Ö. ÍÒ Œμ ±μ ±μ μ μ Ê É μ μ Ê É É ³. Œ..

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006

Innhold. Innledning Del 1 En vei mot målet

Gruppe 43. Hoved-Prosjekt Forprosjekt

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

GJENNOMGANG UKESOPPGAVER 7 REPETISJON

(a δ,a+δ), (a δ,a+δ) = {x R x a < δ}. (a δ,a+δ)\{a} = (a δ,a) (a,a+δ) = {x R 0 < x a < δ}, f(x) = 2x 1.

Digital representasjon

Lynkurs 10. Januar 2012

Conference Centre Portal (CCP)

Transkript:

Prosjektplan v1.3 (final) gruppe 42: Nils-Kristian Liborg (kap.5), Bente Brevig (kap.5), Tom Olav Bruaas (kap: 3.4, 4.1), Eirik Lied (kap: 3.4, 4.1) Hege Lid Pedersen (dokumentasjon, kap: 1, 2, 3.3, 4.3) - alle (kvalitetssikring) 27. september 2002 1

Innhold 1 Introduksjon 3 1.1 Prosjektoverblikk.......................... 3 1.2 Prosjektleveranser.......................... 3 1.3 Utvikling av prosjektplanen.................... 3 2 Prosjektorganisering 4 2.1 Prosessmodellen........................... 4 2.2 Ansvarsområder........................... 5 3 Management 5 3.1 Risikovurderinger og håndteringer................ 5 3.2 Overvåkning og kontrollmekanismer.............. 6 4 Den tekniske prosessen 6 4.1 Metoder, verktøy og teknikker.................. 6 4.2 Prosjektsupportfunksjoner.................... 8 4.2.1 Konfigurasjonsstyring................... 8 4.2.2 Kvalitetssikring....................... 8 5 Skeduleringer og estimeringer 8 5.1 Delaktiviteter............................. 8 5.2 Gant-diagram og estimeringsplan................ 9 5.3 Tidsforbruk.............................. 11 2

1 Introduksjon 1.1 Prosjektoverblikk Dette er dokumentasjonen av prosjektet Hospital 2002 for kurs in219 høsten 2002. Det skal utvikles et HSS - Hospital Scheduling System, hvor to hovedmål er satt i fokus: Allokering av tid/ansatt-resursser Allokering av tid/plass-resursser Det vil si; skeduleringer av ansatte, i hovedsak leger og sykepleiere, iforhold til arbeidstid og skeduleringer av sengeplasser, operasjonsrom etc. med hensyn på pasienters statuser og tiden som er til rådighet. Gjennom prosjektperioden skal det fremlegges fem leveranser. Hvor de fire siste bygger på hverandre. Etter siste leveranse skal det være utviklet nok slik at et system som oppfyller krevene skal kunne lages. 1.2 Prosjektleveranser Overordnet inneholder hver av leveransene: 1. [10.sep] - Hjemmeside for prosjektet 2. [27.sep] - UseCase-modell, Prosjektplan, TauUML tutorial, brukergrensesnitt 3. [11.okt] - UMLdesign A - prioriterte funksjoner, oppdateringer av leveranse 2 4. [29.okt] - UMLdesign B - detaljert design, innspeksjonsrapport og oppdateringer av design A, prosjektplan, UseCase-modell og brukergrensesnitt 5. [12.nov] - Kodegenerering med presentasjon av den og brukergrensesnitt, erfaringsrapport 1.3 Utvikling av prosjektplanen Vi regner med at dette dokumentet, prosjektplanen, vil forandre seg iløpet av leveransene. Da spesielt med tanke på kapitel 5 hvor skeduleringer og estimeringer blir satt opp. Gjennom prosjektet vil nye aktiviteter melde seg og dermed ha behov for tid og resursser. Gamle må oppdateres etter hensyn på nye og erfaringer som er opparbeidet seg. 3

Innad i gruppa kan også arbeidsfordelingene forandre seg og det må oppdateres. Prosjektplanen vil nok utvikle seg til å bli større og mer kompleks enn første eksemplar. Versjon Hovedforfatter Beskivelse Dato Draft Hege,Tom Olav Første kladdarbeid arbeidsfordeling 20.sep Preliminary Hege,Tom Olav, 2. kladd Nils-Kristian refordeling 23.sep Final Alle 1.levering 27.sep Revidert utgave 1 TBD - 11.okt Revidert utgave 2 TBD - 29.okt Revidert utgave 3 TBD - 12.nov Tabell 1: Prosjektplansutvikling 2 Prosjektorganisering 2.1 Prosessmodellen Med tanke på hvordan in219-prosjektets leveranser foreløper, er det naturlig å etterstrebe spiralmodellen når det gjelder valg av prosessmodell. Produktet er ikke lagt opp til som en sekvens av aktiviteter hvor en følger av en annen. Det er heller snakk om aktiviteter som utvikles gjennom flere leveranser. I alle leveransene skal vi oppdatere og videreutvikle det vi har gjort tidligere etter som vi får mer informasjon, både fra oppdragsgiver og fra egen læring og nye erfaringer. Samtidig med disse iterasjonene, er vi igjennom ulike faser i utviklingen av systemet. Dvs. analyse, design, implementasjon... For hver leveranse er det viktig å se på hvor stor risiko hver aktivitet har for å mislykkes. Det kan bestemme hvordan utviklingen av den aktiviteten skal foreløpe. Dette er i tråd med spiralmodellens intensjoner. Likevel er det naturlig la en evolusjonerende prosess være en del av prosessmodellen. Da med tanke på at vi får først en ufullstendig kravspesifikasjon, og senere, etter leveranse tre, får vi den fullstendige. Dette er det samme som at oppdragsgiveren kommer med nye ting til systemet, og av prosessmodeller er det evolusjonsmetoden som håndterer dette best. 4

2.2 Ansvarsområder Ansvarsområde Overordnet prosjektleder Dokumentasjon - Latex Hjemmesidene Tekniske hjelpemidler Kontakt med oppdragsgiver Kvalitetssikring Kravspesifikasjonsutviklingen Sekretær UML Hvem Nils-Kristian Hege Eirik Bente Nils-Kristian Eirik og Hege Tom Olav Bente Eirik og Tom Olav Tabell 2: Ansvarsområder 3 Management 3.1 Risikovurderinger og håndteringer Problemer av ulike slag vil kunne oppstå iløpet av gjennomføringen av et prosjekt. Vi har sett på hva som kan gå galt og vurdert sannsynligheten og effekten av de. Sannsynligheten vurderes ved: lav, moderat, høy og effekten vurderes: liten, moderat, stor. Det er også satt opp en liste over hva vi kan gjøre for å motarbeide disse. Risiko Sannsynlighet Effekt Gruppemedlemmer frafaller lav stor Teknologien svikter lav stor Estimering av tiden er undervurdert høy stor Dårlig arbeidsfordeling moderat moderat Dårlig kommunikasjon innad i gruppa moderat moderat Sykdom moderat stor Dårlig forståelse av verktøy moderat stor Feiltolkning av oppgaven lav moderat Kunnskapssvikt lav moderat Feilvurdering av arbeidsmengde moderat stor Tabell 3: Risikovurderinger 5

Risikohåndtering Frafall - Fokus på fellesskap, forståelse og gjennsidig respekt. Teknologisvikt - Krysse fingrene ofte, håpe på det beste. Tidsestimering - Sette av god tid til oppgavene, mer enn vi tror vi vil bruke. Arbeidsfordeling - Gi alle en stor oppgave, fordele de mindre etterhvert som man blir ferdig. Si ifra når en har for mye å gjøre iforhold til andre fag. Hjelpe hverandre underveis når problemer oppstår. Kommunikasjon - Gi alle de samme beskjedene. Opprette en beskjedside på hjemmesiden. Oppmuntre til å gi kommentarer på andres arbeid. Sykdom - Spise Vekk i morgen og drikke rød solhatt. Bruke lue, votter og skjerf. Verktøy - Lese tutorialen til tau uml. Sette av god tid til oppgaver som skal benytte fremmede verktøy. Gi andre tips om lure triks og hjelpemidler. Oppgaven - Lese oppgaveteksten godt. Lese den flere ganger gjennom hele prosjektet. Streke over viktige ting. Kunnskapssvikt - Lese først igjennom relevant pensum for oppgaven man begir seg utpå. Søke på nettet og titte på andre gruppers hjemmesider. Spørre gruppelærer og andre grupper enn sin egen. Arbeidmengde - Ikke ta på seg mer arbeid enn man vet man klarer. Si ifra i god tid når en er overarbeidet og har problemer med å bli ferdig innen tidsfristen. 3.2 Overvåkning og kontrollmekanismer Vi har registrert timer underveis etter hva vi har jobbet med. Mye går over i hverandre og er vanskelig å registrere. Hjemmesiden vil inneholde en del av tidsregistreringen slik at vi unngår lappesystem. Se kapittel 5.3 for oversikt. 4 Den tekniske prosessen 4.1 Metoder, verktøy og teknikker Software Tools: 6

Tau uml: Vi har brukt tau uml for uml modelleringen så langt. http://www.ifi.uio.no/in219/verktoy/doc/html/doc/sets.htm Latex: Verktøy for dokumentfremstilling (dokumentasjon). http://www.ifi.uio.no/in219/verktoy/latex-for-nybegynnere.pdf Source code control: På dette stadiet av prosjektet har det ikke vært nødvendig. Dette på grunn av at vi ikke har begynt noen implementasjon. Time accounting: Microsoft Excel: Vi har brukt dette regnearkprogrammet for å holde styr på beregnet tidsforbruk. Både for å beregne og for å føre den tiden vi har brukt. http://microsoft.com/office/techinfo/productdoc/default.asp Compiler: Latex: Teksten skrives i emacs for så å kompileres til å bli et latex-dokument (.dvi) Debugging aids: Vi har ikke benyttet noen slike enda. Development methodologies: Requirements development practices: Viser til Professor Ray Wellands forelesning om Requirements Engineering. http://www.ifi.uio.no/in219/foiler/20020903_reqengoslo.pdf Design Methologies: Vi benytter oss av UML. http://www.omg.org/gettingstarted/what_is_uml.htm Programming language: Systemet skal implementeres i Java Coding standards: http://www.jenssoft.com http://java.sun.com/docs/codeconv/ Quality assurance practices: Vi har ikke vært i kontakt med noen slike metoder på dette stadiet av prosjektet. 7

4.2 Prosjektsupportfunksjoner 4.2.1 Konfigurasjonsstyring Konfigurasjonsstyring er viktig. Også i små prosjekter som vårt. Bruk av CVS krever, av erfaring, mye tid, forståelse og krefter å sette opp. Siden vi er relativt få på gruppen har vi valgt å ha en som har ansvar for dokumentasjonen. Vedkommende mottar alt arbeid gjort av andre via mail eller papir, og legger det inn i dokumentene. På den måten vil det til enhver tid bare være en som arbeider på dokumentene, og versjonshåndteringen blir enkel. Gruppemedlemmene mottar jevnlig oppdaterte pdf-dokumenter til gjennomlesning og gir tilbakemelding ved hjelp av disse. 4.2.2 Kvalitetssikring Vår kvalitetssikring vil være at alle leser igjennom dokumentene jevnlig. Påpeker feil, mangler, bra og dårlig formuleringer. Bruker også sjekklister som er utarbeidet.tilsammen sikrer dette, forhåpentligvis, kvaliteten på arbeidet og produktet. 5 Skeduleringer og estimeringer 5.1 Delaktiviteter For hver aktivitet er det tilordnet anvarlige utifra hvor mye tid som er estimert. Se egent punkt. Prosjekthjemmeside (Eirik) Prosjektplan (Tom, Hege og Nils-Kristian) Use Case Modell (Eirik, Bente og Tom) 1. Vurdering av krav og tekniske konsekvenser (Eirik) 2. Use case diagram (Eirik og Bente) 3. Beskrivelse av hver aktør (Eirik, Bente og Tom) 4. Beskrivelse av hvert use case (Eirik, Bente og Tom) 5. Beskrivelse av ikke funksjonelle krav knyttet til use case eller systemet som helhet Skisse av brukergrensesnitt (Nils-Kristian) Tau UML tutorial (Eirik, Bente, Tom, Hege og Nils-Kristian) Domenemodell (Eirik og Bente) 8

Design UML modell (Eirik, Bente, Tom, Hege Nils-Kristian) Klassediagrammer (Hege og Nils-Kristian) Sekvensdiagrammer (Eirik, Bente og Tom) Inspeksjon av UML Design Modell (Hege og Nils-Kristian) Kodegenerering (Eirik) Sluttrapport (Eirik, Bente, Tom, Hege og Nils-Kristian) Sammenligning av virkelig og estimert ressursforbruk (Nils-Kristian) Erfaringer fra prosjektgjennomføring (Eirik, Bente, Tom, Hege og Nils-Kristian) Evalueringer av kvaliteten til leveransene (Eirik og Bente) Evaluering av muligheten til å implementere et godt system basert på produsert design, kodegenerering og brukergrensesnitt (Tom, Hege og Nils-Kristian) Ris og ros med forbedringsforslag til gjennomføringen av obligatorisk prosjekt (Eirik, Bente, Tom, Hege og Nils-Kristian) Presentasjon av kodegenerering og design (Eirik, Bente, Tom, Hege og Nils-Kristian) 9

5.2 Gant-diagram og estimeringsplan º9»¼¼½2º¼¾, ÀAÁ6»º6ÂÃÄ Å Å ÆÇ È ÉÊ Ë ÉÌÍ Î ÆÉÌ Ï Ç Ê Ç&ÌÐ ÑÒ&Å ÆÓ Ô&Ô Í Ç ÉÆÉÎ ÌÉÇ Õ¼6½9Ö,! " # $ Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ø Ù Ú&ÛÒ&ÆÍ ÑÜ&ÆÉÎ Î Ç!Ï È Ò&ÆÛÒ&Æ ÛÒ&ÆÝÌÇ&Ë Ç!ÉÎ Î ÇÛÓ Ë Î Ç&ÆÞ,+ ß6à " # $ )) #+ #* /.,- ßæ áæò áæò ÍâÇ&ÎÑÏ "" ## $ $ Í Î ÑÐâÇ )) #,. #- ÌÔ&Ë ÝAÝ,Ç Í Éã Ç ç&ä!å ç&ä!å æ à ä ä!å,0 ßèìàjéÍ éí Ç!ê6Ô Í Ç*ë/Ò&ã Ç&ÌÌ çäaå æ ä!å ç&ä!å ßèìæ ïç " # $ ÇAê6Ô #&%'&( Í ) Ç!í6ÉÔ #0 Ê&ÆÔ&Ý î ä!å î ßèìèjð9Ó Í "& &123,456 ÆãÎÇ&ÆÉË ÆÉÈ Ç&ÌÍ ÊÔ ÇAÔ È/ÑÇ&Î ÈAéÍ Ë ÉÍ ÇAê6Ô&Í Î ÇAÎ ÆÔ Ç È è è!å è è!å " # $ ) #* 7891/:3,45163,9&; à èä èaå ßç ßèìç íò&ýç Ë Ç&Ý,Ò ã Ç&ÌÌ " + " # $ ) #+ î äaå <6=>)?%=) @='&(A" =B î ä!å ßî ïæó Î Ç&ÆÊ&ÆÇ&Ë Í Ç Í Ë ÉÑÑÍ Î ÉÍ Í Ç " - " # $ ) #- C&%D à ä ä!å ßò ßÔ&ÓAé9ëAñ/ÑÓ ÑÒ&ÆÉÔ&Ì æ äaå æ&äaå æ ä!å æ ä!å æ ä!å ßòìà óìô "". 0 "" íç ## $ $ Í #&%'&( ÉÊ&ËAé9ëñ,ÝÒ )) #0 #,. ã Ç&ÌÌ æ ä!å æ æ äaå æ äaå æ äaå ßòìæ ôç&îè Í Í Ç ã ÉÔ Ê&ÆÔ&ÝÝÇ&Æ î ä!å î ä!å ßõ öë Í Ð Ç&Î Ç&ËÍâÒ&ËÔ Í ã&éô Ê&ÆÔ&ÝÝÇ È,ã Ç Í ÉÊ&Ë!é9ëñÝ,Ò Æ ã Ç&ÌÌ è è!å î ä!å î ä!å è è!å è èaå ß ôìó óò ãññæô&ð Ç Ê Ç ËÐ Ç&ÆÇ&ÆÉË Ò&ÆÑ Ê ;23,4EEFGHI JK æ ä!å I&LNMOPI&Q&JHKR&S&TUæ G&V HGWK SL*L!U VX SKI&Y æ ä!å V HTHVU VU&QZ æ ä!å à äæ ä!å ßøìæ«ùÆÛÔ&ÆÉË ßø&ìàšôÔ&ÝÝÇ&Ë ÌÉÊ&Ë ÉË ÊÔ ÈÆÇ Í Í Ó ÆÍ Å ÆÓ Î A\,] à ä ä!å,^ /_,` &W V HL!I VMV HL!U T&U&K Y Z ESVI&[U W] V` HL!I ] V ßøìè«ùÈ Ê Ç&Æ&ÛÆÔ!Ð ÆÒ&Í âç&î ÑÇ Ñ æ äaå æ äaå æ ä!å æ ä!å æ ä!å 3/Y ßøìç ùè ÊÔ ÈÌÇ È Ç&ÆÔ&Ë Í Ç ÚÎ È Ô&ÌÉÑÇ Ñ î ä!å î äaå V HTHV U VbaU WY K HT&U&[W&U c6^ dec6^ fec6^ gec6^ hec_ijc_\kc_&]ec_&^ec lc_&èc_&dl U T&U&K I&Q&W&Um39TR&U&Q&JHJRnoAHQp5qI r 5I&QQ&W QQ&UQ X sq[hjru SKHQFI V t ß9à äúáæçô&ìó Í Ç&Ë Ç&ÆÉË ÑÔ ÍâÒ&ËÔ ÊAÔ ÈÝÓ ÈÎÌÉÊ&Ï Ò ã ÇÇÊÑÇ&Ë&ì ÛÒ&ÆÉÝÐ Ò&ÊãÌìÇ Í ÉÊ&Ë æ äaå æ&äaå è èaå æè ä!å èaå æè ä!å è!å æ ä!å r W V HLAI VouSL*L!U&Q V I&K U&K v+ v6 w%c w%c )x#&y@z @ƒ x# >'&( {A{,# ) = # } }} } } } } } } } ""& + + -&.& -~0! - 0 ) #*/C #&>> } } } } } } } } " + - ˆ. 0 Š 0!.& v- e ) v- + Ž# #A 6' ) y %=$ #&>) ) #!Œ6=' #A' $A ) D&%'&{ #A 6'&) # } }} }} } } } } } "" + + 0 +& + 0 + 0 Š! + 0 v- -j 9 % #&%=( D' $/@#&y ( =) y #Ay %' $ } " + +~- 0 Š v-. ŒC&{,#&( # {C #&>> } } } } } } " + 0 + 0! - v. Ž% y #&%D%#&( ) # ) ( =@@) y =) ) # } } } } } } } " + 0 k 0 Š! 0 v0 v'& A 9A"2@ @C&%='&> } } } } " + 0 +& + 0 0! + v Œ# ) =D&(A 9",{C #&>> } } } } } +& + 0 +?>' ) ) # =' D&%'&{{#&% } } } } } k 0 v + #&y$ #&( ) &=' D&%'&{{# % } } } } } 0 +! v ( ) ƒ #&y )xc&(' $, # ) =D&(! 9"{,C #&>> } } } v 0 j 0 Š 0A 0 v?c # D # ( #&%#&%=( D } } v -~0j 0! > @@%'&ƒ ƒ C&%@ Figur 1: Gantdiagram } } med v estimering 0 +& + 0 Š! + vš š œ2œ9 ž Ÿ ž ž 2 2 } } 0!. vš +«ª% '&%=( vš -«ª$ '&> D #&% DA' %'Aƒ $># %C $ )x#&y@# #&%'&( ) #@ y$ '&>=@# @ }} }} ŠŠ!. vš&. ª$ '&> #&%=( D' ${A >=D&z # @ C&%={ƒ > } } +. 0!. v9 w%# ) #&( @' )xc&(' $y C # D #&(& C D #&) =D&( } } vš + - Š!. + A±²6³µÁ 6 ¹ ûaüý6þ ÿ ÿ 10

5.3 Tidsforbruk 1 4 > G? A G K G O?! 6 A 6? G G G G G Y!! "$#&%(')+*,.-/ 01 12 03 03 576 89 : : ; ; <= 5@? 89:! 6??A 57A BCED&! < F = 57AH 6IBC< D&! J&!!; 57AH?ML9!NBC< D&! 57AH AQP$= R!S < 57AHTMJC; ; = 5@T L9 < 57G 57!EB&F Ü! 57O J& EB&F UE; = 57OH 6IV9!< =!!; ; 57OH?MW9 =!!; ;E 57X : E! S= EB&F U ;= 57K VZ= 57> W9! 57>H 6IW9!; ;ER!N 57>H?M[9\! ]\! : 57>H AI[Z! R!N!^+! Figur 2: Tidsforbruk 57>HTM[Z<! (! _; \ @;EH 576` 89!: E! N = H = < 11