Page 1
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
Page 2
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
Page 3
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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.
Page 4
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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
Page 5
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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.
Page 6
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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.
Page 7
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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).
Page 8
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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.
Page 9
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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.
Page 10
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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å.
Page 11
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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
Page 12
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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
Page 13
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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
Page 14
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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.
Page 15
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
15
4 DESIGN
4.1 KLASSEDIAGRAM
Page 16
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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.
Page 17
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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.
Page 18
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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.
Page 19
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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.
Page 20
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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).
Page 21
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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.
Page 22
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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.
Page 23
LO138A – PROSJEKT RAPPORT SYSTEMUTVIKLING DOMAINING AS
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