Visualization of Critical Infrastructure Interdependencies using Game Engines

Transkript

1 Forprosjekt: Visualization of Critical Infrastructure Interdependencies using Game Engines Hans Jacob Koren Lund Nils Peter Lunden Robin Skilbrei Sveen 30. januar 2009

2 Innhold 1 Innledning Problemstilling Oppdragsbeskrivelse Rapportens målgruppe og hensikt Målsetting og fokus Rammer Prosjektorganisering Roller i gruppen Grupperegler Rutiner i gruppen Planlegging, oppfølging og rapportering Systemutviklingsmodell: Scrum Daglige statusmøter Sprint-planleggingsmøte Utviklingsmiljø og kvalitetssikring Utviklingsmiljø Dokumentasjon og konfigurasjonsstyring Risikoanalyse

3 1 Innledning 1.1 Problemstilling Kritiske infrastrukturer er systemer som er av høy viktighet for samfunnet. Forstyrrelser av disse infrastrukturene kan føre med seg alvorlige samfunnsmessige og/eller økonomiske konsekvenser. Dette er et tema som er av spesiell interresse for informasjonssikkerhetsavdelingen ved Høgskolen i Gjøvik. Vi har i denne sammenheng fått i oppdrag å utvikle et visualiseringsverktøy som gjør det mulig for brukere å generere forskjellige scenarioer basert på brukerens spesifikasjoner. Verktøyet er tenkt å brukes for å visualisere ulike ulykkesscenarier samt potensielle fareområder i en bygning. 1.2 Oppdragsbeskrivelse I prosjektbeskrivelsen etterlyses et verktøy som gjør det mulig å visualisere ulike scenarioer. Eksempelvis branner, eksplosjoner og oversvømmelser i tilknytning til, eller som følge av forstyrrelser i, kritiske infrastrukturer. Det skal også være mulig å inspisere potensielle faremomenter i en gitt bygningskonstruksjon fra forskjellige perspektiv/synsvinkler dvs. at brukeren skal kunne bevege seg fritt innenfor bygningens vegger jfr. FPS-spill 1. Utover dette skal man kunne importere konstruksjonsdata fra CAD-format (eller et annet standardformat), samt brukerskapte scenarier, på en eller annen måte. Vi anser dette for å være helt avgjørende for hvorvidt verktøyet blir tatt i bruk eller ikke. Dersom ressursene strekker til er det også ønskelig at man skal kunne gå igjennom forskjellige scenarier synkront over nettet med en annen part. For å kunne utvikle et slikt verktøy blir det nødvendig å benytte et eksisterende rammeverk i form av en spillmotor. 1.3 Rapportens målgruppe og hensikt Målgruppen for denne rapporten består hovedsakelig av veilederen for prosjektet, oppdragsgiver og ekstern sensor. Oppdragsgiveren i vårt tilfelle er Høgskolen i Gjøvik v/nils Kalstad Svendsen og Stephen D. Wolthusen. Andre mottakere er studenter ved Høgskolen i Gjøvik som skal ta for seg et liknende hovedprosjekt, eller som ønsker å studere arbeidet i andre sammenhenger. Denne rapporten har til hensikt å gi en fordypende beskrivelse av prosjektet for samtlige mottakere. Prosjektet skal etterhvert vurderes av veileder og ekstern sensor, og det er derfor viktig for oss å få frem hva som er blitt gjort, og hvilke vurderinger og avgjørelser som er tatt underveis. Dette er 1 First Person Shooter-spill 3

