Meditare
CONSIDERAZIONI VARIE DA MEDITARE
.i.Leggi non scritte
Le leggi non scritte del mondo informatico
In genere vengono considerate battute umoristiche, mentre piu' frequentemente esprimono sacrosante verita'.
I maggiori "guru" del mondo informatico sono famosi per alcune affermazioni, nel gergo normale ribattezzate come "leggi", che riescono a descrivere con grande efficacia certi rapporti di causa-effetto che frequentemente si verificano nelle aziende. Osservate e studiate con assoluta precisione nelle grandi "corporation" multinazionali, si scopre ora che gran parte di queste "leggi non scritte" valgono anche nel mondo delle aziende medieúe piccole, che frequentemente ripetono esattamente gli stessi errori delle imprese maggiori. E' utile quindi fare lorouna breve rassegna anche agli EDP manager del mondo dei medi sistemi IBM con l'auspicio che la loro conoscenza possa aiutarli ad evitare alcuni fra gli errori piu' banali e ricorrenti del mondo EDP.
La legge di Conway
"I sistemi infomativi tendono ad assomigliare alle aziende che li sviluppano". Analisti e programmatori che per anni hanno disegnato applicazioni su misura sforzandosi di di ritagliarle ad immagine e somiglianza delle loro utenze con l'accettazione acritica di ogni richiesta, avrebbero spesso meccanizzato anche le piu' razionali inefficienze mentre era loro preciso dovere creare un sistema informativo tecnicamente avanzato nell'ambito di una struttura organizzativa disposta a recepire anche una revisione critica e una riorganizzazione belle procedure interne.
La legge di Brooks '
"Mettere nuove persone in un progetto software gia' in ritardo lo fa ritardare ancora di piu'". Frederick Brooks e' uno dei responsabili che a suo tempo gestirono lo sviluppo del sistema operativo per i mainframe 370 della IBM. Gome e' noto, il progetto si svolse con grandi difficolta' spingendo cosi Brooks a scrivere la sua esperienza nel libro "The Mythical Man-Month" ("Il mitico mese-uomo"), un classico della letteratura infonnatica che descrive i prolemi della gestione di un progetto software. In sostanza, e' inutile inserire altre persone in un progetto allo stato avanzato di sviluppo perche' i nuovi arrivati riducono il rendimento di coloro che lavorano, dovendo questi procedere al loro addestramento.
Tanto piu' si e' avanti, tanto piu' il progetto puo' irrimediabilmente rimanere indietro nel calendario dei lavori
La legge di Gilb
"C'e' sempre un modo per cercare di misurare qualcosa e questo e' preferibile al non misurarla per niente".
Cercando di valutare in termini economici l'impatto di alcuni grossi progetti oppure il valore aggiunto di certe applicazioni, mi sono trovato ad affrontare in pieno le tematiche della teoria di Tom Giib, uno dei cercatori a occuparsi di produttivita' applicata allo sviluppo del software.
Purtroppo le misurazioni relative al valore di un nuovo know how, della produttivita' acquisibile con una applicazione ed altri aspetti del mondo delle informazioni sono molto difficili da misurare in una azienda. Se, ad esempio, in uno staff EDP minimo devo perdere una risorsa, chi scegliere? Ipotizziamo di avere due dipendenti; Roberto sta lavorando ad un'interfaccia di comunicazioni per avviare un magazzino esterno, mentre Paola sta modificando un pacchetto software che dovrebbe servire all'ufficio spedizioni per individuare e scegliere il corriere piu' economico fra quelli disponibili. Dovendo rinunciare ad uno dei due progetti, come misurare quale dei due potrebbe potenzialmente dare una maggiore redditivita' all'azienda?
Chiaramente e' piu' facile contestare determinate misurazioni piuttosto che tentare di delinearle e quindi si tende spesso a evitarle a causa della palese aleatorieta' dei metodi adottati. Tuttavia, il non farle, e' sempre un male peggiore. Se non si tenta di fare una valutazione, non e' possibile prendere corrette decisioni. Poiche' l'arte della gestione EDP comprende anche la capacita' di intuire le misurazioni dei fatti cbe intervengono in un dato processo, non si potra' mai giustificare quali interventi gestionali siano piu' appropriati se non si prepara un criterio minimo di misurazione quale punto di riferimento. La legge di Gilb ha poi come sottoprodotto la metafora di Humphrey. Secondo Watts Humphrey, autore di un "modello di maturita' di un processo" in uso attualmente al Software Engineering Institute, "Se non sapete neanche dove siete, allora non vi serve a nulla disporre di una mappa del territorio". Insomma se non si usano delle metodologie, piu' o meno buone che siano, allora tutto e' lasciato al regno sovrano della improvvisazione.
La legge di Bachman
"Lo sviluppo applicativo non esiste piu'; e' rimasto solo un processo di manutenzione piu' o meno radicale".
Diciamoci la verita': non e' certo un segreto il fatto che tutti noi preferiamo sviluppare nuovi progetti piuttosto che rischiare di annegare nella manutenzione del vecchio software.
Ma e' sacrosanto che le funionalita' di base fornite nei sistemi in via di sviluppo sono quasi sempre le stesse che gia' si trovavano nei sistemi che si intende sostituire. I progetti di nuovo sviluppo vengono in genere avviati quando un sistema applicativo non funziona piu' entro accettabili limiti di efficienza, di costi di manutenzione e di scadenze .di termini di consegna. Come ha osservato Charles Bachman, fondatore ella societa' CASE Software, gran parte di quello che noi chiamiamo "nuovo sviluppo" in realta' non lo e'.
Cambiano le modalita' con le quali sono fornite le funzionalita' del sistema, ma spesso il tutto non cambia radicalmente in termini strutturali per cui puo' essere utile considerare una qualche forma di recupero del patrimonio software precedente.
La legge di Thomsett
"Per i grandi sistemi, mainframe in particolare, non esiste alcuna cosa che possa essere assimilata, in termini concettuali, ad una piccola modifica". Questa legge ci arriva addirittura dall'Australia, per gentile concessione di un consulente informatico (ed ex EDP manager) Rob Thomsett. Secondo Thomsett, tanto piu' grande e' il sistema, tanto piu' lavoro e tempo ci vogliono per capire, progettare e implementare le eventuali modifiche. In questo caso, tanto piu' alta e' la possibilita' di trovare errori quando si fanno i test e tanta di piu' e'la documentazione che dovra' essere modificata. Quindi chi va sulla strada dell'accentramento EDP, deve accettarne le relative conseguenze. Deve sapere che quando si punta ostinatamente alla centralizzazione basandosi su grossi sistemi che, sfuggendo di mano, diventeranno sempre piu' elefantiaci, allora le modifiche piu' banali non saranno certo veloci, anzi tenderanno a diventare un fatto molto costoso per l'azienda.
La legge di Myers
"Un buon test sul software e' quello che trova un difetto". Nell'elaborazione dei dati, tutti ripetono sempre che bisogna testare bene i programmi prima di avviarli definitivamente in produzione. Sono sicuro che nessuno di noi penserebbe di mettere un programma in produzione senza prima testarlo, tuttavia cio' in realta' avviene solo parzialmente perche' i test non sono molto divertenti, anzi e' forse la parte piu' noiosa del nostro lavoro. In piu', ci danno fastidio perche' evidenziano nostre sviste ed errori che devono essere subito corretti, ritardano la consegna dei lavori e, poiche' sono nella fase finale, rappresentano spesso la quota di costo che supera il budget. Glenford Myers, autore di "The Art of Software Testing", sostiene che quando si trovano molti errori, i test non sono stati fatti male; al contrario, cio' vuol dire che sono andati bene. E' stato il processo di programmazione che e' riuscito male.
La legge di DeMarco
"La scoperta della verita' sara' una liberazione, ma prima che avvenga, vi rendera' molto infelici". In realta', molte aziende desiderano periodicamente riesaminare la loro organizzazione e il relativo sistema informativo, ma perdono l'entusiasmo quando scoprono che il modo attuale di fare le cose e' costoso, inefficiente e soggetto a errori. A nessuna azienda convinta di fare molto bene le cose fa piacere scoprire che il "bene" in realta' e' solo qualcosa di estremamente mediocre. Come ha fatto rilevare Tom DeMarco, un pioniere nel campo dell'analisi e della progettazione strutturata, le aziende in grado di accettare le cattive notizie e poi capaci di reagire investendo tempo e risorse per migliorare la qualita' e la produttivita' interna sono quelle che probabilmente resteranno sul mercato nel bello come nel cattivo tempo.
Queste e altre "leggi" similari non costituiscono certo una guida sicura al successo di un EDP manager nella gestione del sistema affidatogli.
Non sono certo constatazioni valide in assoluto e necessariamente idonee in tutte le situazioni. Si potrebbero pero' paragonare queste "leggi" alla segnaletica stradale con i limiti di velocita': essa semplicemente ricorda, a coloro che in modo sistematico la ignorano, che potrebbero trovarsi fuori strada alla prima curva pericolosa.
L'autore
John Boddie e' un consulente indipendente nell'area della organizzazione aziendale e dei sistemi informativi 3X⁄400.