Standard di documentazione

E' garantito il permesso di copiare, distribuire e/o modificare questo documento seguendo i termini della Licenza per Documentazione Libera GNU, Versione 1.1 o ogni versione successiva pubblicata dalla Free Software Foundation. Una copia della licenza è acclusa nella sezione intitolata "Licenza per Documentazione Libera GNU"

Si è cercato di riunire in un unico documento tutta la serie di elaborati cartacei che dovrebbero essere prodotti durante lo sviluppo di un prodotto software di medie dimensioni. Questo documento è dunque una specie di manuale pratico per la redazione dei documenti fondamentali. Si tenga ben presente che esso è nato come strumento di lavoro personale di chi lo ha redatto, per questo molti concetti non sono spiegati ma solo elencati, in una sorta di memento. Chi fosse interessato a capire od approfondire la teoria qui citata dovrà farlo sui diversi testi da cui è tratta.

Per ogni titolo, sia esso capitolo o paragrafo, si è cercato di dare una concisa spiegazione di cosa dovrebbe essere descritto; tali commenti andranno tolti dalla versione definitiva del documento.

Ogni sezione può essere utilizzata sia da sola che in unione alle altre, l’unica regola fissa è che la sezione “Riferimenti” deve essere sempre presente, in quanto in essa sono contenute le informazioni di versione e riferimenti di progetto.

Nel corso del testo, una parte di esso si riferisce ad ipotetici casi di esempio ed un'altra al documento stesso. Questa mescolanza è voluta, per contenere la lunghezza del documento.

Questo testo viene distribuito gratuitamente nella speranza che possa essere di utilità a coloro che si occupano di informatica.

E’ molto gradito ogni tipo di commento su di esso, siano correzioni ortografiche, argomentazioni sui contenuti od integrazioni a parti ingiustamente trascurate.

1.Come utilizzare questo documento 3

2.Sommario 4

3.Software project planning 7

Vision 7

Project Plan 7

Primo stage – n-esimo stage 8

Rilascio 8

4.Analisi del processo 9

Introduzione 9

Overview 9

Input ed output 9

Situazione attuale 9

Descrizione 9

Diagramma situazione attuale 9

Responsabilità 9

Situazione futura 9

Descrizione 9

Diagramma situazione futura 9

Responsabilità 10

Elenco delle differenze 10

5.Piano di sviluppo del software 11

Introduzione 11

Overview 11

Output del progetto 11

Organizzazione del progetto 11

Modello del processo 11

Struttura dell’organizzazione 11

Confini organizzativi ed interfacce 11

Responsabilità del progetto 11

Processo di gestione 12

Obiettivi del management e priorità 12

Assunti, dipendenze e limiti 12

Controllo del rischio 12

Meccanismo di controllo 12

Piano di gestione del personale 12

Processo tecnico 13

Metodi, strumenti e tecniche 13

Documentazione del software 13

Funzioni di supporto 13

Organizzazione del lavoro, schedulazione, budget 13

Struttura del lavoro 13

Dipendenze 13

Risorse necessarie 14

Budget ed allocazione delle risorse 14

Schedulazione 14

Altri componenti ed Appendici 14

6.Procedura di controllo delle modifiche 15

Definizione del ciclo di vita del prodotto 15

Obiettivi del PCM 15

Regole durante lo sviluppo iniziale 15

Regole di accettazione del lavoro 15

Come proporre cambiamenti 15

Valutazione dell’impatto dei cambiamenti 15

Approvazione o rifiuto delle modifiche 16

Definizione del comitato di controllo 16

Sistema di registrazione dei difetti 16

Firme di approvazione 16

7.Piano di controllo del rischio 17

Top 10 17

Quadro di controllo per il rischio x 17

8.Specifica dei Requisiti Software 18

Introduzione 18

Scopo 18

Dominio 18

Definizioni ed abbreviazioni 18

Overview 18

Descrizione generale 18

Prospettiva del prodotto 18

Funzioni del prodotto 19

Caratteristiche utente 19

Limitazioni generali 19

Presupposti e dipendenze 19

Requisiti specifici 19

Interfacce esterne 19

Requisiti funzionali 19

Limitazioni del design 20

Attributi 20

Altri requisiti 20

Stati ed eventi del sistema 20

Stati del sistema 21

Eventi, segnali ed azioni del sistema 21

9.Analisi dei requisiti mediante Casi d’uso 22

Diagrammi dei casi d’uso 22

Nome del caso d’uso: breve frase con verbo in forma attiva 22

Informazioni caratteristiche 22

Scenario principale di successo 22

Estensioni dello scenario 22

Variazioni dello scenario 22

Informazioni correlate 23

