...

Het UVS wil een nieuw programma omdat het oude programma dat ze voor dit doeleinde gebruiken gebruikers onvriendelijk gebruikersonvriendelijk en moeilijk te onderhouden is. Ze zouden het oude programma waarschijnlijk voor de nabije toekomst nog steeds kunnen gebruiken, maar willen  een alternatief hebben om het organiseren van competities eenvoudiger en efficienter te maken.

Stakeholders

De stakeholders van dit project zijn:

...

Het programma dat het UVS momenteel gebruikt heet Rokade; het heeft een heleboel features die niet door het UVS gebruikt worden, is erg gebruikers onvriendelijkgebruikersonvriendelijk, kan soms best sloom zijn om te gebruiken en is geschreven in de oude programmeertaal Delphi. Het UVS zou liever een programma willen hebben zonder deze overbodige functies, die ook beter in elkaar zit, en geschreven is met een modernere taal dan Delphi. Hierdoor zou het makkelijker aangepast kunnen worden door een eventuele hobby-programmeur op het UVS, en meer futureproof zijn voor toekomstige systemen.

...

Het doel van dit project is het ontwikkelen van een nieuwe applicatie ter vervanging van het verouderde programma Rokade.   Belangrijk is ook dat er uitgebreide documentatie wordt gemaakt, zodat toekomstige ontwikkelaars van de vereniging het programma kunnen onderhouden en verder ontwikkelenDit nieuwe programma moet gebruiksvriendelijk zijn, en alleen de features van Rokade bevatten die het UVS nodig heeft. Ook moet het programma geschreven worden in een modernere taal dan Delphi zoals Java of Python, zodat de code toegankelijker is om uit te breiden of aan te passen door eventuele toekomstige gebruikers.

//Move: Daarnaast zou het fijn zijn als de frontend en backend gescheiden zijn, zodat eventuele toekomstige aanpassingen of uitbreidingen gemakkelijk kunnen worden geïmplementeerd.

nieuwe programma simpeler te onderhouden zijn dan Rokade, onder andere door documentatie op te leveren en het in een moderne taal te schrijven.

Opdracht

Uit gesprekken met schaakvereniging UVS en een beter begrip van hun wensen, is de opdracht verfijnd. We zullen een systeem ontwikkelen dat de volgende taken automatiseert:

...

...

Gedurende de ontwikkeling van de nieuwe applicatie wordt gebruikgemaakt van scrum. Door via scrum te werken worden binnen de zogeheten sprintperiodes steeds deelproducten opgeleverd, die uiteindelijk samen het eindproduct vormen. Door via scrum te werken is bij ieder teamlid duidelijk wat er moet gebeuren en door wie, en door de voortgang bij te houden blijft het overzicht helder. Dankzij de flexibiliteit die scrum biedt is het ook makkelijk om gedurende de loop van het project aanpassingen door te voeren indien bijvoorbeeld de behoeften van de opdrachtgever veranderen.

Het nadeel aan scrum is dat aan het begin van het project de kosten van het eindproduct nog niet geheel in kaart kunnen worden gebracht. Aan dit project zijn geen kosten verbonden, dus is dit niet van toepassing.

Projectorganisatie en communicatie

Bij de Schaakvereniging UVS zijn er meerdere contactpersonen aangewezen voor de Projectgroep.

...

dennis@dennisbreuker.nl

...

Voor dit project zijn er een aantal mensen opgesteld die klaar staan voor het adviseren van de projectgroep vanuit de HAN:

...

De projectgroep voor dit project bestaat uit:

...

06-55075006

...

Daily standup

De Daily Standup is een korte en gestructureerde bijeenkomst die dagelijks in de ochtend plaatsvindt. Tijdens deze bijeenkomst komen teamleden bij elkaar om de voortgang van het werk te bespreken, eventuele obstakels te identificeren en de planning voor de komende dag af te stemmen. 

Elke deelnemer deelt kort zijn of haar antwoorden op drie vragen:

