it-swarm-es.com

¿Qué cantidad de tiempo se debe gastar en errores versus desarrollo original?

Esta pregunta es un poco abstracta, pero espero que alguien pueda señalarme en la dirección correcta.

Mi pregunta es qué cantidad de tiempo se puede esperar dedicar a los errores de un proyecto de software en relación con el tiempo de desarrollo original. Me doy cuenta de que hay una gran cantidad de factores determinantes que intervienen, pero esperaba un desglose típico o promedio.

Por ejemplo, si el Proyecto A tarda 40 horas en completarse y otros 10 errores correctores, entonces este proyecto tendría una relación 4: 1.

Si otro Proyecto (B) tarda 10 horas en completarse pero otros 8 en errores, entonces tendría una relación de 5: 4.

¿Es este un concepto documentado/investigado?

ACTUALIZAR

Gracias por todas las respuestas informativas. Entiendo que es imposible establecer un estándar para este tipo de métrica debido a todas las variables y factores ambientales involucrados. Antes de asignar una respuesta, me gustaría saber si esta métrica tiene un nombre acordado para poder seguir investigando. Me gustaría llegar a un punto en el que pueda comprender las medidas necesarias para generar las métricas yo mismo y, finalmente, llegar a un estándar de referencia para mi proyecto.

26
Mike B

El porcentaje de equilibrio de la capacidad total asignada a la corrección de defectos es igual a ¡tasa de inyección de defectos.

Muchos factores pueden afectar esta tasa, entre ellos, por supuesto: qué tipo de producto está desarrollando el equipo, qué tecnologías y prácticas técnicas utilizan, el nivel de habilidad del equipo, la cultura de la empresa, etc.

Considerando el Equipo B, si crean en promedio 8 unidades de retrabajo por cada 10 unidades de trabajo que completen, entonces trabajar esas 8 unidades creará nuevas 6.4 unidades de retrabajo. Podemos estimar el esfuerzo total que eventualmente tendrán que gastar como la suma de una progresión geométrica:

10 + 8 + 6.4 + 5.12 + ...

El número de errores disminuirá exponencialmente con el tiempo, pero el Equipo B tiene un coeficiente tal en su exponente que irá a cero muy lentamente. En realidad, la suma de los primeros tres términos en la serie anterior es solo 24.4; de los primeros cinco, 33.6; de los primeros 10, 45; de toda la serie, 50. Entonces, resumen del Equipo B: tasa de inyección de defectos, 0.8; desarrollo de características, 10/50 = 20%; fijación de defectos, 80%. 20/80 es su asignación de capacidad sostenible.

Por el contrario, el equipo A está en mucho mejor forma. Su progresión se ve así:

40 + 10 + 2.5 + 0.625 + ...

La suma de esta serie es 53 1/3, por lo que la asignación de desarrollo de características del Equipo A es 40/(53 1/3) = 75% y la asignación de reparación de defectos es 25%, lo que coincide con su tasa de inyección de defectos de 10/40 = 0.25 .

En realidad, todos los términos en la serie del Equipo A después de los primeros tres son insignificantemente pequeños. Lo que esto significa en términos prácticos es que el Equipo A probablemente pueda eliminar todos sus errores con un par de versiones de mantenimiento, la segunda versión es bastante pequeña. Esto también crea una ilusión de que cualquier equipo puede hacer eso. Pero no el equipo B.

Pensé en esta equivalencia mientras leía el nuevo libro de David Anderson, "Kanban" . (El libro trata un tema diferente, pero también aborda las inquietudes sobre la calidad.) Al hablar sobre la calidad del software, Anderson cita este libro, de Capers Jones, "Evaluaciones de software, puntos de referencia y mejores prácticas" :

"... en 2000 ... midió la calidad del software para los equipos de América del Norte ... varió de 6 defectos por punto de función a menos de 3 por 100 puntos de función, un rango de 200 a 1. El punto medio es aproximadamente 1 defecto por 0.6 a 1.0 puntos de función. Esto implica que es común que los equipos gasten más del 90 por ciento de su esfuerzo en reparar defectos. "Cita un ejemplo proporcionado por uno de sus colegas de una empresa que pasa el 90% del tiempo arreglando sus errores.

La fluidez con la que Anderson pasa de la tasa de inyección de defectos a la asignación de capacidad de fijación de texto ( ¡demanda de falla es el término para ello) sugiere que la equivalencia de las dos cosas es bien conocida por la calidad del software investigadores y probablemente ha sido conocido por algún tiempo.

