A V D E L I N G F O R I N G E N I Ø R U T D A N N I N G H Ø G S K O L E N I O S L O. Hovedprosjekt i Anvendt Datateknologi Våren 2008

A V D E L I N G F O R I N G E N I Ø R U T D A N N I N G H Ø G S K O L E N I O S L O Hovedprosjekt i Anvendt Datateknologi Våren 2008 2 3. M A I 2 0 0 8 OVERVÅKNINGSSYSTEM FOR ACCENTURE Prosjekt nr. 0 8-27 F o rfattere: Idun B ols ta d, s 10 5459 H eidi R a ae Sj åv i k, s 133700 T r ul s Hage n Selnes, s 135614

PROSJEKT NR.: 08-27 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL: Overvåkningssystem for Accenture DATO: 23. mai 2008 ANTALL SIDER / BILAG: 49 / 10 PROSJEKTDELTAKERE: Idun Bolstad, Heidi Raae Sjåvik, Truls Hagen Selnes INTERN VEILEDER: Dr. Aredo, Demissie OPPDRAGSGIVER: Accenture KONTAKTPERSONER: Therese Børter, Kenneth Stigen, Kjartan Malthe Sørenssen SAMMENDRAG Rapporten er et resultat av gruppe 08-27 sitt hovedprosjekt i Anvendt Datateknologi, våren 2008. Den tar for seg design og modellering av et overvåkingssystem for Accenture og skal kunne brukes til å overvåke systemkritiske prosesser. Overvåkningssystemet består blant annet av overvåkningsagenter som er selvstendige applikasjoner. Arbeidsprosessen under prosjektperioden er også dokumentert. TITTELSIDE STIKKORD: Overvåkningsapplikasjon, Overvåkningsagenter, Soner 2

SAMMENDRAG Prosjektoppgaven gikk ut på å designe og modellere en overvåkingsapplikasjon bestående av overvåkningsagenter, presentasjonslag, mellomvarelag og en database. Oppgaven fikk vi tildelt av konsulentfirmaet Accenture. Applikasjonen skulle brukes til å overvåke systemkritiske prosesser / miljøer. Hele oppgaven ble delt mellom to grupper fra Høgskolen i Oslo og vår del omhandlet overvåkningsagentene og presentasjonslaget. Vi fokuserte for øvrig i hovedsak på agentene. Målet for vår del av oppgaven var å designe og modellere overvåkningsagentene. Overvåkningsapplikasjonen skulle ikke designes for et spesielt målsystem, men være fleksibel slik at nye overvåkningsaktiviteter lett kunne startes opp. Det skulle også være lett å konfigurere og administrere overvåkningsapplikasjonen. Konfigureringen og administrasjonen skulle foregå via et webgrensensitt. Det å få full oversikt over hva vi skulle utvikle og hva det innebar, krevde mange samtaler både innad i gruppen og med veiledere fra Accenture og fra skolen. Forslag ble fremlagt og forkastet etter som innsikten vokste. Til slutt satt vi igjen med en løsning for et overvåkningssystem bestående av overvåkningsagenter og superagenter. Disse skal installeres hos kunden og kommunisere med mellomvarelaget som befinner seg hos Accenture. En essensiell del av vår løsning er bruken av superagenter. En superagent har ansvaret for en eller flere agenter og fungerer som bindeledd mellom agentene og mellomvarelaget. Det er kun agentene som overvåker målsystemet hos kunden. De sender så overvåkningsdata til superagenten som sender dette videre til mellomvarelaget. Superagenten overvåker kun agentene og kan varsle dersom en agent er nede. I rapporten finner man beskrivelse av dette systemet og dokumentasjon av arbeidsprosessen gjennom hele prosjektperioden. 3

FORORD Dette dokumentet er prosjektrapporten for vårt hovedprosjekt ved Høgskolen i Oslo, avdeling for Ingeniørutdanning, Bachelor i Anvendt Datateknologi, våren 2008. Oppdragsgiver for hovedprosjektoppgaven har vært Accenture som er et globalt konsulentselskap med 170.000 arbeidstakere i mer enn 49 land. Accenture i Norge har avdelinger i Oslo, Bergen, Stavanger og Lillehammer med totalt 1200 ansatte. Bedriften leverer tjenester innenfor IT, ledelse, teknologi, rådgivning og outsourcing. Vi søkte Accenture om å få løse en av oppgavene de tilbød som hovedprosjekt for studenter ved Høgskolen i Oslo, avdeling for Ingeniørutdanning. Dessverre ble denne oppgaven trukket tilbake, men Accenture tilbød oss å løse en annen oppgave i stedet og vi takket ja til denne. Dokumentet består av selve prosjektrapporten samt en egen produktrapport. Prosjektrapporten tar blant annet for seg alt arbeid utført i hele prosjektperioden samt tanker rundt prosjektet, utfordringer underveis og hva vi har lært. Produktrapporten tar kun for seg selve produktet vi har laget, med modeller og konkrete beskrivelser av systemet og er å finne som en selvstendig rapport i Vedlegg 1. Det følger også en ordliste bakerst i denne rapporten som forklarer noen ord og uttrykk. Prosjektapporten er først og fremst rettet mot lærere og sensorer og retter seg sekundært mot andre lesere som er interessert i metoder, prosessmodeller og beskrivelser av et overvåkningssystem. Prosjektrapporten er optimalisert for å leses i papirformat. Vi vil gjerne takke våre flinke og inspirerende veiledere, både Kenneth Stigen og Kjartan Malthe Sørenssen fra Accenture og Dr. Aredo, Demissie fra Høgskolen i Oslo, avdeling for Ingeniørutdanning. Vi har satt stor pris på all tid, kunnskap og oppfølging de har gitt oss, og for alle tilbakemeldinger, både positive og negative. De har alle bidratt til å gjøre dette til et utfordrende og lærerikt prosjekt. Vi vil også takke hverandre for det gode samarbeidet; oppmuntringene, rosen og kritikken gjennom hele den perioden prosjektet har vart. Idun Bolstad Truls Hagen Selnes Heidi Raae Sjåvik 4

INNHOLDSFORTEGNELSE Sammendrag... 3 Forord... 4 Innholdsfortegnelse... 5 Liste over illustrasjoner... 7 1 Presentasjon av prosjektet... 8 1.1 Innledning...9 1.2 Om Bedriften...9 1.3 Dagens situasjon...9 1.4 Mål for prosjektet...9 1.5 Utvikling av prosjektstyringsplan...10 2 Organisering av prosjektet... 11 2.1 Intern organisering...11 2.2 Prosjektansvarskart...12 3 Metoder og teknikker... 14 3.1 Arbeids- og fremdriftsplan...14 3.2 Estimering av tidsforbruk...17 3.3 Risikoplanlegging og analyse...18 3.4 Overvåkning og kontrollmekanismer...20 4 Teknisk prosess... 24 4.1 Fossefallmodellen...24 4.2 Rational Unified Process (RUP)...25 4.3 Inkrementell Systemutvikling...25 4.4 SCRUM...25 4.5 Vårt valg...27 5 Kravspesifikasjon... 29 5.1 Antagelser, begrensninger og Ramme -betingelser...29 5.2 Sikkerhet...30 5.3 Brukerkarakteristikk...30 5.4 Funksjonelle krav...31 5

