CharityDoctors. Prosessrapport



Like dokumenter
Hovedprosjekt ved Høgskolen i Oslo våren 2011 CHARITY DOCTORS KRAVSPESIFIKASJON

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

CharityDoctors. Brukermanuel

Del IV: Prosessdokumentasjon

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen.

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo,

PROSESSDOKUMENTASJON

Kravspesifikasjon. Forord

Forprosjekt. Høgskolen i Oslo, våren

Forprosjektrapport. Presentasjon. Oslo, den 29. Januar Gorm Eirik Svendsen Nicolai Mellbye Marius Auerdahl Per Gustav Løwenborg

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Pillbox Punchline

PROSESSDOKUMENTASJON

Testrapport Prosjekt nr Det Norske Veritas

HOVEDPROSJEKT HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet

Produktrapport Gruppe 9

Testrapport. Studentevalueringssystem

Møtereferater: HP36 uke 2, : Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon.

Bachelorprosjekt 2015

Dokument 1 - Sammendrag

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

Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus, våren Camilla Kaasi(s188070) Roza Moustafa(s188113)

Styringsdokumenter. Forord

Studentdrevet innovasjon

Oblig 5 Webutvikling. Av Thomas Gitlevaag

Prosjektdagbok hovedprosjekt våren 09

HOVEDPROSJEKT. Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker.

Forprosjektrapport. Gruppe Januar 2016

Granitt Grafisk AS Kravspesifikasjon Gruppenr:

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1

Dette dokumentet er en produktrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen.

Bachelorprosjekt i informasjonsteknologi, vår 2017

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

[GILJE SELSKAPSLOKALER]

[GILJE SELSKAPSLOKALER]

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer

Kravspesifikasjon. Forord

Kravspesifikasjon Gruppe nr ABTF

DAGBOK. Patrick - Opprettet blogside for å kunne legge ut informasjon om hva som skjer underveis i prosjektet.

1. Forord 2. Leserveiledning

Gruppe 44. Bachelorprosjekt ved Institutt for informasjonsteknologi, våren Høgskolen i Oslo og Akershus,

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp

Prosjektdagbok Oktober 2009 November 2009 Desember 2009 Januar 2010 (Uke 1)

Forprosjektrapport. Gruppe 34. Magnus Dahl Hegge s153549

Hovedprosjektet i Data Høgskolen i Oslo våren 2010

Prosjektdagbok FRA TIL Uke Dato Personer tilstede. Beskrivelse 10: Øyvind. Vi dannet gruppe og skrev Statusrapport.

6 Kravspesifikasjon. 6.1 Presentasjon. Tittel Precision Teaching App for Android

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl

Presentasjon av oppgave 24E Bookingsystem for LillehammerBryggeri. Av Anders Refsahl

Prosjektlogg Samfunnet Bislet (Gr. 44)

Styringsdokumenter. Studentevalueringssystem

1 Del I: Presentasjon

PROSJEKTDAGBOK GRUPPE 28

Forprosjekt gruppe 13

Use Case Modeller. Administrator og standardbruker

Brukermanual. Studentevalueringssystem

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar Gruppemedlemmer

Gruppe Forprosjekt. Gruppe 15

Forprosjektrapport For gruppe 20:

Forprosjektrapport for Agresso R&D Ansettelsessystem Hovedprosjekt våren Skrevet av:

Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008

Forprosjekt - Gruppe 12. Hovedprosjekt av

Kravspesifikasjon MetaView

Hovedprosjekt i ingeniørfag, data, våren Oslo Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo

Gruppelogg for hovedprosjekt 2009

Forprosjekt. Accenture Rune Waage,

Forprosjektrapport Bachelorprosjekt i data/informasjonsteknologi ved OsloMet Oslo / fredag, 19. januar 2018

PBL Barnehageweb. Brukerveiledning

KONTROLL INSIDE MSOLUTION

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD

Kandidat nr. 1, 2 og 3

Mandag : Onsdag : Torsdag : Mandag :

Tema: Oversikt over ansatt, rom, datamaskin, skjerm, software, hardvare og tilkoblingsanlegg.

Del VII: Kravspesifikasjon

Prosessrapport Prosjekt nr SSP Installasjon AS. Dato: 25.mai 2007 Antall sider: 11 Intern veileder: Kjetil Grønning. Kontaktperson: Kai Evjen

