Todos aspiramos a que nuestros proyectos de software se entreguen a tiempo y dentro del presupuesto*. El software es complejo y, a menos que planeemos el éxito, es poco probable que “simplemente suceda”. A la hora de planificar proyectos de software, afortunadamente contamos con la experiencia de fracasos pasados de los que podemos aprender. Deberíamos aprovechar las enseñanzas de estos errores para que nuestros proyectos puedan evitar la ruta “patológica”.
¿Qué entendemos por retraso en un proyecto? El retraso se refiere en realidad a que un proyecto se entrega tarde en relación con las expectativas o, en otras palabras, tarde frente a la estimación. Para evitar decepciones, debemos crear expectativas realistas (estimaciones) Y debemos realizar las actividades para evitar problemas que podrían llevar a que las estimaciones no se cumplan.
En un estudio de 84 proyectos de IBM y AT&T, Capers Jones observó que los proyectos que se retrasaban seis meses o más mostraban poca evidencia de estar en problemas en las primeras etapas. Los últimos proyectos habían escatimado en muchas actividades cruciales, en particular: revisiones de requisitos, inspecciones y control de calidad. Todo lo cual tiene que ver con la atención temprana a la calidad.
¿Por qué se estimaron incorrectamente? O la estimación fue inapropiada o las actividades que podrían haberlo mantenido a tiempo no se realizaron bien.
Capers cita 10 factores que conducen a un desajuste entre estimación y real:
*Algunas partes se benefician de los cargos extra que se generan cuando se extiende un proyecto.
Cómo puede ayudar la IA
La planificación comienza temprano, a medida que conoce o descubre los requisitos. ScopeMaster utiliza IA para ayudarle a comprender los requisitos muy rápidamente. Lo que lleva a mejores planes.
Factores que afectan el cronograma del software y estimar la confiabilidad
| Factor | Descripción | Impacto del cronograma | Mitigación |  |
|---|---|---|---|---|
Errores de métricas |
El uso de métricas inapropiadas, como puntos de historia o similares, generará estimaciones deficientes. | Hasta 100% | Utilice tamaño funcional, puntos de función COSMIC | ScopeMaster automatiza el dimensionamiento funcional y elimina la mayoría de estos errores. |
Ajuste tecnológico |
Incertidumbre/retraso causado al introducir nuevas herramientas/tecnologías/técnicas | El impacto observado puede provocar errores de estimación de hasta 150% | Espere al menos un mes para que la nueva tecnología se integre en uso, planifique para ello | |
Errores de ruta crítica |
La ilusión de que el progreso va por buen camino hasta que el proyecto se detiene por un evento de bloqueo. | Error en horarios de hasta 25% | Un mejor seguimiento de las rutas críticas y una mitigación proactiva de los riesgos técnicos pueden minimizarlos. | ScopeMaster fomenta el pensamiento temprano sobre las complejidades y las integraciones, que son causas comunes de los problemas de CP. |
Problemas de tamaño/alcance |
Subestimar mal la verdadera magnitud de un proyecto conducirá a un aumento del trabajo y del cronograma. La calidad y la integridad de los requisitos también influyen en la capacidad de dimensionar correctamente | Error 15-100% | El dimensionamiento funcional y la verificación automatizada de la integridad ayudarán a mitigar esto. | Resuelto por ScopeMaster (incluso para directores de proyectos sin experiencia). |
Requisitos de usuario progresivos |
Los requisitos cambiantes (a diferencia de los requisitos faltantes) conducirán a un aumento en el trabajo y el cronograma. | Las tasas de error son mayores en proyectos más largos: 2-10% por mes | Esto debe planificarse y adoptarse (ágil). | ScopeMaster ayuda de varias maneras: mejorando la calidad de los requisitos iniciales, una mejor obtención y seguimiento de la volatilidad. |
Errores de asignación |
No asignar el personal adecuado a una actividad dentro de un proyecto. Cada persona que desempeña un rol determinado tiene una capacidad finita para realizar un trabajo y debe ser asignada en el momento adecuado del proyecto. | Error hasta 100% | Gerentes competentes que entienden las capacidades de asignación (ver más abajo). | ScopeMaster ayuda proporcionando un tamaño funcional a partir del cual se pueden determinar los alcances de las asignaciones. |
Errores de tasa de producción |
La diferencia entre la tasa de producción esperada y real. | 20-100% | Unas medidas de tasa de producción realistas y apropiadas ayudarán, por ejemplo. CFP/mes para un equipo determinado. | ScopeMaster ayuda proporcionando un tamaño funcional desde el cual se pueden medir, comparar y monitorear las tasas de producción. |
Aumento del personal |
No desplegar la cantidad adecuada de personal con las habilidades adecuadas en el momento adecuado provocará retrasos. | Es probable que tenga un impacto en semanas o incluso meses. | Los administradores competentes deben planificar adecuadamente. | ScopeMaster ayuda proporcionando un tamaño funcional a partir del cual se pueden determinar la asignación y los alcances. |
Selección de tareas |
No considerar todas las actividades del proyecto, no solo la codificación, provocará errores de programación. | Observado hasta 1000% | Los administradores competentes deben planificar todas las actividades de manera adecuada. | |
Interferencia ejecutiva o política |
Los ejecutivos decretan plazos u otras limitaciones inapropiadas que conducen a una mala calidad. | Error hasta 50% para programación, 100% para costos | Los administradores competentes deberían rechazar con firmeza esa interferencia. | ScopeMaster crea estimaciones de tamaño funcional a partir de las cuales se pueden determinar cronogramas realistas y utilizarlos como defensa. |
Planificación basada en actividades basado en el tamaño funcional
Planificación de proyectos de software
El factor más crítico para determinar la duración de un proyecto es su tamaño. Por tamaño nos referimos al tamaño funcional. El tamaño funcional es el medio más confiable para dimensionar un proyecto de software. A diferencia de los puntos de la historia (que son una estimación del esfuerzo indirecta, subjetiva y no lineal), el tamaño funcional es generalmente consistente, dentro de unos pocos %, independientemente de quién lo dimensione.
Para determinar qué parte de cada actividad es apropiada en nuestro proyecto, necesitamos comprender tanto el alcance de la asignación (cuánta capacidad puede manejar un individuo) y su tasa de producción (cuánta capacidad pueden abordar en un período de tiempo determinado). Estos se muestran en la siguiente tabla según el tamaño funcional del software en el que se está trabajando en los puntos de función.
Existen dos estándares principales para el tamaño funcional: puntos de función tradicionales (IFPUG) y puntos de función COSMIC. Recomendamos este último principalmente porque trata muy bien los requisitos incompletos, no es necesario conocer todos los requisitos para dimensionar una pieza de software (lo que generalmente se hace con IFPUG).
Asignaciones de actividades y productividad media
Para la planificación basada en actividades
No todas estas actividades son necesarias en todos los proyectos. Como guía, cuanto más grande sea el proyecto, más necesitarás realizar.
| Actividad | Alcance de la asignación de personal, FP | Producción mensual, FP |
|---|---|---|
Requisitos |
333 | 175 |
Creación de prototipos |
500 | 150 |
Arquitectura |
1000 | 300 |
Planes de proyecto |
1000 | 500 |
Diseño inicial |
250 | 175 |
Diseño de detalle |
250 | 150 |
Revisiones de diseño |
200 | 225 |
Codificación |
175 | 50 |
Adquisición de reutilización |
500 | 600 |
Compra de paquete |
2000 | 400 |
Inspecciones de código |
150 | 150 |
Verificación y validación independientes |
500 | 125 |
Gestión de configuración |
1000 | 175 |
Integración |
1000 | 250 |
Documentación del usuario |
1000 | 70 |
Examen de la unidad |
200 | 150 |
Pruebas funcionales |
200 | 150 |
Pruebas de integración |
250 | 175 |
Pruebas del sistema |
250 | 200 |
Pruebas de campo (beta) |
1000 | 250 |
Test de aceptación |
1000 | 350 |
Pruebas independientes |
750 | 200 |
Seguro de calidad |
1000 | 150 |
Instalación y capacitación |
2000 | 350 |
Gestión de proyectos |
1000 | 100 |
No está disponible una tabla equivalente basada en la PPC; sin embargo, es razonable considerar que la FP y la PPC son aproximadamente equivalentes cuando se utilizan estos datos para la planificación basada en actividades.
Un enfoque basado en actividades es particularmente útil ya que nos ayuda a identificar el personal y las habilidades necesarias durante el proyecto. Herramientas como Análisis SRM® de Namcook SEER para software de Galorath, SLIM de QSM o Verdadera planificación al unísono (anteriormente Price Systems) puede ayudar aún más al proporcionar un perfil de personal adecuado para un proyecto determinado a lo largo del tiempo.
Esta es una versión condensada de la tabla 11.4 publicada en “Estimating Software Costs, second edition” de Capers Jones. Disponible para comprar en Amazon. Nb, esto es sólo una ilustración de las actividades y sus niveles de dotación de personal, tasas de productividad (costos implícitos). Descubrirá que vale la pena mantener sus propios puntos de referencia para estas actividades.
Estimación Temprana
Si busca ayuda para estimar el tamaño, la duración y la dotación de personal de un proyecto antes de conocer los requisitos, entonces una herramienta adecuada es Software Risk Manager (SRM) de Namcook Analytics. Utiliza datos históricos del proyecto y varios algoritmos para brindar estimaciones de tamaño, duración, dotación de personal y mucho más. SRM se puede encontrar en Namcook sitio web.
Conclusión
Las conclusiones clave de este artículo son:
- Es posible crear estimaciones realistas para proyectos de software. que sean razonablemente consistentes con lo que eventualmente suceda.
- El tamaño (tamaño funcional) es el factor más importante. afectando el esfuerzo y la duración. La fiabilidad de la estimación del tamaño depende de numerosos factores.
- Un enfoque basado en actividades basado en el tamaño funcional puede producir una estimación razonable del esfuerzo (y por lo tanto del costo).
- Conocer el esfuerzo y los índices de productividad típicos nos da una estimación razonable de la duración.
- Los proyectos muy grandes también se beneficiarán de una herramienta de planificación paramétrica que puede pronosticar el tamaño del equipo y las habilidades a lo largo del tiempo durante todo el proyecto.
