La métrica del software es un factor realmente importante en el análisis de un proyecto. Hay distintos métodos de estimación de costes de desarrollo de software, también conocido como métrica del software.
La gran mayoría de estos métodos se basan en la medición del número de Líneas de Código (LDC) que contiene el desarrollo (se excluyen comentarios y líneas en blanco de los fuentes).
Entre estos métodos está el COCOMO (COnstructive COst MOdel) desarrollado por por Barry M. Boehm. Un método de estimación de coste de desarrollo no es otra cosa que establecer una relación matemática entre el esfuerzo y el tiempo requerido para desarrollar un producto / proyecto.
Lo primero que necesitamos saber es el tipo de proyecto del que estamos hablando, hay tres tipos diferentes:
- Orgánico: proyectos relativamente sencillos,En este modo, un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía de unos pocos miles de líneas (pequeño) a unas decenas de miles de líneas (medio).
- Semi-acoplado: proyectos intermedios en complejidad y tamaño. En este tipo, el proyecto tiene unas fuertes restricciones, que pueden estar relacionadas con el procesador y el interface hardware. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla.
- Empotrado: proyectos bastante complejos, en los que apenas se tiene experiencia y se engloban en un entorno de gran innovación técnica. Además se trabaja con unos requisitos muy restrictivos y de gran volatilidad.
Ahora por otro lado tendríamos los diferentes modelos que define COCOMO: Modelo básico, Modelo Intermedio y Modelo Avanzado.
En este punto quiero recordar que este tipo de modelos están orientados a la magnitud del producto final, midiendo el tamaño del proyecto en líneas de código principalmente, por el hecho de realizarse en base al número de líneas de código se mide el producto y su tamaño pero en ningún momento podremos llegar a medir la productividad.
Dificultad de un proyecto en función su líneas de código
| Categoría | Programadores | Duración | Líneas de código | Ejemplo |
| Trivial | 1 | 0 – 4 semanas | < 1k | Utilidad de ordenación |
| Pequeño | 1 | 1 – 6 meses | 1k – 3k | Biblioteca de funciones |
| Media | 2 – 5 | 0,5 – 2 años | 3k – 50k | Compilador de C |
| Grande | 5 – 20 | 2 – 3 años | 50k – 100k | SO pequeño |
| Muy grande | 100 – 1000 | 4 – 5 años | 100k – 1M | Grandes SO |
| Gigante | 1000-5000 | 5 – 10 años | > 1M | Sistema de Distribución |
Ejemplo práctico
Supongamos que queremos estimar el "Coste de desarrollo" de un proyecto que posee menos de 50.000 líneas de código y que por lo tanto y según hemos podido ver se trata de un Proyecto Orgánico.
"Proyecto prueba" = 9.200 líneas de código
La ecuación del esfuerzo de COCOMO es:
E = Esfuerzo = a KLDC b (persona x mes)
KLCD es el número de líneas de código en miles
La ecuación del tiempo de desarrollo es:
T = Tiempo de duración del desarrollo = c Esfuerzo d (meses)
Ahora necesitamos una tabla para obtener los coeficientes (a, b, c, d) que aparecen en las fórmulas citadas, estos coefcientes se obtienen de manera empírica y por lo tanto se basa en la experiencia de datos anteriores.
| Proyecto de software |
a |
b |
c |
d |
| Orgánico |
2,4 |
1,05 |
2,5 |
0,38 |
| Semiacoplado |
3,0 |
1,12 |
2,5 |
0,35 |
| Empotrado |
3,6 |
1,20 |
2,5 |
0,32 |
Por lo tanto el tamaño de nuestro "Proyecto prueba" como hemos visto es de 9,2 miles de líneas de código, si aplicamos las fórmulas:
Esfuerzo realizado = 2,4 * 9.2 1,05 = 25,77 personas / mes
T = 2,5 * 25,77 0,38 = 4,86 mes
Nº de personas para desarrollar el proyecto = E/T= 21,9 / 8,1 » 5 personas
Por lo tanto y con estos resultados diríamos que el "Proyecto Prueba" debería terminarse en aproximadamente 5 meses por un equipo de 5 personas.
Información adicional
Por cierto buscando algo de información sobre este método he encontrado esta página que contiene un formulario con el que calcular rápidamente los diferentes datos de estimación de coste de desarrollo de un proyecto basándose en el método COCOMO.
He encontrado también una comparativa de las líneas de código algunos "Sistemas Operativos actuales y antiguos" (Pueden servirte como ejemplos para porbar las fórmulas anteriormente citadas).
| Sistema Operativo | Líneas de Código |
| Microsoft Windows 3.1 (Abril de 1992) |
3.000.000 |
| Sun Solaris (Octubre de 1998) |
7.500.000 |
| Microsoft Windows 95 (Agosto de 1995) |
15.000.000 |
| Red Hat Linux 6.2 (Marzo de 2000) | 17.000.000 |
| Microsoft Windows 2000 (Febrero de 2000) |
29.000.000 |
| Red Hat Linux 7.1 (Abril de 2001) | 30.000.000 |
| Microsoft Windows XP (2002) |
40.000.000 |
| Red Hat Linux 8.0 (Septiembre de 2002) |
50.000.000 |
| Fedora Core 4 (Mayo de 2005) |
76.000.000 |
| Debian 3.0 (Julio de 2002) |
105.000.000 |
| Debian 3.1 (Junio de 2005) |
229.500.000 |
Enlaces Relacionados
- Escritorios Online
- Utilidad de las teclas de funcion (F1, F2, F3 , etc...)
- Nuevo Windows Unattended Edition
- El mejor fondo de escritorio
- Ventajas del uso de dos monitores
- Disponible OpenOffice 2.3.0 en castellano
- El mejor fondo de escritorio
- Convertir videos YouTube en GIF animados
- Google Desktop para Linux
- Distribuciones Linux... las más populares
Pregunta de productividad
Saludos, me gustaría saber si ustedes tienen algún calculo o algún dato estandar respecto a la productividad de los desarrolladores de software, es decir, un desarrollador al mes puede ser productivo (Software de buena calidad) en un porcentaje especifico.
Duda
NO se porque actualmente se toma en cuenta como referencia aplicando el modelo de cocomo el sistema operativo y no el lenguaje de programación donde se programará el sw.
Yo quisiera que alguien me ayude pero con la matriz basada en el lenguaje de programación pero que este actualizada donde se tome en cuenta lenguajes de última generación tales como Visual Basic.net, c# etc. He encontrado una matriz pero con lenguajes antiguos como
C++
Shell
LISP
Perl
Python
Java
FORTRAN
PHP
Pascal
Ada
En mi caso personal estoy pensando aplicar vb.net pero no encuentro la tabla actualizada donde me indique el LDC aproximado para ese lenguaje.
Cualquier novedad
hola
Hola serias tan amable de facilitarme la matriz con esos lenguajes, estoy interesada en saber el factor de conversion de php. Le agradeceria que me ayudara.
No puedes cobrar por lineas
No puedes cobrar por lineas de codigo, porque nosotros como programadores, nuestro trabajo no es solamente programar, sino crear un codigo eficiente y lo mas corto posible. Realmente lo que cobras por programar (o desde mi punto de vista) es tu conocimiento como programador - porque puedes usar 100 cout's o un solo for - , el esfuerzo que con el que programas y por ultimo la ignorancia de quien no sabe programar.
Como nota personal, una vez cobre 100 pesos mexicanos por un programa de 20 lineas, de lo mas sencillo que hay, pero realmente cobre la ignorancia de quien no sabie.
Estoy de acuerdo
Me parece muy bien pero para las personas que no tienen esperiencia en vender proctudo de software es muy productivo. Lo mas complicado de este tema de software esta es la parte mas complicada
no es obsoleto
el mejor soft no es el que menos lineas de codigo tiene, el mejor soft es el qeu mejor responde a los requerimientos, el qeu tiene un mantenimiento mas facil, el que mejor respeta los estandares, el que es mas facil de apliar, etc. El buen programador no busca reducir el numero de lineas de codigo...... es era en la epoca en qeu la cantidad de lineas afectaban el rendimiento.
Con respecto a saber previamente las lineas de codigo, no se refiere a algo exacto... es una estimacion, y esa estimacion se hace en base a experiencia. Este metodo es muy util y ampliamente usado. Si no te gusta el tema de las LDC podes hacer estimaciones por punto de funcion. Lee pressman.
saludos
de acuerdo con diego
¿cómo saber de antemano cuántas líneas de código voy a tener que escribir?
Lenguajes modernos
Este cálculo se refería a cuando se programa en C, ¿verdad?
Porque hoy en día yo puedo escribir un programa en Perl de una sola línea, en 15 segundos, que equivale a más de 100 en C, escritas y verificadas en media hora.
¿Cómo se valora entonces mi trabajo? ¿Por 15 segundos? ¿Por una línea? ¿O por ahorrar media hora y 99 líneas de programa?
Se entiende que C tiene una
Se entiende que C tiene una sintaxis suficientemente estándar, flexible y global; para poder compararlo con otros lenguajes.
En cualquier caso, los grandes proyectos vienen a estar, en su gran mayoría, en C o C++ (que es para lo que yo entiendo la comparativa, no para programas triviales de menos de 1000 líneas).
De igual manera que programar en C++ es tan o más complicado que programar en C; a pesar de que para ordenar un conjunto de objetos con C++ ocupa una línea y con C habría que implementarlo a mano. Igual que en un lenguaje en el que si escribes "FileDialog" te genera una ventana de diálogo para elegir un fichero no significa que como programador tengas más rendimiento.
Metodo obsoleto
Este analisis de costo es contradictorio, el mejor software es aquel que en menos lineas de codigo brinda la solución esperada. Ahora con este metodo ¿por qué vamos a tratar de optimizar lo mas posible nuestros codigos si vamos a ganar menos por ello? A mi entender este calculo pudo haber sido útil en su momento pero ya no lo es.
Estoy de acuerdo
Estoy de acuerdo
Si para calcular el coste de
Si para calcular el coste de un proyecto necesitas saber previamente el número de lineas de código encuentro todo el asunto poco útil, ya que antes de empezar un proyecto que es cuando te interesa valorarlo nunca sabes el numero de lineas y cuando ya lo has terminado y sabes el número de LDC ya no tiene sentido la valoración
No encontrado
Parece que al descargar el PDF (http://tufuncion.com/archivos/Measuring%20Libre%20Software%20Using%20Deb...), aparece un error de no encontrado 404.
Enviar un comentario nuevo