¿Existe alguna estadística o al menos algún consenso de la industria sobre cuáles son los niveles de calidad comúnmente aceptables para varios tipos de software?
Ciertamente no estoy hablando de transbordadores espaciales o máquinas de soporte vital donde la respuesta es más o menos obvia. Más bien, estoy hablando de cosas como juegos casuales, aplicaciones empresariales, sitios web de comercio electrónico, etc.
Nuevamente, es bastante obvio que incluso con este tipo de aplicaciones, los defectos que causan pérdida de dinero o consecuencias graves similares son inaceptables. Pero, ¿qué pasa con los bloqueos, el mal funcionamiento intermitente y los defectos que tienen una solución incómoda, pero aún así?
Tenga paciencia conmigo aquí, ya que he visto una serie de aplicaciones internas que son lentas, con errores, feas como el infierno, pero que, sin embargo, ayudan con éxito a administrar negocios y en realidad se usan a pesar de todas sus deficiencias.
Además, he visto casos en los que los clientes intencionalmente no estaban dispuestos a pagar por una buena calidad: la ausencia de defectos importantes/críticos era todo lo que necesitaban.
Por supuesto, siempre es útil preguntar por las expectativas de un cliente específico, pero tener algunos puntos de referencia/ejemplos facilitaría enormemente esa conversación y ayudaría a planificar adecuadamente la cantidad de esfuerzos de prevención y evaluación.
Esta es una decisión que debe tomarse al principio del proceso de planificación. "¿Con qué bichos estamos dispuestos a enviar?" Su aclaración de preguntas ("no estamos hablando de software crítico para la vida calificado por humanos") es algo que no se puede repetir demasiadas veces cuando se habla con el control de calidad o la gerencia, quienes pueden tener expectativas poco realistas.
No soy un tipo SW, así que estoy dando mi respuesta desde una perspectiva genérica. Como indicó Scott, los límites de las especificaciones están/deben estar predefinidos. Esto es cierto incluso para productos críticos para la vida; la variación de tolerancia sería menor, pero todavía hay variación, por ejemplo, defectos.
Cuando no se indicó ninguna especificación predefinida, todo se reduce al análisis de riesgos y decisiones. El costo de la reparación en comparación con el impacto económico esperado (probabilidad x impacto financiero) que corre el riesgo. El más barato gana. La próxima vez que aborde un avión, ¡piense en eso!
Trabajé para una empresa hace unos años como PM que debía implementar un conjunto completo de nuevos sistemas de software para tiendas minoristas y un almacén de distribución, y liderar la implementación de nuevos procesos comerciales para permitir que el software inteligente hiciera lo que tenía. hacer. El proyecto fue un gran éxito en términos comerciales, a pesar de los problemas con el software que afectaron su usabilidad en algunas áreas, las brechas en la funcionalidad en otras y la información de gestión muy limitada proporcionada como informes estándar.
Lo que hizo que todo funcionara fue la actitud de la empresa de software, que garantizó que la funcionalidad subyacente estaría completamente bien; prometieron solucionar los principales problemas de usabilidad como una prioridad sobre el desarrollo de nuevas funciones; desarrollarían una nueva funcionalidad antes de los cambios estéticos, y se negaron a desarrollar una capacidad de generación de informes, diciendo desde el día 1 (antes de que compráramos el sistema) que eran nuestros datos: teníamos que desarrollar nuestros propios informes (pero nos dieron herramientas ayudar).
Sorprendentemente (en retrospectiva) nos convencieron de comprar su sistema y brindaron una gran cantidad de soporte, pero también brindaron un enlace excelente y establecieron relaciones duraderas con nuestros técnicos y, lo que es más importante, con los usuarios del sistema.
Esa es una forma larga de decir que si los datos son correctos, puede soportar muchos problemas siempre que sienta que los desarrolladores se preocupan por usted. Supongo que estaban usando una especie de proceso ágil, aunque ni ellos ni yo lo pensamos nunca de esa manera, pero sus desarrolladores fueron rápidos, precisos y entendieron el negocio.
A pesar de esa experiencia increíblemente buena, me pondría nervioso volver a tomar el mismo camino deliberadamente, ya que creo que tuve suerte, pero los principios de buenos datos, procesos correctos y la capacidad de cambiar rápidamente la interfaz de usuario probablemente definan mi filosofía. hacia las prioridades de desarrollo.
No estoy seguro de si eso responde a su pregunta, pero es un ejemplo práctico de cómo los sistemas imperfectos, desarrollados de la manera correcta y con los niveles apropiados de atención en las áreas clave, pueden tener un éxito masivo. Ciertamente no habríamos cambiado la empresa si hubiéramos esperado a la perfección.
Capers Jones ha estado publicando información sobre la densidad de defectos para varios tipos de software durante años. Desafortunadamente, tiene que pagar para obtener sus informes, pero hay algunas personas que han citado los números resumidos. Aquí hay uno del artículo de Watts Humphrey titulado apropiadamente "Funciones de software defectuosas".
Según esos datos, la clase de desarrollo menos disciplinada tiende a producir software que tiene en promedio 10 defectos por 1000 líneas de código (KLOC). El defecto 1 más disciplinado por KLOC en promedio, pero eso varía enormemente. He visto enviar sistemas críticos para la seguridad y nunca un solo cliente informó un defecto.
Hay muchas maneras diferentes de pensar acerca de los defectos. Puede categorizarlos en deficiencias de funcionalidad, peculiaridades de la interfaz de usuario, con solución alternativa versus sin ella, corrupción de datos S/N?, etc. Sin embargo, tiendo a tratar de reducirlo todo a la economía . ¿Cuál es el riesgo de que el software defectuoso perjudique las ventas? La respuesta dependerá en gran medida de quién sea el tomador de decisiones. Si se trata de una aplicación de $5 descargada de una tienda de aplicaciones, la clave es una experiencia sin problemas. Si está creando software empresarial donde el tomador de decisiones no es un usuario real, entonces tendrá un modelo diferente.
Usando este pensamiento económico, uno de los factores clave para mantener bajo el costo de los defectos es eliminarlos lo antes posible . El modelo tradicional dice que eliminar un defecto de requisitos durante una actividad de elicitación de requisitos es 1/10 del costo de hacerlo durante el diseño, y 1/100 de lo costoso que es eliminarlo durante la implementación, y 1/1000 de lo costoso que es arreglarlo después del software. se ha enviado. Esto aboga por la revisión de los requisitos, la revisión del diseño, la revisión del código, etc. Si bien aún existen niveles apropiados de revisión, la mentalidad ágil tiene una forma diferente de pensar al respecto.
El argumento Agile es que si se enfoca en hacer que su software evolucione fácilmente, puede lanzarlo antes y obtener mejores comentarios de los usuarios reales que de los revisores de requisitos/diseño/código. La cantidad es su propia forma de calidad. Es más barato y obtienes mejores resultados si consigues algo y lo reemplazas varias veces que pensar largo y tendido sobre cómo hacerlo perfecto la primera vez. Deje que los usuarios le digan lo que es importante y lo que no lo es.
scott c wilson