1 Ingeniería de Requisitos Tema 3: Administración de Requisitos.

1

Ingeniería de Requisitos

Tema 3: Administración de Requisitos

Temas

Principios y prácticas de Administración de Requisitos

Administrando los Cambios de Requisitos

Trazabilidad de Requisitos

2

Introducción

Una vez revisados y aprobados los requisitos, estos constituyen la línea base para el esfuerzo de desarrollo: un acuerdo entre el grupo de desarrollo y los clientes.

La Administración de Requisitos incluye todas las actividades que mantienen la integridad, exactitud y actualidad del acuerdo de requisitos conforme el proyecto progresa.

3

Actividades de Administración de Requisitos

4

Actividades de Administración de Requisitos

Las actividades incluyen: Controlar los cambios a la línea base de

requisitos. Mantener los planes del proyecto

actualizados con los requisitos. Controlar las versiones tanto de los requisitos

individuales como de los documentos de requisitos.

Monitorear los enlaces lógicos entre requisitos individuales y otros productos de trabajo del proyecto.

5

Los cambios en requisitos

Un equipo de desarrollo que acepta nuevos cambios propuestos a requisitos podría no ser capaz de cumplir con los compromisos de tiempo y calidad.

El líder del proyecto debe negociar los cambios con estos compromisos con los administradores, clientes y stakeholders afectados.

6

Los cambios en requisitos

El proyecto puede responder a nuevos requisitos o cambios en varias formas: Diferir requisitos de baja prioridad Obtener nuevo personal Forzar trabajo extra, preferiblemente con pago,

por un periodo breve de tiempo Extender la calendarización para acomodar la

nueva funcionalidad Sacrificar la calidad con la presión de terminar en

la fecha comprometida (suele ser la reacción por defecto).

7

La Línea Base de Requisitos

Es el conjunto de RF y RNF que el equipo de desarrollo se ha comprometido implementar en un release específico.

La LB da a los stakeholders un entendimiento compartido de las capacidades y propiedades que esperan ver en el release.

8

La Línea Base de Requisitos

En el momento en que se establece la LB ésta se debe colocar bajo el Control de Cambios.

Cambios posteriores se deberán realizar sólo a través del Proceso de Control de Cambios definido.

Los requisitos que están en la línea base se deben distinguir de cualquier otro que no lo esté (draft).

9

Control de Versiones de Requisitos

Lee la siguiente Historia. ¿Has tenido alguna experiencia

similar? Comenta con el grupo.

10


El Control de Versiones es un aspecto esencial de la Administración de la especificación de Requisitos y otros documentos del proyecto.

Cada versión de los documentos de requisitos deben identificarse de forma única.

11


Cada miembro del equipo debe ser capaz de acceder a la versión actual de los requisitos y los cambios se deben documentar y comunicar a todos los afectados.

Para minimizar confusión, conflictos o errores de comunicación, permita que sólo individuos designados actualicen los requisitos y asegúrate de cambiar el identificador de versión cada vez que un requisito cambie.

12


Cada versión de los documentos de requisitos deben incluir una historia de revisiones que identifique los cambios hechos, la fecha del cambio, el individuo que hizo el cambio y la razón del cambio.

Un posible esquema de numeración (manual): Version 1.0 draft 1 Version 1.0 draft 2 Version 1.0 draft x Version 1.0 aprobada Version 2.0 draft 1

Se puede utilizar una herramienta también (tipo CVS o SVN).

13

Atributos de Requisitos

Piensa en cada requisito como un objeto con propiedades que se distingue de otros requisitos.

Además de su descripción textual debería contar con atributos asociados con el.

Los atributos establecen el contexto y trasfondo del requisito más allá de la descripción de la funcionalidad esperada.

14


Considera, por ejemplo: Fecha de creación del requisito Número de versión actual Autor que escribió el requisito Persona responsable de asegurar que el requisito

se satisfizo. Persona propietaria del requisito o una lista de