Forprosjekt. Oppgdragsgiver Unikia, Lille grensen 7, 0159 Oslo, Kontaktperson Anders Kose Nervold,

DinVikar - Bruker Manual

Gruppe 43. Hoved-Prosjekt Forprosjekt

Produktrapport. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23

Kravspesifikasjon. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23

HØGSKOLEN I OSLO OG AKERSHUS. FôrIt CDS. Avslutning

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet.

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen

Innstallasjon og oppsett av Wordpress

Prosessrapport. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23

1 Forord. Kravspesifikasjon

Entobutikk 4.PROSESSRAPPORT VÅR 2011

Prosjektdagbok Gruppe 18

Entobutikk FORPROSJEKTRAPPORT FOR ENTOBUTIKK VÅR 2011 LAGET AV GRUPPE 02

Forprosjekt for Accentures Overvåkningssystem

Hovedprosjekt 2011 HO912A. Securitas IT portal. Forprosjektrapport. Adeel Yousaf Khan s Mats Klingenberg Naustdal s Stig Arild Ysterud

Forprosjektrapport. Hovedprosjekt våren Gruppenr. H09E03. Bent-Henning Nesse Cheko Haji Abbasi Jon Espen Olsen

Utvikling av et nettbasert CMS med tilhørende nettsted for Axel Bruun Sport AS

TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS. Dataingeniørutdanningen, Høgskolen i Oslo GRUPPE 15. Kenneth Ådalen. Vegard Gulbrandsen

Forprosjektrapport. Gruppe 31

Transkript:

CharityDoctors

1. FORORD Beskrivelse i denne rapporten tar for seg hvordan prosjektet har vært utviklet i hele prosjekt perioden. Her forklarer vi hvordan prosessen har vært og begrunnelser for de valgene vi har gjort. Medlemmer av gruppen bak Charity Doctors er Muleha Nhonzi, Ntambwe Harlem Mufoncol og Ruban Amuthalingam. Gruppen kjenner hverandre siden første klasse og har jobbet sammen med andre prosjekter på høgskolen i Oslo. Da tiden for prosjektet nærmet seg, hadde gruppen allerede en tanke om å jobbe sammen. Selve prosjektet hadde vi ikke fått, men etter en møte med hovedprosjekt ansvarlig Thor Krattebøl, ble vi introdusert til flere oppdrager å velge mellom som hovedprosjekt. Der fant vi Charity Doctors og gruppen ble enige om å ta det oppdraget. Rapporten er beregnet for sensor og veilederen vår, men kan også leses av andre som har interessert å vite arbeidsmetodikken vi har brukt. Side 2

Side 3

2. INNHOLD 1. Forord 2 2. Innhold 4 3. Innledning 6 3.1 Om oppdragsgiver 6 3.2 Om prosjekt 6 3.3 Gruppen 7 3.4 Mål med oppgaven 7 4. Planlegging og metode 7 4.1 Forprosjektfasen 7 4.2 Implimentering 8 4.3 System og design 8 4.3.1 Verktøy 9 5 Valg av programmeringsspråk 9 6 Mål og rammebetingelser 9 7 Kravspesifikasjon 10 8 Fremdriftsplan 11 9 Arbeidstid 12 10 Utviklingsprossen 12 10.1 Prosjektfaser 13 10.2 Første utkast av Charity Doctors 15 10.3 Andre utkast av Charit Doctors 16 10.4 Tredje utkast av Charity Doctors 17 10.5 Fjerde utkast av Chaity Doctors 17 10.6 Timebestilling 18 11 Testfasen 20 12 Samarbeid 20 12.1 Samarbeid med veileder 20 12.2 Samarbeid med oppdragsgiver 21 13 Konklusjon 21 14 Kilder 21 Side 4

Side 5

