Produktdokumentasjon

Størrelse: px
Begynne med side:

Download "Produktdokumentasjon"

Transkript

1 Produktdokumentasjon Presentasjon Tittel Oppgave Teknostorage - Lagersystem Et lagersystem som på enkel måte kan registrere varer inn og ut fra lager. Periode 3. januar 2012 til 11. juni 2012 Gruppemedlemmer Abdullah Arshid Atia Iqbal Kenny Nguyen Sharjeel Javaid Tony Vu Pham Prosjektgruppe 25 Veileder Oppdragsgiver Kontaktperson Eva Hadler Vihovde Statsbygg May Liss Urang

2 1. Forord Denne dokumentasjonen er tilrettelagt for sensor, oppdragsgiveren og alle som har interesse for prosjektet. Produktdokumentasjonen gir en detaljert beskrivelse av webapplikasjonen. Av den grunn vil det forekomme enkelte tekniske uttrykk, og vi forventer at leseren har kjennskap til disse. Produktdokumentasjonen omfatter følgende områder: Endelige produktet Datastruktur og virkemåte Klassediagram Sekvensdiagram Use case Hver delrapport kan leses som et selvstendig dokument, av den grunn vil enkelte kapitler være felles for prosess og produktdokumentasjon. Dette gjelder kapittel 3 og 4. Dersom leseren velger å begynne på prosessdokumentasjonen, kan disse kapitlene hoppes over i produktdokumentasjonen. Hvis man ikke har anledning til å kjøre programmet, kan det være nyttig å se gjennom brukerveiledningen. Denne gir et innblikk i programmets funksjonalitet. For å lese om hva systemet gjør og hvordan brukeren samhandler med det, kan leseren gå til kapittelet Use Case på punkt 7. Der vil leseren få innblikk av brukstilfellemodell som visualiserer kravene til systemet.

3 2. Innholdsfortegnelse Produktdokumentasjon Forord Innholdsfortegnelse Innledning Bakgrunn for prosjektet Bedriftens situasjon Mål og rammebetingelser Oppdragsgiver Endelige produktet Lagersystem Oppbygging og funksjonalitet Planleggingsverktøy Use Case modell Detaljerte Use Case beskrivelser Datastruktur og virkemåte ER-modellering Sekvensdiagram Klassediagram Drifting/Implementering av systemet Konklusjon Kilder... 21

4 3. Innledning Dette kapitlet er en begynnelse for å kjenne til bakgrunnen for prosjektet og hvordan situasjonen i bedriften var før prosjektet ble iverksatt. Innledningen består av fire underkapitler; bakgrunn for prosjektet, bedriftens situasjon, mål og rammebetingelser og oppdragsgiver Bakgrunn for prosjektet Gruppen startet tidlig med å kontakte flere bedrifter for hovedprosjekt, det førte til at gruppen hadde flere utvalg av prosjekter. Blant annet fikk gruppen tilbud om å utvikle for Glasspaper og Omega A/S. Ettersom ett av gruppemedlemmene er ansatt i Statsbygg som IT-medarbeider (i IT-support avdelingen, Teknotorget), fikk gruppen tilbud om å kunne utføre hovedprosjektet for dem. Etter idémyldringer og diskusjoner rundt valget av oppgaven, kom vi frem til at Statsbyggs oppgave var den som interesserte oss mest. For å få grundigere detaljer om oppgaven, hadde gruppen møte med kontaktpersonen for Statsbygg. Vi fikk positiv inntrykk og var villig til å gjøre en god innsats i prosjektet Bedriftens situasjon Teknotorget har per idag ikke et elektronisk system som holder rede på varer som kjøpes inn og leveres ut til ansatte i Statsbygg. Det har ført til at Teknotorget ikke har oversikt over antall enheter som utleveres, og som er på lager til enhver tid. Teknotorget ønsker av den grunn å holde rede på deres lagerbeholdning i form av en web-basert applikasjon. Applikasjonen skal være en effektiv og strukturert løsning for brukerne og som kun er tilgjengelig over Statsbyggs intranett. Applikasjonen skal være enkel for Teknotorget å vedlikeholde i ettertid, og være laget i tilknytning til Statsbygg sin PC plattform, det vil si Windows 7 med støtte for 32 og 64 bits. Eksempel på varer som finnes på Teknotorgets lager er datamus og tastatur, minnebrikker, eksterne harddisker etc. Disse varene deles fortløpende ut til brukere ved behov, og varer må etterbestilles når det er tomt på lager Mål og rammebetingelser Målet med oppgaven var å utvikle en webapplikasjon, hvor ansatte i Teknotorget på en enkel måte kan registrere varer inn og ut av lager, og samtidig se hvilke produkter som de har inne på lager. Dette hjelper dem med å finne ut når de må gjøre nye innkjøp. Lagersystemet skal kun brukes av ansatte på Teknotorget.

5 Kravene var målbevisste, realistiske og tidsbegrenset. Teknotorget fremmet ønsket funksjonalitet, og i samråd med dem har vi kommet frem til kravene. Dette er blitt gjort for å komme frem til en god og effektiv løsning. I korte trekk har applikasjonen følgende funksjonalitet: Nye varer blir registrert enkelt inn på lager Varer som deles ut til bruker blir enkelt registrert ut av lager Når en vare når sitt minimumsantall, varsler systemet om at det må bestilles opp mer varer av denne typen Det er enkelt å fjerne eller opprette nye varekategorier i systemet Tar ut rapporter (spørringer) på enkelte varer Det har ikke vært strengt med rammebetingelser, men noen av rammebetingelsene er blitt bestemt på forhånd av oppdragsgiveren, for eksempel bruk av plattform og tidsbegrensninger. Rammekravene som var pålagt fra Teknotorget, var at applikasjonen skulle ha en database i bunn og at applikasjonen skulle være webbasert. Disse var de overordnede rammekravene. Oppkobling mot Visual Studio med database i bunn, var en god kombinasjon til å løse denne oppgaven på best mulig måte. Utover det hadde gruppen frie tøyler til å utarbeide en selvvalgt løsning beskrevet i tilknytning med mål og rammebetingelser over. Det var fritt fram hvilket programmeringsspråk og utviklingsverktøy som skulle benyttes for å utvikle applikasjonen Oppdragsgiver Statsbygg er Norges største statlige eiendomsaktør i sivil sektor med en eiendomsportefølje på rundt 2,7 millioner kvadratmeter til en verdi av ca. 30 milliarder kroner. De driver stedplanlegging, byggfaglig rådgivning, eiendomsforvaltning og styring av byggeprosjekter. Statsbygg er en forvaltningsbedrift med 830 ansatte, med hovedkontoret i Oslo og fem regionskontor. Statsbygg er statens sentrale rådgiver i bygge- og eiendomssaker, byggherre, eiendomsforvalter og eiendomsutvikler. Statsbygg har som mål å være statens førstevalg. Statsbygg er en statlig forvaltningsbedrift. Statsbyggs oppgave er å tilby gode og funksjonelle lokaler til statlige virksomheter, og å realisere vedtatte samfunnspolitiske mål i forhold til arkitektur, statlige planinteresser, kulturminnevern og miljø. IKT avdelingen på hovedkontoret består av ca. 30 ansatte fordelt på tre grupper; IT Support (Teknotorget), IT Drift og IT System.

