Fellesprosjektet Gruppe 205

Størrelse: px
Begynne med side:

Download "Fellesprosjektet Gruppe 205"

Transkript

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

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

3 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 Lage arbeidspakker Use Case Points Gantt-diagram Risikoanalyse Ferdistilling FE2 Systemtestplan Skrive tester Ferdigstilling D2 Brukbarhetstest av papirprototyp Lage overordnet papirprototyp Tilstandsdiagram Lage oppgaver basert på use-case Gjennomføre pre-pilottest Pilottest med studass Gjøre endringer i papirprototyp 5

4 1.3.7 Pilottest med gruppe Ferdigstilling av rapport DB1 Konseptuell datamodell ER-modell Dokument som beskriver hvordan modellen oppfyller krav FE3 Overordnet design Usecase-diagrammer for scenariene i kap , og Tekstlig usecase for scenariene i kap , og Sekvensdiagrammer for scenariene i kap til Overordnet systemdesign med klassediagram Tekstlig beskrivelse av design 16 2 Design 2.1 KTN Sekvensdiagram for samspill melom A1 og A Tilstandsdiagrammer for A 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 Testplan for testing av A D Lage grafisk struktur Spesifisere hvordan applikasjonen reagerer på.hendelser. Konstruksjonsbeskrivelse DB2 Logisk databaseskjema Revidert versjon av DB1, med endringer markert Lag SQL-script basert på ER-modell 15

5 3 Implementasjon 3.1 D Implementasjon av GUI WATCH-menyer Plattformforside, Well-oversikt Well Status Endre Well Kritiske Verdier Log Søkefunksjon Kommentering av hendelser i logg Visning av graf Graf-component Graf-component historikk Graf-component Well-oversikt Graf-component markering av punkter på graf Graf-component markering av event på graf KTN Implementasjon av A accept() connect(address, port) close() send(message) receive() isvalid(packet) Behandling av Threads Skrive tester Oppdaterte diagrammer, beskrivelse av endringer Testing Testrapport Demo Implementasjon av WATCH klasser Grensesnitt mot persistens Sette opp databasen Implementasjon av SQL spørringen for WATCH 16

6 3.3.4 Implementasjon av SQL spørringer for MASTERWATCH Implementere kommunikasjon med database Modell til XML XML til Modell Meldingssystem 16 4 Sluttrapportering 4.1 FE4 Sluttrapport, inkludert systemtest og endringsrapport Estimert og virkelig tidsforbruk, kommentarer Systemtestrapport Resultater Endringsrapport Prosjekterfaringer Hva som bør unngås i senere prosjekter Hva som bør gjentas i senere prosjekter Hva vi bør forbedre oss på 10 Totalt estimert timebruk 877 Arbeid per person timers arbeidsdager per person

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

8 E4 Lead analyst capability E5 Motivation E6 Stable Requirements E7 Part-time workers E8 Difficult Programming language 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 More interface design and touches 2 or more database entities; between 4 to 7 steps; its implementation involves between 5 to 10 classes Involves a complex user interface or processing and touches 3 or more database entities; over seven steps; its implementation involves more than 10 classes Sum 55 Weighted Value UAW Actor Type Description Weight Value Simple Average Complex The Actor represents another system with a defined API The Actor represents another system interacting through a protocol, like TCP/IP The Actor is a person interacting via an interface Sum 5 Weighted Value PF Productivity Factor Hours per use case point Value 20

9 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.

10 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).

11 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 Tidsplanen som er satt opp skjærer seg En PC mister data 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 Vi har tolket kravspesifikasjonen eller oppgaven feil slik at det må implementeres på nytt Gruppa har ikke nok kunnskap på et fagområde 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 /

12 Vi har misforstått / ikke tilfredstilt kravene til en øving og må levere inn på nytt Databasemodellen må endres slik at andre deler av systemet må gjøres om Tekniske problemer med SVN Problemer med å finne plass til å jobbe på 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.

13 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.

14 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.

15 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

16 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.

17 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

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

19 Figur 6: Browse log entries and add comment

20 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)

21 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.

22 Sluttrapport Tidsforbruk Work Breakdown Structure Timer WATCH Arbeidspakker Estimert Brukt 1 Planlegging 1.1 FE1 Prosjektplan Lage arbeidspakker Use Case Points Gantt-diagram Risikoanalyse Ferdistilling FE2 Systemtestplan Skrive tester Ferdigstilling D2 Brukbarhetstest av papirprototyp Lage overordnet papirprototyp Tilstandsdiagram Lage oppgaver basert på use-case Gjennomføre pre-pilottest Pilottest med studass Gjøre endringer i papirprototyp Pilottest med gruppe Ferdigstilling av rapport DB1 Konseptuell datamodell ER-modell Dokument som beskriver hvordan modellen oppfyller krav FE3 Overordnet design Usecase-diagrammer for scenariene i kap , og

23 Tekstlig usecase for scenariene i kap , og Sekvensdiagrammer for scenariene i kap til Overordnet systemdesign med klassediagram Tekstlig beskrivelse av design Design 2.1 KTN Sekvensdiagram for samspill melom A1 og A Tilstandsdiagrammer for A Tekstlig beskrivelse av design og realisering av A Tekstlig beskrivelse av design og realisering av totalløsning 16 8 Tekstlig beskrivelse av hvordan oppfylle krav 4 fra Testplan for testing av A D Lage grafisk struktur Spesifisere hvordan applikasjonen reagerer på.hendelser. Konstruksjonsbeskrivelse DB2 Logisk databaseskjema Revidert versjon av DB1, med endringer markert Lag SQL-script basert på ER-modell Implementasjon 3.1 D Implementasjon av GUI WATCH-menyer Plattformforside, Well-oversikt Well Status Endre Well Kritiske Verdier Log Søkefunksjon 16 36

