T&T Systems - HINTSW

Il modello di sviluppo presentato in questo articolo è quello sviluppato in Germania da IABG in Ottobrunn (Monaco) per conto del Ministero della Difesa Federale tedesca.

Tale modello è basato su di un processo che considera solo il ciclo di vita di sviluppo di un progetto; esso è quindi limitato alla fase di progettazione e di sviluppo, e non prende in considerazione l’intero ciclo di vita di un sistema/apparato che, come intuibile, comprende anche le fasi precedenti (concezione) e successive (esercizio, manutenzione, dismissione) allo sviluppo. Un secondo limite del modello è che si rivolge soprattutto allo sviluppo del software all’interno di un progetto e non prende in considerazione l’intera organizzazione di una azienda. Un ulteriore limite consiste infine nel fatto che il modello stesso non affronta sufficientemente le attività di validazione del software e del sistema, attività che sono da ritenersi critiche per la buon riuscita di un progetto. Nonostante questi limiti, il modello qui presentato appare assai interessante in quanto è stato pensato ad un livello di astrazione molto elevato, risultando così di facile comprensione e soprattutto di utilizzo molto generale. L’architettura del modello contiene una scomposizione che propone una utile categorizzazione delle attività di sviluppo, con una efficace rappresentazione delle relative interdipendenze e correlazioni, risultando così un'ottima guida per l'implementazione di un valido modello di sviluppo.

L'architettura del Modello a V

Ognuno dei livelli sopra descritti è suddiviso in aree funzionali; queste aree sono denominate "sotto-modelli". Come rappresentato in Figura 1 ci sono quattro sotto-modelli:

• Gestione del progetto [Project management (PM)] – Questo sotto-modello si occupa della pianificazione, del monitoraggio e del controllo del progetto e fornsice informazioni agli altri sotto-modelli.
• Sviluppo del sistema [System Development (SD)] – Questo sotto-modello si occupa della sviluppo del Sistema oppure del Software.
• Assicurazione della Qualità [Quality Assurance (QA)] – Questo sotto-modello concerne la specificazione dei requisiti di qualità e la loro comunicazione agli altri sotto-modelli. Ad esempio specifica i casi di prova e ed i criteri per assicurare che i prodotti ed i processi siano conformi allo standard.
• Gestione della configurazione [Configuration Management (CM]) – Questo sotto-modello si occupa di amministrare i prodotti generati.

Il Modello del Ciclo di Vita

Il modello del ciclo di vita di un progetto descrive i processi mediante due concetti base: le attività ed i prodotti. Il modello, inoltre, descrive gli stati dei prodotti e le interdipendenze tra le attività ed i prodotti mediante lo schema di flusso dei prodotti.

Elementi base: Attività e Prodotti

Le attività sono le fasi di lavoro nel processo di sviluppo; l’esecuzione ed i risultati di un’attività sono descritti dal modello con precisione. Un’attività può consistere di sub attività; le attività a più alto livello sono chiamate attività principali. Il risultato di una attività è un prodotto; ovvero un’attività genera, cambia lo stato, o modifica un prodotto. Per ogni attività c’è una descrizione basata su un modello chiamato schema di attività.

Un prodotto può essere un documento, un componente software, o hardware, ed è il risultato di una attività. Similmente alle attività un prodotto può essere scomposto in sottoprodotti e può essere descritto da uno schema di prodotto. Quest’ultimo contiene una breve sinossi del prodotto ed una lista delle componenti strutturali del prodotto.

Schema di attività

Il modello relativo allo schema di attività comprende:

• Nome dell’attività – Descrive il nome ed il numero dell’attività. Può essere indifferentemente una attività principale o una sottoattività. Le sottoattività sono numerate con una notazione che contiene un punto (es.: 1.1).
• Flusso del prodotto – Descrive il flusso di un prodotto, ossia descrive l’input e l’output relativi ad un prodotto sottoposto ad una attività. Nell’input è documentata l’attività da cui è stato derivato il prodotto e ne viene descritto lo stato; il prodotto viene quindi processato mediante una attività specifica ed al suo completamento il prodotto viene emesso; nell’output è documentato a quale attività il prodotto andrà in ingresso, e ne è indicato lo stato.
• Gestione: – Descrive come deve essere gestita l’attività durante la sua realizzazione. Se l’attività è principale vengono descritte anche le sottoattività; si noti che le interdipendenze ed i risultati delle sottoattività vengono descritti con modalità grafiche.
• Raccomandazioni e delucidazioni – Vengono fornite raccomandazioni su come deve essere gestita una attività; le delucidazioni hanno invece lo scopo di chiarire le definizioni utilizzate e di renderne più facile la comprensione.

