19-12-2010

Eindverslag

Titelblad vermeldt minstens groepnummer, naam groepsleden, titel en academiejaar. Layout blijft verder vrij te kiezen, maar een professioneel resultaat is nodig. (LaTeX is op dat vlak een absolute aanrader.)

Volgende zaken vormen minimaal de inhoud van het eindverslag:
- Gevolgde werkplanning (wat, begin, einde, wie)
- Transcript van communicatie met de klant
- Requirements
- Belangrijkste (dus niet alle) use-cases
- Kosten/prijsbepaling
- Architecturaal ontwerp
- Belangrijkste (dus niet alle) interaction diagrams
- Gedetailleerd ontwerp (zoals bedacht voor implementatie)
- Gedetailleerd ontwerp (zoals uiteindelijk geïmplementeerd, desnoods een reverse engineered class diagram)
- Database diagram (met vermelding van tabellen + velden + multipliciteiten)
- Vermelding gebruikte herbruikbare componenten (zoals libraries) met klein woordje uitleg
- Vermelding gebruikte design patronen met klein woordje uitleg
- Zelfevaluatie van groepswerking/resultaat (1 gezamenlijke zelfevaluatie): positieve aspecten, negatieve aspecten, wat zou je anders doen?

Vergeet niet om de feedback die je op sommige van deze zaken gekregen hebt, te verwerken in het eindverslag. Bij alle diagrammen hoort ook wat uitleg.

Verslag wordt nagelezen, proper gedrukt, ingebonden ingediend vrijdag 24/12 tijdens het project.


Met vriendelijke groeten
P. Van Laethem
S. Weemaels

17-12-2010

vergadering 17/12/2010

Niet aanwezig: Sasja Vanderveken
Behandelde punten: verder geschreven aan de code van het programma.
Afspraken: - Joeri: eindverslag maken.
- Joeri: aanpassen van diagrammen aan programma.
- Daniel: enkele logo's maken.
- Iedereen: verder schrijven aan code.

09-12-2010

Wat er allemaal nog moet gebeuren is:

  • Als er liedjes verwijderd worden moet dit ook uit de playlist(programma) verwijderd zijn.
  • Programma's moeten worden aangemaakt in beheerder. Kathleen
  • Programma's moeten worden toegewezen aan een programmamaker Kathleen
  • Programma's moeten kunnen worden aangepast (dus muziek moet in het programma toegevoegd kunnen worden).
  • Bij het vullen van een programma moet er bij het lied aantal keer in playlist verhoogd worden.
  • Programma's moeten kunnen worden verwijderd(moet bij het lied aantal keer in playlist verlaagd worden)

28-11-2010

Bericht van docent

Interaction diagram
Levert dit diagram voor jullie toegevoegde waarde? Leren jullie daar iets uit?

Gedetailleerd ontwerp
Dit diagram zal nog veel moeten aangepast worden in de loop van de ontwikkeling.

Klassendiagram
Wat is het verschil met het gedetailleerd ontwerp?

Database diagram
Er is een relatie tussen gebruikers.naam en programmas.naam?
update database ontwerp:

04-11-2010

voorlopig database ontwerp:

29-10-2010

vergadering 29/10/2010

niet aanwezig: Sasja Vanderveken
Op deze vergadering moesten we verslag uitbrengen aan de projectleiders. Deze heeft ons nog enkele tips gegeven:
- Muziek kan alleen verwijderd worden wanneer deze in geen enkel programma zit.
- Enkel de beheerder kan programma's aanmaken, programmamakers kunnen enkele muziek toevoegen en verwijderen.
Tegen week 7 moeten deze dingen afgewerkt worden:
- architecturaal ontwerp
- interaction diagram
- gedetailleerd ontwerp
- database diagram
Tijdens deze vergadering zijn we dan ook al met het team hieraan begonnen.

acceptatiecriteria

- Bezoekers moeten liedjes kunnen opzoeken zonder zich aan te melden als programmamaker of admin.

- De bezoeker moet een liedje uit de beschikbare muziek kunnen aanvragen.

- De bezoekers mogen enkel muziek opzoeken(titel, jaar, artiest, album, duur) en aanvragen.

- Een programmamaker moet voor zijn toegewezen programma handmatig (liedje per liedje) een programma kunnen maken.

