Prosjektrapport ver.1.0

Avdeling for ingeniørutdanning

Høgskolen i Oslo

Prosjektrapport

Systemutvikling (lo138A)

Høst 2011

Oslo Båtutleie - Bookingsystem

Gruppe 4

Forfattere:

Mjølund, Espen, s171673

Bache, Robert Bicanic, 168499

Karlsen, Marius Kværner, s171667

Bjørnerud, Jonas, s171676

Dato: 25.11.2011

sammendrag

Denne rapporten omhandler prosjektarbeidet vi i gruppen har utviklet og gjennomført i faget Systemutvikling. Rapporten dekker hele prosessen som inngår i et prosjektarbeid: fra ide og planleggingsstadiet, gjennom krav og frem til analyse og design. Rapporten dokumenterer alt arbeidet vi utført, gjennom å vise hvilke fremgangsmåter vi har brukt, valgene vi har foretatt og resultatet vi sitter igjen med ved slutten av prosessen.

Målet for prosjektet var å utvikle et system for en bedrift, Oslo båtutleie, som dekker de oppgaver og behov systemets brukere har for å utføre sine daglige oppgaver. Gjennom prosjektrapporten skal vi dokumentere at vi har oppnådd målene vi har satt relatert til disse behovene.

Innhold

1.2 Mål for Prosjektet. 6

1.3 Omfang av løsning. 7

1.4 Suksesskriteria. 7

1.5 Antagelser. 8

2 tilpasning av utviklingsmodell.. 9

2.1 Beskrivelse av utviklingsmodell. 9

2.2 Begrunnelse for tilpasninger. 9

3 Analyse.. 13

3.1 Kravspesifikasjon. 13

3.2 Use Case Modell. 15

3.2.1 Use case diagram.. 15

3.2.2 Detaljerte Use case beskrivelser 16

3.3 Domenemodell. 19

3.4 aktivitetsdiagram.. 20

4 Design.. 25

4.1 Klassediagram.. 25

4.2 Sekvensdiagram.. 27

4.3 Logisk arkitektur. 38

4.4 Brukergrensesnitt. 39

5 Vurdering.. 42

5.1 Vurdering av foreslått løsning. 43

5.2 vurdering av valg utviklingsmodell. 44

5.3 Vurdering av eget prosjektarbeid. 46

6 Konklusjon.. 47

7 Litteraturliste.. 49

VERSJONSLOGG

Versjon	Dato	Forfatter(e)	Beskrivelse av versjon
0.3	12.10. 2011	EM, RBB, MKK, JB	-Første utgave av prosjektrapport med kapittel 1-2, samt 3.1 & 3.2 utfylt.
0.6	03.11.2011	EM, RBB, MKK, JB	-Generelle rettelser etter tilbakemelding fra veileder -Utfylt kapittel 3 og 4 (grunnleggende modellering)
1.0	25.11.2011	EM, RBB, MKK, JB	-Ferdig versjon. -Generelle rettelser etter tilbakemelding fra veileder -Utfylt sammendrag, kapittel 3, 4, 5, 6 & 7.

1 Introduksjon

1.1 Bakgrunn

Oslo Båtutleie er et nystartet firma som spesialiserer seg på utleie av seilskuter og større motorbåter. Kundegruppen består i hovedsak av firma og organisasjoner som skal på gruppeturer (for eksempel firmafester og events). De blir også kjørt sightseeing i perioder. Privatpersoner har også mulighet til å bestille turer og dette er populært, for eksempel til bryllupsfest eller lignende.

I oppstartsfasen har firmaet basert seg på bruk av programmene i Microsoft Office-pakken til å organisere den daglige driften. De ansattes arbeidsoppgaver, kort oppsummert, dreier seg om mail og telefonkorrespondanse med kunder og leverandører, oppdatering av kundeinformasjon, utforming av tilbud og leieavtaler samt oppretting av bookinger. I tillegg til dette har daglig leder ansvar for oppretting av arbeidsavtaler, vedlikehold av ansattlister samt kjøring av lønninger og generelt regnskap for bedriften. Bedriften benytter et eget regnskap og økonomisystem.

Bedriften bruker Microsoft Word til å skrive kontrakter og tilbud, Excel til ansattlister og oversikt over båter og priser. Til lagring av kundeinformasjon og epost benyttes Outlook. Kalenderfunksjonen i samme program benyttes også til å plotte inn båtbookinger. Hver båt har sin egen kalender.

Fakturaer må legges manuelt inn i bedriftens økonomisystem.

Etter hvert som driften har eskalert har overnevnte løsning vist seg å være lite oversiktlig og tungvint, og dette har skapt mye problemer i det daglige arbeidet:

Bedriftens IT-ansvarlig estimerer at han på ukentlig basis bruker opp til 25 timer på å hjelpe til med problemer som oppstår i forbindelse med utføring av ordinære arbeidsoppgaver.
De ansatte føler selv at de bruker uforholdsmessig mye tid på datautfordringer, og at dette går ut over service over for bedriftens kunder.
Det har også blitt en betydelig mengde feilbookinger grunnet at informasjon må bli manuelt overført mellom de forskjellige programmene, og blant annet dette har ført til at andelen misfornøyde kunder i første driftshalvår har klatret til 25% (av antall bookinger), ut i fra undersøkelser bedriften har gjort.

Oslo Båtutleie har på bakgrunn av dette besluttet å anskaffe et system som er skreddersydd bedriftens bruksområder. Bedriften ønsker at alle oppgavene som nevnt over skal kunne utføres ved hjelp av et enhetlig system, med unntak av det som faller inn under økonomisystemets område.

1.2 Mål for Prosjektet

Prosjektets mål er å skreddersy et datasystem tilpasset Oslo Båtutleies behov i den daglige driften. Datasystemet skal være en enhetlig applikasjon som erstatter alle de separate programmene som bedriften per dags dato er avhengig av. Dette dreier seg om programvare for tekstredigering, regneark, kalender, Epost, kontakter.

Systemet skal effektivisere hverdagen for de ansatte, få ned feilprosenten knyttet til registrering av data, og sørge for mer fornøyde kunder:

· Tiden IT-ansvarlig bruker på å assistere de ansatte med problemløsing på ukentlig basis skal reduseres med 50% innen 3 måneder etter at systemet er satt i drift.

· Tiden de ansatte bruker på tungvint arbeidsflyt og datatekniske problemer på ukentlig basis skal reduseres med 30% innen 3 måneder etter at systemet er satt i drift.

· Antall feilregistreringer av data forårsaket av ansatte skal reduseres med 90% innen 3 måneder etter at systemet er satt i drift.

· Andelen misfornøyde kunder på grunn av feil forårsaket av dataproblemer skal reduseres med 85% innen 3 måneder etter at systemet er satt i drift.

Tidsaspekt.

Ferdig produkt i henhold til omfang (kap. 1.3) skal være klart innen 25. November 2011

1.3 Omfang av løsning

Vi vil innledningsvis gjennomføre en kravanalyse for å kartlegge kundens behov til funksjonalitet i systemet. Dette vil gjennomføres ved diskusjon innad i gruppen for å forsøke å tilegne oss en god forståelse av oppdragsgivers domene, samt å prøve å sette oss inn i arbeidssituasjonen til de ansatte.

