De Opdracht¶
Dit is het project voor de leerroute BIM in semester 2 (2024 - 2025).
Wat je gaat doen?¶
In het tweede semester (blok 3 en 4) werk je in een team van meerdere studenten aan een project bij een echte opdrachtgever. Deze opdrachtgever heeft een probleem of uitdaging en roept jullie hulp in. Je gaat dit probleem analyseren en in overleg met de opdrachtgever bedenk je een oplossing waarbij je een SAAS applicatie ontwerpt en bouwt. Wat jouw groepje wordt en welke opdracht je krijgt, hoor je in de eerste week van jouw docent.
Wat ga je leren?¶
Dit semester ga je opnieuw aan de slag met het ontwerpen en realiseren van software en gebruikersinteractie. Hier komen wel een aantal nieuwe onderwerpen bij, zoals het goed testen van jouw applicatie. Nieuw in het tweede semester is dat we ook aan de slag gaan met infrastructuur. Voor BIM gaan we ook met de architectuurlaag organisatieprocessen aan de slag. Dat betekent dat we een nieuw proces gaan ontwerpen dat ondersteund wordt door onze oplossing. We gaan een implementatieplan schrijven en we gaan beschrijven hoe het straks beheerd gaat worden door de organisatie. Lees de leeruitkomsten dus goed door in de studiehandleiding op de DLO.
Learning stories en User stories¶
Tijdens dit project werk je weer aan learning stories. Daarin staan de te leren vaardigheden en competenties binnen dit project. Ze geven je houvast bij wat je moet leren. Via de DLO ga je deze opnieuw importeren in jouw persoonlijke Learning Journey.
In dit blok ben jezelf verantwoordelijk voor het opstellen van de user stories.
Wat is een user story ook alweer? Op scrumguide.nl vind je de volgende definitie: “Een User Story is een korte beschrijving (Story) van wat een gebruiker (User) wil. User Stories worden gebruikt bij het ontwikkelen van producten of software binnen Agile raamwerken, waaronder Scrum. Een User Story bestaat uit enkele zinnen waarin staat wat de gebruiker van het product moet / wil doen. Een User Story is eigenlijk weinig gedetailleerd en zou moeten kunnen passen op een post-it. Via de User Story heeft de gebruiker invloed op het ontwikkelen van een systeem of product en uiteindelijk de functionaliteit ervan.”
Een user story noteer je volgens een vast format: Als … (soort gebruiker) wil ik … (feature/actie), zodat … (doel/voordeel).
Een voorbeeld van een user story: “Als gamer wil ik met mijn ruimteschip kunnen schieten als ik op de spatiebalk druk, zodat ik vijandige aliens kan uitschakelen.”_
Milestones en sprintboard¶
- Je werkt in zogeheten sprints. Tijdens een sprint selecteer je de learning stories en de user stories van de Product Backlog die je wil gaan oppakken en afronden in 2 of 3 weken (de duur van een sprint in deze opdracht).
- Onder de pagina
Issues > Boards(te vinden via de balk links) vind je onder andere de volgende boards:- Product backlog;
- Sprint 1.
Om een user story toe te wijzen aan een sprint wijs je deze toe aan een Milestone. Dit kun je doen bij de eigenschappen van een user story Zie hiervoor wederom de pagina Issues. het eind van een sprint moet er altijd een bruikbaar product zijn voor de eindgebruiker. User stories die niet af zijn gaan door naar de volgende sprint. Test een user story dus goed voordat je deze op closed zet!
Definition of Done (DoD)¶
Binnen scrum dient iedere user story te voldoen aan een zogenaamde Definition of Done (DoD). Door het opstellen en aanhouden van een Definition Of Done, zorg je ervoor dat het werk wat je aflevert ook daadwerkelijk gebruikt kan worden. Als je een user story af hebt zet je ‘m in Verify en controleer je of deze voldoet aan de Definition of Done (zie hieronder). Pas als dat in orde is kun je de user story op Done zetten.
- Alle acceptatiecriteria van de betreffende user story zijn afgevinkt.
- Je hebt volgens de HBO-ICT werkstandaarden gewerkt (Agile, GitLab, sprint boards, sprint planning, HBO-ICT conventions etc.)
- Het werk is technisch gedocumenteerd in het Engels en relevant voor collega-ontwikkelaars. Denk o.a. aan ERD, UML, testen en testresultaten.
- Het leerproces is beschreven in Standaardnederlands.
- Het werk is gereviewd door een peer.
- Het UX/UI gedeelte van de applicatie voldoet aan het Think-Make-Check (TMC) principe.
- De code is functioneel getest op fouten.
- De code werkt zonder fouten bij normaal gebruik.
- De webapplicatie dient zowel op mobiele- als desktop-apparaten gebruikt te kunnen worden.
Kwaliteitscriteria¶
Voor het bouwen van deze opdracht heb je 2 x 3 sprints de tijd. Aan het einde van die periode moet je applicatie aan een aantal verwachtingen voldoen. We noemen dit de kwaliteitscriteria. Zie voor meer informatie de studiehandleiding 0p de DLO.
Hoe gebruik ik dit, documentatie¶
In de docs folder van de broncode zet je de technische documentatie. Belangrijk is dat de documentatie onderdeel wordt van de broncode. Zo kan je vanuit de ontwikkelomgeving documentatie bijhouden. Wat je geleerd hebt zet je in de docs van jouw Learning Journey.
Al het bewijsmateriaal neem je op in GITLAB zodat dat je daarna kan verwijzen vanuit een user of learning story en Scorion. Definieer daarvoor een folder structuur waarbij je rekening houd met sprints en dat een deel van het bewijsmateriaal per student is.
Zorg dat er in je GITLAB omgeving een beschrijving is van je project. Die moet je dus zelf maken want niet alle teams werken aan precies hetzelfde project.