- De mogelijkheid voor de programmamaker om automatisch een playlist te laten aanmaken aan de hand van een genre, een tijdsduur, aangevraagde nummers.

- Enkel de beheerder kan muziek toevoegen.

- Enkel de beheerder kan muziek verwijderen.

- Een beheerder moet de mogelijkheid hebben programma’s te verwisselen van programmamaker.

- De beheerder moet de mogelijkheid hebben om een programma aan te passen.

- De beheerder moet een programma kunnen verwijderen.

25-10-2010

Requirements

Algemeen wordt dit een applicatie voor het beheren van muziek. De muziek zal georganiseerd zijn in een database, deze zal ook beschikbaar zijn in verschillende formaten(bv. mp3, ogg, aac, wma, . . . ).

Soorten gebruikers

Bij het opstarten van de applicatie is de gebruiker automatisch van het type bezoeker, wanneer er ingelogd wordt zal het type van de gebruiker veranderen en zullen de bijhorende rechten worden toegekend.

De gebruikers van het type bezoeker kunnen beschikbare muziek opzoeken en aanvragen doen, ze zien enkel informatie die voor hen toegankelijk is.

De gebruikers van het type programmamaker kunnen muziek toevoegen/verwijderen aan programma's die aan hun toegewezen zijn . Ze kunnen dit handmatig doen, of het kan ook automatisch gedaan worden op basis van volgende criteria genre, tijdsduur, laatste maal afgespeeld,aanvragen, etc.

De gebruikers van het type beheerder kunnen geplande programma's aanmaken, verwijderen, verwisselen en kunnen ook muziek toevoegen en verwijderen. Hij kan ook een bepaald programma toewijzen aan een programmamaker naar keuze.

Interface

De muziekbestanden uit de databank worden weergegeven in een lijst met bepaalde informatie (Er wordt rekening gehouden met het type gebruiker) met de volgende zaken: genre, tijdsduur, laatste maal afgespeeld,aanvragen, enz.

Programma’s exporteren

Een programma in de applicatie zal ook exporteerbaar zijn in .m3u,xml,. . .

Zoekfunctie

Er zal een zoekfunctie zijn die het de gebruikers gemakkelijker zal maken om hun specifiek muziek snel te kunnen vinden uit de databank. Deze zal functioneren op basis van muziekinfo,( metadata) zoals bv.: genre, artiest, album, enz.

Muziek aanvragen

Voor het aanvragen van muziek zal er steeds een ‘aanvraag’ optie beschikbaar zijn in de vorm van een knop bij het specifiek muziekbestand.

De applicatie zal beschikbaar zijn voor verschillende soorten gebruikers, waarvan de rechten voor elk type gebruiker zullen verschillen.

Muziek toevoegen/verwijderen

Deze optie is enkel beschikbaar voor gebruikers van het type beheerder. Deze hebben de mogelijkheid om muziek toe te voegen/verwijderen uit de databank. Voordat de gebruiker muziek kan verwijderen moet deze eerst verwijderd zijn uit alle programma's, zo niet dan krijgt hij een foutmelding.

Programma’s maken manueel/automatisch

Deze optie is beschikbaar voor gebruikers van het type beheerder. Indien zij manueel een programma willen maken zoeken zij zelf de muziek op via de zoekfunctie en voegen deze manueel toe aan het programma. Voor een automatische opstelling van een programma is er eerst informatie vereist, zoals bv. genre,artiest,album en eventueel de gewilde tijdsduur. Er wordt dan automatisch een programma gegenereerd.

Programma’s toewijzen

Deze optie is enkel beschikbaar voor gebruikers van het type beheerder. Zij kunnen een programma naar keuze toewijzen aan een gebruiker van het type programmamaker.

Programma’s verwijderen

Ook deze optie is enkel beschikbaar voor gebruikers van het type beheerder. Zij kunnen een programma naar keuze selecteren en verwijderen, om fouten te vermijden zal er nog eens naar een bevestiging gevraagd worden.

24-10-2010

Kosten + Prijs

Raming van de kosten voor het project:

Het programma zal ontwikkeld worden over een periode van 12 weken (3 maanden). 5 programmeurs zullen het programma ontwerpen, implementeren, testen en documenteren. Zij werken aan het gemiddelde brutoloon van een beginnende softwaredevelopper dat 2200 euro/maand bedraagt. Er was geen vraag naar benodigde hardware, hiervoor zorgt de klant zelf. Er dienen ook geen licenties betaald te worden aangezien we met freeware applicaties werken.
Met deze gegevens komen we aan een totale kost van 33.000 euro (5*3*2200).