Questioni aperte 23

10.Specifica del Design Software 24

Introduzione 24

Pubblico e norme di utilizzo 24

Linee guida 24

Premesse 24

Norme 24

Architettura del sistema 25

Panoramica 25

Elenco dei moduli 25

Relazioni tra moduli 25

Data base 25

Struttura del database 25

Data dictionary 25

Design dettagliato 25

Design dettagliato del sistema 25

Componente 1 – componente n 26

Appendici 26

11.Piano di Test e Validazione 27

Introduzione 27

Piano di test per i componenti 27

Piano di test per il prodotto completo 27

Tracciabilità 27

Test di accettazione e preparazione per la consegna 28

12.Riferimenti 29

Riferimenti di progetto 29

Altri riferimenti 29

Tabella delle revisioni 29

Riferimenti bibliografici 29

13.Licenza per documentazione libera GNU 31

0. PREAMBOLO 31

1. APPLICABILITÀ E DEFINIZIONI 31

2. COPIE LETTERALI 32

3. COPIARE IN NOTEVOLI QUANTITÀ 32

4. MODIFICHE 33

5. UNIONE DI DOCUMENTI 34

6. RACCOLTE DI DOCUMENTI 34

7. RACCOGLIERE INSIEME A LAVORI INDIPENDENTI 35

8. TRADUZIONI 35

9. TERMINI 35

10. REVISIONI FUTURE DI QUESTA LICENZA 35

Prima di intraprendere qualsiasi altra attività, occorre effettuare un planning sia delle attività di sviluppo che del processo stesso di sviluppo. Per questo si consiglia di distinguere in "n" fasi il processo, segnati almeno dai seguenti punti chiave: approvazione della vision, approvazione del project plan, completata fase 1, … completata fase k, rilascio.

Per ogni fase sarà utilizzato un diagramma di Gantt, che elenchi le principali attività relative, con la loro durata e con le persone/entità^¹ che devono portarle a termine.

Lo strumento principale di planning è un programma di project management, di cui esistono in commercio diversi buoni prodotti. In alternativa, è abbastanza facile realizzare semplici diagrammi di Gantt con un qualsiasi spreadsheet.

In questa fase si dovrebbe stendere un piano che ha lo scopo di schedulare le attività ed i prodotti che portano all'approvazione della vision, p.es.:

Si arriva a questa fase quando è stato superato il punto di go/no go. In questa fase si devono pianificare le attività di sviluppo, con particolare attenzione alla divisione in fasi o stage del progetto. Occorre inoltre stabilire un piano di attività da eseguire per portare a termine la prima fase del progetto.

Durante ogni fase, occorre pianificare le attività da compiere per portare a termine la fase successiva. Il planning di ognuna esse, in linea di massima, ha la stessa struttura di quello della prima fase.

Si elencano alcune attività, per memento ed in ordine sparso: specifica tempi per test, per valutazione rischio, per stesura documentazione, per aggiornamento schedulazione, per congelamento database ed interfaccia, per riunioni di valutazione status dello stage, per test di utilizzabilità, per revisioni tecniche, per sviluppo lezioni on-line, per stampa documentazione, per stesura linee guida sviluppatori, per riunioni con utenti, per promozione e marketing, per definizione e stesura specifiche funzionali, per definizione e stesura analisi dei requisiti, … ed in generale per ogni attività che viene citata in questo stesso documento nei prossimi capitoli.

Occorre pianificare anche tutte le attività di rilascio del prodotto, quali: controllo finale di qualità, controllo della documentazione, creazione delle procedure di installazione, manutenzione, addestramento utenti, …

L'analisi del processo serve a descrivere il processo di business in cui il prodotto software dovrà inserirsi. Tale processo potrà essere costituito da un effettivo processo aziendale oppure, in senso lato, in un processo di attività su cui il prodotto software impatterà.

Si descriva brevemente quali siano il dominio del processo nonché gli scopi del vecchio e del nuovo processo.

Si descrivano gli input ed output del processo vecchio e del nuovo, evidenziandone le differenze.

Si descrivano, per la situazione prima dell'introduzione del prodotto software in oggetto, gli obiettivi del processo, le attività di cui è composto ed il suo dominio.

Si elenchino le principali responsabilità, competenze e mansioni coinvolte nel processo originale.

Si descrivano, per la situazione dopo dell'introduzione del prodotto software in oggetto, gli obiettivi del processo, le attività di cui è composto ed il suo dominio.

Si elenchino le principali responsabilità, competenze e mansioni coinvolte nel nuovo processo.

