You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »



2)   Een onderbouwd oordeel over de kwaliteit van de geleverde deelproducten:

  • Op basis van meetbare kwaliteitscriteria

  • Er wordt gerelateerd aan het doel van het deelproduct

3) Een onderbouwd oordeel over de kwaliteit van het eindproduct als geheel:

  • Op basis van meetbare kwaliteitscriteria

4)  Een evaluatie van de gehanteerde  projectmethode:

  • Beschrijving van de belangrijkste  kenmerken van de methode

en vergelijking van het concrete project met de methode zoals beschreven in het PvA: werkte deze methode? Op welke punten wel/niet? Waarom?

5) Een beschrijving van de rol(len) die je hebt gehad in het project waarin je inzichtelijk maakt:

  • Wat die rol(len) inhield(en) in de praktijk, afgezet tegen de rolbeschrijving die in theorie, in het plan van   aanpak of je best practice was gegeven. Als je geen specifieke   rol/verantwoordelijkheid had beschrijf je hier in eigen woorden wat typisch was voor jouw bijdragen aan de samenwerking in het team
  • Situatiebeschrijvingen ter onderbouwing van je leerproces op dit gebied
  • Leerpunten voor een volgende keer dat jij deze rol zou moeten uitvoeren
  • In hoeverre deze rol jou op het lijf geschreven is, inclusief motivatie

6)   Een nadere toelichting op (zie projecthandleiding voor de competenties die in   jouw semester moeten worden toegelicht) competenties waarin per competentie:

  • Motivatie voor de keuze van de competenties (voor zover deze niet gegeven zijn in de projecthandleiding)
  • Situatiebeschrijvingen waarin je aangeeft wat je plan was, wat het resultaat en jouw concrete bijdrage daaraan   en wat dat vervolgens betekende voor het project als geheel, en wat jouw   inzichten waren
  • Jouw concrete bijdrage wordt ondersteund met 3 tot 5 verwijzingen naar onderliggend materiaal 
  • De verwijzingen geven inzicht in   de kwantiteit en kwaliteit van jouw bijdrage(n) op dit punt

7) Laat concreet zien hoe je gewerkt hebt aan je leerdoelen en hoe je gevorderd bent:

  • Situatiebeschrijvingen waarin je aangeeft wat je plan was, wat het resultaat en jouw concrete bijdrage   daaraan, en wat dat vervolgens betekende voor het project als geheel, en wat   jouw inzichten ten aanzien van je eigen functioneren waren.
  • Jouw concrete bijdrage wordt ondersteund met voldoende verwijzingen/links naar onderliggend materiaal 

8) Een conclusie die:

  • Aansluit op de inleiding
  • Aangeeft waar jij op dit moment staat ten opzichte van de competentie van jouw semester, gegeven je ervaringen   in het project en eventueel eerder in je studie..

9) De tekst voldoet aan de eisen zoals gesteld in de ICA-controlekaart en is maximaal 8 A4, of een vergelijkbare digitale hoeveelheid (dat is ca 4500 woorden, bijlagen niet meegerekend)

10) Een bijlage, de factsheet, met daarin per competentie:  (NB: dit is een van alle competenties, dus óók de links die je in het projectverslag hebt staan):

  • Links naar 3-5 specifieke bijdragen en een korte toelichting op jouw bijdrage
  • Uit de links moet blijken dat je voldoende kwantitatieve en kwalitatieve bijdrage hebt geleverd.


Inleiding

Het is de opdracht om een HR-portaal te ontwikkelen, het hoofddoel van het portaal is werkplaatsbezetting op te slaan, op basis opgeslagen gegevens wordt het declaratieformulier automatisch ingevuld. Daarnaast komen de mogelijkheden om verlofaanvragen te doen en handmatig te declaraties door te geven. Een van de inhoudelijke uitdagingen is kennis op doen van front-end technologie, het framework dat wij gaan gebruiken om het portaal te realiseren is Vue. Het is een framework dat is ontwikkeld door middel van JavaScript, van beide heb ik geen kennis bij aanvang van het project. Het is nodig om onderzoek te doen naar front-end technologie om mijn kennis uit te breiden op dit gebied. Voor het project heb ik twee leerdoelen, de eerste is dat ik de stappen ga visualiseren die mogelijk nodig zijn om een bepaalde functionaliteit te realiseren voordat ik begin met coderen. Zo heb ik een beter beeld van de nodige stappen zodat ik overzicht kan houden over het geheel. Mijn andere leerdoel is dat ik ervoor wil zorgen dat er zo min mogelijk misverstanden zijn bij op te leveren producten, als er misverstanden zijn doordat verschillende personen aan een taak gaan werken kan het voorkomen dat er onduidelijkheden zijn die niet worden besproken. Hierdoor gaat er tijd verloren als het blijkt dat er onderling misverstand is en de implementaties van elkaar afwijken. In het kort samengevat ga ik werken aan mijn vaardigheden om nieuwe onderwerpen te leren en groepscommunicatie vaardigheden.


