Beschrijving Onderwijseenheid (OWE)

1. Inleiding

Deze OWE beschrijving (onderwijskundige eenheid) geeft voor de 'Minor DevOps' (MDO) de competenties, beoordelingscriteria en wijze van toetsing van alle courses en het project. Dit is een AIM norm; de OWE komt ook in het Onderwijs Statuut (OS/OER document). Een meer algemene introductie op deze minor staat op de home pagina van deze website.

De OWE is opgedeeld in secties. Deze hebben naast titel ook een nummer voor het overzicht. De eerste secties hebben geen subsecties omdat ze vrij kort zijn, maar verderop zijn er subsecties met subnummer.

Na deze inleiding volgen in sectie 2, 3 en 4 eerst de competenties van elk van de 3 courses in blok 2. In sectie 5 staan de competenties van het eropvolgende project in blok 2. In sectie 6 komen in subsecties de beoordelingscriteria bij elk van de competenties horen. Deze geven meer details. In sectie 7 volgt tot slot een overzicht van verschillende toetsen voor elk van de courses en toetsvormen en wegingsfactoren en dergelijke. Deze sectie geeft ook de mapping van de competenties en beoordelingscriteria naar de toetsen die deze.... toetsen en beoordelen :).

Tot slot in sectie 8 nog high level de onderwijsmaterialen en in sectie 9 een lijst van vereiste voorkennis voor toegang tot de minor (momenteel alleen ISM en developer profielen van HAN - AIM, in de toekomst wellicht breder toegankelijk voor HBO ICT studenten).

De publiek zichtbare variant van de OWE beschrijvingen is iSAS, hier de links:

2. DevOps competenties

In de 'DevOps' middencourse ontwikkelen alle studenten van de minor als het goed onderstaande competenties. Merk op dat achter elke competentie een kort woord of woord combinatie tussen haakjes staat. Hoewel hiermee niet de gehele zin (e.g. competentie beschrijving) gevat wordt in enkel dit woord, geeft dit wel kernachtig een kernbegrip weer van de competentie. Dit dient als ezelsbrug, ook wel 'mnemonic' genoemd (een concept uit assembly talen). Bij een aantal competenties is dit het DevOps 'buzzword'/thema van de verschillende geplande onderwijsweken (zoals 'Continous Delivery' of 'gitops'). Let wel deze mapping op de ezelsbruggetjes is wel enigszins grof. Zo komt de pipeline die centraal staat bij Continuous Delivery bijvoorbeeld in meerdere weken terug, met aspecten als toepassen van unit tests, automatische deploy etc. verdeeld/verspreid over meerdere lessen/weken.

  • DevOps-1 Je kunt goed samenwerken in een DevOps team en draagt bij aan het iteratief opleveren van nieuwe 'Cloud producten' (Continuous Delivery)
  • DevOps-2 Je kunt werken met versiebeheer centraal in de DevOps aanpak en kent en gebruikt bijbehorende workflows en CI/CD systemen (GitOps)
  • DevOps-3 Je kunt werken met containers, gangbare software architecuren vertalen naar een container architectuur en de principes van container orchestration toepassen (Containerization)
  • DevOps-4 Je kent de rol van testen, TDD en andere testaanpakken, kent DevOps security best practices, kan deze opvolgen en package managers gebruiken (DevSecOps)
  • DevOps-5 Je kunt goede logging en monitoring realiseren in verschillende omgevingen en zorgen voor applicatiespecifieke rapportages (SlackOps)
  • DevOps-6 Je kunt onderzoeksmethoden gebruiken en resultaten uit zelf verricht onderzoek, en dat van anderen toepassen in een beroepsproduct (Onderzoek)
  • DevOps-7 Je laat een nieuwsgierige instelling zien gecombineerde met een pragmatische aanpak en een positief kritische houding (Attitude)

3. Dev competenties (DevOps4Dev)

In de 'DevOps4Dev' schakelcourse leren de instromende 'developer' studenten onderstaande kennis en vaardigheden (e.g. competenties). Merk op dat voor het gemak de competenties codes de vorm 'Dev-x' hebben in plaats van het meer verbose 'DevOps4Dev-x'. Maar dit laatste zou wel correcter zijn.

  • Dev-1 Je kent de rol en functie van besturingssystemen en kent de basis van Linux server beheer en administratie (Linux)
  • Dev-2 Je kent voor DevOps relevante protocollen, netwerkstandaarden en security principes (Protocollen)
  • Dev-3 Je kunt kwalitatieve unit tests en automated acceptance tests schrijven en reviewen en ontwikkelen volgens Behaviour Driven Development (BDD)
  • Dev-4 Je kent een aantal basisprincipes van software design in het algemeen en Domain Driven Design in het bijzonder ((DD) Design)
  • Dev-5 Je kunt zelfstandig verdiepend onderzoek verrichten en de uitkomsten op een voor vakgenoten heldere manier verwoorden (Onderzoek)