24 Kommentering av hendelser i logg Visning av graf Graf-component Graf-component historikk Graf-component Well-oversikt Graf-component markering av punkter på graf Graf-component markering av event på graf Modeller for GUI Modeller for statuspanel Modeller for loggpanel Modeller for propertiespanel KTN Implementasjon av A accept() connect(address, port) close() send(message) receive() isvalid(packet) Behandling av Threads Skrive tester Oppdaterte diagrammer, beskrivelse av endringer Testing/bugfixing Testrapport Demo Implementasjon av WATCH klasser Grensesnitt mot persistens Sette opp databasen Implementasjon av SQL spørringen for WATCH Implementasjon av SQL spørringer for MASTERWATCH Implementere kommunikasjon med database Modell til XML XML til Modell 16 24

25 3.3.8 Meldingssystem Sluttrapportering 4.1 FE Sluttrapport, inkludert systemtest og endringsrapport Estimert og virkelig tidsforbruk, kommentarer Systemtestrapport Resultater Endringsrapport Prosjekterfaringer Hva som bør unngås i senere prosjekter Hva som bør gjentas i senere prosjekter Hva vi bør forbedre oss på Totalt estimert timebruk Arbeid per person timers arbeidsdager per person 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.

26 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

27 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.

28 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 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 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.

29 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.

30 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.

31 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.

Eksamen i fag TDT4140 Systemutvikling. 8. juni, 2007 kl 0900-1300

Eksamen i fag TDT4140 Systemutvikling. 8. juni, 2007 kl 0900-1300 Side 1 av 15 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: 29. juni, 2007 Eksamen

Detaljer

D2 - Papirprototyping av design

D2 - Papirprototyping av design D2 - Papirprototyping av design nnledning Under designprosessen av brukergrensesnitt for systemet WATCH har vi gjennomført en brukbarhetstest med papirprototyp. denne rapporten vil vi beskrive modellen

Detaljer

=Systemutviklingsprosjekt - WATCH - Gruppe 208=

=Systemutviklingsprosjekt - WATCH - Gruppe 208= =Systemutviklingsprosjekt - WATCH - Gruppe 208= 5 personer 5 laptops /m java lunsjpenger -Ressurser- -Arbeidsoppdeling- Hva Timer Ansvar Lete frem relevant informasjon fra uoversiktlig og spredd informasjon

Detaljer

Eksamen i fag TDT4140 Systemutvikling. 22. mai, 2008 kl 0900-1300

Eksamen i fag TDT4140 Systemutvikling. 22. mai, 2008 kl 0900-1300 Side 1 av 11 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: 15. juni, 2008 Eksamen

Detaljer

Oppgave 1. Finn krav. Finn krav. Finn test

Oppgave 1. Finn krav. Finn krav. Finn test Oppgave 1 1. Hensikten med use case er å oppnå en felles forståelse av krav til systemet mellom brukere / kunder og utviklere. Et use case er et scenario, ikke en komplett, deltaljert kravspesifikasjon.

Detaljer

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk

Lykke til! Eksamen i fag SIF8018 Systemutvikling. 20 mai, 2003 kl 0900-1400. Fakultet for fysikk, informatikk og matematikk NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: XX Eksamen i fag SIF8018 Systemutvikling

Detaljer

LocalBank Prosjektbeskrivelse

LocalBank Prosjektbeskrivelse LocalBank Prosjektbeskrivelse INNHOLD MÅL... 2 STRUKTUR... 2 IMPLEMENTASJON AV ILOCALBANKREPOSITORY... 3 GUI... 4 EXCEPTION... 4 KODE... 4 NOEN KLASSER OG SPESIELLE EMNER SOM DE VISER... 5 KLASSE DIAGRAMMER...

Detaljer

KTN1 - Design av forbindelsesorientert protokoll

KTN1 - Design av forbindelsesorientert protokoll KTN1 - Design av forbindelsesorientert protokoll Beskrivelse av A1 A1 skal tilby en pålitelig, forbindelsesorientert tjeneste over en upålitelig, forbindelsesløs tjeneste A2. Det er flere ting A1 må implementere

Detaljer

Eksamen i fag TDT4140 Systemutvikling. 27. mai, 2011 kl 0900-1300

Eksamen i fag TDT4140 Systemutvikling. 27. mai, 2011 kl 0900-1300 Side 1 av 11 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for informasjonsteknologi, matematikk og elektroteknikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:

Detaljer

Testrapport. Studentevalueringssystem

Testrapport. Studentevalueringssystem Testrapport Studentevalueringssystem 1 Forord 1.2 Forord Dette prosjektet er et hovedprosjekt i data ved Høgskolen i Oslo, avdeling for ingeniørutdanning, og gjennomføres i samarbeid med Ingeniøravdeling

Detaljer

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu

UML 1. Use case drevet analyse og design. 20.01.2004 Kirsten Ribu UML 1 Use case drevet analyse og design 20.01.2004 Kirsten Ribu 1 I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 2 Domenemodell visualisering

Detaljer

VEDLEGG 1 KRAVSPESIFIKASJON

