Fellesprosjektet Gruppe 205

Fellesprosjektet Gruppe 205 Lars Kirkholt Melhus, Morten Gjendemsjø, Stian Pedersen, Andreas H. Ulltveit-Moe og Fredrik Hvaring.

Innholdsfortegnelse Fellesprosjektet: Watch... 1 Innholdsfortegnelse... 2 Prosjektplan... 3 Innledning... 3 Arbeidspakker... 3 Kostnadsestimat... 7 Gantt-diagram... 10 Risikoanalyse... 11 Systemtestplan... 13 Innledning... 13 Testplan... 13 Rapportering av feil... 14 Overordnet design... 15 Innledning... 15 Use cases... 15 Tekstlig beskrivelse... 15 Check well status and graph key values... 15 Browse well log file... 16 Change well data and critical values... 16 Report and comment event... 16 Sekvensdiagrammer... 17 Overordnet struktur... 20 Forklaring... 21 Nettverk... 21 Sluttrapport... 22 Tidsforbruk... 22 Diskusjon... 25 Systemtestrapport... 26 Tester... 26 Endringsrapport... 28 Erfaringer... 28 Hva vi vil unngå i senere prosjekter... 28 Sent oppmøte... 28 Crunch time... 28 Unngå ustrukturerte dager... 28 Mangel på oversikt... 28 Hva vi vil gjenta i senere prosjekter... 29 Ta i bruk SVN og Google Docs... 29 Samarbeid på samme sted... 29 Kompetanseutveksling... 29 Ambisjonsnivå/innstats... 29 Hva vi vil forbedre til senere prosjekter... 29 Planlegging av klasser og pakker... 29 GUI planlegging... 29 Bli flinkere til å overholde interne frister... 30 Varierende arbeidsoppgaver... 30 Bedre kontakt med "kunden"... 30 Flere gruppemøter... 30 Arbeidsavtale... 30 Følge standarder... 30 Oppsummering... 31

Prosjektplan Innledning Hensiktet med fellesprosjektet er å utvikle et overvåkingssystem for oljeplattformer. Vårt system WATCH skal overvåke alle oljebrønnene og lagre data som sensorene gir i en database. Systemet skal gi beskjed til en operatør om sensordataene tyder på at det er korrosjon i brønnene, som kan føre til skader på plattformen. Vi har ca 2 og en halv uke før påske, og 2 og en halv uke etter påske tilgjengelig til prosjektet. Vi er 5 personer på gruppen, med arbeidsuker på 40 timer har vi i utgangspunktet 1000 timer tilgjengelig. Denne delen inneholder fordelingen av arbeidsoppgavene i arbeidspakker. Arbeidspakker Her har vi delt inn arbeidet i pakker med en maks størrelse på 16 timer. Work Breakdown Structure Timer WATCH Arbeidspakker Estimert 1 Planlegging 1.1 FE1 Prosjektplan 1.1.1 Lage arbeidspakker 10 1.1.2 Use Case Points 4 1.1.3 Gantt-diagram 4 1.1.4 Risikoanalyse 8 1.1.5 Ferdistilling 10 1.2 FE2 Systemtestplan 1.2.1 Skrive tester 7 1.2.2 Ferdigstilling 2 1.3 D2 Brukbarhetstest av papirprototyp 1.3.1 Lage overordnet papirprototyp 16 1.3.2 Tilstandsdiagram 6 1.3.4 Lage oppgaver basert på use-case 8 1.3.5 Gjennomføre pre-pilottest 8 1.3.5 Pilottest med studass 10 1.3.6 Gjøre endringer i papirprototyp 5

1.3.7 Pilottest med gruppe 10 1.3.8 Ferdigstilling av rapport 16 1.4 DB1 Konseptuell datamodell 1.4.1 ER-modell 16 1.4.2 Dokument som beskriver hvordan modellen oppfyller krav 10 1.5 FE3 Overordnet design 1.5.1 1.5.2 1.5.3 Usecase-diagrammer for scenariene i kap. 3.3.1, 3.3.2 og 3.3.3 5 Tekstlig usecase for scenariene i kap. 3.3.2, 3.3.3 og 3.3.4 5 Sekvensdiagrammer for scenariene i kap. 3.3.1 til 3.3.4 16 1.5.4 Overordnet systemdesign med klassediagram 16 1.5.5 Tekstlig beskrivelse av design 16 2 Design 2.1 KTN1 2.1.1 Sekvensdiagram for samspill melom A1 og A2 16 2.1.2 Tilstandsdiagrammer for A1 16 2.1.3 2.1.4 2.1.5 Tekstlig beskrivelse av design og realisering av A1 16 Tekstlig beskrivelse av design og realisering av totalløsning 16 Tekstlig beskrivelse av hvordan oppfylle krav 4 fra 6.2 10 2.1.6 Testplan for testing av A1 16 2.2 D3 2.2.1 Lage grafisk struktur 16 2.2.2 Spesifisere hvordan applikasjonen reagerer på.hendelser. Konstruksjonsbeskrivelse. 16 2.3 DB2 Logisk databaseskjema 2.3.1 Revidert versjon av DB1, med endringer markert 5 2.3.2 Lag SQL-script basert på ER-modell 15