3. INNLEDNING Inneholdet i dette kapittel handler om bakgrunnsinformasjon for prosjektet. I denne prosessraporten viser vi frem oppdragsgiver, gruppemedlemmer som har vært med i prosjektet og målet vi har satt oss i dette prosjektet. 3.1 Om oppdragsgiver Charity Doctors er et nyetablert uavhengig veledighetsforetak bestående av to leger. Organisasjonen ble stiftet januar 2010, og registrert som veledighetsforetak i Brønnøysundregisteret juni 2010. I samarbeid med Fattighuset i Oslo, som også er en uavhengig veledighetsorganisasjon har Charity Doctors fått et lokale i Fattighuset til disposisjon, der de kan drive deres virksomhet. Dette er et engasjement som drives på fritidsbasis. Organisasjonens formål er å fungere som et lavterskeltilbud for medisinske og helsemessige problemstillinger. Fattighusets brukere og andre som måtte ha behov for det kan ta nytte av tilbudet. Tilbudet er kostnadsfritt for brukere. Charity Doctors utfører enkle generelle helsetester. I tillegg tar de enkle blodprøver på kontoret. De kan måle følgende på kontoret: Hemoglobin CRP Blodsukker og langtidsblodsukker Charity Doctors har også avtale med eksterne laboratorier for mer avanserte blodprøver. Enkle undersøkelser med tanke på lungefunskjon kan også gjøres da de har et spirometer. Man får også rådgivning ved ønske om røykeslutt. Rådgivning ved spørsmål om kosthold og andre beslektede emner. A og B preparater skrives ikke ut på resept. Charity Doctors skriver heller ikke ut sykemeldinger. Charity Doctors har ingen kommunale eller statlige avtaler med tanke på refusjoner eller lignende. De har heller ingen andre inntektskilder. Organisasjonen er kun basert på egeninnsats og donasjoner fra privatpersoner/bedrifter som har ønsket å støtte vårt engasjement. 3.2 Om prosjektet Mange av fattighusets brukere er i vanskelige sosiale og/eller økonomiske situasjoner. Charity Doctors påstår at helsemessige problemstillinger i denne delen av befolkningen ofte kan bli oversett eller i verste fall forbli uoppdaget, mange ganger på grunn av nevnte vanskelige situasjoner. Et kostnadsfritt tilbud der man kan henvende seg med forespørsler som dreier seg om helse, vil etter CharityDoktors syn senke terskelen for å ta kontakt med helsevesenet. Side 6

Et system eller et område hvor kundene kunne gå til for å hente informasjon om deres organisasjon fantes ikke, årsaken er at det er en nyetablerte organisasjon. Charity Doctors hadde ikke noe bestillingssystem verken på data eller via telefon, derfor var oppgave våres å utvikle denne webløsningen helt fra bunnen av. CharityDoctors er tilgjengelige kun på søndager mellom klokken 12 og 15. Dette innebærte at det er lange køer hos dem. De ønsker en nettside som kan løse dagens problem. 3.2 Gruppen Gruppen består av Muleha Nhonzi, Ntambwe Harlem Munfocol og Ruban Amuthalingam. Vi har kjent hverandre siden første året på høyskolen i Oslo og har jobbet sammen ved flere andre prosjekter i utdanningstiden. Vi har ikke hatt noe vanskeligheter å finne et prosjekt eller firma å jobbe med. Det var allerede lagt opp flere forslag på hovedprosjekt sin nettside www.hio.no. Der fant vi et prosjekt som alle gruppemedlemene var mest interesserte å jobbe med. Det var bare å ta kontakt med oppdragsgiver og vi avtalte et møte med dem hvor vi hørte mer om behovene deres. 3.3 Mål med oppgaven Målet med dette prosjektet er at informasjon om Charity Doctors skal være tilgjengelig for pasienter/brukere. Charity Doctors skal kunne selv legge inn informasjon om deres organisasjon og behandle pasientenes registrerte opplysninger. Charity Doctors ønsket å ha en løsning hvor deres pasienter kunne bestille time hos dem. Så ut fra dette har vi utviklet dette systemet ved bruk av php og Mysql-database. 4. PLANNLEGING OG METODE I dette kapittelet skal vi redegjøre på hvordan vi planlagte oppbygging av applikasjonen, og hvilke metoder som skulle brukes. Siden vi ikke hadde noe liggende å gå fra, måtte alt skapes fra bunnen. 4.1 Forprosjektfasen Vi hadde et krav fra skolen om å utvikle en hjemmeside for hovedprosjekt hvor vi kunne legge dokumentene våres og veileder kunne ha tilgang til, samtidig ønsket oppdragsgiver seg en midlertid hjemmeside,hvor informasjon om deres organisasjon kunne være tilgjengelig. Vi hadde også tidsfrister for å levere statutsrapport og prosjektskisse. Mengden på arbeids kapasiteten ble mer på oss. Dette gjorde vi også samtidig gruppemedlemenes hadde tidsfrister og eksamer i andre fag. Med kravspesifikasjon i focus satt vi oss ned med oppdragsgiver for å få avklart hvordan funksjonaliten skulle være. Disse møtene med oppdragsgiver var veldig viktig under planleggingsfasen, vi da avklart mange spørsmål og krav. Gruppen jobbet sammen under hele planleggingsfasen slik at det skulle være enighet på hvordan prosjektet skulle løses. Denne fasen var spesielt viktig siden vi her planla disponeringen av tid som skulle brukes på hver fase ut prosjektperioden. Side 7

