el curioso caso_de_los_requisitos_mutantes_2010

The Requirements Week

Seminario Practicando Requisitos

8 de Junio de 2010 www.visuresolutions.com

El curioso caso de los Requisitos MutantesAnabel Manchón, Directora de Servicios

www.visuresolutions.com Copyright 2008 © Visure Solutions, The Requirements Company - +34 91 806 17 13 - [email protected] - 28760 Tres Cantos MADRID 2

Practicando Requisitos

Agenda

1. ¿Le son familiares estas situaciones?

2. Requisitos sin cambios: ¿es posible?

3. ¿Cuál es la solución?



Agenda

1. ¿Le son familiares estas situaciones?2. Requisitos sin cambios: ¿es posible?3. ¿Cuál es la solución?



� La visión del proyecto y el alcance nunca son claramente definidos.

� Los clientes están demasiado ocupados para gastar su tiempo trabajando con los analistas o desarrolladores sobre los requisitos.

� Los clientes exigen que todos los requisitos sean críticos, y no los priorizan

� Los desarrolladores se encuentran ambigüedades y omisión de información cuando desarrollan los requisitos, y asícomienza la inventiva.

� Sus clientes firman (aprueban) los requisitos y luego los cambian continuamente.

¿Le son familiares estas situaciones?



� El alcance del proyecto aumenta a medida que se aceptan cambios en requisitos, pero el calendario no se modifica en plazos ni en recursos.

� Los cambios de requisitos se pierden e incluso no se conoce el estado de las peticiones de cambio.

� La funcionalidad es solicitada y construida, pero nunca usada.

Cuando ocurre esto ….

…. en el mejor de los casos, la especificación estásatisfecha,…

… pero el cliente no!




Tiempo

Lo que el cliente necesita

Lo que el desarrollador construye

Sorpresa!


Requisitos mutantes!



Características de los Requisitos

1. Características de los requisitos� Volátiles: inconstantes

� Mutantes: presentan alteraciones que se transmiten a otros requisitos

� Emergentes: surgen al ir analizando el sistema en profundidad.

� Colaterales: surgen como efecto de la inclusión de otros requisitos.

� Por compatibilidad: se añaden para adaptar el sistema a su entorno, debido a que el entorno cambia. Este entorno puede ser físico u organizacional (cambian las políticas, se producen cambios en las reglas y en los procesos de negocio)

2. La propia existencia del sistema va a generar nuevos requisitos por parte de los usuarios.



Agenda




4. ¿Problemas de comunicación?



Requisitos sin cambios: ¿es posible?

1. ¿Cuántos de sus proyectos mantienen sus requisitos invariables en el tiempo?

� La respuesta más común es pocos, muy pocos o incluso ninguno...

2. ¿Podemos tener requisitos sin cambios?

� Los requisitos inevitablemente van a evolucionar y cambiar.

Prepárese para los cambios … porque sin duda, ¡van a aparecer!




¿Por qué cambian los requisitos?

� Porque las necesidades de los usuarios varían en el transcurso del proyecto.

� Porque se producen cambios tecnológicos.

� Porque las restricciones del Sistema cambian.

� Porque el entorno y reglas de negocio evolucionan.

� Porque al analizar el problema, no se hacen las preguntas correctas a las personas correctas.

� Porque cambia el problema que se está resolviendo.

� Porque cambia el mercado en el cual se desenvuelve el negocio.





� Los requisitos son a menudo ambiguos, confusos, incompletos o contradictorios.

� Descubrimos los problemas demasiado tarde, aumentando el retrabajo y el coste…

Por muy buenos que seamos en desarrollo, si las necesidades no se comunican correctamente, el sistema no podrá cumplirlas…





¿No le recuerda al juego del teléfono estropeado?

Analista Requisitos Diseño Desarrollador

Stakeholders



Agenda




4. ¿Problemas de comunicación?



14

Mejorar la Comunicación:

