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
Het SRS is naar mijn mening in een voldoende staat om mee te kunnen werken in de komende sprints. Aangezien wij tijdens elke nieuwe usecase het SRS en SDD zullen updaten naar wat we erbij maken.
De introductie is duidelijk je weet waarover het gaat, en het gaat duidelijk over onze applicatie. Daarnaast is goed te zien wie de applicatie gaat gebruiken en wat de applicatie moet doen.
We hadden voor functionaliteit niet veel restricties gekregen en laat het bedrijf ons daar erg los in hierdoor hebben wij er vrijwel geen product functies in het SRS staan maar die komen er later bij als we gaan brainstormen over extra functies.
Het domeinmodel heeft een net glossary die je laat zien wat de concepten zijn die we hebben gevonden en wat ze inhouden.
De gemaakte usecases die tot nu toe bekend zijn, zijn uitgewerkt met behulp van het fully dressed formaat en ieder deel is duidelijk verwoord. Ze hebben allemaal actors, stakeholders, brief description, pre- en postcondities. Met hierbij een mainflow en eventueel een alternatieve flow.
De beschrijving van main flow mag nog wel wat algemener vind ik. Nu zeg je al dat er een button komt maar de opdrachtgever kan ook zeggen dat het om een andere interactie gaat waardoor je geen button meer voor nodig hebt.
De requirements zijn netjes opgesteld met behulp van FURPS+ dit zorgt ervoor dat je in een oogopslag kan zien wat er is en onder welke kopjes deze requirements vallen.
De sketches die gemaakt zijn voor de applicatie zien er netjes en duidelijk uit. Als iemand van buitenaf ernaar zou kijken weet die exact hoe de applicatie eruit moet komen te zien.
2.3 SDD
Ik vind dat we voor het SDD net een voldoende hebben gedaan. Er zijn nog een aantal dingen waar ik me toch wel aan stoor, waaronder dat de comments nog altijd blijven staan ook al zijn mensen klaar met het kopje.
De inleiding is duidelijk en niet te omslachtig, de terminologie is duidelijk aangegeven en wat ze betekenen voor mensen die niet bekend zijn met de termen. Met het deployment diagram had ik zelf nog wat punten die ik niet had gedaan, zoals dat er een extra punt is gezet voor de rest api is naar mijn mening niet van belang. Aangezien de application server de API is en dat zou betekenen dat het er 2 keer in zou moeten staan.
Het class diagram is tot nu toe vrij klein, dit komt omdat we nog weinig functionaliteit hebben en daarom alleen de hoognodige klassen hebben opgenomen. In de komende sprints gaan we meer en meer functionaliteit toevoegen en dit zal het diagram ook uitbreiden.