Projectverslag
1. Inleiding
In dit document wordt mijn individuele bijdragen bijgehouden over het project van de komende 10 weken. Het project zal starten op 1 November. In dit project worden de klas opgesplitst in een aantal groepjes, mijn groepje het als opdracht dat wij een data log systeem moeten maken voor Regterschot Racing. In mijn vorige project hebben we met RUP gewerkt maar dat is nu weer SCRUM geworden. Hiermee splitsen wij de 10 weken op een 6-tal sprints, en in elke sprint gaan wij focussen op een stuk van het project.
De leerdoelen die ik heb gekozen voor dit project is om mij meer te ontwikkelen en betrekken van het project. Ik wil mij meer opstellen als iemand die niet bang is om de leider te spelen in de groep en daarom ook duidelijke wil communiceren naar zowel docenten op school als de opdrachtgever.
De bedoeling van dit verslag is om mijn contributie aan dit project te weergeven, en te laten zien dat ik mijn eigen werk kan beoordelen.
2. Kwaliteitsoordeel deelproducten
2.1 Plan Van Aanpak (PVA)
Het PVA vind ik uiteindelijk wel voldoende. De opstart van het project ging nogal stroef. Dit kwam doordat we elkaar nog niet zo goed kende en we de rollen verdeling nog niet zo goed hadden. Tijdens het assessment van het PVA kwamen er een aantal tekortheden aan het ligt. Zoals dat de urgentie miste in de inleiding waardoor het niet duidelijk was waarom de opdrachtgever juist nu ermee wou beginnen. Verder was er onduidelijkheid wat er nou bedoeld werd over de softwarehandleiding, nadat we ons zelf hebben gehoord klikte het dat de handleiding en Software Design Document hetzelfde zijn in principe. Dit soort fouten horen eigenlijk niet te kunnen, wij hebben de nodige documenten gekregen waar dit al in staat en daar hebben we in dit geval compleet overheen gelezen. Voor volgende projecten ga ik dit ook zeker meenemen dat alles wat we maken qua documentatie ook gecontroleerd wordt op de geleverde documenten zodat we dit soort simpele dingen gemakkelijk kunnen afvangen en voorkomen.
Wat ik wel vind is dat we ondanks de moeilijk start wel een stevig plan van aanpak hebben kunnen opzetten op de genoemde fouten na dan. In hoofdstuk 6 hebben wij aangegeven wat wij gaan opleveren na het einde van dit project, hierin vind ik wel dat we de eisen iets strakker hadden kunnen maken. Bijvoorbeeld bij “software/eindeproduct” zeggen wij dat er via Bitbucket een versiebeheer wordt toegepast, maar niet wat de regels daaraan zijn. Hierdoor kunnen mensen misschien inzien dat er 2 branches zijn en daarop werken met ze allen. Nou is dit niet de bedoeling, en zou er eerder van maken: Er wordt via Bitbucket versiebeheer bijgehouden doormiddel van bij elke issue dat je oppakt een nieuwe branch maakt. Dit is een stuk overzichtelijker en duidelijker wat waarop staat en kan je makkelijker terugkijken in de branch als er iets misgaat.
Er zijn zeker genoeg verbeterpunten om het nog netter te maken maar voor de opdrachtgever is dit een prima plan van aanpak. De verbeterpunten die ik nu nog zo zie gaan vooral de afspraken met de developer groep zodat iedereen op een lijn zitten.
2.2 SRS