Calculo de estimado con COCOMO

[lgarcia]

Hola:
Estoy tratando de realizar un estimado de costo de un software y encontre esta formula Effort = 2.94 * EAF * (KSLOC)E, donde KSLOC son los miles de lineas de codigo, mi duda es que si las lineas de codigo son las que unos genera directamente en las Unit o si incluye todo lo que se va generando cuando uno va insertando componentes y si el sistema trabaja con bases de datos si tambien hay que incluir todas las lineas de codigos de los procedimientos almacenados que unos crea para la administracion de esa base de datos. Trabajo con Delphi 7 y MSSQL Server 2008.

Saludos
Luis Garcia

[[Delphius]]

Empezado por lgarcia

Hola:
Estoy tratando de realizar un estimado de costo de un software y encontre esta formula Effort = 2.94 * EAF * (KSLOC)E, donde KSLOC son los miles de lineas de codigo, mi duda es que si las lineas de codigo son las que unos genera directamente en las Unit o si incluye todo lo que se va generando cuando uno va insertando componentes y si el sistema trabaja con bases de datos si tambien hay que incluir todas las lineas de codigos de los procedimientos almacenados que unos crea para la administracion de esa base de datos. Trabajo con Delphi 7 y MSSQL Server 2008.

Saludos
Luis Garcia

¿Concretamente que pretendes realizar?
COCOMO se emplea para estimar esfuerzo (expresado en persona-mes), Tiempo (meses) y Personas requeridas para proyectos futuros. No se emplea en trabajos actuales y en marcha.
Necesariamente debe contarse con varios proyectos con los cuales realizar los cálculos (al menos unos 10 para empezar), compararlos, y luego se procede a ajustar los valores de las constantes para que de esta manera se apliquen y reflejen lo mejor posible tu negocio.

Además COCOMO no goza de suficientes ventajas, es bastante subjetivo y relativo y depende mucho de la visión que cada persona del equipo tenga. Al estar basado en las KLDC (así es la sigla y no la que tu pusiste) y al ser ésta una métrica bastante arcaica los resultados no necesariamente reflejan la realidad (o mejor dicho la realidad que uno pretendía medir). Medir el tamaño del software por las KLDC no necesariamente es lo mejor... eso era útil en los años 80 y principios del 90. Hoy el Software es mucho más que líneas de código y en un modelo OO como el tiene Delphi (y/o cualquier otro LOO) la métrica pierde sentido. Pero claro, al ser una métrica tan fácil, directa y rápida, de obtener la gente le sigue dando cierta utilidad. ¿Porqué? Porque las KLDC son una medida interna, de lo que sucede por dentro. En un mundo en donde el paradigma OO gobierna, lo que se ve hacia afuera son clases y no las KLDC. Justamente una forma útil en donde puede ser de ayuda las LDC (ya no hablamos de kilos), de forma indirecta, es para calcular el método ponderado por clase (MPC) para normalizar la complejidad de cada método respecto a la LDC de cada uno:
MPC = C1/LDC1 + ... + Cn/LDCn

COCOMO ha sido ampliamente estudiado y desarrollado en base a un amplio abanico de casos de estudio, se supo ganar su reputación en su momento pero bien hace la comunidad de Ingeniería de Software al señalar los riesgos de enamorarse en sus resultados (y lo mismo aplica a cualquier otra métrica, medida e indicador que se proponga)
Pero las cosas han cambiado y se han propuesto otros enfoques.... como FURPS por ejemplo que propone métricas orientadas a la "calidad" y no quedarse únicamente en una mirada en controlar el esfuerzo y la cantidad de personas. Además según el paradigma que se proponga se han ido proponiendo métricas pensadas para cada uno.
Así como carece sentido de medir el tamaño de un soft bajo OO por las KLDC, es que hay todo un mundo de medidas, métricas, e indicadores OO para todo.

La lección a todo esto es que importa más que tengas tu propio método de estimación y control de tus proyectos. Tu mismo eres libre de proponer tus propios modelos empíricos, matemáticos, cualitativos, y/o cuantitativos que mejor te sirvan. Pero volviendo a lo central, y mi pregunta inicial: ¿Que pretendes hacer?

Seriamente te invito a leer como mínimo el libro de Ingeniería de Software, un enfoque práctico de Roger S. Pressman.

Saludos,

[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