Roberto Dadda
|
|
La software factory, un gigante con i piedi di argilla!
In principio era lo waterfallNei secondi anni settanta, con lo realizzazione di progetti software sempre più grandi e costosi, ci si rese conto di essere davanti ad un grave problema. I progetti partivano con pianificazione precisa e con regole ferree, ma arrivavano tutti alla fine con numeri molto peggiori da quelli previsti e con livelli di entropia di sistema pericolosamente alti. Diventava difficilissimo rispettare tempi e costi e la qualità del prodotto finito tendeva a decadere con grandi problemi di debug, modifica evolutiva e manutenzione ordinaria.
L'immagine è tratta dall'articolo originale dove Winston W. Royce introduce il concetto di sviluppo a cascata. L'articolo originale è un documento molto illuminante e descrive nel contempo sia il meccanismo a cascata che i suoi rischi intrinseci e i metodi possibili per apportare correzioni: purtroppo apparentemente tutti si sono limitati alle prime pagine tralasciando le altre! Gli studiosi di ingegneria del software analizzarono il problema ed arrivarono ad una unanime conclusione: il problema, come spesso accade, nasceva dal fatto che si ragionava sulla base di un modello assolutamente non applicabile cercando di imporre un metodo che nella realtà veniva sistematicamente e costantemente disatteso nella realtà. In buona sostanza la suddivisione in fasi rigidamente separate da documenti non è il modo con il quale il software può essere prodotto. Gli unici casi di successo furono quelli, rarissimi, dove si lavorava con specifiche complete e completamente congelate e con architetture hardware e software altrettanto congelate. Anche in quei casi di solito la cosa è stata per forza di cose relegata alla realizzazioni di parti comuni della infrastruttura in fabbriche di software che di fatto al loro interno avevano però comunque anche chi rielaborava le specifiche. Nacquero a quel punto nuovi concetti architetturali ed operativi: gli oggetti da una parte e la prototipazione ciclica dall’altra. L’approccio parte dall’idea di abbandonare il tentativo di imporre la utopica netta separazione tra specifica, realizzazione e test passando ad un modello operativo che costituisse un più fedele modello del reale processo utilizzato da chi credeva erroneamente di applicare un impossibile processo di sviluppo a cascata. Una brillante applicazione di questi concetti venne presentata da IBM sotto il nome di ADCycle, una proposta di strumenti e metodi per la realizzane di processi di prototipazione ciclica (protocycling). Il successo commerciale della iniziativa venne ucciso dal tentativo, tipico della IBM di quei tempi, di limitarlo a strumenti proprietari, ma il concetto era giusto e viene oggi applicato nello sviluppo si sistemi software. A volte tornano…Mentre tutto questo accadeva qualcuno ebbe l’idea di ipotizzare un possibile parallelo tra produzione di software ed industria automobilistica: nacque l’idea di una catena di montaggio, la software factory, che realizzasse i sistemi sulla base di specifiche dettagliate e congelate che qualcuno avrebbe dovuto preventivamente preparare. Fu quasi sempre un disastro, con l’esclusione dei pochissimi casi sopra citati di congelamento assoluto delle specifiche e delle architetture. Perché mai il metodo dovrebbe funzionare per l’industria per esempio automobilistica e non per il software? La risposta è semplice: non funziona così nemmeno lì! Se analizziamo come avviene la realizzazione di una automobile ci rendiamo conto che la catena di montaggio non è quella dove la macchina viene ideata, provata e corretta sulla base degli obiettivi e delle esigenze dell’utente, ma semplicemente quella dove le automobili vengono riprodotte nella quantità di esemplari richiesta. La macchina nasce in uffici di progettazione e di realizzazione di prototipi che via via diventano sempre più vicini a quello che sarà il modello finale. In quel ufficio lavorano a stretto contatto di gomito le persone che specificano, quelle che realizzano prototipi e quelle che li provano con un processo del tutto analogo al citato protocycling: solo a un pazzo verrebbe in mente di separare queste attività! Tutto questo non esclude un metodoLa maggior parte degli strumenti di sviluppo prevede in modo esplicito il metodo della rapida prototipazione ciclica che non rappresenta una deregolamentazione delle operazioni di sviluppo del software, ma la regolamentazione e la organizzazione di quello che, alla prova dei fatti, risulta essere l’unico modo logico per realizzare macchine complesse, e il softare è una macchina molto complessa. maggio 2005 |
|
