prosjektoppgave, inf1050, våren 2005 institutt for informatikk, universitetet i oslo Prosjekthåndteringssystem Kandidatene 108, 124 og 102

Transkript

1 prosjektoppgave, inf050, våren 2005 institutt for informatikk, universitetet i oslo Prosjekthåndteringssystem Kandidatene 08, 24 og 02

2 Innledning Dette er prosjektrapporten til gruppe 0503 i emnet INF050, skrevet av kandidatene 08, 24 og 02 våren 2005 ved Institutt for Informatikk, Universitetet i Oslo. Systemet, kildekode, samt dette dokumentet (i pdf-format med kryssreferanser) er å finne på nettet: Det kjørende systemet Kildekode Dette dokumentet Brukernavn og passord til systemet for de forskjellige brukergruppene er som følger: evilmaster evil Administrator peon peon Bruker test test Observatør i

3 Innhold Innledning Innhold Figurer i ii iv I Systemet Prosjektbeskrivelse 2. Interesseområdet Funksjonalitet Virkninger Eksisterende informasjonssystemer Brukergrupper Bruksmønstre 6 2. Bruksmønstre Sekvensdiagram Dataorientert UML Dokumentasjon 3. Merknader II Utviklingsprosessen 8 4. Rammer for prosjektet Utviklingsstrategi og utviklingsmetoder Milepælsplan Risikovurderinger Gjennomførte reguleringer Juridiske og etiske betrakninger Utviklingsverktøy og utviklingsplattformer UML SQL PHP, (X)HTML og CSS Avslutningsvis ii

4 INNHOLD INNHOLD III Evaluering 24 5 Innledningsvis Merknader Generelt Test av det kjørende systemet Registrering og innlogging Bestilling Administrator Prosjektbeskrivelse og system 29 IV Appendiks 30 A SQL 3 Bibliografi 33 iii

5 Figurer. Logo Bruksmønsterdiagram Sekvensdiagram for utvalgt bruksmønster Klassediagram Ugruppert UML-modell Gruppert UML-modell Faner Innlogging Forum Kommentarer Innlegg Gjøremålsliste Milepæler Kalender Medlemsliste Typografi Fargevalg iv

6 Delrapport I Systemet

7 Prosjektbeskrivelse Vi har laget et informasjonssystem for prosjekthåndtering. Dets hovedhensikt er å skape ett fora som gir muligheter for en alle-til-alle kommunikasjon. Ved kommunikasjon menes informasjon om progresjonen til prosjektet, om del-oppgaver innenfor prosjektets rammer, tidsfrister, prosjektmedlemmer og lignende. Hovedmålet er å skape en oversiktlig dokumentasjon over informasjonen som er nevnt ovenfor. Videre skal systemet fungere som en sentral kommunikasjonskanal for alle som er involvert i prosjektet, det være seg de som jobber direkte med prosjektet eller utenforstående, som kunder, sensorer m.fl... Interesseområdet Interesseområdet vil i dette tilfellet være gitt ved en situasjon hvor en gruppe mennesker skal jobbe sammen for å kunne realisere et prosjekt. Det var i utgangspunktet tenkt at systemet vårt skulle spesialisere seg på datarelatert arbeid (programvareprosjekter o.l.), men implementasjonen slik den er i dag er helt generell med hensyn på hva slags type prosjekt systemet skal håndtere. Det er kanskje viktig å understreke at systemet ikke tar seg av bugtracking (som Bugzilla, FogBugz m.fl.), skjønt det er selvsagt ingenting i veien for at det vil kunne brukes i tillegg. Systemet vil heller ikke være et versjonssystem (som CVS, Subversion m.fl) det trenger altså ikke holde styr på kildekode o.l. Hva er et prosjekt? Ifølge [, oppslagsord Project] (se også [, Project management]) er et prosjekt definert som følger: A project is a temporary endeavor undertaken to create a unique product or service. Temporary means that the project has an end date. Unique means that the project s end result is different than the results of other functions of the organization. Det er i utgangspunktet ingen grense for omfanget av prosjektene som faller innunder interesseområdet, skjønt det vil være naturlig å tenke seg en mindre gruppe mennsesker (3 til 5). Hvis systemet skulle skalere utover dette, ville 2

8 .2. FUNKSJONALITET. PROSJEKTBESKRIVELSE det utvilsomt kreve utvidet funksjonalitet i forhold til den nåværende, som f.eks. støtte for undergrupper og -prosjekter, samt mer stringent avgrensing av brukerrettigheter osv. Selv om systemet implementerer brukerrettigheter, er det ikke spesifisert noen spesiell form for hierarki innenfor brukerne av prosjektet utover det som er forklart andre steder i denne rapporten. Det er således ikke tenkt at prosjektet er administrert av en ansvarlig leder eller liknende. Systemet er altså ment for grupper med relativt «flat» struktur..2 Funksjonalitet Vi har fokusert på å gjøre dette så enkelt å bruke som overhodet mulig, samt å utvikle systemet etter mantraet do one thing, and do it well [, Unix philosophy]. Systemet har fire hovedbestanddeler : board Dette er systemets «hjerte», og en sentral kommunikasjonskanal for alle medlemmer av prosjektet. Postinger er ordnet i motsatt kronologisk rekkefølge. Man kan poste kommentarer til en enkelt posting eller legge til nye. Dette er altså en slags kollektiv blog. Postingene på forumet er publisert på en rss 2 -feed, slik at man har rask tilgang på kommunikasjonen via en newsreader 3. to-do En liste over større og mindre gjøremål, og hvem som har ansvaret. Brukere kan legge til nye gjøremål eller sette status (gjort, ugjort) for gjøremål man selv har ansvaret for. milestones En liste over milepæler (større mål, tidsfrister for prosjektet), og frister for hver av disse. Brukere med admin-rettigheter kan legge til nye gjøremål eller sette status (gjort, ugjort) for milepæler. Man har også tilgang til en kalender over milepælene for inneværende måned, for å kunne visualisere fremgangen og tidsfristene for prosjektet. users En liste over medlemmene av prosjektet, samt personalia og kontaktinformasjon (e-post osv.)..3 Virkninger Informasjonssystemer (og da særlig web-baserte) egner seg glimrende til håndtering av kollektive prosjekter. For eksempel kan man tenke seg at brukerne er spredt geografisk, og at det å møtes ansikt til ansikt kan være problematisk med hensyn til tid og kostnader. Alt man trenger for å benytte dette systemet er tilgang på internett og en nettleser hvor man måtte befinne seg i verden eller hva slags platform man bruker (Linux, Windows, Mac) spiller liten eller ingen rolle. Systemet er implementert på engelsk, derav engelske navn på bestanddelene og annen funksjonalitet 2 Really Simple Syndication. Et enkelt xml-format for publisering av innhold over internett. 3 Program for å lese rss-feeds. 3

