...
JDI Smart Web applications is een bedrijf dat zich bezighoudt met het bouwen van slimme webapplicaties. JDI kan de wensen van haar klanten efficiënt vertalen naar een handige webapplicatie. Het bedrijf is opgericht door Jarno Eggink en is gevestigd in wordt gerund vanuit Velp. Bijzonder aan JDI is dat er binnen het bedrijf geen sprake is van een hiërarchie. JDI is een zogenaamde holocracy; een zelfsturende organisatie met zelfsturende teams. Voor deze opdracht gaat het Perlman ontwikkelteam tijdens het OOSE project aan de slag om voor JDI een hr portaal te realiseren. Dit portaal zal een plek zijn voor het werknemersbeheer, en hier kunnen dingen geregeld worden zoals het aanvragen van verlof en het bijhouden van eventuele reiskosten.
...
Voor het OOSE project gaat team Perlman aan de slag voor JDI Smart Web applications. Hierbij zullen zal een aantal componenten geïmplementeerd worden die te maken hebben met het werknemersbeheer van JDI. Het contact met JDI zal tussen het ontwikkelteam en Jarno Eggink, de oprichter van JDI Smart Web applications, zijn. Verder wordt dit project begeleidt door Jaap Papavoine. De reden voor dit project is dat JDI een hr portaal nodig heeft waarin dingen als werknemersbeheer, werkplekken, reiskosten en verlof kunnen worden gemanaged.
...
De opdrachtgever geeft aan dat er een HR-portaal moet komen, waarbij werknemer-data wordt bijgehouden. Dit portaal houdt persoonlijke gegevens van werknemers bij.
Dit HR-portaal moet het volgende bijhouden:
...
- Plan van aanpak
- Software requirement specification (SRS)
- Software Design Documentation (SDD)
- Broncode (Java Spring Boot en Vue.js) inclusief unit tests ← hier nodig om aan te geven waaruit de broncode bestaat???
- Testrapportage
- Projectbeheerartefacten (Hoofdstuk 6)
- Individueel verslag per groepslid (Dit onderdeel leveren we alleen aan school)
...
- Hoe lang duurt het project, dus wanneer houdt het op?
- Wat hoort inhoudelijk nét niet meer tot de opdracht? Bijvoorbeeld: ontwikkelen voor Windows, maar niet voor Linux; of wel een concept uitdenken, maar niet realiseren.
Verplaatsen naar ander hoofdstuk; Op basis van de tekst lijkt de me een onderdeel voor H3 of toch dit hoofdstuk zie laatste bulletpoint ~connor
Het front-end gedeelte realiseren op basis van Vue.js
Het backend gedeelte realiseren door middel van Java springboot
Organisatorische grenzen
toelichten dat we ook aan onze skills moeten werken
aantal te besteden uren per week - verslag, ontwikkeling, standups, vergaderingen, plannen, reviewen.
Het project Het project begint op 5-4-2022 (pre-sprint)De pregame) en de eerste sprint begint gaat beginnen op woensdag 13-4-2022
Het op te leveren product wordt een Proof Of Concept (POC)
Het ontwikkelteam is niet bereikbaar buiten aangegeven werktijden (werkdagen van 9:00 tot 17:00)
Het ontwikkelteam levert zelf geen voorbeelddata aan
Verplaatsen naar ander hoofdstuk; Op basis van de tekst lijkt de me een onderdeel voor H3 of toch dit hoofdstuk zie laatste bulletpoint ~connor
Het front-end gedeelte realiseren op basis van Vue.js
Het backend gedeelte realiseren door middel van Java springboot
Organisatorische grenzen
Start datum
projectduur
werktijden
opleverdatum
toelichting laatste twee weken
teamleden
toelichten dat we ook aan onze skills moeten werken
aantal te besteden uren per week - verslag, ontwikkeling, standups, vergaderingen, plannen, reviewen.
Projectgrenzen
Randvoorwaarden
Succesvol zijn gaat maar zelden ‘zomaar’. Bij randvoorwaarden geef je SMART aan welke zaken door anderen voor jou geregeld moeten zijn zodat je zelf vlot door kunt werken. Denk bijvoorbeeld aan:
- Schoolritme dicteert (denk hierbij bijvoorbeeld aan inleverdeadlines) externe opdrachtgevers
- Schoolopdracht gaat voor (externe opdrachtgevers)
- Beschikbaarheid begeleider bedrijf. Is hij bijvoorbeeld op de juiste momenten beschikbaar voor het geven van feedback en het tijdig nemen van beslissingen?
- Welke resources (b.v. soft- of hardware) moeten er zijn om te kunnen werken? Denk aan toegang tot systemen, ontwikkelsoftware, aanschaffen van benodigde licenties.
- - ….
Gebruik bij het SMART maken de relevante aspecten van 5xW 1xH: Wie moet Wanneer Wat, Waar, Waarom en Hoe geregeld
hebben zodat jouw project niet in gevaar komt.
Om dit project en de bijbehorende opdracht goed af te kunnen ronden, hebben we de volgende zaken nodig van de volgende personen:
- De school:
- Moet een werkende Bitbucket, Confluence en Jira omgeving aanleveren. Deze tools moeten voor alle teamleden door de gehele duur van het project beschikbaar zijn.
- Moet een aanwezige projectbegeleider leveren, die aanwezig is bij tussentijdse vragen minimaal 1x in de week en bij sprint-retrospectives. ← de retrospectives?
- Moet zorgen dat er een Professional Skills begeleider is, die binnen 2 dagen op vragen en opmerkingen rondom skills-gerelateerde zaken reageert.
- Moet zorgen dat er iedere werkdag binnen dit project een locatie beschikbaar is voor het ontwikkelteam.
- De opdrachtgever
- Moet tijdens kantooruren beschikbaar zijn tot het verduidelijken van vragen, bijvoorbeeld via email.
- Moet aanwezig zijn bij het opleveren van de sprints, door fysiek of online te kunnen beoordelen naar de voortgang.
- Moet voor de start van de eerste sprint voorbeelddata kunnen produceren voor werknemers.
- Moet toegang verlenen tot een Slack systeem om geautomatiseerde berichten naar te kunnen sturen.
- Het eindproduct
Moet ethisch verantwoord zijn, en het portaal kan niet in strijd zijn met de Nederlandse (privacy) wet.
Op te leveren producten en kwaliteitseisen
In dit hoofdstuk behandel je alle producten die je in hoofdstuk 4 beschreven hebt en moet opleveren, zoveel mogelijk in detail. Het gaat dan zowel om producten die je aan je opdrachtgever levert, als om de producten die school van je vraagt. Daarin rafel je de resultaten die je moet opleveren uiteen in kleinere (deel)producten. Zo kan het resultaat ‘een stuk werkende code’ bestaan uit een ontwerp, code, een testrapport en overdrachtsdocumentatie, etc.
In elk geval staan de volgende zaken ook op die lijst:
- Een eindverslag
- Eindpresentatie
- Reflectieverslag (afstudeerders) of projectverslag (onderwijsprojecten)
- Bijlagen (waarnaar je in de hoofdtekst correct verwijst)
Voor ieder van de beschreven producten definieer je vervolgens meetbare (SMART) kwaliteitseisen. Je bedenkt welke activiteiten je moet doen om de producten volgens die kwaliteitseisen te maken en hoe je ervoor zorgt dat die kwaliteit ook in het proces bewaakt wordt (proceskwaliteitseisen). Dit breng je onder in een tabel. Hieronder staat een voorbeeld, dat expres niet uitputtend is ingevuld, ook zijn de kwaliteitseisen nog niet SMART geformuleerd. En… realiseer je dat het slechts een voorbeeld is!
...
Product
...
Productkwaliteitseisen
(SMAR(T))
...
Benodigde activiteiten om te komen tot het product
...
Proceskwaliteitseisen
(5XW 1xH)
...
Respons in maximaal x tijd
Maximaal x major bugs
….
...
Oplevering en
goedkeuring van
tussenproducten
door
opdrachtgever aan
het einde van
iedere sprint
...
SRS
...
ICA Controlekaart
Voldoet aan standaard x
….
Requirements uitvragen
Werkzaamheden observeren
UC diagram maken
Fully dressed use cases uitschrijven
Domeinmodel maken
….
...
Code
100% (geslaagde) unittests
Commentaar in het Engels
Voldoende aan guideline
Traceable naar specifieke requirements
…..
...
Schrijven code
Unittests schrijven
Code reviewen
….
...
Onderzoeksverslag
ICA controlekaart
…..
Wat is nodig om je onderzoeksvraag te beantwoorden, welke activiteiten moet je doen? Bijvoorbeeld:
Interviewen betrokkenen
Literatuuronderzoek
….
. De opleverdatum is .... (OW7 zie planning). In totaal gaat het team werken in drie sprints, tijdens de sprints zijn de regels van SCRUM leidend. (Opdrachtgever mag sprintplanning niet aanpassen tussendoor) De laatste twee weken zijn gereserveerd om de eindpresentatie te maken en het softwarepakket te overhandigen en toe te lichten (Gaan we dit doen?).
Het ontwikkelteam is beschikbaar op werkdagen tussen 09:00 en 17:00, met uitzondering van vrije dagen (https://www.han.nl/studeren/jaarrooster/). Het team bestaat uit vijf ontwikkelaars (studenten). De ontwikkelaars hebben iedere week 40 uur om aan het project te werken. (Hieronder een overzicht waar alle uren heen gaan! moet nog worden verbeterd, dit is puur om een beeld te schetsen.)
40 uur beschikbaar 09:00 tot 5.
5 uur per week pauze
1.5 uur DSU per week
1 uur op de woensdagen in gesprek met begeleider (Jaapie)
4 uur per week om aan het verslag te werken vanaf sprint 1.
2 uur sprint planning om de week Dus 1 uur per week zeker kwijt aan de sprintplanningen.
1.5 uur per sprint om de sprint te reviewen
1.5 uur per sprint om een retrospective te houden
1 uur per sprint om met de opdrachtgever de nieuwe sprint in te delen.
Ergens tijd om met de opdrachtgever in gesprek te gaan??
Het komt erop neer dat er per sprint 25 uur per persoon overblijft om te werken een het product. In deze tijd gaat het team de bijbehorende documenten schrijven, software schrijven, teste, reviewen en overleggen.
Mocht het blijken dat het nodig is om dagelijks te overleggen dan, is de richtlijn dat er per persoon 4 uur per dag aan de producten gewerkt wordt. En in het gunstigste geval blijft er 5 uur over.
softwaregrenzen
Het op te leveren softwarepakket wordt een Proof Of Concept (POC).
Randvoorwaarden
Succesvol zijn gaat maar zelden ‘zomaar’. Bij randvoorwaarden geef je SMART aan welke zaken door anderen voor jou geregeld moeten zijn zodat je zelf vlot door kunt werken. Denk bijvoorbeeld aan:
- Schoolritme dicteert (denk hierbij bijvoorbeeld aan inleverdeadlines) externe opdrachtgevers
- Schoolopdracht gaat voor (externe opdrachtgevers)
- Beschikbaarheid begeleider bedrijf. Is hij bijvoorbeeld op de juiste momenten beschikbaar voor het geven van feedback en het tijdig nemen van beslissingen?
- Welke resources (b.v. soft- of hardware) moeten er zijn om te kunnen werken? Denk aan toegang tot systemen, ontwikkelsoftware, aanschaffen van benodigde licenties.
- - ….
Gebruik bij het SMART maken de relevante aspecten van 5xW 1xH: Wie moet Wanneer Wat, Waar, Waarom en Hoe geregeld
hebben zodat jouw project niet in gevaar komt.
Om dit project en de bijbehorende opdracht goed af te kunnen ronden, hebben we de volgende zaken nodig van de volgende personen:
- De school:
- Moet een werkende Bitbucket, Confluence en Jira omgeving aanleveren. Deze tools moeten voor alle teamleden door de gehele duur van het project beschikbaar zijn.
- Moet een aanwezige projectbegeleider leveren, die aanwezig is bij tussentijdse vragen minimaal 1x in de week en bij sprint-retrospectives. ← de retrospectives?
- Moet zorgen dat er een Professional Skills begeleider is, die binnen 2 dagen op vragen en opmerkingen rondom skills-gerelateerde zaken reageert.
- Moet zorgen dat er iedere werkdag binnen dit project een locatie beschikbaar is voor het ontwikkelteam.
- De opdrachtgever
- Moet tijdens kantooruren beschikbaar zijn tot het verduidelijken van vragen, bijvoorbeeld via email.
- Moet aanwezig zijn bij het opleveren van de sprints, door fysiek of online te kunnen beoordelen naar de voortgang.
- Moet voor de start van de eerste sprint voorbeelddata kunnen produceren voor werknemers.
- Moet toegang verlenen tot een Slack systeem om geautomatiseerde berichten naar te kunnen sturen.
- levert uiterlijk op 14-6 voorbeeld data aan, anders kan het team niet gaan ontwikkelen
- Het eindproduct
Moet ethisch verantwoord zijn, en het portaal kan niet in strijd zijn met de Nederlandse (privacy) wet. (Is dit een randvoorwaarde die we aan iemand stellen of juist andere aan ons?)
Op te leveren producten en kwaliteitseisen
In dit hoofdstuk behandel je alle producten die je in hoofdstuk 4 beschreven hebt en moet opleveren, zoveel mogelijk in detail. Het gaat dan zowel om producten die je aan je opdrachtgever levert, als om de producten die school van je vraagt. Daarin rafel je de resultaten die je moet opleveren uiteen in kleinere (deel)producten. Zo kan het resultaat ‘een stuk werkende code’ bestaan uit een ontwerp, code, een testrapport en overdrachtsdocumentatie, etc.
In elk geval staan de volgende zaken ook op die lijst:
- Een eindverslag
- Eindpresentatie
- Reflectieverslag (afstudeerders) of projectverslag (onderwijsprojecten)
- Bijlagen (waarnaar je in de hoofdtekst correct verwijst)
Voor ieder van de beschreven producten definieer je vervolgens meetbare (SMART) kwaliteitseisen. Je bedenkt welke activiteiten je moet doen om de producten volgens die kwaliteitseisen te maken en hoe je ervoor zorgt dat die kwaliteit ook in het proces bewaakt wordt (proceskwaliteitseisen). Dit breng je onder in een tabel. Hieronder staat een voorbeeld, dat expres niet uitputtend is ingevuld, ook zijn de kwaliteitseisen nog niet SMART geformuleerd. En… realiseer je dat het slechts een voorbeeld is!
Product | Productkwaliteitseisen | Benodigde activiteiten om te komen tot het product | Proceskwaliteitseisen |
Eindproduct (bijvoorbeeld je applicatie) | Respons in maximaal x tijd | Oplevering en | |
SRS | ICA Controlekaart Voldoet aan standaard x …. | Requirements uitvragen Werkzaamheden observeren UC diagram maken Fully dressed use cases uitschrijven Domeinmodel maken …. | |
Code | 100% (geslaagde) unittests Commentaar in het Engels Voldoende aan guideline Traceable naar specifieke requirements ….. | Schrijven code Unittests schrijven Code reviewen …. | |
Onderzoeksverslag | ICA controlekaart ….. | Wat is nodig om je onderzoeksvraag te beantwoorden, welke activiteiten moet je doen? Bijvoorbeeld: Interviewen betrokkenen Literatuuronderzoek …. |
Ontwikkelmethode
Nu je weet wat je gaat opleveren (producten en kwaliteit daarvan) en wat je daarvoor moet doen (overzicht activiteiten) met welkegrenzen en randvoorwaarden, geef je aan welke methode(n) jij gaat inzetten in je project. Heb je te maken met een adviestraject dan ligt het voor de hand om eerst een onderzoek te doen en daarna met een advies te komen. Ben je bezig met het ontwerp van bijvoorbeeld een website of ga je een stuk software ontwikkelen, maak dan eerst een onderbouwde keuze tussen bijvoorbeeld waterval, incrementeel, iteratief of een combinatie van die laatste twee. Daarna kun je eventueel specifieker worden door het kiezen van een bepaalde ontwikkelmethode. Hierbij spelen in elk geval de volgende overwegingen een rol:
- In hoeverre kunnen de resultaten van het project snel en volledig worden beschreven?
- Welke methoden hanteert het bedrijf en in hoeverre kun of moet je daar bij aansluiten?
- Schrijft de school een methode voor (bij propedeuse- en semesterprojecten)?
Wees hierbij wél kritisch: tijdens het afstuderen werk je bijvoorbeeld meestal in je eentje, en niet iedere methode (bijvoorbeeld Scrum bij het ontwikkelen van software) leent zich om individueel mee aan de slag te gaan. Soms is het handig om een methode daarop aan te passen. Dat kan, als je het maar goed onderbouwt en je daarbij baseert op betrouwbare bronnen. En als de methode is voorgeschreven: onderbouw waarom jij vindt dat deze methode passend is bij het soort project dat je moet gaan uitvoeren.Onderaan dit document vind je enkele suggesties voor literatuur over ontwikkelmethoden
Ontwikkelmethode
Nu je weet wat je gaat opleveren (producten en kwaliteit daarvan) en wat je daarvoor moet doen (overzicht activiteiten) met welkegrenzen en randvoorwaarden, geef je aan welke methode(n) jij gaat inzetten in je project. Heb je te maken met een adviestraject dan ligt het voor de hand om eerst een onderzoek te doen en daarna met een advies te komen. Ben je bezig met het ontwerp van bijvoorbeeld een website of ga je een stuk software ontwikkelen, maak dan eerst een onderbouwde keuze tussen bijvoorbeeld waterval, incrementeel, iteratief of een combinatie van die laatste twee. Daarna kun je eventueel specifieker worden door het kiezen van een bepaalde ontwikkelmethode. Hierbij spelen in elk geval de volgende overwegingen een rol:
- In hoeverre kunnen de resultaten van het project snel en volledig worden beschreven?
- Welke methoden hanteert het bedrijf en in hoeverre kun of moet je daar bij aansluiten?
- Schrijft de school een methode voor (bij propedeuse- en semesterprojecten)?
Wees hierbij wél kritisch: tijdens het afstuderen werk je bijvoorbeeld meestal in je eentje, en niet iedere methode (bijvoorbeeld Scrum bij het ontwikkelen van software) leent zich om individueel mee aan de slag te gaan. Soms is het handig om een methode daarop aan te passen. Dat kan, als je het maar goed onderbouwt en je daarbij baseert op betrouwbare bronnen. En als de methode is voorgeschreven: onderbouw waarom jij vindt dat deze methode passend is bij het soort project dat je moet gaan uitvoeren.Onderaan dit document vind je enkele suggesties voor literatuur over ontwikkelmethoden.
Binnen dit project zal het ontwikkelteam op een Agile manier te werk gaan. Iedere sprint wordt een iets groter product opgeleverd, en na de laatste sprint zijn pas alle use cases geïmplementeerd. Dit betekend dat het HR Portaal wat JDI Smart Web applications voor ogen heeft incrementeel tot stand zal komen. Alhoewel er vanaf het begin van het project door het team gekeken wordt naar de globale requirements, wordt bij elke individuele sprint echt vastgelegd welke use cases er na de desbetreffende sprint af moeten zijn. Op deze manier weet de opdrachtgever waar hij aan toe is, omdat er na iedere sprint een concreet resultaat af is (het gaat hier om een subset van de uiteindelijke features). Voordat het ontwikkelteam begint met de incrementele sprints, zal in de eerste week nog een globaal overzicht van het project worden gevormd aan de hand van overlegmomenten en doormiddel van dit Plan van Aanpak.
Projectorganisatie en communicatie
...