VEDLEGG 1 KRAVSPESIFIKASJON VEDLEGG 1 KRAVSPESIFIKASJON INNHOLDSFORTEGNELSE Forord... 2 1 Systembeskrivelse... 2 2 Mål for systemet... 3 3 Funksjonelle krav... 4 4 Ikke-funksjonelle krav... 5 5 Use-case diagram... 6 6 Rammekrav...

Detaljer

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93 90 Testrapport Forord Dette dokumentet er testrapporten for hovedprosjektet, og skal gi en oversikt over all testing utført på systemet under og etter ferdigstilling, samt feil og løsninger gruppen har

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? Use case modellering. Eksempel Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kirsten Ribu beskriver kravene til systemet,

Detaljer

Brukerdokumentasjon for registrering og rapportering beredskapsutstyr hos Post og Teletilsynet

Brukerdokumentasjon for registrering og rapportering beredskapsutstyr hos Post og Teletilsynet Brukerdokumentasjon for registrering og rapportering beredskapsutstyr hos Post og Teletilsynet Innholdsfortegnelse Innlogging...3 Forside...4 Menyen...4 Oversikt over utstyret...5 Rediger utstyr...6 Opprett

Detaljer

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas Prosjekt nr. 2011 22 Testrapport Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s156159 Jørgen Rønbeck s135779 Dato

Detaljer

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser?

I dag UML. Domenemodell visualisering av konsepter. Eksempel. Hvordan finne domeneklasser? UML Use case drevet analyse og design 31.01.2005 Kirsten Ribu I dag Domenemodell (forløper til klassediagram) Interaksjonsdiagrammer Sekvensdiagram Kollaborasjonsdiagram 1 2 Domenemodell visualisering

Detaljer

20.01.2012. Brukerkrav og use case diagrammer og -tekst 19. januar 2012. Agenda. Brukerkrav og use case. Diagrammer Tekst.

20.01.2012. Brukerkrav og use case diagrammer og -tekst 19. januar 2012. Agenda. Brukerkrav og use case. Diagrammer Tekst. Brukerkrav og use case diagrammer og -tekst 19. januar 2012 Agenda Brukerkrav og use case Diagrammer Tekst Praktisk eksempel 1 OOAD i livsløpsperspektiv Krav Design Konstruksjon Her er vi i nå Testing

Detaljer

Kandidat nr. 1, 2 og 3

Kandidat nr. 1, 2 og 3 Kandidat nr. 1, 2 og 3 Rapport 1 IT202E Bacheloroppgave i Informatikk Vår 2011 Mobilapplikasjonsutvikling med Scrum 1 Innhold Innledning... 3 Overordnet Prosjektplan... 3 Produktbacklog... 5 Sprint planning

Detaljer

Brukerdokumentasjon for Administrator og andre brukere fra PT

Brukerdokumentasjon for Administrator og andre brukere fra PT Brukerdokumentasjon for Administrator og andre brukere fra PT Innholdsfortegnelse Innlogging...3 Forside...4 Menyen...4 Oversikt over utstyret...6 Rediger utstyr...7 Opprett nytt utstyr...9 Søk etter utstyr...

Detaljer

Prosjektoppgave: Bildedatabase. TDT4145 Datamodellering og Databasesystemer. Våren 2008

Prosjektoppgave: Bildedatabase. TDT4145 Datamodellering og Databasesystemer. Våren 2008 Prosjektoppgave: Bildedatabase TDT4145 Datamodellering og Databasesystemer Våren 2008 NB! Kun for de som ikke tar fellesprosjektet. Innledning I løpet av de siste årene har det blitt stadig mer vanlig

Detaljer

Testrapport for Sir Jerky Leap

Testrapport for Sir Jerky Leap Jasmine Garry (s135600) Line Sørensen (s135590) Fredrik Hoem Grelland (s135595) Tor Anders Gustavsen (s127668) 1 1. Forord Dette dokumentet inneholder informasjon og redegjøring av tester foretatt i forbindelse

Detaljer

Conference Centre Portal (CCP)

Conference Centre Portal (CCP) IN-MMO Obligatorisk oppgave 1 Brian Elvesæter mmo-oppgaver@ifi.uio.no 1 Conference Centre Portal (CCP) 2 1 Oblig 1: Problem description [1/3] The Conference Center Portal is an Internet portal that organizers

Detaljer

Brukerveiledning Krokus - Regnskaps- og rapporteringssystem for Geovekst

Brukerveiledning Krokus - Regnskaps- og rapporteringssystem for Geovekst Brukerveiledning Krokus - Regnskaps- og rapporteringssystem for Geovekst Link til Krokus er tilgjengelig på http://www.skogoglandskap.no/temaer/geovekst, under «Eksterne lenker». Krokus, NIBIO sitt regnskaps-

Detaljer

Øving D2 TDT4180 MMI. Våren 2013

Øving D2 TDT4180 MMI. Våren 2013 Øving D2 TDT4180 MMI Våren 2013 1 Øvingene i MMI 2 Øving D2 - Papirprototyping og brukbarhetstesting Obligatorisk. Gjøres i gruppe. Frist for pilottesting av papirprototyp og testoppsett: 08.03.2013 Frist

Detaljer

Vedlegg Side 83 av 155

Vedlegg Side 83 av 155 4 Side 83 av 155 Innholdsfortegnelse 1 Kravspesifikasjon... 86 2 Kravspesifikasjon 2.0... 92 3 Domenemodell... 98 4 UseCase Diagram Oversikt... 102 6 Detaljert beskrivelse av UseCase Diagram... 106 Webapplikasjon...

