Hovedprosjekt Høgskolen i Oslo og Akershus Gruppe

Transkript

1 Hovedprosjekt Høgskolen i Oslo og Akershus Gruppe Kristine Jorde Cavallini s Andreas Tranberg Hårsaker s Anders Brown Ranvik s180478

2 PROSJEKT NR Studieprogram: Anvendt datateknologi og Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL NxStage DATO ANTALL SIDER / BILAG 139 / 2 PROSJEKTDELTAKERE Kristine Jorde Cavallini s (3DA) Andreas Tranberg Hårsaker s (3DA) Anders Brown Ranvik s (3IA) INTERN VEILEDER Omar al-khayat OPPDRAGSGIVER OneMed KONTAKTPERSON Geir Hårsaker geir.haarsaker@onemed.com SAMMENDRAG Dette er hovedprosjektrapporten for Gruppe 36 ved anvendt datateknologi- og informasjonsteknologilinjene ved HiOA våren 2014 Prosjektet innebar utvikling av et system for bruk I OneMed som lar bedriften holde oversikt over utleide NxStage-apparater. Dokumentet inneholder følgende deler: Introduksjon til oppgaven & kravspesifikasjon Prosessdokumentasjon Produktdokumentasjon Testdokumentasjon Brukerveiledninger Samt to vedlegg. 3 STIKKORD Dialyse-apparat Objektorientert PHP Nettside

3 Sammendrag Dette er rapporten for hovedprosjektet til gruppe 36 ved anvendt datateknologi- og informasjonsteknologilinjene ved HiOA våren Dette dokumentet er hovedsakelig for veileder, sensor, og arbeidsgiver. Dokumentet inneholder følgende deler: 1. Introduksjon til oppgaven & kravspesifikasjon 2. Prosessdokumentasjon 3. Produktdokumentasjon 4. Testdokumentasjon 5. Brukerveiledninger Samt følgende vedlegg: 1. Bedriftens akseptansebrev 2. Avtale om konfidensialitet Hver enkelt av de 5 hoveddelene inneholder innholdsfortegnelser for den aktuelle delen.

4 1 Introduksjon til oppgaven & kravspesifikasjon 1

5 Sammendrag Denne rapporten er en introduksjon til oppgaven og kravspesifikasjonen for gruppe 36 ved anvendt datateknologi- og informasjonsteknologilinjene ved HiOA våren 2014, og beskriver prosjektets innledende fase. I dokumentasjonen finnes informasjon om gruppen, oppdragsgiver, bakgrunn for prosjektet, systembeskrivelse, og kravspesifikasjon, samt rammekrav og datamodell. Dette dokumentet er hovedsakelig for veileder, sensor, og arbeidsgiver. Det forutsettes generell ITkunnskap. 2

6 Innhold Sammendrag... 2 Innledning... 4 Gruppen... 4 Oppgaven... 4 Oppdragsgiver... 4 Veileder... 4 Forord... 5 Om Bakgrunnen... 5 Leserveiledning... 5 Systembeskrivelse... 6 Systemets kravspesifikasjon... 6 Rammekrav... 7 Sikring mot tap, ødeleggelse, tyveri, og misbruk av data... 7 Kapasitet... 7 Fremtidig utvidelse av systemet... 7 Brukervennlighet... 7 Logisk datamodell... 8 Dokumentasjonskrav

7 Innledning Gruppen Vi er gruppe 36 og består av Kristine Jorde Cavallini (s177485) og Andreas Tranberg Hårsaker (s170109) fra 3. året anvendt datateknologi og Anders Brown Ranvik (s180478) fra 3. året informasjonsteknologi på Høgskolen i Oslo og Akershus. Oppgaven For et medisinsk apparat som ikke selges til kundene men i stedet lånes/leies ut, trenger OneMed noen som kan lage et utlånssystem for å holde oversikt over utlånte apparater og hvor de til enhver tid befinner seg. Dette systemet skal være tilgjengelig for selgerne i den norske delen av bedriften, og det ønskes en web-løsning som man kan ha tilgang til uansett hvor man befinner seg. Oppdragsgiver Vår oppdragsgiver er OneMed som selger medisinske forbruksvarer, som for eksempel engangshansker, engangsmateriell for operasjon, anestesi og intensivavdelinger, i tillegg til å leie ut dialysemaskiner til sykehus og andre institusjoner. Vi har kontakt med dem gjennom Logistikk- og IT-sjef Geir Hårsaker. Han kan kontaktes på geir.haarsaker@onemed.com eller Telefon nummer / Veileder Vår veileder er Omar al-khayat. Han jobber som postdoktor på Simula Research Laboratory på Fornebu. Han har kunnskaper om software-utvikling i Python og C++. 4

8 Forord Hensikten med kravspesifisering er å kartlegge nøyaktig hva bedriften ønsker at systemet skal kunne gjøre, og for å lage en liste over nødvendige funksjoner for at dette skal fungere. Dette gjør at arbeidet blir mer fokusert og kan deles opp i flere mindre oppgaver. I tillegg vil spesifikasjonen gjøre det klart for både bedriften og gruppen hva som skal til for at oppgaven regnes som fullført. Kravspesifikasjonen spiller en svært viktig rolle i prosjektet, da den gir utviklerne klare retningslinjer for hvilke funksjoner bedriften ønsker prioritert. Om Bakgrunnen OneMed er en bedrift som importerer, markedsfører og selger medisinske forbruksvarer og helsepleieprodukter. OneMed-gruppen en av de største leverandørene av helsepleieprodukter i Nord- Europa og betjener både det offentlige og det private markedet. OneMeds norske selskap er en av de minste, men de har et nært samarbeid med Sverige og selger hovedsakelig sine produkter til sykehus. Prosjektet vårt omhandler det bærbare dialyseapparatet NxStage, som lånes ut til pasienter (enkeltpersoner) via et sykehus. OneMed har pr. i dag 15 maskiner som de har oversikt over i et Excelark i bedriften. Dette Excel-arket er ikke oversiktlig hvis det kommer flere maskiner. I tillegg er flere av maskinene allerede feilført eller ført på en måte som ikke følger standarden. Antall utlånte maskiner er forventet å øke. OneMed trenger de et system som er enkelt å bruke og som vil gi dem oversikt over hvilke maskiner som er hvor og hvem som har ansvaret for disse. Det er ønskelig at systemet er nettbasert så de omreisende selgerne kan gjøre endringer og oppdateringer uansett hvor de måtte befinne seg. Et slikt system kan også fungere som et lett tilgjengelig oppslagsværk for å sjekke detaljer for allerede utlånte apparater. Det må være mulig å legge til nye maskiner, endre alle detaljer og å få oversikt over hvilke maskiner som er hvor. Det skal også være mulig å se en enkel service-historie for hver maskin og hva den har av eventuelt tilleggsutstyr. Programmet kan i tillegg utvides med en administratordel som kan opprette, redigere og slette brukere. I tillegg bør denne kunne legge til flere typer tilleggsutstyr til maskinene og på andre måter redigere siden og den tilhørende databasen. Leserveiledning Kravspesifikasjonen organiseres i to kategorier: funksjonelle, og ikke-funksjonelle krav. Funksjonelle krav er hva systemet gjør, hvordan det skal oppføre seg, og hva det ikke skal gjøre. Ikke-funksjonelle krav er de kravene som ikke har noe med hva systemet gjør, men eventuelle rammer som tid, standarder, og kvalitet. 5

