Auteurs:

Docenten

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.

Kwaliteitsoordeel deelproducten

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.

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.

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.

Code fragment

Ik ga hier kijken naar een stuk code die ik van onze bitbucket af heb gehaald

Specefiek kijk ik naar dit stuk

public class TabDAO {

    GraphService graphService;
    @Inject
    public void setGraphService(GraphService graphService) {
        this.graphService = graphService;
    }

    private DatabaseConnection databaseConnection;
    @Inject
    public void setDatabaseConnection(DatabaseConnection databaseConnection) {
        this.databaseConnection = databaseConnection;
    }

    public ArrayList<TabsDTO> getUserTabs(String token) throws NoUserFoundException {
        ArrayList<TabsDTO> tabs = new ArrayList<TabsDTO>();
        try {
            PreparedStatement getTabs = databaseConnection.getConnection().prepareStatement("SELECT tabName, TabId FROM Tab Where userToken = ?");
            getTabs.setString(1, token);
            ResultSet getTabsResult = getTabs.executeQuery();
            while(getTabsResult.next()) {
                TabsDTO tabsDTO = new TabsDTO();
                tabsDTO.setId(getTabsResult.getInt("tabId"));
                tabsDTO.setName(getTabsResult.getString("tabName"));
                tabsDTO.setGraphsDTO(graphService.getAll(getTabsResult.getInt("tabId")));
                tabs.add(tabsDTO);
            }
        } catch (SQLException e) {
            throw new DatabaseExceptions(e);
        }
        
        return tabs;
    }

}

Kijkend naar de Clean Code principles, hier een opsomming van. Voldoet de code er tot zo ver aan. Ik gebruik hier geen dependencies maar het is wel volgens lower camelCase geschreven, er is geen onnodig commentaar en als functie heeft het maar een doel.

De code voldoet daarom ook de kwaliteitseisen in het PvA. Het maakt gebruik van SOLID via de Single Responsibility Principle, deze class heeft een taak en dat is dat de data van de tabbladen worden opgehaald. Het voldoet ook aan onze Definition of Done. Er is gecontroleerd of het is uitgewerkt in het SRS en SDD en of deze documenten overeenkomen. De code horen bij de usecase view data. Er zijn nog geen testen voor geschreven omdat we de nuttalk nog niet hebben gehad, zodra wij deze nuttalk hebben gehad zal deze class de nodige unit testen krijgen. Daarnaast hebben we het nog niet met Jenkins gekoppeld omdat wij als groep het nog niet werkend hebben gekregen. Komende sprint gaan we dat wel doen zodat alle code smells en bugs eruit worden gehaald.

Ik geef de code een goede voldoende.

Onderzoeksverslag

De onderzoeksverslagen die zijn gemaakt zijn competent opgesteld. We hadden al snel gezien welke software we zouden gaan gebruiken. Hierdoor kwam het onderzoek soms een beetje biased over wat niet zou mogen. Uiteindelijk was iedereen tevreden over de uitslag, ook de Erik onze opdrachtgever was tevreden met wat hij zag. Ik heb zelf meegewerkt aan het data visualisatie onderzoek. We hebben meerdere API's bekeken maar uiteindelijk was Google Charts het meeste uitgebreide voor wat wij wouden gaan doen.

Dit onderzoek bevat alle benodigde hoofdstukken. Inleiding, deelvragen en hoofdvraag, resultaten en conclusie. In de inleiding geven wij de achtergrond naar waarom wij het onderzoek gaan doen. Hieruit komen de hoofdvragen en bijbehorende deelvragen uit voort en deze vragen geven wij duidelijk antwoord. Uiteindelijk geven wij van elke API een lijst met voor- en nadelen die wij waren tegengekomen. Waaruit wij weer een uiteindelijke beslissing hebben gemaakt voor de uiteindelijke API.

Ik vind dit een prima onderzoek omdat het langs alle belangrijke vragen gaat en duidelijk antwoord geeft op de hoofdvraag.

Eindproduct

//komt nog

Evaluatie projectmethoden

In dit project wordt gebruikt gemaakt van SCRUM. Het werkt zeer fijn. Ik heb vorig project met RUP gewerkt maar ben van mening dat het manier van werken met SCRUM toch beter bij mij past. Aangezien je telkens een nieuwe stukje maakt in plaats van dat je alles 1 voor 1 maakt, zoals eerst documenten en dan home pagina etc.

