Utarbeidet av. Jørgen Lundgren Martin Sagstuen Ole M. Grodås Espen Flydahl

Størrelse: px
Begynne med side:

Download "Utarbeidet av. Jørgen Lundgren Martin Sagstuen Ole M. Grodås Espen Flydahl"

Transkript

1 NORBUD Utarbeidet av Jørgen Lundgren Martin Sagstuen Ole M. Grodås Espen Flydahl

2 Innholdsfortegnelse 1. PROSJEKTPLAN MÅL OG RAMMER Bakgrunn Prosjektmål Rammer OMFANG Oppgavebeskrivelse / avgrensning PROSJEKTORGANISERING Ressurser og ansvarsforhold Øvrige roller og bemanning Valg av arbeidsmetode PLANLEGGING, OPPFØLGING OG RAPPORTERING Drøfting av overordnet utviklingsmetode RISIKOANALYSE GJENNOMFØRING Beslutningspunkt Milepæler KRAVSPESIFIKASJON USE CASE ANALYSE Use Case diagram Høy-nivå Use Case beskrivelse Detaljert Use Case beskrivelse Sekvensdiagram KONSEPTUELT KLASSEDIAGRAM KVALITETSMESSIGE KRAV Brukervennlighet Ytelse Pålitelighet Nøyaktighet Sikkerhet Vedlikeholdslettende krav Portabilitet Andre krav ARKITEKTUROVERSIKT LOGISK VINKLING PÅ SYSTEMET Lagdeling Konseptuelt klassediagram PROCESS VIEW Teknisk løsning: ordrebehandling Interaksjoner mellom prosessene ved ordrebehandling Teknisk løsning: oppdatering av posisjon Interaksjoner mellom prosessene ved oppdatering av posisjon DEPLOYMENT VIEW GUI, ADMINISTRATOR Ordre Kart EVALUERING Generelt om arbeidet Delinnleveringene Hovedinntrykk KILDER BENYTTET I PROSJEKTARBEIDET... 23

3 1. PROSJEKTPLAN 1.1 MÅL OG RAMMER Bakgrunn Budbilselskapet Kjapt Trygt & Billig driver henting og levering av pakker og gods i flere storbyer. De har spesialisert seg innen hurtig levering og har både faste og spontane kunder. Selv med mange faste kunder blir de ofte kontaktet når det haster som mest og kunden forlanger og er helt avhengig av ekspress levering. Visjonen til selskapet er å være innen hurtigst henting og levering med konkurransedyktige priser. Selskapet ønsker derfor å få på plass et nytt system som kan hjelpe dem med å administrere budbilene på en bedre måte. Systemet skal bidra til å effektivisere og rasjonalisere driften slik at selskapets ressurser blir utnyttet på best mulig måte Prosjektmål Resultatmål Det forventes at det ferdige produktet skal kunne: - registrere vekt og areal på godset som fraktes, og beregne budbilens ledige kapasitet - registrere posisjonen til budbilene, og vise dette på et oversiktskart i nær sann-tid - ved nye ordrer: finne nærmeste budbil med ledig kapasitet - beregne raskeste rute og navigere for sjåførene - registrere nye ordrer og tilby ordrestatus vha et webinterface - samvirke med eksisterende fakturasystem Effektmål Ved å innføre systemet forventer selskapet følgende effekter og gevinster: - Bli ledende i markedet innenfor ekspresslevering - Kortere behandlingstid pr kunde - Fornøyde kunder - Øke antall kunder med 10 % - Øke omsetningen med 20 % - Spare driftskostnader ved å effektivisere ordrebehandlingen (slanke organisasjonen) - Virke innovativ ved å ta i bruk moderne teknologi Rammer Prosjektet utføres og overleveres i henhold til de rammer som er gitt. Juridiske rammer Det ferdige systemet, og måten det brukes på må ikke være i strid med nasjonale og internasjonale lover og regler. Personopplysningsloven og Arbeidsmiljøloven er svært relevante. 1

4 Teknologiske rammer Systemet utvikles innen de rammer som er gitt av tilgjengelige tekniske løsninger, og skal følge gjeldende standarder slik at det lettere kan samvirke med selskapets eksisterende informasjonssystemer. Systemet skal være sikkert og lett å drifte og vedlikeholde. Økonomiske og tidsmessige rammer Systemet ønskes satt i drift i løpet av de neste 12 mnd, og har en kostnadsramme på 4 mill NOK. Ansvarlige for utarbeidelse av prosjektdokumentasjon er Espen Flydahl, Ole Morten Grodås, Jørgen Lundgren og Martin Sagstuen ved FIH 04/ OMFANG Oppgavebeskrivelse / avgrensning KT&B er et firma som i lengre tid har vært i sterk vekst og som ikke har tatt den teknologiske utviklingen innover seg. Firmaet administreres i dag i fra sentraler i hver by som kun baserer seg på telefonisk kontakt med både kundemasse og sine enheter. Her ligger hoveddelen/ utfordringen. I utviklingen av det nye systemet er det et krav at det er lett å innfase. Det skal legges vekt på kommunikasjonen mellom enhetene og administrasjonen, og mellom kunden og administrasjonen. Gjennom å forenkle rutiner og gjøre systemet mer oversiktlig har firmaet som mål å øke sin konkurransedyktighet gjennom å redusere sine administrasjonskostnader samt å effektivisere sin primærvirksomhet. Prosjektet skal ende opp med et system som gir administrasjonen mulighet for å ha kontroll på hver enhet samt få oversikt over ledig kapasitet i bilene. Dette systemet skal samhandle med GPS løsning som skal gi sjåførene ruteanvisning og estimert ankomst på hente/leveringsadresse. Ruten for hver enhet skal i nær sanntid speiles til administrasjonen som fra sitt ståsted kan legge inn nyinnkommende ordrer på planlagt rute. KT&B har i dag et faktura- og regnskapssystem som har funksjonalitet til å automatisere fakturering og regnskapsføring vedrørende ordrebehandling. Dette er per i dag en ubenyttet ressurs som bedriften ønsker å ta seg nytte av. En av våre oppgaver er å få til et ordresystem som er kompitabelt med det eksisterende faktura- og regnskapssystemet, og dermed gjøre ordrebehandlingen mer effektiv. Det skal nå lages et webinterface som kundene kan gå inn på for å registrere ordre samt at det skal gi kunden mulighet for å følge med hvorvidt ordren er behandlet, pakken er hentet eller pakken er levert. Ved hjelp av dette webinterfacet vil de også vil få mulighet til å velge mellom efaktura eller belastning av Eurocard. Betalingsløsning som baseres på efaktura er et samarbeid mellom KT&B og den enkelte kundes bank. Det skal i tillegg inngåes et samarbeid med Eurocard som leverer ferdige bedriftsløsninger. Webinterfacet skal ha mulighet for bestilling av et kundekort som gjelder spesifikt mot KT&B. Disse løsningene er støttet av det eksisterende fakturasystemet. Posisjon og ruteanvisning i hver enkelt bil skal leveres av ekstern aktør. Her skal flere aktører inn med sine produkter for å se hvilken løsning som lettest og billigst kan kombineres med KT&B sitt behov for link mot administrasjonen. Sambandet mellom enhet og administrasjon skal gå ved hjelp av 3G mobilsystemer. Vekt og areal beregning skal først og fremst foregå i mellom kunde og administrasjon der kunde velger mellom faste innvalg av pakkestørrelser som ligger i webinterfacet. Av sikkerhetsmessige årsaker ønskes det at hver bil har heldekkende vekt i lasterom. I tillegg skal sjåførene ha mulighet for å redigere ledig 2

5 kapasitet i form av mål på pakkene. Firmaet legger inn egne grenser for maks pakkestørrelse som kommer til syne på webinterfacet. 1.3 PROSJEKTORGANISERING Innledningsvis vil det holdes et møte med ledelsen der prosjektgruppa settes sammen og velger leder. KT&B driver i mange storbyer, og i en av disse vil systemet bli implementert som et pilotprosjekt for testing og lignende Ressurser og ansvarsforhold Det vil bli etablert en styringsgruppe og en utviklingsgruppe: Styringsgruppa består av: - Jørgen Lundgren FIH04/07 Prosjektleder - Produktsjef KT&B - IT-sjef KT&B - Sjåfør KT&B - Medarbeider ordreavdeling KT&B Jørgen Lundgren velges til prosjektleder med bakgrunn i hans erfaring og resultater som leder i tilsvarende prosjekter. Han sitter også i utviklingsgruppa, og er blir dermed den som har best helhetsoversikt over prosjektet. Utviklingsgruppa består av personell fra FIH 04/07, og utgjør til sammen et team på fire utviklere. Gruppa har kompetanse innen programmering og kommunikasjons- og informasjonsteknologi. Hver av de fire utviklerne har en generell bakgrunn fra disse fagfeltene, men har i tillegg dypere kunnskap innen et av feltene og kan betraktes som fageksperter innen dette området. De fire utviklerne er spesielt plukket ut til dette prosjektet for at utviklingsgruppen skal kunne jobbe effektivt og komme med nytenkende løsninger Øvrige roller og bemanning Det etableres en brukergruppe som skal være med på avklare forventninger og gi konstruktive tilbakemeldinger til styringsgruppa. Brukergruppa skal bestå av medarbeidere fra KT&B, med de rette egenskapene for å delta i utviklingsarbeidet. Det er viktig personene som velges ut har kompetanse tilsvarende en gjennomsnittlig medarbeider, i tillegg til å ha gode kommunikasjonsevner. Fra KT&B skal det stilles tre sjåfører og to medarbeidere fra ordreavdelingen. Det er også ønskelig med to representanter fra KT&Bs faste kunder. Det er lederne ved de respektive avdelingene som skal plukke ut hvilke medarbeidere som skal ta del i brukergruppen. Disse skal representere sine respektive avdelinger, og videreformidle deres syn på mulige løsninger i prosjektet. Det er usikkert hvor stor del av deres vanlige arbeidsoppgaver som vil forstyrres pga utviklingen, men det vil variere utover i prosjektet Valg av arbeidsmetode Daglige møter Hver dag starer med et kort møte der prosjekt deltakerene kan få en oversikt over dagens aktiviteter. Aktuelle problemer kan diskuteres og mindre avgjørelser takes. Møtet blir gjennomfør i et felles areal med whiteboard. Rommet skal ikke ha stoler, dette for å forhindre at møtet dra ut unødvendig i tid, samtidig som det hindrer at man kan sove seg gjennom møtet. 3

