PROSJEKTRAPPORT SYSTEMUTVIKLING (LO138A)...Det skal lages en nettbutikk løsning for salg av eksisterende domenenavn. Delmål: 1. Løsningen skal redusere tidsbruken på å besvare

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 1 3 8 A )

H Ø S T 2 0 1 1

GRUPPE 24: DOMAINING AS

Forfattere:

s171633, Truc Tran

s171171, My Trang Ho Tran

s169998, Christian Andreas Lysaker

s169999, Amund Løchen

Dato: 25.11.2011

SAMMENDRAG

Selskapet Domaining AS eier mer enn 13000 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.

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

LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS

2

I N N H O L D 1 INTRODUKSJON ........................................................................................................................................ 3

1.1 BAKGRUNN ................................................................................................................................................. 3 1.2 MÅL FOR PROSJEKTET ................................................................................................................................... 4 1.3 OMFANG AV LØSNING ................................................................................................................................... 4 1.4 SUKSESSKRITERIA ......................................................................................................................................... 5 1.5 ANTAGELSER ............................................................................................................................................... 5

2 TILPASNING AV UTVIKLINGSMODELL ....................................................................................................... 6

2.1 BESKRIVELSE AV UTVIKLINGSMODELL ................................................................................................................ 6 2.2 BEGRUNNELSE FOR TILPASNINGER ................................................................................................................... 6

3 ANALYSE ................................................................................................................................................. 10

3.1 KRAVSPESIFIKASJON .................................................................................................................................... 10 3.2 USE CASE MODELL ..................................................................................................................................... 11

3.2.1 Use case diagram ............................................................................................................................. 11 3.2.2 Detaljerte Use case beskrivelser ....................................................................................................... 11

3.3 DOMENEMODELL ....................................................................................................................................... 13 3.4 AKTIVITETSDIAGRAM ................................................................................................................................... 14

4 DESIGN ................................................................................................................................................... 15

4.1 KLASSEDIAGRAM ........................................................................................................................................ 15 4.2 SEKVENSDIAGRAM...................................................................................................................................... 16 4.3 LOGISK ARKITEKTUR .................................................................................................................................... 18 4.4 BRUKERGRENSESNITT .................................................................................................................................. 19

5 VURDERING ............................................................................................................................................ 21

5.1 VURDERING AV FORESLÅTT LØSNING .............................................................................................................. 21 5.2 VURDERING AV VALG UTVIKLINGSMODELL ....................................................................................................... 22 5.3 VURDERING AV EGET PROSJEKTARBEID ........................................................................................................... 22

6 KONKLUSJON .......................................................................................................................................... 23

7 LITTERATURLISTE .................................................................................................................................... 23

VERSJONSLOG

Versjon Dato Forfatter(e) Beskrivelse av versjon

V0.3 12.10.2011 Truc, My Trang,

Amund, Christian

Leveranse del 2: Introduksjon, Use case modell,

detaljert analyse, oppdatering av prosjekt plan

V0.6 04.11.2011 Truc, My Trang,

Amund, Christian

Leveranse del 3: Modellering, UP modellen,

oppdatering av prosjekt plan

V1.0 25.11.2011 Truc, My Trang,

Amund, Christian

Leveranse del 4: Modellering, Vurdering av

prosjektet. Hele rapporten


3

1 INTRODUKSJON

1.1 BAKGRUNN

Gruppen har valgt å skrive for selskapet DomainingAS

Domaining AS eier idag mer enn 13000 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 200.000 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 email besvarelser som man regner med

email dialog blir ca 1000 email 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.


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

1.3 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 13000 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


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.


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.


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


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.


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.


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


11

3.2 USE CASE MODELL

3.2.1 USE CASE DIAGRAM

Use case diagram som modellerer løsningens funksjonsområder. Diagrammet suppleres med

forklaringer etter behov.

3.2.2 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 Kjøpe domene

Bruker Kunde

Sekundær bruker Admin

Trigger Kunden ønsker et domene

Pre-betingelser Kunden er registrert i systemet

Post-betingelser Kunden blir eier av domenet

Normal hendelsesflyt 1. Kunden går til websiden


12

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.

Variasjoner 2.1. Domene finnes ikke lenger

2.1.1. Systemet gir beskjed hvis domenet ikke finnes lenger

7.1 Betalingen er ikke i ordren

7.1.1. Feil informasjon. Ingen dekning på kortet.

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

2.1.1. Systemet sier ifra om brukernavn og passord er feil


13

2.1.2. Admin fyller inn riktig brukernavn og passord.

6.1. Feil i systemet

6.1.1. Admin får ikke lagt til, endret eller slettet domene

7.1. Informasjon ble ikke lagret.

7.1.1. Systemet fikk ikke lagret informasjonen på grunn av feil eller at det

mangler andre informasjoner.

3.3 DOMENEMODELL


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.


15

4 DESIGN

4.1 KLASSEDIAGRAM


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.


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.


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.


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.


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


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.


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.


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

Documents

PROSJEKTRAPPORT SYSTEMUTVIKLING (LO138A)...Det skal lages en nettbutikk løsning for salg av eksisterende domenenavn. Delmål: 1. Løsningen skal redusere tidsbruken på å besvare