1. Wat heb ik gedaan sinds de laatste standup?
2. Wat ga ik vandaag doen?
3. Zijn er obstakels die mijn voortgang belemmeren?

De Daily Standup is bedoeld om kort en to the point te zijn, vaak niet langer dan 15 minuten, om te voorkomen dat het een langdradige vergadering wordt. Door regelmatig de voortgang en eventuele problemen te bespreken, kunnen teamleden elkaar ondersteunen, samenwerken en effectief blijven werken aan de gezamenlijke doelen van het project.

Sprint retrospective

De Sprint Retrospective is een cruciale ceremonie binnen het Scrum die plaatsvindt aan het einde van elke sprint. Het doel van deze bijeenkomst is om te reflecteren op de afgelopen sprint en te identificeren wat er goed ging, wat er verbeterd kan worden en welke acties er moeten worden ondernomen om het proces te optimaliseren.

Tijdens de Sprint Retrospective komt het ontwikkelteam samen om open en eerlijk te praten over hun ervaringen tijdens de sprint. De focus ligt op het identificeren van zowel positieve als negatieve aspecten van het werkproces, samenwerking en productkwaliteit. Door middel van gestructureerde discussies en gerichte vragen, zoals wat er goed ging, wat er beter kan en welke acties moeten worden ondernomen, worden waardevolle inzichten verkregen die kunnen leiden tot continue verbetering van het team en het product.

Tijdens dit project zal de retrospective ceremonie plaatsvinden voordat de daadwerkelijke sprint review is gedaan, zodat het team voorbereidt is op de sprint review.

Sprint review

De Sprint Review is een belangrijke gebeurtenis aan het einde van elke sprint. Het doel van de Sprint Review is om het voltooide werk van de sprint te presenteren aan de opdrachtgever om feedback te verzamelen over het geleverde product.

Tijdens de Sprint Review presenteert het ontwikkelteam de voltooide producten of functionaliteiten. Het team demonstreert de nieuwe functies en verbeteringen die zijn toegevoegd aan het product tijdens de sprint en beantwoordt vragen van de opdrachtgever.

Sprint planning

De Sprint Planning is een essentiële ceremonie aan het begin van elke sprint binnen het Scrum-framework. Het doel van de Sprint Planning is om het werk te plannen dat tijdens de sprint zal worden uitgevoerd en om een duidelijk begrip te krijgen van de doelstellingen en het te leveren productincrement. In dit project zal de sprint planning gelijk na elke sprint review plaatsvinden zodat er niet een aparte afspraak gemaakt hoeft te worden.

Projectorganisatie en communicatie

Bij de Schaakvereniging UVS zijn er meerdere contactpersonen aangewezen voor de Projectgroep.

Voor dit project zijn er een aantal mensen opgesteld die klaar staan voor het adviseren van de projectgroep vanuit de HAN:

De projectgroep voor dit project bestaat uit:

Het contact met de opdrachtgever zal voornamelijk met het volgende e-mailadres gebeuren: han-eniac@outlook.com

Groepsafspraken

Voor het project zijn een aantal groepsafspraken nodig om tot een goede einde te komen:

• Werktijden zijn gedefinieerd van 9:00 tot 17:00 uur met tussendoor een pauze van 12:00 tot 12:30 uur.
• Als teamleden ziek zijn wordt er indien mogelijk thuis verder aan het project gewerkt
• Aangezien Job structureel uren mist vanwege zijn topsport ambities zal hij wanneer nodig in eigen tijd verder werken.
• Aangezien Jurre structureel uren mist vanwege rijles zal hij in eigen tijd minimaal de helft van de gemiste uren inhalen.
• Bij eventuele hindering of afwezigheid zal er z.s.m. een bericht verstuurd worden in de groepsapp of gebeld worden naar een ander groepslid. 

Definition of Done

In dit document worden alle requirements besproken die voldaan moeten worden voordat een taak als "done" beschouwd kan worden. Als al deze requirements af worden gegaan is de kans dat het opgeleverde product van kwaliteit is een stuk groter.

