Projectverslag

Auteurs:

Docenten

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.

2.4 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.

2.5 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.

3 Eindproduct

//komt nog

4 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.

5 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.

5.1. 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.

5.1. Eindproduct

//komt nog

6 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.

Ik heb een onderzoek gedaan naar ons CSS-framework dat wij gaan gebruiken bij het maken van onze web applicatie. Ik heb hierbij heel erg gelet op onze kwaliteitseisen die beschreven zijn in het plan van aanpak. Ik heb prototypes gemaakt en mijn uiteindelijke winnaar goed onderbouwd. Mijn startpunt lag denk ik net iets onder het minimale niveau. Zo waren bijvoorbeeld mijn deelvragen niet concreet genoeg voor een goed onderzoek. Ik heb hier opmerking over ontvangen van de reviewers en heb mij hierin verbeterd. Naast dit heb ik mezelf nog ontwikkeld in het krijgen van resultaat in een onderzoek. Ik vond dit lastig op het begin, maar na wat vragen stellen aan teamgenoten ben ik zelf op een oplossing gekomen voor dit probleem. Zo heb ik criteria opgesteld wat ervoor zou zorgen een winnaar uit de gekozen frameworks te vinden. Het niveau dat ik na het maken van dit onderzoek heb bereik is boven gemiddeld voor mijn gevoel en precies het niveau waar wij als groep naar streven voor een succesvol project. Dit denk ik omdat het verwerken van opmerking makkelijk ging en weinig moeite had met het rest van het document. Wel denk ik dat ik nog verbetering kan vinden op het gebied van conclusie schrijven. Dit was namelijk niet concreet genoeg en draaide een beetje om het punt heen. Dit is natuurlijk juist niet wat je moet doen in een conclusie.