På grunnlag av kravanalysen vil vi utvikle en kravspesifikasjon som lister opp funksjonelle og ikke-funksjonelle krav til systemet. Kravspesifikasjonen vil danne grunnlag for et forslag til løsning som presenteres for kunden. Ut i fra kundens tilbakemeldinger til forslaget vil dette enten bli satt i utvikling, eller bli endret dersom dette er nødvendig.

Løsningen vil bli utviklet og dokumentert i en prosjektrapport, men vil ikke bli implementert i dette prosjektet. Det vil altså ikke foreligge programkode ved ferdigstilt prosjekt. Unntaket er pseudokode, som antakelig vil benyttes for å demonstrere ulike funksjoner.

1.4 Suksesskriteria

Hva skal til for at vi lykkes med dette prosjektet?

· Vi må jobbe jevnt med oppgaven hele tiden. Ellers er det lett å komme på etterskudd i forhold til leveringer osv.

· Alle gruppemedlemmene må sette av nok tid til å utføre de oppgavene som er blitt utdelt.

· God prosjektledelse

· God, åpen dialog mellom gruppemedlemmer.

· God dialog med kunden gjennom hele prosjektet.

1.5 Antagelser

Følgende antagelser og begrensninger er gjort for arbeidet i prosjektet:

Antagelser:

Vi antar at oppdragsgiver har nødvendig maskinvare og infrastruktur tilgjengelig til å kjøre løsningen. Dette innebærer PC-er til de ansatte som skal bruke systemet, server til å kjøre web-server og database med tilfredsstillende backup-løsning, samt lokalt nettverk og ordinær internett-tilknytning.
Vi antar at Oslo Båtutleie stiller med nødvendige ressurspersoner i forbindelse med kravanalyse

Begrensninger:

Løsningen vil ikke bli implementert (ingen programmering)
Vår hovedprioritet er å utvikle og få frem funksjonaliteten i de deler av systemet som brukeren vil jobbe direkte mot i det daglige.
Database-tilknytning er noe nedprioritert av tidsmessige årsaker og vil ikke detaljeres i stor grad
Tilknytning til eksternt regnskap/økonomisystem blir ikke vektlagt.

2 tilpasning av utviklingsmodell

2.1 Beskrivelse av utviklingsmodell

Vi skal i prosjektet benytte utviklingsmodellen Unified Process (UP). Dette er en mye brukt utviklingsmodell innen programutvikling.

UP er en iterativ og inkrementell modell. Dette betyr at den lar oss utvikle løsningen et steg om gangen, for så å gå tilbake å revurdere og videreutvikle det vi allerede har gjort, i tillegg til å gradvis utvide funksjonaliteten til løsningen.

Modellen er delt inn i fire faser: idéfasen, utdypningsfasen, konstruksjonsfasen, og overgangsfasen. Her følger litt info om disse:

Idéfasen. Dette er den innledende fasen i utviklingsarbeidet. Fasen er kort, gjerne av en til to ukers varighet. Her foretas valg i forhold til prosjektomfang. Man foretar lønnsomhetsvurderinger. En overordnet kravspesifikasjon for løsning vil også inkluderes her, og grunnleggende modellering i form av enkle Use Case-modeller er også med. Resultatet av denne fasen presenteres for oppdragsgiver som forhåpentligvis gir klarsignal for å fortsette arbeidet.

Utdypningsfasen. Dette er en analysefase. Man jobber videre med detaljering av kravspesifikasjon, detaljering av Use Case-modeller, samt foretar øvrig modellering som danner grunnlag for arbeidet som skal gjøres i konstruksjonsfasen. Dette inkluderer typisk aktivitetsdiagrammer, domenemodell, sekvensdiagrammer, klassediagram med mer.

Konstruksjonsfasen. Dette er fasen der design og programmeringen foregår. Fasen består av flere iterasjoner som inneholder detaljanalyse, design, implementering og testing.

Overgangsfasen. Denne fasen inneholder ferdigstilling av prosjektet. Her dreier mye seg om kvalitetssikring, brukertrening, idriftsettelse, og tilpasning til brukerne.

Blant UP’s sterkeste sider er muligheten til å tilpasse modellen etter prosjektets behov. UP er skalerbar og utviklerne bestemmer selv hvor omfattende krav til dokumentasjon og modellering skal være. Et lite prosjekt, som det vi jobber med her, behøver altså ikke generere like mye artefakter og dokumentasjon, og behøver heller ikke inneholde de samme disiplinene, som et stort prosjekt vil kreve.

UP gir oss muligheten til å kunne gå bakover i prosjektet og evaluere hva vi har gjort tidligere og om nødvendig gjøre forbedringer. Dette er hensiktsmessig da man ofte får en bedre og bedre forståelse av problemstilling etter hvert som man jobber seg nedover i et prosjekt. Man vil da ofte se nødvendigheten av å endre på løsninger man tidligere har designet. Det er også stor sjanse for at kravene til løsning forandrer seg underveis. Fasene deles i UP opp i iterasjoner, som er hovedsakelig tidsdefinerte luker der man jobber med definerte oppgaver. Iterasjonen avsluttes med at man analyserer og vurderer arbeidet som har blitt gjort, som igjen gir grunnlag for arbeidet som skal utføres i neste iterasjon.

Under er en illustrasjon som viser en typisk fordeling av aktiviteter over de forskjellige fasene og iterasjonene:

Beskrivelse: Development-iterative

Figur 2.1.0 Kilde: Wikipedia - http://en.wikipedia.org/wiki/Unified_Process (23.09.2011)

2.2 Begrunnelse for tilpasninger

Da løsningen i dette tilfelle ikke skal implementeres er det derfor hensiktsmessig for oss å fokusere på de tre første fasene, altså idéfasen, utdypningsfasen og konstruksjonsfasen. UP inneholder mange disipliner; forretningsmodellering, krav, analyse, design, implementasjon, testing og idriftsettelse. Igjen velger vi å fokusere på et utvalg av disse disiplinene, og begrunnelsen for dette er igjen at vi ikke skal implementere løsningen i dette prosjektet. Vi holder oss derfor til disiplinene forretningsmodellering, krav, analyse og design. Da det i prosjektet ikke er lagt større vekt på lønnsomhetsvurderinger og liknende fjerner vi også forretningsmodellering og sitter igjen med planlegging, krav, analyse og design:

Planlegging: Denne disiplinen består i stor grad av innledende runder med idéstorming, finne ut hva prosjektet skal omhandle og definere en problemstilling å jobbe ut i fra. I tillegg må vi få på plass brikkene i prosjektarbeidet. Vi fordeler ansvar og jobber med å få i gang og oppdatere styringsdokumenter og rammene for prosjektet vårt. Den tyngste jobben blir gjort innledningsvis i prosjektet, men det må planlegging til underveis i prosjektet, for eksempel i forkant av nye iterasjoner.

