S Y S T E M U T V I K L I N G ( L O A )

Størrelse: px
Begynne med side:

Download "S Y S T E M U T V I K L I N G ( L O 1 3 8 A )"

Transkript

1 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 P R O S J E K T R A P P O RT S Y S T E M U T V I K L I N G ( L O A ) H Ø S T 2011 GRUPPE 24: Forfattere: s171633, Truc Tran s171171, My Trang Ho Tran s169998, Christian Andreas Lysaker s169999, Amund Løchen Dato: SAMMENDRAG Selskapet Domaining AS eier mer enn domenenavn, men har idag ingen egen nettbutikk for for av sine domenenavn. Selskapet mange tusen besøkende daglig og bruker idag mesteparten av tiden blant annet til å besvare henvendelser som de ikke tjener penger på og som stjeler nesten all tiden til de ansatte som egentlig skal aktivt selge. Selskapet har derfor besluttet at de må få utviklet sin egen nettbutikk, og ønsker i den forbindelse konsulent bistand.

2 I N N H O L D 1 INTRODUKSJON BAKGRUNN MÅL FOR PROSJEKTET OMFANG AV LØSNING SUKSESSKRITERIA ANTAGELSER TILPASNING AV UTVIKLINGSMODELL BESKRIVELSE AV UTVIKLINGSMODELL BEGRUNNELSE FOR TILPASNINGER ANALYSE KRAVSPESIFIKASJON USE CASE MODELL Use case diagram Detaljerte Use case beskrivelser DOMENEMODELL AKTIVITETSDIAGRAM DESIGN KLASSEDIAGRAM SEKVENSDIAGRAM LOGISK ARKITEKTUR BRUKERGRENSESNITT VURDERING VURDERING AV FORESLÅTT LØSNING VURDERING AV VALG UTVIKLINGSMODELL VURDERING AV EGET PROSJEKTARBEID KONKLUSJON LITTERATURLISTE VERSJONSLOG Versjon Dato Forfatter(e) Beskrivelse av versjon V Truc, My Trang, Amund, Christian V Truc, My Trang, Amund, Christian V Truc, My Trang, Amund, Christian Leveranse del 2: Introduksjon, Use case modell, detaljert analyse, oppdatering av prosjekt plan Leveranse del 3: Modellering, UP modellen, oppdatering av prosjekt plan Leveranse del 4: Modellering, Vurdering av prosjektet. Hele rapporten 2

3 1 INTRODUKSJON 1.1 BAKGRUNN Gruppen har valgt å skrive for selskapet DomainingAS Domaining AS eier idag mer enn domenenavn. Selskapets hovedinntekter kommer fra salg av domener, men selskapet har idag ingen egen nettbutikk for salg av domenene. Domenene blir idag solgt gjennom andre nettsteder og eksterne agenter som selger på provisjon. Når kundene idag skriver inn et domene som selskapet eier så blir adressen forwardet slik at de kommer til siden domaining.no. På domainning.no ligger det idag et kontaktskjema som interessenten må fylle en forespørsel for å sende en henvendelse til Domaining AS. Type forespørsel kan være pris, bud, samarbeid eller annet. Selskapet har idag ca besøkende i måneden til alle sine domener, og det kommer ca 500 reelle henvendelser i måneden. Mesteparten av tiden brukes til å besvare prisforespørsler og diskutere bud som kommer inn. Mengden besvarelser som man regner med dialog blir ca i måneden. Domaining AS viser idag ikke priser på sine domener. Interesenter må kontakte for å vite prisen. Det blir nesten som å gå inn i en butikk hvor det er masse varer men uten en eneste prismerke. Selskapet har kommet frem til at de må sette en pris på alle sine domener for få redusert antall prisforespørsel slik at man kan bruke mer tid på aktiv salg. Selskapet har månedlig ca 15 såkalte passive salg som kommer ifra inngående forespørsel fra kjøper. Dette tallet synes selskapet er for lavt og lite effektivt i forhold til antall timer som brukes til å svare på maildialog og salgsforhandlinger. Selskapet har tro på at man skal kunne doble dagens salgstall, derfor ønsker selskapet å få til en mer effektiv løsning, slik at man kan få frigitt mye av denne tiden slik at man kan bruke det til å drive med aktiv salg av domener. Domaining AS har med denne bakgrunn bestemt seg for å etablere en nettbutikk slik at interessenter selv kan se hvilke domener selskapet har samt enklere kunne gå inn i nettbutikken og kjøpe domene til oppsatt pris. 3

4 1.2 MÅL FOR PROSJEKTET Det skal lages en nettbutikk løsning for salg av eksisterende domenenavn. Delmål: 1. Løsningen skal redusere tidsbruken på å besvare prisforespørsler med 75%. 2. Løsningen skal frigi tid slik at ansatte skal kunne bruke 50% av tiden på aktiv salg. 3. Løsningen skal øke antall salg av domener med 100%. Ferdig prosjekt skal presenteres oppdragsgiver 25.november OMFANG AV LØSNING Med utgangspunkt i bakgrunnen og mål så skal her beskrive nærmere omfanget av hva løsningen som Domaining AS skal få levert. Det finnes idag flere forkjellige nettsteder som selger domener på annenhåndsmarkedet. Vi vil i dette prosjektet ha fokus på en løsning som dekker primærbehovet til Domaining AS. Salgsted på internett: Det skal lages en domenenettbutikk som skal åpen for alle på internett. Nettbutikken skal være en katalog som viser alle domener selskapet har for salg. Det vil være behov for å kategoriere innholdet inn i både kategorier slik at det er mulig å finne frem og få solgt relaterte domener også. Fokus på brukervennlighet: Nettbutikken skal være intuitivt og enkelt for kunder finne frem og foreta kjøpet. Dette er viktig slik at vi slipper å miste kunder fordi de ikke forstår hvordan de skal få fullført handelen, og for å slippe en del support. Database og søkefunksjon: Når en bruker skriver inn et av domenene som Domaining AS har for salg skal de bli overført til nettbutikken Domaining.no, hvor man får vite salgsinformasjon om at domenet er. Med tanke på at det er mer enn domener, så vil det være enorme datamengder vil være behov for en løsning som har alle data lagret i en database. Data må gjøres søkbare ved å omfatte søkefunksjon. Både selger og kunder skal kunne søke etter domenene som ligger i nettbutikken Administrasjonsfunksjon: I nettbutikken vil det forløpende endringer i varebeholdingen. Det vil være behov for å legge til nye domener som selskapet har kjøpt inn for salg, det vil være behov for å endre på priser og annet informsjon, og slette domener som selskapet har solgt. I den forbindelse vil være nødvendig med et administrasjonssystem, og her ser vi det naturlig at det er webbasert 4