3 Implementasjon 3.1 D3 3.1.1 Implementasjon av GUI 3.1.1.1 WATCH-menyer 16 3.1.1.1.1 Plattformforside, Well-oversikt 16 3.1.1.1.2 Well Status 16 3.1.1.1.3 Endre Well Kritiske Verdier 16 3.1.1.1.4 Log 3.1.1.1.4.1 Søkefunksjon 16 3.1.1.1.4.2 Kommentering av hendelser i logg 16 3.1.1.1.4.3 Visning av graf 16 3.1.1.2 Graf-component 3.1.1.2.1 Graf-component historikk 16 3.1.1.2.2 Graf-component Well-oversikt 16 3.1.1.2.3 Graf-component markering av punkter på graf 16 3.1.1.2.4 Graf-component markering av event på graf 16 3.2 KTN2 3.2.1 Implementasjon av A1 3.2.1.1 accept() 10 3.2.1.2 connect(address, port) 16 3.2.1.3 close() 10 3.2.1.4 send(message) 10 3.2.1.5 receive() 10 3.2.1.6 isvalid(packet) 1 3.2.1.7 Behandling av Threads 16 3.2.2 Skrive tester 16 3.2.3 Oppdaterte diagrammer, beskrivelse av endringer 16 3.2.4 Testing 16 3.2.5 Testrapport 16 3.2.6 Demo 16 3.3 Implementasjon av WATCH klasser 3.3.1 Grensesnitt mot persistens 16 3.3.2 Sette opp databasen 16 3.3.3 Implementasjon av SQL spørringen for WATCH 16

3.3.4 Implementasjon av SQL spørringer for MASTERWATCH 16 3.3.5 Implementere kommunikasjon med database 16 3.3.6 Modell til XML 16 3.3.7 XML til Modell 16 3.3.8 Meldingssystem 16 4 Sluttrapportering 4.1 FE4 Sluttrapport, inkludert systemtest og endringsrapport 4.1.1 Estimert og virkelig tidsforbruk, kommentarer 4 4.1.2 Systemtestrapport 4.1.2.1 Resultater 16 4.1.2.2 Endringsrapport 16 4.1.3 Prosjekterfaringer 4.1.3.1 Hva som bør unngås i senere prosjekter 10 4.1.3.2 Hva som bør gjentas i senere prosjekter 10 4.1.3.2 Hva vi bør forbedre oss på 10 Totalt estimert timebruk 877 Arbeid per person 175.4 8-timers arbeidsdager per person 21.925

Kostnadsestimat Use Case Points Description Formula Current Technical Complexity Factor (TCF). Environment Complexity Factor (ECF). TCF = 0.6 + (0.01*Total Technical Factor) 0.865 ECF = 1.4 + (-0.03*Total Environmental Factor) 0.905 Unadjusted Use Case Points (UUCP). UUCP = UUCW + UAW 60 Productivity Factor (PF). 20 UCP UCP = TCF * ECF * UUCP * PF 939.39 TCF Technical Factor Description Weight Value T1 Distributed system 2 4 8 T2 Performance 1 3 3 T3 End User Efficiency 1 4 4 T4 Complex internal Processing 1 3 3 T5 Reusability 1 0 0 T6 Easy to install 0.5 0 0 T7 Easy to use 0.5 3 1.5 T8 Portable 2 0 0 T9 Easy to change 1 2 2 T10 Concurrent 1 4 4 T11 Special security features 1 0 0 T12 T13 Provides direct access for third parties 1 0 0 Special user training facilities are required 1 1 1 Sum 26.5 Weighted Value ECF Environmental Factor Description Weight Value E1 Familiarity with UML 1.5 2 3 E2 Application Experience 0.5 1 0.5 E3 Object Oriented Experience 1 3 3 Weighted Value

E4 Lead analyst capability 0.5 2 1 E5 Motivation 1 4 4 E6 Stable Requirements 2 4 8 E7 Part-time workers -1 0 0 E8 Difficult Programming language -1 3-3 Sum 16.5 UUCW Use Case Type Description Weight Value Simple Average Complex A simple user interface and touches only a single database entity; its success scenario has 3 steps or less; its implementation involves less than 5 classes. 5 1 5 More interface design and touches 2 or more database entities; between 4 to 7 steps; its implementation involves between 5 to 10 classes. 10 2 20 Involves a complex user interface or processing and touches 3 or more database entities; over seven steps; its implementation involves more than 10 classes. 15 2 30 Sum 55 Weighted Value UAW Actor Type Description Weight Value Simple Average Complex The Actor represents another system with a defined API. 1 0 0 The Actor represents another system interacting through a protocol, like TCP/IP. 2 1 2 The Actor is a person interacting via an interface. 3 1 3 Sum 5 Weighted Value PF Productivity Factor Hours per use case point Value 20