5.5 Ikke-funksjonelle krav...34 5.6 Krav til dokumentasjon...36 5.7 Dokumentstandard...36 6 Evaluering... 37 6.1 Kravspesifikasjonen og dens rolle...37 6.2 Planlegging av prosjektet...38 6.3 Hvordan vi arbeidet og arbeidsmetoder...39 6.4 Verktøy som ble benyttet...39 6.5 Utviklingsprosessen...40 6.6 Forhold gruppa har arbeidet under....42 6.7 Faktisk tidsforbruk...43 6.8 Utfordringer og løsninger...43 7 Oppsummering... 44 Litteraturliste... 46 Ordliste... 48 6

LISTE OVER ILLUSTRASJONER Figurer Figur 3.1 Risikoanalyse med sannsynlighet og alvorlighetsgrad av de ulike risikoene... 20 Figur 4.1 Fossefallsmodellen og dens ulike faser... 24 Figur 4.2 RUP sin livssyklus der hvert inkrement omarbeides helt til perfeksjon oppnås... 25 Figur 4.3 Prosessmodellen SCRUM med sine ulike faser... 26 Figur 4.4 Accentures prosessmodell, ADM.... 28 Figur 6.1 Prosjektet gikk gjennom tre ulike faser... 41 Tabeller Tabell 1.1 Oversikt over utviklingen av prosjektstyringsplanen... 10 Tabell 2.1 Hovedprioriteringer ved prosjektet og hvilken grad de har... 11 Tabell 2.2 Prosjektansvarskart som illustrerer de ulike hovedansvarsområdene... 13 Tabell 3.1 Arbeidsplan som viser alt som skulle gjøres og når det skulle være ferdigstilt... 14 Tabell 3.2 Risikoanalyse med sannsynlighet og alvorlighetsgrad av de ulike risikoene... 19 Tabell 3.3 Oversikt over milepæler, leveranser og logg over møtereferat... 21 Tabell 5.1 Funksjonelle krav... 31 Tabell 5.2 Ikke-funksjonelle krav... 34 7

1 PRESENTASJON AV PROSJEKTET Prosjekttittel Overvåkningssystem Accenture Prosjektbeskrivelse Designe en del av et overvåkningssystem bestående av små selvstendige applikasjoner, overvåkningsagenter, som skal overvåke kritiske systemprosesser i et målsystem. Prosjektperiode 24. oktober 2007-23. mai 2008 Gruppemedlemmer og studentnummer Idun Bolstad, s105459 Heidi Raae Sjåvik, s133700 Truls Hagen Selnes, s135614 Veiledere fra Accenture Kenneth Stigen Kjartan Malthe Sørenssen Veileder fra Høgskolen i Oslo, Avdeling for Ingeniørutdanning Dr. Aredo, Demissie Oppdragsgiver Accenture Kontaktperson Accenture Therese Børter 8

1.1 INNLEDNING Da vi dannet gruppen for hovedprosjektet hadde vi god kjennskap til hverandre fra tidligere prosjekter der vi har samarbeidet, og vi hadde alle god erfaring med det å jobbe sammen. Vi hadde tidlig i studiet avgjort at vi ville løse hovedoppgaven sammen da vi hadde erfaring med at vi samarbeidet godt og har oppnådd bra resultater som gruppe. Gjennom samtaler kom vi frem til at vi ønsket en systemutviklingsoppgave om dette var mulig. Accenture tilbød en oppgave der man skulle utvikle en overordnet modell for en billettog betalingsløsning for et ungdomsarrangement, med bruk av trådløs teknologi. Hovedvekten for løsing av oppgaven ville være prosjektledelse og prosjektstyring. Vi søkte og fikk tilslag på denne oppgaven, men dessverre viste det seg at denne oppgaven bortfalt. Accenture tilbød oss en annen oppgave i stedet og etter litt diskusjon innad i gruppa takket vi ja til tilbudet. I denne rapporten har vi dokumentert hele arbeidsprosessen under prosjektperioden. Man vil finne beskrivelser av de systemutviklingsmetoder som er brukt i prosjektet, styringsprosesser, utviklingsprosessen, arbeidsmetoder og annen informasjon rundt selve arbeidsprosessen og prosjektarbeidet. Kravspesifikasjonen, som både prosjekt- og produktrapporten bygger på, er også å finne i denne rapporten. 1.2 OM BEDRIFTEN Accenture er et globalt konsulentselskap som leverer tjenester innenfor rådgivning, teknologi og outsourcing. Selskapet oppsto i USA i 1953. I 1989 ble Accenture skilt ut fra det daværende moderselskapet og etablert som et selvstendig og uavhengig selskap med fokus på konsulenttjenester innenfor ledelse og teknologi. I juli 2001 ble selskapet børsnotert på New York Stock Exchange (NYSE) med koden ACN. 1.3 DAGENS SITUASJON Accenture ønsker å ha et nytt produkt å tilby kunder. Produktet skal være et overvåkningssystem som kan kjøre på kundens egne datasystemer og overvåke operativsystemorienterte (OS) og databaseorienterte (DB) systemprosesser. 1.4 MÅL FOR PROSJEKTET I mange bedrifter vil det finnes problemer med å ha full oversikt over hva som til enhver tid foregår på eget datasystem. Å kunne overvåke prosesser slik som CPU-bruk, filsystemer og transaksjoner som foregår i en database, vil være svært nyttig. Hvis hele 9

eller deler av kundens datasystem går ned, vil en melding fra en overvåkningsapplikasjon gjøre at man raskere kan reparere feil og få systemet opp igjen. En slik overvåkningsapplikasjon kan ikke være ressurskrevende og da særlig når det gjelder bruk av CPU og minne på serveren den skal kjøre på. Målet med dette prosjektet er å designe en del av en slik overvåkningsapplikasjon, heretter kalt systemet, bestående av overvåkningsagenter som implementeres hos en kunde. Agentene skal kjøre som selvstendige applikasjoner og de skal være små slik at de belaster CPU-bruk minimalt. Systemet skal ha som oppgave å overvåke kritiske systemprosesser i eksterne systemer og skal ikke designes for et spesielt målsystem. Det skal være fleksibelt slik at nye overvåkninger lett kan startes opp. Det skal også være lett å konfigurere og administrere systemet. Konfigureringen og administrasjonen skal foregå i et webgrensesnitt. Hvilke typer konfigurasjoner en bruker har tilgang til avhenger av om bruker er systemadministrator, superbruker eller bruker. 1.5 UTVIKLING AV PROSJEKTSTYRINGSPLAN I Tabell 1.1 er det en oversikt over utviklingen av prosjektstyringsplanen. Den viser hvor mange versjoner det totalt har vært, hva som er endret og dato for endringen. Tabell 1.1 Oversikt over utviklingen av prosjektstyringsplanen Versjon Beskrivelse av versjon Dato 1 Opprettelse av dokumentet. Lagt til kravspek. 31. januar 2 Fjernet kravspek. Denne kommer i eget vedlegg. 21. februar Skrevet beskrivelse og mål 3 Lagt inn designbeskrivelse av systemet 1. april 4 Laget figur- og tabelltekster 8. april 5 Lagt inn prosjektansvarskart. Endret på tekst så 21. april det er korrekt skrifttype og størrelse etc. 6 Lagt til evaluering av prosjektet 29. april 7 Oppdatert og lagt inn mer om evaluering 7. mai 8 Ferdigstilt rapporten 20. mai 10

