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 prototipos y las posibles ideas para mitigarlos.
La causa principal de los defectos de 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 impecables. Además, a menudo hay una presión de tiempo y la mayoría de la metodología se omite a menudo bajo presión.
Las pruebas solo pueden detectar los problemas temprano. Pero incluso los evaluadores 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 estoy diciendo que solo sea divertido, sino porque uno de los grandes problemas que he observado en mi trabajo es la poca recopilación de requisitos, junto con una mala comprensión del dominio del problema, que causa defectos importantes Problemas de usabilidad en el proyecto.
Parte de eso proviene de no estar dispuesto a aprender / entender la terminología del usuario final, causando malentendidos.
Parte de eso proviene de hablar de tecnología demasiado pronto en el proceso a personas que no tienen ni idea de qué 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 ser las preguntas / respuestas en caracteres ... Sabía que él estaba tratando de averiguar qué campo de tamaño utilizar en la base de datos , pero el departamento que lo solicitó no tenía la menor idea de por qué importaba, o de que los espacios contaban. Para nosotros eso parece obvio, pero para ellos fue una verdadera revelación.
La causa principal de los defectos es mala gestión ;)
En serio, un desarrollador que trabaja en buenas condiciones, a quien no se le pide que trabaje demasiado, que reduzca la calidad, que tenga las herramientas adecuadas, que las condiciones de trabajo sean tranquilas, etc.
También la administración que contrata malos desarrolladores también ayuda a aumentar la cantidad de errores.
Mala gestión .
(descargo de responsabilidad: se supone que debo contratar y gestionar desarrolladores)
No veo ninguna causa principal, pero una causa que no se ha mencionado es acoplamiento involuntario con otro código . Escribir código que tiene efectos secundarios invisibles, rompe a través de las capas de abstracción, hace suposiciones sobre los datos (las variables no lo hacen, las constantes no lo son y la información de un usuario no es segura), ataca las cosas que no necesitan preocuparse con, y así sucesivamente.
La mayoría de las prácticas de desarrollo que estudio se reducen a reducir N , porque la complejidad de un programa es al menos O(N^2) y posiblemente O(k^N) . Definir N se 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 la N al compartimentar el problema.
Brecha de comunicación. En la recogida de requisitos. En horario En el documento de diseño. En especificación funcional. En código (espacio entre lo que quiere el programador y lo que le dice al compilador).
Etiqueta social. Es socialmente inaceptable llamar a alguien incapaz.
Apresurándose hacia las cosas sin entenderlas completamente. Comenzar a escribir código sin comprender completamente los requisitos funcionales o la arquitectura técnica.
La programación debería ser casi automática, solo escribir lo que es evidente y ya se ha desarrollado en la mente. En la práctica, veo un montón de 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.
Schedule Pressure es una fuente segura.
Los desarrolladores apresurados no se toman el tiempo para especificar completamente los requisitos, ni entienden completamente la intención detrás de los requisitos, ni investigan completamente a los alternativos para encontrar la mejor solución, ni piensan completamente en todos los casos extremos e interacciones de los cambios realizar o desarrollar un conjunto completo de casos de prueba, o realizar todas las pruebas unitarias, realizar una prueba de integración completa, considerar las dependencias de la plataforma, probar el instalador por completo o documentar completamente lo que han hecho al siguiente el desarrollador puede 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 la prueba de unidad escrita por los desarrolladores es útil para detectar algunos errores, la mayoría de los errores pasarán 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 ha probado (y no me refiero simplemente 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ía de lo que hacen los desarrolladores de software es "esencialmente complejo", por lo que es simplemente la naturaleza Es difícil crear software, el software tendrá errores y nuestro trabajo es solucionarlo.
La falla en entender el software como una red de máquinas de estado, los principios subyacentes a su operación (estados, su determinación y transiciones), y las interacciones de las máquinas de estado.
La falta de verificación de cosas que "no pueden suceder" o que es poco probable que ocurran es una de las mayores. A veces lo perfecto es enemigo de lo bueno. Si no merece una jerarquía de excepciones bien pensada, un manejo rápido y sucio siempre es mejor que nada. Soy un gran fanático de fallar rápido, de afirmaciones y de dejar afirmaciones que tienen un impacto insignificante en el rendimiento en las versiones de lanzamiento. Incluso en las secuencias de comandos rápidas y sucias en las que controlo todos los datos de entrada, introduzco un manejo de errores rápido / sucio, generalmente solo con una función que es equivalente a afirmar pero que permanece activa todo el tiempo. Mi regla de oro es que, si no es probable que ocurra o usted cree que no puede suceder, no necesita fallar con gracia 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 algunos consejos sobre lo que salió mal.
Editar: una táctica útil relacionada es utilizar aserciones como una herramienta importante de depuración y dejarlas ahí después de que finalice la sesión de depuración. A partir de ese momento, su base de código tendrá algunas comprobaciones de seguridad integradas que dificultarán que los errores relacionados vuelvan a suceder. Esto es especialmente útil para el código que es difícil de probar.
En un nivel, la gestión. Pero no es solo el PHB. Es la administración del código en sí, lo que puede o no ser un reflejo de la administración corporativa.
Los participantes en todo el "ciclo de vida" deben estar completamente comprometidos con la calidad y hacer un producto que simplemente no muera . El software en sí mismo tiene la promesa de no romperse nunca, dado 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.
Lea otras preguntas en las etiquetas bug programming-practices experience