6 Ukenlige møter Hver utvikler har i forkant av det ukentlige møtene ansvar for å lage en kort statusrapport. Rapporten skal innholde en punktvis list over fullførte oppgaver denne uken, og en prioritert liste med oppgaver for neste uke. I starten av møtet presenterer alle sin statusrapport. Deretter er det muligheter for å diskuterer problemer og gjøre endringer på kommende oppgaver I det perioder ansatte fra KT&B er aktivt med i systemutviklingen skal de delta på alle møter på lik linje med systemutviklere. 1.4 PLANLEGGING, OPPFØLGING OG RAPPORTERING Drøfting av overordnet utviklingsmetode Prosjektet kan deles inn i segmenter, som vist på figuren under. Figur 4.1 Viktige segmenter i prosjektet Selv om mange av komponentene er avhengig av hverandre vil det være nyttig å dele opp prosjektet i mindre deler som kan utvikles og testes uavhengig av hverandre. Dette er momenter som taler for bruk av inkrementelle utviklingsmetoder. Dette vil øke sjansen for å oppdage feil og mangler tidlig. Det eksisterer allerede programmer og halvfabrikat for mange del systemer nemt over. Foreksempel finnes det ferdig utviklede databaser og gps navigasjons systemer. Ved å bruke ferdig utviklede produkter kan man spare penger fordi utviklingskostnadene blir spredd over flere brukere. Samtidig som det korter utviklingstiden og redusere risikoen for feil. Dette er et moment som taler for en komponentbasert utviklingsmodell. Problemet med gjenbruk er at modifisering av eksisterende programmer kan være svært vanskelig og man kan ende opp med halvgode løsninger. Av den grunn vil vi ha størst nytte av gjenbruksstrategier på det mer generelle delene av systemet som database og GPS navigering. Dette fordi det allerede eksisterer gode og velprøvde løsninger på disse områdene. Et problem man må ta hensyn til er begrensningen som lisenser kan sette på prosjektet. Vi kan konkludere med at det vil lønne seg å bruke en komponentbasert utviklingsprosess på noen av komponentene. Samtidig som det ikke vil lønne seg for brukergrensesnittet for administrasjon av ordrer. Dette fordi brukergrensesnittet er relativt spesielt og gjenbruk vil derfor kreve store modifikasjoner. Et annet moment er at brukergrensesnittet er svært viktig for kunne nå målene med bedre ressursutnyttelse og man bør derfor satse ekstra på denne komponenten. Et kjennetegn ved det ansatte i KT&B er at det har lang erfaring innen budbilbransjen og de har av den grunn god kjennskap til problemer med eksisterende systemer. Samtidig har de liten kunnskap om mulighetene i dagens teknologi. Systemutviklerne har derimot den motsatte kunnskapen. De har god kjennskap til dagens teknologi, samtidig som de har lite kjennskap til problem i forbindelse med administrering av budbiler. Hver for seg har de ikke nok kunnskap til å utvikle et optimalt system, men til sammen har de all nødvendig informasjon. God kommunikasjon mellom systemutviklere og ansatte i KT&B vil derfor være en kritisk faktor for prosjektet. Dette er et moment som taler for utviklingsmodeller som setter brukeren i fokus. Dersom brukeren og utvikleren klarer å kommunisere på en god måte kan vi forvente at det etter hvert får bedre forståelse for hverandres fagområde. Dette vil mest sannsynlig føre til en bedre forståelse av hvordan systemet bør fungere. Vi kan av den grunn forvente at etter hvert som de jobber med prosjektet 4

7 vil finne nye og bedre løsninger. Det vil derfor være viktig å velge en utviklingsmodell som er god til å håndtere endringer. En fordel ved å bruke inkrementell utvikling er at det gir mulighet for delleveranser. Ved å ha mange delleveranser vil konsekvensen av problemer under implementeringen av systemet bli mindre. Samtidig åpner det for mer utbrett testing av programmet på et tidlig tidspunkt. Dette kan gi viktige tilbakemeldinger som fører til revurdering av tidligere planer. Ulempen med delleveranser er at det vil forstyrre den normale driften i KT&B i et større tidsrom. Evolusjonær utvikling har den fordelen at dersom vi oppdager problemer i et segment etter at det er satt i drift har vi mulighet til å endre prosjektplanen og gå tilbake og endre segmentet. Med bakgrunn i prosjektkarakteristikken velger vi å bruke en inkrementell utvikling med innslag av evolusjonær utvikling i noen av segmentene Vi ønsker å ha innslag av evolusjonær utvikling i de delene som er i direkte kontakt med KT&B sine brukere. Dette for å ta hensyn til kunnskapsnivået til utviklere og brukere. Ved å bruke evolusjonær utvikling håper vi å kunne sette i gang en læringsprosess både hos utviklere og brukere som vil føre til et bedre produkt. 1.5 RISIKOANALYSE I denne analysen fastsetter vi risikoen etter følgende figur, der hvitt område representerer lav risiko, lyst skravert område middels risiko og mørkt skravert representer høy risiko: Fig 5.1 Figur for gradering av risiko (kilde: Risikohåndtering, Øksnes og Furuseth 2004) I dette prosjektet har vi i samarbeid med kunden besluttet å sette akseptabelt risikonivå til middels eller lavere. Det vil si at det ikke settes krav til forebyggende tiltak for hendelser som utgjør en lav risiko, men det er heller ikke noe i veien for å gjøre tiltak mot disse risikoene også. Dette blir en avveining mellom kostnad og nytteverdi av eventuelle tiltak. Enkelte av hendelsene som kan inntreffe er det ofte vanskelig å implementere gode forebyggende tiltak mot, og derfor setter vi opp skadedempende tiltak for disse hendelsene. Det er kun de forebyggende tiltakene som det er relevant å prioritere i forhold til hverandre med hensyn til planlegging. 5

8 Beskrivelse Utviklingsprosessen går utover sine planlagte tidsrammer Kostnader i tilknytning utviklingsprosessen går over budsjettert nivå Viktig utviklingspersonell ute av stand til å jobbe videre med prosjektet (sykdom, organisasjonsendring, etc) Det finnes ikke teknologi tilgjengelig som muliggjør oppnåelse av resultatmål i tilfredsstillende grad. Store endringer i krav til funksjonalitet midt inne i utviklinga Kommunikasjonsvikt mellom utviklere og brukere vedrørende kravspesifikasjonen Hendelser Sannsynli Konse Risiko Aksept Ev. tiltak ghet kvens nivå abelt? Lite Liten Lav Ja sannsynlig Sannsynlig Middels Middels Nei Reforhandle med kunde om økonomiske midler. Avtalefeste en mulighet til dette på forhånd Lite sannsynlig Lite sannsynlig Meget sannsynlig Meget sannsynlig Kritisk Middels Nei Erstatte personell Pri Benytte kompetansespredende utviklingsmetoder/prinsi 5 pp; spesielt åpen kildekode for alle utviklere. Kritisk Middels Nei Redusere kompleksitet på produktet for å tilpasse til tilgjengelig teknologi Kritisk Høy Nei Benytte så lav kompleksitet som mulig i koden for å lett kunne 2 gjøre endringer, og ha lett tilgjengelige utviklere Kritisk Middels Nei Involvere brukere i 3 utviklingsprosessen. Få kode ut i drift snarest mulig for tilbakemeldinger Katastro Middels Nei Ha gode backuprutiner 1 fal Middels Lav Ja Ha gode 7 Tap/sletting av store mengder kildekode Lite sannsynlig Kildekode i hendene på Lite konkurrenter sannsynlig sikkerhetsrutiner Endring i ledelse hos KT&B Sannsynlig Middels Middels Nei Gi ansatte/brukere som resulterer i nedprioritering eierfølelse til systemet av prosjektet på et tidligst mulig tidspunkt. Vi har som minimumsmål å implementere tiltakene med prioritet fra og med 1 til og med

