Calculo de estimado con COCOMO

[[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.

[[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,

[Casimiro Notevi]

Empezado por Delphius

......

Creo que eso mismo ha querido decir AzidRain, que en software no se puede cuantificar los proyectos como en otras disciplina, en las que es más fácil medir tiempo y trabajo realizado. Lo nuestro es más creativo. Por ejemplo, anoche no podía dormir porque estaba dándole vueltas a un problema y se me ocurrió una manera abstracta de solucionarlo, me levanté a medianoche a anotarlo y esta mañana me he puesto a implementarlo. ¿Eso cómo se mide y cuánto vale?, lo mismo lo solucionas en un rato pensando mientras estás en el baño, que tardas un par de días dándole vueltas y haciendo distintas pruebas, buscando información, preguntando en foros, etc.

[[Delphius]]

Empezado por Casimiro Notevi

Creo que eso mismo ha querido decir AzidRain, que en software no se puede cuantificar los proyectos como en otras disciplina, en las que es más fácil medir tiempo y trabajo realizado. Lo nuestro es más creativo. Por ejemplo, anoche no podía dormir porque estaba dándole vueltas a un problema y se me ocurrió una manera abstracta de solucionarlo, me levanté a medianoche a anotarlo y esta mañana me he puesto a implementarlo. ¿Eso cómo se mide y cuánto vale?, lo mismo lo solucionas en un rato pensando mientras estás en el baño, que tardas un par de días dándole vueltas y haciendo distintas pruebas, buscando información, preguntando en foros, etc.

En espíritu el ejemplo de AzidRain va con buen sentido, pero al momento de presentar su caso va un reducctio ad extremum. Si vamos a ofrecer ejemplos para ilustrar la diferencia entre lo que vemos en Ingeniería Civil y en Ingeniería en Informática, al menos que sea de una forma en la que no se denigre a ninguna.
Si, se puede "calcular" cuanto va a costar a un obrero cavar un pozo, o cuanto nos cuesta la mano de obra en alisar una pared o revestirla según el material, pero reducir la Ingeniería Civil a ejemplos tan pobres (aunque no deja de ser una noble y digna actividad y que requiere su disciplina y experiencia manual) es un insulto. Y lo mismo va para el área de Informática y hasta para cualquier tarea laboral. Ofrescamos un ejemplo más real.
A manera de cierre, una vez expuesto el punto, y ya con humor si puedes dejarlo. Tal como lo hice para el caso del jefecito que intenta vender el soft más completito y promete hacer hasta actividades recreativas en la parte baja , un recurso literario que se emplea para llamar la atención pero nada más.

Saludos,

[mamcx]

Ya quedo plasmado que es imposible determinar de antemano con precision cuanto va a tardar/costar un software.

Pero de *alguna manera* se debe poder hacer una aproximación, verdad? Si no, seria imposible operar en este negocio.

A groso modo, puedes pensar que un programa va a tardar:

- 1 semana
- 3 meses
- 6 meses
- 1-3 años
- 10 años

Estos son rangos que se repiten mucho y sirven para ubicar los proyectos.

Como se hace la aproximacion?

Debes tener un listado tan detallado como sea posible de cada aspecto del programa. Esto requiere no solo la toma de "caracteristicas" tipicas, sino hacer mockups de las pantallas/procesos, hablar con el cliente/involucrados y desgranar tareas que por experiencia, no te lleven mas de 5h en completar.

Por ejemplo:

"Quiero que le programa tenga seguridad"

Eso asi no te sirve de nada. Asi que digamos que al final tienes que:

1- Crear tabla(s) de usuarios/grupos = 1h
2- Formulario Login = 2h
3- Encriptacion de datos = 5h (incluido cuanto te lleva averiguar los metodos seguros actuales)
4- Crear logica interna de ingreso = 2h
5- Test automaticos = 3h

Y asi por el estilo. Terminas teniendo una lista larga de tareas por completar. Esto es importante, porque asi puedes comunicar facil lo que *realmente* implica hacer el trabajo.

A eso, le debes agregar demoras de comunicacion. Por ejemplo:

- Cuanto demora el cliente en responderte una duda?
- Cuanto demora el cliente en retornar datos de pruebas?
- Y en testear una tarea?

Con eso le agregas otro poco.

El resultado final SERA INEXACTO, Y POR MUCHO

Pero, el punto crucial es que NO DEBES CUANTIFICAR CUANTO TE VAS A DEMORAR, SINO CUANTAS ACTIVIDADES HAY POR HACER!

Resolver un punto de una tarea, aun estimada que no pase de 3-5 horas puede igual irse a unos dias. Comunmente, porque quedas bloqueado por el cliente en responder. Este es un punto crucial.

Sin exagerar, he tenido que esperar hasta *6 meses* a un cliente para poder avanzar en una tarea que toma unas cuantas horas. Es brutal todo lo que implica "comunicar" entre areas distintas del proyecto y es una de las demoras mas significativas e inesperadas por quienes son novatos en esto.

Asi que esa es la formula: Cuantificar en pedazos pequeños las actividades, agregar buffers de comunicacion, y dejar claro que cada actividad no programada OBLIGA a parar las demas. Y que raramente se pueden hacer actividades en paralelo, asi que todo el equipo, INCLUIDO EL CLIENTE, tiene que moverse a un ritmo aceptable.