9 .4. BRUKERGRUPPER. PROSJEKTBESKRIVELSE Det å ha strukturert og sentralisert kommunikasjon i prosjektarbeidet gjør at det blir lettere å finne ut hvor problemer/utfordringer ligger, ansvarsfordeling, samt hvem som har sagt og gjort hva til hvilken tid. En bivirkning som kommer fra dette er evalueringsarbeidet i etterkant. Det er mye lettere å evaluere et prosjektarbeid når man har dokumentert arbeidet såpass systematisk. I ettertid har man oversikt over hele prosessen, fra start til slutt..3. Eksisterende informasjonssystemer Det er utviklet et stort antall mer eller mindre tilsvarende informasjonssystemer for å håndtere prosjekter (project management) det er sågar et eget fagområde med standardiserte sertifiseringsprogrammer 4. Dette forsknings- og standardiseringsarbeidet [, Project Management] er drevet frem av erfaringer man har gjort seg etter større prosjektarbeider som gikk i vasken: I norsk sammenheng kan det famøse Tress prosjektet nevnes her. Vårt prosjekt er åpenbart ikke så ambisiøst, og er som sagt ment for mindre prosjekter der mindre grupper deltar. Blant de kommersielle systemene som kan sammenliknes med vårt, må prosjekthåndteringssystemene Basecamp 6 og FogBugz 7 nevnes. Begge er web-baserte, og deler mye av dette prosjektets interesseområde, men er mer rettet spesielt mot programvareutvikling og IT-arbeid. Imidlertid later de begge til å være relativt komplekse, og det kan hevdes at dette øker terskelen for uerfarne brukere. For mye eller for kompleks funksjonalitet kan også virke forvirrende og overveldende: Man kan risikere at det å bruke prosjekthåndteringssystemet blir et prosjekt i seg selv, og dermed virker mot sin hensikt. I så måte er vårt system relativt fleksibelt, og fremfor alt enkelt og oversiktelig å bruke. Figur.: Logo for prosjekthåndteringssystemet.4 Brukergrupper administrator Dette er brukere med full tilgang. De kan legge til nye brukere til prosjektet, redigere all informasjon i prosjektet og ellers gjøre alt de vanlige 4 Jamnfør ISO 0006:997, Quality management; Guidelines to quality in project management og Project Management Body of Knowledge (pmbok) Se mer på 5 Datasystem for Rikstrygdeverket, utviklet fra 989 til 995: Prosjektet ble forsinket med seks år, og til slutt stanset fullstendig. Prosjektet gikk over budsjett med over,2 milliarder (!) kroner. 6 Project management and task management software: Basecamp. 7 FogBugz. 4

10 .4. BRUKERGRUPPER. PROSJEKTBESKRIVELSE brukerne kan. medlem Dette er de vanlige brukerne, medlemmene i prosjektet. De kan legge inn informasjon, redigere sine egne innlegg og lese alt som er lagt inn. De kan hverken redigere informasjon om eksisterende brukere eller legge til nye. observatør En gruppe for utenforstående som ikke er direkte involvert i arbeidet som prosjektet omfatter. De kan lese all informasjon som er lagt inn i prosjektet, men de kan ikke legge inn vanlig prosjekt-informasjon selv,. Den eneste skriv-rettighet de har på systemet er å legge inn kommentarer til ting som blir lagt ut på forumet. Brukergruppene og deres respektive rettigheter er mer utførlig beskrevet i dokumentasjonen. 5

11 2 Bruksmønstre 2. Bruksmønstre Se figur 2. for bruksmønsterdiagram. Spesifikasjon av bruksmønster Navn Legge til nytt innlegg. Aktør Prosjektmedlem. Trigger Prosjektmedlem ønsker å poste et nytt innlegg til forumet. Normal hendelsesflyt Prosjektmedlemmet poster et nytt innlegg til forumet. 2 Innlegget blir tilgjengelig for alle brukerne av systemet. 3 En annen bruker kommenterer meldingen. Variasjoner 2a Prosjektmedlemmet har ikke tilstrekklige rettigheter til å poste ny melding. 3a Administrator finner innlegget upassende og redigerer det. 3c Prosjektmedlemmet oppdager feil eller mangler i sitt eget innlegg og redigerer det. 3d Innlegget omhandler et gjøremål på gjøremålslisten som prosjektmedlemmet har fullført. 4 Prosjektmedlemmet setter status for gjøremålet som fullført. 2.2 Sekvens- og klassediagram Se figur 2.2 for sekvensdiagram, med tilhørende klassediagram figur