Eerst wat pluspunten. Tijdens de sprints hebben wij usecases uitgewerkt, gekeken wat is beter kan en wat er mis ging en in volgende sprints dit opgepakt en meegenomen. Via de sprintreviews hebben we van de opdrachtgever goed vond en wat hij anders zou willen zien. Tijdens de retrospectives zijn we te weten gekomen wat er in de groep speelde en wat er beter kon, zodat we dit konden oppakken om zo beter als team te kunnen werken.

Wat RUP wel beter deed was dat je eerst volledige focust op documentatie zodat je niet direct bezig zou zijn met coderen. Dit gebeurde namelijk wel in de sprints, mensen begonnen massaal met coderen en vergaten een beetje dat er ook nog documentatie moest komen. Dan moet je nadat de hand alles aan het eind nog maken, dit geeft ook veel stress en is makkelijk te voorkomen. Bij RUP ben je de eerste 2 weken bezig met de documentatie zodat je eigenlijk al exact weet wat je gaat maken en niet voor verrassingen komt te staan.

Rollen

In mijn vorige project hebben ik gewerkt met RUP. Hierin had ik de rol van het bewaken van de Unit Testen, hierdoor moest ik weer even opfrissen welke rollen er ook als weer waren in de SCRUM methodiek. Scrum master ben ik nog niet geweest omdat we dit per sprint een iemand is. Ik ben in de laatste sprint aan de beurt en zal er dan ook meer over kunnen vertellen.

Tussen tijds

In een van de eerste gesprekken die we hadden we de opdrachtgever kwam al gauw naar voren dat hij liever alle communicatie via een persoon wou laten lopen zodat er geen informatie misloopt. Deze rol heb ik op mij genomen en zal dit ook blijven doen de sprint lang. Dit geeft ook meer kansen om mijn leerdoel van betere en heldere communicatie te versterken. Verder ben ik een teamlid geweest dat goed van zich laat horen zodat als er iets in mij opkomt, soms geeft dit nieuwe ideeën soms ook niet. Ik werk altijd graag op mezelf en ga andere niet snel storen. Mijn valkuil hierin is wel dat andere gauw overzicht kwijt zijn van waar ik nou mee bezig ben, hiervoor wil ik vaak tijdens de pauze met een beetje smalltalk laten weten hoe ik ervoor sta en waar ik mogelijk tegen aan ben gelopen.

Eindproduct

//komt nog

Competenties

OOSE P-03. De student onderzoekt voor het project relevant (technologie)keuzes en rapporteert hierover gestructureerd.

Ik heb een onderzoek gaan naar Data visualisatie en welke API wij gaan gebruiken om de data uit de sensoren te kunnen weergeven. Ik heb hierbij erg streng gekeken naar de eisen die de opdrachtgever heeft gesteld en die zijn beschreven in het PvA. Ik heb ene paar prototypes gemaakt en de voor- en nadelen onderbouwd en afgewogen. Mijn startpunt begon echt bij 0, ik had hiervoor nog geen ervaringen op gedaan met grafieken en de API's die het zouden kunnen doen. Hierdoor begon het zeer algemeen met wat er weergegeven moest worden. Daarna kwam het naar voren dat de opdrachtgever ook de data in realtime op de pagina wilt kunnen zien.

Uiteindelijk zijn we dus tot de conclusie gekomen dat de Google Charts API het beste was voor de doelstelling van Regterschot. Het deed alles wat Regterschot van ons vroeg en het had ook nog duidelijke documentatie om het te implementeren.
Aan het einde kwam mijn team wel nog dat ik vaak wat te kortaf schrijf, hierdoor leek het alsof ik niet altijd even goed bezig was. Dus voor volgende onderzoeken zal ik proberen meer uitgebreid te schrijven zodat dit niet meer zo opvalt.

OOSE P-08. De student kan zich zelfstandig verder verdiepen in de beroepstaak.

