METODO PER LA DEFINIZIONE DI MODELLI DI PROCESSO

Alcune caratteristiche del software creano considerevoli problemi relativamente  alla gestione  del processo di costruzione, che richiede dunque l’utilizzo di modelli adeguati. Relativamente a questo argomento, in passato, molti problemi sono rimasti insoluti, come ad esempio: la difficoltà relativa alla leggibilità delle numerose componenti indipendenti per ogni attività nel processo, l’aiuto richiesto dal manager per trattare progetti,  il bisogno di adattare modelli di rischio, e l’ambiente di sviluppo software. I modelli proposti in questo documento, offrono soluzioni a questi problemi. Gli aspetti innovativi dell’approccio descritto sono: l’individuazione e collocazione di tutte le informazioni pertinenti alla produzione del modello al fine di migliorare la gestione, e una definizione formale del processo che rende possibile il controllo automatico  della coerenza interna del piano di sviluppo, grazie all’utilizzo di una notazione flessibile, compatibile con la conoscenza di tutti i soggetti coinvolti nel processo di produzione.

In letteratura sono disponibili esperienze documentate, e sono proposti paradigmi relativi al processo di produzione, manutenzione e riuso del software. Adeguati modelli per la pianificazione e la gestione dei processi nella produzione software sono essenziali per la produzione e l’evoluzione su larga scala. Sfortunatamente l’esperienza acquisita e i modelli di produzione  utilizzati in processi di produzione relativi ad altri settori,  non possono essere applicati.

Poiché il processo di produzione del software non produce o riproduce semplicemente qualcosa, ma crea ogni volta un prodotto con caratteristiche uniche, esso non è mai deterministico ed è dunque soggetto a  rischi imprevisti causati da eventi esterni ad esso. Per tali ragioni, e differentemente dal caso del processo di produzione di materiali in genere, come ad esempio quello utilizzato per la produzione dell’hardware dove i costi e i rischi sono tutti concentrati nella fase di produzione e  nessun rischio è presente nella fase di riproduzione (a causa del determinismo), nel caso del software il processo adottato deve essere adattabile ai rischi che lo caratterizzano sia in fase di produzione, che in fase di riproduzione.

Dato che la principale risorsa del processo di produzione software è l’uomo, la capacità, l’organizzazione dell’ambiente di produzione, le tecnologie utilizzate, assumono grande importanza. Questi elementi sono tipici di ogni sistema di produzione e poiché evolvono indipendentemente, lo sforzo richiesto per lo sviluppo di ogni componente è differente. Ogni soggetto ha un’ inerzia diversa nei confronti dell’innovazione e può quindi assimilarla prima ed essere in grado di produrre più velocemente e meglio, o può assimilarla dopo con ovvie ripercussioni. Per queste ragioni il processo deve essere adattato all’ambiente di produzione e deve essere modificabile durante l’esecuzione, ogni volta che l’ambiente, le capacità, le tecnologie evolvono.

Una condizione necessaria per il successo è la effettiva comunicazione tra i vari team che lavorano in fasi differenti dello stesso processo. Per questa ragione, l’interfaccia di comunicazione tra fasi, deve essere definita con esattezza in termini di input e output che ognuna di esse deve utilizzare e/o produrre.

Un modello per la gestione dei processi, deve avere le seguenti caratteristiche tra le altre:

• leggibilità delle diverse componenti del processo di sviluppo e delle interrelazioni [12]
• adattabilità del modello di produzione al rischio e all’ambiente di sviluppo[2,3,7]
• modificabilità della sequenza delle fasi o sotto fasi previste al fine di consentire la riesecuzione di una fase già eseguita [10].

I modelli classici presenti in letteratura per la gestione e la pianificazione sono Gantt, Critical Path Model (CPM)  e Pert. È possibile trovare la loro descrizione e comparazione in [9] .

Essi sono utilizzati con successo nei processi di produzione dell’hardware ma mostrano evidenti  punti di debolezza per quanto riguarda il software:

• non prendono in considerazione i parametri caratteristici del sistema di sviluppo del software, fornendo esclusivamente delle espressioni per caratterizzare le attività e le risorse necessarie alla realizzazione del progetto.
• non prevedono la possibilità che una fase venga rieseguita automaticamente in seguito all’interruzione della linea principale del progetto causata da un evento imprevisto. Questo problema è particolarmente evidente quando le attività da rieseguire devono essere solo parzialmente eseguite.
• non sono in grado di trattare condizioni booleane presenti nel piano di esecuzione delle attività, e ciò  rende complesso modificare la sequenza delle fasi prevista
• non forniscono sufficienti informazioni per descrivere e trattare gli eventi che occorrono durante l’esecuzione di ogni attività, lasciando che sia l’esperienza di situazioni simili presentatesi e affrontate in precedenza a suggerire cosa fare.

Altri metodi utilizzati per la descrizione di un progetto sono: Grafi AND OR [16] e  Reti di Petri [11].

Questi ultimi non consentono all’ingegnere di processo, ossia colui che crea e migliora un modello di processo, di trattare tutte le informazioni coinvolte in un processo software, come documentazione, standards ecc.. Per tale motivo molti problemi di carattere manageriale, non possono essere completamenti risolti, come ad esempio la tracciabilità tra requisiti e codice che li implementa, l’allocazione delle responsabilità per il mancato soddisfacimento di un requisito ecc..  Le Reti di Petri inoltre deficitano nella gestione di altri tipi di informazioni manageriali come date di inizio e fine attività previste, stima dei costi per l’esecuzione di una attività  e altro ancora.

Liu e Horowitz hanno analizzato questi punti di debolezza a fondo  in [10] e proposto il Design Net Model basato sulle reti di Petri che risolve molti dei problemi visti, ma non tutti.

L’approccio presentato in questo progetto di ricerca, estende le finaltà dello Structured Planning [15], basato sull’Analisi Strutturata [6]. Differentemente dagli altri sistemi formali di modellizzazione dei processi, esso associa il rigore formale ad una rappresentazione amichevole che può essere scelta a piacimento tra le varie rappresentazioni strutturate esistenti [8,10,14].

La  caratteristica importante, il principio guida di questo nuovo approccio, che consente una più facile lettura di un progetto, risiede nella consapevolezza che un progetto deve essere comprensibile prima di tutto alle persone che con esso lavoreranno, coloro che lo useranno: manager e progettista.

Per chiarezza è opportuno definire alcuni concetti utilizzati nel resto di questo documento.

 Modello di Processo: Descrizione concettuale del processo per la produzione o la manutenzione del prodotto software. È costituito dalle seguenti componenti: il Work Flow diagram che descrive le fasi e le attività previste nel processo e la relazioni tra loro, espresse attraverso i manufatti; la descrizione degli attributi che specificano le variabili di processo per ogni attività elementare; la descrizione dello scenario procedurale che descrive la modalità di esecuzione di ogni attività elementare, attraverso le attività di base .

Piano di Progetto: Descrizione della sequenza con cui si possono eseguire le attività base  previste nel Work Flow diagram nel rispetto delle specifiche del modello di processo. Questo eredita dal modello di processo: la descrizione dei manufatti, le variabili di processo e gli scenari procedurali. Nel piano possono essere specificati gli attributi che nel modello di processo sono definiti genericamente per poter riutilizzare il modello in progetti differenti.

Piano Esecutivo: Descrizione del piano esecutivo attraverso le attività elementari, tracciabile solo dopo avere risolto tutti i problemi di indeterminazione che esistono nel piano di progetto ed avere definito esattamente la realizzazione di tutte le variabili di processo.

Il metodo presentato in questo documento parte dal formalismo con cui descrivere il modello di processo; il formalismo consente di verificare la completezza e la correttezza del modello di processo, in accordo con [13], anche nel caso in cui esso sia modificato durante l’esecuzione del relativo progetto per adeguarsi meglio ai cambiamenti che avvengono nella organizzazione esecutrice. Inoltre, è proposta una tecnica a incrementi successivi per la trasformazione del Piano di Progetto in Piano Esecutivo, conforme al modello di processo e che tiene conto delle modalità di realizzazione delle variabili di processo, degli eventi di progetto e delle decisioni assunte dal project manager; che possono modificare le variabili di processo durante l’esecuzione del progetto.