Prosjektdagbok Selve dagbok har vi skrevet på word tekstbehandling og lagt på dropbox. Der noterte vi arbeidet som var gjort og kommet til å gjøre fremover. Veileder Skolen hadde utdelt veiledere til alle gruppene. Veilederen vi hadde fått ga oss mer lys på hvordan vi kunne jobbe videre med selve prosjektet. Arbeidsplan Rett etter nytt år startet gruppen med forprosjekt. Det ble avtalt et møte med veileder hvor vi fikk råd om arbeidsprosessen ut i prosjekt tiden. Der ble ukentlige møter også avtalt. Arbeidsplanen vi hadde var basert på så grunnlaget for utvikling av en fremdriftsplan. I arbeidsplanen satt vi opp de forskjellige fasene vi sto ovenfor i tillegg til den vi da hadde vært gjennom, fasene ble så utdypet med forskjellige punkter som skulle gjennomføres og en beskrivelse av disse igjen. Før vi startet på å utvikle selve bestillingsystem, måtte vi avklarte kravspesifikasjonen til oppdragsgiver for godkjenning og samtidig leverte vi avtale kontrakten for underskrift. 4.2 Implimentering Da vi fikk levert hovedprosjekt oppgave av oppdragiver, fikk vi samtidig webplassen for systemet hvor det skulle lagres og kjøres. Men vi fikk ikke noe utviklinspråk kravsystem fra Charity, f.eks hva slags utviklingsspråk vi skulle bruke php,.net java osv.. I begynnelsen av prosjektet arbeidet, gruppen diskuterte hvilket språk vi skulle bruke. Men til slutt tok vi en beslutning at systemet måtte utvikles i PHP og MySql på grunn av at web serveren er en LINUX server og det vil si at den ikke støtter.net språk. Vi satt oss ned og diskurte om database modellingen, hvordan vi vil løse systemet, hva slags systemet vi vil hjelpe Charity Doctors med. Hva er ulempen eller fordel med systemet, om det er bruke vennelig for Charity Doctors? Vi brukte nesten tre dager for å diskutere dette problemet, fordi at Charity Doctors er tilgjengelig kun på søndager mellom kl12-15. 4.3 System og design Når vi så og leste oppdrags oppgaven fra Charity Doctors på høgskolens hovedprosjekt siden, skjønte vi da ca hvordan systemet skulle lages. Vi hadde også samme forventninger at vi trengte en webapplikasjons oppdrag. Vi tok med engang kontakt med Charity Doctors og vi fikk retten til å løse dette systemet for dem. Da vi møt dem for å høre om kravspesifikasjon, skjønte vi da at systemet måtte løses på en effektiv og letteste måtte slik at de kan spare tid. F.eks Charity Doctors er kun tilgjenlige noen timer på søndager, da syntes vi ikke at pasienter skal se alle dager i måned og hele 24 timer i kalanderen derfor løste vi dette systemet på enklere måtte. Side 8

Figur 1 : Admin kalender Under hele prosjekt utviklingen og implementasjonen av design til systemet, har vi benyttet seg av iterasjon utvikling. Fordi vi syntes at det er greit å teste alt vi utvikler heletiden før vi går videre til neste punkt. Noen ganger en del ting ble forandret slik at systemet får en bedre løsning. 4.3.1 Verktøy Vi har brukt en del verktøy gjennom hele prosjekt perioden både for å utvikle systemet og kommunisere i gruppe og for å kontakte oppdragsgiveren. Adobe Dreamweaver/ Notepad++ HTML, PHP og andre utviklings språkenene ble skrevet eller utviklet ved hjelp av Adobe Dreamweaver Database For å opprette databaser brukte vi MySQL Adobe Photoshop Brukte denne programmen for å redigere bilder og lage bilder. Microsoft Word Alle prosjekt rapportene ble skrevet i Word Dropbox.com Prosjekt fil lagring og filoverføringene skjedde gjennom Drobox tjenesten via nett i gruppen. Gmail / Facebook/Fronter I gruppen og mellom gruppen og oppdragsgiver hadde vi kontakt gjennom Gmail,Facebook og Fronter. Microsoft Visual 2010 og Rational Rose - Disse programmer ble brukt for å tegne diagrammer. 5 Valg av programmeringsspråk Vi valgte PHP, HTML, MySQL, JavaScript fordi, de fleste språkene var Open Source programmeringspråk. Siden Charity Doctors er et veldedighet organisasjon så syntes vi at vi måtte bruke programmeringspråk som ikke trengte innkjøp av utviklingsverktøy. Derfor ble disse språkene valgt overfor de andre. 6 Mål og rammebetingelser Formålet med dette prosjektet er at informasjon om Charity Doctors, skal være tilgjengelig for pasienter/brukere. Charity Doctors skal kunne selv legge inn informasjon om deres Organisasjon og behandle pasientenes opplysninger som adresse, navnet, etternavnet, og forandring av passordet. Side 9