Las palabras clave en la línea de razonamiento que estoy tratando de presentar aquí son "equlibrium" y "sostenible". Si eliminamos la sostenibilidad, entonces hay una forma obvia de engañar a estos números: realiza la codificación inicial, luego pasa al código en otro lugar y deja el mantenimiento a otros. O acumula la deuda técnica y la descarga en un nuevo propietario.

Obviamente, ninguna asignación particular se adaptará a todos los equipos. Si decretamos que se debe gastar el 20% en errores, entonces, si un equipo tiene una tasa de inyección de defectos ultra baja, simplemente no tendrán suficientes errores para llenar el tiempo, y si un equipo tuvo una tasa muy alta, sus errores continuará acumulándose.

Las matemáticas que utilicé aquí están simplificadas. Descuidé cosas como los costos de transacción (reuniones de planificación y estimación, autopsias, etc.), lo que afectaría un poco los porcentajes. También omití ecuaciones que simulan sostener un producto y desarrollar otro simultáneamente. Pero la conclusión sigue en pie. Haga lo que pueda, en términos de prácticas técnicas, como pruebas unitarias, integración continua, revisiones de código, etc., para reducir la tasa de inyección de defectos y, en consecuencia, la demanda de fallas. Si puede crear un solo error por cada 10 funciones, tendrá mucho tiempo libre para desarrollar nuevas funciones y satisfacer a sus clientes.

16
azheglov

Lamentablemente, creo que esta relación es muy variable en un proyecto determinado. Se verá afectado drásticamente por su entorno, idioma, herramientas, tamaño del equipo y experiencia.

8
Mike Clark

Debería dedicar tiempo a un error solo si lo que gana de la corrección es mayor de lo que invierte.

Utilice una matriz como la siguiente (horizontal - tiempo requerido para corregir el error, vertical - tipo de error - impacto en los usuarios)

              | Few hours | Many hours
--------------+-----------+-------------------------
Minor problem | Might fix | Fix only if time permits
--------------+-----------+-------------------------
Major problem | Fix       | Fix

Ejemplo de problemas:

              | Few hours                            | Many hours
--------------+--------------------------------------+---------------------------------
              | Window moves 1px every 10            | Windows is painted incorrectly 
Minor problem | times when you open the application. | every 100th time the app is open.
              | Fix is: handle window resize event   | Fix: Change the graphical engine.
--------------+--------------------------------------+---------------------------------
Major problem | Application crashes when opening     | Poor performance when >100 users 
              | SQL connection.                      | are connected (unusable app)
              | Fix: Fix invalid query + add Nice    | Fix: change architecture + DB
              | message                              |

La matriz puede ser más compleja con diferentes niveles de gravedad, esfuerzo, riesgos, etc.

Incluso puede crear un rango para cada error y corregirlos según la clasificación. Algo como:

Bug priority = Risk x Severity x Effort

* Puede ser (1-x) para algunos operandos, dependiendo de la escala que elija :)

Entonces, para responder a su pregunta: depende del tipo de errores, tiempo/presupuesto disponible, etc.

8
Victor Hurdugaci

La respuesta verdaderamente correcta sería cero horas en la corrección de errores porque su código es perfecto. :-)

Siendo realistas, no puedo decir que haya escuchado a alguien pedir u ofrecer ese tipo de proporción. Eso no quiere decir que algunas empresas no sigan el tiempo para el desarrollo y el mantenimiento. Pero el desarrollo de una aplicación es un período de tiempo tan corto en comparación con el mantenimiento que la mayoría de las empresas no regresan y calculan esa proporción. Probablemente estén más preocupados por saber por qué una aplicación requiere mantenimiento y aplicar esos hallazgos a nuevas aplicaciones.

3
Walter

Es muy variable, no solo (por supuesto) en la experiencia y la calidad del equipo, y en la dificultad del proyecto (no es lo mismo hacer otra aplicación web estándar que un nuevo núcleo del sistema operativo), sino también en el enfoque de gestión que usted Lo usaré.

Por ejemplo, en un modelo en cascada puede configurar con precisión el primer error en la primera fase de prueba, pero en un entorno ágil puede ser difícil establecer una línea que diga "a partir de ahora, estamos corrigiendo errores", ya que las características pueden cambiar ( y para mí no es justo contar un cambio de función como un error)

