domingo, 10 de agosto de 2008

Team Skill 6: Construyendo el Sistema Correcto

Diseñar e implementar el sistema correcto es el más grande trabajo de todos. Una técnica útil es usar los requerimientos y los casos de uso para guiar la implementación de la arquitectura y el diseño. Como estuvimos viendo en los post anteriores, Managing Software Requirements - A Unified Approach es un libro que propone una metodología para capturar y administrar requerimientos durante todo el proceso de desarrollo de software, organizada en Team Skills o Habilidades Grupales.

Llegamos a la última Habilidad Grupal, la que se encarga de la fase de construcción. En esta fase, debemos confirmar continuamente que el desarrollo esté progresando, confirmar que los resultados del desarrollo son correctos y aprender a administrar los cambios que ocurren durante el proceso. Es necesario mantener la trazabilidad de los requerimientos y los casos de uso y establecer procesos de verificación y/o validación mediante pruebas de aceptación de diferente profundidad y cobertura, para corroborar que se siga construyendo el sistema correcto, el sistema que el usuario pidió y el analista relevó.

Verificación mediante Trazabilidad

La verificación es un enfoque analítico que permite un monitoreo constante de la evolución de las funcionalidades del proyecto, los requerimientos, el diseño y la implementación. La Verificación está soportada por el uso de técnicas de trazabilidad para relacionar unas partes del proyecto con otras.

Trazabilidad es la habilidad de trazar la implementación a través de las fases de especificación, arquitectura, diseño, construcción y testing. Es significativa para la calidad del software. A través del uso de la trazabilidad podemos verificar que:
  • Todos los elementos del proyecto se contabilizan.
  • Todos los elementos del proyecto tienen un propósito.
Según la IEEE, la trazabilidad es el grado por el cual una relación puede ser establecida entre dos o más productos del proceso de desarrollo o el grado por el cual cada elemento del producto de desarrollo de software establece una razón para su existencia.

La trazabilidad puede ser:
  • Implícita: cuando nace de las relaciones entre productos.
  • Explícita: cuando nace del desarrollo de las relaciones derivadas de consideraciones hechas por el equipo de desarrollo.
Aunque la verificación es una técnica analítica, los autores de Managing Software Requirements, Dean Leffingwell y Don Widrig, afirman que es importante recordar que pensar es importante. No podemos simplemente aplicar las técnicas de verificación mecánicamente.

Validación mediante Pruebas de Aceptación

La validación es la otra cara del enfoque V&V para asegurar que el sistema está construido correctamente, haciendo foco en las pruebas y en el uso de las técnicas de trazabilidad para seleccionar componentes del sistema que requieren pruebas. Al igual que en la verificación, usamos técnicas de validación para asegurar que:
  • Todos los elementos del proyecto están correctamente probados.
  • Todas las pruebas tienen un propósito útil.
Según la IEEE, la validación es el proceso de evaluación de un sistema o componente durante o al final del proceso de desarrollo para determinar si satisface los requerimientos específicos. Para llevar a cabo la validación se utilizan las Pruebas de Aceptación. A través de ellas, el cliente debe validar que el producto trabaje de la forma en que realmente necesita que lo haga.

Las actividades primarias de la validación consisten en actividades de testing. Debemos tratar de probar contra los requerimientos y no contra la implementación. El proceso de desarrollo debe incluir planificación para actividades de prueba, debe proveer tiempo y recursos para diseñar las pruebas y proveer tiempo y recursos para ejecutarlas, a nivel de pruebas unitarias y pruebas globales del sistema.

Análisis de Riesgos

Necesitaremos aplicar un Análisis de Riesgos para ayudar a decidir qué porción del sistema necesita Verificación y Validación (V&V) y en qué cantidad. Obviamente verificar y validar todas y cada una de las funcionalidades es poco práctico y puede llevar a un producto inseguro que cause daño a los usuarios.

Un correcto Análisis de Riesgos servirá para decidir cuáles son los riesgos a mitigar en el sistema, para decidir el alcance de las actividades de V&V y para realizar un análisis de costo y beneficio que será entrada directa para el cálculo del ROI.

Administración de Cambios

Leffingwell y Widrig aseguran que construir el sistema correcto también depende de la Administración de Cambios. Hasta que la Ingeniería de Software surgió como carrera, los desarrolladores tuvieron que aprender a las patadas que el cambio es parte de la vida, que todo proyecto debe contar con un plan para soportar los cambios y diseñar un proceso con el cual poder gerenciarlos. La Administración de Cambios nos ayudará a saber que el sistema que estamos construyendo es el sistema correcto y, además, que continúa siendo el sistema correcto durante todo el ciclo de vida del proyecto.

Un proceso para la administración de cambios podría ser:
  • Reconocer que el cambio es inevitable
  • Hacer un baseline de los requerimientos
  • Establecer un único canal para establecer el cambio
  • Establecer un sistema de control de cambios
  • Administrar el cambio jerárquicamente: esto se refiere a que los cambios deben ser administrados top-down y no bottom-up, como se suele hacer (problema conocido como "efecto dominó"); los cambios deben comenzar por la visión, construyendo un documento Delta de Visión (como vimos en el Team Skill 3), que luego atraviese todas las disciplinas posteriores.

Entradas Relacionadas