2 ORGANISERING AV PROSJEKTET Gruppemedlemmene kjente hverandre godt fra før og hadde jobbet sammen i tidligere prosjekter. Dette var derimot ingen garanti for et vellykket samarbeid denne gangen. Det ble derfor utarbeidet ulike retningslinjer som måtte følges. Disse er å finne i samarbeidsavtalen i Vedlegg 2. Det er også viktig å være åpne og tålmodige ovenfor hverandre. Skrevne regler er et godt utgangspunkt, men man må også være psykisk innstilt på et samarbeid. Hovedprioriteringer ved prosjektstart er Tid Tid er alfa og omega. Tidsfrister skal holdes. Kvalitet Det er viktig at andre prioriteringer ikke kommer i veien for kvaliteten. For å oppnå god kvalitet, må man være fokusert og målrettet. Omfang Det er viktig å ha en god oversikt over alt som skal gjøres. Tiden kan da planlegges og brukes mer effektivt. Kostnad Den eneste kostnaden i dette prosjektet er tid. Det må brukes betydelig mengder tid for å kunne sikre god kvalitet på sluttproduktet. Disse punktene kan settes opp i en tabell som viser hvilken prioritet de har. Dette er presentert i Tabell 2.1. Tabell 2.1 Hovedprioriteringer ved prosjektet og hvilken grad de har. 1. prioritet 2. prioritet 3. prioritet 4. prioritet Tid X Kvalitet X Omfang X Kostnad X 2.1 INTERN ORGANISERING Motivasjon er alltid viktig i prosjektarbeid, særlig for fremdriften og kvaliteten av prosjektet. Under dette prosjektet har gruppen utviklet flere artefakter som samarbeidsavtale og fremdriftsplan. Disse er med på å hjelpe motivasjonen for videre arbeid. 11

Samtidig har det vært flere andre faktorer som har bidratt til god motivasjon som Samarbeidsavtale Samarbeidsavtalen viser hva som forventes av gruppemedlemmene. Her er også faste møtetider oppført samt hvilke konsekvenser det får for en som bryter avtalen. Fremdriftsplan Fremdriftsplanen viser hva de forskjellige gruppemedlemmene skal gjøre til enhver tid og gir et overordnet perspektiv på prosjektets helhet. Godt samarbeid Tillit til andre gruppemedlemmer, motivasjon å se at andre jobber. Vite at andre gjør sine tildelte arbeidsoppgaver motiverer deg selv til å gjøre dine egne arbeidsoppgaver. Ha det sosialt og bra sammen. Godt humør, samme mål for gruppemedlemmene og at gruppa fungerer godt sammen gir motivasjon. Kommunikasjon Motivere hverandre med god tilbakemelding og konstruktiv kritikk. Vite at andre er avhengig av deg som gruppemedlem og at du er en viktig del av gruppa. God organisering Nå mål og delmål i fremdriftsplanen. Vite at arbeidsoppgavene er fordelt likt og jobber med oppgaver man ønsker å jobbe med. Fremdriftsplan som viser tidsfrister, og arbeid som gjenstår. Motivasjon av resultat Ønske om best mulig sluttprodukt. Se at prosjektet drives fremover og få resultater av jobbing underveis. 2.2 PROSJEKTANSVARSKART Vi har hatt én prosjektleder, men arbeidet ble delt likt og alle skulle ha like mye ansvar. Vi lagde et ansvarskart slik at alle fikk minst ett hovedansvarsområde. Det er dog mye arbeid som er utført av alle på gruppen, men dette hadde ingen noe hovedansvar for. Prosjektansvarskartet viser hovedoppgaver og hvilke gruppe medlemmer som har ansvar for disse oppgavene og er presenterte i Tabell 2.2. 12

Tabell 2.2 Prosjektansvarskart som illustrerer de ulike hovedansvarsområdene Oppgave Hovedansvarlig Delansvarlig Prosjektleder Heidi Raae Sjåvik Truls Hagen Selnes Modelldesign Truls Hagen Selnes Heidi Raae Sjåvik Sekretær Idun Bolstad Truls Hagen Selnes Webutvikler Heidi Raae Sjåvik Idun Bolstad Prosessdokumentasjon Truls Hagen Selnes Heidi Raae Sjåvik Risikoanalyse Idun Bolstad Heidi Raae Sjåvik Backup ansvarlig Heidi Raae Sjåvik Truls Hagen Selnes Fremdriftsplan Truls Hagen Selnes Idun Bolstad Modell beskrivelse Idun Bolstad Alle Rapport Heidi Raae Sjåvik Alle Kvalitetssikring Alle 13

3 METODER OG TEKNIKKER Dette kapittelet tar for seg ulike metoder og teknikker som ble brukt under prosjektstyringen 3.1 ARBEIDS- OG FREMDRIFTSPLAN Noe av det første som ble gjort var å utarbeide en fremdriftsplan og en arbeidsplan. Dette var for å planlegge delene av prosjektet så nøye som mulig og sette oss mål underveis. En arbeidsplan forteller hva som skal gjøres, mens fremdriftsplanen viser hvor lang tid de ulike delene av prosjektet skal ta. Arbeidsplanen er delt opp i fem hoveddeler, henholdsvis hovedprosjekt, forprosjekt, styringsdokumentasjon, prosjektdokumentasjon og avslutning. Fremdriftsplanen er presentert i Vedlegg 3, mens arbeidsplanen er å finne i Tabell 3.1. Tabell 3.1 Arbeidsplan som viser alt som skulle gjøres og når det skulle være ferdigstilt. Aktivitet Beskrivelse Ferdig HOVEDPROSJEKT 2007/2008 Statusrapport - prosjektskisse Godkjent kontrakt med Accenture Oppretting og utforming av hjemmeside Oppdatering av hjemmeside Kvalitetssikring av artefakter Personlig loggføring Datainnsamling Forberede samtaler med veiledere fra Følgende inngår: forprosjekt, styringsog prosjektdokumenter og avslutning. 19.5.2008 Første møte med veileder fra skolen. Generell informasjon om hovedprosjektet. 15.11.2007 Første møte med oppdragsgiver. Accenture la frem en detaljert prosjektoppgave. 03.12.2007 Hjemmeside utvikles for å publisere prosjekt og artefakter som utvikles. 25.10.2007 Design, brukervennlighet og sikkerhet er krav for vår hjemmeside. 19.5.2008 Alt som produseres må gjennomgås og kvalitetssikres. 19.5.2008 Gruppemedlemmer som jobber selvstendig må selv dokumentere dette med loggføring. 19.5.2008 Informasjonen vi trenger for å løse prosjektet på best mulig måte blir innhentet fortløpende. 14.5.2008 Vi forbereder spørsmål for å få best mulig utbytte av ukentlige samtaler med veiledere. 13.5.2008 14

oppdragsgiver Ukentlig samtale med intern veileder Ukentlig samtale med veileder fra Accenture Forprosjekt Møte med Demissie Aredo, intern veileder Møte med Accenture Vår veileder ved Høgskolen, Demissie B. Aredo 13.5.2008 Kenneth Stigen og Kjartan Sørenssen fra Accenture. 13.5.2008 Viser informasjon om arbeidsgiver, prosjekt som skal gjennomføres og løsningsforslag. 1.2.2008 Førstemøte med veileder fra skolen. Generell informasjon om hovedprosjektet. 15.1.2008 Første møte med oppdragsgiver. Accenture la frem en detaljert prosjektoppgave. 16.1.2008 Arbeidsfordeling Deler oppgavene som vi ser skal løses. 15.1.2008 Datainnsamling Utforming av rapport Godkjent kontrakt mellom HiO og Accenture Oppdatering av rapport Informasjonen vi trenger for å løse prosjektet på best mulig måte blir innhentet fortløpende. 29.1.2008 Viktig å synliggjøre informasjon som skal brukes i hovedrapporten. 23.1.2008 Vårt hovedprosjekt med Accenture blir godkjent av HiO. 23.1.2008 Rapporten oppdateres etter ny input fra veiledere. 1.2.2008 Forprosjekt leveranse Innleveringsdato. 1.2.2008 Belønning Styringsdokumentasjon Samarbeidsavtale for gruppen Tidsestimering Arbeidsplan Fremdriftsplan Alltid viktig med belønning under et prosjekt. Vi har noe å se frem mot. 1.2.2008 Dokumentasjon som brukes til å organisere prosjektarbeidet 19.5.2008 En avtale mellom gruppemedlemmer som viser oppmøtetid, roller og forpliktelser. 6.1.2007 Tidsestimat for gjennomføring av prosjekt som gjenspeiler vårt ambisjonsnivå. 6.2.2008 Hva skal gjøres, kort beskrivelse av oppgaver og når disse skal ferdigstilles. 19.5.2008 Hvem gjør hva, tidsestimat og arbeidsoppgaver, overordnet. 19.5.2008 15

