De opdracht deel 2¶

Dit is het project voor de leerroute BIM in blok 4 (2023 - 2024).

De opdracht deel 2

Wat je gaat maken¶

In blok 1 heb je als trainee bij ZMARD gewerkt aan Dokkie. In het tweede blok ben je uitgedaagd om als ondernemer samen met een andere student een zogenaamde Software as a Service (SaaS) oplossing te bedenken en te bouwen voor kleinere bedrijven. Na een kort onderzooek had je het idee welke je hebt uitwerkt in een business plan. Gelijktijdig heb je een “Minimum Viable Product”, gebouwd dat je gebruikt hebt om feedback te krijgen van potentiële klanten. Het blok is afgesloten met een Dragon’s Den meeting.

In het tweede semester (blok 3 en 4) werk je in een team van zo’n 4 studenten aan een project waarbij je een SAAS oplossing ontwerpt en bouwt. Dit kan zijn het ontwikkelen van een SaaS product voor ons eigen bedrijf ZMARD; een nieuw project voor een externe opdrachtgever of een project dat je als team zelf hebt bedacht en succesvol hebt “gepitched” in blok 2. In dit blok 4 lever je dit product op. Je maakt tevens de ontwikkel infrastructuur af en werkt daarmee. Bij het opleveren van het product hoort ook de implementatie en service. Hiervoor maak je als team een plan. Individueel doe je onderzoek naar een deelontwerp en lever je een rapport hierover op.

Wat ga je leren?¶

Dit blok ligt de focus vanuit de leerroute BIM op Organisatie Processen en in het bijzonder in het implementeren daarvan. Welk proces gaat jullie product ondersteunen? Je leert dit proces in kaart te brengen en met een opdrachtgever te communiceren. Verder borduur je voort op alle techniek die je al kent. Je verdiept je kennis op het vlak van Software en Gebruikersinteractie. Je apolicatie bouw je weer met Flask. Dit blok verdiep je je verder in de cloud Infrastructuur. Je SAAS oplossing moet namelijk ook ergens live komen te staan. Nieuw in dit blok is het doen van onderzoek. Dit blok ga je ook in een echt SCRUM team werken. Dus verdiep je je kennis over samenwerken, de sprintplanning en kwaliteitscontrole.

Learning stories en User stories¶

