La importancia de la Ingeniería de Requisitos www.visuresolutions.com La importancia de la Ingeniería de Requisitos Fernando Valera Product Manager IRQA - fvalera@visuresolutions.com 24 de Noviembre de 2009

Agenda La problemática ¿Qué son los requisitos? ¿Qué es la Ingeniería de Requisitos? ¿Por qué es importante? ¿Por qué MS Word o MS Excel NO es suficiente? Integración de la Ingeniería de Requisitos en ALM

Algunas de estas situaciones son familiares… - Voy a ver qué quiere el cliente, ¡el resto empezad a programar!

Algunas de estas situaciones son familiares… Sus requisitos de usuario incluyen 400 funcionalidades. ¿Es consciente de que ningún ser humano podrá utilizar un producto tan complejo? ¡Buena observación! Debería añadir “fácil de utilizar”

Algunas de estas situaciones son familiares… PERFECTO… lo voy a probar! FUNCIONA! Cliente Desarrollador Esto no me vale! … pero funciona! tiempo Lo que el cliente NECESITA Lo DESARROLLADO } Expectation Gap

Lo que un usuario quiere no es necesariamente lo que necesita! Un requisito es… “Requisitos son … una especificación de lo que debería ser implementado. […]” -- Ian Sommerville & Pete Sawyer Una condición o capacidad necesaria para un usuario para solucionar un problema o alcanzar un objetivo […] [IEEE Std 610.12, “IEEE Standard Glossary of Software Engineering Terminology”] …una especificación que el sistema o producto debe cumplir Lo que un usuario quiere no es necesariamente lo que necesita! Los Requisitos son ... El principal criterio de éxito del equipo de proyecto La base de las tareas del equipo de proyecto La base para el diseño, codificación y las pruebas

¿Qué es la Ingeniería de Requisitos? Es la disciplina utilizada para descubrir los requisitos, analizarlos, entenderlos, especificarlos y validarlos de forma colaborativa, gestionando los cambios a lo largo del ciclo de vida. Permite alinear a los stakeholders en: Una visión compartida Unos objetivos Unas expectativas. Reduce el riesgo de que un sistema sea rechazado por los usuarios una vez desarrollado Una Gestión y Definición de Requisitos eficiente permite: Mostrar un nivel de disciplina en el proceso de desarrollo Dar un mejor soporte a la Gestión de Cambios Ganar una mayor eficiencia en las pruebas Reducir los problemas de mantenimiento.

Gestión y Definición de Requisitos Requisitos RDM Gestión y Definición de Requisitos

La realidad de los proyectos software En 2004, el Chaos Report de Standish Group vaticinaba una mejora continuada en el número de proyectos software que terminaban con éxito. ¿Pero qué ha ocurrido en realidad? Nota: Standish Group, en su Chaos Report considera como variables de éxito la entrega en tiempo y coste, la calidad de los sistemas entregados, y el cumplimiento de las necesidades del usuario (alcance)

La realidad de los proyectos software Evolución de los resultados del análisis Chaos Report. En 2004, diferentes analistas ya predecían este comportamiento: Fuente: TynerBlain.com

La realidad de los proyectos software En los últimos 15 años se han introducido importantes mejoras en el desarrollo de software, especialmente en las etapas de gestión de proyectos, codificación y pruebas: Uso de modelos estadísticos en la Gestión de Proyectos Uso de metodologías ágiles y evolutivas. Lenguajes de programación más potentes y multiplataforma Herramientas de desarrollo rápido Aplicación de técnicas de ingeniería maduras Patrones de diseño Reutilización Model Driven Development Análisis estático de código … Automatización de pruebas funcionales y de rendimiento Pero la mayor fuente de defectos sigue siendo los Requisitos!! Se continúa siendo “artesano” en lugar de aplicar técnicas maduras de Ingeniería de Requisitos.

Algunos datos interesantes… Causas de los defectos Esfuerzo dedicado a corregir los defectos Coste relativo de solucionar un defecto La importancia de los Requisitos Fuentes: James Martin, Barry Boehm

Conclusiones Cada vez se produce mejor software, más complejo y de mayor calidad. Pero los problemas persisten en el front end: la comunicación entre negocio y tecnología. Los Requisitos son a menudo ambiguos, confusos, incompletos o contradictorios. Descubrimos los problemas demasiado tarde, aumentando el retrabajo… … y los proyectos continúan fallando. Por muy buenos que seamos en desarrollo, si las necesidades no se comunican correctamente, el sistema no podrá cumplirlas… … y el objetivo de cualquier software es dar respuesta a necesidades de negocio! El foco en la Ingeniería de Requisitos ha sido la documentación y la trazabilidad. Pero … ¿para qué sirve documentar y trazar 500 Requisitos si 150 de ellos son deficientes? Una mejor Gestión y Definición de Requisitos permite: Mejores decisiones de diseño y de arquitectura. Un menor retrabajo, porque se entienden los Requisitos antes de comenzar el desarrollo. Una mayor posibilidad de reutilizar Requisitos entre proyectos Una reducción de las asunciones del equipo de desarrollo. Una mayor eficiencia de las pruebas, reduciendo el riesgo, mejorando la calidad y permitiendo la automatización.

¿Por qué MS Excel y MS Word NO son suficientes? Muchas razones, pero en particular … No hay capacidad multiusuario No existen atributos No hay historial No hay modelado No existe la posibilidad de hacer análisis o informes No hay trazabilidad No existe proceso entre otros...

