¿La metodología de prueba de software se basa en datos defectuosos?

Es un hecho bien conocido en la ingeniería de software que el costo de corregir un error aumenta exponencialmente cuanto más tarde en el desarrollo se descubre ese error. Esto está respaldado por datos publicados en Code Complete y adaptados en muchas otras publicaciones.

Sin embargo, resulta que estos datos nunca existieron . Los datos citados por Code Complete aparentemente no muestran dicha correlación de costo / tiempo de desarrollo, y tablas publicadas similares solo mostraron la correlación en algunos casos especiales y una curva plana en otros (es decir, sin aumento en el costo).

¿Hay datos independientes para corroborar o refutar esto?

Y si es cierto (es decir, si simplemente no hay datos para respaldar este costo exponencialmente más alto para los errores descubiertos más tarde), ¿cómo afecta esto a la metodología de desarrollo de software?

¿La metodología de prueba de software se basa en datos defectuosos?

Si, demostrablemente. El examen de la curva de costo de cambio ágil muestra que parte del trabajo de Kent Beck en XP (no estoy seguro de si fue parte de su motivación o su justificación) fue "aplanar la curva" de los costos de defectos, en base al conocimiento del " "exponencial" que se encuentra detrás de la tabla de Código Completo. Entonces, sí, trabajar en al menos una metodología, la que hizo más para popularizar el desarrollo de prueba primero, se basa al menos en parte en datos defectuosos.

¿Hay datos independientes para corroborar o refutar esto?

Sí, ciertamente hay otros datos que puede consultar: el estudio más grande que conozco es el análisis de defectos realizado en Hughes Aircraft como parte de su programa de evaluación CMM . El informe de allí muestra cómo los costos de defectos dependían de la fase para ellos : aunque los datos en ese informe no incluyen variaciones, por lo que debe tener cuidado de sacar demasiadas conclusiones de "esto cuesta más que eso". También debe notar que, independientemente de la metodología, ha habido cambios en las herramientas y técnicas entre la década de 1980 y hoy que cuestionan la relevancia de estos datos.

Entonces, suponiendo que todavía tengamos un problema para justificar estos números:

¿Cómo afecta esto a la metodología de desarrollo de software?

El hecho de que hayamos estado confiando en números que no pueden verificarse no impidió que la gente progresara en base a anécdotas y experiencia: de la misma manera que se aprenden muchos oficios de aprendices maestros. No creo que haya habido un Journal of Evidence-Based Masonry durante la Edad Media, pero se construyeron un montón de edificios grandes, impresionantes y duraderos con cierto éxito. Lo que significa es que basamos principalmente nuestra práctica en "lo que funcionó para mí o las personas que he conocido"; No está mal, pero quizás no sea la forma más eficiente de mejorar un campo de millones de personas que proporcionan la piedra angular de la era tecnológica actual.

Me parece decepcionante que en una llamada disciplina de ingeniería no tenga una mejor base en el empirismo, y sospecho (aunque claramente no puedo probar) que podríamos lograr un progreso mejor y más claro en mejorar nuestras técnicas y metodologías. esa base en su lugar, al igual que la medicina clínica parece haber sido transformada por la práctica basada en la evidencia. Sin embargo, eso se basa en algunos supuestos importantes:

• que la naturaleza patentada de la mayoría de las prácticas de ingeniería de software no impide que se recopilen suficientes datos útiles y relevantes;
• que las conclusiones extraídas de estos datos son generalmente aplicables (debido a que la ingeniería de software es una profesión calificada, las variaciones personales en experiencia, habilidad y gusto podrían afectar dicha aplicabilidad);
• que los ingenieros de software "en el campo" son capaces y motivados para hacer uso de los resultados así obtenidos; y
• que realmente sabemos qué preguntas se supone que debemos hacer en primer lugar. Obviamente, este es el punto más importante aquí: cuando hablamos de mejorar la ingeniería de software, ¿qué es lo que queremos mejorar? ¿Cuál es la medida? ¿Mejorar esa medida realmente mejora el resultado, o juega con el sistema? Como ejemplo, supongamos que la gerencia de mi empresa decidió que íbamos a disminuir la relación entre el costo real del proyecto y el costo previsto del proyecto. Simplemente podría comenzar a multiplicar todas mis estimaciones de costos por un factor fudge y alcanzaría ese "objetivo". ¿Debería convertirse en una práctica estándar de la industria eludir todas las estimaciones?

Por mi parte, la respuesta a "cómo afecta esto a la metodología de desarrollo de software" es "no mucho".

Ya sea que sea detectado por el desarrollador o el usuario final, ya sea que se necesite más dinero para solucionarlo después de que el usuario lo haya detectado o no, el hecho es que se ha encontrado un error en el sistema. Si el desarrollador lo detecta , es de esperar que sea una solución rápida. La misma esperanza se mantiene para los errores detectados por el usuario.