Prosjektdagbok Prosjektdokumentasjon Utkast til prosjektrapport Prosjektrapport Risikoanalyse Kravspesifikasjon Utvikle Use Case diagram Prosjektdagboken blir oppdatert fortløpende av Idun. Gruppens aktiviteter vises. 19.5.2008 Dokumentasjon som produseres som et resultat av prosjektet 19.5.2008 Utkast til prosjektrapport hjelper oss med videre arbeid, og innhold slik at alt er med. 4.2.2008 Utkast til prosjektrapport videreutvikles til en fullstendig og god prosjektrapport. 19.5.2008 Viser risikoer som kan oppstå under prosjekt arbeidet, tiltak og hangling. 5.2.2008 Hjelper oss med forståelse av systemet som skal utvikles og diagram som skal utvikles. 27.2.2008 Gjenspeiler kravspesifikasjonen. Vi lager et overordnet use case av funksjonaliteten. 26.3.2008 Utvikle Klassediagram Viser alle use case og funksjoner. 5.5.2008 Utvikle Sekvensdiagram Viser gangen i modellen vi har laget. 29.4.2008 Utvikle Samarbeidsdiagram Viser hvilke objekter som kommuniserer med hverandre på et overordnet nivå. 29.4.2008 Skrive designdokument Beskrivelse av modeller som er utviklet. 9.5.2008 Utsende møtereferat Møtereferat fra alle møter vi har gjennomført. 19.5.2008 Utvikle animasjonsfilm til fremføringen Animasjon som viser dataflyten i systemet. 8.5.2008 Avslutning Evaluering av prosjektet. 22.5.2008 Evaluering av prosjekt, arbeid og resultat Forberede presentasjon av prosjektet for Accenture Nådde vi målet? Fungerte arbeidsprosessen? Sammenheng med ambisjon og resultat? 19.5.2008 Forberede og utvikle Powerpointpresentasjonen 8.5.2008 Presentasjon av prosjektet for Accenture Presentere systemet som har blitt utviklet 9.5.2008 Ferdigstille prosjektet Gjøre oss helt ferdige med prosjekt- og produktrapport 20.5.2008 16

Trykke oppgaven Trykke oppgaven i fire eksemplarer + tre til oss selv 21.5.2008 Innlevering av prosjekt Innlevering av det vi har produsert. 23.5.2008 Belønning Forberede presentasjonen av prosjektet for sensor Alltid viktig med belønning under et prosjekt. Vi har noe å se frem mot 23.5.2008 Forberede og utvikle Powerpointpresentasjonen 9.6.2008 Presentere prosjektet Presentere prosjektet for sensor 10.6.2008 3.2 ESTIMERING AV TIDSFORBRUK Det er viktig å finne ut omtrent hvor mye tid som skal brukes til prosjektet slik at man kan planlegge ut fra dette. Vi anslo å primært bruke to dager per uke fra kl. 08:00 16:00 samt en halv dag per uke fra kl. 13:00 16:00 i perioden 15. januar 2007 til 23. mai 2008. Antatt tidsbruk: To dager => 16 timer 1 halv dag => 3,5 timer Antall timer pr uke: 19,5 timer Prosjektvarighet: 19 uker Totalt antall timer per gruppemedlem: Estimert tid for prosjektet er: 19,5 timer * 19 uker = 370,5 timer 370,5 * 3 = 1111,5 timer Man kan også ved hjelp av den matematiske formelen fra Snead og Wycoff regne ut den estimerte tiden (E). E = [O + P + (4 * M)] / 6 Antatt tidsbruk for de forskjellige faser i prosjektet kan så fylles inn i en tabell og ut fra denne kan man regne ut den estimerte tiden basert på den matematiske formelen. E = Estimert tid O = Det mest optimistiske tidsestimatet M = Det mest sannsynlige tidsestimatet (tilsvarer tidligere estimert tid) P = Det mest pessimistiske tidsestimatet 17

O M P Forberedelsesfasen 100,0 150,0 250,0 Utdypningsfasen 280,0 330,0 350,0 Konstruksjonsfasen 350,0 431,5 450,0 Avslutningsfasen 150,0 200,0 300,0 Til sammen 880,0 1111,5 1350,0 E = [880 + 1350 + (4 * 1111,5)] / 6 E = 1113 Dette estimatet ble på 1113 timer, hvilket ikke er lagt unna vårt opprinnelige estimat på 1111,5 timer. Vi anslår derfor å ha et ganske godt estimat for antall timer som brukes i prosjekttiden. 3.3 RISIKOPLANLEGGING OG ANALYSE Personene som er involvert i et prosjekt har svært mye å si om hvor vellykket prosjektet blir. Man tenker, oppfører seg og snakker forskjellig. Man har ofte ulike kulturer, bakgrunner og syn på ting som kan føre til store utfordringer. Det kan derimot også være veldig positivt fordi man kan få mange ulike inputs fra sine prosjektmedarbeidere. Flere hoder tenker i de fleste tilfeller bedre enn ett. Av og til oppstår komplikasjoner i en gruppe. Alle er ikke alltid enige om alt og det bør da iverksettes tiltak for å sikre medlemmenes trivsel. Dette kan for eksempel gjennomføres ved hjelp av en demokratisk avstemming, samtale med hverandre, samtale hvor man trekker inn en ekstern person, eller at man snakker sammen under andre omgivelser som venner og ikke som medarbeidere. Andre problemer som kan oppstå i gruppen kan blant annet være Et gruppemedlem slutter Sykdom som fører til fravær, kort eller lengre Gruppen mister interessen / motivasjonen for prosjektet Medlemmene i gruppen er for øvrig ikke de eneste menneskelige faktorene i et prosjekt. Alle som regnes som interessenter i det prosjektet man arbeider med, stakeholders, er også menneskelige faktorer. Det er viktig å opptre profesjonelt, ha en god kommunikasjon og sørge for å holde interessentene oppdatert, slik at de ikke begynner å tvile på prosjektet. Tvilen kan både være rettet mot prosjektet og mot personene som jobber med det. Disse utfordringene er det viktig å ta med i betraktning tidlig i prosjektet, slik at man kan få en oversikt over omfanget til prosjektet og man kan lage en risikoanalyse som tar for seg mulige problemområder og løsninger på disse. 18