Krav: Ut i fra prosjektets problemstilling henter vi ut de nødvendige krav til løsningen vi skal tilby kunden. Vi gjør dette ved å forsøke å forstå kundens domene, samt sette oss inn i arbeidssituasjonen til de ansatte i firmaet. Vi bruker Use Case som et viktig verktøy for å hente ut krav i denne disiplinen. Dette vil resultere i en kravspesifikasjon. Mye av arbeidet i denne disiplinen blir gjort innledningsvis, men krav til løsning vil gjerne endres underveis, og vi vil antakeligvis få en dypere forståelse av problemområdet etter hvert som vi jobber, og dermed vil denne disiplinen være tilstedeværende gjennom hele prosjektet.

Analyse: I denne disiplinen jobber vi ut i fra kravene vi har tilgjengelig og forsøker å forme et system ut i fra dette. Arbeidet omfatter detaljering av kravspesifikasjon samt modellering. Vi vil jobbe videre med Use Case-modell, samt produsere domenemodell og aktivitetsdiagram.

Design: I denne disiplinen ser vi nærmere på systemet på detaljnivå. Vi jobber med hvilke objekter systemet skal bestå av og samhandlingen mellom disse. Vi vil også se på den logiske arkitekturen til systemet samt vurdere mulige brukergrensesnitt for løsningen. Vi vil produsere sekvensdiagram og klassediagram som igjen vil ligge til grunnlag for senere konstruksjon av løsningen.

Vi har planlagt en iterasjon i idéfasen, to iterasjoner i fordypningsfasen og to iterasjoner i konstruksjonsfasen. Vi setter av ca. 2 uker per iterasjon, med unntak av iterasjon 1, som er ca. 4 uker.

Beskrivelse av iterasjoner i prosjektet:

Figur 2.1.2

Iterasjon 1:

Planlegging
Overordnet Use Case
Overordnet Kravspesifikasjon
Kvalitetssikring
Evaluering

Iterasjon 2:

Re-planlegging
Detaljert Use Case
Detaljert kravspesifikasjon
Overordnet analyse
Kvalitetssikring
Evaluering

Iterasjon 3:

Re-planlegging
Detaljert analyse
Overordnet design
Kvalitetssikring
Evaluering

Iterasjon 4:

Re-planlegging
Detaljert design
Kvalitetssikring
Evaluering

Iterasjon 5:

Detaljert design
Kvalitetssikring
Evaluering

3 Analyse

3.1 Kravspesifikasjon

Her følger våre krav til løsningen vi skal lage.

Funksjonelle krav:

· Brukeren skal kunne foreta en sikker innlogging med brukernavn og passord.

· Brukeren skal kunne sjekke båtstatus (om båtene er ledige, utleide eller på service.)

· Brukeren skal kunne oppdatere båt-status (om båtene er ledige, utleide eller på service.)

· En booket eller reservert båt skal automatisk reserveres i systemet og skal gjøres utilgjengelig for ny reservasjon i valgte tidsperiode.

· En booket eller reservert båt skal vises som opptatt i en grafisk kalender med informasjon om bookingen/reservasjonen i tekst.

· Brukeren skal kunne se prisliste over alle tilgjengelige tjenester og varer.

· Administrator skal kunne redigere prisliste.

· Objekter på prisliste skal kunne legges til på ordre.

· Brukeren skal kunne sende og lese mail.

· Brukeren skal kunne legge til en ny kunde i systemet.

· Brukeren skal kunne redigere informasjon om kunder.

· Administrator skal kunne oppdatere ansattliste (legge til, endre og slette ansatte)

· En ordre skal inneholde en kunde, en eller flere båter, tilleggstjenester og tidspunkt

· En ordre skal automatisk oppdateres med pris ut i fra hvilke tjenester som legges til.

· Brukeren skal kunne overstyre autogenererte priser satt av systemet på en ordre

· Brukeren skal kunne opprette, endre & slette ordre.

· Brukeren skal kunne eksportere ordre over til økonomisystemet.

· Brukere med ekstra tilgang skal kunne administrere databasene via systemet

Ikke-funksjonelle krav:

· Systemet skal ha en oppetid på mer en 23 timer per døgn.

· Systemet skal fungere med 30 samtidige brukere uten merkbare endringer i responstid.

· Systemet (klienter) skal fungere like bra uansett operativsystem, så sant operativsystemet tilbyr en nettleser som støtter HTML5 og CSS3.

· Systemet skal ha et lett og oversiktlig brukergrensesnitt.

· Inngangsterskelen for å bruke systemet skal være lav. Systemet skal være selvforklarende.

· Systemet skal gi gode tilbakemeldinger på eventuelle feil som måtte dukke opp.

· Systemet skal være lettdrevent, stabilt, og raskt.

· Systemet skal avverge eventuelle dobbelt-bookinger, eller om en eksisterende kunde blir forsøkt opprettet på nytt.

· Systemet skal være en webapplikasjon som kjøres i en vanlig web-browser og som kan aksesseres uavhengig av brukerens lokasjon, så lenge det eksisterer en tilkopling til internett.

· Systemet skal holde rede på hvem som har gjort alle endringer.

3.2 Use Case Modell

3.2.1 Use case diagram

Her følger et overordnet Use Case-diagram som modellerer løsningen vi utarbeider.

Figur 3.2.1 – Overordnet Use Case Diagram for løsningen

3.2.2 Detaljerte Use case beskrivelser

Under følger en detaljert beskrivelse av de to brukstilfellene vi anser som å være de viktigste når det gjelder funksjonaliteten i løsningen. Dette er ”Opprette bestilling” og ”legg til kunde”. Disse demonstrerer essensielle funksjoner i et bookingsystem, og det er sannsynlig at dette vil være de funksjonene de ansatte bruker mest i løpet av en arbeidsdag.

Use-Case Opprette bestilling
Aktør(er) Ansatt
Trigger Ansatt ønsker å opprette en bestilling etter forespørsel av kunde.
Pre-Betingelser Kunde må være registrert og eksistere i systemet . Ansatt må være logget på systemet.
Post-betingelser Bestilling er registrert i systemet
Normal hendelsesflyt 1. Ansatt finner kunde i systemet. 2. Systemet viser informasjon om kunden. 3. Ansatt velger dato, tid, sted. 4.Systemet viser liste over båter. 5. Ansatt velger båt ut ifra kundens ønsker. 6. Systemet bekrefter tidspunkt og valg av båt. 7. Ansatt fyller inn tilleggsinformasjon om bestillingen (matbestilling, antall personer med mer). 8. Systemet lagrer informasjonen og gir den ansatte en melding om at bestillingen er lagret.
Variasjoner 5. Systemet viser at det ikke er tilgjengelige båter på ønsket tidspunkt. 5.1 Systemet avbryter bestillingen.
Resultat Ansatt har opprettet og lagret bestilling
Relatert informasjon Ansatt må registrere kunde / firma med personalia i databasen før det kan opprettes bestilling(er).

