Versions Compared

Old Version 45

changes.mady.by.user Teun vanHoof

Saved on

compared with

New Version Current

changes.mady.by.user Mees vanHaeren

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: sequence diagrammen niet in srs

Indelingsprogramma UVS - OOSE 


Jurre de Klijn - 2108958

Robin van Dommelen - 2110605

Mees van Haeren - 2108419

Job Zalmé - 2113130

Teun van Hoof - 2107420

Alex van der Wel - 2106535

 

Domeinbegeleider: Herman Telman

Skills Docent: Eveline Bouwman

Opdrachtgever: UVS Nijmegen


Table of Contents

Inleiding

...

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

...

Schaakvereniging UVS heeft de projectgroep opgedragen een nieuwe applicatie te ontwikkelen waarmee deze interne competities, meerkampen en toernooien kan managen, dat conceptueel lijkt op een ouder programma genaamd "Rokade". 

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 bevatHet UVS wil een nieuw programma omdat het oude programma dat ze voor dit doeleinde gebruiken 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:

...

Doelstelling, opdracht en op te leveren resultaten voor het bedrijf

Probleemstelling

Schaakvereniging Het programma dat het 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 vindenmomenteel gebruikt heet Rokade; het heeft een heleboel features die niet door het UVS gebruikt worden, is erg gebruikersonvriendelijk, 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 beter in elkaar zit, en geschreven is met een modernere taal. Hierdoor zou het makkelijker aangepast kunnen worden door een eventuele hobby-programmeur op het UVS, en meer futureproof zijn voor toekomstige systemen.

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. Dit nieuwe programma moet gebruiksvriendelijk zijn, en alleen de features van Rokade bevatten die het UVS nodig heeft. Ook moet het 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:

  • Het maken van competities
  • Het invoeren van resultaten voor rondes
  • Het printen van rondeschema's
  • Het publiceren van de competitieinformatie naar de website
  • Het bijhouden van een ranglijst
  • Het toevoegen van leden en gasten

Zie bijlage 1 voor de uitleg van de functionaliteiten.

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 waarmee de usecase uitgevoert worden 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.

Projectgrenzen

...

  • , en hoe de ontwikkelomgeving kan worden opgezet.
  • Een Gebruikershandleiding waarin staat beschreven hoe je welke acties in de applicatie kunt uitvoeren.
  • Een Database waarmee de java-code verbinding maakt.

Projectgrenzen

  • Het project duurt tot 7 juni 2024.
  • 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 11 en MacOS 13.

Randvoorwaarden

Projectgroep

  • Werktijden zijn gedefinieerd van 9:00 tot 17:00.
  • Binnen het project wordt scrum gehanteerd en wordt gewerkt in sprints.

Opdrachtgever

  • Na het project is het team niet verantwoordelijk voor gebruikerstraining of systeemonderhoud; de oplevering omvat een installatiegids.
  • Het hele database systeem moet gebackupt kunnen worden als een file via een cloud service als dropbox, zodat er geen kosten zijn om het database systeem te hosten.

Randvoorwaarden

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

Opdrachtgever

  • De Er is broncode van het originele programma Rokade is voordat de eerste sprint begint beschikbaar.
  • Er is een testdatabase beschikbaar waarmee de nieuwe applicatie ontwikkeld en getest kan wordenvoorbeelddatabase beschikbaar die kan worden gebruikt bij de oude Rokade applicatie om te zien hoe functionaliteiten werken.
  • De opdrachtgever is beschikbaar tijdens de geplande afspraken.

...

OOSE-Project Coördinator

  • 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.

Technische randvoorwaarden

  • Er wordt gebruikgemaakt van Jira om de werktijden van projectleden te registreren.
  • Er wordt gebruikgemaakt van Bitbucket om het project op te slaan.
  • Documentatie wordt geschreven en beoordeeld in Confluence.

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
alle hoofdstukken bevatten van het document "Toelichting op PvA 4.0".
De opdrachtgever gaat akkoord met het Plan van Aanpak
  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 in een van de eerste drie weken met de domeinbegeleider en de professional skills begeleider 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.
  3. Bevat system sequence diagrammen voor de balangrijkste usecases.
  4. Bevat functionele eisen volgens FURPS.
  5. Bevat schermontwerpen voor de applicatie