stakeholders Status del requisito Origen o fuente del requisito Justificación del requisito

15


Considera, por ejemplo: Subsistema (o subsistemas) a los cuales se asigna

el requisito Número de release al cual se asigna el requisito Método de verificación a utilizar o criterio de

aceptación Prioridad de implementación Estabilidad (un indicador de que tan probable es de

que cambie el requisito en el futuro) Selecciona el subconjunto más pequeño

de atributos que ayude a manejar los requisitos lo mejor posible.

16

Monitoreando el Status de los Requisitos

“¿Cómo vas con ese subsistema, Jackie? Preguntó Dave”

“Muy bien, Dave. Llevo hecho un 90%”“Pero, ¿No ere ese tu avance hace un par de

semanas? Pregunt desconcertado Dave”“Así pensaba, pero ahora estoy seguro de que

he hecho un 90%”

17

Hay una tendencia común entre los desarrolladores a ser muy optimistas

en los progresos logrados

Monitoreando el Status de los Requisitos

Monitorear el Status de cada RF a lo largo del proyecto ofrece una valoración más exacta del avance del proyecto.

Monitorea el Status de cada RF contra lo que se espera sea “completo”.

18

Status sugeridos

19

Status Definición

Propuesto El requisito ha sido solicitado por una fuente autorizada

Aprobado El requisito ha sido analizado, se ha estimado su impacto y se ha asignado a la línea base. Los stakeholders clave han acordado incorporar el requisito, y el grupo de desarrollo se ha comprometido a implementarlo

Implementado El código que implementa el requisito se ha diseñado, escrito y probado. El requisito se ha trazado a los elementos pertinentes de diseño y código

Status sugeridos

20

Status Definición

Verificado El funcionamiento correcto del requisito implementado se ha confirmado en el producto integrado. El requisito se ha trazado a los casos de prueba pertinentes. El requisito se considera ahora completo

Borrado Un requisito aprobado se ha removido de la línea base. Incluya una explicación de porqué y quién tomó la decisión de eliminarlo

Rechazado El requisito fue propuesto pero no se planeó su implementación en cualquier release próximo. Incluya una explicación de porqué y quién tomó la decisión de rechazarlo

Temas




21

Introducción

Lea la siguiente Historia. ¿Ha vivido usted alguna experiencia

semejante? Comente

22

Introducción

Muchos desarrolladores se han encontrado en situaciones en las que un cambio aparentemente simple resulta más complicado de lo esperado.

Son casos en los que los cambios se introducen “por la puerta trasera” sin ser aprobados por los stakeholders.

23

Introducción

Una organización seria debería asegurar que: Los cambios propuestos a requisitos se

evalúen cuidadosamente antes de comprometerse a ellos.

Los individuos apropiados toman decisiones de negocio informadas sobre las solicitudes de cambio.

Los cambios aprobados se comunican a todos los participantes afectados.

24

Introducción

A menos que los stakeholders del proyecto manejen los cambios durante el desarrollo, ellos no sabrán realmente que se les entregará y esto conducirá a un “vacío de expectativas”.

Entre más cerca se esté de la fecha de entrega, más se deben resistir los cambios al release, porque las consecuencias son más severas.

25

Introducción

Los cambios propuestos deben incluirse en el DERS para mantenerlo actualizado conforme el producto evoluciona.

Cuando se necesita hacer un cambio, inicia al nivel de abstracción más alto que el cambio toca y traza en cascada el impacto del cambio a través de los componentes relacionados. Ej.- Un cambio podría afectar al CU

y sus RF, pero no a un RN.

26

Gestión del Desplazamiento del Alcance (Scope creep)

El Desplazamiento del Alcance (Scope creeping) se presenta cuando surge nueva funcionalidad y modificaciones significativas después que se han “basificado” (line-based) los requisitos del proyecto.

El problema no es la aparición de nuevos requisitos (algo normal). El problema es la falta de control en el crecimiento.

27