9 Systembeskrivelse Systemet som gruppen utvikler skal erstatte måten OneMed per i dag holder oversikt over sine NxStage-apparater. I stedet for en rotete Excel-ark vil en web-basert applikasjon vil gjøre det enklere og raskere for brukerne å vise og endre informasjonen tilknyttet apparatene, samtidig som det gir en økt sikkerhet mht. utilsiktet sletting av data, samt gikk et kvalitetssikret underlag for bruk mot eksternt revisjonsfirma (I OneMed menes det at nåværende Excel-ark ikke gir god nok dokumentasjon og sporbar dokumentasjon i revisjonssammenheng). Systemet vil ta form av en nettside hvor man kan liste ut informasjonen om apparater, legge til og endre avtaler som apparatene er knyttet til, legge til nye apparater og apparatkomponenter, og styre status for disse. Excel-arket som bedriften har brukt tidligere har vært uoversiktlig, og i enkelte tilfeller har ting blitt innført feil. Dette kan fort skape problemer for bedriften. Systemet som gruppen skal utvikle vil, som nevnt over, gjøre det enklere å holde oversikt over apparatene og avtalene, slik at dette ikke kan skje. Systemets kravspesifikasjon Hensikten med systemet er å gi oppdragsgiver muligheter for å holde oversikt over utlån av apparater (Avtale), hvor apparatet består av flere individer. På ett apparat kan individer (komponenter) byttes ut i forbindelse med service. Ett apparat kan flyttes fra én låntaker til en annen (Avtalen flyttes), eller returneres til oppdragsgiver eller produsent. Én avtale vil alltid bestå av ett apparat, hvor apparatet består av fire til fem forskjellige komponenter, dvs. én av hvert artikkeltype. Systemet skal ha følgende funksjonelle krav: Bruker skal kunne definere: o Nye kunder o Nye maskiner o Nye avtaler o Nye kontaktpersoner Bruker skal kunne koble: o Avtale til kunde o Kontaktperson til avtale o Maskin til avtale Bruker skal kunne statusstyre: o Avtale o Maskin o Avtale/Maskin-kombinasjon Mulig administratorkonto skal kunne: o Administrere brukere (legge til, fjerne, endre) o Administrere brukernes tilganger (lese, skrive) o Kun administrator skal kunne slette poster i databasen Alle brukere skal kunne: o Endre status på elementer/records o Endre avtaledata 6

10 o o Maskindata Søke frem avtaler og individer med tilhørende data Systemet skal ha følgende ikke-funksjonelle krav: Brukervennlighet: o Systemet skal være lett å bruke og lære o Feilmeldinger skal være lette å forstå o Det skal være problemfritt å navigere o Lettfattelige brukermanualer for vanlige brukere og administrator Teknologi som skal brukes: o PHP 5 (objektorientert) o HTML 5 o CSS o MySQL Følgende sikkerhetsmetoder skal tas i bruk: Design: o Nettsidens utseende skal være konsistent med OneMeds generelle bruk av skriftstørrelser, logoer og fargevalg Rammekrav Sikring mot tap, ødeleggelse, tyveri, og misbruk av data Bedriften har egne rutiner for drift, sikring og backup av systemer, og det vil derfor anbefales at de følger disse for sikring av dette systemet slik de gjør med sine allerede eksisterende systemer. Kapasitet Per i dag er det 15 NxStage-maskiner som lånes ut til kunder. Det vil bli lagt til rette for at systemet skal kunne håndtere en forventet økning i antall maskiner og komponenter i fremtiden. Fremtidig utvidelse av systemet Systemet bygges i objektorientert PHP, som vil si at det vil bli modulært og dermed enkelt å utvide hvis det er ønskelig eller nødvendig for bedriften. Alt skal være kommentert og ha beskrivende navn slik at det er enkelt for andre utviklere å forstå koden. Det er valgt å kommentere på norsk, siden dette systemet er for den norske delen av bedriften. Hvis OneMed senere ønsker å bruke systemet i flere land er norsk også forstålig for hovedkontoret i Sverige hvor eventuel programerings endringer vil utføres. Brukervennlighet Brukerne som skal interagere med systemet innehar ikke nødvendigvis mye erfaring og kunnskap om bruk av datamaskiner. Derfor er det viktig at systemet ikke er for komplisert eller for vanskelig å tyde for dem. Dette skal sikres gjennom grundig testing når systemet er funksjonelt. 7

11 Logisk datamodell Figur 1 - Den logiske datamodellen for systemet Hensikten med systemet er å gi oppdragsgiver muligheter for å holde oversikt over utlån av apparater, som beskrevet i hver ankelt av kundeavtalene. Én kundeavtale vil alltid bestå av ett apparat, en kunde (sykehus) og to kontaktpersoner (tilsatte ved sykehuset). Alle disse opplysningene skal kunne lagres og endres i systemet. (se Figur 1). Dokumentasjonskrav OneMed ønsker at det skal leveres brukermanualer og dokumentasjon både for de vanlige brukerne og systemadministrator. 8

12 Ordbok Apparat: En NxStage-dialysemaskin. Ett apparat består av 4 til 5 forskjellige komponenter som kan skiftes ut. Komponent: Delene som et apparat består av. Det er 5 forskjellige komponenter. Hvert av disse har et serienummer definert av leverandør. Kontaktperson: Person(er) som har ansvaret for apparatet, som regel leger og ingeniører/teknisk personell ved sykehuset. Kunde: Sykehuset eller klinikken som apparatet leies ut til. Kundeavtale: Avtale om leie av apparat som er inngått med kunde. En kundeavtale omhandler alltid et apparat, en kunde og to kontaktpersoner. 9

13 2 Prosessdokumentasjon 1

14 Sammendrag Dette er prosessdokumentasjonen for hovedprosjektet til gruppe 36 ved anvendt datateknologi- og informasjonsteknologilinjene ved HiOA våren 2014, og beskriver hovedprosjektet fra start til slutt. I dette dokumentet finnes informasjon om arbeidsmetodikk, hjelpemidler, teknologivalg, og prosjektets resultat med konklusjon. Denne dokumentasjonen er hovedsakelig for veileder, sensor og arbeidsgiver. Rapporten krever generell forståelse av IT-systemer, samt noe kunnskap om systemutvikling og kode. 2