Vi ser at totalt kostnadsestimat er regnet til 939 timer. Dette er ikke så langt unna totalt timer estimert i arbeidspakkeskjema som er på litt under 900 timer.

Gantt-diagram I Gantt-diagrammet under har vi lagt inn de viktigste overordnede pakkene. Påskeferien er lagt inn for å markere at det i denne perioden er pause i prosjektet. Vi har jobbet, og planlegger å jobbe, en del parallellt med de forksjellige oppgavene. Derfor er det mange "rektangler" under og over hverandre(parallellt).

Risikoanalyse Her har vi satt opp de risikoene vi mener vi har i prosjektet. Vi har bare tatt med de tilfeller vi mener har en sannsynlighet på 10% eller mer (altså 1 og oppover). Risiko id 1 2 Beskrivelse Sannsynlighet (1-10) (1 = minst sannsynlig) Konsekvens Kostnad for å unngå (1 = minst konsekvens) (1 = minst konstnad) En person blir borte et par dager 1 3 5 8 Tidsplanen som er satt opp skjærer seg. 7 3 8 5 3 En PC mister data 1 7 8 9 4 5 6 7 Et dokument slettes på Google Docs/Code. F.eks at en person kommer bort i "slette" knappen 1 7 En eller flere bærebare pc-er blir ubrukelige. 1 6 1 11 Vi har tolket kravspesifikasjonen eller oppgaven feil slik at det må implementeres på nytt 2 10 4 1 Gruppa har ikke nok kunnskap på et fagområde 6 3 5 4 Prioritet Tiltak Lavere viktigst Orientere personen som kommer tilbake om prosjektets tilstand Utvide arbeidsdagen med noen timer. Evt. jobbe i helger. Eller sløyfe funksjoner i systemet som ikke anses som å være viktig. Benytte Google Code for å lagre koden, sørge for å laste opp alt som vi trenger på Code og Docs Ta jevnlig backup. Lagre dokumenter lokalt på pc'er også. Gruppa flytter arbeidsplassen til en datasal. Lese kravspek grundig, ha kontakt med studass. Utvide arbeidsdagen med noen timer. Evt. jobbe i helger Vi må lese oss opp og bruke ekstra tid på det, nedskalere funksjonaliteten /

8 9 10 11 Vi har misforstått / ikke tilfredstilt kravene til en øving og må levere inn på nytt 7 2 6 3 Databasemodellen må endres slik at andre deler av systemet må gjøres om 2 8 6 2 Tekniske problemer med SVN 1 1 2 6 Problemer med å finne plass til å jobbe på 5 1 2 10 gjøre det mindre avansert Levere inn i god tid slik at vi kan få tilbakemeldinger tidlig Alle skal få god erfaring med SVN slik at de vet hvordan det fungerer Møte opp tidlig. Evt. reservere rom Vi har rangert det å misforstå detaljer i oppgaven høyest fordi vi mener dette, med ikke ignorerbar sannsynlighet, kan komme til å sette oss kraftig tilbake. Ellers legger vi stor vekt på å prøve å unngå feil i databasemodellen, da denne definerer/setter restriksjoner på mye av funksjonaliteten ellers i systemet. Dette må gjøres riktig tidlig.

Systemtestplan Innledning Testene skal testes på det ferdige systemet, og beskrives ut i fra brukerens ståsted. Hver enkelt test tar utgangspunktet i ett av de brukerspesifiserte kravene. Hensikten med testingen er å finne ut om systemet tilfredsstiller alle brukerspesifiserte krav, og avdekke eventuelle feil i systemet. Testplan id Formål med testen Systemets tilstand Inndata Forventet respons 1 Skjekke at det går an å finne kritiske verdier og andre properties på en brønn. Det eksisterer en brønn som er registrert i WATCH. 1. Operatøren velger brønnen fra en meny. 2. Operatøren velger å se på detaljer for den valgte brønnen. 1. Systemet viser skjermbilde for valgt brønn. 2. Systemet viser oversikt over den valgte brønnens kritiske verdier, ID og navn. 2 Sjekke om WATCHsystemet viser alle brønnene på plattformen. WATCH-systemet er basert på en plattform som har mer enn én brønn. 1. Operatøren starter WATCH. 1. Systemet viser alle brønnene. 3 Sjekke om systemet henter data til brønnen hvert sekund. 1. Operatøren velger en brønn. 2. Operatøren sjekker grafen. 1. Systemet viser statusbildet for valgt brønn. 2. Grafen oppdateres med de seneste verdiene. 4 Sjekke om WATCH informerer operatøren når EV > 0. Systemet er foret med data som skal gi EV > 0 på en brønn. 1. Operatøren skjekker brønnoversikt. 1. Systemet viser farget statusikon på brønnen, for å markere unormal EV-verdi. 5 Sjekke om display for brønn endres når man markerer en hendelse som falsk alarm. Systemet er foret med data som gir en hendelse. 1. Operatøren velger å se på brønnen som viser at den har en hendelse. 2. Operatøren studerer hendelsen og aktuelle sensordata, og avgjør at det er falsk alarm. 3. Operatøren markerer falsk 1. Systemet viser skjermbilde for valgt brønn. 2. Systemet viser sensordata fra hendelsen, område på grafen er markert. 3. Systemet bekrefter at hendelsen er rapportert.