• De relevante usecases zijn fully dressed uitgewerkt.
• Het domein model is correct uitgewerkt volgens de conventies van de HAN
• Wireframes zijn opgesteld met ten minste een medium fidelity.
• De gemaakte usecases zijn terug te vinden in het usecase model.
• De gemaakte code is traceerbaar naar het klasse diagram en voldoet aan de kwaliteitseisen opgesteld in het PvA.
• De database is uitgebreid met de nieuwe informatiebehoeftes en voldoet aan de kwaliteitseisen opgesteld in het PvA. 
• System sequence diagrams zijn uitgewerkt volgens de conventies van de HAN.
• De bijbehorende sequence diagrams zijn uitgewerkt volgens de conventies van de HAN. 
• Gemaakte code heeft ten minste 80% line coverage.
• Code wordt geschreven volgens de Coding conventions.
• Usecases zijn door tenminste 2 andere personen nagekeken en goedgekeurd. De task mag dus niet nagekeken en goedgekeurd worden door de persoon die de taak heeft gemaakt. 
• Documentatie is zonder spelfouten uitgetypt. 
• Documentatie is onderverdeeld in hoofdstukken en paragraven. 
• Alle documentatie is in het Nederlands geschreven.
• Documentatie wordt op Confluence gepubliceerd. 

Planning

Het contact met de opdrachtgever zal voornamelijk met het volgende e-mailadres gebeuren: han-eniac@outlook.com

Aan het einde van elke scrumsprint zullen we een Sprint Review bijeenkomst houden met de klant. Tijdens deze vergaderingen zullen we de voortgang van het project bespreken, inclusief de keuzes die we hebben gemaakt en de argumenten daarvoor, evenals wat er gepland staat voor de volgende sprint.

Deze scrumsprints zullen elke week plaatsvinden en zullen gebeuren op locatie PM3 van de HAN. 

Groepsafspraken

Voor het project zijn een aantal groepsafspraken nodig om tot een goede einde te komen:

• Werktijden zijn gedefinieerd van 9:00 tot 17:00 uur met tussendoor een pauze van 12:00 tot 12:30 uur.
• Als teamleden ziek zijn wordt er indien mogelijk thuis verder aan het project gewerkt
• Aangezien Job structureel uren mist vanwege zijn topsport ambities zal hij wanneer nodig in eigen tijd verder werken.
• Aangezien Jurre structureel uren mist vanwege rijles zal hij in eigen tijd minimaal de helft van de gemiste uren inhalen.
• Bij eventuele hindering of afwezigheid zal er z.s.m. een bericht verstuurd worden in de groepsapp of gebeld worden naar een ander groepslid. 

Definition of Done

In dit document worden alle requirements besproken die voldaan moeten worden voordat een taak als "done" beschouwd kan worden. Als al deze requirements af worden gegaan is de kans dat het opgeleverde product van kwaliteit is een stuk groter.

• Uitwerken van fully dressed usecase
• Het aanpassen van domeinmodel op basis van usecase beschrijving
• Designen wireframe
• Bijwerken usecasemodel
• Bijwerken klassediagram
• Updaten database
• Aanmaken system sequence diagram
• Aanmaken sequence diagrams
• Maken unit tests
• Testen van unit tests
• Code wordt geschreven volgens de Coding conventions.
• Reviewen usecase

Planning

Risico’s

Om de risico's goed te kunnen weergeven hebben wij gekozen om twee verschillende tabellen te maken
voor de risico's. De technische risico's en de procesmatige risico's. Deze risico tabellen zijn hieronder te
zien.

Technische risico's

...

De planning voor de sprints is te zien op het Jira bord.

Risico’s

In het project zitten risico's waardoor het project niet afgemaakt kan worden, deze staan in de volgende tabel:

Technische risico's

Bijlage 1

functionaliteit-indelingsprogramma-uvs.pdf

...