15 Innhold Sammendrag... 2 Utviklingsprosessen... 4 Planlegging... 4 Arbeidsplan... 4 Risikohåndtering... 7 Valg av teknologi og utviklingsverktøy... 9 Valg av utviklingsmetodikk Hovedelementer i prosjektutføringen Om kode Utfordringer Erfaringer og konklusjon Tidsaspekt og tidspress Kunnskapsnivå Prosjektgjennomføringen Testing og gjennomføring av testing Kommunikasjon med oppdragsgiver Kommunikasjon med veileder Gruppens egne meninger om gjennomføring Konklusjon Etiske og juridiske betraktninger Kilder

16 Utviklingsprosessen Planlegging Gruppen ble sammensatt da to av medlemmene som begge går på anvendt datateknologi-studiet bestemte seg for å jobbe sammen om hovedprosjektet. Det tredje medlemmet ble funnet gjennom Fronter ved at man sendte ut en til alle studentene på teknologistudiene, hvor det ble avertert etter flere medlemmer til gruppen. Oppgaven ble funnet gjennom bekjente i bedriften OneMed, som trengte et system for å erstatte den nåværende løsning for å holde kontroll på deres NxStage dialysemaskiner og utlån av disse. I starten av prosjektperioden holdt vi et møte hvor vi diskuterte oppgaven og bestemte oss for hvordan vi ønsket å behandle den. Forslag til løsninger og teknologi ble nøye gjennomgått og skrevet ned. Til slutt ble det besluttet at PHP var ønsket programmeringsspråk å bruke til utvikling av et nettbassert system. Objektorientering gjør koden mer oversiktlig, gjennbrukbar og lett å modifisere og er standaren innen flere av de større moderne programeringsspråkene som java og C++. Det innebar en ekstra utfordring å programere objektorientert ettersom mesteparten av gruppens erfaringe med PHP var i prosedural programmering. Det ble også avtalt en generell timeplan for møter, vi kom fram til at vi måtte ha minst to gruppe møter i uken med mulighet for andre møter, for eksempel med veileder, utenom dette. Prosjektskissen ble fullført samme dag. Vi møtte så vår veileder Omar al-khayat ved Simula Research Laboratory på Fornebu. Hos han fikk vi gode råd og en pekepinn på hvordan vi burde gå frem ved utførelsen av prosjektet. For at et prosjekt skal lykkes, er det viktig å bruke tiden man har til rådighet godt. 24 uker høres mye ut, men i virkeligheten oppleves det som at tiden bare flyr avsted. Derfor valgte gruppen å sette opp arbeids- og fremdriftsplaner, både for å kartlegge hvilke oppgaver som skal gjøres og hvor lang tid man har på å utføre disse. Disse planene ble som følger: Arbeidsplan De underliggende avsnittene gir en overordnet oversikt over oppgavene som må utføres: Planlegging og oppstart (dokumentasjon) I denne perioden er fokuset på å planlegge og å skissere opp prosjektet. Vi møter bedriften og veileder. Vi bestemmer verktøy og tidspunkt for når oppgaver skal gjøres. Dette skrives ned i fremdriftsplan, kravspesifikasjon, prosjektskisse og forprosjektrapport. Møter med bedriften (møte med firma) Brukes til å ta avgjørelser om hva bedriften ønsker, hva som er gjort bra og hva som eventuelt kan eller bør endres. Disse møtene er svært viktige for å lage et produkt firmaet er fornøyd med. Utvikle første prototype (programmering) Det skal lages en high-fidelity prototype som med lite arbeid kan forandres til et ferdig produkt. Denne skal være basert på den endelige databasen. Denne prototypen skal være noe som kan vises og diskuteres med firmaer for å lage et endelig produkt de er fornøyd med. 4

17 Utvikle prototype til ferdig produkt (programmering) Å utvikle prototypen til et endelig produkt er i utgangspunktet en liten jobb, da prototypen skal være high-fidelity og svært lik det endelige produktet. Grunnen til at det er satt av lang tid til dette er at det antagelig vil være ønskelig å endre eller videreutvikle prototypen i henhold til bedriftens ønsker. Denne perioden vil hovedsakelig brukes på å utvide og tilpasse prototypen til bedriftens ønsker. Testing (testing) Dette vil i stor grad måtte gjøres under hele prosjektet og ikke bare i den avsatte perioden, men i denne perioden skal fokuset på testing være enda høyere. I tillegg er det i denne perioden ønskelig å få systemet testet av oss, veileder, bedrift og andre frivillige for å sjekke at alt fungerer tilfredsstillende. Arbeid med dokumentasjon (dokumentasjon) Arbeid med dokumentasjon vil utføres under hele perioden med ekstra fokus under begynnelsen og slutten av prosjektet. Det er likevel bestemt at det skal føres dagbok/logg under hele prosjektperioden og at alle avgjørelser skal dokumenteres underveis, mens beslutningene blir tatt. Vise bedriften det ferdige produktet (møte med bedrift) Dette vil kunne ta litt tid, da dette også innebærer å presentere dokumentasjon og brukerveiledninger både skriftlig og muntlig. Ferdigskriving av rapport (dokumentasjon) Dette vil være i fokus den siste måneden mens og etter vi leverer det endelige produktet til bedriften. Rettelse av rapport (dokumentasjon) Dette vil også gjøres under hele prosessen men vil de siste to ukene av prosjektet være hovedfokuset til hele gruppen. Fremdriftsplan Vi har valgt å presentere fremdriftsplanen vår i et Gantt-diagram, som er en type søylediagram som viser et prosjekts gang fra start til slutt. Dette diagrammet finnes på neste side. Vi har valgt dette da denne typen diagram tydelig viser 2 dimensjoner (oppgaver og tid) og hvordan vi har valgt å fordele disse. Oppgavene har fått ulike farger for å skille seg ut på diagrammet. Tidsfordelingen er det vi har sett for oss ville vært ideelt med tanke på en vellykket gjennomførelse av prosjektet, men gruppen vet at det er sjeldent at et prosjekt klarer å følger tidsplanen nøyaktig. Dokumentasjon Programmering Forhåndsatte krav Møte med bedrift Testing Planlegging og oppstart. 5

18 Oppgave Ansvar Uke Planlegging og oppstart Møter firma alle alle Levere forprosjektrapport alle Utvikle første prototype Fungerende prototype kan vises til bedriften alle Utvikle fra prototype til ferdig produkt Testing Arbeid med dokumentasjon Vise bedrift det ferdige nettsted (produkt) Ferdigskriving av rapport Rettelse av rapport Levere prosjektrapport i ekspedisjonen Presentasjon alle alle alle Dette diagrammet viser planlagt tid fordelt på oppgaver. I hver av disse ukene er det minst 2 gruppemøter og en del hjemmearbeid. 6