Gestión del Desplazamiento del Alcance (Scope creep)

El primer paso en manejar el Scope creep es documentar la visión, alcance y limitaciones del nuevo sistema, como parte de los RN. Cada requisito o característica propuesto se debe evaluar contra los objetivos del negocio, visión del producto y alcance del proyecto.

CLAVE: Según (Weinberg,1995) la técnica más efectiva para controlar el SC es ser capaz de decir NO.

28

El Proceso de Control de Cambios

Un Proceso de Control de Cambios permite a los líderes de proyectos tomar decisiones informadas que provean el valor mayor al cliente mientras controlan los costos del ciclo de vida.

29


El proceso permite monitorear todos los cambios propuestos y ayuda a asegurar que no se pierdan o sobrepases.

Una vez estable (linebased) un conjunto de requisitos, se debe seguir este proceso para todos los cambios propuestos a la línea base.

30


Un PCC es un mecanismo de filtro para asegurar que el proyecto incorpora los cambios más apropiados.

El Proceso de Cambios debe ser bien documentado. Tan simple como sea posible y, sobre todo, efectivo.

31

Políticas de Control de Cambios

Todos los cambios de requisitos deben seguir el proceso.

Ningún trabajo de diseño o implementación, distinto a exploración de factibilidad, se deberá hacer sobre cambios no aprobados.

Una petición de cambios no garantiza que se hará. La decisión la tomará el Change Control Board (CCB).

El contenido de la base de datos de cambios estará visible a todos los stakeholders.

32


Cada cambio incluye un Análisis de Impacto.

Cada cambio de requisito incorporado deberá trazarse a una petición de cambio aprobada.

La justificación detrás de cada petición de cambio aprobada o rechazada se deberá registrar.

33


En teoría todas las peticiones de cambios (grandes o pequeñas) deberían pasar por el PCC.

En la práctica, el proceso debería incluir un “Fast-path” para peticiones de cambios expeditas, de bajo riesgo en un ciclo de decisión reducido.

34

Plantilla para definición del PCC

La definición del PCC se puede describir mediante esta plantilla.

Adecúe la plantilla a sus necesidades.

35

El Change Control Board (CCB)

El CCB es el cuerpo de personas, una o más, que decide cuales cambios de requisitos y nuevas características sugeridas aceptar para incluir en el producto.

El CCB también decide cuales defectos reportados corregir y cuando corregirlos.

36

El Change Control Board (CCB)

El CCB revisa y aprueba cambios a cualquier producto de trabajo “basificado”.

No debe ser una estructura “burocrática”, más bien efectiva.

Un CCB efectivo considerará los cambios propuestos y tomará las decisiones basado en el análisis de los impactos potenciales y beneficios de cada propuesta.

37

Miembros del CCB

No todos toman decisión, pero si deben estar informados (busca grupo reducido): Líder de proyecto. Analista de sistema. Desarrollo. Pruebas o QA Representantes del cliente Documentación de Usuario Soporte técnico o Help desk. Gestión de Configuración

38

Los cambios no son gratuitos:Análisis de Impacto

Debido a que a las personas no les gusta decir que “no”, es fácil acumular una gran cantidad de peticiones de cambios aprobadas pendientes.

39

Los cambios no son gratuitos:Análisis de Impacto

El Análisis de Impacto ofrece un entendimiento exacto de las implicaciones de un cambio propuesto.

Esto ayuda a que el equipo haga decisiones de negocios informadas sobre las propuestas a aprobar.

El análisis examina el cambio propuesto para identificar los componentes que podrían crearse, modificarse o descartarse y estimar el esfuerzo asociado con la implementación del cambio.

40

Procedimiento del Análisis de Impacto

El Jefe del CCB pide a un desarrollador con experiencia que realice el Análisis de Impacto para una propuesta específica de cambio.

41

Procedimiento del Análisis de Impacto

El A. de I. tiene tres aspectos:1. Entender las posibles implicaciones de

