¿Cuál considera que es la causa principal de los defectos de software (y cómo minimizarlos) [cerrado]

Defino defecto como:

"algo dentro del diseño o código de la aplicación que impide que funcione según los requisitos".

Estoy buscando ideas sobre las causas de los defectos, por ejemplo, el factor humano, la falta de pruebas, la falta de creación de prototipos y posibles ideas para mitigarlos.

La causa principal de los defectos del software es la interpretación.

La interpretación del cliente de una característica difiere de la interpretación del diseñador.

La interpretación del diseñador difiere de la interpretación del programador.

La mayoría de las metodologías han inventado formas de contrarrestar este efecto. Pero al final, solo somos humanos y no somos perfectos. Además, a menudo hay una presión de tiempo y la mayoría de la magia de la metodología a menudo se omite bajo presión.

Las pruebas solo pueden detectar los problemas temprano. Pero incluso los probadores son humanos, y es imposible probar el 100%. Si quieres liberar antes de que termine el universo.

Considero que la causa principal de los defectos de software son los programadores.

No digo eso solo para ser divertido, sino porque uno de los grandes problemas que he observado en mi trabajo es la falta de recopilación de requisitos, junto con una comprensión deficiente del dominio del problema, que causa defectos importantes y problemas de usabilidad en el proyecto.

Parte de eso proviene de no estar dispuesto a aprender / comprender la terminología del usuario final, lo que causa malentendidos.

Parte de eso proviene de hablar de tecnología demasiado temprano en el proceso para las personas que no tienen idea de lo que estás hablando o por qué es importante.

El mejor ejemplo de eso fue cuando escuché a uno de los programadores tratando de averiguar cuánto tiempo iban a estar las preguntas / respuestas en caracteres ... Sabía que estaba tratando de averiguar qué tamaño de campo usar en la base de datos, pero el el departamento que solicitó esto no era el más confuso por qué eso importaba, o que los espacios contaban. Para nosotros eso parece obvio, pero para ellos fue una verdadera revelación.

La causa principal de los defectos es el mal manejo. ;)

En serio, un desarrollador que trabaje en buenas condiciones, no se le pida que trabaje demasiado, que reduzca la calidad, que tenga las herramientas adecuadas, condiciones de trabajo silenciosas, etc. producirá menos errores que alguien que trabaja bajo presión.

Además, la administración que contrata desarrolladores malos también ayuda a aumentar el número de errores.

Una mala gestión .

(descargo de responsabilidad: se supone que debo contratar y administrar desarrolladores)

No veo ninguna causa principal, pero una causa que no se ha mencionado es el acoplamiento involuntario con otro código . Escribir código que tenga efectos secundarios invisibles, rompa las capas de abstracción, haga suposiciones sobre los datos (las variables no lo harán, las constantes no lo son, y ninguna entrada de un usuario es segura), guarda cosas que no tiene que preocupar a sí mismo con, y así sucesivamente.

La mayoría de las prácticas de desarrollo que estudio se reducen a la reducción N, porque la complejidad de un programa es al menos O(N^2)y posiblemente O(k^N). La definición Nse deja como un ejercicio para el lector, pero estoy pensando en cosas como la complejidad ciclomática aquí. La lógica y los datos encapsulados tienen el efecto de reducir N compartimentando el problema.

La incapacidad para pensar en todo.

Estar incompleto

Brecha de comunicación. En la recogida de requisitos. En horario. En documento de diseño. En especificación funcional. En código (brecha entre lo que el programador quiere y lo que le dice al compilador).

Etiqueta social. Es socialmente inaceptable llamar a alguien incapaz.

Apresurarse en las cosas sin comprenderlas completamente Comenzar a escribir código sin comprender completamente los requisitos funcionales o la arquitectura técnica.