Detaljer

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker.

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker. Logg 22 oktober 2013 Vi skriver status rapport og starter også med å skrive logg idag. Vi har vært i kontakt med mange firmaer uten alt for mye interesse fra deres side. Vi fortsetter å søke etter oppgave.

Detaljer

Administrering av SafariSøk

Administrering av SafariSøk Administrering av SafariSøk Administrering av SafariSøk Revisjonshistorie Revisjon $Revision: 1.6 $ $Date: 2003/08/05 12:44:02 $ Innholdsfortegnelse 1. Om programmet... 1 Generelt... 1 2. Fremgangsmåter...

Detaljer

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp { En selvstendig plattform som kan brukes til å formidle kurs på nett med dagsaktuell teknologi. Oppgave 5, av Fredrik Johnsen Oppgavestiller

Detaljer

Kompendium for Fellesprosjektet for fagene

Kompendium for Fellesprosjektet for fagene Kompendium for Fellesprosjektet for fagene TTM4100 - Kommunikasjon TDT4140 - Systemutvikling TDT4145 - Datamodellering og Databasesystemer TDT4180 - Menneske-maskin-interaksjon Våren 2009 1 Innhold 1 Introduksjon

Detaljer

Kompendium for Fellesprosjektet for fagene

Kompendium for Fellesprosjektet for fagene Kompendium for Fellesprosjektet for fagene TTM4100 - Kommunikasjon TDT4140 - Systemutvikling TDT4145 - Datamodellering og Databasesystemer TDT4180 - Menneske-maskin-interaksjon Våren 2010 1 Innhold 1 Introduksjon

Detaljer

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011 TESTRAPPORT Forord Denne testrapporten har som formål å beskrive all testing som er utført på systemet, både under utviklingen og etter ferdigstilling. Målet for testingen er for å verifisere at vi har

Detaljer

INF 5120 Obligatorisk oppgave Nr 2

INF 5120 Obligatorisk oppgave Nr 2 INF 5120 Obligatorisk oppgave Nr 2 Vigdis Bye Kampenes Stein Grimstad Gruppe 26 INF 5120 Obligatorisk oppgave Nr 2... 1 1 Business model... 2 Innledende kommentarer... 2 Andre avgrensninger... 2 Scoping

Detaljer

Planlegging og dokumentasjon

Planlegging og dokumentasjon Planlegging og dokumentasjon Edgar Bostrøm. - leilighetsnotat, etterutdanningskonferansen, 17.02.2010, noe revidert. Generelle kommentarer: Begrunnelse for hovedområdet Planlegging og dokumentasjon : o

Detaljer

Huldt & Lillevik Lønn 5.0. Installere systemet

Huldt & Lillevik Lønn 5.0. Installere systemet Huldt & Lillevik Lønn 5.0 Installere systemet Innholdsfortegnelse Innholdsfortegnelse Installere Lønn 5.0... 3 Krav til maskin og operativsystem... 3 Forberede installasjonen... 3 Installere database...

Detaljer

Akseptansetest for mottak PLO-meldingen: Orientering om tjenestetilbud

Akseptansetest for mottak PLO-meldingen: Orientering om tjenestetilbud Akseptansetest for mottak PLO-meldingen: Orientering om tjenestetilbud Meldingsversjon: Standard for elektronisk kommunikasjon med pleie- og omsorgstjenesten, versjon 1.5, datert 30.06.2009 2 Akseptansetest

Detaljer

Vedlegg Brukertester INNHOLDFORTEGNELSE

Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester... 1 Testrapport Wireframe... 2 1. INTRODUKSJON... 2 1.1 Systemoversikt... 2 1.2 Meningen med testen... 2 2 TESTPLAN... 2 2.1 Funksjoner som

Detaljer

S y s t e m d o k u m e n t a s j o n

S y s t e m d o k u m e n t a s j o n S y s t e m d o k u m e n t a s j o n Monitorering av produksjonsløyper ved Nasjonalbiblioteket - Project BAKE Utarbeidet av: Einar Wågan Kristian Akerhei Studium: Informasjonssystemer Innlevert: 26.5.2015

Detaljer

2. Beskrivelse av installasjon av SQL Server 2005 og hvordan lage databasen som trengs av administrasjonsprogrammet:

2. Beskrivelse av installasjon av SQL Server 2005 og hvordan lage databasen som trengs av administrasjonsprogrammet: Workaround for DFS Administrasjonssystem og Windows Vista NB! Dette er IKKE en installasjon av systemet, men en måte for å få det til å virke på Windows Vista. Denne veiledningen er laget for litt avanserte

Detaljer

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case?

Use case modellen. Use case modellering i analysefasen. Hva er en Aktør? Hva er et Use case? 1/15/2004 1 Use case modellen Use case modellering i analysefasen Metode for å identifisere og beskrive de funksjonelle kravene til et system Kapittel 3 i UML Distilled Kapittel 8 i Gurholt og Hasle Kirsten

Detaljer

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen

Hensikten med denne delen av kurset. Objektets egenskaper. Objektorientering hva er det? Best practises ved programvareutvikling. Kravspesifikasjonen Hensikten med denne delen av kurset Objektorientert systemutvikling Rational Unified Process (RUP) Gurholt og Hasle kap. 6 UML Distilled kap. 2 Å lære modellerings- og designprinsipper og øve opp teknikker

Detaljer

Kortversjon av brukerdokumentasjon Solman

Kortversjon av brukerdokumentasjon Solman Kortversjon av brukerdokumentasjon Solman For fullstendig versjon se brukerdokumentasjon i Solman. Første gangs pålogging Opprette sak fra SAP HR Opprette sak fra Solman Legge ved vedlegg Hente opp sak

Detaljer

1 Kodegenerering fra Tau Suiten

1 Kodegenerering fra Tau Suiten Kodegenerering fra Tau Suiten For å generere Javakode eller en annen form for programmeringskode ut i fra Tau suiten, er det visse ting som må være utført.. En UML modell må eksistere og være korrekt.

Detaljer

Brukerdokumentasjon. Webservices og webklient for kodeverk/ kodeverdi verifisering

Brukerdokumentasjon. Webservices og webklient for kodeverk/ kodeverdi verifisering Brukerdokumentasjon Webservices og webklient for kodeverk/ kodeverdi verifisering Innholdsfortegnelse... 3... 3... 3... 3... 4... 4... 4... 4... 8... 9... 10!... 10 "... 11 # $... 11 1. Om systemet 1.1.

Detaljer

Installasjons Guide for esam

Installasjons Guide for esam Krav til hardisken for PC (Laptop og Desktop PC) Pentium 4 eller høyere USB 2.0, min. 2 porter tilgjengelige (i nærheten av hverandre) Internet tilkopling må være tilgjengelig Opperasjonssystem: Windows

Detaljer

Akseptansetest for mottak av PLO-meldingen: Helseopplysninger ved søknad

Akseptansetest for mottak av PLO-meldingen: Helseopplysninger ved søknad Akseptansetest for mottak av PLO-meldingen: Helseopplysninger ved søknad Meldingsversjon: Standard for elektronisk kommunikasjon med pleie- og omsorgstjenesten, versjon 1.5, datert 30.06.2009 2 Akseptansetest

Detaljer

Kravspesifikasjon. Vedlegg A

Kravspesifikasjon. Vedlegg A Vedlegg A Kravspesifikasjon Dette dokumentet beskriver krav til applikasjonen som skal designes i prosjektet Nettverksbasert applikasjonsovervåking. Det beskrives her både krav til selve applikasjonen

Detaljer

Krav. Beskriver tjenestene produktet skal håndtere Kravene kan testes

Krav. Beskriver tjenestene produktet skal håndtere Kravene kan testes Krav og terminologi Krav Et utsagn som gjelder produktet vi skal teste og evaluere. Vi skal vurdere graden av sannhet i kravet opp mot funksjonen i produktet Funksjonelle krav Beskriver tjenestene produktet

Detaljer

Manual for å oppgrade TS 1000 fra:

Manual for å oppgrade TS 1000 fra: Manual for å oppgrade TS 1000 fra: Versjon 4.xx til versjon. 5.02 F01 04.02.2011 Første versjon TKi FK Rev. Dato: Beskrivelse: Utarbeidet Sign. Kontrollert Sign INNHOLD 1 GENERELT OM OPPGRADERING TIL VERSJON

Detaljer

Kommuneforlaget Avvikshåndtering Administratordokumentasjon Versjon 2.1.0 Table of Contents

Kommuneforlaget Avvikshåndtering Administratordokumentasjon Versjon 2.1.0 Table of Contents Table of Contents Tildel utildelte avvik... 2 Tildel forfalte avvik...3 Søk etter bruker... 4 Opprett lokal bruker...5 Endre lokal bruker... 6 Endre avviksbehandler for bruker... 7 Synkroniser brukerinformasjon

Detaljer

Akseptansetest for mottak PLO-meldingen Orientering om tjenestetilbud

Akseptansetest for mottak PLO-meldingen Orientering om tjenestetilbud Akseptansetest for mottak PLO-meldingen Orientering om tjenestetilbud Meldingsversjon: Standard for elektronisk kommunikasjon med pleie- og omsorgstjenesten, versjon 1.4, datert 20.02.2008 Akseptansetest

Detaljer

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås,

System integration testing. Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, System integration testing Forelesning Systems Testing UiB Høst 2011, Ina M. Espås, Innhold Presentasjon Hva er integration testing (pensum) Pros og cons med integrasjonstesting Når bruker vi integration

Detaljer

Spesifikasjon av Lag emne

Spesifikasjon av Lag emne Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Fra krav til objekter Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use Cases) o Objektdesign Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Detaljer