4 også viktig mtp. videreutvikling av programvaren. Utover det nevnte, fungerer rapporten også som et hjelpeverktøy for oss i gruppen under prosjektarbeidet. 1.4 Målsetting og fokus Vårt overordnede mål er å komme i land med et produkt som har bruksverdi, og som oppdragsgiver kunne tenke seg å benytte på en eller annen måte. For å oppnå dette vil vi hovedsakelig fokusere på det vi anser for å være de viktigste elementene. Dette innebærer utviklingen av en tredimensjonal visualisering av aktuelle typer scenarier, samt det at man skal kunne importere scenarier og konstruksjonsdata fra standardformater. Dersom vi kommer i land med dette, og fremdeles har disponibel tid, vil vi satse på å implementere en flerbrukerdel der det er mulig for flere parter å gjennomgå og analysere et scenario i sanntid over nettet eller et lokalt nettverk. 1.5 Rammer For å holde prosjektet åpent og juridisk uproblematisk å videreutvikle, må vi benytte oss av et utviklingsmiljø og en spillmotor under lisens for åpen kildekode. Det er ikke satt krav til ytelse og detaljrikhet i scenariene som genereres av verktøyet. På den andre siden trenger vi heller ikke forholde oss til begrensede maskinvareressurser. Utover lisensproblematikken er det ikke annet enn den gjeldende tidsrammen for bacheloroppgaver ved Høgskolen i Gjøvik som setter reelle begrensninger. 2 Prosjektorganisering 2.1 Roller i gruppen Nils Peter Lunden - Prosjektleder, kommunikasjonsansvarlig, backupansvarlig. Hans Jacob Lund - Webmaster, dokumentasjonsansvarlig. Robin Skilbrei Sveen - Testansvarlig, buildmaster. Prosjektleder Det er lederen sitt ansvar å ta tak og være motivator når ting butter i mot og man kanskje har møtt på et uforutsett problem. Derimot er det ikke lederens jobb å kjøre sololøp og ta avgjørelser uten medhold i gruppa. Skulle sterk uenighet oppstå når en avgjørelse skal tas, vil det være lederen som må ta avgjørelsen. Kommunikasjonsansvarlig Har ansvar for å avtale møter med oppdragsgiver og veileder og er generelt gruppens kontaktperson. 4

5 Backupansvarlig Har ansvar for å ta backup av subversion-området i slutten av hver sprint. (Dette brennes ut på CD/DVD og merkes med dato.) Webmaster Har ansvar for å sette opp og vedlikeholde websidene tilknyttet prosjektet. Han vil også ha ansvar for å publisere en oppdatering på prosjektets progresjon hver gang ny funksjonalitet er på plass i programvaren som skal lages. Andre medlemmer på gruppa vil også ha muligheten til å publisere ting på sidene, men webmaster har hovedansvaret for at oppdateringer skjer. Dokumentasjonsansvarlig Har det overordnede ansvaret for dokumentasjonen og å sette sammen de ulike delene som blir forfattet av gruppemedlemmene til en helhet. Han har også ansvaret for å skrive et kort referat av møtene med oppdragsgiver og/eller veileder. Testansvarlig Har hovedansvaret for å utføre tester, eventuelt sørge for at det som skal testes blir testet og at det fungerer slik som det skal. Han har også ansvaret for at tester blir dokumentert. Buildmaster Denne personen skal til enhver tid ha siste versjon av all kildekode slik at vi ser at koden kompilerer og at de ulike delene virker sammen. 2.2 Grupperegler Uenigheter løses ved votering. Prosjektleder blir valgt ved prosjektets start og fungerer ut hele perioden. Gyldig fravær skal meldes så tidlig som mulig. Gjentakende umeldt fravær vil kunne resultere i utestengelse og avkreditering. Alle tar ansvar for at alle mål blir nådd. Alle deltar på gruppe- og statusmøter så langt det lar seg gjøre. Hvis man ikke kan møte opp skal dette gis beskjed om. 2.3 Rutiner i gruppen Hver dag skal arbeidet loggføres. Hver og en skriver ned dato etterfulgt av timeantall og en kort beskrivelse av dagens aktiviteter. For hvert møte som avholdes med oppdragsgiver og/eller veileder, skal det skrives et kort referat som er beskrivende for det som ble diskutert og avgjort på møtet. 5

