Musik afspiller Michael Frøstrup Andersen

Transkript

1 Musik afspiller Michael Frøstrup Andersen Professionshøjskolen University College Nordjylland Professionsbachelor i softwareudvikling University College Nordjylland 1

2 Teknologi og Business Professionsbachelor i softwareudvikling psue0213 Bachelorprojekt Projektdeltagere: Michael Frøstrup Andersen Vejleder: Mogens Holm Iversen Afleveringsdato:

3 Abstract Ved fester er der mange mennesker der gerne vil høre nogle bestemte sang, da det ikke er muligt for værten at have alle sange bliver der ofte brugt youtube, problemet med at bruge youtube er at den normale afspilningsliste bliver afbrudt, og måske aldrig startet igen, dette kan forårsage at der ikke bliver afspillet noget musik i et stykke tid. For at prøve at løse dette problem er der blevet udviklet en løsning af en musikafspiller som kan afspille både youtube links og audio filer. Dette skaber dog nogle problemer da youtubes API er meget begrænset, dog kunne der godt udvikles en løsning. Denne løsning har dog selv sine begrænsninger igen på grund af youtubes api. 3

4 Table of Contents Abstract... 3 Introduktion... 7 Problemformulering... 8 Fag der bliver indraget... 9 Systemudviklingsmetoder Vandfalds modellen Konklusion/ulemper/positive sider Spiral model Konklusion/ulemper/positive sider V-shaped model Konklusion/ulemper/positive sider Iteration model Konklusion/ulemper/positive sider Unified Process Konklusion/ulemper/positive sider Extreme Programming Konklusion/ulemper/positive sider SCRUM Konklusion/ulemper/positive sider Valg af systemudviklingsproces User stories Risk management ingen forbindelse dårlig forbindelse produktet var for stort helbredsmæssige problemer projektet er mere komplex end forventet computerfejl Valg af lydfiler Feature list Arkitektur af programmet SOA

5 Strukturen i projektet Communication between app and computer app point-to-point publish-subscribe channel datatype channel guaranteed delivery Dette Projekt Tidsplan Hvorfor v2 af youtube api i stedet for v Normalisering Metoder for normalisering Hvordan skal det gøres? Asynkron design AKADEMISK ARTIKEL Introduction Wav file format MP3 file format Re-quantization I. Re-quantization in MP I. Normalizing MP3 and Wav I. How it can be done II. Conclusion References Test: Introduktion Resourcer Hvad skal testes? Hvad bliver ikke testet? Risks Schedule Udgivelses kriterier Hvorfor nåede projektet ikke det der var forventet?

6 Hvad var planen med det der ikke blev nået Konclusion References Bilag Bilag 1 (feature list, prioritering og estimering.) Bilag 2 (tidsplan)

7 Introduktion Når man er til private fester så bliver der nogle gange afspillet musik via en computer, når dette sker bliver gæster ofte fristet til at finde en youtube sang på computeren fordi afspilningslisten på computeren ikke har alle sange, dette kan godt blive træls i længden når der er mange folk der gerne vil høre mange forskellige sange, på grund af dette bliver der ofte skiftet sang mellem musikafspiller og youtube. Denne rapport vil beskrive et produkt som er blevet lavet sammenhæng med denne rapport. Dette produkt vil fjerne problemet med at skifte mellem youtube og musikafspiller da dette produkt er en musikafspiller der kan lave en afspilningsliste, som består af både audio filer og youtube links. Samtidig med at denne computer applikation skulle kunne afspille youtube videoer og audio filer, så skal appen også have mulighed for at normalisere audio filerne. Ud over dette beskriver rapporten også omkring en mobilapplikation som skulle kunne sætte sange i kø, så flere folk kan sætte sange i kø. 7

8 Problemformulering Dette projekt består af flere dele der skal arbejde sammen, dog skal der være mulighed for at bruge pc applikationen uden mobil applikationen, På grund af dette kan der bruges SOA 2.0 som er blevet lært i system integration. den første del er en applikation til en computer som skal være en musikafspiller, der skal kunne lave en afspilningsliste som kan blive oprettet ved at inputte lydfiler, mp3 og wav filer samt youtube links. Der skal samtidig være mulighed for at kunne begrænse den maksimale lyd som kan laves af en sang, og der skal derfor enten laves en normalisering af lydfilerne, eller der skal laves en limiter på dem, dette er et område som uddannelsen ikke er kommet ind på og vil derfor blive skrevet om i den akademiske artikel. Applikationen skal samtidig også kunne modtage både mp3 filer og youtube links fra den anden applikation, disse mp3 filer og youtube links skal derefter indsættes i afspilningslisten, og afspilles som den næste sang i rækken, til dette kan der bruges et messaging system som er blevet lært i system integration. dette skal applikationen kunne gøre mens den fortsat afspiller sange fra afspilningslisten på grund af dette skal dette gøres på en asynkron måde som er blevet lært i development of large scale system, da den ene process ikke skal vente på den anden. Den anden del er en applikation til en mobil som skal bruges til at sende mp3 filer og youtube links til den første applikation for at sætte diverse sange i kø, der skal være mulighed for flere mobil applikationer kan sende mp3 filer eller youtube links til pc applikationen på samme tid. Til dette kan der som skrevet tidligere bruges et messaging system som er blevet lært i system integration. Der skal samtidig laves test på begge dele af programmet, dette kan inkludere user tests, unit tests samt andre, der kan også inkluderes en test plan og der kan samtidig snakkes om hvilke tests der skal laves, hvorfor de er nødvendige samt hvorfor de burde laves frem for andre, dette er der blevet undervist i, i test. 8