4.1. Kravspesifikasjon

4.1. Kravspesifikasjon 4.1. Kravspesifikasjon Dette delkapittelet beskriver nærgående alle deler av systemet, hvordan det er tenkt ferdigutviklet med fokus på oppdragsgivers ønsker. 4.1.1. Innledning Informasjon om hvordan kravspesifikasjonens

Detaljer

Øving 1c: Egenrefleksjon

Øving 1c: Egenrefleksjon Tilbake Øving 1c: Egenrefleksjon Antall svarpersoner: 19 1. Matrisespørsmål Vi skal nå fokusere på læremålene. Du skal tenke aktivt gjennom om du har klart å oppfylle læremålene eller ikke. Velg OK dersom

Detaljer

Eksamen i fag TDT4140 Systemutvikling. 6. juni, 2006 kl 0900-1300

Eksamen i fag TDT4140 Systemutvikling. 6. juni, 2006 kl 0900-1300 Side 1 av 10 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: 27. juni, 2006 Eksamen

Detaljer

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004

PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 PROSJEKTPLAN FOR INF [4 3]120-PROSJEKT: PROJECT HOSPITAL 2004 VERSJON: PROSJEKTPLAN (1.0) 24. SEPTEMBER, 2004 prosjektplan.doc GRUPPE 12 PROSJEKTPLAN: PROSJEKTLEDELSE: USE CASE: KVALITETSSIKRING: ANDRÉ

