Forprosjekt for Accentures Overvåkningssystem

Transkript

1 Forprosjekt for Accentures Overvåkningssystem Hovedprosjekt våren februar 2008 Forside Skrevet av: Truls Hagen Selnes Heidi Raae Sjåvik Idun Bolstad

2 Innholdsfortegnelse Forside 1 Innholdsfortegnelse 2 1 Presentasjon 3 2 Om oppdragsgiver 3 3 Sammendrag 3 4 Dagens situasjon 4 5 Mål og rammebetingelser Mål Krav for applikasjonen Komponenter for applikasjonen Rammebetingelser 5 6 Løsninger /alternativer Om oppgaven Valg av løsningsmodell Teknologivalg 7 7 Oppsummering 7 2 / 7

3 1 Presentasjon Tittel: Overvåkingssystem for Accenture Utvikle en applikasjon som kan overvåke systemkritiske Beskrivelse: applikasjoner/miljøer Prosjektperiode: 24. oktober juni 2008 Prosjektgruppe: Gruppemedlemmer: Idun Bolstad, Truls Hagen Selnes, Heidi Raae Sjåvik Oppdragsgiver: Accenture Veileder ved HiO: Demissie Aredo Kontaktperson hos Accenture: Therese Børter 2 Om oppdragsgiver Accenture er et globalt konsulentselskap med 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. Accenture har lang ekspertise innen konsulentoppdrag, nyskapende løsninger, globale ressurser og kan mobilisere de rette mennesker med ulike ferdigheter og teknologier som skal til for å kunne samarbeide med kunden. Målet er at kunden skal bli en virksomhet med høy prestasjonsevne 3 Sammendrag Prosjektet er todelt. (Se figur 1). Hele oppgaven omfatter et system bestående av Overvåkningsagenter som skal overvåke prosesser hos ulike kunder hos Accenture Presentasjon av dataene samlet inn fra overvåkingsagentene Mellomvarelager som bearbeider data fra agentene og lagrer det i en database Database Datavarehus som kan lagre data fra databasen over tid Denne gruppen tar for seg oppgaven som omhandler agenter og presentasjonen. Prosjektet vil for øvrig konsentrere seg om spesifikasjon og dokumentasjon (analyse og utformingsfaser) av utviklingen av systemet og ikke så mye om implementeringen i første omgang. Vi foreslår en arkitekturløsning som i hovedsak består av overvåkningsagenter som skal installeres hos kunden for å overvåke applikasjoner og systemprosesser. Disse agentene skal kommunisere med en superagent for sin lokasjon. Superagenten rapporterer data fra agentene til mellomvarelageret. Overvåkingsagentene skal administreres og konfigureres fra et webgrensesnitt. Det skal være én superbruker hos kunden som har tilgang til alle agentene hos kunden. Vedkommende kan opprette brukerkontoer for medarbeidere og gi spesifikke tilganger som disse skal ha. En 3 / 7

4 superbruker hos én kunde skal ikke kunne se overvåkingsagentene til en annen kunde og omvendt. 4 Dagens situasjon Accenture har i dag flere kunder som benytter ulike applikasjoner med behov for overvåking. De fleste bedrifter har systemer som overvåker de systemkritiske applikasjoner, men det er også ønskelig å ha et system som kan overvåke forskjellige typer applikasjoner. Muligheten for å måle aktivitetene i en applikasjon synliggjør sammenhenger mellom bruken av applikasjoner og informasjonssystemer. Kunden ønsker selv å kunne måle applikasjoners endringer, når og hvordan de blir brukt, for så å enklere kunne gjøre endringer når det trengs. Enkelte kunder har forespurt Accenture om de har denne typen overvåkingssystem som kan brukes på ulike typer applikasjoner. I dagens situasjon har ikke Accenture noen tjeneste/system for dette behovet ut til kunder. Accenture ønsker å utvikle et slikt system som kan tilbys eksterne bedrifter som ønsker denne tjenesten. Grunnet etterspørsel er det nå behov for et egenutviklet overvåkningssystem som kan tilbys kunder. 5 Mål og rammebetingelser 5.1 Mål Målet for prosjektet er å utvikle en overvåkningsapplikasjon. Denne applikasjonen skal være et overvåkningssystem som har som oppgave å overvåke eksterne systemer. Applikasjonen skal ikke designes for et spesielt målsystem, men skal være fleksibel, slik at nye overvåkningsaktiviteter lett kan startes opp. Det skal også være lett å konfigurere og administrere overvåkningsapplikasjonen for nye aktiviteter. Konfigureringen og administrasjonen skal foregå i et webgrensesnitt. 5.2 Krav for applikasjonen Den skal vær utvidbar Overvåkningsagentene skal overvåkes, for eksempel av superagenten, for å sikre at de gjør det de skal Skal være et webbasert grensesnitt for konfigurering og administrasjon Segregering av data på kundenivå av sikkerhetshensyn 4 / 7

