Concetto: Struttura della directory del prodotto
Una struttura di directory di prodotto contiene la directory gerarchica e le directory secondarie delle cartelle e dei file utilizzati per memorizzare i prodotti di lavoro relativi al progetto.
Relazioni
Elementi correlati
Descrizione principale

La struttura della directory del prodotto viene utilizzata come segnaposto nidificato logicamente per tutti i prodotti di lavoro in grado di ricevere una versione e relativi al progetto. I prodotti di lavoro vengono prodotti come risultato del successivo ciclo di vita del processo di sviluppo e per lo sviluppo di ogni elemento di implementazione che costituisce l'intero sistema.

La seguente figura mostra il sistema X formato da "N" sistemi secondari e ognuno di questi formato da "N" componenti. La struttura della directory del prodotto fornisce un segnalibro comune per i vari prodotti di lavoro richiesti per lo sviluppo di ogni parte dell'intero sistema.

Struttura della directory a livello di componente Struttura della directory a livello di sottosistema Struttura della directory del prodotto di sistema Diagramma descritto nella tabella precedente.

Struttura della directory del prodotto di sistema

Anche se un architetto del software con esperienza può avere all'inizio una buona idea sulla composizione del sistema, la visione dei componenti principali dello sviluppo emerge come conseguenza dell'analisi & delle attività correlate al progetto per definire e perfezionare le architetture candidate.

La successiva tabella fornisce un modello di scrittura della directory del sistema del prodotto che potrebbe essere utilizzata come "struttura di directory di prodotto" nelle fasi iniziali dello sviluppo del progetto mentre i dettagli precisi dei sottosistemi compositi e della strutturazione a livelli architetturale devono essere ancora determinati.

>Struttura della directory del prodotto a livello di sistema

Requisiti di sistema

Modelli

Modello del caso d'uso Pacchetto di casi d'uso
Database Attributi dei requisiti
Documenti Visione
Glossario
Richieste degli stakeholder
Specifiche supplementari
Specifiche del requisito software
Storyboard

Report

Report: Valutazione del modello del caso d'uso
Report: Specifica di caso d'uso
Progettazione e implementazione del sistema Modelli Modello di analisi Realizzazione caso d'uso
Modello di progettazione Sottosistema di progettazione
Interfaccia
Pacchetto di progettazione
Modello di dati
Documento di analisi del carico di lavoro
Prototipo dell'interfaccia utente
Documenti Documento dell'architettura software
Report: Valutazione del modello di progettazione
Mappa di esplorazione
Sottosistema 1 Struttura della directory di sottosistema
Sottosistema N Struttura della directory di sottosistema
Integrazione del sistema Piani Piano di build di integrazione
Librerie  
Test di sistema Piano di test Suite di test
Scenari di test Script di test
Dati del test  
Risultati del test  
Distribuzione di sistema Piano di distribuzione  
Documenti Note di rilascio
Manual Materiale di supporto per l'utente
Materiali per la formazione
Artefatti di installazione  
Gestione di sistema Piani Piano di sviluppo software
Piano di iterazione Piano di gestione dei requisiti
Elenco dei rischi Piano di gestione dei rischi
Caso di sviluppo Piano di infrastruttura
Piano di accettazione del prodotto Piano di gestione configurazione
Piano di documentazione Piano QA
Piano di risoluzione dei problemi Piano di gestione dei subappaltatori
Piano di miglioramento del processo Piano di misurazione
Valutazioni Valutazione dell'iterazione
Valutazione dello sviluppo dell'organizzazione
Valutazione dello stato
Tool Tool di ambiente di sviluppo Editor
Compilatori
Tool di gestione di configurazione Rational ClearCase
Tool di gestione dei requisiti Rational RequisitePro
Tool di modellazione visiva Rational Rose
Tool di test Rational Test Factory
Tracciamento difetto Rational ClearQuest
Standard e linee guida Requisiti Attributi dei requisiti
Linee guida specifiche per il programma
Progettazione Linee guida specifiche per il programma
Implementazione Linee guida specifiche per il programma
Documentazione Guida allo stile dei manuali

Una volta che le attività di analisi & progettazione sono attive e c'è una migliorata comprensione sul numero e la natura dei sottosistemi richiesti in tutto il sistema (Compito: Progettazione di sottosistema), la struttura della directory del prodotto deve essere ampliata per ospitare ogni sottosistema.

Le informazioni presenti nella struttura della directory del prodotto di sistema devono essere visibili a tutti i sottosistemi del progetto. Così oltre all'amministrazione del prodotto, gli standard e le linee guida delle informazioni di test e di requisiti farebbero parte della struttura della directory di prodotto di sistema. In questo caso, i tool sono inclusi nella struttura della directory del prodotto di sistema, tuttavia potrebbero essere a un livello di directory più elevato, dove un numero di sistemi potrebbe utilizzare lo stesso insieme di tool.

Struttura della directory di sottosistema

Le informazioni presenti nella struttura della directory di sottosistema di prodotto sono in relazione diretta con lo sviluppo di quel particolare sottosistema. Il numero delle creazioni di istanze della struttura della directory di prodotto di sottosistema è collegato chiaramente con il numero di sottosistemi stabiliti come conseguenza delle attività di analisi & progettazione. Ad esempio, il sistema y può avere tre sottosistemi (sottosistema A, sottosistema B e sottosistema C). Ogni sottosistema dispone delle informazioni necessarie per la sua progettazione ed eventuale implementazione.

Una suddivisione generalizzata della struttura della directory del prodotto di sottosistema è la seguente:

Struttura della directory di prodotto a livello di sottosistema

Requisiti del sottosistema N

Modelli Modello del caso d'uso Pacchetto di casi d'uso
Storyboard
Caso d'uso (testo)
Prototipo dell'interfaccia utente
Database Attributi dei requisiti
Documenti Visione
Glossario
Richieste degli stakeholder
Specifiche supplementari
Specifiche del requisito software
Storyboard

Report

Report: Valutazione del modello del caso d'uso
Report: Specifica di caso d'uso
Progettazione e implementazione del sottosistema N Modelli Modello di analisi Realizzazione caso d'uso
Modello di progettazione Pacchetti di progettazione
Pacchetti di interfaccia
Pacchetti di test
Modello di implementazione
Modello di dati
Modello di carico di lavoro
Documenti Documento dell'architettura software
Report: Valutazione del modello di progettazione
Mappa di esplorazione

Report

Report: Realizzazione di caso d'uso

Componente 1

Directory del componente 1

Componente N

Directory del componente N
Integrazione del sottosistema N Piani Piano di build di integrazione
Librerie  
Test del sottosistema N Piano di test Suite di test
Scenari di test Script di test
Risultati del test  
Dati del test  

Struttura della directory del componente

Il numero di componenti è conseguenza delle decisioni di progettazione del sottosistema. La struttura di directory seguente deve essere istanziata per ogni componente da sviluppare.

Un vantaggio delle directory di nidificazione così stabilite è quello che tutte le informazioni contestuali collegate allo sviluppo di un componente sono disponibili, sia allo stesso livello che a un livello superiore.

Questo tipo di nidificazione logica offre un miglioramento nella configurazione degli spazi di lavoro di sviluppo e integrazione che possono essere collegati alla completa struttura del team di sviluppo.

La convenzione per la denominazione dei prodotti di lavoro viene descritta in Compito: Stabilire politiche CM, Fase: Definire le pratiche di identificazione di configurazione