MIjn team had mij aangewezen om het dashboard te gaan maken. Nou had ik al wel wat gewerkt met Angular maar lang niet genoeg. Ik was begonnen met een korte introductie te maken van hoe angular in elkaar zit en nadat ik er enigs sinds bekend mee was ben ik begonnen aan het realiseren van het dashboard zelf.

Het dashboard moest bestaan uit verschillende grafieken waarin de data van de raceauto te zien was. Zodat de crew van de auto in een oogopslag kon zien wat er aan de hand was en of het nodig was om in te grijpen. Mijn doel was dus om de grafieken makkelijk in een overzicht te krijgen en dat je ze ook naar eigen smaak kon aanpassen en nieuwe kon toevoegen.

Ik heb gekeken naar verschillende manier om tabbladen op een webpagina toe te kunnen voegen zodat je als crew lid zelf de nodigen grafieken kan toevoegen op een tabblad en zo het overzicht makkelijker kan houden.

Leerdoelen

In eerdere projecten liep ik altijd wat meer op de achtergrond en liet ik weinig van mijzelf horen. Dit gaf een wat minder prettige werk omgeving omdat ik niet wist waar andere mee bezig waren en de andere wisten niet waar ik mee bezig was. Dit heeft ook een groot deel te maken met dat ik erg terughoudend ben en het liefst lekker rustig op mezelf aan het werken ben. 

Wanneer mensen niet weten waar iemand mee bezig is kunnen die personen langs elkaar op gaan werken. Dit zorgt voor een balansverstoring in het team en geeft vaak snel conflicten. 

Acties: 

• Ik ga mij opzetten als gespreksleider tijdens de gesprekken met de product owner. Hierdoor wil ik mijn gespreksvaardigheden bijwerken en verbeteren. 
• Voor dat de retrospective van het einde van de eerste sprint begint ga ik minimaal 2 tips bedenken voor mijn project genoten. Hierdoor kom ik voorbereider over en zal dit ook makkelijker gaan voor mij.
  
• Tijdens de tweede sprint ben ik vaker bij mensen geweest als ze vragen hadden zodat ze sneller weer verder konden. Zo wisten mensen waar ik mee bezig was maar wist ik ook waar hun mee bezig waren.

Tijdens het ISE-project hadden we weinig tot geen contact met onze productowner. We hadden in het begin van het project een gesprek met de productowner maar daarna waren er bijna geen gesprekken meer. Tijdens het volgende project wil ik dat er meer gesprekken gaan komen tussen productowner en het team. Hierdoor hoeven wij niet zo veel aannamen te doen en de productowner heeft ook een duidelijker beeld met hoever we zijn en wat hij uiteindelijk kan verwachten. 

Tijdens het ISE-project hadden we vaak de gesprekken die we hadden met de productowner niet goed voorbereidt. Daarnaast hadden we bijna geen gesprekken behalve de verplichte sprint reviews. Daarom wil ik tijdens dit project de productowner wat meer betrekken bij het project. Zo kunnen we tussentijds ook feedback krijgen en misschien zelfs nieuwe wensen in kaart brengen.

• Minimaal 1 keer in de week de productowner erbij pakken om de laatste functionaliteit te kunnen laten zien, zodat hij ook meer enthousiast wordt van het product.
• Als de gesprekken niet lukken om wat voor reden dan ook, stuur ik een korte heads-up met hoever we zijn en waar we momenteel mee bezig zijn.  

Kernkwadranten

Hieronder staan twee kernkwadranten. Dit zijn eigenschappen van mij wat ik niet heb aangeleerd, maar vormen op basis van mijn persoonlijkheid. 

Conclusie

Tussentijds

We lopen momenteel goed op scheme om een net en functionerend eindproduct op te leveren. Ik verwacht dat Regterschot aan het einde een product hebben waar ze goed mee kunnen werken. Verder gaat het halen van de competenties goed en ik verwacht hier weinig tot geen problemen mee te krijgen. De competenties die nog open staan zijn dingen die ik nog in de komende weken zal kunnen behalen. Voor mijn leerdoelen ben ik er al wel mee bezig maar voor het opstaan als gespreksleider laten mijn groepsgenoten weten dat er nog meters te halen vallen.

Om dit te kunnen halen ga ik me tijdens de DSU's wat actiever opstellen om zo meer gehoord te worden.

Eind

Factsheet

Bronnenlijst