Tabell 3.2 Illustrerer mulige risikoer for prosjektet og risikoene er også fremstilt grafisk i Figur 3.1. Tabell 3.2 Risikoanalyse med sannsynlighet og alvorlighetsgrad av de ulike risikoene. Risiko Sannsynlighet % Alvorlighetsgrad Forebyggende tiltak Tiltak hvis problem oppstår Sykdom / ulykke 90 70 Tran, trene, frukt og grønt Ta over oppgaver Prosjektmedlem som slutter 5 40 Godt miljø i gruppa Omorganisering Tid / fravær 85 70 Jobbe effektivt Rapportere, utsette Skade på hardware 10 100 Backup Skaffe nytt, hente backup Underestimering av prosjekt 80 70 God planlegging i forkant Omorganisering Case-verktøy dekker ikke behov 10 20 Oppdragsgiver mister interessen 30 70 Godt forarbeid ved valg av verktøy Jevnlig kontakt, god progressjon Omorganisere Kommunikasjon Avsporing. Resultatet stemmer ikke overens med det produktet som skulle lages 50 95 Gode styringsdokumenter, godt forarbeid Dokumentasjon, kommunikasjon Interne konflikter 70 95 Kommunikasjon Mekling Gruppemedlemmene mister motivasjonen 30 80 Sosialt samvær ved milepæler Teambuilding For lav kompetanse 20 30 Utdanning, litteratur, veileder Mer støtte fra veileder, lese fagstoff Brann 10 100 Backup, lagre flere steder Hente backup Tyveri av utstyr og kunnskap 20 100 Passord på software, backup flere steder Hente backup Datatap 50 100 Backup, lagre flere steder Hente backup Inkonsistent data 15 90 Kommunikasjon Dokumentasjon, kommunikasjon 19

Sannsynlighet, rangering: 0-100 %. Alvorlighetsgrad, rangering: 0-100. 0 ikke alvorlig, 100 = svært alvorlig Inkonsistent data Sykdom / ulykke 100 Prosjektmedlem slutter Datatap 80 60 Tid / fravær Tyveri 40 20 Skade på hardware Brann 0 Underestimering For lav kompetanse Case-verktøy Gruppemedlemmene mister motivasjonen Oppdragsgiver mister interessen Interne konflikter Avsporing Sannsynlighet % Alvorlighetsgrad Figur 3.1 Risikoanalyse med sannsynlighet og alvorlighetsgrad av de ulike risikoene. 3.4 OVERVÅKNING OG KONTROLLMEKANISMER Vi har hatt faste møter både innad i gruppa og med veiledere. Alle møtene har blitt loggført i henholdsvis prosjektdagboka og møtereferat De kan ses i Tabell 3.3 der milepæler er vist i gult. Prosjektdagboka er å finne som Vedlegg 4 og i Vedlegg 5 er det eksempel på et møtereferat. 20

Tabell 3.3 Oversikt over milepæler, leveranser og logg over møtereferat Aktivitet / hva vi jobbet med Dato Første møte med veileder Demissie Aredo på skolen om hovedprosjekt generelt og vårt hovedprosjekt spesielt. 15.1.2008 Første fellesmøte med veiledere fra Accenture, veiledere fra skolen, den andre gruppen og deres veileder fra skolen 16.1.2008 Forprosjekt 17.1.2008 Møte med veiledere fra Accenture, forprosjekt 22.1.2008 Forprosjekt ferdigstilles 23.1.2008 Møte med veiledere fra Accenture 29.1.2008 Jobbe med Use Case og Kravspesifikasjoner 29.1.2008 Use Case og Kravspesifikasjon, arbeid med nettsiden til prosjektet 30.1.2008 Fremdriftsplan, risikoanalyse, Kravspesifikasjoner 31.1.2008 Levering forprosjekt 1.2.2008 Møte med veiledere fra Accenture 5.2.2008 Møte med den andre gruppen, fremdriftsplan, kravspesifikasjon, ADM 5.2.2008 Kravspesifikasjonen 12.2.2008 Møte med veiledere fra Accenture 19.2.2008 Kravspesifikasjonen 19.2.2008 Kravspesifikasjonen 20.2.2008 Møte med den andre gruppen, videre arbeid med kravspesifikasjonen 21.2.2008 Møte med veiledere fra Accenture 26.2.2008 Use Case og kravspesifikasjon 26.2.2008 Vi hadde møte med veileder og fikk tilbakemeldinger på Use Case og om prosjektrapporten. Kravspesifikasjonen ble ferdigstilt 28.2.2008 Møte med veiledere fra Accenture 11.3.2008 Use Case, oppdatering av kravspesifikasjon, beskrivelser av Use Case 11.3.2008 21

Aktivitet / hva vi jobbet med Dato Ferdigstillelse av Use Case, tekst til Use Case, collaboration diagram 12.3.2008 Møte med veiledere fra Accenture 26.3.2008 Ferdigstillelse av Use Case beskrivelse, beskrivelse av applikasjonen, tegninger. 1.4.2008 Sekvensdiagram, klassediagram, arbeid med prosjektrapporten 2.4.2008 Møte med veiledere fra Accenture 8.4.2008 Endret på sekvensdiagram. Oppdaterte rapporten og endret på denne. 8.4.2008 Use Case beskrivelser, prosjektrapport og samarbeidsdiagram 9.4.2008 Møte med veiledere fra Accenture 16.4.2008 Sekvensdiagram, rapport, Use Case 16.4.2008 Sekvensdiagram, rapport 22.4.2008 Rapport 23.4.2008 Videre arbeid med rapporten 29.4.2008 Videre arbeid med rapporten 30.4.2008 Prosjektrapport 1.5.2008 Prosjektrapport 6.5.2008 Prosjektrapport og animasjonsfilm 7.5.2008 Forberede presentasjon av prosjektet for Accenture 8.5.2008 Presentasjon for Accenture 9.5.2008 Prosjektrapport 13.5.2008 Prosjektrapport og siste møte med intern veileder Demissie 14.5.2008 Møte med veiledere fra Accenture og videre jobbing med rapportskriving 15.5.2008 Prosjektrapport 20.5.2008 Skrive ferdig rapportene 21.5.2008 Trykke og binde inn oppgaven 22.5.2008 22

Aktivitet / hva vi jobbet med Dato Levering av hele prosjektet 23.5.2008 Forberede presentasjon 8.6.2008 Forberede presentasjon 9.6.2008 Presentasjon av prosjektet 10.6.2008 23

4 TEKNISK PROSESS Det finnes mange ulike prosessmodeller for å utføre et prosjekt. De er tilpasset ulike behov og har ulike arbeidsmetoder. En utviklingsprosess innebærer gangen gjennom flere ulike faser for å nå et bestemt mål. For eksempel for en husarkitekt: gangen fra idé skisse ferdig tegning prototyp av huset i form av en liten modell ferdigstillelse av selve huset. Hovedfasene i en systemutviklingsprosess er Foranalyse Systemanalyse Design Koding Verifisering & Validering Utrulling av systemet Bruk, testing og vedlikehold Det fins tre hovedretninger for utvikling av programvare: Fossefall, Inkrementell og Iterativ utvikling. 4.1 FOSSEFALLMODELLEN Fossefallmodellen (Waterfall System Development Life Cycle, WSDLC) er en strukturert prosessmodell som forutsetter at tidligere faser i arbeidet er helt ferdig utført før man kan begynne på neste, se Figur 4.1. Denne modellen brukes lite i dag på grunn av sine begrensninger. Figur 4.1 Fossefallsmodellen og dens ulike faser 24