4. Ops competenties (DevOps4Ops)

In de 'DevOps4Ops' schakelcourse doen de instromende 'operations' studenten onderstaande kennis en kunde op (e.g. competenties). Merk op dat analoog aan DevOps4Dev de competenties codes weer simpele vorm 'Ops-x' hebben in plaats van 'DevOps4Ops-x', hoewel dit laatste wellicht correcter zou zijn.

  • Ops-1 Je ontwerpt en ontwikkelt een DevOps-pipeline, zodat je beveiligingsrisico’s zo vroeg en effectief mogelijk kan signaleren en beheersen (DevSecOps)
  • Ops-2 Je valideert een DevOps-pipeline ten aanzien van prestatie-efficiëntie en betrouwbaarheid met methoden zoals performance testing, chaos engineering en monitoring. (Chaos engineering)
  • Ops-3 Je ontwerpt DevOps-structuren (zoals multi-project pipelines) ook op het hoogste abstractieniveau (architectuur), om zo de kwaliteit van softwarediensten in productie te optimaliseren. (quality)
  • Ops-4 Je ontwerpt en ontwikkelt volgens het ‘infrastructure as code’-paradigma. Je analyseert voor- en nadelen voor de opdrachtgever van het ‘infrastructure as code’-paradigma vergeleken met alternatieve paradigma’s zoals interactieve configuratie en geautomatiseerde configuration management.
  • Ops-5 Je kunt zelfstandig verdiepend onderzoek verrichten en van de uitkomsten op een heldere verslag doen zodat vakgenoten dit snel kunnen begrijpen (Onderzoek)

5. DevOps - Project competenties

N.B.: Richting 2023/2024 'multidisciplinair project' aangepast naar 'DevOps groepsproject met een authentieke opdrachtgever'

  • Project-1 Kan in de courses opgedane kennis en vaardigheden toepassen in een DevOps groepsproject met een authentieke opdrachtgever. #Vormbehoud
  • Project-2 Kan onderscheid maken tussen groepsbelangen en belangen inzake de eigen discipline. #Tshaped
  • Project-3 Gebruikt analyse- en onderzoeksmethodieken, -technieken en -gereedschappen en trekt gedegen conclusies uit bevindingen. #onderzoek
  • Project-4 Kan, gegeven een probleem, een beargumenteerde keuze maken over ontwerpbeslissingen. #Ontwerpdocumentatie
  • Project-5 Werkt methodisch en Agile bij het realiseren en/of inrichten van een gekozen oplossing. #Agile
  • Project-6 Communiceert helder over de resultaten van zijn/haar werk, toont aan onverwachte situaties te kunnen oplossen en kan reflecteren op en lering te trekken uit het multidisciplinaire project. #CommunicerenReflecteren

Bovenstaande wordt per minor per september 2024 gewijzigd naar:

  • MDO-Project-1 Kan de 'DevOps volwassenheid' van een gemaakt product en DevOps team aangeven aan de hand van een aangereikt DevOps maturity model #SelfAssessment
  • MDO-Project-2 Kan een door opdrachtgever aangereikte ontwikkelstack gebruiken en gebruik van extra technologieën goed afstemmen, beargumenteren en documenteren #DevOpsTechnology
  • MDO-Project-3 Kan Agile werken, een rol in een team invullen en ceremonies gebruiken om tot een steeds beter product en proces te komen #WayOfWorking
  • MDO-Project-4 Kan een staging én productie omgeving inrichten met bijbehorende pipelines, toenemende productkwaliteit en frequentie van opleveringen #BuildAndDeployment
  • MDO-Project-5 Kan een DevOps product documenteren met README's, software architectuur diagrammen met toelichting en een verzameling van gemaakte architectuur beslissingen #Documentatie
  • MDO-Project-6 Toont een professionele werkhouding door proactieve communicatie met opdrachtgever en begeleiders, een goede en onderling kritische werksfeer in het team en het maken van en zich houden aan afspraken #SoftSkills
  • MDO-Project-7 Heeft een nieuwsgierige houding, zet in courses opgedane kennis en vaardigheden pragmatisch in en bekwaamt zichzelf verder via onderzoek en kritische zelfreflectie #attitude

6.5.1 Project-1-1 Vormbehoud

  • Self assessment (CDMM checkpoints met toelichtingen + cijfer indicatie 5 hoofdcategorieën)
  • c. Build en Deployment (ontwikkelstraat, Azure DevOps, etc.)
  • Verantwoording eigen bijdrage: CI/CD pipelines, ontwikkelstraat, app configuratie, containerization, versiebeheer, monitoring, security, documentatie