9 1.6 GJENNOMFØRING Tidsplan Aktivitet Start Slutt Feb Mar Apr Mai Jun Jul Aug Sep Okt Nov Des Jan Feb Prosjektplan Kravspesifikasjon Gjennomførbarhetsanalyse Use case analyse Funksjonelle krav Ikke funksjonelle krav Avgrensninger Høy nivå design Valg av arkitektur og leverandører av gjenbruksteknologi Oppdeling i inkrementer Utvikling GPS ruteanvisning i bil system Biloversiktsystem Ferie Internt ordresystem Web ordresystem Etterarbeid Evalueringsrapport Figur 6.1 Gannt skjema Vi har delt inn i inkrement som resulterer i et system som har nytteverdi for oppdragsgiver i stedet for å dele inn i fysisk adskillbare systemer. Vi mener at dette er mer korrekt i forhold til tankegangen i tradisjonell inkrementell utvikling Beslutningspunkt 1. mars: Skal prosjektet gjennomføres? 21. mars Hvilken utviklingsplattform skal benyttes? 1. april: Hvilken teknologi skal gjenbrukes? 16. april: Hvordan skal systemet bygges opp og hvem skal levere gjenbruksteknologi? 16. mai: Endelig oppdeling av produktet i inkrementer Underveis i utviklingen av inkrementene vil man nesten hele tiden jobbe med et relativt kort tidsperspektiv og sette beslutningstidspunkt underveis i prosessen Milepæler 24. feb: Prosjektplan ferdig 1. mar: Gjennomførbarhetsanalyse ferdig 16. mai Alt av forberedelser ferdig. Begynne å kode løsningen. 16 mai 6. feb: Ferdigstilling av de forskjellige inkrementene 13. feb Evalueringsrapport ferdig Vi har ikke satt opp spesifikke milepæler under utviklingen utenom ferdigstillingen av de forskjellige inkrementene da de vi kommer til å jobbe med et relativt kort tidsperspektiv under utviklingen, og dette medfører mange mindre milepæler som ikke er klare i nåværende fase av prosjektet. 7

10 2. KRAVSPESIFIKASJON 2.1 USE CASE ANALYSE Use Case diagram I utarbeidelsen av usecase diagrammet fant vi først ut hvem som skulle være brukerne av systemet. Vi plasserte til slutt alle brukerne i 5 kategorier som vist under. Når vi skulle identifisere usecase så vi på hvilke tjenester hver enkelt aktør ønsket fra systemet. Til slutt vurderte vi om det var naturlig å dele opp eller slå sammen noen av use casene. Vi gjentok denne prosessen flere ganger og kom frem til følgende use case diagram. Figur Use Case diagram Etter diskusjon i gruppe bestemte vi at systemet ikke skulle ha noe med lønning av personell å gjøre. Dette er derfor ikke tatt med i usecase diagrammet. 8

11 Vi var lenge usikre på om vi skulle slå sammen det 3 use casene Administrer ordre, Endre ordrestatus og Vis orderoversikt, eller eventuelt bruke includes. Men etter en lengre diskusjon i gruppen kom vi frem til at use casene var så pass forskjellige at det ville være vanskelig å behandle dem samlet. Et annet problemområde var de 3 use casene Vis biloversikt, Vis rute og Vis bilinformasjon. Vi ser for oss vis biloversikt som et kart med mulighet til å plotte informasjon om biler. I den sammenheng er det naturlig å ha muligheten til å plotte ruten til bilene, av den grunn kom vi fram til at det er mest naturlig at vis biloversikt inkluderte vis rute. Vis bilinformasjon er også svært sterkt knyttet til Vis biloversikt, men fordi vis bilinformasjon også har en del funksjonalitet som ikke naturlig kommer direkte inn i vis biloversikt fant vi ut at det var mest naturlig å behandle det som en separat usecase Høy-nivå Use Case beskrivelse Vi har her prøvd å velge ut det 4 usecase diagrammene som illustrere hvordan vi har planlagt Budbil applikasjonen. Use case Aktør: Hensikt Beskrivelse Use case Aktør: Hensikt Beskrivelse Use case Aktør: Hensikt Beskrivelse Use case Aktør: Hensikt Beskrivelse Legg inn ordre Kunde En kunde skal ha mulighet til å registrere ordrer digitalt over internett. En kunde forespørrer et ordreskjema på internett. Når kunden har fylt ut skjemaet korrekt sendes det til en ordrekø i administrasjonen for videre behandling. Administrer ordrer Administasjon Gi administrasjonen mulighet til å fordele ordrene på enkeltbiler på en effektiv måte. Aktøren skal kunne få en oversikt over ordrene som ligger i ordrekøen. Aktøren bruker deretter vis biloversikt og vis bilinformasjon til å finne bilen som passer best til oppdraget. Til slutt gir aktøren oppdraget til en bestemt bil. Administrer kundeprofil Kundre, administrasjon Forenkle bruken av systemet for kunder som bruker systemet ofte. Kunden skal ha mulighet til å legge inn standard betalingsmåte, fakturaadresser, hente og leverings adresser og kontakt informasjon. Administasjon skal ha mulighet til å gjøre endringer på profilene og rette feil. Vis ordreoversikt Kunde Kunden skal på en enkel måte kunne skaffe seg oversikt over ordrene sine. Når kunden logger inn på websiden skal han få en oversikt over aktive ordrer og status på ordrene. Kunden skal kunne ha oversikt over tidligere ordrer og søke i disse. 9

12 2.1.3 Detaljert Use Case beskrivelse Hva som er det mest risikable use caset kan vurderes fra to forskjellige perspektiver. Enten sett opp mot bedriftens forretningsvirksomhet, eller opp mot selve systemet. For forretningsdriften vil det være mest kritisk hvis ordresystemet går ned. For systemet kan risiko vurderes ut fra både vanskelighetsgraden ved utvikling og for selve driften. Systemet skal i hovedsak gjøre det lettere å administrere selskapets ressurser på en effektiv måte, og derfor er det kritisk hvis man mister oversikten over bilene. På grunn av kompleksiteten er det også knyttet risiko til utviklingen av dette use caset. Vi har fokus på systemet og velger derfor vis biloversikt som det mest risikable use-caset. Navn Mål Aktør Pre betingelser Post betingelser Trigger Normal hendelsesflyt ( Main success scenario ) Vis biloversikt Sørge for at administrasjonen får oversikt over de budbilene som er i drift. Administrasjon Det må være budbiler i drift. Ingenting endres. Use caset henter bare ut info fra systemet. Administrasjonen vil vite hvor budbilene befinner seg og hvilke biler som har ledig kapasitet. 1. Use caset begynner når aktøren sender en forespørsel til systemet om å generere oversiktskartet. 2. Systemet viser kartet med standardoppsett med målestokk avhengig av størrelsen på byen systemet er implementert i. 3. Aktøren angir hvor stort område kartet skal vise, eller han kan oppgi en adresse med ønsket radius på området som skal vises. 4. Systemet viser kartet over det definerte området, og gir nå aktøren et filter med valgmulighet til å velge det han er ute etter. Valgmuligheter i filteret: - alle biler i området - biler med ledig kapasitet over x kg - forskjellige sjåfører - type bil, for eksempel bil med kran, kjøle/fryse plass, høyde over 2 meter i lasterom etc. - angi ruten til bilene - vektorer som viser retningen til bilene 5. Aktøren angir sine ønsker til systemet. 5.1 Systemet forespør hvilke biler som er i drift i det angitte området. 5.2 Bilene som er i drift returneres, og det legges til et biltypesymbol og en tekst som forteller sjåføren på bilen. 5.3 Systemet forespør om posisjonen til bilene. 5.4 Bilenes posisjon returneres. 5.5 Systemet forespør om bilenes ledige kapasitet. 5.6 Ledig kapasitet returneres. Denne verdien brukes til å generere en fargekode for bilen som indikerer hvor stor den ledig kapasiteten er. 6. Systemet viser oversiktskartet med ikoner som representerer hver enkelt budbil. 10

13 Variasjoner (gyldige alternativer og feilsituasjoner) 5.2a) Ingen biler i drift. 5.2a1) Systemet gir melding om at ingen biler er i drift. 5.4a) Bilene har ikke oppdatert sin posisjon til nær-sanntid. 5.4a1) Systemet henter siste registrerte posisjon for bilen, men markerer med et tilleggssymbol at posisjonen ikke kan garanteres. 5.6a) Finner ikke nåværende last for en bil. 5.6a1) Systemet markerer bilen med en farge som symboliserer at ledig kapasitet for bilen ikke er kjent. 5.6b) Finner ikke tillatt kapasitet for bilen. 5.6b1) Markerer på samme måte som i pkt. 5a1. 6a) Finner ikke kartet. 6a1) List opp bilene med adresse og område de befinner seg i. Relatert informasjon Systemet må kunne generere oversiktskartet i løpet av 1 sekund Sekvensdiagram Sekvensdiagrammet nedenfor illustrerer forløpet i use caset Vis biloversikt. Vi valgte å lage sekvensdiagram for det use caset vi har utdypet detaljert, fordi vi mener det vil gi bedre forståelse av den detaljerte beskrivelsen. Figur Sekvensdiagram 11

