tuana-vn/system-reverse-engineer

Generierung der Arbeitspaketstruktur (WBS)

Zweck

WBS beschreibt, WAS implementiert werden muss, keine Aufwandsschätzung.

Springen Sie nicht direkt von TDD-Prosa zu generischen Aufgaben.

Eingaben müssen VERIFIZIERTE detaillierte Designs enthalten.

Anforderung
→ Lücke
→ TDD
→ Entwurfsartefakt
→ VERIFIZIERTES detailliertes Design
→ WBS-Aufgabe
→ Verifikation

Eingaben

• maßgebliche Anforderung
• verifizierte Lückenanalyse
• verifiziertes TDD
• Artefaktregister der Entwürfe
• alle DD_VERIFIED detaillierte Designs
• Verifikationsberichte detaillierter Designs
• Testdesign (falls vorhanden)
• aktuelles Repository

1. Aufgabenableitung

Leiten Sie Aufgaben ausschließlich aus verifizierten Designentscheidungen ab.

Aufgabenkategorien:

• Produktionscode
• API/Contract
• Integration
• Daten/Persistenz
• Konfiguration
• Migration/Kompatibilität
• Tests
• Build/Deployment
• Dokumentation
• Bereinigung nur, wenn durch genehmigtes Design erforderlich

Fügen Sie keine „nice-to-have“-Refaktorisierungen hinzu.

2. Aufgabengranularität

Eine Aufgabe sollte klein genug sein, um Folgendes zu haben:

• ein klares Ergebnis
• konkrete Source-/Designanker
• explizite Abhängigkeiten
• überprüfbare Fertigstellungskriterien

Teilen Sie mechanische Änderungen jedoch nicht in Dutzende bedeutungslose Mikroaufgaben auf.

3. Stabile IDs

Verwenden Sie:

WBS-001, WBS-002, ...

3A. WBS ↔ Design-Semantische Identität

Rückverfolgbarkeit ist nicht allein dadurch gegeben, dass eine WBS-Zeile eine vorhandene Artefakt-ID enthält.

Identifizieren Sie für jede WBS-Aufgabe ihr primäres Implementierungsergebnis und weisen Sie nach, dass die referenzierten Entwurfsartefakte dieses Ergebnis besitzen.

Erforderliche semantische Kette:

WBS-Aufgabentitel / Ziel / primäres Ergebnis
↔ Artefaktname des Registers + Verantwortung
↔ VERIFIZIERTE, dem DD zugeordnete Implementierungseinheit(en)
↔ TDD-Entwurfsentscheidung

Regeln:

1. Eine Artefakt-ID-Referenz ist notwendig, aber nicht ausreichend.
2. Ein Typ/Klasse/Interface, der/die in einem DD lediglich erwähnt, importiert, referenziert oder verlinkt wird, weist nicht nach, dass das Artefakt diese Implementierungseinheit besitzt.
3. Wenn das primäre Ergebnis einer WBS-Aufgabe ein untergeordneter Typ ist, muss mindestens eine der folgenden Bedingungen erfüllt sein:
   • das Register/DD deklariert diesen untergeordneten Typ explizit innerhalb des Geltungsbereichs des besitzenden Artefakts, oder
   • die Dekomposition des Entwurfsartefakts muss überarbeitet werden, um ihn separat zu verfolgen.
4. Ordnen Sie keine Aufgabe mit dem Titel für Komponente/Typ A einem Artefakt zu, dessen registrierte Verantwortung Komponente/Typ B ist, es sei denn, das Artefakt besitzt A explizit.
5. Wenn die semantische Eigentümerschaft nicht nachgewiesen werden kann, stoppen Sie mit WBS_BLOCKED_DESIGN_GAP; erfinden Sie keine Zuordnung aus nahegelegener TDD-Prosa.

Erstellen Sie vor dem Ausgeben des WBS eine interne/exponierte Konsistenztabelle:

WBS-ID	Primäres Ergebnis	Referenzierte Artefakt-IDs	Register-Verantwortung	DD-eigene Einheit	Semantische Übereinstimmung?	Nachweis

Erforderlicher Schwellwert:

WBS ↔ Artefakt-Semantische Identität = 100 %

4. WBS-Tabelle

WBS-ID	Entwurfsartefakt-IDs	Aufgabe	Vorhandener Source-Anker / Vorgeschlagener Ort	Änderungstyp	Abhängigkeiten	Anforderungs-IDs	TDD/DD-Referenzen	Verifikation	Fertigstellungs-Kriterien

Änderungstyp:

• ADD
• MODIFY
• REMOVE
• CONFIGURE
• MIGRATE
• TEST
• DOCUMENT
• VERIFY

5. Abhängigkeits-DAG

Leiten Sie die Implementierungsreihenfolge aus Artefaktabhängigkeiten und Code-/Laufzeitabhängigkeiten ab.

Erstellen:

WBS-ID	Hängt ab von	Abhängigkeitsgrund	Hart/Weich

Erkennen Sie zirkuläre Abhängigkeiten.

Erfinden Sie keine Reihenfolge allein aus der Dateireihenfolge.

6. Verifikationszuordnung

Jede codeändernde Aufgabe benötigt einen Verifikationspfad.

Ordnen Sie zu:

• vorhandener Test zum Aktualisieren
• neue Test-ID/Sichtweise
• Source-/Build-Verifikation
• Laufzeit-/Integrationsverifikation
• manuelle Verifikation nur, wenn Automatisierung nicht machbar ist

7. Rückverfolgbarkeit

Erstellen:

Anforderungs-ID	Lücken-ID	TDD-Entscheidungs-ID	Artefakt-ID	DD	WBS-IDs	Test-/Verifikations-IDs	Abdeckung

Kein verifiziertes Entwurfsartefakt darf verwaist sein.

8. WBS-Gate

Vor WBS_READY_FOR_VERIFICATION:

[ ] alle DD_VERIFIED-Artefakte haben Implementierungs-/Verifikationsaufgabenabdeckung
[ ] jede WBS-Aufgabe ist auf verifiziertes Design rückgeführt
[ ] das primäre Ergebnis jeder WBS-Aufgabe stimmt semantisch mit der Verantwortung/besessenen Einheit des referenzierten Artefakts/der referenzierten Artefakte überein
[ ] keine Aufgabe stützt sich auf ein lediglich erwähntes DD-/TDD-Symbol als Nachweis der Artefakt-Eigentümerschaft
[ ] Source-Anker / vorgeschlagene Orte sind konkret
[ ] Abhängigkeiten sind explizit
[ ] codeändernde Aufgaben haben Fertigstellungskriterien und Verifikation
[ ] Konfigurations-/Migrations-/Dokumentations-/Testarbeit ist enthalten, wenn erforderlich
[ ] keine nicht genehmigte Architektur/Refaktorisierung wurde hinzugefügt
[ ] keine HIGH/CRITICAL Source-Lücke versteckt sich innerhalb einer Aufgabe

Status:

• WBS_READY_FOR_VERIFICATION
• WBS_BLOCKED_DESIGN_GAP
• WBS_BLOCKED_SOURCE_GAP

Wichtig

Schätzen Sie in diesem Skill keine Stunden/Tage/Story Points. Aufwandsschätzung ist ein separates Anliegen.