6 4. Endelige produktet Lagersystem Dette kapittelet har til hensikt å gi leseren et lite innblikk i produktets oppbygging og virkemåte, slik at man vet hva arbeidet har resultert i, før man leser de neste kapitlene. Applikasjonen lagersystem er beregnet for ansatte i Teknotorget hos Statsbygg. Avdelingen Teknotorget har ingen elektronisk system som holder rede på varer som kjøpes inn og leveres ut til ansatte i Statsbygg. Applikasjonen skal være effektiv løsning for brukerne. Figur 1: Applikasjons virkemåte Figuren ovenfor viser virkemåten til applikasjonen på følgende vis: 1. Brukeren lager webforespørsel 2. Server sender forespørselen til databasen 3. Resultatet sendes tilbake til serveren 4. Server bygger siden og returnerer resultatet til den endelige klienten Applikasjonen har blitt utviklet i flere språk som CSS,.Net, XHTML, CSS, JavaScript. For utvikling av webapplikasjonen er det brukt Visual Studio 2010 med programmeringsspråk C#. Det er store muligheter for endringer, og er tilrettelagt for eventuelle utvidelser. Applikasjonen har en database i bunn, det betyr at den henter alle dataene fra en SQL database. For å se koblingen i databasene med alle attributtene, finner dere nærmere informasjon om dette i produktdokumentasjonen. Hensikten med applikasjonen er at ansatte på en enkel måte skal klare å registrere varer inn og ut av lager. Applikasjonen viser enkelt oversikten over alle varer på forsiden til applikasjonen. For å beskrive varen, viser den varenavn, merkenavn, antall, kategori og status. Disse kan sorteres i alfabetisk rekkefølge eller minst til høyest antall. Det vil si at brukeren kan for eksempel velge å sortere varenavnene etter kategori eller status (figur 2). Statusen har logiske farger, dersom varen er på lager er statusen oppført som ikke på lager med rødt skrift, og varene som er på lager har status oppført som på lager med grønt skrift.

7 Figur 2. Sorter varenavnene etter status Hovedmenyen er plassert øverst på forsiden med sort farge og hvit skrift. Hovedmenyen består av følgende funksjoner; oversikt, kategorier, siste hendelser, rapporter og administrering (figur 3). Figur 3. Hovedmeny Søking er en sentral funksjon på hovedsiden av applikasjonen. Brukeren kan søke enten ved å skrive inn teksten selv, eller velge merkenavn og kategorinavn ved nedtrekningsmeny (figur 4). Endre varedata endrer varenavnet, merkenavn, kategori, minimumsantall på en spesifisert vare. Endre varedata er et logisk symbol på forsiden. Dersom en vare blir slettet fra systemet, viser det melding om at varenavnet er blitt slettet (figur 5). Figur4. Søkefunksjon

8 Figur 5. Varenavnet er blitt slettet Funksjonen kategorier viser liste over kategoriene. Ved å gå inn på funksjonen kategorier kan brukeren velge vis varer, da blir varene vist i den valgte kategorien. Funksjonen siste hendelser viser alle hendelsene som har skjedd til enhver tid. Per hendelse er beskrevet med dato og klokkeslett, status på antall ut eller inn og beskrivelse av varen (figur 6). Figur 6. Siste hendelser Funksjonen administrering er ikke for en administrator. I denne applikasjonen har alle brukere like rettigheter. Administrering grupperer underfunksjoner (figur 7). Logg inn funksjonen er koblet mot Active Directory (AD), der alle brukerne i Statsbygg er lagt inn. Brukerne blir lagt inn i AD systemet av ansatte i Teknotorget. Applikasjonen vår starter med at brukeren må logge seg inn med initialer og passord (figur 8). Figur7. Administrering siden Figur 8. Logg inn

9 Tilgang til systemet styres igjennom AD (Active Directory). AD brukes til å styre rettigheter og tilganger til de forskjellige systemene i Statsbygg. Det blir opprettet en gruppe i AD som den enkelte må være medlem av for å få tilgang til systemet. Primært skal denne gruppen bestå av de ansatte på Teknotorget. Som medlem i gruppen vil man få tilgang til applikasjonen og kan logge inn med brukernavn og passord, som er identisk med Windows passord på pc. Ivaretakelse av sikkerhet er viktig fra Statsbygg sin side. De har gode rutiner for ivaretakelse av sikkerhet, og jobber kontinuerlig med hindring av uautoriserte adganger til systemer, applikasjoner, servere m.m. For å kunne gjennomføre prosjektoppgaven var det viktig at vi fulgte Statsbygg sine krav om bruk av AD for autorisering av tilgang til systemet og applikasjonen. Applikasjonen inneholder en e-post funksjon som sender e-post varsel for mer bestilling av varer som har gått tomt. Blir ikke varen fylt på innen 14 dager, blir det tilsendt en purr for påminnelse. Denne e-posten blir tilsendt til alle ansatte på Teknotorget (figur 9). Figur 9. Varsel for bestilling av varer Funksjonen rapport tilbyr utskrift av rapport over en vare. Filen genereres i PDF format. Brukeren er pliktig til å fylle inn varenavn i tekstfeltet selv, og velge datoen (figur 10). Figur 10. Rapport funksjon Valideringen av inputfelt er essensielt for å kontrollere at data som blir satt inn samsvarer med datafeltene i databasen. Brukeren får opp feilmeldinger slik at de kan rette opp eventuelle feil. Vi har både med klient og server validering (figur 11).