4.2 RATIONAL UNIFIED PROCESS (RUP) I RUP utvikler man deler av systemet (inkrementer) og lager disse som separate enheter. Disse skal kunne fungere som små delsystemer og skal derfor være kjørbare alene. RUP er både iterativ og inkrementell der man har mange korte og tidsbestemte iterasjoner i hver fase og en risikodrevet utvikling. I motsetning til WSDLC som går i fossefall, går RUP i runder (iterativ prosess), se Figur 4.2. Hver modell, hver beskrivelse, hvert artefakt (delprodukt) som utvikles vil ha en egen idé -, utdypnings-, konstruksjons- og overgangsfase og vil således ha mange utgaver. Figur 4.2 RUP sin livssyklus der hvert inkrement omarbeides helt til perfeksjon oppnås. Siden RUP er en iterativ prosess, kan krav fra brukere endres underveis siden man hele tiden går tilbake endrer allerede utført arbeid. I fossefall så lager man hele systemet og endringer fører til at man må begynne helt på nytt igjen. 4.3 INKREMENTELL SYSTEMUTVIKLING Denne metoden går ut på utvikling av delsystemer eller moduler. Utviklingen deles opp i inkrementer (deler) som skal være selvstendige. Noen inkrementer kan bygge på et foregående inkrement, men skal i prinsippet kunne kjøres og testes som selvstendige programenheter. Man kan styre graden av risiko ved hjelp av de ulike modulene. Dersom de ulike modulene ikke er avhengig av andre deler av programmet, får man et tilnærmet lineært fall i risiko når man når slutten av prosjektet. Dersom modulene derimot er avhengig av andre deler i programmet, vil risikonivået være høyere gjennom hele prosjektet. 4.4 SCRUM Dette er en utviklingsmodell som er meget populær ved utvikling av prosjekter i arbeidslivet. Modellen trekker inn elementer fra modeller som fossefallsmetoden og RUP. Scrum er illustrert i Figur 4.3. 25

Figur 4.3 Prosessmodellen SCRUM med sine ulike faser SCRUM kjennetegnes ved Først gis en oversikt over arbeidsoppgaver som skal gjøres med et møte (sprint planning), som utdyper disse oppgavene (backlog). En sprint fase hvor arbeidsoppgavene fordeles og utføres. Daglig møter hvor man forteller om utført arbeid, hva som skal gjøres videre og eventuelle problemer som oppstår/kan oppstå. Et møte som holdes etter at sprinten er utført, hvor man kan komme med tilbakemelding på utført arbeid og hvordan prosjekter har gått. Personer som bruker SCRUM som utviklingsmetode får også tildelt roller, enten pig (gris) eller chicken (høne). Denne rollefordelingen er basert på en vits som viser hvem som må gi mest. A pig and a chicken are walking down a road. The Chicken looks at the pig and says "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says "Good idea, what do you want to call it?" The chicken thinks about it and says "Why don't we call it 'Ham and Eggs'?" "I don't think so" says the pig, "I'd be committed but you'd only be involved" Pigs er de som faktisk utvikler og ofrer seg for å lage prosjektet, prosjektmedarbeiderne. Chickens deltar ikke i selve utviklingen av prosjektet, men er allikevel med ved å gi tilbakemeldinger. Dette er ofte kunden som har bestilt et produkt. 26

Under SCRUM utviklingsmodellen finnes også Scrum master holder oversikten over prosjektoppgaven, tidsfrister og SCRUM teamet Scrum team er gruppen som utfører selve prosjektarbeidet Product owner (stakeholders) Fordeler ved bruk av SCRUM God kommunikasjon God oversikt over fremdrift i prosjekt God oversikt over arbeidsfordeling Hyppige og korte møter, hvor man får mulighet til å komme med innspill, meninger osv. Korte møter tar mindre tid Ulemper ved bruk av SCRUM Kunden er med under hele utviklingen av prosjektet. Dette kan virke forstyrrende for prosjektmedarbeiderne Kunden (representanten fra kundens side) må også være opptatt av hvordan resultatet blir for at arbeidet skal bli best mulig Det finnes flere utviklingsmodeller og metoder og ofte bygger en modell videre på en annen. Vi finner likheter og ulikheter mellom fossefallsmetoden, RUP og SCRUM. Felles for de tre modellene er at prosjektet deles i mindre deler før det påbegynnes. Ved bruk av RUP og SCRUM kan flere faser av prosjektet påbegynnes samtidig. Dette er en stor forskjell fra fossefallsmetoden som kun tillater en fase som utføres av gangen. Fordelen med SCRUM i forhold til RUP og fossefallsmodellen er fastsatte møte tider. Daglige møter er en del av utviklingen. Både mellom SCRUM teamet og kunden. Problem underveis vil da raskere fanges opp, og kunne forbedres med det samme. 4.5 VÅRT VALG Vi har valgt en blanding av RUP og SCRUM. Vi jobber iterativt, men har ikke daglige standup- møter da vi ikke jobber med dette prosjektet hver dag. Accenture har en egen prosessmodell som heter Accenture Development Model (ADM). Se Figur 4.4. Denne er veldig lik SCRUM, men er meget omfattende og består av et stort antall maler for de ulike fasene i prosjektutviklingen. Prosessmodellen og informasjon om denne er kun tilgjengelig innad i Accenture. Vi har trukket ut punkter fra denne modellen og tilpasse det til vårt prosjekt. 27

Figur 4.4 Accentures prosessmodell, ADM. 28

5 KRAVSPESIFIKASJON Hensikten med å lage en kravspesifikasjon er å skape klare rammebetingelser for det systemet man skal utvikle. Kravspesifikasjonen er med på å bestemme hvordan hele systemet skal være og baserer seg på krav fremmet av oppdragsgiver. Alle rammer og krav til systemet i detalj beskrives og til sammen utgjør dette et sett med regler og retningslinjer for hvordan systemet skal utvikles og hva systemet må inneholde av funksjoner. Det er viktig å lage en så detaljert og spesifikk beskrivelse av kravene som mulig, for å unngå å lage noe annet enn det oppdragsgiver i utgangspunktet ønsket. Hele prosjektet bygger på de retningslinjene som beskrives i kravspesifikasjonen. I hovedsak består kravspesifikasjonen av delene funksjonelle og ikke-funksjonelle krav. I tillegg er det lagt inn antagelser som er forutsetninger for at systemet skal kunne brukes på en mest mulig effektiv måte. Det var et krav fra oppdragsgivers side at Accentures egen prosessmodell ADM skulle brukes under utvikling av kravspesifikasjonen. Det ble benyttet en mal fra denne for hvordan kravspesifikasjonen med funksjonelle og ikke-funksjonelle krav skulle settes opp. Vi utarbeidet også en avtale for kravspesifikasjonen med den andre gruppen. Dette for å sikre at enkelte av punktene i kravspesifikasjonene til de to gruppene skulle samsvare. Denne avtalen er å finne som Vedlegg 6. Kravspesifikasjonen er utviklet av oss og har blitt godkjent av veiledere fra oppdragsgiver, Accenture. 5.1 ANTAGELSER, BEGRENSNINGER OG RAMME - BETINGELSER Antagelser Alle superbrukere må ha et gyldig brukernavn og passord for å konfigurere og administrere agentene. Brukere som skal se på overvåkningsresultater må også ha gyldig brukernavn og passord for å kunne logge inn i webgrensesnittet. Superbruker hos kunde må ha over gjennomsnittlige kunnskaper om operativsystemer og databaser for å kunne konfigurere og administrere de respektive agentene. De må ha kunnskaper om systemprosesser i operativsystemet som brukes og databasespråket som brukes på databasen hos kunden. Brukere som skal håndtere overvåkningen må ha grunnleggende datakunnskaper som innebærer å kunne starte opp en datamaskin, kunne installere og avinstallere programmer og kunne bruke vanlige programmer som tekstbehandling og 29