Kravet fra Charity Doctors er å få en webside hvor de kan ha informasjon om deres Organisasjon og samtidig ha en løsning for å bestille time hos dem. Ut fra dette har vi tenkt å utvikle denne web- baserte løsningen ved å bruke php og Mysql-database. I dette systemet tar vi følgende funksjoner. Bruker/pasient: Tilgang til til informasjoner Tilgjengelige timer Time bestilling Avbestilling av time Kan oppdateres/slettes Disse kravene har blitt bestemt av Charity Doctors. Admin: Legge ut siste nytt/endre Oversikt over brukere Kan oppdatere/slette Charity Doctors hadde allerede domenet klart. Domenet ble kjøpt hos domeneshop.no. Da var det bare å få tilgang serveren. 7 Kravspesifikasjon Denne kravspesifikasjonen beskriver betingelsene for dette prosjektet. I dette dokumentet skriver vi krav til funksjonalitet til Charity Doctors prosjektet. Kravene og websidens grensesnitt er hentet fra deres ønske. Pasienten Side 10

Pasienten må være registrert for å bestille timen. Dersom pasienten allerede er registrert skal det være mulig å bestille timen. Når man velger å bestille timen, skal systemet vise 4 kommende søndager med datoer og tilgjenglige / utilgjengelige timer. Det er mulighet til å utvide de dagene fremover om arbeidsgiver ønsker det. Pasienten kan velge ledige time og bestille. Systemet skal også kunne avbestilles. Pasienten skal kunne endre opplysningene sine ved å logge inn. Registreringsskjema I registreringsskjema skal pasienten fylle fornavn, etternavn, telefon, e-post(valgfri) og passord(velger selv). E-post skal være valgfri siden Charity Doctors antar at ikke alle har tilgang til e-posten. Blogg/sistenytt Charity Doctors skal kunne publisere nyheter via administrator siden. De skal kunne redigere/slette dersom de har behov. De siste skal komme automatisk på forsiden. Administrator Administrator området skal være passordbeskyttet. Oversikt over pasientlister. Og de skal ha tilgang til å endre pasient data. Administrator skal ha oversikt over bestilte timene. De skal kunne legge inn sistenytt, kunne redigere og samtidig slette. Tekniske krav Løsningen utvikles i PHP. For å gi brukere levende opplevelse bruker vi samtidig HTML, CSS, JavaScript og jquery. Vi bruker Adobe Dreamwever og notepad++ for utvikling. Datalagring Alle dataene blir lagret i en ekstern server i MySql database hos domeneshop.no. Validering av data skal skje i kliet maskinen. Passordet til pasientene skal krypteres i mysql-server Mer om kravspesifikasjonen er redegjort i Kapittel 4 i Produktdokumentasjonen. Dette Kapittel bør leses før resten av prosessdokumentasjonen. 8 Fremdriftsplan I begynnelsen av prosjektet hadde vi en samtale med oppdragsgiver for å få mer informasjon om deres organisasjon. Charity Doctors hadde allerede skissert en webside på papir. Dette gikk vi sammen gjennom og diskuterte om hvordan vi kunne løse det. Vi også kom med små forslaget på hvordan hjemmesiden deres skulle se bedre ut. Gruppen ga Charity Doctors forslag om å lage to forskjellige websider med forskjellige utseende og selvfølgelig uferdig sider. Dette ble vi enige om med Charity Doctors. Etter at vi hadde lagd ferdig de to sidene, bestemte Oppdragsgiver å beholde den de likte best. Møte med Charity Doctors ga oss motivasjon til å komme igang med selve prosjektet. Etter at vi hadde lagd mål og rammebetingelse samt kravspesifikasjonen var skissert ut, laget vi en fremdriftsplan tilpasset tidsrammen på fem måneder. Side 11

