Block A — QA_Lernwebseite (Unterordner im Monorepo qa-ctfl-track · Statisches Web-Projekt) · github-repo (GitHub in neuem Tab — Standards-Seite bleibt geöffnet)
Sortierlogik: Die Gruppen in Block A sind nach historischer Entstehungsreihenfolge sortiert. Diese Reihenfolge entspricht gleichzeitig der didaktischen und architektonischen Schichtung — jede Gruppe baut konzeptuell auf der vorherigen auf:
| Gruppe | Entstehung | Begründung |
|---|---|---|
| HTML | 1991 | Tim Berners-Lee — Grundlage jedes Webdokuments |
| Accessibility | 1999 | WCAG 1.0 — aufbauend auf HTML-Semantik |
| CSS | 1996 | Erst Struktur, dann visuelle Gestaltung |
| JavaScript | 1995 | Verhalten kommt konzeptuell nach Struktur und Darstellung |
| Git | 2005 | Linus Torvalds — Versionskontrolle als eigene Schicht |
| IA / Design System | 2000er | Erst als das Web architektonisch reifte |
| Dokumentation | — | Projektbegleitend, kein eigenes Entstehungsdatum |
Reihenfolge innerhalb der Gruppen — Verbreitung und Grundlegendheit
Innerhalb jeder Gruppe steht der fundamentalste und am weitesten verbreitete Standard zuerst. Speziellere oder seltenere Standards folgen danach. Beispiel HTML: Living Standard → Semantic Elements → Viewport → Meta Description → HTML Validation.
Alternative Betrachtung — Schichtenmodell
Die Gruppen lassen sich auch nach einem formalen Schichtenmodell begründen: Struktur → Darstellung → Verhalten → Versionierung → Architektur → Dokumentation. Dieses Prinzip entspricht dem ISO/OSI-Gedanken, angewandt auf Webentwicklung. Beide Betrachtungsweisen — historisch und schichtbasiert — führen zur identischen Reihenfolge. Die historische Begründung wurde gewählt, da sie intuitiver nachvollziehbar ist.
Anmerkung CSS / JavaScript
CSS (1996) steht vor JavaScript (1995), obwohl JavaScript ein Jahr früher erschien. Begründung: CSS baut konzeptuell direkt auf HTML-Struktur auf — Darstellung folgt Struktur. JavaScript als Verhaltensschicht kommt architektonisch danach. Die didaktisch und architektonisch saubere Sequenz hat hier Vorrang vor der chronologischen Jahreszahl.
Gruppen historisch sortiert: HTML (1991) → Accessibility (1999) → CSS (1996) → JavaScript (1995) → Git (2005) → IA/Design (2000er) → Dokumentation · Innerhalb der Gruppen: nach Verbreitung und Grundlegendheit
| # | Standard / Standardfamilie | Zweck & Definition | Autorität / Quelle | Kategorie | Status | Einordnung / Potenzial im Projekt |
|---|---|---|---|---|---|---|
| HTML / Web — WHATWG · W3C · 1991 | ||||||
| 1 | HTML Living Standard | Definiert die Sprache HTML vollständig: Elemente, Attribute, DOM und Parsing-Regeln. Ist die technische Grundlage jeder Webseite. Ohne diesen Standard wären Browser nicht interoperabel — eine Seite würde in Chrome anders aussehen als in Firefox. | WHATWG | HTML | ✓ | Vollständig umgesetzt: DOCTYPE, lang-Attribut, semantische Elemente (main, header, footer, nav, section). Basis aller Seiten. |
| 2 | HTML5 Semantic Elements | Regelt bedeutungstragende HTML-Elemente wie main, nav, header, footer, article, section. Zweck: Struktur und Bedeutung eines Dokuments maschinenlesbar machen — für Browser, Screenreader und Suchmaschinen. Ermöglicht Orientierung ohne visuelle Darstellung. | W3C / WHATWG | HTML | ✓ | main, header, footer, nav, section konsistent verwendet. id="main" als Sprungziel umgesetzt. |
| 3 | Character Encoding (UTF-8) | Legt fest wie Zeichen als Bytes gespeichert und übertragen werden. UTF-8 kann alle Sprachen, Sonderzeichen und Symbole korrekt darstellen. Ohne korrekte Zeichenkodierung entstehen Darstellungsfehler — z.B. erscheinen Umlaute als Fragezeichen oder Kästchen. | IETF RFC 3629 / W3C | HTML | ✓ | meta charset="UTF-8" auf allen aktiven Seiten. |
| 4 | Viewport Meta Tag | Steuert wie eine Seite auf mobilen Geräten skaliert und dargestellt wird. Ohne dieses Tag zeigen Smartphones die Desktop-Version verkleinert an statt sie responsiv anzupassen. Grundvoraussetzung für jede mobilfähige Website. | W3C / WHATWG | HTML | ✓ | meta name="viewport" content="width=device-width, initial-scale=1.0" auf allen Seiten. |
| 5 | Meta Description | Kurzbeschreibung des Seiteninhalts im HTML-Head. Wird von Suchmaschinen als Vorschautext in den Suchergebnissen angezeigt. Verbessert Auffindbarkeit und Klickrate. Hat keinen direkten Einfluss auf das Ranking, aber auf die Nutzererfahrung in der Suche. | W3C / SEO Best Practice | HTML | ✓ | Eigene Meta-Description pro Seite umgesetzt. |
| 6 | HTML Validation | Prüft ob HTML-Dokumente der Spezifikation entsprechen: korrekte Verschachtelung, gültige Attribute, keine veralteten Elemente. Der W3C Markup Validator ist das offizielle Werkzeug. Validation findet Fehler die Browser still korrigieren aber Screenreader nicht. | W3C Markup Validator | HTML | ✓ | HTML Living Standard: Prüfung mit dem W3C Nu HTML Checker (validator.w3.org/nu/) — aktive Seiten ohne Fehler (Stand 29.03.2026). |
| Accessibility — W3C WAI · WCAG · 1999 | ||||||
| 7 | Document Language Declaration | Das lang-Attribut gibt die Sprache des Dokuments an. Screenreader nutzen es für korrekte Aussprache, Browser für automatische Silbentrennung, Übersetzungsdienste für die Sprachzuordnung. WCAG 3.1.1 verlangt es als Pflichtanforderung. | W3C / WCAG 3.1.1 | Accessibility | ✓ | lang="de" auf allen Seiten. WCAG-Konformitätsanforderung erfüllt. |
| 8 | Page Title (title-Element) | Das title-Element benennt die Seite eindeutig und beschreibend. Erscheint im Browser-Tab, in Lesezeichen und Suchergebnissen. WCAG 2.4.2 verlangt einen beschreibenden Titel als Minimalanforderung — ohne ihn können Nutzer mit Screenreader nicht erkennen, auf welcher Seite sie sich befinden. | W3C / WCAG 2.4.2 | Accessibility | ✓ | Eindeutige, beschreibende Titel pro Seite. Benennungsmatrix abgeschlossen. |
| 9 | Skip Navigation Link | Ein meist visuell versteckter Link, der Tastaturnutzern erlaubt, die Navigation zu überspringen und direkt zum Hauptinhalt zu springen. Ohne ihn muss jeder Nutzer ohne Maus bei jedem Seitenaufruf die gesamte Navigation durchtaben. WCAG-Pflichtanforderung Level A. | WCAG 2.4.1 (A) | Accessibility | ✓ | Skip-Link auf Index und Unterseiten implementiert. Beim Druck ausgeblendet. |
| 10 | Heading Hierarchy | Regelt die logische Überschriftenstruktur H1 → H2 → H3. Screenreader nutzen sie zur Seitennavigation, Suchmaschinen zur Inhaltsgewichtung. Eine gestörte oder fehlende Hierarchie bricht die Zugänglichkeit — Nutzer mit Screenreader können den Inhalt nicht strukturiert erfassen. | W3C / WCAG 1.3.1 (A) | Accessibility | △ | H1/H2-Struktur vorhanden, aber noch nicht auf allen Seiten systematisch geprüft. |
| 11 | ARIA Landmark Roles | WAI-ARIA definiert semantische Rollen und Labels für Seitenbereiche (role="navigation", aria-label usw.). Ermöglicht assistiven Technologien die schnelle Orientierung auf der Seite — besonders für blinde Nutzer, die per Screenreader navigieren und direkt zu Regionen springen können. | W3C WAI-ARIA 1.2 | Accessibility | △ | aria-label auf Nav und Diagrammen. Nicht systematisch auf alle Landmarks angewendet. Ausbaubar. |
| 12 | Colour Contrast | Legt Mindestkontrastverhältnisse zwischen Text und Hintergrund fest. WCAG AA verlangt 4.5:1 für normalen Text. Zu geringer Kontrast macht Inhalte für Nutzer mit Sehschwäche, unter Sonnenlicht oder auf schlechten Bildschirmen unleserlich. | WCAG 1.4.3 (AA) | Accessibility | △ | Designfarben gewählt, aber kein systematischer Kontrast-Check durchgeführt. |
| 13 | Keyboard Navigation | Alle interaktiven Elemente müssen per Tastatur erreichbar und bedienbar sein — ohne Maus oder Touch. Grundlage für Barrierefreiheit bei motorischen Einschränkungen und Pflichtanforderung nach WCAG. Betrifft Links, Buttons und Formularelemente. | WCAG 2.1.1 (A) | Accessibility | △ | Grundlegende Navigation per Tab möglich. Kein systematischer Test. |
| 14 | Focus Visible | Sichtbarer Fokusindikator für alle per Tastatur fokussierbaren Elemente. Nutzer die ohne Maus navigieren müssen jederzeit sehen wo sich der Fokus befindet. Ohne sichtbaren Fokus ist Tastaturnavigation blind — de facto unbrauchbar. | WCAG 2.4.7 (AA) | Accessibility | ✗ | Fokus-Stile nicht explizit definiert. Sinnvoll nachzurüsten, besonders für Nav-Elemente. |
| CSS — W3C · 1996 | ||||||
| 15 | CSS2.1 / CSS3 Spezifikation | Definiert die Syntax, Eigenschaften und das Kaskadenmodell von CSS. Regelt wie Stile berechnet, vererbt und angewendet werden. Basis für alle visuellen Gestaltungsentscheidungen — ohne diese Spezifikation wäre CSS-Verhalten zwischen Browsern nicht vorhersagbar. | W3C | CSS | ✓ | Valides CSS, keine veralteten Eigenschaften. base.css, subpage.css, doc-a4.css, index.css. |
| 16 | CSS Custom Properties (Variables) | Ermöglicht die Definition wiederverwendbarer Werte (Farben, Abstände, Schriftgrößen) als CSS-Variablen im :root-Block. Änderungen an einem zentralen Wert wirken sich systemweit aus — ohne Suchen-und-Ersetzen. Grundlage für wartbare und konsistente Designsysteme. | W3C CSS Variables L1 | CSS | ✓ | :root-Variablen für Farben und Abstände konsistent verwendet. |
| 17 | Print Stylesheet / @media print | Definiert CSS-Regeln die nur beim Drucken gelten. Ermöglicht druckoptimierte Darstellung: Navigation ausblenden, Farben anpassen, Seitenumbrüche steuern, A4-Proportionen einhalten. Besonders relevant für Dokument- und Formularseiten. | W3C CSS Media Queries | CSS | ✓ | @media print für A4-Seiten umgesetzt. Nav und Chrome ausgeblendet. page-break-after implementiert. |
| 18 | Responsive Web Design | Beschreibt den Ansatz, Layouts über flexible Grids, flexible Bilder und CSS Media Queries so zu gestalten, dass sie sich an verschiedene Bildschirmgrößen anpassen. Geprägt von Ethan Marcotte 2010. Heute Standarderwartung an jede Website. | W3C / Ethan Marcotte 2010 | CSS | △ | Viewport-Meta umgesetzt. Media Queries punktuell vorhanden. Kein systematischer Responsive-Standard. |
| 19 | CSS Architecture (Separation of Concerns) | Beschreibt Prinzipien zur Strukturierung von CSS-Dateien: Trennung von Layout, Typografie, Komponenten und Utilities. Bekannte Methoden: SMACSS, ITCSS, OOCSS. Ziel: Wartbarkeit und Skalierbarkeit bei wachsenden Projekten. | Praxis / SMACSS / ITCSS | CSS | △ | Basis-/Unterseiten-/Formular-CSS getrennt. Komponentenstil noch nicht vollständig systematisiert. |
| 20 | CSS Naming Convention (BEM o. ä.) | Regelt wie CSS-Klassen benannt werden, z.B. nach dem BEM-Prinzip (Block__Element--Modifier). Ziel: Klassenname erklärt Funktion und Kontext, verhindert Namenskollisionen, macht Code lesbar ohne HTML sehen zu müssen. | BEM / OOCSS / Praxis | CSS | △ | Funktionsbezogene Klassennamen vorhanden. Kein formales BEM. Konsistenz ausbaubar. |
| 21 | CSS Comments & Documentation | Beschreibt die Praxis, CSS-Dateien mit erklärenden Kommentaren zu versehen: Abschnittstrennungen, Begründungen für nicht-offensichtliche Entscheidungen, Hinweise auf Abhängigkeiten. Sichert Wartbarkeit, besonders wenn andere Personen oder KI-Tools mit dem Code arbeiten. | Praxis / Maintainability | CSS | ✗ | CSS-Dateien noch nicht systematisch kommentiert. Sinnvoll für Wartbarkeit bei wachsendem Projekt. |
| 22 | CSS Validation | Prüft ob CSS-Dateien der W3C-Spezifikation entsprechen: gültige Eigenschaften, korrekte Werte, keine Tippfehler. Der W3C CSS Validator ist das offizielle Werkzeug. Findet stille Fehler die zu inkonsistenter Darstellung in verschiedenen Browsern führen. | W3C CSS Validator | CSS | ✗ | Noch kein systematischer CSS-Validierungslauf. Empfehlenswert. |
| JavaScript — ECMA International · 1995 | ||||||
| 23 | JavaScript ES6+ Syntax | ECMAScript 2015 und folgende Versionen definierten moderne JavaScript-Syntax: let/const, Arrow Functions, Template Literals, Modules, Promises. Aktueller Industriestandard. Code der älteren Syntax folgt gilt als veraltet und schwerer wartbar. | ECMA International / ECMAScript | JavaScript | △ | JS nur für SDLC-Visualisierungen. Moderner Syntax genutzt, kein formaler Style Guide. |
| 24 | JavaScript Separation (externe Dateien) | Best Practice: JavaScript-Code gehört in externe .js-Dateien, nicht als Inline-Script in HTML. Trennt Verhalten von Struktur, verbessert Caching, Lesbarkeit und Wartbarkeit. Grundprinzip der Separation of Concerns für Web-Technologien. | W3C / Praxis | JavaScript | ✓ | JS ausgelagert in assets/js/ — sauber von HTML getrennt. |
| 25 | JavaScript Documentation (JSDoc) | Standardformat zur Dokumentation von JavaScript-Funktionen, Parametern und Rückgabewerten direkt im Code als strukturierte Kommentare. Ermöglicht automatische Dokumentationsgenerierung und verbessert Verständlichkeit für andere Entwickler oder KI-Tools. | JSDoc / Praxis | JavaScript | ✗ | Noch nicht umgesetzt. Bei geringem JS-Umfang vertretbar. Sinnvoll wenn JS wächst. |
| 26 | Automated Testing (Unit/E2E) | Automatisierte Tests prüfen Code-Logik (Unit Tests) oder Nutzerflüsse (End-to-End Tests) auf Korrektheit. Werkzeuge: Jest, Cypress. Für statische Informationsseiten ohne Anwendungslogik kein sinnvoller Einsatzbereich. | Jest / Cypress / Praxis | JavaScript | — | Statisches Informationsprojekt. Kein Mehrwert für diesen Scope. |
| Git & Repository — Linus Torvalds · 2005 | ||||||
| 27 | Git Version Control | Git ist ein verteiltes Versionskontrollsystem. Es speichert die vollständige Änderungshistorie, ermöglicht Branching und ermöglicht die Wiederherstellung jedes früheren Zustands. Industriestandard für jede Art von Softwareprojekt. | Git / Linus Torvalds | Git | ✓ | Monorepo qa-ctfl-track: Git am Repo-Root; .gitignore / .gitattributes dort. Im Website-Unterordner keine redundanten Git-Metadaten. |
| 28 | Git .gitignore Standard | Eine .gitignore-Datei definiert welche Dateien und Ordner nicht ins Repository eingecheckt werden sollen: temporäre Dateien, Systemdateien, lokale Konfigurationen. Verhindert versehentliches Committen von sensiblen oder irrelevanten Daten. | GitHub / Praxis | Git | ✓ | Vorhanden und konfiguriert. |
| 29 | Repository Structure Conventions | Regelt die Ordnerstruktur und Dateiorganisation innerhalb eines Git-Repositories: Trennung von Quellcode, Assets, Tests, Dokumentation und Archiv. Macht das Projekt für andere (und für KI-Tools) sofort navigierbar. | GitHub / Praxis | Git | ✓ | Im Website-Ordner: pages/, assets/, templates/ sauber getrennt; README.md der Lernwebsite im Ordner. LICENSE im Repository-Root des Monorepos. |
| 30 | Git Commit Conventions | Regeln für Inhalt, Format und Granularität von Commit-Nachrichten. Bekannter Standard: Conventional Commits (feat:, fix:, docs:, refactor: usw.). Saubere Commits machen die Projekthistorie lesbar und ermöglichen automatische Changelogs. | Conventional Commits / Praxis | Git | △ | Commit-Richtlinie in 08_Commit_Richtlinie.md dokumentiert. Konsistenz der tatsächlichen Commits nicht geprüft. |
| 31 | Open Source License (CC BY-NC-SA 4.0) | Creative Commons BY-NC-SA 4.0 erlaubt die Nutzung und Weitergabe unter Namensnennung, nicht-kommerziell und unter gleichen Bedingungen. Regelt rechtlich was andere mit dem Projekt tun dürfen. Ohne Lizenz gilt urheberrechtlich: alle Rechte vorbehalten. | Creative Commons | Git | ✓ | LICENSE im Repo-Root (Monorepo). Lizenz in Website-README und Index-Seite ausgewiesen. |
| 32 | Branching Strategy (z.B. GitFlow) | Definiert wie Branches in einem Team-Repository organisiert werden: Feature-Branches, Release-Branches, Hotfixes. Relevant ab zwei oder mehr Personen die parallel arbeiten. Für Einzelperson-Projekte kein Mehrwert. | Atlassian / Praxis | Git | — | Einzelperson-Projekt. Kein Team, keine parallelen Branches notwendig. Nicht anwendbar. |
| Information Architecture & Design System — 2000er | ||||||
| 33 | Information Architecture | Beschreibt die strukturelle Planung von Inhalten, Seitentypen und Navigationsbeziehungen in einem Informationssystem. Geprägt von Rosenfeld & Morville. Ziel: Nutzer finden was sie suchen — intuitiv, ohne Erklärung. | Rosenfeld / Morville / Praxis | IA | ✓ | 03_Project_Standards.md und 01_Project_Charter.md (QA-Track 01_Projektsteuerung/) mit IA, Seitentypen, Benennungslogik dokumentiert und umgesetzt. |
| 34 | Naming Conventions (Datei- und Seitenebene) | Einheitliche Regeln für Benennung von Dateien, Seiten, Titeln und Navigationseinträgen. Verhindert Inkonsistenzen, macht Inhalte auffindbar und kommuniziert Struktur ohne Dokumentation. Grundlage für skalierbare Informationsarchitektur. | Praxis / W3C URL-Spezifikation | IA | ✓ | Vollständige Benennungsmatrix (Dateiname, Nav, Title, H1, Untertitel) definiert und umgesetzt. |
| 35 | URL / Filename Conventions (kebab-case) | Kebab-case (wörter-mit-bindestrich) ist der Web-Standard für Dateinamen und URLs. Suchmaschinen interpretieren Bindestriche als Worttrennzeichen, Leerzeichen und Unterstriche nicht. Kleinschreibung verhindert Betriebssystem-Inkompatibilitäten. | W3C / Google / Praxis | IA | ✓ | Durchgängig kebab-case, keine Leerzeichen, keine Versionsnummern in aktiven Dateien. |
| 36 | Traceability (Inhalt → Lehrplan) | Rückverfolgbarkeit stellt sicher dass jeder Inhalt einer definierten Anforderung oder Quelle zugeordnet werden kann. In diesem Projekt: jede Seite ist einem CTFL-Kapitel zugeordnet. Verhindert inhaltliche Lücken und Redundanzen. | ISTQB / IEEE 29119 | IA | ✓ | Alle Seiten mit CTFL-Kapiteln referenziert. Kernlogik des Projekts. |
| 37 | Design System (visuelles Regelsystem) | Ein Design System ist ein vollständiges Set von Regeln, Tokens und Komponenten für die visuelle und strukturelle Gestaltung. Umfasst Farben, Typografie, Abstände, Ikonografie und Komponentenstile. Unterschied zur Component Library: das Design System definiert das Warum, die Library das Was. | Praxis / Google Material / Nielsen | IA | △ | Farben, Typografie, Abstände konsistent in CSS-Variablen. Komponentenstil noch nicht vollständig. |
| 38 | Component / UI Pattern Library | Eine Sammlung definierter, wiederverwendbarer UI-Bausteine mit festgelegtem Verhalten und Aussehen. Verhindert dass dieselbe Komponente (z.B. eine Infobox) auf jeder Seite anders implementiert wird. Grundlage für Konsistenz und Wartbarkeit. | Praxis / Brad Frost Atomic Design | IA | △ | Komponenten (Card, InfoBox, MetaBar, Tag) vorhanden. Kein formales Komponentenregelwerk. Nächster Schritt. |
| Dokumentation — projektbegleitend | ||||||
| 39 | README Standard (Repository Documentation) | Eine README.md im Repository-Root ist der erste Anlaufpunkt für jeden der das Projekt entdeckt. Sie beschreibt Zweck, Struktur, Technologie, Lizenz und Stand. De-facto-Standard auf GitHub und allen anderen Code-Hosting-Plattformen. | GitHub / Open Source Praxis | Dokumentation | ✓ | README aktuell und strukturiert. Projektbeschreibung, Struktur, Lizenz, Stand dokumentiert. |
| 40 | Microcopy / Editorial Consistency | Regelt einheitliche Sprache in der Benutzeroberfläche: Labels, Navigationstexte, Untertitel, Fehlermeldungen, Quellenangaben. Inkonsistente Microcopy (mal 'Kapitel', mal 'Kap.', mal 'Chapter') verwirrt Nutzer und wirkt unprofessionell. | Content Strategy / Praxis | Dokumentation | △ | Benennungsmatrix abgeschlossen. Quellenangaben und Normverweise noch nicht vollständig vereinheitlicht. |
| HTML / Web — WHATWG · W3C · 1991 | ||||||
| 41 | Performance (Ladezeit / Ressourcen) | Definiert Zielwerte für Ladezeit, Ressourcengröße und Rendering-Performance. Google Lighthouse und Web Vitals sind Standardwerkzeuge. Für statische Projekte ohne externe Abhängigkeiten kein aktives Problem. | W3C / Google Lighthouse | HTML | — | Statisches Projekt ohne externe Abhängigkeiten. Performance kein aktives Problem. Kein Handlungsbedarf. |
| 42 | Security (CSP, HTTPS) | Content Security Policy und HTTPS schützen Webanwendungen vor Injection-Angriffen und Man-in-the-Middle-Angriffen. Für statische HTML-Seiten ohne Nutzereingaben, Login oder Backend kein relevantes Thema. | W3C / OWASP | HTML | — | Statisches HTML, kein Backend, keine Formulareingaben. Security nicht relevant für diesen Scope. |
Block B — qa-ctfl-track (Monorepo · Programm, Steuerung, Hausaufgaben, Referenzen, Notizen, Archiv)
Sortierlogik: Die Gruppen in Block B folgen keiner historischen Entstehungsreihenfolge im technischen Sinne, da es sich um Informationsmanagement und nicht um Softwarestandards handelt. Stattdessen gilt eine logische Aufbaureihenfolge: erst die physische Struktur, dann die Dokumentation der Inhalte, dann die Methodik der Wissensorganisation.
| Gruppe | Prinzip | Begründung |
|---|---|---|
| Dateistruktur & Organisation | Physische Basis | ISO 15489, ISO 8601 — bevor Inhalte dokumentiert werden, muss die Ablagestruktur stehen |
| Dokumentationsstandards | Inhaltsebene | Regeln für das Was und Wie der Dokumentation — aufbauend auf der Struktur |
| PKM — Personal Knowledge Management | Methodenebene | PARA, Separation of Concerns — übergeordnete Methodik, die beide vorigen Ebenen nutzt |
Reihenfolge innerhalb der Gruppen — Verbreitung und Grundlegendheit
Dieselbe Regel wie in Block A: der fundamentalste und am weitesten verbreitete Standard steht zuerst. Beispiel Dateistruktur: Folder Structure Conventions → File Naming → Archive Separation → Keine losen Dateien im Root → Konsistente Dateierweiterungen.
Unterschied zu Block A
In Block A ist die historische Entstehungsreihenfolge gleichzeitig die didaktische und architektonische. In Block B gibt es kein vergleichbares technisches Entstehungsdatum — ISO 15489 wurde zwar 2001 formalisiert, aber Ordnerstrukturen existierten vor jeder Norm. Die gewählte Reihenfolge Struktur → Dokumentation → Methodik ist deshalb rein logisch-hierarchisch begründet: jede Ebene setzt die vorherige voraus.
Gruppen: Dateistruktur → Dokumentationsstandards → PKM · Autoritäten: ISO 8601, ISO 15489, ISO 690, PARA-Methode, DRY-Prinzip
| # | Standard / Standardfamilie | Zweck & Definition | Autorität / Quelle | Kategorie | Status | Einordnung / Potenzial im Projekt |
|---|---|---|---|---|---|---|
| Dateistruktur & Organisation — ISO 15489 · 8601 | ||||||
| 1 | Folder Structure Conventions | Regelt die Ordnerorganisation eines Dateisystems nach logischen Kategorien. ISO 15489 (Records Management) beschreibt Prinzipien für die strukturierte Ablage von Dokumenten. Ziel: jede Datei hat genau einen logischen Ablageort, der für alle Beteiligten vorhersagbar ist. | Praxis / ISO 15489 | Struktur | ✓ | Klare Ordnerlogik: Top-Level 01_Projektsteuerung/ bis 07_Tests/ (Steuerung, Portfolio, Hausaufgaben, Referenzen, Notizen, Archiv, Tests). Thematische Trennung konsequent umgesetzt. |
| 2 | File Naming Conventions (YYYY-MM-DD) | ISO 8601 definiert das internationale Datumsformat YYYY-MM-DD. Als Dateinamen-Präfix stellt es chronologische Sortierung sicher — Betriebssysteme sortieren Dateien alphabetisch, und ISO-Datum beginnt mit dem Jahr. Standard in professionellen Dokumentenmanagementsystemen. | ISO 8601 / Praxis | Struktur | △ | In 05_Projektstandards.md definiert. In HA-Ordnern gut umgesetzt. In 04_Notizen noch uneinheitlich. |
| 3 | Archive Separation | Veraltete, ersetzte oder inaktive Dateien werden in einen dedizierten Archivordner verschoben statt gelöscht. Erhält die Nachvollziehbarkeit ohne den aktiven Arbeitsbereich zu belasten. ISO 15489 beschreibt dies als Records-Management-Prinzip. | Records Management / ISO 15489 | Struktur | ✓ | 06_Archiv/ sauber getrennt. alt-claude-PW als Unterordner nachvollziehbar. |
| 4 | Keine losen Dateien im Root | Der Root-Ordner eines Projekts sollte nur Orientierungsdateien enthalten (README, LICENSE, Konfiguration). Alle inhaltlichen Dateien gehören in thematische Unterordner. Verhindert Unübersichtlichkeit bei wachsendem Projekt. | 05_Projektstandards / intern | Struktur | ✓ | Nur README.md im Root. Alles andere in definierten Ordnern. Eingehalten. |
| 5 | Konsistente Dateierweiterungen | Jeder Dateityp hat eine definierte, einheitliche Erweiterung. Doppelablage derselben Datei in zwei Formaten (.md und .txt) verletzt das DRY-Prinzip und erzeugt Unklarheit darüber welche Version aktuell ist. | Praxis | Struktur | △ | Meistens korrekt. 00_Loesung_HA4.md + .txt-Duplikat fällt auf. Bereinigbar. |
| Dokumentationsstandards — Praxis | ||||||
| 6 | Metablock / Frontmatter Standard | Ein standardisierter Metadatenblock am Anfang jeder Markdown-Datei (Erstellt, Aktualisiert, Zweck, Status). Ermöglicht maschinelle Auswertung, einheitliche Dokumentenstruktur und schnelle Orientierung. In modernen Static-Site-Generatoren als YAML Frontmatter etabliert. | YAML Frontmatter / Praxis | Dokumentation | ✓ | Metablock-Prinzip in 01_Projektsteuerung/ (u. a. 03_Project_Standards.md) definiert und praktisch verwendet. |
| 7 | Chronological Ordering (neueste oben) | Konvention für fortlaufende Dokumente: neueste Einträge stehen oben, ältere unten. Entspricht der Erwartungshaltung bei Logs, Changelogs und Statusdokumenten. Verhindert Scrollen zum Ende bei jedem Update. | Praxis / Documentation Gov. | Dokumentation | ✓ | In Projektsteuerungsdokumenten konsequent eingehalten. |
| 8 | README per Ordner | Eine README.md in jedem thematischen Ordner erklärt Zweck, Inhalt und Kontext dieses Ordners. Verhindert dass Inhalte ohne Erklärung stehen. Besonders wichtig bei mehreren Monaten Abstand oder wenn andere Personen oder KI mit dem Repo arbeiten. | GitHub / Praxis | Dokumentation | △ | Vorhanden in 01, 02, 03, 05, 99. Fehlend in 04_Notizen. Sinnvoll ergänzen. |
| 9 | Single Source of Truth | DRY-Prinzip (Don't Repeat Yourself) angewandt auf Dokumentation: jede Information existiert genau einmal, an einem definierten Ort. Duplikate führen zwangsläufig zu Inkonsistenzen wenn eine Version aktualisiert wird, die andere nicht. | Praxis / DRY-Prinzip | Dokumentation | △ | Steuerungsdokumente zentralisiert. Doppelungen noch sichtbar: z.B. 00_Loesung_HA4.md und .txt parallel vorhanden. Bereinigbar. |
| 10 | Reference Management | Regelt die strukturierte Ablage und Zitierung von Quellen und Referenzdokumenten. ISO 690 definiert Bibliografiestandards. In der Praxis: dedizierter Referenzordner, konsistente Benennung, nachvollziehbare Herkunft. | ISO 690 / Praxis | Dokumentation | △ | 05_Referenzen als dedizierter Ordner vorhanden. ISTQB-Quelldokumente sauber abgelegt. Keine formale Zitierstrategie. |
| 11 | Changelog / Historienführung | Keep a Changelog ist ein etabliertes Format für Änderungshistorien: geordnet nach Version oder Datum, kategorisiert nach Added/Changed/Fixed/Removed. Macht Projektverlauf nachvollziehbar ohne die Git-Historie lesen zu müssen. | Keep a Changelog / Praxis | Dokumentation | △ | 02_Project_Status.md führt chronologisch Status. Kein formaler Changelog. Für diesen Scope ausreichend. |
| 12 | Prompt Documentation Standard | Aufkommende Praxis in KI-gestützter Arbeit: Prompts, Prompt-Richtlinien und KI-Vereinbarungen werden wie Code oder Dokumentation versioniert und strukturiert abgelegt. Sichert Reproduzierbarkeit und ermöglicht Qualitätsverbesserung über Zeit. | Emerging AI Practice / intern | Dokumentation | ✓ | 07_Prompt_Richtlinie.md und 09_Prompts.md vorhanden. Guter Ansatz für reproduzierbare KI-Arbeit. |
| Personal Knowledge Management — PARA · SE-Prinzipien | ||||||
| 13 | PKM — Personal Knowledge Management | PARA (Projects, Areas, Resources, Archives) ist ein von Tiago Forte entwickeltes System zur persönlichen Wissensorganisation. Strukturiert Inhalte nach Handlungsrelevanz statt nach Thema. Ziel: die richtige Information zur richtigen Zeit auffindbar machen. | Tiago Forte (PARA) | PKM | △ | Struktur entspricht grob dem PARA-Modell. Nicht explizit angewendet. 04_Notizen noch heterogen. |
| 14 | Separation of Concerns (Inhalt vs. Lösung) | Ingenieurprinzip: verschiedene Aspekte eines Problems werden sauber getrennt behandelt. Hier angewandt auf Lernmaterial: Original-Aufgabe, eigene Formulierung, Lösung, Beispiel und Lernnotizen sind separate Dateien. Verhindert Vermischung von Fremdinhalten und eigener Arbeit. | SE-Prinzip / Praxis | PKM | ✓ | Pro HA: Original-Aufgabe, umformulierte Aufgabe, Lösung, Beispiel, Lerndatei sauber getrennt. Klares Muster. |
| 15 | 04_Notizen — Strukturbereinigung | Loseblatt-Notizen ohne Datum, Kategorie oder Kontext sind mittelfristig nicht auffindbar. Best Practice: Notizen werden entweder thematisch zugeordnet (→ Unterordner), datiert (ISO 8601 Präfix) oder in das übergeordnete System integriert (→ 01_Grundlagen). | Praxis / PKM | PKM | ✗ | Aktuell heterogen: HTML-Dateien, .txt ohne Datum, thematisch gemischt. Bereinigung und Umzug sinnvoll. |