DOMAINING AS GRUPPENR.24

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 PROSJEKTPLAN SYSTEMUTVIKLING (LO138A) HØST 2011 DOMAINING AS GRUPPENR.24 Forfattere: s171633, Truc Tran, s171171, My Trang Tran, s169998, Christian Lysaker, s169999, Amund Løchen, Dato:

2 INNHOLD AD1 INTRODUKSJON BAKGRUNN MÅL OMFANG ANTAGELSER OG BEGRENSNINGER UTVIKLINGSMODELL SUKSESSKRITERIA RISIKO OG TILTAK RAPPORTOVERSIKT BESKRIVELSE AV PROSJEKTLEVERANSENE PROSJEKTORGANISASJON OG PLAN PROSJEKTORGANISASJON ROLLER OG ANSVAR MILEPÆLER OG AKTIVITETER OVERSIKT PROSJEKT PLAN ARBEIDSMÅTE ( WAY OF WORKING ) PROSJEKTHJELPEMIDLER KOSTNADER KOSTNAD PER FASE ADMIN RAPPORTERING OG MØTER DOKUMENTHÅNDTERING TIMEREGISTRERING INFORMASJON REFERANSER VERSJONSLOG Versjon Dato Forfatter(e) Beskrivelse av versjon Truc, My Trang, Amund, Christian Truc, My Trang, Amund, Christian Truc, My Trang, Amund, Christian Prosjektplan innlevering Prosjektplan redigert Prosjektplan redigert 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 om 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 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 Med utgangspunkt i bakgrunnen og mål så skal her beskriver nærmere omfanget av hva løsningen som Domaining AS skal få levert. Det finnes idag flere forskjellige 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. Salgssted på internett: Det skal lages en domenenettbutikk som skal være åpen for alle på internett. Nettbutikken skal være en katalog som viser alle domener der selskapet har for salg. Det vil være behov for å kategorisere 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 varebeholdningen. Det vil være behov for å legge til nye domener som selskapet har kjøpt inn for salg, det vil være behov for 4

5 å endre på priser og annet informasjon, og slette domener som selskapet har solgt. I den forbindelse vil det være nødvendig med et administrasjonssystem, og her ser vi det naturlig at det er web-basert 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 mange 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 ANTAGELSER OG BEGRENSNINGER I dette prosjektet vil vi kun ta for oss webshop løsning for salg av eksisterende domener som en enkel vare og ikke websider med innhold tilknyttet til domenet. Ingen hosting tjenester. Prosjektet tar ikke for seg de praktiske og juridiske prosesser som skjer overføring av domener mellom 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. 1.5 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 5

6 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. 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. Figur: UP Modell (Unified Process) Disiplinene som vi har valgt: 6

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

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

9 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. 1.6 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 forskjellige 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. 9

10 10

11 1.7 RISIKO OG TILTAK Risiko Misforstålese eller feilspesifikasjon Faglige problemer: Konflikter og uenighet mellom konsulent og kunden Undervurdering av tidsbruk på ulike områder I prosjektet Sannsynli ghet Konsekvens Tiltak Liten Tid går tapt Kunden stiller med en kontaktperson som er direkte involvert i prosjektet. Middels Middels Man kjenner kanskje ikke fagområder godt nok og trekker feil beslutnigner som igjen leder til feil anayse og resultater Tidsbruket øker, da kunden må overtale kunden om å velge anbefalte løsning. Kunden kan involvere andre parter. Prosjektkostnadene øker. Bruk av kundens fagperson om faget. Få hjelp fra andre fagpersoner på aktuelle område og prosesser. Gruppen må sørge for å få riktig forståelse. God dialog og forklaring tidligs mulig.viktig at vi lytter nøye til kundens behov. Huske at det er kunden som er spesialisten på sin forrentingsområde. Det er kunden skal ha produktet. Middels Kostnadsoverskridelser Få riktig forståelse for faglig og teknisk omfang. Dette vil være til hjelp med å estimere nøye. Revidering underveis hvis man ser at estimater ikke stemmer. Sykdom Middels Arbeid stopper opp, fordi andre som skal jobbe sammen må vente. Forsinkelser i prosjektet Informere tidlig hvis noe skjer. Jevnlige oppdateringsmøter. Oppgaver blir fordelt med en hovedansvarlig og en backup. Deling av dokumenter, slik at de andre i gruppen kan videreføre arbeidet. Tekniske Middels Tapt arbeidstid Har backup. Lagrer arbeid på nettet. problemer Tidsproblemer Middels Rekker ikke å bli ferdig til frist.mindre tid til å gjøre sluttvurderinger. Jevn arbeid i følge planene. Problemer som oppstår løses straks slik at vi slipper forsinkelser og forskyninger i planen. 11