Independientemente del costo real de la hora del desarrollador para corregir un error detectado por un usuario final, existe el costo intangible de mantener el estereotipo que los codificadores apestan en lo que hacen. Cuando un usuario encuentra un error, es culpa del desarrollador. Por lo tanto, cada error que encuentra el usuario final reduce la confianza del usuario en el sistema. Es como recorrer una casa que desea comprar y ver una mancha de agua que se ve a través del techo en una esquina de la casa. Eso, en sí mismo, es una solución fácil, pero uno se pregunta qué lo causó y qué otra causa podría haber afectado esa causa raíz. ¿Cuánto vale tu tranquilidad? Es posible que tenga que derribar las paredes hacia los postes e inspeccionar visualmente todo para asegurarse de que la mancha fue de un incidente aislado que se ha solucionado. Saber que podría ser una posibilidad no te hace tener mucha confianza en el hogar. Similar,

Estos costos intangibles se evitan cuanto antes se detecta el error, que es el propósito declarado de las metodologías de estilo TDD. Un error detectado durante la escritura por el desarrollador o socio en un par, uno detectado en el momento de la compilación o uno detectado por las pruebas de unidad / integración (la capa agregada por TDD), es un error que el usuario nunca tiene que saber, que su el gerente de proyecto nunca tiene que disculparse, y que no tiene que retirarse de lo que sea que esté haciendo en este momento para cambiar de marcha a modo de corrección de defectos en una parte del sistema que pensó que había dejado atrás semanas hace.

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.

Es simplemente lógica simple.

Error detectado en espec.

Case : Error found while reviewing UseCase/Function spec.
Actions:
        Rewrite paragraph in error.

Case : Error found during unit test.
Actions:
        Fix code.
        (Possibly) rewrite paragraph in spec.
        rerun unit test.

Case : Error found in integration test.
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.

Case : Error found in UAT
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        build new release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.


Case : Error found in production
        Fix code.
        (possibly) rewrite paragraph in spec.
        rerun unit test.
        Build release.
        rerun integration test for whole system.
        deploy release to UAT.
        rerun UAT tests.
        deploy release to production.

Como puede ver, cuanto más tarde se detecta el error, mientras más personas están involucradas, más trabajo tiene que rehacerse y en cualquier entorno "normal", el papeleo y la burocracia aumentan exponencialmente una vez que llega a UAT.

Todo esto sin incluir los costos en los que podría incurrir una empresa debido a un error en el software de producción (pérdida de ventas, pedidos excesivos, pirateo de clientes, etc.)

No creo que nadie haya logrado escribir un sistema no trivial que nunca haya tenido errores en la producción, pero cualquier cosa que pueda hacer para detectarlos temprano le ahorrará tiempo y esfuerzo a largo plazo. Las revisiones de especificaciones, revisiones de códigos, pruebas unitarias extensas, el uso de diferentes codificadores para escribir las pruebas, etc., etc., son métodos probados para detectar errores de manera temprana.

Creo que esto es, y siempre ha sido, sobre gestión de riesgos y economía. ¿Cuál es el costo de reducir el número de defectos frente al valor presente del impacto de defectos futuros? La trayectoria del pájaro amarillo estando ligeramente apagada en Angry Birds no equivale a la trayectoria de un misil de crucero Tomahawk apagado. Los desarrolladores de software en cualquiera de los proyectos no pueden tomar decisiones basadas en esa tabla. En este sentido, nada cambia.

La forma en que creo que esto tiende a funcionar es a través de la retroalimentación, los errores costosos en el campo hacen que las empresas endurezcan sus procesos de calidad, mientras que ninguna queja del campo hace que las empresas lo relajen. Entonces, con el tiempo, las empresas de desarrollo de software tenderán a converger u oscilar en torno a algo que les funcione (+/-). Code Complete puede influir en algunos valores iniciales o puede atraer a las empresas ligeramente de una forma u otra. Una empresa que gasta demasiado esfuerzo en eliminar defectos que nadie notaría probablemente va a perder negocios con un competidor que tiene un enfoque más optimizado. Por otro lado, una empresa que lanza productos con errores también se cerrará.

Algunos documentos relevantes de una búsqueda rápida (lea los documentos completos, investigue más y forme su propia opinión):

Una revisión bibliográfica sistemática de la investigación de costos de calidad de software (2011)

"Si bien la comunidad ha desarrollado una sólida comprensión de la estructura del dominio de investigación, a menudo falta la validación empírica. Solo alrededor de un tercio de los artículos analizados presenta un estudio de caso o resultados empíricos más extensos. Esto parece ser insuficiente para la investigación de costos de calidad de software , que depende en gran medida de los datos cuantitativos para generar nuevos hallazgos. Por lo tanto, se necesitan enfoques novedosos para recopilar datos de costos de calidad, así como una mayor cooperación entre la industria y la investigación para poner a disposición dichos datos ".