5 innloggingsløsning for administratorer, slik at man kan logge inn og utføre endringene. Løsningen skal også gi selgere tilgang til å administrere informasjon rundt domener som skal selges. Betalingsløsning er en viktig del i alle handelsløsninger på internett, og det finnes mnage løsninger og leverandører. Betalingsløsning er også viktig i en nettbutikk løsning for Domaining AS, men vi vil i dette prosjektet ikke utrede nærmere om dette da Domaining AS allerede benytter tjenester fra Paypal og ønsker å fortsette med det. 1.4 SUKSESSKRITERIA Viktige kriterier for å lykkes med prosjektet er: Gruppen må fra start sørge for å jobbe tett med oppdragsgiver og definere problemstillingen, og ha klart definert hva kunden ønsker løsning på. Prosjektmedlemmene planlegger og følger tidsplan med sin del for å unngå forsinkelser. Analysere og diskutere definerte problemstillinger. Fortløpende diskusjoner med forkjellige personer for å få problemer og løsninger vurdert fra flere. Vi skal ikke oppfinne noe på nytt her. Det finnes mange forskjellige løsninger allerede i markedet som vi kan analysere og bruke det som grunnlag når vi skal lage ny nettbutikk for Domaining AS. Det er andre personer som kan gi oss svar på en del feil som er gjort fra før. Sjekk med disse personene. Sjekk på internett om informasjon. Bruke tid sammen med kunden på å analysere sluttkunden/kjøpers kjøpsatferd, slik at vi kan designe og tilpasse løsningen mest mulig passende. 1.5 ANTAGELSER I dette prosjektet vil vi kun ta for oss webshopløsning for salg av eksisterende domener som en enkel vare og ikke websider med innhold tilknyttet til domenet. Ingen hosting tjenester. Prosjektet tar ikek for seg de praktiske og juridiske prosesser som skjer overføring av domener melleom to parter Prosjektet vil ikke ta for seg prosesser som fornyelse av domener. Dette er noe som oppdragsgiver og deres kunder benytter domeneregistrarer til. Ingen utredning av betalingsløsninger, men bruk av eksisterende løsninger fra Paypal. Domaining AS vil selv sørge for å følge opp med prosjektgruppen om de faglige prosessene i deres forretningsvirksomhet. 5

6 2 TILPASNING AV UTVIKLINGSMODELL 2.1 BESKRIVELSE AV UTVIKLINGSMODELL Med oppgaven som vi har fått, skal vi i dette prosjektet ta i bruk en utviklingsmodell. Modellen vi skal benytte er en UP modell som står for Unified Process. Unified Process er et utviklingsverktøy for programutvikling. Den er blitt mye brukt siden 90-tallet og baserer jeg på å utføre forskjellige arbeidsoppgaver til forskjellige tider. I UP modellen består det av: Faser: Idefasen, utdypningsfasen, konstruksjonsfasen og overgansfasen. Disipliner: Forretningsmodellering, kravspesifisering, design, analyse, implementering, testing, idriftsettelse, konfigurasjonsstyring og endringshåndtering, prosjektstyring og utviklingsmiljø (hentet informasjonen fra Applying UML and Patterns kapittel 2.11 Figur 2.7). Hver av disse fasene bygger på arbeidet som er blitt utført i forrige fase og utvikler programmet til et brukbart produkt. Det som er spesielt med UP er at den lar oss utvikle løsningen et steg om gangen, for så å kunne gå tilbake senere å gjenvurdere det vi allerede har gjort i prosjektet og endre på det. Hadde vi benyttet fossefallsmetoden ville vi ikke kunnet gått tilbake og endret på ting i prosjektet. I UP modellen vår har vi valgt å fokusere idefase, fordypningsfase og konstruksjonsfase. Mens i disiplinene har vi da valgt å kun ta med planlegging, analyse og design. Mer forklaring om modellen vår kommer under kapittel 2.2 Begrunnelse for Tilpasninger. 2.2 BEGRUNNELSE FOR TILPASNINGER Vi har valgt å fokusere oss på de 3 første fasene som er idefasen, fordypningsfasen og konstruksjonsfasen. Her har vi ikke tatt med overgangsfasen, fordi prosjektet har et kort tidsrom at det er ikke mulighet til å bruke tid på programmering eller koding som det egentlig skulle være i overgangsfasen. På grunn av kort tidsrom har vi kun mulighet til å utføre disiplinene planlegging, analyse og design. Under her vil vi liste opp aktiviteter og gjøremål i de forskjellige fasene og disiplinene. 6

7 Figur: UP Modell (Unified Process) Disiplinene som vi har valgt: Planlegging: Brainstorming av prosjektet, finne ut hva prosjektet skal inneholde og handle om. Finne en problemstilling. Fordeling av arbeidsoppgave i gruppen. Analyse: Jobbe utifra kravene og forme et system utifra det. Analysere prosjektet via å lage forskjellige modeller som Use Case-modell, domene modell, aktivitetsdiagram, klasse diagram og sekvensdiagram. Design: Logisk arkitektur og brukergrensesnitt. Idefasen Denne fasen her består først og fremt å finne grensene for prosjektet og finne kravene til brukerne. Det vil bli vurdert risiko, kostnader og prosjektets sponsor gir sin tilslutning. Her skal vi lage et brukervennlig betalingssystem for Domaning AS. Kunden skal kunne gå inn i dette system og kunne velge seg fram til systemet og velge en eller flere domener som de vil kjøpe. Det skal samtidig være enkel og lett for Domaning AS å kunne følge med hvor mye trafikk de har om dagen, og hvor ofte folk er innom og klikker på siden. I denne fasen vil vi benytte Iterasjon 1 (IT1) her vil det være mer planlegging,men lite analyse og design (se på modellen ovenfor). 7

