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
Parallel Studio XE 2015
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-2015. 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.