|
|
|
|
|||||||
|
Ercole Colonese |
|||||||||
|
L’ESPERIENZA AL VOSTRO SERVIZIO! |
|||||||||
|
Consulenza informatica ed organizzativa |
|||||||||
|
|
|||||||||
|
|
|||||||||
|
|
Sviluppare software oggi … |
||||||||
|
Stonehenge
In questa pagina:
Problemi del software Problemi gravi Cause principali dei problemi del software Alcune risposte Come fare? Un approccio metodologico organico, semplice ma efficace Il ruolo importante della direzione |
Problemi dei progetti software
Lo sviluppo del software è un'attività creativa ad alto contenuto umano e quindi soggetta ad errori. Errori ed incomprensioni nelle finalità (obiettivi, requisiti, limiti e vincoli, standard, rischi, ecc.) fanno del software un oggetto molto instabile, costoso e spesso non adeguato alle necessità dell'utilizzatore finale. La presenza di errori nel software causa malfunzionamenti che devono essere corretti. E questo ha un costo. Gli interventi sul software diventano più onerosi al crescere della sua complessità e quanto più tardi sono rilevati gli errori: più complesso è il codice e più costoso sarà modificarlo, più tardi scopriamo gli errori e più ci costerà risolverli! Ma il codice è modificato anche per potenziarne le funzionalità, adeguarlo a normative e standard, migliorarne le prestazioni. Si tratta di un'operazione non facile: innestare nuovo codice in un software non progettato per essere modificato, a volte troppo complesso e poco strutturato, è un'operazione difficile e costosa. Sviluppare nuove applicazioni è il sogno di tutti noi. Realizzare qualcosa partendo da zero. Senza dover intervenire su cose fatte da altri (fatte male, come spesso diciamo le cose fatte dagli altri!). Ma anche in questi casi, i risultati dei nuovi progetti non cambiano, i problemi rimangono gli stessi: ritardo nelle consegne, costi oltre il budget, qualità inferiore alle attese! Molti progetti falliscono o non raggiungono i risultati attesi. Perchè? Problemi gravi La disciplina dell'ingegneria del software, benché ricca di studi e ricerca, è ancora poco applicata nella pratica quotidiana. A differenza di altre branche dell'ingegneria, nel campo del software si "naviga a vista", senza l'ausilio di strumentazione adeguata. Si produce "manualmente", piuttosto che con strumenti di produttività. Si "spera" in risultati positivi, e non si adottano metodiche consolidate. Tutti gli studi condotti rilevano una scarsa conoscenza di metodi, tecniche, strumenti e metriche del software da parte degli addetti. In sintesi, ci si avvale di competenze approssimative e non di professionisti del software. Le competenze si fermano quasi sempre agli aspetti puramente tecnici (linguaggi, compilatori, sistemi specifici, programmi particolari) e poco o niente su metodi e tecniche (metodi di progettazione, tecniche di programmazione, metodi di stima, tecniche di testing, tecniche di controllo della qualità, ecc.). L'assenza o scarso utilizzo di strumenti automatici completa il quadro negativo. Molti studi condotti per capire le cause del fallimento di tantissimi progetti software hanno fornito risultati preoccupanti. Anche a livello internazionale, gli esperti del settore hanno evidenziato problemi gravi nelle aree:
Cause principali dei problemi del software Le principali cause che generano i problemi elencati sopra sono identificate dagli esperti nei seguenti elementi: 1. Poca attenzione dedicata all'analisi dei requisiti I requisiti risultano spesso incompleti, poco chiari, non controllati, indirizzati parzialmente e non secondo l'interpretazione degli utenti. 2. Bassa qualità della progettazione La progettazione dei sistemi software risulta spesso non basata su di una architettura consolidata, poco strutturata e con componenti poco coesi, con base dati poco strutturate, poco flessibile e difficile da espandere. 3. Stima poca realistica delle dimensioni dei progetti Questo dato è molto preoccupante in quanto risulta molto estesa la cultura di effettuare stime poco realistiche, mai basate su progetti analoghi, eseguiti da persone poco esperte, mai seguendo una WBS, ecc. 4. Pianificazione "ottimistica" dei progetti o condizionata dalle aspettative della direzione Anche questo aspetto è molto preoccupante; sono molti i casi di stime fatte per "accontentare" la direzione o il cliente; si tratta della sindrome dello struzzo: nascondere la testa sotto la sabbia! 5. Gestione inadeguata dei rischi Mancata individuazione e valutazione dei rischi di progetto in fase iniziale, azioni inadeguate, reazione ai problemi e poca prevenzione. 6. Risorse non adeguate alla complessità del progetto La scarsità, come numero e come competenze, di un adeguato numero di professionisti del software è, a mio avviso, l'aspetto più preoccupante. La "costruzione" di una popolazione di bravi progettisti e programmatori non si improvvisa dall'oggi al domani. Si tratta di un debito professionale di competenze che il nostro paese accumula ogni anno. Nel resto d'Europa il problema è indirizzato in maniera decisa. Noi stentiamo a trovare una soluzione. A metterla in pratica nemmeno a pensarci! 7. Assenza di revisioni tecniche dei prodotti intermedi realizzati Risulta quasi del tutto assente l'utilizzo della tecnica di ispezionare i documenti realizzati nelle fasi alte del progetto. Le poche revisioni tecniche che si fanno sono su base spontanea, viste come momenti di confusione, poco produttive, mai pianificate. Invece sbagliamo. Le ispezioni e revisioni tecniche costituiscono l'UNICA tecnica disponibile per verificare la correttezza della progettazione e delle scelte tecniche, l'unica in grado di rimuovere gli errori nelle fasi alte del progetto, l'unica in grado di ridurre la propagazione degli errori dalla progettazione al codice, l'unica a basso costo per controllare la qualità del software. 8. Inadeguatezza dei collaudi eseguiti I test sono valutati in media solo il 5-10% del costo complessivo del progetto. Spesso sono pianificati con risorse non adeguate (poco skillate, come suol dirsi). La progettazione non copre mai tutti i requisiti, specie quelli qualitativi. L'esecuzione è spesso spostata in avanti causa il ritardo nella programmazione. L'esecuzione è generalmente interrotta quando finisce il tempo o le risorse a disposizione. Credo siano commessi pressoché tutti gli errori che il buon senso suggerirebbe di evitare. 9. Scarso utilizzo di strumenti per la gestione delle modifiche, della configurazione e degli errori Pochissime organizzazioni (per non dire quasi nessuna) adotta metodi, tecniche, processi e strumenti per la gestione di queste tre componenti importanti del software: modifiche, errori, configurazione. Spesso manca la consapevolezza dell'importanza del tema e, quindi, di conseguenza, l'adozione di strumenti, anche molto semplici, come un foglio elettronico! 10. Scarso controllo della qualità Il piano della qualità è presente in quasi tutti i progetti, anche perchè richiesto dalle norme. L'esecuzione del piano, il controllo dell'esito delle attività, la valutazione dei risultati risulta invece pressoché assente nella maggior parte dei progetti, se non quando previsto dal monitoraggio esterno di terza parte. La qualità è spesso sacrificata sull'altare del compromesso tra tempi da rispettare e budget insufficiente. E' scarsa una cultura della qualità intesa come "attitudine", "modo di agire", "risultato delle attività quotidiane", "costruzione giorno per giorno"; è presente invece una cultura che vede la qualità come un di più, qualcosa da fare se si ha tempo o, comunque, che "sarebbe bello se potessi!" Un'indagine personale Pensate di rientrare nell'ipotetica lista delle organizzazioni software che disattendono uno o più punti elencati appena sopra? Ho formulato 10 domande con i punti sopra citati che sottopongo alle organizzazioni software con cui entro in contatto (in realtà sono più di dieci domande, ma raggruppate nei dieci temi dell'elenco di sopra). Sono molti anni che conduco un indagine personale e l'archivio si è popolato con un numero abbastanza alto di dati da consentire un'analisi accurata. Ogni risposta permette di attribuire un punteggio (da zero a uno) per un totale di dieci punti. Il punteggio totale realizzato permette di quantificare il livello di aderenza (o lo scostamento, se volte) dell'organizzazione da una "ideale" in cui i dieci punti siano tutti indirizzati correttamente. Nel tempo si sono aggiunte altre tre domande sulla valutazione dei risultati ottenuti dall'azienda (Quale percentuale di progetti raggiunge gli obbiettivi? Quale livello di soddisfazione esprimono i vostri clienti? Quale livello di soddisfazione è invece espresso dal personale?). A fronte di un risultato atteso che dimostri almeno la sufficienza (6), quello ottenuto dall'indagine è inferiore. Il voto medio è 5,72! Se volete partecipare all'indagine potete scaricare il modulo ed inviarlo all'autore. Alcune risposte L'ingegneria del software è nata proprio per risolvere "la crisi del software", così come fu enunciato nel convegno NATO a Garmisch, in Germania, nel 1968. Essa studia i problemi relativi allo sviluppo del software e ricerca metodi, tecniche e strumenti per affrontarli in modo sistematico. Le migliori fra queste e che dimostrano sul campo la loro efficacia sono dette "best practice". Le norme ISO9000 sono state adeguate (Vision 2000) per fornire un modello di riferimento più maturo e adeguato al contesto attuale, in continua evoluzione e competitività crescente. Il CMM®I (Capability Maturity Model®, Integration) fornisce anch’esso un modello efficace basato sul livello di maturità dei singoli processi (KPA - Key Process Area). Il PMBOK (Project Management Body Of Knowledge) fornisce la base di conoscenza per una corretta gestione dei progetti, specialmente di quelli software. Il SWEBOK(Software Engineering Body Of Knowledge) fornisce invece la base di conoscenza per i professionisti del software (gli ingegneri del software). Come fare? I modelli quindi esistono e, forse, sono anche troppi (meglio troppi che pochi!). Il problema, semmai, è quali adoperare e come applicarli in modo efficace compatibilmente con le attività quotidiane. Gli impegni di lavoro devono comunque essere onorati. Ed il cambiamento richiede tempo e denaro. Facile a dirsi, meno facile a farsi! Occorre la strategia dei piccoli passi. Piccoli ma continuativi, senza mai fermarsi. Poco ma ogni giorno, inesorabilmente. Porsi pochi obiettivi per volta, "raggiungibili" e "in linea con il business quotidiano". E poi perseguirli con rigorosità (quasi con mania!). E poi misurare i risultati, anche se non eclatanti, ed insistere nel miglioramento. Condividere i risultati con tutta l'organizzazione (perchè i risultati sono sempre il frutto dell'intera organizzazione). Quindi porsi un altro obiettivo raggiungibile ed insistere nel perseguirlo. "Anche un lungo viaggio inizia sempre con un primo passo" (ha detto qualcuno molto saggiamente ed io lo riporto qui). Tutto ciò vuol dire che non esistono rimedi miracolosi, ma solo "tanto olio di gomito" (altra frase presa in prestito). Un approccio metodologico organico, semplice ma efficace Un approccio metodologico organico, semplice ma efficace, tesato con successo sul campo costituisce un aiuto. Una soluzione di questo tipo è, per esempio, quella di affrontare un percorso di miglioramento dell'organizzazione che includa con pari efficacia tutti e tre gli aspetti più volte menzionati: le competenze delle persone, sia tecniche che manageriali, i processi produttivi e gestionali; l'utilizzo di metodi, tecniche, metriche e strumenti a supporto delle attività. Una metodologia di questo tipo è stata sperimentata con successo in progetti che hanno visto coinvolto un grande numero di piccole e medie imprese di software italiane. Già definita nelle sue linee principali, essa poggia su tre pilastri irrinunciabili:
Il tutto calibrato in modo da costituire un "unicum" equilibrato di tecniche e competenze, metodi e strumenti, atteggiamento positivo e metriche per misurare i risultati conseguiti. Il ruolo importante della direzione Per il successo di una tale iniziativa occorre il coinvolgimento attivo della direzione aziendale. Essa gioca un ruolo importante nel cambiamento: leader della trasformazione, motore e ispiratore del miglioramento. Non si è mai vista un'organizzazione migliorare le proprie prestazioni senza che la direzione ne veda la necessità, ne capisca l'importanza, si ponga alla testa del cambiamento, ne faciliti le azioni e ne valuti i progressi. |
Sviluppare software oggi ... Un'attività creativa complessa Problemi dei progetti software Soluzioni ai problemi del software Metodologia di sviluppo software
Collegamenti esterni utili: Aicq-ci, Associazione Italiana Cultura Qualità, Sottocomitato Qualità del Software Cnipa, Centro Nazionale per l'Informatica nella Pubblica Ammnistrazione EFQM, European Foundation for Quality Management SEI, Software Engineering Institute PMI, Project Management Institute EUCIP - European Cesrtification of Informatics Professionals (versione italiana a cura dell'AICA).
|
|||||||
|
|
Copyright © 2005-2007 - Ultimo aggiornamento: 31 luglio 2007 |
||||||||