8 Iterasjon 1 (IT1): Planlegging Krav og målsetting Prosjektetbeskrivelge og omfang Utviklingsmodell Vurdere risiko og kostnader Use case modell Fordypningsfasen Denne fasen her vil vi gå nærmere inn på de funksjonelle egenskapene som systemet skal ha. Hva skal systemet tilby. Systemet skal håndtere domene bestillingene. Kunden skal kunne handle varer via systemet. Kunden må registrere seg og ha en Paypal konto fra før. Admin skal kunne endre, slette og legg til domene i systemet. De skal også kunne ha oversikt over produktene. I denne fasen vil vi benytte iterasjon 2 og 3 (IT 2 og IT3) og fokusere mer på analyse, mindre på planlegging og design. Iterasjon 2 (IT2): Replanlegging Use case modell Detaljert kravspesifikasjon Overordnet analyse Domene modell Iterasjon 3 (IT3) Replanlegging Domene modell Aktivitets diagram Klasse diagram Sekvensdiagram Brukergrensesnitt Konstruksjonsfasen Vanligvis i konstruksjonsfasen så er ofte noe av delproduktene ferdig dokumentert, testet og integrert. Men på grunn av begrenset tid og ressurser vil ikke systemet bli implementert og programmet vil ikke bli testet. Se nærmere på designet av prosjektet. Få tak i noen bruker som kan teste produktet ved å fortelle dem om hvordan systemet fungerer å få tilbakemelding på det. 8

9 I denne fasen vil vi benytte iterasjon 4 og 5 (IT 4 og IT5) og fokusere mer på design, mindre på planlegging og analyse. Iterasjon 4 (IT4): Replanlegging Logisk arkitektur Brukergrensesnitt Gjenvurdere risiko og kostnad Iterasjon 5 (IT5): Komplett rapport Vurdering av prosjektet Kvalitetsikre Overgansfasen Ferdigstille prosjektet. Det vil bli utført Beta testing og innføring, kvalitetstesting og opplæring av brukere. Når systemet er ferdig vil det bli utlevert til arbeidsgiveren. Her har vi ikke tatt med overgangsfasen på grunn av begrenset tid og ressurser har gruppen vår ikke mulighet til å lage et ferdig produkt, men kun tatt med litt teori i overgangsfasen. 9

10 3 ANALYSE 3.1 KRAVSPESIFIKASJON Kortfattet og oversiktlig beskrivelse av funksjonelle og ikke-funksjonelle krav til løsingen. Funksjonelle: 1. Åpen nettside som viser alle domenenavn som ligger i webshopen. 2. Søkefunksjon slik at kjøper kan søke i iflg alfabetet, kategorier. 3. For å kunne handle ting på nettsiden må kunden registrere seg først slik at aktøren før den nødvendinge informasjonen om brukeren. 4. Ved innlogging logger kunden inn med kode og brukernavn som de har fått av aktøren. 5. Brukeren skal kunne velge hva slags betalingsalternativ de vil betale for domenet. 6. Dataene for domenenavn og informasjon tilknyttet domene som pris, nøkkelord skal lagres i en database. 7. Til hvert domenenavn skal det knyttes til følgnede nøkler: Full domenennavn med endelse, ordet som danner domenet, Salgspris, År som domenet ble registert og nøkkelord relatert til domenet. 8. Domenene skal organiseres på samme måte som linker på startside/katalog tjeneste. 9. Et domene kan høre til et eller flere av kategoriene. En kategori må være hovedkategori knyttet til domenet. Domenet kan ha flere aktegorier, men da kaller vi de andre multikategori. 10. Handlekurv funksjon slik at de domenenavn som kjøper legger til i handlekrusen vises når man går til handlekurs eller velger Check Out fra handlekruv og utfør ordren. 11. Administrasjonsverktøy, slik at selger skal kunne logge inn i legge til salgsinformasjon om domenet som. Samme gjelder redigering. Redigering kan være slik at man velger unpublish domenet eller ha et valg som sier Sold. 12. Nettbutikken skal utvikles i php og html5. Backend blir programmert i php som jobber mot en MySql database som holder styr på alle domener og data knyttet til det. Ikke-funksjonelle krav: 1. Sikkerheten til nettsiden når kunden logger seg på. 2. Det skal være enkelt å finne seg fram på siden. 3. Systemet skal være tilgjengelig døgnet rundt. 4. Brukergrensesnittet skal være enkel, tilgjengelig og lett å forstå. 10

11 3.2 USE CASE MODELL USE CASE DIAGRAM Use case diagram som modellerer løsningens funksjonsområder. Diagrammet suppleres med forklaringer etter behov DETALJERTE USE CASE BESKRIVELSER Nedenfor vil vi ta for oss 2 use case beskrivelser. 1. Kjøp av domene: Dette er det viktigste fordi det er dette som er primær behovet for Domaining AS, nemlig å selge domener. 2. Administrasjon av data: Dette er løsningen som ansatte i Domaining AS vil utføre. Dette kommer de til å gjøre mest i og med det vil være stadige endringer i selskapets domeneportefølje. Priser må justeres, nye domener som blir kjøpt inn må registreres i systemet osv. Use case Bruker Sekundær bruker Trigger Pre-betingelser Post-betingelser Normal hendelsesflyt Kjøpe domene Kunde Admin Kunden ønsker et domene Kunden er registrert i systemet Kunden blir eier av domenet 1. Kunden går til websiden 11