9 Arbeidstid Alle i gruppa tar ekstra fag og jobber ved siden av. Dermed har vi delt arbeidsplan på en passende arbeidstid for hver av gruppe medlemmene. Slik ser arbeidstid ut. Mandag: Hovedprosjekt kl 09:30-18 Tirsdag: Hovedprosjekt kl 16-21 Onsdag: fag, Møte med veileder kl 14:15-14:45, Hovedprosjekt 15-20 Torsdag: Hovedprosjekt 16-21 Fredag: valgfag, Arbeidsdag hos ekstern arbeidsgiver 10. Utviklingsprossen Under dette prosjektet har vi lagt opp en arbeidsstruktur etter fossefallsmodellen. Fossefallsmodellen stammer fra en mer utopisk ingeniørtradisjon hvor en fase må bli ferdig før en annen kan påbegynnes. Fossefallmetoden har begrensninger til for eksempel endringer i kravspesifikasjon da man måtte ha gått tilbake til tidligere faser. Krav Design Gjennomføring I vår problemstilling har vi forholdt oss til en fast kravspesifikasjon, og tilnærmingen til løsningen har virket veldig systematisk og stegvis. Vi har analysert krav, designet og til sist realisert produktet ved implementering. Dette prosjektet ble påbegynt for alvor rett etter nyttår andre uke i januar, hvor vi hadde samtaler både med oppdragsgiver og veileder for å planlegge og tilrettelegge for et mest mulig funksjonibelt system innen de gitte grenser. Side 12

10.1 Prosjekts faser Gruppen hadde ikke noe utfordringer til å finne et passende prosjekt. Som nevnt var prosjektet allerede lagt på hovedprosjektshjemmeside. Vi hadde allerede gått gjennom disse fasene før vi startet på selve forprosjektfasen etter nyttår. Følgende innledende fase ble gjort: Prosjektshjemmeside Vi utviklet en hjemmeside hvor vi la dokummentene våres på et av gruppemedlemmenes sitt private domene. Figur2: Prosjekts hjemmeside. Statusrapport Var ferdig utviklet og lagt ut på prosjekts hjemmeside den 29.10.2010 Prosjektskisse En beskrivelse av prosjektet så langt med informasjon om oppdragsgiver, kontaktperson og gruppemedlemmer. Den ble lagt ut på prosjekts hjemmesiden den 03.12.2010. Vi hadde avtalt et møte med Charity Doctors om hvordan nettsiden deres skulle utvikles. Dette møte fant sted på et av de gruppe romene på høyskole i Oslo. Charity Doctors hadde en prototype på papir av hjemmeside. Bilde nedenfor viser prototypen av hjemmeside som arbeidsgiver kom med. Side 13

Figur 3: prototype av arbeidsgiver Vi gikk gjennom sammen og diskurterte på hvordan den webbaserte løsningen skulle se ut. Gruppen kom med noe forslag på hvordan den skulle forbedres. Den var uenigheter inni imellom men vi kom på en løsning. Charity Doctors består av 2 leger, en man og en kvinne. Det var noe forslaget vi hadde kommet med som den manlige lege likte mens den kvinnelige lege ikke likte. Så til slutt for å gjøre det enklere for dem, bestemte gruppen om å designe 2 forskjellige nettsider å velge mellom. Charity Doctors var enige med oss og vi da avtalte nytt møte hvor vi kunne presentere de 2 nettsidene. Vi hadde en god møte med dem som også gjorde at vi ble bedre kjent sammen. Før vi skulle utvikle hjemmeside, lagde vi en prototype på hvordan en hjemmeside skulle se ut. Dette hjalp oss å holde oversikt under utviklingen. Bilde under viser prototype av hjemmeside Side 14

