Una técnica universal para mejorar la calidad del software
Todo el mundo quiere mejorar la calidad del software tanto como sea posible, siempre que ello no ralentice la entrega de nuevas funciones.
Da la casualidad de que existe una única técnica que puede mejorar drásticamente la calidad del desarrollo de software. En este artículo, aprenderá dos fundamentos clave:
- El conocimiento del tamaño del software ayuda a mejorar la calidad del software.
- El proceso de dimensionamiento del software ayuda a mejorar la calidad del software.
- Esta técnica puede encontrar y ayudarlo a eliminar 7-10% de todos los defectos antes de codificar.
Comencemos con algunos fundamentos sobre el desarrollo de software. Todo el software tiene defectos (errores). Los errores pueden deberse a una codificación deficiente o pueden deberse a otra cosa. Quizás nos equivocamos en los requisitos, quizás los malinterpretamos, quizás omitimos algunos requisitos importantes.
Muy a menudo, los requisitos son la causa principal de los errores de software. Pero rara vez dedicamos tiempo a analizar los requisitos de calidad. ¿Por qué? Es importante pero rara vez urgente. Revisar y perfeccionar los requisitos casi nunca se considera una actividad crítica en un plan de proyecto. He visto que se utilizan algunos requisitos muy deficientes "solo para que los desarrolladores puedan comenzar". Pero este es un proceso ineficiente y dará lugar a importantes retrasos y retrabajos innecesarios.
Mejore la calidad del software conociendo el tamaño
Si ha trabajado antes con el dimensionamiento de software, también sabrá que el potencial de defectos (el número probable de defectos/errores) en los requisitos es predecible. Este único conocimiento puede guiarlo a ser más eficiente. Puede informarle que introduzca la cantidad óptima de esfuerzo en la calidad de los requisitos antes de codificar, eliminando errores de requisitos, antes de que comience la codificación.
Ejemplo
Hoy en día, un coche típico tiene unos 5 millones de líneas de código. A partir de datos históricos, sabemos que es probable que equivalga a unos 100.000 puntos de función (medida ISO del tamaño del software). También a partir de datos históricos sabemos que existe (en promedio) un potencial de defectos de 0,7 a 1,0 requisitos de defectos por punto de función. Por tanto, habrá (habrá) habido 100.000 defectos de requisitos. Si realiza un seguimiento del número de defectos encontrados y eliminados, puede determinar aproximadamente cuántos quedan. Además, si realiza revisiones y exámenes de requisitos para encontrar y corregir defectos de requisitos de manera temprana, reducirá los defectos de requisitos que se trasladan cuando comienza la codificación.
Saber cuántos defectos existen potencialmente le informa cuánto trabajo debe hacer para eliminarlos. Si optimiza su trabajo de control de calidad (requisitos) teniendo como objetivo (no 100% sino) la eliminación de defectos de 95%, entonces estará en camino de lograr una entrega ágil y eficiente.
Por ejemplo, si utiliza ScopeMaster para examinar y probar sus requisitos antes de codificar, probablemente podría encontrar alrededor de 50.000 de estos defectos (50%) y evitar que lleguen a los desarrolladores. Imagínese cuánto más eficientes serían sus desarrolladores si comenzaran con requisitos que tuvieran 50% menos defectos.
Métricas de calidad válidas a partir de conocer el tamaño del software
Nota CFP = Puntos de Función CÓSMICA
Mejorando la calidad con el proceso de dimensionamiento
El proceso de dimensionamiento funcional formal es ideal para aclarar la intención funcional, es decir ambigüedades. En ocasiones se utilizan términos diferentes pero en realidad significan lo mismo. Al examinar los usuarios funcionales y los tipos de objetos que manejan los usuarios a través de un conjunto de requisitos, puede detectar fácilmente inconsistencias. Si dos funciones realizan la misma acción en un objeto, es posible que tenga un duplicar requisito. Si tiene un objeto que su software debe mantener en su totalidad, pero a sus requisitos le falta una función de mantenimiento de datos críticos, es posible que tenga un Requisito faltante. Si un requisito implica muchos pasos funcionales, podría ser demasiado complicado codificarlo, podría ser necesario simplificarlo, podríamos considerar esto como una defecto de complejidad. En conjunto, estas cinco categorías de defectos de requisitos representan aproximadamente 40% de todos los defectos potenciales.. Es probable que estos defectos queden expuestos por proceso de dimensionamiento funcional. Por lo tanto, el dimensionamiento manual de los requisitos es una actividad de control de calidad eficiente y que vale la pena. El dimensionamiento automatizado a partir de los requisitos con ScopeMaster es aún más eficaz y completo. Detectará e informará sobre estos defectos de forma más rápida y exhaustiva de lo que los humanos podrían lograr manualmente.
Conclusión
Hemos demostrado en este artículo que tanto el conocimiento del tamaño funcional como el proceso de dimensionamiento mejorarán drásticamente la calidad del software. Específicamente, 7-10% de todos los errores de software se pueden eliminar mediante el proceso (automatizado) de dimensionamiento del software. Luego, el conocimiento del tamaño puede ayudar a optimizar las actividades de control de calidad para ayudar a eliminar los errores restantes.