Prijs van het project:

Er zal een winstpercentage van 30% op het product gebruikt worden, dit brengt de totale prijs naar 42.900 euro (33000*1.30).

23-10-2010

Use Cases

Use Case 1: Muziek opzoeken
Brief
De bezoeker zoekt een liedje op via een zoekterm in het programma. Het programma zoekt via de zoekterm alle mogelijke informatie op die een gelijkenis heeft met de zoekterm in de databank. De databank stuurt alle gevonden informatie terug naar het programma. Het programma toont alle gegeven informatie.

Casual:
Handle Returns
Main Success Scenario:
• Alle informatie van de opgezochte muziek wordt weergegeven op het scherm.
Alternate Scenarios:
• Als de bezoeker een deel van de zoekterm ingeeft, komen er meerdere liedjes op het scherm.
• Als de opgezochte zoekterm niet in de databank zit, wordt er een boodschap op het scherm getoond.

Fully-dressed
Use Case UC1: Muziek opzoeken
Stakeholders and Interests:
- De bezoeker wil een zo dicht mogelijke benadering van de zoekterm hebben.
- De bezoeker wil snel een antwoord krijgen op de ingevoerde zoekterm.
- De bezoeker wil een eenvoudig en duidelijk antwoord.
Preconditie: Er moet muziek in de database staan en de database moet beschikbaar zijn.
Postconditie:
Geslaagde postconditie:
De bezoeker krijgt het liedje dat hij zocht snel terug.

Main Success Scenario (or Basic Flow):
1. De bezoeker zet het programma aan.
2. Hij logt in als bezoeker.
3. Er komt een scherm met een invoerscherm en een knop zoeken.
4. De bezoeker typt een zoekterm in.
5. Het programma geeft de zoekterm door aan de databank.
6. De databank zoekt naar de zoekterm.
7. De databank stuurt alle gevonden gegevens terug naar het programma.
8. Het programma geeft het liedje terug dat gezocht werd.

Extensions (or Alternative Flows):
4a. Onbekende invoer
1. Het systeem geeft een error.
2. Het systeem vraagt opnieuw om Invoer.
6a. De zoekterm bevindt zich niet in de databank.
1. Systeem stuurt bericht dat de zoekterm onbekend is.
2. Systeem stuurt mogelijke zoektermen terug.
7a. Het programma kan de gevonden data niet uit de databank halen.
1. Het systeem probeert de data opnieuw uit de databank te halen
2. Het systeem herhaalt stap 6a.
Use case 2: Muziek aanvragen
Brief
De bezoeker heeft al een nummer opgezocht en drukt op de knop “Aanvragen”. Waardoor hij een aanvraag stuurt om een lied af te spelen op de radio.
Casual:
Handle Returns
Main Success Scenario:
• De bezoeker heeft een aanvraag gestuurd. Het aangevraagde liedje komt binnenkort in 1 van de playlists.
Alternate Scenarios:
• De bezoeker stuurt meerdere aanvragen tegelijk.
Fully-dressed
Use Case UC2: Muziek aanvragen
Stakeholders and Interests:
- De bezoeker wil een liedje aanvragen.
- De bezoeker wil een bevestiging dat zijn liedje is aangevraagd.
Preconditie: Het liedje moet beschikbaar zijn voor aanvraag.
De bezoeker moet al het lied hebben opgezocht.
Postconditie:
Geslaagde postconditie:
De bezoeker krijgt een bevestiging dat zijn lied is aangevraagd.
Main Success Scenario (or Basic Flow):
1. De bezoeker duidt een lied aan om een aanvraag te doen.
2. De bezoeker drukt op de knop aanvragen.
3. Het systeem verwerkt de aanvraag
4. Het systeem stuurt de aanvraag door naar de databank
5. De databank zet de aanvraag bij het lied.
6. Het systeem stuurt een boodschap terug naar de gebruiker.

Extensions (or Alternative Flows):
1a. De bezoeker duidt meerdere liedjes aan om aanvraag te doen
1. Het Systeem doet meerdere aanvragen tegelijk.
2. Het systeem stuurt aanvraag per aanvraag naar de databank.