10 Figur 11. Validering Detaljert beskrivelse av programmet finner dere i produktdokumentasjonen og brukerveiledningen. 5. Oppbygging og funksjonalitet Lagdeling sikrer at koden blir mer robust, og derved forebygger feil. Koden vil også bli lettere å vedlikeholde og utvide. Model-view-controller (MVC) er et designmønster anvendt i programvareutvikling. Et MVC-program deler programmet opp i data (model) og brukergrensesnitt (view), slik at endringer i brukergrensesnittet ikke vil ha noen innvirkning på hvordan dataene håndteres. Det bruker en mellomliggende komponent for å kommunisere mellom view og model controller. Model Modell: Modellaget inneholder verdier for applikasjonen. Verdiene ville vanligvis ligget direkte i presentsjonslaget, men for å gjøre kontrollerlaget uavhengig av presentasjonslaget blir det benyttet en generell modell mellom. View presentasjonslaget: Presentasjonslaget er det laget som sluttbrukeren ser og kan manipulere. Dette laget kan hente og sette verdier i modellen samt be kontrollerlaget utføre funksjoner. Controller Kontroller: Hensikten med dette laget er å gjøre all virksomhetslogikk i tillegg til databaselogikk. I tillegg til dette vil dette laget styre hvilke view s som skal kalles. Kontrollerlaget tar seg av alle funksjoner og er selve kjernen i applikasjonen. Kontrollerlager kjenner ikke til presentasjonslaget og kan dermed lett settes sammen med andre presentasjonslag. Grunnen til at vi valgte MVC var for å få en oversiktelig og strukturert programmering, samt dele oppbygging av webapplikasjon inn i MVC (Model view control) struktur.

11 Figur12. Overordnet MVC-arkitektur 6. Planleggingsverktøy For å få et effektivt og strukturert prosjekt, bestemte gruppen å bruke et utviklingsverktøy ved å følge en modell, for å gjøre utviklingsprosessen enklere. Etter å ha diskutert om flere utviklingsmodeller, falt valget på å sette opp UP (Unified Process). En prosess beskrives av hvem (utviklere) som gjør hva (artefakter), hvordan (aktiviteter) og når (arbeidsflyten) (1). Oversikt over prosessene i UP er slik: IDEFASE UTDYPNINGS- FASE KONSTRUKSJON OVERGANG Figur 13. Unified prosess 7. Use Case modell For å vise hva systemet skal gjøre og for hvem, lagde vi en brukstilfellemodell (Use Case Model). Et brukstilfelle er, som navnet tilsier, en isolert funksjon, eller en prosess, som tilfredsstiller et krav hos brukeren, aktøren. Modellen består av et antall brukstilfeller (Use

12 Case) og inneholder i tillegg til diagrammet også en tekstlig beskrivelse. Vi har brukt brukstilfellemodellen til å visualisere kravene til systemet, og benyttet det som vedlegg til en utviklingskontrakt med oppdragsgiver. Use case beskrivelsen er viktig for å beskrive hva et system gjør, men det beskriver ikke hvordan systemet gjør det. Den beskriver hendelsesflyten ved hjelp av tekst, slik at det er lett for en utenforstående å forstå. Figur 14. Use case modell som beskriver systemets hovedfunksjonalitet.

13 7.1.1 Detaljerte Use Case beskrivelser Registrere ny vare Hovedaktør: Bruker Trigger: Brukeren ønsker å registrere ny vare Forbetingelser: Bruker har tilgang til systemet og er logget inn Sluttbetingelser: Bruker har lagt en ny vare i registeret Hovedscenario og trinn (suksess): 1. Bruker trykker på Legg til ny vare knappen 2. Bruker fyller alle felt med informasjon om varen 3. Bruker fyller ut antall varer som legges inn 4. Bruker trykker lagre knappen 5. Systemet oppdaterer databasen Utvidelser (unntak/feiltilfeller): 2a Bruker fyller ikke ut alle obligatoriske felt (feiltilfelle) 2b Vare med samme navn ligger allerede i systemet (feiltilfelle) 2c Bruker fyller ut ugyldig datatype i feltene (feiltilfelle) 3a Bruker fyller inn ugyldig tall 5a Systemet krasjer/overbelastes (feiltilfelle) Tabell 1: Detaljert use case beskrivelse

14 Hovedaktør: Bruker Trigger: Brukeren ønsker å oppdatere vare Forbetingelser: Sluttbetingelser: Hovedscenario og trinn (suksess): Oppdatere vare Bruker har tilgang til systemet og er logget inn Bruker har oppdatert en vare 1. Bruker angir varenavn eller varenummer på varen 2. Bruker trykker på Oppdater vare knappen 3. Bruker fyller nødvendig informasjon som f.eks. antall 4. Bruker trykker på lagre knappen 5. Systemet oppdaterer databasen Utvidelser (unntak/feiltilfeller): 1a Systemet finner ikke varen(feiltilfelle) 2a Bruker bommer på knappen og trykker på X i stedet. 3a Feil datatype blir skrevet inn(feiltilfelle) 5a Systemet krasjer/overbelastes (feiltilfelle) Tabell 2: Detaljert use case beskrivelse Hovedaktør: Bruker Trigger: Brukeren ønsker å slette vare Forbetingelser: Sluttbetingelser: Hovedscenario og trinn (suksess): Slette vare Bruker har tilgang til systemet og er logget inn Bruker har slettet en vare 1. Bruker angir varenavn eller varenummer på varen 2. Bruker trykker på slett vare knappen 3. Systemet oppdaterer databasen Utvidelser (unntak/feiltilfeller): 1a Systemet finner ikke varen(feiltilfelle) 3a Systemet krasjer/overbelastes (feiltilfelle) Tabell 3. Detaljert use case beskrivelse

15 Hovedaktør: Bruker Trigger: Brukeren ønsker å logge inn Forbetingelser: Sluttbetingelser: Hovedscenario og trinn (suksess): Systemet er oppe Logge inn Brukeren har logget seg inn 1. Brukeren skriver inn brukernavn og passord 2. Brukeren trykker på logg inn 3. Systemet sjekker om brukernavn og passord er riktig 4. Systemet logger inn brukeren Utvidelser (unntak/feiltilfeller): 1b Brukeren fyller ikke ut feltene 3a Brukeren skriver inn feil brukernavn eller passord Tabell 4. Detaljert use case beskrivelse Use case modellen og beskrivelsen finner du også i kravspesifikasjonen. 8. Datastruktur og virkemåte Dette kapittelet beskriver databasestrukturen og virkemåten i applikasjonen. Den forteller oss hvilke klasser applikasjonen har blitt bygd opp av, og tilknytningen til disse. Sekvensdiagram, og klassediagram er en del av kapittelet ER-modellering Et E/R-diagram er en grafisk framstilling av strukturen til en database, men beskrivelsen er abstrakt i den forstand at vi ikke tar stilling til hvordan data er representerert fysisk. E/R står for Entity/ Relationship. E/R blir brukt i tidlig fase under utvikling av databaser. Diagrammene består av entiteter, attributter og forhold, som løselig svarer til henholdsvis tabeller, kolonner og fremmednøkler i en relasjonsdatabase (2). Entiteter viser hvordan de er knyttet sammen til andre entiteter, og hvilke entiteter som var viktig i applikasjonen vår. Før vi startet prosjektet var det bestemt at vi skulle ta i bruk Oracle databasen, men på grunn av flere årsaker og oppsett av databasen, ble det bestemt i samråd med Statsbygg at SQL database også var relevant. Endelige avgjørelsen ble at vi satte opp en SQL database på skolens server. Figurene under ER-modell og attributtene. SQL er et språk utformet for arbeid med databaser. Ved hjelp av SQL kan vi blant annet lage utvalgsspørringer, som henter ut data fra tabeller. Som databasebruker betyr dette at man ikke blir låst til et bestemt verktøy.