hacer el cambio.2. Identificar todos los archivos, modelos y

documentos que podrían tener que ser modificados si el equipo incorpora la petición de cambio.

3. Identificar las tareas requeridas para implementar el cambio y estimar el esfuerzo necesario para completar las tareas.

42

Checklist y Procedimientos para ayudar a el A. de I.

Estas listas pueden ayudar al Analista de Impacto a entender las implicaciones del cambio propuesto.

Este procedimiento puede ayudar a evaluar el impacto de un cambio propuesto

43

Temas




44

Introducción

Lea esta Historia. Comente la importancia de la

trazabilidad en el proceso de Análisis de Impacto en los Cambios de Requisitos.

45

Introducción

El Análisis de Impacto es mucho más fácil si se tiene un mapa que muestre donde fue implementado en software cada requisito o regla de negocio.

El Trazado de Requisitos documenta las dependencias y enlaces lógicos entre requisitos individuales y otros elementos del sistema.

46

Introducción

La información de Trazabilidad facilita el Análisis de Impacto ayudando a identificar todos los productos de trabajo que tendrían que modificarse para implementar el cambio propuesto de requisitos.

47

Trazando los requisitos

Los Enlaces de Trazabilidad permiten seguir la vida del requisito tanto hacia adelante como hacia atrás: del origen a la implementación.

Para permitir la trazabilidad, cada requisito deberá ser etiquetado de forma única y persistente de tal forma que pueda referenciarse sin ambigüedad a lo largo del proyecto.

48

Trazando los requisitos

Escriba los requisitos en estilo de grano fino, en lugar de crear párrafos grandes (con muchos RF que conduzcan a una explosión de elementos de diseño y código).

49

Tipos de enlaces de requisitos

50

Algunas implicaciones de estos enlaces

Los Casos de Prueba se derivan –se trazan- a requisitos individuales.

Si un “tester” detecta funcionalidad no esperada sin un requisito correspondiente, pudiera entonces: El Analista agregar esta funcionalidad

legítima O podrían ser código “Gold Plating”.

51

Algunas implicaciones de estos enlaces

Los enlaces de Trazabilidad ayudan a seguir la pista del antecesor, interconexión y dependencia entre requisitos individuales.

Esto ayuda a revelar la propagación resultante de un cambio cuando un requisito se borra o modifica.

Si existe trazabilidad entre el requisito y una unidad de trabajo, esas tareas se verán afectadas cuando el requisito se cambie o borre.

52

Algunos posibles enlaces de trazabilidad de requisitos

53

Motivaciones para la Trazabilidad de Requisitos

La Trazabilidad de Requisitos es una tarea manual intensa que requiere compromiso organizacional.

Mantener la información actualizada de los enlaces conforme se desarrolla y mantiene el sistema demanda disciplina.

Si la información de trazabilidad se torna obsoleta, lo más probable es que nunca se reconstruirá.

54


Beneficios de implementar trazabilidad de requisitos: Certificación: demostrar que los requisitos fueron

implementados (lo cual no garantiza que fueron implementados correctamente).

Análisis de Impacto de Cambios: sin Trazabilidad lo más probable es que se pase por alto elementos de sistema afectados por cambios en requisitos.

Mantenimiento: se facilita la elaboración de cambios correctos y completos durante el mantenimiento. Esto, a su vez, mejora la productividad.

55


Mas Beneficios : Monitoreo del Proyecto: permite mantener un

monitoreo exacto del estado de la implementación de la funcionalidad planeada.

Reingeniería: registrar las funciones de sistemas legados que se están reemplazando y su enlace a los nuevos requisitos y componentes software.

56


Mas Beneficios : Riesgos: cuando un miembro clave del equipo

se va y su conocimiento queda en los enlaces de trazabilidad.

Pruebas: cuando una prueba lleva a un resultado inesperado, los enlaces entre pruebas, requisitos y código apuntan a las partes del código que hay examinar para buscar los defectos.

57


