Ingeniería de Requerimientos

Ingeniería de Requerimientos
Administración de Requerimientos

Si no controlamos el cambio, él nos controlará a nosotros
Si no controlamos el cambio, él nos controlará a nosotros. Y eso nunca es bueno.

Ingeniería de Requerimientos Especificación Validación Análisis Adquisición Desarrollo Administración Control de Versiones Seguimiento Control de Cambios

Temas Definiciones Control de cambios Control de versiones Seguimiento
Otros Pasos a seguir

Definiciones Los requerimientos cambian constantemente
Nuevas regulaciones Especificaciones con errores Nuevas necesidades Cambios en el negocio Cambios en el proyecto

Definiciones Tipos de requerimientos volátiles Mutables Emergentes
Debidos a cambios en el ambiente Emergentes Surgen por un mejor entendimiento del problema Consecuencia Se originan por el uso mismo del sistema De compatibilidad Por cambios en el proceso, dentro de la organización

Definiciones La administración de requerimientos es una aproximación sistemática para identificar, organizar, comunicar y administrar los requerimiento cambiantes de una aplicación de software. Alan M. Davis y Dean A. Leffingwell. Usando Administración de Requerimientos para Acelerar la Liberación de Aplicaciones de Mayor Calidad, 1995

Definiciones Cuando se presentan nuevos requerimientos (o cambios a los existentes) El plan establecido cambia Tiempos Costos Se debe definir una estrategia Posponer requerimientos Contratar más personas, trabajar tiempo extra Ajustar el plan

Definiciones Involucra
Controlar los cambios a la línea base de los requerimientos Mantener los planes del proyecto actualizados Controlar las versiones de los requerimientos Conocer el estado de los requerimientos Administrar los enlaces lógicos entre los requerimientos y otros productos de trabajo

Definiciones Beneficios Mejor control de proyectos complejos
Mejorar la calidad Satisfacción del cliente Reducir costos y retrasos del proyecto Mejor comunicación en el equipo Conformidad con estándares

Administración de requerimientos
Definiciones Actividades Control de cambios Control de versiones Seguimiento Administración de requerimientos Rastreo Estado Métricas Karl Wiegers. Software Requeriments, 2003 Charlene Gross. Why Isn’t Someone Coding Yet (WISCY)?, 2004

Definiciones Se necesita un repositorio central de requerimientos, con: Requerimientos Atributos Estado de los requerimientos Otra información de administración pertinente

Definiciones Algunos atributos Fuente Prioridad Estado Autor(es)
Responsable(s) Fechas Creación Cambios

Definiciones Algunos atributos Métricas – Criterios de éxito
Número de Versión Relaciones con otros requerimientos Objetivos, Casos de uso Relaciones con otros productos Clases, Módulos, Pruebas Estabilidad

Definiciones El repositorio facilita las revisiones
¿Cuántos requerimientos hay? ¿Cuántos son de alta prioridad? ¿Cuándo serán implementados? ¿Cuáles requerimientos han cambiado desde la última revisión? ¿Quiénes son responsables de los cambios? ¿Cuál es el impacto (costos) estimado? Alan M. Davis y Dean A. Leffingwell. Usando Administración de Requerimientos para Acelerar la Liberación de Aplicaciones de Mayor Calidad , 1999

Control de cambios Proceso que ayuda a garantizar:
Los cambios son consistentes con los objetivos Los cambios se comunican a Desarrolladores Usuarios Otras personas afectadas Se toman las acciones correctivas en planes y productos de trabajo

Control de cambios Elementos involucrados Línea base de requerimientos
Solicitud de cambio Análisis de impacto Orden de cambio Documentos de validación/verificación Comunicación de resultados

Control de cambios Línea base de requerimientos
Conjunto de requerimientos que se implementarán (en una versión dada) Antes de ser una línea base está en constante evolución Después de una aprobación los cambios deben pasar por un proceso formal Control de cambios Control de versiones