Stati di un prodotto

Un prodotto, durante la sua generazione e la sua elaborazione, attraversa diversi stati. Una transizione di stato può essere innescata solo da una attività. In ogni schema di attività è definito, sia lo stato del prodotto all'inizio della attività, sia lo stato raggiunto al termine di essa. Gli stati di un prodotto e le relative transizioni sono modellate in Figura 2.

Figura 2

Gli stati di un prodotto pssono esser i seguenti:

• Pianificato – Il prodotto non esiste ancora ma è stato pianificato. È lo stato iniziale di tutti i prodotti.
• In elaborazione – Il prodotto è in elaborazione; è sotto il controllo di uno sviluppatore. Il prodotto può essere sia estratto, sia inserito nella libreria dei prodotti.
• In valutazione – Il prodotto, dal punto di vista dello sviluppatore è terminato; esso viene sottoposto alla QA (Quality Assurance) per essere valutato. Se la valutazione è negativa il prodotto viene rifiutato e ritorna nello stato In elaborazione, altrimenti è accettato.
• Accettato – Il prodotto è stato accettato dalla valutazione della QA e pertanto viene rilasciato; il prodotto potrà essere ulteriormente modificato solo se il suo numero di versione verrà aggiornato.

I Sottomodelli

Come anticipato nella descrizione dell’architettura ci sono quattro sotto-modelli nel Modello a V. In questa sezione i sotto-modelli vengono descritti con maggior dettaglio dal punto di vista del Modello del Ciclo di Vita.

Ogni sotto-modello consiste di attività e genera dei prodotti; i sotto-modelli cooperano tra loro per realizzare l’obiettivo del progetto come mostrato nella seguente Figura 3.

Figura 3

Gestione del progetto (PM- Project Management)

Questo sotto-modello regola le attività di inizio, pianificazione e monitoraggio del progetto; è composto da 14 attività principali, come qui di seguito riportato:

• Inizializzazione del progetto – La struttura organizzativa del progetto viene definita e documentata nel manuale della progettazione, inoltre il Modello a V generico viene personalizzato in un Modello a V specifico per il particolare progetto in corso in accordo con i criteri e le condizioni del progetto stesso. Viene realizzata la pianificazione preliminare basandosi sul manuale di progetto e documentandola nel piano di progetto.
• Inquadramento/approvvigionamento – Implica l’invio delle richieste d’offerta ai possibili subfornitori con la valutazione delle riposte e l’individuazione delle offerte più economiche.
• Gestione dei contraenti – Lo scopo di questa attività è di sorvegliare che i termini riportati nei contratti siano soddisfatti; questo concerne sia i contratti con i clienti, sia i contratti con i subappaltatori.
• Pianificazione dettagliata – L’obbiettivo di questa attività è quello di definire un piano dettagliato per il progetto; l’attività è compiuta con l’aiuto della pianificazione preliminare e con le indicazioni contenute nel manuale della progettazione.
• Analisi dei costi/benefici – Lo scopo di questa attività è quello di determinare la redditività delle soluzioni pianificate. Ogni soluzione proposta è valutata in base ai suoi costi e benefici.
• Riesame della fase – Al termine di ogni fase del progetto viene eseguito un riesame; il riesame viene eseguito per verificare che lo stato attuale del progetto sia in accordo con la pianificazione.
• Gestione del rischio – Lo scopo di questa attività è quello di individuare i rischi di progetto il più presto possibile. I rischi sono gestiti attivando misure preventive e sorvegliando l’efficacia delle misure attivate.
• Controllo del progetto – L’obiettivo di questa attività è di controllare l’andamento del progetto; nel caso si verifichino deviazioni dai valori pianificati, devono essere intraprese delle azioni per correggere il problema.
• Servizio di informazione/relazione – Il fine di questa attività è quello di produrre informazioni circa il progetto adeguate per il cliente, per i subappaltatori e per il personale del progetto.
• Formazione/istruzione – La funzione di questa attività è quella di formare (addestrare) il personale del progetto affinché esso acquisisca le conoscenze necessarie per adempiere al proprio ruolo.
• Approvvigionamento delle risorse – Il compito di questa attività è quella di approvvigionare le risorse necessarie per la realizzazione del progetto.
• Allocazione degli ordini di servizio – Lo scopo di questa attività è quello di iniziare una sessione di lavoro allocata da un ordine di servizio.
• Formazione dello staff – Il fine di questa attività è di introdurre il personale del progetto alla propria sessione di lavoro; esso viene istruito circa il proprio compito e gli vengono fornite le relative informazioni.
• Completamento del progetto – Lo scopo di questa attività e quello di completare il progetto, questo comporta la scrittura di un rapporto finale di progetto che contenga tutta l’esperienza del progetto.

