You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 77 Next »

Indelingsprogramma UVS - OOSE 


Jurre de Klijn - 2108958

Robin van Dommelen - 2110605

Mees van Haeren

Job Zalmé - 2113130

Teun van Hoof - 2107420

Alex van der Wel - 2106535

 

Domeinbegeleider: Herman Telman

Skills Docent: Eveline Bouwman

Opdrachtgever: UVS Nijmegen


Inleiding

Dit document bevat een beschrijving over het plan van aanpak met de daarbij behorende onderdelen. Dit document wordt opgesteld aan de hand van de opdracht gegeven door de HAN, waarbij de projectgroep verantwoordelijk is voor het maken van een nieuw systeem voor schaakvereniging UVS om interne competities, meerkampen en toernooien bij te houden.

Het plan van aanpak zal detailleren hoe wij dit project zullen volbrengen. Hierbij wordt eerst ingegaan op de achtergrond van het project en hoe dit tot stand is gekomen. Daarna wordt de doelstelling van het project beschreven, en wat het verwachte resultaat is. Vervolgens zullen de projectgrenzen van het project beschreven worden, deze beschrijven de grenzen waarbinnen de opdrachtgever het project wil zetten. Ook worden hierna de randvoorwaarden die de projectgroep stelt aan de opdrachtgever nader toegelicht. De op te leveren producten en kwaliteitseisen die bij het product en proces horen staan ook in deze tabel vermeld.

De ontwikkelmethode die de projectgroep gaat gebruiken wordt hierna in detail beschreven, en er zal daarna toelichting gegeven worden over hoe de communicatie en projectorganisatie is geregeld tussen de projectgroep en belangstellenden. Tot slot wordt er een lijst van risico's opgesteld, met toelichting over hoe deze kunnen worden vermeden.

Achtergrond van het project

Beschrijving organisatie

UVS is een schaakvereniging uit Nijmegen die al 80 jaar lang schaakcompetities organiseert voor schaakliefhebbers. Leden kunnen lid worden van de vereniging om daarna echte competitiewedstrijden te spelen.

Opdracht

Schaakvereniging UVS heeft de projectgroep opgedragen een nieuwe applicatie te ontwikkelen waarmee deze interne competities, meerkampen en toernooien kan managen.

Aanleiding

De reden voor het maken van een nieuw systeem is dat het huidige systeem van Schaakvereniging UVS, Rokade, steeds lastiger is om te laten compileren en op moderne systemen te laten draaien. Ook is aangegeven dat Rokade meer functionaliteit bezit dan UVS nodig acht, en deze heeft aangegeven een lichter systeem te willen die een subset van de functionaliteit van Rokade bevat.

Stakeholders

De stakeholders van dit project zijn:

  • Schaakvereniging UVS
    • De leden van UVS
    • Het bestuur van UVS 
  • De HAN

Doelstelling, opdracht en op te leveren resultaten voor het bedrijf

Probleemstelling

Schaakvereniging UVS gebruikt op het moment de applicatie "Rokade" om competities en schema's te maken. De applicatie is geschreven in Delphi en daardoor is het steeds lastiger om een werkende compiler en operating systeem te vinden. Omdat het systeem gebruikt wordt door heel Nederland zijn er veel functies voor gemaakt die UVS niet gebruikt. 

Doelstelling

Het doel van dit project is het ontwikkelen van een nieuwe applicatie ter vervanging van het verouderde programma Rokade, gebruikt door Schaakvereniging UVS uit Nijmegen en mogelijk ook andere schaak- en damverenigingen. Daarnaast moeten frontend en backend gescheiden zijn, zodat eventuele toekomstige aanpassingen of uitbreidingen gemakkelijk kunnen worden geïmplementeerd. Belangrijk is ook dat er uitgebreide documentatie wordt gemaakt, zodat toekomstige ontwikkelaars van de vereniging het programma kunnen onderhouden en verder ontwikkelen.

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:

  • Het maken van competities
  • Het invoeren van resultaten voor rondes
  • Het printen van rondeschema's
  • Het publiceren van de competitieinformatie naar de website