Si elenchino le principali differenze riscontrate tra il processo originale e quello modificato, in maniera da consentire un semplice esame di esse da parte del cliente. Si esaminino, in particolare: nuove mansioni, nuove responsabilità, diminuzioni e/o aumenti di responsabilità per attore, nuove attività, attività cancellabili totalmente o parzialmente, ampliamenti o diminuzioni del dominio del processo, differenze nei costi di processo, differenze nell'efficienza o nell'efficacia.

Queste differenze costituiscono lo strumento principale per uno studio di fattibilità.

Breve sommario degli obiettivi del progetto, del software da consegnare, delle attività principali, …

Lista delle cose da consegnare perché il progetto si possa considerare a buon fine: programmi, file di help, manuali, …, nonché dei mezzi con cui effettuare tale consegna: CD, email, FTP.

Definire anche le quantità necessarie di ogni elemento del prodotto: numero di licenze, di eseguibili, chiavi hardware, supporti software, …

Descrivere quali siano gli obiettivi del management durante il progetto, tra cui:

Elencare presupposti, dipendenze e limitazioni su cui si basa il piano di sviluppo del software.

Descrivere come verrà gestito il rischio, in generale fare esplicito riferimento al “Piano di controllo del rischio”.

Descrivere numero e tipo di personale necessario per condurre a buon fine il progetto, compreso di elenco delle abilità, conoscenze, date di inizio, durata di impiego nel progetto, metodo di reperimento personale, insegnamento e corsi necessari, modalità di uscita dal progetto.

Descrivere gli altri documenti che si riferiscono a funzioni di supporto quali: gestione configurazioni, controllo qualità, documentazione finale per l’utente, ecc.

Identificare e descrivere i pacchetti di lavoro che devono essere completati per realizzare il prodotto. Identificare ogni pacchetto con un ID e mostrare in un diagramma la struttura dei pacchetti (sottopacchetti, ecc.).

Identificare le dipendenze dei pacchetti tra loro e tra pacchetti ed eventi esterni.

Identificare e descrivere le risorse necessarie per settimana o per mese. Descrivere il numero dei computer necessari, il software usato ed il numero delle licenze, gli spazi e le risorse a livello di uffici, i corsi necessari, il budget utilizzato, …

Descrivere come il budget verrà allocato per le differenti funzioni (ingegnerizzazione, controllo qualità, documentazione, gestione, …).

Descrivere la schedulazione per le varie attività e funzioni del progetto, tenendo conto delle dipendenze, delle pietre miliari fissate e delle date di consegna programmate. Esprimere la schedulazione come date assolute oppure come tempi relativi a pietre miliari (es. “firma dei requisiti+60 giorni”).

Includere, p.es.: piani di gestione dei terzisti, piani di assicurazione, piani di istruzione, piani per l’acquisizione dell’ hardware, piani per la gestione degli uffici, ecc.

Definire quale dovrebbe essere il ciclo di vita del prodotto, ovvero le modalità con cui verrà gestita la vita del prodotto durante lo sviluppo e dopo il rilascio.

In questo stadio le regole devono permettere una semplice applicazione dei cambiamenti e delle modifiche necessarie. Definire una modalità di gestione dei cambiamenti semplice e rapida. In generale ci saranno almeno:

Definire le regole per la revisione del lavoro fatto in funzione di determinarne la completezza.

Descrivere come proporre i cambiamenti, in sostanza dovrebbero essere identificati almeno:

Il comitato di controllo approva o rifiuta le modifiche. In ogni caso occorre registrare:

Seguono esempi dei due strumenti di base per gestire un piano di controllo del rischio. Per indicazioni di cosa sia e come fare, vedere [10].

Per ogni rischio, definire: perché esso costituisca un rischio per il progetto, come trovare un modo di eliminare od abbassare tale rischio, cosa fare praticamente per affrontarlo e chi deve farlo.

Quando una parte qualsiasi di questo documento dovesse cambiare, è imperativo assicurarsi che i necessari aggiustamenti vengano fatti al piano di sviluppo, al prodotto ed alle attività correlate.

Le persone che devono utilizzare questo documento dovrebbero essere istruite per farlo, inoltre sarebbe necessario definire formalmente il modo di eseguire una specifica dei requisiti, in maniera da impostare un processo ripetibile che possa essere condiviso da tutte le parti.

Ogni modifica, inclusione o cancellazione di requisiti deve essere misurata, in linea di massima indicando numero e gravità delle modifiche, aggiunte, cancellazioni, …

Infine questo stesso documento dovrebbe essere soggetto alla verifica del Controllo Qualità.

Identificare il prodotto software che deve essere sviluppato e l’ambiente ad esso circostante.

Includere definizioni e abbreviazioni che saranno usate, per facilitare la lettura dei punti seguenti.

