¿Por qué es más costoso descubrir un defecto más adelante en el proceso?¿Por qué es más costoso descubrir un defecto más adelante en el proceso?
He oído esto mucho pero me cuesta entender y poner contexto/ejemplos a esto.
Cuanto más tiempo se tarda en encontrar un error, entonces:
más el comportamiento del insecto puede haber sido aceptada como correcta, y los más de otras cosas puede haber pasado a depender de que el comportamiento (Windows es notorio por esto).
Cuanto más integrado esté el sistema, más difícil será extraerlo.
mayor es la probabilidad de que el comportamiento erróneo del error se duplique en otro lugar en virtud de copiar y pegar o en clientes que usan el código erróneo.
Cuanto más tiempo ha pasado desde que el código fue escrito originalmente y más difícil puede ser para entenderlo.
es menos probable que las personas que entienden esa parte original del sistema estén cerca para solucionarlo.
Porque habrá más personas que pasarán tiempo con el software defectuoso.
Si soluciona un error al principio, usted y tal vez un revisor de códigos le dedicará un poco de tiempo.
Si se libera a los clientes y se expresa como un error, se han codificado, alguien puede haber revisado, alguien puede haber probado, alguien puede incluso haber documentado y así sucesivamente ...
Cuanto más tarde descubras un error, peor. Cuando encuentras un error inmediatamente después de codificar, tienes todo el comportamiento en mente y sabes exactamente qué cambios lo causaron. Podrá concentrarse en el problema, una vez que sepa dónde reside.
Cuando lleva mucho tiempo, los desarrolladores ya no recuerdan exactamente cómo funcionó, y hay muchos más lugares para investigar para encontrar el error. Tal vez el desarrollador que codificó el error ya no esté trabajando en la empresa.
Además, con el paso del tiempo, es probable que más partes del código dependan del código del buggy, y es posible que también deba corregirlas.
Finalmente, existen problemas que afectan a los usuarios. Si encuentra un error después de un lanzamiento, más usuarios se sentirán frustrados y la imagen de su producto empeorará. Los usuarios también pueden usar una solución para este error, que puede comenzar a fallar después de corregir el error.
Resumen: Cuando se toma mucho tiempo para encontrar un error
Estás construyendo una casa. Estás colocando las tuberías de alcantarillado en los cimientos, pero, para tu desconocimiento, una de las tuberías está bloqueada por un erizo muerto.
¿Prefiere saber:
(Hay una broma "desbordamiento de pila" en algún lugar de esta analogía. 8-)
Puede haber otras dependencias (internos o externos) que afectará a la fijación de un defecto.
Por ejemplo - Si puedo resolver este defecto, puede que tenga que corregir algo más
Imagínese que usted está escribiendo un ensayo sobre por qué es más costoso para descubrir un defecto más adelante en el proceso, y se da cuenta de repente uno de las premisas en las que se basa la mayoría del contenido de su ensayo es falso.
Si aún está planificando, solo tiene la mitad de una página del plan para cambiar. Si su ensayo está casi terminado, de repente necesita desechar el lote y empezar de nuevo. Si ya lo entregó, el error le costará su calificación.
La misma razón.
Esto se puede ilustrar en un ejemplo simple (si no trivial).
Tome un diálogo simple con un mensaje y solo dos botones "Aceptar" y "Cancelar".
Supongamos que el error es un error ortográfico.
Si esto se encuentra después de que se lanza el producto, debe lanzarse una nueva versión del producto con todos los costos asociados. Los manuales necesitarán ser reimpresos.
Si esto se encuentra en las pruebas finales, se deberá reimprimir el manual. El código deberá ser reescrito y las pruebas volverán a ejecutarse.
Si esto se encuentra durante el desarrollo, existe el costo de corregir el código.
Si esto se encuentra durante el diseño, entonces el código se escribe correctamente la primera vez, sin costo.
+1: Nos encontramos con algo así. El cliente nos dio un montón de etiquetas en un lenguaje totalmente incomprensible para nosotros. El único que pudimos verificar fue trabajar sobre cada vertiginosa de cada carácter retorcido y confirmar que era correcto. El cliente rechazó el trabajo) +: La primera palabra en cada etiqueta era el equivalente a 'Ejemplo'. – Everyone
Para un producto de software envuelto: Si encuentra un error después de que su producto llegue a las tiendas, tendrá que ayudar a los usuarios a través de llamadas de soporte, sugerir una solución o incluso retirar el producto/emitir un paquete de servicio.
Para un sitio web: Las interrupciones del sitio y las demoras le cuestan dinero. La pérdida del cliente como resultado de un sitio deficiente/mal funcionamiento le cuesta más. El proceso de depuración también es costoso.
Debido al proceso de desarrollo y todo el trabajo involucrado en la reparación del defecto.
Imagina que encuentras un problema en la función que codificaste ayer, solo echas un vistazo, arreglas, registras, punto. Todavía está fresco en tu mente, sabes de qué se trata y que tu solución no tendrá ningún efecto secundario.
Ahora imagine encontrar el mismo error en seis meses a partir de ahora. ¿Recordarás por qué la función fue codificada de esa manera? ¿Seguirás trabajando en este proyecto/compañía? Debe abrir un informe de defectos, se debe emitir una nueva versión de su software, el control de calidad debe validar la corrección. Si el software se ha implementado, entonces todas las instancias tienen que actualizarse, los clientes llamarán a soporte ...
Ahora bien, es cierto que la curva que muestra el costo se compone para ilustrar el punto; De hecho, depende del proceso de desarrollo.
Probablemente sea un error del autor de la pregunta, pero la pregunta real es: "¿Por qué es más costoso descubrir un defecto más adelante en el proceso?" Dentro de esa pregunta está el costo de descubrir el error y podemos esperarlo también significa arreglarlo. La mayoría de las respuestas hacen un buen trabajo al describir el costo de la reparación y por qué es mejor solucionarlo antes que corregirlo más tarde. Y, realmente no estoy en desacuerdo con ninguno de ellos. Pero, esa no es toda la pregunta.
Tengo una serie regular de argumentos esotéricos con algunos sobre el costo de descubrimiento. Cuántas pruebas habrían sido necesarias para encontrar un error específico (sin retrospectiva). ¿Habría llevado 3 meses-hombre más de pruebas automáticas o manuales antes de que hubiera sido probable que encontrara ese caso de prueba y escenario?
En la práctica, prueba tanto como puedas pero encontrar ese punto de equilibrio no es tan fácil como muchos pensarían. La mayoría de los programas son demasiado grandes para tener una cobertura de código del 100%. Y, la cobertura del código del 100% suele ser solo una fracción de todos los escenarios posibles que debe manejar el código.
Otro factor que entra en el costo de un error es el costo comercial asociado con el error. ¿Hay 5 millones de cajas sosteniendo el error? ¿Tendría que hacer un retiro del producto? ¿Generará X llamadas a su mesa de ayuda de garantía? ¿Desencadenará alguna cláusula de un contrato que lo haga responsable de los daños y perjuicios? En términos muy simples, esta es la razón por la cual el software escrito en el campo médico cuesta más por LOC que aquellos para el desarrollo de sitios web.
Yo diría que el más costoso es encontrar un defecto y dejarlo. Cuanto más tiempo permite que el defecto viva, más costoso se vuelve.
Estaba en una empresa a la vez, donde tenían la política, que una vez que habían tomado una decisión, la seguían.El sistema en el que trabajé estaba cargado de errores debido a un estúpido marco corporativo que nos forzaron a usar, y una gran incomprensión del uso correcto de los servicios web.
Hasta el día de hoy, creo que la forma más económica para que la compañía obtenga un sistema que funcione y funcione, sería deshacerse de todo el sistema y volver a escribirlo desde cero.
Así que mi punto es que no creo que encontrar un defecto en una etapa posterior sea problemático. Pero ignorar un defecto hasta una etapa tardía es extremadamente problemático.
http://www.joelonsoftware.com/articles/fog0000000043.html # 5 –
La afirmación más común es que "es más costoso _finalizar un defecto cuando se descubre más adelante en el proceso". – MSalters