14 2.2 KONSEPTUELT KLASSEDIAGRAM Figur Konseptuelt klassediagram Som det kommer frem av UML skissen er ordre kjernen i systemet vårt. Klassene Statistikk og Adresser er ment som et verktøy bedriften kan bruke ved gjennomgng av trafikken. Det er bygd opp slik at man lett kan se hvilke soner, gjennom en tidfestet periode, hoveddelen av trafikken har gått. Adresser er knyttet til Kunde med en mange til mange relasjon fordi det er stor sannsynlighet for at flere kunder vil sende pakker til samme adresse. Sjåfør og Admin er del av sikkerhetssystemet fordi det vil gi kunden svar på hvem som har håndtert ordren og kjørt pakken i ettertid av en leveranse. Admin er i tillegg grensesnittet mellom oversiktskart og kunde for å kunne besvare leveranserelaterte spørsmål fra kunder. Oversiktskart er hjelpemiddelet til Admin som suppleres av Bilklassen. Faktura benytter seg av knytningen Kunde, Bil, Sjåfør og Pakke har til Ordreklassen, og kan ved hjelp av dette gi detaljerte fakturaer ut til kundemassen Vi har valgt å ikke skille ut noe eget rundt kartapplikasjonen som vedrører bilene. Dette er fordi det kun er en versjon av kartet for alle enheter, men som har mange nivåer i dybde og som oppdateres ved hjelp av GPS og trafikk som går mellom Oversiktskart og Bil. 2.3 KVALITETSMESSIGE KRAV I de kvalitetsmessige kravene har vi lagt vekt på å ha målbare krav. Vi har satt krav innenfor de områdene vi mener er viktigst for dette prosjektet Brukervennlighet Sjåførens brukergrensesnitt skal kunne brukes uten at det er til aber for sjåføren med tanke sikkerhet, ergonomi og effektivitet. 12

15 Systemets brukergrensesnitt mot Admin og Sjåfør skal være så intuitive at det ikke er nødvendig med kursing utover 1 dag Grensesnittet mot kunden skal være oppbygd som en nettbutikk med innlogging, innlegging av ordre, valg av betalingsmåte, etc. Det skal være samme metodikk som kundene med høy sannsynlighet har tidligere erfaringer med fra andre nettbutikker slik opplæring ikke er nødvendig Ytelse Enheters posisjoner skal oppdateres hvert 5 sekund på Admin GUI Ruteanvisning skal gjennomsnittlig ta mindre enn 1 sek å generere på sjåførens system fra ordre er plassert på sjåførens system Webinterfacet skal ikke gjennomsnittlig ta lengre enn 2 sek å laste inn hos en klient med en 1,5 Mbps internett forbindelse (ikke over 365 kb) Systemet skal kunne oppdatere ordrestatus ut til brukergrensesnitt med en tidsforsinkelse mindre enn 5 sek fra statusen er forandret Systemet skal kunne håndtere opptil 30 simultane ordrebestillinger uten at det går utover andre krav gitt her Systemet skal kunne takle at minst 10 simultane administratoraktiviteter uten at det går utover andre krav gitt her Alle innloggingsprosesser i systemet skal enkeltvis ikke ta lenger enn 5 sek Systemet skal ha en lagringskapasitet for å lagre enkeltordrer Pålitelighet Systemet skal ikke gjennomsnittlig ha mer enn 1 alvorlig feil (feil som setter viktige funksjonaliteter ut av drift) per halvår Nedetid ved en alvorlig feil skal ikke gjennomsnittlig overstige 3 driftstimer. Det skal ikke gå tapt lagret nyttedata som konsekvens av feil Ved feil i ett inkrement skal systemets andre inkrementer allikevel fungere så langt det er mulig Nøyaktighet Posisjonsanvisningen skal ikke ha større feil enn 20 meter. Kartsystemet må kunne oversette adresser til kartreferanser med mindre enn 20 meters feil Sikkerhet Det skal være så godt som umulig å for uvedkommende å få tilgang til eller å endre personopplysninger gjennom systemets tilknytning til Internett Alle sikkerhetsmessige tiltak og systemets arkitektur som helhet skal dokumenteres (Kravene i punkt kommer som en konsekvens av personopplysningsloven 13) Vedlikeholdslettende krav Systemet skal være oppbygd av standardiserte hardware-enheter som lett kan erstattes Systemets software skal være kodet etter en felles standard for det aktuelle programmeringsspråket med tanke på navn for variabler, innrykk, etc Portabilitet Sjåførens brukergrensesnitt skal ikke være større enn 30x25x5 cm Andre krav Webgrensesnittet skal før registrering i kundedatabasen gi kunden opplysning om punktene spesifisert i personopplysningsloven 19. Personopplysninger om kunder skal slettes umiddelbart etter kundeforholdet er avsluttet (personopplysningsloven 28) 13

16 3. ARKITEKTUROVERSIKT Vi har valgt å benytte oss av trekk fra RUP s 4+1 view som vi føler er spesielt anvendbare i vårt prosjekt. Disse er Logical View, Process View og Deployment View. Vi har ikke lagt vekt på å følge RUP s tunge spesifikasjoner til punkt og prikke, men vi føler at vi har med det sentrale under hvert punkt. I tillegg har vi tatt med oss et annet element som man finner i en klassisk arkitekturbeskrivelse; nemlig GUIutforming. 3.1 LOGISK VINKLING PÅ SYSTEMET Lagdeling Vi har her delt systemet opp i mindre komponenter. Fokuset i denne del har vært å dele opp systemet slik at vi får solide delsystem. Med dette mener vi delsystemer som har enkle og veldefinerte roller og få koblinger til andre delsystemer. Målet er å samle lik funksjonalitet slik at man unngår duplisert kode og gjøre det enkelt å bytte enkelt komponenter. Presentation layer Application layer Database layer Figur Figuren kan tolkes som at vi i bunn av systemet vårt har en felles database og backup system for lagring av ordreinformasjon. Over denne lagringsenheten har vi forskjellige applikasjoner som henter ut data fra databasen. Administrasjon GUI og Sjåfør GUI er to separate programmer som i hovedsak har felles kode på applikasjons laget. I web løsningen har vi valgt å lage et skille mellom den teknologien vi ønsker å benytte på server siden (web data) og den teknologien vi ønsker å bruke på klient siden (web layout). Grunnen til dette er at det for tiden er stor utvikling på dette området og det er svært vanskelig å si hvilke teknologi som vil være dominerende om 10år. Etter som Web layout er kundens grensesnitt mot bedriften ser vi på det som spesielt viktig å være med i tiden på dette området. Vi må derfor forvente at dette er en av pakkene som oftest må oppdateres eller skiftes ut. I lag modellen har vi illustrert at det er svært høy grad av kodedeling mellom sjåfør og administrasjons GUIene. Vi mener det bør være et mål at det to applikasjonene har så mye felles kode som er praktisk mulig. Men i hvor stor grad man kan klare å gjennomføre kodedelingen vil man først finne ut når man har funnet hvilke hardwareplattform og hvilke programmeringspakker som skal benyttes i det to applikasjonene. Det blir her en utfordring å finne hardwareplattformere og programmeringspakker som gjør det lett å utvikle felles klasser for det to applikasjonene. 14

17 Dersom man studerer de to applikasjonene nærmere vil man oppdage at det har store forskjeller både på bruksområde og teknologiske løsninger. For eksempel har Sjåfør GUIet begrenset skjermstørrelse, det må kunne styres med en hånd samtidig som sjåføren kjører, og det skal bare vise ordreinformasjon for den aktuelle bilen. Det er derfor fare for at kodedeling kan føre til halvgode løsninger. Man bør derfor vurdere nøye hvor man skal benytte seg av kodedeling. Dette kan føre til at man ender opp med mindre kodedeling en lagdelings modellen illustrere. Når man studerer lag modellen ser man at webdata - og felles db klasser -pakkene inneholder mye av den samme funksjonaliteten. Begge pakkene ligger på applikasjons laget og er ansvarlig for å hente ut og oppdatere informasjon i databasen. Det som skiller det to pakkene er at applikasjonene som benytter felles db klassen ønsker å få melding når det skjer endringer i databasen. Denne pakken må derfor støtte en event/message handler. Dette er ikke tilfelle for webdata pakken. En annen grunn til å skille de to er det tradisjonelt er brukt svært forskjellig teknologi for å lage dynamiske websider og for hente ut data til vanlige desktop programmer. Vi ser på det som problematisk å stille enda flere krav til valget av programmeringspakker for det to GUIene Konseptuelt klassediagram Ved nærmere studie av konseptuelt klassediagram ser vi at noen av konseptene er mer beslektet enn andre. Vi har her prøvd å samle de konseptene som har mest signifikante fellestrekk i pakker. Under oppdelingen fant vi ut at det som var mest beskrivene for konseptene var hvilken type data de behandler. Dette fordi forskjellig data stiller forskjellige krav til sikkerhet, lagring og backup og må derfor behandles forskjellig. Figur Sortert konseptuelt klassediagram Vi ser at ved å flytte kunde inn i systembrukerpakken får vi mange koblinger på tvers av pakkene. Dette er i utgangspunktet ikke ønskelig. Men vi valgte å gjøre dette slik fordi både admin, kunde og sjåfør er konsepter der persondata er sentralt. Denne typen data må behandles i henhold til Personopplysningsloven og dette vil være styrende for hvordan dataen kan lagres og brukes. 15