Descrivere il prodotto in relazione a: prodotti similari, sistema che lo contiene, interfaccia con l’ambiente esterno, esistente hardware, …

Breve descrizione delle funzioni che il software deve eseguire. Questa descrizione deve essere in una forma comprensibile anche dal cliente/utente.

Descrivere i requisiti dell’interfaccia utente (non solo grafica, ma anche logica, di input, in termini di operazioni da svolgere tipo stampe ecc.) basandosi sulle caratteristiche del target di utenti.

Limitazioni imposte da altre fonti che non siano l’interfaccia umana, del tipo: lim. hardware, lim. interfacciamento con altre applicazioni, …)

Elencare i presupposti fondamentali o le dipendenze su cui si basa il prodotto, p.es. ambiente di esecuzione, sistema operativo, ….

Elencare e descrivere le interfacce con l’utente, con le altre applicazioni e con eventuali sistemi esterni. Si elenchino tra l’altro: input ed output del sistema, compresi di accuratezza, range di valori, frequenza; report necessari e loro formato, interfacce di comunicazione con relativi protocolli; …

Per ogni requisito funzionale, descrivere: scopo, descrizione, input, modo di elaborazione dal punto di vista dell’output, …

Elencare: numero di connessioni al sistema, di utenti concorrenti, tempo di risposta necessario, numero di file, dimensioni di file e table, numero di transazioni per intervallo.

Elencare limitazioni dovute all’ hardware, agli standard, alla capacità dei programmatori.

Elencare voci quali: sicurezza, disponibilità, affidabilità, manutenibilità, occupazione di memoria normale e massima, spazio su disco (storage), …; devono essere specificate in modo da poterne poi misurare la realizzazione nel prodotto finito.

Questa parte dell’analisi dei requisiti serve a definire quali siano gli stati principali che deve attraversare il sistema, nonché quali siano gli eventi o segnali o azioni che causano un cambiamento di stato.

Identificare gli stati che attraversa il sistema, utilizzando diagrammi di stato UML. Concentrare l’attenzione sugli stati del processo/sistema e non su di una sua implementazione, che potrà avere un numero completamente diverso di stati.

Descrivere gli eventi oppure i segnali ovvero le azioni che provocano un cambiamento di stato nel sistema. Infine tracciare uno o più diagrammi di stato UML che descrivano con completezza questo aspetto del sistema.

Questa proposta di modulo serve per annotare le richieste utente che nascono tipicamente da riunioni od interviste con utenti e key user. E' uno strumento da usare per definire i requisiti e per i rapporti con i clienti.

Descrizione: Non si ritiene molto comoda la gestione di tale campo in DIBA (poco automatica, poco evidente, ...) e si richiede una sua sofisticazione. Rif. Industrializzazione.

I punti che seguono, riguardanti i casi d’uso, vanno utilizzati se si vuole effettuare una analisi di questo tipo. Per approfondimenti sulla teoria, vedere [12] e [7].

Qui vanno disegnati i diagrammi use case, badando a riportare tutti quelli che poi verranno affrontati in dettaglio.

Per ogni caso d’uso sarà presente una sezione come la presente, in cui si riportano i punti che devono essere affrontati.

Dare una panoramica dell’intero documento, tra cui: scopi, dominio, utenti di riferimento del documento, sistema in oggetto, riferimenti necessari ad altri documenti, …

Panoramica della struttura dei moduli e componenti: utilizzare i seguenti diagrammi UML: deployment diagr., components diagr.. A questo dettaglio non entrare nei particolari (utilizzare max. 10-12 nodi).

Elenco dei moduli, riportando per ogni modulo una descrizione della sua funzione principale, eventuale pseudo codice di esempio associato.

PDM ovvero diagrammi ER della struttura del database o della parte del database interessata. E’ possibile usare anche diagrammi UML che descrivano la struttura logica e fisica del database (si confronti “UML User Guide”).

Data Dictionary, con almeno: ID record, descrizione del dato, alias o acronimi, lista dei moduli che lo utilizzano, definizione del formato, informazioni addizionali quali valori iniziali, di default, limiti, …

Per ogni componente (p.e. file, programma, procedura, SQL, modulo, classe, package, interattivo, batch, video,…), seguono i punti da esaminare:

Se il componente contiene classi, o se è una classe, disegnare il diagramma di classe (od oggetti), il diagramma di sequenza dei casi d’uso principali, … .

Il piano di test è strettamente legato al documento “Specifica dei Requisiti Software”. In effetti dovrebbe essere definito durante la fase di analisi dei requisiti, di modo che durante tutto lo sviluppo già esista una serie di test a cui sottoporre il prodotto. La matrice di tracciabilità serve proprio a questo scopo, essa collega i requisiti ai corrispondenti test.