Navn:	Legge til kunde
Aktør:	Ansatt
Pre-betingelse:	Ansatt er logget på systemet
Post-betingelse:	Kunden er registrert i systemet
Trigger:	Den ansatte skal legge inn ny kunde i systemet
Normal hendelsesflyt:	1. Ansatt oppretter ny kundeoppføring. 2. Systemet ber den ansatte om å fylle nødvendig informasjon. 3. Ansatt registrer informasjon om kunden og velger ”lagre”. 4. Systemet legger inn den nye kunden og gir ansatt bekreftelse på ny kundeoppføring.
Variasjoner:	4. Kunden er registrert i systemet fra tidligere 4.1. Brukstilfelle avbrytes av systemet og ansatt blir varslet med feilmelding.

3.3 Domenemodell

Her følger en domenemodell for løsningen vi lager. Diagrammet viser konseptuelle klasser for domenet vi undersøker, med relasjoner mellom klassene. Sentralt for modellen er:

· et båtregister som inneholder bedriftens båter med all informasjon,

· et kunderegister med info om kunder

· en prisliste for mulige tjenester

· en kalendertjeneste.

Disse konseptuelle klassene samhandler med ordre-klassen når en bestilling opprettes.

Figur 3.3 - Domenemodell

3.4 aktivitetsdiagram

Lag et aktivitetsdiagram for hovedflyten i løsningen.

Her følger aktivitetsdiagram for de Use Casene som er gjennomgått i kapittel 3.2.2, ”Legge til kunde” og ”Opprette bestilling”. Et aktivitetsdiagram tar et brukstilfelle, og ser på aktiviteter som må til for å oppfylle dette.

Hva som er gangen i de to brukstilfellene er utfyllende forklart i Use Case-beskrivelser kapittel 3.2.2, men det følger allikevel en steg for steg-gjennomgang til hvert av aktivitetsdiagrammene.

Beskrivelse av ”legg til kunde” - aktivitetsdiagram:

Hvem: Ansatt oppretter en ny kundeoppføring i systemet.

Hendelsesforløp:

- Brukeren velger å opprette en ny kunde

- Bruker fyller inn data om kunden.

- Skjemaet blir så sjekket opp mot systemet for å se om innholdet oppfyller kriteriene for lagring. Er det feil eller mangler i skjemaet må brukeren gjøre de nødvendige endringer før systemet lar brukeren gå videre.

- Er alt i orden vil brukeren få inputdata presentert av systemet sammen med valgmulighetene: bekreft og avbryt. Ved å velge avbryt blir sesjonen avbrutt og innholdet blir ikke lagret.

- Ved bekreft lagres innholdet og brukeren får en bekreftelse på at en ny kunde er opprettet.

Figur 3.4.1 – Aktivitetsdiagram – ”legg til ny kunde”

Beskrivelse av ”opprett bestilling” - aktivitetsdiagram:

Hvem: Ansatt oppretter en ny bestilling i systemet.

Hendelsesforløp:

- Bruker utfører valg for oppretting av ny bestilling

- Brukeren velger kunden som skal knyttes til bestillingen (gjennom identifisering av kundens navn eller nummer som er lagret i systemet).

- Skulle informasjonen for indentifisering av kunden være feil eller ikke eksistere vil brukeren bli gjort oppmerksom på dette gjennom en feilmelding.

- Hvis kundeinformasjonen stemmer blir brukeren presentert et skjema for å fylle inn nødvendig data om den aktuelle bestillingen.

- Dataen fra skjemaet blir sjekket opp mot systemet for å se at det ikke inneholder feil eller mangler som forhindrer lagring. Hvis det blir funnet feil, vil brukeren få en feilmelding og må gjennomføre endringer i inputen før det er mulig å gå videre.

- Er alt i orden vil brukeren få inputdataen presentert av systemet sammen med valgmulighetene: bekreft og avbryt. Ved å velge avbryt blir sesjonen avbrutt og innholdet blir ikke lagret.

Ved bekreft lagres innholdet og brukeren får en bekreftelse på at en ny bestilling er opprettet.

Figur 3.4.2 – aktivitetsdiagram – ”opprett ny bestilling”

4 Design

4.1 Klassediagram

Et klassediagram viser oversikt over programvare-klasser i systemet vi utvikler. Det vises sammenhenger mellom klassene, og attributter, samt metoder objekter av klassene bruker til å sende meldinger til hverandre.

Informasjon om begrensninger og forenklinger gjort i klassediagram.

Vi foretar en forenkling på det viset at alle registre (båtregister, kunderegister osv.) ligger i minne i form av arrays, som f.eks. "kundeliste: array". Vi beskriver ikke detaljer omkring tilkopling til databaser osv.

For å begrense omfanget av diagrammet har vi valgt å begrense oss til de systemkomponentene som relaterer seg til de to Use Casene vi har jobbet med i prosjektet. Mye annen funksjonalitet som ikke relaterer seg til Use Casene, har blitt utelatt. Dette er gjort for oversiktlighetens skyld, samt av tidsmessige årsaker.

Figur 4.1 - Klassediagram

4.2 Sekvensdiagram

Et sekvensdiagram viser kommunikasjon mellom aktør og systemet, samt kommunikasjon mellom systemets interne moduler/objekter som en funksjon av tid.

Her følger sekvensdiagram som modellerer brukstilfellene ”Legg til ny kunde” og ”Opprett bestilling”, også presentert som detaljerte Use Case-beskrivelser i kapittel 3.2.2. Brukstilfellene blir modellert både som blackbox-sekvensdiagram (med normalflyt og avvik) og ordinært sekvensdiagram (med normalflyt og avvik). Forskjellen på disse er at blackbox-varianten viser samhandling mellom aktør og systemet som en blackbox – altså ser vi ikke på hva som skjer på innsiden av systemet, kun hva resultatet blir. Ordinært sekvensdiagram åpner systemet og ser nærmere på kommunikasjon mellom systemets objekter i tillegg til mot aktøren. Kapittel 4.2.1 ser nærmere på Blackbox-variantene, mens kapittel 4.2.2 viser ordinære sekvensdiagrammer for brukstilfellene.

4.2.1 Black-box sekvensdiagram:

4.2.2 Sekvensdiagram – ”legg til ny kunde” - normal hendelsesflyt:

1. Den ansatte ønsker å føre opp en ny kunde.

2. Kunderegisteret ber den ansatte om å fylle inn alle feltene i registreringen.

3. Den ansatte registrerer informasjonen om kunden.

4. Ny kunde blir opprettet og den ansatte får bekreftelse på at ny kunde er oppført.

Figur

4.2.1.1 – sekvensdiagram blackbox – opprett ny kunde – normal hendelsesflyt

Sekvensdiagram – ”legg til ny kunde” - avvikende hendelsesflyt:

1. Den ansatte ønsker å føre opp en ny kunde.

2. Kunderegisteret ber den ansatte om å fylle inn alle feltene i registreringen.

3. Den ansatte registrerer informasjonen om kunden.

4. Kunderegisteret sier at kunden allerede finnes i registeret og avbryter registreringen.

Figur

4.2.1.2 – sekvensdiagram blackbox – opprett ny kunde – avvikende hendelsesflyt

Sekvensdiagram – ”Opprett bestilling” - normal hendelsesflyt:

1. Den ansatte finner kunde i systemet.

2. Systemet viser informasjon om kunden.