� Disponer de un proceso de Requisitos definido y mantenido

� Formación en técnicas y habilidades humanas relativas a Requisitos

� Formación en metodología de Ingeniería de Requisitos

� Especialización de la profesión: Certificación IREB (InternationalRequirements Engineering Board )

� Disponer de Herramientas

¿Cuál es la solución?



¿Cuál es la solución?

1. ¿Qué gano si mejoro la comunicación?

� Mejores decisiones de diseño y de arquitectura.

� Menor retrabajo, porque se entienden los Requisitos antes de comenzar el desarrollo.

� 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 de las pruebas.

� Una reducción de riesgos y costes.

� Etc.



La Mejora del Proceso de Ingeniería de Requisitos.

Process

Asset

Library

Requirements

Capability

Model

Evaluaciones Visure

University

Technical

Asset

Library

Contexto

Actual y legislativo

Modelos

Madurez



El Modelo RCM

1.The Requeriments Capability Model (RCM) evalúa la idoneidad de la Capacidad del Proceso de Requisitos en 3 aspectos: Los PROCESOS, Las PERSONAS y la TECNOLOGÍA.

2. Método de Evaluación:

� La documentación de los Procesos de Gestión y Definición de Requisitos

� La documentación de los Proyectos en el marco de los Requisitos

� Entrevistas con el personal involucrado, de forma que todos los puntos de vista son tenidos en cuenta.

3. Prácticas:

� Ingeniería de Requisitos

� Control de Cambios

� Implantación Corporativa

� Reutilización



El Modelo RCM

Los requisitos están identificados con códigos únic os, redactados de forma adecuada y caracterizados con algunos atribut os básicos (origen y prioridad)

Nivel 1Estructurado

Se establecen los niveles de requisitos a tratar (r equisitos de usuario, de sistema, de subsistema, etc.), y los tipos de re quisitos (funcionales, no funcionales.)Se definen las relaciones de trazabilidad entre requ isitos.Se establece el proceso de gestión de los requisito s de los distintos niveles (ciclo de vida, responsables de cada estado , etc.)

Nivel 2Proceso Definido

Se asegura que los requisitos son verificables. Se trazan los requisitos con las pruebas de aceptac ión y verificación. Se trazan los requisitos con las etapas del proyect o.

Nivel 3Trazado inicial

Los requisitos se trazan con los elementos de diseñ o. Nivel 4Trazado

Se realizan modelos de negocio: clases conceptuales , casos de uso de negocio, diagramas de secuencia, etc. Se realizan modelos del funcionamiento del sistema a desarrollar: casos de uso, escenarios, prototipos, etc.

Nivel 5Modelizado

Los requisitos están recogidos en documentos y no e stán estructurados.

Nivel 0No Estructurado

NIVELES DE CAPACIDAD

Gestión del cambio y

reutilización



19

• La Ingeniería de Requisitos es la rama de Ingeniería de Sistemas que se ocupa del tratamiento, definición y gestión de las necesidades del usuario que debe satisfacer el sistema a construir.

Disponer de un proceso

No tiene relación con las artes

adivinatorias …… ni con la magia …



Proceso. Ciclo de vida de Requisitos

InformaciónAlcance

Necesidades

Especificación de requisitos

1 Captura

3 Especificación

2 Análisis

4Validación

Revisión

Rev

isió

n

RevisiónRev

isió

n



21

1. Explorar y averiguar cuáles son los requisitos mediante conversaciones con las personas implicadas, observación de los sistemas existentes, etc.

2. El proceso de construcción de un sistema se inicia con las primeras conversaciones entre usuarios y analistas, en las que ya empiezan a identificarse requisitos, que se van completando y refinando en fases posteriores.

El éxito o fracaso depende en gran medida de las habilidades humanas para la captura de los requisitos.

La Captura

Analista Requisitos Diseño Desarrollador

Stakeholders