Elencare le procedure di test da effettuare prima di considerare consegnabile il prodotto, nonché quanto è necessario controllare prima di spedire (od installare) il prodotto.

Archiviazione documenti del progetto: indicare dove sono archiviati i documenti del progetto

Osservazioni: spedire eventuali osservazioni sul presente documento a info@projectoo.com

Una certa parte del materiale presente in questo documento deriva da traduzioni ed adattamenti dai seguenti riferimenti:

[1] V.L. Almstrum - Project Documentation Standards - The University of Texas at Austin

[6] B. Appleton – Software Design Specification – Construx Software Builders

[7] Cockburn - "Structuring Use Cases with Goals", Journal of Object-Oriented Programming, September/November 1997

[8] D.Zubrow et al. - Maturity Questionnaire Special Report CMU/SEI-94-SR-7 - Software Engineering Institute, Carneige Mellon University, 1994

[9] R.Pressman – Software engineering, a practicioneer approach – Addison Wesley, 1992

[10] S. McConnell – Software Projects Survival Guide – Microsoft Press, 1998

[12] G.Schneider, J.P.Winters - Applying use cases, a pratical guide – Addison-Wesley, 1998

[13] The Samuel Brooks Corporation – Microsoft Solution Framework Gantt Chart Builder – Microsoft, 1998

[14] W.S.Junk – Outline for the Software Requirements Specification – Computer Science Dept., University of Idaho, 1998

Lo scopo di questa licenza è di rendere un manuale, un testo o altri documenti scritti "liberi" nel senso di assicurare a tutti la libertà effettiva di copiarli e redistribuirli, con o senza modifiche, a fini di lucro o no. In secondo luogo questa licenza prevede per autori ed editori il modo per ottenere il giusto riconoscimento del proprio lavoro, preservandoli dall'essere considerati responsabili per modifiche apportate da altri.

Questa licenza è un "copyleft": ciò vuol dire che i lavori che derivano dal documento originale devono essere ugualmente liberi. è il complemento alla Licenza Pubblica Generale GNU, che è una licenza di tipo "copyleft" pensata per il software libero.

Abbiamo progettato questa licenza al fine di applicarla alla documentazione del software libero, perché il software libero ha bisogno di documentazione libera: un programma libero dovrebbe accompagnarsi a manuali che forniscano la stessa libertà del software. Ma questa licenza non è limitata alla documentazione del software; può essere utilizzata per ogni testo che tratti un qualsiasi argomento e al di là dell'avvenuta pubblicazione cartacea. Raccomandiamo principalmente questa licenza per opere che abbiano fini didattici o per manuali di consultazione.

Questa licenza si applica a qualsiasi manuale o altra opera che contenga una nota messa dal detentore del copyright che dica che si può distribuire nei termini di questa licenza. Con "Documento", in seguito ci si riferisce a qualsiasi manuale o opera. Ogni fruitore è un destinatario della licenza e viene indicato con "voi".

Una "versione modificata" di un documento è ogni opera contenente il documento stesso o parte di esso, sia riprodotto alla lettera che con modifiche, oppure traduzioni in un'altra lingua.

Una "sezione secondaria" è un'appendice cui si fa riferimento o una premessa del documento e riguarda esclusivamente il rapporto dell'editore o dell'autore del documento con l'argomento generale del documento stesso (o argomenti affini) e non contiene nulla che possa essere compreso nell'argomento principale. (Per esempio, se il documento è in parte un manuale di matematica, una sezione secondaria non può contenere spiegazioni di matematica). Il rapporto con l'argomento può essere un tema collegato storicamente con il soggetto principale o con soggetti affini, o essere costituito da argomentazioni legali, commerciali, filosofiche, etiche o politiche pertinenti.

Le "sezioni non modificabili" sono alcune sezioni secondarie i cui titoli sono esplicitamente dichiarati essere sezioni non modificabili, nella nota che indica che il documento è realizzato sotto questa licenza.

I "testi copertina" sono dei brevi brani di testo che sono elencati nella nota che indica che il documento è realizzato sotto questa licenza.

Una copia "trasparente" del documento indica una copia leggibile da un calcolatore, codificata in un formato le cui specifiche sono disponibili pubblicamente, i cui contenuti possono essere visti e modificati direttamente, ora e in futuro, con generici editor di testi o (per immagini composte da pixel) con generici editor di immagini o (per i disegni) con qualche editor di disegni ampiamente diffuso, e la copia deve essere adatta al trattamento per la formattazione o per la conversione in una varietà di formati atti alla successiva formattazione. Una copia fatta in un altro formato di file trasparente il cui markup è stato progettato per intralciare o scoraggiare modifiche future da parte dei lettori non è trasparente. Una copia che non è trasparente è "opaca".