Het SRS moet gebaseerd zijn op het template bestand "SRS" van de HAN.

  1. Userstories bedenken
  2. Usecases bedenken
.
  2. Usecases
fully dressed
  1. uitwerken
  • Non-functional requirements maken
    2. Domeinmodel maken
    3. System sequence diagrammen maken mits usecase groot of onduidelijk is.
    4. Functionele en non-functionele eisen opstellen volgens FURPS+
    5. Frontend ontwerpen maken

    Nadat een onderdeel gemaakt is wordt het door een andere persoon dan de maker gereviewd.

    De kwaliteitsmanager doet steekproeven om te zien of alle reviews juist zijn gedaan.

    Software Design Document

    Het 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. Het SDD 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. Het SDD bevat een package-diagram.
    3. Het SDD bevat sequence diagrammen voor grote of onduidelijke usecases.
    4. Het SDD bevat een klasse diagram met uitleg over de gemaakte keuzes.
    5. Het SDD bevat een PDM met uitleg over de gemaakte keuzes.

    Het SDD moet gebaseerd zijn op het template bestand "SDD" van de HAN.

    1. Een PDM moet gemaakt worden voor het database.
    2. Sequence diagrammen uitwerken als dit nodig is.
    3. Sequence diagrammen toelichten
    4. Klasse diagram maken
    5. Er moet een deployment diagram gemaakt worden
    6. Er moet een package-diagram gemaakt worden

    Nadat een onderdeel gemaakt is wordt het door een andere persoon dan de maker gereviewd.

    De kwaliteitsmanager doet steekproeven om te zien of alle reviews juist zijn gedaan.

    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
    .
  • code schrijven
    • code reviewen
    1. .
    2. De frontend classes en backend classes mogen niet direct functies van elkaar aanroepen.
    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
    . 
    . Bij oplevering wordt de gehele codebase naar de opdrachtgever gestuurd.
    Database
    1. De database moet minimaal in de derde normaalvorm zijn
    2. De database moet gemaakt worden op basis van het PDM
    3. De database moet gebackupt kunnen worden via een cloud service als dropbox, en moet niet gehost worden als een externe database.
    4. Tabelnamen en attributen zijn met camelCase geschreven.
    5. Tabelnamen beginnen met hoofdletters
    6. Enkel de Engelse taal word gebruikt in de database
    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

    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.
  • De installatiegids bevat een package-diagram.

    • moet beschrijven hoe de applicatie geïnstalleerd kan worden en hoe de ontwikkelomgeving moet worden opgezet. Dit moet op een manier zodat iemand zonder verstand van ict het ook kan.

    1. Beschrijven installatie van applicatie
    2. Beschrijven opzet ontwikkelomgeving
    		De installatiegids moet getest en gereviewed worden door iemand anders dan die hem geschreven heeft.
    Gebruikershandleiding

    Beschrijft hoe je de functies in de applicatie kunt uitvoeren.

    1. Beschrijven hoe je de functies in de applicatie kunt uitvoeren.
    		 

    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.

    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 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.com
    Contactpersoon
    Ex-intern wedstrijdleider


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

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

    ...

    De projectgroep voor dit project bestaat uit:

    Naam
    Emailadres
    E-mailadresTelefoonnummerRol
    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
    -Master
    Mees van Haerenm.vanhaeren@student.han.nl06-83179086Product
    owner
    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.

    Planning

    TOEVOEGEN WEKELIJKSE PROFSK-BEGELEIDER MEETING

    TOEVOEGEN WEKELIJKSE PROJECT-BEGELEIDER MEETING

    TOEVOEGEN WEKELIJKSE SPRINT REVIEW

    TOEVOEGEN WEKELIJKSE SPRINT RETROSPECTIVE

    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


    Week StartdatumEinddatumSprintWeek StartdatumEinddatumTaken
    03 April5 April


    3 April: 14:30 Aftrap

    4 April: 11:00 Gesprek opdrachtgever

    5 April: 14:00 Gesprek Professional skills begeleiderWekelijks PS-begeleider gesprek

    18 April12 April

    Wo: Start sprint 1

    8 April: 10:45 Nutshell talk Toolstack

    8 April: 14:00 Gesprek ProjectbegeleiderDomeinbegeleider

    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: 9:00 - 12:00 Tijd voor projectverslag

    12 April: 14:00 Wekelijks PS-begeleider gesprek

    12 April: 22:00 PvA op ISAS

    215 April19 April


    15 April: 10:00 Wekelijks domeinbegeleider gesprek

    16 April: 11:00 Nutshell talk VueJS

    19 April: 9:00 - 12:00 Tijd voor projectverslag

    19 April: 14:00 Wekelijks PS-begeleider gesprek

    322 April26 April

    Wo: Einde sprint 1
    Wo: Start sprint 2

    22 April: 9:45 Nutshell talk Sprint Review

    22 April: 10:00 Wekelijks domeinbegeleider gesprek

    23 April: 13:40 Nutshell talk Sprint ReviewSpring framework

    23 April: 18:30 Sprint review bij UVS

    26 April: 9:00 - 12:00 Tijd voor projectverslag

    26 April: 14:00 Wekelijks PS-begeleider gesprek

    46 Mei10 Mei

    Wo: Einde sprint 2
    Wo: Start sprint 3

    6 Mei: 10:00 Wekelijks domeinbegeleider gesprek

    9 Mei: Hemelvaartsdag (Vrij)

    10 Mei: 9:00 - 12:00 Tijd voor projectverslag

    10 Mei: 14:00 Wekelijks PS-begeleider gesprek

    513 Mei17 Mei

    Wo: Einde sprint 3
    Wo: Start sprint 4

    13 Mei: 10:00 Wekelijks domeinbegeleider gesprek

    17 Mei: 9:00 - 12:00 Tijd voor projectverslag

    17 Mei: 14:00 Wekelijks PS-begeleider gesprek

    620 Mei24 Mei

    Wo: Einde sprint 4
    Wo: Start sprint 5

    20 Mei: 2e Pinksterdag (Vrij)

    24 Mei: 9:00 - 12:00 Tijd voor projectverslag

    24 Mei: 14:00 Wekelijks PS-begeleider gesprek

    727 Mei31 Mei

    Wo: Einde sprint 5
    Wo: Start sprint 6

    27 Mei: 10:00 Wekelijks domeinbegeleider gesprek

    31 Mei: 9:00 - 12:00 Tijd voor projectverslag

    31 Mei: 14:00 Wekelijks PS-begeleider gesprek

    83 Juni7 Juni

    Wo: Einde sprint 6

    3 Juni: 10:00 Wekelijks domeinbegeleider gesprek

    7 Juni: 9:00 - 12:00 Tijd voor projectverslag

    7 Juni: 14:00 Wekelijks PS-begeleider gesprek

    7 Juni: 17:00 Inleveren project

    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: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 er
    uit
    precies voor een inlevermoment uit te liggen vanwege een storing of soortgelijke issueKlein
    MiddelWerken via wordHiervoor is geen uitwijkstrategieBitbucket services
    komen eruit te liggen KleinErg
    grootZoveel mogelijk lokaal
    werkenHiervoor is geen
    uitwijkstrategieJIRA services komen
    eruit te liggen Klein Erg
    grootAltijd een opdracht
    hebben die je kan
    doenHiervoor is geen
    uitwijkstrategie

    Procesmatige risico's 

    ...

    GrootDezelfde werkzaamheden gaan uitvoeren in word.Regelmatige kopieën van het gemaakte werk hebben op bijvoorbeeld OneDrive of lokaal. 


    Bijlage 1

    functionaliteit-indelingsprogramma-uvs.pdf

    ...