18 Det tre pakkene langtidslager, systembrukere og situasjonsdata har ansvar for data som er lagret i den sentrale databaseserveren. Vi valgte likevel å skille det i 3 pakker fordi dataen har så forskjellige krav til hvordan den blir behandlet. Prosessert data Prosessert data kjenne tegnes ved at det er generert fra andre kilder. Det betyr at dataen kan generertest på et senere tidspunkt. Det er derfor ikke behov for at data skal lagres over lenger tid og man trenger derfor ikke ta spesielle hensyn til lagring og oppbevaring av dataen. Langtidslager Når man behandler langtidslagret dataen skal lagres over lengre tid. Man må da i større grad ta hensyn til sikring og backups rutiner. Denne dataen er også viktig for å dokumentere aktivitetene til bedriften og noen av dataen må lagres og oppbevares i henholde til Bokføringsloven. Systembrukere Systembruker data inneholder mange person opplysninger og må derfor behandles i henholde til personopplysnings loven. Samtidig er hemmeligholding av passord et viktig moment i denne pakken. Situasjonsdata Må distribueres effektivt, er bare relevant i en kort tidsperiode. 3.2 PROCESS VIEW I systemet er det aktører som bruker forskjellige tekniske løsninger. En grov inndeling av systemet vil være database, sjåførterminal, administrasjon og webgrensesnitt (se deployment view for ytterligere detaljer). Vi har her valgt å fokusere på informasjonsutvekslingen mellom de forskjellige prosessene som kjøres i de ulike tekniske løsingene. Derfor vektlegger vi å få avklart hvordan interaksjonene mellom de forskjellige prosessene er. Følgende prosesser er definert: 1. legge inn ordre 2. endre ordre 3. oppdatere database 4. hent data fra database 5. oppdater grafisk brukergrensesnitt i administrasjon 6. oppdater grafisk brukergrensesnitt hos sjåfør 7. ajourfør faktura 8. oppdatere bilposisjon 9. oppdatere webgrensesnitt (på kundes initiativ) Vi har valgt å se på to systemoppgaver som vi anser som viktigst i systemet. Disse to er ordrebehandling og posisjonsdatahåndtering. Vi diskuterer først den tekniske løsningen, og ser så på hvilke av de definerte prosessene som er involverte og hvordan disse samspiller med hverandre Teknisk løsning: ordrebehandling Før vi beskriver noe mer rundt hver av prosessene og interaksjonene mellom dem skal vi velge ulike tekniske løsninger for å kunne gjennomføre prosessene best mulig. Først tar vi for oss løsningen for å informere de ulike aktørene om at det har skjedd endringer i databasen. Bilene skal koble seg opp mot databasen, og lagre deler av databasen lokalt på terminalen. Linken mellom bilen og databasen har liten båndbredde i tillegg må bedriften betale for datamengden som overføres på linken. 16

19 En løsning som vi slo fra med en gang oss var å la alle oppdateringer sendes til alle bilene. Dette ville skape mye overflødig data i nettverket, og unødvendig data å prosessere for terminalene. Vi måtte derfor se oss om etter en løsning der hver prosess bare trenger å konsentrere seg om relevant informasjonen. Dette ville være med på å redusere trafikken på linken ut til bilene. Bedriften måtte jo tross alt betale for overført datamengde. En mulighet for å oppdatere den lokale kopien på bilene, er at terminalene bruker polling. I gitte intervaller vil da terminalen spørre databasen om det har kommet oppdateringer. Et problem med denne løsningen er å finne riktig tid på pollingintervallet. For korte intervaller vil skape mye trafikk på linken, mens for lange intervaller vil føre til utdatert data på klientene. Sammenliknet med det første forslaget har vi redusert trafikken noe, men denne løsningen er ikke ideell for vårt system pga. båndbredden og kostnadene pr. MB overført data. Vi kom etter hvert frem til at vi ønsket en løsning der bilene varsles med et signal når ny data var tilgjengelig. Signaleringen skal fortelle bil X at det har kommet en endring i databasen som den trenger. Tanken var å utvikle en kontroller som skule styre informasjonsflyten i systemet. Ved hjelp av enkel signalering ville kontrolleren motta informasjon om oppdateringene som blir gjort mot databasen. Signalet skulle definere hvilken type oppdatering som nettopp ble gjort. Kontrolleren tolket dette, sjekket i sin abonnentliste hvem som har nytte av oppdateringen, og sendte signalering til disse prosessene. Når en prosess mottok signalering fra kontrolleren skulle den selv kontakte databasen for å hente ut den oppdaterte informasjonen den trengte. Dette ville sikra at hver prosess fikk dataen i nær-sanntid, samt at den bare fikk de data den har bruk for. Dette virket som en fornuftig løsning. Den store ulempen med denne løsningen er at vi må programmere kontrolleren selv. Etter å ha vurdert kostnadene dette ville gi, valgte vi å undersøke om denne løsningen allerede fantes innebygd i noen databaser. Det ville vært den absolutt beste løsningen for oss. Vi fant løsningen vi var ute etter hos Oracle. Deres Oracle Database 10g Release 2, har en funksjon som håndtere endringer i data på den måten vi ønsket. Den sender ut en endringsnotifikator til den de applikasjonene/prosessene som abonnerer på dataene. Når en applikasjon mottar en slik notifikator kan den selv hente ned de nye dataene i databasen. Løsningen var optimal for å implementeres med bilterminalene. Vi gjorde liknende vurderinger for både administrasjonen og fakturasystemet, og kom frem til at de også kunne ha nytte av funksjonaliteten i Oracle Database. I administrasjonen bør ordrestatuser være så nær sanntid som mulig. Løsningen vi har valgt vil være med på å gjøre at endringer i ordrestatus vil komme opp på GUI et nesten umiddelbart etter at handlingen er utført. Dette vil være spesielt viktig dersom flere administratorer jobber med samme område. Fakturasystemet skal ha beskjed når ordren har fått status ferdigbehandlet, og løsningen vår vil være slik at databasen sender ut en endringsnotifikator når denne statusen inntreffer. Ut fra vurderingene ovenfor har vi valgt Oracle Database 10g Release Interaksjoner mellom prosessene ved ordrebehandling Vi tar her for oss behandlingen av en ordre fra opprettelse til den er ferdigbehandlet og lagt inn i fakturasystemet. Det første som skjer er at kunden legger inn ordre (prosess 1) i webgrensesnittet. Webgrensesnittet oppdaterer databasen (prosess 3) når ordren blir registrert med status ubehandlet. Samtidig sendes det ut en endringsnotifikator til administrasjonen om at den må hente ubehandlede ordrer i databasen. Administrasjonen henter ordren fra databasen (prosess 4), og oppdaterer lista over ubehandlede ordrer. Dette resulterer i at GUI i hos administrator blir oppdatert (prosess 5). Når ordren er behandlet og overført til bil settes statusen til under behandling (prosess 3). 17

20 Databasen oppdateres med den nye informasjonen (status og hvilken bil som skal ekspedere ordren) (prosess 3). Databasen sender ut en endringsnotifikator til bil X om at den må hente en nye ordrer. Terminalen som sitter i bil X kobler seg opp mot databasen og henter ordren (prosess 4). Dette resulterer i GUI hos sjåfør oppdateres (prosess nr 6). Når sjåføren har ekspedert ordren, settes statusen til ferdigbehandlet (prosess 2). Terminalen i bilen oppdaterer så databasen (prosess 3) med den nye informasjonen. Fakturasystemet skal så varsles om ordrer med status ferdigbehandlet, og det sendes derfor ut en endringsnotifikator til fakturasystemet. Fakturasystemet mottar varslingen, og henter data fra databasen (prosess 4), for å kunne ajourføre fakturaen (prosess 7) på den angitte ordren. Ordrebehandlingen er nå avsluttet Teknisk løsning: oppdatering av posisjon Denne prosessen er den som håndterer størst totalmengde data i systemet. I kravspesifikasjonen har vi sagt at bilenes posisjon skal oppdateres minst hvert 5 sek. I tillegg er det et krav fra kunden at systemet skal være skalerbart, med tanke på å både kunne håndtere et lite og stort antall biler. Data som skal overføres karakteriseres av følgende: Mange overføringer per tid Små mengder data i én overføring Posisjonsdata i overføringen har kort levetid Man må også ta med i betraktningen at kostnadene tilknyttet mobilterminalene i bilene beregnes ut i fra mengde data overført. Det vil altså være mest gunstig å velge en overførselsmetode som er forbindelsesløs. Problemet er at så godt som alle ferdige biblioteker for databasetilknytning baserer seg på TCP/IP som er forbindelsesorientert. Hvis vi skal benytte databaser, så må altså vi akseptere den ekstratrafikken som TCP/IP skaper. Når det gjelder tidspunktet knyttet til en posisjon, så defineres dette som det lokale tidspunktet på sentralen da posisjonen blir mottatt. Dette for å eliminere problemet med feil klokke på bilterminal, og for å minske overført data. Vi anser forsinkelsen i nettet som for liten til å ha betydning. Hovedutfordringen ligger i å velge hvordan posisjonsdata skal behandles i sentralen. Det er tre alternativer som peker seg ut: 1. Lagre de x siste posisjoner og tidspunkt i en databasetabell for hver enkelt bil 2. Lagre den sist innkomne posisjonen i en databasetabell med alle bilene tilknyttet én posisjon hver 3. Ikke lagre posisjonsdata i det hele tatt, men route data direkte til alle admin terminaler De to første alternativene har en felles fordel gjennom at vi kan benytte standardiserte metoder for oppdatering og henting av data. Denne standardiserte metoden tilbyr brukerautentisering. Det tredje alternativet tilbyr best ytelse og minst belastning av systemet, men her eksisterer det ikke noen brukerautentisering. Løsningen ville vært å konfigurere routeren som står opp i mot internett til å multicaste posisjonsdata til eget nett for admin terminaler. Alternativet til dette er å kode en egen applikasjon som ivaretar autentisering og videreformidling av data. Vi er avhengige av å ha en viss sikkerhet på integriteten på posisjonsdata for at ikke hvem som helst skal kunne koble til systemet og oppdatere posisjon feilaktig. Vi velger å se bort fra alternativ 3 da det allerede finnes standardiserte måter å gjøre dette på i form av enten alternativ 1 eller 2. Dette medfører bruk av TCP/IP fra bil til sentral. 18