1. Construir modelos conceptuales del problema y/o del sistema a desarrollar para ayudar a la comprensión de los requisitos.

2. Estos requisitos deben gestionarse a lo largo de todo el ciclo de vida del proyecto, se han de modelar de acuerdo a la metodología de referencia: diagramas de contexto, diagramas de flujo de datos, casos de uso, escenarios, diagramas de estados, diagramas de secuencia, etc.

El éxito o fracaso depende en gran medida de las técnicas metodológicas empleadas.

El Análisis



23

1. Es la etapa peor entendida dentro del ciclo de vida de sistemas, debido al carácter no mecanizable que le aporta la cercanía con el cliente humano. Es una etapa crucial, ya que, si los requisitos no son los correctos o no son bien comprendidos, el sistema que se construya tampoco seráel correcto. (Requisitos Mutantes).

2. Describir con precisión y formalizar los requisitos obtenidos para que puedan actuar como la base contractual de la relación entre usuarios y desarrolladores.

El éxito o fracaso depende en gran medida de las técnicas metodológicas empleadas para la especificación de los

requisitos.

La Especificación



24

La Validación

1. Se han de definir criterios para decidir si los requisitos son correctos, tanto individualmente (un requisito debe ser no ambiguo, realista, comprobable, etc.) como en conjunto (el conjunto de requisitos del proyecto debe ser completo, consistente, etc.).

El éxito o fracaso depende en gran medida de las técnicas metodológicas empleadas.



Requisitos de Usuario

Requisitos de Sistema

Diseño

Requisitos de Sub-Sistema

Diseño de Sub-Sistema

Implementación

Ciclo de vida de Requisitos

1. Las Técnicas son FUNDAMENTALES, nos aportan DETALLE, ya que van a dirigir CÓMO realizar las actividades y tareas fijadas en el proceso.

Inputs

Outputs

TTéécnicascnicas



El talón de Aquiles de la Ingeniería de Requisitos

¡Controlar los Cambios! 1. No controlar los cambios causa problemas

� Retrabajo, baja calidad, calendarios impredecibles, aumento de costes, etc.

� Especificaciones no satisfechas

� Requisitos Mutantes



Controlar los cambios

1. ¿Cómo controlar los cambios?

� Gestionar las versiones de las releases y los requisitos.

� Establecer líneas base de requisitos.

� Almacenar los requisitos con sus atributos.

� Priorizar los requisitos.

� Hacer seguimiento del estado de cada requisito.

� Trazar los requisitos a través del diseño, código y pruebas.

� Establecer un canal para realizar los cambios.

� Realizar un análisis de impacto ante los cambios.

� Disponer de métricas de control de cambios.

� Disponer de herramientas o templates.



Línea Base

1. Línea Base

� Es el conjunto de requisitos funcionales y no-funcionales que se van a implementar en una release específica.

� Es una versión aprobada de la especificación de requisitos del software.

2. Los requisitos antes de entrar en la Línea Base deben ser sometidos a un procedimiento de revisión formal.

3. Una vez entrado el requisito en la línea base cualquier cambio debe someterse al procedimiento de control de cambios.



Priorización

1. ¿En base a qué criterios podemos decidir qué requisitos forman parte de una release y qué hacer cuando estos criterios cambian?

� Es preciso disponer de criterios de priorización que, de una forma objetiva, nos ayuden a diferenciar unos requisitos de otros, así como poder diferenciar entre urgencia, criticidad e importancia.



Priorización

1. No todo puede estar en el “top” de las prioridades:

� MoSCoW (Must have, Should have, Could have, Won’t have)

2. Debemos diferenciar entre diferentes criterios de priorización:

� Urgente: Relativo a la prisa

� Importante: Relativo a la funcionalidad del sistema

� Criticidad: Relativo al funcionamiento del negocio

3. Hay que definir los posibles valores, ponderación y significados para cada criterio de priorización.



Priorización

1. Asignar prioridades nos ayudarán a:

� Trabajar desde el principio en lo más prioritario

� Tomar decisiones

� Negociar y añadir cambios a los requisitos

� Entender qué requisitos son más importantes y más urgentes



Una posible escala para priorizar

Importante No Importante

No Urgente

UrgenteAlta Prioridad

Debe ser incluido

en la próxima release

Baja PrioridadSería bueno que

pudiéramos incluirlo

Media PrioridadDebe ser incluido pero

puede esperar

[Covey, Stephen R. The 7 Habits of Highly Effective People. Simon & Schuster, 1989.]



Requisito Beneficio si está presente

(1-9)

Penalización si no está (1-9)

Total (Beneficio + Penalización)

Valor %

1

2

3

Estimando la prioridad para cada requisito

• Definimos una priorización basada en tres componentes:

� Valor relativo para el cliente

� Coste

� Riesgo



Requisito Valor % Coste % Riesgo % Prioridad

1 A L X A/(L+X)

2 B M Y B/(M+Y)

3 C N Z C/(N+Z)

-- 100% 100% 100% --

Estimando la prioridad para cada requisito

Procedente de la planificación

Procedente de la gestión de riesgos



1. Evaluar el Impacto del cambio en términos de:� Coste

� Funcionalidades del sistema

� Impacto para el cliente y stakeholders externos

2. Especificar los QUIENES:� QUIEN es el que tiene una necesidad concreta.

� QUIEN ha aprobado que se implemente una necesidad.

� QUIEN va a realizar los cambios.

3. Especificar los CÓMOS:� CÓMO cambia el calendario y presupuesto del proyecto.

� CÓMO cambian los riesgos del proyecto.

� CÓMO cambian otros elementos del proyecto (requisitos, elementos de diseño, pruebas, etc.)

Análisis de Impacto



4. Determinar los componentes del sistema que se ven afectados:

� Otros requisitos

� Diseños, código, pruebas, documentación de usuario, pantallas, etc.

� Planes (calendarios, presupuestos, riesgos, etc.), hardware, otros sistemas…

5. Entender todas las implicaciones del cambio

� Conflictos con otros requisitos

� Viabilidad, coste, recursos

6. Identificar las tareas necesarias, estimar el esfuerzo, coste y calendario

Análisis de Impacto



La Trazabilidad

¡La trazabilidades

imprescindible!



La Trazabilidad

Permite la visibilidad bidireccional entre las relaciones

RequisitosDe usuario

Elementos de Diseño

Necesidades RequisitosDe Sistema

Código

Pruebas



Las métricas

Las métricas proporcionan una visión objetiva acerca de quéestá pasando …

…y nos dirigen para poder encontrar el porqué de los cambios

Weeks After SRS was Baselined

Num

ber

of R

eq. C

hang

es

0

2

4

6

8

10

12

14

16

0 5 10 15 200

5

10

15

20

25

30

Num

ber

of R

eq. C

hang

es

Source

Marketing

Management

Customer

SW Group

Other Eng.

Testing



La Formación y las Herramientas

1. Formación

� Disponer de planes de formaciónadecuados para capacitar en proceso, técnicas y habilidades interpersonales para facilitar la realización de las actividades de Ingeniería de Requisitos y facilitar la comunicación.

� Especialización de la profesión: Certificación IREB (InternationalRequirements Engineering Board )



La Formación y las Herramientas

2. Herramientas

� Facilitar un entorno común de trabajo

� Eliminar documentos de difícil mantenimiento.

� Gestionar el ciclo de vida de los Requisitos.

� Facilitar la transición entre Negocio (documentos) y Tecnología (repositorio).



Especialización. Certificación IREB

1. El International Requirements Engineering Board (IREB) es una organización internacional que persigue la profesionalización de la Ingeniería de Requisitos como disciplina clave de la Ingeniería de Software y de Sistemas.

