Opleiding: Softwarekwaliteit in het tijdperk van open source, outsourcing en AI

Lesmethode :

Klassikaal

Algemeen :

Tijdens deze cursus leer je de kwaliteit en veiligheid van software beoordelen, ook wanneer de code door leveranciers of AI is geschreven. Je bekijkt welke controles nodig zijn tijdens de ontwikkeling, bij oplevering en tijdens het onderhoud. Daarmee herken je eerder beveiligingsrisico's en problemen die de software moeilijker te onderhouden maken.

Je kijkt naar de volledige levenscyclus van software door vier verschillende lenzen: functionaliteit, security, architectuur en governance. We behandelen hoe je risico's in kaart brengt via threat modelling en welke rol tools als SAST, DAST en SBOM spelen bij het bewijzen van kwaliteit. Je bespreekt hoe wijzigingen de samenhang tussen softwareonderdelen kunnen verstoren en hoe je dat voorkomt. Daarbij is er aandacht voor wat je automatisch kunt controleren en wanneer menselijke beoordeling nodig blijft.

Aan de hand van een doorlopende casus analyseer je software die is ontstaan uit een mix van intern werk, externe leveranciers en AI-agents. Je oefent met het herkennen van assurance-gates en bepaalt welke maatregelen proportioneel zijn om risico's te beperken. Deze werkwijze helpt je om in je eigen werk gerichte vragen te stellen over softwarekwaliteit en te onderbouwen waarom je code wel of niet accepteert.

Doel :

Na deze cursus kun je systematisch bewijs verzamelen over de kwaliteit en veiligheid van software, ongeacht of deze intern, via partners of door AI is geschreven.

Doelgroep :

Softwareprofessionals die de kwaliteit van groeiende codebases willen bewaken, zoals softwareontwikkelaars, architecten, QA-engineers en Dev(Sec)Ops-experts.

Voorkennis :

De volgende voorkennis is vereist:
- Ervaring met softwareontwikkeling of kwaliteitsbewaking
- Basisbegrip van de software development lifecycle (SDLC)
- Het cursusmateriaal is in het Engels, een goede beheersing van de Engelse taal is vereist.

Onderwerpen :

- Introduction
+nbsp;+nbsp;+nbsp;- Growth in code volume, maintenance burden, and verification debt
+nbsp;+nbsp;+nbsp;- Code provenance: in-house, outsourcing, open source, and GenAI
+nbsp;+nbsp;+nbsp;- Software assurance as a system of evidence and feedback
- Plan
+nbsp;+nbsp;+nbsp;- Risk classification, ownership, and accountability
+nbsp;+nbsp;+nbsp;- Quality objectives, definition of done, and GenAI policy
+nbsp;+nbsp;+nbsp;- Supplier governance, maintenance, and phase-out
- Specify
+nbsp;+nbsp;+nbsp;- Testable functional and non-functional requirements
+nbsp;+nbsp;+nbsp;- Security, privacy, performance, misuse cases, and abuse cases
+nbsp;+nbsp;+nbsp;- Acceptance criteria and traceability for humans, suppliers, and agents
- Design
+nbsp;+nbsp;+nbsp;- Modularity, coupling, cohesion, and architectural decisions
+nbsp;+nbsp;+nbsp;- Trust boundaries, data flows, and threat modelling
+nbsp;+nbsp;+nbsp;- Secure by design, reference architectures, and early debt prevention
- Develop
+nbsp;+nbsp;+nbsp;- Coding standards, peer review, and manageable changes
+nbsp;+nbsp;+nbsp;- SAST, linting, secret detection, and dependency selection
+nbsp;+nbsp;+nbsp;- Unit tests and repository instructions such as AGENTS.md and RULES.md
+nbsp;+nbsp;+nbsp;- Generated and outsourced code treated as untrusted contributions
- Verify
+nbsp;+nbsp;+nbsp;- Test portfolio: unit, integration, contract, system, and end-to-end testing
+nbsp;+nbsp;+nbsp;- Positive, negative, exploratory, and security testing
+nbsp;+nbsp;+nbsp;- Coverage, mutation testing, DAST, and fuzzing
+nbsp;+nbsp;+nbsp;- False positives and negatives, false confidence, and agentic QA
- Release & Deploy
+nbsp;+nbsp;+nbsp;- CI, quality gates, SCA, and CVE prioritisation
+nbsp;+nbsp;+nbsp;- SBOM, build provenance, artifact integrity, and configuration validation
+nbsp;+nbsp;+nbsp;- Release evidence, risk acceptance, rollback, and supplier acceptance
- Operate & Maintain
+nbsp;+nbsp;+nbsp;- Observability, incident response, patch management, and vulnerability management
+nbsp;+nbsp;+nbsp;- Dependency updates, regression testing, and architectural erosion
+nbsp;+nbsp;+nbsp;- Technical debt, knowledge loss, ownership, and use of the SBOM
+nbsp;+nbsp;+nbsp;- Feedback from operations into planning, requirements, and design