Tuesday, September 27, 2005 

Real Options and Software Design

In a comment to an earlier posting, I suggested The Structure and Value of Modularity in Software Design as an introductory paper to Real Options applied to Software Design.
Davide Cesarini asked if it makes sense to apply the technique to evaluate alternative designs for an existing, non-modular system. He also suggested that the Design Structure Matrix could be a useful documentation tool when a new application is being designed.
Overall, I see the biggest value of the article in the approach, method and language used to deal with software design. There is no advocacy about the (usually unjustified) superiority of some language, technique, paradigm. Instead, the authors' goal is to discover the real economic value of each proposal. This, as Davide noticed, does not come for free. In fact, the approach described in the paper is better suited to the comparison of alternative designs for a new application: most likely, the authors opted for an existing "reference problem" to avoid a lengthy explanation of a new problem, to build upon existing knowledge, and possibly to avoid bias in the selection of the problem.
What I see as immediately useful when documenting design decisions (a cornerstone of good design documentation) is the portion of the matrix relating environment parameters and design rules. This is useful even if we don't go on and apply the Net Option Value part.
Even more important, for the designers, is to get the message: delaying decisions can add value; the best modular design adds more value. Even in the absence of formal value calculations, we definitely need to start thinking in this way about software design.

Labels: , ,

Comments:
Personalissimi pensieri sparpagliati sullo sviluppo del software

Mi occupo di analisi e sviluppo del software da più di vent'anni :-(( ed avendo appreso queste discipline autodidatticamente per pura passione senza una formazione specifica in un ateneo trovo talvolta difficoltà coi formalismi, i teoremi e gli assiomi. Spesso mi faccio sovverchiare dalla ragion pratica a discapito di un maggior rigore metodologico.

In genere progettazione e programmazione han sempre fatto parte inscindibile del mio lavoro. Uno dei pregi che mi sono spesso attribuito (modestamente :-) è stato quello di riuscire a prevedere i tempi di sviluppo con un buon grado di approssimazione. In verità l'esperienza mi ha portato a constatare che per lavori di poche ore / giornate spesso avanzavo del tempo mentre invece per progetti appena più ampi (oltre la decade) tendevo a starci stretto.

In genere non ho quasi mai avuto occasione di realizzare software progettato da altri fino a poco tempo fa. Il guaio è stato quello di aver espresso una stima sulle idee degli altri ed il risultato è stato che per un'ipotesi di lavoro di circa 5 mesi in realtà ce ne sono voluti quasi 7.

Tutto sommato era abbastanza ovvio e sicuramente il corso di Carlo sulle Tecniche di Stima per Progetti Software dovrebbe essere illuminante in tal senso.
Ma poi mi consolo perché anche Microsoft puntualmente sfora i tempi di consegna...

Pensare e realizzare con una testa sola ha un'innegabile vantaggio. Purtroppo o ti chiami Carlo ;-) oppure le cose che riesci a fare sono molto limitate rispetto al lavoro in team.

Lungi da me il voler stendere una summa sull'argomento termino qui riservandomi di completare il mio pensiero in futuro, se la vita ce ne darà l'occasione.
 
Post a Comment

<< Home