9 Fag der bliver indraget SOA 2.0 (System Integration, lektion 13): I faget messaging system blev der undervist i SOA, og dette koncept er også et koncept der kan bruges i dette projekt, dette skal bruges til at implementere messaging systemet der skal snede beskeder mellem computer programmet og mobil applikationen, dette koncept bliver brugt til at lave et event driven koncept på programmet. Den event drevet del af programmet bliver kommunikationen mellem computeren og mobil appen, da computer appen skal vente på at få en besked ind, hvorefter den skal bearbejde den besked, så behøver mobil applikationen ikke at få noget svar tilbage når den er færdig. På denne måde får man også et mere løst program hvor selv hvis mobil applikationen ikke bliver brugt, eller ikke er tilstede, så vil der stadig være et computerprogram der kan udføre sine andre roller uden at det ville skabe problemer. messaging system (system integration, lektion 6-12) I faget messaging systems blev der lært at lave messaging systemer som kunne bruges til at kommunikere mellem flere programmer og endda nogle forskellige sprog, for at inddrage dette fag i projektet blev der planlagt at lave en mobil applikation som kunne kommunikere med et computer program. For at sørge for at dette fag blev inddraget mere blev der valgt at planlægge en java applikation til android mobiler, og en C# applikation som så skulle bruge det der var lært i lektionerne til at kommunikere, Messaging systemet der var planlagt til dette projekt. Dog på grund af tidsmangel blev dette fag dog ikke brugt til noget praktisk, så dette fag blev kun udnyttet til teoretisk planlægning af systemet. Asynchronous design (development of large scale systems, lektion 11) I faget development of large scale systems, blev der blandt andet undervist i asynkront design, dette er relevant for dette projekt, da dette projekt skal afspille musik mens det skal gøre andre ting. I lektion 11 i development of large scale systems, blev der snakket om hvordan et asynkront design kunne gøre programmet hurtigere, og derfor ville det være godt i store programmer der bliver nødt til at arbejde meget hurtigt, i dette projekt, bliver det brugt til at have flere features til at køre i baggrunden. Dette fag, og denne lektion skal bruges til at lave normaliseringen, så det kan køre i baggrunden, mens musikafspilleren stadig spiller musik. Dette fag skal også bruges til at sørge for at messaging systemet ikke får musikken til at holde pause når der bliver modtaget en besked, og den besked så skal behandles. Test (Test, lektion 1-13) I faget test er der blevet brugt nogle forskellige ting. En af disse ting er en testplan, der er blevet valgt at lave en testplan til dette projekt for at sikre sig at tingene bliver testet, der bliver samtidig brugt viden omkring forskellige typer tests, og der bliver taget stilling til hvilke af disse tests der skal laves i dette projekt. Der vil 9

10 også blive taget stilling til hvilke tests der skal laves som whitebox teste, og hvilke test der skal laves som black box tests, ifølge den viden som der er blevet undervist i, i faget test. Systemudviklingsmetoder når der skal vælges udviklingsmetode er der meget at tage stilling til, der er mange project management modeller at vælge imellem og mange udviklingsmetoder, i dette afsnit vil der blive forklaret omkring nogle forskellige project management modeller og nogle udviklingsmetoder som kan bruges til at udvikle et projekt. Der vil samtidig blive lavet en lille konklusion til hver enkelte udviklingsmetode og management model for at snakke om hvilke fordele og ulemper de forskellige metoder har. Vandfalds modellen Vandfalds modellen er en projektmanagement model til at lave software, hvor software udviklingen betragtes som konstant flydende nedad (som et vandfald). Denne bevægelse sker, oftest, gennem følgende faser: Figur 1 Overblik Vandfald At følge vandfaldsmodellen vil sige at gå fra én fase til den næste strengt sekventielt. For eksempel afslutter man først skrivning af kravspecifikationen helt, sådan at det efter kravspecifikation fasen er fuldstændig klart hvad systemet skal kunne. En kravspecifikation for Wikipedia kunne være "Wikipedia skal tillade at anonyme kan rette i artiklerne; wikipedia skal give folk mulighed for at søge efter information", men realistiske specifikationer vil være meget mere komplekse og detaljerede. Når og kun når kravene er fuldt beskrevet går man videre til design. I designfasen laves en "arkitekttegning" som programmørerne skal følge - dette design skal være en plan for, hvordan man implementerer kravene fra kravspecifikationen fasen. Når og kun når designet er lavet færdigt, implementeres designet af programmører. Når alle dele af systemet er lavet sætter man dem sammen i integrationsfasen. For eksempel kan et team have lavet webside komponenten af Wikipedia og et andet team har lavet server komponenten af Wikipedia. Disse komponenter skal så sættes sammen i integrationsfasen for at lave det samlede system. 10

11 Efter implementations- og integrationsfaserne er færdige laves afprøvning og fejlfinding af softwaren; fejl, der stammer fra tidligere faser, fjernes i afprøvningsfasen. Derefter installeres softwaren og senere laves vedligeholdelse, hvor ny funktionalitet kan introduceres og fejl kan fjernes. Således siger vandfaldsmodellen, at man kun skal gå til næste fase når den foregående fase er færdig og perfektioneret. Faserne i vandfaldsmodellen er således diskrete, og man hopper aldrig frem og tilbage mellem faser eller har overlappende faser. Der er dog forskellige modificerede vandfaldsmodeller, der kan indeholde mindre eller større variationer af denne proces. Konklusion/ulemper/positive sider Fordelene ved vandfaldsmodellen er, at den er meget udbredt, og nemt at forstå. Det er drevet af dokumentation, og forstærker dermed gode vaner. Modellen er afhængig af, at man har veldefinerede milepæle, for at man kan bevæge sig videre til næste fase. Der er dog også ulemper ved modellen. Den er meget idealiseret med hensyn til dokumentation af krav tidligt i processen, og er ikke god til at håndtere ændringer, da man bevæger sig slavisk frem mellem faserne. Dette gør også leveringen problematisk, da der er risiko for først at opdage kritiske fejl sent i processen. Spiral model Spiral modellen består af fire faser, som henholdsvis er planlægning, risikoanalyse, implementering og evaluering. Et projekt gennemgår disse fire faser flere gange i iterationer, som kaldes spiraler. Man begynder med den første spiral, som også kaldes baseline spiral. Alle efterfølgende spiraler bygger på baseline spiral. De fire faser indeholder følgende: Planlægning: Der indsamles krav. Risikoanalyse: Denne fase går ud på at finde risici, og evt. alternative løsninger. Til sidst i denne fase, laver man en prototype. Implementering: Fasen består af kodning og test heraf. Evaluering: Kunden vurderer og evaluerer resultatet, før det går videre til næste spiral. Modellen består af mange af de samme faser som vandfaldsmodellen. Der produceres dokumentation efter behov, og er derfor ikke fast defineret hvornår i processen dette sker. 11

