[[Delphius]]

Empezado por AzidRain

COCOMO es super anticuado...tanto que lo utilice en un proyecto de universidad hace casi 25 años precisamente para estimar el costo de un proyecto de software sobre el cual no se había escrito ni una sola línea. No me convenció mucho en ese entonces porque su estructura se basa en cuestiones que sabemos no son determinantes en un proyecto como por ejemplo la cantidad de líneas de código que un programador promedio genera para resolver un x problema. En los años 80s lejos de programación web y lenguajes visuales y cerca de lenguajes como fortraan, cobol y otros similares, sí tenía sentido. Ahora cualquier entorno de desarrollo te genera cualquier cantidad de líneas adicionales a las que realmente el desarrollador introduzca. Coo dice Delphius en Ingeniería civil y arquitectura hay modelos que permiten definir un costo aproximado pues no son técnicas que tengan que abstraer nada, sin embargo, como toda ingeniería deben encontrar soluciones para resolver problemas, los cuales son problemas físicos y tangibles: v.g.: Hacer un hoyo y sacar el escombro que genere cuesta $XXXX, Allanar una pared con yeso de primera calidad cuesta $XXX x m2...etc. En el software esto no funciona así... Imáginate: Hacer que cada vez que un usuario se equivoque y escriba mal un emal de cliente, llegue un aviso al supervisor y a su jefe, quede un registro de que se envio el correo...Cuanto cuesta eso??? Es imposible de medir y siempre variará en función de la experiencia y habilidad de quien desarrolle la solución.

Como que los ejemplos que propones están un pelín exagerados
En Ing. Civil se manejan mucho con tablas con valores ya previamente calculados. Pero para otras cosas hay todo un abaraje de ecuaciones y fórmulas que con unos cuantas variables ya te calculan la cantidad de vigas, de que tamaño, grosor de los hierros, etc. Es ciencia exacta. Es a estos ejemplos a los que apunto.
Y como que es medio absurdo buscar el precio por una "funcionalidad" extraña y traída de los pelos. Suena más real intentar predecir el costo de mantenimiento de un módulo que data de 3 años, y que ha sufrido ya 5 cambios mayores y posee 10 clases fuertemente acopladas ¿no crees?

El ejemplo que pones sobre el costo de mano de obra también medio que está tabulado... y eso lo manejan majormente más los arquitectos. Por lo general acá los Ingenieros Civiles tienen un perfil más del tipo calculista/proyeccionista y se dedican a los aspectos estructurales y la gestión de plazos y del personal y del diseño y distribución/funcionalidad de/en obra se suele delegar en arquitectos. Por lo general estas tablas de costos se define y forma parte (al menos en Argentina) de lo que se conoce como Índice de construcción. Cada provincia tiene una organización que regula esto, y las inmobiliarias, agentes de fideicomisos, constructoras, etc. toman como base para proyectar sus costos. Estos índices se actualizan mes a mes según como varía el precio de las materias primas y de la mano de obra, etc.
No estoy seguro si los arquitectos se manejaran con algo de métricas, creería que si porque recuerdo de un amigo que comentaba sobre cátedras de gestión o administración y andaban con algunos profes de Ing. Civil.
Otro concepto que recuerdo que les robamos a los Ing Civiles son los patrones. Nosotros los llamamos patrones de diseño; ellos lo llaman Lenguaje de Patrones. En escencia es lo mismo: una descripción de problema/solución para una situación particular. ¡Que manga de copiones que somos!

El problema de estimar un proyecto en Informática es que es muy abstracto y demasiado "artístico" (o como se suele decir, del estado del arte). Es un mundo creativo, que requiere otras percepciones y visiones más complejas... las interacciones son diferentes. Los equipos y distribución de trabajos son diferentes a los que encontramos en obras de construcción, etc. Amoldar las prácticas de ingeniería de otras disciplinas no es tan fácil. Por dar un ejemplo, podes estimar cuanto te demora un albañil en levantarte una pared de 4x5 con ladrillos comunes (de 15x10x3) e incluso hasta realizar métricas como m2/horas. Es una labor muy mecánica. Ponele que Juan te levanta 30m2 en 2hs, y Santiago apenas hace el mismo trabajo en 2,5h. Si el Inge necesita mandarse 10000m2 sabe como organizarse.
Es bastante habitual ver en consultores y jefes deseosos de controlar la productividad de sus desarrolladores que proponen la métrica KLDC/horas... ponele que Pedrito apenas te manda 0,128 KLDC/h (o bien 2,13 LDC/min) y se pasó 6 hrs sin teclear. Para el jefecito le parece una pérdida de tiempo, lo que no ve es que ese Pedrito es un capo que INVIRTIO esas 6h en llegar a una solución tran creativa, óptima, y eficiente que le basta con esas 128 simples LDC para el módulo que tenía a su cargo.
Acá el Jefe no tiene una idea tan aproximada de cuanto realmente va a ser necesario para llegar a la solución final (ni sabe a ciencia cierta) si en realidad es la mejor solución. ¡Sabes como desearían poder saber que el producto fuera como levantar 100 paredes!

Por esto es que a nuestros clientes no lo podemos estar dandole demasiado formulerío que esto será así, que ponemos a 4 tipos a desvelarse y alimentados por sonda con pizza triturada y 10000 litros de café y en 3 meses tendrá el soft que por poco no maneja un brazo biónico para que le haga una manuela. Necesitamos ofrecer otras maneras creativas de como justificar y poder demostrarle nuestro valor del trabajo. Los números son fríos, aburridos, académicos y nuestros clientes son humanos que viven en la tierra. Las métricas sirven para controlar nuestro trabajo de manera interna... Como dice una amiga mía... ¡tenemos que salir de nerdlandia más a menudo!

Saludos,