Figur4: prototype av charity Doctors hjemmeside Når vi skulle begynne med selve system utviklingen begynte vi med å designe selve layouten, både på frontend og bakend av siden. Vi i gruppen syntes at det vil være lettere å begynne med slikt, slik at det skulle bli lettere å plugge inn data modulen når vi begynner med databaser osv.. Da satte vi gang med å lage layout deler i forskjellige deler, f.eks header, main osv. Samtidig testet vi alle layoutene i hele utviklingsfasen om det fungerte. Etter at layount delen var ferdig og vi var fornøyde, tok vi kursen mot selve systemsutviklings delen. 10.2 Første utkast av CharityDoctors Bilde under viser det første utkastet vi kom med til Charity Doctor Figur 5: første utkast til Charity Doctors Denne hjemmeside var første hjemmeside vi kom med som forslag til Charity Doctors. Gruppen designet et logo til Charity Doctors siden de ikke hadde det fra tidligere av. Denne logoen designet vi med tanke på navnet til arbeidsgiver. De likte utseende, men var litt forsiktig med bildene og ville ikke ha noe med logo å gjøre. De ville helst ha bare navnet av organisasjon deres som logo. Den Side 15

kvinnelige lege likte layouten mest enn den manlige lege. Så var det bare å vise dem den andre utkastet. 10.3 Andre utkast av CharityDoctors Bilde under viser andre utkast av hjemmeside vi hadde til arbeidsgiver. figur 6: andre utkast Denne utkast likte begge legene bedre men de ville beholde fargene fra den første utkastet. Den hadde også mangel på språk del og reklame. Da måtte vi lage den tredje utkast. Midlertid nettside om deres organisasjon ville Charity Doctors ha, men på grunn av mye forandringer heletiden, var ikke nettsiden på serveren før januar. Bilde på neste side viser den tredje utkast av Charity Doctors Side 16

10.4 tredje utkast av CharityDoctors Figur 7: den tredje utkast I denne utkast lagde vi noe ekstra ikoner i menyen. Disse ikonene var tenkt til å være mer brukervennlig til navigasjon, men arbeidsgiver ville ikke ha noe med ikoner å gjøre, så måtte vi fjerne dem. De også ville ha disse forskriftene på venstre siden og små forandriger på tekstene. Ellers var layouten bra. Så vi måtte lage den absolute endelige utkast. Vi ga dem forslag på om vi kunne legge inn skrift størrelse ved siden av språket. I følge universiel utforming, er det viktig å ha slike ting. Det likte de, det var bare å utvikle hjemmesiden videre. 10.5 Den fjerde utkast av CharityDoctors Bilde under viser den fjerde og endelige utkast. Figur 8 : den fjerde og endelige utkast Side 17

Denne utkast likte arbeidsgiver og det gjorde vi også. Det var en lettelse for oss å få den gjort. Hjemmesiden har vært online siden januar, fordi at Charity ville ha en midlertid hjemmeside om deres organisasjon. Det har vært mulighet til å lese nyheter men ikke bestille timer. Små forbedringer har vært inn i mellom heleveien. Bilde under viser Utviklingsprosess av hjemmeside. Figur 9: utviklingsprosess av Charity Doctors hjemmeside. Her kan vi se hvordan hele prosessen av hjemmeside ble utviklet. 10.6 Timebestilling system Diskusjon på hvordan timebestillingen skulle se ut tok mer tid. Dette område var det ingenting med arbeidsgiveren å gjøre. Gruppen har måtte besteme selv, siden det er bare de registrerte som kan se de timene. Der tenkte vi på hvor enklest mulig måtte systemet skulle være for de registrerte pasienter og administratoren. Bilde på neste sider viser prototype av timebestilling for pasient. Side 18

figur: 10 prototype1 av timebestilling for pasient Gruppen var usikker på hvordan utviklingen av time bestilling skulle se ut, vi visste ikke hvordan vi skulle gjøre det. Gruppen var på et klasserom på høyskole i Oslo, der skisserte vi flere systemet valg av timebestilling på tavla, og gikk gjennom sammen. Bilde under viser hvordan gruppen jobbet under timebestilling Figur 11: prototype2 av timebestilling Siden Charity Doctors jobber kun en dag, det vil si bare på søndager fra klokken 12 til 15, tenkte vi at det ikke er noe mening å vise fram hele kalenderen for pasienten for å finne bare søndager. Dette syntes vi var tungvint. Dersom Charity Doctors ombestemer seg senere om å jobbe andre dager enn på en søndag, kan de velge det selv gjennom kalederen. Derfor valgte vi denne løsning. Om oppdragsgiver jobber andre dager i fremtiden da er det enklere å utvikle systemet til denne løsningen. Vi også tenkte at systemet skal være veldig enkel for charity å velge for fleksibelt arbeidsdag og lettere for en pasient å velge dag og tid. Systemet gir kalender lista for Charity admin del for å velge arbeidsdag enn på SØNDAGER. Pasientene kan kun se de 4 neste tilgjengelige dager gjennom bestillingsystem. Side 19

