analisi-disegno.com
Lo sviluppo software è periodicamente oggetto di mode, in cui vengono propagandati nuovi strumenti miracolosi. Gli anglosassoni li chiamano "silver bullet", pallottole d'argento. Solo grazie alle pallottole d'argento, narrano le leggende, è possibile uccidere avversari particolarmente ostici come lupi mannari, mostri e vampiri.
Nel software, le pallottole d'argento risolverebbero una volta per tutte, secondo i propagandisti, i problemi di produttività e di qualità dello sviluppo.
Tra le pallottole d'argento di moda negli ultimi decenni spiccano quelle legate agli strumenti Case, ai generatori di codice, al model driven engineering, e naturalmente al riuso. Cose interessanti e (in parecchi contesti) utili. ma che alla prova dei fatti si sono spesso dimostrate meno efficaci e più costose di quanto asserisse chi aveva interesse a diffonderle. È la caratteristica comune a tutti i silver bullet del mondo del software, come asseriva, oltre vent'anni fa, nel 1986, un celebre articolo di Fred Brooks: "No Silver Bullet - Essence and Accident in Software Engineering", istruttivo e attuale oggi come quando fu scritto.
Esiste al contrario una pratica molto efficace e poco costosa, per la quale sono ampiamente dimostrati gli effetti positivi sulla qualità e sulla produttività dello sviluppo software. Eppure, questa pratica viene poco raccomandata, forse perché nessun propagandista ha un interesse concreto alla sua diffusione. È la pratica del confronto. La peer review, revisione tra pari, o tra colleghi.
La revisione tra pari funziona così: quando produco qualcosa (ad esempio una specifica di requisiti, un design, un programma, un piano di test), lo faccio esaminare da altre persone. Possono essere persone che ricoprono il mio medesimo ruolo, e allora ad esempio se io fossi un analista sottoporrei la mia specifica dei requisiti all'esame di altri analisti. Oppure possono essere persone che ricoprono ruoli complementari al mio, e allora sottoporrei la specifica all'esame di progettisti, sviluppatori, tester.
Perché la revisione tra pari funziona, e migliora produttività e qualità? Perché con un costo molto basso aiuta a scoprire rapidamente i difetti, permette la condivisione di tecniche efficaci e l'eliminazione di altre meno adeguate, favorisce l'apprendimento e la crescita della conoscenza. Anche quando chi produce il prodotto da esaminare è molto esperto, e chi lo esamina è un principiante, la revisione tra pari è efficace. Il principiante impara, ma aiuta anche l'esperto a individuare sviste e possibili miglioramenti.
Quali sono gli ostacoli alla sua diffusione? Possono essere a volte di tipo psicologico: ho paura a far vedere ad altri il mio lavoro, perché sono insicuro della mia abilità e temo le loro critiche. O, al contrario, mi ritengo talmente superiore ai miei colleghi che vivo il confronto con loro come una pura perdita del mio tempo prezioso.
Più frequentemente, però, si tratta di ostacoli legati alla cultura dell'organizzazione, che non favorisce o addirittura scoraggia la collaborazione e il confronto tra colleghi.
Non si tratta mai di direttive esplicite, naturalmente. Si tratta sovente, invece di una serie di fattori concomitanti: l'abitudine a guardare al proprio orticello, la diffidenza, la competizione, l'accentramento delle responsabilità operative su pochi individui iper-impegnati. Fattori "sottili", su cui il management può intervenire in modo da modificarli. Purché il management, per primo, sia consapevole dei benefici della revisione tra pari. E dei rischi che si corrono quando non vengono favoriti la collaborazione e il confronto.
*** UML 2.2 e SysML 1.1 ***
L'Object Management Group (OMG) ha approvato le nuove versioni di:
*** La nuvola ***
The cloud - la nuvola. L'infrastruttura di elaborazione evaporata.
O, meglio, servizi di elaborazione erogati allo stesso modo dell'energia elettrica, da grandi centrali che garantiscono una continua disponibilità. Le stanno costruendo, tra gli altri, Microsoft, Google, IBM, HP, Amazon.
Una soluzione attraente - in termini di costi - per diverse tipologie di potenziali clienti. Ma con rischi significativamente diversi rispetto ad altre forme di outsourcing.
Al cloud computing è dedicato un inserto pubblicato il 23 ottobre dall'Economist: http://www.economist.com/specialreports/displaystory.cfm?story_id=12411838
Se volete, potete contribuire ad ANALISI-DISEGNO:
ANALISI-DISEGNO viene spedito a chi ne fa richiesta. La pubblicazione non avviene con periodicità predefinita.
Archivio notiziari | Notiziario precedente | Notiziario successivo
analisi-disegno.com , servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.