regneark. Bruker må også ha kunnskap til internett, som innebærer bruk av en nettleser og sende og motta e-post. Datastudenter kan for eksempel passe til dette. Begrensninger Kundens systemer der agenten kjører må støtte Java versjon 5 Agentene må kjøre på en server Accenture skal ikke ha support på systemet. Rammebetingelser Rammebetingelsene for oppgaven var at den skulle utvikles ved bruk av Microsoft programvare og ellers utvikles med Open Source - basert programvare. Grunnen til dette var at Accenture ikke ønsket at kunder som skulle benytte seg av applikasjonen skulle måtte ga til innkjøp av lisenser eller ekstra programvare for å benytte seg av produktet. Ellers var det et krav at applikasjonen skulle utvikles i Java. 5.2 SIKKERHET Sikkerhet er svært viktig. Overvåkningsagenten vil sende data ut fra systemet som overvåkes, via et mellomvarelag og til databaser hos Accenture. Kontakt og sending av data vil alltid initieres fra agentene som befinner seg på kundens server, og aldri utenfra og inn. Denne løsningen er valgt av sikkerhetshensyn. Oppdateringer og konfigurasjon vil sendes agentene når de tar kontakt med superagent for å sende data, som i sin tur tar kontakt med mellomvarelaget for å sende data videre til databasen. Det vil også være mulig å benytte en plugin på agentene for å kunne sende data kryptert når det er ønskelig med en større grad av sikkerhet. All sensitiv data skal behandles i henhold til norske lover og forskrifter. 5.3 BRUKERKARAKTERISTIKK Brukere av overvåkningssystemet vil være ansatte ved den organisasjonen som har installert overvåkningsagentene på sine systemer. I tillegg til brukere og superbrukere hos kunden, finnes det en eller flere systemadministratorer hos Accenture. Brukerne vil ha ulik grad av datakunnskaper. De forskjellige typer brukere vil ha ulike roller. Alle brukere vil administrere agentene fra et webgrensesnitt og vanlige brukere vil her kunne se på overvåkningsresultater fra agenter som kjører på eget system. Gjennom webgrensesnittet vil superbruker kunne legge til nye brukere og agenter, samt konfigurere eller definere nye overvåkningsoppgaver som agentene skal utføre på målsystemet. 30

Systemadministrator hos Accenture vil overvåke hele overvåkningsapplikasjonen bestående av agenter, webgrensesnitt, et mellomvarelag og en database. 5.4 FUNKSJONELLE KRAV De funksjonelle kravene er de helt konkrete kravene til systemet og beskriver en ønsket tilstand som enten er oppnådd eller ikke oppnådd. De funksjonelle kravene er presentert i Tabell 5.1. Tabell 5.1 Funksjonelle krav ID Sub # Funksjonelle krav, beskrivelse Prioritet Type Lav / / Middels Obligatorisk / Ønskelig A1.0 Agenter Agent A1.1 Agenter skal kunne overvåke målsystemet. (Server / klienter) A1.2 Agenter skal kunne ta over rollen som superagent om denne skulle gå ned. A1.3 Agenter skal kunne sende data til superagent i XML format. A1.4 Hvis kunden ønsker å sende data kryptert, kan agenten gjøre dette. (Egen plugin). Superagent A1.5 En superagent skal overvåke de vanlige agentene. Den rapporterer dersom en vanlig agent er nede. A1.6 Superagenten skal kunne ta over rollen som vanlig agent dersom denne går ned. A1.7 Superagenten skal kunne sende data til mellomvarelaget. B1.0 Data B1.1 Sending av data skal foregå i Realtime. F.eks. dersom en spørring gjennomføres hvert femte minutt, skal data sendes hvert femte Lav Obligatorisk Ønskelig Obligatorisk Ønskelig Obligatorisk Ønskelig Obligatorisk Ønskelig 31

ID Sub # Funksjonelle krav, beskrivelse Prioritet Type minutt. B1.2 Frekvensen på sending av data kan konfigureres. B1.3 Data som sendes fra agent til mellomvarelaget skal sendes som XML. B1.4 Agentene sender data til superagenten som samlet sender data videre til mellomvarelaget. B1.5 Data som sendes initieres alltid fra målsystem og ut. C1.0 Sikkerhet C1.1 Data som sendes ut på Internett kan krypteres ved hjelp av en egen plugin. Trippel DES anbefales. D1.0 Brukere Bruker D1.1 En bruker må logge inn for å kunne bruke webgrensesnittet. Vedkommende vil ha tilgang til forskjellige funksjoner ut fra hva slags brukerkonto han / hun har. D1.2 Se data fra spesifikk agenter / målsystemer. Kan f. eks se om en agent er i live. Superbruker skal i tillegg kunne Lav Ønskelig Obligatorisk Ønskelig Obligatorisk Ønskelig Obligatorisk Ønskelig D1.2 Legge til nye agenter. Obligatorisk D1.3 Konfigurere nye og eksisterende agenter via et web- grensesnitt. Middels Ønskelig D1.4 Administrere agenter via et web- grensesnitt Obligatorisk D1.5 Navigere seg inn til en enkelt agent og se hva den utfører. Obligatorisk D1.6 Legge til nye brukere / superbrukere. Obligatorisk D1.7 Endre / avslutte eksisterende brukere / superbrukere. Obligatorisk D1.8 Kunden skal kunne definere de overvåkinger Obligatorisk 32

ID Sub # Funksjonelle krav, beskrivelse Prioritet Type en OS- orientert agent skal utføre. F.eks. hvor hyppig en agent skal gjennomføre en overvåking og hva den skal se etter. D1.9 Kunden skal kunne legge inn eller endre på spørringen en databaseagent skal utføre. Kunden kan legge til en ny spørring den skal utføre i tillegg til den gamle. Alle systemer vil ha forskjellige behov for hva man skal spørre etter og hvor (tabeller / kolonner) man skal hente informasjonen fra. Systemadministrator skal i tillegg kunne Obligatorisk D1.9 Legge til nye kunder. Obligatorisk D1.10 Endre / avslutte eksisterende kunder. Obligatorisk D1.11 Overvåke hele overvåkningsapplikasjonen og se dets status. Det vil være aktuelt å kunne se hvor mange/hvilke agenter som er i live. D1.12 Kunne se resultater fra de forskjellige lokale agenter hos alle kundene. E1.0 Konfigurering i web- grensesnittet E1.1 Hva som kan konfigureres vil være avhengig av hvilken type agent det gjelder, (databaseeller OS- orientert). F1.0 Presentasjon av resultater i web- grensesnitt F1.1 Overvåkningen skal kunne overvåkes nær sanntid fra et web- grensesnitt. Dette grensesnittet skal presentere resultatene grafisk der det er naturlig. Det skal kunne være mulig å velge forskjellig måter å fremstille resultatene. Presentasjonslaget vil hente dataene fra applikasjonsdatabasen og skal filtrere dataene i forhold til rettighetene en bruker har. F1.2 Det skal være en avgrensning for hvor langt tilbake i tid man kan se i overvåkningsvinduet. Middels Middels Middels Ønskelig Ønskelig Ønskelig Ønskelig Ønskelig 33

