Av: Fredrik Hørtvedt (080530 08HBPUA) Jørn-André Myrland (080531 08HBPUA) Fredrik Kvitvik (080532 08HBPUA) Side 1
Innhold 1. PROSJEKTPLAN...4 1.1. Mål og rammer...4 1.1.1. Bakgrunn...4 1.1.2. Prosjektmål...4 1.1.2.1. Effektmål...4 1.1.2.2. Resultatmål...5 1.1.3. Rammer...5 1.2. Omfang...5 1.2.1. Oppgavebeskrivelse/avgrensning...5 1.2.2. Brukergrupper...6 1.3. Prosjektorganisering...7 1.3.1. Ansvarsforhold...7 1.3.2. Øvrig bemanning...7 1.4. Planlegging, Oppfølging og Rapportering...8 1.4.1. Systemutviklingsmodell...8 1.4.2. Statusmøter og beslutningspunkter...9 1.5. Risikoanalyse...9 1.5.1. Kritiske suksessfaktorer...9 1.5.2. Risikoevaluering...9 1.5.2.1. Risikovurdering...9 1.5.2.2. Prioritering...10 1.6. Kvalitetssikring...10 1.6.1. Kvalitetssikring av kritiske suksessfaktorer...10 1.7. Gjennomføring...10 1.8. Kontrakter og avtaler...11 1.8.1. Det juridiske... 11 1.8.2. Det praktiske...11 1.9. Gantt-skjema...12 2. KRAVSPESIFIKASJON...13 2.1. Funksjonell kravspesifikasjon...13 2.1.1. Use-case modell...14 2.1.1.1. Diskusjonsmomenter...15 2.1.2. Highlevel use-case...15 2.2. Domenemodell...20 2.3. Funksjonelle krav...21 2.3.1. Risikoanalyse...21 2.3.2. Extended use-case...23 2.4. Overordnede operasjonelle krav...28 2.4.1. Systemet...28 2.4.2. Brukerens systemkrav...29 2.4.3. Brukervennlighet...29 2.4.4. Juridiske krav...30 2.4.5. Opplæring...30 2.5. Delleveranser...30 2.6. Øvrige hardwarekrav...30 2.6.1. Hardware installasjon...30 2.6.2. Vedlikehold og oppgradering...30 Side 2
3. DESIGN...31 3.1. Introduksjon...31 3.1.1. Målsettinger...31 3.1.1.1. Arkitektur...31 3.1.1.2. Design...31 3.1.2. Bruksområder...31 3.1.3. Rammer...32 3.2. Arkitektur...32 3.2.1. Nettverksdiagram...32 3.2.2. Organisering...33 3.2.3. Klient / tjener...33 3.2.4. Kommunikasjon...35 3.3. Design av brukergrensesnitt...36 3.3.1. Innledning...36 3.3.2. Bruker analyse...36 3.3.3. Prototyping av brukergrensesnitt...36 3.3.4. Eksempler på GUI...38 3.3.5. Elementer i GUI...41 3.3.5.1. Konto...41 3.3.5.2. Favoritter...42 3.3.5.3. Søk...42 3.3.5.4. Spilleliste...42 3.3.5.5. Innstillinger...42 3.3.5.6. Opplastning...43 3.3.5.7. Øvrig funksjonalitet...43 3.3.5.2.1 Høyreklikk...43 3.3.5.7.2 Kjøp av låt...44 3.3.5.7.3 Tilleggsinformasjon...44 4. VEDLEGG...45 4.1. PowerPoint-presentasjon...45 Side 3
1. PROSJEKTPLAN 1.1. Mål og rammer 1.1.1. Bakgrunn Ulovlig nedlasting av musikk er som kjent et stort problem for platebransjen, og har fått mye fokus de siste årene. Platebransjen har innsett at de må fornye seg for å henge med i tiden, og det er lansert flere tjenester som selger digitale filer. Dette har blitt en viktig inntektskilde for bransjen, men det er fremdeles store mørketall, og piratkopieringen fortsetter. Gründer Per Pedersen så stort potensial i dette markedet, og henvendte seg til de største plateselskapene i bransjen. Dette førte i sin tur til at han ble outsourcet til å utvikle Pay2Play-systemet. Ettersom Pedersen selv ikke driver noe utviklingsfirma, måtte han leie et eksternt firma til denne jobben. Code-IT fikk til slutt utviklingsjobben. Pedersen vil fungere som et viktig bindeledd som ivaretar bransjens ønsker, og jobber tett opp mot utviklerne. Pay2Play (P2P) setter brukernes krav om digitalisering og tilgjengelighet i fokus, og fører musikkbransjen inn i fremtiden. Det er en abonnementstjeneste for musikk over internett, i tillegg til å være en konkurrent på salgsmarkedet. Systemet skal inneholde et bibliotek av musikk fra alle de involverte plateselskapene/rettighetshaverne, samt bidrag fra usignerte band/artister. P2Psystemet gir usignerte artister en enestående mulighet til å bli oppdaget, ettersom det til en hver tid føres statistikk over de mest hørte bidragene. 1.1.2. Prosjektmål 1.1.2.1. Effektmål P2P har et mål om å redusere omfanget av piratkopiering av musikk. Delmålet er en reduksjon på 10 % i løpet av det første året. 25 % nedgang i løpet av de neste 5 årene ansees som realistisk. For å få til dette må tjenesten appellere og tilgjengeliggjøres for flest mulig brukere. P2P har derfor flere brukerkategorier, slik at hver enkelt bruker kan få et produkt tilpasset sine behov. Det kan være flere grunner til at piratkopiering forekommer. En av disse er pris. Veldig mange har nå for vane å hente musikk gratis, uten at skaperne/rettighetshaverne får noe igjen for det. Denne målgruppen vil være vanskelig å nå ut til med en betalingstjeneste. Vi lanserer derfor en reklamefinansiert versjon av tjenesten. På denne måten når man en del av markedet, som tidligere kun var representert som tap av fortjeneste. Reklamemengden gratisbrukerne utsettes for vil være betydelig mindre den første tiden etter registrering, og deretter økes gradvis. Dette gjøres av strategiske hensyn, og målet er at 5 % av denne gruppen oppgraderer kontoen sin til Premium. Disse kommer i tillegg til de som registrerte Premium-konto i utgangspunktet. I tillegg til dette har man en målsetting om å ta 25 % av markedet for kjøp av nedlastbare låter, i løpet av en 5-års periode. På bedriftsmarkedet er målet at 5 % av de som allerede har jukebox-systemer, bytter ut det gamle systemet mot vårt produkt. Vi ser også for oss å ta 20 % av nye kunder for denne typen tjenester. Side 4
1.1.2.2. Resultatmål Tjenesten deles i flere mindre moduler, som implementeres i programvaren. Det vil gis ut flere betaversjoner underveis. I løpet av 2009 skal det foreligge en programvare som inneholder de nødvendige modulene for å sette systemet i drift. Pay2Play vil da kunne la brukerne søke etter musikk og legge favoritter i egne spillelister. En avspillingsmodul vil være på plass, og det vil føres statistikk over alt som spilles av via streaming. Betalingssystemet skal også være på plass. 1.1.3. Rammer P2P vil ta hensyn til eksisterende avtaler mellom artister og plateselskap. Hvilket innhold som blir gjort tilgjengelig for hver enkelt bruker, vil være i henhold til lovgivningen i landet brukeren befinner seg/er registrert i. Særavtaler, rettigheter og utgivelsesdatoer som varierer over landegrensene vil også tas hensyn til. Brukere vil ikke få tilgang til tjenesten før de er autentisert, og eventuell betaling er mottatt. Programvaren skal designes med hensyn til at det vil implementeres flere moduler etter hvert. Modulene for opp- og nedlasting av musikk er ikke nødvendig for å sette systemet i drift, og vil ikke prioriteres før de øvrige modulene er på plass. Tjenesten må være tilgjengelig med støtte for flere operativsystemer, så versjoner med støtte for Mac OS og Linux må foreligge, i tillegg til Windows (XP/Vista). Det må også lages en programvare som er spesialtilpasset bedriftskunder. Dette innebærer en modul som vil kunne styre en jukebox opp mot våre databaser. Tjenesten vil i inneværende utviklingsperiode kun dreie seg om musikk/audio, men vil ta hensyn til at senere utvidelser er aktuelle. Det skal for eksempel være smertefritt å implementere en modul som lar brukeren se musikkvideoer gjennom P2P. Utvidelser av denne typen vil bli diskutert i beslutningspunkter underveis i utviklingsprosessen. 1.2. Omfang 1.2.1. Oppgavebeskrivelse/avgrensning Oppgaven går ut på å lage en nettbasert tjeneste, med utgangspunkt i en programvare som brukeren selv installerer på sin PC. Programvaren er kompatibel med operativsystemer som f.eks. Windows XP/Vista, Mac OS eller Linux. For hver oppstart av programvaren, kreves det autentisering av brukeren, før tjenestene blir gjort tilgjengelig. Programvaren har også en offlinemodus, slik at man kan kjøre programvaren uten autentisering, for å spille av lokale/kjøpte låter. En av hovedfunksjonalitetene til P2P er å gi dens brukere tilgang til å lytte til musikk ved hjelp av streaming og Peer2Peer teknologi. Det betyr at all musikk som er tilgjengelig for brukeren, ligger lagret på P2P's egne servere. Dette inkluderer ikke kjøpte/lokale låter som brukeren legger til programvaren. Det vil også være mulighet for kjøp av låter/album. Brukeren vil da kunne laste ned de kjøpte digitale filene, og benytte seg av disse også i offline-modus, eller på en ekstern avspiller. Oppdragsgiver krever også en funksjon for å laste opp egenproduserte låter av brukeren. P2P vil ikke støtte funksjoner for innspilling av låter, bare opplastning av en ferdig innspilt låt. P2P vil heller ikke støtte salg/nedlasting av opplastede låter. Side 5
Programvaren må inneholde en avspillingsfunksjon som støtter dagens mest brukte filformat for musikk. P2P vil derfor ha støtte for blant annet MP3, WMA, OGG og FLAC. Ved avspilling av en låt skal programvaren kunne gi en komplett og lettfattelig oversikt over all data for låten. Dette innbefatter navn på artist/band, sangtittel, albumtittel, sjanger, plateselskap, total spilletid og avspilt/gjenstående tid av låten. Denne funksjonen må også inneholde en queue -funksjon, slik at brukere kan sette låter i kø etter hverandre. Andre funksjonaliteter oppdragsgiver krever til P2P-programmvaren: Søkemotor linket opp mot en database, som er linket opp mot en server. Drag n drop funksjon (dra en låt fra søket, og inn i en spilleliste). Implementeres også i spillelister, for avgrenset søk der. Spillelistegenerering. Betalingsfunksjon ved kjøp av låter/album. Paypal- og kredittkortstøtte. Statistikk over låter og artister. Mest avspilte låt for uken, måneden og året basert på sjanger. Mest avspilte låt for artist. Filter slik at brukeren kan spesialisere søket. Implementert i søkemotoren og statistikk Abonnementsfunksjon for artist. Nyhetsfeed over valgte artister/plateselskap. (Ny utgivelse, konserter, etc.) Oppdragsgiver ser helst at de forskjellige funksjonalitetene deles opp i moduler og settes sammen ved hjelp av et UI. Oppdragsgiveren vil også kunne komme med innspill/endringer under utviklingsperioden. 1.2.2. Brukergrupper Oppdragsgiveren vil at det skal være tre forskjellige brukergrupper/brukerkontoer: Free, Premium og Business. Kunden har tilgang til å registrere sin egen konto via P2P's hjemmeside, og derfra velge en kontotype tilpasset kundens behov. Hver brukerkonto har sitt eget unike «fingeravtrykk», slik at det ikke er mulig at to like brukerkontoer kan være pålogget på samme tid fra 2 forskjellige IP-adresser. Business-kontoen krever nedlasting av en spesialdesignet programvare, som er optimalisert for å fungere som en Jukebox. Dette innebærer bl.a. spesialtilpasset kø-system for låter. Bedrifter/Kaféer som ønsker å benytte vår tjeneste uten Business-funksjonalitet vil ha mulighet for dette, men må likevel betale for Business-konto. På neste side ser du en oversikt over hva oppdragsgiveren krever av tjenester for de forskjellige brukergruppene. Side 6
Tjenester Brukergrupper Free Premium Business Streaming Ja Ja Ja Reklame Ja Nei Nei Opplastningsmulighet Nei Ja Nei Nedlastningsmulighet Ja Ja Nei 1.3. Prosjektorganisering 1.3.1. Ansvarsforhold God prosjektorganisering er viktig for at et prosjekt skal lykkes. Det kan være avgjørende for om prosjekt blir en fiasko, eller suksess. Vi har derfor bestemt oss for en styringsgruppe som består av folk med høy kunnskap og kompetanse på området. Styringsgruppen skal bestå av: Prosjektleder Per Pedersen innleid av plateselskapene for å utvikle tjenesten i henhold til selskapenes ønsker. Investorene, siden det er de som avgjør hvor mye som satses på prosjektet. Det er til sammen 3 investorer, som representerer hvert sitt plateselskap. Per Pedersen skal også være «on site customer», siden han er bindeleddet mellom utviklerne og plateselskapene. Plateselskapene har i møter med Pedersen presisert hva de ønsker, og gitt han fullmakt til å ta avgjørelser. Styringsgruppen skal delta i planning game, slik at alle får muligheten til å komme med innspill og vurderinger. Dette er viktig, siden vi skal utvikle etter XP-modellen. En advokat skal også være med på planning game. Advokaten blir en viktig brikke i prosessen, for å holde styr på lovene. Han skal være behjelpelig ved å informere om lover som kan komme i konflikt med de forskjellige modulene. Selve utviklingsteamet består av 6 utviklere, som har generell kompetanse. De har erfaring fra tidligere prosjekter med design, databaser og nettverksapplikasjoner. 1.3.2. Øvrig bemanning Noen brukere skal få tilgang til en betaversjon, for å teste den. Dette vil være en fordel for oss, ettersom flere feil vil bli avdekket tidlig. Vi kan da ordne disse feilene fortløpende, å minke risikoen for at bugs slippes ut i den endelige versjonen. Testgruppen vil bestå av vanlige sluttbrukere fra hele verden, som har ønsket å delta i testingen. Brukerne vil velges ut etter første mann til mølla prinsippet, slik at de første 600 som melder seg får bli betatestere. De forplikter seg da til å rapportere om feil, og mangler. Programmet skal slippes til testgruppen, etter hvert som de forskjellige modulene blir klare. Side 7
Modulene blir på denne måten godt testet, og vi vil ut fra tilbakemeldinger kunne luke ut feil, å bedre den generelle opplevelsen brukerne har av programvaren. 1.4. Planlegging, Oppfølging og Rapportering 1.4.1. Systemutviklingsmodell Vi har tatt opp og diskutert flere utviklingsmodeller relevant for dette prosjektet, blant andre evolusjonær, inkrementell og XP (extreme Programming). Vi har valgt å ta for oss disse utviklingsmodellene, fordi de vil dekke prosjektets behov for å få se tidlige resultater av utviklingen, i tillegg til at modellene er relativt åpen for endringer. Ved bruk av en av disse utviklingsmodellene vil vi også ha muligheten for å utvikle modul for modul, og til slutt sette dem sammen vha. et UI. Dette tilfredsstiller også oppdragsgiverens ønsker. Vi vurderte å ta den evolusjonære utviklingsmodellen i bruk, fordi den ville gitt oss et tidlig visuelt overblikk over tjenesten vi skal utvikle, og at vi for hver gjennomkjøring kunne tatt for oss og utviklet en og en modul. Men vi mener at XP er en mer strukturert utviklingsmodell og mer relevant for prosjektet. Den inkrementelle utviklingsmodellen ville vært helt gunstig å bruke, siden den gir oss en tidlig og komplett oversikt over kravspesifikasjon, og fordi vi legger vekt på å utvikle modul for modul, som til slutt settes sammen vha. et UI. Men siden vi er en såpass liten gruppe, og har muligheten til å ha en on-site customer, har vi heller valgt å bruke XP som utviklingsmodell. Vi bruker da samme prinsippet som ved den inkrementelle utviklingsmodellen, og utvikler modul for modul som til slutt settes sammen vha. et UI. I den første iterasjonen vil vi i se nøye på kravspesifikasjon, for å finne de eksakte systemkravene til tjenesten. I motsetning til de andre aktuelle utviklingsmodellene, skjer all programmering parvis i XP. Som resultat får man en bedre struktur, og en generelt bedre kode. Med XP som valgt utviklingsmodell, vil vi i tillegg raskt kunne se resultater (eller problemer) av moduler som skal implementeres i den endelige programvaren. Vår on-site customer vil da også kunne komme med innspill/forslag til endringer. Ulempen ved XP, er at modellen er ganske uforutsigbar når det gjelder estimering av tid, som igjen resulterer i dårlig/unøyaktig estimering av ressurser. For å forhindre dette har vi tenkt til å slippe relativt hyppige beta-releaser (første betaversjon slippes etter 6. iterasjon, og vil deretter følges opp med ny versjon etter hver 3. iterasjon) ut på det internasjonale markedet. På denne måten vil vi kjapt få bruker-testet tjenesten, og ved hjelp av brukerenes feedback, estimere gjenstående utvikling i tid og ressurser. Hvis XP ikke er gjennomførbart, vil vi kunne falle tilbake på den inkrementelle utviklingsmodellen. Side 8
1.4.2. Statusmøter og beslutningspunkter Med extreme Programming som vår utviklingsmodell, har vi har bestemt at hver iterasjon skal gå over 2 uker. Vi vil i starten av hver iterasjon ha et såkalt planning game. På dette møtet fastslås det hva den kommende iterasjonen vil bestå av. I hvert planning game vil også aktiviteter fra forrige iterasjon bli diskutert. Man vil da kunne ta lærdom av feil, og forbedre fremtidige estimeringer rundt prosjektet. Ved planning games skal utviklerne, on-site customer og evt. advokater være til stede. 1.5. Risikoanalyse 1.5.1. Kritiske suksessfaktorer Alle juridiske hensyn må overholdes. Oppdragsgiver/plateselskap må ikke trekker seg før et endelig produkt er ferdigutviklet, da de er den økonomiske motoren under utviklingsperioden. Det er derfor viktig å ta hensyn til innspill som kommer underveis, i den grad det lar seg gjøre. Tidsfrist(er) må overholdes. Helst med god margin, for å forhindre eventuelle konkurrenter fra å komme utviklingen i forkjøpet. Komme med flere beta-releaser slik at det blir snakk rundt programvaren. Gjøre avtaler med store annonsører, slik at drift av gratisversjonen muliggjøres uten store tap. Økonomien i prosjektet vil da også sikres i større grad. 1.5.2. Risikoevaluering 1.5.2.1. Risikovurdering Risiko er definert som produktet av sannsynlighet og konsekvens. I tabellen under har vi gjort en risikovurdering av problemer som kan oppstå underveis. Nærmere beskrivelse av de aktuelle problemstillingene finner du i punkt 1.5.2.2. Beskrivelse Sannsynlighet Konsekvens Risikovurdering Sykdom og andre ting som holder 4 3 12 % arbeideren borte over lengre tid Manglende Kompetanse 2 6 12 % For høye teknologiske krav 2 8 16 % Finansielle problemer 5 8 40 % Fatale endringer 3 7 21 % For lave estimater 4 8 36 % Konkurrenter kommer på markedet med tilsvarende produkt, før oss 2 9 18 % Sannsynlighet og konsekvens på en skala fra 1 til 10. Side 9
1.5.2.2. Prioritering De forskjellige risikoene vil naturligvis vektlegges i varierende grad, avhengig av risikovurderingen. Vår utviklingsmodell (XP) sitt syn på risiko er at de fleste av dem aldri vil inntreffe, så derfor har ikke preventiv ressursbruk på dette området veldig høy prioritet. Man bør derimot være forberedt på at risiko inntreffer, og være tilpassningsdyktig når det skjer. Som tabellen i punkt 1.5.2.1 illustrerer, er økonomiske problemer en risiko av stor betydning i vårt prosjekt. Vi må være forberedt på at underestimering kan bli et tema, spesielt når det gjelder hardware, da dette er et prosjekt med ganske stort omfang, i tillegg til at det har potensialet til å vokse underveis. Andre finansielle problemer kan også oppstå. Det er mange investorer involvert, og når vi nå i tillegg er inne i en finansiell krisetid, øker risikoen for at en eller flere investorer trekker seg. Et prosjekt av dette omfanget vil fort kunne bli av interesse for utenforstående. Som vist i tabellen vil dette være kritisk for prosjektet, både økonomisk og tidsmessig. 1.6. Kvalitetssikring 1.6.1. Kvalitetssikring av kritiske suksessfaktorer I finansielle nedgangstider er det desto viktigere at vi sørger for overbevisende resultater underveis. Det skaper en trygghet rundt prosjektet og blidgjør investorene. Det bør være en god dialog mellom utviklerne og investorene, slik at de blir fornøyde. For å få til det, må vi overholde prosjektplanen, og vise til resultater. Likevel kan det oppstå problemer hvis det kommer ønsker om endringer, som vil være vanskelig for utviklerne å implementere. Vi vil derfor gi ut betaversjoner hyppig, og tilpasse oss endringer i best mulig grad. Disse utgivelsene sørger også for PR rundt programmet og tjenesten. Publisiteten vil være med på å blidgjøre annonsører, og nye annonsører vil eventuelt komme på banen. Samtidig er det ønskelig å holde en lav profil i den innledende fasen av prosjektet. På denne måten vil vi forhindre at konkurrenter kommer på markedet med tilsvarende produkt, før oss. Det er også viktig å ha en jevn dialog med advokater, gjennom hele prosjektet. De er ekspertene innenfor det juridiske aspektet, og skal sikre at vi holder oss innenfor alle lovens rammer. Vi har derfor også en advokat med i styringsgruppen. 1.7. Gjennomføring Hovedaktivitetene i utviklingen er lagt opp med hensyn til å få en fullverdig beta-versjon klar så tidlig som mulig, uten å kompromissere kvaliteten. Vi har derfor valgt å nedprioritere modulene for opp- og nedlasting, samt diverse mindre moduler, som for eksempel nyhetsoppdateringer. Dette er også i takt med de retningslinjene vi er gitt. Vi benytter oss av utviklingsmodellen XP, og vil ha møter om videre arbeid annenhver uke. Vi vil da komme nærmere inn på hvilke moduler det vil jobbes med i kommende periode. Grunnet påskeferie vil iterasjon 3 og 4 bli slått sammen, slik at 3. iterasjon vil gå over 3 uker. Side 10
1.8. Kontrakter og avtaler 1.8.1. Det juridiske Alle kontrakter som angår hvilken musikk som kan gjøres tilgjengelig, er gjort mellom vår oppdragsgiver og de involverte plateselskapene. Dette omfatter blant annet hvem som får tilgang, hvilken type tilgang, og nårtid musikken gjøres tilgjengelig. Det er leid inn eksterne jurister, og advokaten i styringsgruppa er med for å sikre at programvaren ikke åpner for brudd på lovverk, eller platekontrakter. 1.8.2. Det praktiske Oppdragsgiver Per Pedersen har i samarbeid med representanter fra platebransjen satt sammen en avtale som omhandler blant annet de økonomiske og tidsmessige aspektene med prosjektet. Det er i første omgang budsjettert med to millioner kroner for å utvikle selve programvaren. Pedersen og juristene er satt utenfor denne økonomiske rammen, selv om de vil jobbe side om side med oss. Hardwarekostnader vil man komme nærmere inn på etter at kravspesifikasjonen er på plass. Driftskostnader har de heller ikke noen formening om, annet enn at det ikke bør være unødvendig høyt. Underveis i prosessen vil det bli gjort vurderinger i forhold til videreutvikling ut over det som allerede er kontraktsfestet. Disse møtene vil bli avholdt under beslutningspunkter i diagrammet på neste side. Pay2Play planlegges utgitt i januar 2010, og det forventes da at programvaren er godt testet. Det gis derfor ut betaversjoner hver 6. uke, som vist i diagrammet. Avtalen innebærer også at vi får utviklingsjobben når en sannsynlig utvidelse av tjenesten blir aktuelt. Dette er en avgjørelse som plateselskapene ønsker skal fungere som en gulrot for Code-IT. Hvis systemets kostnader holdes på et akseptabelt nivå, vil det være enklere for investorene å sette i gang utvidelser. Side 11
1.9. Gantt-skjema Side 12
2. KRAVSPESIFIKASJON 2.1. Funksjonell kravspesifikasjon Pay2Play er en abonnementstjeneste for musikk over internett. Systemet skal inneholde et bibliotek av musikk fra alle de involverte plateselskapene/rettighetshaverne, samt bidrag fra usignerte band/artister. Det vil også være mulig å kjøpe låter fra vårt arkiv, samt abonnere på oppdateringer/nyheter fra artister. Det skal føres statistikk over all lytterdata, slik at dette kan benyttes når artister/plateselskaper skal få betalt. Brukergruppen Free skal utsettes for reklame, enten i form av bilder eller lydklipp som spilles av mellom låter. Brukergruppen Premium vil ha mulighet for å laste opp egenprodusert musikk, som legges i vårt arkiv - tilgjengelig for våre øvrige brukere. For mer informasjon om brukergrupper, se punkt 1.2.2. De funksjonelle kravene i systemet er representert med en use-case modell vist i pkt 2.1.1 og med tilhørende beskrivelser i pkt 2.1.2. Side 13
2.1.1. Use-case modell Side 14
2.1.1.1. Diskusjonsmomenter Før vi fikk på plass diagrammet var det noen momenter vi så oss nødt til å ta en ekstra runde på. Vi måtte avgjøre om inn- og utbetaling var separate caser, eller om begge tilfellene skulle håndteres i samme case. Den samme vurderingen ble gjort for hvordan reklamedistribusjonen skulle fungere. Vi fant til slutt ut at en separering var det mest hensiktsmessige, i begge tilfeller. Aktørene Free og Administrator har to helt forskjellige tilnærminger til reklamen. Administratoren står for ajourføring av reklameinnholdet, mens gratisbrukeren bare har en passiv tilknytning til distribusjonssystemet. Etter å ha sett nærmere på betalingssystemet, kom vi frem til at utbetalingen foregår på andre premisser enn innbetaling. Den automatiserte innbetalingen vil være basert på et fast månedsbeløp, mens utbetalingen vil være variabel ettersom den baserer seg på statistikk. Pay2Play er nødt til å basere seg delvis på Peer2Peer-teknologi for at tjenesten skal kunne fungere i det omfanget som er tiltenkt. Denne teknologien vil være en viktig del av avspillingsfunksjonen når det skal spilles av låter via internett. Først så vi på muligheten for å implementere det i ett og samme case, men valgte til slutt å legge Peer2Peer-støtten i en egen case, som inkluderes i avspilling. Dette valgte vi på bakgrunn av at avspillingsfunksjonen ikke vil benytte seg av denne hjelpefunksjonen til en hver tid. Den vil for eksempel ikke være aktiv under avspilling av lokale låter. 2.1.2. Highlevel use-case Use-case: Aktør: Mål: Normal hendelsesflyt: Variasjoner: Registrer brukerkonto Uregistrert Bruker Uregistrert Bruker kan registrere en brukerkonto, enten av typen Free, Premium eller Business via P2P s hjemmeside. 1. Aktøren trykker på Registrer konto knappen. 2. Aktøren velger kontotype. 3. Aktøren fyller inn nødvendig data. (Brukernavn, passord, e-post ) 4. Utfører use-case Last ned programvare. Hvis aktøren velger å registrere en konto av typen Premium eller Business er det krav om å oppgi kredittkort-opplysninger i pkt 3, og systemet trekker så penger for x antall mnd med gjeldende kontotype. Ved pkt 3 vil aktøren få melding hvis brukernavnet er i bruk og må registrere ett nytt brukernavn. Ved pkt 4 vil aktøren få lastet ned Business versjonen, om aktøren har registrert Business -konto. Use-case: Aktør: Mål: Normal hendelsesflyt: Variasjoner: Last ned programvare Uregistrert bruker og Bruker Å få lastet ned programvaren via P2P s hjemmeside, slik at brukeren får tilgang til P2P s tjenester. 1. Aktøren trykker på Last ned programvare knappen. 2. Aktøren velger programvareversjon (Orginal/Business) 3. Aktøren laster ned aktuell programvare og installerer den. Om aktøren velger å laste ned business versjon ved pkt 2, blir aktøren bedt om å autentisere seg, for å verifisere om aktøren har Business -konto. Side 15
Use-case: Aktør: Mål: Normal hendelsesflyt: Variasjoner: Avspilling Bruker Spille av valgt låt for aktøren 1. Aktøren markerer(velger) låten som skal avspilles fra spilleliste/søk. 2. Systemet henter låtinformasjon. 3. Låten spilles av ved at aktøren trykker på Play knappen. Låten kan også spilles av ved at brukeren dobbelklikker på låten. Aktøren vil også ha mulighet for å spille av neste og forrige låt i spillelisten/søket. Aktøren har under hele hendelsesflyten lov til å justere volumet for avspilling eller sette låten til pause. Use-case: Aktør: Mål: Normal hendelsesflyt: Variasjoner: Deling vha. Peer2Peer-teknologi Avspilling, Bruker Brukeren er med på avlaste systemet ved å spre avspillet låt til andre brukere 1. Brukeren laster ned bruddstykker av låt som avspilles. 2. Brukeren er med på å laste opp disse bruddstykkene til andre brukere. 3. Etter avspilling av låt (ny låt/stop) vil nedlastet data bli slettet. Hvis det ikke er brukere å kobles opp mot, vil caset være passivt. Use-case: Aktør: Mål: Normal hendelsesflyt: Variasjoner: Last ned/kjøp musikk Bruker Aktøren slipper å være online for å lytte til låten/albummet. 1. Aktøren markerer(velger) låten/albumet som skal kjøpes. 2. Aktøren trykker på Kjøp låt -knappen 3. Systemet ser om kreditkortopplysninger er registrert hos bruker. 4. Aktøren velger hvor låten skal lastes ned. 5. Låten lastes ned til gitt plassering og penger blir trukket fra aktøren. Nedlasting nektes dersom kreditkortopplysning ikke er registrert eller er ugyldig. Aktør får valg om å registrere nytt kredittkort eller avslutte kjøp. Use-case: Aktør: Mål: Normal hendelsesflyt: Variasjoner: Automatisert innbetaling Premium og business. Pengeinnkreving skjer automatisk når betalt tid utløper. 1. Systemet sjekker om vedkommende må betale. 2. Systemet gir beskjed om at betalt tid er utløpt. 3. Aktøren får valg om å avbryte betaling eller fortsette å betale for gjeldende konto. Ved pkt 2 og 3 vil kontoen bli degradert til free-konto til penger er overført for gjeldende kontotype. Side 16
Use-case: Aktør: Mål: Normal hendelsesflyt: Variasjoner: Administrere låter Administrator, Artist/Plateselskap og Premium Legge til/endre/fjerne låter 1. Aktøren trykker på Administrer låter. 2. Systemet viser en oversikt over låtene som aktøren har eierskap til. Brukerens autentisering avgjør hvilke låter som er tilgjengelig. Administrator har eierskap over alle låter i systemet. 3. Aktøren velger last opp nye låter eller et utvalg låter som skal endres/fjernes. 4. Aktøren fyller inn informasjon om låtene. (artist/tittel/sjanger o.l.) 5. Nye låter/oppdatert informasjon sendes tilbake til systemet. 6. Systemet godkjenner/avviser det nye materialet. I pkt. 4 vil aktøren få melding om eventuelle duplikater. I pkt. 6 kan systemet avdekke at låten ikke tilhører aktøren. Den aktuelle låten vil bli utelatt fra opplastingen, og en melding vil sendes til systemets administrator. Filer i feil format vil også avvises. Use-case: Aktør: Mål: Normal hendelsesflyt: Variasjoner: Administrere brukerkonto Bruker og Administrator. Administrere data ved brukerkonto 1. Aktøren trykker på Administrere brukerkonto -knappen 2. Systemet henter gjeldende data om brukerkontoen. 3. Brukeren kan så endre/slette/legge til data for kontoen. 4. Endret data blir så sendt tilbake til systemet. Ved pkt. 1 må administratoren lese inn brukernavnet for den brukerkontoen som skal endres for å få opp data om brukeren. Dersom kredittkortinformasjon blir endret/fjernet i pkt. 3, eller ikke lenger er gyldig av andre årsaker, vil kontoen bli degradert til free i pkt. 4. Denne endringen vil tre i kraft når inneværende betalingsperiode utløpet. Use-case: Aktør: Mål: Normal hendelsesflyt: Variasjoner: Administrere reklame Administrator Fjerne reklame som er utgått, og/eller legge inn ny. 1. Aktøren åpner reklamepanelet. 2. Systemet viser en oversikt over aktiv reklame. 3. Aktøren legger til/fjerner/endrer reklameinnslag. 4. Oppdatert data sendes tilbake til systemet. Pkt. 3: Hvis reklamen er i bruk, gis det melding om dette. Operasjonen vil bli utført så snart reklamen ikke er i bruk lenger. Side 17
Use-case: Aktør: Mål: Normal hendelsesflyt: Variasjoner: Utsettelse for reklame Free Utsette free -brukeren for reklame i form av audio og små animasjoner/bannere. 1. På et gitt tidspunkt skal reklame spilles av i form av audio. 2. På et gitt tidspunkt skal den visuelle reklamen byttes ut. Pkt. 1: Hvis en låt spilles av på det gitte tidspunktet, skal reklamen spilles av etter gjeldende låt. Pkt. 2: Hvis brukeren ikke har internettforbindelse på tidspunktet, vil det skje en oppdatering så snart brukeren kobles på nettet igjen. Use-case: Aktør: Mål: Normal hendelsesflyt: Variasjoner: Statistikk oversikt Administrator og Artist/Plateselskap Vise statistikk over antall avspillinger på låtene/artistene som oppfyller kravene i aktørens forespørsel. 1. Aktøren angir/filtrerer hvilken statistikk som ønskes vist. Søket kan filtreres til å vise f.eks. én bestemt artist, et plateselskap, et album, eller aktiviteten i et bestemt geografisk område. 2. Systemet viser ønsket statistikk. Hvis statistikken som forespørres ikke eksisterer, vil systemet gi en melding om dette i pkt. 2. Use-case: Aktør: Mål: Normal hendelsesflyt: Variasjoner: Spilleliste generering Bruker Brukeren får opprettet en spilleliste 1. Aktøren oppretter ny spilleliste. 2. Aktøren søker etter artist/låt. 3. Systemet finner artist/låten. 4. Aktøren legger til ønsket sang i spilleliste. 5. Repeterer punkt 2, så lenge det er ønsket. Ved pkt 3. om systemet ikke finner låt/artist, kan aktøren avbryte eller gjenta pkt 2. Use-case: Aktør: Mål: Normal hendelsesflyt: Variasjoner: Abonnere på artist/plateselskap Bruker Brukeren får oppdateringer om en artist, eller nyheter fra ett plateselskap 1. Aktør søker etter artist/plateselskapene 2. Systemet finner artist/plateselskap. 3. Aktør melder seg på nyhetsbrev. 4. Får nyheter om artisten, som nye sanger, konserter osv. 5. Repeterer fra punkt 1, så lenge det er ønsket. Ved pkt 2. Hvis systemet ikke finner artist/plateselskap, kan aktøren avbryte eller gjenta pkt 1. Side 18
Use-case: Aktør: Mål: Normal hendelsesflyt: Variasjoner: Søk på låtinformasjon Bruker Brukeren søker etter ønsket låt. 1. Bruker velger avansert søk. 2. Han får da muligheten til å velge mange forskjellige filtreringsmuligheter, som for eksempel: År, sjanger, artist, plateselskap, brukeropplastet musikk, nyeste sanger, mest populære, osv. 3. Han velger de punktene han skal søke innenfor, og søker. 4. Systemet ser etter låter/artister med gitte parameter. 5. Repeterer fra punkt 1, så lenge det er ønsket. Ved pkt 4. Hvis systemet ikke finner noe, kan aktør avbryte eller søke på ny. Use-case: Aktør: Mål: Normal hendelsesflyt: Variasjoner: Autentisering Bruker, Administrator og artist/plateselskap Systemet finner ut hvilken brukergruppe aktøren tilhører. 1. Aktør skriver inn brukernavn og passord. 2. Systemet validerer brukernavn og passord, og finner ut hvilken brukergruppe aktøren tilhører. 3. Da kan han få tilgang til de mulighetene programmet gir han. Hvis ikke brukernavn og passord stemmer overens, så får aktøren feilmelding. Hvis brukerkontoen allerede er i bruk av en annen IP får aktøren en feilmelding. Use-case: Aktør: Mål: Normal hendelsesflyt: Variasjoner: Automatisert utbetaling Bruker, Administrator og artist/plateselskap At artist/plateselskap skal få betaling. 1. Systemet sjekker hvor mye en artist skal få, ut fra statistikk over antall ganger avspillet. 2. Så blir pengene automatisk overført til artisten, på grunnlag av antall ganger spilt. N/A Side 19
2.2. Domenemodell Figuren under illustrerer funksjonell struktur og relasjoner i P2P-systemet, ved hjelp av et konseptuelt klassediagram (UML). Side 20
2.3. Funksjonelle krav 2.3.1. Risikoanalyse I tabellen under har vi satt opp en risikorangering fra 1 til 6. Dette vil være grunnlaget for hvilke caser vi gjør en grundigere gjennomgang av. Case Forretningsmessig Teknologisk Sum Risiko utfordrende Registrer brukerkonto 6 1 7 Last ned programvare 6 1 7 Automatisert 5 2 7 innbetaling Automatisert utbetaling 5 2 7 Administrere 1 1 2 brukerkonto Administrere reklame 3 1 4 Administrere låter 6 3 9 Avspilling 6 1 7 Last ned/kjøp musikk 6 3 9 Søk på låtinformasjon 6 1 7 Spillelistegenerering 2 1 3 Abonner på artist/ / 1 1 2 Utsettelse for reklame 3 1 4 Autentisering 6 3 9 Statistikk 4 1 5 Deling vha. P2Pteknologi 6 6 12 Ut fra tabellen ser vi at den forretningsmessige risikoen alltid vil være tilsvarende - eller høyere - rangert enn den teknologiske utfordringen. Tre av casene med rangering 7 eller mer involverer overføring av penger. Vi har valgt å se nærmere på bare én av disse. Vi har også valgt å se på registrering av konto, selv om det ikke er en teknologisk kompleks case. Registreringen er brukerens inngang til tjenesten og er nødt til å fungere på en tilfredsstillende måte. Nedenfor følger en komplett oversikt over funksjonene vi har valgt å beskrive i hvert sitt extended use-case i pkt 2.3.2: Registrere brukerkonto Det aller første caset som er aktuelt er registrering av brukerkonto. Hvis ikke brukerregistreringen fungerer som den skal, vil ikke brukeren kunne få tilgang til P2P s tjenester. I verre tilfeller kan det føre til at brukeren får tilgang på tjenester, selv om essensielle opplysninger inneholder mangler/feil. Autentisering Autentiseringen er en vesentlig del av systemets sammensetning, og det er helt essensielt for hele systemet at den fungerer slik som tiltenkt. Autentiseringen sørger for at brukeren får tilgang på de tjenester som er betalt for, og de innstillingene/aktivitetene brukeren har gjort på sin konto. Autentiseringen blir brukerens fingeravtrykk i systemet, og vi ønsker å gi en best mulig beskrivelse av hvordan dette skal virke. Side 21
Deling vha. Peer2Peer-teknologi I følge risikoanalysen er dette den mest kritiske funksjonen i vårt prosjekt. Det er en forretningsmessig høy risiko ettersom det vil være umulig å drifte prosjektet uten at kapasitetsbehovet avlastes av denne funksjonen. Funksjonen er i tillegg en stor teknologisk utfordring i vårt prosjekt, siden den skal kobles opp og fungere sammen med annen teknologi og funksjonalitet. Det å basere tildeling av linjekapasitet til brukerne ut fra deres status i denne funksjonen, vil bli spesielt utfordrende. Administrere låter Å administrere låter innebærer at brukeren får tilgang til å laste opp låter til vårt system. Som nevnt i pkt. 1.5.1 i prosjektplanen, er juridiske hensyn en kritisk suksessfaktor for P2P. Vi må være påpasselig, og i best mulig grad forsikre oss mot uautorisert opplasting av rettighetsbeskyttet materiale. Dette er årsaken til at vi ser oss nødt til å se nærmere på denne casen. Selv om hver enkelt bruker også har et ansvar her, skal ikke P2P være et system som tilrettelegger for ulovligheter. Advokatene som er involvert i utviklingen, vil ha avsatt ekstra tid i forkant av utviklingen av denne seksjonen. Kjøp av låt(er) Kjøp av låter har vi også valgt å se nærmere på, ettersom det kommuniseres med en tredjepart. Her er det selvsagt vesentlig at brukerne blir belastet korrekt, for de låtene som kjøpes. Et godt fungerende låtsalg er viktig for tjenestens likviditet, og investorenes interesser. Side 22
2.3.2. Extended use-case Use-case: Aktør: Mål: Beskrivelse: Før-betingelser: Etter-betingelser: Spesielle krav: Deling vha Peer2Peer-teknologi Avspilling, Bruker Brukeren er med på å avlaste systemet ved å spre avspillet låt til andre brukere Når brukeren lytter til en låt, vil bruddstykker av den aktuelle låten mellomlagret på brukerens PC. Disse bruddstykkene vil deles med andre brukere som vil lytte til samme låt, for å forhindre buffring. Brukeren har mellomlagret bruddstykker av en ekstern låt Midlertidig data blir slettet N/A Aktørens handling 1. Caset starter når flere brukere vil lytte til samme låt. Hendelsesflyt Systemets tilbakemelding 2. Kobler brukere opp mot hverandre i forhold hvem som har behov for hvilke bruddstykker. 3. Bruddstykkene lastes opp til angitte brukere, uten at det krever noen aktiv handling fra brukerens side. Punkt 2 & 3 vil repeteres for alle brukerne som involveres i syklusen. Alternativ Hendelsesflyt Pkt. 2: Systemet finner ikke potensielle brukere å koble sammen. Disse brukerne vil da få større prioritet når opplastingskapasiteten til systemet fordeles. Pkt. 3: Hvis brukeren aktivt forhindrer opplastingen vil brukeren bli nedprioritert av systemet, og få melding om dette. Side 23
Use-case: Aktør: Mål: Beskrivelse: Før-betingelser: Etter-betingelser: Spesielle krav: Autentisering Bruker, Administrator og artist/plateselskap Systemet finner ut hvilken brukergruppe aktøren tilhører. Aktøren skriver inn brukernavn og passord, som systemet bruker for å finne ut om kontoen er gyldig, og hvilken kategori den har. N/A N/A N/A Aktørens handling 1. Use-caset starter når en bruker ønsker å logge seg på. Hendelsesflyt Systemets tilbakemelding 2. Ber om brukernavn og passord 3. Skriver inn brukernavn og passord 4. Sjekker brukernavn og passord 5. Sjekker om kontoen er logget på en annen klient. 7. Aktøren får tilgang til tjenestene, avhengig av hvilken brukergruppe kontoen tilhører. 6. Sjekker hvilken brukergruppe kontoen tilhører, og returnerer dette til programvaren. Alternativ Hendelsesflyt Pkt. 1: Hvis programmet ikke klarer å koble seg opp mot internett, vil programmet gå i offlinemode. Aktøren har da bare tilgang til å spille av lokale låter. Pkt. 4: Hvis brukernavnet ikke er registrert, eller at brukernavn og passord ikke stemmer overens, kommer systemet med en melding om dette, og går tilbake til pkt. 2. Ved 3 feil inntastinger vil kontoen bli tildelt ett nytt tilfeldig passord, som brukeren vil få tilsendt på sin registerte e-postadresse. Pkt. 5: Hvis brukerkontoen allerede er i bruk, vil nåværende økt kobles fra og aktøren vil bli logget på, med en melding om at kontoen var i bruk. Side 24
Use-case: Aktør: Mål: Beskrivelse: Før-betingelser: Etter-betingelser: Spesielle krav: Registrer brukerkonto Uregistrert bruker Uregistrert Bruker kan registrere en brukerkonto, enten av typen Free, Premium eller Business via P2P s hjemmeside. Brukeren velger Registrer konto og velger deretter en brukergruppe. Brukeren fyller så inn nødvendig informasjon, som sendes til systemet. Aktøren laster deretter ned aktuell programvaren. N/A N/A N/A Aktørens handling 1. Use-caset starter ved at aktøren vil registrere en brukerkonto Hendelsesflyt Systemets tilbakemelding 2. Ber om brukeropplysninger 3. Fyller inn brukeropplysninger 4. Sjekker om brukeropplysninger allerede er registrert 5. Ber om ønsket kontotype 6. Velger aktuell kontotype 7. Sjekker om kontotypen krever betaling 8. Ber om betalingsmetode 9. Gir opplysninger om betalingsmetode 10. Validerer betalingsopplysninger 11. Aktiverer brukerkonto 12. Kjører use-caset; last ned programvare Alternativ Hendelsesflyt Pkt. 4: Hvis opplysningene er registrert fra før, gir systemet melding om dette og går tilbake til pkt. 2. Det samme vil skje ved mangelfulle/feil opplysninger. Pkt. 7: Hopper direkte til pkt. 11 hvis kontotypen ikke krever betaling. Pkt. 10: Hvis valideringen mislyktes, gir systemet melding om det, og gir brukeren valg om å gå tilbake til pkt. 5 eller 8. Pkt. 12: Hvis use-caset avbrytes pga. evt. feil, vil aktøren ha tilgang til å laste ned programvare gjennom pålogging via P2Ps webtjeneste. Hvis økten termineres før pkt. 11 er gjennomført, kanselleres registrering av brukerkonto. Side 25
Use-case: Aktør: Mål: Beskrivelse: Før-betingelser: Etter-betingelser: Spesielle krav: Administrere later Administrator, Artist/Plateselskap og Premium Legge til/endre/fjerne låter Aktøren trykker på Administrer låter, og får en oversikt over låtene han/hun har eierskap til. Tilgjengeligheten avgjøres ved å sjekke autentiseringen. Aktøren kan deretter laste opp nye låter, eller fjerne/redigere eksisterende. Den oppdaterte informasjonen sendes tilbake til systemet. Aktøren må være autentisert. Administrator har eierskap over alle låter. N/A N/A Hendelsesflyt Aktørens handling 1. Use-caset starter ved at aktøren trykker på Administrere låter. 5. Svarer på systemets forespørsel 7. Velger låt(er) operasjonen skal utføres på Systemets tilbakemelding 2. Sjekker aktørens kontotype 3. Gir en oversikt over låter aktøren har eierskap til. 4. Ber om ønsket operasjon (ny/endre/fjern) 6. Ber aktøren om å velge låt(er) 8. Utfører operasjon 9. Validerer nye later 10. Oppdaterer låtarkivet Alternativ Hendelsesflyt Pkt. 2: Hvis aktøren ikke er autentisert som premium-bruker, administrator eller artist/plateselskap, kjøres ikke caset. Pkt. 3: Hvis aktøren ikke har noen eksisterende eierskap til låter, er det kun operasjonen last opp som blir tilgjengelig i pkt. 4. Pkt. 4: I dette punktet gis aktøren valget mellom å laste opp, fjerne eller redigere (informasjon om) låter. Pkt. 5: Hvis aktøren velger operasjonen last opp, går systemet rett til pkt. 8. Hvis aktøren ikke velger denne operasjonen utføres ikke valideringen i pkt. 9. Pkt. 7: Hvis aktøren har valgt operasjonen rediger, gjøres disse endringene i pkt 7. Den endrede dataen sendes deretter til systemet, som går videre til pkt. 10. Avslutte: Hvis aktøren ikke ønsker å avslutte etter pkt. 10, går systemet tilbake til pkt. 4. Side 26
Use-case: Aktør: Mål: Beskrivelse: Før-betingelser: Etter-betingelser: Spesielle krav: Last ned/kjøp musikk Bruker Aktøren slipper å være online for å lytte til låten/albummet. Aktøren velger låten/albumet som skal kjøpes, og trykker på kjøp. Systemet validerer deretter betalingsmetoden som brukeren har valgt, og trekker et gitt beløp. Brukeren kan deretter laste ned låten(e). Aktøren må være autentisert. Aktøren har funnet og valgt ønsket låt. Ønsket låt er lastet ned til brukerens lokale lagringsmedium. N/A Hendelsesflyt Aktørens handling 1. Use-caset starter ved at aktøren vil kjøpe en låt. 7. Aktøren laster ned låt Systemets tilbakemelding 2. Sjekker om låten er betalt fra før. 3. Sjekker hvilket ønsket betalingsmiddel brukeren har registrert i kontodetaljene. 4. Validering 5. Penger trekkes fra aktøren. 6. Gir brukeren tilgang til å laste ned låt Alternativ Hendelsesflyt Pkt. 2: Hvis låten allerede er betalt, kjøres pkt. 5 i use-caset. Pkt. 3: Hvis aktøren ikke har oppgitt betalingsopplysninger i brukerkontoen, får han/hun valget mellom å avslutte kjøpet, eller å registrere betalingsopplysninger. Pkt. 4: Hvis valideringen mislykkes, får aktøren valget mellom å avslutte, eller å forsøke på nytt ved å registrere nye betalingsopplysninger. Pkt. 5: Hvis aktøren ikke har tilstrekkelig betalingsmidler, får han/hun valget mellom å avslutte, eller å forsøke på nytt ved å registrere nye betalingsopplysninger. Pkt. 7: Hvis nedlastingen avbrytes, har brukeren tilgang til å laste ned låten ved senere anledninger via brukerkontoen. Side 27
Sekvensdiagram for betaling 2.4. Overordnede operasjonelle krav 2.4.1. Systemet Siden P2P skal lanseres som en internasjonal tjeneste, er det viktig at kapasiteten er stor nok. Det er derfor er det viktig at systemet er riktig dimensjonert. Brukermasse Systemet må være dimensjonert for en stor brukermasse. På forhånd er det vanskelig å komme med en god estimering over hvor mange brukere vi kan forvente. Hvis programmet blir godt mottatt kan det være snakk om flere millioner brukere. Vi må derfor lage et system som kan håndtere 2 millioner påloggede brukere. For å takle en slik påkjenning, kreves det en god infrastruktur. Våre servere skal ha kapasitet til å håndtere opp til 75000 påloggede brukere. Lagringsplass Systemet krever stor lagringskapasitet. I tillegg til alle låtene vi i samarbeid med plateselskapene skal gjøre tilgjengelig, skal serverne også håndtere låter som lastes opp av våre brukere. For å holde filstørrelsene på et akseptabelt nivå, har vi valgt å kun tillate filformatet MP3 på våre servere. De aller fleste låtene vil da ha en størrelse på under 10Mb. Vi velger likevel å estimere med dette som snittstørrelse, for å være på den sikre siden. Vi regner med å gjøre ca. 3 millioner låter tilgjengelig i løpet av tjenestens oppstartsfase. For disse låtene må vi da sette av 30Tb harddiskplass. Når vi i tillegg må ta høyde for at (premium)brukerne har opplastningsrettigheter, har vi i første omgang estimert med 50Tb lagringsplass. Systemet skal være tilpasset endring, slik at det ekstra lagringsplass skal kunne implementeres rask og smertefritt. Filformat Selv om vi som sagt kun kommer til å tillate/bruke MP3-format i våre tjenester, skal programvarens avspillingsfunksjon også støtte følgende formater: WMA, WAV, OGG og FLAC. Dette gjøres med hensyn til at avspilleren også skal fungere for brukerens lokale filer, som ikke nødvendigvis er kjøpt hos oss. Internett Ettersom vi skal benytte oss av streaming fra servere, er det viktig å ha internettlinjer med meget høy opplastningshastighet. For å i det hele tatt ha mulighet til å betjene 2 millioner (teoretiske) Side 28
brukere, må vi ha flere servere strategisk fordelt på det globale markedet. Fra hver av disse serverne skal det være en internettutgang med kapasitet på minst en Gbit/s. Systemet vil i tillegg avlastes vha. Peer2Peer-teknologi. Ytelse Det settes følgende krav til systemets ytelse: Programvaren skal kunne startes opp på < 5 sekunder. En brukerautentisering skal ta < 5 sekunder. Brukeren vil da ha tilgang til alle online-tjenester i løpet av maksimalt 10 sekunder. Det skal ta 2-3 sekunder fra brukeren gjør et søk, til resultatene presenteres. Ved kjøp av låter skal validering og betaling skje i løpet av maks. 5 sekunder. (tiden det tar fra brukeren sender betalingsinformasjon, til låten er tilgjengelig for nedlasting) Når brukeren klikker på en låt som skal streames, skal det ta < 1 sekund før sangen starter. (avvik som følge av brukerens nedlastningshastighet vil komme i tillegg) Tilgjengelighet Serveren må ha en oppetid på minst 99 %. Ettersom dette er en internasjonal tjeneste, vil det være vanskelig å finne et felles tidspunkt for planlagt nedetid. Serverne vil derfor tas ned separat, på tidspunkter som er gunstige i plasseringens tidssone, når det lar seg gjøre. 2.4.2. Brukerens systemkrav Her beskrives hvilke systemkrav P2P stiller til brukeren, for at systemet skal fungere optimalt: For å få best mulig kvalitet og raskest mulig responstid, bør brukeren ha en internett-tilkobling av type SDSL, ADSL, ADSL2+, fiber - eller annet med tilsvarende kapasitet. Minimumskravet for å unngå buffring utover sekundet vi tillater i oppstarten, er en 3G-tilkobling (rundt 350 kbit/s). P2P-programvaren krever et operativsystem av typen Windows XP, Windows Vista, MacOS eller Linux. Det skal i tillegg utarbeides støtte for det kommende operativsystemet Windows 7. Med unntak av lydkort, er P2Ps hardwarekrav tilsvarende de aktuelle operativsystemenes krav. P2P krever at brukeren har et lydkort - enten integrert i hovedkortet, eller eksternt - og at dets drivere er installert. 2.4.3. Brukervennlighet For å gi brukeren valgfrihet har vi valgt å la programvaren støtte flere operativsystemet (se pkt. 2.4.2). Drag n drop skal i stor grad implementeres i programvaren. Man vil for eksempel kunne dra en låt fra et søkeresultat og inn i en spilleliste, slik at den automatisk blir lagret der. De fleste brukere er kjent med slik funksjonalitet fra sine OS. Programvaren vil for de fleste kunne tas i bruk uten instrukser. Det vil likevel spilles av en kort videosnutt ved første oppstart, som tar en kjapp gjennomgang av funksjonaliteten. Videoens innhold vil variere ut fra hvilken brukergruppe brukeren tilhører. Videoen vil også være tilgjengelig for senere avspilling via en hjelpemeny. I denne menyen vil det i tillegg ligge et dokument som detaljert tar for seg hvert enkelt bruksområde for tjenesten. Programvaren vil i første omgang kun være engelskspråklig, men vil oversettes etter behov. Side 29
2.4.4. Juridiske krav Alle brukere må godta en kontrakt før de kan ta i bruk programvaren. Kontrakten vil utarbeides av våre advokater og vil blant annet ta for seg ansvarsforholdet med hensyn til opplasting av musikk. Advokatene vil også ta seg av eventuelle juridiske tvister som likevel skulle dukke opp underveis. Distribuering av kopibeskyttet materiale skal ikke forekomme. 2.4.5. Opplæring Operatører/administratorer skal kunne anvende og administrere systemet etter en dags veiledning. 2.5. Delleveranser Den første betaversjonen vil gis ut 12 uker etter prosjektstart. Det vil deretter følge en ny betaversjon hver 6. uke. Det er planlagt 5 betaversjoner med følgende moduler klar for testing: Beta v 0.1: Registrering av konto, autentisering og administrering av låter. Beta v 0.2: Avspillingsfunksjon (u/p2p), søkemotor og spillelistegenerering. Beta v 1.0: Administrer brukerkonto og avspillingsfunksjon(m/p2p). Beta v 1.5: Abonneringsfunksjon, betalingsfunksjon og reklamering. Beta v 2.0: Opplastning for premiumbrukere og kjøp/nedlasting av låter. Hver betaversjon bygger på sin forgjenger. Versjon 1.0 og 2.0 vil gis ut for lukket betatesting, mens de øvrige versjonene vil testes internt. 2.6. Øvrige hardwarekrav 2.6.1. Hardware installasjon Serverne skal fordeles og installeres strategisk, ut fra forventet markedsfordeling. Hver enkelt server skal operere på en Linux-plattform. 2.6.2. Vedlikehold og oppgradering Systemet skal være tilrettelagt for oppgradering av lagringskapasitet og internettforbindelse. Alle servere vil ha samme innhold, og vil da fungere som backup for hverandre. Vedlikehold og oppgradering skal foregå i tidsrommet med minst aktivitet, i den aktuelle tidssonen der serveren er plassert. Side 30