12 Variasjoner 2. Kunden søker opp ønsket domene 3. Systemet søker i databasen og finner frem domenet 4. Kunden velger domene 5. Kunden klikker på kjøp domene 6. Systemet henter opp betalingsalternativer 7. Kunden velger betalingsalternativ. 8. Kunden sender betalingen 9. Admin mottar betalingen 10. Admin overfører domenet, og endrer status til Solgt 11. Kunden mottar domenet Domene finnes ikke lenger Systemet gir beskjed hvis domenet ikke finnes lenger 7.1 Betalingen er ikke i ordren Feil informasjon. Ingen dekning på kortet Kunden mottar ikke domene. Kontakte Admin Use case Administrasjon av data Bruker Admin Sekundær bruker - Trigger Admin logger seg inn i systemet Pre-betingelser - Post-betingelser Logget inn. Legg til domene, endre domene eller slette domene Normal hendelsesflyt 1. Admin går til nettsiden og logger seg inn. 2. Admin logger på med brukernavn og passord. 3. Systemet viser all innhold. 4. Admin går til egen side for å registrere, endre eller slette. 5. Admin setter inn domeneadressen og får beskjed av systemet om den finnes eller ikke finnes fra før. 6. Admin fyller ut, endrer eller sletter informasjon. 7. Systemet lagrer informasjonen. 8. Admin får tilbakemelding av systemet. Variasjoner 2.1. Feil brukernavn og passord Systemet sier ifra om brukernavn og passord er feil 12

13 Admin fyller inn riktig brukernavn og passord Feil i systemet Admin får ikke lagt til, endret eller slettet domene 7.1. Informasjon ble ikke lagret Systemet fikk ikke lagret informasjonen på grunn av feil eller at det mangler andre informasjoner. 3.3 DOMENEMODELL 13

14 3.4 AKTIVITETSDIAGRAM For kunder som kjøper våre domener så vil vi kun tillate Paypal for betaling, vi henter først ut totalsummen, Paypal vil selv sjekke saldo og andre ting. Videre vil vi da vise godkjent og sende kvittering på mail. Til slutt blir transaksjonen utført. 14

15 4 DESIGN 4.1 KLASSEDIAGRAM 15

16 4.2 SEKVENSDIAGRAM Sekvensdiagram for betaling av produktet Sekvensdiagram - Normalflyt Kunde kjøper domene og får godkjenn betaling før den blir sendt videre til Admin bekreftelse at domene er betalt. Admin sender tilbake til kunden og godkjenner betalingen. 16

17 Sekvensdiagram - variasjon/avvik Her kjøper kunden domene. Kunden betaler, men får tilbakemelding at betalingen er ikke godkjent. Betaling ikke godkjent kan enten være at PayPal ikke virker eller at du har ikke penger på PayPal. 17

18 4.3 LOGISK ARKITEKTUR Lag 1: Brukergrensesnitt utgjør den visuelle delen av webshoppen som brukeren ser. Lag 2: Applikasjonslaget som tar imot informasjon fra brukergrensesnittet som input og valg brukeren gjør, for så å gi tilbakemeldinger til brukeren. Lag 3: Business og applikasjonslogikken til webshoppen. Her ligger logikken som styrer alt av oppretting, henting, endring, lagring av data fra blant annet laget under som er databasen. Lag 4: Databasen for tjenesten hvor alle dataene om domener ligger. Brukernavn og innloggingspassord ligger også i denne databasen. 18

19 4.4 BRUKERGRENSESNITT Beskrivelse (tekst og skisser/skjermbilder) av brukergrensesnitt design. Nettsiden Domaining AS starter med hovedsiden. Siden inneholder Logg inn, Hjem, Domene, Kategori og Kontakt oss. Ved å trykke på Logg inn linken vil brukeren få mer tilgang til domene siden, samt kjøpe domenesider og legge til handlekurven. Her kan brukeren registrere seg hvis brukeren ikke er kunde der fra før. 19

20 Kunden skal kunne velge mellom type domenere som er oppdelt i kategori f.eks kunst, sport, design, film og mye mer. I handlekurven skal brukeren kunne se hva de har lagt til i handlekurven. Hvis de ikke ønsker å ha domene allikevel, så trykker brukeren på Slett. Når de er ferdig med å handle kan de da bare trykke på Paypal. Kunden skal kunne også avbryte handlekurven hvis de ikke ønsker å kjøpe domene (knappen avbrytt synes ikke i brukegrensesnittet her). 20

21 5 VURDERING 5.1 VURDERING AV FORESLÅTT LØSNING Krav: Kravspesifikasjon har blitt laget ut ifra DomainingAS sitt behov om en domenewebbutikk for å selge sine domener. Vi har i kravspesifikasjonen identifisert og beskrevet alle funksjoner for en komplett løsning. Kravspesifikasjonen dekker en løsning for grupper brukere, som er DomainingAS sine ansatte som skal håndtere salgene og DomainingAS sine kunder som domenekjøpere. Vi har fokusert på at begge skal enkelt kunne bruke webbutikken uten mye nødvendig support. Modellering Vår modellering viser hvordan systemet skal fungere og gir en detaljert beskrivelse av hvordan de forskjellige metodene, klassene og use-casene opererer. Vi har også sørget for å ha oversikt over dataflyten, dataoppbevaringen og informasjonsbehandlingen som foregår. Den oversiktlige og detaljerte modelleringen er for å sikre lettere og bedre implementeringsarbeid for programmererne som skal utvikle systemet. Klassediagrammet gir en detaljert oversikt over systemets klasser og relasjoner. Sekvens diagrammet beskriver detaljert hendelsesforløpet på funksjoner. Vi har i løpet av prosjektet for flere funksjoner gått tilbake en iterasjon for vurdere annerledes og mer passende modellering. Brukergrensesnitt Vi har fokusert på at systemet ved siden av å ha alle de nødvendige funksjoner også skal ha et enkelt, intuitivt og brukervennlig brukergrensesnitt. Vi har skissert flere grafiske skjermbilder for å beskrive dette, og forklart funksjonaliteten, noe som gir en bedre visualisering for alle involverte parter, og unngå at risikoen for misforståelse.. Vi mener at løsningsforslaget vårt er grundig og dekker kravspesifikasjonene og designgrunnlaget for å kunne utvikle systemet videre. 21

