|
119 | 119 | description={Soluzione progettuale generale a un problema ricorrente. Una descrizione o un modello da applicare per risolvere un problema che può presentarsi in diverse situazioni durante la progettazione e lo sviluppo del software} |
120 | 120 | } |
121 | 121 |
|
| 122 | +\newglossaryentry{documentazionediprogetto} |
| 123 | +{ |
| 124 | + name=Documentazione di progetto, |
| 125 | + description={Tutto ciò che descrive gli ingressi e le uscite delle attività necessarie al progetto} |
| 126 | +} |
| 127 | + |
| 128 | +\newglossaryentry{repository} |
| 129 | +{ |
| 130 | + name=Repository, |
| 131 | + description={Database centralizzato nel quale risiedono, individualmente, tutti i configuration item di ogni \textit{baseline} nella loro storia completa} |
| 132 | +} |
| 133 | + |
| 134 | +\newglossaryentry{attributidiprodotto} |
| 135 | +{ |
| 136 | + name=Attributi di prodotto, |
| 137 | + description={All'interno della classificazione dei requisiti, definiscono le caratteristiche richieste dal sistema.\\ Rispondono alla domanda: Cosa devo fare? (requisiti funzionali, prestazioni, di qualità del prodotto)} |
| 138 | +} |
| 139 | + |
| 140 | +\newglossaryentry{attributidiprocesso} |
| 141 | +{ |
| 142 | + name=Attributi di processo, |
| 143 | + description={All'interno della classificazione dei requisiti, pongono vincoli sui processi impiegati nel progetto |
| 144 | + ..\\ Rispondono alla domanda: Come devo farlo? (requisiti di vincoli realizzativi, normativi e contrattuali)} |
| 145 | +} |
| 146 | + |
| 147 | +\newglossaryentry{requisito} |
| 148 | +{ |
| 149 | + name=Requistito, |
| 150 | + description={Definizioni multiple: |
| 151 | + \begin{enumerate} |
| 152 | + \item Condizione necessaria ad un utente per risolvere un problema o raggiungere un obiettivo (visione dal lato del bisogno) |
| 153 | + \item Condizione che deve essere soddisfatta da un sistema per adempiere ad un obbligo (visione dal lato della soluzione) |
| 154 | + \end{enumerate}} |
| 155 | +} |
| 156 | + |
| 157 | +\newglossaryentry{Verifica} |
| 158 | +{ |
| 159 | + name=Verifica, |
| 160 | + description={Accertare che l'esecuzione delle attività di processo non abbia introdotto errori (Ho costruito il sistema correttamente?)} |
| 161 | +} |
| 162 | + |
| 163 | +\newglossaryentry{validazione} |
| 164 | +{ |
| 165 | + name=Validazione, |
| 166 | + description={Accertare che il prodotto realizzato corrisponde alle attese (\' E un sistema corretto?)} |
| 167 | +} |
122 | 168 |
|
123 | 169 | %%%%%%%%%%%%%%%%%%%%%%% ** DA CONTROLLARE ** %%%%%%%%%%%%%%%%%%%% |
124 | 170 |
|
|
426 | 472 | \item Una baseline è una collezione delle versioni dei componenti che compongono un sistema. Le baseline sono controllate, il che significa che le versioni dei componenti che compongono il sistema non possono essere cambiate e che è sempre possibile ricreare una baseline a partire dai componenti che la costituiscono. [Sommerville, pag 684] |
427 | 473 | \end{enumerate} } |
428 | 474 | } |
| 475 | +\newglossaryentry{Checkin} |
| 476 | +{ |
| 477 | + name=Check-in, |
| 478 | + description={All'interno di una \textit{repository} premette a ciascun membro del team di lavorare su vecchi e nuovi CI senza rischio di sovrascritture accidentali} |
| 479 | +} |
| 480 | + |
| 481 | +\newglossaryentry{Checkout} |
| 482 | +{ |
| 483 | + name=Check-out, |
| 484 | + description={Attività che permette a ciascun membro del team di condividere il lavorato nello spazio comune della \textit{repository}} |
| 485 | +} |
429 | 486 |
|
430 | 487 | \newglossaryentry{versione}{ |
431 | 488 | name=Versione, |
|
0 commit comments