ESTIMACIÓN PARA PROYECTOS DE SOFTWARE

ESTIMACIÓN PARA PROYECTOS DE SOFTWARE

La gestión del proyecto de software comienza con un conjunto de actividades que en grupo se denominan planificación del proyecto. Antes de que el proyecto comience el gestor, del proyecto y el equipo de software deben estimar el trabajo que habrá de realizarse, los recursos que se requerirán y el tiempo que transcurrirá; desde el principio hasta el final.

McConell argumenta que cualquier proyecto puede encontrar el tiempo para planificar (y adaptar el plan a lo largo del proyecto) simplemente tomando un pequeño porcentaje del tiempo que se habría gastado en la reelaboración que ocurre debido a que no se planificó.

 

1.- OBSERVACIONES ACERCA DE LA ESTIMACIÓN

La planificación requiere que los gestores técnicos y los miembros del equipo de software establezcan un compromiso inicial, aun cuando sea probable que este "compromiso" pruebe estar equivocado. Siempre que se realizan estimaciones se atisba al futuro y se acepta automáticamente algún grado de incertidumbre.

La estimación de recursos, costo y programa de trabajo para una tarea de ingeniería de software requiere experiencia, acceso a buena información histórica (métricas) y el valor para comprometerse con predicciones cuantitativas cuando la información cualitativa es todo lo que existe. La estimación implica riesgo inherente, y éste conduce a la incertidumbre.

La disponibilidad de información histórica tiene una fuerte influencia en el riesgo de la estimación. Al mirar en retrospectiva, se pueden emular las cosas que funcionaron y mejorar las áreas donde surgieron problemas. Cuando hay disponibles amplias métricas de software de proyectos previos, las estimaciones se hacen con mayor seguridad, los programas de trabajo se pueden establecer para evitar dificultades pasadas y el riesgo global se reduce.

El riesgo de la estimación se mide por el grado de incertidumbre en las estimaciones cuantitativas establecidas para recursos, costos y programa de trabajo. Si el ámbito del proyecto se comprende en forma deficiente o los requisitos del proyecto están sujetos a eventuales cambios, la incertidumbre y el riesgo de la estimación se incrementan peligrosamente. El planificador y, en forma más importante, el cliente deben reconocer que la variabilidad en los requisitos del software significa inestabilidad en costo y programa de trabajo.

 

2.- EL PROCESO DE PALNIFICACIÓN DEL PROYECTO

El objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo que permita al gestor estimar razonablemente recursos, costo y programa de trabajo. Además, las estimaciones deben intentar definir los escenarios de mejor y peor caso de modo que los resultados del proyecto se puedan acotar. Aunque existe un grado inherente de incertidumbre, el equipo de software se embarca en un plan establecido como consecuencia de las tareas de planificación.

 

3.- ÁMBITO DEL SOFTWARE Y FACTIBILIDAD

El ámbito del software describe las funciones y características que se entregarán a los usuarios finales, los datos que son entrada y salida, el "contenido" que se presenta a los usuarios como consecuencia de emplear el software, así como el desempeño, las restricciones, las interfaces y la confiabilidad que acotan el sistema.

Una vez identificado el ámbito (con la participación del cliente) es razonable preguntar: ¿es posible construir software para satisfacer este ámbito? ¿El proyecto es factible? Con mucha frecuencia los ingenieros de software soslayan estas preguntas (o gestores o clientes impacientes los presionan para hacerlo), sólo para verse enredados en un proyecto condenado al fracaso.

 

4.- RECURSOS

La segunda tarea de la planificación es la estimación de los recursos necesarios para completar el esfuerzo de desarrollo del software. La figura muestra las tres grandes categorías de los recursos de ingeniería del software: personal, componentes de software reutilizables y el entorno de desarrollo (hardware y herramientas de software). Cada recurso se especifica con cuatro características: descripción del recurso; un informe de disponibilidad; cuándo se requerirá el recurso; tiempo durante el cual el recurso se aplicará. Las últimas dos características se pueden ver como una ventana de tiempo. La disponibilidad del recurso para una ventana específica debe establecerse lo más pronto posible.

 

5.- ESTIMACIÓN DE PROYECTOS DE SOFTWARE

El software es el elemento más caro de virtualmente todos los sistemas basados en computadora. En sistemas complejos, personalizados, un gran error en la estimación del costo puede hacer la diferencia entre beneficio y pérdida. Rebasar el costo puede ser desastroso para el desarrollador.

La estimación del costo y el esfuerzo nunca será una ciencia exacta. Demasiadas variables —humanas, técnicas, ambientales, políticas— pueden afectar el costo final del software y el esfuerzo aplicado a desarrollarlo. Sin embargo, la estimación del proyecto de software se puede transformar de una práctica oscura en una serie de pasos sistemáticos que proporcionan estimaciones con riesgo aceptable. Para lograr estimaciones confiables de costo y esfuerzo se tienen varias opciones:

1.    Demorar la estimación hasta más tarde en el proyecto (obviamente, ¡se puede lograr 100 por ciento de estimaciones precisas después de que el proyecto esté terminado)

2.    Basar las estimaciones en proyectos similares que ya hayan sido completados.

3.    Emplear técnicas de descomposición relativamente simples para generar estimaciones de costo y esfuerzo del proyecto.

4.    Utilizar uno o más modelos empíricos en la estimación de costo y esfuerzo.

6.- TÉCNICAS DE DESCOMPOSICIÓN

La estimación del proyecto de software es una forma de resolver problemas; en la mayoría de los casos, el problema que debe resolverse (es decir, el desarrollo de una estimación de costo y esfuerzo para un proyecto de software) es muy complejo como para considerarlo una sola pieza. Por esta razón se descompone el problema, recaracterizándolo como un conjunto de problemas más pequeños (y, esperanzadoramente, más manejable).

Se ha examinado el enfoque de descomposición desde dos diferentes puntos de vista: descomposición del problema y descomposición del proceso. La estimación emplea una o ambas formas de partición. Pero antes de que pueda realizarse una estimación, el planificador del proyecto debe entender el ámbito del software que se construirá y generar una estimación de su "tamaño".

6.1 TAMAÑO DEL SOFTWARE

La precisión de la estimación de un proyecto de software se manifiesta en varios factores: 1) el grado con el cual el planificador ha estimado adecuadamente el tamaño del producto que se construirá; 2) la habilidad para traducir la estimación del tamaño en esfuerzo humano, programa de trabajo y dinero (una función de la disponibilidad de las métricas de software confiables a partir de proyectos previos); 3) el grado en el cual el plan del proyecto refleja las habilidades del equipo de software; y 4) la estabilidad de los requisitos del producto y el entorno que soporta el esfuerzo de ingeniería del software.

En esta sección se considera el problema del tamaño del software. Puesto que la estimación de un proyecto sólo es tan buena como la estimación del tamaño del trabajo para realizarlo, el tamaño representa el primer gran desafío del planificador del proyecto. En el contexto de la planificación del proyecto, tamaño se refiere a un resultado cuantificable del proyecto de software.

 

7.- MODELOS EMPÍRICOS DE ESTIMACIÓN

Un modelo de estimación para software de computadora utiliza fórmulas obtenidas empíricamente para predecir el esfuerzo como una función de LDC o PF.

Los datos empíricos que apoyan la mayoría de los modelos de estimación proceden de una muestra limitada de proyectos. Por esta razón, ningún modelo de estimación es apropiado para todas las clases de software ni en todos los entornos de desarrollo. En consecuencia, los resultados obtenidos a partir de tales modelos se deben emplear juiciosamente.

Un modelo de estimación debe calibrarse para reflejar las condiciones locales. El modelo debe probarse mediante la aplicación de los datos recopilados a partir de proyectos completados, colocar los datos en el modelo y luego comparar los resultaos reales con los predichos. Si la concordancia es insuficiente, el modelo debe afinarse y ponerse a prueba nuevamente antes de que se pueda utilizar.

7.1 LA ESTRUCTURA DE LOS MODELOS DE ESTIMACIÓN

Un modelo de estimación típico se deriva mediante el análisis de regresión de los datos recopilados de proyectos de software previos. La estructura global de tales modelos toma la forma

E = A + B x (ey) c

Donde A, B y C son constantes obtenidas empíricamente, E es el esfuerzo en persona-mes y ev es la variable de estimación.

 

7.2 LA ECUACIÓN DEL SOFTWARE

La ecuación de software es un modelo multivariable que supone una distribución específica del esfuerzo a lo largo de la vida de un proyecto de desarrollo de software. El modelo procede de datos de productividad recopilados de casi 4 000 proyectos de software contemporáneos. Con base en estos datos, un modelo de estimación de la forma

E = [LDC x B0.333/P]3 x (1/t4)

Donde

E = esfuerzo en personas-mes o personas-año

t = duración del proyecto en meses o años

B = "factor especial de habilidades"

 

8.- ESTIMACIÓN PARA PROYECTOS ORIENTADOS A OBJETOS

1. Desarrollar estimaciones aplicando la descomposición de esfuerzo, análisis de PF y cualquier otro método que sea aplicable en aplicaciones convencionales.

2. Aplicar el modelado de análisis orientado a objetos, desarrollar casos de uso y determinar un conteo. Reconocer que el número de casos de uso puede cambiar conforme avance el proyecto.

3. A partir del modelo de análisis, determinar el número de clases clave (llamadas clases de análisis).

4. Categorizar el tipo de interfaz para la aplicación y desarrollar un multiplicador para las clases de soporte:

Tipo de interfaz	Multiplicador
Sin IUG	2.0
Interfaz del usuario basada en texto	2.25
IUG	2.25
IUG compleja	3.0

 

Multiplicar el número de clases clave por el multiplicador para obtener una estimación del número de clases de soporte.

5. Multiplicar el número total de clases (clave + soporte) por el número promedio de unidades de trabajo por clase. Se sugiere de 15 a 20 personas-día por clase.

6. Comprobar de manera cruzada la estimación basada en clase al multiplicar el número promedio de unidades de trabajo por caso de uso.

 

9.- TÉCNICAS DE ESTIMACIÓN ESPECIALIZADAS

Las técnicas de estimación estudiadas en las secciones 6, 7 y 8 se pueden aplicar en cualquier proyecto de software. Sin embargo, cuando un equipo de software encuentra una duración de proyecto extremadamente corta (semanas más que meses) —que probablemente tengan una continua corriente de cambios— la planificación del proyecto en general y la estimación en particular se deben abreviar.

    9.1 ESTIMACIÓN PARA DESARROLLO ÁGIL

Puesto que los requerimientos para un proyecto ágil se definen como un conjunto de escenarios de usuario es posible desarrollar un enfoque de estimación informal, aunque razonablemente disciplinado y significativo dentro del contexto de la planificación del proyecto para cada incremento de software.

La estimación para los proyectos ágiles aplica un enfoque de descomposición que abarca los pasos siguientes:

1.    Cada escenario de usuario se considera por separado respecto de propósitos de estimación.

2.    El escenario se descompone en el conjunto de funciones y las tareas de ingeniería del software que se requerirán para desarrollarlo.

3a. Cada tarea se estima por separado.

3b. Alternativamente, el "volumen" (tamaño) del escenario se puede estimar en LDC, PF o alguna otra medida orientada a volumen.

4a. Las estimaciones de cada tarea se suman para crear una estimación para el escenario.

4b. Alternativamente, el volumen estimado para el escenario se traduce en es-fuerzo mediante la aplicación de datos históricos.

5. Las estimaciones de esfuerzo acerca de todos los escenarios que se imple-mentarán para un incremento de software dado se suman con el fin de desarrollar el esfuerzo estimado para el incremento.

 

9.2 ESTIMACIÓN PARA PROYECTOS DE INGENIERÍA WEB

Como se asentó anteriormente, los proyectos de ingeniería Web con frecuencia adoptan el modelo de proceso ágil. Es factible emplear una medición de punto de función modificada, con el fin de desarrollar una estimación para la WebApp.

Roetzheim sugiere los siguientes valores de dominio de información cuando se adaptan puntos de función para la estimación WebApp:

•    Entradas: son cada pantalla o formato de entrada (por ejemplo, CGI o Java), cada pantalla de mantenimiento y, si en alguna parte utiliza una etiqueta de metáfora de cuaderno, cada etiqueta.

•    Salidas: son cada página Web estática, cada guión de página Web dinámica (por ejemplo, ASP, ISAPI u otro guión DHTML) y cada reporte (ya sea que esté basado en Web o sea del todo administrativo).

•    Tablas: son cada tabla lógica en la base de datos más, si emplea XML para almacenar datos en un archivo, cada objeto XML (o colección de atributos XML).

•    Las interfaces retienen su definición como archivos lógicos (por ejemplo, formatos de registro únicos) en las fronteras exteriores del sistema.

•    Consultas: son cada interfaz publicada externamente o utiliza una interfaz orientada al mensaje. Un ejemplo típico son las referencias externas DCOM o COM.

Los puntos de función (calculados empleando los valores de dominio de información anotados) son un indicador razonable del volumen para una WebApp.

 

10.- LA DESICIÓN DESARROLLAR-COMPRAR

A menudo, en muchas áreas de aplicación de software es más rentable adquirir que desarrollar software de computadora. Los gestores de ingeniería del software enfrentan una decisión de desarrollar-comprar que tal vez se complique aún más por varias opciones de adquisición: 1) el software se puede comprar (o adquirir la licencia) ya desarrollado, 2) los componentes de software de "experiencia completa" o "experiencia parcial" se pueden adquirir y luego modificar e integrar para satisfacer necesidades específicas, o 3) el software se puede construir de manera personalizada por medio de un contratista externo para satisfacer las necesidades del comprador.

Los pasos involucrados en la adquisición los definen lo crucial del software que se comprará y el costo final. En el análisis final, la decisión desarrollar-comprar se realiza basándose en las siguientes condiciones: 1) ¿El producto de software estará disponible antes que el software desarrollado de manera interna? 2) ¿El costo de adquisición más el costo de personalización será menor que el costo de desarrollar el software de manera interna? 3) ¿El costo del soporte externo (por ejemplo, un contrato de mantenimiento) será menor que el costo del soporte interno? Estas condiciones se aplican a cada una de las opciones de adquisición.