19 Milepælsplan I tillegg til arbeids- og fremdriftsplanene, valgte vi også å sette opp en milepælsplan med spesifikke datoer. Da prosjektet bød på mange utfordringer ble de færreste av disse møtt. Dato Plan Beskrivelse Prosjektstart Prototype En enkel fungerende versjon av nettsiden kan vises til bedriften Nettsiden er ferdigstilt Rapporten er ferdig skrevet Alt innhold er på plass i rapporten Rapporten er ferdigstilt Rapporten er ferdigstilt, korrekturlest osv Innlevering Frist for å levere inn prosjektrapporten og kildekoden Presentasjon Presentasjon av prosjektet Risikohåndtering I et prosjekt med et visst omfang er det viktig å forutse risikoer, problemer og kriser som kan oppstå, og ha strategier klare for å håndtere disse. Vi diskuterte oss fram til de vanligste risikoene, satte oppe en liste, og hva som skulle gjøres hvis noen av disse oppsto. Ut fra denne listen ble denne tabellen utarbeidet: Risiko Sannsynlighet Skadeomfang Forebyggende tiltak Respons Kortvarig sykdom. Langvarig sykdom. Tekniske problemer. Høy sannsynlighet. Liten sannsynlighet. Medium sannsynlighet. Gruppemedlem(er) kan bli forsinket med sine oppgaver. Hvis gruppemedlem(er) blir borte over lenger tid kan prosjektet forsinkes kraftig, og kvaliteten på arbeidet kan synke betraktelig. Prosjektet kan bli forsinket mens Det er lite som kan gjøres for å forebygge ting som sesongforkjølelser o.l. utenom å holde oss generelt sunne. Godt arbeidsmiljø. Passe på at utstyr og teknologi som brukes Enten å fortsette å jobbe gjennom sykdomsperioden hvis mulig, eventuelt la andre gruppemedlemmer midlertidig ta seg av det foreliggende dersom det er viktig og tidsbegrenset. Umiddelbart få problemet fikset. 7

20 Risiko Sannsynlighet Skadeomfang Forebyggende tiltak Respons Tap av data Konflikter innad i gruppen. Bortfall av medlemmer. Manglende kompetanse. Motivasjonsfall. Medium sannsynlighet. Lav sannsynlighet. Lav sannsynlighet. Hele gruppen er motivert og innstilt på å fullføre prosjektet. Medium sannsynlighet. Medium sannsynlighet. problemene blir utredet og fikset. Mengden av data som tapes kan forårsake at prosjektet forsinkes til den grad at gruppen ikke klarer å gjenskape dataen i tide. I verste fall kan prosjektet mislykkes helt. Forsinkelse i prosjektet pga. dårlig samarbeid og kommunikasjon. Forsinkelse i prosjektet, lav kvalitet eller at hele prosjektet mislykkes pga. manglende arbeidskraft. Forsinkelse eller manglende kvalitet på prosjektet. Forsinkelse i prosjektet. vedlikeholdes på riktig måte og behandles pent. Ha backup-utstyr klart. Backup-kopier av all kode og data på flere steder, blant annet på Dropbox, eventuelt på minnepinner som en siste sikring. Å ha et godt arbeidsmiljø og diskutere eventuelle problemer før de kan utvikle seg. Godt arbeidsmiljø. Alle setter seg inn i teknologien og teknikker som skal brukes. Ha klare retningslinjer og mål som er innen rekkevidde - dette vil hjelpe med stress og manglende motivasjon Gjenopprette tapt data med backup-kopi Umiddelbart prøve å løse konflikten mellom oss, eventuelt skaffe hjelp via megling. Endre prosjektet slik at det blir gjennomførbart med resterende gruppemedlemmer. Hvis nødvendig, omfordele oppgaver slik at gruppemedlem(er) kan bidra på områder de kan. 8

21 Valg av teknologi og utviklingsverktøy Basert på møter med bedriften og diskusjon innad i gruppen ble det bestemt at produktet egner seg best som en nettside med tilhørende database som viser informasjonen som er relevant for brukeren. Avgjørelsen om at systemet skulle være nettbasert ble hovedsakelig gjort på grunnlag om at systemet skulle være tilgjengelig uansett hvor brukerne var, eller hvilken datamaskin de hadde med seg. Det var også viktig at dette traff innenfor gruppens kompetanse, der hovedvekten ligger nettopp på utviklingen av nettsider. I tillegg vil ikke systemet bli spesielt stort, og gruppen var veldig opptatte av at utviklingen ikke skulle kompliseres mer enn nødvendig. I løpet av prosjektet ble det bestemt at det ikke var ønskelig for bedriften å integrere systemet i deres servere, ettersom dette krever mye jobb for dem og godkjennelse fra OneMeds hovedkontor. Dermed skulle systemet som gruppen utvikler kjøres på en klargjort terminal dedikert til dette - i dette tilfellet en laptop-datamaskin. Hadde dette vært tydelig i starten av prosjektet hadde gruppen antageligvis laget et lite program som kunne vært installert og kjørt på en maskin, utviklet i for eksempel java. Siden dette kom frem forholdsvis langt inn i prosjektet og gruppen lenge hadde planlagt og startet å lage et nettside bassert system, ble det avgjort å fortsette med dette. Dette gir også OneMed mulighet til å med små modifiseringer å legge sytemet ut på en server senere, hvis det er ønskelig. På bakgrunn av dette, ble følgende teknologier valgt for utviklingen: Objektorientert PHP 5 PHP 5 er et programmeringsspråk som brukes for å utvikle dynamiske nettsider, og språket som gruppen utvilsomt var best kjent med i begynnelsen av prosjektet, da vi har gjennomført to kurs i dette. Det ble bestemt at all programmering skulle gjøres objektorientert, da dette vil gjøre systemet modulært, oversiktlig, og enkelt å modifisere. Det vil også være en ekstra utfordring fordi gruppen er mer kjent med prosedural programmering. Selv om løsningen slik den blir levert skal installeres på og skal brukes på én enkeltstående PC gir PHP-løsningen muligheter for fremtidig flytting til server i nettverket og da være tilgjengelig for flere brukere via web-grensesnitt. HTML 5 CSS HTML (HyperText Markup Language) brukes til utvikling av selve rammeverket til systemet. Gruppen er kjent med dette språket gjennom kurs på HiOA. Det er denne versjonen av HTML som er mest utbredt og som fungerer best på alle nettlesere. CSS (Cascading Style Sheets) brukes til å utforme utseendet til rammeverket. Dette er nødvendig for at nettsiden skal oppfylle OneMeds krav til farger, skrifttype og generell utforming. Igjen er gruppen kjent med dette gjennom kurs på HiOA. XAMPP-pakken XAMPP-pakken er en fri (open-source) programvarepakke distribuert av Apache Friends som består av Apache HTTP Server, MySQL, og tolker for programmeringsspråkene PHP og Perl. 9