Brukerveiledning. Madison Møbler Nettbutikk

Brukerveiledning. Madison Møbler Nettbutikk Brukerveiledning Madison Møbler Nettbutikk 1 1. Forord 1.1 Produktet Produktet er i denne manualen nettbutikken www.madison-mobler.no. Dette er en nettbutikk som skal gi brukerne mulighet til å handle

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

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

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR INF 1050 UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR Oppgave 1 a) Foranalyse: Foranalysen kan med fordel gjøres i to trinn. Den første er å undersøke finansiering og øvrige

Detaljer

KRAVSPESIFIKASJON FOR SOSIORAMA

KRAVSPESIFIKASJON FOR SOSIORAMA KRAVSPESIFIKASJON FOR SOSIORAMA Innhold 1. Forord... 2 2. Definisjoner... 3 3. Innledning... 4 3.1 Bakgrunn og formål... 4 3.2 Målsetting og avgrensninger... 4 4. Detaljert beskrivelse... 8 4.1 Funksjonelle

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

S i d e 1. Brukerveiledning Brevfabrikken

S i d e 1. Brukerveiledning Brevfabrikken S i d e 1 Brukerveiledning Brevfabrikken S i d e 2 Innholdsfortegnelse 1 Brevfabrikken innledning 4 2 Komme i gang /Registrer 5 2.01 Registrer 5 2.02 Last ned program 5 3 Min side: 6 3.01 Kontodetaljer

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

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

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

Detaljer

Brukerdokumentasjon... 2. 1.1 Logg inn... 2. 1.2 Ny bruker... 3. 1.3 Hovedmeny... 6. 1.4 Oppdrag... 8. 1.4.1 Oppdragsgiver... 8

Brukerdokumentasjon... 2. 1.1 Logg inn... 2. 1.2 Ny bruker... 3. 1.3 Hovedmeny... 6. 1.4 Oppdrag... 8. 1.4.1 Oppdragsgiver... 8 Innhold Brukerdokumentasjon... 2 1.1 Logg inn... 2 1.2 Ny bruker... 3 1.3 Hovedmeny... 6 1.4 Oppdrag... 8 1.4.1 Oppdragsgiver... 8 1.4.2 Opprett oppdrag... 9 1.4.3 Slett oppdrag... 19 1.4.4 Hjelper...

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

Gruppe 33 - Hovedprosjekt

Gruppe 33 - Hovedprosjekt Gruppe 33 - Hovedprosjekt s188080 Joakim Rishaug s181130 Sondre Sparby Boge s188098 Martin Hagen s178816 Lars Erik Kasin 1 av 7 Kravspesifikasjon Forord Kravspesifikasjonen utformes både for kunden, og

Detaljer

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

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

Detaljer

2013 Aditro AS 1 (24)

2013 Aditro AS 1 (24) 1.0. Rutine for Altinn innsending og Altinn retur... 2 1.1. Om Altinn... 2 1.2. Roller og rettigheter i Altinn... 2 1.3. Opprette datasystem-id og passord i Altinn.... 4 1.4 Sette opp Huldt & Lillevik

Detaljer

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

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

Detaljer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

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

Detaljer

Brukermanual for Norwex Norge AS nettbutikk

Brukermanual for Norwex Norge AS nettbutikk Brukermanual for nettbutikk Innhold 1. Innledning 2. Hvordan handler du som ekstern kunde? 3. Hvordan går du frem for å komme i gang med din nettbutikk? 4. Hva skjer når tilfeldige kunder handler tilknyttet

Detaljer

Kandidat nr. 1, 2 og 3

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

Detaljer

Brukermanual. Versjon 1.3.5. Copyright 2002 Devinco AS

Brukermanual. Versjon 1.3.5. Copyright 2002 Devinco AS Brukermanual Versjon 1.3.5 Copyright 2002 Devinco AS Manual SpeedyCraft Client 1. utgave, mai 2003 (V 1.3.5) Devinco AS Dersom du har kommentarer, ønsker eller synspunkter ang. denne manualen, vennligst

Detaljer

1.0 Funksjonalitet for medarbeidere i fanen Min Info... 2. 1. 1 Status... 2. 1.1.1 Sende melding om ferdig registrering... 2 1.2 CV...

1.0 Funksjonalitet for medarbeidere i fanen Min Info... 2. 1. 1 Status... 2. 1.1.1 Sende melding om ferdig registrering... 2 1.2 CV... Dossier Kompetanse Innholdsfortegnelse 1.0 Funksjonalitet for medarbeidere i fanen Min Info... 2 1. 1 Status... 2 1.1.1 Sende melding om ferdig registrering... 2 1.2 CV... 3 1.2.1 Personalia... 3 1.2.2

Detaljer

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

BRUKERMANUAL. Deviations and Reporting

BRUKERMANUAL. Deviations and Reporting BRUKERMANUAL Deviations and Reporting Forord Dette er brukermanual for CEMAsys Immediate Reporting applikasjon som er laget for iphone og Android telefoner. CEMAsys Immediate Reporting er en applikasjon

Detaljer

Elsmart Brukerveiledning Nettmelding for Installatører

Elsmart Brukerveiledning Nettmelding for Installatører Elsmart Brukerveiledning Nettmelding for Installatører Nettmelding Brukerveiledning Generell 0.5.doc Side 1 av (26) Innledning Dette er den generelle brukerveiledningen til Elsmart Nettmelding. Denne veiledningen

Detaljer

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

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

Detaljer

SQUARE Systemspill for online spill på hest Brukerveiledning

SQUARE Systemspill for online spill på hest Brukerveiledning SQUARE Systemspill for online spill på hest Brukerveiledning Innholdsfortegnelse INNLEDNING... 3 BETINGELSER... 4 HOVEDSIDEN... 5 VELG SPILLE OBJEKT... 6 SPILLETYPE... 6 SYSTEM... 6 BANE... 6 LØPSDATO...

Detaljer

OKOK. 2012 DataPower Learning AS Administrasjon 1

OKOK. 2012 DataPower Learning AS Administrasjon 1 OKOK 2012 DataPower Learning AS Administrasjon 1 Administrasjon DataPower Learning Online inneholder en administrasjonsdel som kan brukes for å administrere brukere og kurs. For at et kurs skal være tilgjengelig

Detaljer

Visma CRM Nyheter og forbedringer Side 1

Visma CRM Nyheter og forbedringer Side 1 Visma CRM Nyheter og forbedringer Side 1 NYHETER OG FORBEDRINGER Visma CRM Nyheter og forbedringer Side 2 Oslo, juni 2011 1. Sirkulasjon All informasjon i dette dokumentet kan endres uten varsel og innebærer

Detaljer

1 INNLEDNING... 2. 1.1 Om Altinn... 2. 1.2 Skjemaer som støttes... 2 2 INSTALLASJON OG OPPSTART... 3. 2.1 Nedlasting... 3. 2.2 Registrering...

1 INNLEDNING... 2. 1.1 Om Altinn... 2. 1.2 Skjemaer som støttes... 2 2 INSTALLASJON OG OPPSTART... 3. 2.1 Nedlasting... 3. 2.2 Registrering... INNHOLD Mamut for Altinn INNHOLD 1 INNLEDNING... 2 1.1 Om Altinn... 2 1.2 Skjemaer som støttes... 2 2 INSTALLASJON OG OPPSTART... 3 2.1 Nedlasting... 3 2.2 Registrering... 5 2.3 Opprett en bruker... 7

Detaljer

11.0.0 W i n T i d. Nyheter versjon 11.0.0 og Dashboard versjon 4.0.0 Logica Norge AS

11.0.0 W i n T i d. Nyheter versjon 11.0.0 og Dashboard versjon 4.0.0 Logica Norge AS 11.0.0 W i n T i d Nyheter versjon 11.0.0 og Dashboard versjon 4.0.0 Logica Norge AS Innholdsfortegnelse 1. OM DOKUMENTET... 4 1.1 DOKUMENTETS MÅLSETNING... 4 1.2 HVEM ER DOKUMENTET SKREVET FOR?... 4 1.3

Detaljer

Brukerdokumentasjon. Webservices og webklient for kodeverk/ kodeverdi verifisering

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

Detaljer

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011

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

Detaljer

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

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1 1 FORORD Dette dokumentet er brukerveiledningen, og skal være en veiledning

Detaljer

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

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

Detaljer

Verktøy for boligkartlegging

Verktøy for boligkartlegging Verktøy for boligkartlegging Rapporter Versjon 3.0 Opprettet 15.05.2005 av Pål Guddal Sist endret 23.01.2007 av André Teig Bli kjent med Bokart- Rapporter Side 2 Hva er filter, og hva brukes de til? Filter

Detaljer

Verktøy for boligkartlegging

