Fasi di revisione del progetto Revisione dei requisiti (comunicazione e pianificazione) Revisione della specifica architetturale Revisione della codifica e collaudo Accettazione (esame finale)
Documentazione Tutti i documenti dovranno contenere Il nome e logo della società L elenco dei nominativi dei redattori, con le rispettive firme e la data L elenco dei nominativi di chi ha approvato il documento con le rispettive firme e la data L oggetto del contenuto ed eventualmente un sommario La versione con il registro delle modifiche apportate con i vari riferimenti, il numero e la data Le pagine dei documenti devono essere numerate progressivamente, indicando sempre anche il totale delle pagine (es: pag. 4 di 10)
Attenzione! Nell ottica di avvalersi della documentazione come supporto al processo di sviluppo del software, essa deve essere redatta durante lo svolgimento del progetto stesso e non al termine dello stesso solo al fine di completare il pacchetto software IMPORTANTE AL FINE DELLA VALUTAZIONE DEL PROGETTO
Organizzazione dei gruppi 1 Ogni gruppo di lavoro rappresenta una società (anche cooperativa). Una volta ricevuta una richiesta per la realizzazione di un sistema software, esso deve impegnarsi ad individuare il direttore generale responsabile del progetto (project manager)
Organizzazione dei gruppi 2 Una volta che il project manager ha avuto l incarico, provvede alla stesura dell elenco dei documenti necessari allo svolgimento del progetto, che devono tenere traccia scritta di tutte le attività di progetto. Tale documentazione deve consentire alla direzione di pianificare e controllare lo svolgimento del progetto, ma anche di analizzare a posteriori ciò che è accaduto, in un ottica di miglioramento sia dell organizzazione che del processo di produzione del software
Elenco documenti 1 Documentazione inerente il management del progetto: Organigramma Diario di progetto Verbale Piano di progetto Norme di progetto Offerta Piano di gestione della qualità
Elenco documenti 2 Documentazione del progetto Analisi del dominio Analisi dei requisiti Specifica architetturale Specifica di dettaglio Piano delle prove Risultati delle prove Manuale d uso
Inoltre Ogni documento redatto dal gruppo di progetto deve comparire nel diario di progetto, purché sia stato preventivamente approvato Poiché la verifica ispettiva terrà conto solo ed esclusivamente dei documenti elencati nel diario di progetto, è fondamentale che il project manager lo mantenga costantemente aggiornato
Organigramma E un documento non versionato, redatto dal project manager prima dell inizio delle attività del gruppo. Contiene la descrizione dei ruoli assegnati ai membri del gruppo esecutivo di progetto. Il documento prevede una parte per eventuali annotazioni utili a spiegare la ripartizione dei ruoli e una breve descrizione delle conoscenze e delle competenze di ogni membro del progetto. L assegnazione dei ruoli ai singoli membri è indicativa e può essere cambiata durante lo svolgimento del progetto. Tutti i membri del gruppo devono firmare questo documento, nella parte relativa all accettazione dei ruoli indicati. La parte relativa all approvazione comprende anche il docente che, firmando questo documento, prende atto della composizione del gruppo (in termini di numero di membri) e dell assegnazione dei ruoli. Casi molto particolari di variazione dell organigramma (in termini della sua composizione) devono essere segnalati immediatamente al docente che valuterà la variazione proposta ed, eventualmente, provvederà all approvazione di un nuovo organigramma.
Diario di progetto Rappresenta il registro ufficiale della documentazione del progetto. Contiene l elenco di tutti i movimenti, in entrata ed in uscita, relativi all archivio di progetto (che può contenere documenti e prodotti). Ogni movimento è caratterizzato dalla data in cui avviene, dalla descrizione e dal riferimento univoco e dalla versione del documento (o del prodotto), dal nominativo e dal ruolo del consegnatario o ricevente. I documenti entranti nell archivio devono essere approvati dal project manager.
Verbale Le riunioni del gruppo, sia quelle interne sia quelle con il committente, devono essere verbalizzate. Il verbale è un documento non versionato, utilizzato per riportare sinteticamente gli argomenti discussi durante una riunione. Gli elementi caratterizzanti di un verbale sono la data e il luogo in cui si è tenuta la riunione, l indicazione di chi ha redatto il verbale (nome, cognome, data di redazione), persone presenti alla riunione (nome, cognome e ruolo ricoperto nella riunione), ordine del giorno, discussione degli argomenti elencati nell ordine del giorno. Il verbale deve essere firmato dal redattore e da tutti gli intervenuti. L ordine del giorno guida lo svolgimento di una riunione. È buona norma stabilire l ordine del giorno prima della riunione (di solito si convoca una riunione comunicando contestualmente l ordine del giorno) e seguirlo durante la riunione stessa. Se si ritiene che l ordine di discussione stabilito prima della riunione non è più idoneo alle esigenze della discussione è possibile cambiarlo nel corso della riunione.
Piano di progetto È un documento versionato, redatto dal project manager per poter stimare realisticamente le risorse, i costi e i tempi necessari alla realizzazione del progetto. Il piano di progetto si divide in due parti, pianificazione e consuntivazione, per rendere possibile la pianificazione delle attività future e il riscontro tangibile tra le attività effettuate e quelle previste. Il piano di progetto è un documento che varia nel tempo a seconda delle situazioni e dell evolversi delle attività portate avanti dai membri. Una parte del documento, il registro delle modifiche, tiene traccia delle variazioni apportate al piano, registrando la data delle modifiche e la versione del piano. Il piano del progetto contiene la descrizione delle attività pianificate 1. Definizione degli obiettivi 2. Analisi dei rischi (piano gestione rischi, sintesi rischi individuati e strategie di prevenzione) 3. Descrizione del modello di processo di sviluppo Descrizione fasi (milestones) del processo 4. Stima dei costi 5. Attività di progetto (Work Breakdown Structure, Diagramma di Gantt) 6. Consuntivo attività 7. Strumenti utilizzati La documentazione inerente il controllo del progetto prevede almeno (1) una tabella nella quale per ogni attività si evincano i partecipanti con i rispettivi monte ore, (2) una tabella nella quale per ogni membro del gruppo si evincano le attività a cui egli ha preso parte ed il totale numero di ore di lavoro.
Norme di progetto 1 Le attività di progetto si svolgono nel rispetto di norme stabilite nella fase iniziale del progetto. Il documento che le contiene è versionato, ed è redatto dal project manager. La sua struttura è articolata come segue. 1. Convenzioni generali Documentazione del progetto Dove è mantenuta la documentazione del progetto. Quali convenzioni si usano per identificarla, redarne e approvarne i contenuti, archiviarla e diffonderla. Comunicazione Com è organizzata la comunicazione all interno del gruppo: le interfacce con l esterno e fra i ruoli interni, le regole di utilizzo della posta elettronica, le modalità di comunicazione e di gestione dei problemi. Organizzazione dello spazio di lavoro Dove staranno i file del progetto e come sarà organizzata la struttura di cartelle in rete che conterrà la documentazione propria del progetto, il codice, gli eseguibili, la documentazione del prodotto, riferimenti (anche URL) ed altra documentazione (ad es. norme di codifica pubblicamente disponibili) utile per il progetto. Come saranno organizzati e gestiti gli spazi di lavoro dei vari ruoli, gli spazi comuni e quelli privati. Uso degli strumenti Quali strumenti, e secondo quali convenzioni, saranno usati per l analisi, la progettazione, la codifica e la verifica del prodotto, ed inoltre, per la gestione delle versioni.
Norme di progetto 2 2. Norme di sviluppo Norme di analisi Modalità di svolgimento e documentazione delle attività di analisi. Particolari convenzioni adottate per la stesura dei documenti. Norme di progettazione Modalità di svolgimento e documentazione delle attività di progettazione. Particolari convenzioni adottate per la stesura dei documenti (ad es. nei diagrammi UML, nelle modalità di specifica dei componenti). Norme di codifica Eventualmente con sezioni dedicate ai diversi linguaggi di programmazione usati nel progetto. Intestazione dei file, regole per la costruzione degli identificatori, commenti e documentazione del codice, indentazione.
Offerta L offerta è un documento non versionato, redatto dal project manager. L offerta viene consegnata al committente che provvede a firmarla per accettazione. Comprende una breve descrizione del prodotto offerto, i dettagli economici, l allegata analisi dei requisiti e i tempi di consegna con l indicazione delle eventuali penali.
Piano di gestione della qualità Pianificazione della qualità Politica ed obiettivi della qualità Riferimento ad un eventuale modello di qualità adottato Controllo della qualità Procedure di controllo. Comunicazione e risoluzione di anomalie. Strumenti, tecniche, metodi (Management reviews, Technical reviews, Inspections, Audits) Miglioramento della qualità (se previsto dal modello adottato).
Analisi del dominio Documento versionato, contiene le seguenti sezioni: Introduzione (sulla società committente, breve descrizione del prodotto richiesto) Glossario (definizioni, acronimi, abbreviazioni) Conoscenze generali sul dominio Caratteristiche dei clienti e degli utenti L ambiente di utilizzo Compiti e procedure attualmente eseguiti Software competitori Similarità ad altri domini
Analisi dei requisiti Documento versionato per la definizione dei requisiti, strutturato nella seguente maniera: Problema e scopo del prodotto software Contesto d uso e funzioni del prodotto Informazioni di background Modelli di ambiente e di sistema Requisiti funzionali Requisiti non-funzionali Vincoli, assunzioni, dipendenze, tempi di risposta, throughput Risorse impiegate Requisiti di qualità (affidabilità, disponibilità, manutenibilità ed evoluzione futura) Requisiti di interfacciamento Piattaforma, tecnologia
Specifica architetturale Lo scopo primario di questo documento è la descrizione architetturale del sistema. Introduzione Glossario Descrizione generale e contesto d uso del prodotto Definizione del prodotto Disegno generale dell architettura Decomposizione funzionale (top-down) generica Decomposizione ad oggetti Casi d uso Modellazione strutturale Modellazione dinamica e comportamentale Breve descrizione dei singoli componenti Tipo e funzione dei componenti Interfaccia e dati trattati Relazioni con altri componenti Relazione della specifica con i requisiti
Specifica di dettaglio Scopo del disegno di dettaglio è la specifica dei componenti identificati nel disegno architetturale. In particolare è previsto il seguente schema: Disegno architetturale dettagliato Descrizione dettagliata dei componenti Codice sorgente relazione del prodotto con i requisiti
Piano delle prove 1 Definizione delle prove di integrazione Metodologia di integrazione adottata Pianificazione delle prove e definizione delle batterie di prova Codice sorgente di stub e driver utilizzati Definizione delle prove di collaudo (del sistema completo) Pianificazione delle prove e definizione delle batterie di prova Risultati ottenuti Per ogni caso di prova il verificatore deve riportarne l esito
Piano delle prove 2 Una batteria di prove è costituita da una sequenza di singoli casi di prova correlati. Un caso di prova prevede la verifica di una funzionalità del sistema in corrispondenza di determinati input, ed è descritto nella seguente maniera: Classificazione della prova. Identificativo, titolo, elenco delle componenti coinvolte nella verifica, descrizione degli obiettivi in termini di funzionalità o di caratteristiche di qualità da verificare con riferimenti al disegno di dettaglio (per le prove d integrazione) o all'analisi dei requisiti (per le prove di collaudo), livello d importanza della prova. Istruzioni per il verificatore. In particolare, la descrizione dei dati in ingresso. Risultati attesi. Dati in output e/o effetti attesi. Istruzioni di ripristino (se necessario): Informazioni per il verificatore per riportare il sistema alla normalità dopo la prova.
Risultati delle prove Risultati dell'esecuzione di un caso/batteria di prove; uno per ogni caso/batteria previsti dal Piano delle Prove, identificato con riferimento al caso/batteria di prova e alla ripetizione della prova.
Manuale d uso In forma cartacea ed in forma di help on-line contiene le tre sezioni qui riportate (generalmente versionato ma per nostra semplicità unico e riferito all ultima versione del software): Introduzione Descrizione d uso del manuale Descrizione generale Istruzioni d uso Descrizione funzionale Azioni richieste e/o permesse Errori probabili ed eventuali cause Appendice Glossario Messaggi d errore Comunicazione di malfunzionamenti