3. Den ansatte velger dato, tid og sted for bestilling.

4. Systemet viser en liste over båter

5. Kunden velger ønsket båt fra liste

6. Systemet bekrefter tidspunkt og valg av båt

7. Kunde fyller inn tilleggsinformasjon om bestilling (f.eks matbestilling)

8. Systemet lagrer informasjon og gir bekreftelse til kunden

Figur 4.2.1.3 – sekvensdiagram blackbox – opprett bestilling – normal hendelsesflyt

Sekvensdiagram – ”Opprett bestilling” - avvikende hendelsesflyt:

1. Den ansatte finner kunde i systemet.

2. Systemet viser informasjon om kunden.

3. Den ansatte velger dato, tid og sted for bestilling.

4. Systemet viser en liste over båter

5. Kunden velger ønsket båt fra liste

6. Systemet gir feilmelding om at valgt båt ikke er ledig til ønsket tid. Bestilling avbrutt.

Figur 4.2.1.4 – sekvensdiagram blackbox – opprett bestilling – avvikende hendelsesflyt

4.2.3 Ordinære sekvensdiagram:

Informasjon om diagrammet ”Opprett ny kunde – normal hendelsesflyt:”

(Denne beskrivelsen er ment som et supplement til sekvensdiagrammet i tilfellet dataflyten oppleves som uklar)

Bruker velger "opprett kunde" fra meny. Fra GUI utføres metodekallet "OpprettKunde()" på systemkontrolleren. Dette oppretter et "Kunde_register"-objekt. Dette objektet inneholder et objekt av typen "Kunde" som initieres. Som en del av "OpprettKunde"-metoden utføres Display("Fyll inn info") som genererer informasjon på skjerm. Vi antar at metoden Display() kan vise alle typer informasjon på skjerm. Metoden "Set_DataFromGUI()" lagrer data inntastet fra kunde i variabel "DataFromGUI". Vi antar for enkelhetsskyld at dette er løst ved å legge inn info i form av komma-separerte-verdier. "Set_Kunde()" overfører informasjon tastet av ansatt til "Kunde"-objektet og bruker attributtet "DataFromGUI" som argument. LeggInnKunde() lagrer Kunde-objektet i Kunderegisterets "-Kundeliste: array".

Metoden "LeggInnKunde()” inneholder logikk som kontrollerer om kunden eksisterer i registeret fra tidligere. På grunnlag av dette sendes enten melding om at "kunde er lagret" eller "feilmelding: kunde eksisterer fra før" til systemkontroller ved hjelp av metoden "Set_DataToGUI()". Status lagres i variabelen "DataToGUI" og videresendes til GUI ved hjelp av metoden "Display(DataToGUI).

Figur 4.2.2.1 – Sekvensdiagram ”opprett ny kunde – normal hendelsesflyt

Informasjon om diagrammet ”Opprett ny kunde – avvikende hendelsesflyt:”

(Denne beskrivelsen er ment som et supplement til sekvensdiagrammet i tilfellet dataflyten oppleves som uklar)

Metoden "LeggInnKunde() inneholder logikk som kontrollerer om kunden eksisterer i registeret fra tidligere. På grunnlag av dette sendes enten melding om at "kunde er lagret" eller "feilmelding: kunde eksisterer fra før" til systemkontroller ved hjelp av metoden "Set_DataToGUI()". Status lagres i variabelen "DataToGUI" og videresendes til GUI ved hjelp av metoden "Display(DataToGUI).

Figur 4.2.2.2 – Sekvensdiagram ”opprett ny kunde – avvikende hendelsesflyt

Informasjon om diagrammet ”Opprett ny bestilling – normal hendelsesflyt:”

(Denne beskrivelsen er ment som et supplement til sekvensdiagrammet i tilfellet dataflyten oppleves som uklar)

Bruker velger "opprett ordre" fra meny. Fra GUI utføres metodekallet "OpprettOrdre()" på systemkontrolleren. Dette oppretter et "Ordre"-objekt. Dette objektet inneholder et objekt av typen "Kunde" som initieres. Det initieres også et Kunde_register"-objekt. Dette objektet inneholder hele kundelisten i et array. Ved hjelp av metoden Set_DataToGUI(kundeliste) overføres kunderegisteret til systemkontrolleren som ved hjelp av GUI-metoden Display(DataToGUI) viser kundeliste på skjerm. Ansatt velger riktig kunde fra liste og overfører valget til systemkontrolleren ved hjelp av metoden "set_DataFromGUI()". Get_kunde_from_list(DataFromGUI) overfører informasjon om valgt kunde til kunderegisteret som henter ut samsvarende informasjon fra "kundeliste" og overfører til "Kunde"-objektet ved hjelp av "set_kunde()".

I ordre-objektet initieres det et kalender-objekt som skal ta hånd om tid og dato for ordren. Ved hjelp av metoden set_DataToGUI("Fyll ut tid og dato") sendes en melding til systemkontroller som videreformidler meldingen til GUI ved hjelp av Display(DataToGUI). Ansatt fyller inn ønsket dato og tid og sender dette fra GUI til systemkontroller ved hjelp av metode set_DataFromGUI(). Informasjonen sendes til kalender-objektet ved hjelp av "NyKalenderOppføring(DataFromGUI)".

Når ansatt er ferdig med å legge inn båter i bestilling opprettes et nytt objekt av type ordrelinje. Dette oppretter igjen et Tilleggstjeneste-objekt og det opprettes et "Tilleggstjenester_register"-objekt. Sistnevnte inneholder alle tilleggstjenester i et array. Ved hjelp av "set_DataToGUI(tjenesteliste) overføres tjenestelisten til systemkontrolleren som ved hjelp av GUI-metoden "Display(DataToGUI) viser listen på skjerm. Ansatt velger riktig tjeneste fra liste og overfører valget til systemkontrolleren ved hjelp av metoden "set_DataFromGUI()". Get_tjeneste_from_list(DataFromGUI) overfører informasjon om valgt tjeneste til "Tilleggstjenester_register" som henter ut samsvarende informasjon fra "tjenesteliste" og overfører til "Tilleggstjeneste"-objektet ved hjelp av "set_tilleggstjeneste()". Metoden WriteOrdrelinjeToArray() overfører Ordrelinje-objektet til arrayet "Ordrelinjer". Hvis ansatt ønsker å legge inn flere tilleggstjenester på samme ordre loopes siste avsnitt (fra opprettelse av ordrelinje).

Når alle tjenester er lagt inn i ordrelinjer kan ordren sluttføres. Ordre-objektet utfører metoden "Sluttfør_ordre()" på seg selv. Denne metoden har ingen reel funksjonalitet innebygd, men det kan tenke seg at eksport til økonomi-system, samt lagring i database ville foregå her, men dette er ting vi ikke går i dybden på i oppgaven. Avslutningsvis sender ordre-objektet en melding til systemkontroller "Set_DataToGUI("Din Ordre er opprettet") til systemkontroller, som viderefører denne til GUI ved hjelp av Display(DataToGUI).

Figur 4.2.2.3 – Sekvensdiagram ”opprett bestilling – normal hendelsesflyt