22 5.2 VURDERING AV VALG UTVIKLINGSMODELL Fra starten da vi valgte å skrive om domenenettbutikk hadde vi ingen erfaringer på hva UP var. Etter å ha jobbet med prosjektet og fått litt mer kunnskap om UP, synes vi at prosessmodellen UP var en passende modell til prosjektet vårt. Det som vi synes er fint med UP er at vi kan gå tilbake og endre på ting i UP underveis i prosjektet. Hver av fasene er grundig planlagt helt fra starten slik at det skal bli lettere å jobbe. De inneholder viktige informasjoner som viser hvordan man skal utføre prosjektet. Vi kunne kanskje ha brukt utviklingsmodellene Scrum eller MSF, fordi de to er avhengig av tilbakemeldinger og brukertesting fra arbeidsgiveren og prosjektgruppa. Vi har ikke klart å bestemme hvilken av utviklingsmodellene som kanskje kunne ha passet til dette prosjektet. 5.3 VURDERING AV EGET PROSJEKTARBEID Gruppen kom tidlig igang med prosjektarbeidet siden vi allerede hadde gode forbindelse med DomainingAS, og trodde lenge vi lå meget godt ann. Vi fikk imidlertid ikke godkjent prosjektplanen fordi vi planen var upresist og mangelfull på flere områder og havnet da på etterkudd siden vi da måtte beskrive prosjektplanen bedre. I ettertid ser vi at det var bra at vi ikke godkjent prosjektplanen i første omgang og måtte bruke tid på å presisere både målet og prosjektbeskrivelse. Det hadde vært verre om vi hadde kommet til slutten av prosjektet, også viser det seg at vårt løsningsforslag ikke dekker oppdragsgivers viktigste krav. Vi tror den tidlige kritiske tilbakemeldingen økte vår egen kritiske vurdering og skjerpet vår fokus på det vi skulle løse. Det har vært noe uenigheter i prosjektarbeidet om valg av modeller og iterasjoner, men det har løst seg gjennom at flertallsprinsippet etter diskusjoner. Vi har også hatt sykdom, men da har andre i gruppen tatt ansvar og tatt seg av oppgavene til den som har vært fraværende, slik som vi kunne holde oss til prosjektplan og milepæl. Vi har hatt et møte i uken for å oppdateres, men ellers så har vi jobbet med prosjektet hver for oss med, men sammen gjennom Skype og Google Docs. 22

23 6 KONKLUSJON Vi har i dette prosjektet utviklet et system for DomainingAS for salg av domener. Dette systemet skal håndtere oppgaver for to parter. Den ene parten er DomainingAS ansatte som skal ha systemet for å administrere og håndtere salgene. Den andre parten er kundene som kjøper domener fra DomainingAS. Vi har brukt UP-modellen og fulgt de 3 første fasene som er idefasen, fordypnignsfasen og konstruksjonsfasen, som har hjulpet oss med å få ferdig prosjektet til det nivået at vi kan overføre prosjektet videre til utviklere og grafiske designere som kan ta det videre i overgangsfasen og programmere og designe ferdig systemet. Målsetningene ble oppnådd og vi har klart å følge tidsfrister selv om men prosjektet har tatt noe lenger tid enn planlagt. Dette skyldes av vår noe upresis definering av mål og avgrensinger samt ikke mangel av disipliner i de ulike fasene i UP begynnelsen. Da dette ble ble grundig gjennomgått igjen ble det mye enklere å følge planen for å utføre videre systemutvikling mer presist. Det har ellers gått mye tid å utarbeide modellene godt nok slik at videre ferdig utvikling av systemet ikke blir feil. Målet var å få ferdig systemutviklingen slik at DomainingAS kan ta en beslutning og overføre resten av jobben til programmererne har en manual for å ferdigeutvikle hele løsningen og det synes vi vi har klart. 7 LITTERATURLISTE Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition, 2004, Craig Larman Systemsutvikling, 2008, Thor E Hasle Forelesnings notatene Wikipedia 23

DOMAINING AS GRUPPENR.24

DOMAINING AS GRUPPENR.24 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 PROSJEKTPLAN SYSTEMUTVIKLING (LO138A) HØST 2011 DOMAINING AS GRUPPENR.24 Forfattere: s171633, Truc Tran, s171171, My

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

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

Vakt og lønnssystem - Rema 1000

Vakt og lønnssystem - Rema 1000 Avdeling for ingeniørutdanning Høgskolen i Oslo og Akershus Prosjektrapport Systemutvikling (LO138A) Høst 2011 Vakt og lønnssystem - Rema 1000 Gruppe 8 Forfattere: Andreas Baaserud, s169982 Ravi Agnihotri,

Detaljer

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn

Modellering av krav. INF1050: Systemutvikling 11. februar 2015. Universitetslektor Yngve Lindsjørn INF1050: Systemutvikling 11. februar 2015 Modellering av krav Universitetslektor Yngve Lindsjørn INF1050 ->Systemutvikling-> Modellering av krav / Yngve Lindsjørn 1 Temaer i dagens forelesning Modellering

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

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

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

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

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

Avdeling for ingeniørutdanning Høgskolen i Oslo. Prosjektrapport Systemutvikling (lo138a) Høst 2010. Taxisentral

Avdeling for ingeniørutdanning Høgskolen i Oslo. Prosjektrapport Systemutvikling (lo138a) Høst 2010. Taxisentral Avdeling for ingeniørutdanning Høgskolen i Oslo Prosjektrapport Systemutvikling (lo138a) Høst 2010 Taxisentral Gruppe 19 Prosjekthjemmeside: http://gruppe19.lmdahl.no/ Forfattere: Larsen, Mads s156151

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

Avdeling for Ingeniørutdanning Høgskolen i Oslo. Prosjektplan. Systemutvikling (lo138a) Høst 2010. Taxisentral. Forfattere:

Avdeling for Ingeniørutdanning Høgskolen i Oslo. Prosjektplan. Systemutvikling (lo138a) Høst 2010. Taxisentral. Forfattere: Avdeling for Ingeniørutdanning Høgskolen i Oslo Prosjektplan Systemutvikling (lo138a) Høst 2010 Taxisentral Gruppe 19 Prosjekthjemmeside: http://gruppe19.lmdahl.no/ Forfattere: Bergan, Bjørn s161593 Baisa,

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

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

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

Detaljer

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

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

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

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

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

UNIVERSITETET I OSLO

UNIVERSITETET I OSLO Bokmål Kandidat nummer: UNIVERSITETET I OSLO Det matematisk-naturvitenskapelige fakultet Eksamen i: INF1050 Eksamensdag: 31. Mai, 2011 Tid for eksamen: 09:00-13:00 Oppgavesettet er på 6 sider Vedlegg:

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

Kravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009

