S Y S T E M U T V I K L I N G ( L O 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