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åtservice’s 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). Denne modellen består av fire faser: idéfasen, utdypningsfasen, konstruksjonsfasen, og overgangsfasen.

I motsetning til den tradisjonelle fossefallsmetoden gir UP 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. UP er iterativ og lar oss utvikle løsninger et steg om gangen, for så å kunne gå tilbake å revurdere og forfine det vi allerede har gjort. 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.

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 tilgjengelige 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 ber om bekreftelse fra ansatt om å lagre informasjon 9. Ansatt godkjenner bekreftelse om lagring. 10. 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 går tilbake til punkt 3 i normalhendelsesflyten.
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. 4. Systemet ber ansatt om bekreftelse på lagring . 5. Ansatt bekrefter lagring. 6. 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.

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 bestillingsklassen når en bestilling opprettes. Ut i fra en bestilling kan det genereres et tilbud til kunde, og når tilbudet er godkjent genereres en avtale. Alle registreringer skal merkes med ansatt som har utført registrering.

Domenemodell vil detaljeres og rettes i forbindelse med fremtidige iterasjoner.

3.3 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.3.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.3.2 – aktivitetsdiagram – ”opprett ny bestilling”

4 Design

4.1 Klassediagram

Klassediagram blir presentert ved neste innlevering

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 brukstilfellet ”Legg til ny kunde”, også presentert som detaljert Use Case i kapittel 3.2.2. Brukstilfellet 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.

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. Kunderegisteret ber om bekreftelse på oppføringen.

5. Den ansatte gir bekreftelse på oppføringen.

6. Ny kunde blir opprettet.

7. Den ansatte får bekreftelse på at ny kunde er oppført.

Figur 4.2.1 – sekvensdiagram blackbox – opprett ny kunde – normal hendelsesflyt

Figur 4.2.2 - – sekvensdiagram – opprett ny kunde – normal hendelsesflyt

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

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

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

4. Den ansatte registrerer informasjonen om kunden.

5. Kunderegisteret sier at kunden allerede finnes i registeret.

6. Den ansatte avbryter registreringen.

Figur 4.2.3 – sekvensdiagram blackbox – opprett ny kunde – avvikende hendelsesflyt

Figur 4.2.4 – sekvensdiagram – opprett ny kunde – avvikende hendelsesflyt

4.3 Logisk arkitektur

Logisk arkitektur blir presentert ved neste innlevering.

4.4 Brukergrensesnitt

Brukergrensesnitt blir presentert ved neste innlevering

5 Vurdering

6 Konklusjon

Oppsummering av hovedpunkter i arbeidet. Ble målsetning oppnådd? Ble prosjektet gjennomført etter plan og innen budsjett?

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

7 Litteraturliste

Kilder:

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