Programmazione.it v6.4
Ciao, per farti riconoscere devi fare il login. Non ti sei ancora iscritto? Che aspetti, registrati adesso!
Info Pubblicità Collabora Autori Sottoscrizioni Preferiti Bozze Scheda personale Privacy Archivio Libri Corsi per principianti Forum
Le leggi dell'economia contro il software perfetto
Scritto da Paolo Raviola il 30-03-2010 ore 11:23
The Parallel Universe
A intervalli più o meno regolari, salta fuori la questione suggerita nel titolo, direi anzi che si tratta di una costante dell'industria del software, che però è bene ricordare di tanto in tanto. Ovviamente, ponendo la domanda in modo diretto, nessun responsabile ammetterà di rilasciare dei prodotti bacati. Ma tutti hanno bene in mente la legge del diminishing returns, la quale, in parole povere, stabilisce una sorta di punto di equilibrio, oltre il quale non è più vantaggioso accanirsi, pena un calo degli introiti o evidenti perdite.

Cerchiamo di chiarire le cose con un esempio astratto: supponiamo di avere un programma con 100 difetti, ognuno dei quali richieda un'unità di lavoro; immaginiamo che 40 di queste ultime siano necessarie per trovare i primi 70 errori, le altre 30 troveranno 20 bachi, e le rimanenti 30 scoveranno gli ultimi 10 errori.

Questo significa che la soluzione dei primi 70 bachi richiede 40/70=0,571 unità di lavoro, i successivi 30 1,5 unità lavorative, fino ad arrivare a un costo di 3 unità per i restanti 10. Questi ultimi richiedono quindi più di 5 volte le risorse impiegate per i primi 70.

Ci si può giustamente chiedere se sia redditizio ostinarsi su quegli ultimi dieci, tenendo anche conto che stiamo parlando di una situazione ideale: nella realtà, nessuno è in grado di dire che si è risolto l'ultimo baco, semplicemente perché nessuno sa quanti siano.

Un'ulteriore difficoltà è la seguente: come si fa a decidere quali sono i difetti gravi, sui quali vale la pena perseverare? Per risolvere il problema, Andy Boothe, nel suo blog, propone due regole d'oro, entrambe di carattere eminentemente economico: non mettere in imbarazzo la compagnia e non perdere clienti.

Naturalmente, è indispensabile sapere di quale software si tratta: se è un gioco, il ragionamento è valido, se si tratta di elaborazioni economico/finanziarie, perde la sua solidità, per non parlare degli applicativi (embedded o meno) in campo medico, che possono mettere a rischio la vita di una persona.
Precedente: Una nanomacchina di Babbage promette di risparmiare energia (1/2)
Successiva: Guida ai cavi e connettori: connettori 8P8C (1/2)
Intervento di lordmax del 09-04-2010 ore 19:23, Torino (TO)
Nobile
Nobile
(66 interventi)
Iscritto il 07-05-2001
Il problema è posto nel modo sbagliato IMVHO.

Il punto non è quanti bachi ci sono nel programma ma perché ci sono questi bachi.
Se il programma è stato realizzato nel modo corretto (acquisizione dei requisiti, analisi funzionale, analisi tecnica, modellazione, sviluppo, test, correzione, test, verifica... il test può essere fatto in più fasi ovviamente, questa è una semplificazione) i bachi sono presenti solo per colpa di un errore di programmazione e sono estremamente facili da individuare e risolvere.
Se si usa un approccio alla Ca... di Ca.. come sempre più accade allora i problemi sono TUTTI seri e difficilmente risolvibili.
Copyright Programmazione.it™ 1999-2014. Alcuni diritti riservati. Testata giornalistica iscritta col n. 569 presso il Tribunale di Milano in data 14/10/2002. Pagina generata in 0.185 secondi.