Detaljer

INF2120 Prosjektoppgave i modellering. Del 1

INF2120 Prosjektoppgave i modellering. Del 1 INF2120 Prosjektoppgave i modellering Del 1 Håkon Ulvestad haakonu@ifi.uio.no Jonas Winje jonaw@ifi.uio.no Amaia Santacoloma amaiac@ifi.uio.no Rakel Johnsen rakelj@ifi.uio.no Våren 2006 Innledning Prosjektoppgaven

Detaljer

TERA System Quick Start Guide (Norsk)

TERA System Quick Start Guide (Norsk) TERA System Quick Start Guide (Norsk) 1. Pakk ut drivere fra Driver Installation Tool.zip filen slik at du får en mappe \Driver Installation Tool\... 2. Hvis du har en 64bit operativt system kjør installasjon

Detaljer

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk Produktdokumentasjon Madison Møbler Administrasjonsside og Nettbutikk 1 1. Forord 1.1 Dokumentasjonen Dette er en teknisk dokumentasjon på produktet som er utviklet. Denne er tiltenkt personer med teknisk

Detaljer

Gruppe 23. Rapport D2, MMI. Prototypen. Tilstandsdiagrammet til prototypen ser slik ut: Designet på prototypen er som under.

Gruppe 23. Rapport D2, MMI. Prototypen. Tilstandsdiagrammet til prototypen ser slik ut: Designet på prototypen er som under. Rapport D2, MMI Prototypen Tilstandsdiagrammet til prototypen ser slik ut: Designet på prototypen er som under. Man lager en ny avtale ved å trykke på knappen add event oppe i høyre hjørne. For å komme

Detaljer

Huldt & Lillevik Lønn 5.0. Installere systemet

Huldt & Lillevik Lønn 5.0. Installere systemet Huldt & Lillevik Lønn 5.0 Installere systemet Innholdsfortegnelse Innholdsfortegnelse Installere Lønn 5.0... 3 Krav til maskin og operativsystem... 3 Forberede installasjonen... 3 Installere database...

Detaljer

INF5120 - Oblig 2. Hour Registration System (HRS)

INF5120 - Oblig 2. Hour Registration System (HRS) INF5120 - Oblig 2 Hour Registration System (HRS) 1 av 40 1 Innholdsfortegnelse 1 Innholdsfortegnelse... 2 2 Innholdsfortegnelse for figurer... 3 3 Hour Registration System (HRS)... 4 3.1 Introduksjon...

