Eccoci alla seconda puntata che fa da introduzione all’argomento principe, il processo software detto “Extreme Programming”.
Riassumiamo quello che è stato detto la volta scorsa. Esclusi alcuni casi (progetti di dimensioni giocattolo), l’attività di produzione software non può essere ridotta alla pura e semplice programmazione: si possono individuare diverse fasi nell’evoluzione di un progetto e ad ogni fase corrispondono competenze e professionalità ben precise; è necessario organizzare le attività che realizzano queste fasi in modo da ottimizzare il flusso dei sottoprodotti che da esse scaturiscono e la gestione delle risorse, economiche e umane destinate al progetto. Il processo di produzione va costantemente monitorato, anche ricorrendo ad opportune metriche, per essere in grado di intervenire se sono necessarie modifiche e per quantificare i risultati ottenuti da una particolare organizzazione piuttosto che un’altra.
Si arriva quindi alla seguente definizione: un modello di processo software descrive come organizzare, gestire, supportare, misurare e migliorare le attività che concorrono alla realizzazione delle varie fasi dell’attività di produzione software.
Si parla separatamente di organizzazione e gestione perché è bene sottolineare il fatto che esistono tanto problematiche legate alle relazioni che sussistono fra le varie attività, quanto problematiche legate alla gestione delle risorse (umane, economiche, tecnologiche, etc.) necessarie all’implementazione del modello.
Chi partecipa a progetti basati su un dato modello di processo software deve soddisfare determinati obblighi, deve conformare il suo modus operandi agli schemi proposti dal modello. Quando si parla di supporto ad un processo di produzione software ci si riferisce a tutti quegli strumenti che rendono più agevole seguire le regole imposte dal modello: per esempio, se è prevista un’attenta gestione dei versionamenti del codice prodotto allora può essere opportuno adottare uno dei tanti strumenti in commercio che si prestano allo scopo; od ancora, se si deve gestire un archivio degli errori con relativi ambiti, cause, soluzioni, problemi aperti, allora può essere opportuno sfruttare un qualche database che permetta di usufruire in maniera ottimale delle informazioni raccolte. E’ poi necessario effettuare delle misure sul processo, perché per controllare ed eventualmente migliorare qualcosa, bisogna prima disporre dei dati necessari a conoscere quello ciò su cui si sta focalizzando l’attenzione. Disponendo di informazioni di carattere quantitativo sul processo è possibile sottolinearne pregi e difetti e intervenire là dove necessario per poi effettuare nuove misure e valutare i risultati del proprio intervento.
Giusto per presentare un esempio concreto, prendiamo in esame il capostipite dei modelli di processo software: il Waterfall Model, o Modello a Cascata.
Il modello a cascata è stata una reazione alle scioccanti rivelazioni scaturite da attente analisi sui costi delle varie fasi nel ciclo di vita del software. Queste fasi potrebbero essere grossolanamente identificate nelle seguenti: analisi, design, implementazione, test e manutenzione. L’analisi corrisponde alla raccolta dei cosiddetti requisiti, ovvero la descrizione delle caratteristiche che un sistema deve esibire per essere quello che il cliente vuole. Il design è la fase di progettazione: i requisiti raccolti in varie interviste con il cliente, vengono usati per ottenere una descrizione del sistema che possa essere di guida nella fase di implementazione. Tipicamente in questa fase vengono prese decisioni circa l’architettura del sistema, il tipo di organizzazione dei dati, l’organizzazione in moduli delle funzionalità che il sistema deve fornire, i piani di testing e tante altre cose. La fase di implementazione, infine, è, piuttosto intuitivamente, quella in cui le decisioni e le linee guida che vengono dalle fasi precedenti sono concretizzate nel codice.
Torniamo alla genesi del modella a cascata. Si era scoperto che i costi della correzione di eventuali errori crescevano esponenzialmente in funzione del ritardo in cui i difetti venivano individuati, fino ad assumere proporzioni decisamente preoccupanti nel caso in cui questi difetti fossero individuati a consegna del prodotto avvenuta. Il modello a cascata proponeva una soluzione a questa situazione: cercare di produrre un prodotto che fosse il “più perfetto” possibile sin dall’inizio, così da ridurre la necessità di intervenire in seguito. Per fare ciò, la produzione di software viene organizzata nelle fasi di cui sopra e queste vengono inserite in una successione strettamente sequenziale come quella proposta in figura.
L’obiettivo è quello di congelare in fase di analisi un insieme di requisiti il più completo possibile. Questo documento viene passato a chi si occupa della progettazione che in fase di design produce le specifiche del sistema da sviluppare. Queste specifiche, così come i requisiti, sono da considerarsi definitive. Le specifiche guidano infine l’implementazione durante la quale vengono prodotti tutti i moduli in cui il sistema è stato composto in fase di design. Questi moduli vengono uniti e si procede ai test di integrazione e a quelli di sistema, dopodiché il gioco è fatto: il sistema viene consegnato e installato presso il cliente.
L’idea di riuscire a dare una descrizione completa e corretta del sistema al primo colpo, però, si è dimostrata troppo ottimistica. Spesso i requisiti cambiano durante il processo stesso di sviluppo e le ragioni di ciò possono essere molteplici: il cliente ha cambiato idea su di una caratteristica del sistema; gli analisti hanno commesso un errore; una soluzione si rivela non fattibile per ragioni di budget, sheduling, tecnologiche, od altro ancora.
Non è infrequente che in fase di implementazione ci si renda conto della necessità di cambiare le carte in tavola e di dover ritoccare le specifiche del sistema per adattarsi a nuovi requisiti. Il limite del modello a cascata sta proprio nella sua eccessiva rigidità e nel non aver compreso che una certa ciclicità nel processo di produzione è inevitabile, per cui può essere necessario in fasi avanzate ritornare alla fase di design.
Dal modello a cascata di acqua sotto i ponti ne è passata parecchia e le soluzioni proposte sono molte, alcune delle quali hanno riscosso anche un grande successo commerciale come il Rational Unified Process, ma presentarne anche solo alcune significherebbe forzare i limiti giustamente fissati per questa breve panoramica. I lettori potranno comunque contattarmi per ogni quesito in merito all’argomento.
Abbiamo già osservato come l’adozione di un processo software, o come sarebbe meglio dire, l’implementazione di un particolare modello di processo software, seppur utile al fine di ottimizzare il rapporto costo/beneficio, può essere in pratica irrealizzabile per team di piccole dimensioni. Esistono dei costi, in termini di risorse umane, tempo sottratto ad altre attività, che devono essere affrontati e che per una software house che può contare solo su una manciata di persone, possono essere inaccettabili. Oltre ai semplici costi di “mantenimento” del processo bisogna infatti considerare anche quelli relativi alla formazione del personale. Raramente chi lavora in piccole imprese ha il background culturale necessario ad accettare l’introduzione di pratiche del genere e deve quindi essere istruito e appoggiato da personale qualificato tanto nella fase di introduzione di un particolare processo, quanto nel periodo successivo di stabilizzazione e miglioramento del processo.
Le proposte di modelli di processo che si trovano comunemente in letteratura sono, in genere, adatte a organizzazioni di grosse dimensioni che possono contare su una forza lavoro di diverse centinaia fra esperti di processo, software engineer, programmatori e altre figure professionali. Esistono però tentativi di scalare queste soluzioni al mondo delle piccole software house: uno dei più recenti ed interessanti è proprio l’Extreme programming di cui tratteremo più diffusamente nel prossimo articolo.
Ti potrebbe interessare
3 apr 2000