Evaluación del costo de la calidad del software (1998)

"Finalmente, hemos visto que es importante monitorear los costos de conformidad y no conformidad del software para que las políticas de conformidad se puedan ajustar para reducir los costos totales de la calidad del software".

El comportamiento del costo de los defectos de software (2004)

Resumen ... "La investigación actual intenta actualizar nuestro conocimiento sobre la forma en que los defectos y el costo de corregirlos (o, alternativamente, dejarlos sin corregir) influyen en el costo final del software" ... "los defectos no corregidos se vuelven exponencialmente más costosos con cada fase en la que están sin resolver "

Prueba de cobertura y defectos posteriores a la verificación: un estudio de caso múltiple (2009)

"También encontramos que el esfuerzo de la prueba aumenta exponencialmente con la cobertura de la prueba, pero la reducción de los problemas de campo aumenta linealmente con la cobertura de la prueba. Esto sugiere que para la mayoría de los proyectos los niveles óptimos de cobertura probablemente sean muy inferiores al 100%".

Cerrar la brecha entre el proceso de prueba de software y el valor comercial: un estudio de caso (2009)

No puedo responder a su primera parte de la pregunta, ya que simplemente no lo he verificado. Pero puedo formular una respuesta a su segunda pregunta, y quizás insinuar una posible respuesta a la primera.

No hace falta decir que algunos de los factores más importantes en el costo de corregir un error, salvo las herramientas de desarrollo intrínsecamente difíciles de usar, son la complejidad intrínseca del producto y qué tan bien el usuario puede entender ese producto.

Centrándonos por un segundo en el código, bajo el supuesto de que el código es típicamente escrito y mantenido por desarrolladores capaces de lidiar con las complejidades intrínsecas de su código (que puede no ser del todo cierto y merecer su propio debate), me atrevería a sugerir que La importancia crítica en el mantenimiento y, por lo tanto, en la corrección de errores, es la capacidad de los encargados de comprender dicho código.

La capacidad de comprender el código se mejora en gran medida mediante el uso de herramientas de ingeniería de software comprobadas que, desafortunadamente, se utilizan en su mayoría de manera inadecuada o inadecuada. Usar el nivel correcto de abstracción, modularidad, mejorar la cohesión del módulo y reducir el acoplamiento del módulo son herramientas críticas para hacer frente a la complejidad que necesitan un uso adecuado. La codificación de interfaces o, en OOP, evitar el uso excesivo de la herencia sobre la composición, el empaquetamiento por características, son algunas de las técnicas que a menudo reciben una atención insuficiente en la codificación.

Creo que las realidades de la competencia en la industria ejercen una fuerza negativa sobre el empleo de métodos de mejora de la calidad para desarrollar software, manteniendo baja la calidad intrínseca del software como una medida del éxito continuo.

En consecuencia, creo que, en la industria, el software tiende a sufrir más los costos de corrección de errores a medida que crece. En tales productos, los errores se vuelven más difíciles de corregir con el tiempo porque el sistema se vuelve más difícil de entender a medida que crece. Las inquietudes introducidas por cada característica están demasiado asociadas con otras inquietudes, lo que dificulta la comprensión. O bien, no se empleó el nivel correcto de abstracción, lo que dificulta al encargado de formular un modelo adecuado del sistema y razonar sobre él. La falta de documentación ciertamente no ayuda.

Hay excepciones. Estoy seguro de que Google no funciona a su ritmo sin algunas prácticas sólidas respaldadas por desarrolladores estelares. Y es probable que otros estén en la misma situación. Sin embargo, para la mayoría del software, no me sorprendería si los datos lo hizo , de hecho, confirman la afirmación de código completo .

Otra respuesta! Esta vez para abordar la pregunta del título "¿La morhtodoligía del software se basa en datos defectuosos".

La respuesta real es "no hay datos". Como no hay un gran cuerpo de datos confiable sobre proyectos de software, hay defectos, éxitos, tiempo de comercialización, etc.

Todos los intentos de recopilar dichos datos han sido insuficientemente financiados, estadísticamente defectuosos o tan específicos para un proyecto en particular que no es posible derivar conclusiones generales.

Además, no creo que lo haya, el proceso de desarrollo de software es demasiado subjetivo y resbaladizo para una medición estricta. Las organizaciones mejor ubicadas para recopilar dichos datos (las grandes casas de software e integradores de sistemas) saben en su corazón que cualquier cifra obtenida de su desempeño sería profundamente vergonzosa.

Las únicas organizaciones que publican números sobre el costo y el éxito de los proyectos de software
son los departamentos gubernamentales y, solo entonces, porque tienen que hacerlo, y sí, estos números son profundamente vergonzosos, sin importar cuánto den masajes a las cifras.

En conclusión, todos los estudios de software son necesariamente puramente subjetivos porque no hay datos reales en los que basar una conclusión objetiva.