¿Crees que sólo si te atan al extremo de una cuerda elástica y te tiras al vacío sube tu adrenalina? ¿Sólo el parapente sin parapente es una actividad de riesgo? Prueba a estimar un proyecto software. Armour lo expresa así en su artículo publicado en CrossTalk:
Predicting the future can be a rewarding occupation, but it can also be a dangerous one. Historically, oracles were often praised and lauded. But they were also stoned to death if they were wrong – and sometimes if they were right.
Muchos de los problemas asociados a la estimación de un proyecto software ganan una nueva dimensión si se observan desde un concepto de "software" totalmente distinto al habitual que tenemos:
Software project estimation is a difficult task for a simple reason: Software is not really a product, it is a packaging of knowledge and we cannot measure knowledge. Software is best thought of as a knowledge storage medium rather than a manufactured product. It is one of the five places we can put knowledge once we have obtained it, the other four being (in historical order): DNA (Deoxyribonucleic Acid), brains, hardware, and books. However, knowledge in software has different characteristics than knowledge stored in the other media.
Si el software no es un producto en el sentido industrial, sino un medio de almacenamiento del conocimiento, el proceso software no es un proceso de producción, sino de "adquisición de conocimiento":
If software is not a product, but is a medium, then software development is not a product-producing activity. In fact, it is best thought of as a knowledge acquisition activity. Most of the effort on a software project is related to acquiring and validating knowledge rather than creating a product. We know what we are doing.
Desde ese punto de vista, la estimación adquiere una dimensión distinta:
In an attempt to estimate projects, we are trying to figure out how much knowledge we do not have and how much time and effort it will take to get it, plus a small amount of time and effort to translate it into the executable form once we have obtained it. There are two challenges to this: First, we are trying to measure something we do not have which is always hard to do, and second – and very importantly – we are trying to measure knowledge, and knowledge is simply not a measurable thing.
Pocas perspectivas del software como esta, la idea del software como un medio de almacenamiento de conocimiento y no como un producto han cambiado tanto mi forma de ver y entender el software. En este artículo, Armour extiende dicha influencia a un aspecto más: la estimación de tiempo y recursos.
Armour expuso esta nueva perspectiva en un artículo publicado en Communications of the ACM (The Business of Software: the case for a new business model).
No hay comentarios:
Publicar un comentario