16 Se databasestrukturen nedenfor: Figur 15. Databasestruktur

17 8.1.2 Sekvensdiagram Det finnes to typer interaksjonsdiagrammer, sekvensdiagram og samarbeidsdiagram. Vi velger sekvensdiagram fordi den visualiserer klassesamarbeidet best. Sekvensdiagram og klassediagram sørger for at det er konsistens mellom diagrammene. Den er nyttig for den viser tydelig meldingers struktur og sekvens. Spesielt viser de konstruksjoner som er oversentralisert, hvor et objekt gjør alt arbeidet. Sekvensdiagrammet brukes også til å se atferden mellom flere objekter innen samme Use Case. Vi har valgt ut to sekvensdiagrammer over prosjektet vårt; legg til vare og varehistorikk. Disse viser hendelsene innenfor diagrammet, og ansvarsfordelingen. Figur 16. Sekvensdiagram - Legg til vare

18 Figur 17. Sekvensdiagram Varehistorikk Klassediagram Klassediagram viser de objektene som inngår i problemdomenet. Med problemdomenet mener vi det domenet (området) som skal forbedres med et nytt informasjonssystem. Dette er det grunnleggende klassediagrammet som ligger til grunn for både datamodellering (ERdiagrammet) og for implementering. Operasjoner i tillegg til attributter skal være tatt med her. Dette utføres parallelt med utviklingen av det detaljerte sekvensdiagrammet og ofte selve programmeringen. I klassediagrammet ser vi ulike relasjoner mellom klassene.

19 Figur 18. Klassediagram over lagersystemet

20 8.1.4 Drifting/Implementering av systemet For å implementere systemet, er det nødvendig å ha en database i bunn, slik at alle data blir overført på den. Det er også nødvendig å ha en.net server, som databasen skal knytte seg opp mot. E-post funksjonen vil fungere hvis den blir knyttet mot Microsoft Outlook 2010, som Statsbygg bruker per i dag. Applikasjonen fungerer optimalt på alle nettlesere som Firefox, Internet Explorer, Opera, Google Chrome. I prosjektet ble nettleser firefox brukt mest. Firefox har egenskaper at den er rask, enkel, og svært utvidbar nettleser. Det er viktig at applikasjonen kjører uavhengig av nettleser. Dersom Statsbygg ønsker å bytte standardnettleseren, er det mulig å benytte applikasjonen. Valideringen er en del av applikasjonen. Valideringen av inputfelt er essensielt for å kontrollere at data som blir satt inn samsvarer med datafeltene i databasen. Vi har både med klient og server validering. Klientvalidering kjører på nettleser og bruker javascript til å sjekke om inputfeltene er av riktig type. Mens servervalidering vil for en siste gang sjekke at dataene som har blitt sendt er riktig, før det settes inn i databasen. Klientvalideringen er avhengig av at man har aktivert java på nettleseren for at den skal fungere, derimot servervalideringen vil slå til uansett. 9. Konklusjon Produktet er ferdigstilt og kan settes ut i drift. Det startet med at applikasjonen ble kjørt på skolens server. Dette var kun en midlertidig løsning fra Statsbygg sin side. Ettersom produktet ble ferdig, ble det tekniske og tidsmessige utfordringer fra oppdragsgiveren og dermed ble applikasjonen stående på skolens server. Med hensyn til kobling mot AD for innlogging i systemet, var det relevant å sette opp applikasjonen på Statsbygg sine egne servere. AD er en sentral katalogtjeneste som kjører på Statsbygg sine servere, for håndtering av brukere. Valget av teknologi gjorde at applikasjonen ble slik vi ønsket. Dette var de riktige avgjørelsene. Programvarene påførte ikke store endringer eller utfordringer, utenom valget av databasen. Kravet fra oppdragsgiveren var å bruke Oracle, men i samråd med Statsbygg ble vi enige om at SQL databasen ville gi en bedre innvirkning med hensyn til oppkobling mot Visual Studio. Arbeidet ble enklere, og vi var ganske godt kjent med SQL språket. Datastruktur i programmet ble løst med ER-modellene. Gruppen fikk bedre innblikk etter å ha diskutert og laget modellene. Entiteter og attributter i sammenheng med databasen, medførte utviklingen av applikasjonen mot databasen raskere. Attributtene ble allerede bestemt og skulle knyttes sammen i databasen. Designvalgene var ikke høyest prioritert i prosjektet vårt, men designvalgene ble likevel gjennomtenkt. Det var viktig at designen ikke skilte seg så veldig mye fra de tidligere applikasjonene i Statsbygg. Applikasjonene var omtrent på samme nivå som vi ønsket å

21 fremlegge vår applikasjon, det gjorde applikasjonen enda bedre. Oppdragsgiveren hadde ikke mange krav til applikasjonen, vi stod fritt til å lage designen på egenhånd, så lenge den var brukervennlig. Målet var å designe layouten så enkelt som mulig. Enkel design passet perfekt til temaet lagersystem. Dokumentasjonen var et godt virkemiddel for prosjektet. Det ble klarert hva vi ønsket, og samtidig var det positivt å se hvordan arbeidet ble utført. Ofte er det vanskelig å ha oversikt over hva gruppen gjør, og hvor langt de kommer med arbeidet. Ved hjelp av dokumentasjonen ble dette dekket. Dokumentasjonen er levende, og jobben er ikke ferdig før dokumentasjonen er oppdatert. Endringer skjedde ofte og ble dokumentert jevnlig. Fordelene er at endringene blir distribuert på et øyeblikk, og det blir også enkelt å sikre (backup). 10. Kilder (1) Systemutvikling - Applikasjoner og databaser av Thor E.Hasle s.94 (2) Systemutvikling - Applikasjoner og databaser av Thor E.Hasle s.153

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den

Detaljer

Teknostorage - Lagersystem. Et lagersystem som på enkel måte kan registrere varer inn og ut fra lager. 3. januar 2012 til 11.

Teknostorage - Lagersystem. Et lagersystem som på enkel måte kan registrere varer inn og ut fra lager. 3. januar 2012 til 11. 1 Brukerveiledning Presentasjon Tittel Oppgave Periode Gruppemedlemmer Prosjektgruppe Veileder Oppdragsgiver Kontaktperson Teknostorage - Lagersystem Et lagersystem som på enkel måte kan registrere varer

Detaljer

Testdokumentasjon Presentasjon

