Forprosjektrapport. Gruppemedlemmer: Maud Veronica Gine Lundh - s Noha Xue - s Ketil Øvrebø - s Even Geithus Øwre - s171663

Transkript

1 Forprosjektrapport Gruppemedlemmer: Maud Veronica Gine Lundh - s Noha Xue - s Ketil Øvrebø - s Even Geithus Øwre - s Sammendrag: Aptoma AS har behov for et statushåndteringssystem som samler status/feilmeldinger fra flere systemer og presenterer dette på en fornuftig måte. Prosjektet skal gjøre det lettere for alle ledd i organisasjonen til å gi beskjed og få beskjed om status på systemet. Systemet skal utvikles i PHP, MySQL, HTML og involverer både back-end og front-end. Side 1 av 11

2 1 Presentasjon 2 Om bedriften 3 Dagens situasjon 4 Mål og rammebetingelser 4.2 Mål 4.2 Rammebetingelser 5 Løsninger 5.1 Back-end 5.2 Front-end 6 Analyse av løsninger 6.1 Back-end 6.2 Front-end 7 Vedlegg Arbeidsplan Fremdriftsplan Side 2 av 11

3 1 Presentasjon Tittel: Oppgave: Periode: Systemstatussystem for Aptoma AS Utvikle en løsning for håndtering av systemstatus fra flere delsystemer, og et brukergrensesnitt for kunder og administrerende brukere. 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 Oslo Kenneth Froholdt Tlf: Epost: 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 Oslo med flere ansettelser defra. Aptoma er glad i åpne og frie løsninger og programvare. 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å Side 3 av 11

4 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å noe mer informasjon om en systemfeil så 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 virke forstyrrende på teknikerne som antakeligvis allerede jobber sprenghardt 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. Side 4 av 11

5 4 Mål og rammebetingelser 4.2 Mål Målet med prosjektet er hovedsakelig å 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, , XML og API. Inndata skal så behandles og lagres i ett format. Behandlet data skal så være tilgjengelig via et API. Systemet skal hovedsakelig skrives i PHP. Statushåndteringsystem (Front-end) Det skal lages et Front-end for fire hovedgrupper. Kunder Behov for å se status Administrativ bruker på kunde side Behov for å se status Behov for å se statistisk data (Oppetid i % for sammenligning med SLA o.l) Support Behov for å se status Behov for å kunne opprette og redigere statusmeldinger Intern (Teknikker) Behov for å se status Behov for å kunne opprette, redigere og slette statusmeldinger. Statusmeldingene skal inneholde 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 Side 5 av 11

6 4.2 Rammebetingelser Kunde - bruker av programvaren Aktive brukere av Aptomas programvare på hyppig basis. Det kan vœre en journalist som skriver artikler, redigerer forsider, og/eller laster opp nytt videoinnhold til publisering. Denne gruppen skal kunne: Se informasjon om systemene er oppe og fungerer som de skal. Ved driftsproblemer se informasjon om det aktuelle problemet, hvilke konsekvenser det får og forventet tid for feilretting. Kunde - merkantil kontakt En merkantil eller administrativ bruker. Denne gruppen skal kunne: Se aktuell og historisk informasjon om driftsstabilitet. Se informasjon om vi har levert god nok oppetid på tjenesten i henhold til avtalefestet SLA-nivå. Ved driftsproblemer se informasjon om det aktuelle problemet, hvilke konsekvenser det får og forventet tid for feilretting. Internt - supportavdeling Supportavdeling i Aptoma, førstelinje. Den som mottar første henvendelse fra kunde om et problem. Denne gruppen skal kunne: Skrive informasjon fra teknisk avdeling om problemet, konsekvens og forventet tid for feilretting. Oppdatere om sakens fremdrift. Viderekommunisere informasjonen til kunder som har tatt kontakt. Dette for å minske arbeidet på teknikere som jobber med å rette problemet. Se om det foreligger driftsproblemer, basert på informasjon lagt inn av teknisk avdeling. Internt - driftsteknikere og tjenesteutviklere Teknisk kompetent personell som jobber med utviklìng av løsning og driftsmiljø. Både teknisk og support skal ha mulighet for å oppdatere informasjonen. Denne gruppen skal kunne: Skrive teknisk informasjon om problemet, konsekvens og forventet tid for feilretting. Oppdatere om sakens fremdrift. Side 6 av 11

