Requisitos mutantes seminario

The Requirements Week

Seminario Practicando Requisitos

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

8 de Junio de 2010 www.visuresolutions.com

Practicando Requisitos

Agenda

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

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


Agenda




¿Le son familiares estas situaciones?

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.




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!




a
e cesit
e nte n
ue el cl i
Lo q Sorpresa!
Lo qu Requisitos mutantes!
e el d
esarr
ollad
or co
n st r u
ye

Tiempo



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…




Stakeholders

Analista Requisitos Diseño Desarrollador

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



Agenda

4. ¿Problemas de comunicación?



¿Cuál es la solución?

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 (International
Requirements Engineering Board )
Disponer de Herramientas



¿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
Contexto Asset
Actual y legislativo Library

Modelos
Madurez

Requirements
Capability
Model

Evaluaciones Technical
Visure
Asset
University
Library



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

NIVELES DE CAPACIDAD
Se realizan modelos de negocio: clases conceptuales, casos de uso de
Nivel 5 negocio, diagramas de secuencia, etc.
Modelizado Se realizan modelos del funcionamiento del sistema a desarrollar:
casos de uso, escenarios, prototipos, etc.
Gestión del cambio y

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

Se asegura que los requisitos son verificables.
Nivel 3
Se trazan los requisitos con las pruebas de aceptación y verificación.
Trazado inicial
Se trazan los requisitos con las etapas del proyecto.
Se establecen los niveles de requisitos a tratar (requisitos de usuario,
de sistema, de subsistema, etc.), y los tipos de requisitos (funcionales,
Nivel 2 no funcionales.)
Proceso Definido Se definen las relaciones de trazabilidad entre requisitos.
Se establece el proceso de gestión de los requisitos de los distintos
niveles (ciclo de vida, responsables de cada estado, etc.)
Los requisitos están identificados con códigos únicos, redactados de
Nivel 1
forma adecuada y caracterizados con algunos atributos básicos
Estructurado
(origen y prioridad)
Nivel 0 Los requisitos están recogidos en documentos y no están
No Estructurado estructurados.



Disponer de un proceso

• 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.

No tiene relación con
las artes
adivinatorias …
… ni con la
magia …



Proceso. Ciclo de vida de Requisitos

Alcance Información

Especificación
de requisitos

Necesidades

R
ev
ión

is
ió
vis

n
1 4
Re

Captura Validación

2 3
Análisis Especificación
n
is ió

Re
v
Re

vis
ión



La Captura

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
Stakeholders
humanas para la captura de los requisitos.

Analista Requisitos Diseño Desarrollador



El Análisis

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.



La Especificación

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.
metodológicas empleadas para la especificación de los
requisitos.



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.).
metodológicas empleadas.



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.
Requisitos de Usuario

Requisitos de Sistema Inputs
Técnicas

Diseño
Outputs
Requisitos de Sub-Sistema

Diseño de Sub-Sistema

Implementación



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

Alta Prioridad
Urgente Debe ser incluido
en la próxima release

Media Prioridad Baja Prioridad
No Urgente Debe ser incluido pero Sería bueno que
puede esperar pudiéramos incluirlo

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



Estimando la prioridad para cada requisito

• Definimos una priorización basada en tres componentes:
Valor relativo para el cliente
Coste
Riesgo

Requisito Beneficio si está Penalización si Total (Beneficio + Valor %
presente no está (1-9) Penalización)
(1-9)

1

2

3



Estimando la prioridad para cada requisito

Procedente de la Procedente de la
planificación gestión de riesgos

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% --



Análisis de Impacto

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



La Trazabilidad

¡La trazabilidad
es
imprescindible!



La Trazabilidad

Permite la visibilidad bidireccional entre las relaciones

Necesidades Requisitos Requisitos Elementos Código
De usuario De Sistema de Diseño

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

16
Number of Req. Changes

30
14

Number of Req. Changes
12 25
10 Marketing
20
Management
8
15 Customer
6 SW Group
4 10 Other Eng.
2 5 Testing
0
0
0 5 10 15 20 Source
Weeks After SRS was Baselined



La Formación y las Herramientas

1. Formación
Disponer de planes de formación
adecuados 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 (International
Requirements 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.




3. La certificación IREB es uno de los 4
ISAQB/ISTQB/
IREB NTCCM/ISQI/
ISSECO
pasos requeridos para obtener la
certificación QAMP (Quality
Assurance Management
ISTQB
Professional
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?



¿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



¿Problemas de comunicación?

¿Problemas de
comunicación?
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.



Algunos ejemplos

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



¿PREGUNTAS?
¡Muchas gracias!
amanchon@visuresolutions.com


Requisitos mutantes seminario

Recommended

Recommended

More Related Content

Similar to Requisitos mutantes seminario

Similar to Requisitos mutantes seminario (12)

Requisitos mutantes seminario