Esempi di formati adatti per copie trasparenti sono l'ASCII puro senza markup, il formato di input per Texinfo, il formato di input per LaTex, SGML o XML accoppiati ad una DTD pubblica e disponibile, e semplice HTML conforme agli standard e progettato per essere modificato manualmente. Formati opachi sono PostScript, PDF, formati proprietari che possono essere letti e modificati solo con word processor proprietari, SGML o XML per cui non è in genere disponibile la DTD o gli strumenti per il trattamento, e HTML generato automaticamente da qualche word processor per il solo output.

La "pagina del titolo" di un libro stampato indica la pagina del titolo stessa, più qualche pagina seguente per quanto necessario a contenere in modo leggibile, il materiale che la licenza prevede che compaia nella pagina del titolo. Per opere in formati in cui non sia contemplata esplicitamente la pagina del titolo, con "pagina del titolo" si intende il testo prossimo al titolo dell'opera, precedente l'inizio del corpo del testo.

Si può copiare e distribuire il documento con l'ausilio di qualsiasi mezzo, per fini di lucro e non, fornendo per tutte le copie questa licenza, le note sul copyright e l'avviso che questa licenza si applica al documento, e che non si aggiungono altre condizioni al di fuori di quelle della licenza stessa. Non si possono usare misure tecniche per impedire o controllare la lettura o la produzione di copie successive alle copie che si producono o distribuiscono. Però si possono ricavare compensi per le copie fornite. Se si distribuiscono un numero sufficiente di copie si devono seguire anche le condizioni della sezione 3.

Si possono anche prestare copie e con le stesse condizioni sopra menzionate possono essere utilizzate in pubblico.

Se si pubblicano a mezzo stampa più di 100 copie del documento, e la nota della licenza indica che esistono uno o più testi copertina, si devono includere nelle copie, in modo chiaro e leggibile, tutti i testi copertina indicati: il testo della prima di copertina in prima di copertina e il testo di quarta di copertina in quarta di copertina. Ambedue devono identificare l'editore che pubblica il documento. La prima di copertina deve presentare il titolo completo con tutte le parole che lo compongono egualmente visibili ed evidenti. Si può aggiungere altro materiale alle copertine. Il copiare con modifiche limitate alle sole copertine, purché si preservino il titolo e le altre condizioni viste in precedenza, è considerato alla stregua di copiare alla lettera.

Se il testo richiesto per le copertine è troppo voluminoso per essere riprodotto in modo leggibile, se ne può mettere una prima parte per quanto ragionevolmente può stare in copertina, e continuare nelle pagine immediatamente seguenti.

Se si pubblicano o distribuiscono copie opache del documento in numero superiore a 100, si deve anche includere una copia trasparente leggibile da un calcolatore per ogni copia o menzionare per ogni copia opaca un indirizzo di una rete di calcolatori pubblicamente accessibile in cui vi sia una copia trasparente completa del documento, spogliato di materiale aggiuntivo, e a cui si possa accedere anonimamente e gratuitamente per scaricare il documento usando i protocolli standard e pubblici generalmente usati. Se si adotta l'ultima opzione, si deve prestare la giusta attenzione, nel momento in cui si inizia la distribuzione in quantità elevata di copie opache, ad assicurarsi che la copia trasparente rimanga accessibile all'indirizzo stabilito fino ad almeno un anno di distanza dall'ultima distribuzione (direttamente o attraverso rivenditori) di quell'edizione al pubblico.

è caldamente consigliato, benché non obbligatorio, contattare l'autore del documento prima di distribuirne un numero considerevole di copie, per metterlo in grado di fornire una versione aggiornata del documento.

Si possono copiare e distribuire versioni modificate del documento rispettando le condizioni delle precedenti sezioni 2 e 3, purché la versione modificata sia realizzata seguendo scrupolosamente questa stessa licenza, con la versione modificata che svolga il ruolo del "documento", così da estendere la licenza sulla distribuzione e la modifica a chiunque ne possieda una copia. Inoltre nelle versioni modificate si deve:

Se la versione modificata comprende nuove sezioni di primaria importanza o appendici che ricadono in "sezioni secondarie", e non contengono materiale copiato dal documento, si ha facoltà di rendere non modificabili quante sezioni si voglia. Per fare ciò si aggiunga il loro titolo alla lista delle sezioni immutabili nella nota di copyright della versione modificata. Questi titoli devono essere diversi dai titoli di ogni altra sezione.