22 Siden systemet skal kjøres på én maskin uten tilknytning til andre servere, er det nødvendig med en webserver, som Apache, som kan utføre funksjonene i PHP-scriptene. MySQL er et SQL-basert relasjonsdatabasesystem. Gruppen har god erfaring i bruken av dette, og vil derfor utvikle databasen i dette. I tillegg til denne programvaren følger det også med et grafisk brukergrensesnitt for samhandling med MySQL-systemet, kalt PHPMyAdmin, som vil gjøre det enklere og raskere å utvikle databasen. Dropbox Det er viktig at all relevant prosjektdata samles på ett sted som gruppen alltid kan få tilgang til uansett hvor de er. Dropbox egner seg utmerket til dette, og også som en backup-løsning. Hvis dataen lagres på Dropbox, lokalt på egne maskiner, og på eksterne lagringsmedier, vil ikke tap av data være en stor risiko. Javascript JSON Javascript er et skriptspråk som primært anvendes til å tilføre en nettside dynamiske elementer, som endring av tekst avhengig av hvor på siden man klikker, åpning av pop-up-vinduer o.l. JavaScript er nødvendig for at systemets individuelle funksjoner skal passe inn i rammeverket, pluss at man slipper å ha separate og individuelle sider for hver eneste funksjon. JSON (JavaScript Object Notation) er en standard for å utveksle data mellom en server og en webapplikasjon, og et alternativ til XML. Gruppen har lite erfaring med denne, og avgjørelsen om å bruke dette ble tatt i midten av prosjektet etter at andre alternativer med PHP og HTML var utprøvd. Dette innebar en ekstra utfordring, men gjorde systemet enklere å bruke, med automatisk utfylling av felt, når man søker eller endrer noe i databasen. NetBeans IDE Valget av NetBeans som utviklingsmiljøet vi ønsket å bruke stammer mest ut fra det faktum at det er det primære utviklingsmiljøet vi er blitt kjent med på HiOA, og vi har brukt det mye i tidligere fag, spesielt innen programmering av PHP og HTML. I dette programmet følger det også med en innebygget debugger, som vil være meget nyttig for å oppdage feil som ellers kan være vanskelig å oppdage. SourceTree SourceTree er en gratis Git- og Mercurial-klient for Windows og Mac. I starten av prosjektet hadde ingen i gruppen noe erfaring med versjonskontroll eller håndtering av kildekode, og ble rådet til å sette oss inn i dette av veileder. SourceTree har et grafisk brukergrensesnitt, og var enklere å bruke enn flere andre programmer som primært kjører via kommandolinje. 10

23 Valg av utviklingsmetodikk Det var viktig i begynnelsen av prosjektet å finne en utviklingsmetodikk slik at det ikke blir sløsing av tid. Etter en del lesing og diskusjon kom gruppen fram til at det var ønskelig å følge prinsippene i metoden Extreme Programming, heretter kalt XP. Denne utviklingsmetodener valgt fordi den ligner mest på metodene vi har brukt i tidligere prosjekter. Dette er en metodikk vi kunne være komfortable med helt fra begynnelsen i prosjektet, i stedet for å måtte bytte metodikk underveis fordi en ukjent metodikk ikke fungerte. Det ble gjort enkelte småendringer på metodikken underveis, men ikke nok til å kunne kalle den noe annet. Agile XP er en agile, eller smidig, utviklingsmetode. Agile methods er et samlebegrep for en rekke programvareutviklingsmetoder som er avhengige av en inkrementell tilnærming av spesifisering, utvikling, og levering av programvare. De passer best for prosjekter hvor funksjonelle krav fort kan endres. Kunden er ofte dypt involvert, og får fort levert fungerende versjoner av produktet som de deretter kan teste, og foreslå endringer som fortløpende kan bli gjort i senere iterasjoner. Målet er å kutte ned på unødvendig bruk av tid på planlegging av hvordan produktet skal utvikles fremfor selve utviklingen og testingen. Det finnes et eget manifest for smidig utvikling som forklarer filosofien bak det hele, kalt "The Agile Manifesto", eller "Manifestet for smidig programvareutvikling" på norsk. Dette manifestet sier: Vi finner bedre måter å utvikle programvare på ved å gjøre det selv og ved å hjelpe andre med det. Gjennom dette arbeidet har vi lært oss å verdsette følgende: Personer og samspill fremfor prosesser og verktøy Programvare som virker fremfor omfattende dokumentasjon Samarbeid med kunden fremfor kontraktsforhandlinger Å reagere på endringer fremfor å følge en plan Dette vil si: Selv om punktene som står til høyre har verdi, så verdsetter vi punktene til venstre enda høyere. (Agile Alliance, 2001) Å bruke annet enn en smidige metode for vårt prosjekt ville vært tungvint med tanke på størrelsen, da vårt produkt er relativt lite. Vi var avhengige av å kunne enhetsteste produktiterasjonene kontinuerlig under utviklingen, og det var viktig for oss at kunden fikk se hva vi holdt på med og om vi var på rett spor når det gjaldt funksjonene de ønsket å få på plass. I tillegg kunne det bli nødvendig med mange endringer underveis, fra begges sider. Kanskje ønsket kunden å ha flere funksjoner, eller kanskje måtte vi endre taktikk på grunn av uoverkommelige problemer. 11

24 Extreme Programming XP er en av de mest kjente og brukte agile-utviklingsmetodene. Den fikk dette navnet fordi den går ut på å dytte god praksis, som iterativ utvikling, til "ekstreme" høyder. Den følger en utgivelsessyklus som kan sees i Figur 1. Figur 1 - Extreme Programming utgivelsessyklus I XP blir krav uttrykt som scenarioer, også kalt brukerhistorier. Disse brukerhistoriene blir så brutt ned til enkelte "tasks", eller oppgaver. Gruppen utviklet brukerhistoriene som kan sees i Figur 2. Figur 2 - Brukerhistorier som brytes ned til oppgaver 12

