Forprosjektrapport. Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus

Transkript

1 Presentasjon Gruppenummer: 21 Forprosjektrapport Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Gruppemedlemmer: Guro Asbjørnsen, Ester Jansson, Marius Skalstad og Eigil Johansen. Periode: til Oppdrasgiver: Dr. Akram org: Kontaktperson: Mohammed Usman Akram Tlf: Mail: usmanakram10@hotmail.com Veileder: Oppgave: Thor E. Hasle. thor.hasle@hioa.no Lage et nettsted for Oslo Vaksineklinikk. Sammendrag Oppgaven vår går ut på å utvikle et nettsted for bestilling av vaksiner for Oslo Vaksineklinikk. Her skal kunden kunne bestille time for vaksinering og betale denne gjennom en faktura eller eventuelt PayPal. Gjennom en animert globus eller et animert kart skal du kunne få opp vaksineinformasjon i det aktuelle landet du velger. Du skal også kunne skrive spørsmål i et diskusjonsforum og få svar fra Dr.Akram. Dagens situasjon Oppdragsgiveren vår arbeider som turnuslege og ønsker å etablere en nettbasert vaksineklinikk som han kan arbeide med ved siden av den faste jobben. Han pendler mellom Oslo og Skien, men ønsker at vaksineklinikken skal holde sted i Oslo. Vårt oppdrag er å lage et nettstedet som skal gi informasjon om hvilke vaksiner man behøver til forskjellige land, bestilling av time til vaksinering og et forum hvor man kan få svar på spørsmål. Det er oppdragsgiver som skal stå for informasjonen som skal være på nettstedet. 1

2 Mål og rammebetingelser Vi har følgene mål som vi skal forholde oss til ved krav om ferdig produkt: 1. Nettsted skal være lett tilgjengelig og universelt utformet. 2. Nettstedet skal være godt søkeoptimalisert 3. Det skal være et integrert forum i systemet med mulighet for innlogging slik at kunder kan opprette brukere. 4. I sammenheng med disse brukerne skal kunden også kunne se historie på alle tidligere timer og eventuelle bestlite timer. 5. Nettstedet skal ha et integrert faktureringssystem for både kunder og oppdragsgiver. Mulig integrering av tjenester som Paypal eller Payex. 6. Interaktivt kart hvor brukere skal kunne klikke seg til valgt destinasjon og få opp informasjon om sykdommer og anbefalte vaksiner. 7. En stor del av nettstedet må være klart til sent mars. Løsninger /alternativer Struktur av side Egenkode(HTML,CSS etc) Mal(Bootstrap,Wordpress etc) Mal mens vi lager finpussen Vi har selv full kontroll på hva slags kode vi skriver. Har også alle muligheter åpne når det gjelder tilgjengelig teknologi. Tidsspørsmål Vi slipper å kode strukturen selv. Enklere å lage og bruker mindre tid. Mere oversiktiktlig for legen hvis han skal endre ting i senere tid. Alle alternativer er kanskje ikke tilgjengelig for den aktuelle malen. Fordelen: Ting tar kort tid og vi kan fokusere mer på de viktige funksjonene. Dårlig kvalitet. Og oppgaven kan bli sett på som mindre omfangende. 2

3 Faktureringssystem bruk av en kjent plattform (Paypal, sikker E-handel osv) Troverdig betalingsform. Koster en liten andel av transaksjoner. Krever en egen bruker. Har ikke like bred målgruppe som andre løsninger (som oftest personer med middels til høy teknologisk forståelse) Giro Mulighet for kontant betaling. omfatter en stor målgruppe. kan kombineres med kjente plattformer som Paypal Krever selvlaget system for at legen har en historie-oversikt. krever integrering med og posten. Egetutviklet system Kan få til en integrering med diverse banker for trygg handel. Mister mye troverdighet. Kan støte på en del problemer. Trygg handel integrering vil ta lang tid og mye krefter. Forum egen kode mal full mal med finpuss av oss Kan gjøre det så enkelt som mulig. Enkelt å lære bort til oppdragsgiver. Vil bli den mest krevende delen av prosjektet Vil ta kortere tid enn om vi lager alt selv. Som regel de vanskeligste aspektene som må gjøres for hånd. Nesten alt er gjort for oss. Rik på funksjoner. Ikke fullt så god kontroll på koden. Vanskelig å lære bort. Universell utforming Tidlig integrering Ettertanke mellom frister Ettertanke vil gjøre det tilgjengelig for flest brukere. Kan ta bruk av de mindre nevnte rettningslinjer (ATAG, UAAG, WAI-ARIA) kan fort bli ett alt for stort aspekt av oppgaven. Beste integrering i forhold til frister og tidsbruk på dette. begrenset til å holde oss såvidt innenfor lover. kan gå litt på bekostning av brukeropplevelse. Lite tid brukt. Kan fort bli stressende for å få godkjent innenfor lover. 3