Kravspesifikasjon med UML use case modellering. Erik Arisholm 25.02.2009 Kravspesifikasjon med UML use case modellering Erik Arisholm 25.02.2009 Unified Modeling Language (UML) Notasjon som støtter opp under modellbasert systemutvikling objektorientert analyse ( hva systemet

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

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

Kravspesifikasjon. Dagens forelesning. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Kravspesifikasjon og objektorientert analyse

Kravspesifikasjon. Dagens forelesning. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Kravspesifikasjon og objektorientert analyse Dagens forelesning Kravspesifikasjon Kravspesifikasjon og objektorientert analyse Hva skal systemet gjøre? Hvem og hva påvirker krav? Motivasjon: Hvorfor trenger vi UML? Noen resultater fra et UML-eksperiment

Detaljer

Spesifikasjon av Lag emne

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

Detaljer

Aksjonær / Interessent

Aksjonær / Interessent Brukermanual Aksjonær / Interessent 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

Kravspesifikasjon. Kravspesifikasjon. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Hva skal systemet gjøre? Hvem og hva påvirker krav?

Kravspesifikasjon. Kravspesifikasjon. Mal for kravspesifikasjon. Hvordan finne fram til kravene? Hva skal systemet gjøre? Hvem og hva påvirker krav? Kravspesifikasjon Kravspesifikasjon Erik Arisholm Simula Research Laboratory & Institutt for Informatikk Hva skal systemet gjøre? Hvem og hva påvirker krav? Motivasjon: Hvorfor trenger vi UML? o Noen resultater

Detaljer

Meeting Reservation System

Meeting Reservation System Meeting Reservation System Oblig1c-1 Gruppe 8 Frode Revheim, Sven-Erik Nilsen, Terese Haug, Rolf Vassdokken Krav Vise møteromsoversikt Vise tilgjengelige rom for en gitt tidsperiode og med tilgjengelig

Detaljer

2 Innholdsfortegnelse

2 Innholdsfortegnelse Kravspesifikasjon 1 Forord Kravspesifikasjonen er ment å sees i sammenheng med gruppas forventninger til sitt eget sluttprodukt. Den er altså like mye våre egne krav som krav stilt av arbeidsgiver. Vi

Detaljer

INF5120 - Oblig 2. Hour Registration System (HRS)

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

Detaljer

Legg opp din nye Website raskt og enkelt!

Legg opp din nye Website raskt og enkelt! Legg opp din nye Website raskt og enkelt! Det å bytte fra gammel til ny løsning tar normalt sett ikke lang tid, siden du allerede vet hvordan du ønsker at siden din skal være bygget opp og inneholde. o

Detaljer

Nettside, Webshop og Beregningsmodell. Hovedprosjekt våren 2009

Nettside, Webshop og Beregningsmodell. Hovedprosjekt våren 2009 Nettside, Webshop og Beregningsmodell Hovedprosjekt våren [Type the abstract of the document here. The abstract is typically a short summary of the contents of the document. Type the abstract of the document

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

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser

Ulike typer prosessmodeller. Systemutvikling. Utviklingsmodeller. Prosessmodell - faser 1 Ulike typer prosessmodeller Systemutvikling Oppsummering av hovedområdene i kurset LO 135A Kirsten Ribu 19.05.2004 De røde er viktige i kurset: Evolusjonær (prototyping) Inkrementell (RUP) XP fossefall

Detaljer

Mamut Enterprise Partner Web Kunde og Partner Web

Mamut Enterprise Partner Web Kunde og Partner Web Mamut Enterprise Partner Web Kunde og Partner Web Dette er en innføring i hvordan du bruker tilleggsproduktet Mamut Enterprise Kunde- og Partner Web. Først vil det bli gjennomgått hva du kan få ut av din

Detaljer

Brukerveiledning for barnehagestillinger.no

Brukerveiledning for barnehagestillinger.no Brukerveiledning for barnehagestillinger.no Registrering Åpne nettleseren din og gå til barnehagestillinger.no. Oppe til høyre på siden klikker du på «Ny bruker». Velg «Arbeidsgiver» og fyll ut registreringsskjemaet.

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

Presentasjon av bachelorprosjekt

Presentasjon av bachelorprosjekt Presentasjon av bachelorprosjekt Oppgave 008E: Utvikling av dynamisk nettsted med portefølje, showreel og nettbutikk, for profilering av multimediaselskap. Oppdragstaker: Morten Nyutstumo (BAIN) Veileder:

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

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 modellering. Use case modellen. Metode for systembeskrivelse og Nettsted-design

Use case modellering. Use case modellen. Metode for systembeskrivelse og Nettsted-design Use case modellering Metode for systembeskrivelse og Nettsted-design Kirsten Ribu 11.09.2007 Use case modellen beskriver kravene til systemet beskriver systemet sett fra kundens perspektiv beskriver hva

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

Ansvarsdrevet OO: CRC og UML Sekvensdiagrammer

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

Detaljer

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

Så hva er affiliate markedsføring?

Så hva er affiliate markedsføring? Så hva er affiliate markedsføring? Affiliate markedsføring er en internettbasert markedsføring hvor Altshop belønner deg for hver kunde som du rekrutterer til Altshop. Vi vil ta godt hånd om dem for deg

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

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

VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD

VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD GRUPPE 36 FORFATTERE: NORDENGEN, THOMAS LARSEN, GLENRUBEN E. STEEN, SEBASTIEN-JEROME 1 INNHOLDSFORTEGNELSE VEDLEGG 1 KRAVSPESIFIKASJON... 03 VEDLEGG 2

Detaljer

kan flere studenter falle av underveis, da det er vanskelig for faglærer å se hvem som kan ha nytte av å følges opp ekstra.

kan flere studenter falle av underveis, da det er vanskelig for faglærer å se hvem som kan ha nytte av å følges opp ekstra. Visjonsdokument 1 Introduksjon Dette prosjektet er gitt av Svend Andreas Horgen, og gjennomføres som en prosjektoppgave i faget TDAT3022-A 14H Systemutviklingsprosjekt ved HiST, AiTEL. Hensikten med dette

Detaljer

Løsningsforslag til Case. (Analysen)

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

Detaljer

1. Hvilke type krav angår sikkerhet og pålitelighet?

1. Hvilke type krav angår sikkerhet og pålitelighet? 1. Hvilke type krav angår sikkerhet og pålitelighet? a) Funksjonelle b) Ikke-funksjonelle Svar: b), IS side 88, lærebok s.96 2. Verdien av etnografi er at den hjelper til å oppdage som reflekterer hvordan

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

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

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

