Karla es ingeniero de software que ha estado trabajando con PSP desde que entró a trabajar a una compañía que se ha convertido en un referente en la consultoría de proyectos de software. Al inicio del año su jefe le asignó un proyecto al que se le asignaron 600 horas de trabajo de un programador a tiempo completo. A Karla esta estimación del esfuerzo requerido para obtener la funcionalidad completa le pareció muy baja, pues considera que el cliente espera cubrir una necesidad crítica para su negocio. Ella estima que deberían incluirse al menos 200 horas extras a la estimación inicial.

Ante esta discrepancia, Karla aprovecha una reunión con el gerente del proyecto para consultarle cómo es que llegaron a esa decisión. El gerente le confirmó que era una cantidad de líneas de código requeridas que fueron reutilizadas, y se realizó un cálculo de los Puntos de Función tomando en cuenta uno de los proyectos anteriores en los que se requirió una funcionalidad similar y se misma arquitectura de software. Karla se pregunta ¿cómo se estima la cantidad de líneas de código cuando se incorporan funciones de otros programas ?, ¿qué se refirió el gerente del proyecto cuando mencionó el término de puntos de función y qué relación tiene con la dimensión del tamaño del software?

4.1 Tamaño del software

Los proyectos de software deben basarse en un plan que incluya una secuencia de actividades, a las que se les asigna recursos. En este ejercicio de planeación será necesario un cálculo de cantidades como el tiempo requerido y el personal que realizará las tareas, a esto se le llame estimación.  La estimación es una actividad tan importante en los proyectos que podría transformarse en un aliado o en el peor enemigo de los proyectos. Al estimar el tamaño del software a desarrollar se calcula el tiempo que el proyecto durará y la cantidad de recursos necesarios. En opinión de Humphrey (2006), para que el tamaño del software sea una medida útil debe ser precisa, específica, y cuantificable de forma automática.

Haz clic para conocer más detalle

Existe una correlación entre la estimación del tamaño del software y el tiempo requerido para desarrollarlo. Entre el tamaño del software sea más grande se requiere más tiempo para analizar los requerimientos del cliente, el diseño es más complejo, la cantidad de casos de prueba será mayor, al igual que el tiempo que le dediquen a documentar el software. Por ejemplo, para establecer una medida de la base de datos que se utilizaría en un sistema es posible contabilizar la cantidad de tablas y campos, incluso un estimado de la cantidad de registros que se crearían de forma periódica. En un desarrollo se podría establecer la cantidad de elementos de la interfaz gráfica (cantidad de campos, etiquetas, botones, opciones del menú, etc.), el tamaño de los programas podría estimarse con la cantidad de líneas de código.
Cualquier elemento que sirva para estimar el esfuerzo necesario para generar un producto de software serían muy útiles.

SLOC (source lines of code)

La cantidad de líneas de código es una medida que está directamente relacionada con el esfuerzo del programador, y probablemente la más sencilla. Sin embargo, es importante primero definir el método para contabilizar de manera consistente. En el siguiente ejemplo, puedes ver dos formas en las que puede aparecer una misma estructura de código:

Ejemplos tomados del libro: Humphrey, W. (2005). PSP(SM): A Self-Improvement Process for Software Engineers. EE. UU: Pearson Education. Sólo para fines educativos.

En el ejemplo 1 podríamos contabilizar cada renglón como una línea de código, lo que implica que cantidad de LOC’s=9, mientras que en el ejemplo 2 sería LOC’s=3. Podrías decir que el primer código tiene una carga de esfuerzo mayor que el segundo, lo cual no sería del todo cierto.

Otra manera sería contabilizar cada línea cada vez que aparezca un punto y coma (;), eso equivale a que en el ejemplo 1 y el ejemplo 2 tienen un valor de LOC’s=1, siendo una contabilización más consistente.

La descripción completa del método sería:

1. Contabilice las sentencias lógicas de código. Es decir, aquellas que terminan con un punto y coma.
2. Los comentarios y los renglones en blanco no se cuentan.
3. Considere aplicar estas reglas para un lenguaje de programación específico.

Lo importante de tener esta definición radica en la posibilidad de automatizar el método, lo que facilita el cálculo.

El siguiente paso sería determinar cómo evaluar el esfuerzo del programador al asignarle un programa que debe modificar para agregarle funcionalidad.

Humphrey (2006), ofrece las siguientes definiciones:

Una forma gráfica para comparar 2 versiones de código la puedes ver en el siguiente diagrama. El total de líneas de código de la versión 2 es de 910, que se componen de las líneas de código base (sin modificar) + modificadas + reusadas + añadidas. Total = 175 + 75 + 600 + 60. En este caso no fueron incorporadas líneas de nuevo código reusable.

Diagrama tomado del libro: Humphrey, W. (2005). PSP(SM): A Self-Improvement Process for Software Engineers.
EE. UU: Pearson Education. Sólo para fines educativos.

