Alle delrapportene er tilgjenglig på prosjektgruppens hjemmeside (

Transkript

1 1

2 2

3 3

4 4

5 Forord Sluttrapporten er ett produkt som er blitt utarbeidet i forbindelse med hovedprosjekt våren 2011 for ingeniøravdelingen ved HIO. Gruppen består av to studenter fra avdelingen anvendt data. Dokumentet består av fem delrapporter. Samtlige delrapporter er lagt opp slik at de kan leses hver for seg. Dette fører til gjentagelse av innhold i enkelte deler av sluttrapporten. Alle delrapportene er tilgjenglig på prosjektgruppens hjemmeside ( Vi retter en stor takk til veilederen Alfred Bratterud som anbefalte oss å bruke Joomla og bidro med rådgivning under utviklingsprosessen og dokumentasjonen. Til oppdragsgiver som har vist stor samarbeidsvilje og stilte til rådighet når vi trengte dem. Det rettes også en takk til sykkelgutta fra ( som har bidratt med bildemateriale fra deres ekspedisjon i Afrika. Bildene, skjermbildene samt illustrasjoner i oppgaven er produsert av gruppen, andre bilder har vi mottatt fra Jørn Wichne Pedersen ( med fri tillatelse til publisering. HIO Dag Otto Lund Christensen Amin Hamrioui 5

6 6

7 Innholdsfortegnelse STYRINGSDOKUMENTER STATUSRAPPORT PROSJEKTSKISSE FORPROSJEKTRAPPORT FREMDRIFTSPLAN KRAVSPESIFIKASJON PROSESSRAPPORT INNLEDNING PLANLEGGING UTVIKLINGSPROSESSEN KRAVSPESIFIKASJON OPPSUMMERING KILDER PRODUKTRAPPORT INNLEDNING TEKNOLOGI OPPBYGGING OG VIRKEMÅTE DATABASE FUNKSJONALITET SIKKERHET PRODUKT VS KRAVSPESIFIKASJON VIDEREUTVIKLING BRUKERVEILEDNING ADMINISTRATOR BRUKER TESTRAPPORT INNLEDNING TEST AV SYSTEMET TEST AV FUNKSJONER TESTING AV GUI/ GRENSESNITT

8 8

9 Styringsdokumenter Forord Dette er en samling av samtlige styringsdokumenter gjennom hele prosjektperioden. Styringsdokumentene er satt opp i rekkefølge i forhold til leveringsfrister Dokumentene ble levert inn etter følgende frister: Statusrapport Prosjektskisse Forprosjekt Prosjektrapport

10 Innhold 1 STATUSRAPPORT PROSJEKTSKISSE FORPROSJEKTRAPPORT FREMDRIFTSPLAN KRAVSPESIFIKASJON

11 1 Statusrapport Statusrapport Vi, Amin Hamrioui og Dag Otto Lund Christensen har bestemt oss for å jobbe sammen med prosjektoppgaven. Denne gruppen har bestått av de samme personene siden vi startet dette studiet i 2008, noe gruppen vil dra stor nytte av. Vi har ikke fått fastslått en prosjektoppgave enda, men vi har kontaktet flere firmaer, og venter på svar. Firmaene vi har kontaktet er: Fremgang Aptoma Hydro Is IBM HP CSC Tietoenator EDB Til nå har vi bare fått tilbakemelding fra Aptoma, angående en webløsning ved bruk av deres verktøy. Her var vi også på intervju tirsdag 19 oktober. Det ser forøverig dårlig ut ettersom de mest sannsynelig trekker seg fra studentprosjekter i år, grunnet for lite kapasitet. De resterende venter vi fortsatt på svar fra, men vi har trappet opp mailskrivingen og håper på en snarest positiv tilbakemelding. Hva ønsker vi? Vi ønsker sterkest en etablert it-bedrift og vi legger stor vekt på veiledning fra bedriftens side. Utviklingsoppgave innenfor web, database, html står øverst på listen. 11

12 2 Prosjektskisse PROSJEKTSKISSE PR 15.DESEBER 2010 Sted og dato: Oslo, 15 desember Tittel: Gruppemedlemmer: Oppdragsgiver: Kontaktperson: Webside for Charity Tube Dag Otto Christensen, Amin Hamrioui. Charity Tube Neena Al-Mustafa, Daniel Baffoe Epost: Tlf: Oppdragsgiver: Charity Tube er ett sideprosjekt for Charity Doctors som er en veldedighetsorganisasjon bestående av to leger. Disse tilbyr legetjenester for mennesker som ikke har mulighet til å besøke fastlege eller legevakt. Dette er et engasjement som drives på fritidsbasis og alt arbeid er frivillig. Prosjektet: Charity Tube skal være en webside hvor forskjellige veldedighetsorganisasjoner kan legge ut videosnutter, bilder for å promotere sin egen organisasjon. Websiden skal kunne registrere nye brukere/organisasjoner. Det skal også være mulig å logge inn som administrator for å administrere siden. Brukere skal kunne laste opp video, bilder, og informasjon om sin egen organisasjon. Det skal her være et filter hvor administrator må godkjenne brukere som prøver å registrere seg, dette for å unngå spam og useriøse aktører. For å utvikle systemet har vi tenkt å bruke HTML, CSS, PHP, MySQL, javascript. s Amin Hamrioui s Dag Otto Christensen 12

13 3 Forprosjektrapport FORPROSJEKT Presentasjon Tittel Oppgave Charity Tube Website Utvikle en webside for Charity Tube Periode 03.januar 2011 til 01.juni 2011 Gruppemedlemmer Dag Otto Christensen, Amin Hamrioui Prosjektgruppe 19 Veileder Oppdragsgiver Alfred Bratterud Charity Doctors Sammendrag Kontaktperson Daniel Boffoe tlf Neena Prosjektet skal gjennomføres som hovedprosjekt ved HIO avd. for Ingeniøravdelingen i samarbeid med Charity Doctors. Kort oppsummert består oppgaven av å utvikle en webside som skal være ett samlingspunkt for mindre veldedighetsorganisasjoner. Om bedriften Bedriften startet opp i Desember 2010 og er i utvikling. Charity Tube skal drives på fritidsbasis og all administrasjon skal være frivillig. Bedriften består av to nyutdannede leger, med stort engasjement mot veldedighet. Deres ambisjoner er å finne en måte å samle forskjellig små organisasjon som sliter med å få oppmerksomhet i forhold til større organisasjoner. 13

14 Om prosjektet Målet med prosjektoppgaven er å gi veldedighetsorganisasjoner en ny måte å promotere seg selv på. Det skal lages en web-side som fungerer som en videokanal hvor alle store og små organisasjoner kan laste opp en video som kan gi litt beskrivelse rundt selve organisasjonen og hvilke områder organisasjonen tar for seg. På denne måten blir det letter for potensielle givere å få en oversikt over hva som finnes av veldedighetsorganisasjoner der ute. Det blir også enklere for mindre organisasjoner å få et ansikt utad. Web-siden skal hete charitytube og kommer til å stå i stil med den mer kjente videokanalen, youtube. En CharityTube løsning vil definitivt være med å øke små veldedighetsorganisasjoners inntektskilder og popularitet. Dagens situasjon Som situasjonen er i dag, må veldedighetsorganisasjoner promotere seg selv via dør til dør kampanjer, standaktivitet, facebook profiler eller private websider. Dette er veldig resurskrevende og ikke alltid like vellykket. Det er ingen samleplass på nettet som tilbyr promotering av veldedighetsorganisasjoner. Med tanke på hvor mange små veldedighetsorganisasjoner det finnes i verden, kan man tenke seg hvor mange ressurser som frigjøres ved å tilby en CharityTube løsning. Rammebetingelser Gruppen står fritt til å velge hvilket språk vi vil benytte for å programmere charitytube. I utgangspunktet tenker vi å modellere/beskrive systemet 100% og ikke minst lage skisse av systemet. Gruppen velger å utvikle systemet ved hjelp av Joomla, og planlegger å bruke PHP som programmeringsspråk og MySQL som database verktøy, ettersom det er disse verktøyene vi har mest erfaring med når det gjelder programmering av web- løsninger fra høgskolen i Oslo. Joomla er et GPL-lisensiert publiseringsverktøy basert på åpen kildekode. De ferdige websidene skal støtte Internet Explorer, Mozilla Firefox og Opera som minste krav. 14

15 Mål Målet med prosjektoppgaven var at veldedighetsorganisasjoner skal kunne benytte seg av charitytube systemet for å promotere seg selv og øke interessen rundt dem. Systemet bør: kunne registrere nye brukerkonto på en sikker måte. holde orden på rettighetene til brukerne. ha en login/logout funksjon. ha en egen brukermeny som vises kun etter innlogging med diverse hjelpemidler. gjøre det mulig for brukere å laste opp video på opptil 100 MB. ikke publisere video før administrator godkjenner den. innholde kommentarfelt for videoer. ha en søkemotor for video. være enkel å administrere, admin har ingen programmeringskunnskap. Opprettholde personvernet til den enkelte. Være 100% nettbasert. Funksjonalitet som kan implementeres: Paypal donasjon direkte fra charitytube. Charitytube forum. Teknologi og løsning Følgende vil bli benyttet som utviklingsverktøy: Teknologier: HTML, CSS, PHP, MySQL, Joomla. Utviklingssprogram: Emacs unix, textpad windows, fraise tekst editor for mac. Database: MySQL Server. Andre programmer: Adobe Photoshop, GIMP, FTP filezilla, smart FTP, putty. Konklusjon Vi mener charitytube vil være til stor hjelp for veldedighetsorganisasjoner og givere. Det vil gi en større oversikt over hjelpeorganisasjoner en hva det er pers dags dato. Systemet vil lette arbeidsmengden med tanke på promotering av organisasjonenes arbeid, og være til stor hjelp for giverne da de kan forholde seg til en samleside. Dette vil gi givere større muligheter til å finne eksakte og mer konkrete prosjekter de ønsker å støtte, for eksempel jenteskole i Tanzania. Vi mener systemet vil: Øke donasjonene til de mindre og mer målrettede organisasjonene. Gi mer oppmerksomhet rundt frivillig arbeid. Motivere folk til å starte/drive med veldedighet. Gjøre det enklere å donere direkte til det du vil støtte. 15

16 4 Fremdriftsplan Fig3 Fremdriftsplan 16

17 5 Kravspesifikasjon Kravspesifikasjonen beskriver betingelsene for CharityTube. I dette dokumentet beskriver vi funksjonalitet og rammebetingelser. Kravene er utarbeide i samarbeid med oppdragsgiveren. Funksjonskrav Administratordel Admin skal ha egen login. Oversikt over alle brukere. Legge til, endre og slette brukere. Oversikt over alle opplastede video. Endre og slette brukerevideo. Kontrole og akseptere brukernes opplastinger. Opprette video kategori. Skal kunne laste opp reklame. Skal kunne legge ned siden ved vedlikehold. Motta e-post når bruker laster opp video. Brukerdel Registrer seg med brukernavn og passord. Logg inn/ut. Laste opp video. Endre egenprofil (navn, e-post osv.) Oversikt over egne videoer. Mulighet for å kommentere andres videoer. Videofunksjon Laste opp video fra egen maskin. Laste opp video via url (youtube, google osv.) Videostørrelse på opptil 100 mb. Deling av video via sosial medier. Egen søkemotor. Fullskjerm mulighet. Kategorisering av video i henhold til kontinent. Visning av egen logo når video spilles av, slik som youtube. Beskrivende tekst under hver video Komprimering av video under opplasting Kommentarfelt under hver video 17

18 Tekniske krav Teknologi: Joomla. Database: MySQL. Programmeringspråk: PHP, CSS, XHTML, javascript, flash, SQL. Programmvare: textpad, fraise tekst editor for mac, Adobe Photoshop, GIMP, FTP filezyla,, smart FTP, putty. Krav til design Design Layout Enkelt, brukervennlig og intuitivt brukergrensesnitt. Websiden skal være på engelsk. Bruker skal kunne navigere via video kategorier. Søkefunksjonalitet. Lyse farger, helst blått og hvitt. CharityTube logo. Video sentret på siden. Kategori meny til venstre. Reklamefelt til høyre. Hovedmeny i toppen. Søkefunksjon sammen med hovedmeny. Logo øverst til venstre. Krav til dokumentasjon Gruppehjemmeside hvor alt dokumentasjon skal publiseres, blant annet dagbok. Endelig prosjektrapport skal innholde: Produktrapport Prosessrapport Testrapport Brukermanual Styringsdokumenter 18

19 19

20 20

21 Prosessrapport Forord Denne prosessrapporten forteller om gruppens samarbeid og metoder benyttet for hovedprosjektet ved Høgskolen i Oslo avdeling for ingeniørutdanning, anvendt datalinjen, vårsemesteret Rapporten er beregnet for sensor, veileder, oppdragsgiver og andre som har interesse av å sette seg inn i utfordringer, løsninger og arbeidsmetoder i prosjektet. Det blir i rapporten gjort rede for samsvaret mellom sluttproduktet i forhold til kravspesifikasjonen. Vi retter en stor takk til veilederen Alfred Bratterud som anbefalte oss å bruke Joomla og bidro med rådgivning under utviklingsprosessen og dokumentasjonen. Til oppdragsgiver som har vist stor samarbeidsvilje og stilte til rådighet når vi trengte dem. Det rettes også en takk til sykkelgutta fra ( som har bidratt med bildemateriale fra deres ekspedisjon i Afrika. Bildene, skjermbildene samt illustrasjoner i oppgaven er produsert av gruppen, andre bilder har vi mottatt fra Jørn Wichne Pedersen ( med fri tillatelse til publisering. Det kreves ingen spesiell datakompetanse for å sette seg inn i denne rapporten. Dokumentet er optimalisert for papirutskrift. 21

22 Innhold 6 INNLEDNING Om arbeidsgiver Om prosjektet Dagens situasjon Mål Rammebetingelser Konklusjon PLANLEGGING Gruppevalg Oppstartsfasen Hjemmeside Konkretisering av prosjektet Forkunnskap Kompetansetillegning Forprosjektet Valg av metodikk Risikoanalyse Fremdriftsplan

23 8 UTVIKLINGSPROSESSEN Fasene i utviklingen Insatallasjon av Joomla Forståelse av Joomla Design og Layout Implementering av komponenter Domene- og websideflytting Overgang Arbeidsplass Arbeidsdagbok Testing KRAVSPESIFIKASJON Generelt Endringer i kravspesifikasjonen Kravspesifikasjonens rolle under design og implementering Kravspesifikasjonen i dag Avvik Avvik i videofunksjonen Avvik i administrasjonsdelen Avvik i brukergrendelen OPPSUMMERING Hva har vi lært Hva kunne vært gjort bedre Videreutvikling KILDER

24 6 Del 1 7 Innledning 7.1 Om arbeidsgiver CharityTube er ett sideprosjekt for Charity Doctors. Charity Doctors er et nyetablert veldedighetsforetak bestående av lege Neena Al-Mustafa og lege Daniel Baffoe. I samarbeid med Fattighuset i Oslo har de fått et lokale i Fattighuset til disposisjon for å drive Deres virksomhet. Dette er et engasjement som drives på fritidsbasis. Organisasjonen ble stiftet januar Charity Doctors har ingen kommunale eller statlige avtaler med tanke på refusjoner eller lignende. Organisasjonen har heller ingen andre inntektskilder. Charity Doctors er kun basert på egeninnsats og donasjoner fra privatpersoner og bedrifter. 7.2 Om prosjektet Målet med prosjektoppgaven er å gi veldedighetsorganisasjoner en ny måte å promotere seg selv på. Det skal lages en web-side som fungerer som en videokanal hvor alle store og små organisasjoner kan laste opp en video som kan gi litt beskrivelse rundt selve organisasjonen og hvilke områder organisasjonen tar for seg. På denne måten blir det letter for potensielle givere å få en oversikt over hva som finnes av veldedighetsorganisasjoner der ute. Det blir også enklere for mindre organisasjoner å få et ansikt utad. Web-siden skal hete charitytube og kommer til å stå i stil med den mer kjente videokanalen, youtube. En CharityTube løsning vil definitivt være med å øke små veldedighetsorganisasjoners inntektskilder og popularitet. 7.3 Dagens situasjon Som situasjonen er i dag, må veldedighetsorganisasjoner promotere seg selv via dør til dør kampanjer, standaktivitet, facebook profiler eller private websider. Dette er veldig resurskrevende og ikke alltid like vellykket. Det er ingen samleplass på nettet som tilbyr promotering av veldedighetsorganisasjoner. Med tanke på hvor mange små veldedighetsorganisasjoner det finnes i verden, kan man tenke seg hvor mange ressurser som frigjøres ved å tilby en tilsvarende løsning. 24

25 7.4 Mål Målet med prosjektoppgaven var at veldedighetsorganisasjoner skal kunne benytte seg av charitytube systemet for å promotere seg selv og øke interessen rundt dem. Systemet bør: kunne registrere nye brukerkonto på en sikker måte holde orden på rettighetene til brukerne ha en login/logout funksjon ha en egen brukermeny som vises kun etter innlogging med diverse hjelpemidler gjøre det mulig for brukere å laste opp video på opptil 100 MB ikke publisere video før administrator godkjenner den innholde kommentarfelt for videoer ha en søkemotor for video være enkel å administrere, admin har ingen programmeringskunnskap. Opprettholde personvernet til den enkelte Være 100% nettbasert Funksjonalitet som kan implementeres: Paypal donasjon direkte fra charitytube Charitytube forum 7.5 Rammebetingelser Gruppen står fritt til å velge hvilket språk vi vil benytte for å programmere charitytube. I utgangspunktet tenker vi å modellere/beskrive systemet 100% og ikke minst lage skisse av systemet. Gruppen velger å utvikle systemet ved hjelp av Joomla, Joomla er et GPL-lisensiert publiseringsverktøy basert på åpen kildekode. Vi planlegger å bruke PHP som programmeringsspråk og MySQL som database verktøy, ettersom det er disse verktøyene vi har mest erfaring med når det gjelder programmering av web- løsninger fra høgskolen i Oslo. De ferdige websidene skal støtte Internet Explorer, Mozilla Firefox og Opera som minste krav. 7.6 Konklusjon Vi mener charitytube vil være til stor hjelp for veldedighetsorganisasjoner og givere. Det vil gi en større oversikt over hjelpeorganisasjoner enn hva det er per dags dato. Systemet vil lette arbeidsmengden med tanke på promotering av organisasjonenes arbeid, og være til stor hjelp for giverne da de kan forholde seg til en samleside, og ha større sjanser for å finne eksakte og mer konkrete prosjekter de ønsker å støtte, for eksempel jenteskole i Tanzania. 25

26 Del 2 8 Planlegging 8.1 Gruppevalg Gruppesammensetning har bestått av de samme medlemmene siden det første prosjektet høsten Medlemmene har blitt godt kjent sammen siden den tid, noe som gjorde det enklere å begynne med prosjektsøket. Siden gruppen har samarbeidet mange ganger tidligere, vet vi hvor hver av oss står i forhold til den enkeltes kompetansenivå. Gruppen bestod i starten av tre medlemmer, men en av medlemmene falt av under planleggingsfasen. Dette har ikke gjort noe effekt på gruppen, da det skjedde i en såpass tidlig fase. 8.2 Oppstartsfasen Oppdragssøket startet så fort vi fant prosjekter som passet gruppens interesser og utfordringer. Vi ble raskt interessert i annonsen fra Aptoma på hios hjemmeside, og tok hurtig kontakt med oppdragsgiveren. Vi stilte på intervju og håpet på å få prosjektet da Aptoma har lang erfaring og samarbeid med høgskolen. Til vår store skuffelse valgt Aptoma å trekke sitt prosjekt på grunn av en travel hverdag og at de ikke kunne stille til disposisjon like mye som det trengs i ett hovedprosjekt. Deretter ble det sendte flere søknader til bedrifter og gruppen fikk ett tilbud fra Charity Dorctors. Dermed fikk vi ansvaret for å utvikle CharityTube, en webside med videofunksjon for promotering av veldedighetsorganisasjoner. I tillegg til at oppgaven har ett fengende tema, var det ekstra motiverende å vite at jobben vi legger ned går til en god sak, og hjelpe veldedighetsorganisasjoner med å fortsette arbeidet deres. 8.3 Hjemmeside Vi opprettet etter hvert en hjemmeside som representerer gruppen, Det brukes for det meste til å legge ut innlegg som en slags dagbok. Det vil gjøre det lettere for veileder og kontaktperson å følge med. De nødvendige dokumentene for prosjektet legges også til nedlastning fra hjemmesiden. 8.4 Konkretisering av prosjektet Til å begynne med var det meget viktig og finne ut definisjonen av CharityTube før man kunne gå videre med planleggingen av prosjektet. Deretter ble det satt opp flere møter med oppdragsgiveren for å avklare kravene under planleggingsfasen. Møtene ble gjennomført med god kvalitet og minimaliserte derfor behovet for avklaringer senere i prosjektet. 26

27 Det var hyppige møter med veileder som skulle holde orden på at vi kom oss videre og at vi satt opp mål for å leverte resultater hver uke. Det var viktig å finne ut hva lignende systemer bestod av og hvordan de brukes i dag. I forhold til kravspesifikasjonen, og alt siden skulle bestå av, ble vi nødt til å undersøkte om hvilke muligheter det fantes der ute av systemer som hjelper oss til best mulig resultat. Første møte med veilederen resulterte i at vi ble anbefalt å bruke joomla sitt verktøy for utviklingen av CharityTube. CMS verktøyet til joomla vil være til stor hjelp for å oppnå best mulig resultat. Veilederen hadde god erfaring med joomla og kunne stå til rådighet hvis vi skulle trenge det. I tillegg til at joomla har ett ukomplisert brukergrensesnitt for administrator, er det også flere fordeler knyttet til design av websiden. Ettersom joomla er et GPL-lisensiert publiseringsverktøy basert på åpen kildekode, finnes det utallige komponenter som kan kobles til websiden. Når gruppen bestemte seg for å bruke joomla, ble det spurt om tillatelsen fra studielederen i avdelingen, noe han godkjente uten problem. 8.5 Forkunnskap Høgskolen i Oslo, og avdeling for ingeniører, har flere fag som tar for seg MySQL, PHP, HTML og CSS gjennom studieperioden. Disse fagene har hele veien vært meget relevante både til eksamen og andre prosjektoppgaver. Siden ingen av gruppemedlemmene hadde noe særlig programmeringskunnskap før studiestart ved Høgskolen i Oslo, har vi hele veien tatt til betraktning disse fagene og prioritert de høyt. Oppdragsgiver framsatte ikke krav om hvilken teknologi vi skulle bruke, men det var ingen tvil om at MySQL, PHP, HTML og CSS skulle bli tatt i bruk. Dette er verktøyer som i dagens utviklingsmiljø blir brukt mer og mer, sammen i utvikling av databasesystemer. 8.6 Kompetansetillegning Å jobbe med ett publiseringsverktøy som joomla, er noe helt nytt for begge gruppemedlemmene. Vi måtte sette oss inn i hvordan man installerer joomla, krav av server, installasjon av komponenter, moduler og maler(templates), redigering av maler, og generelt hvordan joomla fungerer og er satt opp. Det passet veldig bra for oss at komponentene, modulene og malene i joomla bruker PHP, HTML, CSS og MySQL som programmeringsspråk, og dette var en av hovedgrunnene til at vi valgte joomla, da vi fikk bruk for kunnskapen vi har lært tidligere fra høgskolen og ta det til ett høyre nivå. 27

28 8.7 Forprosjektet I starten av prosjektet var det veldig viktig å sette seg inn i dagens situasjon og hvordan veldedighetsorganisasjoner promoterer seg selv i dag. I denne fasen presiserte vi problemstillingen. Hva som er målet med oppgaven og mål for prosjektgruppen. Vi skrev blant annet forprosjektarbeid og presiserte en grov problemstilling som var grunnlaget for mål og rammebetingelser i etterkant. I samarbeid med oppdragsgiver bestemt vi de mest relevante og meningsfulle problemformuleringene som vi brukte for å skrive kravspesifikasjonen senere i arbeidet. 8.8 Valg av metodikk Vi har vært heldige med hvordan samarbeidet med oppdragsgiver har utartet seg. Det ble aldri satt noen krav om hvordan vi skulle jobbe og hva slags prosjektstyringsmetode som skulle brukes. Dette ga oss friheten til å gjøre som vi ville i forhold til prosjektstyring. Gruppen besto kun av to medlemmer dermed var det naturlig å følge en iterativ utvikling. Årsaken var at vi ikke trengte noen spesiell styring ettersom oppgavene var relativt lette å fordele. Vi har kommunisert hele veien og samarbeidet tett med hyppige møter og jobbet regelmessig med å holde hverandre oppdatert. 8.9 Risikoanalyse Basert på den detaljerte arbeidsplanen som ble opprettet i starten av prosjektet, ble diverse risiko minsket betraktelig. I tillegg ble en risikoanalyse laget for å redusere sjansene for at ting skal gå galt. Fig3 Risikoanalyse. 28

29 Hvordan redusere sjansen for at ting kan gå galt? Holde jevnlig og god kontakt/dialog med arbeidsgiver. Ha en eller to alternativer vi kan kontakte i tilfelle samarbeid med arbeidsgiver feiler. Samarbeid oss imellom slik at vi til enhver tid vet hva som skal bli utført. Dette gjøres ved å holde kontakt via telefon, skype, mail og i jevnlige møter. Enhver gruppemedlem opparbeider seg kunnskap i de forskjellige rollene slik at vi kan steppe inn i de forskjellige arbeidsoppgavene i tilfelle kortvarig eller langvarig sykdom. Lage backup av alle dokumenter samt benytte seg av dropbox Fremdriftsplan Fremdriftsplan ble satt opp tidlig i prosjekter. Oppfølgingen av planen har gått veldig greit, vi diskuterte hva som skulle prioriteres, og fant ut at det var noen oppgaver som krevde mer tid en andre. Fremdriftsplanen ble delt opp i forskjellige faser. Fasene var for å unngå å starte på nye oppgave før de forrige ble fullført. På denne måten blir flyt i arbeidet. Fig4 Fremdriftsplan. 29

30 Del 3 9 Utviklingsprosessen De praktiske utfordringene var mange. Ettersom vi aldri før hadde vært borte i joomla, eller andre CMS systemer, var dette den første utfordringen vi måtte overkomme. For å oppnå en bratt læringkurve, benyttet vi oss hovedsaklig av diverse video-tutorials og ellers google generelt. Det finnes veldig mye informasjon og mange forumer som dekker alle områder av joomla. 9.1 Fasene i utviklingen Insatallasjon av Joomla Alle installasjons-prosessene til joomla ble nøye betraktet av begge to, og vi fikk raskt en oversikt over hvordan joomla er lagt opp. Her er punktene vi gjennomgikk for installasjonen av joomla. Laste opp Joomla på webhotellet via ftp Opprette database: For å benytte Joomla må du ha en database. Vi benyttet oss av en mysql wizard gjennom cpanel til webhotellet for å enkelt opprette databasen. Systemsjekk: mysql støtte, php støtte, xml støtte. Lisens godkjenning: Mens de fleste lisenser godkjennes for å ta bort friheten til å dele og endre programvaren, vil GNU/GPL på sin side garantere for denne egenrådigheten. Ftp konfigurasjon: For å unngå mulige rettighetsrestriksjoner på filsystemet, installerer joomla en ftpfilsystemfunksjon for å håndtere filsystemmanipulasjon. Dette er ikke ikke nødvendig om man benytter seg av windows som operativsystem. 30

31 9.1.2 Forståelse av Joomla For å forstå hvordan joomla fungerer brukte vi en uke etter installasjonen til å eksperimenter med forskjellige funksjoner under joomla. Vi tilegnet oss raskt kunnskap om hvordan moduler og komponenter kunne lastes ned for så å installeres for bruk. Alle administratormulighetene ble prøvd ut og forsøkt forstått. Via ftp-klienten undersøkte vi også hvordan fil-treet til joomla var lagt opp. Dette hjalp oss å tidlig forstå hvordan vi skulle gå frem for å gjøre endringer av kodene. Når det er sagt så opererer joomla med flere hundre forskjellige.php-,.xml-, css- og html-filer. Det var med andre ord mye å sette seg inn i, selv om vi til slutt fant en slags logikk Design og Layout Selv om vi kontinuerlig endret på layouten i begynnelsen(farger, bilder etc), etter møter med arbeidsgiver, holdt vi oss til de samme rammene og skissene vi i starten hadde satt oss. Nedenfor kan du se prosessen fra skisse til ferdig produkt, kravspesifikasjonene tatt i betraktning. Fig5 skisse av websiden Fig6 Ferdig produkt En oversiktlig og enkel forside. Bruker vil straks oppfatte at det dreier seg om en videokanal, og burde ved hjelp av logoen også forstå at temaet er veldedighet. Vi har etter krav fra arbeidsgiver anvendt engelsk som språk ettersom web-siden helst skal representeres internasjonalt. De tre klassiske A'ene oppe i høyre representerer skriftstørrelsen. For å oppnå best mulig similarity har vi benyttet oss av firkantede uthevede knapper som vi har holdt oss til på alle sidene. Charitytube-logoen har vi selv designet i photoshop etter ønske fra arbeidsgiver. Ettersom arbeidsgiver vil ha lyse farger falt valget vårt på blått, grått og hvitt med utgangspunkt i logoen. Dette er både vi og arbeidsgiver fornøyde med. 31

32 9.1.4 Implementering av komponenter Under alle gruppemøtene ble det diskutert og prøvd ut forskjellige komponenter og moduler. Først og fremst forskjellige videokomponenter, da dette er den viktigste og største komponenter vi benytter oss av. Etter mye «prøve og feile» kom vi tilslutt frem til en videokomponent som støttet alle kravene vi og arbeidsgiver stillte, nemlig: Contus HD Video Share Fig7 Videokomponent leverandør Domene- og websideflytting Endring av webhotel I starten av prosjektet ble vi tildelt et webhotel av arbeidsgiver ifra one.com. Vi har tidligere hatt dårlige erfaringer med one.com og stilte oss litt skeptiske til bruken av dette wehotelet. Spesielt med tanke på at hovedbruken vil være opp og nedlasting av video, og one.com er et rimelig alternativ og man får som oftest det man betaler for. Det skulle vise seg at vår skeptisisme ikke var uten grunn, og midtveis i prosjektet fant vi ut at one.com ikke gir oss tilgang til endring av php.ini. Ettersom standard innstillinger har satt maksimal opplasting til 12mb ble det derfor bestemt at det var uaktuelt for oss å fortsette med one.com. Vi tok også kontakt med one.com i flere tilfeller og spurte om alternative løsninger til problemet vårt, men fikk bare negative tilbakemeldinger. Etter litt undersøkelser tok vi kontakt med inmotionhosting.com. Inmotionhosting var veldig imøtekommende og gav oss svar på alt vi måtte ønske. Vi fikk full tilgang til php.ini og inmotionhosting har også alle kraven for å kjøre joomla på serveren. Prisen var litt høyere enn med one.com, men etter samtaler med oppdragsgiver, ble det klart at vi skulle gå for dette alternativet Endring av domenenavn Det første domene-navnet vi fikk tildelt fra arbeidsgiver var mycharitytube.com. Etter at vi hadde vist frem og forklart om produktet vårt for oppdragsgiver i første møte, viste de stor interesse og gav uttrykk for å investere penger for å kjøpe opp charitytube.com. Dette så vi på som en tillitserklæring Utfordringer 32

33 Det ble noen utfordringer i forhold til bytting av domene-navn og flytting av web-hotel. Ingen av gruppemedlemmene hadde tidligere vært borte i denne prosessen Flytting av kode Eksportere databasen på den gamle serveren til one.com via phpmyadmin. Opprette en database på den nye serveren(inmotion Hosting) og importere database-scriptet. Last opp Joomla filene til den nye plasseringen via ftp Flytte dns-pekeren Vi måtte også endre dns-pekeren. Dns endringene kan ta opp til 24 timer, men vi gjorde noen reduseringer i TTL(time to live) for å få fortgang på prosessen. Følgende ble gjort i dns innstillingene for vårt domene. Fig8 Flytting av dens-peker Overgang Overgangsfaser har vi brukt til finpussing av produktet og vi har i det siste møte med arbeidsgiver gitt dem opplæring og veiledning til å administrere web-siden selv, samt overlevere en brukerveiledning. Vi har gjennom hele prosjektet holdt arbeidsgiver informert om sammenhengen i joomla og hvordan administrator-delen fungerer. Det var derfor en uproblematisk overgang for oss når vi skulle overlate all administrasjon av web-siden til arbeidsgiver. Det kan leses mer om brukerveiledningen i vedlagt dokument(brukermanual.pdf). 9.2 Arbeidsplass Vi arbeidet for det meste på skolen, og var flinke til å bestille grupperom så vi fikk sitte i fred. Ellers hadde vi alltid kontakt via skype når vi jobbet hjemmefra, og delte alle dokumentene våres over nettet. I den forbindelsen benyttet vi oss av dropbox ( 33

34 9.3 Arbeidsdagbok Etter hvert gruppemøte skrev vi arbeids-dagbok. Vi noterte de viktigste punktene vi hadde snakket om og ellers hva vi jobbet med. Dagboken kan leses på gruppens hjemmeside ( 9.4 Testing For å oppnå best mulig resultat bestemte vi oss for å foreta tre forskjellige tester av web-siden. Den første testen skulle ta for seg systemet, og kontrollere alt det tekniske. Det som ble testet under denne fasen var: Databasen og SQL spørringer link sjekk server test port skanning ping test web leser kompatibilitet. Dette testet vi selv uten å bruke testpersoner. I den andre testfasen ville vi finne ut om web-sidens funksjoner fungerter som de skulle. Testpersoner var heller ikke nødvendig for denne fasen. Siste testfase var for å finne ut om web-siden var så intuitiv og enkel i bruk som vi hele tiden hadde antatt. For best mulig resultat, ble denne testen utført av et knippe personer med ulik IT bakgrunn. Vi fikk veldig gode tilbakemeldinger fra testpersonene og mer om testingen kan leses i testrapporten. 34

35 Del 4 10 Kravspesifikasjon 10.1 Generelt Da kravspesifikasjonen skulle utvikles, kontaktet vi oppdragsgiver for å få høre deres ønsker og eventuelle krav de måtte ha til websiden. Dette, i tillegg til våre tanker og ideer, dannet kravspesifikasjonen. Kravspesifikasjonen skal betraktes som en kontrakt mellom prosjektgruppen og oppdragsgiver, men vi var enige om at den ikke skulle stå i veien om vi fikk nye og bedre ideer etter hvert. Mer om kravspesifikasjon kan leses i styringsdokumenter Endringer i kravspesifikasjonen Første versjon av kravspesifikasjon ble opprettet i forprosjektet. Denne var som nevnt tidligere basert på ønsker vi fikk fra oppdragsgiver, i tillegg til den funksjonalitet gruppen så for seg systemet hadde ved prosjektslutt. Da vi kom ut i planleggingsfasen, ble det tydeliggjort at kravspesifikasjonen var en smule vag på noen områder og enkelte ønsker fra oppdragsgiver var litt utydelige. Gruppen bestemte seg for at kravspesifikasjonen måtte utbedres og det ble avtalt et møte med oppdragsgiver der det ble utarbeidet en bedre forklaring på hva en kravspesifikasjon skal innholde. Første versjon av kravspesifikasjonen gikk mest ut på å avklare minstekravene til systemets funksjonalitet og tekniske krav. I tillegg til dette, inneholdt andre versjon mer spesifikke funksjonaliteter og krav til hva systemet skulle kunne levere. Andre versjon var også utvidet en del, siden oppdragsgivere fant noen uklarheter i første versjon. Gruppen var fornøyd med denne versjonen og den fikk oss raskt på rett spor igjen. Vi følte at denne versjonen representerte systemet vi skulle utvikle Kravspesifikasjonens rolle under design og implementering. Vi fikk etter hvert en veldig oversiktelig kravspesifikasjon, som vi kunne forholde oss til under utviklingen av systemet. Første versjon av skissen ble utarbeidet på bakgrunn av kravene satt i kravspesifikasjonen. Det måtte til noen endringer før oppdragsgivere godkjente skissen. Da utviklingen av websiden starten, visste vi akkurat hvordan den skulle se ut, noe som effektiviserte prosessen. I kravspesifikasjonen er det tydeliggjort hvilken funksjonalitet oppdragsgiver og gruppen har ønsket for systemet, og disse har også hatt stor prioritet under utviklingen. Det har hele tiden blitt arbeidet mot denne under implementering av kode til systemet. De mest grunnleggende kravene(som logg inn, registrering, sletting) ble implementert først, deretter startet vi med video funksjonen. Dette ble gjort i tilfelle gruppen hadde kollapset tidsmessig, ville oppdragsgiver få de mest grunnleggende funksjonalistene på systemet. Kravspesifikasjonen har under hele prosjektperioden vært en fin huskeliste å forholde seg til. Har det vært spørsmål angående funksjonalitet har vi alltid dobbeltsjekket med kravspesifikasjonen. Uten denne har det villet vært svært vanskelig å få fram det resultatet vi har i dag. 35

36 10.4 Kravspesifikasjonen i dag Nesten alle punktene i kravspesifikasjonen er oppfylt, noen mangler skyldes tidsmangel og prioriteringer av de forskjellige funksjonene. Tross alt er det ikke alt for mye kode som skal til, for å fullføre smutthullene siden databasen er klargjort for alt i kravspesifikasjonen Avvik Det er noen avvik fra kravspesifikasjonen som nevnt ovenfor Avvik i videofunksjonen Kommentarfelt for hver enkelt video. Beskrivende tekst som vises under hver video. Komprimering av video før opplasting Avvik i administrasjonsdelen Motta e-post når brukere laster opp en video, for å kontrollere innholdet og publisere video Avvik i brukergrendelen Intern kommunikasjon med andre brukere Ikke all funksjonalitet som vi har satt som krav til systemet har blitt løst. Dette kan anses som avvik men vi ser på det som forbedringsmuligheter i fremtiden. De fleste avvik er heller ikke så store, men små endringer som ikke tar så lang tid å sette opp. 36

37 Del 5 11 Oppsummering Ut ifra de målsetningene vi satte oss ved begynnelsen av prosjektet, er vi godt fornøyd med løsningen og resultatet av oppgaven. Vi fullførte våre mål, og har skapt et produkt som er i henhold til oppgavebeskrivelsen og kravspesifikasjonene. Per dags dato fungerer websiden optimalt og har oversteget de kravene som ble satt opp i kravspesifikasjonen. Dette systemet er det mest lønnsomme og effektive å bruke for veldedighetsorganisasjoner som ønsker å promotere seg selv. Det er ingen konkurrenter i markedet. I tillegg har vi planlagt de videre utvidelsene av CharityTube, og hvilke muligheter systemet kan ha videre. Under vil vi forklare hva vi har lært underveis, og hva vi kunne gjort bedre Hva har vi lært Prosjektet har vært lærerikt på mange områder. Vi føler vi har fått ett bedre innblikk i hvordan prosjekter i arbeidslivet fungerer. Gruppen har lært hvordan vi skal oppføre oss ovenfor en oppdragsgiver, med tanke på å holde tidsfrister, jobbe mot kravene som er satt opp og bruke kravspesifikasjon som en slags huskeliste. Samarbeidet har fungert veldig bra, og vi mener det å ha god kommunikasjon er avgjørende for at ett prosjektsamarbeid skal lykkes Hva kunne vært gjort bedre Underveis dukket det opp problemer i forbindelse med, webserver som ikke passet våre behov. En del nytt stoff og studering av ett nytt publiseringsverktøy. Slike situasjoner ville vært ønskelig at ble løst raskere, da det har tatt store deler av prosjekttiden. Også enkelte problemer underveis, med implementering av noen moduler og flytting av domenepeker tok mye verdifull tid, som forklart tidligere Videreutvikling I Joomla vil det alltid være rom for videreutvikling, og det er også en av fordelene med å bruke et CMS system. Joomla er hele tiden i utvikling, og nye moduler og komponenter vil bli lagd så lenge joomla forblir et populært publiseringsvertøy. Vi har vært veldig nøyaktige og strukturerte i måten vi har satt opp joomla på, og også måten vi har modifisert de forskjellige php-komponentene. 37

38 Del 6 12 Kilder Generell info om joomla: Flytting av joomla webside: Hjelpemidler til video komponent: Flytting av DNS-peker: Lærebok: Thor E. Hasle: Systemutvikling Applikasjoner og databaser, Cappelen Akademisk Forlag, ISBN: Lærebok: Sven Andreas Horgen: Webprogrammering i PHP. 38

39 39

40 40

41 Produktrapport Forord Dette prosjektet er ett hovedprosjekt i data ved Høgskolen i Oslo, avdeling for ingeniørutdanning, og gjennomføres i samarbeid med Charity Docters. Dette dokumentet er produktrapporten for hovedprosjektet, og skal gi en oversikt over hvordan hele systemet er bygget opp og hvordan det fungerer i praksis. Veiledning for klargjøring og installasjon av systemet er også en del av rapporten. Det forutsettes at leseren er kyndig i Joomla, PHP, HTML og MySQL databaser. Vi retter en stor takk til veilederen Alfred Bratterud som anbefalte oss å bruke Joomla og bidro med rådgivning under utviklingsprosessen og dokumentasjonen. Til oppdragsgiver som har vist stor samarbeidsvilje og stilte til rådighet når vi trengte dem. Det rettes også en takk til sykkelgutta fra ( som har bidratt med bildemateriale fra deres ekspedisjon i Afrika. Bildene, skjermbildene samt illustrasjoner i oppgaven er produsert av gruppen, andre bilder har vi mottatt fra Jørn Wichne Pedersen ( med fri tillatelse til publisering. 41

42 Innhold 14 TEKNOLOGI Betingelser Valg av teknologi Beskrivelse av Teknologi CMS Om joomla Krav for bruk av teknologien Systemkrav for Joomla Tilgang til php.ini Andre løsninger Wordpress Drupal OPPBYGGING OG VIRKEMÅTE Introduksjon Design, brukergrensesnitt og tilgjenglighet Layout Grensesnitt og Brukervennlighet Kommunikasjon Delene Brukerdel Administratordel DATABASE Introduksjon Strukturer Tabeller users Tabeller Components Tabeller Modules Tabeller session Tabeller Menu Tabeller Videos"

43 17 FUNKSJONALITET Templates Noen CSS endringer CSS endringer i layout.css for optimalisering av possisjon Moduler, komponenter & Php modefikasjon Contus HD Video Share Banner Flexi Contact mod_yoo_login mod_mainmenu Search Tube Advanced Copyright Module w3c.org CSS/XHTML Validator Front-end Font Size Adjuster Endringer i php.ini SIKKERHET Generelt Passord PRODUKT VS KRAVSPESIFIKASJON VIDEREUTVIKLING

44 Del 1 13 Innledning 13.1 Om arbeidsgiver CharityTube er ett sideprosjekt for Charity Doctors. Charity Doctors er et nyetablert veldedighetsforetak bestående av lege Neena Al-Mustafa og lege Daniel Baffoe. I samarbeid med Fattighuset i Oslo har de fått et lokale i Fattighuset til disposisjon for å drive Deres virksomhet. Dette er et engasjement som drives på fritidsbasis. Organisasjonen ble stiftet januar Charity Doctors har ingen kommunale eller statlige avtaler med tanke på refusjoner eller lignende. Organisasjonen har heller ingen andre inntektskilder. Charity Doctors er kun basert på egeninnsats og donasjoner fra privatpersoner og bedrifter Om prosjektet Målet med prosjektoppgaven er å gi veldedighetsorganisasjoner en ny måte å promotere seg selv på. Det skal lages en web-side som fungerer som en videokanal hvor alle store og små organisasjoner kan laste opp en video som kan gi litt beskrivelse rundt selve organisasjonen og hvilke områder organisasjonen tar for seg. På denne måten blir det letter for potensielle givere å få en oversikt over hva som finnes av veldedighetsorganisasjoner der ute. Det blir også enklere for mindre organisasjoner å få et ansikt utad. Web-siden skal hete charitytube og kommer til å stå i stil med den mer kjente videokanalen, youtube. En CharityTube løsning vil definitivt være med å øke små veldedighetsorganisasjoners inntektskilder og popularitet Dagens situasjon Som situasjonen er i dag, må veldedighetsorganisasjoner promotere seg selv via dør til dør kampanjer, standaktivitet, facebook profiler eller private websider. Dette er veldig resurskrevende og ikke alltid like vellykket. Det er ingen samleplass på nettet som tilbyr promotering av veldedighetsorganisasjoner. Med tanke på hvor mange små veldedighetsorganisasjoner det finnes i verden, kan man tenke seg hvor mange ressurser som frigjøres ved å tilby en tilsvarende løsning. 44

45 13.4 Mål Målet med prosjektoppgaven var at veldedighetsorganisasjoner skal kunne benytte seg av charitytube systemet for å promotere seg selv og øke interessen rundt dem. Systemet bør: kunne registrere nye brukerkonto på en sikker måte holde orden på rettighetene til brukerne ha en login/logout funksjon ha en egen brukermeny som vises kun etter innlogging med diverse hjelpemidler gjøre det mulig for brukere å laste opp video på opptil 100 MB ikke publisere video før administrator godkjenner den innholde kommentarfelt for videoer ha en søkemotor for video være enkel å administrere, admin har ingen programmeringskunnskap. Opprettholde personvernet til den enkelte Være 100% nettbasert Funksjonalitet som kan implementeres: Paypal donasjon direkte fra charitytube Charitytube forum 13.5 Rammebetingelser Gruppen står fritt til å velge hvilket språk vi vil benytte for å programmere charitytube. I utgangspunktet tenker vi å modellere/beskrive systemet 100% og ikke minst lage skisse av systemet. Gruppen velger å utvikle systemet ved hjelp av Joomla, Joomla er et GPL-lisensiert publiseringsverktøy basert på åpen kildekode. Vi planlegger å bruke PHP som programmeringsspråk og MySQL som database verktøy, ettersom det er disse verktøyene vi har mest erfaring med når det gjelder programmering av web- løsninger fra høgskolen i Oslo. De ferdige websidene skal støtte Internet Explorer, Mozilla Firefox og Opera som minste krav Konklusjon Vi mener charitytube vil være til stor hjelp for veldedighetsorganisasjoner og givere. Det vil gi en større oversikt over hjelpeorganisasjoner enn hva det er per dags dato. Systemet vil lette arbeidsmengden med tanke på promotering av organisasjonenes arbeid, og være til stor hjelp for giverne da de kan forholde seg til en samleside, og ha større sjanser for å finne eksakte og mer konkrete prosjekter de ønsker å støtte, for eksempel jenteskole i Tanzania. 45

46 Del 2 14 Teknologi 14.1 Betingelser Oppdragsgiveren ga oss ingen betingelser i forhold til valg av teknologi eller plattform. Vi fikk friheten til å velge den teknologien vi ønsket. Den eneste betingelsen var at man skulle kunne laste opp video direkte fra egen maskin, altså man skulle ikke være avhengig av en tredjepart for eksempel youtube og at innholdet på siden skal være på engelsk Valg av teknologi Det eneste egnede programmeringsspråket vi har vært borti på HiO er PHP. Derfor var det veldig naturlig for oss at det var dette vi skulle benytte oss av. PHP er også åpent tilgjengelig og kan kjøres på alle plattformer. Vi vil også benytte oss av MySQL som databaseplattform. MySQL- plattformen har vi brukt tidligere og også i andre prosjekter ved HiO. Ettersom videoløsningen skal være nettbasert, må vi også benytte oss av HTML, CSS, FLASH og javascript. Etter samtaler med veileder ble vi anbefalt et CMS-program som heter Joomla. Joomla er basert på php og mysql og ville ifølge vår veileder passe perfekt til den type nettside vi nå skulle lage, altså en videokanal. 46

47 14.3 Beskrivelse av Teknologi CMS Content Management System er en programvare som kjører på en webserver. Oftest som en databaseapplikasjon som i Joomla sitt tifellet; med MySQL. Fig3 Joomlas grafiske brukergrensesnitt for administrator. Hovedvekten til CMS systemet er den grafiske formen for administrering. Administrator kan enkelt gjennom brukergrensesnittet lage artikler, laste opp bilder, laste opp video og vedlikeholde siden generelt for å opprettholde nettstedets kompleksitet og kontinuitet. Alt dette uten tekniske kunnskaper om html, css eller andre programmeringspråk Om joomla Joomla er et populært og prisbelønt Content Management System, også kalt CMS. Systemet er et verktøy for publisering av nettsteder og kraftige online applikasjoner. Navnet kommer fra lyden av et Swahilisk ord. Ordet «jumla» betyr «all together» eller «som en helhet». Navnet ble valgt for å reflektere samholdet i Joomla! Det er mange faktorer som spiller inn angående Joomlas økende popularitet etter at den første versjonen ble publisert september Vi skal her snakke litt om de største og viktigste aspektene ved vårt valg av utviklingsverktøyet Joomla!: Åpen kildekode Omtales ofte med begrepet «Open Source» på engelsk, betyr at kildekoden til et dataprogram, i dette tilfellet Joomla!, er gjort tilgjengelig for alle. Det finnes flere forskjellige lisenser for «Open Source», men den mest brukte er GNU-General Public License (GPL). 47

48 Teknologien Joomla er skrevet i PHP, bruker objektorientert programmering (OOP) teknikker og programvare design mønstre, lagrer data i en MySQL database. Sidene blir skrevet med HTML og CSS. PHP PHP er et dynamisk, tolket og løst typet programmeringsspråk hovedsakelig brukt for å utvikle dynamiske nettsider. PHP syntaks ligner på C og Perl. Den vanligste implementasjonen av PHP er en fri og åpen versjon skrevet i C og distribuert av The PHP Group via php.net. HTML HyperText Markup Language (HTML, hypertekstmarkeringsspråk) er et markeringsspråk for formatering av nettsider med hypertekst og annen informasjon som kan vises i en nettleser. HTML benyttes til å strukturere informasjon angi noe tekst som overskrifter, avsnitt, lister og så videre. CSS Cascading Style Sheets (CSS) er et språk som brukes til å definere utseende på filer skrevet i HTML eller XML. Prinsippet er at HTML- eller XML-dokumentet utelukkende skal beskrive struktur og semantikk, mens oppsett, farger og annen stilinformasjon skal beskrives ved hjelp av CSS. Stilinformasjonen kan integreres i selve dokumentet eller skilles ut som en egen fil med endelsen.css. Et ubegrenset antall dokumenter kan peke til og styres av samme.css-fil, noe som er styrken i CSS: Ved å endre på en fil, kan man endre fargebruk, bakgrunnsbilder osv. i alle dokumenter som peker til CSS-filen. MySQL Mysql er et SQL-basert databaseadministrasjonssystem som er lisensiert under GPL. Mysql er også lett å bruke og sette opp, gratis og holder en høy ytelse i forhold til både pris og krav til maskinvare Gode administrator muligheter/enkel bruk Joomla har meget gode administratormuligheter, og det grafiske brukergrensesnittet overgår all forventning. Som ansvarlig av en ferdigstilt webside vil administrator kunne vedlikeholde, publisere og oppdatere data osv. uten noen tekniske ferdigheter eller kunnskap om hverken html, css eller andre programmeringspråk. 48

49 Gode utvidelsesmuligheter Joomla er veldig brukervennlig og fleksibelt, og har enorme utvidelsesmuligheter. Det finnes et stort arsenal av funksjoner innebygd i joomla, men den reelle makten ligger i måten du tilpasser Joomla på, og hvordan du bruker utvidelsesmulighetene. På tross av Joomlas brukervennlighet og innebygde styringssystemer er det en svært vanskelig læringsprosess som må gjennomgås om man aldri har arbeidet med dette tidligere. Heldigvis finnes det en mengde lærings-materiale tilgjengelig på Internett Krav for bruk av teknologien For å kunne installere joomla i webserveren er det visse krav som må oppfylles Systemkrav for Joomla 1.5 Programvare Anbefalt Minimum PHP * 5, MySQL ** 4.1.x + 3,23 Apache *** (med mod_mysql, mod_xml, og mod_zlib) 2.x + 1,3 Microsoft IIS **** 7 6 fig4 systemkrav for joomla Joomla er ikke kompatibel med MySQL 6. Joomla er optimalisert for Apache server. Joomla 1.6 krever altså PHP 5 eller høyere, og MySQL 5. Ettersom vi skal lage en videotube må vi også ta hensyn til lagringsplass når vi velger webhotel. Vi valgte derfor å binde oss til Inmotion Hosting som innehar følgende relevante spesifikasjoner: Disk plass (GB) ubegrenset FTP Accounts (1,000 stk) Sikker POP3/IMAP/SMTP Epost PHP - Versjon 5 tilgjengelig MySQL - Versjon 5 tilgjengelig 49

50 Tilgang til php.ini Det var viktig for oss at vi kunne ha full tilgang til php.ini, slik at vi selv kunne endre på blant annet maksimal opplasting per person, per video. Mange webhotel gir deg ikke tilgang til å overstyre denne fila. Her er endringene vi gjorde for å tilpasse vårt prosjekt: php.ini: upload_max_filesize = 100M (Default: 12M) post_max_size = 20M (Default: 10M) 14.5 Andre løsninger Det finnes flere CMS (content management system) løsninger i dag, de mest populære er Wordpress, Drupal og Joomla. De siste årene har Wordpress vist seg frem som en utfordrer og er på vei opp for å være en ekte CMS, mens de to andre variantene har kjempet i toppen for å være den beste CMS løsningen i markedet. Begge er åpne kildekoder, og har tusenvis av medlemmer som hjelper med videreutviklingen av systemene Wordpress Mens Wordpress regnes som underdog i CMS krigen, er den definitivt kongen av blogging programvare, noe joomla og drupal bør gjøre noe med i fremtiden. Wordpress er et utmerket system å bruke når du oppretter et nettsted som lar deg raskt få dine tanker ut på nettet, men mens det er ofte brukt som en blogg, kan det være konfigurert til å fungere i mange andre interessante måter også. Fordeler med Wordpress: Enkel å bruke, ikke behov for modifikasjoner. Utmerket for blogging, eller dele taker i en sekvensiell måte. Brukere med minimalt it kunnskap kan få tak på det meste. Ulemper med Wordpress: Ikke utviklervennlig Brukerne klager ofte på systemet Oppdateringer fører oftere til problemer enn løsninger 50

51 Drupal Liker man å håndkode innholdet i siden på egenhånd, da er Drupal det riktige valget. Dette avanserte CM Systemet likner mer en utvikler plattform enn tradisjonell CMS. Det er ikke riktig å si at kun programmerere og utviklere kan bruke Drupal, men de vil føle seg mer hjemme enn ved bruk av Wordpress. Nettsidene som blir laget ved hjelp av drupal fungerer på en fin måte, men de er ikke kjent for å fokusere veldig mye på design. Det er litt synd da det ville vært perfekt med en sterkere brukervennlighet og design grensesnitt. Fordeler med Drupal: Ekstremt utviklervennlig Stor popularitet blant brukere, hundrevis av funksjoner og koder tilgjenglig. Kan brukes til å lage fantastiske hjemmesider som overgår mange der ut. Ulemper med Drupal: Lite design og brukervennlig. Vanskelig for en med lite kode kunnskaper. Administrator må ha gode programmeringskunnskaper for å administrere siden. Å publisert en Drupal webside koster mye tid, dermed mer penger enn Wordpress eller Joomla. 51

52 Del 3 15 Oppbygging og virkemåte 15.1 Introduksjon Under denne delen går vi gjennom hensikten og hva systemet kan gjøre. Formålet med websiden er å gi ett enkelt system til veldedighetsorganisasjoner i hele verden for å kunne promotere og fortelle om seg selv ved å laste opp korte videosnutter. Charitytube bygger på prinsippet om at de registrerte skal laste opp video om seg selv og arbeidet deres, besøkende skal kunne se de forskjellige videoene og deretter kontakte organisasjonene for donasjoner. At flere organisasjoner samles i en felles side, blir det letter for givere å finne veldedigheten de ønsker å støtte. Det er selvfølgelig mange utfordringer knyttet til oppnåelsen av dette på en ryddig måte. Administrator må passe på at data kontrolleres før den blir publisert, at det ikke er mobbing og trakassering av organisasjoner og målgrupper. Administrator skal ha mulighet til å utestenge de som prøver seg. Dette er bare noen av utfordringene som vi har måttet løse underveis. Systemet består av to deler: bruker og administrator del. De fyller forskjellige krav og er tydelig fraskilt. Begge delene er webbasert og er tilgjengelig fra hvilken som helst plass i verden, så lenge brukeren har nettilgang. I utgangspunktet skal alle nettlesere og operativsystemer gi samme brukeropplevelse. Alt dette var en selvfølge når vi startet designet av websiden Design, brukergrensesnitt og tilgjenglighet For å oppnå best mulig brukervennlighet, har vi prøvd å lage ett grensesnitt som er enkel og intuitivt. For å unngå at brukerne skal rote seg bort i de overflødige funksjonalitetene, har vi tatt med kun det som er nødvendig for systemet Layout Når det gjelder fargevalg, har vi satset på farger og nyansene som er behaglige for brukerne. Kontrasten mellom grått og blått faller i god smak, det har blitt brukt mye tid og resurser på fargevalg da dette er en viktig faktor for oppdragsgiveren. Ved å legge alt som er relevant for brukerne i en egen user menu til venstre i forsiden(fig5), har vi redusert antall klikk ganske kraftig. 52

53 Fig5 layout av websiden Oppdragsgiver ønsket en logo for CharityTube, og vi fikk frie hender. Ettersom det dreier seg om en tube valgte vi å lage en logo som lignet youtube sin logo, slik at besøkende på en intuitiv måte vil oppfatte at websiden er en «tube». Logoen ble laget med Adobe Photoshop. Fig6 logo Grensesnitt og Brukervennlighet Store deler av brukergrensesnittet er skrevet i HTML, PHP og CSS. Ved det har vi redusert kravet til maskinvare og programvare hos klient maskinene. Det var uunngåelig å benytte flash for videofunksjonen, dette setter derimot ett krav hos brukerens maskiner. Vi har også laget nettsiden slik at den kan skaleres ved hjelp av den innebygde zoom funksjonen i nettleseren på en god og hensiktsmessig måte. I utgangspunktet er teksten godt tilpasset for det meste av brukermassen. Skulle det være noe tvil, finner man en funksjon i headeren som endrer skriftstørrelsen på siden. Nettsiden er validert av W3C, både HTML koden og CSS filene er godkjent. Noe som nok en gang hjelper til på nettleser kompatibilitet og unngår at man får seg en overraskelse når brukere benytter forskjellige nettlesere enn de som er blitt brukt i interne tester. Vi valgte å 53

54 programmere i W3C HTML standard: XHTML Transitional 1.0 siden det er det vi er vant til, og det er dette som er den standarden som brukes hyppigst til dags Kommunikasjon Kommunikasjon fra klient til server og omvent skjer gjennom internett og HTTP protokollen. Systemet fungerer uten bruk av cookies som lagres på klientmaskinen. Det er serveren som holder rede på hvem som er innloget ved hjelp av session variabler. Ingen informasjon om aktiviteten på applikasjonen vil bli lagret av nettleseren Delene Brukerdel En viktig funksjonalitet i grensesnittet er registrerte brukeres mulighet til å laste opp videoer. Det vil derfor dukke opp en brukermeny når bruker har logget inn med brukernavn og passord. Figuren under viser alternativene i brukermenyen. Fig7 User Menu Naturlig nok finnes det funksjoner for hver brukers mulighet til å slette videoer, endre på videoer og holde generelt oversikt over sin egen data. Vi har modifisert videokomponenten slik at den kun viser kravspesifiserte områder på en intuitiv og enkel måte for brukeren. Figuren under viser hvordan dette fungerer i praksis. Fig8 My Videos 54

55 Ved opplasting av video må følgende data fylles inn for å kunne ferdiggjøre opplastingen Valg av url video, eller opplasting fra egen pc Tittel Thumbnail bilde Beskrivelse Valg av kategori Og om video skal vises kun for medlemmer eller for alle besøkende. Vi har satt følgende begrensninger, Fig9 Last opp en video Maks 100 MB video 200 ord til beskrivelse Maks 1 kategori per video Administratordel Personene med det overordnede ansvaret for websiden, skal benytte seg av administratorsiden for å gjøre endring og holde oversikt. Alt dette gjennom et brukervennlig grafisk grensesnitt. Ettersom administrator i dette tilfellet ikke har noen data-tekninske kunnskaper, har vi valgt å ha fokus på kun den viktigste biten av administrators mange muligheter. Under ser du hovedmenyen i det grafiske grensesnittet til joomla for administrator: Fig10 Administrators kontrollpanel Vi har gitt administrator mulighet å gjøre følgende endringer på selve websiden etter innlogging: 55

56 Registrere, endre eller slette brukere Fig11 Bruker oversikt Her ser vi hvordan administrator kan holde oversikt over, redigere, eller eventuelt slette brukere. Det finnes også mulighet for å legge til nye brukere. Henter følgende fra jos_users databasen: ('a.name', 'a.username', 'a.block', 'groupname', 'a. ', 'a.lastvisitdate', 'a.id') Endre på menyene Som administrator kan du også endre på menyen. I eksempelet nedenfor kan administrator gjøre endringer i hovedmenyen, eventuelt legge til nye emner. Fig x i front end, og fig x i back end) Fig12 Oversikt over menyer i back end systemet. Fig13 Hovedmenyen 56

57 Godkjenne og publisere brukernes videoer Her følger endringene administrator kan foreta seg under Videokomponenten: Når brukerne laster opp en video vil den ikke automatisk bli publisert. Videoen venter da på godkjenning fra administrator. Nedenfor viser vi hvordan administrator enkelt kan publisere, eller ikke publisere videoer på som er på vent. Her kan det også slettes videoer, redigere videoer eller sette videoer som anbefalt (featured). Her holder administrator også en generell oversikt over videoene, og kan se feks hvor mange ganger en video har blitt vist. Fig14 Oversikt over opplastede videoer Som figur 14 viser kan administrator enkelt merke en video og publish/unpublish. 57

58 Gjøre generelle layout endringer Innebygd i Joomla finnes det funksjoner som gjør det mulig å endre noen av parametrene i selve layouten. Administrator har som vist nedenfor mulighet til å endre noen av egenskapene i CSS-filene uten å gå inn i selve CSS- og HTML kodene. Fig15 Panel for endring av layout 58

59 Redigere eller lage nye kategorier I likhet med videoene kan administrator også redigere videospillerens kategorier. Lage ny, endre eller slette kategorier. Fig16 Oversikt over videokategorier Endre avanserte innstillinger på videospilleren (høyde/bredde, etc.) Administrator har også mulighet til å endre innstillingene til videokomponentens parametere. Fig17 Innstillinger for videospiller 59

60 Del 4 16 Database 16.1 Introduksjon CharityTube bruker SQL-setninger for samtlige gjøremål. Programmeringen er gjort med tanke på at websiden skal brukes i ett MySQL-tjener miljø. Under installasjon av joomla blir databasen vi har opprettet fylt opp med forskjellige tabeller for administrering av siden. For å forstå best mulig funksjonaliteten til siden og oppbygging av den, har vi satt oss godt inn i innholdet og funksjonen til disse tabellene. For en ryddig databasen om minimalt med dobbeltlagring, satte vi oss som mål at den følger tredje normalform. Dataene som blir lagret er delt opp logisk, slik at man ikke skal trenge å blande inn for mange tabeller for å komme frem til den dataen man ønsker. I denne delen av rapporten vil hele databasens oppbygning og funksjon bli gått gjennom. Funksjonaliteten som dekkes av de ulike tabellene vil bli forklart, og verdier som kan virke kryptiske vil bli gitt en mening. Målet med dette er å gi administrator en forklaring på hvordan han skal behandle informasjon som skal ut eller inn fra databasen. Vi har prøvd å gjøre tabellene og datastrukturene så enkle og forståelig som mulig, slik at det skal være lett å sette seg inn for administratorer og videreutviklere. Alle forklaringene av de ulike tabellene som fortsetter videre inneholder en figur printet ut fra MySQLWorkbench. 60

61 16.2 Strukturer Det er opprettet flere tabeller i databasen, under forklares Tabeller users Denne tabellen inneholder nødvendig data om alle brukere. Informasjon som lagres i tabellen er: Ett unikt bruker identifikasjonsnummer, som er usynlig og transparent for brukere. En tabellene bør alltid ha en unik primærnøkkel, det for å unngå problemer når man registrere store mengder data og senere finne den fram. Navn, brukernavn, og passord blir også lagret. Passordet blir ikke lagret i klartekst, men i hash form. Tabellen users forteller også om slags brukertype som er registrert. Administratorer, superbrukere, og flere brukertyper er lagret i samme database. Det var ikke nødvendig å splitte de i flere tabeller da en bruker kan kun ha en tittel, man kan ikke være administrator og superbruker samtidig, og dermed får man aldri dobbelt lagring. Users forteller også om når brukeren ble registrert, om kontoen er aktivert og siste innloggingsdag. Fig18 Databasetabell users 61

62 Tabeller Components Components tabellen tar for seg all nødvendig data om komponentene som er installert i joomla. Både hovedlinken og underlinkene i komponenten. Dette er en tabell som er opprettet av joomla og ikke påvirket av oss. Tabellen har den unike identifikasjonsnummer, som blir gitt til hver komponent. Dette er primærnøkkelen. Tabellen forteller også om navn, om det er hovedlink eller underlink til en komponent i administrator menyen. Den innholder også bilde/logo til komponenten. Fig19 Databasetabell komponenter 62

63 Tabeller Modules Dette er også en tabell som er implementert av joomla. jos_modules fremstiller dataen om de forskjellige modulene som er blitt installert. Tabellen har en identifikasjonsvariabel id, som er primærnøkkel. jos_modules forteller oss tittel på modulen, innhold (f.eks logo), plasserings rekkefølge, posisjon/plassering i siden, publiseringsstatus, navn på modulen. Dataene i denne tabellen brukes i administrasjonsdelen av systemet, under module manager Fig20 Databasetabell moduler 63

64 Tabeller session Det er mange grunner til å bruker session når man oppretter en web-basert applikasjon som bruker PHP. Session informasjon, som standard, er lagret i en fil på webserveren. Det er ikke særlig sikkert. Denne tabellen har en session_id som identifikasjonsvariabel. Den forteller også om brukernavn til den som er pålogget, tiden han logget inn, om man er gjest eller bruker, hvis bruker lagres det brukerid fra tabellen user, brukertype, gruppeid, klientid, og dataen om brukeren. Under data lagres det alt info om nettleser, os og diverse data. Fig21 Databasetabell session Tabeller Menu Fig22 Databasetabellene menu og menu_type Meny tabellen innholder den unike id identifikasjonsnøkkel for hver punkt i en menytype (f.eks Home i mainmenu). Dette er enda en tabell som er implementert av joomla i likhet med modules og components. Den innholder data om hvem punkt i en meny, menutype, navn, link man blir sendt til når man klikker, typemeny, om den er publiser, om det er en undermeny, komponentid hvis det er en av type komponent, sortering av rekkefølge, parameter innstilling og om hvilken av menypunktne som er forsiden. 64

65 Tabeller Videos" hdflv_category er en tabell med data om video kategoriene. Den består av en primærnøkkel id, category navn, om det er underkategori id, sortering etter rekkefølge, og om kategorien er publisert. Fig23 Databasetabell Videokategori Her lagres all dataen etter at en video er blitt opplastet. Tabellen har også en unik primærnøkkel som brukes for binde den sammen med andre tabeller. Det lagres brukerid av opplaster. Published er en variabel som forteller om videon er publisert eller ikke. Den er satt som default å ikke publisere. Andre data som lagres er tittel på video, om den er blant de anbefalte, antall ganger den er blitt vist, og viltype. Antall ganger vist er veldig kjekt da man kan skille mellom de populær videoen. Man finner også link til video, dette er en link til ftp serveren eller tredjepart servere som youtube, google osv. Beskrivelse av video og opplastingsdato er også nedskrevet i denne tabellen. Fig24 Databasetabell opplasting av video 65

66 Del 5 17 Funksjonalitet 17.1 Templates Templets handler om joomlas layout og visuelle fremvisning. Det er en slags mal som kan redigeres til ønskelig resultat. Templaten er lagret seperat fra alt annet innhold på MySQL databasen. Templetene finner man i «templets» mappen i ROOT. Det finnes forskjellige templates, men hver templat består av følgene filer: index.php Denne filen inneholder HTML, PHP og noen mulige javascript som definerer rammene til websiden. Ved å kombinere index.php med CSS- og bilde filer får man helheten av utformingen. templatedetails.xml TemplateDetails.xml filen er en viktig fil. Uten den vil ikke templaten bli gjennkjent av Joomla. Filen inneholder "metaverdier" om malen (tabeller, rader, indekser og struktur ). template_thumbnail.png Dette er bare bilde av templaten, en thumbnail. template_css.css Denne fila ligger i css-mappen. Her ligger CSS filene (Cascading Style Sheets) som håndterer de visuelle effektene på nettstedet. Alt fra fontstørrelse til farger. Man kan ha mange forsjellige css filer forutsatt hensiktsmessig HTML referanse i index.php-filen. Eventuelle media filer Media filer som er lokalisert i «images» mappen. Filer som.gif.png.jpg. Dette er grafiske elementer koblet opp mot css filene. For eksempel så ligger logoen våres i denne mappen. Som nevnt tidligere kan administrator gå inn å endre noen simple innstillingene uten å grave i kodene. Vi har naturlig nok endret og konfigurert vår egen mal ved hjelp av justeringer i php, css og html kodene. 66

67 17.2 Noen CSS endringer Det første som var viktig for våres del var å endre posisjoner som joomla-templaten hadde satt. Vi visste hvordan vi ville ha det og hadde lagd en skisse med arbeidsgiver fra starten. Templetene fungerer med forskjellige posisjoner, så først og fremst måtte disse stå riktig CSS endringer i layout.css for optimalisering av possisjon For optimalisering Først og fremst var det viktig at posisjoneringene fikk samme output i de forskjellige nettlesere (IExplorer, Firefox, Opera, Chrome). Ofte oppstår det pikselproblemer på tvers av nettlesere, dette ordnet vi med å implementere følgende kode i toppen av CSS-filen for å resette alle satte posisjonsendringer: *{margin:0; padding:0;} kode benyttet for endring av posisjonering: position:(fixed eller ralative); z-index: «antall»; padding-top: «antallpiksler»px; padding-left: «antallpiksler»px; padding-right: «antallpiksler»px; margin-top: «antallpiksler»px margin-bottom: «antallpiksler»px margin-right: «antallpiksler»px margin-left: «antallpiksler»px width: «antallpiksler»px ; height: «antallpiksler»px ; float:«left/right/none»; I eksempelet nedenfor kan man se hvordan posisjonene er lagt opp og hvordan css-filen påvirker posisjonene. Alle posisjonene er merket med svart firkant. 67

68 Fig25 Posisjoner For å ha en ryddig template har vi slettet de module-posisionene som var unødige. Dette gjorde vi via ftp klienten, hvor vi fikk tilgang til template.php. Dermed sitter vi igjen kun med det som er nødvendig for vår del Moduler, komponenter & Php modefikasjon. En modul i joomla er en tilleggsfunksjonalitet til nettsiden. Den er som regel knyttet til en komponent. Som joomlabruker kan man laste ned tusenvis av forskjellige moduler og komponenter. Modulene installeres, aktiveres og kobles til en posisjon(som vi snakket om ovenfor). Det er full tilgang til koden(open source), så alle moduler og komponenter kan modifiseres ved å implementere eller gjøre endringer i kodene. Vi har i valgt å benytte oss av 3 komponenter og 11 moduler, hvorav alle er aktivert og i bruk Contus HD Video Share Contus videoshare er selve videospilleren våres. Det er den kraftigste komponenten og har posisjon midt på startsiden. Den har som hovedoppgave å spille av videoene for publikum. Vi har modifisert følgende funksjonaliteter i videokomponenten: 68

69 Upload video Først gjorde vi endringer slik at videoene ikke ble publisert med en gang en bruker lastet opp video. Et av kravene var som vi snakket om tildligere, at administrator ville se gjennom videoen før den ble publisert for å unngå spam etc. Vi endret følgende php kode: defeault.php $query='insert into # hdflv_upload(title,filepath,videourl,thumburl,previewurl,published,type,memberid,descripti on,created_date,addedon,playlistid,hdurl) values ("'.$title.'","'.$ftype.'","'.$url.'","'.$img.'","'.$previewurl.'","1","'.$type.'","'.$memberid.'","'.$des cription.'","'.$cdate.'","'.$cdate.'","'.$cid.'","'.$hd.'")'; Vi satt tallet 1, til 0. Denne lille endringen gjør at videoen ikke automatisk blir publisert. Ettersom ikke video blir publisert med en gang, må også personen som laster opp video få beskjed om dette. Derfor implementerte vi følgende php kode: default.php $success=""; $success="your video Uploaded Successfully, And Will be Published by Administrator as Soon as Possible"; return array($category1,$success,$editvideo1); Edit video Editering av video fungerte veldig bra, og det ble bare gjort noen enkle html-endring av teksten på formene Count views Her ser vi hvordan sql-spørringen teller antall views og plusser med en for å få riktig antall views: $query="update # hdflv_upload SET times_viewed=1+times_viewed where id=$playid"; 69

70 Featured Videos Vi ville også forandre hvordan featured videos ble vist frem i spilleren slik at alle videoene som er featured blir fremvist i tilfeldig rekkefølge, og ikke etter når de ble valgt som featured. Vi implementerte følgende SQL kode for å løse problemet. Player.php group by e.vid order by rand() $featuredquery = "select a.*,b.category,d.username,e.* from # hdflv_upload a left join # users d on a.memberid=d.id left join # hdflv_video_category e on e.vid=a.id left join # hdflv_category b on e.catid=b.id where a.published='1' and a.featured='1' and a.type='0' group by e.vid order by rand() limit 0,$featurelimit "; Banner Banner er den komponenten vi bruker til «Advertisement». Administrator kan laste opp reklame i denne komponenten, for så å holde en oversikt over feks hvor mange klikk hver enkelt reklame har hatt. Her er koden for hvordan banner-komponenten teller antall klikk: // Oppdaterer antall klikk $query = 'UPDATE # banner'. ' SET clicks = ( clicks + 1 )'. ' WHERE bid = '. (int)$id; Flexi Contact Dette er en komponent vi bruker slik at besøkende kan sende inn spørsmål etc til eieren av websiden. Denne fungerer til akkurat det den skal og vi har ikke gjort noen spesielle endringer i php-kodene mod_yoo_login Denne modulene bruker vi for innlogging med brukernavn og passord, samt utlogging. 70

71 Fig26 Logg in modul mod_mainmenu Denne modulen benytter vi oss av i alle menyfeltene på web siden. Fig27 Hovedmeny modul Search Tube Denne modulen er plassert oppe i høyre på web-siden og er fungerer som søkemotoren til videospilleren. Fig28 Søkemotor for video Advanced Copyright Module Denne modulen har vi lagt i bunnen av web-siden. Den har kun som funksjonalitet og vise frem copyright datoene w3c.org CSS/XHTML Validator Et av kravene til web-siden er at den skal valideres og godkjennes som CSS og XHTML produkt. Modulen har som oppgave å re-dirigerer bildene til validator sidene. Fig29 viser modulene Copyright og w3c Front-end Font Size Adjuster Fig30 Font size endring Modulen er til for å kunne forandre web-sidens tekststørrelsen. Fig x viser Font size modulen 71

72 Endringer i php.ini For å sette upload-størrelsen på et relativt høyt nivå, må vi gjøre noen endringer. Web hotellet har en standard som er satt til 12mb. Vi må sette vil sette denne grensen til 100mb. Ikke alle web-hoster tillater endring i php.ini -fil, men i vårt tilfellet har vi full tilgang. Endring av php.ini er den enkleste og sikreste måten å gjøre slike endringer på. Har man ikke tilgang til endringer av denne filen kan det gjøres med endringer i.htaccess-filen til apache server. Endret flgende kodesetning i php.ini: upload_max_filesize = 100M 72

73 Del 6 18 Sikkerhet 18.1 Generelt Sikkerheten i charitytube er hele veien blitt tatt i betraktning. Under implementering av systemet har vi tatt hensyn til scenarioer som kan dukke opp fra ondsinnede brukere. Det har blitt vist hensyn til at dataen som blir publisert skal til en hver tid kontrolleres av administratoren før det legges ut for offentlighet. Inputen som blir hentet inn fra brukeren går igjennom ett innebgyd sql-injection filter i PHP. Det skal ikke være mulig for brukere å sende eksekverbare kodesnutter til applikasjonen eller databasen. Per i dag kommuniserer siden via HTTP kanalen, dette er kjent for å være en mindre sikker kanal, men nok for charitytubes behov. Skulle det i en senere anledning implementeres donasjonsmulighet for organisasjoner, er det i aller høyeste grad viktig å videreutvikle applikasjonen for å støtte HTTPS slik at man får bedre sikring mot eavesdropping, og tyveri av givernes opplysninger Passord Når det gjelder brukernes passord, er den blitt lagret i databasen users med en en-veis hash. Det er gjort for at de ikke skal finnes som lesbar form noen sted i kildekoden eller databasen. Det er forskjellig hash krypteringsformer, som f.eks MD5 denne typen frarådes ettersom det er kjente hull i den. SHA2 (256-bit) viser seg å være ett bedre alternativ. På denne måte slipper man å risikere at brukernes passord kommer på avveie selv om databasen skulle bli kompromittert. Skulle det være ønskelig kan man lett endre til en annen form for hash i senere tid ved å endre på passord variabelen som finnes i auth.inc.php. Er brukeren uheldig og glemmer passordet, sendes det en kode i e-post som gir brukeren mulighet til å lage en ny kode. Ett passord som er en-veis hashkryptert kan ikke hentes tilbake i lesbarform. Dermed er bytte av passord den eneste løsningen. 73

74 Del 7 19 Produkt vs kravspesifikasjon Når vi ser på produktet som en helhet, og sammenligner med de gitte kravspesifikasjonene, mener vi at web-siden innfrir til forventningene. Vi skulle lage en videokanal, hvor veldedighetsorganisasjoner kunne laste opp video for å dele med omverdenen. Akkurat dette har vi gjort og alle funksjonalitetene til videokanalen er fungerende. Punktene som vi ikke har fått gjennomført er: Administratordel Brukerdel Motta e-post når bruker laster opp video. Mulighet for å kommentere andres videoer. Videofunksjon Del 8 Komprimering av video under opplasting Kommentarfelt under hver video 20 Videreutvikling Prosjektet og CharityTube er godt utviklet, og i full funksjonalitet. Men det er alltid ting som kan implementeres eller forbedres. Vi har gitt systemet ett godt grunnlag for å kunne videreutvikles. Applikasjonen slik som den er i dag har noen mangler, men kan raskt ferdigstilles av en god php programmerer som har erfaring med joomla. Ting vi mener står på listen over fremtidige utvikling er: Kommentarfelt for video Paypal donasjon direkte fra webside CharityTube forum Fremvisning av logo på videospiller Teste siden på brukere med nedsatt funksjoner Samt avvikene fra kravspesifikasjon. 74

75 75

76 76

77 Brukerveiledning Forord Denne brukermanualen innholder beskrivelse av systemets funksjonalitet og introduserer systemet for brukeren. Brukermanualen er delt inn i to deler. Beskrivelse for: Brukerdel Administratordel 77

78 Innhold 21 ADMINISTRATOR Innlogging Kontrollpanel Beskrivelse av «Global Configuration» Beskrivelse av «user manager» Beskrivelse av «Media manager» Videokomponenten Member Videos Admin Videos Member detail Category Player settings Site settings Google adsense BRUKER Registrering Logg inn Brukermeny Edit details Upload Video My videos

79 21 Administrator 21.1 Innlogging Innlogging til administrator siden skjer via ( Logg inn med tildelt brukernavn og passord som vist nedenfor. Her kan det også velges alternative språk om ønskelig. fig 1. Innlogging for administrator 21.2 Kontrollpanel Kontrollpanelet(fig 2) er det første som møter administrator etter innlogging. Vi skal se nærmere på de forskjellige funksjonene. fig 2. Administrators kontrollpanel 79

80 21.3 Beskrivelse av «Global Configuration» Her kan globale endringer enkelt utføres. Alle utførelsene avsluttes med «save» eller «apply» for å lagre. Fig 3 Golbal configuration 21.4 Beskrivelse av «user manager» En grei oversikt over alle som har registrert seg. Her kan admin slette/endre/registrere brukere. Fig 4 User manager 80

81 21.5 Beskrivelse av «Media manager» Her finnes oversikten over alle mediafilene(ikke mediafilene til videokomponenten). I vårt tilfellet er det mappen «advertisement» som er aktuell. Laster man opp bilder(reklame) i denne mappen, så vil bildene gå som et «slideshow» til høyre på websiden, under «advertisment». Administrator kan også slette og lage nye mapper og filer. Fig 5 Media manager 21.6 Videokomponenten For å administrere videokomponenten: Hold musepeker over Components > ContusHDvideoShare > (et av alternativene) Fig 6 Contus HD Video Share 81

82 Member Videos Det er under Member videos administrator publiserer og godkjenner videoene som er blitt lastet opp. Her velger også administrator om videoen skal anbefales og vises på forsiden. Member videos viser er oversikt over alle videoen som er lastet opp av registrerte brukere. Her kan administrator publisere/slette/redigere videoer. Fig 7 Member videos Admin Videos Tilsvarende «member videos»(fig 7). Bortsett fra at her er det kun administrators opplastinger som ligger Member detail Detaljer over registrerte brukere. Muligheter for administrator til å aktivere/deaktivere/ brukere. Admin kan også nekte brukere å kunne laste opp video. 82

83 Fig 8 Member details Category Det er her alle kategoriene settes. De kan også endres, og administrator kan legge til nye kategorier. Vi anbefaler og ikke endre på disse innstillingene Player settings Her vises alle innstillingene til videokomponenten. Vi anbefaler og ikke endre på disse innstillingene Site settings Her vises alle innstillingene til den visuelle delen av videokomponenten. Vi anbefaler og ikke endre på disse innstillingene Google adsense AdSense er Googles reklameprogram. Adsense tilbyr deg å reklamere for et eller annet produkt, eller å putte reklame på din side. Hvis du vil reklamere koster det per klikk du får, mens hvis du har reklame på sida di får du penger for hvert klikk noen gjør på reklamen. Vi anbefaler og ikke endre på disse innstillingene. 83

84 22 Bruker Tilgang til brukerdelen skjer fra ( Registrering Det første en bruker må gjøre for å laste opp video er å registrere seg på charity tube. Det gjøres ved å holde musepeker over login, for så å trykke på «create an account». Fig 8 Create an account Følgende registreringsskjema må fylles inn, og avslutte med et trykk på «register». Bruker vil da få en melding om at brukeren ble opprettet: Fig 9 Register 84

85 Følgende melding vil komme om registreringen var vellykket: «Your account has been created and an activation link has been sent to the address you entered. Note that you must activate the account by clicking on the activation link when you get the before you can login.» For å unngå spam er det påkrevd å trykke på en aktiviseringslink for at bruker skal bli godkjent. Denne mailen bli sent til din registrerte epostadresse. Når bruker trykker på aktiviseringslinken blir følgende beskjed synlig: fig 10 Activation Complete 22.2 Logg inn Når aktivisering er unnagjort er det bare å logge inn. Innlogging ( Logg inn med brukernavn og passord som vist nedenfor. Fig 11 login 85

86 22.3 Brukermeny Etter innlogging vil det dukke opp en brukermeny som ser slik ut: fig 12 Brukermeny 22.4 Edit details Her kan brukeren oppdatere og redigere sine egene detaljer, og avslutte med «save». Vist feks bruker har endret epost adresse. fig 13 Edit details 86

87 22.5 Upload Video Det er her bruker laster opp video. Følgende må fylles inn: fig 15 Upload Video Etter at videoen er lastet opp får bruker beskjed om at videoen er lastet opp, men vil ikke bli publisert før administrator har godkjent den. 87

88 22.6 My videos My videos gir en oversikt over alle videoer som bruker har opplastet. Her kan brukeren spille av, redigere, og slette videoene. fig 14 My videos 23 Kilder Wikipedia Systemkrav joomla Andre løsninger Inmotion spesifikasjoner

89 89

90 90

91 Testrapport Forord Dette dokumentet er testrapporten for hovedprosjektet, og skal gi en oversikt over all testing utført på systemet under og etter ferdigstilling, samt feil og løsninger gruppen har funnet. 91

92 Innhold TESTRAPPORT FORORD INNHOLD INNLEDNING TEST AV SYSTEMET Databasen og SQL spørringer Link sjekk Server test Port skanning Ping test Webleser kompatibilitet TEST AV FUNKSJONER Brukerdel Administratordel TESTING AV GUI/ GRENSESNITT Generelt Testmiljø Brukerdel Testperson Testperson Testperson Tilbakemeldinger fra brukerdel Administratordel Testperson Testperson Tilbakemeldinger fra administratordel

93 24 Innledning 24.1 Testing Testing av websiden ble utført for å minske diverse feil i systemet. Dokumentasjon av hva som er teste og hvordan, vil lette arbeide for de som skal vedlikeholde og videreutvikle systemet. Vi utviklet en skisse/prototype for å få ett bilde av hvordan vi så for oss at grensesnittet skulle se ut. Deretter ble det testet på vanlige brukere. Vi fikk veldig gode tilbakemeldinger og gjorde noen endringer før sluttskissen ble presentert for oppdragsgiveren. For å oppnå best mulig resultat bestemte vi oss for å foreta tre forskjellige tester av web-siden. Den første testen skulle ta for seg systemet, og om alt det tekniske fungerte. Det som ble testet under denne fasen var: Databasen og SQL spørringer Link sjekk Server test Port skanning Ping test Webleser kompatibilitet. Dette testet vi selv uten å bruke testpersoner. I den andre testfasen ville vi finne ut om web-sidens funksjoner virket som de skulle. Testperson var heller ikke nødvendig for denne fasen. Siste testfase var for å finne ut om web-siden var så intuitiv og enkel i bruk som vi hele tiden hadde antatt. For best mulig resultat, ble denne testen utført av et knippe personer med ulik IT bakgrunn. 25 Test av systemet 25.1 Databasen og SQL spørringer Database og spørring testen er for å kontrollere at databasen virker slik den skal og at spørringene gir oss de resultatene vi forventer. Testingen ble utført via ssh tilkobling ved bruk av putty Link sjekk Link sjekk ble gjort for å verifiserer URLs tilgjengelighet. Her nedlastes hele HTML-innhold, og kontrollerer tilgjengelighet av alle de interne komponentene og for alle lenker som finnes på siden. 93

94 25.3 Server test Serveren testen verifiserer tilgjengelighet og måler responstid av enhver TCP / UDP basert web service koblet til Internett. Server tester inkluderer HTTP,, FTP, SMTP, POP3, IMAP, SSH, DNS og tilpassede tjenester Port skanning Port Scan testen skanner noen av de mest populære portene på den angitte verten. Her testes følgende standard porter: 21 - FTP 22 - SSH 25 - SMTP 80 - HTTP POP IMAP 25.5 Ping test PING testen kontrollerer om en webside er tilgjengelig over Internett ved å sende flere ICMP pakker og lytter etter svar. PING testen måler tiden det tar pakker å gå fra den maskinen vi tester fra til verten svarer. Testresultatene viser korteste, den gjennomsnittlige og den maksimale rundturen ganger og pakketap rate mellom maskiner Webleser kompatibilitet Siden ble vist og testet med forskjellige nettlesere og operativsystemer for å kontrollere websidens kompatibilitet. Nettlesere som ble testet på operativsystemet til MAC OS X : Firefox og Opera Google Chrome Safari Nettlesere som ble test på operativsystemet Windows 7 er: Firefox 4 Opera 11 Internett Explorer 8 Google Chrome 11 Under viser vi noen bilder av resultatet. Testresultatene viser at det er ingen synlig forskjeller eller feil på web-siden ved bruk av de forskjellige nettlesere og operativsystemer. 94

95 Fig1 Chrome i MAC OS X Safari i Mac OS X 95

96 Fig2 Internett Explorer windows, Firefox windows 26 Test av funksjoner 26.1 Brukerdel Under denne fasen testes samtlige brukerfunksjoner i CharityTube Registre bruker fig Logg in fig Tilgang til brukermeny fig Endre selvinfo fig6 96

97 Last opp video fig Tilgang til mine video fig Endre video fig Kontakt oss fig Logg ut 97

98 fig Administratordel Under denne fasen testes samtlige administratorfunksjoner i CharityTube Logg inn fig Legg til bruker fig Endre rettighet på bruker fig Endre rettighet på bruker fig Slette bruker fig Opprett video kategori fig17 98