Riutilizzare con successo: ecco i requisiti

• 1 ottobre, 2002
• Stampa
• Invia a un amico
• 0

Archivio della rubrica/>

Per sviluppare software di successo è importante la metodologia: deve essere adatta sia al team di sviluppo sia agli obiettivi del progetto. Oggi lo sviluppo del software è più difficoltoso che mai. Ancora si devono bilanciare gli stessi obiettivi contrastanti: produrre applicativi affidabili, senza bachi e che soddisfino le esigenze del management e degli utenti finali, ma farlo nel modo più veloce ed economico possibile.

Dieci anni fa gli sviluppatori impiegavano circa 18 mesi per creare applicazioni client/server che sarebbero state usate solamente all’interno di un’azienda . Oggi hanno a disposizione tre mesi per costruire un’applicazione che verrà utilizzata da clienti e partner, ben sapendo che rilasciare in questo scenario un’applicazione con errori potrebbe incrinare i rapporti di affari e portare a perdite economiche. Un margine così ridotto significa che non è mai stato così importante confezionare la metodologia di sviluppo in modo da soddisfare i requisiti del progetto. Comunque, indipendentemente dalla metodologia scelta, i passi da seguire, eliminare o sostituire dipendono dalla dimensione del progetto, dai limiti di tempo, dalle priorità e dall’esperienza e dalle capacità degli sviluppatori.

Ovviamente la costruzione di applicazioni grandi e complesse, che incorporano nuove tecnologie, richiedono più enfasi nella pianificazione, nel test e nello sviluppo incrementale e iterativo rispetto a progetti semplici che necessitano di tecnologie familiari e un esiguo numero di sviluppatori, e ciò che funziona per un progetto non funziona necessariamente per un altro.

Le metodologie aumentano la qualità del software e abbassano i costi, dividendo i processi di sviluppo in parti più gestibili, guidando gli sviluppatori all’interno di ogni fase del progetto, determinando gli input e gli output di ogni attività e ottenendo anche best practice per i progetti successivi. In questo senso il solito noto e forse ‘vecchio’ concetto (o dovremmo dire sogno mai realizzato) del riutilizzo trova una rilettura decisamente interessante, almeno secondo Giga. Il riutilizzo del codice, secondo Giga, è il risultato di processi di sviluppo d’eccellenza, piuttosto che un processo in sé. Per ottenere ottimi risultati, non solo è necessario investire in tecniche e tecnologie per l’architettura, per lo sviluppo basato su componenti e per ottenere processi flessibili, mai devono essere discussi e in qualche modo affrontati i problemi culturali sottostanti.

I benefici del riutilizzo del codice sono stati discussi più volte e ampiamente. Ma quali sono i requisiti per ottenere questi fantomatici benefici? Secondo Giga, si possono ridurre a sei punti fondamentali:
- realizzare modelli di proprietà condivisa degli asset;
- risolvere i problemi a livello di cambio del management: controllo delle versioni, meccanismi di aggiornamento e mutamento strutturale dei processi di gestione;
- realizzare un ambiente apposito per la condivisione degli asset condivisi;
- assicurare modelli di incentivazione appropriati per chi produce e consuma asset riutilizzabili;
- espandere le metriche di sviluppo per misurare obiettivi specifici legati al riutilizzo;
- controllare il riutilizzo di successo pilotando i processi di riutilizzo, gli strumenti e soprattutto i nuovi ruoli organizzativi all’interno dell’intero contesto dei piani di implementazione.

Senza tali prerequisiti, i programmi di riutilizzo sono destinati a fallire, sostiene Giga. Ovvero non supereranno mai il livello del singolo progetto o del team. In generale, per l’efficace riutilizzo del codice o dei processi devono essere coinvolti i team manageriali dell’IT e del business, allo scopo di ottenere la realizzazione dei sei punti sopra elencati.

Una discussione dei componenti di norma include la discussione dei processi di riutilizzo e gli sviluppatori spesso confondono i due livelli di discussione in uno solo. Tuttavia, con la comparsa dello sviluppo sul modello dei servizi si può ricadere nel medesimo errore. Da un lato potrebbe essere una tendenza appropriata, nel senso che componenti e servizi sono di fatto asset riutilizzabili ed è di vitale importanza prenderli in considerazione quando si discute dei processi di riutilizzo. Però, sostiene Giga, limitare l’attenzione sul riutilizzo a queste tecnologie può essere fuorviante per almeno tre motivi:
- le componenti e i servizi sono allo stesso tempo sia pratiche relative allo sviluppo che promuovono migliori performance, riduzione dei costi di mantenimento e integrazione, sia parti vitali del ciclo di ritulizzo;
- ci sono molti più asset da riutilizzare che non soltanto componenti e servizi;
- considerare ‘componente’ come sinonimo di ‘riutilizzo’ incoraggia la tendenza a pensare che è appropriato stabilire un ‘programma di riutilizzo’ su dei processi di sviluppo già esistenti (e probabilmente immaturi), piuttosto che vedere il riutilizzo come parte integrante di uno sviluppo applicativo maturo e ben definito.

Il più importante è probabilmente l’ultimo punto. Molte aziende tentano di inseguire il sogno del riutilizzo come una strategia da costruire sopra processi già esistenti, pensando che con l’acquisizione di un semplice repository di componenti e alcuni cambiamenti minori ai processi già esistenti potranno realizzare l’obiettivo richiesto. Questo, Giga lo dice chiaramente, è del tutto sbagliato. Il modo migliore per ottenere un buon processo di riutilizzo è rendere questo aspetto un obiettivo esplicito e integrato del proprio processo di sviluppo generale.

0

commenti a questo articolo