6 Når det blir tatt en vesentlig beslutning, skal dette dokumenteres. På slutten av hver sprint skal det fullstendige innholdet av lagringsområdet (subversion) brennes på en CD eller DVD. Hver enkeltfil (tekst eller kode) har én ansvarlig person slik at vi unngår konflikter og unødvendig hodebry i forhold til opplasting til repository. Slik vil vi også unngå at alle driver litt med alt. 3 Planlegging, oppfølging og rapportering 3.1 Systemutviklingsmodell: Scrum Ingen i prosjektgruppen har jobbet med et spillmotor-rammeverk tidligere, og det er slikt sett vanskelig å estimere hvor mye vi klarer å produsere, tatt i betraktning den tiden vi har til rådighet. Det er derfor viktig for oss å sørge for at vi har et sluttprodukt som er synlig, og som kan demonstreres. Etter anbefaling fra veileder, konkluderte vi med at vi ville satse på en agile utviklingsmodell. Tidligere, i systemutviklingsfaget, ble det av agilemetoder stort sett fokusert på extreme Programming(XP) og Scrum. Vi valgte derfor å eliminere andre grener av agile-metoder. Siden vi er en gruppe på tre, er parprogrammering (XP) umulig, og siden oppdragsgiver ikke er tilgjengelig til envher tid lar heller ikke on-site customerprinsippet (XP) seg gjøre i praksis. Med dette som grunnlag falt valget på scrum-modellen. Scrum legger til rette for en iterativ og inkrementell arbeidsmåte, og sørger for at vi ikke står uten et presentabelt produkt. Scrum-modellen legger opp til arbeidsintervaller (sprinter) på eksempelvis to til fire uker. Hver gang en sprint er over skal vi ha produsert et kjørbart produkt. Dette innebærer at vi til enhver tid har et produkt som er demonstrerbart/presentabelt. Dette bidrar også til at vi som utviklere i gruppen har noe visuelt og håndfast å forholde oss til. Vi i gruppen føler at prosjektet er nokså ambisiøst med tanke på arbeidsmengde, og det er derfor motiverende at vi med scrum-modellen kan dele opp prosjektet i mindre og mer kortsiktige delmål. Scrum-modellen er ikke spesielt tidkrevende å sette seg inn i, og vi slipper dermed å bruke alt for mye tid på å sette opp rammeverket for arbeidsmetodikken. Vi anser det ikke som nødvendig å innføre noen nye rollebegreper i sammenheng med innføringen av scrum i en såpass liten utviklergruppe. Scrum-modellen vil ikke nødvendigvis bli fulgt slavisk på alle punkter, men den vil fungere som grunnsteinen i strukturen, planleggingen og arbeidsmetodikken i prosjektet. 3.2 Daglige statusmøter Deltakere: utviklergruppen. I henhold til scrum-modellens retningslinjer skal det holdes et femten-minutters 6

7 statusmøte til et fast tidspunkt hver arbeidsdag. Her forteller alle gruppemedlemmer hva de har gjort siden siste statusmøte og hva de planlegger å gjøre frem til det neste. Andre problemstillinger tas også opp på dette møtet. Vi velger å være fleksible på møtenes varighet, da det kan være viktige/vanskelige problemstillinger som bør tas opp i gruppen. 3.3 Sprint-planleggingsmøte Deltakere: utviklergruppen, veileder, oppdragsgiver. Under dette møtet som skal holdes etter hver sprint, ser vi tilbake på hva som er gjort, hva som gikk bra, evt. hva som gikk galt. Dersom oppdragsgiver ønsker å gjøre endringer i prioriteringer eller justeringer i kravspesifikasjonen (scrum-modellen er åpen for endringer i kravspesifikasjonen underveis) må dette tas opp på dette møtet. Ut over dette, diskuterer møtedeltakerene neste forestående sprint, og tar opp eventuelle problemstillinger og innspill. Dokumentasjonsansvarlig i gruppen noterer det som blir diskutert under møtet, og fører inn alle møtereferater. 4 Utviklingsmiljø og kvalitetssikring 4.1 Utviklingsmiljø Følgende programvare og biblioteker kommer vi til å bruke i arbeidet vårt: jmonkeyengine[5] Spillmotoren vi skal bruke. Dette er et såkalt Java scenegraph API 2. Forkortes til jme. Utgitt under BSD-lisensen[2]. JGN[6] Java game networking. Java-rammeverk for nettverksspill. jme Physics[7] Bibliotek for fysikk som er tett knyttet til jme. Eclipse[8] Java IDE 3 som brukes til å skrive all kode. Her vil vi også bruke en programutvidelse for å integrere Subversion-funksjonalitet. Denne vil være bindeledd mellom Eclipse og jme, JGN og jme Physics 2. Apache Ant[9] Vil bli brukt som project build tool. Dette kan integreres i Eclipse. Doxygen[10] Program som vil bli brukt til å generere LaTeX-dokumentasjon basert på vår kildekode. Eclox hot Doxygen-utvidelse til Eclipse. Blender[4] 3D-modellereringsverktøy som vil bli brukt til å konvertere modellfiler. 2 Application programming interface 3 Integrated development environment 7