6.5.2 Project-1-1 T-shaped

  • a. Technologie (techstack, devops tools, monitoring/metrics)
  • Verantwoording eigen bijdrage: broncode

6.5.3 Project-1-1 Onderzoek

  • Verantwoording eigen bijdrage: Onderzoek

6.5.4 Project-1-1 Ontwerpdocumentatie

  • d. Documentatie (C4, continuous documentation, ADR's, etc.)
  • Verantwoording eigen bijdrage: documentatie

6.5.4 Project-1-1 Agile

  • b. Way of Working (Scrum, Storymap, etc.)
  • Verantwoording eigen bijdrage: review, Agile werkproces

6.5.5 Communiceren en reflecteren

  • e. Soft Skills (effectief Agile werken, communiceren en presenteren aan technische+niet technische stakeholders)
  • Verantwoording eigen bijdrage: groepsproces, communicatie opdrachtgever en soft skills, leerervaringen en conclusies

6. Beoordelingscriteria per competentie

De subsecties 6.2 tot en met 6.5 geven voor elk van de competenties van elk van de 3 courses en het project de beoordelingscriteria die de competentie verduidelijken en beoordeeling concreter maken. Vanwege het DRY principe (Don't Repeat Yourself) zijn de competenties hierbij NIET herhaald. In 6.1 eerst een korte toelichting over nummering.

6.1 Toelichting sectienummers en nummering competenties en beoordelingscriteria

De nummering van subsubsecties met beoordelingscriteria hieronder komt overeen met de nummering van hoofdsecties met de bijbehorende competentie. Dus beoordelingscriteria in sectie 6.x.y horen bij de competentie in sectie x (bv. 6.3.x horen bij sectie 3). Dit is — mede — dankzij het invoegen van deze inleidende sectie 6.1 met een structuurbeschrijving. Dit is een soort interne 'leeswijzer'. Zonder dat het als een kopje 'leeswijzer' heeft, maar een meer inhoudelijke naam. Tip: Volg dit voorbeeld in het blog van je onderzoek (een toets)! Gebruik ook sectienummers en subsectienummers zoals hier om kortere interne verwijzing te (kunnen) doen. Gebruik NIET meer niveaus dan 3 (subsubsecties is diepste niveau, in analogie met Linus (Torvalds, z.d.) richtlijn in de Linux kernel coding style: "...if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."

Om de koppeling met de competentie duidelijk te maken hebben de beoordelingscriteria een subcijfer. Voor competentie DevOps-7 zijn bijvoorbeeld 3 beoordelingscriteria met code DevOps-7-1, DevOps-7-2 en DevOps-7-3.

NB Net als bij de competenties zegt de gebruikte volgorde van beoordelingscriteria niet per se iets over de volgorde van onderwerpen in de lessen.

6.2 DevOps beoordelingscriteria per competentie

De 5 competenties van de algemene 'middencourse' DevOps beschreven in sectie 2 mappen naar respectievelijke beoordelingscriteria opgesomd in de nu volgende sectie 6.2.1 tot en met 6.2.7.

6.2.1 DevOps-1 Continuous Delivery (Cultuur & Organisatie)

  • DevOps-1-1 Kent de Agile principes en kan uitleggen hoe DevOps in het verlengde hiervan ligt
  • DevOps-1-2 Vindt een eigen rol in een team, neemt hierbinnen verantwoordelijkheid en communiceert proactief binnen het team en naar buiten
  • DevOps-1-3 Kan helder, ondubbelzinnig en doelgroepgericht communiceren over Devops concepten, practices en producten zowel mondeling als schriftelijk
  • DevOps-1-4 Levert een DevOps product op iteratieve wijze op, en kan je bijdrage hieraan zelf onderbouwen
  • DevOps-1-5 Kent en gebruikt correct voor DevOps relevante concepten zoals MVP, product-increment, greenfield, brownfield en microservices
  • DevOps-1-6 Kent de grote cloud providers/platforms, de verschillende '... as a service' categorieen en het onderscheid tussen public en private cloud

6.2.2 DevOps-2 GitOps (Build & Deploy)

  • DevOps-2-1 Kan een CI/CD pipeline opzetten en configureren voor handmatige en automatische deployment naar meerdere omgevingen (OTAP)
  • DevOps-2-2 Kent de centrale rol van een versiebeheersysteem in DevOps en belangrijke GitOps concepten zoals push- vs pull model, reconcilliation en desired state
  • DevOps-2-3 Kan goed omgaan met een versiebeheersysteem (Git) en kent de principes hierachter en enkele advanced features ervan
  • DevOps-2-4 Kent enkele workflows voor teams in een VCS platform, methodes van 'trunk based development' en realiseert hiermee Continous Integration
  • DevOps-2-5 Kent Continuous Deployment strategieen zoals green-blue deployment, feature toggles en canary deploys en past één of meer toe

6.2.3 DevOps-3 Containerization (Design & Architectuur)

  • DevOps-3-1 Kent basisprincipes van testen, de testpiramide en kan geautomatiseerde tests uitvoeren en code coverage bepalen met een tool
  • DevOps-3-2 Kent best practices en principes voor Cloud applicaties en kan deze verifieren (12factor principes)
  • DevOps-3-3 Kan applicatie onderdelen 'containerizen' en onderling laten communiceren
  • DevOps 3-4 Kent de rol van netwerken bij containers, en principes van een load balancer, firewall en proxy en relevante protocollen/standaarden
  • DevOps 3-5 Kent de principes van een message broker en past er een toe in een multi-container applicatie
  • DevOps 3-6 Kent de basisprincipes van InfraStructure as Code en hoe dit past binnen de DevOps aanpak
  • DevOps 3-7 Kent de basisprincipes van Domain Driven Design en kan deze toepassen en toetsen in DevOps code, configuratie en documentatie

6.2.4 DevOps-4 DevSecOps (Test & Verificatie)

  • DevOps-4-1 Is security aware tijdens het realiseren van een DevOps product en houdt overzicht van zwakke plekken
  • DevOps-4-2 Kan containers scannen en vulnerabilities en security alerts opvolgen via updates m.b.v. een package manager
  • DevOps-4-3 Kent een aantal DevOps security best practices en past deze toe
  • DevOps-4-4 Weet wat CVE's zijn en de relatie leggen naar eigen code/product en gebruikte depdencies
  • DevOps-4-5 Kan evt. regressiefouten als gevolg van security update opsporen en uitsluiten in productie

6.2.5 DevOps-5 SlackOps (Information & Reporting)

  • DevOps-5-1 Kent best practices voor logging in een containerized omgeving en kent de integratiepunten van tools als Docker en Kubernetes
  • DevOps-5-2 Kan hardware gebruik in een container cluster monitoren en rapporteren en ook applicatiespecifieke monitoring toevoegen
  • DevOps-5-3 Kan directe rapportage in- en integratie met collaboratietools als bijvoorbeeld MS Teams, Slack of Discord realiseren

6.2.6 DevOps-6 Onderzoek

  • DevOps-6-1 Kan zich snel verdiepen in nieuwe DevOps technologieen in het verlengde van bestaande kennis en kunde en kan inschatten of verder onderzoek een goede tijdsinvestering is
  • DevOps-6-2 Kent onderzoeksmethoden voor praktijkgericht onderzoek en past deze toe in de realisatie van het beroesproduct
  • DevOps-6-3 Maakt gebruik van onderzoeksresultaten van anderen en jezelf, verantwoordt de kwaliteit van het onderzoek en geeft een correcte bronvermelding

6.2.7 DevOps-7 Attitude

  • DevOps-7-1 Bent pragmatisch, stelt zelf vantevoren een voldoende duidelijk einddoel en werkt hier naartoe, maar kunt je werk ook timeboxen en inschatten wanneer 'You ain't gonna need it'
  • DevOps-7-2 Bent positief kritisch op gebruikte bronnen, gemaakte specificaties, ontwerpen, producten en rapportages van jezelf en anderen
  • DevOps-7-3 Toont een kritische blik in verslaglegging, documenteert known issues en 'speelt op de bal; niet op de persoon'
  • TODO: DevOps-7-4 Werkt goed samen en fungeert als T-shaped professional zoekend naar verdieping in een of enkele onderwerpen, maar ook breed georienteerd op andere onderwerpen en overdracht van en naar teamgenoten

6.3 Dev beoordelingscriteria per competentie

Hieronder alle beoordelingscriteria voor de competenties van developers specifieke course beschreven in sectie 3.

6.3.1 Dev-1 Linux

  • Dev-1-1 Kan met behulp van command line/terminal navigeren op eigen systeem en externe Linux servers en systeeminformatie opvragen
  • Dev-1-2 Je kan containers debuggen via gebruik van standaard linux tools gebruiken en nieuwe tools installeren
  • Dev-1-3 Je kent de rol van Linux voor containers, en hoe containers op andere operating systemen draaien

6.3.2 Dev-2 Protocollen

  • Dev-2-1 Kan een load balancer instellen en configureren voor een container of container cluster
  • Dev-2-2 Kent het gebruik van het DNS protocol in containers en past deze toe voor container communicatie
  • Dev-2-3 Kan netwerk instellen en communicatie tussen verschillende netwerken mogelijk maken
  • Dev-2-4 Kent verdere voor DevOps relevante protocollen, implementaties hiervan en architecturele stijlen zoals RabbitMQ, etcd en REST

6.3.3 Dev-3 Behaviour Driven Development

  • Dev-3-1 Kent de BDD principes en tools en kan samen met eindgebruikers en/of niet ontwikkelaars requirements opstellen en uitwerken
  • Dev-3-2 Kent de relatie tussen TDD en BDD en kan de toegevoegde waarde van elk uitleggen
  • Dev-3-3 Kan hoge test coverage realiseren en aantonen en kent de waarde en beperkingen hiervan
  • Dev-3-4 Kent de principes van de test pyramide en past deze effectief toe in een DevOps omgeving

TODO: Evt. aanpassen, omdat we Dev-3 in 2021 in de DevOps course behandelden.

6.3.4 Dev-4 Design en Domain Driven Design

  • Dev-4-1 Kent de belangrijkste strategic patterns uit Domain Driven Design namelijk Ubiquitous Language, Bounded Context en Context mapping en past deze toe
  • Dev-4-2 Kent enkele tactical patterns uit DDD, namelijk Services, Entities, Value Object en het Aggregate pattern, en past deze toe indien mogelijk
  • Dev-4-3 Kan een software architectuur ontwerp documenteren met diagrammen en een duidelijke toelichting hierop geven met extra informatie en aandachtspunten

TODO: Evt. aanpassen, omdat we Dev-4-1 en Dev-4-2 in 2021 in de DevOps course behandelden, namelijk de InfoSupport workshops. Hier was ook aandacht voor Event Driven Architectures zoals CQRS.

6.3.5 Dev-5 Onderzoek

  • Dev-5-1 Verdiept zich zelfstandig in Devops concepten en nieuwe DevOps technologieen (tools, talen, frameworks of practices, principles, patterns)
  • Dev-5-2 Beschrijft onderzoeksresultaten helder, ondubbelzinnig, gestructureerd en doelgroepgericht
  • Dev-5-3 Selecteert bruikbare bronnen van derden en doet correcte bronvermelding

Merk op dat de de competentie en beoordelingscriteria voor Dev-5 en Ops-5 'onderzoek' identiek zijn.

6.4 Ops beoordelingscriteria per competentie

De competenties specifiek voor operations en infrastructuur en security studenten mappen elk ook naar een aantal beoordelingscritera in de volgende 5 subsecties.

6.4.1 Ops-1 DevSecOps

  • Ops-1-1 Je kunt security problemen oplossen via een update zonder een voor eindgebruikers merkbare verstoring
  • Ops-1-2 Je kan relevante security issues uit OS of middleware vinden met een tool of via handmatig doornemen van security rapporten
  • Ops-1-3 Je kan een update doorvoeren in een test omgeving en daar via (bestaande) tests bepalen of er regressie issues zijn
  • Ops-1-4 Je kent een techniek voor incremental rollout van de nieuwe applicatie versie en kan problemen hierbij monitoren
  • Ops-1-5 Je bent je bewust van mogelijkheden en onmogelijkheden bij oplossen van security issues en hoe hierover te communiceren met stakeholders en developers

6.4.2 Ops-2 Chaos monkey

  • Ops-2-1 Je kent de principes van chaos engineering en toegevoegde waarde hiervan
  • Ops-2-2 Je kunt een tool gebruiken om chaos engineering toe te passen in een containerized omgeving
  • Ops-2-3 Je weet hoe productie en QA/test omgeving zo te configureren dat chaos engineering effectief is

TODO '22: Competentie(s) rondom chaos engineering verplaatsen naar DevOps course, in ieder geval de conceptuele (e.g. Ops-2-1)

6.4.3 Ops-3 Quality Attributes

  • Ops-3-1 Je kunt de rol van System Quality Attributes in een software ontwerp beschrijven en voldoen aan deze requirements inzichtelijk maken met een DevOps aanpak
  • Ops-3-2 Je kunt met een orchestration tool als Kubernetes configuratie opzetten voor bijvoorbeeld autoscaling, Quality of Service en health checks
  • Ops-3-3 Je neemt verantwoordelijkheid voor non-functionele eisen van een applicatie en weet hoe deze te monitoren en verbeteren ook rekening houdend met kosten aspecten

6.4.4 Ops-4 Infrastructure As Code

  • Ops-4-1 Je kent de principes van IAC en kunt deze toepassen met behulp van een tool in een private of public cloud
  • Ops-4-2 Je kunt een nieuwe test of productie omgeving inrichten, uitrollen en documenteren voor gebruik door teamleden die weinig van IAC afweten
  • Ops-4-3 Je kunt in een bestaande applicatie InfraStructure As Code introduceren of stapsgewijs toewerken naar een meer 'cattle not pets' aanpak

6.4.5 Ops-5 Onderzoek

  • Ops-5-1 Je verdiept je zelfstandig in Devops concepten en nieuwe DevOps technologieen (tools, talen, frameworks of practices, principles, patterns)
  • Ops-5-2 Je beschrijft onderzoeksresultaten helder, ondubbelzinnig, gestructureerd en doelgroepgericht
  • Ops-5-3 Je selecteert bruikbare bronnen van derden en doet correcte bronvermelding

Merk op dat de de competentie en beoordelingscriteria voor Dev-5 en Ops-5 'onderzoek' hetzelfde zijn.

7. Mapping tussen toetsen en course- en projectcompetenties

Hieronder voor elk van de 3 courses en het project de beoordelingscriteria die deze specifiek toetsen. Ook andere gegevens als toetsvorm en deelcijfers.

Het verschil tussen beoordelingscriteria en deelcijfers is dat criteria vakinhoudelijk zijn, terwijl deelcijfers meer over de vorm of fasering gaan. Zo kennen de courses wekelijkse deeltoetsen die docenten of student assistenen afzonderlijk beoordelen, maar wiens gemiddelde cijfer een enkele toets vormt.

De deelopdrachten die je per week opbouwt commit je naar de je persoonlijke remote git repository (voor de week deadline!) zodat deze voor beoordelaar inzichtelijk zijn. Maar i.v.m. AIM standaarden en externe accreditatie moet je een verzamel .zip uit git van alle opdrachten op het eind van de course (en voor de deadline die in iSAS staat) ook uploaden in iSAS voordat je een cijfer kunt krijgen. Geen upload is geen beoordeling.

7.1 Toetsing Course DevOps (10 ECTS)

  • BP_Team Teamcijfer beroepsproduct
    • Toetsvorm: Beroepsproduct
    • Toetsvorm extra: DevOps product, inclusief team demo documentatie en individuele verantwoording schriftelijke en mondeling
    • Gewicht, grens: 60%, >= 5,5
    • Deelcijfers:
      • Kwaliteit en kwantiteit 'DevOps beroepsproduct' inclusief documentatie (aka 'product')
      • Duidelijkheid van Team demo van product en WIJ`E beantwoorden vragen
      • README + Documentatie
      • Team product review + self assessment
      • Kwaliteit en kwantiteit individuele werk
      • Duidelijkheid en aantrekkelijkheid toelichting/verantwoording individuele bijdrage
      • Toepassen onderzoek in BP met bronvermelding
      • Reflectie eigen functioneren mondelinge toelichting
  • Leeruitkomsten (percentage toetsmatrijs tussen haakjes):

    • DevOps-1 Continuous Delivery (15%)

    • DevOps-2 Containerization (14%)

    • DevOps-3 GitOps (14%)

    • DevOps-4 DevSecOps (14%)

    • DevOps-5 SlackOps (14%)

    • DevOps-6 Onderzoek (14%)

    • DevOps-7 Attitude (15%)

    • T_DevOps 2-wekelijkse theorietoetsen

      • Gewicht, grens: 40%, >= 5.5
      • Deelcijfers:
        • week 3, >= 4.0
        • week 6, >= 4.0
      • Leeruitkomsten (percentage toetsmatrijs tussen haakjes):
        • DevOps-1 Kent Continuous Delivery principes, concepten en tools (20%)
        • DevOps-2 Kent Containerization principes, concepten en tools (20%)
        • DevOps-3 Kent GitOps principes, concepten en tools (20%)
        • DevOps-4 Kent Orchestration en DevSecOps principes, concepten en tools (20%)
        • DevOps-5 Kent SlackOps principes, concepten en tools (20%)

    • Opdr_DevOps Wekelijkse huiswerkopdrachten DevOps

      • Toetsvorm Extra: Github commits + iSAS .zip
      • Gewicht, grens: Vink
      • Deelcijfers:
        • 5 weekopdrachten, allen vink, of gemiddeld voldoende
      • Leeruitkomsten (percentage toetsmatrijs tussen haakjes):
        • DevOps-1: Kan Continuous Delivery toepassen (20%)
        • DevOps-2: Kan Containerization toepassen (20%)
        • DevOps-3: Kan GitOps toepassen (20%)
        • DevOps-4: Kan Orchestration en DevSecOps toepassen (20%)
        • DevOps-5: Kan SlackOps toepassen (20%)

7.2 Toetsing Course Ops (5 ECTS)

  • T_Ops Gemiddelde van theorie(deel)toetsen Ops

    • Toetsvorm: 2 theorietoetsen digitaal
    • Gewicht, grens: 50%, >= 5.5
    • Beoordelingscriteria:
      • Ops-1 'DevSecOps: Alle beoordelingscriteria
      • Ops-2 'Chaos Engineering': Alle beoordelingscriteria)
      • Ops-3 'Quality Attributes': Alle beoordelingscriteria
      • Ops-4 'Infrastructure as Code': Alle beoordelingscriteria

  • Blog_Ops Blog n.a.v. onderzoek

    • Ops-5 (onderzoek)

  • Opdr_Ops Wekelijkse huiswerkopdracht Ops

    • Toetsvorm Extra: Github commits + iSAS .zip
    • Gewicht, grens: 50%, >= 5.5
    • Deelcijfers:
      • Week 2: Vink
      • Week 4: Vink
    • Leeruitkomsten (percentage toets matrijs tussen haakjes):
      • Ops-1: Kan DevSecOps toepassen (todo)
      • Ops-2: Kan Quality Attributes opstellen, realiseren en toetsen (todo)
      • Ops-3: Kan Chaos Engineering toepassen (todo)
      • Ops-4: Kan kan Infrastructure as Code toepassen (todo)

7.3 Toetsing Course Dev (5 ECTS)

  • T_Dev Gemiddelde van theorie(deel)toetsen Dev
    • Toetsvorm: Wekelijkse deeltoetsen
    • Gewicht, grens: 50%, >= 5.5
    • Leeruitkomsten (percentage toetsmatrijs tussen haakjes):
      • Dev-1 Linux: Alle beoordelingscriteria (50%)
      • Dev-2 Protocollen: Alle beoordelingscriteria (25%)
      • Dev-3 BDD: Alle beoordelingscriteria (0%)
      • Dev-4 (DD) Design/C4/Continuous Documentation: Alle beoordelingscriteria (25%)

TODO okt '21: Stof Dev-2+Dev-3 en Dev-4 behandelt tijdens DevOps les respectievelijk InfoSupport workshops en getoetst in DevOps deeltoets 2 (m.u.v. Dev-4-3 arch/doc. met C4 en Continuous Documentation en In Dev-2 moet RabbitMQ beter verwerkt in volgende editie) TODO sept '23: Stof micro front-ends moet nog een leeruitkomst bij, of verwerken in/herformuleren van Dev-4

  • Blog_Dev Blog n.a.v. onderzoek

    • Toetsvorm: Markdown commits + pdf iSAS
    • Gewicht, grens: 50%, >= 5.5
    • Beoordelingscriteria:
      • Dev-5 'Onderzoek': Alle beoordelingscriteria (100%)

  • Opdr_Dev

    • Toetsnaam: Wekelijkse huiswerkopdracht Dev
    • Gewicht, grens: Vink
    • Toetsvorm Extra: Github commits + iSAS .zip
    • Deelcijfers:
      • Week 2: Vink
      • Week 4: Vink
    • Leeruitkomsten (percentage toetsmatrijs tussen haakjes):
      • Dev-1: Kan Linux gebruiken (50%)
      • Dev-2: Kan relevante communicatie protocollen voor DevOps zoals DNS en RabbitMQ gebruiken (50%)
      • Dev-3: Kan Behaviour Driven Development toepassen (0%)
      • Dev-4: Kan software design lezen en Domain Driven Design toepassen (0%)

NB: Bij editie '21 zijn Dev-3 - BDD en Dev-4 - DDD getoetst en gedoceerd in DevOps toets en lessen, en was het 'protocol' RabbitMQ Exchanges (DNS, etcd. e.d. ook in DevOps). TODO voor '23/'24: Onderwerp Micro front-ends expliciet toevoegen. Missende inlevergelegenheid voor Wekelijkse huiswerkopdracht toevoegen in iSAS.

7.4 Toetsing DevOps Project (15 ECTS)

Beoordeling via beoordelingsmodel Projecten met 4 toetsmomenten:

  • 10% Tussentijdse beoordeling Beoordeling. Geen minimumscore. Bestaande uit:
    • groepscijfer, op basis van kwantiteit en kwaliteit Beroepsproduct en DevOps groepsproces, zie team beoordeling
    • Verrekenen van individuele 'delta' op basis van individuele verantwoording schriftelijk en presentatie en observaties begeleiders (knock-out bij duidelijk te weinig inbreng), zie individuele beoordeling
  • 90% Eindbeoordeling Beroepsproduct. Score minimaal een 5,5. Ook bestaande uit:
    • groepscijfer
    • en individuele delta of knock-out, zelfde als tussentijds

7.4.2 Toelichting afwijken reguliere AIM projectbeoordeling

De structuur met 4 toetsen tussentijds en eindcijfer en voor beide een groepscijfer en individuele beoordeling is hetzelfde als de reguliere AIM projectbeoordeling. Als minor vallen we hier niet onder, maar voor eenduidigheid is dit wel prettig.

De weging van cijfers gebeurt echter net anders, het eindcijfer is een optelling van groepscijfer en een individuele delta, eventueel negatief, of positief, maar doorgaans 0 (e.g. hele groep zelfde cijfer). De reguliere projectmethode gebruikt weegfactoren voor groepscijfer en individuele cijfer. Maar een vermenigvuldiging in plaats van simpele optelling van cijfers leidt tot minder intuitieve betekenis van delta. Want dit halveert voor het daadwerkelijke eindcijfer effectief de gegeven delta van de gekozen -1 tot +2 range naar de -0.5 naar +1 range.

Ook gelden groepscijfer en individueel niet beiden als knock-out voor eindcijfer, maar alleen de individuele cijfer. Dit kan door een negatieve delta waardoor je cijfer onder de 5,5 komt of het toekennen van de 1 of 4 absolute cijfers op basis van onvoldoende individuele bijdrage of verantwoording (e.g. knock-out). Dat een onvoldoende groepscijfer geen directe knock-out is, laat onverlet dat alle individuele teamleden verantwoordelijk zijn dit wel als signaal moeten zijn tijdig te communiceren met begeleiders en via samen bepaalde weg als team toch nog een groeps voldoende te behalen. Een eventuele neiging in zo'n situatie alleen voor de eigen individuele voldoende te gaan, zal leiden tot individueel alsnog onvoldoende beoordeling vanwege onvoldoende samenwerking en verantwoordelijkheidsgevoel. Als ondanks steken van voldoende aandacht hierin dit toch niet lukt, kan een evt. toegekende positieve delta evt. alsnog bepaalde groepsleden over de streep trekken.

8. Onderwijsmaterialen

  • Online lesoverzicht
  • Opdrachten via GitHub Classroom
  • Committen en samenwerken via AIM interne Gitlab: https://gitlab.devops.aimsites.nl.
  • Uploaden resultaten in iSAS
  • Reader DevOps - Ian Sommerville (alleen beschikbaar voor AIM/minor studenten)
  • Diverse Online documentatie tools (o.a. docker.com, kubernetes.io)
  • TODO: PluralSight (via XTend kortingsdeal AIM)

Aangeraden naslagmateriaal (e.g. leestips van de docent)

  • Boek Continuous Delivery, Jez Humble, David Farley
  • The Phoenix project, Gene Kim

8. Ingangseisen

De minor is alleen toegankelijk voor HBO ICT studenten met een development profiel.

Vanwege het verdiepende karakter van de minor moet je ook een 4-e jaars student zijn. We gaan er van uit dat je bij aanvang van de minor je (meeloop) stage en verdiepende semester hebt afgerond. Op het moment van inschrijven voor de minor is dit idealiter ook zo, of ben je je verdiepende semester of (meeloop)stage aan het afronden.

Inhoudelijk gelden verder de onderstaand eisen over je voorkennis en vaardigheden. Deze heb je nodig om tijdens de minor verder uit te bouwen of om mee te kunnen werken in het beroepsproduct aan het eind van de course fase en het DevOps project in blok 2.

Om ze te onderscheiden van de TIJDENS de minor opgedane competentie zijn de competenties codes hieronder voorzien van een V- prefix.

Edit juni 2023: Op dit moment staat deelname in deze minor niet open voor ISM (infratructuur) studenten. Mogelijk verandert dit voor editie in 2024 of later en er zijn naast V-Dev competenties ook V-Ops competenties opgesteld. Om verwarring te voorkomen hebben we deze verwijderd (en in versiebeheer gestald). Deze kennis en vaardigheden zijn nodig tijdens de courses, maar ook tijdens het project, om een voldoende product op te kunnen leveren.

9.2 Vereiste voorkennis Developers

  • V-Dev-1 Je kunt object geörienteerd programmeren in een getypeerde taal en kent enkele OO design patterns en kan deze herkennen en toepassen
  • V-Dev-2 Je kunt geautomatiseerde unit en integratie tests schrijven met gebruikmaking van een test framework en -tool
  • V-Dev-3 Je kunt ontwikkelen volgens Test Driven Development (TDD) en kent TDD patterns als Red-Green-Refactor, Arrange, Act, Assert en concepten als sut, mocks, stubs, etc.
  • V-Dev-4 Je kent de werking van web protocollen als HTTP en DNS en dataformaten als XML en JSON
  • V-Dev-5 Je kent de standaard 3-tier architectuur en principes van andere gelaagde architecturen
  • V-Dev-6 Je kent basis UML technieken en kan requirements en technische documentatie samenstellen

Bronnen

*Merk op dat we hier afwijken van standaard APA conventie van `Achternaam, voorletters'en gewoon 'Linus Torvalds' schrijven. Dit is vanwege het vaak informelere 'je' en 'jij' binnen de ICT en ook het fenomeen van rockstar developers e.d. wel verantwoord. Je mag hieruit opmaken dat afwijken van standaarden best mag, mits expliciet gemaakt en met een goede argumentatie en afstemming vantevoren. Belangrijkste punt is dat je laat blijken de standaard WEL kent en hebt overwogen. Stem dit dus af met evt. beoordelaars.

Last change: 2025-01-13