6 Sjekke om R, ΔR, P og T er lagret i loggen. 7 Sjekke om det går ann å legge til kommentarer som er lenket til en hendelse. 8 Sjekke om det går ann å søke gjennom loggen og sette inn kommentarer for operatør på plattform. 9 Sjekke om det går an å søke gjennom loggen og sette inn kommentarer for operatør on-shore. Systemet er foret med data som gir en hendelse. Systemet er foret med data som gir en hendelse. Systemet er foret med data. Systemet er foret med data. Onshore system er koblet til plattformen. alarm på hendelsen. 1. Operatøren velger en brønn som skal ha blitt foret med data. 2. Operatøren klikker seg inn på loggen. 3. Operatøren sjekker at de aktuelle verdiene ligger lagret i loggen. 1. Operatøren går inn i loggen 2. Operatøren finner en aktuell hendelse 3. Operatøren legger inn en kommentar på hendelsen 1. Operatør går inn i loggen. 2. Operatør finner et aktuelt tidsrom med søkeverktøyet 3. Operatøren kan velge et eller flere punkter og legge inn en kommentar 1. Operatør velger plattform og brønn. 2. Operatør går inn i loggen. 3. Operatør finner et aktuelt tidsrom med søkeverktøyet 4. Operatøren kan velge et eller flere punkter og legge inn en kommentar 1. Systemet viser skjermbilde for valgt brønn. 2. Systemet viser skjermbildet for loggen. 1. Systemet gir beskjed om at kommentaren ble lagt inn. 2. Kommentaren kommer opp under hendelsen i loggen 1. Systemet gir beskjed om at kommentaren ble lagt inn. 2. Kommentaren kommer opp under hendelsen i loggen 1. Systemet gir beskjed om at kommentaren ble lagt inn. 2. Kommentaren kommer opp under hendelsen i loggen Rapportering av feil Vi gjennomfører testen med observatører som noterer problemer med systemet etter hvert som de oppstår.

Overordnet design Innledning Dette dokumentet inneholder use-caser, overordnet klassediagram, sekvensdiagrammer og forklaringer rundt implementasjonen av WATCH-systemet. Use cases Scenariene 1 til 4 er oppsummert i fire separate use caser. Brukeren vil være omtalt som operatøren. Dette kan både være ingeniøren som sitter på plattformen og han som sitter på land, siden begge skal ha samem funksjonalitet. Figur 1: Use case-diagram. Tekstlig beskrivelse Under kommer en tekstlig beskrivelse av hver use case. Check well status and graph key values Suksess-scenario: 1. Operatøren velger brønnen han vil se på fra menyen. 2. Systemet henter ut de siste dataene fra loggen og presenterer de form av en graf. 3. Operatøren ser på grafen og finner nøkkelverdier for brønnen. Utvidelser: 4a: Report and comment event

Browse well log file Suksess-scenario: 1. Operatøren velger brønnen han vil se på fra menyen. 2. Operatøren velger å se på loggen via menyen. 3. Operatøren fyller inn søkeskjema for å filtrere loggdata, og trykker søk. 4. Systemet henter ut loggdata basert på operatørens kriterier. 5. Operatøren skjekker loggdataene. Utvidelser: 5a: Report and comment event Change well data and critical values Suksess-scenario: 1. Operatøren velger brønnen han vil se på fra menyen. 2. Operatøren velger å endre properties for brønnen. 3. Operatøren fyller inn nye verdier for brønnens egenskaper. 4. Systemet lagrer endringene. Utvidelser: Ingen. Report and comment event Suksess-scenario: 1. Operatøren avgjør om den aktualle hendelsen er falsk alarm ved å se på nøkkelverdier. 2. Operatøren skriver en kommentar om hendelsen. 3. Systemet lagrer rapporten. Utvidelser: Ingen.

Sekvensdiagrammer Sekvensdiagrammene viser hvordan WATCH-systemet håndterer de forskjellige use casene. Vi har ikke inkludert hvordan GUI oppfører seg i forhold til dette. Figur 2: Check Well Status Figur 3: Change Well Properties

Figur 4: Polling from WellSim Figur 5: Browse event entries and add comment

Figur 6: Browse log entries and add comment

Overordnet struktur Her er oppdatert versjon av klassediagrammet, slik det ble ferdig implementert. Figur 2 viser overordnet struktur for Watch og figur 3 viser hvordan persistenslaget til MasterWatch skiller seg fra persistenslaget til Watch. Figur 7: Modell og persistens for Watch (på plattformen) Figur 8: Persistens for MasterWatch (på land)