Brukermanual til Domenia Norges webshop

Brukermanual til Domenia Norges webshop Brukermanual til Domenia Norges webshop Du finner din webshop på adressen dittdomenenavn.no/nettbutikk (f.eks www.domenia.no/nettbutikk). 1. Login For å gjøre endringer i nettbutikken din, må du logge

Detaljer

Eksamen i Internetteknologi Fagkode: IVA1379

Eksamen i Internetteknologi Fagkode: IVA1379 Høgskolen i Narvik Side 1 av 5 Eksamen i Internetteknologi Fagkode: IVA1379 Tid: Mandag, 07.06.04, 9:00-12:00 Tillatte hjelpemidler: Alle trykte og skrevne hjelpemidler tillatt. Eksamen består av 4 oppgaver

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

GRUPPE 22. My Trang Ho Tran Nguyen Thao Tran Jakub Hamad

GRUPPE 22. My Trang Ho Tran Nguyen Thao Tran Jakub Hamad GRUPPE 22 My Trang Ho Tran Nguyen Thao Tran Jakub Hamad 1 PROSJEKT NR. 22 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET

Detaljer

IBX eorder Rekvirentens Bruksanvisning

IBX eorder Rekvirentens Bruksanvisning IBX eorder Rekvirentens Bruksanvisning Manuell Revisjon: 11.1.1 Date: 12-FEB-2011 Language: Norwegian Dokumentkontroll Revisjonshistorie Versjon Dato Konsulent Beskrivelse 1,0 20.09.2010 Merja Karjalainen

Detaljer

Presentasjon 1, Requirement engineering process

Presentasjon 1, Requirement engineering process Presentasjon 1, Requirement ing process Prosessodeller Hvorfor bruke prosessmodeller? En prosessmodell er en forenklet beskrivelse av en prosess En prosessmodell er vanligvis lagd ut fra et bestemt perspektiv

Detaljer

Produktinformasjon WIPS publiseringsløsning

Produktinformasjon WIPS publiseringsløsning Enkel og effektiv publisering på på nett! Produktinformasjon WIPS publiseringsløsning WIPS publiseringsløsninger - Oversikt WIPS Start Standard PRO PRO med intranett Fleksibel forside * * * * 1 stk designmal

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

Få din egen hjemmeside

Få din egen hjemmeside I dette avsnittet lærer du å bygge din egen hjemmeside legge til tekst og bilder lage din egen design legge en bakgrunn på hjemmesiden I neste nummer får du hjelp til å bygge en større hjemmeside til en

Detaljer

Administrasjon av saker. - Redigere saker med standard mal

Administrasjon av saker. - Redigere saker med standard mal Administrasjon av saker - Redigere saker med standard mal Admin V3 September 2015 INNLEDNING... 3 HVA ER EN ARTIKKEL?... 4 FANE: INNHOLD... 4 Felter i en standard artikkel... 5 LAGE EN NY ARTIKKEL... 6

Detaljer

student s104111, s107911, s122357

student s104111, s107911, s122357 Forord Denne brukerveiledning er ment som et hjelpemiddel for brukerne av administrasjonssystemet og vaktsystemet. Målgruppen for administrasjonssystemet er avdelings ledere på Grefsenhjemmet, mens målgruppen

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

Planlegging og dokumentasjon

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

Detaljer

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen

Forprosjektrapport. Presentasjon. Sammendrag. Tittel Informasjonsplatform for NorgesGruppen Forprosjektrapport Presentasjon Tittel Informasjonsplatform for NorgesGruppen Oppgave Utvikle en informasjonsplatform for butikkene i NorgesGruppen Periode 3. Januar 14. Juni Gruppemedlemmer Joakim Sjögren

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

KRAVSPESIFIKASJON FORORD

KRAVSPESIFIKASJON FORORD KRAVSPESIFIKASJON 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

Detaljer

Side 1. Sniggabo CMS brukermanual rev. 2

Side 1. Sniggabo CMS brukermanual rev. 2 Side 1 Sniggabo CMS brukermanual rev. 2 INNHOLDSFORTEGNELSE Logg inn... 3 Menylinje... 3 Artikkelliste... 4 Ny artikkel... 5 Aktiviteter... 8 Rediger aktivitet... 9 Dokumenter... 9 Nytt dokument... 10

Detaljer

Introduksjon About Us Our Wines Newsroom Library Webshop Login Logo Contact FAQ Terms and Conditions

Introduksjon About Us Our Wines Newsroom Library Webshop Login Logo Contact FAQ Terms and Conditions Introduksjon Velkommen til vår nye nettside. For å forenkle din handleopplevelse har vi nedenfor satt opp en liten brukerveiledning for å hjelpe deg med eventuelle spørsmål. Dersom du på noe tidspunkt

Detaljer

Bruksanvisning. Royal Canin webshop

Bruksanvisning. Royal Canin webshop Bruksanvisning Royal Canin webshop Innhold Hvordan logger jeg inn på webshop? 3 Hvordan bestiller jeg produkter? 3 1. Bla i Katalogen 3 2. Hurtigkjøp 3 Hvordan søker etter et produkt? 4 Hvordan se om et

Detaljer

Tom Røise 26.02.2007. IMT2243 : Systemutvikling 1. IMT2243 Systemutvikling 26. februar 2007. Klassediagrammet. Klasse

Tom Røise 26.02.2007. IMT2243 : Systemutvikling 1. IMT2243 Systemutvikling 26. februar 2007. Klassediagrammet. Klasse IMT2243 Systemutvikling 26. februar 2007 Tema : Domenemodellering og Kravspeken - Repetisjon konseptuelle klassediagram - Eksempler - konseptuelle klassediagram (IHID løsningen og OL-Veiviseren) - Maler

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

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

Enkel brukerveiledning myweblog

