¿Cuándo es suficiente la frecuencia de errores en un sistema de producción para indicar que es necesario un cambio significativo en la práctica de ingeniería?

En breve:

El umbral de frecuencia de errores es diferente para cada cliente. Debe decidir en SU ​​caso qué es aceptable o no, y evaluar las diferentes alternativas. Tal vez el nuevo software tiene muchos menos errores, ¡pero su precio es mucho más alto porque se resuelven en un mes!

En mucho tiempo:

Seamos honestos, creo que el desarrollo de software es imposible sin errores. Podemos, con prácticas de ingeniería, tratar de minimizar su número (TDD, XP, etc.). O podemos intentar minimizar el costo asociado con los errores (Agile, suites de pruebas automatizadas, escribir pruebas de regresión con cada error resuelto, ALM, seguimiento de problemas, etc.).

Creo que 7 errores en un año, y resueltos especialmente en menos de 24 horas, son un precio aceptable en un producto no maduro. Pero esta es una opinión subjetiva, porque no sé qué requisitos específicos necesita en su organización. Pero si el riesgo de tomar una decisión incorrecta es demasiado alto, puede seguir un proceso de soporte de decisiones.

Analice sus requisitos específicos, incluidos los requisitos no funcionales como tolerancia a fallas, confiabilidad y robustez. Obviamente, los requisitos de tolerancia a fallas para una aplicación son diferentes en un sistema hospitalario o en un sistema de almacén. Identifique cuáles son los requisitos obligatorios y opcionales . ¡Incluso podría dar un valor comercial a los opcionales , si desea invertir el tiempo suficiente!

Tenga en cuenta, por supuesto, el precio de la aplicación que paga y su diferencia con el dinero que ahorra al usarla (¡supongo que ahorra más de lo que paga, de lo contrario no debería usarla!).
¿Puede traducir en costos las consecuencias de cada error que haya encontrado?
Por ejemplo, $ / hora de trabajo que sus empleados tuvieron que trabajar, costo
de las facturas retrasadas, etc. Solo tiene que agregar estos costos al precio total y volver a calcular el dinero ahorrado. Ahora tiene el precio real del software que está utilizando. Al dividir el precio por la suma de los valores comerciales de los requisitos cumplidos, puede crear un punto de referencia para evaluar diferentes alternativas.

Repita el análisis de costos con el nuevo software y, violá, puede decidir mejor.

PD1: tal proceso, por supuesto, solo puede seguirse cuando el riesgo de decisión es lo suficientemente alto. La mayoría de las veces no necesitamos invertir tiempo y dinero en la toma de decisiones y simplemente decidimos basándonos en la intuición.

PD2: Esto es un poco orientado a la administración, además del factor de costo hay percepciones subjetivas que usted y sus empleados tienen sobre el software, y también debe considerarlo.

Por cierto, me gustaría saber si con el nuevo sistema tiene la misma reacción rápida que el sistema anterior, cuando encuentra un error.

Es en gran medida una decisión comercial. Si 7 errores tienen un impacto lo suficientemente grande en su negocio, entonces son demasiados. Si es lo suficientemente crítico, cree el número de errores en el SLA. O tenga medidas en el contrato para compensarlo cuando su negocio se vea afectado.

El software libre de errores es absolutamente posible. Solo necesita estar dispuesto a pagar por ello. ¿Cuántos errores de software puede tener un avión o el transbordador espacial?