doc/PdQ/Piano_di_Qualifica.tex

   1 \documentclass[a4paper,11pt]{article}
   2 \usepackage[utf8]{inputenc}
   3 \usepackage[italian]{babel}
   4 \usepackage{appendix}
   5 \usepackage{fancyhdr}
   6 \usepackage{graphicx}
   7 \usepackage{lastpage}
   8 \usepackage{tabularx}
   9 \usepackage{ulem}
  10 \usepackage[pdftex]{hyperref}
  11
  12 \hypersetup{
  13         breaklinks,
  14         colorlinks,
  15         linkcolor=blue,
  16         pdftitle={Piano\_di\_Qualifica\_v1.0.pdf},
  17         pdfsubject={Piano di Qualifica},
  18         pdfauthor={ITWorks!},
  19         pdfcreator={TeXLive-2007}
  20 }
  21
  22 \renewcommand{\appendixtocname}{Appendici}
  23 \renewcommand{\appendixpagename}{Appendici}
  24 \renewcommand{\headrulewidth}{0.6pt}
  25 \renewcommand{\footrulewidth}{0.4pt}
  26
  27 \begin{document}
  28
  29 \normalem
  30 \newtoks\titolo
  31 \titolo{Piano di Qualifica}
  32 \newtoks\data
  33 \data{\today}
  34
  35 \pagestyle{fancy}
  36 \lhead{\includegraphics[scale=0.3]{../Logo_simple}}
  37 \chead{}
  38 \rhead{\small{itworks@googlegroups.com}}
  39 \lfoot{\small{\the\titolo}}
  40 \cfoot{}
  41 \rfoot{\thepage\ di \pageref*{LastPage}}
  42
  43 \thispagestyle{empty}
  44
  45 \begin{center}
  46
  47 \includegraphics[scale=0.7]{../Logo_green}
  48 \vspace{2cm}
  49 \\\Huge{\textsc{\the\titolo}}
  50 \vspace{1cm}
  51 \\\Large{\textsl{\the\data}}
  52 \vspace{1.2cm}
  53
  54 \begin{abstract}
  55 Nel Piano di Qualifica viene data una visione globale della strategia di verifica che la nostra azienda intende attuare nel corso della realizzazione del progetto. Questo implica anche la specifica delle risorse, degli strumenti e delle tecnologie richieste.
  56 \end{abstract}
  57
  58 \small
  59 \vspace*{\stretch{1}}
  60 \begin{tabular}{r|l}
  61         \textbf{Redazione} & Martina Astegno \\
  62                                                 & Daniele Battaglia \\
  63         \textbf{Revisione} & Martina Bernardini \\
  64                                                 & Davide Pesavento \\
  65         \textbf{Approvazione} & Martina Bernardini \\
  66         \textbf{Versione} & $1.0$ \\
  67         \textbf{Data} & \the\data \\
  68         \textbf{Stato} & Formale \\
  69         \textbf{Uso} & Esterno \\
  70         \textbf{Distribuzione} & Prof.\ Tullio Vardanega \\
  71                                                         & Prof.\ Renato Conte \\
  72                                                         & ITWorks! \\
  73 \end{tabular}
  74 \vspace{\stretch{1}}
  75
  76 \end{center}
  77
  78 \pagebreak
  79
  80 \normalsize
  81 \vspace*{0.1cm}
  82 \tableofcontents
  83
  84 \pagebreak
  85
  86 \section{Introduzione}
  87
  88 \subsection{Scopo del documento}
  89 L'obiettivo del presente documento è di chiarire in modo preciso le tecniche di verifica e validazione che l'azienda ritiene di dover mettere in atto, in particolare quando intervenire in base alle revisioni previste. Verranno inoltre fissati anche i ruoli, responsabili di mettere in atto tali tecniche.
  90
  91 \subsection{Scopo del prodotto}
  92 L'azienda \textsl{ITWorks!} si prefigge come scopo la realizzazione di un prodotto che risponda ai requisiti individuati in fase di analisi, in particolare si tratta di un sistema software per l'implementazione del gioco chiamato \mbox{\textbf{GoMoku3D}}. Pertanto si può far riferimento direttamente alla documentazione relativa all'\textit{Analisi dei Requisiti}.
  93
  94 \subsection{Glossario}
  95 Il \textit{Glossario} cui far riferimento è fornito in un file separato, allegato al presente \textit{Piano di Qualifica}.
  96 Le definizioni del glossario si applicano a tutti i documenti formali allo scopo di rendere non ambigua e omogenea la terminologia tecnica utilizzata.
  97
  98 \subsection{Riferimenti}
  99 \subsubsection{Normativi}
 100 \begin{itemize}
 101 \item Capitolato d'appalto. \\ \url{http://www.math.unipd.it/~tullio/IS-1/2007/Progetti/GoMoku3D.html}
 102 \item IEEE Std 1008-87 - \textit{Standard for Software Unit Testing}
 103 \item IEEE Std 730TM-2002 (revision of IEEE Std 730-1998) - \textit{Standard for Software Quality Assurance Plans}
 104 \end{itemize}
 105 \subsubsection{Informativi}
 106 \begin{itemize}
 107 \item Wikipedia, l'enciclopedia libera. \\
 108 \url{http://en.wikipedia.org/wiki/Main_Page}
 109 \item \textit{Guide to the SWEBOK.} \\
 110 \url{http://www.swebok.org}
 111 \item Pagina web del docente. \\
 112 \url{http://www.math.unipd.it/~tullio}
 113 \end{itemize}
 114
 115 \section{Visione generale della strategia di verifica}
 116
 117 \subsection{Organizzazione, pianificazione strategica e temporale, responsabilità}
 118 \label{resp}
 119 Verifica e validazione sono attività essenziali nel processo di qualifica e in quanto tali hanno bisogno di essere organizzate e fissate sulla base di particolari criteri stabiliti all'interno dell'azienda. Questo compito è affidato al responsabile, che in prima persona o delegando l'amministratore, specifica la ripartizione in moduli delle attività di verifica che devono essere messe in atto. Fin da subito, e quindi nell'\textit{Analisi dei Requisiti} si manifesta la necessità di un intervento da parte del verificatore, che dovrà accertare la presenza dei soli requisiti necessari e sufficienti al prodotto, inclusi quelli introdotti direttamente dal fornitore a integrarne il valore aggiunto.
 120 \`E compito del verificatore evidenziare eventuali anomalie o non conformità alle \textit{Norme di Progetto} riscontrate nel corso della sua attività. Tutte queste incongruenze, opportunamente comunicate a chi ha redatto il documento, dovranno essere risolte e documentate come previsto nella sezione \ref{anomalie}. Quanto detto alla sezione \ref{anomalie} non si applica nel caso di difetti di forma, infatti basterà notificare all'autore del documento la non conformità del suddetto, affinché proceda ad effettuare le modifiche necessarie, il tutto per evitare un sovraccarico al sistema di \uline{ticketing}.
 121 La seguente tabella indica in modo dettagliato il momento e gli incaricati a svolgere le attività di verifica e validazione. Vista la scelta del modello di ciclo di vita incrementale vi sarà un'unica fase di \textit{Analisi} iniziale, mentre la sequenza \textit{Progettazione-Programmazione-Qualifica} saranno ripetute come indicato nel \textit{Piano di Progetto}.
 122 \\\\
 123 \begin{tabularx}{\textwidth}{l|X}
 124         \hline
 125         \textbf{Analisi} & Tracciamento tra requisiti utente e requisiti software. \\
 126         \hline
 127         \textbf{Progettazione} & Tracciamento tra requisiti software e descrizione dei componenti, definizione dei test \mbox{\textit{Driver \& Stub}} che verranno effettuati in fasi future. \\
 128         \hline
 129         \textbf{Programmazione} & Test \textit{white box} eseguiti con l'ausilio di \textit{debugger}. \\
 130         \hline
 131         \textbf{Qualifica} & Esecuzione dei test \mbox{\textit{Driver \& Stub}} precedentemente definiti, oppure, in fase di validazione del sistema, $\alpha$-test, e relativa documentazione. \\
 132         \hline
 133 \end{tabularx}
 134 \\\\
 135
 136 \subsection{Dettaglio delle revisioni}
 137 L'azienda dovrà confrontarsi con due tipologie di processi di revisione, quali:
 138 \begin{description}
 139         \item[Revisione formale:] fondamentalmente di carattere bloccante, condotta direttamente dal cliente che gode di piena autorità (\textit{Audit Process}):
 140                 \begin{itemize}
 141                         \item Revisione dei Requisiti (RR)
 142                         \item Revisione di Accettazione (RA)
 143                 \end{itemize}
 144         \item[Revisione informale:] di progresso, non è bloccante, ma consente maggiore interazione tra cliente e fornitore (\textit{Joint Review Process}):
 145                 \begin{itemize}
 146                         \item Revisione del Progetto Preliminare (RPP)
 147                         \item Revisione del Progetto Definitivo (RPD)\footnote{Questa revisione verrà effettuata in modo interno senza l'intervento del committente, come con esso accordato.}
 148                         \item Revisione di Qualifica (RQ)
 149                 \end{itemize}
 150 \end{description}
 151 Tutti i documenti redatti in sede di \textit{Audit Process} hanno valenza contrattuale, mentre quelli relativi al \textit{Joint Review Process} hanno solo scopo informativo.
 152
 153 \subsubsection{Revisione dei Requisiti}
 154 \begin{itemize}
 155         \item Prodotti in ingresso: Capitolato d'Appalto, Analisi dei Requisiti e Piano di Progetto.
 156         \item Funzioni: accordarsi con il committente sulle funzionalità richieste al prodotto.
 157         \item Stato del prodotto in uscita: descritto.
 158 \end{itemize}
 159
 160 \subsubsection{Revisione del Progetto Preliminare}
 161 \begin{itemize}
 162         \item Prodotti in ingresso: Specifica tecnica, aggiornamento del Piano di Qualifica.
 163         \item Funzioni: accertamento di realizzabilità (esistenza di strategie, tecniche, metodologie e tecnologie adeguate allo scopo), e attivazione della fase realizzativa del prodotto.
 164         \item Stato del prodotto in uscita: specificato.
 165 \end{itemize}
 166
 167 \subsubsection{Revisione del Progetto Definitivo}
 168 \begin{itemize}
 169         \item Prodotti in ingresso: Definizione del Prodotto, aggiornamento del Piano di Qualifica.
 170         \item Funzioni: informare il committente sulle caratteristiche finali del prodotto e attivare la fase ascendente di qualifica.
 171         \item Stato del prodotto in uscita: definito.
 172 \end{itemize}
 173
 174 \subsubsection{Revisione di Qualifica}
 175 \begin{itemize}
 176         \item Prodotti in ingresso: aggiornamento finale del Piano di Qualifica, versione preliminare del Manuale Utente e specifica delle prove proposte dal fornitore per il collaudo.
 177         \item Funzioni: approvazione dell'esito finale della fase di verifica, attivazione della fase di validazione.
 178         \item Stato del prodotto in uscita: qualificato.
 179 \end{itemize}
 180
 181 \subsubsection{Revisione di Accettazione}
 182 \begin{itemize}
 183         \item Prodotti in ingresso: versione definitiva del Piano di Qualifica, versione definitiva del Manuale Utente.
 184         \item Funzioni: collaudo del sistema per accettazione da parte del committente, accertamento di soddisfacimento di tutti i requisiti pattuiti in sede contrattuale.
 185         \item Stato del prodotto in uscita: accettato.
 186 \end{itemize}
 187
 188 \subsection{Risorse necessarie e rese disponibili}
 189 L'attività di verifica per essere concretizzata necessita di risorse di natura principalmente umana e tecnologica. Pertanto è compito dell'amministratore accertare in ogni momento l'efficienza e l'affidabilità dei mezzi tecnologici, in modo da consentire al verificatore di svolgere il proprio lavoro al meglio. Il responsabile ha il compito di controllare che le scadenze siano rispettate in modo da non ritardare l'attività di qualifica.
 190
 191 \subsection{Strumenti, tecniche, metodi}
 192 \subsubsection{Tracciamento}
 193 Al fine di evitare software ridondante o che presenta parti non richieste è indispensabile avere a disposizione il tracciamento completo e preciso di tutti i requisiti rilevati, anche in previsione di eventuali cambiamenti futuri opportunamente gestiti (\uline{ticketing}). I documenti di tracciamento dovranno essere redatti dai ruoli indicati nella sezione \ref{resp} e il compito del verificatore sarà quello di controllare che non esistano incoerenze e che il prodotto soddisfi tutti e soli i requisiti tracciati.
 194 \subsubsection{Documenti}
 195 Per quanto riguarda i documenti il verificatore è chiamato a controllare che:
 196 \begin{itemize}
 197         \item il linguaggio usato non sia ambiguo;
 198         \item il documento non presenti errori linguistici;
 199         \item il contenuto sia corretto e completo rispetto a quanto richiesto dalla natura del documento stesso.
 200 \end{itemize}
 201 Particolare attenzione verrà data ai documenti di \textit{Analisi dei Requisiti} e \textit{Progettazione} per i quali il controllo sul contenuto dovrà comprendere metriche di valutazione specifiche. Per l'\textit{Analisi dei Requisiti} verrà posta particolare attenzione sull'atomicità dei singoli requisiti mentre per la \textit{Progettazione} dovrà essere verificato che il livello di accoppiamento sia mantenuto ragionevolmente basso, che il riuso di componenti esistenti sia fatto in modo non opportunistico e che siano applicati principi di progettazione ritenuti utili come ad esempio il principio di \textit{encapsulation}.
 202
 203 \subsubsection{Codice}
 204 Partendo dal presupposto che il sistema sia suddiviso in unità, cioè in elementi che rappresentano le funzionalità di specifiche componenti, l'attuazione della verifica richiede essenzialmente due generi di attività distinte, che possiamo ricondurre a:
 205 \begin{itemize}
 206         \item \textbf{Analisi Statica}: viene fatta senza richiedere esecuzione di codice, ed essendo particolarmente onerosa e complessa è mirata a precise componenti. Verrà effettuata con le tecniche di:
 207                 \begin{itemize}
 208                         \item Analisi di flusso dei dati, per individuare l'uso di variabili non inizializzate correttamente.
 209                         \item Analisi di flusso di controllo, per individuare l'esistenza di rami irraggiungibili del codice.
 210                         \item \textit{Inspection} o \textit{walkthrough}, a discrezione del verificatore e della sua esperienza. \`E fortemente consigliato il metodo di \textit{inspection}; nel caso in cui si adotti la tecnica di \textit{walkthrough}, questo dovrà essere approvato dal responsabile che ne valuterà l'impatto in termini di costi e tempi, già in parte previsti.
 211                 \end{itemize}
 212         \item \textbf{Analisi Dinamica}: prevede l'esecuzione di test a due livelli:
 213                 \begin{itemize}
 214                         \item Unità: testate con il metodo \mbox{\textit{Driver \& Stub}} dove e come definito in sede di progettazione.
 215                         \item Sistema: validato sui requisiti software con l'ausilio di $\alpha$-test e sui requisiti utente con l'ausilio di $\beta$-test.
 216                 \end{itemize}
 217 Grazie al $\beta$-test saremo in grado di raccogliere opinioni sull'usabilità del prodotto dal campione di test, mentre con l'$\alpha$-test, interno all'azienda, cercheremo di valutare i risultati raggiunti dal prodotto in termini di affidabilità ed efficienza e rilevare eventuali non conformità funzionali.
 218 \end{itemize}
 219
 220 \section{Gestione amministrativa delle revisioni}
 221
 222 \subsection{Comunicazione e risoluzione di anomalie}
 223 \label{anomalie}
 224 Eventuali anomalie possono essere riscontrate non solo nel corso dell'attività di verifica, ma anche in altri momenti del ciclo di vita. Ciascun membro del gruppo ha perciò facoltà di provvedere alla comunicazione di quanto riscontrato anche se non in veste di verificatore.
 225 \subsubsection{Categorie}
 226 Le anomalie sono raggruppate nelle seguenti categorie in base alla loro origine:
 227 \begin{itemize}
 228         \item \textbf{Analisi}: errori riscontrati sulla fase di analisi, elementi superflui, incoerenze di vario genere.
 229         \item \textbf{Progettazione}: errori riscontrati sulla fase di progettazione, elementi superflui, incoerenze di vario genere.
 230         \item \textbf{Sviluppo}: errori riscontrati sulla fase di codifica, plausibilmente nella fase di test.
 231 \end{itemize}
 232 \subsubsection{Comunicazione}
 233 La comunicazione delle anomalie riscontrate dovrà essere effettuata usando lo strumento di gestione automatica fornito all'indirizzo: \url{http://gomoku3d.devjavu.com}. Ciascun componente del gruppo dispone di un nome utente e di una password da usare per l'autenticazione nel sistema. Per comunicare una nuova anomalia sarà necessario aprire un nuovo \uline{ticket}. Nel creare un nuovo \uline{ticket} si dovranno rispettare le seguenti linee guida:
 234 \begin{itemize}
 235         \item inserire un titolo il più sintetico ed esemplificativo possibile;
 236         \item essere chiari e diretti nella descrizione del problema;
 237         \item fare uso di termini e riferimenti non ambigui nella descrizione;
 238         \item se individuato, indicare il file a cui devono essere apportate modifiche;
 239         \item indicare la categoria di appartenenza dell'anomalia;
 240         \item assegnare inizialmente il \uline{ticket} all'indirizzo del gruppo \mbox{\url{mailto:itworks.swe@gmail.com}} affinchè venga comunicato automaticamente a tutti i componenti l'aggiunta del nuovo \uline{ticket}.
 241 \end{itemize}
 242 \subsubsection{Gestione dell'anomalia e trattamento delle discrepanze}
 243 Successivamente il responsabile o un suo delegato verificherà che effettivamente l'anomalia è presente, ed assegnerà il compito di risolvere l'anomalia ad uno dei componenti del gruppo. Tale procedura può essere eseguita sempre con il sistema automatizzato, il quale comunicherà al nuovo proprietario ciascun aggiornamento. Nel caso la risoluzione di un'anomalia richieda più di tre giorni lavorativi, il proprietario del \uline{ticket} è invitato a segnalare nel \uline{ticket} stesso eventuali aggiornamenti e procedure in atto. Quando il proprietario di un \uline{ticket} ritiene risolta l'anomalia, lo comunicherà impostando lo stato del \uline{ticket} a \textit{fixed}.
 244 I verificatori saranno responsabili di controllare l'effettiva risoluzione dell'anomalia.
 245
 246
 247 \subsection{Procedure di controllo di qualità di processo}
 248 Al fine di migliorare efficacia ed efficienza dei processi l'azienda ha deciso di applicare ove opportuno delle tecniche volte a realizzare il meccanismo del ciclo \uline{PDCA}.
 249 \subsubsection{Miglioramento di processo}
 250 Le fasi logiche in cui si suddivide il meccanismo di miglioramento possono essere così riassunte:
 251 \begin{itemize}
 252         \item \textbf{Misurazione}: quantitativa, basata su metriche.
 253         \item \textbf{Analisi e Modellazione}: si cerca di capire la struttura del processo, eventualmente attraverso un diagramma e, in base alle misurazioni e alla loro interpretazione, si prova ad individuare in che punto di tale struttura esiste margine di miglioramento per il processo.
 254         \item \textbf{Cambiamento}: viene apportato sulla base dei risultati del punto precedente, garantendo comunque la misurabilità dell'effetto migliorativo.
 255 Può essere fatto tramite:
 256                 \begin{itemize}
 257                         \item ordinamento delle attività;
 258                         \item introduzione o rimozione di uscite del processo;
 259                         \item definizione di nuovi ruoli e responsabilità.
 260                 \end{itemize}
 261 \end{itemize}
 262 \subsubsection{Metriche}
 263 Con questo termine si intende l'insieme di parametri misurabili su un processo. Questi possono essere riassunti in:
 264 \begin{itemize}
 265         \item \textbf{Tempo}: rappresenta l'ammontare totale delle ore effettivamente utilizzate dall'avvio alla terminazione del processo.
 266         \item \textbf{Risorse}: rappresenta il numero di risorse umane e strumenti utilizzati nel processo.
 267         \item \textbf{Numero di difetti} (o non conformità rispetto alle norme): riscontrate nello svolgimento del processo.
 268 \end{itemize}
 269
 270 \section{Resoconto delle attività di verifica}
 271 \subsection{Tracciamento componenti - requisiti}
 272
 273
 274 \pagebreak
 275
 276 \appendix
 277 \appendixpage
 278
 279 \section{Registro delle modifiche}
 280 \vspace{5mm}
 281
 282 \begin{center}
 283
 284 \small
 285
 286 \begin{tabularx}{\textwidth}{|*{3}{X}|}
 287         \hline
 288         \textbf{Versione} & \textbf{Data} & \textbf{Autore} \\
 289         \hline
 290 \end{tabularx}
 291
 292 \vspace{2mm}
 293
 294 \begin{tabularx}{\textwidth}{*{3}{X}}
 295         \vspace{1mm}
 296         \\\hline
 297         1.1 & 11/01/2008 & Tobia Zorzan \\
 298         \multicolumn{3}{p{0.95\textwidth}}{Modifica della gestione delle anomalie adottando un sistema di ticketing automatico.} \\
 299         \vspace{1mm}
 300         \\\hline
 301         1.0 & 06/12/2007 & Martina Bernardini \\
 302         \multicolumn{3}{p{0.95\textwidth}}{Verifica e approvazione documento.} \\
 303
 304         \vspace{1mm}
 305         \\\hline
 306         0.5 & 05/12/2007 & Davide Pesavento \\
 307         \multicolumn{3}{p{0.95\textwidth}}{Verifica del documento. Corretti alcuni errori e migliorato l'aspetto tipografico.} \\
 308
 309         \vspace{1mm}
 310         \\\hline
 311         0.4 & 05/12/2007 & Martina Astegno \\
 312         \multicolumn{3}{p{0.95\textwidth}}{Completata la sezione sul controllo di qualità di processo.} \\
 313
 314         \vspace{1mm}
 315         \\\hline
 316         0.3 & 04/12/2007 & Davide Pesavento \\
 317         \multicolumn{3}{p{0.95\textwidth}}{Aggiornamento alla versione 1.2 del template di documento.} \\
 318
 319         \vspace{1mm}
 320         \\\hline
 321         0.2 & 03/12/2007 & Daniele Battaglia \\
 322         \multicolumn{3}{p{0.95\textwidth}}{Aggiunta sezione relativa alle tecniche di analisi statica e dinamica del codice.} \\
 323
 324         \vspace{1mm}
 325         \\\hline
 326         0.1 & 02/12/2007 & Martina Astegno \\
 327         \multicolumn{3}{p{0.95\textwidth}}{Versione iniziale.} \\
 328 \end{tabularx}
 329
 330 \end{center}
 331
 332 \end{document}