La programación debe ser casi automática, simplemente escribiendo lo que es evidente y ya ha sido resuelto en la mente. En la práctica, veo muchos errores en el código para tratar de entender exactamente qué se supone que debe hacer el código. He sido culpable de esto muchas veces.

Errare humanum est

Schedule Pressure es, sin duda, una fuente sólida.

Los desarrolladores apresurados no se toman el tiempo para especificar completamente los requisitos, o entender completamente la intención detrás de los requisitos, o investigar completamente las alternativas para encontrar la mejor solución, o pensar completamente en todos los casos extremos e interacciones de los cambios que están haciendo, o desarrollar un conjunto completo de casos de prueba, o realizar completamente todas las pruebas unitarias, o realizar una prueba de integración completa, o considerar completamente las dependencias de la plataforma, o probar completamente el instalador, o documentar completamente lo que han hecho para que el próximo desarrollador pueda entender ....

Otra cosa que debe mencionarse es no tener una prueba externa. Cuando el desarrollador escribe las pruebas y las ejecuta, solo prueba su interpretación, no el requisito real. Si bien las pruebas unitarias escritas por los desarrolladores son útiles para detectar algunos errores, la mayoría de los errores habrán pasado estas pruebas pero no serán lo que el usuario quiere o necesita. Cualquier software que no haya sido probado por alguien que no sea el desarrollador no se prueba (y no me refiero solo a ejecutar las pruebas del desarrollador).

Es porque la ingeniería de software es intrínsecamente compleja. El ensayo "No Silver Bullet" discute esto.

Irónicamente, muchas de las otras respuestas aquí tocan temas que son "accidentalmente complejos", en el lenguaje de ese ensayo, mientras que en realidad la mayor parte de lo que hacen los desarrolladores de software es "esencialmente complejo", por lo que es solo la naturaleza de lo que crea el software es difícil, el software tendrá errores y nuestro trabajo es lidiar con eso.

La incapacidad de comprender el software como una red de máquinas de estado, los principios subyacentes a su funcionamiento (estados, su determinación y transiciones) y las interacciones de las máquinas de estado.

Escribir código que falla en silencio versus código que informa todos los errores.

La falta de verificación de las cosas que "no pueden suceder" o que es poco probable que sucedan es importante. A veces lo perfecto es enemigo de lo bueno. Si no vale la pena una jerarquía de excepciones bien pensada, un manejo rápido y sucio siempre es mejor que nada. Soy un enormefanático de fallar rápidamente, de afirmaciones y de dejar afirmaciones que tienen un impacto insignificante en el rendimiento en las versiones de lanzamiento. Incluso en scripts rápidos y sucios únicos donde controlo todos los datos de entrada, pongo un manejo de errores rápido / sucio, generalmente solo con una función que es equivalente a afirmar pero permanece activa todo el tiempo. Mi regla general es que, si no es probable que ocurra o si cree que no puede suceder, no es necesario que falle correctamente con un mensaje de error fácil de usar, pero al menos debería fallar rápidamente con un mensaje de error que le da al programador algunas pistas sobre lo que salió mal.

Editar: Una táctica útil relacionada es usar afirmaciones como una herramienta de depuración importante y dejarlas allí después de que termine la sesión de depuración. A partir de ese momento, su base de código tendrá algunas comprobaciones de sanidad incorporadas que dificultarán que los errores relacionados vuelvan a ocurrir. Esto es especialmente útil para el código que es difícil de probar.

La causa principal de los defectos del software es escribir código.

Escriba menos código y tendrá menos errores ;-)

En un nivel, gestión. Pero no es solo el PHB. Es la gestión del código en sí, lo que puede o no ser un reflejo de la gestión corporativa.

Los participantes en todo el "ciclo de vida" deben invertir completamente en calidad y hacer un producto que simplemente no muera . El software en sí tiene la promesa de nunca romperse, dada la fiabilidad de abstracción adecuada. Es solo una cuestión de si los constructores de software están interesados ​​en tener esa operación perfecta.