¿Por qué MS Excel y MS Word NO son suficientes? Los malos requisitos son como una bomba de relojería defectuosa Nunca sabes cuándo van a explotar!

¿Cómo puede ayudarte la Ingeniería de Requisitos Invertir en herramientas de requisitos permite: Mejorar la productividad a través de la reutilización, la reducción del “retrabajado” y un aumento de la calidad. Reducir costes de Ingeniería mediante la reutilización y la disminución del “retrabajado”. Aumentar los beneficios con un menor time-to-market y productos más competitivos. Mantener la competitividad mejorando los procesos de ingeniería en cuanto a eficiencia y eficacia. Ayudando a alinear los esfuerzos de Ingeniería con las necesidades de negocio. Agilizar los procesos mejorando la trazabilidad y el análisis de impacto.

¿Qué es IRQA? 17

¿Qué es IRQA? Áreas cubiertas por IRQA ACTIVIDADES CONTRATO GESTIÓN DE PROVEDORES DISEÑO Y ACTIVIDADES DE INGENIERÍA ANÁLISIS PRUEBAS DE VALIDACIÓN PRUEBAS DE ACEPTACIÓN REQUISITOS DE USUARIO DISEÑO PRUEBAS DE INTEGRACIÓN PRUEBAS UNITARIAS CONSTRUCCIÓN Cubierto por IRQA Cubierto por IRQA 18

¿Qué es IRQA? Las soluciones Customer Provider eXchange IRQA Requirements Communication Visual Prototyper Prototype and simulate sw reqs IRQA Face. J-IRQA Face – COM & Java API IRQA Requirement Definition & Management (RDM) Report Manager Reporting IRQA Quality Analyzer Semantic Analysis Existing Integrations Project Management (MS Project) Requirements Driven Testing Test Test Director Test Bench Driven Design Enterprise Architect IBM RSM/RSA ARTiSAN Studio SCM (SCC) (Subversion, etc) USER MANAGEMENT (NT, LDAP) IRQA Integration Platform External Elements Other Tools Propietary Tools Comm. Tools 19

¿Qué es IRQA? IRQA es el entorno… Gráfico Ingeniería de Requisitos Entorno Integrado 20

Requisitos, servicio o pruebas (Estándares –LOPD–, Usabilidad, etc.) ¿Qué es IRQA? Reutilización Producto Silver PROYECTO ORIGEN Listados de elementos Requisitos, servicio o pruebas (Estándares –LOPD–, Usabilidad, etc.) Producto Gold Conjuntos de elementos trazados Requisitos, servicio, pruebas y trazabilidad (Funcionalidad –Login–, Interfaces, etc.) 21

Integración con Visual Studio 2005 22

Próxima integración con Team Foundation Server PRUEBAS REQUISITOS SERVICIOS (Requisitos, Servicios, Pruebas y trazabilidad) SINCRONIZACIÓN SINCRONIZACIÓN (Requisitos, Servicios, Pruebas y trazabilidad) WORK ITEMS

Próxima integración con Team Foundation Server Introducción La integración consistirá en un plugin desarrollado con el nuevo SDK de IRQA Podrá ser utilizado localmente o establecido como corporativo para todos los usuarios del proyecto

Próxima integración con Team Foundation Server Exportar requisitos Exportará requisitos como Work Items, con la opción de: Añadir Actualizar Borrar Exportará trazabilidad de requisitos con: Requisitos Los motivos serán tipos en TFS Servicios Escenarios de prueba Se mapearán atributos y valores a los correspondientes en TFS Selección de la carpeta destino La información de los requisitos sincronizada será: Código, Nombre, Descripción, Jerarquía y atributos

Próxima integración con Team Foundation Server Exportar Servicios (Casos de Uso) Exportará servicios como Work Items, con la opción de: Añadir Actualizar Borrar Exportará trazabilidad de servicios con: Requisitos Escenarios de prueba Se mapearán atributos y valores a los correspondientes en TFS Selección de la carpeta destino La información de los servicios sincronizada será: Código, Nombre, Descripción, y atributos

Próxima integración con Team Foundation Server Exportar escenarios de prueba Exportará escenarios de prueba como Work Items, con la opción de: Añadir Actualizar Borrar Exportará trazabilidad de escenarios de prueba con: Requisitos Servicios Se mapearán atributos y valores a los correspondientes en TFS Selección de la carpeta destino La información de los requisitos sincronizada será: Código, Nombre, Descripción, pasos, jerarquía y atributos

Próxima integración con Team Foundation Server Importar requisitos, servicios y escenarios de prueba Se podrá importar de vuelta y sincronizar requisitos, servicios y escenarios de prueba creados o modificados en TFS Se podrá importar de vuelta la trazabilidad establecida en TFS entre requisitos, servicios y pruebas Se podrá seleccionar la partición de acceso y el bloque destino en IRQA Esto permitirá establecer mecanismos de sincronización en ambos sentidos entre IRQA y TFS

Próxima integración con Team Foundation Server Guarar la configuración El plugin permitirá guardar la configuración en un fichero XML

Próxima integración con Team Foundation Server La integración proporcionará potentes capacidades para establecer y explotar la trazabilidad entre herramientas. El mecanismo de sincronización entre las herramientas permitirá que cada equipo sea capaz de centrarse en sus propias actividades, utilizando su propio conjunto de herramientas, mientras se beneficia de los resultados de las actividades de otros equipos, visualizando la información correspondiente en su propio entorno. 30