Tijdens dit blok 4 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. Je vindt ze samen met de user stories onder `Issues > Boards > Backlog.
In dit blok ben jezelf verantwoordelijk voor het opstellen van de user stories. Als hulpmiddel hebben we per sprint aangegeven welke stappen je zou moeten doorlopen om het prodcut daadwerkelijk aan het eind van blok op te kunnen leveren. Iedere user story bevat een aantal acceptatiecriteria en taken, die je houvast geven bij het bouwen. Je wordt geacht met het team volgens de SCRUM normen user stories op te zetten en af te ronden.

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). In totaal zijn er 3 sprints. Om een user story of learning story toe te wijzen aan een sprint wijs je deze toe aan een Milestone. Dit kun je doen bij de eigenschappen van een issue. Je kan hiervoor ook het board Sprint 1 gebruiken.
Onder Issues > Milestones > Sprint 1 kun je de burndown van de eerste sprint zien, wat er voor de sprint gepland staat, waar je mee bezig bent en wat af (done) is.
Sprint 1, duurt 2 weken en loopt van 15 april - 28 april
Sprint 2, duurt 3 weken en loopt van 6 mei - 26 mei
Sprint 3, duurt 3 weken en loopt van 27 mei - 16 juni
Boards
Onder de pagina Issues > Boards(te vinden via de balk links) vind je onder andere de volgendev boards:
- Product backlog met alle user stories en learning stories;
- 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. Aan 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!

Planning gehele project: sprint doelen¶

In dit blok ga je met je team het project afronden: jullie leveren jullie applicatie op. Dat behelst meer dan alleen een link naar de code opsturen. Daar komt ook een implementatieplan, een service management plan en een geteste applicatie die draait in de cloud bij. Hoewel je in SCRUM per sprint bepaald wat er wel/niet wordt gemaakt, stellen we de volgende sprint doelen voor:

Sprint 1: De applicatie draait in de ontwikkelomgeving. De benodigdheden voor de oplevering zijn uitgezocht. Alle user stories zijn beschreven. Elke student is begonnen met het indiviudele onderzoek.
Sprint 2: De applicatie is getest en draait in de ontwikkelomgeving. De live omgeving is omschreven. De eerste versie van alle plannen voor de oplevering en de periode daarna zijn door experts bekeken.
Sprint 3: De applicatie draait live en is gedocumenteerd. Het team levert de applicatie en alles wat daarbij hoort op aan de organisatie. Het individuele onderzoek is afgerond en opgeleverd.

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. Jullie kunnen overwegen om de criteria te copieren naar elke user story.

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 3 sprints de tijd. Aan het einde van die periode moet je applicatie aan een aantal verwachtingen voldoen. We noemen dit de kwaliteitscriteria. Voor dit blok zien de kwaliteitscriteria er als volgt uit:

Cat	Nr	Kwaliteitscriteria	HBO-i model
1	K1	Je hebt object georiënteerde software gemaakt die samenwerkt met een database.	S-O, S-R, S-MC
1	K2	Je hebt de wensen en behoeften van gebruikers verwerkt in een goed doordacht prototype.	G
1	K3	Je hebt een infrastructuur ontworpen en gebouwd volgens zelf-gedefinieerde vereisten.	I
2	K4	Je kan eenvoudig(e) organisatieprocessen, gegevensstromen, databehoeften en procesbesturing realiseren	O-R
2	K5	Je kan een eenvoudig(e) organisatieproces, organisatie, gegevensstroom, databehoefte en procesbesturing managen en beheersen	O-M&C

Gedragscriteria¶

Om een IT-project succesvol op te leveren, is het noodzakelijk dat je leert om je als een professional te gedragen. Je hebt hiervoor vaardigheden nodig, die we binnen het hbo professional skills noemen. Voor dit project dient je gedrag aan de volgende criteria te voldoen:

Cat.	Nr	Gedragscriteria	HBO-i model
3	G1	Je blijft leren en werkt doelgericht.	Persoonlijk leiderschap
4	G2	Je werkt constructief samen en stemt je mondelinge- en schriftelijke communicatie af op het doel (een onderzoeksverslag) en de doelgroep.	Doelgericht interacteren
4	G3	Je herkent ethische aspecten en maatschappelijke gevolgen van de opdracht en maakt hierin bewuste keuzes.	Toekomstgericht organiseren
4	G4	Je doet methodisch onderzoek en analyseert de uitkomsten. Vanuit deze analyse concludeer je wat de beste oplossing van een probleem is.	Onderzoekend probleemoplossen

Lesmateriaal¶

In de learning stories en user stories staan verwijzingen naar het lesmateriaal.

HBO-i¶

Binnen deze opdracht ligt de focus op de volgende architectuurlagen:

Software (S) : niveau 1
Gebruikersinteractie (G) : niveau 1
Infrastructuur (I): niveau 1
Organisatieprocessen: niveau 1

Binnen deze opdracht ligt de focus op de volgende professional skills:

Persoonlijk leiderschap (PL) : niveau 1
Toekomstgericht organiseren (TO) : niveau 1
Doelgericht interacteren (DI) : niveau 1
Onderzoekend probleemoplossen (OP) : niveau 1

Een overzicht van alle competenties vind je hier.

Hoe installeer ik het?¶

Dit blok ga je verder met de code van het project uit blok 3. Die code ga je integreren met dit blok 4 project in Gitlab. Daar staan namelijk de user stories en learning stories in. De installatie is daarom anders dan in blok 3.

Dit is dan ook een mooi moment om de code van het project op te schonen en alleen de werkende main branch te importeren.

Voorbereiding¶

Als er nog verschillende branches zijn met code die over moet naar blok 4: merge die branch in blok 3.
Los eventuele merge conflicten op.
Bepaal als team of de code nu compleet is>
Doe een laatste check of alles in de main branch zit.
Zorg dat de main branch uit gecheckt is.

Overnemen van de code uit blok 3¶

Controleer of alle teamleden toegang hebben tot het blok 4 project.
De SCRUM Master maakt nu een clone van dit blok 4 project. Zo maak je dus een nieuw project (folder) aan in VSC.
De SCRUM Master opent een bestandsbeheer programma (File Explorer bijv) via VSC (rechts klikken op de project map). De locatie van het blok 4 project is nu geopend in een explorer.
De SCRUM Master opent nu het project 3 in VSC. Open wederom een bestandsbeheerder, maar nu van het blok 3 project, via VSC. Er zijn nu twee bestandsbeheerders open.
Selecteer alle bestanden, behalve de (verborgen) directory .venv en .git en de \docs map.
Kopieer alle code bestanden, dus zonder deze drie directories, van het blok 3 naar het blok 4 project.
Controleer of de bestanden compleet zijn in blok 4.
De SCRUM master doet nu 1 commit in de main branch met als comment ‘import blok 3 code’

In blok 3 zaten ook de infra-docker-compose bestanden in de docs map. Kopieer die nu ook. Die heb je nodig om lokaal dus op je eigen laptop, een netwerk te bouwen zodat de losse onderdelen van jullie applicatie (webapp, database, etc) met elkaar kunnen praten.

Optioneel: Oefenen met merges en branches¶

Als je als team nog niet echt soepel werkt met merges en branches in GIT: hieronder staat de opstart oefening.

Maak een clone van het project. Ieder lid 1
Iedereen met een clone van dit project moet controleren of de volgende bestanden de juiste naam hebben, en zo nodig hernoemen:
gitignore -> .gitignore (indien nog niet voorzien van een .)
dockerignore -> .dockerignore (indien nog niet voorzien van een .)
Het lid met de rol SCRUM master gaat nu een git branch maken in VSC. Geef de branch een duidelijke naam, bijvoorbeeld dev. Maak een nieuw bestand aan in docs en commit. Let op dat je nu commit in de branch die je zojuist hebt aangemaakt. De SCRUM master pushed hem naar Gitlab.
Controleer op Gitlab of deze nieuwe branch zichtbaar is.
Alle andere leden doen nu een pull, oftewel ze halen de wijzigingen van Gitlab op.
Alle leden doen een checkout van deze nieuwe branch. Controleer of je het nieuwe bestand ziet.
Maak nu een merge request aan op Gitlab en voer de merge uit. Controleer of er nog maar 1 branch is: main.
Alle leden doen een sync en checkout van de main branch.
Zorg ervoor dat iedereen in een eigen branch werkt; gebruik voor die branch bijvoorbeeld de naam van de betreffende blueprint. Werk niet in main maar maak alleen merge requests aan naar main toe.

Koppelen database¶

Mocht dit nog niet gebeurd zijn: Lees de omschrijvingen en verander alle VARIABELEN, dus de variabelen in HOOFDLETTERS. Zie verder blok 2.

Blueprints¶

Als je team de verschillende funcionaliteiten nog niet in blueprints heeft opgezet, doe dit dan nu. Bepaal samen met het team en de docent welke blueprints jullie nodig hebben.

Het GITLAB spel¶

Leren wat GITLAB is? Speel dan het spel hier.

Hoe gebruik ik dit, documentatie¶

In de docs folder van de broncode zet je de technische documentatie én beschrijf je wat geleerd hebt. Belangrijk is dat de documentatie onderdeel wordt van de broncode. Zo kan je vanuit de ontwikkelomgeving documentatie bijhouden. 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.