Si può aggiungere una sezione intitolata "Riconoscimenti", a patto che non contenga altro che le approvazioni alla versione modificata prodotte da vari soggetti--per esempio, affermazioni di revisione o che il testo è stato approvato da una organizzazione come la definizione normativa di uno standard.

Si può aggiungere un brano fino a cinque parole come Testo Copertina, e un brano fino a 25 parole come Testo di Retro Copertina, alla fine dell'elenco dei Testi Copertina nella versione modificata. Solamente un brano del Testo Copertina e uno del Testo di Retro Copertina possono essere aggiunti (anche con adattamenti) da ciascuna persona o organizzazione. Se il documento include già un testo copertina per la stessa copertina, precedentemente aggiunto o adattato da voi o dalla stessa organizzazione nel nome della quale si agisce, non se ne può aggiungere un altro, ma si può rimpiazzare il vecchio ottenendo l'esplicita autorizzazione dall'editore precedente che aveva aggiunto il testo copertina.

L'autore/i e l'editore/i del "documento" non ottengono da questa licenza il permesso di usare i propri nomi per pubblicizzare la versione modificata o rivendicare l'approvazione di ogni versione modificata.

Si può unire il documento con altri realizzati sotto questa licenza, seguendo i termini definiti nella precedente sezione 4 per le versioni modificate, a patto che si includa l'insieme di tutte le Sezioni Invarianti di tutti i documenti originali, senza modifiche, e si elenchino tutte come Sezioni Invarianti della sintesi di documenti nella licenza della stessa.

Nella sintesi è necessaria una sola copia di questa licenza, e multiple sezioni invarianti possono essere rimpiazzate da una singola copia se identiche. Se ci sono multiple Sezioni Invarianti con lo stesso nome ma contenuti differenti, si renda unico il titolo di ciascuna sezione aggiungendovi alla fine e fra parentesi, il nome dell'autore o editore della sezione, se noti, o altrimenti un numero distintivo. Si facciano gli stessi aggiustamenti ai titoli delle sezioni nell'elenco delle Sezioni Invarianti nella nota di copiright della sintesi.

Nella sintesi si devono unire le varie sezioni intitolate "storia" nei vari documenti originali di partenza per formare una unica sezione intitolata "storia"; allo stesso modo si unisca ogni sezione intitolata "Ringraziamenti", e ogni sezione intitolata "Dediche". Si devono eliminare tutte le sezioni intitolate "Riconoscimenti".

Si può produrre una raccolta che consista del documento e di altri realizzati sotto questa licenza; e rimpiazzare le singole copie di questa licenza nei vari documenti con una sola inclusa nella raccolta, solamente se si seguono le regole fissate da questa licenza per le copie alla lettera come se si applicassero a ciascun documento.

Si può estrarre un singolo documento da una raccolta e distribuirlo individualmente sotto questa licenza, solo se si inserisce una copia di questa licenza nel documento estratto e se si seguono tutte le altre regole fissate da questa licenza per le copie alla lettera del documento.

Una raccolta del documento o sue derivazioni con altri documenti o lavori separati o indipendenti, all'interno di o a formare un archivio o un supporto per la distribuzione, non è una "versione modificata" del documento nella sua interezza, se non ci sono copiright per l'intera raccolta. Ciascuna raccolta si chiama allora "aggregato" e questa licenza non si applica agli altri lavori contenuti in essa che ne sono parte, per il solo fatto di essere raccolti insieme, qualora non siano però loro stessi lavori derivati dal documento.

Se le esigenze del Testo Copertina della sezione 3 sono applicabili a queste copie del documento allora, se il documento è inferiore ad un quarto dell'intero aggregato i Testi Copertina del documento possono essere piazzati in copertine che delimitano solo il documento all'interno dell'aggregato. Altrimenti devono apparire nella copertina dell'intero aggregato.

La traduzione è considerata un tipo di modifica, e di conseguenza si possono distribuire traduzioni del documento seguendo i termini della sezione 4. Rimpiazzare sezioni non modificabili con traduzioni richiede un particolare permesso da parte dei detentori del diritto d'autore, ma si possono includere traduzioni di una o più sezioni non modificabili in aggiunta alle versioni originali di queste sezioni immutabili. Si può fornire una traduzione della presente licenza a patto che si includa anche l'originale versione inglese di questa licenza. In caso di discordanza fra la traduzione e l'originale inglese di questa licenza la versione originale inglese prevale sempre.

Non si può applicare un'altra licenza al documento, copiarlo, modificarlo, o distribuirlo al di fuori dei termini espressamente previsti da questa licenza. Ogni altro tentativo di applicare un'altra licenza al documento, copiarlo, modificarlo, o distribuirlo è deprecato e pone fine automaticamente ai diritti previsti da questa licenza. Comunque, per quanti abbiano ricevuto copie o abbiano diritti coperti da questa licenza, essi non ne cessano se si rimane perfettamente coerenti con quanto previsto dalla stessa.

