Aanscherpen template kwaliteitsplan

[Sebastiaan127001]

• [x] consistente velden. Voor sommige termen zijn er velden met verschillende veldnamen zoals: {beheerpartij} en {beheerorganisatie} en {opdrachtgevende organisatie} en {opdrachtgever}. Graag consistenter maken zodat het makkelijker in te vullen is
• [ ] kwaliteitsmanager ICTU staat als reviewer van het KP terwijl deze ook de auteur is
• [x] ipv overal {naam} vanvangen door {naam product owner} en {naam kwaliteitsmanager} zodat het makkelijker is aan te passen
• [ ] Wijzig de titel van Kwaliteitsplantemplate naar Kwaliteitsmanagementplantemplate omdat het eerste lijkt te impliceren dat het plan van kwaliteit is terwijl het eigenlijk een plan is hoe we de kwaliteit gaan managen voor dit project. Vervang alle andere documenten (inclusief diagram).
• [x] vervang alle instanties van 'pull request' voor 'merge request' het verzoek is namelijk om het samen te voegen met de main
• [ ] bij paragraaf 5.3.1 opnemen aan welke codeerstandaarden men kan denken, bijvoorbeeld PEP-8 voor Python. Zie comment @Sebastiaan127001 hieronder.
• [ ] bij 2.4 uitgangspunten opnemen waar men nog meer aan kan denken, bijvoorbeeld, KP van ICTU is gebaseerd op KP van OG, er wordt gewerkt volgens een specifieke kwaliteitsstandaard (bijv. ISO 9000).
• [ ] In het NFE is sprake van het toewijzen van eisen aan software, hardware of een combinatie daarvan, maar in de inleidende tekst en de leeswijzer is ook sprake van applicatie en infrastructuur. Maak de termen consistent. En vertel ergens dat systeem = hardware/infra + software/applicatie. Voeg voetnoot toe aan de eerste tabel met een verwijzing naar de leeswijzer.
• [ ] Maak de pagina's met eisen in het NFE-template landscape zodat de tabellen beter bruikbaar zijn.
• [ ] In hoofdstuk 5 toevoegen: voorstel om reactietijden (uit Qt) op te nemen in paragraaf 5.2.1: Desired metric response times (de tijden waarop het team moet reageren op meldingen vanuit het kwaliteitssysteem ( wanneer de afgesproken grenswaarden worden overschreden, wanneer ze bijna worden overschreden (near target met), en ook wanneer er geen beeld is (status white) en de oplostijd van geaccepteerde technische schuld (grey). Desired time after which to review measurement entities (violations, warnings, issues, etc.); individuele deelresultaten (entities) van metrieken kunnen apart een status krijgen. Hierop moet het team een reactietijd afspreken.
• [ ] Onder H 5.13 Technische Schuld een paragraaf opnemen over de afspraken hoe het ontwikkelteam (met KM) hiermee omgaat: 1) het onderdrukken van meldingen wordt gedaan door het team / de kwaliteitsmanager 2) bv suppressed warnings in SonarQube, duplicate code exclusion in SonarQube, regels uitsluiten/uitzetten in SonarQube, suppression in OWASP dependency-check
• [ ] Overwegen om hoofdstuk 5 los te trekken omdat dit gaat over teamafspraken. En in h5 dan een duidelijk onderscheid tussen generiek (ICTU KA) en speciefiek (teamafspraken zoals DoD en DoR). Idee: Powerpoint met de samenvatting van de DoR, DoD, codeerstandaarden, linters en formatters, review/merge policy, reactietijden en measurement entities management.
• [ ] Linters/quality checks voor testcode (bijv. RoboCop, RoboTidy, Pytest-plugins?).

Apart issue van gemaakt:

• [ ] #861

[AukeBloembergen]

• [ ] Alg: Tekst moet niet voorschrijvend zijn (zoals KA), maar beschrijvend (zoals voorgenomen door het project)
• [ ] Eigen tijd voor ICTU om kwaliteit te leveren expliciet in KP opnemen
• [ ] Toevoegen Referentieapplicatie?

[Sebastiaan127001]

@fniessink hierbij:

Beyond PEP-8, there are several other coding standards and style guides for different programming languages and contexts. Here are a few notable examples:

Google Style Guides: Google has published style guides for various languages, including C++, Java, Python, Go, JavaScript, and others. These are used internally at Google but are publicly available and widely respected in the industry.

Airbnb JavaScript Style Guide: A very popular style guide for writing consistent JavaScript code. It covers naming conventions, best practices, and patterns to follow.

Microsoft's C# Coding Conventions: Part of Microsoft's documentation, these conventions cover the coding styles for C# programming, including naming conventions, layout conventions, and commenting conventions.

Oracle's Java Code Conventions: Though somewhat dated, Oracle's Java code conventions were long considered the standard for Java coding practices, covering file organization, indentation, comments, declarations, and more.

The Rust Programming Language Style Guide: The Rust community follows an official style guide (fmt) for formatting Rust code, which helps in maintaining consistency and readability across Rust codebases.

Kotlin Coding Conventions: Published by JetBrains, the company behind Kotlin, these conventions cover the coding practices recommended for Kotlin programming, including naming, formatting, and structuring code.

PSR-1 and PSR-2 for PHP: The PHP-FIG (Framework Interop Group) has published several PHP Standard Recommendations (PSRs), among which PSR-1 (Basic Coding Standard) and PSR-2 (Coding Style Guide) are focused on coding standards and styles for PHP.

PEP-257 for Python Docstrings: While PEP-8 focuses on the code style, PEP-257 provides conventions for writing good Python docstrings, which are essential for documentation.