Enkel brukerveiledning myweblog Enkel brukerveiledning myweblog Sist oppdatert 2.2.2011. Introduksjon myweblog er et web-basert system som skal brukes i forbindelse med booking av fly og registrering av flyturen etterpå. Etter hvert

Detaljer

Vedlegg LMC intranett

Vedlegg LMC intranett Vedlegg LMC intranett H12D02 Jarl-Håvard Holen Ole-Martin Larsen Fredrik Sethne-Andersen André Ritari Vedlegg 1 Resultater av kortsortering. Kortsortering Bruker 1, Salg: Kortsortering Bruker 2, Teknisk:

Detaljer

for å lykkes med e-handel? WebOn - for din lønnsomhet

for å lykkes med e-handel? WebOn - for din lønnsomhet Hvorfor er måling viktig for å lykkes med e-handel? Bakgrunn Vestlandsforsking: Forsker / utvikler - 1999 WebOn: Rådgiver - 2007 Butikk Trafikk Hvorfor de kommer Hvem og hvor mange handler Hva handler

Detaljer

Administrasjon av kataloger - Oversikt over innstillinger på kataloger

Administrasjon av kataloger - Oversikt over innstillinger på kataloger Administrasjon av kataloger - Oversikt over innstillinger på kataloger COPYRIGHT Syzweb AS 2010 Alle Rettigheter Reservert Side 1 av 10 Innledning... 3 Hva er en katalog?... 4 Katalogtreet... 4 Opprette

Detaljer

IBX eorder Admin Bruksanvisning

IBX eorder Admin Bruksanvisning IBX eorder Admin Bruksanvisning Manuell Revisjon: : 11.1.1 Date: 12-FEB-2010 Language: Norwegian Dokumentkontroll Revisjonshistorie Versjon Dato Konsulent Beskrivelse 1.0 20.09.2010 Merja Karjalainen Lag

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

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

BRUKERVEILEDNING FOR NETTBUTIKK. Innlandskortet

BRUKERVEILEDNING FOR NETTBUTIKK. Innlandskortet BRUKERVEILEDNING FOR NETTBUTIKK verdi på ditt. NY BRUKER: Klikk her for å lage ny brukerkonto! EKSISTERENDE BRUKER: Skriv inn brukernavn og passord, og logg deg inn her! Husk at oppdateringen er tilgjengelig

Detaljer

Trip Tracker - Tracks your trip. Harald H. Tjøstheim Dagfinn Rasmussen Jan Magne Tjensvold

Trip Tracker - Tracks your trip. Harald H. Tjøstheim Dagfinn Rasmussen Jan Magne Tjensvold Trip Tracker - Tracks your trip Harald H. Tjøstheim Dagfinn Rasmussen Jan Magne Tjensvold Våren 2006 Sammendrag Trip Tracker er et klient-tjener system for sporing og plotting av koordinater fra en GPS-mottaker

Detaljer

Visma ERP POS. Utvid økonomisystemet med en brukervennlig kasseløsning

Visma ERP POS. Utvid økonomisystemet med en brukervennlig kasseløsning Visma ERP POS Utvid økonomisystemet med en brukervennlig kasseløsning En moderne og funksjonell kasseløsning kasseløsning Det lønner seg å utvide økonomisystemet med integrert kassefunksjonalitet. I alle

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

IBX eorder Rekvirentens Bruksanvisning

IBX eorder Rekvirentens Bruksanvisning IBX eorder Rekvirentens Bruksanvisning Manuell Revisjon: 12.2 Date: 29. MARS 2012 Language: Norwegian Dokumentkontroll Endre logg Kapittel Dato Beskrivelse 1.1 18.01.2011 Oppdatering av mal 2.2 18.04.2011

Detaljer

Aktivitetskart. Fremdriftsplan: denne prosessen: Peder Sundbø. ferdigstilt uke 8. fastslåing av prosjekt. Magnus Eriksen. Uke 8.

Aktivitetskart. Fremdriftsplan: denne prosessen: Peder Sundbø. ferdigstilt uke 8. fastslåing av prosjekt. Magnus Eriksen. Uke 8. Aktivitetskart Planlegging dato: 29.01-09 TIL 7.2-09 Kravspesifikasjon beskrivelser Papirprototyp ER-diagram Planlegging og fastslåing av prosjekt En del av kravspesifikasjon. Grafisk visning av systemets

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

Kjøpsvilkår for Nettbutikk Butikkenes brukere kan være personer som fylte 18 år og er habile i henhold til loven.

Kjøpsvilkår for Nettbutikk Butikkenes brukere kan være personer som fylte 18 år og er habile i henhold til loven. KJØPSVILKÅR Salg i nettbutikken blir gjennomført på grunnlag av nettbutikkens Kjøpsvilkår som Kunden bør bli kjent med for han/henne legger inn bestilling. Sending av bestillingen betraktes som godkjenning

Detaljer

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

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

Detaljer

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

Næringsregner på PC n versjon 1.1.0

Næringsregner på PC n versjon 1.1.0 Laget av Innhold: Introduksjon 2 Næringsregner på PC n 2 Næringstabell 2 Statistikk 2 Hvem passer programmet for? 2 Bruk av programmet 3 Innlogging av forskjellige brukere 3 Hovedprogramet har 3 felt 4

Detaljer

AP221 Use Case - TUL - Utarbeid prosessflytmal og komponenter

AP221 Use Case - TUL - Utarbeid prosessflytmal og komponenter AP221 Use Case - TUL - Utarbeid komponenter Utarbeid komponenter En tjeneste i Sluttbrukerløsningen har en arbeidsflyt som bestemmer de forskjellige stegene som må gjennomføres i skjemainnsendingen. Disse

Detaljer

Obligatorisk oppgave 1: Foranalyse og Kravhåndtering Lars- Martin Hejll 5611 Systemutvikling

Obligatorisk oppgave 1: Foranalyse og Kravhåndtering Lars- Martin Hejll 5611 Systemutvikling Obligatorisk oppgave 1: Foranalyse og Kravhåndtering LarsMartin Hejll 5611 Systemutvikling Høgskolen i Telemark Oppgave 1: Bakgrunn for systemet LarsMartin Hejll A) Ved å sentralisere bookingsystemet til

Detaljer