Figur 9: Request-klassen Forklaring Designet er delt inn i GUI, modell, persistens og nettverk. GUI-delen definerer grensesnitt mot brukeren og baserer seg på data i modell-laget (GUI er ikke tegnet inn her). Modell-biten er for det meste lik for både Watch og MasterWatch. Modell-klassene forholder seg til et grensesnitt definert i "Services" for å kommunisere med persistenslaget. På tjenersiden (Watch) vil kall mot WatchService oversettes til spørringer mot databasen. Hos klient (MasterWatch) vil kall mot MasterWatchService parses til et definert XML-format og sendt over nettverk til et Watch-system. Hos Watch er det en prosess som videresender requests fra MasterWatch til en XMLParser, som igjen kaller riktig service hos WatchService. Den offisielle modellen, de "riktige" dataene, vil til enhver tid være definert til de som ligger i databasen til Watch (på plattformen). Alle forandringer Watch eller MasterWatch gjør genererer kall til metoder som oppdaterer databasen med nyeste data. GUI-delen er ikke tatt med her. Siden MasterWatch skal ha litt mer funksjonalitet enn Watch (kunne velge plattform), blir MasterWatch sitt modell- og GUI-lag noe utvidet/ annerledes. Nettverk All kommunikasjon mellom MasterWatch og Watch skjer gjennom A1-protokollen (se eget dokument). Alt som sendes over nettverket er objekter i XML-format. Klassen XMLParser tar seg av konvertering til/fra XML. Den viktigste funksjonaliteten i Watch skal også gjelde for MasterWatch, derfor må det være mulig for MasterWatch å kalle alle metodene definert i grensesnittet Services. Som vist i figur 9 lager vi klassen Request som pakker inn parametre til metodekall over nettverket.

Sluttrapport Tidsforbruk Work Breakdown Structure Timer WATCH Arbeidspakker Estimert Brukt 1 Planlegging 1.1 FE1 Prosjektplan 1.1.1 Lage arbeidspakker 10 16 1.1.2 Use Case Points 4 3 1.1.3 Gantt-diagram 4 3 1.1.4 Risikoanalyse 8 7 1.1.5 Ferdistilling 10 8 1.2 FE2 Systemtestplan 1.2.1 Skrive tester 7 10 1.2.2 Ferdigstilling 2 4 1.3 D2 Brukbarhetstest av papirprototyp 1.3.1 Lage overordnet papirprototyp 16 30 1.3.2 Tilstandsdiagram 6 2 1.3.4 Lage oppgaver basert på use-case 8 4 1.3.5 Gjennomføre pre-pilottest 8 5 1.3.5 Pilottest med studass 10 5 1.3.6 Gjøre endringer i papirprototyp 5 5 1.3.7 Pilottest med gruppe 10 10 1.3.8 Ferdigstilling av rapport 20 20 1.4 DB1 Konseptuell datamodell 1.4.1 ER-modell 16 15 1.4.2 Dokument som beskriver hvordan modellen oppfyller krav 10 8 1.5 FE3 Overordnet design 1.5.1 Usecase-diagrammer for scenariene i kap. 3.3.1, 3.3.2 og 3.3.3 5 1

1.5.2 1.5.3 1.5.4 Tekstlig usecase for scenariene i kap. 3.3.2, 3.3.3 og 3.3.4 5 1 Sekvensdiagrammer for scenariene i kap. 3.3.1 til 3.3.4 16 6 Overordnet systemdesign med klassediagram 16 16 1.5.5 Tekstlig beskrivelse av design 16 4 2 Design 2.1 KTN1 2.1.1 Sekvensdiagram for samspill melom A1 og A2 16 20 2.1.2 Tilstandsdiagrammer for A1 16 10 2.1.3 2.1.4 2.1.5 Tekstlig beskrivelse av design og realisering av A1 16 10 Tekstlig beskrivelse av design og realisering av totalløsning 16 8 Tekstlig beskrivelse av hvordan oppfylle krav 4 fra 6.2 10 5 2.1.6 Testplan for testing av A1 16 10 2.2 D3 2.2.1 Lage grafisk struktur 16 27 2.2.2 Spesifisere hvordan applikasjonen reagerer på.hendelser. Konstruksjonsbeskrivelse. 16 32 2.3 DB2 Logisk databaseskjema 2.3.1 Revidert versjon av DB1, med endringer markert 5 4 2.3.2 Lag SQL-script basert på ER-modell 15 12 3 Implementasjon 3.1 D3 3.1.1 Implementasjon av GUI 3.1.1.1 WATCH-menyer 3.1.1.1.1 Plattformforside, Well-oversikt 16 15 3.1.1.1.2 Well Status 16 27 3.1.1.1.3 Endre Well Kritiske Verdier 16 16 3.1.1.1.4 Log 3.1.1.1.4.1 Søkefunksjon 16 36