� IREB ha creado un programa de certificación profesional en tres niveles (Foundation, Advanced, Expert) equivalente a la certificación de reconocido prestigio, ISTQB, en el área de Pruebas: Certificación IREB.




IREB

ISTQB

ISAQB/ISTQB/NTCCM/ISQI/

ISSECO

3. La certificación IREB es uno de los 4 pasos requeridos para obtener la certificación QAMP (QualityAssurance ManagementProfessional http://www.qamp.org/).

4. La certificación IREB se basa en el conocimiento del programa de certificación Syllabus, que es actualizado en base a las experiencias y prácticas contrastadas como exitosas en el día a día.

5. La validez de la certificación IREB no expira.



Foundation: � Adquirir el conocimiento práctico necesario para el éxito en la disciplina de la Ingeniería de Requisitos, a través de ejercicios especialmente diseñados para mostrar las problemáticas más habituales de esta disciplina.

� Transmitir los conceptos fundamentales de la Ingeniería de Requisitos que son igualmente válidos para cualquier dominio o industria, y de forma independiente a la metodología y procesos de desarrollo utilizados.

� Mostrar métodos, técnicas y prácticas maduras y probadas en la Ingeniería de Requisitos.

� No existen exigencias para optar a este nivel de certificación. Debe superar 1 examen oficial





Advanced:� Este nivel ofrece módulos de especialización, cada uno de ellos enfocado a una problemática, actividad, dominio o proceso:• Captura de Requisitos

• Gestión de Requisitos

• Definición de Procesos de Ingeniería de Requisitos

• Especificación de Requisitos

• Verbalizar requisitos textuales

� Es necesario el nivel Foundation para optar a este nivel. El examen se realiza para cada uno de los módulos elegidos.

Expert: (actualmente en definición.)

� Certifica el conocimiento especializado en dominios o métodos determinados. Para optar a este nivel, seránecesario haber obtenido la certificación Advanced en 3 o más módulos.



¿Problemas de comunicación?




¿Problemas de Comunicación?

Un juego (10 voluntarios)

1. El primer participante piensa en una frase y se la dice al oído y rápidamente al segundo participante, y éste a un tercero y éste a un cuarto y éste a un quinto, y así hasta un noveno participante.

2. El noveno participante deberá hacer un dibujo basado en esa frase.

3. El décimo participante deberá decir una frase basada en el dibujo del noveno.



¿Problemas de Comunicación?

El loro y el mono están fuera de la jaula





En determinadas ocasiones nos acostumbramos a pensar en una sola dirección, dando por cierta la respuesta más obvia

a la problemática que se nos plantea.



1. A Pepito se le cayó un anillo dentro de una taza llena de café, pero el anillo no se mojó. ¿Cómo puede ser?

El café era en grano

2. ¿Cuántas veces podría restarse el número 1 del número 1111?

Una vez, pues entonces el número será 1110

3. En un árbol hay siete pajaritos. Pepito dispara y mata a dos pajaritos. ¿Cuántos pajaritos quedan?

Ninguno, los que quedan huyen del susto

Algunos ejemplos



4. Este loro es capaz de repetir todo lo que oiga, le aseguró a una señora el dueño de una pajarería. Pero una semana después, la señora que lo compró estaba de vuelta en la tienda, protestando porque el loro no decía ni una sola palabra. Y sin embargo, el vendedor no le había mentido. ¿Puedes explicarlo?

El loro era sordo

5. Un avión comercial va volando y en el instante en que cruza la frontera entre España y Portugal le empiezan a salir los dientes a un bebé que viaja con sus padres. Con estos datos, ¿puedes deducir dónde le salen los dientes al bebé?

En la boca

Algunos ejemplos



52

¿PREGUNTAS?

¡Muchas [email protected]

el curioso caso_de_los_requisitos_mutantes_2010

Travel

los requisitos son

los requisitos inevitablemente

practicando requisitos

los requisitosvoltiles

los casos

por qu cambian los requisitos

visure solutions

requirements company