Konzept: Produktverzeichnisstruktur
Eine Produktverzeichnisstruktur enthält das hierarchische Verzeichnis und die Unterverzeichnisse mit Ordnern und Dateien, in denen produktbezogene Arbeitsergebnisse gespeichert werden.
Beziehungen
Zugehörige Elemente
Hauptbeschreibung

Die Produktverzeichnisstruktur dient als logisch verschachtelter Platzhalter für alle produktbezogenen Arbeitsergebnisse mit Versionsangabe. Arbeitsergebnisse werden im folgenden Entwicklungsprozesszyklus und für die Entwicklung jedes zugehörigen Implementierungselements des Gesamtsystems erzeugt.

Die folgende Abbildung zeigt, dass sich System-X aus "N" Subsystemen und jedes Subsystem aus "N" Komponenten zusammensetzt. Die Produktverzeichnisstruktur ist ein allgemeiner Platzhalter für die verschiedenen Arbeitsergebnisse, die für die Entwicklung jedes Teil des Gesamtsystems erforderlich sind.

Verzeichnisstruktur auf Komponentenebene Produktverzeichnisstruktur auf Subsystemebene Produktverzeichnisstruktur des Systems In der Überschrift genannte Abbildung

Systemproduktverzeichnisstruktur

Obwohl ein erfahrener Softwarearchitekt von vornherein einen sinnvollen Lösungsansatz für die Systemzusammensetzung haben kann, entsteht die Sicht der wichtigen Entwicklungskomponenten als Ergebnis der analyse- & designbezogenen Aktivitäten, wo die geeigneten Architekturen definiert und präzisiert werden.

Die folgende Tabelle zeigt ein Muster für eine Produktsystemverzeichnisstruktur, die in den ersten Phasen der Projektentwicklung als "Produktverzeichnisstruktur" verwendet werden könnte. Die exakten Details der zugehörigen Subsysteme und die Architekturschichten müssen jedoch noch festgelegt werden.

Produktverzeichnisstruktur auf Systemebene

Systemanforderungen

Modelle

Anwendungsfallmodell Anwendungsfallpaket
Datenbank Anforderungsattribute
Dokumente Vision
Glossar
Stakeholder-Anfragen
Ergänzende Spezifikationen
Softwareanforderungsspezifikation
Storyboards

Berichte

Bericht: Übersicht über das Anwendungsfallmodell
Bericht: Anwendungsfallspezifikation
Systemdesign und -implementierung Modelle Analysemodell Anwendungsfallrealisierung
Designmodell Designsubsystem
Schnittstelle
Designpaket
Datenmodell
Auslastungsanalysedokument
Benutzerschnittstellenprototyp
Dokumente Softwarearchitekturdokument
Bericht: Übersicht über das Designmodell
Navigationsübersicht
Subsystem-1 Subsystemverzeichnisstruktur
Subsystem-N Subsystemverzeichnisstruktur
Systemintegration Pläne Build-Plan für Integration
Bibliotheken  
Systemtest Testplan Testsuites
Testfälle Testscripts
Testdaten  
Testergebnisse  
System-Deployment Deployment-Plan  
Dokumente Release-Informationen
Handbücher Unterstützendes Material für Benutzer
Schulungsmaterial
Installationsartefakte  
Systemmanagement Pläne Softwareentwicklungsplan
Iterationsplan Anforderungsmanagementplan
Liste der Risiken Risikomanagementplan
Entwicklungsfall Infrastrukturplan
Produktabnahmeplan Konfigurationsmanagementplan
Dokumentationsplan QS-Plan
Plan zur Problemlösung Plan zum Subunternehmermanagement
Prozessverbesserungsplan Plan für die Erfolgsmessung
Bewertungen Iterationsauswertung
Beurteilung der Entwicklungsorganisation
Statusbewertung
Tools Tools für Entwicklungsumgebung Editoren
Compiler
Konfigurationsmanagementtools Rational ClearCase
Anforderungsmanagementtools Rational RequisitePro
Tools für visuelle Modellierung Rational Rose
Testtools Rational Test Factory
Fehlererfassung Rational ClearQuest
Standards und Richtlinien Anforderungen Anforderungsattribute
Projektspezifische Richtlinien
Design Projektspezifische Richtlinien
Implementierung Projektspezifische Richtlinien
Dokumentation Styleguide für Handbücher

