19-12-2010
Eindverslag
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
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
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?
10-11-2010
05-11-2010
04-11-2010
29-10-2010
vergadering 29/10/2010
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
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
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
21-10-2010
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
16-10-2010
15-10-2010
Antwoord op de gestelde vragen
14-10-2010
Vergadering 08/10/2010
13-10-2010
Vragenlijst
Specificaties:
Er wordt bijgehouden:
Muziek aanvraag doen