4 Arbeidsmetode Vi som gruppe har valgt å jobbe etter prosessmodellen Scrum. Denne type prosess følger en prosjektleder metodikk. Fordelen med denne type prosessmodell er at at alle vet hva som skjer til en hver tid. En annen fordel med scrum-prosessen er at det er enklere å tilpasse seg endrede, eksterne faktorer og redusere behovet for å kunne forutsi endringene og framtidige behov. Kunden og sluttbrukeren involveres i større grad i utviklingsprosessen. Ulemper med denne metoden er derimot at ikke alle team vil selvorganisere og ta kollektivt eierskap, og derfor hviler det et stort ansvar på Scrum-master som må ha kunnskap nok til å detektere dette problemet og forsøke å bøte på det. En måte man kan motvirke dette på er å sørge for at alle i teamet har nok motivasjon til å ville gjennomføre prosessene. Analyse av virkninger Vi ønsker å benytte oss av en template/mal istedet for selvlaget kode. Det blir enklere for oss i starten og vi kan fokusere på hovedfunksjonene på nettstedet, men det blir like mye jobb etterhvert. Alternativet er at vi skriver kode fra starten av. Da har vi bedre kontroll på koden og det kan være lettere å finne feil, men det blir også mer arbeid. Som faktureringssystem ønsker vi å benytte oss av en kjent plattform som Paypal eller liknende, samt fakutrering via e-post. Dette vil gjøre at nettstedet vil få en pålitelig og sikker netthandel, imotsetning til om vi skulle lage noe eget. Forumet ønsker vi å kode selv. Dette gjør at vi kan få forumet akkurat slik vi ønsker det, imotsetning til å bruke en mal. Samtidig blir det mye mer arbeid. Universell utforming skal vi integrere tidlig i prosjektet. Gjør vi dette vil nettstedet være bygget på universell utforming og ikke noe vi tenker på i siste liten. Dette vil gjøre nettstedet mest mulig brukervennlig og vil kunne brukes av flest mulig. 4

5 Kravspesifikasjon Prioritert funksjonalitet: Systemet skal kunne: 1. Ha et innebygd faktura system, slik at kunden kan betale vaksinen med faktura. 2. Ha et diskusjonsforum, der kunden sender inn spørsmål de lurer på og legen kan svare. 3. Ha et login system for å kunne bestille vaksiner og delta i diskusjonsforumet. 4. Kategorier på forumet, slik at kunder lett kan finne hva andre har spurt etter. Legen skal være admin, slik at han kan endre/slette meldinger der. 5. Ha en lyd-funksjon for synshemmede. Ønsket funksjonalitet: Systemet bør kunne: 1. Ha en annen betalingsmetode enn faktura. For eksempel Pay Pal. 2. La brukere kunne se vaksinehistorikk. 3. Ha et eget kontakt meg skjema, hvor kundene får direkte kontakt med legen. Eventuell tilleggsfunksjonalitet Systemet kan eventuelt kunne: 1. La kunde endre kontoinformasjon 2. Få SMS/Epost påminnelse om vaksinetime. 3. Ha en FAQ side hvor kunden kan se ofte stilte spørsmål. 5

6 Ikke-funksjonelle krav Produktkrav Brukervennlighet 1. Nettstedet skal følge retningslinjer og krav til universell utforming. 2. Språket på nettstedet skal være på norsk bokmål. 3. Nettstedet skal ikke inneholde vanskelige fremmedord og fagspråk. Effektivitetskrav 1. Nettstedet skal kunne kjøres i alle typer nettlesere og lastes inn innen normal hastighet. (Rundt 1 sekund) Pålitelighetskrav 1. Data skal lagres trygt i en database. 2. All informasjon på nettstedet skal være tilgjengelig og oppdatert. 3. Sikkerhet ved bestilling av vaksiner. Estetiske krav 1. Oppsettet skal gjøre det lett å finne frem. Ikke mer enn tre musklikk. 2. Gjennomgående farge/farger i hele nettstedet. Rammekrav 1. Nettstedet skal fungere på alle nettlesere og på alle enheter. Dvs. PC, Mac, Iphone, android og nettbrett osv. 2. Programmeringspråkene HTML5, CSS, PHP, javascript og MYSQL skal brukes. 3. Template skal brukes. 6

7 Arbeids- og fremdriftsplan Fremdriftsplan 12 januar: Gjøre ferdig forprosjektrapport. 15 januar: Første møte med veileder. Sende bekreftelseskjema til oppdragsgiver 22 januar: Sette opp oversikt over tidligere fag og mål for hva vi skal ha lært -> lage små sjekkpunkter for resten av prosjektet. uke 5-7: Ferdigstilling av planleggingsfag ie. prototyping, itip, mmi, ia osv. oppstart av kodeskriving. uke 13: Største delen av nettsiden må være klart for ferievaksiner : Innlevering av prosjektrapport : Fremføring av bachelorprosjekt. Uten frist: høre med helsenorge.no, fastsette system for faktura, få tak i brødtekst fra mohammed, 7