Testdokumentasjon Presentasjon Testdokumentasjon Presentasjon Tittel Oppgave Teknostorage - Lagersystem Et lagersystem som på enkel måte kan registrere varer inn og ut fra lager. Periode 3. januar 2012 til 11. juni 2012 Gruppemedlemmer

Detaljer

Produktrapport Gruppe 9

Produktrapport 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

Detaljer

Hovedprosjekt i teknologi, kunst og design ved Høgskolen i Oslo og Akershus Våren Gruppe 25

Hovedprosjekt i teknologi, kunst og design ved Høgskolen i Oslo og Akershus Våren Gruppe 25 1 Hovedprosjekt i teknologi, kunst og design ved Høgskolen i Oslo og Akershus Våren 2012 Gruppe 25 Tony Vu Pham Atia Iqbal Kenny Nguyen Sharjeel Javaid Abdullah Arshid 1 S i d e 2 Sluttdokumentasjon Presentasjon

Detaljer

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie SRD GLIS Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie Innholdsfortegnelse 1. Systemoversikt... 2 2. Tekniske krav... 3 2.1. Funksjonskrav og brukergrensesnitt spesifikasjon... 3 2.2. Begrensninger...

Detaljer

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 2 Hovedprosjekt 2014, Høgskolen i Oslo og Akershus 1 INNHOLD 2 Presentasjon... 2 2.1 Gruppen medlemmer... 2 2.2 Oppgave... 2 2.3 Oppdragsgiver... 2 2.4 Veileder... 2 3 Sammendrag...

Detaljer

System Dokumentasjon. Team2. Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk

System 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

Detaljer

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

SRD GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie SRD GLIS Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie Innholdsfortegnelse 1. Systemoversikt... 2 2. Tekniske krav... 3 2.1. Funksjonskrav og brukergrensesnitt spesifikasjon... 3 2.2. Begrensninger...

Detaljer

Bachelorprosjekt 2015

Bachelorprosjekt 2015 Bachelorprosjekt 2015 Høgskolen i Oslo og Akershus Tam Ha (s171513) Arslan Yousaf (s189135) Gabriel Noraker Alfarrustad (s161910) Eivind Lund (s180381) Phillip Padiernos Næss (s162951) Forprosjekt Prosjektets

Detaljer

Prosessdokumentasjon Presentasjon

Prosessdokumentasjon Presentasjon Prosessdokumentasjon Presentasjon Tittel Oppgave Teknostorage - Lagersystem Et lagersystem som på en enkel måte kan registrere varer inn og ut fra lager. Periode 3. januar 2012 til 11. juni 2012 Gruppemedlemmer

Detaljer

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1 KRAVSPESIFIKASJON Gruppe 2 Hovedprosjekt, Høgskolen i Oslo og Akershus Våren 2014 KRAVSPESIFIKASJON 1 CONTENTS 1. Forord... 3 2. Presentasjon... 3 2.1 Gruppens medlemmer... 3 2.2 Oppdragsgiver... 3 2.3

Detaljer

Team2 Requirements & Design Document Værsystem

Team2 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

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

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet Kravspesifikasjon Hovedprosjekt 2014 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Tittel: Oppgave: Gruppemedlemmer: Digitalt Helsekort for Gravide Utvikle en prototype

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

Kravspesifikasjon. 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, 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...

Detaljer

Requirements & Design Document

Requirements & 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

Detaljer

SRD. Software Requirements and Design GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie

SRD. Software Requirements and Design GLIS. Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie SRD Software Requirements and Design GLIS Cecilie Dortea Gløsmyr, Espen Buø og Henrik Lie Innholdsfortegnelse 1. Systemoversikt... 2 2. Tekniske krav... 3 2.1. Funksjonskrav og brukergrensesnitt spesifikasjon...

Detaljer

Entobutikk 3.TESTRAPPORT VÅR 2011

Entobutikk 3.TESTRAPPORT VÅR 2011 3.TESTRAPPORT VÅR 2011 1 DELKAPITTEL 1 FORORD Denne testrapport er skrevet i forbindelse med vårt hovedprosjekt ved Høgskolen i Oslo, ingeniørutdanning, våren 2011. Rapporten beskriver testingen av hele

Detaljer

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

Granitt Grafisk AS Kravspesifikasjon Gruppenr: 2011-12

Granitt Grafisk AS Kravspesifikasjon Gruppenr: 2011-12 1 av 6 1.Innledning 1.1Presentasjon Dato: 01.02.2011 Bacheloroppgave: Produktkalkyle for Granitt Grafisk AS Gruppenr: 11-12 Gruppemedlemmer: Pål Georg Dahl Myran Joakim Haneberg Johansen Michael Venables

Detaljer

TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS

TESTRAPPORT   Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS Medlemmer av gruppe 35: Joakim Larsen, s150070, 3AB Kristian Kjelsrud, s147787, 3IA Anastasia Poroshina, s140720, 3AB Prosjektperiode:

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

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer Kravspesifikasjon Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011 Gruppemedlemmer Adeel Yousaf Khan s141459 Mats Klingenberg Naustdal s148155 Nur M. Ahmed s148108 Thomas Wiborg s161335

Detaljer

1. Forord 2. Leserveiledning

1. Forord 2. Leserveiledning KRAVSPESIFIKASJON 1 1. Forord Hensikten med kravspesifikasjonen er at den skal fungere som et styringsdokument under prosessen og definere rammer og betingelser rundt hovedprosjektet. Den er utviklet etter

Detaljer

Forprosjektrapport for Agresso R&D Ansettelsessystem 31.01.07. Hovedprosjekt våren 2007. Skrevet av:

Forprosjektrapport for Agresso R&D Ansettelsessystem 31.01.07. Hovedprosjekt våren 2007. Skrevet av: Forprosjektrapport for Agresso R&D Ansettelsessystem Hovedprosjekt våren 2007 31.01.07 Skrevet av: Anders Hartvoll Ruud Christian Årving Leif Martin Næss Sahdia Fayyaz Moghal 1 Sammendrag Prosjektittel:

Detaljer

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 INNHOLDSFORTEGNELSE 1. PRESENTASJON 2. SAMMENDRAG 3. DAGENS SITUASJON 4. MÅL OG RAMMEBETINGELSER 5. LØSNINGER \ ALTERNATIVER 6. ANALYSE AV

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

3.3 Case 3: Opprette en bruker Case 4: Endre en bruker... 8

3.3 Case 3: Opprette en bruker Case 4: Endre en bruker... 8 Testdokumentasjon 1 Forord Denne rapporten omhandler testingen av systemet. Rapporten er først og fremst beregnet på sensor og intern veileder ved Høgskolen i Oslo, men kan gjerne leses av andre som måtte

Detaljer

Forprosjektrapport. Utvikle en plattform for digitalisering av foosballbord.