3.1.1.1.4.2 Kommentering av hendelser i logg 16 14 3.1.1.1.4.3 Visning av graf 16 9 3.1.1.2 Graf-component 21 3.1.1.2.1 Graf-component historikk 16 20 3.1.1.2.2 Graf-component Well-oversikt 16 19 3.1.1.2.3 Graf-component markering av punkter på graf 16 21 3.1.1.2.4 Graf-component markering av event på graf 16 23 3.1.1.3 Modeller for GUI 3.1.1.3.1 Modeller for statuspanel 16 20 3.1.1.3.2 Modeller for loggpanel 16 20 3.1.1.3.3 Modeller for propertiespanel 16 20 3.2 KTN2 3.2.1 Implementasjon av A1 3.2.1.1 accept() 10 10 3.2.1.2 connect(address, port) 16 12 3.2.1.3 close() 10 15 3.2.1.4 send(message) 10 10 3.2.1.5 receive() 10 15 3.2.1.6 isvalid(packet) 1 6 3.2.1.7 Behandling av Threads 16 2 3.2.2 Skrive tester 16 6 3.2.3 Oppdaterte diagrammer, beskrivelse av endringer 16 3 3.2.4 Testing/bugfixing 16 25 3.2.5 Testrapport 16 2 3.2.6 Demo 16 14 3.3 Implementasjon av WATCH klasser 3.3.1 Grensesnitt mot persistens 16 25 3.3.2 Sette opp databasen 16 10 3.3.3 3.3.4 3.3.5 Implementasjon av SQL spørringen for WATCH 16 36 Implementasjon av SQL spørringer for MASTERWATCH 16 33 Implementere kommunikasjon med database 16 27 3.3.6 Modell til XML 16 28 3.3.7 XML til Modell 16 24

3.3.8 Meldingssystem 16 0 4 Sluttrapportering 4.1 FE4 4.1.1 Sluttrapport, inkludert systemtest og endringsrapport Estimert og virkelig tidsforbruk, kommentarer 4 5 4.1.2 Systemtestrapport 4.1.2.1 Resultater 11 16 4.1.2.2 Endringsrapport 11 16 4.1.3 Prosjekterfaringer 4.1.3.1 Hva som bør unngås i senere prosjekter 10 16 4.1.3.2 Hva som bør gjentas i senere prosjekter 10 16 4.1.3.2 Hva vi bør forbedre oss på 10 16 Totalt estimert timebruk 899 990 Arbeid per person 179.8 198 8-timers arbeidsdager per person 22.475 24.75 Diskusjon Som timeføringen viser overskred vi det estimerte timeantallet ganske betraktelig på mange områder av implementasjonen. Det er flere ting som gjorde at vi brukte mer tid enn antatt: Implementering av graf viste seg å være noe vi aldri ble helt ferdig med. Det var nok også mer krevende teknisk enn vi antok. Implementering av MasterWatch, serialisering av objekter og få ting til å fungere over nettverk ble vi heller aldri helt ferdige med. Her gikk det med mye tid på debugging. Til slutt måtte vi si oss fornøyd med en MasterWatch som henger seg opp av og til. Ingen av oss er eksperter på layout i Swing, så mye tid ble kastet bort på bare å få GUI til å se bra ut og fungere. Vi rakk ikke å implementere meldingsfunksjonalitet mellom Watch og MasterWatch, derfor er det ført opp 0 timer på det punktet. Arbeidspakkene under 'Implementasjon av Watch-klasser' fikk generelt veldig store tidsoverskridelser. Her inngår også mye bugfiksing og implementasjon av funksjonalitet vi fant ut at vi trengte i implementasjonsfasen. Her kunne vi sikkert delt opp i flere arbeidspakker.

Systemtestrapport Tester id Formål med testen 1 Skjekke at det går an å finne kritiske verdier og andre properties på en brønn. 2 Se om WATCHsystemet viser alle brønnene på plattformen. 3 Sjekke om systemet henter data til brønnen hvert sekund. 4 Sjekke om WATCH informerer operatøren når EV > 0. 5 Sjekke om man kan markerer en hendelse som falsk alarm. Systemets tilstand Det eksisterer en brønn som er registrert i WATCH. WATCHsystemet er basert på en plattform som har mer enn én brønn. Systemet er foret med data som skal gi EV > 0 på en brønn. Systemet er foret med data som gir en hendelse. Inndata 1. Operatøren velger brønnen fra en meny. 2. Operatøren velger å se på detaljer for den valgte brønnen. 1. Operatøren starter WATCH. 1. Operatøren velger en brønn. 2. Operatøren sjekker grafen. 1. Operatøren skjekker brønnoversikt. 1. Operatøren velger å se på brønnen som viser at den har en hendelse. 2. Operatøren studerer hendelsen og aktuelle sensordata, og avgjør at det er falsk alarm. 3. Operatøren markerer falsk Forventet respons 1. Systemet viser skjermbilde for valgt brønn. 2. Systemet viser oversikt over den valgte brønnens kritiske verdier, ID og navn. 1. Systemet viser alle brønnene. 1. Systemet viser statusbildet for valgt brønn. 2. Grafen oppdateres med de seneste verdiene. 1. Systemet viser farget statusikon på brønnen, for å markere unormal EVverdi. 1. Systemet viser skjermbilde for valgt brønn. 2. Systemet viser sensordata fra hendelsen, område på grafen er markert. 3. Systemet bekrefter at hendelsen er rapportert. Resultat 1. Systemet viser skjermbilde med sanntidsdata. OK 2. Systemet viser navn og kritiske verdier. OK 1. Systemet viser alle brønnene. OK 1. OK 2. Grafen oppdateres hvert sekund. OK 1. Viser ikke når EV er over 0, men når EV er over EV_limit, i mer enn 10 sekunder. OK 1. OK 2. OK 3. OK