Resultaten

Aan het einde van het project zal schaakvereniging UVS de volgende producten in handen hebben:

  • Een Plan van aanpak waarin alle afspraken over het project zijn beschreven en waar de ontwikkelgroep op kan terugvallen.
  • Een Software Requirement Specification waarin staat wat de software doet en geeft een beeld over het systeem aan de stakeholders.
  • Een Software Design Document waarin staat hoe het product gemaakt is en wat de technische specificaties zijn.
  • De Java-code van de te realiseren applicatie.
  • Een Testplan dat beschrijft hoe er getest wordt.
  • Een Testrapport waarin de resultaten van alle tests beschreven staan.
  • Een Installatiegids die schaakvereniging UVS kan gebruiken om de applicatie op het eigen systeem te installeren.
  • Een Database waarmee de java-code verbinding maakt.

Projectgrenzen

  • De applicatie-backend wordt ontwikkeld in Java.
  • Om de applicatie te koppelen met een database wordt de Java Persistence API (JPA) toegepast, waardoor het later mogelijk is om relatief makkelijk andere databases met de applicatie te koppelen.
  • Het uiteindelijke product moet werkzaam zijn op Windows en MacOS.
  • Na oplevering is het team niet verantwoordelijk voor gebruikerstraining of systeemonderhoud; de oplevering omvat een installatiegids,

Randvoorwaarden

Om het project succesvol te kunnen afronden zijn de volgende voorwaarden vastgesteld:

Opdrachtgever

  • Er is broncode van het originele programma Rokade beschikbaar.
  • Er is een testdatabase beschikbaar waarmee de nieuwe applicatie ontwikkeld en getest kan worden.
  • De opdrachtgever is beschikbaar tijdens de geplande afspraken.

HAN

  • Er zijn werkruimtes voor zes personen beschikbaar met toegang tot internet.
  • Er is toegang tot Jira om taken in te plannen en voortgang te noteren.
  • Er is toegang tot Bitbucket om het project te managen.
  • Er is toegang tot Confluence om documentatie te schrijven en bij te werken.
  • Er moet toegang zijn tot stroom om laptops op te kunnen laden.

Op te leveren producten en kwaliteitseisen