25 Disse brukerhistoriene ble brutt ned til mindre oppgaver, det vil si funksjonene systemet skulle ha. I hovedtrekk har vi fulgt XPs prinsipper under utviklingen, dog med enkelte endringer for å tilpasse arbeidsflyten til vår erfaring både med prosjektarbeid og teknologien vi utviklet i. Prinsippene til XP er som følger: 1. Inkrementell utvikling støttes gjennom små, hyppige utgivelser av systemet. 2. Kunden er involvert gjennom hele utviklingsprosessen, gjerne som en del av utviklingsteamet, og er med på å definere akseptansetester for systemet. 3. Personer, ikke prosesser, støttes via parprogrammering, kollektivt eierskap av systemkoden og en bærekraftig utviklingsprosess som ikke involverer kjempelange arbeidstider. 4. Endringer omfavnes gjennom regelmessige systemutgivelser til kunden, "test først"- utvikling, og kontinuerlig integrasjon av ny funksjonalitet. 5. Å opprettholde enkelhet gjøres gjennom konstant omgjøring som forbedrer kodekvalitet og ved å bruke enkel design som ikke unødvendig forventer framtidige endringer av systemet. For at prosjektet skulle fungere opptimalt, ble det gjort noen små justeringer. På grunn av systemets størrelse ville det være unødvendig med regelmessige utgivelser - det ville kun tatt opp unødvendig mye tid. I stedet ble ferdige funksjoner kontinuerlig presentert og vist til kunden, som da kommenterte og foreslo endringer som da ble vurdert og eventuelt tatt med i neste iterasjon av disse funksjonene. Gruppen er ikke stor nok til at parprogrammering ville vært mulig, da vi kun er 3 medlemmer. I stedet ble det under møtene gjennomgått kode, diskutert mulige løsninger, programmert og testet. Det ble en slags "workshop" under hvert møte, som bidro godt til arbeidet generelt. Dette var de nødvendige endringene, og vi føler at disse har kun bidratt positivt til utviklingen. Hovedelementer i prosjektutføringen Ut ifra Gantt-diagrammets inngående elementer har vi valgt å fremheve følgende fire punkter og gitt videre kommentarer på disse ettersom de er de mest sentrale punktene som er verdt å kommentere spesielt: Oppstart De første ukene av prosjektet ble satt av til planlegging av alt som skulle gjøres, estimering av tidsforbruk, og første møter med bedriften og intern veileder. Under disse møtene ble forprosjektrapporten, med prosjektets forhåndssatte krav, utarbeidet og levert. Så ble kravspesifikasjonen satt sammen med kontaktpersonen fra bedriften, i tillegg til brukerhistoriene som skulle brytes ned til oppgaver. Arbeidsmetoden ble så avtalt. Oppgavene basert på brukerhistoriene ble fordelt på gruppemedlemmene. Programmering og dokumentasjon skulle hovedsakelig gjøres som hjemmearbeid, men det skulle holdes gruppemøter 2-3 ganger i uken, både for at gruppen skulle klare å holde tidsfrister, og for å holde hverandre oppdatert på hva som foregikk. Lengdene på disse møtene varierte ofte, men de ble aldri avsluttet før alle hadde fått utalt seg, fått eventuelle problemer løst og 13

26 spørsmål besvart og beskrevet oppgaver som måtte gjøres til neste møte. Kode og dokumentasjon ble gjennomgått og endret hvis nødvendig - det var viktig at alle fikk sagt sin mening om disse. Møter med bedrift Til sammen ble det holdt 4 "store" møter med bedriften, der gruppen tilbrakte store deler av dagen på OneMeds kontorer og jobbet. I tillegg ble det under hele prosjektperioden holdt jevnlig kontakt med kontaktperson i bedriften, som ble underrettet om systemet og dets utvikling. Kontaktpersonen fikk se tidlige versjoner av funksjonene som skulle inngå i systemet og ble informert om databasen og hvordan den ville fungere. Rammeverket, altså nettsiden (HTML-koden) som systemet skulle bygges inn i, ble også nøye gjennomgått med kontaktpersonen slik at utformingen, fargevalg, osv. stemmet overens med OneMeds generelle grafiske stil, dog dette var ikke så viktig ettersom systemet kun er beregnet på intern bruk og ikke skal være bedriftens ansikt utad. Hvis kontaktpersonen ønsket endringer, ble disse diskutert både innad i gruppen og med han. Hvis det ble besluttet at endringen ville være gjennomførbar, ville den bli implementert i neste inkrement av systemet. Likeledes ble kontaktperson involvert i avgjørelser om endringer som gruppen følte var nødvendige. Det ble tidlig i samarbeidet med bedriften bestemt at ny funksjonalitet som måtte tilkomme underveis i prosjektet eller under testingen, skulle behandles som "change request" - og kun gjennomføres dersom tilgjengelig tid i prosjektet tillot slike endringer. Møte med veileder Ettersom gruppen har jobbet mest på skolen, har vi valgt å benytte oss av ressursene tilgjengelige her, blant annet faglærer i PHP, Tor Krattebøl. Det ble holdt en del møter med veileder i starten av prosjektet, men det ble færre etter hvert som prosjektet kom ordentlig i gang, både fordi vi følte at vi hadde kontroll på prosjektet, og fordi vi følte at vi ikke trengte å dra så langt fordi vi hadde den nødvendige PHP-kompetansen tilgjengelig på HiOA. Dokumentasjon Dokumentasjonen av prosjektet startet fra første dag i prosjektet med kravspesifikasjonen, som er del 1 av hovedprosjektrapporten. Prosessrapporten ble startet under det første møtet, med oppsett av risikoplan og fremdriftsplan, og senere utfylt da utviklingsmetoden ble valgt. Denne delen av rapporten ble det kontinuelig jobbet med underveis i prosjektperioden. Produktrapporten ble påbegynt etter hvert som enkelte deler av systemet ble ferdig, og godkjent av gruppen og kontaktperson fra bedriften. En prosjektdagbok på Dropbox ble vedlikeholdt både for å holde styr på møteskjemaet, i tillegg til at den fungerte som en logg for hva som ble gjort når. Testrapporten ble påbegynt mot slutten av prosjektet, da den endelige prototypen ble ferdigstilt og klargjort for bedriften, og ferdigstilt da både gruppen og bedriften så seg fornøyde med produktet. Det ble satt opp et "skjelett" av brukerveiledningen i forbindelse med den endelige akseptansetestingen, og denne ble så gjort ferdig da systemet ble sett på som "ferdig". Testing I tillegg til den endelige akseptansetestingen som ble gjort på slutten av prosjektet, ble det kontinuerlig gjort enhetstesting under utviklingen, både av gruppen og kontaktpersonen. Dette var for å sikre at all 14