Informasjon om diagrammet ”Opprett ny bestilling – avvikende hendelsesflyt:”

(Denne beskrivelsen er ment som et supplement til sekvensdiagrammet i tilfellet dataflyten oppleves som uklar)

Ordre-objektet inneholder et Objekt av type ordrelinje. Dette oppretter igjen et båt-objekt og det opprettes et Båt_register-objekt. Sistnevnte inneholder hele båt-listen i et array. Ved hjelp av "set_DataToGUI(båtliste) overføres båt-listen til systemkontrolleren som ved hjelp av GUI-metoden "Display(DataToGUI) viser båt-listen på skjerm. Ansatt velger riktig kunde fra liste og overfører valget til systemkontrolleren ved hjelp av metoden "set_DataFromGUI()". Get_båt_from_list(DataFromGUI) overfører informasjon om valgt båt til båtregisteret som henter ut samsvarende informasjon fra "båtliste" og overfører til "Båt"-objektet ved hjelp av "set_båt()". Metoden WriteOrdrelinjeToArray() overfører Ordrelinje-objektet til arrayet "Ordrelinjer". Denne metoden inneholder logikk som kontrollerer valgt båts tilgjengelighet i tidsrommet i kalender-objekt (Vi har av tidsmessige årsaker ikke greid å produsere denne funksjonalitetens logikk, så vi gjør en antakelse her, og antar at metoden har mulighet til å sjekke dette). Som i dette tilfellet er båten opptatt på valgte tidspunkt. Dette fører til at ordre-klassen sender en melding til systemkontroller: "Set_DataToGUI("Valgt båt er ikke tilgjengelig på valgte tidspunkt, vennligst forsøk på nytt")". Melding overføres så til GUI ved hjelp av Metoden Display(DataToGUI). Etter utsendt melding ødelegges "Ordre"-objektet. Denne avslutningen er veldig enkel, og neppe så populær hos brukerne som må begynne for fra med å legge inn kunde på nytt, men for å demonstrere systemflyt gjør den jobben.

Figur 4.2.2.4 – Sekvensdiagram ”opprett bestilling – avvikende hendelsesflyt

4.3 Logisk arkitektur

Vi foreslår å benytte en trelags-arkitektur av typen Model-View-Controller (MVC) i løsningen vi utvikler. Dette er en mye brukt arkitektur som isolerer brukergrensesnitt fra applikasjons-logikk ved introduksjon av et kontroller-lag. MVC tilbyr lav kopling mellom lagene. Dette medfører at en systemkomponent f.eks brukergrensesnitt kan byttes ut uten at det vil få større innvirkning på systemet generelt.

Modell-laget tar seg av applikasjonens logikk samt lagring av data (selv om vi ikke har utdypet det siste spesielt mye i dette prosjektet) og vil inneholde alle de forskjellige objektene som brukes av applikasjonen under kjøring

View-laget inneholder brukergrensesnitt. Bruker kan manipulere grensesnitt som genererer input events til kontroller

Kontroller-laget tar i mot input fra brukergrensesnitt og genererer meldinger til modell-laget som utfører handlinger på input. Resultater returneres (når påkrevd) til systemkontroller som genererer output til view.

Vi ser det som hensiktsmessig å utvikle applikasjonen som en Web-applikasjon, der view er i form av et HTML-web-interface, og kontroller og modell er plassert server-side og implementert i for eksempel PHP.

Figur 4.3 – Logisk arkitektur – Model View Controller

4.4 Brukergrensesnitt

Her presenterer vi det forslaget vi har utarbeidet til brukergrensesnitt for løsningen. Vi ser for oss et stilrent og luftig web-grensesnitt som skal være behagelig å bruke for de ansatte. Vi presenterer to skjermbilder, et for siden der den ansatte kan legge til ny kunde i systemet, og et for siden der den ansatte legger inn en ny bestilling.

Først vises siden for registrering av ny kunde. Siden består av tekstfelt som må fylles ut og som avsluttes med å trykke lagre knappen. I det dynamiske feltet under knappen vil det komme opp tekst med status på om lagringen var vellykket eller ikke.

På siden etter vises ordresiden hvor man setter opp bestilling etter forespørsel fra kunden som ønsker å leie båt. Før man går videre må all kundeinformasjon ligge i systemet. På ordresiden finnes en kalender for å registrere sted, dato og tidsrom. Deretter kan man velge båt og tilleggstjenester.

Figur 4.4.1 – Forslag til brukergrensesnitt – registrering av kunde.

Figur 4.4.2 – Forslag til brukergrensesnitt – opprette bestilling.

5 Vurdering

5.1 Vurdering av foreslått løsning

Forslag til løsningen vi har utviklet for vår kunde, Oslo Båtutleie, er basert på identifisering av krav ved hjelp av en kravanalyse. Krav til løsning har blitt utdypet ved hjelp av Use Case-modellering og har resultert i en kravspesifikasjon. Etter hvert som arbeidet har gått fremover og vi har tilegnet oss bedre forståelse av kundens domene og behov har kravspesifikasjon blitt videre detaljert og vi har bygget videre på Use Case-modell for å sørge for krav til løsning gjenspeiles.

Delvis på grunn av tidsmessige årsaker og dels på grunn av oppgavens spesifisering har vi på et tidlig tidspunkt satt fokus på to brukstilfeller av løsningen, hvordan man legger inn en ny kunde i systemet, og hvordan man oppretter en bestilling. Disse tilfellene har videre blitt detaljert godt i aktivitetsdiagrammer og sekvensdiagrammer. Klassediagram for løsningen , og til en viss grad domenemodell er fokusert rundt disse brukstilfellene, og funksjonalitet som ikke er relatert til dette er i stor grad ikke tatt med i modellene.

På grunnlag av dette forekommer det et ganske stort sprik i mellom hva som sånn sett er lovet kunden (i form av kravspesifikasjon og overordnet Use Case-diagram) og hva vi faktisk har designet og modellert i prosjektet. Som eksempel på dette har vi i kravspesifikasjon krav til at kunden skal kunne sende og motta e-post, administrator skal kunne legge til/fjerne ansatte osv. Innledningsvis (under målsetning) har vi til og med gått ut så kraftig som å si at ”Datasystemet skal være en enhetlig applikasjon som erstatter alle de separate programmene som bedriften per dags dato er avhengig av. Dette dreier seg om programvare for tekstredigering, regneark, kalender, Epost, kontakter.”

Det er liten tvil om at vi har tatt oss litt vann over hodet innledningsvis. Gruppens prosjektleder er ganske glad for at dette er et studentprosjekt, og ikke en reel jobbsituasjon. Det vil nok kreves et ukjent antall iterasjoner og inkrementeringer før all denne funksjonaliteten er i nærheten av å være på plass. Når dette er sagt synes vi at design og modellering av den funksjonaliteten som vi har vektlagt til nå er av god kvalitet og vil kunne være et godt grunnlag for implementering. Det er sånn sett i tråd med utviklingsmodellen å velge ut et knippe av de viktigste funksjonene først, for så å legge til mer funksjonalitet gradvis.

5.2 vurdering av valgt utviklingsmodell