La descrizione del modello di processo, del piano di progetto e del piano esecutivo è strutturata perché nei modelli è prevista la posizione esatta della descrizione di ogni informazione necessaria, inoltre per ogni informazione è prevista la struttura della sua descrizione. Grazie all’approccio strutturato questi modelli sono facili da descrivere, modificare, leggere e comprendere.

 

1.1    Definizione Modifica e Verifica del Modello di Processo.

Il procedimento per la definizione e verifica di un modello di processo, secondo l’approccio proposto in questo progetto di ricerca, prevede i seguenti passi:

• Definizione e descrizione dei manufatti
• Definizione e descrizione del Work Flow diagram
• Definizione degli scenari procedurali
• Descrizione degli attributi specificanti le variabili di processo
• Verifica del modello di processo descritto.

I passi elencati non sono eseguiti necessariamente con la sequenza lessicale precedente. Ad esempio la definizione dei Work Flow Diagram e dei manufatti, in generale, è iterativa. Infatti l’ingegnere di processo qualche volta conosce meglio i manufatti, che descrive prima, e successivamente è in grado di descrivere le attività che li producono, mentre qualche altra volta conosce meglio le attività da eseguire e da queste deriva le descrizioni dei manufatti.

Anche gli attributi possono essere descritti contemporaneamente alla costruzione dei Work Flow Diagram e dei manufatti relativi.

Il Work Flow  Diagram consente di rappresentare l’insieme delle attività previste e le loro interfacce, come una rete di attività. L’insieme dei Work Flow Diagrams costituisce un insieme stratificato che evolve partendo dal processo visto come nodo radice sino ad arrivare attraverso raffinamenti successivi alle attività elementari.

La definizione e descrizione dei manufatti, è utilizzata per descrivere i prodotti finiti e semi finiti che costituiscono gli input delle attività o i loro output.  Il sistema software da produrre, viene visto come l’insieme di tutti i manufatti.

Uno scenario procedurale descrive in maniera univoca un’attività elementare. Uno scenario, è una sequenza di attività base che possono essere ottenute attraverso l’utilizzo di metodi tecniche e tools appositamente creati per raggiungere questo risultato.

Ad ogni componente vista sono associati gli attributi, con relativa descrizione,  necessari alla sua caratterizzazione. Alcuni attributi possono essere valutati in fase di definizione del modello di processo, altri quando questo è adattato alla produzione di uno specifico sistema software, altri ancora dinamicamente durante l’esecuzione del processo. La lista degli attributi associata ad ogni componente, in questo studio, non è da considerarsi esaustiva, ma in crescita al crescere dell’esperienza acquisita.

Nel presente metodo, viene adottato un formalismo tale da consentire il controllo di consistenza tra le componenti viste, il controllo automatico della coerenza interna di un processo, e rende inoltre possibile apportare qualsiasi modifica o adattamento al processo  senza che vengano generate inconsistenze.

1.1.1   Definizione e descrizione dei manufatti

I manufatti, descrivono i prodotti o documenti, finiti e semi-finiti che costituiscono gli input delle attività o i loro prodotti.  Il sistema software da produrre, viene visto come l’insieme di tutti i manufatti  descritti nella descrizione dei manufatti.

Sia D l’insieme dei manufatti che costituiscono il sistema software e N un insieme di interi. Su D possono essere definiti i seguenti operatori strutturati:

+ _D               : DxD        Þ  D                  (concatenazione)

/ _D           : DxD        Þ  D                  (alternativa)

m {}n     : NxDxN   Þ D                   (ripetizione)

Per le operazioni binarie è utilizzata la notazione infissa inserendo il simbolo “+” o “/” tra i due operandi cioè “a+b” o “a/b”. Per quanto riguarda le operazioni unarie è utilizzata una notazione analoga, cioè “0{a}n”.

