Fellesprosjektet Gruppe 205
|
|
- Arvid Brekke
- 8 år siden
- Visninger:
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.
Fellesprosjekt: gruppe 214
Fellesprosjekt: gruppe 214 Innholdsliste Use case diagrammer...3 Scenario 1 - Registrere prosjekt...3 Scenario 2 - Registrere erfaringer...4 Scenario 3, 4, 5 - Lese og kommentere erfaringer...5 Klassediagram...6
DetaljerEksamen 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
DetaljerD2 - 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= 5 personer 5 laptops /m java lunsjpenger -Ressurser- -Arbeidsoppdeling- Hva Timer Ansvar Lete frem relevant informasjon fra uoversiktlig og spredd informasjon
DetaljerUse case modellering
Use case modellering Metode for å identifisere og beskrive de funksjonelle kravene til et system. Bente Anda 21.09.2004 1 Modellering i INF3120 Fordypning i objekt-orientert analyse og design Bygger på
DetaljerTestrapport 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
DetaljerOppgave 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.
DetaljerEksamen 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
DetaljerInnholdsfortegnelse INNHOLDSFORTEGNELSE... 2 REVISJONSOVERSIKT...4 INTRODUKSJON MED FORUTSETNINGER... 5
1 Innholdsfortegnelse INNHOLDSFORTEGNELSE... 2 REVISJONSOVERSIKT...4 INTRODUKSJON MED FORUTSETNINGER... 5 FRA LEVERANSE 1 (GRUPPE 2)...5 TILLEGG I FORUTSETNINGER... 5 REVIDERT UTGAVE AV SPESIFIKASJON FRA
DetaljerVedlegg 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
DetaljerTestrapport. 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
DetaljerLykke 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
DetaljerKTN1 - 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
DetaljerLocalBank 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...
DetaljerTestrapport 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
DetaljerForord Dette er testdokumentasjonen skrevet i forbindelse med hovedprosjekt ved Høgskolen i Oslo våren 2010.
TESTDOKUMENTASJON Forord Dette er testdokumentasjonen skrevet i forbindelse med hovedprosjekt ved Høgskolen i Oslo våren 2010. Dokumentet beskriver hvordan applikasjonen er testet. Dokumentet er beregnet
DetaljerGruppe KTN2 innlevering. Endringer gjort siden KTN1:
Gruppe 210 - KTN2 innlevering Endringer gjort siden KTN1: - Sekvensdiagram forenklet. Fjernet en del unødvendige sekvenser med portnr. Nå viser det veldig enkelt og greit gangen i tilkobling, sending av
DetaljerEksamen 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:
DetaljerSystem Dokumentasjon. Team2. Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk
System Dokumentasjon Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk System Dokumentsjon 23/04/2018 Systemutvikling og dokumentasjon/ia4412
DetaljerKandidat 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
DetaljerSystemutvikling - oppsummering. Alexander Nossum blog.eksplisitt.net 22. mai 2006
Systemutvikling - oppsummering Alexander Nossum alexander@nossum.net blog.eksplisitt.net 22. mai 2006 INNHOLD 2 Innhold 1 Utviklingsprosessmodeller 3 1.1 Fossefall/waterfall................................
DetaljerLæ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
DetaljerGruppe 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
DetaljerUML 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
DetaljerI 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
DetaljerBrukerdokumentasjon 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
DetaljerTESTRAPPORT... 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
DetaljerTESTRAPPORT - PRODSYS
TESTRAPPORT - PRODSYS PRODSYS-DATASYSTEM FOR ÅS PRODUKSJONSLAB AS GRUPPE 12 CHRISTOPHER CONRADI STEFFEN DIEDRICHSEN ROMAN KOVALENKO INFORMASJONSTEKNOLOGI, INGENIØRUTDANNINGEN, HØYSKOLEN I OSLO 1. FORORD
DetaljerAdministrering 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...
DetaljerBrukerdokumentasjon 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Ø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
DetaljerBle 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.
DetaljerVEDLEGG 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...
DetaljerUse 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,
DetaljerVårt system kan kjøres ved å skrive. STUD1 konto fredo 37 (holdeplass)
1 Vårt system kan kjøres ved å skrive STUD1 konto fredo 37 (holdeplass) Holdeplass er frivillig. Dersom man kun sender linjenr finner systemet den nærmeste holdeplassen. Systemet returnerer de 3 neste
DetaljerProsjektoppgave: 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
DetaljerRequirements & Design Document
Requirements & Design Document Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk SRD 03/04/2018 Systemutvikling og dokumentasjon/ia4412
DetaljerSvarskjema for kurset 'Databaser' - evalueringsrunde 2 - Antall svar på eval: 13
Kurs: Databaser(10stp) Faglærer: Edgar Bostrøm Dato: 05.05.2009 1. Hvilke forventningen hadde du til kurset på forhånd? At det skulle være vanskelig og mye å gjøre, men at det også ville være spennende
DetaljerOptimalJ-kurs UIO Oppsummering av kurset. De ulike modellene egenskaper og formål
OptimalJ-kurs UIO 2004 Agenda Time 1: Oppsummering av kurset Time 2: De ulike modellene egenskaper og formål Team Development med OptimalJ Domain Patterns Egenutviklede transformasjoner (krever Architect
DetaljerUKE 11 UML modellering og use case. Gruppetime INF1055
UKE 11 UML modellering og use case Gruppetime INF1055 Hva skal vi i dag? Analyse og design - kapittel 5 og 7 UML modellering Ukesoppgaver 3: Modellering av krav UML UML Kompetansemål Modellering av krav
DetaljerForelesning IMT Mars 2011
Forelesning IMT2243 31. Mars 2011 Tema: forts. arkitektur og OOD (ObjektOrientert Design) Eksempler på arkitekturvurderinger Yummy Inc., BUSTA, Tidligere studentprosjekter Prosjekt del 3 Designfasen Forventninger
DetaljerUniversitetet i Oslo Institutt for informatikk. Eskild Busch. UML hefte
Universitetet i Oslo Institutt for informatikk Eskild Busch UML hefte 6. desember 2000 Innhold Dette heftet tar for seg deler av UML som er sentralt i kurset IN29. Use case-, sekvens-, tilstand- og klassediagrammer,
DetaljerProduktrapport Gruppe 9
Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette
Detaljer2. 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
DetaljerKunden 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
DetaljerTestdokumentasjon. Testdokumentasjon Side 1
Testdokumentasjon Testdokumentasjon Side 1 1. Innledning Dette er en testrapport som er laget for å teste applikasjonene for ios og Android plattformer. Den vil være delt opp i 4 deler. Den første delen
DetaljerTestsituasjon Resultat Kommentar. Fungerer som det skal!
Test- rapport Testsituasjon Resultat Kommentar Test av PHP-variablene. Sjekke om de er riktig deklarert, og om de kommer med fra form til database Alle variablene som skal leses fra konfigurasjonssiden,
DetaljerSystem 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
DetaljerTeam2 Requirements & Design Document Værsystem
Requirements & Design Document Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk SRD 22/01/2018 Systemutvikling og dokumentasjon/ia4412
DetaljerEksamen i fag SIF8018 Systemutvikling. Fredag 25. mai 2001 kl
Side av 9 NTNU Norges teknisk-naturvitenskapelige universitet BMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist:. juni Eksamen i fag SIF808
DetaljerRessursallokering. Grunnlag for beregning av arbeidskapasitet
Ressursallokering Formålet med ressursallokering er å maksimalisere dine medarbeideres utnyttelsesgrad, ved å gi god oversikt over ansattes arbeidsbelastning. Ressursallokering gjør det mulig for deg å
DetaljerProsjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store. Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson
PROSJEKTGRUPPE 1 MGT SOFTWARE LEVERANSE 4 NY FUNKSJONALITET (ENDELIG) Prosjektgruppen: Gjermund Gartmann Tommy Jansson Margrethe Store Prosjektledelse: Margrethe Store Kvalitetssikring: Tommy Jansson Dato:
DetaljerKrav. 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
Detaljer20.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
DetaljerChiCMS 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
DetaljerMARE NOSTRUM. Del 2 Kravspesifikasjon
MARE NOSTRUM Del 2 Forord Kravenes hensikt og utforming Kravene i kravspesifikasjonen utformet slik at de skal imøtekomme oppdragsgivers krav, ønsker og spesifikasjoner på best mulig måte. Hensikten med
DetaljerPatron Driven Acquisitions (PDA) Brukerstyrt innkjøp
Patron Driven Acquisitions (PDA) Brukerstyrt innkjøp Dato: 2015-06-16 Roller For å kunne jobbe med PDA i Alma, må du ha en av følgende roller: Purchasing Operator Purchasing Manager Hvordan fungerer PDA
DetaljerEksamen i fag TDT4140 Systemutvikling. Tirsdag 27. mai 2004 kl
Side 1 av 12 NTNU Norges teknisk-naturvitenskapelige universitet BOKMÅL Fakultet for fysikk, informatikk og matematikk Institutt for datateknikk og informasjonsvitenskap Sensurfrist: 22. juni Eksamen i
DetaljerManual 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
DetaljerGruppe 43. Hoved-Prosjekt Forprosjekt
Gruppe 43 Hoved-Prosjekt Forprosjekt Mobil Applikasjon Utvikling HiOA Bacheloroppgave forprosjekt våren 2017 Presentasjon Gruppen består av: Gebi Beshir Ole-Kristian Steiro Tasmia Faruque s182414 s189141
DetaljerINF 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
DetaljerProMed. Brukermanual for installasjon og bruk av mobiltelefon eller SMS og nett for sending av SMS direkte fra. for Windows
Side 1 av 9 Brukermanual for installasjon og bruk av mobiltelefon eller SMS og nett for sending av SMS direkte fra ProMed for Windows Kundeoppfølging og Administrasjon Versjon 1.7 23.10.2009 Litt om sending
DetaljerDel - leveranse Del 2. Inf 2120 fredag Gruppe 1 Knut Johannes Dahle
Del - leveranse Del 2 Inf 2120 fredag 29.4 Gruppe 1 Knut Johannes Dahle AV Catrine Myhre (catrinem@ifi.uio.no) Mehdi Zare (mehdiz@ifi.uio.no) Odd Christer Brovig (oddcb@ifi.uio.no) Christer Aas (chrisva@ifi.uio.no)
DetaljerProsjektoppgave: Bildedatabase. TDT4145 Datamodellering og Databasesystemer. Våren 2007
Prosjektoppgave: Bildedatabase TDT4145 Datamodellering og Databasesystemer Våren 2007 NB! Kun for de som ikke tar fellesprosjektet. Innledning I løpet av de siste årene har det blitt stadig mer vanlig
DetaljerGJENNOMGANG UKESOPPGAVER 7 REPETISJON
GJENNOMGANG UKESOPPGAVER 7 REPETISJON INF1050 V16 KRISTIN BRÆNDEN DAGENS TEMA Oppgaver hentet fra tidligere eksamensoppgaver om temaene vi har gått gjennom til nå DAGENS PLAN Gjennomgang av oppgaver Repetisjon
DetaljerDistributed object architecture
Forelesning IMT2243 6. April 2010 Tema: forts. arkitektur og design av programvare Prosjektstatus Programvarearkitektur Oppsummering fra før påske Distribuerte objektarkitektur MDA - Model Driven Architecture
DetaljerPresentasjon 2 Gruppe 2 Oppgave 2 Oppdragsgiver 2. Sammendrag 3. Dagens situasjon 3 ServiceNow 3 Coop 3. Mål og rammebetingelser 3 Mål 3 Teknologier 4
Forprosjektrapport Bachelorprosjekt for gruppe 8, våren 2017 Innholdsfortegnelse Presentasjon 2 Gruppe 2 Oppgave 2 Oppdragsgiver 2 Sammendrag 3 Dagens situasjon 3 ServiceNow 3 Coop 3 Mål og rammebetingelser
DetaljerEn liten oppskrift på hvordan jeg installert og fikk Xastir til å virke sånn at jeg ble synlig i APRS verden.
En liten oppskrift på hvordan jeg installert og fikk Xastir til å virke sånn at jeg ble synlig i APRS verden. La meg med en gang si at jeg er rimelig grønn i Linux verden så dere får bære over med meg
Detaljer4.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
DetaljerEn 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...
DetaljerAkseptansetest av mottak Dialogmelding
Akseptansetest av mottak Dialogmelding Meldingsversjon: 1.0 datert 08.07.2005 Akseptansetest av mottak Dialogmelding 2 Innholdsfortegnelse 1. REVISJONSHISTORIKK... 3 2. AKSEPTANSETEST FOR MOTTAK AV DIALOGMELDINGEN...
DetaljerInstallasjons 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
DetaljerConference 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
DetaljerBrukerveiledning 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-
DetaljerOppgave 1 (Opprett en database og en tabell)
Oppgave 1 (Opprett en database og en tabell) 1) I «Object Explorer» (i «SQL Server Management Studio»), høyreklikk over Databases : 1 2 2) Skriv så databasenavnet og klikk OK: 3) Plasser så kursoren på
Detaljeror*dtrosnilt,'+'.q':'
%,u lbnvaston.*.'. or*dtrosnilt,'+'.q':' JavaBin 5. mai Vidar Alvestad - Skatteetaten Inspirert av: Noen eksempler er hentet fra boken. Jeg tror Mr. Feathers tilgir meg dersom du kjøper boken ;-) Hva er
DetaljerJon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad
Forprosjektrapport Presentasjon Tittel: Oppgave: Infront SSO Utvikle en Single Sign-on løsning for Infront Periode: 8/1-2013 28/5-2013 Gruppemedlemmer: Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini
DetaljerKravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo,
Kravspesifikasjon Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 12.01.2013 Public 2013 Aker Solutions Page 1 of 7 Table of Contents Forord... 3 Om bakgrunnen... 3 Presentasjon...
DetaljerStikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client.
Stikkord: Java EE, EJB, JSF, JPA, SWT, klient/tjener, Glassfish server, Application Client. Studenter: Magnus Skomsøy Bae, Marius Eggen, Magnus Krane Klasse: 3ING, Systemutvikling Produserer redaksjonelle
Detaljernotater 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
DetaljerSoftware Development Plan. Software Development Plan. Forum / Nettverkssamfunn Team 2
Forum / Nettverkssamfunn Team 2 1 Innholdsfortegnelse 1 Introduksjon... 3 2 Team & Organisering... 3 3 Brainstorming, tanker og utførelse... 4 3.1 Bruker Registrering og metoder... 4 3.2 Generering av
DetaljerBruksanvisning 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
DetaljerVerden. Steg 1: Vinduet. Introduksjon
Verden Introduksjon Processing Introduksjon Velkommen til verdensspillet! Her skal vi lage begynnelsen av et spill hvor man skal gjette hvilke verdensdeler som er hvor. Så kan du utvide oppgava til å heller
Detaljer!!!!!!!!!!!! !!!!!!!!!!! WP-WATCHER WORDPRESS SIKKERHET
WP-WATCHER WORDPRESS SIKKERHET WP-WATCHER BACKUP - SIKKERHETSKOPIERING «Hei Jeg oppdaterte en plugin på siden min og nå kommer jeg ikke inn på siden min i det hele tatt. Kan du hjelpe meg?» «Hjelp Jeg
DetaljerAkseptansetesten. 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
Detaljer1 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.
DetaljerHensikten 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
DetaljerPROSJEKTPLAN 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É
DetaljerPlanlegging 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
DetaljerAGENDA. 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
DetaljerKravspesifikasjon. Forord
Forord Kravspesifikasjonen skal gi en oversikt og forståelse over det planlagte systemets funksjonalitet. Dokumentet skal gi både utviklere og oppdragsgivere innblikk i hvordan og hva systemet skal levere.
DetaljerTestdokumentasjon. Gruppe 9
Innholdsfortegnelse 1.Innledning... 3 2.Test av systemet... 3 3.Test med brukermanual av utenforstående... 7 4.Konklusjon... 8 2 1.Innledning Testdokumentasjonen er et dokument som beskriver vår endelige
DetaljerIrc-klient. Eigil Obrestad. Morten H Singstad. Kristofers Celms
Irc-klient Eigil Obrestad Morten H Singstad Kristofers Celms Komme i gang Når programmet starter, blir du møtt av ett ganske tomt brukergrensesnitt. Det første du må gjøre for å komme i gang, er å koble
DetaljerUML-Unified Modeling Language
UML-Unified Modeling Language Use case realisering Designmodellering 21.01.2004 Kirsten Ribu Use Case diagram Klassediagram Oppførselsdiagrammer: Sekvensdiagram Kollaborasjonsdiagram Tilstandsdiagram Aktivitetsdiagram
DetaljerAPI: Application programming interface, eller programmeringsgrensesnitt
API: Application programming interface, eller programmeringsgrensesnitt 1 Interface 1: Cockpit i F16 2 Interface 2: GUI GUI: Graphical user interface The first Graphical User Interface on the XeroxStar
DetaljerForord Dette er brukerdokumentasjonen skrevet i forbindelse med hovedprosjekt ved Høgskolen i Oslo våren 2010.
BRUKERDOKUMENTASJON Forord Dette er brukerdokumentasjonen skrevet i forbindelse med hovedprosjekt ved Høgskolen i Oslo våren 2010. Dette dokumentet beskriver hvordan å applikasjonen, og er skrevet for
DetaljerAkseptansetest av mottak Rekvirering av medisinske tjenester Radiologi
Akseptansetest av mottak Rekvirering av medisinske tjenester Meldingsversjon: v1.5 datert 01.12.2008 Akseptansetest av mottak Rekvirering av medisinske tjenester 2 Innholdsfortegnelse 1. Revisjonshistorikk...
DetaljerSQL 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
DetaljerVedlegg LMC intranett
Vedlegg LMC intranett H12D02 Jarl-Håvard Holen Ole-Martin Larsen Fredrik Sethne-Andersen André Ritari Vedlegg 1 Resultater av kortsortering. Kortsortering Bruker 1, Salg: Kortsortering Bruker 2, Teknisk:
DetaljerOppsummering. Thomas Lohne Aanes Thomas Amble
Oppsummering Thomas Lohne Aanes Thomas Amble 14.11.04 Kapittel 2: Data Modell Mål: Data som skal brukes av applikasjonen blir spesifisert på en formell og likevel intuitiv måte. Resultat: Vi får et konseptuelt
Detaljer