27 funksjonalitet var på plass før alt ble satt inn i rammeverket, og at funksjonaliteten oppfylte kravene til bedriften. Mer informasjon om testingen generelt finnes i del 4 av hovedprosjektrapporten, Testrapporten. Om kode All kode er skrevet og kommentert (der det er nødvendig) hovedsaklig på norsk fordi det er tvilsomt at andre enn norskspråklige utviklere kommer til å lese eller endre på systemet etter utgivelse. Informasjon om selve koden og utviklingen av denne finnes i Produktrapporten. Utfordringer Det er ikke uvanlig å møte utfordringer og vanskeligheter under utviklingsprosjekter. Vårt var intet unntak. Utfordingene vi har møtt har i stor grad blitt løst fortløpende og ofte har de forskjellige gruppemedlemmene hjulpet hverandre å løse små problemer med databaser, koden eller nettsiden skjennerelt. Her har vi valgt å skrive om de utfordringene som har påvirket gruppen i større grad og over lengere tid. Den største utfordringen har utvilsomt vært selve kodingen. Ingen av gruppemedlemmene hadde noen videre erfaring med objektorientert PHP i starten av prosjektet, og mye tid har gått med på å tilegne oss kunnskap om dette. Det å sette opp en relevant og kjørbar objektorientert PHP fil var noe som var vanskligere og tok flere timer enn hva som var tiltenkt. Organiseringen og navngivning av kode i et så stort prosjekt var også en utfordring. Dette systemet kunne bygges opp hvordan gruppen selv ønsket, uten at noen hadde noen videre erfaring og preferanser om hva som kunne være god organisering av kode og database i begynnelsen av prosjektet. Dette har medført at mange av filene og databasetabellene har måttet bytte navn i løpet av utviklingsperioden, noe som også førte til ekstra arbeid for programmererne. Bruken av JSON for dynamiske søk i databasen under utfylling av skjemaer viste seg også å være vanskligere enn forventet og medbrakte egne problemer for eksempel ved bruk av Æ, Ø og Å. Et annet problem som oppsto underveis var at det plutselig ble umulig med flere brukere og passord i systemet. Ikke engang konsultasjon med faglærer resulterte i en løsning på dette. Som en følge av problemer med kodingen, ble det vanskelig å møte de fastsatte tidsfristene. Deler av Gantt-diagrammet vårt ble forskjøvet til fordel for mer tid til å programmere systemet. Et eksempel på dette er akseptansetestingen, som egentlig skulle finne sted i midten av april, men måtte flyttes til begynnelsen av mai. Vi møtte også vanskeligheter i form av en avgjørelse vi måtte ta litt under halvveis i utviklingsperioden, da det viste seg at det ikke ville bli mulig å integrere systemet i OneMeds lokale nettverk, da dette krever tillatelse fra OneMeds hovedkontor og mye jobb med sikring. Dette ville tatt for mye tid, i tillegg til at det var tvilsomt at hovedkontoret ville gått med på det. Hadde denne opplysningen blitt oppdaget tidligere i prosjektet, ville gruppen kanskje vurdert å utvikle systemet i et annet språk som ville resultert i et program som ble kjørt lokalt på Pcen i stedet, utviklet i foreksempel Java. Dessverre ville denne endringen tatt for lang tid og at gruppen ville måtte sette seg inn i Java, noe som, igjen, ville vært tidkrevend og resultert i et dårligere prosjekt. Derfor valgte vi å fortsette å utvikle systemet i PHP, selv om dette ikke lenger var den optimale løsningen. 15

28 Det har også vært møtt på mange mindre utfordringer, for eksempel var flere gruppemedlemmer kortvarig syke under prosjektperioden. Dette ble løst som foreslått i risikoplanen ved at den som var syk fremdeles gjorde oppgavene i den grad de var istand til det, eller ba de andre gruppemedlemmene om hjelp hvis de hadde kritiske oppgaver som måtte utføres. Det er hele tiden hvert kontinuelig kontakt over Facebook, men det er ikke altid like lett å vite i hvilken grad beskjeder der er blitt motatt av de andre gruppemedlemmene. Skulle dette prosjektet vært gjort på nytt hadde vi kanskje laget klarere retningslinjer for dette. Andre problemer vi har møtt på har hovedsakelig vært på grunn av koden. Æ, Ø, Å-problematikken har flere ganger fått oss til å riste fortvilet på hodet og febrilsk lete etter problemet, helt til et av gruppemedlemmene husket å sjekke databasen for disse. Å lage fungerende SQL-setninger som inneholder flere enn en tabell og få satt disse riktig inn i PHP-koden er også en ting som har tatt overaskende mye tid, da et tegnfeil her er vanskelig å oppdage og har kunnet tatt opptil flere timer å oppdage og løse. Å få til det riktige utseendet ved å stille parametere i CSS-filen har tatt oppmerksomheten til flere av gruppemøtene. Disse kodeproblemene var bare et lite utdrag av småproblemene vi møtte under prosjektet. Dette kan regnes som småfeil og det var på forhånd forventet at vi skulle møte på flere av disse. Det største problemet med disse var at utfordringene kunne være tidkrevende å løse, og tiden var noe som plutselig rant ut veldig fort under dette prosjektet. 16

29 Erfaringer og konklusjon Dette prosjektet har utvilsomt vært det største og mest omfattende prosjektet som gruppens medlemmer har jobbet med. Det har vært krevende og til tider vanskelig, men også lærerikt og erfaringsmessig nyttig for fremtiden hvis det er denne typen jobber vi vil ende opp i. Da tidligere prosjekter under utdanningen ved HiOA har vært relativt korte i varighet og størrelse, har dette hovedprosjektet gitt oss en rekke erfaringer i ulike aspekter ved arbeid av denne typen. Disse erfaringene, samt konklusjon, følger nedenfor. Tidsaspekt og tidspress Dette prosjektet har vart hele vårsemesteret 2014, med forberedende arbeid på slutten av høstsemesteret Fem måneder, for oss, virket som et hav av tid i begynnelsen, men vi merket mer og mer tidsklemma jo lenger ut i prosjektet vi kom. Mesteparten av tiden i prosjektet har blitt brukt til selve utviklingen av systemet, dvs. nettsiden, funksjonene og databasen, og resten ble brukt til å skrive rapporten. Vi mener selv at vi har brukt tiden godt, men det er kanskje noen ting som kunne vært gjort litt mer effektivt. For eksempel brukt vi en del tid på planleggingen av prosjektet i begynnelsen av januar, og det kunne ha vært en fordel å ha begynt med programmeringen samtidig, ettersom det er programmeringen som har bydd på den største utfordringen under prosjektet. Det ble satt en rekke tidsfrister og milepæler under planleggingen. Få av disse ble møtt, da utviklingen av systemet viste seg å by på flere vanskeligheter enn vi hadde forutsett. Allikevel ble systemet ferdiggjort og etter to runder med testing, akseptert av bedriften ettersom det oppfylte kravene som ble fremsatt i begynnelsen av prosjektet. Kunnskapsnivå Gruppemedlemmene var klare over at vi ikke hadde all kunnskapen som krevdes for å fullføre systemet fra begynnelsen. Ingen hadde utviklet et så stort system som dette før, og hadde heller ikke mye erfaring med objektorientert PHP-programmering. Dette betydde at vi måtte tilegne oss kunnskap om dette, både gjennom lesing av teori og øvelse. Selv om vi hadde kunnskap om databaser og utviklingen av disse fra før, måtte vi lære en del om dette også, spesielt med tanke på forenkling og dobbeltlagring. Dette resulterte i at den første prototypen av databasen, som bestod av 9 tabeller, ble redusert til 4 i den ferdige versjonen. Alt i alt har gruppen tilegnet seg mye kunnskap om selve utviklingen av systemer, i tillegg til hvordan det er å jobbe med slike prosjekter. Dette vil utvilsomt være verdifullt for fremtiden. Prosjektgjennomføringen Som tidligere nevnt har ikke gruppens medlemmer jobbet med et prosjekt på denne størrelsen før. Det var én ting å skulle utvikle et system, men det å holde "koken" under hele perioden, og å holde oversikten over alt sammen har vært en utfordring. Det har i perioder også måttet bli tatt hensyn til gruppemedlemmer som har obligatoriske oppgaver og eksamner i andre fag. Motivasjonen har vært høy stort sett under hele perioden, men dalte litt i perioder der det var stort press andre steder. Mot slutten av prosjektet steg motivasjonen og arbeidsviljen igjen da tidspresset ble mer tydelig og produktet begynte å fungerte riktig og å se bra ut. 17

