Voy a presentar esto con el hecho de que la mayor parte de lo que encuentro proviene de los años setenta y principios de los ochenta. Durante este tiempo, los modelos de procesos secuenciales fueron mucho más comunes que los enfoques iterativos y / o incrementales (el modelo en espiral o los métodos ágiles). Gran parte de este trabajo se basa en estos modelos secuenciales. Sin embargo, no creo que eso destruya la relación, pero uno de los beneficios de los enfoques iterativos / incrementales es liberar características (una porción vertical completa de una aplicación) rápidamente y corregir los problemas antes de que se inyecten las dependencias y la complejidad de cada fase. es alto.
Acabo de sacar mi copia de Software Engineering Economics y encontré una referencia a los datos detrás de este cuadro en el Capítulo 4. Cita "Inspecciones de diseño y código para reducir errores en el desarrollo del programa" por ME Fagan ( IEEE , PDF de UMD ), EB "Gestión de la ingeniería de software" de Daly, "Un análisis de los recursos utilizados en el desarrollo de software del sistema de salvaguardia" ( ACM ) de WE Stephenson y "varios proyectos de TRW".
... el costo relativo de corregir errores de software (o realizar otros cambios de software) en función de la fase en la que se realizan las correcciones o cambios. Si se detecta y corrige un error de requisitos de software durante la fase de planes y requisitos, su corrección es una cuestión relativamente simple de actualizar la especificación de requisitos. Si el mismo error no se corrige hasta la fase de mantenimiento, la corrección implica un inventario mucho mayor de especificaciones, códigos, manuales de usuario y mantenimiento, y material de capacitación.
Además, las correcciones tardías implican un proceso de aprobación y control de cambios mucho más formal, y una actividad mucho más extensa para revalidar la corrección. Estos factores se combinan para hacer que el error sea generalmente 100 veces más costoso de corregir en la fase de mantenimiento en proyectos grandes que en la fase de requisitos.
Bohem también analizó dos proyectos más pequeños y menos formales y encontró un aumento en el costo, pero mucho menos significativo que las 100 veces identificadas en los proyectos más grandes. Dado el cuadro, las diferencias parecen ser 4 veces mayores para corregir un defecto de requisitos después de que el sistema está operativo que en la fase de requisitos. Él atribuyó esto al menor inventario de artículos que componen el proyecto y a la menor formalidad que condujo a la capacidad de implementar arreglos más simples y rápidos.
Basado en Boehm en Software Engineering Economics, la tabla en Code Complete es bastante hinchada (el extremo inferior de los rangos a menudo es demasiado alto). El costo para realizar cualquier cambio dentro de la fase es de hecho 1. Extrapolando de la Figura 4-2 en Economía de Ingeniería de Software, un cambio de requisitos debe ser 1.5-2.5 veces en arquitectura, 2.5-10 en codificación, 4-20 en pruebas y 4- 100 en mantenimiento. La cantidad depende del tamaño y la complejidad del proyecto, así como de la formalidad del proceso utilizado.
En el Apéndice E de Barry Boehm y Richard Turner, Balancing Agility and Discipline contiene una pequeña sección sobre los hallazgos empíricos sobre el costo del cambio.
Los párrafos iniciales citan la Programación extrema explicada de Kent Beck, citando a Beck. Dice que si el costo de los cambios aumentara lentamente con el tiempo, las decisiones se tomarían lo más tarde posible y solo se implementaría lo que fuera necesario. Esto se conoce como la "curva plana" y es lo que impulsa la Programación Extrema. Sin embargo, lo que la literatura anterior encontró fue la "curva empinada", con sistemas pequeños (<5 KSLOC) con un cambio de 5: 1 y sistemas grandes con un cambio de 100: 1.
La sección cita el Centro de Ingeniería de Software con Base Empírica de la Universidad de Maryland (patrocinado por la National Science Foundation). Realizaron una búsqueda en la literatura disponible y descubrieron que los resultados tendían a confirmar una relación de 100: 1, y algunos resultados indicaban un rango de 70: 1 a 125: 1. Desafortunadamente, estos fueron típicamente proyectos de "gran diseño por adelantado" y se gestionaron de manera secuencial.
Hay ejemplos de "pequeños proyectos comerciales de Java" ejecutados usando Extreme Programming. Para cada historia, se realizó un seguimiento de la cantidad de esfuerzo en la corrección de errores, el nuevo diseño y la refactorización. Los datos muestran que a medida que se desarrolla el sistema (se implementan más historias de usuarios), el esfuerzo promedio tiende a aumentar en una tasa no trivial. El esfuerzo en la refactorización aumenta aproximadamente un 5% y los esfuerzos para corregirlo aumentan aproximadamente un 4%.
Lo que estoy aprendiendo es que la complejidad del sistema juega un gran papel en la cantidad de esfuerzo necesario. Al construir cortes verticales a través del sistema, disminuye la velocidad de la curva agregando lentamente complejidad en lugar de agregarla en pilas. En lugar de lidiar con la gran cantidad de complejidad de los requisitos, seguida de una arquitectura extremadamente compleja, seguida de una implementación extremadamente compleja, y así sucesivamente, comienza de manera muy simple y agrega.
¿Qué impacto tiene esto en el costo de arreglar? Al final, tal vez no mucho. Sin embargo, tiene las ventajas de permitir un mayor control sobre la complejidad (a través de la gestión de la deuda técnica). Además, los entregables frecuentes a menudo asociados con el ágil significan que el proyecto podría terminar antes, en lugar de entregar "el sistema", las piezas se entregan hasta que se satisfacen las necesidades del negocio o se ha cambiado drásticamente que un nuevo sistema (y, por lo tanto, un nuevo proyecto) es necesario
Las métricas y modelos de Stephen Kan en Ingeniería de calidad de software tienen una sección en el Capítulo 6 sobre la rentabilidad de la eliminación de defectos de fase.
Comienza citando el artículo de 1976 de Fagan (también citado en Software Engineering Economics) para afirmar que la reelaboración realizada en diseño de alto nivel (arquitectura de sistema), diseño de bajo nivel (diseño detallado) e implementación puede ser entre 10 y 100 veces menos costosa que el trabajo realizado durante las pruebas a nivel de componentes y sistemas.
También cita dos publicaciones, de 1982 y 1984, de Freedman y Weinberg que tratan sobre sistemas grandes. El primero es "Manual de tutoriales, inspecciones y revisiones técnicas" y el segundo es "Revisiones, recorridos e inspecciones". La aplicación de revisiones al inicio del ciclo de desarrollo puede reducir la cantidad de errores que alcanzan las fases de prueba en un factor de 10. Esta reducción en la cantidad de defectos conduce a una reducción de los costos de prueba en un 50% a 80%. Tendría que leer los estudios con más detalle, pero parece que el costo también incluye encontrar y corregir los defectos.
Un estudio de 1983 realizado por Remus, "Validación de software integrada en la vista de inspecciones / revisión", estudió el costo de eliminar defectos en diferentes fases, específicamente inspecciones de diseño / código, pruebas y mantenimiento, utilizando datos del Laboratorio Santa Teresa de IBM en California. Los resultados citados indican una relación de costo de 1:20:82. Es decir, un defecto encontrado en las inspecciones de diseño o código tiene un costo de cambio de 1. Si el mismo defecto escapa a la prueba, costará 20 veces más. Si se escapa por completo a un usuario, multiplicará el costo de corrección hasta en 82. Kan, utilizando datos de muestra de la instalación Minnessota de Rochester de IBM, descubrió que el costo de eliminación de defectos para el proyecto AS / 400 es similar a las 1:13:92. Sin embargo, señala que el aumento en el costo podría deberse a la mayor dificultad para encontrar un defecto.
Las publicaciones de Gilb de 1993 ( "Inspección de software" ) y 1999 ("Optimización de la especificación de ingeniería de software y procesos de control de calidad") sobre inspección de software se mencionan para corroborar los otros estudios.
Se puede encontrar información adicional en la página de Construx sobre Aumento del costo de defectos , que proporciona una serie de referencias sobre el aumento del costo de reparación de defectos. Cabe señalar que Steve McConnell, autor de Code Complete, fundó y trabaja para Construx.
Recientemente escuché una charla, Real Software Engineering , impartida por Glenn Vanderburg en Lone Star Ruby Conference en 2010. Ha dado la misma charla en Scottish Ruby Conference y Erubycon en 2011, QCon San Francisco en 2012 y O'Reilly Software Architecture Conference en el año 2015 . Solo he escuchado la Conferencia Lone Star Ruby, pero la charla ha evolucionado con el tiempo a medida que sus ideas fueron refinadas.
Venderburg sugiere que todos estos datos históricos realmente muestran el costo de reparar defectos a medida que pasa el tiempo, no necesariamente a medida que un proyecto avanza por fases. Muchos de los proyectos examinados en los documentos y libros mencionados anteriormente fueron proyectos secuenciales "en cascada", donde la fase y el tiempo se movieron juntos. Sin embargo, surgiría un patrón similar en proyectos iterativos e incrementales: si se inyectara un defecto en una iteración, sería relativamente económico solucionarlo en esa iteración. Sin embargo, a medida que avanzan las iteraciones, suceden muchas cosas: el software se vuelve más complejo, la gente olvida algunos de los detalles menores sobre el trabajo en módulos particulares o partes del código, los requisitos cambian. Todo esto aumentará el costo de arreglar el defecto.
Creo que esto probablemente esté más cerca de la realidad. En un proyecto en cascada, el costo aumenta debido a la cantidad de artefactos que deben corregirse debido a un problema aguas arriba. En proyectos iterativos e incrementales, el costo aumenta debido a un aumento en la complejidad del software.