Per maggiore chiarezza verranno mostrati di seguito alcuni esempi di utilizzo degli operatori introdotti: “a+b” significa che sia “a” che “b” sono presenti nella descrizione del manufatto, e precisamente che “a” precede “b”; “a/b” significa che “a” o in alternativa “b” sarà presente, e non saranno mai presenti contemporaneamente; l’operatore di ripetizione “m {a}n” specifica che l’elemento “a”  è ripetuto nel manufatto al minimo “m” volte, e al più “n” volte. Un caso particolare si presenta quando m=0, il che significa che l’elemento tra parentesi può essere presente o meno (opzionalità), e nel caso lo sia può essere ripetuto al massimo  “n” volte. Qualche volta, il valore di “n” è noto al momento della definizione del processo, mentre altre volte, è noto solo dopo la costruzione del prodotto. Ad esempio il numero di moduli di cui si compone un programma è noto solo alla fine della fase di disegno.

L’operatore di concatenazione, gode della proprietà associativa, pertanto  le parentesi possono essere rimosse senza creare ambiguità. Per esempio, “a=a₁+a₂+a₃” può essere scritto anche come “a=(a₁+a₂)+a₃” o ancora come “a=a₁+(a₂+a₃)”. La proprietà commutativa  non è  valida, infatti  oltre alla presenza della sotto componente, l’operatore di concatenazione  specifica anche l’ordine lessicale in cui la sotto componente appare.

L’operazione che specifica l’alternativa gode sia della proprietà associativa che di quella commutativa ed è inoltre distributiva rispetto all’operazione di concatenazione.

Ogni manufatto D prodotto o utilizzato è univocamente identificato da un’etichetta. I manufatti etichettati formano una gerarchia descrivibile attraverso gli operatori strutturati: il manufatto D è la radice dell’albero mentre i nodi intermedi e finali sono sotto manufatti etichettati in esso compresi. Chiameremo l’albero di decomposizione appena introdotto albero di decomposizione dei manufatti.

In figura 1 viene mostrato un esempio di descrizione del manufatto chiamato “Documentazione del Software”. Viene per prima cosa definito l’insieme delle sue componenti (sotto manufatti); segue per ogni componente la specifica di dettaglio,  nel caso specifico viene dettagliato “Manuale Utente”; infine è descritto un attributo associato a “Condizioni di Errore”.

1.2    Definizione e descrizione del Work Flow Diagram

Il Work Flow di un generico sistema S può essere formalizzato attraverso un Diagramma di Flusso Formale (Formal Data Flow Diagram FDFD) [13], che combina la modellizzazione delle funzioni di un Diagramma di Flusso dei Dati (DFD)  tipico dell’analisi strutturata, con il modello comportamentale caratteristico delle reti di Petri.

La definizione di un Work Flow Diagram sfrutta il principio di decomposizione top down, che consente di decomporre gerarchicamente il sistema iniziale per livelli di astrazione.

Un Work Flow è definito come una 4-pla W=(D_w,T,I,O) dove :

• D_w è un sottoinsieme dei manufatti etichettati presenti in W;
• T è un insieme finito di attività o fasi ;
• I:TÞE e O:TÞE sono funzioni che definiscono gli input e output logici necessari all’attivazione di una attività o fase; “E” denota l’insieme delle espressioni booleane che possono essere generate utilizzando gli operatori logici “AND” e “OR” definiti sull’insieme dei manufatti

La rappresentazione grafica di un Work Flow è identica a quella di un Diagramma di Flusso dei Dati, dove i processi coincidono con le attività, i flussi di dati coincidono con i manufatti, e gli operatori logici utilizzati, per esprimere le logiche di input e di output, sono “AND” e “OR” .

I processi complessi sono costituiti da molte attività, e il loro modello risulta quindi difficile da leggere; per questo motivo è utile, se non addirittura necessario, suddividere  i Work Flow per livelli di astrazione differenti, in cui generalmente, ogni attività T_i è descritta  attraverso un Work Flow di dettaglio  W_i = (D_i, T_j, I, O). Il raffinamento successivo delle attività può essere rappresentato attraverso un albero,  in cui i nodi corrispondono alle attività e i rami alle relazioni padre-figlio tra queste. Il nodo radice rappresenta l’intero progetto.  L’albero di decomposizione che descrive la decomposizione dei Work Flow, è chiamato Work Flow System (WFS).