Deelproduct: Toevoegen van werkplekken

Criteria

Criteria waarop er wordt beoordeeld zijn: User Interface (UI) en code kwaliteit. Als richtlijn worden de volgende criteria voor de UI aangehouden (https://lvivity.com/checklist-for-ui-testing)

  • Typography.

  • Style conformity.

  • The functionality use. .

  • Check the spelling.

Voor code kwaliteit worden de volgende criteria aangehouden: 

Oordeel

User Interface

De UI voldoet aan de grotendeels criteria Typograpy want, de text is duidelijk leesbaar t.o.v. de achtergrond, verder is het zichtbaar wat de hoofdzaak is van de pagina. Er zijn meer dan twee fonts gebruikt, om de kwaliteit te verbeteren moet ik de styling van de pagina aanpassen zodat er niet meer dan twee fonts worden gebruikt. De criteria Style Conformity voldoet grotendeels want, de wireframe en de uiteindelijke implementatie verschillen van elkaar. Om de User Experience (UX) te verbeteren heb ik het mogelijk gemaakt om de capaciteit te verhogen of te verlagen door middel van een druk op de knop, dit dekt de criteria The functionality use af. Anders had de gebruiker zelf de waarde moeten invullen. De input velden en opmaak komen wel overeen. Een ander verbeterpunt is de lege ruimte, hiervoor moet ik de opmaak aanpassen zodat er geen lege vlakken meer zijn. En als laatst is de spelling correct en voldoet de laatste criteria ook.

 Code kwaliteit

Het principe DRY waarborg ik door de v-for functionaliteit van Vue toe te passen. Hierdoor wordt er voor iedere werkplek de soort automatisch weergegeven. Als ik deze functionaliteit niet zou gebruiken zou ik handmatig een lijst moeten schrijven van alle werkplaats soorten (FIGUUR).

De code voldoet aan de volgende clean code principes: "Be consistent, If you do something a certain way, do all similar things in the same way", "use searchable names", "Functions do one thing", "Don't comment out code. Just remove". De code voldoet niet aan de Test principes uit de clean code principes.

 Eindoordeel

Als ik het product een cijfer zou geven op dit moment dan, geef ik een 6.5. De UI voldoet grotendeels aan de criteria die hiervoor gelden. De code kwaliteit is beoordeeld op basis van de principes die van toepassing zijn op de code, en voldoet de code aan een aantal principes. Na het verbeteren van de opmerkingen dan, is het mogelijk om van het cijfer een voldoende een goed te maken.


Oordel eindproduct

n.v.t. op het tussentijdse verslag.


Evaluatie gehanteerde projectmethode

A) Is de methode ideaal (zoals in het pva)

". . . Aan de hand van Scrum wordt iedere sprint een iets groter product opgeleverd, . . . Dit betekend dat het HR Portaal wat JDI Smart Web applications voor ogen heeft incrementeel tot stand zal komen. Alhoewel er vanaf het begin van het project door het team gekeken wordt naar de globale requirements, wordt bij elke individuele sprint echt vastgelegd welke use cases er na de desbetreffende sprint af moeten zijn. . . . Voordat het ontwikkelteam begint met de incrementele sprints, zal in de eerste week nog een globaal overzicht van het project worden gevormd aan de hand van overlegmomenten en doormiddel van dit Plan van Aanpak. Om dit project goed via Scrum te kunnen uitvoeren, zijn een aantal vaste momenten van belang. Ten eerste zal het ontwikkelteam dagelijks tussen 9:00 en 9:15 een daily standup houden. . . . kan er ook nog gekozen worden om een mid-daily standup te houden. Dit is hetzelfde als de daily standup, maar dan om te checken of iedereen die ochtend goed aan de slag is geweest en om een planning te maken voor de rest van de dag. Of er ook ruimte en belang is voor een mid-daily standup zal tijdens de eerste sprint duidelijk worden. Naast de daily standups zullen er tussen de sprints ook sprint planning en sprint retrospective ceremonies plaatsvinden. . . . Denk hierbij bijvoorbeeld aan het selecteren van de use cases die in de volgende sprint worden opgepakt. Ten slotte wordt er na iedere sprint ook een sprint review gehouden, . . . "