5 5.3 Komponenter for applikasjonen Overvåkningsagenter som er konfigurerbare Forskjellige typer agenter Mellomvarelag som kommuniserer med presentasjonslaget og agentene og som håndterer all kommunikasjon mellom databasen En Oracle 10g eller 11g database 5.4 Rammebetingelser Det er et krav at Oracle skal benyttes for databaseteknologi og Java er utviklingsspråket for applikasjonen. Utover dette er det ønskelig at Open Source produkter skal benyttes der det er mulig. 6 Løsninger /alternativer 6.1 Om oppgaven Vi tok utgangspunkt i applikasjonsskissen fra oppdragsgiver for å finne en løsning på oppgaven. Den går ut på å ha overvåkningsagenter installert på lokasjon hos kunden. Disse overvåker systemprosesser og rapporterer dette tilbake til et mellomvarelager. Mellomvarelageret prater så med en database der dataene lagres. (figur 1.) Figur 1 Applikasjonsskisse med agenter, mellomvarelager, database, datavarehus og presentasjon. Det er også ønskelig med en presentasjon av dataene samt et datavarehus der man kan lagre store mengder data over tid, for eksempel over flere år. Oppgaven er meget omfattende og deles derfor mellom to grupper som vist i figur 1. 5 / 7

6 Denne gruppen vil ta for seg den rosa delen som omhandler overvåkningsagentene. Vi vil spesifisere og dokumentere overvåkningsagentene, mens den andre gruppen tar for seg mellomvarelager og databasen. Presentasjonsdelen og datavarehuset blir utsatt til vi har oversikt over hvor tidkrevende oppgaven blir. 6.2 Valg av løsningsmodell Det er to mulige modeller for overvåkningsagentene: 1. Den ene baserer seg på stjernetopologi. Det går ut på å ha en agent per målsystem som skal overvåkes og en superagent som kommuniserer med disse. Denne superagenten sender så dataene videre til mellomvarelageret. (Figur 2) 2. Det andre alternativet er at de ulike agentene er selvstendige og kommuniserer direkte med mellomvarelageret. (Figur 3) Figur 2 Selvstendige agenter som kommuniseres med og overvåkes av en superagent som igjen kommuniserer med mellomvarelageret. Figur 3 Selvstendige agenter som kommuniseres med mellomvarelageret direkte. 6 / 7

7 Fordelen med det første alternativet er at man kan ha én overvåking av alle agentene i tillegg. Dersom en agent er nede, vil dette kunne fanges opp av superagenten. Dersom superagenten er nede kan man på forhånd ha bestemt at en av de andre agentene skal overta rollen som superagent. Dersom man ikke har en superagent så må alle agentene overvåke seg selv i tillegg. Dette vil nødvendigvis kreve mer systemressurser enn i det første alternativet. Det er et krav at agentene skal utvikles i Java, så de skal derfor programmeres i dette språket. For utvikling av webgrensesnittet for administrering og konfigurering var det ønskelig at Open Source- produkter, som for eksempel Struts, JSP og Spring, ble brukt så langt det var mulig. For øvrig ville de ikke at PHP ble benyttet da Java også skulle brukes front end mot kunden. 6.3 Teknologivalg Utviklingsverktøy: Rational Rose Andre programmer: MS Word, MS Excel, MS Paint, MS Project, Adobe Acrobat 7 Oppsummering På bakgrunn av kapittelet om valg av modell, mener vi at det første alternativet med en superagent er det beste alternativet. Prosjektet kommer til å omhandle spesifikasjon, dokumentasjon, analyse og utformingsfaser av systemet på høyere abstraksjonsnivå enn implementeringen. Dette er fordi det er viktig å ha god dokumentasjon av systemkravet da dette forenkler implementeringen samt utførelsen av lignende prosjekter i fremtiden. 7 / 7