Programmazione/L'Extreme Programming (I)

Programmazione/L'Extreme Programming (I)

Le metodologie di sviluppo del software contemplano quasi esclusivamente le necessità di grossi team di lavoro. In questa serie di articoli vedremo che anche nelle piccole realtà un modello di produzione del software può avere la sua importanza
Le metodologie di sviluppo del software contemplano quasi esclusivamente le necessità di grossi team di lavoro. In questa serie di articoli vedremo che anche nelle piccole realtà un modello di produzione del software può avere la sua importanza


Spesso, troppo spesso, la produzione di software è vista come un’attività artigianale. Il programmatore, quasi un eroe romantico, affronta mille problemi forte della propria intuizione e capacità di improvvisazione. Fornito di mille manuali e un folto gruppo di newsgroup a cui porre quesiti, passa nottate intere alla luce del monitor a battere migliaia di righe di codice. Sebbene la genialità, una buona libreria di manualistica e la possibilità di disporre di un’efficiente rete di comunicazione con esperti di vari settori siano cose tutte importantissime, la visione presentata è sicuramente almeno riduttiva rispetto alla realtà delle cose.

La produzione di un sistema software è un’attività altamente articolata che coinvolge varie fasi: giusto per citarne alcune si va dall’analisi dei requisiti alla progettazione di massima, dalla progettazione logica dei dati all’implementazione fisica di un database. Tutte queste fasi prevedono precise competenze, e una certa organizzazione dev’essere presente per garantire che le informazioni prodotte in ogni fase flluiscano correttamente attraverso quelle successive.
L’organizzazione di queste fasi e delle risorse, anche umane, da assegnare ad ognuna di esse è quello che va sotto il nome di modello di processo software.

Chiaramente fino a che si considerano sistemi di piccole dimensioni, come quelli che si potrebbero veder funzionare sul PC del cartolaio sotto casa, la necessità di un modello di processo software ben definito non si fa sentire più di tanto. La produzione di un sistema simile può essere effettivamente compito di una sola persona che, inoltre, non ha bisogno di disporre di particolari competenze. Sono infatti in commercio vari strumenti che permettono la creazione di piccole applicazioni senza dover ricorrere alla programmazione o facendolo solo in minima parte.

Il problema si fa più spinoso quando si parla di sistemi di dimensioni più ragguardevoli, progetti che, per intenderci, non possono essere gestiti da una sola persona e che sono destinati a clienti che pretendono determinate garanzie di qualità e affidabilità del prodotto e del processo di produzione. Sotto queste condizioni ci si trova presto nella necessità di disporre di uno strumento che permetta di gestire i compiti rivestiti da ogni elemento del team di sviluppo in modo tale da avere in ogni momento un’idea chiara su chi stia facendo cosa, quanto ci metterà, a chi è destinato il risultato della sua attività, e cosa dovrà fare dopo. E’ necessario inoltre monitorare il processo di produzione per essere in grado di determinarne in ogni istante il grado di avanzamento e stimarne i tempi di completamento e i costi globali e locali ad ogni attività.

Queste problematiche sono comuni per le grosse compagnie che hanno a che fare con clienti del calibro del dipartimento della difesa americano, oppure con grosse banche, o con multinazionali, ma sono sicuramente meno conosciute e comprese in realtà più piccole. Il paradosso è che nonostante le piccole software house potrebbero trarre grandi vantaggi dall’adozione di un modello di produzione software ben definito, non dispongono delle risorse necessarie ad implementare una delle metodologie proposte dal mondo della ricerca, che in questo caso raccoglie tanto l’ambiente accademico quanto quello industriale. Tanto per usare un po ‘ di gergo tecnico, si potrebbe dire che queste soluzioni non “scalano” bene su piccoli gruppi di sviluppo, sono infatti pensate per grossi team, dell’ordine di diverse decine di persone, se non di qualche centinaio.

In questa serie di articoli vedremo, brevemente, cosa si intende per modello di processo software. Verrà descritto quello che storicamente è il primo modello di processo software presentato. Tramite questo esempio sarà possibile fissare alcuni concetti base e un po ‘ di terminologia. Si parlerà poi di Extreme Programming, una proposta nel panorama dei modelli di processo software che sembra bene adattarsi alle piccole realtà, quelle, per intenderci, con le quali potrebbe trovarsi ad avere a che fare uno qualsiasi dei nostri lettori. L’appuntamento è dunque alla prossima settimana con il secondo articolo della serie.

Simone Semprini

Link copiato negli appunti

Ti potrebbe interessare

Pubblicato il
20 mar 2000
Link copiato negli appunti