12 Figur 2 Overblik Spiral model Konklusion/ulemper/positive sider Der er både fordele og ulemper ved denne model. Fordelene er at der er meget risikoanalyse, der produceres software tidligt i projektet. Det benyttes ofte på store og forretningskritiske systemer. Ulemperne er at det kan være en bekostelig metode, risikoanalysen kræver erfaring og ekspertise. Det er ikke en optimal metode til mindre projekter. V-shaped model V-modellen kan ses som en slags udvidet vandfaldsmodel. Som i vandfaldsmodellen, arbejdes der i v-modellen også i step-by-step form, det vil sige at en fase skal afsluttes før en ny fase kan begynde. Den største forskel her er, at der efter implementeringen følger testfaserne, dvs. vejen nedad holdes nu til analyse og designet, mens vejen opad igen er knyttet til test og integrationer. Figur3 Overblik V-model 12

13 Billedet viser tydeligt, hvordan der først analyseres og designes, og dette afsluttes med kodningen. Her sker så udvidelsen til vandfaldsmodellen, kodningen bliver efterfulgt af unit test, som er påbegyndelsen af testfasen. I testfasen bevæger man sig igen opad med en række test som er tilpassede til de nedadgående faser; f.eks. kodning og unit test eller Software Requirements og acceptance testen. Først når alle faser er testet, eller bedre sagt produktet er testet og det passer til den fase(trin) den står på, så er produktet færdig. Skulle en test fejle, ved man hvilken trin det gik galt på, dermed også på hvilken trin i analysen det gik galt. Konklusion/ulemper/positive sider Ligesom vandfaldsmodellen er V modellen en dyr og ufleksibel model. V-modellen har dog fordele overfor vandfaldsmodellen i forhold til succes, og fungerer godt til mindre projekter. På samme måde som vandfaldsmodellen, er den meget ufleksibel, hvilket også gør den meget dyr. Det er en ulempe at den ikke benytter sig af prototyper, og modellen giver heller ikke nogen løsningsforslag på problemer under testfasen. Iteration model I et iterativt forløb vil projektet i stedet gennemløbe en række faser, der i princippet omfatter det samme, nemlig hver for sig en miniudgave af vandfaldsmodellens faser. Der er ikke nødvendigvis lige så meget arbejde at udføre på hvert af punkterne i en iteration. En iteration tidligt i forløbet vil ofte have mest fokus på de første punkter, mens en iteration sent i forløbet måske kun omfatter programmering og test. Figur 4 Overblik Iteration Konklusion/ulemper/positive sider At lave iterationer indenfor softwareudvikling indeholder både fordele og ulemper. Fordelene er at man fanger fejl tidligt i processen. Ulemper er at man kan bruge meget tid på fejlfinding, og at man kan sidde fast i sine iterationer, uden at få defineret hvornår man er færdig. Altså sidder man nærmest fast i et loop. Mange nyere systemudviklingsmetoder er iterative, og det iterative element kobles ofte med inkrementel udvikling. Eksempler på disse metoder er Unified Process og Extreme Programming. 13