Gli operatori logici tra i manufatti che rappresentano gli input e gli output logici, devono essere  considerati in maniera corretta nel dettaglio del WF al fine di mantenere la consistenza all’interno del WFS.

L’esempio di seguito chiarisce i concetti appena introdotti:

il Work Flow dell’attività chiamata “Analisi dei Requisiti” in Fig.2 è dettagliata in Fig.3; quest’ultima è l’espressione grafica della descrizione formale di seguito mostrata:

D = Contratto Utente, Richieste Utente, Requisiti Strutturati, Errori, Requisiti Strutturati Verificati,……

T = Analisi del Sistema, Disegno del modello, Verifica del Modello,….

I = (Analisi del Sistema; Documentazione Cliente), (Disegno del modello; Richieste Utente OR Errori),…….

O = (Analisi del Sistema; Richieste Utente), (Analisi delle Operazioni; Rischio AND Piano delle Operazioni),….

1.2.1   Definizione degli scenari procedurali

Ad ogni attività elementare nel Work Flow System è associato uno scenario procedurale che specifica la natura dell’attività nel dettaglio, attraverso un’insieme di attività base. Uno scenario procedurale è una 5-pla PD = (isc,iec,D_p,B_p,OP_p).

Le “isc” e le “iec” sono le condizioni interne di ingresso (internal starting conditions) e condizioni interne di uscita (internal ending condition). Le “isc” devono essere vere al fine di poter attivare l’attività elementare a cui sono riferiti. Le condizioni di ingresso sono un’espressione booleana che legano, attraverso operatori logici, eventi temporali, attributi della attività e le condizioni di uscita imposte dagli altri processi.La scelta di rappresentare le condizioni di entrata e uscita solo all’interno degli scenari procedurali:

• semplifica la lettura di un progetto dando una rappresentazione grafica non carica eccessivamente di informazioni;
• rende possibile il riutilizzo del processo in altri contesti grazie al fatto che i cambiamenti da apportare sono localizzati nella descrizione delle attività, e quindi non impattano sull’intera struttura.

L’insieme di D_p rappresenta un insieme di manufatti etichettati che costituiscono l’albero di decomposizione dei manufatti. D_p include i manufatti di I(T) e O (T) relativi all’atività elementare T e i loro discendenti nell’albero di decomposizione dei manufatti.

B_p rappresenta l’insieme delle azioni di base che vanno a costituire l’attività elementare. Un’ attività base, come le attività nei Work Flow, può essere definita come qualcosa che trasforma un input in un output. Nelle attività base, differentemente dalle attività in un Work Flow, gli input e output logici legano sempre i manufatti in AND e non ci sono condizioni interne. Dal punto di vista grammaticale una attività base è una frase del tipo (verbo) (0utput) USANDO (input): dove (verbo) denota l’azione e (0utput) ed  (input) denotano l’espressione logica dei manufatti prodotti e l’espressione logica dei manufatti usati. Si può fare riferimento a un’ attività base con un’etichetta che indica il livello dell’attività elementare più un numero sequenziale (es. 1.2.1,1.2.1,……per lo scenario procedurale dell’attività elementare 1.2)

Sull’insieme delle attività base che costituiscono la attività elementare, è possibile definire gli operatori OP_p  di:

• sequenza: seq(b₁, b₂, , b_n);
• alternativa a una via: if then (b₁);
• alternativa a due vie: if then else (b₁, b₂);
• alternativa a n vie: (b₁, b₂, , b_n);
• iterazione condizionata con opzione: while (b_i)
• iterazione condizionata con compulsione: repeat (b_i)
• iterazione incondizionata: for each (b_i)

La rappresentazione grafica di uno scenario procedurale è molto simile a una specifica procedurale utilizzata nei linguaggi strutturati. Ad esempio in fig.a e fig.b vengono descritte rispettivamente lo scenario procedurale  dell’attività elementare 1.2 e la relativa descrizione dei manufatti.

 

