A continuación se ofrecen algunas ideas sobre el valor de encontrar defectos de requisitos antes del diseño o codificación.
Para un equipo de desarrollo de software es muy valioso encontrar defectos tempranamente. Aún mejor es evitar los defectos por completo. Los requisitos excelentes son una forma eficaz de prevención de defectos y prevención de retrabajo. Un requisito ambiguo puede dar lugar a un esfuerzo desperdiciado sustancial.
Los defectos surgen antes de que comience la codificación
Los defectos surgen en los requisitos y la arquitectura incluso antes de que comience la codificación. Imaginemos que estamos en un negocio de seguros y los empresarios han decidido que se necesita un sistema nuevo (o modificado). Se propusieron describir lo que querían y se lo transmitieron a TI para que lo estimara. Estos requisitos a menudo se escriben como historias de usuarios, normalmente esto se hace en un formato consistente: “Como “…”Necesito “…. "de modo que" …
Tan pronto como se pone la pluma sobre el papel, aparecen ambigüedades y omisiones, es inevitable. Estos errores en los requisitos escritos (si no se descubren) pueden dar lugar a costosas reelaboraciones más adelante en el proyecto. El coste de tales defectos no es trivial: el Reino Unido perderá 37.000 millones de libras esterlinas en proyectos de TI (ágiles) fallidos (referencia). Para evitar estos costos evitables, debemos asegurarnos de que los requisitos sean lo más inequívocos y completos posible. Incluso los autores de requisitos más hábiles cometerán errores involuntarios y corregirlos no es tan fácil. Aquí es donde la automatización puede ayudar ahora.
Beneficios de encontrar defectos en los requisitos con antelación
Valorar el descubrimiento temprano de un defecto en los requisitos no es sencillo ni definitivo. La razón principal es que depende de qué tan tarde (en el proceso de desarrollo) se podrían haber encontrado esos defectos. Si no se encuentra un defecto hasta una etapa mucho más avanzada, su reparación requerirá mucho más esfuerzo, lo que costará miles de dólares; si solo se encuentra una etapa del SDLC antes, entonces tal vez se puedan ahorrar algunas horas de esfuerzo. En promedio, estimamos un modesto ahorro de 4 horas de personal por cada defecto de requisitos descubierto tempranamente: aproximadamente $200.
Esfuerzo típico de encontrar, arreglar y verificar la solución de:
a defecto de requisitos encontrado durante el requisitos etapa: 20 minutos – 4 horas
a defecto de requisitos encontrado durante el diseño etapa: 1-10 horas
a defecto de requisitos encontrado durante el desarrollo etapa: 2 – 15 horas
a defecto de requisitos encontrado durante el prueba del sistema etapa: 4 horas hacia arriba
a defecto de requisitos encontrado durante el producción etapa: 8 horas hacia arriba
Tenga en cuenta que esto solo representa el trabajo adicional para resolver el problema, no aborda las consecuencias del defecto.
Costo de Requerimientos Defectos encontrados en Producción
Cuando se encuentra un defecto de requisitos en producción generalmente lo reporta un usuario, y debemos considerar:
- Cuántos usuarios se vieron afectados antes de que nos informaran.
- Cuántos usuarios más se verán afectados hasta que se pueda solucionar.
- ¿Cuáles son los costos de brindar una solución alternativa a quienes han sido afectados?
- ¿Cuál es la pérdida consiguiente de este defecto para los clientes y nuestra organización?
- El efecto en cadena (costo de oportunidad) de desviar la atención hacia este problema frente a otras oportunidades.
La suma de estos costos generalmente supera el costo de reparar la reparación, por un margen significativo. En algunos casos extremos, la supervivencia de las empresas puede verse amenazada por un solo defecto en una aplicación importante de cara al cliente. por ejemplo, un sistema bancario que perdió la pista de los saldos de las cuentas
Defectos de seguridad: un caso especial
Los defectos de seguridad que no se encuentran hasta la producción siempre serán costosos de solucionar, a menudo pueden implicar demandas legales contra la organización y normalmente se miden en millones de dolares. Por lo tanto, encontrar defectos de seguridad a tiempo (especialmente en la fase de requisitos) puede evitar incidentes que podrían costar millones de dólares.
Valor de ScopeMaster Búsqueda de requisitos Defectos
Pasemos al valor que aporta ScopeMaster al exponer tempranamente los defectos de los requisitos. De hecho, existen múltiples beneficios al utilizar ScopeMaster según sus necesidades:
- Manera muy rápida de garantía de calidad requisitos
- Encuentra (algunos) posibles requisitos faltantes: automáticamente. (Recuerde: un requisito faltante es un defecto).
- Al mejorar los requisitos, habrá menos defectos en otros lugares, cronogramas y desarrollo y pruebas. los costos se reducirán.
- Mejorar la claridad de los requisitos, reduce la posible discordia entre los miembros del equipo causado por requisitos ambiguos.
- Genera una métrica de tamaño funcional automatizada sin esfuerzo manual, que se puede utilizar para dar mas control del proyecto.
- Mejora el velocidad de medición del tamaño funcional por 200-400% (para aquellos proyectos que miden el tamaño funcional)
- Cambia el idioma utilizado por los autores de requisitos de modo que con el tiempo prevenir defectos de requisitos de ser introducido.
No todos tienen el mismo valor y su importancia relativa variará de un proyecto a otro. En muchos casos, quizás el último punto sea el más importante. Si se pueden prevenir defectos especificando los requisitos de forma más precisa y completa, habrá menos defectos que buscar en el futuro.
Si bien los beneficios potenciales de usar ScopeMaster en un proyecto podrían ser millones, un modesto $200/defecto es una estimación muy conservadora de El valor de exponer el defecto tempranamente..
- Encontrar defectos en los requisitos en la fase de requisitos normalmente se hace con 3 o 4 amigos discutiéndolos; después de eso, son unos minutos para solucionarlo. 15 minutos de discusión con amigos equivalen a 1 hora de tiempo del personal. (Muchos de estos se pueden encontrar y solucionar en 4 a 10 minutos del personal con ScopeMaster).
Encontrar y corregir defectos de requisitos en las pruebas del sistema.
- Encontrar los defectos requeridos en la fase de prueba del sistema puede llevar solo 1 hora, pero solucionarlos llevará mucho más tiempo porque:
- Cuando se encuentra un (defecto de requisitos) en la prueba del sistema, se debe documentar abundantemente, luego se requiere una coordinación extraordinaria de los evaluadores y desarrolladores de SME para clasificarlo y verificarlo como un defecto de requisitos real y, finalmente, corregir el requisito.
- La implementación de la solución puede ser un trabajo de configuración modesto, pero las nuevas capas de prueba en torno a este defecto y toda la funcionalidad relacionada que también debe volver a probarse mediante regresión no son triviales.
- La detección tardía de un defecto en los requisitos significa que existe una mayor probabilidad de que se realicen correcciones incorrectas. es decir. un defecto causa uno o dos más (cada uno con su propia documentación, clasificación y ciclo de reparación y verificación).
- Existe una tendencia humana a no cuestionar los requisitos en etapas posteriores. Los evaluadores tienden a aceptar los requisitos como correctos y es más probable que cuestionen el cumplimiento de la codificación/configuración de los requisitos, no los requisitos en sí. La consecuencia es que es más probable que los defectos (causados por requisitos deficientes) terminen en producción, con muy malas consecuencias”.