User case 3: Programma Handmatig maken
Brief
De programmamaker kiest een programma in de lijst. Hij beslist om handmatig het programma te maken. Hij zoekt een lied op en voegt die toe in de programmalijst.

Casual:
Handle Returns
Main Success Scenario:
• De programmamaker heeft zijn programma gemaakt en geëxporteerd naar een muzieklijst.
Alternatie Scenario’s:
• De programmamaker heeft zijn programma niet helemaal opgesteld maar heeft zijn programmalijst opgeslagen om later verder af te werken.

Fully-dressed
Use Case UC3: Programma Handmatig maken
Stakeholders and Interests:
- De programmamaker wil dat zijn programma aan al zijn eisen voldoet.
- Hij wil dat het snel en efficiënt wordt opgesteld.
- De programmamaker wil dat zijn programma niet groter is dan de lengte die het mag hebben.
- Hij wil dat het programma opgeslagen wordt en geëxporteerd naar een programma om op eenders welke andere muziekspeler te kunnen afspelen.
Preconditie:
- De programmamaker moet ingelogd zijn.
Postconditie:
Geslaagde postconditie:
De programmamaker heeft zijn programma afgewerkt, opgeslagen en geëxporteerd naar een programmalijst.

Main Success Scenario (or Basic Flow):
1. De programmamaker zoekt een liedje op.
2. De programmamaker voegt het lied toe aan zijn programma.
3. Alle gegevens van het lied worden uit de database gehaald.
4. Alle bekende gegevens worden in de lijst gezet.
5. Stap 3 wordt herhaald tot de tijd van het programma is gehaald.
6. Een boodschap komt op het scherm om te zeggen dat de duur van het programma is behaald.
7. De programmamaker controleert het programma en past het aan waar nodig.
8. De programmamaker slaagt het programma op.
9. De programmamaker exporteert programmalijst naar een M3U bestand.

Extensions (or Alternative Flows):
1a. Het gezochte lied bestaat niet.
1. Er wordt vermeld dat het liedje niet in de databank zit.
5a. Het toegevoegde lied is te lang voor de speellijst.
1. Er wordt gevraagd of u dit lied wil verwisselen met een al in de lijst zittend lied.
2a. Het lied wordt verwisseld
2b. Het lied wordt niet in de lijst toegevoegd
Use case 4: Programma Automatisch maken
Brief
De programmamaker duidt aan op welke criteria hij de lijst wil laten maken. Het programma wordt willekeurig aangemaakt op basis van de ingevoegde criteria. De programmamaker kijkt of het programma naar zijn keuze is en past aan waar nodig. De programmamaker slaagt het programma op. De programmamaker kiest of hij het programma wil exporteren.

Casual:
Handle Returns
Main Success Scenario:
• Het programma voldoet onmiddellijk aan de criteria van de programmamaker.
Alternate Scenario:
• Het programma moet nog verder aangepast worden tot al de eisen van de programmamaker voldoen.

Fully-dressed
Use Case UC4: Programma Automatisch maken
Stakeholders and Interests:
- De programmamaker wil zo snel mogelijk een programma.
- De programmamaker wil een programma dat past bij zijn criteria.
Preconditie: De programmamaker moet ingelogd zijn.
Postconditie:
Geslaagde postconditie:
Het programma is opgeslagen.
Main Success Scenario (or Basic Flow):
1. Duid de criteria aan.
2. Het systeem kiest een nummer dat aan alle criteria voldoet.
3. Het systeem slaagt het nummer op in de programmalijst.
4. Stap 2 wordt herhaald tot de tijd gehaald is.
5. De programmamaker kijkt de programmalijst na en past aan waar nodig
6. De programmamaker slaagt de programmalijst op.
7. De programmamaker kiest om het programma te exporteren.

Extensions (or Alternative Flows):
1a. Er is geen of onvoldoende criteria ingegeven.
1. Het systeem toont een boodschap met de melding om meer criteria in te geven.
2. De programmamaker geeft criteria in.
2a. Er zijn geen nummers dat aan de criteria voldoen.
1. Er wordt een melding gegeven
2. De dichtstbijzijnde passende nummers worden gekozen



Use case 5: Programma aanmaken
Brief
De beheerder beslist om een nieuw programma aan te maken. Hij geeft de naam van het programma, de duur en de programmamaker in en slaagt het programma op.

