Estimaciones de Costes en Proyectos de Software
Durante el desarrollo de un proyecto de software, este se divide en diversas actividades que se ejecutan de manera secuencial o en paralelo. La estimación de costes y la creación del calendario del proyecto se realizan conjuntamente. Sin embargo, en la etapa inicial, se requieren estimaciones de costes preliminares antes de la planificación detallada. Estas estimaciones son cruciales para establecer un presupuesto o definir el precio del software para un cliente.
Existen tres parámetros fundamentales en el cálculo del coste total de un proyecto de desarrollo de software:
- Costes de hardware y software, incluyendo el mantenimiento.
- Costes de viajes y capacitación.
- Costes de esfuerzo.
La estimación del software debe ser objetiva y buscar predecir con la mayor precisión posible el coste de desarrollo. No existe una fórmula mágica para una estimación precisa del esfuerzo requerido. Las estimaciones iniciales se basan en la definición de alto nivel de los requerimientos del usuario.
Las organizaciones, para realizar estimaciones de esfuerzo y coste, utilizan una o más técnicas de estimación (modelado algorítmico de costes, juicio experto, estimación por analogía, ley de Parkinson, pricing to win). Estas técnicas son aplicables cuando se cuenta con un documento de especificación de requerimientos. En proyectos grandes de ingeniería de sistemas, es común contar con este tipo de documento.
Estimación en Proyectos de Software
Estimar implica predecir valores de entidades y sus atributos relevantes para el proyecto.
- Predecir: Anticipar con cierto grado de certeza.
- Entidades: En software, se refiere a procesos, productos y recursos.
- Atributos: Características de las entidades.
- Relevantes: Aquellas que implican mayor riesgo.
SQA: Medición y Métricas de Software
Los controles de calidad del software consumen tiempo, recursos económicos y pueden retrasar la entrega. Sería ideal contar con herramientas que evalúen automáticamente la calidad del diseño o del código. Las valoraciones del software permiten identificar las partes que cumplen con la calidad requerida y aquellas que necesitan revisión y corrección.
Medición del Software
La medición del software consiste en obtener un valor numérico de un atributo del software o del proceso de desarrollo. Comparando estos valores entre sí y con los estándares de la organización, se pueden obtener conclusiones sobre la calidad del software o de los procesos.
Las mediciones de software se utilizan para:
- Realizar predicciones generales sobre el sistema.
- Identificar componentes anómalos.
Métricas de Software
Una métrica de software es cualquier medida relacionada con un sistema, proceso o documentación de software. Las métricas pueden ser de control o de predicción, y ambas influyen en la toma de decisiones de gestión.
- Métricas de Control: Asociadas a los procesos. Ej.: esfuerzo y tiempo promedio para reparar defectos.
- Métricas de Predicción: Asociadas a los productos. Ej.: complejidad ciclomática de un módulo, longitud media de los identificadores.
Relación entre Métricas Internas y Externas
A menudo, es imposible medir directamente los atributos de calidad del software (mantenibilidad, comprensión, usabilidad). Por ello, se miden atributos internos (como el tamaño) y se asume una relación entre estos y los atributos externos.
Para que la medida de un atributo interno sea un indicador útil de una característica externa, se deben cumplir tres condiciones:
- El atributo interno debe medirse con precisión.
- Debe existir una relación entre lo medible y el atributo externo.
- La relación debe ser comprendida, validada y expresable mediante una fórmula o modelo.
Pasos clave en el proceso de medición:
- Seleccionar las medidas a realizar.
- Seleccionar los componentes a evaluar.
- Medir las características de los componentes.
- Identificar mediciones anómalas.
- Analizar los componentes anómalos.
Métricas de Producto
Se refieren a las características del propio software. Se dividen en dos clases:
- Métricas dinámicas: Recogidas durante la ejecución del programa.
- Métricas estáticas: Recogidas de las representaciones del sistema (diseño, código, documentación).
Las métricas dinámicas ayudan a evaluar la eficiencia y la fiabilidad. Las métricas estáticas ayudan a evaluar la complejidad, la comprensión y la mantenibilidad.
Work Breakdown Structure (WBS)
La WBS es una subdivisión del trabajo en unidades más manejables. Permite:
- Mostrar las actividades necesarias para lograr los objetivos.
- Identificar responsables y responsabilidades.
- Registrar el avance del proyecto.
- Representar el estado del proyecto.
- Facilitar la comunicación entre los actores.
- Mostrar cómo se controlará el proyecto.
Organización de una WBS
- Orientada al producto: Permite identificar cada componente.
- Orientada a la fase: Permite evaluar las fases del proyecto.
- Orientada a la función: Permite identificar a los actores del proyecto.
Consideraciones al crear una WBS
- Nivel de agregación vs. esfuerzo de seguimiento.
- Fechas comprometidas con el cliente.
- Fechas comprometidas internamente.
- Incluir o no tareas administrativas y de SQA.
Representación Gráfica de la Calendarización
Los gráficos de barras (Gantt) y las redes de actividades (PERT) son herramientas para ilustrar la calendarización del proyecto.
- Gráficos de Gantt: Muestran la planificación, asignación de fechas y la precedencia entre tareas.
- Gráficos PERT: Muestran la planificación y la precedencia entre tareas.
Análisis de Riesgo en Proyectos de Software
En el análisis de riesgo, se considera cada riesgo identificado y se evalúa su probabilidad e impacto. Este análisis se basa en la experiencia del gestor del proyecto. La probabilidad del riesgo se clasifica en intervalos (muy bajo, bajo, moderado, alto, muy alto). Los efectos del riesgo se clasifican como catastróficos, serios, tolerables o insignificantes.
Los resultados del análisis se organizan en una tabla, ordenada por la severidad del riesgo. Se deben considerar los riesgos catastróficos y los riesgos serios con una probabilidad moderada o alta de ocurrencia.
Planificación de Riesgo
Se consideran los riesgos clave identificados y se definen estrategias para gestionarlos. Esto depende del juicio y la experiencia del gestor del proyecto.
Supervisión de Riesgo
Se evalúa cada riesgo para determinar si su probabilidad o impacto han cambiado. Se buscan indicadores que den pistas sobre la probabilidad e impacto del riesgo.
Hitos en Proyectos de Software
Al planificar un proyecto, se establecen hitos, que son puntos finales de una actividad del proceso de software. Cada hito debe tener una salida formal, como un informe. Los informes de hitos deben ser concisos y resumir los logros de la actividad. Los hitos representan el final de una etapa lógica en el proyecto.
Entregas
Las entregas son los resultados del proyecto que se entregan al cliente, generalmente al final de una fase principal (especificación, diseño, etc.). Las entregas suelen ser hitos, pero no todos los hitos son entregas. Algunos hitos son resultados internos que utiliza el gestor del proyecto para verificar el progreso.
Gestión de Proyectos de Software
La gestión de proyectos de software es esencial en la ingeniería de software. Una buena gestión no garantiza el éxito, pero una mala gestión suele conducir al fracaso. Los gestores de proyectos son responsables de la planificación, la programación y la supervisión del proyecto. Deben asegurar que el proyecto se ejecuta según los estándares, se ajusta al presupuesto y cumple con los plazos.
La ingeniería de software está sujeta a restricciones de tiempo y presupuesto. El gestor de proyectos debe asegurar el cumplimiento de estas restricciones y la entrega de un software que contribuya a los objetivos de la empresa.
Desafíos en la Gestión de Proyectos de Software
La gestión de proyectos de software presenta desafíos específicos debido a la naturaleza del software:
- Intangibilidad: El software no se puede ver ni tocar, lo que dificulta la visualización del progreso.
Gestión de Riesgos en Proyectos de Software
El gestor de proyectos debe anticipar los riesgos que podrían afectar la programación o la calidad del software y tomar medidas para evitarlos. Los resultados del análisis de riesgos se documentan en el plan del proyecto. Los riesgos varían según el proyecto y el entorno, pero algunos son comunes a muchos proyectos (rotación de personal, cambios en la gestión, falta de disponibilidad de hardware, cambios en los requerimientos, etc.).
Modelos Paramétricos de Estimación: COCOMO II
COCOMO II es un modelo empírico basado en la experiencia con proyectos grandes. Es un método bien documentado, cuya primera versión se publicó en 1981. La última versión, COCOMO 2, considera diferentes enfoques de desarrollo, reutilización, etc.
El modelo de fase posterior a la arquitectura se utiliza cuando:
- Los requisitos están establecidos.
- La arquitectura básica del software está definida.
- Se está en la fase de construcción del software.
COCOMO II y otros modelos paramétricos tienen una estructura común y parámetros que se pueden calibrar con datos de proyectos anteriores.
COCOMO: Modelo Empírico de Estimación
COCOMO es un modelo empírico basado en datos de proyectos grandes. Las fórmulas del modelo vinculan el tamaño del sistema, factores del proyecto, factores del equipo y el esfuerzo de desarrollo.
Razones para elegir COCOMO:
- Está bien documentado, es de dominio público y cuenta con herramientas de apoyo.
- Ha sido ampliamente utilizado y evaluado.
- Tiene una larga trayectoria, desde su primera versión hasta COCOMO 2.