Muchos de los beneficios son a largo plazo, reduciendo los costos del ciclo de vida aunque incrementen el costo de desarrollo (por el esfuerzo de mantener los enlaces).

La Trazabilidad de Requisitos es una inversión que pagará dividendos cuando tengas de extender, modificar o reemplazar el producto.

En realidad no es mucho trabajo si recolectas la información conforma procede el desarrollo; pero es tediosa y cara para un sistema completo sin trazabilidad previa.

58

Matriz de Trazabilidad

Es la forma más común de representar enlaces entre requisitos y otros elementos del sistema.

59

Ejemplo de Matriz de Trazabilidad

60

RU RF Elemento de Diseño

Módulo de Código

Caso de Prueba

CU-28 Catalog.query.sort Clase Catalogo

Catalog.sort() Search.7Search.8

CU-29 Catalog.query.sort Clase Catalogo

Catalog.sort() Search.12Search.13 Search.14

Esta información se debe ir incluyendo conforma avanzael proyecto

Cardinalidad entre enlaces

Uno a Uno: un elemento de diseño implementado en un módulo de código.

Uno a Muchos: un RF verificado con múltiples Casos de Prueba

Muchos a muchos: un CU que deriva múltiples RF y ciertos RFs a comunes a varios CU.

61

Variantes entre las Matrices de Trazabilidad

Una Matriz de Trazabilidad puede definir diferentes tipos de enlaces entre requisitos: Requisito-Requisito (del mismo tipo) Requisito-Requisito (de tipo distinto) Requisito-Caso de Prueba

Estos tipos de matrices pueden definir varios tipos de relaciones: “especifica/es especificada por”, “depende de”, “es padre de”, “restringe/es restringida por”

62

Matriz de Trazabilidad: CU-RF

63

Req. Funcionales

Casos de Uso

CU-1 CU-2 CU-2 CU-3

RF-1 <-

RF-2 <-

RF-3 <-

RF-4 <-

RF-5 <-

Responsables de mantener la trazabilidad-quién tiene la información

64

Tipo de Objeto Fuente

Tipo de Objeto Destino

Fuente de Información

Caso de Uso Requisito Funcional Analista

Requisito Funcional Requisito Funcional Analista

Requisito Funcional Caso de Prueba Ingeniero de Prueba

Requisito Funcional Elemento de la Arquitectura Software

Arquitecto de Software

Requisito Funcional Otros elementos de Diseño

Diseñador o desarrollador

Elemento de Diseño Código Desarrollador

Regla de Negocio Requisito Funcional Analista

Procedimiento para Trazabilidad de Requisitos

1. Seleccionar las relaciones de enlace que deseas definir (usa el diagrama de relaciones posibles)

2. Selecciona el tipo de matriz de trazabilidad que desea usar: 1 o más matrices.

3. Identifica las partes del producto para las cuales deseas mantener información de trazabilidad.

65


4. Modifica tus procesos y checklist para recordar a los desarrolladores que actualicen los enlaces después de implementar un requisito o un cambio aprobado.

5. Define convencionalismos de etiquetas que utilizarás para identificar de forma única todos los elementos del sistema de tal forma que se puedan enlazar entre sí.

66


6. Identifica los individuos que proveerán la información de enlace y la persona que coordinará las actividades de trazabilidad y gestión de datos.

7. Educa al equipo sobre los conceptos e importancia del trazado de requisitos, los objetivos de la actividad, donde se almacenarán los datos de trazabilidad y las técnicas para definir enlaces. Asegúrate que todos se comprometan en sus responsabilidades

67


8. Conforme avanza el desarrollo, que cada participante provea la información de trazabilidad por cada unidad pequeña de trabajo.

9. Audita periódicamente la información de trazabilidad para asegurar que está actualizada.

68

1 Ingeniería de Requisitos Tema 3: Administración de Requisitos.

Documents

Transcript of 1 Ingeniería de Requisitos Tema 3: Administración de Requisitos.