12 1.8 RAPPORTOVERSIKT Kapittel 1: Introduksjon. Presentasjon av selskapet og problemstillingen som vi skal ta tak i. Kapittel 2: Tilpasning og utviklingsmodell. Beskrive utviklingen i prosjektet Kapittel 3: Analyse. Her vil vi se på kundenes atferdsmønster, eksisterende løsninger. Kapittel 4: Design. Lage modeller og design ut ifra spesifikasjoner fra analyse. Kapittel 5: Her vil vi gi en vurdering av analysen vi har utført, valgte modeller og design. Kapittel 6: Konklusjon. Oppsummering av prosjektet 2 BESKRIVELSE AV PROSJEKTLEVERANSENE Leveranse 1 Prosjektplanen inneholder all planleggingen i hele prosjektet, alle estimater og det er dette som leveres i leveranse 1. Ferdig med problemstilling og prosjektplan Leveranse 2 I denne leveransen skal vi ha utfylt hele prosjektrapporten og spesifisert overordnet kravspesifisering og use case modellering. Kapittel 1-2 i prosjektrapport mal er utfylt. Seksjonene : Overordnet kravspesifisering og use case modellering så langt som mulig Leveranse 3 I leveranse 3 fokuserer vi på å fylle ut kapittel 1-4 i prosjektrapporten. Sekvensdiagram Domenemodell Aktivitetsdiagram Klassediagram Logisk arkitektur Brukergrensesnitt 12

13 Leveranse 4 Her avslutter vi med å levere en komplett rapport. Komplett rapport Kvalitetssikring av fullstendig dokument. 3 PROSJEKTORGANISASJON OG PLAN 3.1 PROSJEKTORGANISASJON Prosjektlederen fungerer som bindeleddet mellom kunden og alle deltakerne i prosjektet. 3.2 ROLLER OG ANSVAR Rolle Ansvar Navn (Backup) Prosjektleder Leder prosjektet. Er bindeledd Truc mellom kunde, gruppen. (My Trang) Kan være fagpersonen. Sluttrapport Analyse Innhenting av informasjon, Christian use case analysearbeid (Truc) Design Grafisk, Design og protoyping My Trang (Amund) Webansvarlig Ansvarlig for oppdatering av websiden for prosjektet Amund (Christin) Kompetanse Siviløkonom Prosjektledelse Domener Dataing. Design, Html, Photoshop Html, Webprogrammering Tidsperiode Hele Idefasen, FF KF, OF Hele Vi har valgt å fordele arbeidsoppgaver på ulike områdene med at alle tar hver for egne områder, men hvor det vil være en hovedansvarlig på området og at en backup person som også er involvert og oppdatert 13

14 3.3 MILEPÆLER OG AKTIVITETER MILEPÆL 1: Leveranse Del Aktiviteter: Ide, planlegging, overordnet analyse. Ferdigstille prosjektplanleggingen og få godkjent. Iterasjon 1 Leveranse: Prosjekt Plan v1.0 MILEPÆL 2: Leveranse Del Aktiviteter: Introduksjon, Use case modell, detaljert analyse, oppdatering av prosjekt plan. Gjøre ferdig Kapittel i ProsjektRapport Domaining AS og få godkjennelse av leveranse 2 Iterasjon 1 & Iterasjon 2 Leveranse: Prosjekt Plan v1.0 & Prosjekt Rapport v0.3 MILEPÆL 3: Leveranse Del Aktiviteter: Oppdatere rapporten. Analyse, gjøre ferdig modellene (sekvensdiagram, domenemodell, aktivitetsdiagram, klassediagram), brukergrensesnitt, kvalitetsikre dokumentene. Få godkjent leveranse 3. Iterasjon 3 & Iterasjon 4 Leveranse: Prosjekt Rapport v0.6 MILEPÆL 4: Leveranse Del Aktiviteter: Komplett rapport, vurdering av løsning, utviklingsmodell og eget prosjektarbeid, kvalitetsikre dokumentene. Sende inn siste leveranse 4 og få godkjent Iterasjon 5 Leveranse: Prosjekt Rapport v1.0 14