Forprosjektrapport. Utvikle en plattform for digitalisering av foosballbord. Forprosjektrapport Tittel Oppgave Periode Openfoos Utvikle en plattform for digitalisering av foosballbord. 3. januar til 15. juni Gruppemedlemmer Amir Ghoreshi Marcel Eggum Neberd Salimi Valentin Rey

Detaljer

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni.

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. KRAVSPESIFIKASJON Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. Prosjektgruppe: 27 Prosjektmedlem: Ole Almenning Stenhaug Veileder.

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

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet Produktrapport Hjelpemiddel portal for Parkinsonforbundet 1 Innhold: Forord ------------------------------------------------------------------------------------------------------2 Planlegging og arbeidsmetode

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

Del VII: Kravspesifikasjon

Del VII: Kravspesifikasjon 1 2 Forord Dette dokumentet inneholder retningslinjer for gruppen vår og beskrivelse av betingelsene for utviklingen av vårt prosjekt. Vår gruppe benyttet dette dokumentet som et styringsdokument for å

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

Oblig 5 Webutvikling. Av Thomas Gitlevaag

Oblig 5 Webutvikling. Av Thomas Gitlevaag Oblig 5 Webutvikling Av Thomas Gitlevaag For oppgave 1 og 2 skal dere levere en funksjonell webside på deres hjemmeområde. Dere skal også levere alle phps-filene slik at man for en hver side kan slenge

Detaljer

HTML5. Skjemaer på nettsider. Skjemaer med. Informasjonsteknologi 1 og 2. Gløer Olav Langslet Sandvika VGS

HTML5. Skjemaer på nettsider. Skjemaer med. Informasjonsteknologi 1 og 2. Gløer Olav Langslet Sandvika VGS Skjemaer med HTML5 Gløer Olav Langslet Sandvika VGS Leksjon 10 Informasjonsteknologi 1 og 2 Skjemaer på nettsider I denne leksjonen skal vi se litt nærmere på bruk av skjemaer på nettsider. Du har sett

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

Entobutikk 2.PRODUKTRAPPORT VÅR 2011

Entobutikk 2.PRODUKTRAPPORT VÅR 2011 2.PRODUKTRAPPORT VÅR 2011 1 DELKAPITTEL 1 FORORD Denne produktrapporten inneholder detaljer om produktet vi har utviklet samt programmessig oppbygning, illustrasjoner, diagrammer over produktet, funksjoner

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

Brukerveiledning for Vesuv

Brukerveiledning for Vesuv Brukerveiledning for Vesuv Innhold Pålogging... 3 Registrering av ny bruker... 3 Glemt passord... 4 Startsiden... 5 Nytt utbrudd... 6 Nedtrekksmenyer... 6 Obligatoriske felt... 7 Spørsmål vises og fjernes...

Detaljer

Presentasjon... 3. Sammendrag... 4. Dagens situasjon... 5. Mål og rammebetingelser... 5. Moduler... 6. Løsning og alternativer...

Presentasjon... 3. Sammendrag... 4. Dagens situasjon... 5. Mål og rammebetingelser... 5. Moduler... 6. Løsning og alternativer... Innholdsfortegnelse Presentasjon..................................................... 3 Sammendrag.................................................... 4 Dagens situasjon.................................................

Detaljer

Kravspesifikasjon. 1 Prosjektfakta. Medlemsregister for YXD-Kurdistan. Prosjektnummer: 07 09. Ernad Fajkovic

Kravspesifikasjon. 1 Prosjektfakta. Medlemsregister for YXD-Kurdistan. Prosjektnummer: 07 09. Ernad Fajkovic Kravspesifikasjon 1 Prosjektfakta Prosjekttittel: Medlemsregister for YXD-Kurdistan Prosjektnummer: 07 09 Gruppemedlemmer: Oppdragsgiver: Kontaktperson: Intern veileder: Asad Fattahi Ernad Fajkovic YXD-Kurdistan

Detaljer

Hovedprosjekt 2013. Gruppe 27. Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie

Hovedprosjekt 2013. Gruppe 27. Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie 2013 Hovedprosjekt 2013 Gruppe 27 Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie Innhold 1. Presentasjon... 2 2. Sammendrag... 2 3. Dagens Situasjon... 2 4. Mål og rammebetingelser...

Detaljer

CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA

CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA Sist oppdatert 18.02.2010 INNHOLD INNHOLD... 1 HVA ER CABINWEB... 2 HVA KAN DU BRUKE CABINWEB TIL?... 3 HVA ER NYTT I CABINWEB VERSJON 2.0...

Detaljer

Del IV: Prosessdokumentasjon

Del IV: Prosessdokumentasjon 1 2 Forord Dette dokumentet omhandler detaljert beskrivelse av vår arbeidsprosess gjennom hele perioden med prosjektet. Prosessdokumentasjonen er en viktig del av sluttrapporten, og er delt opp i følgende

Detaljer

Publiseringsløsning for internettsider

Publiseringsløsning for internettsider Publiseringsløsning for internettsider Hva er Edit? Edit er et verktøy for publisering og vedlikehold av nettsider. Tidligere har det å vedlikeholde en nettside vært en tungvinn prosess, men nå kan alle

Detaljer

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer...

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer... Side 1 1. Forord Dette dokumentet er en kravspesifikasjon og har blitt utarbeidet av arbeidsgiver og prosjektgruppen. Dokumentet består av ni kapitler. Det vil først bli presentert hvem prosjektgruppen

Detaljer

Studentdrevet innovasjon

Studentdrevet innovasjon Studentdrevet innovasjon Hovedprosjekt 2013 Høgskolen i Oslo og Akershus Forprosjektrapport av Gruppe 11 Karoline Sanderengen, Mona Isabelle Yari og Randi Ueland 25.01.2013 Studentdrevet innovasjon 9 Innhold

Detaljer

Bachelorprosjekt i informasjonsteknologi, vår 2017

Bachelorprosjekt i informasjonsteknologi, vår 2017 Bachelorprosjekt i informasjonsteknologi, vår 2017 Gruppe 29: Marthe Janson Skogen, s236357, Ingeniørfag - data Odd Einar Hoel, s236313, Ingeniørfag - data Forprosjektrapport Rapporten inneholder presentasjon,

Detaljer

INF1050 Systemutvikling

INF1050 Systemutvikling INF1050 Systemutvikling Krav til innlevering: Innleveringene skal ha: Forside med gruppenummer, dato, leveransenummer, navn på gruppemedlemmer med brukernavn og navn på prosjektet Forklarende overskrifter

Detaljer

Forprosjekt - Gruppe 12. Hovedprosjekt av