Comité de control de cambios
Análisis de impacto Técnico, tiempo, necesidad, dinero Comité de control de cambios Requerimiento aceptado Requerimiento rechazado Requerimiento presentado Gustavo Andrés Alvear. Ingeniería de Requerimientos Línea base

Control de cambios Proceso (1)
1. Solicitud de cambio por parte del interesado 2. Valoración Análisis de impacto 4. Comité de control de cambios decide Rechazar e informar al interesado Aceptar el cambio

Control de cambios Proceso (2) 5. Generar orden técnica para cambio
Actividades y responsables 7. Hacer el cambio 8. Verificar el cambio - actividades de calidad 9. Promover el cambio (nueva versión), informar al usuario

Control de cambios Información de una solicitud (1) Identificador
Origen – quién realiza la solicitud Tipo (cambio, mejora, error) Fecha Descripción Prioridad o fecha para la cual se requiere el cambio

Control de cambios Información de una solicitud (2) Proyecto Respuesta
Estado Registrada, Evaluada, Rechazada, Aprobada, Cambio realizado, Verificada, Cancelada, Cerrada Responsable del cambio Verificador

Ejercicio Elabore un formato que permita realizar solicitudes de cambios en su organización

Control de cambios Comité de control de cambios
De tres a cinco personas Incluir representantes de los interesados Evalúa los cambios propuestos Rechazar Aceptar Estimar esfuerzo Priorizar Actualizar el SRS

Definir criterios para aprobar / rechazar una solicitud Usar una lista de chequeo Apoyarse en una evaluación de impacto y esfuerzo Todo cambio tiene un costo

No siempre los clientes tienen la razón, pero tienen argumentos que son válidos y pueden ofrecer ideas para futuras versiones No se debe usar el proceso como una barrera Las razones para aprobar / rechazar una solicitud deben quedar registradas

Control de cambios Para cambios aprobados:
Identificar las tareas que se deben realizar Se puede tener una lista de tareas estándar Asignar recursos a las tareas Estimar el esfuerzo requerido para cada tarea, de acuerdo con los recursos asignados y los elementos afectados Establecer el orden de las tareas Estimar el impacto en el cronograma

Ejercicio Elabore un formato de reporte final, que resuma las decisiones del comité para una solicitud de cambio.

Control de cambios

Control de cambios Hacer el cambio
Empezar del mayor nivel de abstracción, y luego en cascada en los diferentes elementos que afecta Proceso de control de versiones Realizar cambios en la documentación pertinente (no solo en el código) Registrar tiempos

Control de cambios Verificación Pruebas, Inspecciones, …
Revisar enlaces Informar a las personas interesadas Usuarios Personas responsables de los elementos afectados Personas encargadas del control de versiones

Control de cambios Un cambio en apariencia pequeño puede convertirse en algo muy grande Trampa (no caer en ella): Evitar el procedimiento formal de control de cambios, y aceptar “pequeñas” solicitudes de los usuarios

Control de cambios Tener espacios de retroalimentación en el proceso de desarrollo No hacer sentir “culpables” a quien solicite un cambio justificado Hacer énfasis en la revisión de los requerimientos con los interesados ¿Qué podría ocasionar que este requerimiento cambiara?

Control de versiones Versión
Representa el estado de un requerimiento (o documento de requerimientos) en un momento dado Las versiones sucesivas difieren en uno o más cambios Adición, modificación o borrado de elementos Cada versión debe estar identificada de manera única

Control de versiones Esquema de identificación (numeración)
Tres dígitos Primero: Cambios mayores Ejemplo: Cambio en comportamiento Segundo: Cambio menor Ejemplo: Adicionar una funcionalidad Tercero: Revisión Ejemplo: Corrección de un error Convención: Antes de la son versiones no oficiales Bruegge y Dutoit. Ingeniería de Software Orientado a Objetos

Control de versiones Aspectos
Asegurar la disponibilidad de la versión correcta Evita desperdiciar tiempo en requerimientos obsoletos o inconsistentes Los miembros del equipo de desarrollo tienen acceso a la última versión Cada cambio debe ser claramente documentado y comunicado Se definen permisos para realizar los cambios

