Estandares en lineas de codigo??

[andresenlared]

Saludos.

entiendo que las lineas de codigo es un insumo para un proyecto donde se quiera determinas costos como lo hace COCOMO, o para determinar metricas de funcionalidad teniendo las funciones de los casos de uso etc.

La pregunta es si existen estandares que determinen si dependiendo del numero de lienas de codigo se puede determinar si una aplicacion es funcional o no??

[[oscarac]]

creo yo (y es un comentario muy particular) que la funcionalidad no esta relacionada la cantidad de codigo, si no mas bien, va en relacion proporcional al diseño de la aplicacion

con los nuevos lenguajes de programacion orientados a objetos, se pueden realizar muchos procesos con muy pocas lineas de codigo, no por eso se puede decir que si tiene poco codigo no es funcional

Yo provengo de Lenguajes como Foxpro donde tenia que desarrollar mucho codigo para hacer un Catalogo o Mantenimiento ahora un grid y algo de codigo lo resuelve

[[escafandra]]

Evidentemente las líneas de código escritas sólo son la cara visible del mismo. Detrás tenemos el lenguaje que esconde muchas mas, a parte de la optimización que sea capaz de realizar. Si usamos librerías de clases, ¿Cuantas líneas encierran en una simple línea escrita por nosotros?

En definitiva, las líneas de código y su cantidad hablan de nuestra forma de codificar, pero no del compilador, librerías binarias o librerías de clases usadas. Todo el conjunto sumará o restará eficiencia a la aplicación final.

Saludos.

[ecfisa]

Hola andresenlared.

La pregunta es si existen estandares que determinen si dependiendo del numero de lienas de codigo se puede determinar si una aplicacion es funcional o no??

Así planteado creo que no.

Si una aplicación resuelve una determinada taréa es funcional, no importa si tiene 5 ó 50.000 líneas de código. En ese sentido ambas son eficaces.
Aunque puede suceder que una aplicación muy extensa pierda funcionalidad al sobrepasar la capacidad de determinado equipo.

Considero que tampoco es medible la eficiencia de un código en función al número de lineas.

Pero es sólo mi opinion...

Saludos.

[[Delphius]]

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,

[ecfisa]

Empezado por Delphius

Disculpen semejante rollo.

Pero... ¡ Todo lo contrario! Fue una muy buena explicación.

Saludos.

[andresenlared]

Gracias a todos por sus aportes.

Aunque el hilo le hacia falta cuerpo creo que se entendio y de verdad muchas gracias por sus aportes.

Cuando me formularon esa pregunta pense de forma muy general en lo que se ha comentado en este hilo, pero si queria tener la certeza de que mis pensamientos no estan del todo errados.

Respecto a mi comentario sobre COCOMO, lo coloque para indicar que las lineas de codigo no se usan para obtener algun indicador de funcionalidad(al menos en este caso), se usan como insumo para hacer estimaciones de esfuerzo, costos entre otros, tal como lo dice Delphius.

Sobre usar las lineas de codigo en metricas lo coloque porque encontre algo relacionado en este enlace.

De nuevo muchas gracias.

[[Delphius]]

Empezado por andresenlared

Sobre usar las lineas de codigo en metricas lo coloque porque encontre algo relacionado en este enlace.

Pues si lees el libro que cité te encontrarás un montón de métricas e indicadores basados en LDC.

A lo que voy con todo el rollo es que no debemos quedarnos como si fueran exactas (y no por ello, hay que abandonar cualquier intento de traer orden a la casa). Tiene sus pros y contras... y no sólo es la medida LDC sino que aplica a TODAS.
A veces los números nos ayudan a comprender las cosas, pero no por ello van a ser una fiel y exacta representación.

Muchos piensan que por el sólo hecho de medir, se harán las cosas con calidad. Con y/o sin medidas, métricas e indicadores se pueden hacer las cosas bien como mal. Y esa es una advertencia que te hago.

Sólo recalqué la dualidad y lo abstracto y relativo que puede ser tomar decisiones UNICAMENTE por lo que digan las líneas de código. Como he dicho, aún se le puede sacar utilidad; pero mientras sepamos centrarnos (y centrarlas) el contexto en que se las aplica. Por ejemplo, a un nivel interno/micro puede ser de mucha ayuda, para un análisis global/macro va perdiendo significado y utilidad y es por ello que se las suele combinar con otras para obtener indicadores más "calibrados". En el ejemplo del MPC que mencioné, es un caso. En el contexto OO, medir una clase por las LDC como que está desentonando, pero se puede aprovechar tanto la V(G) como la LDC para obtener mediciones relativas y normalizadas de complejidad de cada método. Luego, se asume que la clase posee una complejidad proporcional, a la cantidad de métodos.

La conclusión a la que llega MPC es que cuantos más métodos y más complejos sean el valor será más alto, indicando que la clase es más compleja.

Cuanto más abstractos y general nos vamos haciendo la exactitud que pudiera ofrecernos cualquier métrica va disminuyendo. (en el ejemplo de PMC se ha pasado de un estrema estructurado, a uno orientado a objetos) Es como si tuviéramos un microscopio, a su máxima capacidad le podemos apreciar muchos detalles, en cuanto vamos quitando zoom menos vamos distinguiendo y todo nos resulta una cosa borrosa o lo mismo. Con las métricas sucede lo mismo, en cuanto se las saca de contexto, va perdiendo sentido, y necesario ajustarlas a la nueva visión que estamos enfrentando.

¿Me explico?

Saludos,

[heroe555]

El uso de estandares en el mundo del desarrollo de software es muy importante, siempre que se entienda, que el uso de estandares, medidas y pruebas va orientado a ayudar; a ser coayudante, y NO a ser protagonista, a ser el principal factor del desarrollo.

Hay empresas que molestan constantemente al programador con cosas como: cuanto tiempo has empleado en esa tarea?, describe y detalla el dia de trabajo, por que usas ese nombre de variable, y la lista de estupideses sigue.

Usar estandares beneficia cuando se trabaja en una empresa seria, donde su uso, esta orientado a mejorar la calidad, no a entorperer al desarrollador. Me parece que algunas empresas escuchan de estandares, y por jugar de profesionales, empiezan a obligar a usarlos sin saber lo que hacen.

En en plano individual todos los involucrados en el mundo de la programación deberiamos preocuparnos por seguir algún tipo de enfoque que nos permita mejorar nuestro desempeño.