DeelproductProductkwaliteitseisen (//smart)Benodigde activiteitenProceskwaliteitseisen (//5xW 1xH)
Plan van aanpakHet plan van aanpak moet het doel van het project, de projectgrenzen, de randvoorwaarden, de eisen van de deelproducten en risicos bevatten.
  1. Eerste gesprek houden met de opdrachtgever om extra informatie over de opdracht te verkrijgen
  2. Goed de opdrachtinformatie doorlezen
Het plan van aanpak wordt in een assessment besproken waarna feedback volgt en aangepast wordt.
Software Requirement Specification

Het SRS moet usecases bevatten, en de code/tests moeten traceerbaar zijn naar deze usecases.

  1. De userstories zijn genummerd.
  2. De usecases zijn gekoppeld aan de relevante userstories.
  1. Userstories bedenken
  2. Usecases bedenken
  3. Usecases uitwerken
  4. System sequence diagrammen maken
  5. Functionele en non-functionele eisen opstellen volgens FURPS+
  6. Frontend ontwerpen maken
Nadat een onderdeel gemaakt is wordt het door de kwaliteitsmanager gereviewd.
Software Design DocumentHet SDD moet designkeuzes uitleggen en beargumenteren. In het SDD moet verwezen worden naar SOLID of GRASP principes, zoals aangeleerd in Object oriented analysis and design.
  1. Sequence diagrammen uitwerken
  2. Sequence diagrammen toelichten
  3. Klasse diagram maken
Nadat een onderdeel gemaakt is wordt het door de kwaliteitsmanager gereviewd.
Java-code
  1. De code wordt met Java gemaakt.
  2. Er word gebruik gemaakt van Maven.
  3. In de code wordt enkel de Engelse taal gebruikt.
  4. Namen van classes, methods en variables voldoen altijd aan camelCase.
  5. Namen van classes beginnen altijd met een hoofdletter.
  6. Namen van packages bevatten nooit hoofdletters.
  7. Voor elke method staat een comment met daarin een korte beschrijving van de method.
  8. Wanneer een class gebruik maakt van een externe library wordt er gebruik gemaakt van het adapter pattern.
  9. De naam van testclasses is de naam van de geteste class plus Test.
  1. Er moet een maven project gemaakt worden
  2. De code van usecases moet gemaakt worden
Elke pull-request word door tenminste 2 andere teamleden nagekeken of de code voldoet aan de eisen gesteld in kolom 2. 
Database
  1. De database moet minimaal in de derde normaalvorm zijn
  2. De database moet gemaakt worden op basis van het PDM
  1. De database moet ontworpen worden o.b.v de verkregen testdatabase
  2. Het PDM moet gemaakt worden
Telkens als de database veranderd moet minimaal 1 ander persoon de structuur controleren om er zeker van te zijn dat het goed gedaan is.
TestplanHet testplan bevat informatie over de tests die uitgevoerd gaan worden, en instructies over hoe deze uitgevoerd moeten worden. De tests moeten traceerbaar zijn naar de usecases in het SRS.
  1. Tests moeten bedacht worden
  2. Tests moeten beschreven worden
Elke keer als er een Java test gemaakt is wordt deze in dit document toegelicht.
TestrapportHet testrapport bevat de resultaten van de tests die uitgevoerd zijn volgens het testplan. 
  1. De resultaten van de tests moeten beschreven worden.
  2. Er moet een conclusie gemaakt worden
Nadat alles is getest wordt er een rapport gemaakt waarin beschreven staat wat er wel goed gaat en wat er niet goed gaat.
Installatiegids
  1. De installatiegids bevat een deployment-diagram.
    1. Het deployment-diagram bevat de juiste versies van gebruikte software.
    2. Communicatie tussen lagen bevat de gebruikte poorten en communicatietechnieken.
  2. De installatiegids bevat een package-diagram.


  1. Er moet een deployment diagram gemaakt worden
  2. Er moet een package-diagram gemaakt worden
  3. Er moet worden beschreven worden hoe de applicatie geïnstalleerd kan worden
De installatiegids moet getest en gereviewed worden door iemand anders dan die hem geschreven heeft.

Ontwikkelmethoden

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.

Projectorganisatie en communicatie


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

NaamEmailadresRol
Ron van Dijkintern@uvsnijmegen.nlIntern wedstrijdleider
Dennis Breuker

dennis@dennisbreuker.nl

Penningmeester
Maarten van Rooijrooijm@gmail.comContactpersoon


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

NaamEmailadresRol
Herman Telmanherman.telman@han.nlBegeleider
Meron Brouwermeron.brouwer@han.nlAssessor
Eveline Bouwmaneveline.bouwman@han.nlProfessional skills begeleider


De projectgroep voor dit project bestaat uit:

NaamEmailadresTelefoonnummerRol
Alex van der Wela.vanderwel@student.han.nl06-43027288Tester
Jurre de Klijnjjc.deklijn@student.han.nl06-23519611Planner
Job Zalméj.zalme@student.han.nl

06-55075006

Scrum-Master
Mees van Haerenm.vanhaeren@student.han.nl06-83179086Product Owner by proxy
Robin van Dommelenrb.vandommelen@student.han.nl06-30379353Kwaliteitsmanager
Teun van Hooft.vanhoof@student.han.nl06-10408355Tester

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 weken plaatsvinden en zullen gebeuren op locatie PM3 van de HAN. De Sprint Review-bijeenkomsten zullen doorgaans plaatsvinden op de woensdag om ____ uur.

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 13:00 uur.
  • Als teamleden ziek zijn wordt er indien mogelijk thuis verder aan het project gewerkt
  • Elk teamlid klokt zijn gemaakte uren via Jira
  • 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. 

Planning

TOEVOEGEN WEKELIJKSE PROJECT-BEGELEIDER MEETING

TOEVOEGEN WEKELIJKSE SPRINT REVIEW

TOEVOEGEN WEKELIJKSE SPRINT RETROSPECTIVE

Week StartdatumEinddatumTaken
03 April5 April

3 April: 14:30 Aftrap

4 April: 11:00 Gesprek opdrachtgever

5 April: 14:00 Wekelijks PS-begeleider gesprek

18 April12 April

8 April: 10:45 Nutshell talk Toolstack

8 April: 14:00 Gesprek Projectbegeleider

9 April: PvA + Eerste versie SRS op confluence

10 April: 9:00 Planningpokeren + taken op jira

10 April: 13:00 Start sprint 1

12 April: 14:00 Wekelijks PS-begeleider gesprek

12 April: 22:00 PvA op ISAS

215 April19 April

16 April: 11:00 Nutshell talk VueJS

19 April: 14:00 Wekelijks PS-begeleider gesprek

322 April26 April

22 April: 9:45 Nutshell talk Sprint Review

23 April: 13:40 Nutshell talk Spring framework

26 April: 14:00 Wekelijks PS-begeleider gesprek

46 Mei10 Mei

9 Mei: Hemelvaartsdag (Vrij)

10 Mei: 14:00 Wekelijks PS-begeleider gesprek

513 Mei17 Mei17 Mei: 14:00 Wekelijks PS-begeleider gesprek
620 Mei24 Mei

20 Mei: 2e Pinksterdag (Vrij)

24 Mei: 14:00 Wekelijks PS-begeleider gesprek

727 Mei31 Mei31 Mei: 14:00 Wekelijks PS-begeleider gesprek
83 Juni7 Juni

7 Juni: 14:00 Wekelijks PS-begeleider gesprek

7 Juni: 17:00 Inleveren project

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

RisicoKans (groot - middel - klein) Impact(groot - middel - klein) TegenmaatregelUitwijkstrategie
Confluence services komen
eruit te liggen vanwege een storing of soortgelijke issue
KleinMiddelDezelfde werkzaamheden gaan uitvoeren in word.Regelmatige kopieën van het gemaakte werk hebben op bijvoorbeeld OneDrive of lokaal. 
Bitbucket services
komen
eruit te liggen vanwege een storing of soortgelijke issue waardoor waardoor de code niet kan worden gepusht of gepulld.
KleinErg
groot
Regelmatige kopieën van het gemaakte werk hebben op bijvoorbeeld OneDrive of lokaal. Als de storing zich voor een langdurige tijd voordoet dan is zal de code moeten worden verplaatst vanaf de lokale kopie van het project naar een vervangende versiebeheertool zoals GitLab of GitHub.
JIRA services komen
eruit te liggen vanwege een storing of soortgelijke issue waardoor het team niet bij essentiële informatie over het project kan komen.
Klein Erg
groot
Back-ups hebben van de Jira gegevens zodat er altijd mee kan gewerkt worden in het geval van storingDe lokale kopie van de Jira-gegevens delen met teamleden zodat het werk door kan gaan en de communicatie met de werkgever goed houden i.v.m. mogelijke.






Procesmatige risico's 

RisicoKans (groot - middel - klein) Impact(groot - middel - klein) TegenmaatregelUitwijkstrategie
Ziekteverlof van een of meer van de teamleden. Hierdoor zal de voortgang van het project worden gehinderdKleinKleinDuidelijk aanstellen wie welke taak heeft op genomen zodat de taken kunnen worden overgenomen door andere teamleden

Bij een langdurig ziekteverlof zal de planning opnieuw moeten worden gepland en de taken van het uitgevallen teamlid zullen moeten worden overgenomen door de rest van het team.

Ook moet er contact op worden genomen met de werkgever voor mogelijke vertraging binnen het project.






  • No labels