Hola andresenlared,
Disculpa mi atrevimiento, pero me parece que te hace falta una buena lectura de algún libro de Ingeniería de Software. Por mi parte recomiendo la lectura de Ingeniería de Software. Un enfoque práctico de Robert Pressman.
En primer lugar déjame decirte que COCOMO no ofrece ninguna medida de la funcionalidad, COCOMO solamente se limita a ofrecer una ESTIMACIÓN sobre el posible tiempo y el esfuerzo (expresado, y medido, en pers-mes) según el tamaño del proyecto, siendo la medida base las KLDC.
Ahora bien, el modelo trabaja, en realidad, sobre datos históricos. Sus estimaciones tienen mayor sentido si son para efectuar mediciones de control y de comparación. Con estos datos, luego, en teoría, el profesional podría estimar el tiempo y esfuerzo de un proyecto que tuviera similares características.
Para ello hace falta una buena cantidad de proyectos ya hechos y calcular los valores estimados con los reales a fin de determinar si el modelo se acerca a la realidad. Esto también favorece, y se aconseja realizarlo, ya que nos permite calibrar los coeficientes a, b, c y d a
datos locales y no conformarnos a lo general.
En segundo lugar, NO existe relación alguna entre las LDC y los Casos de Uso. Tampoco existen, según tengo entendido, medidas, métricas e indicadores que tengan como medida base los Casos de Uso, o peor aún, los Diagramas de Caso de Uso.
Los Casos de Uso no son más que una de las técnicas y herramientas de recolección de requisitos, y por definición... las LDC no podría, ni deberían, existir antes de un Caso de Uso.
En tercer lugar, define ETC. Porque que yo sepa uno no necesariamente está limitado, ni obligado, a tomar las medidas, métricas e indicadores de fábrica que ha propuesto (y sigue proponiendo) la disciplina de Ingeniería de Software. Tranquilamente uno está en su libertad de definir su propio juego de medidas, métricas e indicadores. Ese etc es muy amplio... y no tiene sentido esforzarse demasiado en recopilar centenares de medidas, métricas e indicadores si después no los entiendes ni/o le puedes sacar alguna utilidad.
Lo primero a pensar es si realmente se va a tomar conciencia y valoración a esto de las métricas. De nada sirve recopilar esa información si dentro del equipo será un adorno, o una molestia.
Si se toma conciencia de su utilidad, y no resulta una carga ahora queda DELIMITAR cuáles de ese conjunto se tomará. Toma el conjunto que consideres que más te puede servir como para tomar decisiones y dirigir el proyecto, no asumas más de lo que no puedes. Es preferible tomar un pequeño conjunto manejable que cientos sin tener un buen proceso de toma ni organización.
Como te han sugerido, no hay (al menos, yo no veo alguna) manera de relacionar LDC con funcionalidad. El sentido común nos invita a pensar en ello... y ya de plano concluiríamos de que no hay correlación ¿Acaso debe existir relación entre ellos? Pensemos... entonces, un programa de 5KLDC debe funcionar peor, mejor, o igual que otro que tenga 25KLDC?
El punto aquí pasaría por preguntarnos que deberíamos entender por FUNCIONALIDAD.
Tu pensamiento me hizo recordar de Halstead y su teoría.
Halstead propone que existe un volumen y una longitud mínima, en el que puede expresarse un algoritmo. Toma como base unas medidas muy primitivas: la cantidad de operadores y operandos, y las frecuencias de aparición.
Expresa, por decir de algún modo, una medida de complejidad y del tamaño del problema y hasta del lenguaje de programación.
La conclusión que llega Halstead es que se requiere de mayor esfuerzo expresar un programa en un lenguaje que requiera de mayor LDC. Algunas de sus comparaciones se basaron entre FORTRAN y ensamblador. Pongo datos de un ejemplo extraído del libro que he citado: para un algoritmo SORT en FORTRAN se ha calculado un volumen V = 204, para emsamblador un V = 328. Así diríamos que FORTRAN es 204/328 = 0,6219 -> 1 - 0,6219 = 0,3781 => 37,81% mejor que ensamblador.
En teoría, se decía que debe existir un volumen mínimo para un algoritmo. Y así es... los algoritmos de ordenamiento por ejemplo, en promedio a nivel general tienen una complejidad similar o del orden del O(n^2), y esto es independiente del lenguaje. Halstead definió una relación de volumen L como la razón entre la forma más compacta posible y la real obtenida.
La conclusión de él fue que aquellos lenguajes que poseían una media mayor son mejores que otros.
Intentó demostrar su hipótesis de que el nivel de lenguaje sería constante.
Esta teoría luego quedó en el olvido, y estancada debido a que se demostró que no sólo era inútil encontrar alguna relación entre un lenguaje y otro por las LDC que consume, sino que además hay un factor externo que influye y no había considerado: las habilidades y el conocimiento del programador y no se puede resumir únicamente al nivel del lenguaje de turno.
Si ha quedado, demostrado y se le da crédito en que los lenguajes más abstractos y de nivel más alto son más eficientes que el de bajo nivel.
Volviendo a nuestro caso, ¿crees que las LDC puedan ser capaces de poder decirte que está mal o no va a funcionar?
Hay un problema con las LDC, hoy en día (bueno en realidad viene desde hace mucho tiempo... casi desde que se propuso ésta métrica) esta medida no goza de una buena aceptación. Debido principalmente a que está desfazada de la realidad. Hoy el paradigma reinante es OO y en éste es algo inútil intentar medir las cosas por las LDC cuando expresamos el código en función de las clases.
Otro hecho que hace que no goce de total aceptación se debe a que no necesariamente las LDC son una medida exacta, son bastantes abstractas y relativas ya que dependientes no sólo del lenguaje sino del programador. Es decir... sus resultados no son demasiados "real-life".
Pero hay que reconocer, que también hay puntos a favor de su utilidad:
1. Es muy fácil de calcularlas y extraerlas (¡basta contar!), y
2. No hubo ni hay demasiadas propuestas más serias, y sencillas que permitan obtener valores más precisos.
Aún hoy, es posible darles cierta utilidad, por ejemplo tomando las V(G) y las LDC de un método se podría calcular su complejidad normalizada C. Con los valores C de todos los métodos de una clase se podría ahora obtener el valor de MPC o Métodos Ponderados por Clase. Para más info léase el capítulo dedicado a las métricas OO del libro citado.
Aunque se aconseja (o al menos se debería llamar la atención) a la comunidad a que se tomen las cosas con pinzas y que no se queden en que por ser números se está en una ciencia exacta. ¡RECUERDA QUE TODO ESTO ES SOLO ESTIMACIÓN! Esto quizá es lo que lleva a una buena parte de la comunidad informática a sostener y pensar que la disciplina de Ingeniería de Software es una pseudo-ciencia que no vale la pena seguir manteniendo.
El ejemplo más cercano y famoso que tengo a mano es un
comentario emitido por un (supuesto) erudito en materia de Software Libre, ex coterráneo, Ricardo Galli.
Yo por mi parte, defiendo la disciplina. Quizá no sea la mejor, pero como dice Grady Booch:
"Las personas son más importantes que cualquier proceso.
Buenas personas con un buen proceso siempre actuarán mejor que buenas personas sin procesos".
Nunca se ha pretendido que la Ingeniería de Software sea exacta, pero al menos ofrece un arsenal de herramientas que están para tener una mejor orientación. Está en uno en evaluar que, como, cuando y cuánto tomar de ellas.
Creo que con todo esto ya te puedes hacer una idea.
Ahora bien déjame darte un último chascarillo: el título de tu mensaje va en otro sentido de lo que describes. Al leer el título se me vienen cosas como CamelCase, Notación Húngara, PascalCase, y el estándar propuesto por Borland/CodeGear (ahora, Embarcadero) para escribir código: Object Pascal Style Guide. (te pondría el enlace pero no encuentro el oficial
).
Aún así, y si estás interesado en llegar a producir alguna métrica que busque relacionar o predecir la cantidad de líneas de código con la cantidad de unidades, quizá algo como la relación entre KLDC y el Acoplamiento con otras unidades de las que depende más la que dependen de ésta pueda darte alguna aproximación.
Por ejemplo, digamos que tienes un KLDC de 3,457 en una unidad. Supongamos también que dicha unidad está relacionada o vinculada y depende de 1 módulo, y existe otras 3 unidades que están acopladas a ésta y por tanto dependen de ella. Tenemos en total un valor de 4.
Entonces diríamos que: 3,457/4 = 0,864. Se podría argumentar de que cuanto este valor sea menor a 1, es deseable mientras que si es mayor podríamos suponer que el módulo o unidad analizada está muy densa y quizá sea más conveniente partirla.
Creo yo que con todo esto te puedes hacer una mejor idea.
Disculpen semejante rollo.
Saludos,