30 Rapporten har også bydd på utfordringer, da ingen av oss har skrevet en så omfattende gjennomgang av et prosjekt før. Dette er nyttig kunnskap, ettersom IT-bransjen involverer mye rapportskriving. Testing og gjennomføring av testing Gruppen har hele tiden vært klare over hvor viktig det er med brukertesting, både for å sikre at systemet oppfyller bedriftens krav til funksjonalitet og utforming, og for å oppdage feil og mangler som gruppen selv kan ha vært "blinde" for. Det ble ikke oppdaget mange grove feil under den første brukertestingen. Noen småfeil ble oppdaget, mens forbedringer ble foreslått, inkludert felttillegg i databasen som gruppen ikke hadde vært klare over tidligere. Andre brukertest fant kun to punkter som kunne endres/forbedres, og deretter ble systemet akseptert. Mer om dette kan man lese i Testrapporten. Som en følge av småfeilene gruppen selv ikke hadde sett, fikk gruppmedlemmene bedre forståelse av hvorfor brukertesting er utrolig viktig i forbindelse med prosjekter som dette. Brukertestingen i vårt prosjekt ble utført litt sent og skulle dette bli gjort igjen hadde det blitt gjort tidligere. Da hadde gruppen fått mer tid til å programmere og å rette over koden etter brukertestingen i sluttfasen av prosjektet. Kommunikasjon med oppdragsgiver Extreme Programming involverer kunden i stor grad i utviklingen. Gruppen har vært i kontinuelig kontakt med OneMed under hele prosjektperioden i tillegg til de store møtene. Kontakten med bedriften har vært til stor hjelp for at vi hele tiden beveget oss i riktig retning med systemet. Vi føler også at OneMeds representant har satt pris på dette, da han har kunnet komme med forslag underveis. På denne måten har systemet blitt utformet etter både gruppens og kundens ønsker. Kommunikasjon med veileder Møter med veilederen for prosjektet har vært veldig nyttige for å sette opp en slags "løype" for prosjektet, dvs. hva vi bør gjøre, når, og hvordan. Uten disse hadde nok prosjektet blitt gjennomført annerledes, og sannsynligvis ikke like godt. Gruppen kunne kanskje ha vært mer aktive og oppsøkt veileder i sammenheng med problemstillingene, men vi ser i ettertid at det at vi ikke gjorde det har tvunget oss til å lære mer på egenhånd for å finne gode løsninger. Gruppens egne meninger om gjennomføring Til tross for enkelte problemer underveis med programmeringen og andre ting, mener gruppen at prosjektet har blitt gjennomført på en god måte, og som gruppemedlemmene selv føler vi kan være stolte av. Én ting som kunne vært bedre under selve gjennomføringen av prosjektet, har vært kommunikasjonen gruppen imellom utenom møtene. Denne kommunikasjonen har stort sett gått over Facebook-gruppen som vi opprettet i begynnelsen av prosjektet, og det har ikke alltid vært like klart om alle medlemmene har fått med seg beskjedene som ble lagt ut her. Dette har ikke forårsaket noen større vanskeligheter, da gruppemøtene har vært hyppige nok til at beskjedene også kunne gjentas der og alle alltid er 18

31 tilgjengelige over telefon. Likevel er dette noe man kan ha i tankene til neste prosjekt hvor elektroniske kommunikasjonsmidler tas i bruk. Konklusjon Få, hvis noen, prosjekter fullføres uten problemer. Vårt var intet unntak. Flere tidsfrister og milepæler ble ikke møtt, enkelte deler av prosjektet måtte endres eller gjøres om, programmeringsproblemer oppstod, osv. Allikevel ble systemet fullført etter bedriftens ønsker og krav, og akseptert, og gruppen mener selv at vi har gjort en god jobb og at prosjektet kan ansees som vellykket - både sett fra gruppens og oppdragsgivers ståsted (se Vedlegg 1 med tilbakemelding fra oppdragsgiver). Nettsiden vår både ser pen ut, er enkel å bruke og oppfyller alle bedriftens viktigste krav. Det er også blitt lært mange nye ting, både om systemutvikling generelt, og prosjektarbeid på denne skalaen. Læringskurven har i perioder vært bratt og det største læringsutbytte kommer utvilsomt fra programmeringen og utfordringene vi har måttet løse her. Etter diskusjon i gruppen kommer det frem at alle gruppemedlemmene sitter igjen med følelsen av at de har blitt mye bedre i objektorientert PHP. Vi har klart å møte alle kravene som bedriften satte frem i begynnelsen av prosjektet. Vi kan derfor konkludere at produktet, i forhold til arbeidsgivers absolutte krav, er ferdig og klart til å tas i bruk av bedriften. Figur 3 viser systemets forside. Figur 3 - Systemets forside 19

32 Etiske og juridiske betraktninger I forbindelse med lagring av informasjon om NxStage-apparatene ville vi få tilgang til reelle data om spesifikke personer og kontaktpersonopplysninger hos OneMeds kunder. På grunn av dette satte OneMed et krav om at all informasjon som ble tilegnet underveis måtte holdes konfidensielt, og derfor ble det utarbeidet en konfidensialitetsavtale om dette, undertegnet av alle gruppemedlemmene og kontaktperson hos OneMed, som ligger som Vedlegg 2 i slutten av Hovedprosjektrapporten. Gruppen ønsker å påpeke at vi ikke har hatt tilgang til sensitive pasientdata, fordi systemet ikke inneholder pasientopplysninger. Den eneste informasjonen vi har hatt tilgang til er kundedata og data om kontaktpersoner hos kundene, dvs. sykehusene. 20