Forprosjekt - Gruppe 12. Hovedprosjekt av FORSIDE A V D E L I N G F O R I N G E N I Ø R U T D A N N I N G H Ø G S K O L E N I O S L O O G A K E R S H U S Forprosjekt - Gruppe 12 Hovedprosjekt av S AJ ID, OZAI RE (S 1711 9 7), S VEEN, S IMEN (S171208),

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Hensikten med en kravspesifikasjon er å gi et overblikk over programmets funksjonalitet og tilleggsfunksjoner, dette vil si både over de som er utviklet før prosjektstart, og de

Detaljer

InfoRed Publisering. - produktbeskrivelse. TalkPool WebServices Postboks Åneby

InfoRed Publisering. - produktbeskrivelse.  TalkPool WebServices Postboks Åneby InfoRed Publisering - produktbeskrivelse www.talkpool.no TalkPool WebServices Postboks 90 1484 Åneby InfoRed Produktbeskrivelse 2 Sammendrag InfoRed Publisering er produktet for å administrere en hel informasjonstjeneste,

Detaljer

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl Kravspesifikasjon HOVEDPROSJEKTETS TITTEL Bestillingssystem for frisørsalong PROSJEKTDELTAKERE Endre Gulbrandsen (s150690) DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl OPPDRAGSGIVER

Detaljer

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Sluttrapport Høgskolen i Oslo Student: Martin Oppegaard Gruppe: 07-12 Dato: 25. mai 2007 Veileder ved HIO: Eva Vihovde Oppdragsgiver: Bekk Consulting

Detaljer

Datamann Informasjonssystemer

Datamann Informasjonssystemer 1 Datamann Informasjonssystemer Brukerveiledning 2013 Datamann AS 2 3 DATAMANN INFORMASJONSSYSTEMER SYSTEMKRAV PC med Pentium eller høyere. Internettilgang med 1 Mbit/s eller høyere Internett Explorer

Detaljer

Prosjektoppgave våren 2007

Prosjektoppgave våren 2007 Prosjektoppgave våren 2007 Innledning Formålet med kurset er å bli i stand til å delta i utviklingen av informasjonssystemer. Dette innebærer: å kjenne til bruken av informasjonssystemer, å kjenne til

Detaljer

Entobutikk 1.KRAVSPESIFIKASJON VÅR 2011

Entobutikk 1.KRAVSPESIFIKASJON VÅR 2011 1.KRAVSPESIFIKASJON VÅR 2011 1 DELKAPITTEL 1 INNLEDNING Kravspesifikasjonen er svært nyttig sett i forhold til produktet vi ønsker å utvikle. Dokumentet regnes som et av de viktigste i hovedprosjektet

Detaljer

TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS. Dataingeniørutdanningen, Høgskolen i Oslo GRUPPE 15. Kenneth Ådalen. Vegard Gulbrandsen

TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS. Dataingeniørutdanningen, Høgskolen i Oslo GRUPPE 15. Kenneth Ådalen. Vegard Gulbrandsen TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS GRUPPE 15 Kenneth Ådalen Vegard Gulbrandsen Kien Trung Nguyen Dataingeniørutdanningen, Høgskolen i Oslo Våren 2009 2 S i d e FORORD I dette dokumentet tar

Detaljer

FORPROSJEKT KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK

FORPROSJEKT KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK 2017 FORPROSJEKT BACHELOROPPGAVE 2017 KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK PRESENTASJON OPPGAVE: Oppgaven er å lage en webapplikasjon som kan hjelpe bachelor

Detaljer

Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008

Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Forprosjekt Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Skrevet av Ole Myrbakken, Fadima Mohamoud, Orji Okoroafor, Karen Arrendondo Side 1 PRESENTASJON Prosjekt tittel: Prosjektperiode: MetaGen 7.jan

Detaljer

Forprosjekt for Accentures Overvåkningssystem

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

Detaljer

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften Kravspesifikasjon Presentasjon Hovedprosjektet gjennomføres ved Høgskolen i Oslo, avdelingen for ingeniørutdanning. Målet med oppgaven er å utvikle en online webshop for bestilling av postkasser. Dette

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

Kravspesifikasjon. 1. Innledning. Presentasjon. Innledning. Om bedriften. Bakgrunn for prosjektet

Kravspesifikasjon. 1. Innledning. Presentasjon. Innledning. Om bedriften. Bakgrunn for prosjektet Kravspesifikasjon Presentasjon Tittel: Oppgave: Backup for PDA/Smartphones Utvikle en applikasjon for PDA/Smartphones med funksjonalitet for backup av sms, mms, e-post, kontakter, kalender, bilder og dokumenter

Detaljer

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

KRAVSPESIFIKASJON DAGSPLANAPPLIKASJON FOR NETTBRETT. Gruppe 28 Hovedprosjekt våren 2015

KRAVSPESIFIKASJON DAGSPLANAPPLIKASJON FOR NETTBRETT. Gruppe 28 Hovedprosjekt våren 2015 KRAVSPESIFIKASJON Kravspesifikasjon er en beskrivelse av hvilke krav oppdragsgiver har til systemet som skal utvikles. Den fungerer som en kontrakt mellom oppdragsgiver og utviklere. DAGSPLANAPPLIKASJON

Detaljer

Arbeidsplan. Startfasen. Aktivitet Beskrivelse Ferdig Ansvarlig (Ressurser)

Arbeidsplan. Startfasen. Aktivitet Beskrivelse Ferdig Ansvarlig (Ressurser) Arbeidsplan En arbeidsplan er en måte å få oversikt over de ulike fasene i prosjektet. I arbeidsplanen har vi delt arbeidet i naturlige faser og detaljert disse med estimert tidsbruk. Hovedfasene er startfasen,

Detaljer

Huldt & Lillevik Ansattportal 2013-04-30. Ansattportal. Versjon 2013.2

Huldt & Lillevik Ansattportal 2013-04-30. Ansattportal. Versjon 2013.2 Ansattportal Versjon 2013.2 Innhold 1 Oppdatere til 2013.2... 2 2 Aktivere Microsoft.Net Rammeverk 4.0... 5 3 Ansattportalen kompatibel med flere nettlesere... 7 4 Timer Registrere pr uke... 7 5 Ny adgangsprofil

Detaljer

https://nhh.itslearning.com/

https://nhh.itslearning.com/ e-læringssystemet https://nhh.itslearning.com/ Sist oppdatert 08.09.2009 10:07 1 1. Hva er It s Learning? It's Learning er et e-læringssystem hvor du finner elektronisk informasjon om alle våre kurs/studier,

Detaljer

KRAVSPESIFIKASJON. Kristian Kjelsrud, s147787, 3IA Anastasia Poroshina, s140720, 3AB. Prosjektperiode: 4. januar mai 2010