12 2.2. SEKVENSDIAGRAM 2. BRUKSMØNSTRE Legge til ny posting Legge til ny bruker Legge til ny milepæl Kommentere en posting User:ProjectMember Redigere en posting Administrator: ProjectMember Logge inn Observer: ProjectMember Legge til nytt gjøremål Registrere gjøremål som utført Registrere milepæl som utført Figur 2.: Bruksmønsterdiagram. Ole: ProjectMember View Controller Model Post logger inn authenticate ("ole", "idole"):boolean containsuser ("ole", idole"): boolean får tilbakemelding hvis innlogging feilet legger inn nytt innlegg checkpermissions(ole):boolean new Post(Ole, "Hei, hei") leser registrert innlegg update() addpost(this) Figur 2.2: Sekvensdiagram. Normal hendelsesflyt for henholdsvis innlogging og posting av nytt innlegg. 7

13 2.2. SEKVENSDIAGRAM 2. BRUKSMØNSTRE update() View har Controller static int ADD_POST authenticate(string username, String password):boolean checkpermissions(projectmember member, int action):boolean har har 0 0 Model addpost(post p) containsuser(string username, String password) holder styr på holder styr på Post ProjectMember author String text Date dateofpost * er skrevet av * ProjectMember username password Administrator User Observer Figur 2.3: Klassediagram. 8

14 2.2. SEKVENSDIAGRAM 2. BRUKSMØNSTRE 0:* «BEGREP» Message messageid{id} er vedlagt «BEGREP» File filepath{id} «BEGREP» Password password{id} «BEGREP» {id} «BEGREP» Accesslevel name{id} har tilgangsnivå autentifiseres ved «BEGREP» User username{id} har «BEGREP» Name name{id} har skrevet står ansvarlig for har skrevet har opprettet er kommentar til har har «BEGREP» Text text{id} 0:* 0:* «BEGREP» Comment commentid{id} «BEGREP» Milestone milestoneid{id} har har «BEGREP» Status status{id} er datert har «BEGREP» Title title{id} «BEGREP» Date date{id} har deadline er beskrevet ved er beskrevet ved «BEGREP» Description description{id} er datert er datert Figur 2.4: Ugruppert UML-diagram for systemet. 0:* «BEGREP» To-Do todoid{id} 9

15 2.3. DATAORIENTERT UML 2. BRUKSMØNSTRE 2.3 Dataorientert UML Gruppert UML, se figur 2.5. Ugruppert UML, se figur 2.4. To-Do todoid{id} description responsible{fk} status=0 0:* Accesslevel level{id} description :* er ansvarlig for Milestone milestoneid{id} description createdby{fk} status=0 0:* er opprettet av User username{id} password firstname lastname 0:* har adgangsnivå i henhold til Accesstable level{fk} username{fk} har skrevet 0:* Comment commentid{id} messageid{fk} text author{fk} date 0:* er kommentar til 0:* Message messageid{id} text author{fk} date Figur 2.5: Gruppert UML-diagram for systemet 0

16 3 Dokumentasjon Systemet er forhåpentligvis relativt rett-frem og enkelt å bruke. Utgangspunktet er login-skjermen (figur 3.2), der allerede registrerte brukere kan få tilgang til systemet. (Her har man også tilgang til dokumentasjon og kildekode.) Etter innlogging blir brukeren tatt videre til forumet/oppslagstavlen (figur 3.3). Ved hjelp av faner kan man navigere mellom funksjonene i systemet, og lett se hvor man er (figur 3.). På forumet kan man avhengig av brukerens rettigheter legge inn nye postinger, redigere egne postinger eller legge inn kommentarer til egne eller andres postinger. Kommentarene til hver og en av postingene er i utgangspunktet skjult, men kan sees ved å klikke på en link under postingen (kommentarene dukker da opp under den aktuelle postingen). Se figur 3.4. Nye meldinger legges inn ved å klikke på Post new message-linken øverst til høyre. Kommentarer legges inn ved å klikke på Write comment-linken under hver posting. Brukeren blir da tatt videre til en side der man kan legge inn sin posting/kommentar (figur 3.5). Link til rss-feed er også øverst til høyre på forumsiden. Autentifisering i newsreaderen/nettleseren gjøres via http. Gjøremålslisten og milepælslisten deler mange av de samme grensesnittelementene. Begge er tabeller der hvert punkt har en status (gjort eller ikke gjort). Hvert gjøremål har en bruker som står ansvarlig. Hvis den innloggede brukeren har ansvar for et gjøremål, har brukeren anledning til å endre status for dette gjøremålet. Se figur 3.6. Man kan også legge til nye gjøremål. Milepælslisten (figur 3.7) er tilsvarende, skjønt bare administratorer har anledning til å endre status for hver enkel milepæl eller legge til nye milepæler. Øverst til høyre er en link til en kalender for inneværende måned. Her får man en rask oversikt over milepælene for inneværende måned (figur 3.8). Under medlemslisten har man tilgang til en liste over medlemmene av prosjektet, med personalia som brukernavn, navn og epostadresse (figur 3.9). Man logger ut av systemet ved å klikke på Log out-linken øverst i høyre hjørne.

17 3.. MERKNADER 3. DOKUMENTASJON Figur 3.: Faner. Brukeren navigerer mellom systemets funksjoner med hjelp av faner. Det «stedet» man befinner seg på kommer forrerst, det andre bak. Figur 3.2: Innlogging-skjerm. 3. Merknader Med hensyn til xhtml/css har vi jobbet opp mot Firefox (Mozilla bør oppføre seg tilsvarende) og har ikke hatt anledning til å teste mot Internet Explorer. Firefox/Mozilla er derfor den foretrukne nettleseren å bruke for dette systemet. 2

18 3.. MERKNADER 3. DOKUMENTASJON Figur 3.3: Forum. Oversikt over postinger, med informasjon om poster, dato og kommentarer. Legg merke til at det øverste innlegget er skrevet inn av den som er innlogget, og at brukeren således kan redigere innlegget. Figur 3.4: Kommentarer. De postingene som har kommentarer, har en JavaScript-link som viser/skjuler kommentarene for denne postingen. 3

19 3.. MERKNADER 3. DOKUMENTASJON Figur 3.5: Nye innlegg. En liten forklaring på formaterings-reglene kan sees til høyre. 4

20 3.. MERKNADER 3. DOKUMENTASJON Figur 3.6: Gjøremålsliste. Liste over gjøremål, samt skjema for å legge til nye gjøremål. 5

21 3.. MERKNADER 3. DOKUMENTASJON Figur 3.7: Milelpæler. Liste over milepæler, samt skjema for å legge til ny milepæl. Figur 3.8: Kalender. Visualisering av milepælene for inneværende måned. Dager som er milepæler merkes rødt, og dagens dato grått. 6

22 3.. MERKNADER 3. DOKUMENTASJON Figur 3.9: Medlemsliste. Liste over medlemmer av prosjektet, med personalia. Georgia Bold 20pt Verdana Regular pt Figur 3.0: Typografi. Typesnitt brukt i systemet. Begge fontene Georgia og Verdana er utviklet spesielt med hensyn på lesbarhet på skjerm #4446C #4446C #D3D3D3 #E6E6E6 #EFEFEF Figur 3.: Fargevalg. Vi har holdt oss til å bruke to hovedfarger ( og 2) konsekvent gjennom systemet. Sjatteringer av grått (3 til 5) brukes som bakgrunnsfarger og border. 7

23 Delrapport II Utviklingsprosessen 8

24 4. Rammer for prosjektet Tidsrammene for prosjektet følger tidsrammene satt av UIO for innleveringer. Vi startet opp i januar med deadline 27. mai. Innenfor denne rammen fulgte vi milepæler som nevnt under. De økonomiske rammene kan kun beskrives i tid. Gjennomsnittlig jobbet vi kanskje 4-5 timer i uken direkte med informasjonssystemet. Men, under prosjektets gang har vi ikke ført noen logg eller hatt annen kontroll over tidsforbruk/tidskostnad ved prosjektet. Setter vi timeprisen vår til 00 kr, kan vi i etterkant si at produksjonskostnaden på prosjektet vil ligge i størrelsesordenen til kroner. Alltså mellom 50 og 00 timer. De teknologiske rammene var bundet av hva vi hadde tilgjengelig. Websidene ble kjørt på UiO sin student-webserver, backend-databasen kjørte på UIO sin Oracle-database. Den eneste mangelen med disse var var webserverens restriksjoner om at brukeren kunne laste opp filer. Dette var funksjonalitet vi hadde med i systemdesignet, men som vi ikke fikk implementert i systemet grunnet de teknlogiske rammene. Vi klarte heller ikke å få fatt i noe teknologisk system for samarbeid på kildekodenivå (CVS). Dette var en stor mangel for oss, og våre teknlogiske rammer tvang oss da til å bruke en ganske tungvint manuell løsning. Hver enkelt bruker hadde friheten til å velge sitt ett utviklingsmiljø, og det var ingen restriksjoner eller rammer i det hele tatt for hva hver enkelt brukte eller hvordan man jobbet. Med unntak av mangel på CVS var de teknologiske rammene bra, og gjorde jobben vår lettere. Vi slapp unna mye konfigurering og testing, og fikk gått rett på jobben med å lage systemet vårt. Mer enn det kan man kanskje ikke forvente. 4.2 Utviklingsstrategi og utviklingsmetoder Vår utviklingsstrategi gikk ut på å planlegge mest mulig før kodingen begynte. Vi hadde nesten modellert alt før det ble lagt inn i databasen. Videre ble det ikke satt av plass til nye funksjoner i systemet før databasen hadde støtte for det. Mindre funksjonalitet, som ikke krevde interaksjon med backend-databasen ble tilføyet med eksperimentell utvikling. Her snakker vi om å gjøre om smileys-tegn til grafikk, tekst-parsing og lignende. Grunnen til at prosessen ble ganske preget av analytisk utvikling var forsåvidt strukturen prosjektet hadde med tanke på milepæler/innleveringer. Parallelt med utviklingen av database og datamodeller ble det gjort en «mock-up» av systemet i statisk html. Dette ga et ganske godt visuelt grunnlag 9

25 4.3. MILEPÆLSPLAN for resten av utviklingen. Etter vi var ferdig med den analytiske delen, og hadde mesteparten av designet (både database og UI) på plass, ble det en progressiv/eksperimentell utvikling av systemet. Dette kan karakteriseres som finpuss, eller siste realisering. Vi brukte systemet til å sette sjekklister for oss selv (To-Do i systemet) og fulgte disse. Sjekklistene sørget for en åpen informasjon til alle de involverte i prosjektet om hva som var blitt gjort, og kanskje viktigere, hva som måtte gjøres. Progresjonen i prosjektet ble opprettholdt gjennom milepælene bestemt av UiO. 4.3 Milepælsplan Under selve utviklingsfasen opererte vi ikke med noen fastlagt milepælsplan rent bortsett fra den som var gitt i form av delinnleveringene. Imidlertid kan vi i etterkant oppsummere milepælene for prosjektet som følger: Fastslå funksjonalitet Modellering Implementasjon av database «Mock-up» eller prototyp av grensesnitt Realisering av systemet med funksjonalitet Videre fungerte gjøremålslisten i systemet som et godt verktøy for større og mindre oppgaver som dukket opp i løpet av utviklingsfasen. 4.4 Risikovurderinger Med hensyn på risikovurderinger tok vi dessverre lite høyde for fallgruver. I ettertid burde vi ha kanskje sørget for å oss gi bedre tid for å nå milepælene og unngå skippertak, men det ble desverre ikke gjort. Vi hadde forsåvidt heller ingen plan klar for hvordan en redesign av databasen eller systemet skulle behandles. Vi gjorde enkelt og greit ingen risikovurderinger, og hadde noe uforutsett skjedd ville vi måtte prøvd å løse det på sparket. 4.5 Gjennomførte reguleringer Systemet var gjenstand for grundig evaluering av en annen gruppe. De pekte på flere ting ved systemet som vi ikke hadde tenkt eller tatt oss tid til å teste, og et par ting som var resultat av misforståelser og/eller grunnet bruk av Internet Explorer. Større og mindre ting ble utbedret i etterkant av evalueringen: Oppdeling av foruminnlegg (eller «bla»-funksjon); 0 innlegg pr. side. Link til rss-feed bruker nå feed-protokoll for URLen for å unngå misforståelser. 20

26 4.6. JURIDISKE OG ETISKE BETRAKNINGER Sortering av brukere på brukerlisten etter etternavn. Diverse utbedring av håndtering av feilmeldinger. Mindre utbedringer av CSS/layout. Andre punkter som ble påpekt i evalueringen ble vurdert endret/utbedret, men mange av punktene var av en såpass liten betydning (eller at funksjonaliteten var misforstått) at endringer ikke ble gjort. 4.6 Juridiske og etiske betrakninger Det er vanskelig å si om det etiske betraktninger er relevante for dette systemet. Imidlertid lagrer systemet personalia (navn og epost), som åpenbart faller innunder personvernloven. Vi har ikke lagt inn noen slags form for notis om personvern o.l i systemet, hvilket det muligens burde ha vært. Formålet med opplysningene er imidlertid relativt ganske klare og utvetydige: De lagres ikke med noen annen hensikt enn for å gi en måte å differensiere forskjellige brukere i systemet (navn), samt å gjøre kommunikasjon enklere (epost). Ingen av disse opplysningene kan sies å være sensitive. Ved opprettelse av ny bruker samtykker man ikke med noen ting, så det er forholdsvis underforstått at opplysningene ikke kan brukes utenfor systemet. 4.7 Utviklingsverktøy og utviklingsplattformer 4.7. UML Vi har ikke benyttet noen spesiell form for utviklingsverktøy for UML (TauUML e.l), bortsett fra penn og papir vi syntes det var enklest og mest hensiktsmessig for et prosjekt på denne størrelsen. For større prosjekter passer utvilsomt mer egnede dataverktøy bedre. uml er utvilsomt svært nyttig i oppstartsfasen, og gjør at alle har et klart bilde (sågar visuelt) av hva systemet er og hvordan bestanddelene henger sammen. Når man begynner å kode er det imidlertid lett å glemme diagrammene, i den grad uml sjelden sier noe om hvordan noe bør implementeres. Det er svært nyttig at det eksisterer en felles notasjon for modellering av denne typen, skjønt standarden favner veldig bredt av og til er diagrammer vanskeligere å forstå enn kode eller gode, gammeldagse setninger. Tidligere i denne rapporten har vi nevnt hvordan det er viktig at det å bruke verktøyet (som f.eks. dette systemet) ikke må bli et prosjekt i seg selv; da kan det lett bli et hinder for utvikling snarere enn hjelp 2. Det tar også tid å oppdatere uml skulle det bli endringer, og det kan diskuteres om hvorvidt dette er fruktbart. Imidlertid er dette et svært lite prosjekt, og det er vanskelig å vurdere disse tingene utfra en såpass kortvarig erfaring. uml i denne rapporten er gjort i diagramprogrammet OmniGraffle 2 Også kjent som Analysis Paralysis. 2

27 4.8. AVSLUTNINGSVIS SQL SQL for databasen ble først modellert, og senere ble selve koden skrevet ut til en fullstendig fil (se appendiks A). Stort sett hadde vi gode erfaringer med Oracle og SQL*Plus-grensesnittet, skjønt Orcale har noen særegenheter som kan være litt irriterende å ha med gjøre, særlig hvis man har tidligere erfaring med mer «lette» SQL-varianter som MySQL og tilsvarende (imidlertid ingenting litt googling kan ordne opp i). Relasjonsdatabaser som sådan og konseptene bak dem er lette å forstå og ha med å gjøre PHP, (X)HTML og CSS I mangel av noe annet enn manuell versjonskontroll har vi stort sett jobbet i enkle teksteditorer direkte opp mot serveren. Endringer og ny funksjonalitet har som regel blitt dokumentert direkte i systemet vi laget selv, eller kommunisert på annen måte (vha. epost eller liknende). Igjen tilsier størrelsen på prosjektet at dette ikke har vært noe stort problem, men for større prosjekter er nok dette ikke den lureste måten å arbeide på et ordentlig versjonskontrollsystem hadde vært å foretrekke. Man får et slags elsk-hat-forhold til php etter å tilbragt endel tid med språket. Ting har lett for å bli rotete, og interpetereren er svært tilgivende, hvilken et uvant i forhold til mer stringente (kompilerte) språk som Java. På den andre siden går utvikling rivende raskt: Det tar svært kort tid å implementere funksjonalitet, mye grunnet et stort bibliotek av innebygde funksjoner som er svært godt dokumentert og spesielt rettet mot web-applikasjoner. I tillegg finnes det et utall ressurser på nettet for referanse eller generell hjelp. Med hensyn på html og css har vi lagt relativt stor vekt på at utseende og grensesnitt skulle være tiltalende. I denne sammenhengen legges det muligens lite vekt på det (i den grad dette ikke er noe webdesign-kurs), men grensesnitt og estetiske hensyn er utvilsomt en viktig del av ethvert datasystem iallefall hvis man håper på at det faktisk skal brukes. Dette er imidlertid tidkrevende; css (og måten ulike nettlesere tolker css) kan være forholdsvis vanskelig å ha med å gjøre. Vi har også lagt vekt på å følge web-standarder 3, og semantisk korrekt markup uten bruk av tabeller. Dette er problematisk med hensyn på Internet Explorer (IE), som har en lang rekke bugs i sin css-implementasjon. Grunnet den relativt korte tidsrammen for dette prosjektet (og mangel på tilgang til Windows-maskiner), har vi valgt å ikke bruke tid på å få sidene til å se bra ut i IE. I stedet har vi utviklet systemet mot nettlesere som har en mer korrekt implementasjon i forhold til standarden 4. Forøvrig har Firefox (med diverse plug-in-moduler) vært uvurderlig for debugging av CSS og validering av XHTML. 4.8 Avslutningsvis Avslutningsvis må vi nevne at erfaringenene med utvikling av en web-applikasjon har vært svært gode. Det medfører mange utfordringer med hensyn på 3 Samtlige sider er gyldige vis a vis xhtml.0 Strict og css Mozilla (og andre Gecko-nettlesere), samt Safari (og andre KHTML-nettlesere). 22

28 4.8. AVSLUTNINGSVIS grensesnitt og brukbarhet som man ikke er kjent med fra mer tradisjonelle applikasjoner, der man generelt har mer kontroll over brukerinteraksjon o.l. Imidlertid har nettopp erfaringene med hvor komplekst dette er vært svært interessante. En viktig erfaring vi har gjort oss er at Gud ligger i detaljene! Ting som man i utgangspunktet kan anse som banale eller uviktige er eller kan være svært viktige deler av helheten. I den forstand er vi stolte av å ha laget et system som om vi så må si det selv er gjennomført ned til de minste detaljene. Vi er også fornøyde med å ha realisert et system som har en faktisk relevans for oss som informatikkstudenter, og som i løpet av prosjektets gang har fungert meget godt som vektøy for utvikling og planlegging. Forøvrig oppfordres det til å besøke systemet for å få et bilde av hvordan kommunikasjonen har foregått og fungert i gruppen. Vi har hatt få problemer av organisatorisk karakter, og har ikke hatt forsinkelser utover de oppsatte fristene. Utviklingen av systemet har sånn sett vært relativt smertefritt. Imidlertid har vi selvsagt gjort oss erfaringer som kan være til nytte for senere arbeid. Vi var heldige med en evaluering som hadde gått systemet svært nøye i sømmene. Dette var til stor hjelp det er overraskende hvor mye man kan overse eller glemme å tenke på. Det kan være vanskelig å se disse tingene i sitt eget system; en objektiv vurdering og testing av systemet har vært uvurderlig. Nødvendigheten av god planlegging og et klart bilde av hva systemet skal gjøre (og hva det ikke skal gjøre) er åpenbar. Vi hadde stor nytte av å ha dette mer eller mindre fastlagt på forhånd. Hyppig kommunikasjon via epost, IM og forumet i systemet har også vært til stor hjelp. Vi har heldigvis ikke vært utsatt for store fallgruver under utviklingsprosessen, skjønt viktigheten av å begynne i god tid har så definitivt gjort seg gjeldende særlig i forkant av innleveringer o.l. Det er imidlertid forbausende mye man kan få gjort i løpet av et skippertak, selv om denne arbeidsmetoden kanskje ikke alltid er den beste! Det er et spørsmål om erfaringene fra prosjektet samsvarer med teori som danner grunnlaget for faget. Mye har stemmet overens, mens andre ting har kanskje ikke vært like samsvarende. Den mest sentrale erfaringen vi har gjort oss er kanskje at det finnes ingen kongevei til systemutvikling: Selv om både uml og utviklingsverktøy og -metodikk er til stor hjelp, støter man alltid på problemer som man ikke har forutsett eller kan løses ved hjelp av ting som står i bøker det må læres ved erfaring. 23

29 Delrapport III Evaluering 24

30 5 Innledningsvis 5. Merknader Denne delen av rapporten er vår evaluering (datert 23. april 2005) av systemet Taxireservasjon. Notene var mest ment som tips og informasjon til gruppen vi evaluerte, men tas med her for helhetens skyld. 5.2 Generelt Taxireservasjonssystemet er en god idé, systemet har sobert og pent grensesnitt og oppfyller for det aller meste kravspesifikasjonen. Per dags dato bærer det imidlertid litt preg av å mangle litt finpuss her og der, stort sett i form av manglende eller uventet/utilsiktet tilbakemelding til brukeren. Meget bra SQL og konsistens vis à vis modeller og kjørende system. 25

31 6 Test av det kjørende systemet 6. Registrering og innlogging Utgangspunktet for systemet er innlogginssiden, med et skjema for brukernavn og passord. Litt mer utfyllende informasjon om hva en førstegangsbruker har å gjøre hadde kanskje vært ønskelig her, som f.eks. en litt mer synlig link til registrering av ny bruker. Skjemaet for registrering av ny bruker er oversiktelig og greit. Feltet for navn har en begrensning på antall tegn (20), hvilket kanskje er noe lavt med tanke på at navn ofte er en god del lengre enn det. I kravspesifikasjonen står det at «alle felter er påkrevd», men systemet gir ingen feilmelding i fall brukeren ikke fyller ut alle feltene i stedet får man en utskrift av php-feilmelding. Passord må gjentas to ganger. Systemet gir heller ingen feilmelding hvis disse ikke stemmer overens, men man kommer til en helt blank side. Ifall man fyller ut en epost-adresse som allerede ligger registrert i systemet, får man også en utskrift av feilmelding. Dette er riktig oppførsel fra systemets side, men brukeren bør kanskje få litt informasjon om hva som er skjedd. Med hensyn på feltene for adresseinformasjon er det et par ting må påpekes. Kravspesifikasjonen legger vekt på at brukeren ikke skal kunne legge inn feilaktig eller ødelagt informasjon systemet, hvilket er en god ting. I stedet for at brukeren legger inn adresseinformasjon selv, har man i stedet tilgang på adresseinformasjonen som ligger i systemet fra før av. Dette har mange fordeler, men er også problematisk på noen områder (mer om dette senere). For registreringens del er det kanskje litt selsomt at man har anledning til å legge inn informasjon om postnummer, da det egentlig følger som en konsekvens av gateadressen man har valgt (slik later det også til å fungere i oversikten over personene som man har tilgang til som admin-bruker). Det later heller ikke til at denne informasjonen lagres noe sted. Da vi testet dette, lå det bare informasjon om fire gater inne i systemet. I den grad brukeren faktisk bor i en av disse gatene, fungerer det ganske bra med en drop-down-meny for å velge hvilken gate man bor i. Det står ingen ting i kravspesifikasjonen om hvor stort området systemet skal kunne håndtere, men man må kunne regne med at antallet gater er langt høyere enn fire, selv for php-tips: Sjekk dokumentasjonen for php-konstruksjonen isset den returnerer true for variabler som er tomme strenger. Bruk heller empty()-metoden eller tilsvarende. 26

32 6.2. BESTILLING 6. TEST AV DET KJØRENDE SYSTEMET mindre steder. Isåfall kan det bli tungvint for brukeren å velge blant mange gater i en drop-down-meny. Man burde kanskje heller velge en scrollbar liste 2 eller dele gatene inn i mindre områder (som for eksempel kommune). Når man har lagt inn den nødvendige informasjonen i skjemaet får man tilbakemelding om at brukeren er registrert. Man blir ikke logget inn som den brukeren man registrerte seg som etter vellykket registrering. Det er en vurderingssak om dette bør være tilfelle. En liten ting vedrørende innlogging og registrering er at brukeren ikke får noen hint eller beskjed om at brukernavnet er epostadressen. Det bør kanskje være en fotnote eller liknende på registreringssiden om at dette er tilfelle. Ved innlogging med feil brukernavn får man tilbakemelding om dette. Det samme gjelder innlogging med feil passord, med den lille forskjellen at denne beskjeden bare dukker opp et sekund før man blir tatt tilbake til innlogginssiden. Når man har logget inn med riktig brukernavn og passord får man tilbakemelding om at man er innlogget, hvem man er innlogget som, og at man kan benytte menyen til venstre. 6.2 Bestilling I menyen er det et valg for bestilling av taxi. Bestilling later til å være en to-delt prosess: Først valg av kommune, så videre valg av adresse, antall personer mm. Skjemaet for kommunevalg blir imidlertid værende på siden også for steg to. I og med at dette skjemaet fungerer også her (det andre skjemaet forandrer seg passende), bør det første steget kanskje utelates. I og med at systemet har lagret informasjon om adressen til brukeren som er innlogget er det kanskje litt påfallende at det ikke finnes noe eget valg for bestilling til hjemadressen til vedkommende. Man kan for eksempel se for seg at det første steget innebærer å velge mellom et av to: Bestill taxi fra din adresse, eller bestill taxi fra den-eller-den kommunen. Under resten av skjemaet kan man velge gate mha. en drop-down-meny (se over for hvorfor det kan være problematisk), samt gatenummer, antall personer bestillingen gjelder og klokkeslett. Det er tilsvarende problem for manglende utfylling av felter her systemet skriver ut en feilmelding hvis gatenummer blir latt være blankt. Det gjøres ingen sjekk for om hvorvidt adressen gate og gatenummer danner eksisterer, men feltet er begrenset til fem tegn, hvilket virker rimelig. Brukeren kan legge inn gatenummer som en tekststreng uten at det byr på problemer, så man kan spesifisere informasjon om f.eks. oppgang eller liknende. Imidlertid kan man legge til feilaktig informasjon her (som f.eks. gatenummer ABC), hvilket er litt motstridende med hensyn på ambisjonen om at brukeren ikke skal kunne gjøre feil eller legge inn ødelagt data. Man kan velge tidspunkt for bestillingen, men det er ikke noe valg for «så fort som mulig», eller direkte bestilling. Det er heller ingen måte å spesifisere dato for bestillingen. Man kan altså ikke forhåndsbestille taxi lengre frem i tid enn dagens dato, hvilket kanskje er en liten svakhet. Etter fullendt bestilling får brukeren tilbakemelding om at bestillingen er registrert, samt informasjon om adresse o.l om denne. Det er ikke anledning til å angre bestillingen, og i og med at man kan tenke seg at en taxibestilling er forholdsvis bindende for 2 Kan gjøres med multiple-attributten for <select>-elementet. 27

33 6.3. ADMINISTRATOR 6. TEST AV DET KJØRENDE SYSTEMET kundens del, burde det kanskje være en bekreftelsesfunksjon eller liknende under bestillingsprosessen. Under Vis detaljer-linken i menyen, har brukeren oversikt over sine bestillinger med informasjon om disse (med unntak av gatenummer). Det later ikke til å være noen grense for antall bestillinger en bruker kan legge inn, og man kan også legge inn bestillinger til samme adresse (eller andre) til nøyaktig samme tidspunkt. Dette virker uhensiktsmessig, men det får kanskje bli en sak mellom kunden og drosjeselskapet å rydde opp i det. Igjen er det er svakhet at tidspunktet for bestilling ikke innebærer en dato. Hva betyr f.eks. bestillingsinformasjonen tre dager senere? 6.3 Administrator-funksjonalitet Ifølge kravspesifikasjonen har brukere med administrator-rettigheter anledning til å gjøre alt andre brukere kan, samt ha tilgang til historikk og rapporter fra systemet. Under Informasjon-linken i menyen har man tilgang til administratorfunksjonalitet. Med hjelp av et radioknapp-skjema kan man skifte mellom de forskjellige tabellene. Det er litt tungvint å måtte spesifisere hvilken type informasjon man vi se med hjelp av et skjema det er ingen grunn til at dette ikke kan gjøres med ordinære lenker. Skjemaet fungerer imidlertid akkurat som det skal, og man har tilgang til fire tabeller: Personer, Adresser, Soner og Bestillinger. Alle fungerer i henhold til tittelen, og er relativt selvforklarende. Listen over bestillinger er kanskje den mest interessante for en administrator. Den inneholder informasjon om bestillingsnummer brukernavn (altså epostadresse) til den som har lagt inn bestillingen (hvorfor ikke navn?), adressen for bestillingen (men ikke gatenummer, bare gate), samt kommunenummer, antall personer og tidspunkt for bestillingen. Det er en svakhet her at listen ikke later til å være sortert etter noe spesielt kriterium, slik at f.eks. den bestillingen som først skal tas hånd om kommer øverst. Administrator-funksjonaliteten fungerer i henhold til kravspesifikasjonen, men man kan kanskje hevde at det burde være litt mer å administrere. Det er f.eks. ikke noen funksjonalitet for å fjerne eller endre informasjon om brukere e.l., men dette ligger kanskje utenfor «mandatet» til dette systemet i forhold til det eksisterende systemet. 28

34 7 Konsistens mellom prosjektbeskrivelse og system Generelt må det sies at konsistensen mellom kravspesifiasjon og dokumentasjon og det kjørende systemet er svært bra. Systemet oppfyller all funksjonalitet mer eller mindre perfekt i henhold til prosjektbeskrivelsen. Systemet er ment å komplettere et allerede eksisterende system for fordeling av bestillinger o.l, og det innfrir det kjørende grensesnittet. Man imidlertid ønske seg en litt mer spesifikk beskrivelse av det tenkte systemet og en litt mer utførlig forklaring av hvor grensen går mellom de to. Prosjekbeskrivelsen legger også vekt på at brukeren skal kunne gjøre så få feil som mulig med hensyn på feilaktig data o.l. Dette er i høyeste grad tilstede i det kjørende systemet. Riktignok fordrer det eksisterende data (om adresser o.l) som er svært utstrakt og oppdatert fra systemets side. Det blir noe vanskelig å vurdere dette da såpass lite data ligger inne per dags dato, og det står ingen ting i prosjektbeskrivelsen om utstrekningen av det tiltenkte systemet. For eksempel: Er dette et taxiselskap som skal håndtere kunder i hele Oslo, eller kun for et lite tettsted? Med hensyn på UML-modeller og SQL later det også til at sammenhengen er svært bra, og den kjørende systemet stemmer mer eller mindre eksakt med diagrammene i prosjektbeskrivelsen. Imidlertid vi savner kanskje tidspunkt for bestilling som henholdsvis begrep og attributt i diagrammene, da dette er (eller burde være) en relativt essensiell del av systemet. Det er en svakhet med systemet (skjønt ikke med modellen per se) at feltet for tidspunkt er av datatype CHAR, og ikke DATE da dette hadde tilført vesentlig funksjonalitet til systemet i form av sortering av tabeller, forhåndsbestilling frem i tid osv. Use-case- og sekvensdiagrammer stemmer også godt overens med det vi finner i det kjørende systemet. Med hensyn på use-case-diagrammet er et par ting muligens spesifisert litt upresist (hva ligger i bruksmønstret Administrer?). Sekvensdiagrammet er også oversiktelig og fint, men tidspunkt glimrer igjen med sitt fravær. DATE lagrer et tidspunkt som dag, måned, år, time, minutt og sekund. 29

35 IV Appendiks 30

36 Tillegg A SQL /* 2 * USERS 3 */ Listing A.: SQL for systemet 4 CREATE TABLE users ( 5 username VARCHAR (5) PRIMARY KEY, 6 password VARCHAR (32) NOT NULL, 7 fname VARCHAR (5), 8 lname VARCHAR (20), 9 VARCHAR (40) 0 ); 2 3 /* 4 * ACCESSLEVEL 5 */ 6 CREATE TABLE accesslevel ( 7 lvl NUMBER () PRIMARY KEY, 8 description VARCHAR (5) 9 ); /* 23 * ACCESSTABLE 24 */ 25 CREATE TABLE accesstable ( 26 lvl NUMBER (), CONSTRAINT fk_ level FOREIGN KEY ( lvl ) 27 REFERENCES accesslevel ( lvl ), 28 username VARCHAR (5), CONSTRAINT fk_ username_ access 29 FOREIGN KEY ( username ) 30 REFERENCES users ( username ) 3 ); /* 35 * TO -DO 36 */ 3

37 TILLEGG A. SQL 37 CREATE TABLE todo ( 38 todoid NUMBER (38) PRIMARY KEY, 39 description VARCHAR (024), 40 opprettet DATE, 4 ansvarlig VARCHAR (5), CONSTRAINT fk_ username_ todo 42 FOREIGN KEY ( ansvarlig ) 43 REFERENCES users ( username ), 44 ferdig NUMBER () DEFAULT 0 45 ); /* todoid increment sequence */ 48 CREATE sequence todo_id 49 START WITH 50 INCREMENT BY 5 NOMAXVALUE ; /* 55 * BOARD 56 */ 57 CREATE TABLE bulletinboard ( 58 messageid NUMBER (38) PRIMARY KEY, 59 username VARCHAR (5), CONSTRAINT fk_ username_ bbs 60 FOREIGN KEY ( username ) 6 REFERENCES users ( username ), 62 title VARCHAR (50), 63 text VARCHAR (255), 64 post_ date DATE, 65 filepath VARCHAR (255) 66 ); /* bulletinboard incerement sequence */ 69 CREATE SEQUENCE bbs_id 70 START WITH 7 INCREMENT BY 72 NOMAXVALUE ; /* 76 * COMMENTS 77 */ 78 CREATE TABLE comments ( 79 commentid NUMBER (38) PRIMARY KEY, 80 username VARCHAR (5), CONSTRAINT fk_ username_ comments 8 FOREIGN KEY ( username ) 82 REFERENCES users ( username ), 83 text VARCHAR (255), 84 comment_ date DATE, 85 messageid NUMBER (38), CONSTRAINT fk_ messageid_ comments 86 FOREIGN KEY ( messageid ) 87 REFERENCES bulletinboard ( messageid ) 88 ); /* comments incerement sequence */ 32

38 TILLEGG A. SQL 9 create SEQUENCE comment_ id 92 START WITH 93 INCREMENT BY 94 NOMAXVALUE ; /* 98 * MILESTONES 99 */ 00 CREATE TABLE milestones ( 0 milestoneid NUMBER (38) NOT NULL, 02 description VARCHAR (52), 03 created_ date DATE, 04 deadline DATE, 05 username VARCHAR (5), CONSTRAINT fk_ milestones_ user 06 FOREIGN KEY ( username ) 07 REFERENCES users ( username ), 08 done NUMBER () DEFAULT 0 09 ); 0 /* milestoneid incement sequence */ 2 CREATE SEQUENCE milestone_ id 3 START WITH 4 INCREMENT BY 5 NOMAXVALUE ; Listing A.2: Tabeller som det ikke er blitt implementert støtte for i systemet. Kanskje av interesse for senere utvidelser. 6 CREATE TABLE projects ( 7 projectname VARCHAR (25) PRIMARY KEY, 8 description VARCHAR (250) 9 ); 20 2 CREATE TABLE groups ( 22 groupname VARCHAR (40) PRIMARY KEY, 23 description VARCHAR (00) 24 ); CREATE TABLE gmembership ( 27 groupname VARCHAR (40), CONSTRAINT fk_ groupname 28 FOREIGN KEY ( groupname ) 29 REFERENCES groups ( groupname ), 30 username VARCHAR (5), CONSTRAINT fk_ username 3 FOREIGN KEY ( username ) 32 REFERENCES users ( username ) 33 ); 33

39 Bibliografi [] Wikipedia, the free encyclopedia. [2] XHTML.0 The Extensible HyperText Markup Language. A Reformulation of HTML 4 in XML.0. World Wide Web Consortium, 2 utgave, [3] Cascading Style Sheets, level 2 revision CSS 2. Specification. World Wide Web Consortium, [4] Apple Computer, Inc. Apple Human Interface Guidelines, Kodifisering av regler for bruk av grensesnittelementer. [5] Gerhard Skagestein. Systemutvikling: fra kjernen og ut, fra skallet og inn. Høyskolefolaget, Kristiansand, ISBN [6] Gerhard Skagestein, Ole Hanseth og Erik Arisholm. Foiler og forelesninger våren Universitetet i Oslo, Institutt for Informatikk. 34