Detaljer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer Fra krav til objekter Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer INF1050--1 Dagens forelesning o Kort repetisjon av kravspesifikasjon med UML Hva skal systemet gjøre? UML: Bruksmønstermodeller (Use

Detaljer

Feilsøking i BO. Olav Syse, konsulent. Jan Terje Hansen, service manager. Be business intelligent

Feilsøking i BO. Olav Syse, konsulent. Jan Terje Hansen, service manager. Be business intelligent Feilsøking i BO Olav Syse, konsulent Jan Terje Hansen, service manager Hovedfokus: Business Intelligence 900 ansatte i Norge, Sverige, Danmark, Finland, Estland, Latvia, Litauen og Polen 135 ansatte i

Detaljer

SQL Server guide til e-lector

SQL Server guide til e-lector LES LETTERE, LES RASKERE, FÅ LESELYST! SQL Server guide til e-lector Innhold 1 Innledning... 2 2 SQL Express 2008 R2 installasjon... 2 3 Etter installasjon... 4 3.1 SQL Express... 4 3.1.1 Nettverksoppsett

Detaljer

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Testrapport 1 INNHOLDSFORTEGNELSE 1 INNHOLDSFORTEGNELSE... 1 2 Innledning... 2 3 Formål med testing... 3 3.1 Funksjonalitet...

Detaljer

Use case drevet design med UML

Use case drevet design med UML Use case drevet design med UML Bente Anda 26.09.2005 23.09.04 INF3120 1 I dag Domenemodeller System sekvensdiagrammer Operasjonskontrakter GRASP patterns Designmodeller med sekvens- og klassediagram 26.09.05

Detaljer

Brukerveiledning. For importapplikasjon til Naturbase. Versjon 17. mars 2015

Brukerveiledning. For importapplikasjon til Naturbase. Versjon 17. mars 2015 Brukerveiledning For importapplikasjon til Naturbase Versjon 17. mars 2015 Innhold 1. Innledning... 2 1.1 Rutiner for å legge data inn i Naturbase... 2 1.2 Leveranseinstrukser... 3 2. Om leveranse av data

Detaljer

Akseptansetest av mottak Rekvirering av medisinske tjenester Medisinsk biokjemi

Akseptansetest av mottak Rekvirering av medisinske tjenester Medisinsk biokjemi Akseptansetest av mottak Rekvirering av medisinske tjenester Meldingsversjon: versjon 1.4, datert 20.05.2005 2 Akseptansetest av mottak Rekvirering av medisinske tjenester Innholdsfortegnelse 1. Revisjonshistorikk...

Detaljer

Løsningsforslag til Case. (Analysen)

Løsningsforslag til Case. (Analysen) Løsningsforslag til Case (Analysen) Dette er en skisse til løsning av Case et med bussinformasjonssystemet. Jeg kaller det en skisse fordi det på den ene siden ikke er noe fasitsvar og fordi løsningen

Detaljer

Installasjonsveiledning Future

Installasjonsveiledning Future Installasjonsveiledning Future Maskinkrav: Operativsystemer CPU/Prosessor RAM/Minne Ledig diskplass Internett tilgang Nettverk Windows 2008r2, Windows 7 Business/Professional/Ultimate. Windows 8, windows

Detaljer

Steg 1: Installasjon. Steg 2: Installasjon av programvare. ved nettverkstilkoblingen på baksiden av kameraet. Kameraet vil rotere og tilte automatisk.

Steg 1: Installasjon. Steg 2: Installasjon av programvare. ved nettverkstilkoblingen på baksiden av kameraet. Kameraet vil rotere og tilte automatisk. Innhold Steg 1: Installasjon... 3 Steg 2: Installasjon av programvare... 3 Steg 3. Oppsett av wifi, email varsling og alarm... 5 Steg 4: Installasjon og oppsett av mobil app... 8 Steg 5: Installasjon og

Detaljer

AGENDA. En produktiv arbeidsplass Ja, derfor Office 365 Hege Line Arnstein Andreassen. Office 365 del 2. Avslutning. Marie Johansen, Microsoft

AGENDA. En produktiv arbeidsplass Ja, derfor Office 365 Hege Line Arnstein Andreassen. Office 365 del 2. Avslutning. Marie Johansen, Microsoft AGENDA En produktiv arbeidsplass Ja, derfor Office 365 Hege Line Arnstein Andreassen Office 365 del 1 Marie Johansen, Microsoft PAUSE Office 365 del 2 Marie Johansen, Microsoft Avslutning Hege Line Eiliv

Detaljer

PC-AXIS-2006. Brukerveiledning for tabelluttak og bearbeiding av data

PC-AXIS-2006. Brukerveiledning for tabelluttak og bearbeiding av data PC-AXIS-2006 Brukerveiledning for tabelluttak og bearbeiding av data 04.01.2007 Innledning Nyheter i PC-Axis 2006 Nyhet i PC-Axis 2006 - En funksjon for innspilling av aktiviteter gjordt i PC-Axis som

Detaljer

INTEGRASJONSGUIDE BP CODE Check Point R75.x R76

INTEGRASJONSGUIDE BP CODE Check Point R75.x R76 BRUKERVEILEDNING INTEGRASJONSGUIDE BP CODE Check Point R75.x R76 ÅPEN Versjon: 1.2 Versjonsdato: 30.07.2013 Buypass AS Nydalsveien 30A, PO Box 4364 Nydalen Tel.: +47 23 14 59 00 E-mail: kundeservice@buypass.no

Detaljer

Paul Hinsch. MICADO AS Utviklet MapBasic applikasjoner i 10 år. Registreringsknapper og Objektdialog

Paul Hinsch. MICADO AS Utviklet MapBasic applikasjoner i 10 år. Registreringsknapper og Objektdialog Brukerdefinerte registreringsknapper og objektdialog Paul Hinsch MICADO AS Utviklet MapBasic applikasjoner i 10 år Paul Hinsch MICADO AS 2011 Brukere klarer ikke alltid selv å styre hvilket kartlag data

Detaljer

1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen

1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen Kravspesifikasjon 1 Inledning 1.1 Presentasjon Tittel Informasjonsplattform for NorgesGruppen Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen Periode 3. Januar 14. Juni Gruppemedlemmer

Detaljer

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester.

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester. 1 Forord Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg prosjektets rammer

Detaljer

Før du starter, del 2

Før du starter, del 2 1 Før du starter I Windows må du sørge for at tekst og andre elementer er satt til å vises normalt 100%. Visma Global støtter ikke zooming, da vil noen elementer forsvinne fra programmet og ikke fungere.

Detaljer

Din verktøykasse for anbud og prosjekt

Din verktøykasse for anbud og prosjekt Veiledning Serverinstallasjon 14.03.2013 Din verktøykasse for anbud og prosjekt 2013 CITEC AS v/sverre Andresen Side 1 av 27 Innholdsfortegnelse 1 INNLEDNING 3 2 DATABASEINSTALLASJON (SQL SERVER 2008)

Detaljer

Inspeksjon Brukermanual

Inspeksjon Brukermanual 2013 INNHOLD Inspeksjon Brukermanual Denne applikasjonen lar deg enkelt inspisere utstyr som er plassert i Utstyrsportalen. Inspeksjon Onix AS 10/4/2013 0 Side INNHOLD INNHOLDSFORTEGNELSE Page # INTRODUKSJON...

Detaljer

Enbruker-installasjon

Enbruker-installasjon Veiledning Enbruker-installasjon Mars 2016 Din verktøykasse for anbud og prosjekt 2016 Powel AS Side 1 av 28 Innholdsfortegnelse 1 INNLEDNING 3 2 DATABASEINSTALLASJON 3 2.1 SIKKERHETSKOPI 3 2.2 INSTALLASJON

Detaljer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesten Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesting Formell testing med hensyn til brukerbehov, krav, og forretningsprosesser som utføres for å avklare om et system oppfyller

Detaljer

Hvordan komme i gang med ArchiMate? Det første modelleringsspråket som gjør TOGAF Praktisk

Hvordan komme i gang med ArchiMate? Det første modelleringsspråket som gjør TOGAF Praktisk Hvordan komme i gang med ArchiMate? Det første modelleringsspråket som gjør TOGAF Praktisk Logica 2012. All rights reserved No. 3 Logica 2012. All rights reserved No. 4 Logica 2012. All rights reserved

Detaljer

VMware Horizon View Client. Brukerveiledning for nedlasting, installasjon og pålogging for fjerntilgang

VMware Horizon View Client. Brukerveiledning for nedlasting, installasjon og pålogging for fjerntilgang VMware Horizon View Client Brukerveiledning for nedlasting, installasjon og pålogging for fjerntilgang Introduksjon Fjerntilgang er blitt oppgradert til en bedre og mer moderne løsning. Programmet er identisk

Detaljer

Bruksanvisning for Diabetesdagboka

Bruksanvisning for Diabetesdagboka Bruksanvisning for Diabetesdagboka Introduksjon Diabetesdagboka er et selvhjelpsverktøy for deg som har diabetes, utviklet av Nasjonalt senter for samhandling og telemedisin (NST). Diabetesdagboka gir

Detaljer

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006 Forstudierapport Magne Rodem og Jan-Erik Strøm 18. juni 2006 Innhold 1 Introduksjon 3 2 Bakgrunn for prosjektet 3 2.1 Beskrivelse av problemer og behov........................... 3 2.2 Kort om dagens systemer................................

Detaljer

Prosjektstyring med Projectfronter (En innføring i grunnleggende Projectfronter-funksjonalitet)

Prosjektstyring med Projectfronter (En innføring i grunnleggende Projectfronter-funksjonalitet) Olav Dæhli: 06.10.05 Prosjektstyring med Projectfronter (En innføring i grunnleggende Projectfronter-funksjonalitet) Fronters systemer består av tre sentrale moduler, Classfronter, Teamfronter og Projectfronter

Detaljer

notater Gule lapper Mine Et praktisk eksempel med objekter IT2 Læreplansmål Gløer Olav Langslet Sandvika VGS

notater Gule lapper Mine Et praktisk eksempel med objekter IT2 Læreplansmål Gløer Olav Langslet Sandvika VGS Mine notater Gløer Olav Langslet Sandvika VGS Et praktisk eksempel med objekter Vi kjenner alle til korktavlen med gule lapper. Vi henger opp en lapp for at vi selv eller andre skal huske eller bli minnet

Detaljer

Bedriftspraksis Høgskolen i Østfold, ITD35014. 01.12.2014 Halden Nicklas Alexander Gresholdt Eltvik

Bedriftspraksis Høgskolen i Østfold, ITD35014. 01.12.2014 Halden Nicklas Alexander Gresholdt Eltvik Bedriftspraksis Høgskolen i Østfold, ITD35014 01.12.2014 Halden Nicklas Alexander Gresholdt Eltvik Innhold Tiny-mesh... 4 Oppgave i faget bedriftspraksis... 5 Bedriftsoppgave... 5 Kravspesifikasjon...

Detaljer

Intentor Helpdesk - Installasjon Step #3: Microsoft Reporting Services

Intentor Helpdesk - Installasjon Step #3: Microsoft Reporting Services Intentor Helpdesk - Installasjon Step #3: Microsoft Reporting Services Dokumentasjon levert av: Prosjekt: Norsk Data Senter AS Installasjon av Intentor Helpdesk Norsk Data Senter AS e-post info@nds.no

Detaljer

Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no

Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no Obligatorisk oppgave 1 INF-3200 12. oktober 2003 Tor-Eirik Bakke Lunde torebl@stud.cs.uit.no Oppgavebeskrivelse: Designe og implementere en distribuert ray-tracing applikasjon, med basis i kontroller-

Detaljer

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet.

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet. Produktrapport Forord Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet. Dataansvarlig eller supporter trenger informasjon om

Detaljer

Akseptansetest av mottak Elektronisk epikrise - Den gode epikrise

Akseptansetest av mottak Elektronisk epikrise - Den gode epikrise Akseptansetest av mottak Elektronisk epikrise - Den gode epikrise Meldingsversjon: 1.1 datert 23.09.2006 Akseptansetest av mottak Epikrise 2 Innholdsfortegnelse 1. REVISJONSHISTORIKK... 3 2. AKSEPTANSETEST

Detaljer

En enkel lærerveiledning

En enkel lærerveiledning En enkel lærerveiledning ~ 1 ~ Innhold INNLEDNING... 3 Hva?... 3 Hvorfor?... 3 INN- og UTLOGGING... 4 Innlogging... 4 Utlogging... 5 Lærerinnlogging/-utlogging... 5 OUTLOOK / EPOST... 6 Skrive epost...

Detaljer

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634 Forprosjekt Presentasjon Gruppe 19: Event-planlegger Andreas Berglihn s169991 Harald R. Svendsen s127142 Gruppe Gruppe 19 Andreas Berglihn, s169991 Harald R. Svendsen s127142 Oppgave Eventplanlegger Utvikle

Detaljer

Installasjons veiledning for QuickNG SuperService integrasjon

Installasjons veiledning for QuickNG SuperService integrasjon Installasjons veiledning for QuickNG SuperService integrasjon OKTOBER 2012 REV 0.3 Oppsett av SuperService Log på SuperService online: https://login.ifmsystems.com/default.aspx Du må ha en bruker fra SuperService

Detaljer