6 Sjekke om R, ΔR, P og T er lagret i loggen. 7 Sjekke om det går ann å legge til kommentarer som er lenket til en hendelse. 8 Sjekke om det går ann å søke gjennom loggen og sette inn kommentarer for operatør på plattform. 9 Sjekke om det går an å søke gjennom loggen og sette inn kommentarer for operatør onshore. Systemet er foret med data som gir en hendelse. Systemet er foret med data som gir en hendelse. Systemet er foret med data. Systemet er foret med data. On-shore system er koblet til plattformen. alarm på hendelsen. 1. Operatøren velger en brønn som skal ha blitt foret med data. 2. Operatøren klikker seg inn på loggen. 3. Operatøren sjekker at de aktuelle verdiene ligger lagret i loggen. 1. Operatøren går inn i loggen 2. Operatøren finner en aktuell hendelse 3. Operatøren legger inn en kommentar på hendelsen 1. Operatør går inn i loggen. 2. Operatør finner et aktuelt tidsrom med søkeverktøyet 3. Operatøren kan velge et eller flere punkter og legge inn en kommentar 1. Operatør velger plattform og brønn. 2. Operatør går inn i loggen. 3. Operatør finner et aktuelt tidsrom med søkeverktøyet 4. Operatøren kan velge et eller flere punkter og legge inn en kommentar 1. Systemet viser skjermbilde for valgt brønn. 2. Systemet viser skjermbildet for loggen. 1. Systemet gir beskjed om at kommentaren ble lagt inn. 2. Kommentaren kommer opp under hendelsen i loggen 1. Systemet gir beskjed om at kommentaren ble lagt inn. 2. Kommentaren kommer opp under hendelsen i loggen 1. Systemet gir beskjed om at kommentaren ble lagt inn. 2. Kommentaren kommer opp under hendelsen i loggen 1. OK 2. OK, får opp skjermbilde, men må først søke på event, deretter loggdata innenfor eventintervallet for å få vist verdiene. 1. OK 2. OK 1. OK 2. OK Fungerer, men masterwatch/ nettverk krasjer av og til.

Endringsrapport De fleste funksjonene var på plass under første systemtest, men vi har en del feil med MasterWatch og hvordan vi parser/sender objekter over A1 mellom Master og Watch. Vi klarte ikke å fikse dette før fristen. Etter første systemtest ble en del kosmetiske feil rettet, grafen ble litt forbedret, men ingen funksjonelle endringer. En siste systemtest ble gjennomført, uten overraskende med samme resultat som den første. Erfaringer Hva vi vil unngå i senere prosjekter Sent oppmøte Alle dagene har vi avtalt tidspunkt for oppmøtet til kl 10.00. Likevel har det alltid vært noen som har kommet en time eller to for sent. Dettte er ikke ønskelig da det er en fordel at alle møter for å planlegge dagen. Crunch time De siste fire dagene har lengden på arbiedsdagen økt betraktelig. 10-13 timers arbeidsdag er i det meste laget. Med bedre planlegging/mer innsikt i hvor mye av prosjektet som gjenstod kunne vi til en viss grad unngått dette. Unngå ustrukturerte dager Fra dag til dag hadde vi ingen plan for hva vi skulle gjøre. Det hadde vært en fordel at vi på morgene noterte ned en liten plan for hva som skulle gjøres, hvem som skulle gjøre det, og eventuelt hvor lang tid vi burde sette av tid til det. Planen kunne også inneholde tidspunkter for pause/lunsj osv. for å få mer orden på når folk tar pauser og når de jobber. For eksempel burde litt internettsurfing av og til unngås. Mangel på oversikt Vi hadde lite oversikt over hvor mye/lite som egentlig gjenstod tidsmessig totalt i prosjektet. Dette har nok mye å gjøre med at vi ikke har laget et så "stort" system før, og defor har manglende forståelse for hvor lang tid enkelte ting egentlig tar. Å lage tidsanalyser underveis i prosjektet hadde nok vært en fordel.