Casual:
Handle Returns
Main Success Scenario:
• Het programma is gecreëerd.

Fully-dressed
Use Case UC6: Programma aanmaken
Stakeholders and Interests:
- De beheerder wil een programma aanmaken zonder veel tijd te verdoen.

Preconditie: Er moeten programmamakers bestaan

Postconditie:
Geslaagde postconditie:
Het programma is aangemaakt.
Main Success Scenario (or Basic Flow):
1. De beheerder geeft de naam van het programma in.
2. Hij geeft de duur van het programma in.
3. Hij kiest een programmamaker.
4. Het systeem controleert alle ingevoerde gegevens.
5. Het systeem stuurt een bevestigingsvraag.
6. De beheerder bevestigt.
7. Het systeem maakt het programma aan.

Extensions (or Alternative Flows):
1a. De programmanaam bestaat al.
1. Er komt een waarschuwing op het scherm
2. Er wordt een alternatieve naam voorgesteld die u nog kan bewerken.
2a. De beheerder geeft ongeldige invoer in.
1. Er wordt een waarschuwing gegeven.
2. Er wordt weer om invoer gevraagd.


Use case 6: Programma Toewijzen
Brief
De beheerder bekijkt de verschillende programma’s. Hij selecteert een programma. De beheerder kiest een programmamaker uit de lijst en wijst het programma toe aan die programmamaker.

Casual:
Handle Returns
Main Success Scenario:
• Het programma wordt zonder te veel moeite verplaatst naar een andere programmamaker.

Fully-dressed
Use Case UC6: Programma Toewijzen
Stakeholders and Interests:
- De beheerder wil zonder veel moeite de programma’s toewijzen aan een andere programmamaker.

Preconditie: Er moeten programma’s in de databank staan.
Er moeten programmamakers zijn.

Postconditie:
Geslaagde postconditie:
Het programma heeft een andere programmamaker gekregen.
Main Success Scenario (or Basic Flow):
1. De beheerder kiest een programma.
2. Hij selecteert programma toewijzen.
3. Hij kiest een programmamaker uit de lijst.
4. Het systeem stuurt een bevestiging.
5. De beheerder bevestigt.
6. Het systeem wijst het programma toe aan de programmamaker.


Use case 7: Programma Verwijderen
Brief
De beheerder kiest een programma uit de lijst. Hij bekijkt het programma nog eens en drukt dan op programma verwijderen. Het systeem stuurt een waarschuwingsboodschap. Het programma wordt verwijderd uit het systeem.

Casual:
Handle Returns
Main Success Scenario:
• Het programma wordt onmiddellijk verwijderd uit het systeem.

Fully-dressed
Use Case UC7: Programma Verwijderen
Stakeholders and Interests:
- Het programma moet onmiddellijk verwijderd zijn.

Preconditie: Er moeten programma’s in de lijst staan.
Postconditie:
Geslaagde postconditie:
Het programma is onmiddellijk verwijderd.
Main Success Scenario (or Basic Flow):
1. De beheerder selecteert een programma uit de lijst.
2. Hij bekijkt het programma nog eens.
3. De beheerder drukt op programma verwijderen.
4. Het systeem stuurt een waarschuwing.
5. De beheerder drukt op ok.
6. Het programma wordt verwijderd.

Extensions (or Alternative Flows):
5a. De beheerder drukt op annuleren.
1. Het programma wordt niet verwijderd.
2. Het scherm van de programmalijst komt terug naar voor.












Use case 8: Muziek toevoegen
Brief
De beheerder selecteert een lied of meerdere van op zijn computer en drukt op voeg toe. Het systeem voegt de geselecteerde muziek toe aan de databank. Daarna wordt er een bericht gestuurd dat de muziek in de databank is opgeslagen.

Casual:
Handle Returns
Main Success Scenario:
• De geselecteerde muziek is toegevoegd aan de databank.