5.5 IKKE-FUNKSJONELLE KRAV Ikke- funksjonelle krav er de tekniske kravene rundt datasending, målsystem og andre tekniske rammer rundt systemet. De ikke-funksjonelle kravene kan gjerne tallfestes i for eksempel prosent, antall eller tid. De ikke-funksjonelle kravene er presentert i Tabell 5.2. Tabell 5.2 Ikke-funksjonelle krav ID Sub # Ikke-funksjonelle krav, beskrivelse Prioritet Type Lav / / Middels Obligatorisk / Ønskelig T1.0 Generelt T1.1 Agentene skal være plattformuavhengige. Obligatorisk T1.2 Agentene skal belaste systemet de installeres på minimalt. Obligatorisk T1.2.1 Agentene skal ikke bruke mer enn 2 mb av serverens harddisk. Obligatorisk T1.2.2 Agentene skal ikke bruke mer enn 5 megabyte minne. Obligatorisk T1.2.3 Agentene skal belaste CPU minimalt. Obligatorisk T1.3 Overvåkingsagentene skal ha en oppetid på minimum 98 % av døgnet. T1.4 Systemet som helhet, inkludert agenter, mellomvarelag og database, skal ha en oppetid på minimum 95 %. T1.5 Svartid på webgrensesnittet skal være maksimum 2 sekunder. T1.6 Oppdateringer skal ha så liten innvirkning på systemet som mulig. T1.7 Tilgjengelig hjelpeinformasjon om agenter og konfigurasjon / administrasjon i webgrensesnittet skal være på en slik måte at det er forståelig for brukergruppen. Det må f.eks. ikke være for teknisk språk hvis brukerne ikke har god teknisk forståelse. T1.8 Målsystemet agentene skal kjøres på må støtte Java versjon 5. Obligatorisk Ønskelig Ønskelig Obligatorisk Obligatorisk Obligatorisk 34

ID Sub # Ikke-funksjonelle krav, beskrivelse Prioritet Type T1.9 Avhengig av konfigurasjonen kan vanlige agenter enten overvåke operativsystem- (OS) eller databaseorienterte transaksjoner. T1.10 En kunde som har servere som ikke kan kommunisere med hverandre, kan ha én superagent pr server som skal overvåkes. T1.11 En kunde som har servere som kan kommunisere med hverandre, kan ha én superagent som overvåker alle agenter i nettverket. Obligatorisk Obligatorisk Obligatorisk T1.12 Data sendes i formatene tid, tekst og tall. Obligatorisk T1.13 Dataformatene må være like for hele overvåkningssystemet, fra agenter via mellomvarelaget og til databasen. T1.14 Data som overvåkes og sendes vil være databaseorienterte eller OS- orienterte. Agentene overvåker spørringer og transaksjoner og overfører data i form av tall eller datasett. Agentene vil overvåke cpu, disk, nettverk, filsystem og minnebruk og overføre dataene i formatene tid, tekst og tall T1.15 Tid måles som Unix timestamp og sendes til mellomvarelaget. Hvis agentene skal brukes etter år 2038 må systemet migreres til et 64 bits system. T1.16 Data som sendes må inneholde sendingsinformasjon som dato, agent-id og datamåling. Datamålingen må inneholde agent-id, tidspunkt og data T1.17 Sensitive data skal behandles etter Norske lover og forskrifter. T1.18 Det skal være to hovedtyper av agenter; superagent og vanlig agent. Disse er i utgangspunktet like, forskjellen ligger i konfigurasjonen og plugin moduler som blir benyttet. T1.19 Systemet skal være utvidbart og være modulbasert. Ønskelig Obligatorisk Obligatorisk Ønskelig Ønskelig Ønskelig Ønskelig 35

5.6 KRAV TIL DOKUMENTASJON I et stort prosjekt som strekker seg over en lengre periode er det viktig med god dokumentasjon fra hele tidsrommet prosjektet varer. Det er gruppen som har vært ansvarlig for å samle og skrive ned all informasjon om prosjekttiden og for å dokumentere alt arbeid som er blitt utført. Gruppen har ført prosjektdagbok og skrevet møtereferater etter alle møter med veiledere. Å dokumentere alt som skjer gir gruppen god kontroll over prosjektets tilstand, hvordan man ligger an i forhold til fremdriftsplanen og hvilke oppgaver som ble utført når. Prosjektet er også blitt dokumentert gjennom styringsdokumenter og prosjektdokumenter. Styringsdokumentene bestod av Fremdriftsplan Arbeidsplan Risikoanalyse Prosjektdagbok Prosjektdokumentene bestod av Kravspesifikasjon Prosjektrapport Produktrapport 5.7 DOKUMENTSTANDARD Fra Høgskolens side var det et krav at man fulgte deres dokumentstandard som er utarbeidet av førstelektor Ann-Mari Torvatn. Denne tok for seg alle dokumenter som skulle leveres og hva som skulle inngå i hvert enkelt. For å få en ryddig rapport med et gjennomført design, har gruppen bestemt at alle dokumenter skal skrives med skriftstilen Times New Roman, skriftstørrelse 12 pkt. og at det skal brukes enkel linjeavstand. Tekst som står i tabeller skal for øvrig skrives med skriftstilen Arial og med skriftstørrelse 10 pkt. De ulike kapitteloverskriftene, sidenummerering og topptekster skal ha lik stil i både prosjekt- og produktrapporten og det skal fremgå visuelt hvilket nivå hver enkelt overskrift befinner seg på. 36

6 EVALUERING Alt arbeidet som er utført er evaluert i dette kapittelet. 6.1 KRAVSPESIFIKASJONEN OG DENS ROLLE Prosjektoppgaven gikk ut på å utvikle dokumentasjon og modeller for et helt nytt overvåkningssystem bestående av agenter som skulle overvåke kritiske prosesser i et målsystem. Viktigheten av å utarbeide en svært nøyaktig og detaljert kravspesifikasjon når en slik applikasjon skal utvikles kan ikke understrekes nok. Dette kapittelet tar for seg selve kravspesifikasjonen samt beskrivelser av datainnsamling, utvikling, endringer og det ferdige resultatet. Innsamling av data Ved prosjektets oppstart hadde vi et oppgaveutkast fra Accenture, se Vedlegg 7, der systemet var beskrevet i grove trekk. For å kunne starte utviklingen av kravspesifikasjonen var vi avhengig av mer informasjon, både fra veiledere hos Accenture om hva de forventet at et slikt system, og fra veileder ved skolen om hva som var teknisk mulig for oss å utvikle. Gjennom møter med veiledere fra Accenture og veileder fra skolen ble oppgaven begrenset og det kom klarere frem hva slags system som skulle utvikles og hvilke krav som ville bli stilt til en slik applikasjon. Utvikling av kravspesifikasjonen Samtaler med veiledere gikk over en lengre periode der vi kom med utkast til kravspesifikasjon, fikk tilbakemeldinger og rettet denne i henhold til disse. Vi hadde også mange diskusjoner innad i gruppa om hva som ville være gode løsninger og om hvordan vi skulle besvare oppgaven best mulig. Den opprinnelige prosjektoppgaven ble fordelt på to grupper, der vår gruppe sto for utvikling av modeller og dokumentasjon for agenter og den andre sto for utvikling av databasedelen som nevnt i kapittel 1 i Produktrapporten. På bakgrunn av dette var det naturlig å ha noen møter med den andre gruppen for å kunne samkjøre kravspesifikasjonene for de ulike delene av systemet. Slik ville vi unngå at de ulike delene av systemet kommer i konflikt med hverandre og at data som sendes fra en del av systemet til en annen er inkonsistente. Det å utvikle en god og detaljert kravspesifikasjon som ga klare føringer for resten av oppgaven, viste seg å være langt mer tidkrevende enn det vi så for oss ved oppstarten av hovedprosjektet. Det krevde mange møter med veiledere og stadig nye versjoner ble utviklet av gruppen. 37