Hva vi vil gjenta i senere prosjekter Ta i bruk SVN og Google Docs Dette var nok det beste valget vi gjorde i prosjektet. Google Docs brukte vi spesilt de to første ukene. Dette gjorde at alle kunne ha samme dokument oppe på sin pc og flere kunne redigere. Slik gjorde samarbeidet vi med alle innleveringer i planleggingsfasen. SVN i kombinasjon med Google Code gjorde det svært enkelt å ha en versjon på nett som hele tiden skulle være den ofisielle. Gjorde vi en endring, gjorde man en "update" for å få siste versjon ned på sin pc, før man "committed" det man hadde gjort. Samarbeid på samme sted Nesten uten unntak satt vi på samme bord med hver vår pc og jobbet. Dette førte til veldig god kommunikasjon, og vi unngikk problemer som at flere jobbet på samme ting og lignende. Vi fikk også fordelen av å kunne hjelpe hverandre dersom noen trengte hjelp; bedre hjelp enn man kunne fått på MSN eller Skype. Feilsøking ble også enklere da feil ofte kunne dukke opp på grunn av noe andre hadde gjort. Kompetanseutveksling Vi hjalp hverandre dersom man hadde problemer noe. Det var ikke sånn at man ikke gadd å hjelpe noen fordi det "ikke er min oppgave". Samtidig ble det noen som jobbet mye med GUI, andre med nettverk - så læringsutbyttet var litt forskjellig. Ambisjonsnivå/innstats Å være i en gruppe der alle har samme ambisjonsnivå for sluttresultatet og der alle gir mye innsats, er både bra og motiverende til selv å gjøre en god jobb. Man slipper følelsen av at noen må gjøre alt, som hadde gitt en dårlig stemning i gruppen. Hva vi vil forbedre til senere prosjekter Planlegging av klasser og pakker Klassediagrammet gav også ganske god struktur og en oversikt over hvilke klasser vi skulle ha. Likevel ble det litt uoversiktlig hvilke klasser som ble laget og hvilke pakker disse ble lagt i. Vi hadde ikke en felles plan for hvilke paker som skulle opprettes. En bedre planlegging kunne nok gjort arbeisfordelingen lettere. GUI planlegging Til tross for at oppdeling av GUI klasser stort set gav seg selv, hadde det vært en fordel med en liten oversikt over hvilke klasser som skulle lytte på hvilke klasser og hvilke grensesnitt/metoder som skulle implementeres for å få til en slik sammenkobling.

Bli flinkere til å overholde interne frister Vi satte opp noen interne frister for visse deler av programmet men de ble ikke tatt hensyn til senere. Dette førte til lange arbeidsdager og ekstra press. Vi burde utviklet programmet mer systematisk i stedet for å starte overalt. Samtidig hadde alle oppgaver som de kunne gjøre uten å forstyrre eller måtte vente på andre. Varierende arbeidsoppgaver Det ble en tendens etterhvert at noen jobbet med graf, noen med generell GUI, nettverk, database, indre logikk osv. Det var ikke stor flyt/omrokkering av arbeidsoppgaver. For enkelte ble det derfor litt ensformig å jobbe med samme ting, i tillegg til lite kunnskap om deler av systemet og tilhørende fagfelt. Dette kan forbedres. Bedre kontakt med "kunden" I et senere prosjekt bør vi nok prøve å få mer klarhet i detaljer i kravspesifikkasjonen. Kravspesifikkasjonen var ikke så klart formulert, men det kan en vel ikke forvente i praksis heller. Derfor burde vi nok tatt kontakt med "kunden", i vårt tilfellet studassen, for å kunne stille spørsmål rundt kravspesifikkasjonen. Etter hvert som vi jobbet med prosjektet, så mistet vi litt fokus på hva som kravspesifikasjonen ba om. Blant annet var det litt forrvirring rundt det som het ΔR og EV. Flere gruppemøter Vi hadde ambisjoner om å ha et gruppemøte i form av et scrummøte hver morgen. Dette skjedde ikke i praksis. Det kan ha noen med at ikke alle var på plass på avtalt tidspunkt slik at folk bare begynte å jobbe litt individuelt. Likevel følte vi nok at et slikt "formelt" møte var unødvendig da alle som regel visste hva som skulle gjøres, og bare ville komme i gang. Arbeidsavtale Det hadde vært en fordel å lage en slags arbeidsavtale som alle ble enig om at vi skulle følge. Dette kunne gjøre at gruppemedlemmene fikk en større følelse av plikt til å møte til riktig tid. Følge standarder Neste gang vil vi nok avtale en felles kodestandard med tanke på identering/luft i koden, men ellers var vi flinke til å holde Java-konvensjonen på navngivning. Vi kan være flinkere til å benytte gettere og settere på variabler også som brukes innenfor egen klasse.

Oppsummering Vi satte ambisjonsnivået høyt fra starten. Det var kanskje noe optimistisk, siden vi ikke klarte å få alt helt ferdig innen fristen. Likevel tror vi det er viktig å legge lista høyt for å få mest mulig læring ut av et sånt prosjekt. Selv om vi kunne gjort ytterligere forbedringer er vi veldig fornøyde med produktet vi klarte å levere på kun to uker med implementasjon. Kravspesifikasjonen mener vi blir oppfylt i stor grad, med et lite men for MasterWatch sin funksjonalitet som ikke er helt patent. Her kunne vi nok sluppet unna billigere hvis vi hadde benyttet et eller annet ferdig rammeverk for å parse til og fra XML for eksempel.