Calculo de estimado con COCOMO

[lgarcia]

Gracias Delphius por tu respuesta, pero en mi caso especifico se trata de sistemas que estan en explotacion y lo que necesito para poder recibir una remuneración es presentar un método o una formula que pueda presentar a la comision que lo evalue y que el costo no salga del aire, o sea referenciarlo contra algo. Por eso esa formula de Cocomo me podria venir bien, pero como explique en el caso de las lineas de codigo son todas las que estan en la Unit o solo las que uno va generando a traves de los eventos u otras definiciones en el programa y tambien queria esclarecerme acerca del codigo que uno va creando en los procedimientos almacenados de la BD formaban parte de eso.

Saludos
Luis Garcia

[[Delphius]]

Empezado por lgarcia

Gracias Delphius por tu respuesta, pero en mi caso especifico se trata de sistemas que estan en explotacion y lo que necesito para poder recibir una remuneración es presentar un método o una formula que pueda presentar a la comision que lo evalue y que el costo no salga del aire, o sea referenciarlo contra algo. Por eso esa formula de Cocomo me podria venir bien, pero como explique en el caso de las lineas de codigo son todas las que estan en la Unit o solo las que uno va generando a traves de los eventos u otras definiciones en el programa y tambien queria esclarecerme acerca del codigo que uno va creando en los procedimientos almacenados de la BD formaban parte de eso.

Saludos
Luis Garcia

Con más razón, ¡COCOMO no! Va de nuevo: COCOMO es para estimar proyectos a futuro en base a proyectos históricos. Si la idea es ofrecer una base sólida para argumentar el valor de tu proyecto piensa de otra forma. ¿Que vale más para ti? ¿El código? ¿tus años de experiencia? ¿O el tiempo que le invertiste en el análisis, en el diseño, la implementación y las pruebas?
COCOMO es para algo interno, le sirve al equipo de desarrollo. No tiene sentido buscarle la tuerca y tratar de ofrecerle una formulita mágica al cliente como para justificar lo que ya está hecho. Si te demoraste 6 meses, pues eso: 6 meses. No lo que te tire COCOMO. Valórate. No por aplicar un modelo "estándar" como COCOMO te hace ser más profesional.
COCOMO además no es exacto, es sólo una estimación y que hay que estar corrigiendo los coeficientes a números locales y ajustados para el negocio o empresa particular. Y para eso debe analizarse varios proyectos. Ajustarlo para que calce a este proyecto en particular es mentirse.
Tomá si queres todas las líneas, descartando comentarios, o si quieres la sección implementation... ¡de todas formas tendrás que toquetear!

Vamos por parte: convengamos que esa es la forma errada de encararlo. ¿Y si te lo rechazan? ¿Que haces con tu tiempo y esfuerzo gastado al vicio? Justamente lo que se debe hacer es definir de entrada una estimación inicial con cierto márgen de error (hacia arriba y nunca para abajo) y poner en papel y con gancho. Tener la cosa segura. Se le ofrece unos tiempos prudenciables, y unos costos esperables y si hay visto bueno recién se arranca fuerte. Naturalmente para dar dicha estimación debe haber un pre análisis y estudio del caso. Para llegar a esos números bien se podría utilizar aquellos datos históricos que gracias a COCOMO podrían ayudar... (la cosa es que tu pretendes ver lo actual con COCOMO cuando este mira el pasado para adivinar el futuro) pero lo primero y fundamental a poner en la mesa es la propia experiencia, lo que tienes por aportar, y aplicar un buen plan de viabilidad técnica-operativa, económica y legal.


Otra cosa, ¿y si resulta que la formulita de COCOMO te tira para abajo lo que esperas? ¿Que haces? Digamos que en tu cabeza ronda un numerito de 50.000 dólares y la formulita de COCOMO de libro te sale un 35.000. ¿Sos el carero? ¿O es que COCOMO infravalora? ¿Y si el esfuerzo persona-mes no es lo que en verdad te ha llevado? Y esto te lo digo porque si hay algo en lo que COCOMO falla es en proyectos medianos a chicos... se lo conoce por no ser preciso en los proyectos chicos y esto se debe a que el Modelo se basó en un estudio de mega proyectos millonarios ¡y de hace años! En el año 1997 salió COCOMO II, que al menos en lugar de usar KLDC también puede emplearse la medida Puntos de Función y algo le "calibraron" pero sigue teniendo los mismos inconvenientes de sus orígenes.

Las medidas, métricas e indicadores en Ingeniería de Software son un concepto que extrapolamos y copiamos de Ingeniería Civil... en un mundo de exactas. En Informática las cosas son más abstractas, relativas... y no hay recetas mágicas. En Civil hay formulitas que dicen esto es así y si le erras se te cae la estructura. Acá las formulitas no son nada mágicas, y no hay nada certero... tenemos blanco, negro y grises. Pesa mucho más nuestra propia experiencia e intuición que lo que te pueda decir una formulita propuesta en la universidad Yanqui y que ha estudiado en mega proyectos locales.

Con todo respeto: busca otra carta que jugar. Si la idea es ofrecer una jugada que los atraiga y le den visto bueno aporta otro enfoque.

Saludos,

[[Delphius]]

Para profundizar quisiera dejarte algunas palabras que expresé hace ya un buen tiempo:
Hilo 1
Hilo 2

Y de estos hilos, me quedo con éste post. Esto no lo digo porque sea bonito, sino porque me ha pasado a mi.

No es que tire mala onda, es que intentar que las cosas salgan bien por arte de magia en base a los libros y sacar formulitas de la galera para autojustificarnos no necesariamente sirve. Si han fracasado grandes proyectos informáticos aún aplicando las buenas prácticas de la Ingeniería de Software ¡mirá si un simple tipo detrás de una PC en un cuartito de 4x5 no va caer en la misma suerte!

A lo que apunto es que no hay garantías de nada. Las métricas y estimaciones son necesarias (traer orden a la casa es muy importante y nos dará un buen plan de trabajo que a la larga nos ayuda a ser mejores)... pero también son un arma de doble filo en mentes optimistas y también en las pesimistas. Un día las amas, al día siguiente te bajan del trono. ¡Yo vivo con ese amor odio!
No hay que cuidarse, y esto se aprende a por las duras... y te lo dice alguien que se viene curando desde hace años con esto de estimaciones

Por cierto, ahora recuerdo otra de Pressman... ¡Que fácil es estimar cuando uno ya tiene el proyecto hecho! La dejo de yapa para que la analicen

Saludos estimados diría Al.

[lgarcia]

Muchas gracias Delphius por tus sabias recomendaciones, voy a leerme esos link y vere como encuentro la mejor forma de enfrentar el problema.

Saludos
Luis Garcia

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