KRAVSPESIFIKASJON. Kristian Kjelsrud, s147787, 3IA Anastasia Poroshina, s140720, 3AB. Prosjektperiode: 4. januar mai 2010 KRAVSPESIFIKASJON Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS Gruppemedlemmer: Joakim Larsen, s150070, 3AB Kristian Kjelsrud, s147787, 3IA Anastasia Poroshina, s140720, 3AB Prosjektperiode:

Detaljer

Brukerhåndbok CabinWeb Bruker

Brukerhåndbok CabinWeb Bruker Brukerhåndbok CabinWeb Bruker Applikasjon: CabinWeb Laget av: Delfi Data AS (www.delfi.no) Versjon 1.11 Dato 06.11.2006 Historie 1.1 Revisjon utgave 1.11 Lagt til Kartmodul Innledning CabinWeb er et system

Detaljer

Generell brukerveiledning for Elevportalen

Generell brukerveiledning for Elevportalen Generell brukerveiledning for Elevportalen Denne elevportalen er best egnet i nettleseren Internett Explorer. Dersom du opplever kompatibilitets-problemer kan det skyldes at du bruker en annen nettleser.

Detaljer

Forprosjektrapport Bacheloroppgave 2017

Forprosjektrapport Bacheloroppgave 2017 Forprosjektrapport Bacheloroppgave 2017 Chat Modul for Webnodes Content Management System Gruppe 32 Adam Asskali, Anmer Seif, Sara Khan 20.01.2017 Veileder G. Anthony Giannoumis Innholdsfortegnelse 1.Presentasjon

Detaljer

UKE 11 UML modellering og use case. Gruppetime INF1055

UKE 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

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

Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad

Jon 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

Detaljer

Dokument 1 - Sammendrag

Dokument 1 - Sammendrag Dokument 1 - Sammendrag Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Innholdsfortegnelse Sammendrag 1 1. Innledning 1 2. Om

Detaljer

Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008

Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008 Kravspesifikasjon Hovedprosjekt ved Høgskolen i Oslo Våren 2008 1.Forord I dette dokumentet skal vi gi et bildet av de kravene som er satt til prosjektet. Dokumentet er hovedsakelig beregnet som et styringsdokument

Detaljer

Stikkord: 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. 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

Detaljer

Brukermanual. Studentevalueringssystem

Brukermanual. Studentevalueringssystem Brukermanual Studentevalueringssystem 1 Forord 1.1 Forord Denne brukermanualen innholder beskrivelse av systemets funksjonalitet og introduserer systemet for brukeren. Brukermanualen er delt inn i tre

Detaljer

BRUKERMANUAL. Telsys Online Backup

BRUKERMANUAL. Telsys Online Backup BRUKERMANUAL Telsys Online Backup TELSYS AS - 06.08.2009 Innhold Generelt... 3 Kom i gang... 4 Installasjon av Telsys Online Backup Proff/Standard... 4 Start opp klienten for første gang!... 10 Logg inn...

Detaljer

Kravspesifikasjon. Forord

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

Detaljer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 207 Digitalisering av Sentralen UNG Gründer Gruppe 34 Kenneth Di Vita Jensen, s236745 Frank Arne Bjørkmann

Detaljer

Oppgave 1: Multiple choice (20 %)

Oppgave 1: Multiple choice (20 %) Oppgave 1: Multiple choice (20 %) For alle oppgavene gjelder at det bare er ett riktig svar. No Spørsmål Svar A Svar B Svar C Svar D 1 Kanban er et eksempel på: Prosess Software prosess Prosess modell

Detaljer

Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no

Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no Hovedprosjekt 2008 av Audun M. Solheim, student HIST/BAIN, audun@c2i.net Oppdragsgiver:Bjørg Minnesjord Solheim, bjorg@midt-svartdal.no

Detaljer

Kravspesifikasjonsrapport

Kravspesifikasjonsrapport Kravspesifikasjonsrapport JobCrawl Ledige jobber representert i kart for IBM Gruppe 9 Bachelorprosjekt ved Oslo Metropolitan University Gruppemedlemmer: Kim Smedsrud Chris-Thomas Lundemo Grenness Lars

Detaljer

Oppsummering. Thomas Lohne Aanes Thomas Amble

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

Utvikling av et nettbasert CMS med tilhørende nettsted for Axel Bruun Sport AS

Utvikling av et nettbasert CMS med tilhørende nettsted for Axel Bruun Sport AS Utvikling av et nettbasert CMS med tilhørende nettsted for Axel Bruun Sport AS Håkon Bogsrud Anders Høye Karlsen Alexander Borgen Saxevik Bacheloroppgave vår 2012 IT-støttet bedriftsutvikling Oppgavenummer:

Detaljer

Case Prosess Resultat Kommentar

Case Prosess Resultat Kommentar TimeStamp Hovedprosjekt ved HIOA Forord Dette dokumentet omhandler testing av systemet, og er først og fremst rettet mot sensor og intern veileder ved Høgskolen i Oslo. Rapporten gir en oversikt over hvilke

Detaljer

Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus. Forprosjektrapport. Bravo Booking App

Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus. Forprosjektrapport. Bravo Booking App Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus Forprosjektrapport Bravo Booking App 1 Presentasjon 2 1.1 Gruppe 2 1.2 Oppdragsgiver 2 1.3 Kontaktpersoner 2 1.4 Oppgave 3 2 Dagens

Detaljer

Informasjonsportalen

Informasjonsportalen Brukermanual Informasjonsportalen Aksjeservice versjon 2.0 Aksjeservice AS Kolbergveien 20 3121 Tønsberg / Munkedamsveien 68 0270 Oslo Forord Aksjeservice er en løsningsleverandør for ikke-børsnoterte

Detaljer

[GILJE SELSKAPSLOKALER]

[GILJE SELSKAPSLOKALER] 2013 Hovedprosjekt 2013 Gruppe 27 Kravspesifikasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie Kravspesifikasjon 1 Presentasjon 1.1 Innledning Dette prosjektet er et hovedprosjekt

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

1. Introduksjon. Glis 13/02/2018

1. Introduksjon. Glis 13/02/2018 SDP GLIS Espen Buø Innholdsfortegnelse 1. Introduksjon... 2 2. Gruppebeskrivelse og ansvarsområder... 3 3. Risikoanalyse... 4 4. Hardware og softwarekrav for brukeren... 5 5. Behov for prosjektet... 6

Detaljer

[GILJE SELSKAPSLOKALER]

[GILJE SELSKAPSLOKALER] 2013 Hovedprosjekt 2013 Gruppe 27 Kravspesifikasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie Kravspesifikasjon 1 Presentasjon 1.1 Innledning Dette prosjektet er et hovedprosjekt

Detaljer

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5 Testrapport Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 24.5.2013 Public 2013 Aker Solutions Page 1 of 5 Innledning I denne rapporten vil vi skrive om testingen som

Detaljer