8 LEd[3] Tekstredigeringsprogram for LaTeX. LEd produserer også selvfølgelig DVI, Postscript og PDF med enkle grep. MS Project 2007 Vil bli brukt til å legge tidsplan og å lage Gantt-skjema. 4.2 Dokumentasjon og konfigurasjonsstyring All dokumentasjon som produseres skal være skrevet i LaTeX for å forenkle samarbeidet om dokumenter. Dokumentene er da bare ren tekst, noe som gjør det enklere å bruke Subversion som lagring til også dokumentasjon. Det vil også gjøre at vi kan fokusere mye mer på innhold framfor hodebry i forhold til dokumentets utseende. Vi skal også bruke Doxygen for å kommentere/dokumentere kildekode (dette gjøres direkte i kildekoden) da denne utvidelsen til Eclipse kan generere LaTeX-dokumentasjon for oss. Kommentering skal skrives underveis mens man koder og ikke senere. Når det gjelder skriving av Java-kildekode generelt vil vi støtte oss til Sun sine retningslinjer og konvensjoner[1]. Videre vil vi konsekvent bruke tab-tasten som innrykk. 2-4 whitespaces per tab gir et godt utseende. 8

9 9

10 4.3 Risikoanalyse Risiko Alvorlighet Sannsynlighet Tiltak Langvarig sykdom. Middels Lav Skrive oversiktlig og veldokumentert kildekode slik at det ikke blir problematisk for en annen på gruppa å ta over ansvarsområdet til den som måtte bli syk. Svikt i maskinvare. Høy Lav Bruke subversion-området til lagring av alt prosjektrelatert. I tillegg skal det tas sikkerhetskopi av dette innholdet i slutten av hver sprint. Hver og en sørger for at sin PC er sikret, det vil si at operativsystem er oppdatert og sikret med antivirusprogramvare. Ikke bli ferdig med Lav Middels Ta igjen tapt tid på sprinter funksjonaliteten som som omfatter mindre kom- skal leveres på sprinten. pleks funksjonalitet. I verste fall fire på kravene til funksjonalitet da dette er et forskningsprosjekt. Manglende kompetanse. Lav Middels Lese teori og tilegne oss kompetanse underveis. Bruke veileder og oppdragsgiver aktivt i prosessen. Buggy kode. Lav Høy Utnevne en på gruppa til testansvarlig. Foreta grundig testing når ny funksjonalitet blir lagt til. Prioritere bug-fiksing foran å kode ny funksjonalitet. Overskride prosjektets Høy Lav Å bruke vår tidsplan (Ganttskjema) tidsfrist. aktivt og foreta justeringer i forhold til den underveis. Fokusere på å delegere oppgaver slik at ikke mer enn én person jobber med en oppgave. Ende opp uten et Høy Lav Velge utviklingsmetode som demonstrerbart produkt. krever periodevis innlevering av kjørbar programvare. 10

11 Generelt tiltak: Utarbeide et godt forprosjekt og bruke dette aktivt videre i arbeidsprosessen for å øke kvaliteten på arbeidsmetoder og resultat. Referanser [1] Sun Microsystems, Code Conventions for the Java Programming Language. [2] jmonkeyengine, BSD license. [3] LaTeX Editor (LEd), [4] Blender, [5] jmonkeyengine, [6] Java Game Networking (JGN), [7] jme Physics, [8] The Eclipse Foundation, Eclipse. [9] Apache Ant, [10] Doxygen, 11