Por experiencia, digo que es algo que SIEMPRE está subestimado, y muy fácilmente puede pasar la misma cantidad de horas que el "proyecto original".

3
Khelben

Tener un criterio demasiado amplio para lo que es un error casi puede duplicar su tiempo. Un administrador demasiado entusiasta que piensa que la solicitud de un cliente para agrandar un botón (tienen problemas con el mouse) es una excelente manera de aumentar la cantidad de errores que solucionamos. Solo tomará unos segundos solucionarlo porque no hay necesidad de considerar, probar, recompilar y distribuir un parche. Ah, y se cuenta dos veces como una nueva característica.

2
JeffO

Software no crítico, una relación 1: 1 no es inusual. Solo para las pruebas unitarias, he visto indicadores que mencionan 1 día de pruebas unitarias por cada 10 líneas de código.

1
mouviciel

Creo que tienes razón: no obtendrás ninguna métrica significativa debido a la gran cantidad de factores que influyen.

Si ayuda, puedo decirle que los proyectos en los que trabajo (espacio empresarial, sistemas complejos grandes, mucha integración con otros sistemas) tienen una relación de aproximadamente 3: 2. La mayoría de estos no son fallas con el código, más comúnmente fallas con las interfaces. Por ejemplo, el sistema A y B se comunican entre sí a través de la interfaz X. Los desarrolladores del sistema A interpretan la interfaz X de forma ligeramente diferente a los desarrolladores del sistema B. Se produce la comedia.

Una observación a realizar es que el desarrollo del código y las pruebas/corrección de errores del código no deberían ser dos fases distintas. Si prueba a medida que desarrolla, el "costo" de la corrección de errores es menor.

1
darreljnz

Creo que esta pregunta está sesgada: parte de la presuposición de que corregir errores es una fase similar a desarrollar nuevas funcionalidades. Este no es el caso.

Un buen desarrollador no pasará mucho tiempo depurando el código, ya que su código estará libre de errores desde el principio. Un mal desarrollador pasará mucho tiempo depurando su código porque no puede crear abstracciones adecuadas para resolver problemas reales.

Tenga en cuenta que los desarrolladores deben probar su propio código por sí mismos. Es su responsabilidad laboral entregar un código libre de errores. Por lo tanto, es difícil separar la codificación de la depuración.

También es una cuestión de prioridad. Cuando se desarrolla, el tiempo necesario para corregir un error se relaciona exponencialmente con el tiempo transcurrido desde el momento en que insertó el error en el código. Por lo tanto, corregir errores debería ser de mayor prioridad que desarrollar nuevas funcionalidades.

Entonces, en lugar de hablar sobre el "tiempo dedicado a errores", debería hablar sobre el "tiempo dedicado a las pruebas" (pruebas de integración, pruebas de aceptación del usuario ...)

1
Jérôme Radix

El factor determinante más importante para esto es si está trabajando con una nueva tecnología o una existente. Si está trabajando con algo nuevo y está desarrollando algo que no se ha hecho o se ha hecho varias veces en diferentes circunstancias, pasará mucho tiempo reparando errores y haciendo que su proyecto funcione de la manera que desee . Con frecuencia, los errores serán el resultado de trabajar en una esquina, y necesitarás hacer una cantidad significativa de trabajo para reestructurar lo que has hecho. Además, muchos errores resultarán de una comprensión incompleta de las expectativas del usuario y del desconocimiento del desarrollador de los casos de Edge.

Si está trabajando en una tecnología establecida, la mayoría de los problemas han sido resueltos por las bibliotecas o por las prácticas de la comunidad, y debería poder buscar en Google, comprar o solicitar la salida de cualquier error con el que se encuentre.

1
Dan Monego

Tomo un punto de vista puramente práctico: ¿qué impide más la utilidad práctica del proyecto? Si se trata de errores en la funcionalidad existente, debe corregir los errores. Si faltan características, debe hacer el desarrollo original, luego volver y corregir los errores una vez que se implementen las características faltantes más graves. Esto requiere familiaridad con sus casos de uso. Un error que bloquea el programa en algún caso de esquina extraño puede ser una prioridad menor que las mejoras de usabilidad menores que afectan a todos. Un pequeño error molesto en la funcionalidad más utilizada puede ser más importante que una función que solo beneficia a las personas que están llevando su software a los extremos.

0
dsimcha