[1 INNLEDNING] 2
[1 INNLEDNING] PROSJEKT NR. 2013-18 HOVEDPROSJEKT TILGJENGELIGHET Åpen Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKTETS TITTEL Aptostat Systemovervåkning for Aptoma DATO 22.05.2013 ANTALL SIDER / BILAG 147/10 PROSJEKTDELTAKERE s171647 Maud Veronica Gine Lundh s171636 Noha Xue s171686 Ketil Øvrebø s171663 Even Geithus Øwre INTERN VEILEDER Norun Christine Sanderson OPPDRAGSGIVER Aptoma KONTAKTPERSON Kenneth Froholdt SAMMENDRAG Etter oppdrag fra Aptoma har det blitt utviklet et system, både front- og back-end, for systemovervåkning. Aptoma har allerede sensorer og eksterne overvåkningstjenester, men ville gjerne ha et system som samler feilmeldingene, grovfiltrerer dem for falsk alarm og presenterer feilmeldingene oversiktelig med mulighet for å håndtere dem og publisere dem for deres kunder. Hele dette sluttdokumentet dokumenterer prosess, produkt og testing. 3 STIKKORD Statusovervåkning REST-API AMP - Apache, MySQL, PHP 3
[1 INNLEDNING] Innholdfortegnelse [1 INNLEDNING]... 5 [2 PROSESSDOKUMENTASJON]... 12 [3 PRODUKTDOKUMENTASJON]... 44 [4 TESTDOKUMENTASJON]... 61 [5 APPENDIX]... 82 4
13-18 [1 INNLEDNING] Avd. for Ingeniørutdanning Maud Veronica Gine Lundh, Noha Xue, Ketil Øvrebø, Even Geithus Øwre [1 INNLEDNING] 5
[1 INNLEDNING] Forord Dette dokumentet inkluderer all sluttdokumentasjon i forbindelse med hovedprosjektet i bachelorstudiumet i Anvendt Datateknologi ved Høgskolen i Oslo og Akershus, våren 2013. Rapporten er også tilgjengelig på nettet på adressen http://student.iu.hio.no/hovedprosjekter/data/2013/18/files/sluttrapport13-18.pdf Rapporten består av 5 deler: Presentasjon Prosessdokumentasjon Inneholder en redegjørelse for vår utviklingsprosess. Produktdoumentasjon Testdokumentasjon Vedlegg Inneholder en beskrivelse av vårt produkt og dets bestandeler. Inneholder vår testplan, utførte brukertester og konklusjon. Inkluderer kravspesifikasjon, brukerveiledning, kildehenvisninger, diagrammer m.m. Det anbefales at første hoveddelen av dokumentasjonen, Presentasjon, leses i sin helhet før man går videre. De ulike hoveddelene er selvstendige, og enkelte begreper har derfor blitt redegjort for flere steder, hvor det har vært avgjørende for leserens forståelse av systemet. Denne rapporten har blitt optimalisert for trykk. Det er tatt hensyn til lesbarhet på papir med tanke på valg av font og linjeavstand, som utlinjet i den offisielle rapportmalen vi har fått utdelt av Høgskolen i Oslo. Vi vil gjerne benytte anledningen til å takke Aptoma for å ha gitt oss denne oppgaven og tilgang til deres lokaler i prosjektløpet. Vi vil spesielt takke Kenneth Froholdt for god hjelp og veiledning i prosjektets start- og sluttfase. Vi vil takke Håkon Drange for tilliten han har gitt oss i vårt arbeid med oppgaven han skrev. I tillegg vil vi takke Gunnar Lium og Jo-Herman Haugholt for deres assistanse med diverse tekniske problemer vi har hatt underveis. Stor takk rettes også til Norun Christine Sanderson ved HiOA, som har vært vår veileder underveis i prosjektet. Hun har vært uvurdelig i gjennomføringen av prosjektet med tanke på de krav og frister skolen stiller til vårt prosjekt. Vi vil også takke Tor Krattebøl for å ha satt oss i kontakt med Aptoma, og Amir Maqbool Ahmed for hans assistanse og tålmodighet i oppsett av vår produksjonserver på skolen. En demo av Aptostat ligger ute på http://apto.vlab.iu.hio.no og http://apto.vlab.iu.hio.no/admin (Demoen vil ligge ute til sensuren har gått, da vil tilgang fjernes.) Brukernavn: sensor Passord: sensor 6
[1 INNLEDNING] Innholdfortegnelse 1 Presentasjon... 8 2 Om bedriften... 9 3 Dagens situasjon... 10 4 Mål og rammebetingelser... 11 7
[1 INNLEDNING] 1 Presentasjon Tittel: Systemstatussystem for Aptoma AS Oppgave: Utvikle en løsning for håndtering av systemstatus fra flere delsystemer, og et brukergrensesnitt for kunder og administrerende brukere. Periode: 13. januar til 13. juni Prosjektgruppe: 18 Gruppemedlemmer: Veileder: Oppdragsgiver: Kontaktperson: Maud Veronica Gine Lundh Noha Xue Ketil Øvrebø Even Geithus Øwre Norun Christine Sanderson Aptoma AS Akersgaten 55 0107 Oslo Kenneth Froholdt Tlf: +47 95807763 Epost: kenneth@aptoma.com 8
[1 INNLEDNING] 2 Om bedriften Aptoma er et produktutviklingsfirma som holder til i VG-huset i Akersgata, Oslo. De utvikler verktøy for nettaviser som muliggjør rask og effektiv redigering av forsider, forfatting av artikler og publisering av video. Noen av deres kunder er VG Nett, TV2, NRK, Dagens Næringsliv, SOL, Edda Media, A- Pressen, Ekstrabladet, Danmarks Radio m.fl. Aptoma har gjennom flere år hatt hovedprosjektgrupper fra Høgskolen i og har ansatt flere gjennom disse. Aptoma er glad i åpne og frie løsninger og programvare. 9
[1 INNLEDNING] 3 Dagens situasjon Aptoma benytter i dag seg av Pingdom for statusovervåkning av sine systemer. Kunder og supportpersonell kan lese av status på alle delsystemene til Aptoma på http://status.aptoma.com. Pingdom gir informasjon om oppestatus på tjenestene, men gir ingen informasjon utover om tjenesten er tilgjengelig eller ikke. For en frustrert kunde vil det være ønskelig å vite hva som kan være årsaken i problemet, om det jobbes med en løsning og når man kan forvente at tjenesten er oppe igjen. For å få mer informasjon om en systemfeil må kundene ringe opp Aptoma. Der vil en supportdesk svare så godt som mulig på spørsmål som kundene stiller. Ofte er det slik at support blir nødt til å gå direkte til teknikerne for å spørre. Dette kan bli forstyrrende for teknikerne som prøver å jobbe rask, effektivt og konsentrert med problemet. Prosjektet er derfor satt av til å effektivisere kommunikasjonsflyten mellom Aptoma og kundene om en tjeneste skulle bli utilgjengelig. Det er ønskelig at Aptoma kan legge inn en statusmelding når et problem oppstår slik at kundene selv kan sjekke opp status uten å måtte ringe support. 10
[1 INNLEDNING] 4 Mål og rammebetingelser Målet med prosjektet er hovedsaklig å utvikle to hovedkomponenter: System som samler og behandler systemmeldinger (Back-end) Det skal lages et system som henter inn systemmeldinger fra ulike delsystemer med ulike formater. Det kan være i formater som JSON, e-mail, XML og API. Inndata skal så behandles og lagres i ett format. Behandlet data skal så være tilgjengelig via et API. Systemet skal hovedsaklig skrives i PHP. Statushåndteringsystem (Front-end) Det skal lages et Front-end for to hovedgrupper. Kundeside Behov for å se status Support og teknikkere Behov for å se status Behov for å kunne opprette og redigere statusmeldinger Statusmeldingene skal inneholde eller gi muligheten til å inkludere informasjon om: Hva problemet er Når det oppsto Hvilket system det dreier seg om Hvorvidt noen jobber med problemet Når det er forventet å være løst Andre rammebetingelser Ta hensyn til false-positives fra monitoreringsverktøy. Det kan være at tjenesten ikke er direkte påvirket selv om en test feiler. Alle komponenter i systemet er på engelsk. Dette gjelder også dokumentasjon som for eksempel installasjonsveiledningen. 11
13-18 [2 PROSESSDOKUMENTASJON] Avd. for Ingeniørutdanning Maud Veronica Gine Lundh, Noha Xue, Ketil Øvrebø, Even Geithus Øwre [2 PROSESSDOKUMENTASJON] 12
[2 PROSESSDOKUMENTASJON] Forord Prosessdokumentasjonen inneholder hele prosessen fra prosjektstart til prosjektslutt. I dette dokumentet drøftes organisering, metoder, verktøy til å bistå med prosessen, resultatet, læringsutbytte og refleksjon. Dokumentet skal gi et innblikk inn i teamets prosjekthverdag og tanker rundt dette. Enkelt begreper som er benyttet her kan være tekniske eller uklare. Om det er noen ord og utrykk som er ukjente anbefales å ta en titt i dataordboken bakerst i rapporten (Vedlegg 9). Prosessdokumentasjonen består av disse hoveddelene: Planlegging og arbeidsmetode Tar for seg hvordan prosjektet ble planlagt og organisert. Tar også for seg hvilke prosjektorganiseringsmetoder som ble brukt, hvilke verktøy som ble benyttet og hva som var nødvendig å lære seg av nye ting. Utviklingsprosessen Beskriver de ulike inndelingene og fasene av prosjektet, interne refleksjoner i forhold til faglige utfordringer, viktige valg som er foretatt igjennom prosjektets forløp, vanskeligheter i prosjektøpet og forholdet til oppdragsgiver. Kravspesifkasjonen og dens rolle Tar for seg utarbeidelsen av kravspesifikasjonen, justeringer underveis, bruken av den og samsvar med produktet. Avsluttende del Tar for seg læringsutbytte for gruppemedlemmene, refleksjoner og forbedringspotensiale, oppdragsgivers synspunkt og videre utvikling av produktet. En demo av Aptostat ligger ute på http://apto.vlab.iu.hio.no og http://apto.vlab.iu.hio.no/admin (Demoen vil ligge ute til sensuren har gått, da vil tilgang fjernes.) Brukernavn: sensor Passord: sensor 13
[2 PROSESSDOKUMENTASJON] Innholdfortegnelse 1. Planlegging og arbeidsmetode... 15 1.1 Planlegging og organisering... 15 1.2 Dokumentering... 16 1.3 Verktøy... 17 1.4 Læringsbehov... 21 2. Utviklingsprosessen... 23 2.1 Utviklingsmetode og faser... 23 2.2 Avgjørelser i utviklingen... 28 2.3 Forholdet til bedriften underveis... 36 2.4 Utfordringer og refleksjoner... 36 3. Kravspesifikasjonen og dens rolle... 41 3.1 Avvik - Mangler... 41 3.2 Avvik - Tilføyelser... 41 3.3 Avvik - Utenom Kravspesifikasjonen... 42 4. Avsluttende del... 43 14
[2 PROSESSDOKUMENTASJON] 1. Planlegging og arbeidsmetode 1.1 Planlegging og organisering Alle medlemmene i hovedprosjektgruppen er godt kjent med hverandre og tar også samme bachelor. En fordel med dette er at de kjenner hverandres styrker og svakheter. Det ble på et tidlig stadie foreslått å avholde faste møter både på skolen og hos Aptoma som holder til i VG-bygget ved Akersgata. Møtetidspunktene som ble satt var som følger: Hver mandag med Norun Christine Sanderson klokken 13.30-14.00 Hver tirsdag hos Aptoma - Ballrommet klokken 09.00-14.00 Hver torsdag hos Aptoma - Rammerommet klokken 09.00-16.00 I tillegg var det forventet at hvert gruppemedlem jobbet med sine ansvarsområder mellom hver økt. Etterhvert ble også onsdagene et fast møtetidspunkt fra klokken 09.00-16.00. Arbeidsfordeling Hvert gruppemedlem har vært sitt ansvarsområde innenfor dette prosjektet. De er som følger: Maud - GUI Noha - API Ketil - Back-end Even - Database Ansvarsområdene betyr ikke at gruppemedlemmet alene skal jobbe med området, men at de skal holde oversikt over ansvarsområdet. Hvert gruppemedlem er ansvarlig for at sine ansvarsområder oppfyller rimelige kvalitetskrav og leveres til rett tidspunkt. Utover dette kan hvert gruppemedlem spørre om assistanse. Prosjektmetodikk Aptoma var veldig åpne på prosjektmetodikk og gruppen var fri til å velge metode og organisering. Etter å ha bli introdusert for Aptomas interne måte å organisere prosjekter på falt valgtet på nettopp denne metoden. Aptoma er som nevnt en bedrift som hovedsaklig består av utviklere og de har derfor sentrert organiseringen rundt 5 faser og 4-5 enkeltstående dokumenter for å lette dokumentasjonsarbeidet: 1 Initiering 2 Analyse, Scope 3 Utvikling 4 Launch 5 Retrospektiv Denne måten å strukturere prosjekter på er inspirert av Scrum, som er en variant av den smidige utviklingsmetodikken, og benytter seg av korte sprinter med spesifikke mål. Etter hver sprint har man et retrospektivt møte der man diskuterer resultatet for sprinten og planlegger hva som skal 15
[2 PROSESSDOKUMENTASJON] utføres i den neste. Denne metodikken egner seg best i små grupper der alle kan jobbe mot ett felles mål i løpet av en kort periode. Kenneth Froholdt ved Aptoma har gitt oss tilgang til prosesstyringsdokumentene de bruker ved interne prosjekter og det ble bedt om å definere og anlysere prosjektets omfang, suksesskriterier og krav til tid og ressurser. I denne fasen ble kontrakten mellom Aptoma og Høyskolen underskrevet og det ble enighet om Aptomas krav til det ferdige systemet. I denne fasen ble det også skrevet en konsekvensutredning som ligner mye på en risikoplan. Det ble deretter utformet en kravspesifikasjon som detaljerte hva systemet skulle gjøre, basert på den originale oppgaveteksten og diskusjoner med Kenneth og Håkon ved Aptoma. Sammen med Aptomas interne dokumenter utgjør kravspesifikasjonen avtalen mellom oppdragsgiver og gruppen. Aptomas interne dokumenter blir beskrevet i kapittelet Styringsdokumenter. Etter dette ble arbeidsområder identifisert og ansvar for disse fordelt på gruppemedlemmene. Til dette ble dokument 2 brukt. Dette baserer seg på WBS (Work Breakdown Structure), som er en måte å dekonstruere et prosjekt til mindre arbeidsoppgaver for å få bedre oversikt over det totale scopet. Ansvarsfordelingen for disse oppgavene ble så skrevet ned i CTR-form (Cost-Time- Resource Schedule), som inkluderer anslag av tids- og ressursbruk. Diagrammer og modeller for de ulike arbeidsområdene ble laget i plenum. HipChat har vært hovedverktøyet for kommunikasjon mellom Aptoma og gruppemedlemmene. Aptoma bruker selv HipChat internt i bedriften og det var derfor lett å få tak i folk. HipChat har vært svært nyttig ved mindre problemer og øvrig teknisk hjelp, da det var mulig å få svar raskt og effektivt. Bruk av Trello, et kanban-inspirert prosjektstyringsverktøy, ble foreslått av Aptoma. Etter nærmere vurdering ble det besluttet at Trello skulle brukes til å administrere arbeidsoppgaver og den mer tradisjonelle arbeidsplanen ble derfor ikke brukt. 1.2 Dokumentering 1.2.1 Styringsdokumenter Som tidligere nevnt har gruppen i tillegg til HiOAs dokumenter for prosjektstyring benyttet seg av Aptomas egne prosjektstyringsdokumenter. Der det er overlapp ble Aptomas dokumenter prioritert. Prosjektskisse Prosjektskissen ble levert 10. desember og inneholdt informasjon om valgt bedrift og skisse for foreslått oppgave. Prosjektdagbok Prosjektdagboken har blitt benyttet som et loggføringshjelpemiddel og utgjør sammen annen historikk fra GIT og Google Docs et stort hjelpemiddel for når prosessdokumentasjonen skal skrives. Daglige tanker og utfordringer, utfordringer og løsninger blir skrevet ned for hver økt. Forprosjektrapport Forprosjektrapporten er en nærmere analyse av prosjektet, dens omfang og oppgavene. Her gjøres det en nærmere utredning av krav, rammebetingelser, kundens forventninger og læringsomfang. Arbeidsplan og fremdriftsplan I begynnelsen av prosjektet ble en fremdriftsplan skissert og et gantt-diagram opprettet. Fremdriftsplanen ble levert inn sammen med forprosjektrapporten. Arbeidsplanen har falt fra til fordel for prosjekthåndteringsverktøyet Trello. Trello egner seg bedre for agile utviklingsprosjekter. 16
[2 PROSESSDOKUMENTASJON] Kravspesfikasjon Kravspesifikasjonen inneholder prosjektets krav, rammebetingelser og systembeskrivelser. Dokumentet definerer de klare suksesskriteriene og er dokumentet som benyttes for å avgjøre om Kravspesifikasjonen sammen med Aptomas Scope dokument utgjorde kravene og rammene for prosjektet. Stort sett alt som er beskrevet i Aptomas Scope dokument er også dekket i Kravspesifikasjon. Aptoma - Analysis. Conditions Et dokument som beskriver prosjektdetaljer slik som: hvem eier prosjektet, hvilke prosjektmedlemmer er involvert både internt og eksternt samt. arbeidslokaler osv. Aptoma - Analysis, Scope Dette dokumentet tar for seg omfang på prosjektet og legger mer konkrete rammer på hva som er forventes og hva som er valgfri ekstra funksjonalitet. Dokumentet definerer også hver arbeidsoppgave ned med WBS (Work Breakdown Structure) og CTS (Cost-Time-Resource Schedule). Aptoma - Schedule Dokumentet (Figur 1) inneholder alle frister og krav til kommunikasjon mellom oppdragsgiver og gruppen. I tillegg inneholder den en konskvensutredning som ligner veldig mye på en Figur 1 risikoplan. Dette er også dokumentet som signeres når Aptoma starter prosjekter. Sammen med de tidligere Aptomas andre dokumenter utgjør dette avtalen mellom kunde og oppdragsgiver. 1.2.2 Sluttdokumenter HiOA setter med dokumentasjonsstandarden visse krav til sluttdokumentasjonen og disse blir derfor fulgt. Det er imidlertid gjort justeringer for at dokumentasjonen skal passe dette prosjektet spesifikt. Brukeranvisningen er for eksempel ikke tatt med, da det var et spesifikt ønske fra Aptoma. Aptoma mente at med et godt utformet brukergrensesnitt burde brukerveiledning burde være overflødig. Det er derimot skrevet en grundig installasjonsveiledning av systemet. 1.3 Verktøy Pingdom Pingdom (Figur 2) er et overvåkningsverktøy for nettsider, som fra eksterne kilder måler et domenes responstid, tilgjengelighet og nedetid. Systemet lagrer alle brudd i tilgjengelighet og varigheten av disse og tilbyr tilgang til denne informasjonen via et API. APIet kan i tillegg benyttes til å sette opp nye tester, administrere varsler, hente nedetidshistorikk og lignende. Figur 2 17
[2 PROSESSDOKUMENTASJON] Nagios Nagios (Figur 3) er et overvåkningsverktøy for servere som måler interne faktorer som prosessorbelastning, ledig diskplass, databasetilgang, samt responstid og tilgjengelighet på en rekke protokoller. Informasjon om alle tester på alle servere blir loggført og er også tilgjengelig i en sanntidsstatusrapport. Figur 3 PHP PHP (Figur 4) er et allment programmeringspråk som i web-utvikling brukes for å kjøre serverbasert kode for dynamiske nettsider. PHP kompileres ikke på forhånd, men tolkes av serveren idet koden kjøres. Aptoma bruker PHP som hovedspråk i sine prosjekter, og det er dette språket vi har hatt mest opplæring i fra Høgskolen, så det var et naturlig valg å basere hoveddelen av vårt system på PHP. JavaScript JavaScript er et klientbasert scriptspråk som tillater interaktiv manipulering av HTML. Aptoma bruker også mye JavaScript i sine prosjekter og foreslo at vi kunne prøve å sette oss inn i dette i løpet av prosjektet. JavaScript-basert kode finnes kun på frontend-delen av prosjektet. Ajax Ajax er en kombinasjon av JavaScript, XML og andre skript- og markeringsspråk som tillater asynkrone webapplikasjoner ved å sende og motta data fra serveren uten å laste inn siden på nytt. Figur 4 Silex Silex (Figur 5) er et mikrorammeverk for PHP som utgjør Controller-laget i vår MVC-modell. Silex håndterer HTTP-forespørseler, ruter det til korrekt controller og sender et svar basert på hva som er kodet i bakenden. Silex er tett knyttet opp mot Symfony2 (som er et fullendt rammeverk for PHP) og er utviklet av samme selskapet. Figur 5 Propel Propel (Figur 6) er en PHP-extension som kartlegger objektrelasjoner i en SQL-database og generer klasser og metoder for tabeller og koblinger. Dette lar deg operere objektorientert mot databasen. Propel håndterer tiltak mot SQL-injections automatisk i bakgrunnen, og queries skrevet i Propel er ryddigere og mer oversiktlige enn rene SQLsetninger. jquery jquery (Figur 7) er et Javascript-bibliotek som sikter på å forenkle bruken av Javascript. Det er i dag det mest populære Javascript-biblioteket i verden. Biblioteket har en forenklet syntaks og ferdiglagde funksjoner, kalt widgets, som gjør det mulig for utviklere å produsere avanserte og dynamiske nettsider på mye kortere tid enn med vanlig Javascript. Figur 7 Figur 6 18
[2 PROSESSDOKUMENTASJON] Composer Composer (Figur 8) er en avhengighetshåndterer for PHP. Man oppretter en liste over de utvidelser, tillegg og biblioteker som systemet er avhengig av og kjører Composer for å automatisk laste ned og oppdatere disse. Composer gjør det lettere å portere kode, ved å redusere installasjonstider og sikre at alle kritiske komponenter blir installert riktig. Composer følger PSR-standarden for håndtering av utvidelser. 960-grid system 960-grid (Figur 9) er et CSS-rammeverk som forsøker å gjøre det så smidig som mulig å posisjonere elementer på websider. Navnet kommer fra 960 pixler, den totale sidebredden i systemet. 960 ble brukt i begynnelsen av prosjektet, men ble senere erstattet med Twitter Bootstrap, da det har samme funksjonalitet inkludert. Twitter Bootstrap Bootstrap er et CSS-rammeverk utviklet in-house hos Twitter, og frigitt gratis for allment bruk. Det inkluderer et fullt CSS-oppsett med predefinerte elementer, et responsivt grid-system på 960 pixler som standard og skreddersydd JavaScript som baserer seg på jquerybiblioteket. Bootstrap lar deg raskt sette opp avanserte HTML-elementer som glidende overganger, slides, modale dialogbokser, faner, dropdowns og lignende. Les mer om den på http://twitter.github.io/bootstrap/. Figur 8 Figur 9 curl curl er et kommandolinjeverktøy for dataoverførsel via protokoller. Vi bruker curl og den tilhørende PHP-utvidelsen for å sende og motta forespørsler til APIet via HTTP. Twig Twig (Figur 10) er et PHP-verktøy for å lage HTML-maler til webapplikasjoner. I vår MVC-modell fungerer Twig som vårt Viewverktøy. Twig lar oss auto-generere store mengder HTML-kode med svært lite kildekode, basert på innhentet informasjon. Git Git (Figur 11) er et platformuavhengig open-source versjonshåndteringssystem skrevet av Linus Torvalds. Med Git har alle deltakere en fullverdig kopi av kodebasen som følge av at den er distribuert. Git fører historikk over alle endringer som gjøres i koden og kan flette sammen disse. Ved endringskonflikter vil Git bevare begge endringene og la brukeren velge hvilken versjon som er riktig eller manuelt flette dem sammen. Figur 10 Figur 11 Memcached Memcached er en Linux-tjeneste som mellomlagrer informasjon. Vi har benyttet oss av memcached i kombinasjon med en PHP-utvidelse som lar oss sette og innhente datastrukturer på tvers av delsystemer, uten å måtte gå via databasen. Vi bruker memcached i tilfeller der vi har behov for korttidslagring av informasjon som ikke behøver å lagres permanent i en database for å øke responstiden på websiden. 19
[2 PROSESSDOKUMENTASJON] HTML & CSS HTML er et markeringspråk for å definere web-elementer. Nettleseren tolker et dokument, skiller HTML-kode fra vanlig tekst og produserer en nettside. CSS er et stilspråk som identifiserer og definerer utseendet og plassering av HTML-elementer. MySQL MySQL er et open-source relasjonsdatabasesystem. Det er mest brukte relasjonsdatabasesystemet i verden og er en av komponentene i AMP-kombinasjoner av software (Apache, MySQL, Perl/PHP/Python). Det eies og utvikles i dag av Oracle. Ubuntu Linux Ubuntu er en av de meste utbredte Linux-distribusjonene i dag. Den er basert på Debian og bruker et pakkehåndteringssystem som gjør det enkelt å installere og oppdatere programvare. Aptoma benytter seg av Ubuntu Server 12.04 LTS på sine servermiljøer, og vi ble oppfordret til å gjøre det samme av kompatibilitetsårsaker. Apache Apache har vært den mest brukte webserverprogramvaren i verden siden 1996. Den er opensource og utvikles av frivillige under navnet Apache Software Foundation. Kjernefunksjonaliteten i Apache kan utvides ved hjelp av moduler, f.eks. for autentisering, logging og SSL. PhpStorm Et IDE (Integrated Development Environment) for PHP og gir et sett med støtteverktøy og autofullføringsfunksjoner som er til stor hjelp for en programmerer. Programmet er gitt ut av JetBrains og benyttes av flere større aktører, bl.a. Facebook. 20
[2 PROSESSDOKUMENTASJON] 1.4 Læringsbehov Med prosjekter i utdanningssammenheng vil det oftest være to hovedmotiver som driver prosjektet. Det ene er resultat og produkt som kanskje er den største årsakene til at prosjekter blir satt igang. Et annet motiv som nærmest er sidestilt og iblant til og med hovedhensikten er læringspotensiale og utvikling av mennesklige ressurser. Teambuilding og kompetanseheving er i slike prosjekter viktige både med tanke på god unyttelse av tid og videre framtid både for hvert individ og for en organisasjon. I dette prosjektet har det vært behov for å lære seg bruk av nye teknologier, programmeringsprinsipper og verktøy. MVC (Model-View-Controller) MVC (Figur 12) er et programmeringsprinsipp som deler inn ansvarsområdene i et program i tre ulike deler. Ved å dele opp et program i model, som inneholder kjernekoden, og view, som inneholder presentasjonskode vil man kunne programmere disse komponentene uavhengig av hverandre. Controlleren fingerer som bindeleddet mellom model og view. Dette stiller krav til hvordan man strukturerer koden. PSR-2 (Php Standards Recommendation 2) Et sett med anbefalinger for hvordan kode skal skrives rent syntaksmessig. PSR-2 setter opp retningslinjer på for eksempel på hvordan man skal skrive opp kontrollstrukturer som IF, WHILE og FOR på en lesbar måte. Det har heldigvis for gruppen vært lite endringer i kodevaner, da standarden følger vanlige konvensjoner for lesbar kode. Figur 12 Verktøy Underveis i prosjektet har det blitt tatt i bruk av rammeverk og håndteringsverktøy for kode i forskjellige sammenhenger og det har derfor vært et behov for å lære seg bruken av disse. Verktøy hvor det har vært et betydelig læringsbehov: Silex Sette seg inn i bruken av Silex fungerer og metodene som er mulig å benytte for å løse våre problemer. Propel Sette seg inn i Propels metoder for kommunikasjon til database og hvordan SQL henger sammen i dette bildet. jquery Også her har det vært et stort behov for å sette seg inn i biblioteket for å kunne utnytte det best mulig. I tillegg har det vært har det vært et behov for å sette seg inn i API-grensesnittet til både Nagios og Pingdom for å avgjøre hvilken informasjon de leverer, når den leveres og i hvilket format for å avgjøre hvordan den skal brukes. 21
[2 PROSESSDOKUMENTASJON] Ellers i prosjektet har det blitt tilegnet mye kunnskap angående design og strukturering av både design og kode med for eksempel bruk av template systemer, slik som Twig og utvikling av et REST (Representational State Transfer) API. 22
[2 PROSESSDOKUMENTASJON] 2. Utviklingsprosessen 2.1 Utviklingsmetode og faser Som nevnt i kapitelet Planlegging og organisering har vi tatt i bruk Aptomas egen måte å strukturere et prosjekt på. Initiering Initieringsfasen fant sted gjennom første kontakt med Aptoma og forprosjektrapporten. I denne fasen skal oppgaven defineres utfra et behov og hva som skal utføres skal dokumenteres. Denne fasen er nærmere beskrevet i kapitlet Planlegging og organisering. Analyse, Scope I denne fasen ble først kravspesifikasjonen skrevet og scope bekreftet med kunden. På bakgrunn av denne kunne systemet modelleres og tidsplanen settes opp. Med tidsplanen satte ble det også satt opp milepæler for utviklingen. Disse reflekterte gruppens beslutning om å utvikle back-end og API først og deretter bygge GUI på toppen av dette. I denne fasen ble ansvarsområder også fordelt. Disse endte opp som hovedarbeidsområder for gruppemedlemmene. Etter planleggingen var fullført gikk prosjektet inn i oppstartsfasen. Arbeidet med å å detaljere systemet, gjøre research på overvåkningsystemene Arbeid med å sette seg inn i Pingdom og Nagios samt verktøyene ble satt i gang. APIet til Pingdom har utmerket dokumentasjon og var derfor lett å håndtere og jobbe med. Forbindelse ble raskt opprettet og testing med loggføring til disk ble gjort fram til databasen var opprettet. Nagios viste seg å være mindre brukervennlig. Den offisielle dokumentasjonen viste seg å være mangelfull, da Aptoma benytter seg av en tredjepartsutvidelse for å få lettere tilgang på overvåkningsdata. Vi ble anbefalt å bruke loggen til denne utvidelsen for å hente ut statusmeldinger, men da den hadde et lite konsekvent format og inneholdt store mengder irrelevant data ble det bestemt å kun hente nåværende sanntidsdata. Dette tilsvarer metoden som er brukt til å hente ut data fra Pingdom, og gjorde det lettere å få til et felles dataformat på feilmeldinger. Utvikling Denne fasen omfatter alt av utvikling, som også utgjorde den desidert største delen av prosjektet. Utviklingsløpet har ikke fulgt en spesifikk metodikk, men har heller variert mellom varianter av agile metoder. I begynnelsen av prosjektet ble det nettbaserte verktøyet Trello satt opp med den hensikt å organisere arbeidet i Scrum-/Kanban-basert struktur. Det ble imidlertid ikke fulgt opp mens mye av utviklingen pågikk, men ble virkelig brukt mot slutten. Denne problematikken beskrives nærmere i kapitlet Utfordringer og refleksjoner. Det ble tidlig besluttet at hovedfokus i begynnelsen av prosjektet skulle ligge i back-end komponenter av systemet. Disse komponentene ville være essensielle for å senere implementere det grafiske brukergrensesnittet. Det var imidlertid satt av ressurser for utvikling av front-end og flere designforslag ble skissert allerede på dette stadiet. (Figur 13og 14). 23
[2 PROSESSDOKUMENTASJON] Figur 13 24
[2 PROSESSDOKUMENTASJON] Figur 14 Databasen ble på dette stadiet modellert etter kravene i oppgaven og har i prosjektets løp hatt flere omstruktureringer. Dette på bakgrunn av misforståeler og endrede krav etterhvert som ting ble mer klart. Omtrent midtveis i utviklingen, 12. mars 2013, ble det avholdt et møte for demonstrasjon og spørrerunde med Gunnar Lium, som viste en demonstrasjon på hvordan man kunne refaktorere koden til å være mer lesbar og mer effektiv. Dette viste seg å være svært lærerikt. Like etter dette møtet ble det avhold et større midtveismøte med tilbakemelding fra Kenneth Froholdt, Håkon Drange, Gunnar Lium og Jo-Herman Haugholt. Under dette møtet ble det nevnt flere forslag til forbedringer i forhold til design på brukergrensesnitt, avgrensning av scope og klarere beskrivelser av noen krav. Det ble også tatt opp noen nye ønsker Aptoma hadde for siden. Det ble besluttet å refaktorere front-end komponentene av systemet til å være tettere integrert med Twig og Silex. Denne endringer ble utført parallelt med normal utvikling av funksjoner takket være GIT. 16. mars 2013 ble refaktorert front-end slått sammen hoveddelen av koden og førte til en ganske stor ringeffekt som krevde enkelte mindre endringer i andre komponenter. Refaktoreringen av front-end markerte også endepunktet av utvikling av back-end komponenter og bare fiksing av bugs og andre små endrigner ble gjort på back-end etter dette punktet. Mot slutten av utviklingsfasen var hyppigheten av møter med Aptoma færre, da Aptoma har hatt svært mye å gjøre. Front-end ble i løpet av sluttfasen ferdigutviklet (Figur 100, 101, 102 og 15) og 25
[2 PROSESSDOKUMENTASJON] en god del bugs fikset helt opp mot leveransen. Figur 100: Admins forside Figur 101: Håndtering av rapporter Figur 102: Killswitch panel 26
[2 PROSESSDOKUMENTASJON] Launch I begynnelsen av mai ble det satt av tid til et møte med Aptoma for å avvikle prosjektet med dem. På dette møtet ble tilstanden for prosjektet og hvorvidt det samsvarte med kravspesifikasjonen avklart. Systemet ble demonstrert for Aptoma og funksjonstester ble gjennomgått. De kom fram til at kravspesifikasjonen var oppfylt, men det ble likevel avdekket en rekke små mangler og bugs som ble fikset opp i løpet av samme dag. Større mangler som ble avdekket etter samtale med Aptoma og egen intern testing kan leses om i kapitlet Videre utvikling i Produktdokumentasjonen. Det ble deretter besluttet at systemet skulle installeres snarlig. Det var i drift og tatt i bruk omtrent én uke senere. Første reelle use-case dukket opp tirsdag 21. mai, da en av hosting-providerne til Aptoma ble utsatt for et DDoS-angrep som påvirket noen av deres tjenester (Figur 15). Figur 15: Et reelt use-case. Grensesnittet for visning av én enkelt incident Det ble også utført testing i henhold til testplanene som var utarbeidet paralellt med launch. Dette kan leses mer om i Testdokumentasjonen. Retrospektiv I denne fasen går man tilbake og ser på prosjektet i etterpåklokskapens lys for å evaluere hva som har blitt gjort bra, hva som er gjort mindre bra og hvilken lærdom man kan ta med videre til neste prosjekt, både for gruppen og for oppdragsgiver. Gruppen tok en retrospektiv økt på egen hånd tidlig i mai. 13. mai 2013 ble det avholdt et retrospektiv møte med Kenneth Froholdt fra Aptoma. Denne fasen medfører omfattende dokumentasjon og har fått sin egen seksjon i kapitlet Utfordringer og refleksjoner og i den avsluttende delen. 27
[2 PROSESSDOKUMENTASJON] 2.2 Avgjørelser i utviklingen Produksjonsmiljø Aptoma var i tvil om de ville la oss sette opp virtuelle maskiner i deres produksjonsmiljø på deres servere, da det kunne ha en innvirkning på deres tjenester. Derfor tok vi kontakt med Amir Maqbool Ahmed ved Høyskolen i Oslo og forhørte oss om muligheten til å få satt opp en virtuell maskin på skolens servere. Vi fikk tildelt et område på skolens server kort tid etter og denne løsningen har fungert utmerket. Etter ønske fra Aptoma har vi utviklet systemet med Ubuntu versjon 12.04 LTS, da det er dette Aptoma benytter seg av på sine servere. Omtrent midtveis i utviklingen oppsto det noen problemer med bruken av VM-en, da det hadde blitt satt opp automatisk oppdatering av prosjektfiler på serverene med utgående SSH trafikk. Dette ble løst ved å ta i bruk en post-recieve-hook som GIT tilbyr. I essensen er en post-recievehook et script som kjører etter at serveren mottar nye oppdateringer av GIT-prosjektfilene. Nettleserstøtte, responsivt design og jquery Vårt system støtter alle moderne nettlesere. Det vil si Internet Explorer 10 og nyere, Firefox 4 og nyere og Chrome 6 og nyere. Uavhengig av nettleser krever vi at JavaScript er aktivert og tillatt på siden. Vi diskuterte med Aptoma om det var ønskelig å ha backupløsninger slik at alt kan kjøres uten JavaScript, men vi ble enige om at dette ikke var nødvendig når man tar sidens målgruppe og bruksområde i betraktning. Vi benytter oss av Twitter Bootstrap sitt CSS-rammeverk, som inkluderer et responsivt rutenettsystem som lar siden skalere og gjemme innhold i forhold til skjermstørrelse. Dette lar oss vise en forenklet versjon av siden hvis man aksesserer siden via mobiltelefon. Det er varierende støtte for de nye CSS3-elementene i de forskjellige nettleserne, og Bootstrap tar høyde for dette. Twitter Bootstrap inkluderer funksjonalitet som benytter seg av jquery-biblioteker for å utføre enkelte av de mer avanserte funksjonene. Siden benytter seg i tillegg av jquery for øvrig og jquery UI for å gjøre nettsiden mer dynamisk. Ved å bruke Ajax til å kontakte APIet og hente oppdatert informasjon kan vi oppdatere eller forandre enkeltelementer på siden ved behov i stedet for å laste inn hele siden på nytt. Dette ble implementert for å forbedre arbeidsflyten samt redusere antall page loads. Git Aptoma bruker Git som versjonskontrollsystem på alle sine prosjekter og det er dette systemet vi har erfaring med fra skolen, så det var et naturlig valg. I prosjektets startfase benyttet vi oss av Bitbucket for hosting av kodebasen, da studentkontoer på Github tar lang tid å opprette. Github var det foretrukne valget fordi Aptoma benytter seg av det, det er markedsledende, raskt og har mye bra funksjonalitet. Da våre studentkontoer var klare på Github flyttet vi koden over, slik at vi på enklest mulig vis kunne gi våre veiledere på Aptoma tilgang. Lagringshåndtering For langtidslagring av feilmeldinger, opprettede saker og øvrig informasjon av historisk verdi brukes en MySQL-database. MySQL ble valgt fordi det er kjent teknologi, lett å bruke og har god integrasjon med PHP. For direkte databasehåndtering brukes PHP-utvidelsen Propel. Dette gjør det mulig å operere objektorientert mot databasen, ettersom den legger et abstraksjonslag rundt kommunikasjonen mellom databasen og gjør koden lettere å lese og håndtere. Propel ordner i tillegg en rekke sikkerhetsproblemer automatisk ved å hindre SQL-injection og lignende. 28
[2 PROSESSDOKUMENTASJON] Til midlertidig informasjon som ikke var av historisk verdi, eller der historikken eksisterte lett tilgjengelig andre steder benyttet vi oss av Memcached, som er en caching-tjeneste til Linux, og dertil tilhørende PHP-utvidelse. Sanntidsdata samt oppetidshistorikk blir hentet direkte fra overvåkningsverktøyet Pingdom i faste intervaller, og lagret i tidsbegrensede mellomlagre for å redusere responstid på websiden. Sikkerhet Sikkerhet ble i samtale Aptoma tidlig tatt ut av scopet og et grunnleggenede sikkerhetsopplegg ble i stedet satt som et krav. Dette blir videreutviklet av Aptoma som både har mer kunnskap om emnet og det kan tenkes at valget også kommer av at slik informasjon er sensitivt og bør håndteres internt av Aptoma. Design Gjennom prosjektet ble det på den offentlige kundedelen av Aptostat tatt flere valg som skulle legge litt mer til rette for brukere med funksjonsnedsettelser, utenom de krav satt fra Aptoma. Det ble imidlertid gjort tidlig rede for at det ikke trengte å legges til rette for funksjonsnedsettelser i det administrative grensesnittet, men at det likevel skulle ha et enkelt design som var intuitivt å bruke. Fokuset ble da på å lage et helhetlig design til både kundedelen og den administrative delen. Det er flere funksjonsnedsettelser å ta hensyn til, men det ble kommet fram til at mer «usynlige» nedsettelser, som kognitive nedsettelser, dårlig syn og fargeblindhet, var de vi trenger å ta hensyn til. Funksjonsnedsettelser som blindhet, bevegelsehemmet og lignende er ikke like enkelt å kombinere med et så krevende og stressende yrke som journalistiskk, med noen unntak. I tillegg er journalistikk et veldig sosialt krevende yrke, så nedsettlser som autisme og aspergers er heller ikke vanlig blant journalister. Det ble derfor konkludert at man skulle heller fokusere mer på kognitive nedsettelser som ADD, dysleksi og fellestrekkene til de fleste kognitive nedsettelser, som å holde konsentrasjonen og evnen til å trekke ut relevant informasjon. Selv om ADD, ADHD og dysleksi er ikke like lett å ha i et slik skriftlig yrke som journalistikk, har det med tiden blitt mer åpent for personer med disse nedsettelsene. Med bruk av korrekturlesere er det heller ikke et like stort problem lenger. Fargeblindhet er å ha nedsatt fargesans, slik at mennesker med fargeblindhet oppfatter farger annerledes enn andre. Det fins ulike typer fargeblindhet, men det ble fokusert på de mest utbredte: Protanopi og Deuteranopi. Protanopi er rødblindhet og Deuteranopi er grønnblindhet. Dette er relativt vanlige nedsettelser og det er dokumentert at mennesker med denne type nedsettelsene tilpasser seg de fleste typer yrker godt. Journalistikk og media er et av disse yrkene. I fargeblindhetstestene ble det også testet på Akromatopsi, fullstendig fargeblindhet. Disse testene viste seg å være vellykkede og designet passerte med henhold til fargevalg. 29
[2 PROSESSDOKUMENTASJON] Figur 16: Deuteranopi (Grønnblindhet) Figur 17: Protanopi (Rødblindhet) 30
[2 PROSESSDOKUMENTASJON] Figur 18: Akromatopsi (Fullstendig fargeblindhet) Når det gjaldt å tilpasse for fargeblindhet ble hver farge og sammensetningen av farge valgt med omhu. Selv om designet skulle følge fargepalletten til Aptomas eksisterende sider var det også viktig at alle farger var lette å skille fra hverandre ved tilfeller av fargeblindhet eller svakere syn. Fargefilteret som ble brukt klarte ikke å vise statusikonene på siden. Dette var en feil som lå i selve fargefilteret, men som en bieffekt av dette fikk vi simulert hvordan siden fungerte uten ikonene. Vi kan se at tekstbeskrivelsen for hvert ikon tar over deres funksjon og beskriver statusen på hver tjeneste og incident. I tidlige tester ble det oppdaget at noen farger fra første utkast måtte endres. Til å begynne med hadde incidentsboksene en mild lysegul bakgrunnsfarge og ikoner i grønt gjorde det vanskelig å skille ut, noe som følgelig ga negative resultater på testene. Det ble valgt å bruke hvitt eller grått som bakgrunnsfarger. All tekst skulle enten være grå, svart eller hvitt. Hvis bakgrunnsfarge er hvitt, blir det mørk grått eller svart tekst, om det er grå bakgrunn vil det bli lys grå til hvit tekst. Etter endringer i designet har det nåværende designet blitt godkjent gjennom testene med fargeblindhetsfilteret Colorfilter. Som man kan se i figur 16 til 18, kan fargene skilles godt fra hverandre og innholdet er leselig. Whitespace mellom modulene på siden blir brukt for å balansere det visuelle inntrykket og gjøre det lettere for personer med kognitive nedsettelser å trekke ut informasjon. Større font og fet tekst på overskrifter og systemstatus gjør det lettere for dyslektikere å tolke den viktigste informasjonen på siden. 31
[2 PROSESSDOKUMENTASJON] Det er for øvrig viktig å huske at universell utforming ikke kun dreier som om å tilpasse seg de med funksjonsnedsettelser, men at produktet skal kunne brukes av alle, uten problemer. Følgende valg ble gjort på kundesiden for å gjøre den bedre å bruke for alle: Fargene er distinkte og brukes i kjente situasjoner, som at grønn betyr OK og at rød betyr fare. Alle ikoner og labels fikk tekstbeskrivelse slik at om det er vanskelig å se selve bildefilen så har man en tekstlig beskrivelse av hva ikonet er. F.eks. får det grønne ikonet teksten OK ved siden av selve ikonet. Bruken av Twitter Bootstrap fører med seg optimalisert og semantisk strukturering av innhold som også følger WAI-ARIA-standarden. Dette gjelder imidlertid kun for innhold som bruker Bootstrapen. Bruk av lyse farger som ikke tar oppmerksomheten fra ikonene gjør at personer med f.eks. konsentrasjonsvansker kan lettere skille ut relevant informasjon fra siden. Selv om det ble brukt ulike nyanser av grått som kan tenkes å være vanskelig å skille fra hverandre, ble det gjort tester med fargeblindhetsfiltre for å se om det var et faktisk problem. For bruk på mobiltelefoner ble det lagd en forenklet versjon av siden, slik at det blir mindre rot for brukeren på en mindre skjerm. På den måten får brukeren kun det viktigste av informasjon, sanntidspanelet og aktuelle hendelser, slik at brukere med eventuelle kognitive nedsettelser slipper å måtte sile ut overflødig informasjon. Alle elementer på siden er designet for å være mest mulig selvforklarende for å unngå behovet for en brukermanual. Store overskrifter og klare, beskrivende symboler sørger for dette. Balansert bruk av whitespace og store mellomrom gjør det roligere for øyet Bruk av en enkel font og ingen lange setninger vil gjøre det enklerer å lese og tolke riktig tekst. Designet ble skissert (figur 19 21) på et tidlig stadie og ble gjennomgått i plenum for å best mulig design og forståelse for arbeidsflyten. Etter diskusjon innad i gruppen ble designet godkjent og man gikk videre til å lage en prototype man kunne vise til Aptoma: 32
[2 PROSESSDOKUMENTASJON] Figur 19 Figur 20 33
[2 PROSESSDOKUMENTASJON] Figur 21 Brukergrupper Etter nærmere analyser ble det observert at førstelinjesupport og teknikkere har den samme sikkerhetsklareringen og har behov for de samme verktøysettet. Det ble derfor besluttet at på det tekniske nivået blir disse to brukergruppene definert som den administrative brukergruppen. Sluttbrukere er definert som brukere som har behov for å se status på systemene og tjenestene til Aptoma og vil derfor være Aptomas kunder og kan bestå av teknikkere, journalister, sekretærer osv. Brukergruppen er stor og variert. Det er derfor valgt å ta utgangspunkt i en ganske lav ITkompetanse. MVC Besluttningen om å jobbe ut fra MVC som et prinsipp stammer fra nødvendigheten av å ha vedlikeholdbar kode og kunne jobbe parallelt med flere komponenter samtidig. Aptoma delte en Silex-bootstrap og med noen Tech Guidelines (Vedlegg 3) med gruppen, som ga oss et startpunkt for arbeid med oppgaven ettersom bootstrapen er bygget opp etter MVC-prinsipper. Midtveispresentasjonen Det ble kjørt en midtveispresentasjonen i regi av Norun Christine Sanderson og Siri Kessel 3. april 2013. Ettertanke: Her har vi lagt terskelen for kvalitet lavt (i forhold til presentasjon). Gruppemedlemmene var generelt opptatt med å arbeide på produktet og presentasjonen har ikke vært prioritert. Heldigvis har alle gruppemedlemmene fremført tidligere i andre prosjekt og har erfaringer som skal benyttes i mer fullstendig form til aller siste sensorpresentasjon. Det er satt av tilstrekkelig tid for dette. 34
[2 PROSESSDOKUMENTASJON] Refaktorering av front-end Det ble etter midtveismøtet med Aptoma besluttet at front-end skulle refaktoreres og integreres emd Twig og Silex. Dette var en større oppgave for gruppen, men ville føre til bedre kodekvalitetet og bedre videreutviklingsmuligheter. Avgjørelsen kom ganske sent i prosjektet og med etterpåklokskapens visdom ser man at dette var en besluttningen som burde ha vært tidligere. 35
[2 PROSESSDOKUMENTASJON] 2.3 Forholdet til bedriften underveis I startfasen av prosjektet var vi mye i kontakt med Kenneth Froholdt ved produktavdelingen i Aptoma. Han hjalp oss med planleggingsarbeidet og ga oss en innføring i hvordan Aptoma går frem i starten av et prosjekt. Vi tok i bruk Aptomas prosjektstyringsdokumenter for å definere prosjektets omfang, krav og suksesskriterier. Etterhvert som kravspesifikasjonen begynte å ta form ble det satt opp spørresesjoner med Håkon for å utrede uklarheter. Dette fant sted to ganger. Resterende spørsmål ble tatt over bedriftens chat-løsning. Underveis i prosjektløpet fikk vi hjelp fra Gunnar ved Aptoma til strukturering av Silex-baserte applikasjoner, dette i form av en workshop som varte i et par timer. Med denne nye kunnskapen ble hele kodebasen gradvis refaktorert. Dette var veldig nyttig for å holde orden og oversikt over koden senere i prosjektet. Til dette formål fikk vi tilgang til Aptomas Silex-bootstrap, som tidligere nevnt og Aptoma benytter denne selv sine egne løsninger. Bootstrappen er en ferdig Silex-mal som inneholder de grunnleggende elementene og en Composer-definisjon med der de vanligste avhengighetene er inkludert. Etter midtveispresentasjonen reduserte vi antall dager hos Aptoma til én i uka og det var lite kontakt med bedriften etterhvert som leveringsfristen nærmet seg. Det ble jobbet videre i henhold til planen på egenhånd. I de siste to ukene før leveranse ble kontakten tatt opp igjen for å sjekke at krav var oppnådd, retrospektiv og organisere testing og overføring av kodeeierskap. Uheldigvis hadde Aptoma lite tid å avse mot slutten, da testing skulle gjennomføres, noe som muligens kunne vært unngått ved å avtale dette lenger i forveien. Kenneth anerkjente imidlertid at de generelt hadde satt av for lite tid til veiledning og felles møter gjennom prosjektløpet, men etter retrospektiven gikk det fint å planlegge de nødvendige møtene før prosjektet ble avsluttet. 2.4 Utfordringer og refleksjoner Utfordringer og tanker Utviklingsrekkefølge Vi satte opp fire milepæler i planleggingsfasen, én for hver komponent i systemet, men disse ble fort irrellevante da vi nådde tredje milepæl allerede før den første skulle være ferdig. Det vi senere oppdaget var at milepælene ikke var representative for hvilken funksjonalitet som skulle være ferdig til hvilken tid. Vi siktet på å ferdigstille enkeltkomponenter hver for seg, men dette viste seg å være veldig optimistisk med tanke på at de skulle samhandle. Systemet vi skulle utvikle var tredelt. Vi hadde et nett-grensesnitt som kommuniserte med et API øverst. API hentet ut informasjon som var innsamlet via en rekke scripts på serveren og lagret i en felles database. Enkeltfunksjoner på serveren og i APIet tok lengre tid enn vi hadde regnet med, som resulterte i mye bortkastet tid da det også gikk ut over produktiviteten til de som jobbet med grensesnittet. Det vi kunne, og burde, ha gjort før arbeidet startet er å definere avhengigheter og nøyaktig hva APIet skulle returnere, på hvilke forespørsler, og i hvilket format. Hvis dette var bestemt på forhånd kunne man utviklet grensesnittet hurtigere selv ved nedetid eller feil i APIet. De vage milepælene gjorde at vi ble låst inn i en utviklingsstruktur som liknet fossefallsmodellen mer enn en agil modell som Scrum. 36
[2 PROSESSDOKUMENTASJON] Web-grensesnittet Ved skissering og planlegging ble det bestemt hvordan arbeidsflyten skulle fungere, og vår valgte metode hadde behov for ganske mye Ajax- og jquery-funksjonalitet for å redusere behovet for å laste inn siden på nytt. Da mye av dette var ukjente teknologier ble det brukt mye tid på å lære dette i begynnelsen av utviklingsløpet, som resulterte i at det tok veldig lang tid før faktisk funksjonalitet ble implementert. I tillegg ble det valgt løsninger som ikke lot seg gjennomføre innenfor prosjektets tidsramme og måtte løses på andre måter. CSS-rammeverket vi benyttet oss av ble også byttet underveis, som førte til ytterligere forsinkelser da mye måtte skrives om. Et annet problem var at grensesnittet ikke ble utviklet som en Silex-applikasjon fra begynnelsen. Dette førte til at vi måtte refaktorere hele grensesnittet ganske sent i prosjektløpet, konvertere alle sidene til Twig-maler og sette opp et MVC-hendelsesløp. Dette var en total konvertering av strukturen og det ble en utfordring å omstille seg for de som hadde jobbet med grensesnittet frem til dette punktet. Databasehåndtering Det ble svært mye omskriving og refaktorering av databasen underveis i utviklingen, delvis grunnet dårlig planlegging og delvis grunnet misforståtte eller forandrede krav. Dette førte til ytterligere forsinkelser i datainnsamling- og API-funksjonalitet, da mye måtte omskrives for å passe til en annen databasestruktur. Selv ved prosjektslutt er det enkelte aspekter ved databasen vi gjerne skulle ha forandret, men ikke hadde tid til. Tilbakemelding fra Aptoma Vi burde tatt initiativ til hyppigere møter med Aptoma der vi kunne vise frem design og fremgangsmåte og få tilbakemelding, kritikk og forslag. Dette ble det brukt for lite tid på underveis i prosjektet, og det kan ha gått ut over prosjektets fremgang. Særlig prototyper burde blitt ferdigstilte og vist fram på et tidlig stadie. I de få møtene vi hadde fikk vi mye tilbakemelding som førte til at vi måtte gå tilbake og forandre enkelte funksjoner. Med møter i faste intervaller kunne vi kommet i forkant av disse problemene og brukt tiden vår mer effektivt. Kunnskapsdeling internt Vi kunne med fordel ha satt av mer tid til intern gjennomgang av kode og små retrospektiver underveis i prosjektet for å sikre at alle gruppemedlemmer forsto alle aspekter av systemet. Enkelte gruppemedlemmer ble veldig låst til de delsystemene de hadde utvikler da de var de eneste som hadde nødvendig kunnskap til å løse feil raskt og effektivt. Hvis vi hadde satt av faste tider til gjennomganger kunne vi ha sluppet å ta demonstrasjoner i rykk og napp ved behov, og kunne på sikt spart tid. Det ville også bety at alle hadde kommet ut av prosjektet med lik lærdom og ville ha vært fordelaktig for videre utvikling av de individuelle medlemmenes kunnskaper. Bruk av Trello Vi benyttet oss av prosjektorganiseringsverktøyet Trello (Figur 22) for å styre arbeidsoppgaver innad i gruppen. I begynnelsen av utviklingsløpet jobbet vi med veldig Figur 22: Et Trello board. Her er det mulighet for å flytte kort fram og tilbake. Mye insipirert fra Kanban separate oppgaver på separate systemer, og Trello ble derfor veldig lite brukt. Vi kom ikke ordentlig i gang med Trello før mot slutten av prosjektet da vi alle jobbet på grensesnittet og vi 37