Fully-dressed
Use Case UC8: Muziek toevoegen
Stakeholders and Interests:
- De beheerder wil zoveel mogelijk in muziek in een keer in de databank kunnen zetten
- De beheerder wil probleemloos muziek in de databank krijgen
- De beheerder wil de muziek met al zijn criteria in de databank steken
Preconditie: De beheerder moet ingelogd zijn.
De databank moet verbonden zijn met het systeem.
Postconditie:
Geslaagde postconditie:
De muziek is toegevoegd aan de databank
Main Success Scenario (or Basic Flow):
1. De beheerder kiest een liedje op de computer.
2. De beheerder zet het liedje in het systeem.
3. Herhaal stap 2 en 3 tot de beheerder al zijn nummers heeft toegevoegd.
4. De beheerder drukt op “toevoegen”
5. Het systeem laadt lied per lied in de databank.
6. Het systeem stuurt een bericht dat alle muziek in de databank is ingevoegd.

Extensions (or Alternative Flows):
2a. De beheerder kiest niets en drukt onmiddellijk op toevoegen
1. Er wordt een foutboodschap gestuurd en vraagt opnieuw om muziek toe te voegen
2b. De beheerder kiest een ongeldig bestandsformaat.
1. Er wordt een foutboodschap gestuurd en vraagt opnieuw om muziek toe te voegen






Use case 9: Muziek verwijderen
Brief
De beheerder selecteert muziek in de muzieklijst. Hij drukt op verwijderen. Het systeem stuurt een waarschuwing om te melden dat er muziek verwijderd zal worden. De muziek wordt verwijderd.

Casual:
Handle Returns
Main Success Scenario:
• De muziek is onmiddellijk verwijderd uit de muzieklijst.
Fully-dressed
Use Case UC9: Muziek verwijderen
Stakeholders and Interests:
- De beheerder wil meerdere liederen tegelijk kunnen verwijderen.
Preconditie: De beheerder moet ingelogd zijn.
Er moet muziek in de databank zitten.
De muziek mag niet in een opgeslagen programmalijst zitten.
Postconditie:
Geslaagde postconditie:
De geselecteerde muziek is verwijderd uit de databank.

Main Success Scenario (or Basic Flow):
1. De beheerder selecteert de muziek in de databank.
2. Het systeem toont een bericht met alle gekozen nummers.
3. De beheerder verwijdert de muziek.
4. Het systeem stuurt een bericht dat de muziek verwijderd is.

Extensions (or Alternative Flows):
1a. de databank is leeg
1. Er wordt een foutbericht getoond.
3a. De muziek bevindt zich nog in een programma.
1.Het systeem stuurt een foutboodschap.
2. De muziek is niet verwijderd.

22-10-2010

vergadering 22/10/2010

aanwezigheden: iedereen.
Vorige vergadering hebben we enkele taken verdeeld die moesten afgewerkt worden tegen deze vergadering. Iedereen heeft deze afgewerkt en deze hebben we in groep bekeken en zijn dan ook op de blog geplaatst.
De vragen die bij het maken van deze opdrachten zijn gerezen zijn dan ook gesteld tijdens de vergadering.
Om gelijk met de planning te blijven moeten binnen 2 weken 5 diagrammen af zijn. Iedereen van de groep gaat thuis eens kijken wat deze diagrammen inhouden tegen volgende vergadering.
In de volgende vergadering zal dan een taakverdeling gedaan worden.

19-10-2010

Planning

Week 2 - Week 4

Te volbrengen opdrachten:

· Planning

· Requirements (tekstvorm) X

· Specificatie X

· Klantencontact

· Use cases

· Kosten

· Risk assessment X

· Prijs

· Acceptatiecriteria

Datum deadline:

vrijdag, 22. okt 2010

Opmerkingen

Opdrachten met kenteken 'X' moeten nog toegewezen worden aan leden van de groep.

Week 5 - Week 6

Te volbrengen opdrachten:

· Architecturaal ontwerp

· Interaction diagram

· Gedetailleerd ontwerp

· Database diagram


· Herbruikbare componenten

Datum deadline:

vrijdag, 5. nov 2010

Opmerkingen

Geen opmerkingen

Week 7 - Week 12

Te volbrengen opdrachten:

· Implementatieplanning (alpha, beta)

· Design patterns

· Codestandaard

· Testing

· Documentatie

Datum deadline:

vrijdag, 17. dec 2010

Opmerkingen

Er zal veel belang gehecht worden aan het testen van het programma. Tijdens de voorstelling en bij afgifte van het programma zullen geen bugs meer aanwezig zijn.

Week 13

Te volbrengen opdrachten:

· Verkoopspresentatie