Til dette prosjektet valgte vi å gå for prosessmodellen Unified Process (UP) etter krav fra oppdragsgiver. Vi tilpasset UP modellen med økt fokus på planlegging, krav og analyse/design. Grunnen til dette kom ut i fra kravene i oppgaven hvor vi tolket det til at implementasjon, testing og idriftsettelse ikke skulle prioriteres fordi prosjektet ikke skal lede til et fysisk sluttprodukt.

For oss var det viktig å basere prosjektet på en modell som tillater skalering etter vårt behov og hvor vi kan bestemme hvilke områder som vi ønsker å fokusere på, uten å ødelegge prosjektmodellens helhetsfølelse.

Vår vurdering av denne prosjektmodellen er at den bidrar til å skape en klar fremgangsplan i form av de ulike fasene. Fasene skaper naturlige grenser og hjelper oss definere hvor vi befinner oss og hva som blir den videre fremgangen. Samtidig er det noen utfordringer knyttet til det faktum at ingen av fasene utgjør definitive frister, men heller er veiledende for oss som ender med å sette dem. Det betyr at vi har muligheten til å foreta endringer i ettertid selv om disse fasene allerede er utført. UP er iterativt, og innehar en høy grad av fleksibilitet når det kommer til å gå tilbake å foreta endringer i ettertid. Det er utviklerne og kunden som setter grensene for hvor lenge en kan gå tilbake å foreta endringer på allerede utførte delprodukter. Eksempelvis kan utvikleren legge til nye krav underveis eller endre på eksisterende krav skulle det vise seg fornuftig lengre ut i prosessen.

Det er både fordeler og ulemper med denne prosjektmodellen. Fordelen er at det er gode muligheter til å endre prosjektet underveis i utviklingen dersom krav forandrer seg og svakheter blir oppdaget. I tillegg er modellen skalerbar og lett å tilpasse, så små prosjekter av typen vi har jobbet med her behøver ikke inneholde alle disipliner og artefakter som større prosjekter ville påkrevd. En ulempe kan være at det kan bli vanskeligere for utvikleren og avgjøre når prosjektet har nådd sine mål ettersom disse ofte blir utsatt for forandringer. Hvis interne frister blir endret for ofte fordi en går tilbake for å gjøre endringer i prosessene, vil dette kunne forsinke hele prosjektet. Det vil også føre til at dokumentasjonen blir unødvendig omfattende og komplisert.

Et alternativ som kunne egne seg for denne type prosjektarbeid, ville være en type lettvekts-modell (agile process). For vårt prosjekt kunne en av disse modellene hvert et godt alternativ grunnet valgfriheten som preger disse modellene. Muligheten for å prioritere samhandling mellom bruker og system vektlegges fremfor verktøy og prosesser i agile. Denne tankegangen tror vi kunne ha bidratt til å skape et bedre sluttprodukt ettersom interaksjonen mellom bruker og system kunne prioriteres fremfor rent tekniske detaljer. Å la sluttbruker ha enda mer påvirkningsmuligheter under utvikling er noe vi har tro på kan lede til et enda bedre sluttprodukt. Samtidig kan det ha en negativ effekt ved at brukere ikke alltid er klar over deres behov og utvikleren er bedre skikket til å avgjøre hva sluttbrukerne trenger ettersom de ofte over- eller undervurderer behovene sine.

Lettvekts-metoder generelt gjør også et poeng ut av at dokumentasjon gjør størst nytte kun i de tilfellene hvor utviklerne selv ser den nyttig. Når vi sammenligner med UP modellen hvor en god del av tiden har gått til dokumentasjon, er inntrykket vi sitter igjen med at mindre tid brukt på å dokumentere kunne ha frigjort mer tid til å bruke på utvikling og analyse. Mangel på dokumentasjon kan derimot være negativt når prosjektene er svært omfattende spesielt der strukturer og innhold i systemene er for kompliserte til at man klarer å holde oversikt over hva som faktisk skal endres eller implementeres. Dokumentasjon er også viktig for å holde oversikt over arbeidsoppgavene til utviklerne.

Uten å gå nærmere inn på en spesifikk lettvekts-metode velger gruppen å konkludere med at det var et fornuftig valg å holde oss til Unified process, da denne tilbyr god balanse mellom en fastsatt prosjektgjennomføring og muligheten til å foreta eventuelle endringer underveis. UP gir stabilitet og fleksibilitet til systemutvikling. I tillegg er modellen såpass skalerbar at vi i virkeligheten snakker om en ganske smidig og lett UP som har blitt brukt i dette prosjektet.

5.3 Vurdering av eget prosjektarbeid

Mange ganger har arbeidsoppgaver blitt noe skjevt fordelt, slik at noen gruppemedlemmer til tider har hatt mer å gjøre enn andre i forhold til interne leveringer. Dette har justert seg gjennom hele prosjektet da vi har etterstrebet at alle i gruppen skal bidra likt. Vi har alltid hatt åpen dialog mellom gruppemedlemmene, alle har blitt hørt og problemstillinger som angår arbeidsoppgaver eller annet har blitt drøftet på gruppemøtene. Vi har hatt møter mandager og onsdager. Det har vært bra oppmøte på gruppemøtene og vi har sjelden hatt fravær på grunn av sykdom eller lignende. De gangene noen har vært syke har alle gruppemedlemmer allikevel hatt tilgang til det arbeidet som har blitt gjort på en fellesmappe i Dropbox .

Alle gruppemedlemmer har vært åpne for å bli kontaktet hvis det var noe man lurte på i forhold til de individuelle arbeidsoppgavene vi fikk tildelt på gruppemøtene, dersom man ikke kunne stille på gruppemøte på grunn av sykdom eller annet. Vi har på gruppemøtene hatt gjennomgang av oppgavene vi har holdt på med for å holde en høy kvalitet, andre gruppemedlemmer kan komme med innspill til forbedringer og enkelt kunne ta over arbeidsoppgaver dersom noen skulle bli syk.

Vi har også vært flinke med å få booket rom i god tid slik at vi har kunne samle oss på et grupperom for å drøfte oppgaver og problemstillinger, i forhold til innleveringer og interne frister, samt å tildele nye oppgaver og komme med innspill til endringer og forbedringer.

Når det gjelder prosjektoppgaven tok det tid før vi kom i gang, mye fordi vi slet med å sette oss inn i hva oppgaven gikk ut på og hva som faktisk skulle leveres inn.

Det at vi selv skulle finne en oppgave opplevdes vanskelig , vi brukte i overkant mye tid på å finne en oppdragsgiver og et mål for prosjektet.

Vi mener at vi har ligget litt for tett opp mot leveringsfristene og hvis vi hadde vært litt flinkere til å strukturere arbeidet, kunne vi fått en større buffer opp mot leveringsdato. Vi har hatt egne interne frister men ofte ble vi ikke helt ferdige med oppgavene som var satt internt i gruppen. Dette skyldes delvis at vi opplevde mye ”trykk” på datalaben og at vi ikke fikk svar når vi ville og måtte vente med å få hjelp til neste datalab.

