Desarrollo de software cuesta pirámide [cerrada]

Question

Un amigo me decía el otro día que hay una pirámide de los costos de reparar un problema en el ciclo de vida del software de desarrollo. ¿Dónde podría encontrar esto?

Se refería al costo de la fijación de un problema.

Por ejemplo,

  

Para solucionar un problema en los requisitos de Costes de la etapa 1.

     

Para solucionar un problema en la etapa de desarrollo cuesta 10.

     

Para solucionar un problema en la etapa de prueba cuesta 100

     

Para solucionar un problema en la etapa de producción Los costos de 1000.

(Estos números son ejemplos sólo)

Yo estaría interesado en ver más sobre esto si alguien tiene referencias.

Answer 1

El increíble Tasa de rendimiento decreciente de corregir errores de software

(Stefan Priebsh: programación orientada a objetos y patrones de diseño: Codeworks DC en septiembre de 2009)

Answer 2

Este es un resultado muy conocido en la ingeniería de software empírica que se ha replicado y verificado una y otra vez en innumerables estudios. Lo cual es muy raro en la ingeniería de software, por desgracia: la mayoría de ingeniería de software "resultados" son básicamente rumores, anécdotas, conjeturas, opiniones, pensamiento ilusorio o sólo mentiras llanas. De hecho, la mayor parte de ingeniería de software, probablemente no merece la marca "ingeniería".

Por desgracia, a pesar de ser uno de los sonidos más sólida, más científicamente y estadísticamente, más ampliamente investigado, más ampliamente comprobados, resultados más a menudo replicados de ingeniería de software, también está mal.

El problema es que todos esos estudios no controlan adecuadamente sus variables. Si se desea medir el efecto de una variable, que tiene que ser muy cuidado al cambio solamente que un variable y que las otras variables don 't cambio en absoluto . No es "cambiar algunas variables", no "minimizar los cambios en otras variables". "Sólo uno" y los otros "en absoluto".

O, en las palabras brillantes de Zed Shaw:. Si se desea medir mierda, no miden la otra mierda

En este caso particular, lo hicieron no justa medida en la que la fase (requisitos, análisis, arquitectura, diseño, implementación, prueba, mantenimiento) se encontró el error, que también midieron la los se mantuvo en el sistema. Y resulta que la fase es prácticamente irrelevante, lo único que importa es el tiempo. Es importante que se encontraron errores rápido , no en qué fase.

Esto tiene algunas consecuencias interesantes: si es importante para encontrar errores rápido , entonces ¿por qué esperar tanto tiempo con la fase que es más probable encontrar errores: las pruebas? ¿Por qué no poner la prueba en el comenzando

El problema con la interpretación "tradicional" es que conduce a decisiones ineficientes. Debido a que se asume que necesita para encontrar todos los errores durante la fase de requisitos, arrastra a cabo la fase de requisitos innecesariamente largo: no se puede ejecutar requisitos (o arquitecturas, o diseños), por lo que búsqueda un error en algo que ni siquiera se puede ejecutar está volviendo loco duro ! Básicamente, mientras que fijar errores en la fase de requisitos es barato, encontrar ellos es caro.

Si, sin embargo, se da cuenta de que no se trata de encontrar los errores en la fase más temprana posible , sino más bien sobre la búsqueda de los insectos a la mayor brevedad posible , entonces puede realizar ajustes en su proceso, por lo que se mueve la fase en la que encontrar insectos es el más barato (pruebas) hasta el punto en el tiempo donde fijar ellos es más barato (el principio ).

---

Nota: Soy muy consciente de la ironía de poner fin a una diatriba acerca de no aplicar correctamente las estadísticas con una reclamación por completo de fundamento. Por desgracia, he perdido el enlace donde leí esto. Glenn Vanderburg también mencionó esto en su " Propiedades Ingeniería de Software " hablar en la Conferencia Lone Star Ruby 2010, pero AFAICR, que no citó ninguna fuente, ya sea.

Si alguien sabe de ninguna fuente, por favor que me haga saber o editar mi respuesta, o incluso sólo robo mi respuesta. (Si se puede encontrar una fuente, que se merece todo el representante!)

Answer 3

Vea las páginas 42 y 43 de este presentación (pdf).

Por desgracia, la situación es la que representa Jörg, de hecho algo peor: la mayor parte de las referencias citadas en esta huelga documento mí como falso, en el sentido de que el documento citado, o bien no es una investigación original, o no contiene palabras que sustentan el reclamo se están realizando, o - en el caso de la papel 1998 sobre Hughes (p54) - contiene mediciones que de hecho contradecir lo que está implícito en la curva de la p42 de la presentación: diferente forma de la curva, y una modesta x5 al factor de x10 de coste-a-fix entre la fase de requisitos y la fase de prueba funcional (y, de hecho disminuyendo en la prueba y mantenimiento del sistema).

Answer 4

Nunca oído hablar de él que se llama una pirámide antes, y que parece un poco al revés para mí! Sin embargo, la tesis central es ampliamente considerada como correcta. solo grueso de ello, los costes de la fijación de un error de alfa etapa son a menudo trivial. Por fase beta puede ser que tome un poco más de depuración y de usuario informes. Después de la expedición que podría ser muy costoso. una versión completamente nueva tiene que ser creado, usted tiene que preocuparse por romper el código y los datos de producción, también puede haber pérdida de ventas debido al error?

Answer 5

Probar artículo . Se utiliza el argumento de "costo de la pirámide" (sin nombrarlo), entre otros.