Control de versiones Cada documento debe tener Historia de revisiones
Número de versión Fecha Descripción Razón del cambio Autor Opcional Adicionar un número a los requerimientos que cambiaron

Control de versiones Ejemplo historia de cambios Versión Fecha
Descripción Autor 1.0 Fecha0 Versión inicial autor0 1.1 Fecha1 Descripción cambio1 autor1 : n Fechan Descripción cambion Autorn

Control de versiones Versión 1.1 (Aprobada) Versión 1.2 (Aprobada)
check-in check-in Versión 1.1 (Aprobada) Versión 1.2 (Aprobada) Repositorio del proyecto 1.1 check-out 1.2 Realizar cambios Verificación Roger Pressman. Ingeniería del Software: un enfoque práctico consulta 1.2 consulta 1.1

Control de versiones Definir permisos para realizar “check-in” y “check-out” Comité de control de cambios Permitir consultar las últimas versiones de los productos Mecanismos para notificar sobre los cambios

Control de versiones Usar herramientas
Marcas de revisiones de los procesadores de texto Herramientas para control de versiones CVS, Perforce, ClearCase, … Herramientas para manejo de requerimientos, con control de versiones integrado

Administración de requerimientos
Control de cambios Control de versiones Seguimiento Rastreo Estado Métricas

Seguimiento Rastreo También conocido como “Seguir el rastro”
Trazabilidad (Trace) “Seguir el rastro” Hace parte de las actividades de aseguramiento de calidad

Seguimiento Permite Verificar que las necesidades de los usuarios/clientes se han implementado y probado Saber de dónde se derivó cada requerimiento Verificar que no existen comportamientos “extra” ni requerimientos que aparecen de la nada Entender el impacto de los cambios Qué elementos afecta un cambio en un requerimiento

Seguimiento Elementos del Rastreo Establecer las relaciones
Poder ver/seguir las relaciones Identificar inconsistencias Mantener las relaciones cuando hay cambios

Necesidades de los clientes Productos subsecuentes
Seguimiento Necesidades de los clientes Rastreo hacia Adelante (forward) Requerimientos Rastreo hacia Atrás (backward) Karl Wiegers. Software Requirements, 2003 Productos subsecuentes

Seguimiento Fuente:

Seguimiento Rastreo Técnicas
Matrices (la más usada) Árboles Otras (como hipervínculos) Determinar qué elementos se desean enlazar y qué técnicas usar Incluir en cada producto referencias al anterior Actualizar la información cuando hay cambios

Seguimiento Ejemplo matriz casos de uso – requerimientos funcionales
Karl Wiegers. Software Requirements, 2003

Seguimiento Ejemplo matriz seguimiento

Ejercicio Elaborar una matriz de seguimiento a los requerimientos

Seguimiento Estados Permite tener una aproximación de avance del proyecto Definir los estados que se manejarán en la organización Establecer estándares para cambios de estados Responsables Métodos de seguimiento

Seguimiento Posibles estados Propuesto Aprobado Implementado
Verificado Rechazado Eliminado

Seguimiento Estados de un requerimiento Aceptado Diseñado Desarrollado
Probado Implantado Eliminado Presentado Rechazado

Seguimiento Métricas Solicitudes de cambio Actividades de cambios
Por estado (abiertas, cerradas, etc.) Por fuente Actividades de cambios Tipos de actividades Tiempos (estimados e invertidos) Costos

Seguimiento Métricas Esfuerzo total destinado Número de requerimientos
Clasificados por estados Número acumulativo de cambios en los requerimientos Identificar requerimientos más volátiles

Seguimiento Métricas Índice de madurez de los requerimientos
RMI = (Rt – Rc) / Rt Rt Cantidad de requerimientos en la versión actual Rc Cantidad de requerimientos adicionados, modificados o borrados desde la versión anterior

Otros Plan de requerimientos Plan de versiones Reporte retrospectivo