B) Praktijk gaat bij ons zo:....

Zoals omschreven houden we iedere morgen een daily standup, en is er in de eerste week een beeld gevormd van het op te leveren product. Na het overleg hebben we een vragenlijst doorlopen met de opdrachtgever om er zeker van te zijn dat er geen onduidelijkheden zijn. In de eerste week zijn we erachter gekomen dat het houden van een mid-daily standup niet nodig is op het moment, als iemand ergens mee klaar is geeft die persoon het aan en vertelt diegene aan welke taak de persoon gaat werken.

C) Werkt de methode? Zijn er verbeterpunten. Geef de verbeterpunten aan. Als het goed gaat maak van een 9 een 10

D) Geen verbeterpunten? Dat is geen optie, anders is dit onderdeel onvoldoende



Beschrijving rollen

Onderdeel 5) Project rollen

A) ideaal vs. praktijk

B) Leerproces omschrijven rondom de rol; Wat kan beter; Wat wil je leren in je rol

C) Situatiebeschrijving STARRT; Overal waar situatie staat. maak een STARRT formulier, dus volgens Sjir worden het er wel ongeveer 6 bij het eindverslag (smile)

Starrt mag in tabelvorm maar de voorkeur gaat uit naar een lopend verhaal.


Competenties

Onderdeel 6) Competenties

Verwijs naar factsheet. met een link naar het materiaal. Ook hier zijn situatie beschrijvingen ook van toepassing om je ontwikkeling aan te geven.


Leerdoelen

Onderdeel 7) Leerdoelen

A) geef een aanleiding voor het leerdoel; tekortkoming; kritiek uit je team; zelfreflectie uit vorig project; zelfkennis

C) Theorie uit boek of web (APA), wat aansluit bij je leerdoel.

D) SMART acties opstellen 2 stuks per leerdoel

E) STARRT per actie


de eerste is dat ik de stappen ga visualiseren die mogelijk nodig zijn om een bepaalde functionaliteit te realiseren voordat ik begin met coderen. Zo heb ik een beter beeld van de nodige stappen zodat ik overzicht kan houden over het geheel. Mijn andere leerdoel is dat ik ervoor wil zorgen dat er zo min mogelijk misverstanden zijn bij op te leveren producten, als er misverstanden zijn doordat verschillende personen aan een taak gaan werken kan het voorkomen dat er onduidelijkheden zijn die niet worden besproken. Hierdoor gaat er tijd verloren als het blijkt dat er onderling misverstand is en de implementaties van elkaar afwijken. In het kort samengevat ga ik werken aan mijn vaardigheden om nieuwe onderwerpen te leren en groepscommunicatie vaardigheden.


Leerdoel 1: Visualiseren

aanleiding

gedragscompetenties

  • Schriftelijke uitdrukkingsvaardigheid
  • Samenwerken
  • Plannen en organiseren
  • Creativiteit
  • Leervermogen
  • Probleemanalyse
  • Stressbestendigheid

theorie over hoe visualiseren kan helpen

2 SMART acties


Leerdoel 2: Misverstanden voorkomen bij het voorbereiden van een product.

aanleiding

gedragscompetenties (http://www.van-osch.com/lipoweb/opr0.htm)

  • Luisteren
  • Mondelinge presentatie
  • Groepsgericht leiderschap
  • Voortgangscontrole
  • Durf

theorie over hoe visualiseren kan helpen

2 SMART acties

  • De vaardigheid Luisteren, Samenvatten, Doorvragen (LSD) toepassen als ik het idee heb dat er enigszins onduidelijkheid heerst in het gesprek.
  • Het opstellen van documentatie als er meerdere groepsleden aan een deelproduct werken.


comm front→backend → START vooraf afspraken maken


te lange discussie tijdens het planningspoker


Afsluitend spel voor teambuilding en afschakeling



  

  • No labels