Dette gjorde det at vi brukte mer tid på det på systembestilling. Vi hadde også tenkt at passienten kunne velge time via check boks, der etter ble det en diskusjon på det på hvordan systemet skulle kobles mot database men vi kom på en løsning til slutt på hvordan det skulle se ut. Bilder under viser timebestilling for pasient. Figure 12: Timebestilling for pasient Denne løsningen var det den enkleste løsning vi kom på. Vi har her lagt inn symboler og forklart betydningen for å gjøre det så enkelt som mulig å forstå. 11 Testfasen Selve testen har vi gått gjennom heleveien. Derfor skriver vi litt her om det. Vi har sjekket alle feilene som oppstå og rettet samtidig. Språk del har vi ikke fått det helt til på Charity doctors serveren, men vi har allerede utviklet det på en av gruppens serveren. Vi utviklet språket i det første utkastet som oppdragsgiver ikke ønsket, der fungerte det bra. Her er linken hvor vi beviser at språket fungerer. http://www.amirunt.no/charity. Alle engelske ordene som skal være på hjemmeside er klært, det fikk vi oppdragsgiver til å skrive. Alt ligger i funksjonene men nekter å virke i serveren til charity Doctors. På grunn av kort tid ville vi jobbe med det videre etter innleveringen av dokummentasjonen. Gruppen ønsker at oppdragsgiver skal være fornøyd med resultatet vi har gjort. 12 Samarbeid Her beskrives hvordan samarbeidet med veileder og oppdragsgiver har fungert 12.1 Samarbeid med veileder Eva Hadler Vihovde har vært våres veileder. Etter nytt år fikk vi henne som veileder. Vi ble enige om å ha en ukentlige møter. Side 20

Vi har fått gode veiledning på hvordan dokumentene vi har jobbet med skulle se ut og har fått en god veiledning igjennom heleprosjektet. 12.2 Samarbeid med oppdragsgiver Samarbeid med oppdragsgiver har fungert bra. Vi har hatt en god kommunikasjon sammen. Tingene gruppen lurte på fikk vi svaret på uten noe problemer, men det eneste probleme vi hadde var at oppdragsgiver ønsket en midlertid hjemmeside som innholdte informasjon om deres organisasjon. Med en gang nettside var publisert, ønsket de mer fra oss. Det virket som de ville ha en hjemmeside klært med engang, men målet vårt med dette prosjektet var å bli ferdig med produktet i slutten av mai. Så vi følte at det ble en press på oss. 14 KONKLUSJON www.charitydoctors.com oppbyggingen har vært en veldig lærerik prosess. Vi fikk lære om objektorientert programmering, det å sette kunnskapen ut i praksis for oss er da det mest viktige vi har gjort opp til nå gjennom studiene våres, ihvertfall det mest spennendes. Applikasjonen er et viktig verktøy for legene, siden de ikke har et fast telefon nummer som de kan bli kontaktet direkte til. Og nå skal pasientene endelig få mulighet å bestille time istedenfor å møte opp og vente lenge i fattighusets trange venteromene. Applikasjonen skal ikke brukes til å føre journal om enkelte pasientene kun for å ha en oversikt over bestilte timer og å vise gjennom nyheter hva Charity Doctors har fått i donasjon. Vi fikk noen reaksjoner fra to pasienter som besøker Charity Doctors regelmessig og de syns at det var bra at legene fikk et system for det de kalte for kaos. Det var mange på venteromet noen ganger, rakk ikke legene å ta imot alle. Vi er veldig fornøyde med det vi har gjort, denne bacheloroppgaven har vært med å øke vår selvtillit når det gjelder det å bevise i fremtiden vår kunnskap om PhP. Og vi synes at produktet er vel bygd og at applikasjonen tilfredstiller kravene som ble stilt av legene også at vi hadde lagt til og med litt ekstra enn det de trengte, fordi de ville ha noe veldig enkelt. 15 Kilder www.charitydoctors.com Tidligere hovedprosjekt sider på hio.no Bilder ble hentet fra google.com utenom header/charitylogo Språk løsning er fra toturials på nette. Side 21