La Free Software Foundation può pubblicare nuove, rivedute versioni della Licenza per Documentazione Libera GNU volta per volta. Qualche nuova versione potrebbe essere simile nello spirito alla versione attuale ma differire in dettagli per affrontare nuovi problemi e concetti. Si veda http://www.gnu.org/copyleft.

Ad ogni versione della licenza viene dato un numero che distingue la versione stessa. Se il documento specifica che si riferisce ad una versione particolare della licenza contraddistinta dal numero o "ogni versione successiva", si ha la possibilità di seguire termini e condizioni sia della versione specificata che di ogni versione successiva pubblicata (non come bozza) dalla Free Software Foundation. Se il documento non specifica un numero di versione particolare di questa licenza, si può scegliere ogni versione pubblicata (non come bozza) dalla Free Software Foundation.

Questa Sett.	Scorsa Sett.	Sett. In lista	Rischio	Progresso nella Risoluzione del rischio

Perché?
Come?
Cosa fare?
Chi?

ID	Descrizione	Voto	Riferimento
1	Inserire qui la descrizione del requisito, a cui si darà un voto con la seguente convenzione: tre = imprescindibile; due = importante ; uno = secondario ; nulla = non definito	3	Nome utente o cliente che ha richiesto il requisito
2	Inserire qui la descrizione del requisito …	2
3	Inserire qui la descrizione del requisito …	1
4	Inserire qui la descrizione del requisito …

ID	Descrizione	Voto	Riferimento
1	Inserire qui la descrizione del requisito, a cui si darà un voto con la seguente convenzione: tre = imprescindibile; due = importante ; uno = secondario ; nulla = non definito	3	Nome utente o cliente che ha richiesto il requisito
2	Inserire qui la descrizione del requisito …	2
3	Inserire qui la descrizione del requisito …	1
4	Inserire qui la descrizione del requisito …

ID	Descrizione	Voto	Riferimento
1	Inserire qui la descrizione del requisito, a cui si darà un voto con la seguente convenzione: tre = imprescindibile; due = importante ; uno = secondario ; nulla = non definito	3	Nome utente o cliente che ha richiesto il requisito
2	Inserire qui la descrizione del requisito …	2
3	Inserire qui la descrizione del requisito …	1
4	Inserire qui la descrizione del requisito …

Prodotto	Persone che devono firmare il prodotto perché sia definito consegnabile.

Obiettivo :
Ambito :
Livello :
Requisiti :
Condizioni di successo :
Cond. di fallimento :
Attore primario :
Evento scatenante :

Schedulazione :
Priorità :
Performance :
Frequenza :
Super Caso d’uso :
Sotto Caso d’uso :
Canale all’attore principale :
Attori secondari :
Canali agli attori secondari :

Versione	Autore Principale	Descrizione della versione	Completata
0.1	MP	Prima bozza	12/01/99
0.2	MP	Prima versione generica
0.8	MP	Versione beta, distribuita ad Iniziativa Progetti – prima versione utilizzabile
0.94	MP	Versione beta2 – inserita parte su processo e marketing, rifatta la parte sul design	02/02/99
0.98	MP	Versione beta3 – revisione generale	16/02/99
0.99	MP	Versione beta4 – modifiche varie, in special modo specifica del design	17/02/99
1.00	MP	Release ufficiale – revisione generale, preparazione per la pubblicazione su Web	18/02/99
2 alfa	MP	Inizio della versione n.2	27/03/99
2 alfa	MP	SRS, voto ed altre minori	06/05/99
2 alfa	MP	Conversione Word 2000, aggiornamento riferimenti, vari interventi minori.	08/09/99
2 beta	MP	Creazione capitolo su use case, controllo sezione SRS, interventi vari	19/09/99
2 beta 2	MP	Riordino capitoli, sistemazione project planning	26/09/99
2 beta 3	MP	Revisione	28/09/99
2.00	MP	Versione ufficiale 2.00 – pubblicata su www.projectoo.com	30/09/99
2.50 alfa	MP	Inizio sviluppo nuova versione	13/07/00
3 alfa	MP	Versione GNU – modifica layout – revisione e semplificazione delle sezioni	03/05/02
3 beta	MP	Aggiunto template richiesta utente – revisioni varie	10/05/02

Persona	Responsabilità/Competenze/Mansioni

Persona	Responsabilità/Competenze/Mansioni

Responsabilità	Persona

Passo	Condizione	Descrizione dell’azione