Vi har også feilberegnet hvor lang tid det ville ta å lage ferdig diagrammene og få dem godkjent. Det har vanskeligere enn vi trodde og vi har hatt mange endringer på vei mot mål.

Vi har forsøkt så godt vi kan å tenke Unified Process, følge iterasjoner og strukturere arbeidet i henhold til innholdet i prosjektplanen. Vi føler at det tidvis har vært vanskelig å relatere det arbeidet vi har gjort til UP. Det har nok vært lettest med de forskjellige diagrammene og modellene vi har laget som i høy grad har blitt utviklet iterativt, men mange andre aspekter av utviklingsmodellen har nok kommet litt i bakgrunnen. Et eksempel på dette er risikohåndtering som burde blitt gjort bedre. Vi har ”tidsmangel” som er et punkt i vår ”risikoanalyse” (prosjektplan) med en plan for hvordan dette skal unngås/løses. Her har vi i praksis ikke vært gode nok til å identifisere på et tidlig tidspunkt at vi ligger etter skjema i forhold til innleveringer. Dette har fått som konsekvens at vi mer enn en gang har sittet lange dager når det nærmer seg frister. Heldigvis har vi alltid greid å holde fristene, men vi har gjort det vanskelig for oss selv. Det positive er selvsagt at vi skal lære noe av dette prosjektet, og dette bidrar i høy grad til at vi nå forstår viktigheten av å vurdere risiko fortløpende og gjøre nødvendige grep på et tidlig tidspunkt.

6 Konklusjon

Oppsummering av hovedpunkter i arbeidet.

Vi har i dette prosjektet innledningsvis skaffet oss en oppdragsgiver, Oslo Båtutleie Vi har kartlagt oppdragsgivers behov og har satt oss som mål å utvikle en kontor og booking-løsning basert på de krav vi har kommet frem til ved hjelp av en kravanalyse. Vi har benyttet oss av en rekke verktøy og metoder for å utdype krav og lage et forslag til design på grunnlag av dette. Unified process har blitt valgt som utviklingsmodell, og vi har generert en rekke artefakter, blant annet Use Case-modeller, aktivitetsdiagram, sekvensdiagram, domenemodell, klassediagram, forslag til logisk arkitektur og forslag til brukergrensesnitt.

Vi har nok tatt oss litt vann over hodet innledningsvis da vi hadde satt oss som mål å designe et komplett kontor og booking-system for kunden. Systemet skulle inneholde ordinære kontorfunksjoner som tekstbehandling, epost og mye annet fint, i tillegg til en komplett booking-løsning for utleie av kundens båter. Dette var nok veldig naivt av oss, men vi begrunner det med at vi når vi startet på prosjektet hadde veldig lite forståelse av kompleksiteten forbundet med systemutvikling. Underveis i prosjektet har vi i større og større grad fått denne forståelsen, og skulle vi begynt på nytt ville vi helt sikkert satt oss en mye enklere målsetning, og laget en enklere løsning.

Oppgaven er også lagt opp til å fokusere mye av arbeidet rundt to forskjellige brukstilfeller. Vi har stort sett forholdt oss til dette gjennom prosjektet, og det meste av modellering og design er begrenset til disse brukstilfellene.

Ut i fra dette kan vi ikke si at prosjektets målsetning er nådd. Vi har allikevel fullført viktige komponenter i systemet, og kvaliteten på disse er vi fornøyd med.

Vi har kommet i mål med prosjektet innen fristene som er satt. Prosjektplanen som ligger til grunn for arbeidet har vi forsøkt å følge så godt det har latt seg gjøre, men vi opplever at det har vært vanskelig å beregne arbeidsmengde, og veldig ofte har vi kommet litt for tett inn på fristene, og har fått vel mye å gjøre de siste dagene.

Vi har opplevd det som vanskelig å sette arbeidet inn i iterasjoner i praksis, og vi opplever at dette har sklidd ut. Vi har allikevel forsøkt å gjøre dette etter boken, med evaluering av iterasjon etc. før neste iterasjon påbegynnes. Diagrammer og modeller har blitt utarbeidet iterativt, men vi har ikke helt greid å holde en skikkelig struktur rundt dette.

Det har i prosjektplan blitt satt opp et budsjett for prosjektet vårt. Estimert kostnad for hele prosjektperioden ble satt til 125.840 kr. Etter føring av timer underveis i prosjektet har vi ved prosjektslutt utført nye beregninger. Den faktiske kostnaden for prosjektet har landet på 90.470 kr. Vi ligger altså godt under budsjett på prosjektet. Dette er hovedsaklig grunnet mindre timebruk en antatt, spesielt innledningsvis i prosjektet. Med tanke på at vi kun har levert deler av det vi har forespeilet kunden i prosjektet antar vi at de er glade for å høre at det blir billigere enn antatt. Hvis vi antar at prosjektet skal føres videre og ferdigutvikles som beskrevet i prosjektets mål, ville prosjektet overskredet budsjettet i en så stor grad det antakelig hadde blitt advokat-mat.

Forslag til forbedringer av prosjektets resultater og kvalitet i gjennomføringen.

Vi har altså ikke klart å levere det produktet vi satt oss som mål innledningsvis i prosjektet. De komponentene vi har levert er vi allikevel fornøyd med. Vi har forsøkt å detaljere både klassediagram og sekvensdiagram med metoder for kommunikasjon så godt og detaljert det lar seg gjøre. Ingen av gruppemedlemmene er veldig erfarne innen ”programmerings-tankegang” da vi har begrenset med undervisning i dette i løp av vårt studieløp. Vi antar det ville vært rom for forbedring her, men det innebærer at vi tilegner oss mer informasjon om dette fagfeltet.

Vi har i prosjektet undervurdert hvor komplekst og avansert modellering av systemer er, og hadde vi visst det vi vet nå ville vi nok ha prioritert dette kraftigere, tidligere i prosjektet.

For å oppsummere sitter vi igjen med følelsen av at denne oppgaven har vært utrolig lærerik. Vi har i løpet av prosjektet tilegnet oss erfaringer om prosjektarbeid, prosjektstyring og modellering og en rekke andre felt som vi på forhånd kunne svært lite om. Vi har forstått kompleksiteten av et slikt prosjekt, og ser verdien av å støtte oss på en utviklingsmodell for å strukturere arbeidet.

Det er hovedsakelig den informasjonen vi har tilegnet oss i løpet av prosjektet som kan være nøkkelen til forbedring av resultatene. Skulle vi gjort prosjektet om igjen ville vi nok hatt større fokus på å levere systemkritiske komponenter tidlig i prosjektet og bruke mindre krefter på dokumentasjon. I tillegg måtte vi nok ut i fra prosjektets tidsmessige begrensninger ha begrenset omfanget av den løsningen vi lovet kunden.

7 Litteraturliste

Kilder:

Illustrasjon 2.1.0: Kilde: Wikipedia - http://en.wikipedia.org/wiki/Unified_Process (23.09.2011)

Thor E. Hasle – “Systemutvikling – Applikasjoner og Databaser” – Cappelen 2008

Craig Larman – “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3^rd edition” - Addison Wesley Professional 2004