Verktøy for boligkartlegging Verktøy for boligkartlegging Rapporter. Versjon 2 Helse og Velferd - Norge Stasjonsgata 37, NO-1820 Spydeberg - Tlf: + 47 90 12 45 50, Faks: + 47 69 83 87 10 - www.tietoenator.com Bli kjent med Bokart-

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

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

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

BAAN IVc. BAAN Data Navigator - Brukerhåndbok

BAAN IVc. BAAN Data Navigator - Brukerhåndbok BAAN IVc BAAN Data Navigator - Brukerhåndbok Utgitt av: Baan Development B.V. P.O.Box 143 3770 AC Barneveld The Netherlands Trykt i Nederland Baan Development B.V. 1997. Med enerett. Informasjonen i dette

Detaljer

MindIT sin visjon er å være en anerkjent og innovativ leverandør av teknologi og tjenester i den globale opplæringsbransjen

MindIT sin visjon er å være en anerkjent og innovativ leverandør av teknologi og tjenester i den globale opplæringsbransjen If you think education is expensive... try ignorance! MindIT sin visjon er å være en anerkjent og innovativ leverandør av teknologi og tjenester i den globale opplæringsbransjen Styrende verdier i MindIT:

Detaljer

4. Varemottak DFØ. Versjon: 1.1 4.1 Utføre varemottak 04.04.13. Innhold

4. Varemottak DFØ. Versjon: 1.1 4.1 Utføre varemottak 04.04.13. Innhold 4. Varemottak DFØ Versjon: 1.1 4.1 Utføre varemottak 04.04.13 Innhold 1 Utføre varemottak/annullere bestilling 2 Endre data/legge til interne kommentarer før mottak av varen 3 Registrere klage/søk på klage

Detaljer

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO

Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Eksamen 2012 INF1050 Lars- Martin Hejll Universitetet i OSLO Høgskolen i Telemark 2 Lars- Martin Hejll Høgskolen I Telemark Oppgave 1 Spørsmål fra pensum (20%) 1. Nødvendige aktiviteter i systemutvikling:

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

Guide til system for flervalgsprøver

Guide til system for flervalgsprøver Guide til system for flervalgsprøver Systemet skal i utgangspunktet være selvforklarende, og brukere oppfordres til å klikke seg rundt og bli kjent med systemet på egen hånd. Det er allikevel laget en

Detaljer

STE6221 Sanntidssystemer Løsningsforslag

STE6221 Sanntidssystemer Løsningsforslag HØGSKOLEN I NARVIK Avdeling for teknologi MSc.-studiet EL/RT Side 1 av 3 STE6221 Sanntidssystemer Løsningsforslag Tid: Fredag 02.03.2007, kl: 09:00-12:00 Tillatte hjelpemidler: Godkjent programmerbar kalkulator,

Detaljer

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 2. juni 2014 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 4 sider Vedlegg: Ingen Tillatte hjelpemidler:

Detaljer

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

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

Detaljer

Brukerdokumentasjon for Administrator og andre brukere fra PT

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

Detaljer

Brukermanual for Central Løssalg Planogramsystem Denne manualen gir en hurtig innføring i Central Løssalg - Planogramsystem og dens funksjoner

Brukermanual for Central Løssalg Planogramsystem Denne manualen gir en hurtig innføring i Central Løssalg - Planogramsystem og dens funksjoner Brukermanual for Central Løssalg Planogramsystem Denne manualen gir en hurtig innføring i Central Løssalg - Planogramsystem og dens funksjoner Laboremus Oslo AS // St. Olavs gate 12, 0165 Oslo, Norway

Detaljer

Bytte til OneNote 2010

Bytte til OneNote 2010 I denne veiledningen Microsoft OneNote 2010 ser helt annerledes ut enn OneNote 2007, så vi har laget denne veiledningen for å gjøre det så enkelt som mulig for deg å lære forskjellene. Les videre for å

Detaljer

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress Sist oppdatert 05.06.2015 Innholdsfortegnelse 1. Hva er Wordpress?... 3 2. Hvordan logger jeg inn i kontrollpanelet?...

Detaljer

Rapportene i Xakt... 5. Rapportmenyen... 5 Filtrering (utvelging)... 5 Sortering... 5 Rapportmenyen... 6. Kunder... 6

Rapportene i Xakt... 5. Rapportmenyen... 5 Filtrering (utvelging)... 5 Sortering... 5 Rapportmenyen... 6. Kunder... 6 i Xakt Innhold Innhold Rapportene i Xakt... 5 Rapportmenyen... 5 Filtrering (utvelging)... 5 Sortering... 5 Rapportmenyen... 6 Kunder... 6 Adresseliste... 6 Telefonliste... 6 Etiketter... 6 Aldersfordelt

Detaljer

Utplukk og sortering. Innhold

Utplukk og sortering. Innhold Innhold Utplukk og sortering... 2 Definering av utplukk... 2 Velge felter for utplukket... 2 Filtrering og søk på tilgjengelige databasefelter... 3 Endre databasekobling etter at felt er valgt... 7 Valg

Detaljer

Administrasjon Nettbutikk: www.dittdomene.com/administrasjon Bruk brukernavn og passord som er sendt på e-post.

Administrasjon Nettbutikk: www.dittdomene.com/administrasjon Bruk brukernavn og passord som er sendt på e-post. Administrasjon Nettbutikk: www.dittdomene.com/administrasjon Bruk brukernavn og passord som er sendt på e-post. - Konfigurasjon Klikk på Konfigurasjon i menyen helt til venstre, og deretter Min butikk.

Detaljer

AP226 Use Case Diagram - SBL

AP226 Use Case Diagram - SBL AP226 Use Case Diagram - SBL Use Case Diagram Figuren under (Figur 1) viser en oversikt over alle use case for Sluttbrukerløsningen i Altinn 2 versjon 1. Den innerste firkanten inneholder alle use case

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

Beskrivelse av skjermbilder og funksjoner i PayBack SingelUser.

Beskrivelse av skjermbilder og funksjoner i PayBack SingelUser. Beskrivelse av skjermbilder og funksjoner i PayBack SingelUser. 00. PayBack startes ved innlogging til Zylin's webserver. Brukernavn og passord er satt opp etter informasjonen fra webformularet. Adressen

Detaljer

PROEX.NO. En webbasert samhandlingsløsning. Utviklet av Eskaler as. Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger

PROEX.NO. En webbasert samhandlingsløsning. Utviklet av Eskaler as. Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger PROEX.NO En webbasert samhandlingsløsning. Utviklet av Eskaler as Rogaland Kunnskapspark Postboks 8034 Postterminalen 4068 Stavanger Telefon: 51 87 48 50 Fax: 51 87 40 71 Dette dokumentet inneholder en

Detaljer

Oppgradering WMS og PLS

Oppgradering WMS og PLS Oppgradering WMS og PLS Lageret til Midtunbygget Varehotell ble bygget for Vinmonopolet på åttitallet. Leverandør for automatlageret var den gang Munck Autech Technology. Lageret består av fire reolganger

Detaljer

Mamut Enterprise Travel CRM

Mamut Enterprise Travel CRM Mamut Enterprise Travel CRM Tilleggsproduktet Mamut Enterprise Travel CRM gir deg muligheten til å ta med deg arbeidet på en bærbar datamaskin ut av kontoret. Du arbeider da på en kopi av den sentrale

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

KONTROLL INSIDE MSOLUTION

KONTROLL INSIDE MSOLUTION KONTROLL INSIDE MSOLUTION Forandre renholdsteam eller renholdsdager på oppdrag I denne brukerveiledningen skal vi bruke bytte renholdsdager. Det skjer jo at vi bytter renholdsdager eller team på kunder.

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

Mamut Enterprise Telefonkatalogen Online

Mamut Enterprise Telefonkatalogen Online Mamut Enterprise Telefonkatalogen Online Med Mamut Enterprise Telefonkatalogen Online kan du hente inn og oppdatere kontaktinformasjon fra Telefonkatalogen 1880 online. Ved å oppdatere blant annet navn,

Detaljer

Nyheter i Office 2016 NYHETER, FUNKSJONER, FORKLARING

Nyheter i Office 2016 NYHETER, FUNKSJONER, FORKLARING Nyheter i Office 2016 NYHETER, FUNKSJONER, FORKLARING 1 Word 1.1 Gjør ting raskt med Fortell meg det Du vil legge merke til en tekstboks på båndet i Word 2016 med teksten Fortell meg hva du vil gjøre.

Detaljer

Kommuneforlaget Avvikshåndtering Administratordokumentasjon Versjon 2.1.0 Table of Contents

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

Detaljer

Fakturabehandling på web

Fakturabehandling på web Visma Enterprise Fakturabehandling Versjon 2009.2 Fakturabehandling på web II Kurs fra Visma Unique Visma Unique sin opplæringsvirksomhet har som mål å gi deg muligheten for en systematisk og grundig systemopplæring

Detaljer

Veileder for boligeier: Hvordan søke om støtte til energirådgiving og oppgradering av bolig

Veileder for boligeier: Hvordan søke om støtte til energirådgiving og oppgradering av bolig Veileder for boligeier: Hvordan søke om støtte til energirådgiving og oppgradering av bolig Velkommen som søker på Enovas tilbud til boligeiere! Denne veilederen beskriver framgangsmåten for å søke om

Detaljer

Endelig!! WEB påmelding og betaling i DogWeb-Arra, utstilling!

