Avdeling for ingeniørutdanning Høgskolen i Oslo Prosjektrapport Systemutvikling (lo138a) Høst 2010 Taxisentral Gruppe 19 Prosjekthjemmeside: http://gruppe19.lmdahl.no/ Forfattere: Larsen, Mads s156151 Hegge, Magnus s153549 Bergan, Bjørn s161593 Baisa, Abdi s156140 Dato: 22.11.2010
Sammendrag Denne rapporten beskriver et prosjekt i faget systemutvikling på HiO. Prosjektet ble gjennomført høsten 2010 av en gruppe bestående av Magnus Dahl Hegge, Abdi Baisa, Mads Larsen og Bjørn Bergan. Rapporten inneholder dokumentasjon og diagrammer som beskriver planleggingsfasen av utviklingen av et taxisentralsystem. Videre arbeid med systemet etter planleggingsfasen er ikke beskrevet her da dette ikke var en del av prosjektoppgaven.
Innhold Sammendrag Innhold Versjonslogg 1 Introduksjon 1.1 Bakgrunn 1.2 Mål for Prosjektet 1.3 Omfang av løsning 1.4 Suksesskriteria 1.5 Antagelser 2 Tilpasning av utviklingsmodell 2.1 Beskrivelse av utviklingsmodell 2.2 Begrunnelse for tilpasninger 3 Analyse 3.1 Kravspesifikasjon 3.2 UseCase-modell 3.2.1 UseCase-diagram 3.2.2 Detaljerte UseCase beskrivelser 3.3 Domenemodell 3.4 Aktivitetsdiagram 4 Design 4.1 Klassediagram 4.2 Sekvensdiagram Normalflyt Avvik 4.3 Logisk arkitektur 4.4 Brukergrensesnitt 5 Vurdering 5.1 Vurdering av foreslått løsning 5.2 Vurdering av valgt utviklingsmodell 5.3 Vurdering av eget prosjektarbeid 6 Konklusjon 7 Litteraturliste
Versjonslogg Versjon Dato Forfatter(e) Beskrivelse av versjon 1.0 22.11.10 Larsen, Mads s156151 Hegge, Magnus s153549 Bergan, Bjørn s161593 Baisa, Abdi s156140 Prosjektrapport er ferdig.
1 Introduksjon 1.1 Bakgrunn Problemstillingen, Hvordan planlegge utviklingen av et Taxisentralsystem? ble valgt fordi vi ville ha et realistisk mål for prosjektet. En taxisentral er avhengig av mange forskjellige elementer, som alle er nødvendige for å nå ett enkelt mål: Skaffe kunden transport fra A til B. For å nå dette enkle målet, må systemet være så automatisert som mulig og være enkelt for brukeren å forholde seg til. Selv om systemet er enkelt, ser vi for oss mange utfordringer som denne oppgaven vil frembringe, noe som vil gi oss nødvendig erfaring til en forhåpentligvis lang karriere innenfor IT. Da taxisystemer i dag hovedsakelig består av en kunde som ringer til en sentral, en ansatt på sentralen som tar i mot bestillingen og ringer en taxi for å videreformidle denne, ser vi for oss en stor forbedring hvis man kunne automatisere hele eller deler av denne prosessen. Dette er basert på vår egen erfaring med taxisentraler, vi har som de fleste andre hatt store problemer med å skaffe oss taxi til tider, både fordi man ikke får svar på taxisentralen og fordi man opplever at hele taxisystemet arbeider for sakte. Med vårt system vil alle som ønsker det kunne bestille en taxi ved hjelp av forskjellige medier uten å prate med en ansatt på taxisentralen. Dette mener vi vil kunne forhindre problemene med at man ikke får kontakt med taxisentralen i perioder med stor etterspørsel etter taxi. Vårt system har mulighet til å gjennomføre bestillinger selv. Vi anbefaler allikevel at ansatte er tilgjengelige for å ta i mot bestillinger for de som ønsker å prate med en virkelig person eller for å diskutere problemer kunder har hatt eller lignende. Vi ser for oss at alle taxiene i bedriften vil være utstyrt med en GPS og en nettverksforbindelse til sentralen. Taxiene vil da sende sin posisjon hvert minutt slik at sentralen har et godt bilde av hvor alle bilene befinner seg. I sentralen skal det være et kartsystem som regner ut kjøredistanse mellom kunder og taxi, og finner taxien med kortest kjøredistanse / tid til kunde. Ved å automatisk velge den ledige taxien som er nærmest kundens posisjon ved hjelp av GPS vil vi også tro at en taxi bedrift vil kunne spare penger på bensinutgifter.
1.2 Mål for Prosjektet 1. Systemet skal ha mulighet til å utføre ca. 90 % av sentralens oppgaver automatisk. a. Systemet skal kunne ta i mot bestilling via telefon, SMS, e-post og internett. b. Systemet skal lagre bestillinger automatisk innen 1 sekund etter de mottas. Bestillinger lagres i 24timer etter taxituren er over. c. Systemet skal lokalisere nærmeste ledige taxi av riktig type (f.eks. maxitaxi) ut i fra en database som inneholder informasjon om bilene og GPS. Søket starter med et område på 1 km². Hvis ingen ledige taxier blir funnet utvides søket med 2 km² per forsøk til en taxi blir funnet. Et forsøk skal ikke ta mer enn 5 sekunder. Hvis søket tar lenger tid enn 20 sekunder vil kunden få beskjed om dette per telefon, SMS eller email, i forhold til hvordan taxien ble bestilt. d. Systemet skal videresende bestillinger til taxi innen 2 sekunder etter de har kommet inn og blitt registrert. e. Systemet skal sende ordrebekreftelse til kunde i løpet av 5 sekunder etter sjåføren har godtatt oppdraget. f. Det skal være mulig å utføre systemets oppgaver manuelt om det er behov for dette. g. En kundebehandlingsavdeling holdes åpen for å snakke med kunder om klager o.l. og for å ta imot bestillinger over tlf. h. Når systemet mottar en avbestilling vil denne automatisk sendes til gjeldene taxi i løpet av 3 sekunder. i. Systemet skal ha mulighet til å lagre reservasjoner. Dette vil gjøre det mulig for en kunde å bestille en taxi til senere. 2. Systemet skal være enkelt å bruke og ha kort opplæringstid a. Grensesnittet skal ha svært enkelt og oversiktlig design, med ikke flere en 3 alternativer per oppgave og en lineær fremgangsmåte. Ved å holde systemets design relativt likt det de fleste er vant til (Windows o.l.) vil grensesnittet ikke virke fremmed, og personer med grunnleggende datakunnskaper vil forstå det raskere.
3. Systemet vil ha rask behandlingstid, være svært pålitelig og ha lave krav til hardware a. Da det er en liten mengde informasjon som skal sendes fra kunde til sentral og videre til taxi (ca. 50-100kb) vil dette skje i løpet av få sekunder. Maks 10. b. Dersom sjåføren ikke svarer på bestillingen i løpet av 1 minutt vil bestillingen avbrytes og sendes til neste bil. c. Programmet har lave krav til minnestørrelse, da det vil ha et ganske enkelt GUI. På klientmaskiner vil programmet ta opp mellom 5 og 10 MB RAM, og installasjonen tar ca. 200MB. 4. Prosjektet skal være ferdig utviklet og klart til presentasjon 14.12.2010. a. Alle aspekter av systemet er ferdig planlagt. b. Prosjektrapport er ferdig skrevet.
1.3 Omfang av løsning Et taxisentralsystem har mange forskjellige aspekter som ikke bare omfatter data. En fungerende telefonsentral vil være nødvendig, som kan rute samtaler fra eventuelle kunder til første ledige taxi, eller til et kundesenter. For at samtalen skal bli rutet til første ledige taxi, er det et par kriterier som må oppfylles: 1. Taxien må være innenfor en fornuftig avstand fra kunden, slik at kunden ikke må vente på at sjåføren f.eks. skal kjøre igjennom Oslo by. 2. Taxien må ha en måte å sende et klar signal, eller opptatt signal, til sentralen på for å gi beskjed om at den er ledig. Siden taxifirmaer har sjåfører i feltet til alle døgnets tider, er man avhengig av et kundesenter som er døgnåpent alle dager i uken. Dette er for at kunder aldri skal måtte vente på at en bil blir ledig for å få lagt inn sin bestilling dersom man ikke ønsker å gjennomføre en automatisk bestilling. Det viktigste på dette punktet er å ha et effektivt og godt bemannet kundesenter, men det er ikke noe som vi tar med i denne oppgaven, da vi vil fokusere på kommunikasjonen biler imellom, sentral til bil, bil til sentral og kunde til bil. Samtalene som kommer inn til kundesentralen vil ikke være nødvendig for oss å håndtere. Prosjektets omfang blir da alle elementer som skal fungere sammen for at en kunde skal komme seg inn i baksetet på taxien, med unntak av selve samtalen kunden utfører med sentral, eller bil.
1.4 Suksesskriteria Samarbeid For å gjennomføre et prosjekt så omfattende og langvarig som dette sammen med andre er godt samarbeid viktig. Samarbeid mellom gruppemedlemmene har fungert godt på tidligere prosjekter og det er derfor lite sannsynlig at problemer oppstår, men usannsynlige problemer burde også inkluderes i en risikoplan. Planlegging Planlegging av prosjekter er svært viktig. Uten en god fremdriftsplan vil arbeidet ofte bli gjort i siste liten og det vil gå ut over kvaliteten. God timeplan God planlegging inneholder gjerne en detaljert timeplan som beskriver hva gruppemedlemmene skal jobbe med. God risikoplan Når man jobber med et prosjekt over flere uker og måneder er det viktig å ha en oversikt over mulige problemer som kan oppstå og løsninger for disse. Gruppa burde være forberedt på både svært sannsynlige problemer og høyst usannsynlige problemer. Online tilgjengelighet Svært mye av arbeidet som blir gjort gjøres på internett. Rapport, notater o.l. ligger på nettet og innleveringer skjer på internett. Problemer som kan oppstå i sammenheng med dette burde være en del av risikoplanen.
1.5 Antagelser Ut ifra hva som er oppført under omfang, er det noen antakelser som vi må ta. Hvis vi skal planlegge et fullt fungerende taxisentral system vil det være alt for mange elementer å håndtere for gruppen vår alene. Som nevnt tidligere er det snakk om en fungerende telefonsentral, et døgnåpent hovedkontor og i de fleste tilfeller en fungerende SMS sentral. Dette vil gjøre oppgaven særdeles tung hvis alt skal bli implementert. Det vi vil fokusere på er selve kommunikasjonssystemet mellom hovedkontor, kunder og taxier. Det vil da være kommunikasjon direkte mellom kunder og taxi som står i fokus, mens samtalene mellom kunder og sentral ikke vil være vesentlige, da bestillingen uansett vil bli sendt til nærmeste ledige taxi fra sentralen. En annet aspekt vi ikke vil ta tak i er betalingssystemet. I prinsippet er ikke betalingen viktig for denne rapporten, da det er et separat system som er koblet opp mot BBS og ikke sentralen. Det vil si, i prinsippet betaler alle kunder kontant. Vi tar utgangspunkt i et taxifirma med en betraktelig mengde sjåfører og biler, som vil kunne dekke en mellomstor by. Dette vil kreve et enkelt kommunikasjonsverktøy mellom biler og sentral, slik at meldinger, og oppdatert status, kan bli sendt fram og tilbake. Et vanlig taxiselskap har gjerne en hjemmeside, og vi tar derfor utgangspunkt i at det allerede finnes en fullt fungerende hjemmeside som oppfyller de kravene vi ønsker at den skal ha. Hvis en kunde bestiller fra hjemmesiden vil det i prinsippet være helt likt som om kunden har ringt inn til hovedkontoret. Derfor er det ikke nødvendig for oss å utvikle denne. Som nevnt tidligere vil uansett bestillingen bli sendt videre til en taxi fra sentralen.
2 Tilpasning av utviklingsmodell 2.1 Beskrivelse av utviklingsmodell Vi har valgt å benytte en tilpasset versjon av UP som systemutviklingsmodell. Denne modellen setter et agilt rammeverk som lett kan tilpasses, og begrenses, ved de krav som settes av målet. Modellen er en iterativ og inkrementell utviklingsprosess. Fasene (ide, utdypning, konstruksjon og overgang) gjennomgår en rekke gjentakelser. Hver iterasjon vil gi et intervall som gir en forbedring, eller utvidet versjon, av systemets funksjonalitet satt mot den forrige utgaven. Dette systemet skal ikke implementeres, så bredden av disipliner vil være begrenset. Krav og design, gjennomgå flere gjentakelser etter hvert som modellen utvikles. Prosessen er UseCasedrevet så det er de kommende brukerne av det ferdige resultatet som står i sentrum. Designet av programmet og prosessene i hele systemet skal basere seg på hvordan det vil komme bruker til nytte. 2.2 Begrunnelse for tilpasninger Opplagte tilpasninger vi vil gjøre er å fjerne implementering, drifting o.l. da dette ikke er en del av vår prosjektoppgave. De ulike fasene: Idefasen: I denne fasen får vi en oversikt over hva hovedmål, krav og omfanget til prosjektet skal være. Vi blir enige om hvordan vi skal jobbe med prosjektet, og identifiserer eventuelle risiki. Andre elementer inneholder, men er ikke begrenset til, lønnsomhetsanalyse, kostnadsanalyse, med fokus på problemforståelse og prosjektbeskrivelse, som skal samles til 1. iterasjon av oppgaven. Utdypningsfasen: I denne fasen tar vi en grundigere gjennomgang av prosjektet etter å ha fått tilbakemelding etter 1. iterasjon. Her skal kravspesifikasjonene, målene og omfanget korrelere slik at det kan utvikles en basis, men tilstrekkelig god, arkitektur for hvordan systemet skal utformes. Risiki er identifisert og håndtert. Hovedfokus vil være å ha en klar, forståelig,
fremgangsmåte for hvordan prosjektet skal løses, representert ved hjelp av UseCases, sekvens-, domene- og klassediagram. Fasen vil bestå av flere iterasjoner, og vil granskes nøye før vi beveger oss videre til neste fase. Konstruksjonsfasen: I denne fasen vil det jobbes med analyse og design av systemet i henhold til omfang, krav og GUI m.m. Dette skal representeres ved hjelp av skisser og ferdigstilte diagrammer. I denne fasen skal alle spesifikasjoner være ferdigstilt, og point of no return skal være nådd etter siste iterasjon. I teorien skal programmeringen også være ferdigstilt, men det vil ikke bli utført noe programmering i denne oppgaven. Overgangsfasen: Vi kommer ikke til å ta med implementering og drifting som en del av utviklingsprosessen, derfor er overgangsfasen noe irrelevant for oss. Innleveringsiterasjoner: Dette er en oversikt over innleveringer og endringene vi gjorde etter disse. De inneholder ikke de interne iterasjonene av oppgaven som vi selv har hatt før innleveringene ble gjennomført. F.eks. forskjellige versjoner av use-cases osv. 1. Iterasjon: Vi startet arbeidet med prosjektplan versjon 0.2 og påbegynte/ferdigstilte del 1-6. Etter innlevering fikk vi beskjed om at vi ikke hadde levert riktig rapport, og at arbeidet måtte gjøres igjen. 2. Iterasjon: Etter at vi fikk beskjed om at innleveringen var feil, jobbet vi igjen med prosjektplanen slik at den inneholdt rett informasjon. Kommentarene til vår innlevering hjalp oss å få en bedre pekepinn om hvor faglærer ville at vi skulle ta prosjektet. Vi skrev om del 1-6 i henhold til kommentarene, leverte inn og planen ble godkjent, men fortsatt med noen mangler som bør forbedres. Bl.a. Mål og Beskrivelse var for dårlig og måtte gjøres igjen. 3. Iterasjon: Etter 2. iterasjon fikk vi beskjed om at de funksjonelle og ikke funksjonelle kravene var gjort feil og måtte forbedres. Etter gjennomgang med studentassistenten så gjorde vi det på nytt. UseCase beskrivelsene var for svake, og måtte gjøres mer detaljert. Hvis vi ikke fikset dette ville ikke innlevering 3 bli godkjent. Etter forbedringene begynte vi arbeidet med 4.iterasjon
4. Iterasjon: Etter 3. iterasjon fikk vi kommentarer om en rekke småfeil på et UseCase diagram, klassediagrammet og domenemodellen. I tillegg til dette fikk vi beskjed om diverse mangler ellers i rapporten. Vi fikk hjelp av en student assistent til å forstå feilene våre bedre og forbedret de feilene som var nevnt. Flere av diagrammene våre måtte endres på, men da det ble klart hva som var galt gikk dette raskt. Når feilene var rettet skrev vi del 5 og 6 i rapporten, oppdaterte hjemmesiden og kvalitetssikret hele rapporten.
3 Analyse 3.1 Kravspesifikasjon Funksjonelle krav: Når det legges inn en bestilling vil systemet lokalisere nærmeste taxi ved å bruke en oversikt over ledige taxier innenfor et område på 1 km², hvis ingen taxier er innenfor dette område utvides arealet med 2 km² til en ledig taxi blir funnet. Når kunden legger inn en bestilling og den er registrert vil systemet automatisk videresende denne til den aktuelle taxien. Da dette er en svært lite krevende prosess vil dette fullføres på under 4 sekund. Hvis en kunde avbestiller en taxi skal systemet ta i mot avbestilling og videresende denne til bilen. Dette vil ta under 3 sekunder. Hvis en kunde ønsker å reservere en bil til et senere tidspunkt skal systemet ta i mot og lagre denne bestillingen. Dette vil ta under 5 sekunder for kunden å utføre. Når en kunde bestiller en taxi skal systemet automatisk velge riktig type taxi (f. eks maxi taxi hvis det er bestilt til flere en 4 personer) ut i fra informasjonen i bestillingen. Dette vil ta under 2 sekunder å utføre. Når en sjåfør har godtatt et oppdrag og systemet registrerer bilen som ikke ledig vil det automatisk sendes en ordrebekreftelse til kunden. Dette vil ta under 5 sekunder. Når kunden har betalt for reisen vil taxien automatisk etter betaling bli registrert som ledig i systemet. Dette vil ta under 2 sekunder. Systemet vil inneholde et enkelt brukergrensesnitt som er spesiallaget for kundebehandlere. Her vil kundebehandlere som tar i mot klager på telefon kunne skrive inn disse, og lagre de. Systemet vil da lagre disse i en database hvor hver klage har et unikt ID nummer. Kunden vil få oppgitt dette ID nummeret for senere referanser. Via brukergrensesnittet vil kundebehandlerne også ha mulighet til å hente frem gamle klager ved hjelp av klageid nummeret. Klagene lagres ut i fra kategori, de forskjellige kategoriene kan identifiseres med forskjellige typer klageid nummer. Hvordan klagene skal håndteres er opp til bedriften.
Ikke-funksjonelle krav: Systemet skal ha rask behandlingstid. Fra en bestilling kommer inn til systemet videresender denne til nærmeste taxi, går det under et sekund. Deretter skal taxisjåføren svare på om han tar oppdraget eller ikke. Det gjør han innen 1 minutt, dersom systemet ikke får noe svar innen 1 minutt, sendes forespørselen til nest nærmeste taxi, osv. Programmet som skal brukes av de ansatte skal være svært brukervennlig dvs. veldig lik Windows miljøet for lett å kunne læres av folk lave datakunnskaper. Programmet må ha kontinuerlig nettverkstilgang for å registrere lokasjonsdata. Programmet har lave krav til minnestørrelse, da det vil ha ganske enkelt GUI. På klientmaskiner vil programmet ta opp mellom 5 og 10 MB RAM, og installasjonen tar ca. 200MB. Programmet er laget med tanke på høy ytelse og god pålitelighet, da det til tider er stor trafikk hos en taxisentral. Vi sikter på 99 % oppetid, og responstiden vil som nevnt over være på under 1 på kommunikasjon fra taxi til systemet, og fra kunde til systemet. Totalt fra kunde sender inn bestilling til han får bestillingsbekreftelse skal det gå 2-5 sekunder, dersom det er lite trafikk på mobilnettverk/mailservere osv. Deretter skal kunde få bekreftelse på hvilken taxi som er på vei etter ca. 1 min. Max 5 min. Eksterne krav Systemet registrerer taxiers posisjon, sjåfører skal informeres om dette. Siden dette er en døgnåpen bedrift, må det være tilstrekkelig med ansatte for å kunne håndtere skiftrotasjonene i henhold til arbeidsmiljøloven.
3.2 UseCase-modell 3.2.1 UseCase-diagram
3.2.2 Detaljerte UseCase beskrivelser UseCase Aktør Trigger Prebetingelser Postbetingelser Normal hendelsesflyt Bestilling Sentral / kunde / taxi Kunde bestiller taxi 1. Systemet er i funksjon 2. Kunden ønsker taxi. 3. Kunden har informasjon om hvordan han / hun bestiller taxi (f.eks. kodeord som må brukes i sms). 4. Kundens bestilling kommer frem. 1. Taxi er på vei til kunden. 2. Sentralen har registrert taxien som ikke ledig. 3. Kunden har mottatt ordrebekreftelse og vet at en taxi er på vei. 1. Kunde bestiller Taxi ved hjelp av telefon, sms, eller fra hjemmesiden. 2. Sentral / Systemet sjekker om ønsket taxi type er ledig i området. 3. Sentral registrerer bestillingen og videresender den til bilen. 4. Taxisjåføren godtar oppdraget. 5. Sentralen registrerer aktuell taxi som ikke ledig. 6. Sentralen sender ordrebekreftelse til kunden.
Variasjoner 1. Ingen taxier er ledig i nærheten av kunden. 2. Ingen taxisjåfører ønsker å ta oppdraget. 3. Ingen ledige taxier av typen kunden ønsker.
UseCase Aktør Trigger Prebetingelser Postbetingelser Normal hendelsesflyt Finn ledig taxi Taxi / sentral Sentral ønsker å lokalisere den taxien som er nærmet en adresse og er ledig. 1. Systemet kjører. 2. Systemet har internettilgang. 3. GPS i taxi fungerer. Ledig taxi funnet 1. Sentral ber systemet finne en ledig taxi i nærheten av en adresse. 2. Systemet lokaliserer taxier i et område rundt adressen. 3. Søket utvides hvis ingen taxi er nærme nok. 4. Sentral velger nærmeste ledige taxi. Variasjoner 1. Ingen ledig taxi funnet. 2. Ingen taxi funnet i området.
3.3 Domenemodell
3.4 Aktivitetsdiagram
4 Design 4.1 Klassediagram
4.2 Sekvensdiagram Normalflyt
Avvik Sekvensdiagrammet for avvik er likt det til normal flyt. Dette fordi hvis en taxi ikke er ledig eller en taxisjåfør sier nei til et oppdrag gjentas løkken til en taxi finnes. Den søker igjennom taxiene etter distanse til henteadresse, de nærmeste taxiene først.
4.3 Logisk arkitektur Gruppen har valgt dette designet for logisk arkitektur av systemet. Arkitekturen viser en logisk oppbygning og anvendelse av systemet. Øverst er klientens brukergrensesnitt og de forskjellige
kommunikasjonsmediene for å ta imot bestillinger. Det øverste laget bruker den tekniske delen for å utføre handlinger. Domene delen vil hele tiden bruke den tekniske delen for å utføre/lagre og endre på de forskjellige dataene. Vi lagde først et annet design som vi valgte ikke å bruke. Det så mer ut som en tegning enn et diagram, og vi likte ikke måten det presenterte seg på. Vi tok i bruk Gliffi som programvare for å lage den nye versjonen av arkitekturen, og likte hvor enkelt dette designet ble for å demonstrere systemets arbeidsrelasjoner. Man kan lett se hvordan alt henger sammen, og på hvilke nivåer de opererer.
4.4 Brukergrensesnitt Vi har valgt å holde designet på vårt brukergrensesnitt så enkelt som overhode mulig for å forsikre oss om at personer med liten erfaring med data vil kunne forstå hvordan man gjennomfører en bestilling raskt og med lite opplæring. Da det skal være mulig å gjennomføre hele bestillingsprosessen manuelt, måtte alle oppgavene inkluderes, men da dette ble svært mange valgte vi å begrense det til 3 valg per side og programmet fikk derfor flere sider. Vi følte dette var et bedre alternativ siden mange alternativer på en side kan virke forvirrende og skremmende for noen. Vi har inkludert både en fremover pil og en bakover pil, siden det kan oppstå situasjoner hvor man må gå tilbake og endre på tidligere valg, ved for eksempel misforståelser mellom kunde og kundebehandler eller hvis en feil har oppstått. Tekstboksen på høyre side av vårt brukergrensesnitt inneholder informasjon om knappen man har valgt, og teksten her vil bli vist fra man gjør valget til man går til neste side i programmet. Skisse 1. Førsteutkast For å illustrere hvordan vi ønsket at brukergrensesnittet skulle se ut mens vi diskuterte diverse design lagde vi denne skissen.
Skjermbilde av foreslått brukergrensesnitt Dette skjermbildet er av vårt forslag til programmets brukergrensesnitt. Vi har valgt å holde det så enkelt som mulig og relativt likt Windows miljøet for å gjøre det enklere å forstå.
5 Vurdering 5.1 Vurdering av foreslått løsning Denne rapporten er skrevet med tanke på at en eller flere programmerere skal lese den og forstå hvordan vi ønsker at systemet skal konstrueres. Vi mener selv at rapporten beskriver dette på en tilfredsstillende måte ved hjelp av en detaljert kravspesifikasjon og oversiktlige diagrammer, men vi følte at vi ikke kunne avgjøre om dette var godt nok selv, siden vi har skrevet rapporten, og derfor har et større grunnlag for å forstå hvordan vi mente at det skulle utformes. Vi valgte derfor å involvere en tredjepart som kunne gi oss et nytt perspektiv. Han ble informert om at vi hadde behov for å vite om det kom tydelig frem hvordan vi ønsket å konstruere systemet og hvilke oppgaver det skulle ha mulighet til å utføre. Med svært lite forklaring forsto han hvordan vi ønsket at det endelige systemet skulle være og mente det ikke var alvorlige mangler i rapporten. Når vi fikk en bekreftelse på at en person som ikke hadde vært involvert i prosjektet forsto diagrammene og hva vi ønsket å formidle konkluderte vi med at kvaliteten på vårt arbeid var god nok og vi startet arbeidet med konklusjonen og kvalitetssikringen. 5.2 Vurdering av valgt utviklingsmodell Etter å ha jobbet med dette prosjektet i lengre tid har vi kommet fram til at utviklingsmodellen vår, med tilpasninger som er gjort, fungerte veldig bra. Vi har hatt en dynamisk prosess over lengre tid som har munnet ut i denne rapporten. I starten var det problematisk å få et grep om utdypningsfasen. Det var flere misforståelser om hva vi faktisk ville fram til, men etter å ha tatt noen runder her så har det gått veldig bra. Underveis i prosjektet har vi generelt fulgt utviklingsmodellen slik den skal være, det har vært noen tilbakeslag, f.eks. å bevege oss videre til neste fase, før en fase er ferdig, men det er en del av lærdommen vi tar fra faget. Vi klarte ikke å finne en utviklingsmodell som kunne ha fungert bedre til å gjennomføre dette prosjektet. Siden vi ikke skulle programmere noe, så var det den teoretiske delen av utviklingsprosessen som har vært viktig. Dette gjør utviklingstyper som MSF, XP og Scrum vanskelig å gjennomføre, siden de alle er avhengig av brukertestinger og tilbakemelding til teamet fra arbeidsgiver.
5.3 Vurdering av eget prosjektarbeid I løpet av dette prosjektet har gruppen fungert godt. Alle gruppemedlemmene har klart å samarbeide, og det har alltid vært mulig å diskutere problemer med andre gruppemedlemmer og å komme med kritikk av hverandres arbeid. I planleggingsfasen av vårt prosjekt lagde vi en detaljert og omfattende risikoplan som har sørget for at det alltid har vært en løsning når det har oppstått problemer. Det har for eksempler vært sykdom innad i gruppen, men når dette har blitt et problem har oppgavene som skulle vært utført av personen som ble syk fordelt mellom resten av gruppen. De som hadde minst arbeidsmengde i denne perioden fikk da en større del av den syke personens oppgaver en de som hadde mer å gjøre. Problemer med sykdom er uunngåelig i prosjekter som dette, men vi føler vi har klart å håndtere dette svært bra. Det har til tider oppstått problemer når arbeidsmengden har blitt så stor at gruppen har fått for dårlig tid til å gjennomføre en omfattende kvalitetssikring av arbeidet før innlevering. Dette har da ført til en større arbeidsmengde før neste innleveringsdato fordi feil må rettes o.l. Problemer med arbeidsmengder i andre fag har også påvirket arbeidet med prosjektet. Til tross for dette har gruppen klart å hente seg inn før siste innlevering, og kvalitetssikringen av denne ble gjort i god tid og i flere omganger. Det har også oppstått problemer da det av og til har vært vanskelig å forstå nøyaktig hva som er gjort galt i rapporten på grunn av noe uspesifikke kommentarer på innleveringer. Når dette har oppstått har det gått med tid til å få en grundigere forklaring av personen som rettet oppgaven. At det til tider kan bli en stor arbeidsmengde burde vært forutsett og bedre planlagt, for eksempel kunne gruppen startet arbeidet med prosjektet tidligere hver måned, men som nevnt tidligere fikk gruppen organisert arbeidet bedre etter hvert som det viste seg at det var svært nødvendig for å klare å bestå faget. Det har ikke oppstått andre betydelige problemer en de som allerede er nevnt. Hadde det derimot gjort det, mener vi at vi hadde vært godt forberedt, da vi hadde en plan for å minimalisere effekten av alle problemene vi antok at kunne oppstå, f.eks. datakræsj, tap av et gruppemedlem, konflikter og leveringsproblemer. Underveis i prosjektet har vi opplevd at noen av oppgavene har vært vanskeligere å gjennomføre en andre. Vi arbeidet svært mye med å strukturere mål og kravspesifikasjon. Vi slet med å forstå nøyaktig hvordan det var ønsket at dette skulle gjøres, og fikk flere ganger beskjed om at dette burde gjøres bedre. Før vi endelig fikk godkjent disse punktene hadde vi brukt både lærebok,
internett, forelesningsnotater og studentassistender for å skaffe oss en god forståelse av hvordan det endelige resultatet burde se ut. Arbeidet med diagrammer har generelt vært vellykket, noe som kan være en konsekvens av at vi har sett på dette som en av de mest spennende delene av prosjektet. Noen av diagrammene har inneholdt feil, særlig i de førte fasene av prosjektet, men arbeidet med disse har for det meste gått svært bra.
6 Konklusjon For dette prosjektet valgte vi å sette Hvordan planlegge utviklingen av et Taxisentralsystem? som målsetning. Dette var et åpent mål, men allikevell krevende. For og virkelig oppnå dette målet var det nødvendig å skaffe seg en god forståelse av faget systemutvikling, og relevant pensum. Når oppgaven ble løst, og rapporten var klar til levering, hadde vi fått den grunnleggende kunnskapen som var nødvendig for å oppnå målet vi hadde satt for prosjektet. Utviklingen har vært noe tidkrevende, og har til tider vært særdeles frustrerende, siden vi aldri var helt sikre på om det som ble levert i de ulike iterasjonene av rapporten var korrekt. Selv med noen tilbakeslag underveis klarte vi å forholde oss til de tidsrammer som ble satt opp i planleggingsfasen uten store vanskeligheter. Takket være denne planleggingen klarte vi også å forutse den relativt store arbeidsmengden som dette prosjektet ville skape, noe som forårsaket et budsjett som ikke ble sprengt grunnet uforutsette hendelser, feil kalkulering av tid eller tilbakefall på grunn av feil i systemets struktur. Underveis i prosjektet har vi hele tiden jobbet for å finne ut hva, om det eventuelt er noe i det hele tatt, som kunne bli gjort bedre. Dette har ført til en flytende kvalitetskontroll over hele prosjektets gang. Nå som prosjektet er ferdigstilt, så mener vi at det eringeting som kan bli gjort bedre. Det er litt problematisk å føye til noe under dette punktet, for hvis vi kommer på noe som kan gjøres bedre, så gjøre vi det før konklusjonen blir ferdigskrevet. Det var viktig for oss å oppnå målet om å automatisere en svært stor del av taxisentralens oppgaver. Ved hjelp av automatisering kan et system driftest mye lettere, med færre kostnader og høyere effektivitet. Ved hjelp av diagrammer og kravspesifikasjon har vi påvist at dette kan gjennomføres og vil gi bedriften mange fordeler i forhold til de som fortsatt baserer seg på callcenter uten automatisering. Vi har valgt å ha svært omfattende mål for systemet vi har planlagt. Som man kan se i del 1.2. i denne rapporten er det oppført mange og detaljerte mål. Prosjektets hovedfokus har alltid vært å oppfylle disse målene på en realistisk gjennomførbar måte. Når systemet var ferdig planlagt var målene vi satte opp i startfasen av prosjektet oppnådd og systemet inneholdt alle elementene som var nødvendig for å oppnå funksjonaliteten vi ønsket. Hendelsesflyten i taxisentralens operasjoner har gjort det mulig for oss å planlegge et system med en svært oversiktlig struktur. Som man kan se i våre diagrammer, er det ikke vanskelig å forstå hvordan systemet skal arbeide, og i hvilken rekkefølge operasjonene skal utføres. Det har også vært en prioritet og holde rapporten oversiktlig og diagrammene enkle nok til at