15 3.4 OVERSIKT PROSJEKT PLAN Oversikt over prosjektaktivitetene for hele perioden 3.5 ARBEIDSMÅTE ( WAY OF WORKING ) Planlegging I planleggingsfasen skal vi jobbe med å utforme prosjektplanen og finne ut hvilke løsninger vi skulle bruke i forskjellige problemstillinger og lage utviklingsmodeller. Vi skal hovedsaklig jobbe med å utforme problemstillingen vår. Det kommer til å bli mindre planlegging jo lenger ut i prosjektet vi kommer. Se modellen i kapittel 2.0. Analyse I analysefasen skal vi bestemme hva slags system som skal lages og hvordan det virker. Analysen skal dokumenteres slik at det lettere kan lages i designfasen. Denne delen av prosjektet vil ta opp en god del av det totale tidsforbruket. Å bestemme nøyaktig hva vi skal lage er essensielt i analysefasen. 15

16 Når analysefasen er ferdig skal vi ha en spesifikasjon som forteller oss nøyaktig hva det er vi skal gå videre med og lage i designfasen av prosjektet. Det blir mye analyse gjennom mesteparten av prosjektet og analysefasen og designfasen glir litt over i hverandre. Design I designfasen skal vi jobbe videre med å designe det vi har kommet frem til gjennom analysefasen. Vi skal blant annet ha prototyping i designfasen for å sikre at det vi lager er det kunden (Domaining AS) ønsker. Vi skal lage klassediagrammer og sekvensdiagrammer som kan brukes i prototypingen. Vi skal designe og skissere brukergrensesnittet. Det blir mest design mot slutten av prosjektet. Det kan hende vi blir nødt til å gå tilbake og analysere i designfasen. Konstruksjonfasen består også av testing av prosjektet. Hvordan vi skal jobbe: Vi skal møtes til avtalte tider og datoer 1-2 ganger i uken hvor vi diskuterer oppgaven og finner ut hvem som skal gjøre hva, og hva vi skal samarbeide på og fokusere nærmere på. Vi oppsummerer hva vi har gjort tidligere. Vi jobber med å utvikle et fokus på de viktigere delene av prosjektet, holde detaljene klare så vi senere kan få det lettere. Når vi kommer over et problem som vi ikke har tenkt over nok tidligere så setter vi oss ned og brainstormer en masse mulige løsninger og diskuterer fordeler og ulemper. De som har mer kunnskap enn andre vil passe på å peke ut de mest essensielle delene til diskusjon, og forklare bedre hva slags problem vi står ovenfor. Vår største prioritet er å holde alle gruppemedlemmer i gang med arbeid, alle skal vite akkurat hva som mangler å gjøre, og utføre det effektivt. På den måten kan vi bli ferdig før tiden og kvalitetsikre alle dokumentene. 3.6 PROSJEKTHJELPEMIDLER I dette prosjektet vil vi benytte oss av følgende verktøy: Microsoft Word og Powerpoint For å arbeide på rapport plan og mal Use case modeller modullering modeller 16

17 Open Office For å arbeide på rapport plan og mal Google Docs For å dele dokumenter mellom gruppemedlemmer og arbeide på samtidig. Dropbox For å dele filer mellom gruppemedlemmer MatchWare For å lage Gantt kartet Microsoft project Alternativ 2 til å endre/lage på Gantt kartet. Paint For å lage fase diagram Use case modell lage andre modeller 17

18 4 KOSTNADER 4.1 KOSTNAD PER FASE Fase Antall timer Timekostnad Total pris Idefasen: Personer involvert her: Fagperson fra oppdragsgiver Prosjektleder Fordypningsfasen Konstruksjonsfasen Total

19 5 ADMIN 5.1 RAPPORTERING OG MØTER Vi har fordelt forskjellige oppgaver som hver enkelt har ansvar for å få gjort ferdig til avtalte frister. Gruppen har blitt enige om å møtes 1-2 ganger i uken for å diskutere ting sammen. Referat og rapportering vil møter skjer via vår prosjekthjemmeside. 5.2 DOKUMENTHÅNDTERING Gruppen har valgt å benytte seg av Dropbox for å dele på dataene. Vi skal bruke Google Docs for å samarbeide når vi jobber sammen samtidig. 5.3 TIMEREGISTRERING FASE Truc My Christian Amund Sum Total Idefase Fordypningsfase Konstruksjonsfase Sum total pr pers INFORMASJON Vi vil undersøke og prøve å innhente infromasjon fra andre webshoptjenester innen samme bransjen Ellers så vil vi måtte studere nærmere infromasjonsmateriell og tester av software løsnigner som tilbys. 19

20 6 REFERANSER 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 20