Plan van Aanpak
Inhoudsopgave
- 1. Achtergrond van het project
- 2. Doelstelling, opdracht en op te leveren resultaten voor het bedrijf
- 3. Projectgrenzen
- 4. Randvoorwaarden
- 5. Op te leveren producten en kwaliteitseisen
- 6. Ontwikkelmethoden
- 7. Projectorganisatie en communicatie
- 8. Planning
- 9. Risico's
- 10. Bronnen
Inleiding
Doel en Introductie
In dit document wordt de aanpak van het project Solution for translations and automated localization vastgelegd. Deze opdracht wordt ontwikkeld voor het bedrijf Bluenotion en de klanten van Bluenotion. Het doel van dit project is om een tool te ontwikkelen die statische teksten van de applicatie automatisch vertaald naar een andere taal aan de hand van een AI tool. Verder wil Bluenotion dat de klant de vertalingen zelf kan beheren/aanpassen.
Leeswijzer
In dit document worden de volgende dingen besproken:
- Hoe dit project tot en met stand is gekomen.
- Een beschrijving van het bedrijf en de organisatie.
- Doelstelling van het project.
- Welke randvoorwaarden en projectgrenzen vastgesteld zijn.
- Welke beroepsproducten er opgeleverd worden, aan welke kwaliteitseisen deze beroepsproducten moeten voldoen en hoe ervoor wordt gezorgd dat deze eisen nagekomen worden.
- Welke ontwikkelmethoden er gebruikt worden.
- Een globale planning van het project.
- Welke contactpersonen betrokken zijn bij het project en wat hun verantwoordelijkheden zijn.
- Welke risico's er zijn en hoe deze aangepakt worden.
1. Achtergrond van het project
1.1 Organisatiebeschrijving
Bluenotion is een digitale agency, die maatwerksoftware ontwikkelt voor klanten die met hun problemen naar Bluenotion toekomen. Dit doen ze met 25 medewerkers binnen Bluenotion zelf, waarvan 19 ontwikkelaars. Het bedrijf werkt niet met afdelingen, alles is dus een grote afdeling. Bluenotion neemt projecten van alle branches aan, op het moment draaien er ongeveer 20 gelijktijdige projecten. Bluenotion neemt diverse projecten aan, maar ze zijn gespecialiseerd in portalen, marketplaces, high traffic websites en kassasystemen. Bluenotion heeft een bedrijf genaamd Wilmar overgekocht, Wilmar is een bedrijf dat een kassasysteem verkoopt aan fietsenwinkels door heel Nederland. Bij de ontwikkeling van dit kassasysteem wordt soms de hulp van Bluenotion ingeroepen.
Bluenotion bouwt vrijwel altijd een MVP voor een klant en ontwikkelt daarna bij vraag van de klant door aan het product, dit doen ze in C# .NET, React en React Native.
1.2. De opdracht
Solution for translations and automated localization
1.2.1. Huidige situatie
Veel klanten willen vertalingen doorvoeren. Het kost veel geld om door ons steeds te laten vertalen. Gebruik maken van standaard software is niet mogelijk omdat de maandelijkse kosten te hoog zijn. De meeste features die in de bestaande software zitten worden niet gebruikt. Als klant wil je de systeem taal van de applicatie vertalen naar een andere taal (statische teksten zoals headers van tabellen). We pakken nu een JSON-bestand met daarin alle systeem taal. Het JSON-bestand laten we vertalen door ChatGPT, het resultaat kopiëren we hierna terug in het nieuwe JSON-bestand zodat deze gebruikt kan worden. Voor de uitwerking van deze opdracht is het automatisch aanmaken van de bestanden al ingebouwd. Het probleem is wel dat de vertalingen aangeleverd moeten worden, dit doen we niet zelf. De vertalingsmodellen zijn nog niet optimaal, waardoor het lastig blijft om hier gebruik van te blijven maken.
1.2.2. Gewenste situatie
Als oplossing wordt er een tool voorgesteld die in onze code opzoek gaat naar de vertalingsbestanden. Het is de bedoeling dat deze ook in een user interface beschikbaar gemaakt worden voor klant. De klant kan dan zelf vertalen of via een AI tool (die nog onderzocht moet worden) automatisch zijn complete vertalingsbestand vertalen naar een nieuwe taal. De klant moet ook de mogelijkheid hebben om de vertalingen zelf te beheren. Als de klant zijn veranderingen opslaat moeten de wijzigingen automatisch in het versiebeheer systeem wijzigen of toegevoegd worden. Verder moeten nieuwe vertalingen direct beschikbaar worden voor de eindgebruikers, zelfs als er in het versiebeheer systeem een pull requests gedaan moet worden. Hiervoor zal dus een extra bron voor de vertalingen moeten komen. Voor de user interface kan voortgebouwd worden op het portaal dat ontwikkeld wordt door een andere afstudeerder. Als de andere afstudeerder het inloggen af heeft dan kan het hierop voortgebouwd worden.
1.3. Stakeholders
Bluenotion, het bedrijf waar ik afstudeer is stakeholder van dit product, specifieker gezien zijn het de projectmanager en de developers. Het zal Bluenotion geld en tijd besparen als zij niet voor elke klant statische vertalingen hoeven te maken, vooral als de klanten deze ook nog een zelf kunnen beheren. De klant is stakeholder, omdat hij zijn vertalingen wil kunnen beheren en genereren.
1.4. Organisatiestructuur
1.5. Aanleiding
Bluenotion wil met deze opdracht gemak voor de klant bieden, meer tijd voor ontwikkelaars vrij maken en de verantwoordelijkheid voor vertalingen bij de klant neerleggen. Bluenotion wil dat deze opdracht nu uitgevoerd wordt, omdat het in de toekomst veel tijd zal besparen, vooral omdat Bluenotion aan het groeien is. Dit betekent dus ook dat de vraag voor vertalingen zal toenemen.
2. Doelstelling, opdracht en op te leveren resultaten voor het bedrijf
2.1. Probleem
Op het moment worden statische teksten op de applicaties van klanten vertaald via ChatGPT door developers van Bluenotion. Dit heeft als resultaat dat het onnodige extra tijd en geld kost voor developers om vertalingen te laten genereren door ChatGPT, te controleren en live te zetten op de omgeving wanneer een bedrijf in een nieuw land of continent uitrolt.
In sommige gevallen stuurt Bluenotion de vertalingsbestanden (JSON & Scriban) door naar de klant zelf zodat hij deze in kan vullen. De klant is echter niet behendig in de techniek die de vertalingsbestanden, hierdoor moet een ontwikkelaar vaak alsnog naar de bestanden kijken omdat het formaat van het document niet meer klopt.
2.2. Doelstelling
Om tijd en geld te besparen wil Bluenotion een tool ontwikkelen die statische teksten van de applicatie automatisch vertaald naar een andere taal aan de hand van een AI tool. Verder wil Bluenotion dat de klant de vertalingen zelf kan beheren/aanpassen zodat de klant zelf verantwoordelijk is voor de vertalingen op binnen zijn systeem.
2.3. Opdracht
De opdracht is om een uitbreiding te schrijven op een bestaand systeem dat een andere afstudeerder aan het ontwikkelen is. Hierin kunnen externe klanten en Bluenotion zelf de vertalingen van projecten beheren en nieuwe vertalingen genereren. Dit geldt enkel voor statische vertalingen. De vertalingen moeten direct na het publiceren beschikbaar worden voor de eindgebruikers. De vertalingen moeten ook handmatig door gebruikers ingevuld kunnen worden, zodat ze niet vast zitten aan de AI tool en mogelijke foutieve vertalingen kunnen corrigeren.
2.4. Resultaten
Een uitbreiding op een bestaande applicatie met een back-end in C# .NET, en een front-end die gebouwd is in React Native en Typescript. De uitbreiding zorgt ervoor dat de klant zijn vertalingen kan beheren en nieuwe vertalingen in andere talen kan genereren.
Een nieuwe module in de back-end die vertalingen ophaalt uit de applicatie, deze vertaalt met een AI tool 1. en deze nieuwe vertalingen opslaat in een Git versiebeheer systeem zodat de applicatie ze kan gebruiken.
Er moet ook een service gemaakt worden waarin nieuwe gepubliceerde vertalingen direct beschikbaar worden voor de eindgebruikers.
1. Welke AI tool hiervoor gebruikt gaat worden is nog niet duidelijk, hier wordt nog onderzoek naar gedaan.
3. Projectgrenzen
- De uitbreiding in de back-end wordt enkel ontwikkelt voor statische content, niet dynamische content.
- De implementatie gaat alleen werken voor een Git versiebeheer systeem, geen andere soorten systemen.
- In weekend, buiten werktijd en (school)vakanties kan mogelijk doorgewerkt worden, maar dit is niet verplicht.
- De stagetermijn van dit project is van 2 September 2024 tot en met 31 Januari 2025, hierna zal er dus niet meer doorgewerkt worden aan het project.
4. Randvoorwaarden
- Bluenotion levert bij de start van het project een werkplek met een laptop om aan het project te kunnen werken.
- Bluenotion stelt minstens 1x per week een werknemer (Bedrijfsbegeleider) beschikbaar om over het project te kunnen overleggen en feedback te krijgen.
- Bluenotion biedt wanneer nodig budget om AI tools te kunnen onderzoeken en gebruiken.
- Bluenotion zorgt voor een ontwikkelomgeving/infrastructuur om de uitbreiding van de back-end en de front-end portal (in een live omgeving) te kunnen testen.
5. Op te leveren producten en kwaliteitseisen
| Product | Productkwaliteitseisen | Activiteiten | Proceskwaliteitseisen (SMART) |
|---|---|---|---|
| Plan van aanpak | - De bedrijfs- en schoolbegeleider hebben het plan van aanpak goedgekeurd - Contactgegevens voor alle partijen zijn vastgelegd - Bevat een duidelijke beschrijving van de opdracht/het project - Bevat een duidelijke beschrijving van wat er opgeleverd gaat worden aan het bedrijf - Op te leveren producten bevatten goede product en proces kwaliteitseisen met uit te voeren activiteiten - Projectgrenzen en randvoorwaarden zijn vastgelegd - Er is een globale planning vastgelegd - Risico’s zijn vastgelegd met tegen maatregels en uitwijk strategieën |
- Bespreken met bedrijfs- en schoolbegeleider - Plan van aanpak uitwerken aan de hand van de handleiding die de HAN beschikbaar gesteld heeft. |
- de developer zet in de eerste week het Plan van Aanpak op en loopt deze met zijn begeleider aan het einde van de eerste week door. - Plan van Aanpak wordt in week 6 van het project nagekeken door de docentbegeleider, indien er feedback gegeven wordt door de Docentbegeleider en/of Bedrijfsbegeleider, wordt deze door mij verwerkt en het Plan van Aanpak in week 8 nogmaals nagekeken. |
| Onderzoek AI tool vertalingen | Beantwoord de volgende hoofdvraag: - Welke AI tools zijn er beschikbaar voor het vertalen van teksten, en welke is het meest passend voor het project? Deelvragen: 1. Welke AI tools zijn er beschikbaar voor het vertalen van teksten? 2. Wat zijn de voor- en nadelen van de verschillende AI tools? 3. Welke AI tool(s) presteert/presteren het beste? |
- Onderzoek naar verschillende AI tools voor het vertalen van woorden/teksten, performance, kosten, ondersteunde talen. - Vergelijking van tools maken en een keuze maken over welke tool het meest passend is voor dit probleem. - Onderzoek/overleg naar budget voor AI tool |
- Voor het starten van het onderzoek moeten de requirements goedgekeurd worden door de Project Manager en een Tech Lead, zodat de opdracht vast staat en duidelijk is. - Feedback van Opdrachtgever op de resultaten van het onderzoek, en de conclusie verwerken en gebruiken om een goede beslissing te maken. Discussiëren over uitkomst/beslissing en het eens worden over de implementatie die gebruikt gaat worden. (De Opdrachtgever overhalen waarom de uitkomst de beste keuze is.) |
| Eindproduct (front- en backend) | - Bevat een front-end waarin de vertalingen beheerd en in een nieuwe taal gegenereerd kunnen worden - Bevat nieuwe back-end module die verantwoordelijk is voor het communiceren naar de AI tool voor de nieuwe vertalingen, en het opslaan van de nieuwe vertalingen via een koppeling in een Git versiebeheer systeem. - Bevat een service die de (nieuwe) gepubliceerde vertalingsbestanden beschikbaar maakt voor de eindgebruikers - Is beschikbaar op een productieomgeving van Bluenotion, die volgens CI/CD live gezet wordt via een pipeline. Deze wordt op een Linux server via Microsoft IIS gedeployed. (hier wordt ook het domein voor de applicatie ingesteld) |
- Front-end bouwen/uitbreiden met beheerbare vertalingen en genereerbare vertalingen. - De back-end module uitbreiding bouwen, die de daadwerkelijke vertalingen doorstuurt naar de AI tool en opslaat in het Git versiebeheer systeem. - De service die de nieuwe vertalingen aanbiedt bouwen |
- De front-end bouwen/uitbreiden aan de hand van de gemaakt schermontwerpen uit het functionele ontwerp. - De front- en backend bouwen aan de hand van de functionele, niet functionele eisen en het technisch ontwerp. - Feedback van Product Owner bij iedere Sprint Review over opgeleverde product(en), en volgende stappen. - Bij belangrijke technische keuzes overleggen met de Tech Lead over wat een handige en passende oplossing is. - Bij een Sprint Review wordt er ook samen met de Product Owner gekeken naar alle documentatie en code, om zo te kunnen zien of het overeen komt en of Bluenotion er daadwerkelijk iets aan heeft. |
| Functioneel ontwerp | - Bevat functionele en niet functionele eisen - Bevat een lijst van alle actoren binnen het systeem. - Bevat alle use cases. - Bevat schermontwerpen/wireframes gemaakt in Figma per use case, in wireframe, low fidelity en high fidelity formaat. - Bevat per use case een video die weergeeft hoe de gebouwde functionaliteit daadwerkelijk functioneert. - Bevat een domeinmodel en use case diagram in UML formaat. - Functionele requirements zijn uitgewerkt in use cases, wanneer het nodig is in fully dressed formaat, anders in de brief formaat. - use cases bevatten happy en (relevante) alternative flows (wanneer relevant). - Use case happy en alternative flows zijn met Mermaid.js vastgelegd in de vorm van een sequence diagram. |
- Gesprek met opdrachtgever om de wensen en stakeholders vast te leggen. - Gesprek met UX collega om tot en met een goede wireframe/schermontwerp te komen. - Eisen opdelen in functioneel en niet functionele eisen. - Functionele eisen vastleggen in fully dressed use cases met MoSCoW prioritering. |
- Wanneer het Plan van Aanpak akkoord is kunnen de functionele en niet functionele eisen uitgewerkt worden, hierna kunnen de use cases uitgewerkt worden. - Wanneer het use case diagram en de use cases uitgewerkt zijn kunnen de schermontwerpen gemaakt worden. - Wijziging van het functioneel ontwerp en/of technisch ontwerp worden ook in de uitwerken/het product gereflecteerd. - Feedback van Product Owner wordt verwerkt tijdens Sprint Review als er dingen niet lijken te kloppen of missen. |
| Technisch ontwerp | - Voor de datastructuur wordt een diagram in de vorm van een ERD gemaakt, deze hoeft niet te voldoen aan alle eisen van een ERD, zolang de data structuur maar duidelijk is. - Voor de diagrammen wordt UML, C4-Model of een soortgelijke techniek gebruikt. Voor een overzicht van de infrastructuur zal het C4 Context diagram gebruikt worden. Voor een overzicht van de onderdelen binnen de applicatie wordt het C4 Container en Component diagram gebruikt. - Bevat een technische beschrijving waarin nieuwe modellen, implementaties, interfaces inzichtelijk worden per uitgewerkte use case. Hiervoor zullen code voorbeelden en component diagrammen van C4 voor gebruikt worden. - Alle (nieuwe) endpoints die gemaakt zijn per use case worden uitgewerkt met de endpoint, methode, beschrijving, request en response body. - Bevat een diagram die de infrastructuur en de communicatie daartussen in beeld brengt. |
- Een klasse diagram maken, en deze bijwerken wanneer nodig - De lijst van endpoints per use case bijwerken als er een nieuwe endpoint gemaakt is. - Een database diagram maken als dit nodig blijkt te zijn. - Een C4 Context en container diagram uitwerken. - Per use case de C4 component diagrammen uitwerken, voor de back-end een overzicht van de interfaces, modellen en implementaties (ook in een C4 component diagram en mogelijk andere vormen om dit duidelijk in beeld te brengen). |
- De diagrammen bijwerken als er een verandering in de code/architectuur komt. - Een eerste opzet van de diagrammen maken wanneer er een start aan de uitwerking van het project gemaakt wordt. - Feedback van Product Owner wordt verwerkt tijdens Sprint Review als er dingen niet lijken te kloppen of missen. |
| Code | - Code wordt in het Engels geschreven - Code volgt de structuur van het Functioneel en Technisch ontwerp - Er wordt waar realistisch mogelijk rekening gehouden met coding principles (Zoals SOLID en GRASP, en design patterns). - Frontend code wordt geanalyseerd door ESLint. - Backend code wordt geanalyseerd met dotnet format, met aanvullende regels van StyleCop, Bluenotion heeft hier een globaal editorconfig bestand voor die alle projecten gebruiken. - Code formatting wordt gedaan aan de hand van Editorconfig en Prettier. |
- Code wordt geschreven volgens de programmeertaal standaarden - ESLint, StyleCop, Editorconfig en Prettier dienen geïnstalleerd en gebruikt te worden. |
- Voordat er een pull request aangemaakt wordt, wordt er gecontroleerd of de code voldoet aan de Definition of Done - Wanneer er een pull request wordt aangemaakt worden de unit tests, integratie tests en end-to-end tests uitgevoerd. Eventuele andere tests die gemaakt worden, die niet in deze lijst staan vallen hier ook onder. - Een pull request wordt nagekeken door een andere ontwikkelaar zodat de code kwaliteit en de kwaliteit van de code infrastructuur bewaard kunnen worden. - Feedback op de documentatie van de Bedrijfsbegeleider en eventuele opmerkingen moeten ook aangepast worden in de code. |
| Geautomatiseerde tests en/of testplan | - Geautomatiseerde tests, zoals Unit tests, end-to-end tests of integratie tests worden geschreven wanneer het om een complexe flow gaat, of als het een belangrijk stuk functionaliteit is van de applicatie. - De geautomatiseerde test of de test in het testplan bevat voor elke use case de happy flow. - De geautomatiseerde test of de test in het testplan vangt de alternatieve flows van het scenario af die relevant zijn. - Als er geautomatiseerde tests geschreven zijn moeten deze 100% slagen. |
- Een geautomatiseerde test of een nieuwe test in het testplan wordt toegevoegd wanneer er een stuk code gebouwd is die communiceert met een ander systeem. - Enige andere tests die mogelijk relevant zijn om toegevoegd te worden, worden overlegd met de opdrachtgever. |
- Geautomatiseerde tests of het plan worden uitgevoerd voordat er nieuwe veranderingen gepusht worden - Tests worden geschreven wanneer het gaat om een complexe flow of een belangrijk stuk functionaliteit in de applicatie. - Bij de Sprint Review laat ik onder andere ook de verschillende tests die ik gemaakt heb zien aan mijn Bedrijfsbegeleider (integratie, end-to-end, unit tests, etc) zodat ik feedback kan ontvangen over de dekking en werking van de tests, en ik deze kan verwerken in de volgende sprint mocht dit nodig zijn. |
| Afstudeerverslag | - Het verslag is maximaal 6000 woorden (ongeveer 15 pagina's), dit is exclusief samenvatting, inhoudsopgave, bronvermeldingen en bijlagen. - Her verslag wordt in het Nederlands opgeleverd. (Behalve beroepsproducten, deze mogen in het Engels) - Alle beoordelingscriteria (BC1 t/m BC5) uit het beoordelingsformulier afstuderen ICT 2020-2021 van de Afstudeerhandleiding HBO-ICT en CMD 2024-2025. Alle PC's moeten minimaal een 4 zijn, en alle BC's moeten minimaal een 5.5 zijn. - Het verslag voldoet aan de richtlijnen van de AIM-controlekaart |
- Het afstudeerverslag schrijven - Het afstudeerverslag controleren a.d.h.v de AIM-controlekaart - Het afstudeerverslag controleren op de het beoordelingsformulier |
- Tussentijds en aan het einde wordt er naar het verslag gekeken, tussentijds krijg ik feedback op het verslag zodat ik deze feedback kan verwerken. - Ik werk iedere week een middag aan het verslag - Ik laat mijn Bedrijfsbegeleider tussentijds (misschien nog vaker als dit nodig blijkt te zijn) het verslag doorlezen, zodat hij kan controleren of wat er instaat overeenkomt met wat ik uitgevoerd heb. Ook zodat hij feedback kan geven en ik deze feedback kan verwerken. |
| Eindpresentatie | - Er wordt een presentatie gegeven van maximaal 20-30 minuten waarin alle activiteiten en resultaten van het project besproken worden. | - De presentatie zelf maken | - Aan het einde van het project (Week 20) wordt er een presentatie gemaakt die beschrijft wat er in het project uitgevoerd is. - De presentatie oefenen met mijn Bedrijfsbegeleider, zodat hij feedback kan geven op de presentatie en ik deze kan verwerken. |
| Opleverdocument | - Bevat een lijst van acties die uitgevoerd moeten worden om de software lokaal en op een productie omgeving werkend te krijgen - Uitwerken van afhankelijkheden met externe partijen. - Uitwerken van belangrijke keuzes die tijdens de uitwerking van het project gemaakt zijn. - Uitwerken van de lijst van niet afgeronde functionaliteiten (wanneer dit het geval is) |
- Uitwerken van de acties die uitgevoerd moeten worden om de software draaiend te krijgen. - Afhankelijkheden vastleggend - Belangrijke keuzes vastleggen - Niet afgeronde functionaliteit (wanneer dit het geval is) vastleggen |
- Wanneer het complete project/product afgerond is wordt de opleverdocumentatie uitgewerkt - De opleverdocumentatie wordt doorgenomen samen met een andere ontwikkelaar, die niets weet over het project. Dit zodat er getest kan worden of de opleverdocumentatie duidelijk is. Eventuele feedback die hier uitkomt zal verwerkt worden in de documentatie. |
6. Ontwikkelmethoden
Waterval is een goede ontwikkelmethode waarbij een strict achtereenvolgende stappen gevolgd worden om tot en met een resultaat te komen. Wanneer een stap afgerond is kan deze stap in hetzelfde proces niet herhaald worden. Deze methode werkt het beste in situaties waar de requirements goed gedefinieerd zijn en niet veranderen. GeeksforGeeks. (2024, June 3)
In het geval van deze opdracht is het mogelijk dat de requirements gedurende de ontwikkeling veranderen doordat de wensen van de Product Owner veranderen. Hierdoor is een waterval methode niet handig. Daardoor ga ik voor de ontwikkelmethode van dit project een iteratieve en incrementele werkmethode gebruiken.
Bluenotion gebruikt een combinatie van een waterval en agile werkmethode. Aan het begin van een project inventariseren ze alle werkzaamheden die gedaan moeten worden, deze worden vervolgens allemaal op een backlog gezet zodat er een urenschatting voor de klant gemaakt kan worden. Nadat dit gedaan is volgt Bluenotion een Agile werkvorm waarin ze iedere 2 weken een stukje functionaliteit opleveren aan de klant. Bluenotion werkt bij ieder project toe naar een zogenaamde MVP de planning en indeling van de fases richting de MVP wordt door Bluenotion zelf gedaan, nadat de MVP bereikt is kan de klant meedenken over welke functionaliteit prioriteit heeft om uitgewerkt te worden. Scrumban lijkt enigszins op de werkmethode die Bluenotion nu gebruikt, met uitzondering van de complete uitwerking van de backlog aan het begin van het project. In mijn geval is dit niet nodig, omdat dit project intern ontwikkelt wordt en het budget hiervoor niet relevant is. Doordat de methode die door Bluenotion gebruikt wordt voor de ontwikkeling veel lijkt op Scrumban zal eventuele ondersteuning hierbij niet lastig moeten zijn.
Aan het begin van het project ben ik van plan eerst alle requirements in kaart te brengen, zodat ik en de opdrachtgever op dezelfde lijn zitten over wat er wel en niet gebouwd gaat worden. De functionele requirements zullen geprioriteerd worden, de niet functionele requirements worden als een algemeen vereiste opgenomen. De functionele requirements, ook wel user story's worden hierna toegekend aan use cases zodat bij de start van de ontwikkeling al bekend is wat er uitgewerkt moet worden. Vanaf dit punt zal ik verder werken volgens de Scrumban werkmethode.
Bluenotion gebruikt voor zijn projecten vaak de term MVP. Hiermee wordt een product bedoeld waarin de minimale versie die bruikbaar is voor de klant. In het geval van mijn opdracht is dit ook zo. Als het uitkomt zou het mogelijk interessant zijn om klanttesten uit te voeren om te kijken of de klant tevreden is met de MVP, en of er nog dingen aangepast moeten worden. Dit is echter niet verplicht, omdat het onduidelijk is of de klant hier tijd voor heeft en of dat het project op tijd afgerond is om dit nog te kunnen doen. In het geval van mijn opdracht houdt de MVP in dat een klant gemakkelijk zijn vertalingen kan beheren.
Ik ga in dit project de Scrumban methodiek gebruiken, omdat deze methodiek geen rollen vereist. Verder vereist Scrumban geen verdeling van verantwoordelijkheden en kan daardoor ook door een enkel persoon gebruikt worden, in dit geval voor een afstudeerproject is dit ideaal. Verder heeft Scrumban geen product backlog, alles wat nodig is komt in To Do op het bord. Net zoals Bluenotion zullen mijn sprints ook 2 weken duren.
Scrumban schrijft voor om te werken met een bord, waarin kaarten (taken) aangemaakt kunnen worden. Deze kaarten worden in kolommen geplaatst, de kolommen zijn: To Do, In Progress, Review en Done. In de kolom To Do staan alle taken die nog uitgevoerd moeten worden, een taak komt in To Do wanneer er aan een nieuwe onderdeel begonnen wordt. In het geval van deze opdracht heet de To Do kolom Backlog. Wanneer een taak opgepakt wordt komt deze in de In Progress kolom. Wanneer een taak afgerond is komt deze in de Review kolom, hier wordt de taak bekeken door een andere developer. Wanneer de taak goedgekeurd is komt deze in de Done kolom, in het geval van mijn project heet deze Done/Development. De In review is niet zoals voorgeschreven vanuit Scrumban, maar in mijn geval heb ik hem wel toegevoegd omdat ik het fijn vind om een extra controle te hebben op mijn werk. Mijn To Do kolom heet Backlog, omdat ik dit een logischere naam vind voor de taken die nog uitgevoerd moeten worden, verder wordt deze naam ook gebruikt bij andere projecten binnen Bluenotion. De rol van de kolom is nog steeds hetzelfde als in Scrumban. Atlassian, B. (n.d.)
Scrumban vereist volgens voorschriften geen rollen, dit betekent dat iedereen in het team dezelfde verantwoordelijkheden heeft. In mijn geval ben ik de enige ontwikkelaar die aan het project werkt. Echter zijn er wel andere mensen betrokken bij het project, denk hierbij aan mensen zoals de Bedrijfsbegeleider, de Opdrachtgever en de Buddy. Deze mensen hebben geen directe invloed op de taken die ik uitvoer, maar leveren wel andere soorten input die ik kan gebruiken om mijn werk te verbeteren. De UX/UI Designer heeft in dit geval wel invloed op mijn werk, omdat ik de front-end van het project ga bouwen volgens de schermontwerpen die hij maakt. De schermontwerpen zijn echter wel gebaseerd op eerdere wireframes en low fidelity schermontwerpen die ik zelf ontwerpen heb.
Verder schrijft Scrumban een aantal "Events" voor, namelijk een Sprint Planning, Daily standup en Sprint retrospective. De Sprint Planning doe ik samen met de Opdrachtgever, alhoewel Scrumban geen Sprint Review voorschrijft, zal ik deze wel houden met de Opdrachtgever. De Daily Standup doe ik niet officieel, wanneer er iets misloopt communiceer ik dit naar mijn Bedrijfsbegeleider, zodat hij mij hierbij tijdig bij kan helpen. De Sprint Retrospective doe ik door de sprint heen. Deze gebruik ik om mijn verslag aan te vullen, als bij de Sprint review blijft dat er iets aan mijn werkmethode moet veranderen zal ik deze ook tijdens mijn persoonlijke Sprint Retrospective bespreken met mijn Opdrachtgever.
Klik hier om de live Productive omgeving te bekijken
7. Projectorganisatie en communicatie
| Rol(len) | Student/Afstudeerder |
|---|---|
| Naam | Kevin Vink |
| Contactgegevens | kevin@bluenotion.nl |
| Contactmomenten | Ma-Vr 09:00 tot en met 17:30 (of andere tijden zolang deze maar op 8 uur per dag uitkomen) |
| Verantwoordelijkheden | - Plannen en uitvoeren van het afstudeerproject - Plannen en begeleiden van afspraken, communicatie met belanghebbende in het bedrijf en binnen de HAN. - Het project zelf plannen, uitvoeren en vastleggen. |
| Rol(len) | Buddy (andere Afstudeerder) |
|---|---|
| Naam | Stephan Tollenaar |
| Contactgegevens | stephan@wilmarinfo.nl |
| Contactmomenten | Wanneer nodig |
| Verantwoordelijkheden | - Contactpersoon om technische of functionele zaken van het project mee te overleggen. |
| Rol(len) | Bedrijfsbegeleider, Tech Lead & Product Owner |
|---|---|
| Naam | Sjoerd Crooijmans |
| Contactgegevens | sjoerd@bluenotion.nl |
| Contactmomenten | Iedere dinsdag 09:00, wanneer nodig vaker op aanvraag als het uitkomt |
| Verantwoordelijkheden | - Aan het einde van een sprint (Review) meekijken naar de voortgang, en vervolgstappen vaststellen samen met mij. - Feedback geven op documenten, project eventueel overleggen over de opdracht - Overleg en feedback leveren op back-end design keuzes, infrastructuur keuzes en standaarden van Bluenotion. |
| Rol(len) | Operationeel Manager |
|---|---|
| Naam | Jesse Bekke |
| Contactgegevens | jesse@bluenotion.nl |
| Contactmomenten | Wanneer nodig |
| Verantwoordelijkheden | - Aanspreekpunt voor zaken binnen Bluenotion. |
| Rol(len) | UX/UI Designer |
|---|---|
| Naam | Roel Dekkers |
| Contactgegevens | roel@bluenotion.nl |
| Contactmomenten | Wanneer nodig |
| Verantwoordelijkheden | - Overleg en feedback leveren op front-end UI/UX, en eventueel ontwerp voor de uitbreiding op het portal. |
| Rol(len) | Docent Begeleider |
|---|---|
| Naam | Lars Thijsma |
| Contactgegevens | Lars.Tijsma@han.nl |
| Contactmomenten | - Iedere 2 weken, wanneer nodig op basis van voortgang die gecommuniceerd wordt via mail. - Start, tussentijds en aan het einde van het project |
| Verantwoordelijkheden | - Begeleidt de student waar nodig, geeft feedback op documenten wanneer dit nodig is. |
| Rol(len) | Assessor |
|---|---|
| Naam | Bart van der Wal |
| Contactgegevens | Bart.vanderWal@han.nl |
| Contactmomenten | Aan het einde van het project |
| Verantwoordelijkheden | - Beoordeelt alle beroepsproducten, het proces en het gehele project. Geeft het uiteindelijke punt van de afstudeerstage |
8. Planning
| Sprint | Datums | Week/Weken | Werkzaamheden | Op te leveren producten |
|---|---|---|---|---|
| Sprint 1 | 2 September 2024 tot en met 13 September 2024 | Week 1 & 2 | Plan van Aanpak opstellen, requirements inventariseren, requirements categoriseren in functionele en niet functionele eisen, eisen prioriteren a.d.h.v. MoSCoW. | - Plan van Aanpak - Functioneel ontwerp met geprioriteerde functionele- en niet functionele eisen, domeinmodel en use case diagram |
| Sprint 2 | 16 September 2024 tot en met 27 September 2024 | Week 3 & 4 | Onderzoek doen naar best passende AI tool. PoC (Proof of Concept) opzetten om communicatie tussen AI tool en het Git versiebeheer systeem vast te stellen. Verder ook onderzoeken in welk formaat de JSON vertaling bestanden het beste door de AI tool verwerkt kunnen worden, inclusief mogelijke context die nodig is. | - Onderzoek AI tool (incl resultaten) - PoC communicatie AI tool en Git versiebeheer systeem |
| Sprint 3 | 30 September 2024 tot en met 11 Oktober 2024 | Week 5 & 6 | Opzet koppeling tussen bestaande back-end en Git repository, met mogelijkheid voor toekomstige integratie van andere version control platformen. Ophalen van alle vertalingsbestanden in een project. Functioneel ontwerp uitbreiden en technisch ontwerp opzetten. Infrastructuur schets maken, ERD voor koppeling project en version control repository. | - Technisch ontwerp (Klasse diagram, ERD, infrastructuur schets) - Nieuwe iteratie van het eindproduct, waarin de koppeling tussen project en version control repository en de bijbehorende access tokens opgeslagen worden in de database. |
| Sprint 4 | 14 Oktober 2024 tot en met 1 November 2024 | Week 7 & 8 | Wireframes maken voor de front-end, zodat deze later door een UX developer uitgewerkt kunnen worden tot high fidelity schermontwerpen. Verder worden de opgehaalde bestanden geformatteerde naar een formaat die vertaald kan worden door de AI tool, vervolgens worden alle teksten/woorden vertaald. Hierna worden de teksten/woorden opnieuw geformatteerd naar het formaat van het JSON vertalingsbestand, en wordt het nieuwe bestand opgeslagen in het Git versiebeheer systeem. | - Wireframes - Nieuwe iteratie waarin vertalingsbestanden omgezet kunnen worden naar een nieuw vertalingsbestand in een andere taal |
| Herfstvakantie | ||||
| Sprint 5 | 4 November 2024 tot en met 15 November 2024 | Week 9 & 10 | Nieuwe vertalingsbestanden opslaan in het Git versiebeheer systeem, met toekomstbestendige opzet voor andere Git version control systemen, handmatig vertalingen aan kunnen passen en op kunnen slaan. De nieuwe service implementeren waarin de nieuwe gepubliceerde vertalingsbestanden beschikbaar gesteld worden voor de eindgebruikers. | - Nieuwe iteratie waarin de nieuwe vertalingsbestanden worden opgeslagen in de Git version control en de nieuwe service. Verder de vertalingen handmatig aan kunnen passen en kunnen publiceren. |
| Sprint 6 | 18 November 2024 tot en met 29 November 2024 | Week 11 & 12 | Uitloop voor back-end ontwikkeling, wanneer alles afgerond is verder gaan met taken van Sprint 7. | - Niet afgeronde functionaliteit |
| Sprint 7 | 2 December 2024 tot en met 13 December 2024 | Week 13 & 14 | Onderdeel van high fidelity schermontwerp uitwerken (genereren van vertalingen), mogelijkheid om vertalingen te genereren voor nieuwe ondersteunde taal. | - Iteratie met front-end om teksten/woorden in nieuwe taal te genereren |
| Sprint 8 | 16 December 2024 tot en met 10 Januari 2025 | Week 15 & 16 | Resterende deel van high fidelity schermontwerp uitwerken (beheren van vertalingen). Gegenereerde woorden zelf aan kunnen passen met eigen invulling. | - Nieuwe iteratie waarin vertalingen beheerd kunnen worden, aanpassen van vertaling via front-end portal. |
| Kerstvakantie | ||||
| Sprint 9 | 13 Januari 2025 tot en met 24 Januari 2025 | Week 17 & 18 | Uitloop voor front-end ontwikkeling, wanneer alles afgerond is eventueel nieuwe functionaliteit toevoegen, of alle beroepsproducten en documenten alvast op orde maken voor afronding. Afstudeerverslag afronden | - Afstudeerverslag - Niet afgeronde functionaliteit |
| Sprint 10 | 27 Januari 2025 tot en met 31 Januari 2025 | Week 19 | Opleverdocument en de eindpresentatie maken. | - Opleverdocument - Eindpresentatie |
9. Risico's
| Risico | Kans (Klein/Middel/Groot) | Impact (Klein/Middel/Groot) | Tegenmaatregel | Uitwijkstrategie |
|---|---|---|---|---|
| Het portaal waarin de vertalingen beheerbaar worden is niet op tijd af | Klein | Middel | Contact met ontwikkelaar houden over progressie van het portaal | De template van Bluenotion gebruiken, waarin inloggen en registreren al inzit, en daar het beheren inbouwen. |
| AI tool blijkt niet genoeg talen te ondersteunen, niet goed te performen, of niet goed met teksten/woorden om te kunnen gaan | Middel | Groot | Onderzoek naar mogelijkheden van AI tools | Overleggen met Product Owner over alternatieven, of mogelijke veranderingen in de doelen/grenzen van de opdracht |
| UX designer heeft geen tijd om schermontwerpen te maken | Klein | Klein | Overleggen met UX designer over de prioriteit van de schermontwerpen, of op tijd plannen met de operationeel manager | Zelf schermontwerpen maken, en deze laten controleren door de UX designer |
| De back-end module kan niet communiceren met de AI tool | Klein | Middel | Overleggen met de Tech Lead over de mogelijkheden van de back-end module | Overleggen met de Tech Lead over alternatieven, of mogelijke veranderingen in de doelen/grenzen van de opdracht |
| De stakeholders blijken niet genoeg tijd te hebben om feedback te geven of te overleggen | Klein | Middel | Stakeholders tijdig herinneren over afspraken | Nieuwe afspraak met stakeholders maken. |
10. Bronnen
- GeeksforGeeks. (2024, June 3). Difference between Waterfall model and Incremental model. GeeksforGeeks. https://www.geeksforgeeks.org/difference-between-waterfall-model-and-incremental-model/
- Atlassian, B. (n.d.). Scrumban: Mastering two Agile Methodologies | Atlassian. Atlassian. https://www.atlassian.com/agile/project-management/scrumban