4.2 Uso de los datos del tamaño

Una vez que se ha calculado el tamaño del software, estos datos pueden ser utilizados para planear, administrar la calidad y medir la productividad

Haz clic para conocer más detalle

4.3 Puntos de función

Mientras medir el producto del software a través de la cantidad de líneas de código se realiza a través del punto de vista del programador, existe otro método para medir el tamaño del software desde el punto de vista del usuario. A este método se le conoce como FP - Functional Points o Puntos de Función y en opinión de Chemuturi (2009) es un método muy popular y ha sido aceptado por muchas organizaciones como un estándar. Esta técnica se basa en medir la funcionalidad que se ofrece el software al usuario. Para cuantificar la funcionalidad se requiere descomponer el sistema en partes pequeñas que puedan ser entendidas y analizadas tanto por el usuario como por el programador. Se divide entonces en 5 aspectos: entradas, salidas, archivos, consultas e interfaces que utiliza.

(1) El factor de peso ha de elegirse de forma subjetiva según el tipo de funcionalidad requerida.

Se realiza el siguiente cálculo:

PF= [Conteo Total] x [0.65 + 0.01 x ∑(F_i)]

Donde F_i = Factores de ajuste de valor (i=1 al 14) Dependiendo de las respuestas a las preguntas que aparecen en la siguiente tabla:

(2) Los valores se determinan usando la siguiente escala de valores:

Los puntos de función son de especial ayuda para calcular el esfuerzo, costo y posibles defectos en el software de la siguiente manera:

Según el estándar propuesto por el Grupo Internacional de Usuarios de Puntos de Función   IFPUG (2015), se estima que el esfuerzo requerido para desarrollar un Punto de Función es de 14 horas-hombre:

Esfuerzo Requerido = PF * 14 (Horas-Hombre)

Tomando en cuenta lo anterior, es posible calcular el costo del esfuerzo realizado:

Costo Requerido= Esfuerzo Requerido * Costo Hora-Hombre

Además, este mismo estándar establece que los defectos potenciales en el desarrollo de un sistema tienen la siguiente proporción:

Defectos Potenciales = 5.5 * PF

Y una vez entregado el sistema, habiendo pasado todas las pruebas, se estima que los defectos entregados al cliente son los siguientes:

Entrega de Defectos = 0.22 * PF

Para que estos cálculos sean una base adecuada que pueda utilizarse para planear el esfuerzo de un proyecto, es importante considerar los siguientes elementos:

• Tipo de plataforma de hardware: Mainframe, Cliente-Servidor, PC.
• Lenguaje de programación: Java, C++, C#, PHP, Python
• Tipo de Proyecto: Software del Sistema, Software intermedio, Software de Aplicación
• Tipo de Sistema Operativos: Windows, Linux, Unix
• PF históricos: Cálculo de otros proyectos similares
• Costos históricos: Costos incurridos en proyectos similares.

Determinar cuánto esfuerzo requiere un proyecto de software suele ser una actividad basada en la experiencia de un grupo de programadores expertos, que en muchas ocasiones ni siquiera son parte activa en el mismo proyecto. Esto provoca generar proyectos subestimados en recursos, que se vuelven una dura carga para el equipo de programadores, que tratarán de cumplir con fechas de entrega que son prácticamente imposibles, o bien, se sobreestima el esfuerzo requerido, lo que encarece el producto y merma las oportunidades del cierre de contratos. Sin duda, nadie tiene una bola mágica que prediga con exactitud lo que implica realmente la realización de un proyecto de software, sin embargo, cuando el tamaño del software está basado en una técnica que se aplica de manera consistente, resulta ser una opción mucho mejor que basarse en opiniones subjetivas.

En la actualidad no existe una única forma de estimar el tamaño del software que sea utilizada por la industria de las compañías dedicadas al desarrollo del software. Cada una aplica la técnica que mejor le ha funcionado. Lo cierto es que recuperar la mayor cantidad de datos para medir la productividad del equipo de desarrollo es la mejor forma que pueden aplicar para estimar con mayor precisión sus nuevos proyectos de software. 

Asegúrate de poder:

• Reconocer la importancia de medir el tamaño del software como una base para planear el proyecto, la calidad y la productividad.
• Aplicar las técnicas de Líneas de Código y Puntos de Función para estimar el tamaño del software.

Correlación: es el grado en el que dos variables se relacionan entre sí.

• Chemuturi, M. (2009). Software estimation best practices, tools & techniques. EE. UU: J. Ross Publishing,
• Humphrey, W. (2005). PSP(SM): A Self-Improvement Process for Software Engineers. EE. UU: Pearson Education.
• IFPUG (2015). Function Point Alignment, Recuperado de: http://www.ifpug.org/Metric%20Views/MetricViewsJan2015.pdf