analisi-disegno.com
Ogni intervento che viene effettuato su un sistema software esistente ha una duplice valenza.
La prima valenza è relativa alla richiesta da cui è partito l'intervento (evolutiva o correttiva, a volte entrambe le cose insieme). L'intervento deve, innanzitutto, soddisfare tale richiesta.
La seconda valenza riguarda lo stato complessivo di qualità del sistema. Ogni intervento può essere effettuato in modo più o meno affrettato, più o meno professionale, risolvendo comunque la richiesta che lo ha originato, ma con ricadute diverse sulla qualità globale del sistema.
Al termine di ogni intervento, la qualità del sistema può essere rimasta invariata. O migliorata. O peggiorata.
Se l'intervento sul software ne ha peggiorato la qualità, si può dire che ha aumentato il debito tecnico del sistema.
La metafora del debito tecnico ("technical debt") è analoga al debito finanziario che contraiamo quando chiediamo un mutuo o l'apertura di una linea di credito. Nel caso del debito finanziario, non solo dobbiamo rimborsare il capitale, ma dobbiamo rimborsare anche gli interessi. Nel caso del debito tecnico, ogni intervento futuro dovrà fare i conti con il peggioramento della qualità complessiva del sistema, e risulterà quindi più costoso (interessi più elevati).
L'intervento di manutenzione può però migliorare la qualità complessiva del software, anziché peggiorarla. I refactoring (le ristrutturazioni del codice con l'obiettivo di migliorarne la qualità senza variarne le funzioni) sono utili anche e soprattutto dal punto di vista economico, perché riducono il debito tecnico e rendono più agevoli le evoluzioni successive.
Quali sono le variabili che influenzano il modo di effettuare l'intervento, e quindi le successive ricadute in termini di debito tecnico?
Sul debito tecnico, alcuni riferimenti in inglese:
*** PMBOK 4 ***
Nuova edizione del Project Management Book of Knowledge (PMBOK), la quarta, uscita il 31-12-2008.
Il Project Management Institute (PMI) ha pubblicato un contemporaneo aggiornamento anche di altri tre propri standard:
*** Sviluppo software evolutivo ***
Un articolo di Peter Denning, Chris Gunderson e Rick Hayes-Roth, tre esperti IT di lungo corso che lavorano attualmente per la US Navy, la marina statunitense, segna a mio avviso una tappa importante nel percorso verso la piena affermazione dei processi agili.
"The software engineering community has hotly debated preplanned versus agile processes. After a while they reached a truce where they agreed that preplanning is best for large systems where reliability and risk-avoidance are prime concerns, and agile is best for small to medium systems where adaptability and user friendliness are prime concerns.
We challenge that conclusion. Preplanning is ceasing to be a viable option for large systems. [...]
All the evidence says that that evolutionary processes works for systems large and small, and that risk seeking is the fastest route to fitness. There is too much at stake to continue to allow us to be locked into a process that does not work."
L'articolo, "Evolutionary System Development", è stato pubblicato nel numero di dicembre 2008 di Communications of the ACM.
*** Libro su BPMN ***
BPMN (Business Process Modeling Notation) è lo standard per la rappresentazione dei processi di business, gestito dall'Object Management Group (OMG).
Stephen White, il coordinatore del gruppo di lavoro che ha prodotto e fa evolvere BPMN, ha pubblicato un testo sullo standard: "BPMN Modeling and Reference Guide".
Il libro non aggiunge nulla a quanto contenuto nella specifica ufficiale OMG, scaricabile gratuitamente - ma è organizzato e scritto in un modo più comprensibile, e costituisce comunque un'utile introduzione all'argomento.
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.