14 Unified Process UP er en populær iterativ og traditionel project management model. Men UP er også en fælles udviklingsmetode for udviklingsprocessen, som kan tilpasses de enkelte problemområder, organisationer, kompetenceniveauer og projektstørrelser. UP`s kendetegn er at den er komponentbaseret, dvs. at den sigter efter at udvikle software systemer, der består af komponenter, som kommunikerer via veldefinerede interfaces. UP benytter UML (Unified Modelling Language) gennem hele processen, et standardsprog til primært visuelle modeller af et software system. Det der især adskiller UP fra andre metoder, er de tre fundamenter, metoden er baseret på. Disse tre fundamenter er, at den er use case drevet, arkitektur centreret og iterativ og inkrementel. Begrebet use case drevet betyder, at use cases bruges til planlægning og kontrol af al fremdrift i udviklingsarbejdet fra de indledende krav overvejelser til koden. En arkitektur er den fundamentale organisering af et system som en helhed, dvs. fundamentet som systemet skal hvile på (nogle kalder det også for et overordnet design). Iterationerne resulterer i en trinvis fremgang af produktet og stadig en mindskning af risici på projektet. Denne model er optimal for de store projekter med et stort udviklingshold. Figur 5 Overblik UP Konklusion/ulemper/positive sider UP forudsætter en velstruktureret, gennemtænkt og detaljeret plan. UP benyttes ofte i lange projekter. UPs største fokus ligger på selve processen og er plan drevet, dvs. at udførelsen af projektet og kommunikation mellem faserne sker via dokumenterne. Det er god systemudviklingsproces til store projekter, hvor der er mange involverede, da den bygger på meget og god kommunikation. Dog er dette et problem ved projekter hvor der forekommer en masse ændringer. Extreme Programming XP er også både en projektmanagement model og en udviklingsmetode for udviklingsprocessen. XP benytter planning game, som er fordelt I 3 trin: exploration, commitment og steering. Hvis vi skal forstå hvad der skal ske, er vi nødt til at forstå hvordan man vil håndtere de 3 koncepter, som er kravspecificering, estimering og release og iterationsplanlægning. I exploration skriver kunder user stories, udviklerne estimerer, kunden opdeler evt. i mindre stories, og eksperimenter (spikes) ved ukendte områder bliver vurderet. I commitment fasen vælger kunden omfang og dato for den næste release, og i steering fasen sker en opdeling i iterationer og en regulering, hvor omfang af opgaver bliver estimeret igen. Denne model er optimal for små til mellemstore projekter, men kræver meget kommunikation mellem kunde og udviklingsteam. 14

15 Figur 6 Overblik XP Konklusion/ulemper/positive sider XP har gode metoder der passer godt til små og mellemstore projekter. Pga. stor kommunikation skabes der et godt samarbejde i teamet. Det er testbaseret hvilket vil sige at der er stor fokus på kvalitetssikring, og generelt i XP er der stor fokus på det endelige produkt. Dog er XP ikke optimalt at bruge til store projekter hvor der er meget dokumentation. Flere af værktøjerne, som f.eks. test first er en svær og specialiseret ekspertise. SCRUM SCRUM er en agil projekt management model, der giver mulighed for at fokusere på at levere det ønskede produkt på kort tid. Det tillader at inspicere hurtigt og gentage det aktuelle produkt (hver anden til fjerde uge). Kunden prioriterer og udviklingsholdet organiser selv den bedst mulige vej til at aflevere de højest prioriterede dele af programmet. Hver anden til fjerde uge kan alle se et færdigt produkt og beslutte sig om, at lave en levering eller fortsætte med at implementere de næste prioriteter i det nye sprint. SCRUM projekter vokser i en serie af sprints svarende til iterationer i XP. Produktet bliver designet, programmeret og testet i et sprint. SCRUM definerer 3 roller (Product Owner, Scrum Master, Team), fire møder (Sprint planning, Sprint review, Sprint retrospective, Daily scrum meeting) og 3 artefakter (Product backlog, Sprint backlog, Burndown chart). SCRUM kan blive brugt til alle arter af projekter, men passer generelt bedst, hvis det er et nyt og kompleks projekt med kort tidsrum til at udvikle det. Afhængig af kompleksiteten og størrelsen af projektet kan man så benytte UP eller XP som udviklingsmetode. Figur 7 Overblik SCRUM 15

16 Konklusion/ulemper/positive sider SCRUM er et agilt kompromis mellem ingen og for meget proces. SCRUM arbejder med kort fokus i form af sprint logs, hvori projektets fremgang evalueres hver 2-4 uge. SCRUM behøver ikke nær så meget dokumentation da selve koden af projektet er dokumentation. I SCRUM lægges der mere vægt på holdet frem for processen. SCRUM er en projektmanagement model og kan både benytte sig af traditionelle og agile udviklingsmetoder. Valg af systemudviklingsproces Boehm har udviklet et kort for at hjælpe med at finde den rigtige project management model. Han definerer 5 kritiske punkter. Hvis man ender i midten af kredsen, vælger man en agil model, ellers skal man bruge en traditionel model. Ender man med en blandet profil har man eventuelt mulighed for at tilpasse sin profil. Det gør man i Personnel, Size eller Culture. Figur 8 Projektkort Efter at man har besluttet sig for en model, skal man vælge en metode. Når dette projekt bliver lavet i boehms diagram bliver projektet meget tæt på midte, dette sker blandt andet fordi størrelsen på personalet er en enkelt person, og det kritiske ved dette projekt er kun mangel af komfort, samtidig har projektet også en stor del dynamisk udvikling hvor der godt kan ske en del ændringer i løbet af projektet, dog er disse ikke alt for store, men den ligger ved de ca. 10% change. Culture ligger omkring de 70% hvilket betyder at diagrammet ligger meget mod midten af diagrammet, på grund af dette burde der ifølge dette diagram vælges en agil udviklingsmetode. 16

17 Der er to udviklingsmetoder der kan bruges hvis man skal gå efter hvad beohms diagram siger, og det er scrum og extreme programming, dog på grund af at der kun er en enkelt person i dette projekt mister scrum meget af sin funktionalitet da det handler meget om kommunikation mellem de uddelte roller, og hvis der kun er en person kan der ikke uddeles roller. På grund af dette er der blevet valgt at bruge extreme programming, selv om der er nogle af de metoder som bliver brugt af extreme programming som ikke giver mening at lave da der kun er en person i dette projekt, dette betyder at der blandt andet mangler pair programming, og på grund af mangler som det, mangler der quality assurance, på grund af dette er der blevet valgt at der skal være mere fokus på at få testet de forskellige features ordentligt. User stories der er blevet skrevet nogle user stories, som i følger den agile fremgangs måde at forberede på. I dette tilfælde hvor brugeren også er udvikleren, er disse user stories meget simplificeret for at udtrykke de krav der er til produktet, samtidig udtrykker de features som brugeren gerne vil have i meget specifikke krav. 1. som en bruger vil jeg kunne afspille sange 2. som en bruger vil jeg kunne oprette en liste af sange 3. som en bruger vil jeg kunne skifte sang 4. som en bruger vil jeg kunne afspille en youtube video 5. som en bruger vil jeg kunne tilføje youtube videoer på afspilningslisten 6. som en bruger vil jeg kunne sortere afspilningslisten 7. som en bruger vil jeg kunne bruge min mobil til at tilføje et youtube link til afspilningslisten 8. som en bruger vil jeg kunne høre en bestemt sang som den næste og vil gøre det fra mobilen. 9. som en bruger vil jeg kunne skrue ned for lyden 10. som en bruger vil jeg kunne pause en sang Risk management Til at snakke om risk management bliver der brugt nogle risk reducing/eleminerigns metder som er kort skrevet herunder, disse fire metoder er 4 forskellige måder at håndtere risks på. Avoidance (eliminate, withdraw from or not become involved) Reduction (optimize mitigate) Sharing (transfer outsource or insure) Retention (accept and budget) ingen forbindelse hvis der ikke er forbindelse så kan der ikke afspilles youtube links, da det kræver internet, og der kan samtidig ikke laves noget kommunikation med telefon appen. på grund af dette skal det være muligt for computer appen stadig at fungere som en musikafspiller skulle internettet fejlen. 17

18 Denne fejl kan ikke undgås, da der ikke altid vil være mulighed for at få en forbindelse, og der skal derfor reduceres i stedet for, denne fejl kan reduceres ved at sørge for at programmet beholder så mange funktion som muligt når der ikke er forbindelse, og springer de funktioner over, eller gør dem utilgængelige når der ikke er forbindelse. dårlig forbindelse hvis forbindelsen er dårlig, så vil det få youtube videoer til ikke at load hurtigt nok, og på grund af dette vil det skabe problemer. Dette vil sørge for at youtube videoer ikke kan afspilles ordentligt, dog ville det stadig være muligt at modtage beskeder fra mobil applikationen, dog vil det tage længere tid alt efter forbindelse. Dette problem kan ikke løses da der ikke altid kan skabes en god forbindelse, og på grund af dette så kan der kun reduceres de problemer som en dårlig forbindelse skaber. for at reducere denne risk skal der være mulighed for at springe youtube videoer over hvis de ikke loader hurtigt nok. produktet var for stort for at sørge for at produktet ikke er for stort, så skal der laves en realistisk estimering af hvor meget der kan laves, dog kan der godt estimeres forkert, og på grund af dette kan produktet godt være for stort. For at reducere dette skal der prioriteres, for at finde ud af hvilke features der er vigtigst, og hvilke features der nemmest kan undværes, dette vil fjerne problemet i de fleste tilfælde, dog hvis projektet er meget for stort, og der derfor skal skæres nogle vigtige features væk, så vil problemet kunne blive reduceret i stedet for at blive undgået helt hvis produktet er for stort til at det kan laves i den aftalte mængde af tid, så bliver der nødt til at blive skåret features. helbredsmæssige problemer helbredsmæssige problemer kan ikke undgås helt, dog er det muligt at reducere. For at reducere de helbredsmæssige problemer kan der først og fremmest undgå ting der går arbejdere syge, dog hvis der stadig sker helbredsmæssige problemer kan skal der enten fjernes features fra listen over features da der bliver mistet noget arbejdstid. En anden måde at reducere den tidsmangel der sker ved en helbredsmæssig situation ville være at sætte mere tid af til at arbejde på projektet, dog vil dette ikke altid være muligt. projektet er mere komplex end forventet. I tilfælde af at projektet har nogle features der er mere komplex end forventet skal der gøres en af følgende ting. Den første mulighed er at finde en mindre kompleks løsning til div. komplekse løsninger, dog er dette ikke altid en god løsning, og det er ikke altid muligt. 18

19 Den anden løsning ville være at tilføje mere arbejdstid, eller skære features væk for at danne mere tid til de komplekse dele af projektet. computerfejl. hvis der går noget galt med computeren, enten på hardware eller på software, så skal det rettes op på hurtigst muligt, disse fejl vil altid koste tid, og måske data. for at undgå at miste data skal der laves version control og programmet skal være gemt på internettet for at sikre at programmet altid kan hentes af andre computere. dette vil sørge for at hvis der sker en stor software eller hardware fejl, så kan programmet stadig hentes på en anden computer og arbejdes videre med der. hvis der sker hardware fejl skal hardwaren blive repareret hurtigst muligt, og hvis dette tager for lang tid skal der anskaffes en anden computer til at tage over mens den gamle computer er til reparation. Hvis der sker en stor softwarefejl, skal den repareres hurtigst muligt, om det så er at formatere computeren, eller bare at gendanne til at tidligere punkt. Valg af lydfiler I dette projekt skal der vælges hvilke lydfiler der skal være mulige at afspille i musik afspilleren, dette er nødvendigt at tage stilling til på grund af flere årsager. Den første årsag er at når der skal normaliseres så skal filerne åbnes og ændres, da hver eneste filtype er opbygget forskelligt så skal alle filer arbejdes med på forskellige måder, så for at få en realistisk mængde af lydfiltyper, skal der tages stilling til hvor mange forskellige lydfiler programmet skal kunne understøtte til at starte med, for at vælge imellem de mange forskellige audio filtyper. For at finde ud af hvilke audio filtyper der skulle bruges blev der stillet spørgsmålet, hvilke audio filtyper er de mest normale for musik, til dette er svaret oftest mp3 filtypen, dette er typisk det filformat der bliver brugt til det meste musik som man får fra cd er og fra internettet. På grund af dette bliver mp3 formatet valgt som en af de audio filformater der skal være understøttet af dette produkt. Dog for at lave normalisering som er et krav for dette produkt, vil der komme spørgsmålet om hvordan det skal gøres imellem flere forskellige audio filtyper, for at besvare dette spørgsmål vil der blive valgt mindst en anden filtype som skal understøttes så der skal normaliseres imellem forskellige filtyper. for at vælge den anden filtype er der blevet kigget på hvilke filtyper der er almene. For at finde ud af hvilke filtyper der er almene er der blevet søgt efter det, og ifølge dette link: så er nogle af de mest normalle filtyper følgende: Mp3, Wma, Wav, Real audio, MIDI og Ogg, ifølge beskrivelsen som også findes på hjemmesiden, så er MIDI et format der er brugt meget af instrumenter såsom synthesizers eller lydkort. WMA er microsofts filformater til at encode digital audio, dette audio format minder meget om mp3 formatet. 19

20 WAV formatet et simpelt filformat som kan afspilles af næste alle windows applikationer. Real audio er et audio format der er meget brugt af realplayer, og det er brugt til at stream lyd så det kan afspilles i realtid. ogg formatet er et audio format som oftest bliver brugt til at afspille og gemme digital music, forskellen på dette er at det er gratis og det er ikke patented. Til dette produkt er der blevet valgt WAV formatet. Dette format er blevet valgt af flere årsager, Den første årsag er at det er et simpelt format, og det vil derfor være nemmere at arbejde med end mange af de andre formater der er komprimeret på forskellige måder. En anden årsag er at det er et meget normalt format som mange forskellige programmer kan afspille. En tredje årsag er at der er meget dokumentation der er nemt tilgængelig til wav filer, og på grund af dette vil det blive nemmere at arbejde med wav formatet i stedet for andre formater. Da dette er et projekt der skal indeholde ny viden som ikke er blevet undervist i på skolen, vil der blive lavet normalisering på de udvalgte filtyper, og der vil derfor blive valgt wav formatet da det lægger et godt grundlag for lydfiler, da der ikke er komprimering af nogen art på dem. Så i sidste ende vil der blive valgt wav og mp3 fil formatern Feature list I denne del af rapporten vil der blive beskrevet de forskellige features der var planlagt, dette inkludere hvad de skal gøre, og hvorfor de skal implementeres, der vil samtidig blive givet en prioritering og en beskrivelse til hvorfor der bliver givet den udvalgte prioritet. prioriteten er et tal mellem 1 og 10 hvor 10 er de vigtigste, og 1 er de ikke vigtige features. Et skema blev lavet over feature listen samt prioritet hvor der også blev estimeret de forskellige features, dette skema kan findes i bilag 1. lydkontrol i programmet skal der være mulighed for at ændre på lydniveauet på programmet, dette er en god feature at have for at kunne finjustere lydniveauet på musikken, så den hverken er for høj eller for lav, dette kan også gøres i windows egen lydkontrol, dog vil dette skabe en let og brugervenlig tilgang til at ændre på lydniveauet. Samtidig er dette også noget som brugere forventer af alle musikafspillere, og dette gør det til en forventet features som ville være meget skuffende hvis den manglede. Denne feature har fået en prioritet på 9, da det er en meget vigtig feature, dog er der andre features som denne feature er afhængig af, så som muligheden af at kunne afspille lydfiler. 20

21 afspille lydfiler for at dette program kan blive til en musikafspiller der kan afspille både audio filer, og youtube links bliver den nødt til at have nogle af de mest basiske funktioner for at virke. Denne funktion er den grundlæggende funktion i programmet, uden denne funktion ville programmet miste en af sine mest basiske funktioner og dette må ikke ske. Denne feature vil sørge for at der kan afspilles lyd fra lydfiler. Denne feature har fået en prioritet på 10. Den har fået en prioritet på 10 da dette er en af de mest basiske og samtidig vigtigste funktioner i en musikafspiller, og uden denne feature ville programmet miste stort set alt hvad programmet skal. Samtidig er denne feature også vigtig i det at den skal bruges til at få mange andre features til at give mening. afspille youtube links en af ideerne bag ved dette program var at lave en musikafspiller der også kunne afspille youtube links, på grund af dette er denne feature meget vigtig. Planen med denne feature var at det skulle være muligt at indsætte et youtube link, hvorefter dette program så ville kunne afspille den hvis et gyldigt link blev givet, Denne funktion skulle også have mulighed for at blive integreret i andre funktioner, såsom at kunne ændre på lydniveauet og blive sat ind i en afspilningsliste. Denne feature har fået en prioritet på 9, selvom denne feature er meget vigtig for selve programmet har den ikke fået en prioritet på 10, da der er andre basiske funktioner der er vigtige at få på plads før denne funktion bliver implementeret. Dog er denne funktion stadig meget vital for programmet, da denne funktion var en af de grundlæggende ideer bag produktet, og den har derfor fået en prioritet på 9. spole i sang(seek bar) En feature som blev planlagt til dette produkt var at lave en seek bar, denne feature er en normal feature som kan ses i mange forskellige musikafspillere, og det er derfor en feature der er forventet af en musik afspiller. En seek bar sørger for at man kan spole i en sang, så hvis der er en intro man gerne vil springe over kan man springe et stykke tid ind i sange. Seek baren skal implementeres på en måde så den virker med både de normale lydfiler, men også på youtube videoer hvis det er en youtube video der bliver afspillet mens seek baren bliver ændret på. seek baren har fået en prioritet på 5, selvom en seek bar er noget man typisk finder i en musikafspiller, så er det en feature der godt kan undværes hvis det er absolut nødvendigt. Samtidig i dette projekt er der mange ting som er blevet vurderet til at være vigtigere, enten på den ene eller den anden måde, og på grund af dette har seek baren fået en prioritet på 5. 21

22 afspilningsliste En feature som ofte ses i mange musikafspillere er en afspilningsliste, en afspilningsliste indeholder alle de sange som musikafspilleren skal afspille, uden en afspilningsliste ville man skulle åbne en ny lydfil imellem hver sang, for at undgå dette vil der blive implementeret en afspilningsliste for at sørge for at brugeren kan lave afspilningslister. En afspilningsliste gør det også nemt for brugeren at skifte sang ved at udnytte afspilningslisten, og samtidig vil brugeren kunne se hvilken sang der bliver afspillet som den næste. Afspilningslisten skal i dette projekt kunne indeholde både audio filer og youtube links. Den skal have mulighed for dette på grund af den grundlæggende ide bag dette projekt. afspilningslisten har fået en prioritet på 9. Den har fået denne prioritering da denne feature er meget vigtig at have i en musikafspiller, og samtidig dækker denne feature det krav som er blevet sat op, med at der skal kunne laves en afspilningsliste af både musik filer og youtube links. Dog har denne feature ikke fået en prioritet på 10 fordi der er andre funktioner som denne feature kræver er færdige før den kan blive implementeret, der er derfor blevet valgt at denne feature har en prioritet på 9 i dette projekt. åbne lokale lydfiler (browser) En feature som er meget nødvendigt er evnen til at åbne lokale lydfiler, dette er et krav for mange andre funktioner, da det ikke er muligt at lave mange af de funktioner der er i dette produkt uden at kunne åbne en lydfil. Denne feature skal sørge for at brugeren kan åbne en browser hvorefter at brugeren skal kunne finde sine lydfiler og åbne dem, så de enten kan blive afspillet, eller blive tilføjet til afspilningslisten når den er implementeret. Denne feature har fået en prioritet på 10, da denne feature er meget vigtig for mange af de andre features i dette produkt var den nødt til at blive prioriteret højt. Uden denne funktion ville programmet miste evnen til at kunne lave en brugerdefineret afspilningsliste, eller bare evnen til at kunne afspille lokale lydfiler, og på grund af dette har den fået den høje prioritet på 10. drag'n drop filer Denne filer skulle gøre det muligt at tilføje filer på afspilningslisten ved at markere dem i den mappe de ligger i, og trække dem ind på afspilningslisten, denne feature er ikke vigtig og er mest af alt planlagt af ren luksus. Denne feature har fået en prioritet på 4, den har fået denne prioritet da denne feature ikke er særlig vigtig, og at den mest af alt er der for at give brugeren en feature som han gerne vil have, dog er denne feature ikke vital på nogen måde, på grund af dette har den fået en lav prioritet. 22

23 skifte sang En feature som er meget vigtig er muligheden for at skifte sang i afspilningslisten, dette skal kunne gøres ved at klikke på en sang i afspilningslisten. Denne feature er en basisk feature som findes i musikafspillere som benytter afspilningslister. Denne feature har fået en prioritet på 9, den har fået denne prioritet da det er en meget basisk funktion i en musikafspiller, og det er noget brugeren altid forventer der findes i afspilleren. Fordi denne funktion er så vigtig for brugeren, og samtidig en basisk feature fra musikafspillere, har den fået en prioritet på 9. pause/play knap Produktet skal også have en feature der gør det muligt at pause sange, og hvis de allerede er pauset så skal der være mulighed for at fortsætte sangene, dette er en funktion som ses i alle musikafspillere, og den er vigtig at have, så brugeren ikke skal lukke programmet ned for at få musikken til at stoppe i et øjeblik. Denne funktion skal også virke med youtube videoer, da det også skal være muligt at pause dem og få dem til at fortsætte ved at klikke på den samme knap som de normale lydfiler. Denne feature har fået en prioritet på 9, den har fået denne prioritet da denne feature er meget vigtig for programmet, da der skal være mulighed for at pause sange, dog har denne feature ikke fået en 10 i prioritet da der skal være mulighed for at afspille en sang før den kan blive paused, på grund af dette har den fået prioriteten 9 og ikke 10. næste/forrige knap produktet skal have mulighed for at gå videre til den næste sang, eller gå tilbage til den forrige sang, dette er endnu en feature som findes i alle musikafspillere, og det er en feature som brugere vil forvente at der er i produktet. Denne feature skal også integrere youtube videoer, da det skal være muligt at gå videre til den næste sang, selv hvis den nuværende eller næste sang er en youtube video. Denne feature har fået en prioritering på 9, den har fået denne prioritet da denne feature er meget vigtig, og er noget der findes i samtlige musikafspillere, på grund af dette vil brugeren altid forvente at denne feature findes i programmet, samtidig er det også vigtigt at kunne skifte til den næste og forrige sang. random afspilning. produktet skal have mulighed for at skifte imellem tilfældig afspilning og normal afspilning, dette skal enten gøres ved at blande afspilningslisten hvis brugeren vil have tilfældig afspilning eller også skal den afspille tilfældige sange fra listen, uanset hvilken metode der bliver valgt er konceptet det samme, at de næste sange bliver blandet. Denne feature har fået en prioritet på 3, da denne feature ikke på nogen måde er vital for produktet, denne feature er bare en luksus feature som brugeren gerne vil have, men som er langt fra nødvendig. 23

24 repeat Programmet skal have en feature der gør at brugeren kan vælge om afspilningslisten skal gentages, eller om den kun skal afspille en gang, denne feature skal tage stilling til tilfældig afspilning hvis der bliver valgt at den ikke skal blande afspilningslisten, men bare afspille tilfældige sange. Denne feature har fået en prioritet på 3, da denne feature ikke på nogen måde er vital for produktet, denne feature er bare en luksus feature som brugeren gerne vil have, men som er langt fra nødvendig. reklame skip for youtube videoer Programmet skal have implementeret en løsning for de store reklamer på youtube, da nogle reklamer starter før videoen, afspiller lyd, og kan tage flere minutter skal der findes en løsning på at få disse reklamer skilt af vejen, da disse reklamer ville være træls for brugeren, da det ville skabe en unødvendig pause i afspilningen. Denne feature har fået en prioritet på 6, den har fået denne prioritet da denne feature ville være rar at have, og den ville gøre at brugeren ikke ville blive tvunget til at sidde ved computeren og konstant holde øje med om reklamen kan skippes, eller det ville skabe en stor pause hvor der er reklame i stedet for musik. på grund af dette har den fået en relativ høj prioritet, dog er der på grund af krav fra opgavens side er der blevet sat nogle andre features end højere end denne, og derfor har denne feature kun fået en prioritet på 6. Normalisering Denne feature er er et krav til dette produkt, denne er inddraget i dette produkt for at få en ny viden, og bruge det i et produkt, normaliseringen skal gøre at de forskellige lydfiler i en afspilningsliste ikke har forskellige volume. Normaliseringen vil ændre på filerne for at få dem til at altid have den samme volumen højde. Denne feature har fået en prioritet på 8, den har fået denne prioritet på grund af et krav fra opgavens side, da denne feature ikke i sig selv er den vigtigste feature. Hvis denne feature ikke var et krav ville den have en prioritering på 6 eller under, dog på grund af krav fra opgavens side har den fået en prioritet på 8. sort playlist Programmet skal have en feature der gør det muligt at sortere afspilningslisten efter nogle bestemte krav, såsom alfabetisk eller efter længden af lydfilerne. Denne feature har fået en prioritet på 3, den har fået denne prioritet da denne feature ikke er særlig vigtig for produktets ydeevne. Denne feature er en feature der er rar at have for brugeren, dog langt fra nødvendig, denne feature har derfor fået sin prioritet på 3. 24

25 rearrange playlist Programmet skal have mulighed for at re arrangere de forskellige sange i afspilningslisten, så de kan blive sorteret efter brugerens behov, dette skal tillade at brugeren selv kan flytte rundt på diverse elementer i afspilningslisten. Denne feature har fået en prioritet på 4, da denne feature mest af alt kun er en luksus feature der er rar at have for brugeren, og ikke en nødvendig feature. På grund af dette har denne feature ikke fået en høj prioritet. asynkron design. Programmet skal have asynkrone funktioner da programmet skal have nogle features som skal gøres samtidig med at musik bliver afspillet, på grund af dette skal visse features af programmet laves på en asynkron måde, dette design skal tages stilling til, og der skal samtidig tages stilling til visse metoder der kræver den asynkrone fremgangsmåde, denne feature er lavet på grund af messaging systemet, så der ikke kommer forstyrrelser når der skal modtages en besked. Denne feature har fået en prioritet på 7, da denne metode er påkrævet af visse metoder for ikke at få pauser i musikken når programmet skal lave nogle andre funktioner. send message/message system Programmerne skal have en måde at kommunikere mellem hinanden, dette skal gøres via et messaging system. Denne feature er påkrævet af nogle af de andre features. Denne feature har fået en prioritet på 7, den har fået denne prioritet fordi den er påkrævet af nogle af de andre features, og har derfor fået en højere prioritet end de features som skal kræver denne feature. input link Mobil applikationen skal have mulighed for at sende et youtube link til computer programmet, hvorefter den youtube video skal tilføjes til afspilningslisten på computeren, dette ville sørge for at der kan tilføjes youtube videoer til afspilningslisten uden at det er nødvendigt at sidde ved computeren. Denne feature har fået en prioritet på 6. Denne feature kræver at musikafspilleren allerede kan fungere som musikafspiller for at denne feature kan virke, samtidig er der også andre features som er påkrævet for at få denne feature til at virke som den skal uden at skabe et problem for det flow der er i en musikafspilning, på grund af dette har den fået en prioritet på 6, der var overvejelser om denne feature skulle have en prioritet på 7 da den dækker nogle af de fag som der er blevet undervist i under uddannelsen, dog kræver denne feature en del forarbejde, og der er derfor blevet valgt at forarbejdet skal ligge på en prioritet på 7, hvor denne feature så får en på 6. 25

26 input song name Programmet skal have mulighed for at kunne modtage en besked fra mobil applikationen, hvori der bliver sendt et navn på en sang, denne sang skal så sættes i kø som den næste sang på afspilningslisten. Dette ville give brugere mulighed for at vælge den næste sang selv når de ikke sidder ved computeren. Denne feature har fået en prioritet på 6. Denne feature kræver at musikafspilleren allerede kan fungere som musikafspiller for at denne feature kan virke, samtidig er der også andre features som er påkrævet for at få denne feature til at virke som den skal uden at skabe et problem for det flow der er i en musikafspilning, på grund af dette har den fået en prioritet på 6, der var overvejelser om denne feature skulle have en prioritet på 7 da den dækker nogle af de fag som der er blevet undervist i under uddannelsen, dog kræver denne features en del forarbejde, og der er derfor blevet valgt at forarbejdet skal ligge på en prioritet på 7, hvor denne feature så får en på 6. send sound file Programmet skal have mulighed for at kunne modtage lydfiler fra den app der er planlagt i sammenhæng med dette projekt, Samtidig skal appen også kunne sende lydfiler til musikafspilleren på computere. Denne feature skal gøre det muligt for brugere at tilføje deres egne sange fra mobilen selv hvis de ikke ligger på computeren. Denne feature har fået en prioritet på 2, da denne feature ikke er vigtig, og der er mange features der er meget vigtigere end denne har denne feature ikke kunne få en høj priorit Arkitektur af programmet SOA I dette projekt er der planlagt at bruge SOA til at lave kommunikationen mellem mobil applikationen og computer applikationen. SOA konceptet skal blive brugt til at lave en event baseret kommunikation mellem de to applikationer, dette skal sørge for at computer applikationen ikke fejler ved at der mangler en mobil applikation at kommunikere med, på grund af dette kan de to applikationer fungere seperat fra hinanden på grund af den lave afhængighed af hinanden, dog ville mobil applikationen ikke have meget funktionalitet tilbage når den ikke kan kommunikere. SOA er samtidig et værktøj som der er blevet undervist i under uddannelse, i faget messaging systems. I dette tilfælde skulle det bruges til at sørge for at messaging systemet i mobil app'en fulgte denne event baseret fremgangsmåde, dog kom dette ikke til at ske da denne applikation ikke blev lavet på grund af mangel af tid. Strukturen i projektet I dette projekt er der en struktur af hele projektet som en helhed, til dette er der 26

27 blevet lavet et lille diagram for at vise denne struktur. Denne struktur viser at en mobilapplikation der har en streg til både en computer applikation, og internet, internettet skal bruges til at finde youtube videoer, den skal bruge kommunikationen til computeren til at sende beskeder til den. Computeren har kommunikation til både mobil applikationen i tilfælde af at der skal sendes noget tilbage, og den har samtidig forbindelse til internettet, den skal bruge internettet til at afspille youtube videoer. Communication between app and computer app For at finde ud af hvilken type channel der skal bruges til dette projekt, er der i dette afsnit blevet skrevet nogle forskellige type af message channels som måske kunne bruges til at lave det messaging system som programmet skal bruge. Der vil samtidig blive beskrevet hvorfor hvilke typer channels passer bedre end andre, og der vil blive taget stilling til hvilken form for message system der skal bruges. point-to-point hvis Point-to-Point skal virke så skal der være en ny channel for hver bruger, denne skal kunne oprettes, dette vil skabe en større mængde channels som der skal holdes øje med af musikafspilleren, dog vil alle android applikationerne kun skulle bruge en channel hver, da de hver især får tildelt deres egen channel til at sende information til musikafspilleren. publish-subscribe channel Dette er det modsatte af hvad dette program skal bruge. Et publish-subscribe pattern er at der kan være flere modtagere for hver publisher, dog i dette tilfælde skal der bruges flere publishers for hver modtager. Så i dette projekt skal der ikke bruges et publish-subscribe pattern. datatype channel En Datatype channel består i at sende flere forskellige datatyper på en gang, og i tilfældet af dette projekt ville det være en mulighed hvis der skal være mulighed for at kunne sende musik, eller bare links via en channel til musikafspilleren, dette system ville kunne løse det problem, dog er der stadig det samme problem som der blev skabt i Point-to-Point ved at der skal oprette channels for hvert ekstra device der skal tilsuttes til dette program guaranteed delivery Guaranteed delivery pattern sørger for at beskeden bliver leveret før den bliver slettet, dette kan i sidste ende skabe problemer hvis der er problemer med forbindelsen og der derfor ikke bliver forbundet til den valgte channel, dette vil tage plads på mobilenheden, dette vil ikke skabe bruge plads på mobilenheden som har begrænset mængde af plads. Samtidig er der ingen kritisk data der bliver sendt i dette program så der er intet grundlag for at bruge dette pattern for at sikre at beskederne kommer igennem. 27