1 SAMMENDRAG Dette dokumentet beskriver kravene vi har til systemet og hva systemet skal gjøre. Dokumentet beskriver både funksjonelle og ikke-funksjonelle krav, samt rammebetingelser. Kravspesifikasjonen har tatt utgangspunkt i ønsker og krav fra oppdragsgiver. Disse kravene var ikke så mange eller strengt formulert, så de aller fleste kravene og funksjonaliteten til programmet har gruppen selv laget. Noe av essensen med oppgaven fra Accenture var jo nettopp å se hva slags løsning vi ville komme frem til. Det gjelder også med tanke på kravspesifikasjonen. Dette dokumentet gir et innblikk i hvordan systemet er oppbygd og har vært grunnlaget for utviklingsarbeidet vårt. Vi har hele tiden brukt kravspesifikasjonen som noe å gå tilbake til for å sjekke om systemet vårt oppfyller kravene vi hadde. Den beskriver i detalj all funksjonalitet vi ønsker den ferdige applikasjonen skal besitte. Vi har ikke endret mye på kravspesifikasjonen i løpet av prosjektet. Vi lagde noen utkast før vi fikk den godkjent av Accenture, og det vi har forandret på etter den tid er gjort rede for i kapitel 5. Det kan tenkes at etterhvert som applikasjonen blir utvidet og videreutviklet at kravspesifikasjonen også bør oppdateres. Ettersom vi ikke skal utvikle et presentasjonslag med grafisk design har vi heller ikke laget noen designkrav til systemet, men det vil være naturlig å gjøre dette når et slikt presentasjonslag skal bli utviklet for å sikre et brukervennlig og enkelt brukergrensesnitt. Side 1
1 SAMMENDRAG 1 2 INNLEDNING 3 1.1. OM OPPDRAGSGIVER 3 1.2. OM BAKGRUNNEN FOR OPPGAVEN 3 3 FORKLARING TIL KRAVSPESIFIKASJONEN 4 4 SAMSVAR MELLOM PRODUKT OG KRAVSPESIFIKASJON 5 5 OM ENKELTE DELER AV KRAVSPESIFIKASJONEN 6 MÅLINGSTYPER 6 OS-SPESIFIKKE MÅLINGER 6 DATABASESPESIFIKKE MÅLINGER 6 USPESIFISERTE MÅLINGER 6 6 KRAVSPESIFIKASJONEN 7 7 KRAV TIL KODE 12 8 KRAV TIL DOKUMENTASJON 13 9 UTVIDELSER 14 10 ORDLISTE 15 ORM 15 POJO 15 Side 2
2 INNLEDNING 1.1. Om oppdragsgiver Accenture er et globalt konsern som tilbyr konsulent-, teknologi- og outsourcingtjenester. Accenture har over 170 000 ansatte i 49 land, og er med det verdens største konsulentselskapet, og et av de største IT- selskapene på verdensbasis. I Norge startet Accenture som en konsulentavdeling i Arthur Andersen LLP, dannet i 1913. Konsulentavdelingen ble opprettet i 1953 etter et oppdrag fra General Electric om å lage en studie i bruk av datamaskiner til lønningslister. Det ble utviklet et lønningssystem på bakgrunn av denne studien, et system som regnes som verdens største kommersielle IT-prosjekt. Selskapet het da Andersen Consulting. I 2001 skiftet Andersen Consulting navn til dagens Accenture. Accentures konsulenter arbeider med vidt forskjellige aktiviteter, fra strategisk planlegging via forbedring av kundeservice til optimalisering av kundenes daglige driftsoppgaver. 1.2. Om bakgrunnen for oppgaven Prosjektet gjennomføres som hovedprosjekt for Høgskolen i Oslo, prosjektoppgaven er levert av Accenture. Oppgaven består av å utvikle et overvåkningssystem for Accenture. Fra før har Accenture utviklet et lignende system for sine kunder, men dette har brukt utdatert teknologi og det er også kunden til Accenture som eier dette programmet. Gruppen kan derfor ikke benytte seg av tidligere kode. Accenture har bruk for et system som kan overvåke oppetid og ytelse og lignende på servere og i miljøer for ulike kunder av Accenture. Prosjektet går ut på å lage et system for innhenting, lagring, behandling og presentasjon av informasjon fra agenter som installeres på de forskjellige servere. Det er et mål at rammeverket er godt designet og at det skal være enkelt å vedlikeholde og videreutvikle. Prosjektet er delt mellom vår gruppe og en annen gruppe som går på linjen Anvendt Datateknologi. Vår del av prosjektet går ut på å lage den sentrale applikasjonen i systemet og databaseløsningen. Den andre gruppen skal ta seg av systemdesign med fokus på agentene, og eventuelt implementasjon av agentene. Side 3
3 FORKLARING TIL KRAVSPESIFIKASJONEN Kravspesifikasjonen er skrevet i et dokumentasjonsformat som Accenture bruker. Accenture ville gjerne ha det i dette formatet, noe vi syntes var greit. Vi har kun laget en kravspesifikasjon for oppgaven som er felles for denne dokumentasjonen og som levering til Accenture. Dokumentasjonsstandarden til Accenture kalles ADM (Accenture Delivery Methods). Kravspesifikasjonen er delt inn i funksjonelle krav, tekniske krav og krav til sikkerhet. De funksjonelle kravene er konkrete krav til systemet som beskriver en ønsket tilstand. De tekniske kravene beskriver systemkravene og hvordan feilhåndteringen skal skje. Sikkerhetskravene beskriver generelle krav til sikkerhet som passordbeskyttelse, rolletilgang med mer. Systemet er rollestyrt med 3 ulike brukere som har forskjellige tilganger og muligheter i systemet. Disse er admininstrator, superbruker og bruker. De funksjonelle kravene er delt inn i naturlige undergrupper som systemkrav, applikasjonskrav, meldingshåndtering, varsling, tilganger, konfigurasjon og målingstyper. Under kolonnen type i selv kravspesifikasjonen har vi lagt inn om kravene er obligatoriske, ønskelige eller mulige. At kravene er mulige er kanskje litt søkt, men det illustrerer hvilke muligheter vår generiske applikasjon har for lettere å illustrere for sensor og de som skal videreutvikle systemet hva det kan brukes til. Disse mulige kravene forutsetter da at agentene som sender data til vår applikasjon er konfigurert til å hente disse dataene. Man kan se på disse mulige kravene som noen av mange scenarioer som vår applikasjon er i stand til å håndtere, men dette avhenger av agentene som er installert og konfigurert hos brukeren. Side 4
4 SAMSVAR MELLOM PRODUKT OG KRAVSPESIFIKASJON I det store og hele samsvarer vårt ferdige produkt med kravspesifikasjonen. Allikevel er det noen krav som vi gjør rede for: Systemet skal ha en oppetid på 95 % Dette kravet har vi ikke fått testet nok til å konkludere med at det er implementert. En oppetid på systemet må testes over en lengre periode enn det vi har hatt anledning til. Databasen som vi bruker har hatt en oppetid på 100 % i et par måneders tid, men dette er ikke nok til å konkludere med at systemet har en oppetid på 95 %. Tid fra kunden trykker på "søk" til siden returneres til kunde skal være maksimalt to sekunder I og med at vi ikke har laget noe brukergrensesnitt så vi har ikke fått testet dette punktet. Vi tror at dette kravet greit skal kunne oppfylles hvis et grensesnitt blir laget, da søk i vår database ser ut til å være svært tidseffektiv. Side 5
5 OM ENKELTE DELER AV KRAVSPESIFIKASJONEN Målingstyper Ettersom agentene skal overvåke forskjellige ting har vi definert noen målingstyper, meningen med agenten er at den skal overvåke alt mulig, men vi har tenkt oss at den vil bli mest brukt til å overvåke enten OSspesifikke målinger, databasespesifikke målinger eller nettverksspesifikke målinger. OS-spesifikke målinger Med OS-spesifikke målinger tenker vi på målinger som operativsystemet kan hente ut, målinger som er aktuelle: CPU-last : Informasjon om gjennomsnittlig last siste minuttet Minne: Total minne og hvor mye minne i % er i bruk nå Diskplass: Totalplass og diskbruk i % akkurat nå. Databasespesifikke målinger Databasespesifikke målinger er målinger som går på databasen til kunde, agentene skal kunne overvåke databaser, målinger som er aktuelle: Finne ut hvor lang tid det tar å kjøre en spørring Kunne kjøre spørringer i databasen og returnere resultatet av disse Kunne hente informasjon om hvor mange spørringer som utføres per sekund i databasen Hente ut informasjon om hvor stor plass en database bruker Uspesifiserte målinger Systemet skal også kunne ta imot uspesifiserte målinger, dette er målinger kunden har definert selv og kan i teorien være alt mulig, dette er også grunnen til at vi ikke har definert alle typer målinger ettersom en viktig funksjon i systemet er at kunden kan definere målinger selv. Side 6
6 KRAVSPESIFIKASJONEN High-level Requirements Project Name: Project Stage: Monitoring Framework Analyse Highlevel Requir ement ID Business Topic 1 Funksjonelle krav High-level Requiremen t Name Systemkrav Short Description Primært mål med systemet Sekundært mål med systemet Priori ty (L,M, H) Type Long Description H Obligatorisk Systemet skal overvåke kritiske applikasjoner i eksterne systemer. Eksempler på hva som kan overvåkes er diskforbruk, cpulast og databaseytelse. Systemet skal kunne konfigureres til ulike kunder. H Obligatorisk Systemet skal overvåke egen applikasjon. Utvidbarhet H Obligatorisk Systemet skal kunne utvides med plug-in-moduler - nye typer agenter skal kunne settes i bruk uten at det påvirker systemets struktur Utvidbarhet H Obligatorisk Databasen skal modelleres slik at det ikke legges begrensninger på hva som kan legges inn av målinger og konfigurasjonsdata Overordnet beskrivelse H Obligatorisk Applikasjonen skal ta imot målingsdata fra agenter. Agenter er små applikasjoner installert i målsystemer Målingstyper H Obligatorisk Målinger kan være alle typer data som agenter er konfigurert til å måle/overvåke Selvovervåkning L Ønskelig Alle agenter skal sende en melding minst hvert minutt i tidsintervallet de er satt til å overvåke??? Lagring av konfigurasjon H Obligatorisk All konfigurasjon skal lagres i og hentes fra databasen Køløsning H Ønskelig Ved å bruke en kø skal applikasjonen sørge for at innsamlet data fra agentene ikke går tapt ved kommunikasjonsfeil, enten mellom agentene og applikasjonen, eller mellom applikasjonen og databasen Applikasjonskrav Meldingshåndtering Side 7 L Ønskelig Agenter skal sende krypterte meldinger til en kø på sentral server H Ønskelig Køen skal motta meldinger i form av serialiserte POJO s fra agenten M Ønskelig Køen skal kjøre på samme server som applikasjonen H Ønskelig En meldingshåndterer skal hente en melding fra køen M Ønskelig Meldingene fra agenten og ned til meldingshåndteren skjer via en
sikker SSL - protokoll H Ønskelig Meldingshåndtereren skal sende meldingen til en valideringsmodul H Ønskelig Valideringsmodulen skal validere meldingen og sende den tilbake M Ønskelig Meldingshåndtereren skal sende meldingen til en parser M Ønskelig Parseren returnerer et målingsobjekt H Ønskelig Meldingshåndtereren skal sende målingsobjektet til et ORMobjekt H Ønskelig ORM-objektet skal håndtere lagring i databasen Varsling Overvåking av applikasjon Overvåking av database Varsling ved kritiske nivåer H Obligatorisk Systemet skal sende en mail til driftsansvarlig hos Accenture hvis deler av systemet blir inoperativt H Obligatorisk Systemet skal sende en mail til driftsansvarlig hos Accenture hvis kommunikasjon mot databasen ikke er mulig H Obligatorisk Systemet skal sende en mail til kunde hvis målinger overstiger de definerte terskler for varsling, se pkt. "Konfigurasjon" Tilganger Alle roller Alle roller har følgende tilganger: Innlogging Ønskelig Alle roller skal måtte logge inn for å bruke applikasjonen Utlogging Ønskelig Alle roller skal kunne logge ut av applikasjonen Autentisering Ønskelig For å logge inn må man oppgi bruker-id og passord Endre opplysninger Ønskelig Alle roller skal kunne endre sitt passord Endre opplysninger Ønskelig Alle roller skal kunne endre sitt telefonnummer Endre opplysninger Ønskelig Alle roller skal kunne endre sin epostadresse Bruker H I tillegg til tilgangene for alle roller skal bruker ha følgende tilganger: Se målinger Ønskelig Bruker skal kunne se målinger fra egne systemer Superbruker I tillegg til tilgangene for bruker skal superbruker ha følgende tilganger: Opprette bruker Ønskelig Superbruker skal kunne opprette brukere Opplysninger om brukere Side 8 Ønskelig Brukere skal registreres med navn, telefonnummer, epostadresse og bruker-id Slette bruker Ønskelig Superbruker skal kunne slette bruker Endre brukeres passord Ønskelig Superbruker skal kunne generere nytt passord til brukere Endre opplysninger om bedrift Ønskelig Superbruker skal kunne endre opplysninger om egen bedrift Legge til agent Ønskelig Superbruker skal kunne legge til nye agenter Konfigurere agent Ønskelig Superbruker skal kunne konfigurere agenter Administrator I tillegg til tilgangene for alle
roller skal administrator ha følgende tilganger: Opprette kunde Ønskelig Administrator skal kunne opprette kunder Opplysninger om kunde Ønskelig Kunder skal registreres med navn på bedrift, navn på superbruker og kunde-id Avslutte kunde Ønskelig Administrator skal kunne slette kunder fra systemet. Dette inkluderer sletting av alle data om kundens systemer Opprette superbruker Endre superbrukers passord Ønskelig Ønskelig Administrator skal kunne opprette superbrukere Administrator skal kunne generere nytt passord til superbrukere Slette superbrukere Ønskelig Administrator skal kunne slette superbrukere Se status på agenter Ønskelig Administrator skal kunne se status på agenter Se målinger fra alle agenter Ønskelig Administrator skal ha tilgang til alle målinger i databasen Se status på systemet Ønskelig Administrator skal kunne se status på applikasjonen Se status på systemet Ønskelig Administrator skal kunne se status på databasen Konfigurasjon Konfigurere varslingsterskler H Obligatorisk Superbruker skal kunne definere terskler for varsling på mail Eksempel, nettverksbruk "Mail ønskes tilsendt hvis det de siste <fem> minutter har vært over <80%> aktivitet Eksempel, CPU-last "Mail ønskes tilsendt hvis det de siste <fem> minutter har vært over <80%> CPU-last Eksempel, filområde "Mail ønskes tilsendt hvis </home/automekanikk/www> fyller mer enn <300> MB Konfigurere filsti H Er Mulig Superbruker skal kunne definere filsti til område av disk som ønskes overvåket Konfigurere tidsintervall Konfigurere frekvens Konfigurere databaseagent Konfigurere spørring H Er Mulig Superbruker skal kunne definere hvilket tidsintervall en måling skal utføres i H Er Mulig Superbruker skal kunne definere hvor ofte en måling skal utføres H Er Mulig Superbruker skal kunne konfigurere hvilken database agenten skal spørre i H Er Mulig Superbruker skal kunne spesifisere hvilken spørring som skal overvåkes Legge til spørringer H Er Mulig Superbruker skal kunne legge til nye spørringer Endre spørringer H Er Mulig Superbruker skal kunne endre spørringer Deaktivere spørringer H Er Mulig Superbruker skal kunne deaktivere spørringer, slik at de ikke blir slettet fra databasen, men ligger der for historikk og til eventuelt senere bruk Målingstyper OS Eksempler på målinger OS-spesifikke målinger: CPU Er Mulig Man skal kunne hente informasjon om CPU-last. Mest hensiktsmessig er kanskje å hente informasjon om gjennomsnittlig cpu-last for eksempel for det siste minuttet Side 9
Minnebruk Er Mulig Man skal kunne hente informasjon om hvor mye minne som er i bruk Installert minne Er Mulig Man skal kunne hente informasjon om hvor mye minne som er installert Bruk av disk Er Mulig Man skal kunne hente informasjon om hvor stor del av diskplass som er i bruk Total diskplass Er Mulig Man skal kunne hente informasjon om total diskplass som er installert Filsystem Er Mulig Man skal kunne overvåke hvor stor plass en del av et filsystem bruker Applikasjoner Er Mulig Man skal kunne sjekke om spesifikke applikasjoner kjører Database Databasespesifikke målinger: Er Mulig Man skal kunne hente informasjon om hvor lang tid det tar å kjøre en definert spørring i måldatabasen Er Mulig Man skal kunne kjøre definerte spørringer i måldatabasen og se resultatet av disse Er Mulig Man skal kunne hente informasjon om hvor mange spørringer som utføres per sekund i måldatabasen Er Mulig Man skal kunne hente informasjon om hvor stor diskplass en måldatabase bruker Nettverk Er Mulig Nettverksspesifikke målinger: Nettverkstilkobling Er Mulig Man skal kunne hente informasjon om om målmaskinen er tilkoblet nettverket Nettverkstrafikk Er Mulig Man skal kunne hente informasjon om antall åpne tilkoblinger Nettverkstrafikk Er Mulig Man skal kunne hente informasjon om hvor mange prosent av nettverkskapasiteten som er i bruk 2 Tekniske krav Systemkrav Utrulling L Ønskelig Applikasjonen skal leveres som én jar-fil Konfigurasjon av applikasjonen L Ønskelig Applikasjonen skal konfigureres av maksimum fire konfigurasjonsfiler Oppsett av database L Ønskelig Databasen skal settes opp automatisk når jar-filen kjøres Utviklingsspråk H Obligatorisk Applikasjonen skal utvikles i Java Database H Obligatorisk Databasen som skal brukes er Oracle 10gR2 Oppetid M Ønskelig Systemet skal ha en oppetid på 95 % Responstid M Ønskelig Tid fra kunden trykker på "søk" til siden returneres til kunde skal være maksimalt to sekunder Feilhåndtering Logging H Obligatorisk Alle feil skal logges til fil og håndteres på en slik måte at systemet fortsetter å kjøre Feil i validering av melding Side 10 M Ønskelig Hvis det oppdages feil i meldinger fra agenter, skal dette logges i en egen logg
3 Sikkerhet Adskillelse av H Obligatorisk All informasjon skal segregeres sensitive data på kundenivå Roller H Ønskelig Tilgang skal baseres på roller Inndeling i roller H Ønskelig Det skal defineres tre roller: administrator, superbruker og bruker Begrensning av tilgang Oppbygging av passord Oppbygging av passord H Obligatorisk Det skal defineres klare skiller mellom rollers muligheter i applikasjonen. L Ønskelig Passord skal ha en minimumslengde på åtte tegn L Ønskelig Passord skal bestå av syv bokstaver og minimum et alfanumerisk tegn Side 11
7 KRAV TIL KODE Accenture satte som krav at all kode skulle skrives på engelsk, med engelske variabel- og klassenavn. Kommentarer skal også skrives på engelsk. Forøvrig skal koden være lett lesbar og inneholde fornuftig bruk av kommentarer. Koden skal være robust og være enkel å videreutvikle etter. Side 12
8 KRAV TIL DOKUMENTASJON Dokumentasjonen skal skrives på norsk, all dokumentasjon skal leses igjennom av minimum to personer for å begrense skrivefeil. Ellers skal vi følge høgskolens dokumentasjonsstandard: http://www.iu.hio.no/~ulfu/hovedprosjekt/dokumenter/dokumentasjonsstandard.pdf Side 13
9 UTVIDELSER Da oppgaven ikke krevde at prosjektet ble laget med et web-grensesnitt er dette den mest opplagte utvidelsen av systemet. Under utviklingen av prosjektet har det vært lagt opp til at et brukergrensesnitt skal utvikles senere, slik at all infrastruktur og kode som underbygger et brukergrensesnitt allerede eksisterer. Varsling over SMS til mobiltelefoner er en funksjonalitet det vil være ønskelig å tilby i dette systemet. Gruppen har ikke undersøkt denne muligheten, men det er generelt ikke vanskelig å implementere denne funksjonaliteten ved hjelp av funskjoner som er innebygget i Spring-rammeverket. Systemet er modulbasert og vil kunne tilpasses andre typer overvåking. Utvikling av nye former for agenter og tilkoblingspunkter for eksterne overvåkingssystemer vil gjøre at man kan tilby overvåking av en stor mengde systemer, ikke begrenset til servere, datamaskiner og databaser. Eksempler på dette kan være industrirelatert overvåking som brukes i olje- eller prosessindustri, overvåking av kritiske apparater på sykehus, i et kraftnettverk eller lignende. Etter at systemet har vært i bruk over lengre tid vil det være naturlig å implementere mulighet for overføring av lagrede overvåkingsdata til et datavarehus. Dermed vil man kunne avlaste databasen ved søk i historiske data, og med en potensielt stor kundemasse vil dette være hensiktsmessig. Side 14
10 ORDLISTE ORM ORM (Object-Relational Mapping) er en programmeringsteknikk som konverterer data mellom ulike databasetyper som for eksempel Oracle, og til objekt orienterte språk som C++ og Java. Resultatet av dette er en virtuell objektdatabase som kan benyttes under utviklingen av programmeringsspråket. Det finnes både gratis og kommersielle produkter til dette formålet. Fordelen med O/R-mapping er at du slipper å skrive databasespørringer mot databasen. POJO Bruken av POJO (Plain Old Java Object) springer ut fra ideen om at jo enklere design, desto bedre. Navnet brukes til å understreke at objektet det gjelder er et vanlig Java-objekt, ikke et spesielt objekt som for eksempel en Javabønne. Side 15