Plan de Requerimientos
Establecer la forma de trabajo de manera formal Cómo se llevarán a cabo las actividades relacionadas con requerimientos Incluso para proyectos pequeños Desarrollarlo al comienzo del proyecto

Temas (1) Propósito El objetivo del plan Resumen del proyecto Descripción general Visión

Temas (2) Desarrollo de los requerimientos Mecanismo acordado entre clientes/usuarios y equipo de desarrollo para revisar los requerimientos propuestos Criterios que definen un buen requerimiento Razones que soporten el requerimiento

Temas (3) Roles y responsabilidades Proceso de requerimientos Tareas Entradas, salidas Responsable Medidas para evaluar calidad del producto y del proceso

Temas (4) Mecanismos, técnicas y herramientas que se utilizarán Integración de prácticas efectivas Basadas en otras experiencias Referencias Apéndices

Plan de versiones Proyectos iterativos – incrementales
Método para planeación de proyectos Establecer cómo se implementarán los requerimientos Diferentes niveles de detalle Cada versión se produce a intervalos definidos y proporciona un valor agregado a lo anterior

Plan de versiones Ejemplo Requerimiento Versión 1 Versión 2 Versión 3
CU-13 No Si, 100% CU-25 Solo flujo normal (50%) Flujos alternos 1 y 2 (80%) 100% CU-05 Funcionalidad completa, sin registro de auditoría Adicionar registro de auditoría (100%)

Reporte Retrospectivo
Resultados del proceso de requerimientos Qué partes funcionaron bien Qué partes funcionaron mal No se debe usar como mecanismo de premio/castigo Fuente: Libro “Mastering the requirements process, second edition”.

Reporte Retrospectivo
Aspectos Aprendizajes (Logros – Dificultades) ¿Se lograron los objetivos? Comunicación con los interesados ¿Se tuvieron en cuenta todos los interesados? Herramientas usadas Proceso de revisiones Dificultades - errores Acciones

Pasos a seguir

Pasos a seguir Establecer prácticas actuales Crear plan de
acciones para mejorar Definir un piloto e implementar los nuevos procesos Evaluar los resultados

Pasos a seguir Aspectos
Las pruebas piloto deben ser en proyectos que no tengan mucho riesgo, antes de incorporarlo “oficialmente” Adaptar a su organización No forzar ni incluir todas las prácticas Mecanismos de control Auditorías Posibilidad de reformar a partir de sugerencias

Pasos a seguir Recomendaciones Definir las actividades a realizar
Documentar las actividades Capacitar a los participantes Publicar formatos, usar sistemas de apoyo Definir un responsable de los procesos de administración de requerimientos

Pasos a seguir Incluir en la capacitación
Importancia de las actividades de requerimientos Éxito/Fracaso de proyectos Inversión: Valor de los buenos requerimientos Procesos, métodos, técnicas, herramientas que se utilizarán Errores que se pueden presentar y cómo evitarlos/corregirlos Ralph Young. The requirements engineering handbook

Pasos a seguir El cambio toma tiempo
Identificar problemas en proyectos anteriores debidos a requerimientos Obtener el compromiso de los líderes / directivos Empezar con las prácticas más fáciles de implementar

Esfuerzo para verificar cumplimiento Validación y Verificación
Pasos a seguir Área IR Esfuerzo para adoptar Esfuerzo para verificar cumplimiento Adquisición Moderado - Difícil Difícil Análisis Moderado Administración Fácil - Moderado Fácil Documentación Validación y Verificación   

Pasos a seguir Procesos recomendados para comenzar Inspecciones
Usar plantillas para documentos de requerimientos Proceso de control de cambios Adicionar, posteriormente, el análisis de impacto Listado de requerimientos y Matriz de seguimiento

Enlaces Control de cambios: Herramientas control de versiones:
Herramientas control de versiones:

Ingeniería de Requerimientos

Presentaciones similares

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

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Ingeniería de Requerimientos

Presentaciones similares

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

Presentaciones similares

Sobre el proyecto

Feedback