Endelig!! WEB påmelding og betaling i DogWeb-Arra, utstilling! DogWeb Arra NKKs system for arrangører! Endelig!! WEB påmelding og betaling i DogWeb-Arra, utstilling! Innhold Hvordan begynne å bruke elektronisk påmelding!... 3 Sjekke priser, klasser i DogWeb-Arra....

Detaljer

TDT4102 Prosedyre og Objektorientert programmering Vår 2014

TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Norges teknisk naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Øving 10 Frist: 2014-04-11 Mål for denne øvinga:

Detaljer

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

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

Detaljer

Første bestilling av kurs

Første bestilling av kurs DataPower Learning Online Første bestilling av kurs for bedriftskunder Versjon 2.x OKOKOK 1 Bestilling Finn aktuelt kurs For å finne det kurset du er på utkikk etter, kan du enten søke i søkefeltet eller

Detaljer

Skriverkontrollprogrammet MarkVision

Skriverkontrollprogrammet MarkVision Skriverkontrollprogrammet MarkVision Skriverprogram og verktøy 1 MarkVision for Windows 95/98/2000, Windows NT 4.0 og Macintosh leveres med skriveren på CDen Drivers, MarkVision and Utilities. Det grafiske

Detaljer

Installasjonsveiledning Visma Avendo, versjon 5.2

Installasjonsveiledning Visma Avendo, versjon 5.2 Installasjonsveiledning Visma Avendo, versjon 5.2 April 2011 Innhold Innledning... 1 Administrator... 1 Sikkerhetskopi... 1 Testfirmaet... 1 Før du starter installasjonen/oppgraderingen... 2 Nedlasting...

Detaljer

Retningslinjer for etwinning-verktøy

Retningslinjer for etwinning-verktøy Retningslinjer for etwinning-verktøy Registrer deg til etwinning Første trinn: opplysninger om registrator Andre trinn: samarbeidspreferanser Tredje trinn: opplysninger om skolen Fjerde trinn: skolens

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

SOLICARD ARX. Adgangssystemet som gir deg ubegrenset frihet. An ASSA ABLOY Group company

SOLICARD ARX. Adgangssystemet som gir deg ubegrenset frihet. An ASSA ABLOY Group company SOLICARD ARX Adgangssystemet som gir deg ubegrenset frihet An ASSA ABLOY Group company SOLICARD ARX arkitektur SOLICARD ARX LCU oppkoblet via Internet Eksisterende nettverk SOLICARD ARX AC SOLICARD ARX

Detaljer

Hoved fokus for denne App n:

Hoved fokus for denne App n: Novapoint GO Navigering og oppfølging på anlegg Geir Andersen. Jarle Dawes og Heidi Berg Brukermøte 2011 Hoved fokus for denne App n: Byggeledere, kontrollingeniører, prosjektingeniører, anleggsledere

Detaljer

Kort veiledning for avsendere og hentesteder

Kort veiledning for avsendere og hentesteder Kort veiledning for avsendere og hentesteder Side 1 Innholdsfortegnelse Innholdsfortegnelse Kort veiledning for avsender/hentested, ver 6.0 Daglige Oppgaver Før henting (korriger mengder) Legge inn merknader

Detaljer

Brukerguide for www.altadykkerklubb.com

Brukerguide for www.altadykkerklubb.com Brukerguide for www.altadykkerklubb.com Utgitt første gang: 27/09-07 Sist oppdatert: 23/03-09 1 Innledning Dette er den nye siden til Alta Dykkerklubb! Den er blitt laget over et system som gjør det mulig

Detaljer

Med nye TINE Handel får du som kunde nytte og glede av følgende funksjoner:

Med nye TINE Handel får du som kunde nytte og glede av følgende funksjoner: Velkommen til nye TINE Handel! Vi har oppgradert TINE Handel med ny og bedre handelsfunksjonalitet, et bedre handelsløp og mange nye funksjoner og forbedringer. I tillegg har nettsiden tinepartner.no blitt

Detaljer

Humanware. Trekker Breeze versjon 2.0.0.

Humanware. Trekker Breeze versjon 2.0.0. Humanware Trekker Breeze versjon 2.0.0. Humanware er stolte av å kunne introdusere versjon 2.0 av Trekker Breeze talende GPS. Denne oppgraderingen er gratis for alle Trekker Breeze brukere. Programmet

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

SiteGen CMS. Innføringsmanual

SiteGen CMS. Innføringsmanual SiteGen CMS Innføringsmanual Copyright Barlind Solutions AS 2008 Hva er SiteGen CMS? SiteGen CMS er et såkalt content-management-system; eller med litt andre ord et publiseringssystem. Det kan brukes til

Detaljer

Webfaktura slik bruker du det. for sluttbrukere

Webfaktura slik bruker du det. for sluttbrukere Webfaktura slik bruker du det for sluttbrukere 24.06.2013 Innhold: Beskrivelse av Webfaktura... 3 Generelt... 3 Pålogging... 3 Første gangs pålogging... 3 Mitt firma... 3 Min bruker... 4 Vedlikehold av

Detaljer

Derfor er forretningssystemet viktig for bedriften

Derfor er forretningssystemet viktig for bedriften Innhold Derfor er forretningssystemet viktig for bedriften... 2 Når er det på tide å bytte forretningssystem?... 2 Velg riktig forretningssystem for din bedrift... 3 Velg riktig leverandør... 4 Standard

Detaljer

MinTid web brukerdokumentasjon

MinTid web brukerdokumentasjon 5.4.0 MinTid web brukerdokumentasjon Logica Norge AS 3.1.0 MinTid brukerdokumentasjon i Innhold MinTid 1 Generelt... 1 Hvem skal bruke MinTid og hva kan gjøres?... 1 Standardfunksjoner i MinTid... 1 Logg

Detaljer

Slå BRUKERVEILEDNING AMESTO BUSINESS SEARCH DATO: 26.03.14

Slå BRUKERVEILEDNING AMESTO BUSINESS SEARCH DATO: 26.03.14 Slå BRUKERVEILEDNING AMESTO BUSINESS SEARCH DATO: 26.03.14 INNHOLD GENERELT... 3 SØKE ETTER FIRMA... 4 Søkekriterier... 4 Søk... 6 SE PÅ SØKERESULTAT... 7 BEHANDLE SØKERESULTAT... 10 Oppdatere en bedrift

Detaljer

1. Intro om SharePoint 2013

1. Intro om SharePoint 2013 Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Intro om SharePoint 2013 Stein Meisingseth 09.08.2013 Lærestoffet er utviklet for faget LO205D Microsoft SharePoint 1. Intro om SharePoint

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

INF5120 Oblig 2 - Timeregistreringssystem Gruppe 25 Annette Kristin Levine Nils-Kristian Liborg Unni Nyhamar Hinkel

INF5120 Oblig 2 - Timeregistreringssystem Gruppe 25 Annette Kristin Levine Nils-Kristian Liborg Unni Nyhamar Hinkel INF5120 Oblig 2 - Timeregistreringssystem Gruppe 25 Annette Kristin Levine Nils-Kristian Liborg Unni Nyhamar Hinkel 2-1 Business Model 2-1 a) Scoping statements I Våre avgrensninger Timeregistreringssystemet

Detaljer

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

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

Detaljer

Introduksjon til Vega SMB 2012

Introduksjon til Vega SMB 2012 Introduksjon til Vega SMB 2012 Side 1 av 15 Introduksjon til Vega SMB Velkommen som bruker av Vega SMB. Klikk på Vega ikonet for å starte Vega SMB første gang. Velg ditt brukernavn og skriv inn passord

Detaljer

Pedagogisk regnskapssystem

Pedagogisk regnskapssystem av Benjamin Dehli og Jørgen Tellnes Innhold 1 Innledning 2 Om forprosjektet 2.1 Forprosjektgruppen 2.2 Målsetninger med forprosjektet 3 Beskrivelse av hovedprosjektet 3.1 Arbeidstittel 3.2 Prosjektgruppe

Detaljer

INF 2120 Innlevering 1. Gruppe 4. Kravspesifikasjoner til trafikanten +

INF 2120 Innlevering 1. Gruppe 4. Kravspesifikasjoner til trafikanten + INF 2120 Innlevering 1 Levert av Gruppe 4 Anders Bakken (andeba) Are O. Pedersen (arep) Daniel M. Wittwer (danielmw) Naima Akram (naimaa) Ronnie Østgaard (ronnieo) Kravspesifikasjoner til trafikanten +

Detaljer

1. Generelt. FM-OA, Kompletterende undervisning. 1.1. Innledning. 1.2. Stikkord. 1.3. Prosessen. Spec 2, datert 12.12.2005

1. Generelt. FM-OA, Kompletterende undervisning. 1.1. Innledning. 1.2. Stikkord. 1.3. Prosessen. Spec 2, datert 12.12.2005 1. Generelt 1.1. Innledning Det skal utvikles en databasert løsning for å lette arbeidet rundt tilskudd til kompletterende undervisning i fagene norsk, samfunnsfag og kristendomskunnskap med religions-

Detaljer

Rollebasert tilgangskontroll i TakeCargo WEB (RBAC Role Based Access Controll)

Rollebasert tilgangskontroll i TakeCargo WEB (RBAC Role Based Access Controll) Brukerveiledning Rollebasert i TakeCargo WEB (RBAC Role Based Access Controll) Konfigurering av organisasjonsstruktur, organisasjonsenheter, brukere og bruker, samt hvilke roller de skal spille. Tilgang

Detaljer