Sviluppo del sistema (SD - System Development)

Il sotto-modello SD disciplina le attività di sviluppo del sistema; il sotto-modello è composto dalle nove attività seguenti:

• Analisi dei requisiti di sistema – Questa attività comporta la creazione dei requisiti di sistema secondo il punto di vista dell’utente; il sistema è specificato secondo un punto di vista “esterno” al progetto.
• Progettazione del sistema – Questa attività consiste nella definizione dell’architettura del sistema e nella stesura di un piano di integrazione dell’architettura.
• Analisi dei requisiti SW/HW – Questa attività comporta l’aggiornamento dei requisiti tecnici e delle informazioni operative con riferimento ai requisiti software ed hardware. Ciò viene fatto con l’aiuto dei requisiti utente, dell’architettura del sistema, e dei requisiti tecnici precedentemente determinati.
• Progettazione preliminare del SW – Questa attività consiste nella progettazione dell’architettura software. Questo comprende la descrizione esaustiva delle interfacce e l’aggiornamento del piano di integrazione del software.
• Progettazione dettagliata del SW – L’architettura del software e la descrizione delle interfacce vengono ulteriormente dettagliate; vengono definite le specifiche ed i dettagli relativi ad ogni modulo e componente software, ed alle basi dati.
• Implementazione del Software – Vengono realizzati i moduli, i componenti software e le basi dati; questa attività può essere svolta in diversi passi.
• Integrazione del software – Viene effettuata l’integrazione dei moduli, dei componenti e delle basi dati; anche questa attività può essere eseguita in diversi passi.
• Integrazione del sistema – Viene eseguita l’integrazione del sistema; componenti software ed hardware vengono integrati conformemente all’architettura del sistema.
• Transizioni verso l'utilizzo – Questa attività comprende i compiti necessari per mettere il sistema in servizio nell’ambiente di destinazione.

Nella seguente Figura 4 è illustrato il flusso delle attività del sotto-modello SD.

Figura 4

Assicurazione della Qualità (QA - Quality Assurance)

Il sotto-modello QA disciplina le attività ed i prodotti degli altri sotto-modelli valutandoli prima della loro accettazione; il sotto-modello è composto dalle cinque attività seguenti:

• Inizializzazione della QA – Questa attività consiste nello specificare gli obiettivi organizzativi e procedurali delle attività di QA. Tutti i requisiti relativi ai prodotti e alle attività vengono documentati nel piano di assicurazione della Qualità.
• Preparazione della valutazione – Questa attività consiste nella stesura del piano di valutazione; il piano contiene i metodi di valutazione, i criteri, gli ambienti ed i casi prova.
• Processo di valutazione delle attività – Questa attività consiste nella valutazione dei processi per determinare se essi sono adeguati.
• Valutazione dei prodotti – Questa attività consiste nella valutazione dei prodotti. Un prodotto può essere accettato e quindi può entrare nello stato “Accettato”, oppure può essere rifiutato e quindi deve ritornare nello stato “in elaborazione” (si veda Figura 2).
• Reporting di QA – Questa attività consiste nella valutazione dei rapporti di QA. La valutazione è compiuta sulla base del numero di problemi riscontrati, della loro gravità e della loro categoria, e sulla base delle cause.

Gestione della configurazione (CM - Configuration Management)

Il sotto-modello CM ha lo scopo di garantire che i prodotti possano essere univocamente identificati in qualsiasi momento; il sotto-modello è composto dalle quattro attività seguenti:

• Pianificazione della gestione della configurazione – Questa attività consiste nel definire il quadro organizzativo e nel documentarlo in un piano di gestione della configurazione; nel piano sono indicate anche le risorse e gli strumenti necessari alla gestione della configurazione.
• Prodotti e gestione della configurazione – Questa attività consiste nel gestire la libreria dei prodotti mediante la loro catalogazione; la configurazione deve comprendere l'intero sistema.
• Gestione delle modifiche – Questa attività consente la gestione delle modifiche mediante tre passi:
  1. una modifica deve essere formalmente richiesta e la richiesta deve essere registrata;
  2. la richiesta di modifica deve essere valutata e può essere accettata oppure rifiutata;
  3. se accettata la modifica viene implementata e tutti coloro che ne sono coinvolti vengono informati.
• Servizi di gestione della configurazione – I servizi di CM sono attività di servizio al progetto che comprendono la catalogazione dei prodotti SW, il coordinamento delle interfacce, i backup, la gestione dei rilasci e l'archivio storico di progetto.