Wenn die Analyse- & Designaktivitäten laufen und mehr Informationen zur Anzahl und zum Charakter der erforderlichen Subsystem für das Gesamtsystem vorliegen (Aufgabe: Subsystemdesign), muss die Produktverzeichnisstruktur erweitert werden, um die einzelnen Subsysteme unterzubringen.

Die Informationen in der Systemproduktverzeichnisstruktur muss für alle Subsysteme im Projekt sichtbar sein. Somit gehören neben dem Produktmanagement auch Standards und Richtlinien für Anforderungen und Testinformationen in die Systemproduktverzeichnisstruktur. In dem Beispiel sind Tools in der Systemproduktverzeichnisstruktur enthalten. Sie könnten aber auch in ein Verzeichnis der höheren Ebene eingefügt werden, damit mehrere Systeme dieselben Tools verwenden können.

Subsystemverzeichnisstruktur

Die Informationen in der Produktsubsystemverzeichnisstruktur beziehen sich direkt auf die Entwicklung des jeweiligen Subsystems. Die Anzahl der 'Instanzierungen' der Produktsubsystemverzeichnisstruktur bezieht sich eindeutig auf die Anzahl der Subsysteme, die während der Analyse- & Designaktivitäten identifiziert wurden. System-y kann beispielsweise drei Subsysteme haben (Subsystem-A, Subsystem-B und Subsystem-N). Jedes Subsystem hat die erforderlichen Informationen für sein Design und eventuell auch für seine Implementierung.

Eine generalisierte Gliederung der Produktsubsystemverzeichnisstruktur ist wie folgt:

Produktverzeichnisstruktur auf Subsystemebene

Anforderungen an Subsystem-N

Modelle Anwendungsfallmodell Anwendungsfallpaket
Storyboard
Anwendungsfall (Text)
Benutzerschnittstellenprototyp
Datenbank Anforderungsattribute
Dokumente Vision
Glossar
Stakeholder-Anfragen
Ergänzende Spezifikationen
Softwareanforderungsspezifikation
Storyboards

Berichte

Bericht: Übersicht über das Anwendungsfallmodell
Bericht: Anwendungsfallspezifikation
Design und Implementierung von Subsystem-N Modelle Analysemodell Anwendungsfallrealisierung
Designmodell Designpakete
Schnittstellenpakete
Testpakete
Implementierungsmodell
Datenmodell
Auslastungsmodell
Dokumente Softwarearchitekturdokument
Bericht: Übersicht über das Designmodell
Navigationsübersicht

Berichte

Bericht: Anwendungsfallrealisierung

Komponente-1

Verzeichnis von Komponente-1

Komponente-N

Verzeichnis von Komponente-N
Integration von Subsystem-N Pläne Build-Plan für Integration
Bibliotheken  
Test von Subsystem-N Testplan Testsuites
Testfälle Testscripts
Testergebnisse  
Testdaten  

Komponentenverzeichnisstruktur

Die Anzahl der Komponenten ist ein Ergebnis von Subsystemdesignentscheidungen. Die folgende Verzeichnisstruktur muss für jede zu entwickelnde Komponente instanziert werden.

Wenn Sie Verzeichnisse in der vorgeschriebenen Weise verschachteln, hat dies den Vorteil, dass alle relevanten Kontextinformationen zur Entwicklung einer Komponente auf der Ebene der Komponente selbst oder der übergeordneten Ebene verfügbar sind.

Auf der Basis einer solchen logischen Verschachtelung können Entwicklungs- und Integrationsarbeitsbereiche eingerichtet werden, die mit der Gesamtstruktur des Entwicklungsteams verknüpft werden können.

Die Namenskonvention für Arbeitsergebnisse ist in Aufgabe: Richtlinien für das Konfigurationsmanagement festlegen, Schritt: Verfahren für die Konfigurationsidentifizierung beschrieben.