7 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. Tilby nåværende status og oppetidsprosent via et API for implementasjon i Aptomas produkter og evt. eksternt. Tilby mulighet for â abonnere på driŕtsmeldínger pr. epost. Link til å følge twitter.com/aptomaops på Twitter. Alle komponenter i systemet er på engelsk. Kategorier: Issues, Updated, Resolved, Invalid. Verktøy og teknologi Linux Apache MySQL eller NoSQL PHP HTML Javascript CSS API-data fra overvåkningssystemer 5 Løsninger 5.1 Back-end Back-end delen av systemet skal programmeres i PHP og MySQL. Dette er spesifisert i rammebetingelsene og det som også passer kompetansen til gruppen best. Det skal bygges opp et API-bibliotek slik at andre delsystemer også kan få tilgang til statusmeldningene. Systemet skal kjøre på en Linux-server (Ubuntu) og vil i stor sannsynlighet svare over HTTP-protokollen via port Front-end Front-end delen av systemet skal kodes i HTML5 og CSS3. Løsningen skal ha et responsivt design og være krysskompatibelt med de mest populære nettleserene. (Internet Explorer, Mozilla Firefox, Google Chrome, Safari, Opera) Det vil være et fokus på et universelt utformet design som tar hensyn til WCAG 2.0 og WAI-ARIA 1.0 der det gjelder. Side 7 av 11

8 Det finnes mange spennende løsninger innenfor design og en foreslått løsning kan være å implementere AJAX for å gjøre nettsidene mer dynamiske. 6 Analyse av løsninger 6.1 Back-end Apache, PHP og MySQL er en meget populær kombinasjon og man finner mange større aktører som bruker dette i dag, noe som gjøre dem til noen de ledende teknologiene innen webutvikling. Facebook er et meget godt eksempel. Siden blir utviklet i PHP som senere blir konvertert til C++ for å minske serverbelastning. 6.2 Front-end Front-end delen av systemet skal kodes i HTML5 og CSS3. Løsningen skal ha et responsivt design og være krysskompatibelt med de mest populære nettleserene (Internet Explorer, Mozilla Firefox, Google Chrome, Safari, Opera). Det vil være et fokus på et universelt utformet design som også validerer WCAG 2.0. Side 8 av 11

9 7 Vedlegg Arbeidsplan Arbeidsplanen er et prosjektverktøy for å definere de enkelte aktivitetene i prosjektet og når de skal være ferdig. Det tas forbehold av endringer. Innledning Prosjektskisse Beskriver prosjektet og arbeidsgiveren Forprosjektrapport Analyse og avgrensning av oppgaven som skal løses Arbeidsplan Beskriver aktivitetene i prosjektets forløp Fremdriftsplan Et Gantt-diagram som viser inndelingen og forløpet til prosjektet Kravspesifikasjon Kravinnsamling Innsamling av krav og informasjon fra arbeidsgiver Kravanalyse Nærmere analyse av krav og informasjon fra arbeidsgiver Kravspesifikasjon Formell dokumentasjon av krav på bakgrunn av analysen Uke 8 Implementering Database E/R-modellering og implementering av database Uke 9 Milepæl 1: Datainnsamling Opprette koblinger til Aptomas APIer. Uke 10 Milepæl 2: Databehandling Milepæl 3: Datalagring Behandle informasjonen og konvertere alt til ett standardformat. Lokal lagring og historikk av uptime på de forskjellige tjenestene. Uke 11 Uke 12 Side 9 av 11

10 Milepæl 4: GUI rammeverk Milepæl 5: Fungerende GUI Grafisk presentasjon av systemstatus og historikk. Uke 12 Grafisk grensesnitt for kunder og teknikere. Uke 13 Testing og feilsøking Intern testing Deployment og testing i full skala på vår egen server Ekstern testing Deployment og testing på Aptomas servere Ferdigstille kode Finpuss og bugfix Dokumentasjon API-kompendium Oversikt over API-ene vårt system skal overvåke, samt de aktuelle kommandoene vi skal bruke og hva de returnerer Prosjektdagbok Fortløpende dokumentering av prosjektets fremdrift Prosjektrapport Den endelige sluttrapporten Sluttføring Forberede presentasjon Forberedelse av presentasjon Presentasjon Fremføring av vårt prosjekt for sensorer, de øvrige studentene og eventuelle inviterte gjester Fremdriftsplan Vår fremdriftsplan er forsatt ikke fullstendig detaljert og endringer vil skje underveis. Her har vi gjort diagrammet generisk nok til at vi ved hver fase kan gå inn å justere når vi starter hver fase i prosjektet. Side 10 av 11

11 Side 11 av 11