· Deployment

· Opleiding


· Verdediging

Datum deadline:

vrijdag, 24. dec 2010

Opmerkingen

De powerpoint moet ten minste 3 dagen voor de eigenlijke presentatie voor ieder lid beschikbaar gemaakt worden om voldoende tijd te voorzien voor het instuderen.

18-10-2010

vergadering 15/10/2010

Aanwezigheden: iedereen.
Inhoud: De klant had zijn antwoorden op onze gestelde vragen doorgestuurd dus hebben we deze met de groep bekeken. Met deze informatie in ons achterhoofd zijn we begonnen aan de use cases, zowel tekstueel als het diagram.
Om zeker op schema te blijven hebben we enkele taken verdeelt.
Zo zal Katleen voor het afgewerkte use case diagram zorgen. Jelle gaat zich deze week bezig houden met het opstellen van een kosten en prijsberekening. Joeri moet voor een lijst van acceptatiecriteria zorgen.

15-10-2010

Antwoord op de gestelde vragen

Ik geef u bij deze graag een antwoord op de door u gestelde vragen.

-       In de gegevensbank worden er technische gegevens van de muziek bijgehouden. Wat houden deze gegevens precies in? (vb.: tijdsduur, bitrate, enz.

Duur, bitrate, manier van compressie, audio encryptie methode, muziekformaat , ... In feite alle informatie die terug te vinden is in de metadata van de nummers (id3v1, id3v2, vorbiscomments, etc)

-       Bij het automatisch opstellen van een programma, zijn er meerdere criteria waar rekening mee gehouden moet worden, zoals het jaar enz. ?

Automatische opstelling gebeurt op basis van volgende gegevens: genre, tijdsduur, laatst gespeeld op, aantal aanvragen, artiest, jaar of album. 

-       Bij het handmatig opstellen wordt er gesproken over een aantal tools, wat wordt hiermee bedoeld?

We bedoelen dat het zoeken (en terugvinden) van nummers zo vlot mogelijk moet gaan in het programma. Daarbij dachten we bvb (geïnspireerd door google) aan een zoekbox die on-the-fly (alle) info van de nummers doorzoekt naar een bepaalde zoekterm. (Merk op dat google tegenwoordig al reageert nog voor de volledige zoekterm is ingetypt.) Ook zoeken in slechts 1 gedeelte van de info van een nummer is soms nodig. (Ook daar vinden we het voorbeeld van google interessant, waarbij zoeken in gmail bvb op volgende manier kan.... to:kathleen zoekt alle mails die als "aan:" veld kathleen bevatten.... Moest het programma op een gelijkaardige manier werken, dan zou dat voor ons super zijn.)

-       De bezoekers mogen muziek opzoeken, welke informatie mag er worden doorgegeven?

Album, Artiest, Duur, Titel, Jaar 

-       De bezoekers kunnen aanvragen doen, is dit via een webapplicatie?

De aanvragen gebeuren via de applicatie die jullie schrijven. Deze zal op een aantal van onze pc's draaien. Ik hoop dat dat uw vraag beantwoordt. 

-       Wat houd een programma precies in? Is het een bestand waar alle af te spelen muziek in staat, of wordt de muziek rechtstreeks van het programma afgespeeld?

Een programma is een lijst van af te spelen muziek. Deze lijst moet te bezichtigen zijn in de applicatie, maar moet ook kunnen opgeslagen worden in een gewoon bestand ofzo, zodat we het op andere plaatsen echt kunnen afspelen. Wel moet (met het oog op het opstellen ervan) het mogelijk zijn om korte fragmentjes van nummers te beluisteren. 

-       Welke informatie van de muziek moet er zichtbaar zijn in een programma?

Titel, artiest en jaar zijn altijd direct te zien. Indien gewenst moet er meer info kunnen getoond worden van het nummer. (Album, Artiest, Duur, Titel, Jaar)

-       Beheerders kunnen geplande programma’s verwisselen, wat wordt hiermee bedoeld?

Bedoeld wordt dat programma's kunnen worden toegewezen aan andere programmamakers. Daarbij is het dan natuurlijk goed om te weten dat programma's dus kunnen worden opgesteld door sommige programmamakers en niet door andere programmamakers.
 
-       Beheerders kunnen ook muziek toevoegen en verwijderen, is dit in het programma of in de gegevensbank?

Via het programma, in de gegevensbank. 

-       Heeft de interface van het programma een bepaalde stijl nodig? 

Je mag de stijl laten inspelen op die van het logo. (http://www.nostalgie.eu/content/design/images/09/HdrLogo.png


14-10-2010

Vergadering 08/10/2010

In onze eerste vergadering hebben wij met onze groep gebrainstormd over onze nieuwe opdracht.
Als eerste hebben we overlegd over wat wij denken dat de oplossing ongeveer zal moeten zijn, en hierbij hebben wij dan ook enkele features bedacht en de zaken opgesomd die het programma zeker zal moeten kunnen uitvoeren.
Hierbij zijn enkele vragen naar boven gekomen omtrent de opdracht.
Deze hebben we dan ook samen gelegd en gaan we voorleggen aan de klant.
Bij het afsluiten van de vergadering hebben we dan ook deze blog aangemaakt zodat iedereen op de hoogte is van wat er gebeurt rond het project. Hierbij hebben wij dan ook onze gegevens uitgewisseld zodat iedereen makkelijk bereikbaar is.
einde vergadering 1 op 08/10/2010

13-10-2010

Vragenlijst


-       In de gegevensbank worden er technische gegevens van de muziek bijgehouden. Wat houden deze gegevens precies in? (vb.: tijdsduur, bitrate, enz.)
-       Bij het automatisch opstellen van een programma, zijn er meerdere criteria waar rekening mee gehouden moet worden, zoals het jaar enz. ?
-       Bij het handmatig opstellen wordt er gesproken over een aantal tools, wat wordt hiermee bedoeld?
-       De bezoekers mogen muziek opzoeken, welke informatie mag er worden doorgegeven?
-       De bezoekers kunnen aanvragen doen, is dit via een webapplicatie?
-       Wat houd een programma precies in? Is het een bestand waar alle af te spelen muziek in staat, of wordt de muziek rechtstreeks van het programma afgespeeld?
-       Welke informatie van de muziek moet er zichtbaar zijn in een programma?
-       Beheerders kunnen geplande programma’s verwisselen, wat wordt hiermee bedoeld?
-       Beheerders kunnen ook muziek toevoegen en verwijderen, is dit in het programma of in de gegevensbank?
-       Heeft de interface van het programma een bepaalde stijl nodig?

Specificaties:


Muziek is georganiseerd in een gegevensbank
Er wordt bijgehouden:
- Artiest
- Album
- Jaar
- Genre
- Technische gegevens
Duur, bitrate, manier van compressie, audio encryptie methode, muziekformaat , ... In feite alle informatie die terug te vinden is in de metadata van de nummers (id3v1, id3v2, vorbiscomments, etc)
Een programma kan automatisch opgesteld worden:
- met behulp van criteria:
Ø  Genre
Ø  Tijdsduur
Ø  Laatste maal afgespeeld
Ø  Aanvragen
Ø Artiest
Ø  Jaar
Ø  Album

Of handmatig:
                - met een aantal tools
-          Zoekfunctie
-          On-the-fly

We bedoelen dat het zoeken (en terugvinden) van nummers zo vlot mogelijk moet gaan in het programma. Daarbij dachten we bvb (geïnspireerd door google) aan een zoekbox die on-the-fly (alle) info van de nummers doorzoekt naar een bepaalde zoekterm. (Merk op dat google tegenwoordig al reageert nog voor de volledige zoekterm is ingetypt.) Ook zoeken in slechts 1 gedeelte van de info van een nummer is soms nodig. (Ook daar vinden we het voorbeeld van google interessant, waarbij zoeken in gmail bvb op volgende manier kan.... to:kathleen zoekt alle mails die als "aan:" veld kathleen bevatten.... Moest het programma op een gelijkaardige manier werken, dan zou dat voor ons super zijn.)

Gebruikers van het radiostation:
- Bezoekers:
                Muziek opzoeken
               Enkel informatie die mag worden doorgegeven: Album, Artiest, Duur, Titel, Jaar
                Muziek aanvraag doen
-  Programmamakers:
                Kunnen programma’s opstellen
-  Beheerders:
                Kunnen geplande programma’s verwisselen
               Kunnen programma’s toewijzen aan andere programmamakers
                Kunnen muziek toevoegen en verwijderen in de gegevensbank