Por supuesto, el software no se desgasta, pero hace unas décadas se creía que, tarde en el mantenimiento del código de ciclo de vida de la aplicación presenta más errores de los que corrige.¿La curva de bañera se aplica al software moderno?
Pero sí se aplica la curva de la bañera al software moderna desarrollado con modernos métodos de ingeniería de software?
La respuesta breve es "sí". La respuesta larga es que la distribución de la bañera no es un modelo muy bueno, debido a la falta de continuidad en el funcionamiento de las fallas. Digamos, por ejemplo, que un valor de entrada de 42 causa un error de división por cero; entonces la distribución de esas fallas será exactamente la distribución de 42 valores en la entrada. No es como el hardware, como dices: el software no falla con el tiempo, falla cuando está mal.
Ahora, puede ser que está mal uso de las palabras aquí: usted mi decir un defecto lugar de un fracaso. Una falla es una ocurrencia de comportamiento incorrecto; un defecto es un defecto en la implementación, un "error". El aspecto de los defectos en el software tiende a tener una distribución parecida a la bañera, pero realmente no es tan limpio como su imagen: los errores tienden a observarse temprano y disminuyen, luego aumentan los parches y los nuevos lanzamientos. , con una tendencia general al alza que comienza más adelante en la vida del software. Sin embargo, incluso eso toma una definición cuidadosa, ya que realmente está hablando de los defectos observados por unidad de tiempo.
Ahora, una vez dicho esto, las prácticas modernas de SE tienden a cambiar las tasas reales, pero no la distribución de los defectos observados en el tiempo. "Moderno" aquí también vale una pequeña definición: el software Space Shuttle HAL tiene muy bajas tasas de defectos, utilizando técnicas SE que eran "modernas" hace 20 años: especificación fuerte, programación estructurada, revisión rigurosa y control y pruebas de la versión OCD. La Programación Extrema tiende a tener bajas tasas de "defectos", pero muchas de las cosas que los métodos más tradicionales llamarían "defectos" llamadas XP "entrada del usuario" - ya que no hay definición finita y rigurosa de lo que debería hacer, un "defecto" es solo otra historia.
Ha habido estudios decentes para demostrar que XP/TDD da como resultado bajas tasas de defectos, pero me sorprendería mucho si la distribución de defectos/unidad de tiempo tiene una forma diferente.
No realmente, la mayoría de los errores se encuentran durante la implementación inicial del software. Después de eso, suele ser un conjunto gradual de errores, en su mayoría causados por modificaciones en el código o la adición de nuevas características. Nada como el lanzamiento del código inicial. A medida que los desarrolladores que hicieron que el producto original muriera y las actualizaciones cesen, también los errores se detienen.
Creo que hay una verdad (pequeña) en el gráfico. Después de la primera versión o dos, estás presentando nuevas funcionalidades y nuevos errores junto con las correcciones de errores de errores anteriores, por lo que creo que tienes un flujo constante de nuevos errores. Pero después de un tiempo, la base de código se vuelve frágil y difícil de mantener, por lo que creo que el flujo de nuevos errores aumenta bruscamente. Es entonces cuando finalmente (con suerte) puedes convencer a tus jefes para que dejen de parchear y comiencen a reingeniería.
La curva de la bañera es realmente un descriptor de fallas de hardware (y una buena, en eso) no de software.
Sin embargo, sucede algo similar con el software.En términos generales, en la mayoría de la producción de software, nuestra capacidad para crear complejidad ha seguido superando ligeramente nuestra capacidad para manejarla --- i.o.w. hay algún tipo de director Peter en el trabajo donde los sistemas de software (colectivamente) crecen en complejidad hasta que se vuelven inmanejables, y luego permanecen allí. Entonces, aunque hoy en día somos mucho mejores en el manejo de algunos de los problemas sistémicos de la década de 1990 que en aquellos tiempos, no somos mucho mejores en el manejo de los problemas sistémicos de los 00. Así es la vida.
No creo que esto se vea como una bañera, sin embargo.
Creo que mucho depende de qué tan bien se mantenga. Tengo una aplicación de GUI grande en la que prácticamente soy el único programador que la mantiene, y su frecuencia de defectos ha disminuido constantemente a lo largo de los años, y no anticipo que suba en ningún momento en el futuro.
Sin embargo, si hubiera dejado que un programador junior lo mantuviera, no me sentiría de la misma manera, ya que hay una gran tentación para un programador de mantenimiento de codificar una solución "suficientemente buena" y no la solución "correcta". No puedo culparlo por completo, probablemente no tenga el conocimiento del código que el programador original hizo.
Respecto al lado derecho de la bañera, si considera factores externos, como los sistemas operativos, puede haber cierta correlación, ya que he tenido algunas aplicaciones que rompieron versiones más recientes de Windows, generalmente sin culpa del aplicación Pero este es un número relativamente pequeño.
Brilliant response! –