1.2.2   Descrizione degli attributi

Ad ogni componente sino a questo punto descritta, sono associati sia la descrizione sia gli attributi necessari alla sua caratterizzazione. Gli attributi rappresentano un insieme di proprietà caratteristiche della componente considerata, cioè le variabili di processo utili ad esplicitarne il comportamento. Alcuni attributi  possono essere valutati in fase di definizione del modello di processo, altri quando questo è adattato alla produzione di uno specifico sistema software, altri ancora dinamicamente durante l’esecuzione del processo. La lista degli attributi associata ad ogni componente, in questo documento, non è da considerarsi esaustiva, ma ampliabile al crescere dell’esperienza maturata, e a seconda delle esigenze della specifica organizzazione.

Un  manufatto etichettato, ha una serie di attributi A_d , che lo caratterizzano, tra cui:

• metriche di qualità,
• supporti di comunicazione,
• formato,
• standard di presentazione,
• istruzione di compilazione.

Gli attributi associati ad ogni manufatto saranno un sotto insieme di tutti i possibili attributi (in?)dipendentemente dal contenuto e dall’uso del prodotto a cui fa riferimento. Per esempio un programma avrà “parametri di qualità” e “stile di presentazione”, mentre un manuale avrà “istruzioni di compilazione”; tutti i manufatti che saranno condivisi da più utenti o sviluppatori avranno associato l’attributo “supporto di comunicazione”, che indica come l’informazione associata ad ogni manufatto viene scambiata tra gli interessati.

Ogni Attività, è anch’essa caratterizzata da un insieme di attributi A_T, tra cui:

• priorità di esecuzione,
• data inizio attività,
• data ultima fine attività,
• stato attività ecc..

Nella definizione di un’ attività, viene utilizzato il principio di decomposizione top down. Pertanto bisogna fare alcune considerazioni riguardo al rapporto esistente tra un’ attività e le relative sotto-attività: gli attributi di ogni attività, sono ereditati dalle sotto attività di livello inferiore, sino al livello elementare dove sono esplicitamente dettagliati. Ad esempio se l’attributo “stato di avanzamento” dell’attività T_i “Eseguire test di unità” è “in corso”, le sotto attività che lo compongono sono anch’esse da considerarsi nello stato “in corso”.

Le attività base, sono descritte attraverso un insieme di attributi, in numero  maggiore al caso di un’attività di più alto livello. Ciò avviene in quanto trovandosi al livello di astrazione più basso, è necessario caratterizzare con maggior precisione gli aspetti d’interesse.

Gli attributi più comuni di una attività base sono:

• competenze,
• tools,
• tecniche e metodi utilizzati per la sua esecuzione,
• modelli per la stima dei tempi,
• sforzo
• costo,
• misurazioni per documentare lo stato di avanzamento dei lavori,
• priorità,
• consegna
• stato ecc..

L’utilizzo di un modello di processo e della specifica dei manufatti rendono possibile il riutilizzo di componenti in progetti futuri. Anche l’utilizzo degli attributi risulta essere molto vantaggioso ai fini del riuso di un modello di processo, o al fine della modifica di quest’ultimo. Infatti le caratteristiche instabili del modello, sono localizzate negli attributi dei manufatti, delle fasi e delle attività base, ed è perciò possibile effettuare modifiche al modello di processo senza grossi effetti o con effetti limitati.

 

1.2.3   Verifica del Modello di Processo.

Le verifiche eseguibili sul modello di processo sono classificabili in  statiche e dinamiche. Le prime sono eseguite direttamente sulla descrizione del modello di processo, le seconde sono eseguite su un modello di simulazione della esecuzione dinamica del modello descritto.

1.2.3.1   Verifiche Statiche

Su ogni componente si possono effettuare una serie di verifiche statiche che ne assicurano la consistenza

Manufatti.

Con riferimento alla struttura di un  manufatto può essere effettuata una forma ridotta  di controllo di consistenza: Consistenza Globale