La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Ingeniería de Requisitos

Presentaciones similares


Presentación del tema: "Ingeniería de Requisitos"— Transcripción de la presentación:

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

2 Temas Principios y prácticas de Administración de Requisitos
Administrando los Cambios de Requisitos Trazabilidad de Requisitos

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

4 Actividades de Administración de Requisitos

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

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

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

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

9 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).

10 Control de Versiones de Requisitos
Lee la siguiente Historia. ¿Has tenido alguna experiencia similar? Comenta con el grupo.

11 Control de Versiones de Requisitos
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.

12 Control de Versiones de Requisitos
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.

13 Control de Versiones de Requisitos
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).

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

15 Atributos de Requisitos
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

16 Atributos de Requisitos
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.

17 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%” Hay una tendencia común entre los desarrolladores a ser muy optimistas en los progresos logrados

18 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”.

19 Status sugeridos 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

20 Status sugeridos 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

21 Temas Principios y prácticas de Administración de Requisitos
Administrando los Cambios de Requisitos Trazabilidad de Requisitos

22 Introducción Lea la siguiente Historia.
¿Ha vivido usted alguna experiencia semejante? Comente

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

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

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

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

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

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

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

30 El Proceso de Control de Cambios
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.

31 El Proceso de Control de Cambios
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.

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

33 Políticas de Control de Cambios
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.

34 Políticas de Control de Cambios
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.

35 Plantilla para definición del PCC
La definición del PCC se puede describir mediante esta plantilla. Adecúe la plantilla a sus necesidades.

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

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

38 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

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

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

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

42 Procedimiento del Análisis de Impacto
El A. de I. tiene tres aspectos: Entender las posibles implicaciones de hacer el cambio. Identificar todos los archivos, modelos y documentos que podrían tener que ser modificados si el equipo incorpora la petición de cambio. Identificar las tareas requeridas para implementar el cambio y estimar el esfuerzo necesario para completar las tareas.

43 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

44 Temas Principios y prácticas de Administración de Requisitos
Administrando los Cambios de Requisitos Trazabilidad de Requisitos

45 Introducción Lea esta Historia.
Comente la importancia de la trazabilidad en el proceso de Análisis de Impacto en los Cambios de Requisitos.

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

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

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

49 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).

50 Tipos de enlaces de requisitos

51 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”.

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

53 Algunos posibles enlaces de trazabilidad de requisitos

54 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á.

55 Motivaciones para la Trazabilidad de Requisitos
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.

56 Motivaciones para la Trazabilidad de Requisitos
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.

57 Motivaciones para la Trazabilidad de Requisitos
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.

58 Motivaciones para la Trazabilidad de Requisitos
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.

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

60 Ejemplo de Matriz de Trazabilidad
RU RF Elemento de Diseño Módulo de Código Caso de Prueba CU-28 Catalog.query.sort Clase Catalogo Catalog.sort() Search.7 Search.8 CU-29 Search.12Search.13 Search.14 Esta información se debe ir incluyendo conforma avanza el proyecto

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

62 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”

63 Matriz de Trazabilidad: CU-RF
Req. Funcionales Casos de Uso CU-1 CU-2 CU-3 RF-1 <- RF-2 RF-3 RF-4 RF-5

64 Responsables de mantener la trazabilidad-quién tiene la información
Tipo de Objeto Fuente Tipo de Objeto Destino Fuente de Información Caso de Uso Requisito Funcional Analista Caso de Prueba Ingeniero de Prueba Elemento de la Arquitectura Software Arquitecto de Software Otros elementos de Diseño Diseñador o desarrollador Elemento de Diseño Código Desarrollador Regla de Negocio

65 Procedimiento para Trazabilidad de Requisitos
Seleccionar las relaciones de enlace que deseas definir (usa el diagrama de relaciones posibles) Selecciona el tipo de matriz de trazabilidad que desea usar: 1 o más matrices. Identifica las partes del producto para las cuales deseas mantener información de trazabilidad.

66 Procedimiento para Trazabilidad de Requisitos
Modifica tus procesos y checklist para recordar a los desarrolladores que actualicen los enlaces después de implementar un requisito o un cambio aprobado. 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í.

67 Procedimiento para Trazabilidad de Requisitos
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. 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

68 Procedimiento para Trazabilidad de Requisitos
Conforme avanza el desarrollo, que cada participante provea la información de trazabilidad por cada unidad pequeña de trabajo. Audita periódicamente la información de trazabilidad para asegurar que está actualizada.


Descargar ppt "Ingeniería de Requisitos"

Presentaciones similares


Anuncios Google