UNIVERSIDAD VERACRUZANA
FACULTAD DE ESTADÍSTICA E
INFORMÁTICA
Maestría en Ingeniería de Software
Herramienta para la Administración de
Requerimientos de Software (HEARS)
TRABAJO QUE COMO REQUISITO PARCIAL PARA OBTENER EL
GRADO DE MAESTRÍA EN INGENIERÍA DE SOFTWARE
PRESENTA:
ULISES MARINERO AGUILAR
DIRECCIÓN:
DRA. MARÍA DE LOS ÁNGELES SUMANO LÓPEZ
Maestría en Ingeniería de
Software
UNIVERSIDAD VERACRUZANA
FACULTAD DE ESTADÍSTICA E INFORMÁTICA
C. L.l. Ulises Marinero Aguilar Candidato a la Maestría en Ingeniería de Software PRESENTE
Por este medio comunico a usted el dictamen aprobatorio de la comisión revisora integrada por:
Dra. María de los Ángeles Sumano López Dr. Juan Manuel Fernández Peña
Dra. María Karen Cortés Verdín
Mtro. Carlos Alberto Fernández y Fernández
Directora Jurado interno Jurado interno Jurado externo
Para el trabajo titulado “Herramienta para la Administración de
Requerimientos de Software (HEARS)”.
En consecuencia, se autoriza la impresión del trabajo, para continuar con los trámites correspondientes.
ATENTAMENTE
“LIS DE VERACRUZ: ARTE, CIENCIA, LUZ” Xalapa-Enríquez, Veracruz, a 10 de diciembre de 2009
Este trabajo se lo quiero agradecer a Dios que se encuentra alrededor e interior de todos nosotros quien hizo del cerebro y cuerpo humano una de su más grandes creaciones.
Agradezco a mi directora Dra. María de los Ángeles Sumano López y Dr. Juan Manuel Fernández Peña, teniendo el gusto de conocerlos más durante este tiempo y saber que son excelentes personas, ya que ambos me brindaron su paciencia, confianza, consejos y sobre todo parte de su tiempo en ayudarme a realizar y mejorar este trabajo.
Agradezco a todos mis maestros y compañeros que he tenido dentro de la escuela y fuera de ella, desde mi maestra de preescolar hasta mi último maestro de maestría, todos aportaron a que este momento se hiciera realidad.
CONTENIDO
1 INTRODUCCIÓN... 1
1.1 Objetivosdeltrabajo...2
1.2 Justificación... 2
1.3 Organizacióndel Trabajo... 2
2 FUNDAMENTOS TEÓRICOS... 3
2.1 Requerimientos...3
2.2 Tiposde Requerimientos...'...3
2.3 Ingenieríade Requerimientos... 5
2.4 Administraciónde Requerimientos...6
2.4.1 Control de Camb ios... 6
2.4.2 Control de Versiones... 6
2.4.3 Seguimiento y Estado... 7
2.4.4 Trazabilidad... 7
2.5 Establecimientode Requerimientos...8
2.6 Requerimientos Cambiantes... 9
2.6.1 Requerimientos Mutables... 9
2.6.2 Requerimientos Emergentes... 9
2.6.3 Requerimientos de Consecuencia...9
2.6.4 Requerimientos de Compatibilidad...9
2.7 Administrarlos Cambiosde Requerimientos...9
2.8 Trazabilidadde Requerimientos... 11
2.9 Impactoenlos Requerimientos...14
2.9.1 Extracción de Trazabilidad... 16
2.9.1.1 Análisis de la Trazabilidad Pregrabada... 16
2.9.1.2 A nálisis de Dependencia...16
2.9.1.3 Análisis de Experiencia Plana... 17
2.9.1.4 Análisis de Extrapolación,...,... 18
2.9.1.5 Análisis de Certeza... 18
2.9.2 Análisis de Trazabilidad...19
2.9.3 Composición Lateral...20
2.9.4 Composición Vertical...20
2.9.5 Resolución de la Duplicación...:... 22
2.9.6 Aplicación de Decadencia... 23
3 ESTABLECIMIENTO DE REQUERIMIENTOS... 24
3.1 Contextoy Situación Actual...24
3.1.1 Contexto...'... 24
3.1.2 Situación Actual...24
3.1.2.1 Diálogos de la Situación Actual... ...25
3.1.3 Conclusión de la Situación Actual... 26
3.2 Justificacióndel Nuevo Software...26
3.3 Propuesta Computacional... ... ...26
3.3.1Pista Requerimiento... ...27
3.3.2 Pista Trazabilidad-Análisis...28
3.4 Prototipode HEARS... 30
3.5 Bitácorade Desarrollode HEARS... 33
3.5.1 Pista Requerimiento...33
4 ANÁLISIS DE HEARS .41
4.1 Diagramasde Paquetesy Casode Uso...41
4.2 Realizaciónde Casosde Usode Análisis...42
4.2.1 Diagrama de Colaboración y Flujo de Sucesos del Caso de Uso: Creación LBR... 42
4.2.2 Diagrama de Colaboración y Flujo de Sucesos del Caso de Uso: Crear Nuevo AT a RE...44
4.2.3 Diagrama de Colaboración y Flujo de Sucesos del Caso de Uso: Actualiza Requerimiento ...45
4.2.4 Diagrama de Colaboración y Flujo de Sucesos del Caso de Uso: Reporte LBR... 47
4.2.5 Diagrama de Colaboración y Flujo de Sucesos del Caso de Uso: Crear Trazabilidad...48
4.2.6 Diagrama de Colaboración y Flujo de Sucesos del Caso de Uso: A nalizar REC... 49
5 DISEÑO DE HEARS... 52
5.1 Arquitecturadelsistema...52
5.1.1 Modelo de Despliegue... ... 52
5.1.2 Modelo de Diseño...52
5.2 Realizaciónde Casosde Usodel Sistema HEARS...53
5.2.1 Realización del CU: Creación LBR...53
5.2.2 Realización del CU: Creación Nuevo AT aRE...56
5.2.3 Realización del CU: Actualiza Requerimiento... :...57
5.2.4 Realización del CU: Reporte LBR...60
5.2.5 Realización del CU: Crear Trazabilidad... 61
5.2.6 Realización del CU: Analizar REC... 63
6 Pruebasde HEARS...67
6.1 Plandeprueba... 67
6.1.1 Pruebade Sistema... 67
6.1.2 Pruebade Unidad...75
6.1.2.1 Estructurasdelasclases OperadorAnalisisy CompositorVertical...75
6.1.2.2 Estructurasde Grafode Llamadas Mejoradosy Matrizdeuso Mínimodelaclase OperadorAnalisis...i...76
6.1.2.3 Estructurasde Grafode Llamadas Mejoradosy Matrizdeuso Mínimodelaclase CompositorLateral...80
6.1.2.4 Secuenciasdetransformadoresdelasclases OperadorAnalisisy CompositorLateral... 84
6.1.2.5 Definicióndecasosde Pruebade Unidad...86
6.1.3 Corrida de los casos de prueba con JUnit... 90
6.2 Análisisdelos Casosde Prueba...91
7 Conclusión... 92
APÉNDICE A FIGURAS COMPLEMENTARIAS DEL EJEMPLO DEL REQUERIMIENTO CANDIDATO PAGO EN LÍNEA... ...96
APÉNDICE B. MANUAL DE OPERACIÓN DE HEARS 105 APÉNDICE C. CODIFICACIÓN DE PRUEBAS DE UNIDAD DE HEARS... ... ...116
LISTA DE FIGURAS
Figura 1. Diferentes Tipos de Relaciones de Información de Requerimientos (Tomado de [Wiegers, 2003]).. 4
Figura 2. Subcomponentes de Dominio en la Ingeniería de Requerimientos (Tomado de [Wiegers, 2003]).... 5
Figura 3. Principales Actividades en la Administración de Requerimientos... 6
Figura 4. Posibles enlaces de Trazabilidad en los Requerimientos ( Tomado de Kotonya, Sommerville (1998)) ... 8
Figura 5. Etapas en el proceso de Administración del Cambio ( Tomado de Kotonya, Sommerville (1998))..10
Figura 6. El Proceso de Análisis y Costeo en el Cambio ( Tomado de Kotonya, Sommerville (1998))...10
Figura 7. Cuatro tipos de Trazabilidad de Requerimientos (Adaptado de Wiegers, 2003)...12
Figura 8. Trazabilidad de Extrapolación de Sistema Bibliotecario...18
Figura 9. Generación de la Estructura de Propagación [Lock y Kotonya 1999)...20
Figura 10. Generación de la Composición Lateral [Lock y Kotonya 1999)...20
Figura 11. Generación de la Composición Vertical [Lock y Kotonya 1999]...21
Figura 12. Probabilidad ajustada del impacto...21
Figura 13. Duplicación de Caminos [Lock y Kotonya 1999]... 22
Figura 14. Aplicación de la Decadencia a la Estructura de Propagación... 23
Figura 15. Guión teórico de la Situación Actual...25
Figura 16. Pista Requerimiento de HEARS... 27
Figura 17. Pista Trazabilidad de HEARS...29
Figura 18 Diagrama de Paquetes de HEARS... ... 41
Figura 19. Diagrama casos de uso de HEARS...42
Figura 20 Diagrama de Colaboración Creación LBR... 43
Figura 21 Diagrama de Colaboración Crear Nuevo AT a RE... 45
Figura 22 Diagrama de Colaboración Actualiza Requerimiento... 46
Figura 23 Diagrama de Colaboración Reporte LBR... 47
Figura 24 Diagrama de Colaboración Crear Trazabilidad...48
Figura 25 Diagrama de Colaboración Analizar REC... 50
Figura 26 Modelo de Despliegue de HEARS... 52
Figura 27 Modelo de Diseño HE AS... 53
Figura 28 Diagrama de Clases para el Caso de Uso Creación LBR...54
Figura 29 Diagrama de Secuencia para el Caso de Uso Creación LBR... ... 55
Figura 30 Diagrama de Clases para el Caso de Uso Crear Nuevo AT a RE... 56
Figura 31 Diagrama de Secuencia para el Caso de Uso Crear Nuevo AT a RE... 57
Figura 32 Diagrama de Clases para el Caso de Uso Actualiza Requerimiento... 57
Figura 33 Diagrama de Secuencia para el Caso de Uso Actualiza Requerimiento... 59
Figura 34 Diagrama de Clases para el Caso de Uso Reporte LBR... 60
Figura 35 Diagrama de Secuencia para el Caso de Uso Reporte LBR... 60
Figura 36 Diagrama de Clases para el Caso de Uso Crear Trazabilidad... :... 61
Figura 37 Diagrama de Secuencia para el Caso de Uso Crear Trazabilidad... 62
Figura 38 Diagrama de Clases para el Caso de Uso Analizar REC... 63
Figura 39 Diagrama de Secuencia para el Caso de Uso Analizar REC... 66
Figura 40. Representación UML de la clase OperadorAnalisisr... 75
Figura 41. Representación UML de la clase Compositor Lateral... 76
Figura 42. Parte 1 de la GLLM de la clase OperadorAnalisis...77
Figura 43. Parte 2 de la GLLM de la clase OperadorAnalisis... 77
Figura 44„Parte 3 de la GLLM de la clase OperadorAnalisis... 78
Figura 45. Parte 4 de la GLLM de la clase OperadorAnalisis... 78
Figura 46. Parte 1 de la GLLM de la clase CompositorLateral...81
Figura 47. Parte 2 de la GLLM de la clase CompositorLateral... 81
Figura 48. Parte 3 de la GLLM de la clase CompositorLateral...82
Figura 53 Propagación de Certeza del Impacto - Caminos Duplicados... 97
Figura 54 Propagación de Certeza del Impacto - Resolución de Caminos Duplicados... 98
Figura 55 Propagación de Certeza del Impacto- Aplicación de Decadencia...99
Figura 56 Propagación de Certeza del Impacto - Aplicación de Corte menor de .3 de probabilidad...100
Figura 57 Propagación de Precaución del Impacto - Caminos Duplicados... 101
Figura 58 Propagación de Precaución del Impacto - Resolución de Caminos Duplicados... 102
Figura 59 Propagación de Precaución del Impacto — Aplicación de Decadencia... 103
Figura 60 de Precaución del Impacto - Aplicación de Corte menor de .3 de probabilidad... 104
LISTA DE TABLAS
Tabla 1. Trazado de Requerimientos por Caso de Uso ( Adaptado de Kotonya, Sommerville (1998))...13Tabla 2. Lista de Trazabilidad (Tomado de Kotonya, Sommerville (1998))... 14
Tabla 3. Requerimientos de Sistema Bibliotecario... 15
Tabla 4. Lista de Requerimientos Cambiados... 15
Tabla 5. Trazabilidad Pregrabada de Sistema Bibliotecario...17
Tabla 6. Trazabilidad de Dependencia dé Sistema Bibliotecario... 17
Tabla 7. Trazabilidad de Experiencia Plana de Sistema Bibliotecario...18
Tabla 8. Certeza Total de Requerimientos...19
Tabla 9. Identificación y grado de dificultad de archivos...38
Tabla 10. Dificultad de Requerimientos...38
Tabla 11. Puntos de Función sin ajustar...39
Tabla 12. Cálculo de Modificadores... 39
Tabla 13 Casos de Prueba para el Caso de Uso Creación de LBR... 68
Tabla 14 Casos de Prueba para el Caso de Uso: Crear Nuevo AT a RE...68
Tabla 15 Casos de Prueba para el Caso de Uso: Actualiza Requerimientos...69
Tabla 16 Casos de Prueba para el Caso de Uso: Reporte LBR... 70
Tabla 17 Casos de Prueba para el Caso de Uso: Crear Trazabilidad... 70
Tabla 18 Casos de Prueba para el Caso de Uso: Analizar REC... 72
Tabla 20 Métodos de la Clase OperadorAnalisis... 76
Tabla 21 Matriz de uso Mínimo de la clase OperadorAnalisis... ... 79
Tabla 22 Método de la Clase CompositorLateral... 80
Tabla 23. MUM de la Clase CompositorLateral... ...83
Tabla 24 Secuencias de transformadores de las clases OperadorAnalisis... 84
Tabla 25 Secuencias de transformadores de las clases CompositorLateral... 85
Tabla 26. Valores para la clase OperadorAnalisis... 86
Tabla 27. CompositorLateralalores para la clase CompositorLateral... 87
Tabla 28. Casos de Prueba de la clase OperadorAnalisis... 88
Tabla 29. Casos de Prueba de la clase CompositorLateral... 89
1 INTRODUCCIÓN
La ingeniería es una actividad natural y espontánea en el ser humano, que lo ha llevado a crear herramientas útiles para su beneficio. Una de ellas es la computadora, donde hardware y software trabajan conjuntamente.
El software debe desarrollarse de una manera ordenada y metódica, la disciplina de Ingeniería de Software es la encargada de realizar está tarea. En los últimos años ésta se ha desarrollado a grandes pasos y al mismo tiempo han surgido nuevas áreas de oportunidades para mejorar el desarrollo de sistemas de software.
Hoy en día, cuando los sistemas de software son herramientas fundamentales para la sociedad en general, los ingenieros de software hacen la reflexión sobre la importancia que tiene el momento de iniciar un proyecto informático, el momento de la definición de requerimientos.
Una de las actividades básicas en la definición y, especialmente en la evolución de un proyecto, radica en la administración de los requerimientos. Un requerimiento es “una especificación que debe de ser implementada, son las descripciones de como el sistema debe de comportarse, la propiedad o atributo de un sistema, deben ser las limitaciones en el proceso del desarrollo del sistema” [Sommerville, 2005], un requerimiento surge de una necesidad del mundo real, necesidad que puede o no cambiar con el paso del tiempo.
El ingreso de un requerimiento nuevo puede tener un impacto en mayor o menor grado sobre los requerimientos ya establecidos para la creación de un sistema. El impacto del requerimiento nuevo, puede estimarse probabilísticamente siguiendo las relaciones y dependencias de los requerimientos establecidos anteriormente; el impacto debe de ser analizado y evaluado antes de aplicar el nuevo requerimiento al sistema.
Administrar los requerimientos del proyecto de software es una actividad clave para entregar el producto en el tiempo estimado y que finalmente cumpla con todas las funciones esperadas por el usuario. Desafortunadamente en la mayoría de proyectos de sistemas no existe una buena administración de requerimientos, sólo está una idea vaga de que el sistema debe dar un resultado esperado y que este le sea útil al usuario final.
1.1
Objetivos del trabajo
El objetivo general es contribuir a la Administración de Requerimientos de un proyecto qué permita enfrentar con éxito los cambios, dentro de los límites que se habían impuesto.
Los objetivos específicos son desarrollar una herramienta para administrar la información básica de los requerimientos en el desarrollo de sistemas, y evaluar probabilísticamente el impacto de un requerimiento propuesto, sobre los requerimientos ya establecidos.
1.2
Justificación
HEARS se hace para que el desarrollador tenga una buena administración de
los requerimientos. Como “buena administración” se entiende que se cuenta con la información oportuna de los requerimientos.
HEARS ayudará a evaluar probabilísticamente el impacto del requerimiento propuesto sobre los requerimientos iniciales del proyecto, esta información probabilística le podrá ser de ayuda al desarrollador al momento de negociar con el cliente la implantación de un requerimiento nuevo. La información de impacto ayudará a tomar una decisión sobre esté, con el fin de contribuir a entregar y desarrollar un sistema de calidad.
1.3 Organización del Trabajo
El trabajo está conformado inicialmente en el capítulo dos por los fundamentos teóricos, en donde se hace una introducción al tema de la Administración de Requerimientos, pero principalmente se explica la metodología para desarrollar el análisis de impacto de un requerimiento nuevo.
El capítulo tres está enfocado al establecimiento de requerimientos de la herramienta, en donde básicamente se platea la propuesta computacional, el prototipo de la herramienta y el cálculo de puntos de función para obtener el costo de la herramienta.
En el capítulo cuatro se desarrolla el análisis de cada caso de uso, cada uno con su respectivo diagrama de colaboración y flujo de sucesos.
El capítulo cinco se enfoca al diseño de la herramienta en donde se plantea la arquitectura por medio de un de diseño y despliegue, así mismo se expone la realización de los casos de uso por medio de diagramas de clases y diagramas de secuencia con su respectivo flujo se sucesos.
Finalmente las conclusiones a las que se ha llegado con la realización de la herramienta.
2
FUNDAMENTOS TEÓRICOS
En el presente capítulo se tratan los aspectos teóricos que dan fundamentos a la aplicación de software realizada en el presente trabajo.
2.1
Requerimientos
Un requerimiento, hablando en términos generales, es algo que se debe hacer y cómo se supone o se espera que deba funcionar un producto que se ha adquirido, con el fin de satisfacer necesidades especificas.
El IEEE Standard Glossary of Software Engineering Terminology (1990), define requerimiento como:
1. Una condición o capacidad necesitada por un usuario para resolver un problema o^alcanzar un objetivo.
2. Una condición o capacidad que debe de ser reunida o poseída por un
sistema o componente de sistema para satisfacer un contrato, estándar, especificación u otro documento de imposición formal.
3. Una representación documentada de una condición o capacidad, así como en los puntos 1 y 2.
2.2
Tipos de Requerimientos
Los requerimientos en el ámbito del desarrollo de proyectos de software tienen tres niveles: requerimientos de negocio, requerimientos del usuario y requerimientos funcionales.
En la Figura 1 se muestra una forma de ver los diferentes tipos de requerimientos existentes, los óvalos representan el tipo de información de los requerimientos, los rectángulos representan los contenedores (documentos, diagramas o base de datos), en los cuales se almacena la información [Wiegers, 2003]. A continuación se listan sus definiciones:
Requerimientos del Negocio: Estos requerimientos son las metas principales del negocio, representan los altos objetivos de la empresa, describen el por qué la empresa está implementando el sistema. Por ejemplo el incrementar los ingresos, decrementar costos, mejorar la administración de los datos, incrementar el conocimiento tecnológico [Kotonya y Sommerville, 1998].
Requerimientos Funcionales: Especifica la funcionalidad del software, que debe de ser construida por los desarrolladores del producto, para que los usuarios cumplan sus tareas [Wiegers, 2003]; son las transformaciones de entradas a salidas que el sistema debe de realizar, estos requerimientos se derivan de los dos tipos de requerimientos anteriores, los de usuario y negocio [Kotonya y Sommerville, 1998],
Requerimientos de Sistema: Representa un alto nivel en los requerimientos de un producto, el cuál contiene múltiples subsistemas operando, como por ejemplo los subsistemas que operan el hardware [Wiegers, 2003],
Reglas del Negocio: Son regulaciones del gobierno, estándares en la industria, prácticas contables. Las reglas del negocio no son requerimientos funcionales en si, por que están fuera de la frontera de las especificaciones del sistema, sin embargo algunas veces restringen algunos casos de uso [Wiegers, 2003],
Figura 1. Diferentes Tipos de Relaciones de información de Requerimientos (Tomado de [Wiegers, 2003]).
Los requerimientos funcionales están documentados en la Especificación de Requerimientos de Software (Software Requirement Specification SRS ), la cual describe el comportamiento esperado de un sistema de software, éste puede ser un documento, una base de datos o una hoja de cálculo que contiene los requerimientos [Wiegers, 2003],
Además de los requerimientos funcionales, el SRS contiene requerimientos no funcionales. El SRS incluye las metas de desempeño y la descripción de los atributos de calidad. Las interfaces externas describen la interacción entre el sistema y el mundo exterior, así como su diseño e implementación. Los límites imponen restricciones sobre las opciones disponibles del desarrollador para el diseño y construcción del producto [Wiegers, 2003],
2.3
Ingeniería de Requerimientos
La Ingeniería de Requerimientos de Software, tiene dos subcomponentes para la creación de un sistema (ver Figura 2), estos subcomponentes son el Desarrollo de Requerimientos y la Administración de Requerimientos [Wiegers, 2003].
Figura 2. Subcomponentes de Dominio en la Ingeniería de Requerimientos (Tomado de [Wiegers, 2003]).
El Desarrollo de Requerimientos comprende el obtener, analizar, especificar y validar los requerimientos de un proyecto [Abran y Moore, 2001], por ejemplo la documentación de los casos de uso, especificación de requerimientos, un diccionario de datos y un modelo de análisis.
Una vez definidos y aprobados los requerimientos iniciales se crea su línea base, misma que será entregada al equipo de desarrollo. Ésta es un acuerdo entre los desarrolladores del proyecto y los clientes; será el puente de continua comunicación entre el desarrollo y la administración de los requerimientos [Wiegers, 2003].
2.4 Administración de Requerimientos
La administración de los requerimientos está conformada por las actividades que mantienen la integridad y exactitud de la información asociada durante la evolución del proyecto, información que dio valor e importancia a los requerimientos iniciales, plasmada en la especificación de requerimientos de software (SRS).
La administración de requerimientos es complicada, específicamente por que los requerimientos tienden a cambiar durante la evolución del proyecto, especialmente cuando es un nuevo producto, como por ejemplo un sistema de una función específica, una aplicación, un sistema móvil o un sistema web.
La administración de requerimientos está compuesta principalmente por las tareas de control de cambios, control de versiones, seguimiento y estado de los requerimientos y finalmente el trazado de los requerimientos, como se muestra en la Figura 3 [Wiegers, 2003].
Figura 3. Principales Actividades en la Administración de Requerimientos
2.4.1 Control de Cambios
Esta actividad corresponde al control sobre los cambios propuestos: analizar el impacto de dichos cambios y tomar decisiones sobre ellos. Dichas actividades deben de estar basadas en las políticas del proyecto que se está construyendo, es decir tener un proceso de control para el cambio de los requerimientos.
El comité de control de los cambios (Configuration Control Board CCB ) ha sido identificado como la mejor práctica para el desarrollo de software [MacConnell, 1996] el CCB es un cuerpo de gentes, puede ser un individuo o diversos grupos. El CCB decide qué requerimiento propuesto cambia y qué características nuevas son aceptadas o rechazadas en el producto.
2.4.2 Control de Versiones
Esta actividad indica los requerimientos válidos que se están desarrollando actualmente; es posible representarlo por medio de un documento que enlista los requerimientos válidos con sus propiedades.
Cada versión del documento o del requerimiento debe de ser único. Es importante contar con la versión actual de los requerimientos, a la cual todos los miembros del equipo de desarrollo puedan acceder.
Los cambios en los requerimientos deben documentarse y comunicarse a todos los involucrados en el proyecto, ya que trabajar con una versión no actualizada ocasionaría desperdicio de tiempo y esfuerzo con requerimientos inválidos.
Personas autorizadas pertenecientes al CCB podrán actualizar la versión de los requerimientos. Tal actualización debe contener información histórica de los cambios en los requerimientos, por ejemplo la fecha del cambio, la persona que hizo el cambio y la razón por la cual se cambio el requerimiento.
2.4.3 Seguimiento y Estado
Este aspecto de la administración de requerimientos está enfocado en definir el estado de los requerimientos, es decir quién es o quiénes son los responsables de cumplir_eada requerimiento y el porcentaje realizado.
Para que se pueda tener seguimiento y estado, los requerimientos deben contener atributos, los cuales deben distinguirse claramente, es decir deben poseer atributos específicos. Por ejemplo la fecha en que fue creado el requerimiento, la versión que pertenece el requerimiento, la persona responsable de cumplirlo, estado actual del mismo, la razón para la que se propuso y la prioridad que se le asignó.
Los atributos de los requerimientos se deben iniciar con tres o cuatro propiedades. Se podrán ir añadiendo más atributos según sea significativa la información, ya que un exceso puede confundir al desarrollador [Wiegers, 2003],
2.4.4 Trazabilidad
La trazabilidad son enlaces entre requerimientos, los cuales ayudan a construir una imagen más completa del sistema a desarrollar. La trazabilidad de los requerimientos tiene su soporte en los atributos que definen el seguimiento y estado de los requerimientos.
Modifica
Requerimientos Del Negocio
Maneja la especificación de
Es verificado por
1
Pruebas De Unidad
Figura 4. Posibles enlaces de Trazabilidad en los Requerimientos ( Tomado de Kotonya, Sommerville (1998))
Los involucrados en el proyecto deben decidir qué enlaces son necesarios, cuáles contribuyen más al desarrollo y apoyan al mantenimiento del sistema.
El invertir en la trazabilidad durante la administración de requerimientos incrementará las oportunidades de entregar y mantener un producto, que cumpla con todos los requerimientos del cliente.
2.5 Establecimiento de Requerimientos
El conjunto de requerimientos funcionales y no funcionales definidos en el SRS (Software Requirement Specification - Especificación de Requerimientos de Software) constituye una línea base para el proyecto, que los desarrolladores deben realizar en una determinada liberación del producto; definen el alcance inicial de las propiedades que se espera posea el producto.
La metodología Áncora se acopla muy bien a la administración de requerimientos, ya que “cubre la primera etapa en el desarrollo de un nuevo sistema de software, esto es, la definición de qué se quiere”, [Sumano, 2006]. El producto final de Áncora es la Especificación de Requerimientos de Software, que es el punto de partida para la Administración de Requerimientos.
Una vez que la Especificación de Requerimientos de Software ha sido revisada y aprobada por los involucrados, ésta queda a cargo de la administración de requerimientos. La aplicación de cambios sobre la línea base deberá de seguir un proceso de control de cambios.
2.6
Requerimientos Cambiantes
La naturaleza de un requerimiento suele ser inestable, es decir tiende a cambiar durante la evolución del sistema. Los requerimientos cambiantes se clasifican de la siguiente manera [Kotonya y Sommerville, 1998]:
2.6.1 Requerimientos Mutables
Estos tipos de requerimientos cambian según el medio ambiente en cual se desarrollan. Por ejemplo, se tiene un requerimiento que reduce los impuestos, pero este requerimiento debe de cambiar porque ha surgido una nueva ley sobre impuestos.
2.6.2 Requerimientos Emergentes
Estos requerimientos son aquellos que no se pudieron definir en la etapa de especificación del sistema, sino que aparecen conforme el sistema se va diseñando e implementando.
2.6.3 Requerimientos de Consecuencia
Estos requerimientos están basados en cómo se supone que el sistema debe trabajar, pero cuando el sistema se pone en ejecución se observa que tales suposiciones iniciales fueron incorrectas, lo que traerá como resultado que los usuarios finales demanden un cambio.
2.6.4 Requerimientos de Compatibilidad
Estos tipos de requerimientos son dependientes de otros procesos o dispositivos externos, si el dispositivo externo cambia también el requerimiento debe hacerlo, para que siga existiendo compatibilidad.
2.7 Administrar los Cambios de Requerimientos
Administrar cambios involucra manejar una gran cantidad de información que pasa entre muchos individuos de una organización [Kotonya y Sommerville, 1998], dichos individuos se pueden agrupar en dos grandes grupos, los clientes y los desarrolladores del producto. Debe de existir un común acuerdo en ambos para aplicar el cambio y asumir costos.
El cambio será evaluado por el equipo de desarrollo, éste debe analizar cuidadosamente el cambio propuesto para justificar su costo ante el cliente.
Figura 5. Etapas en el proceso de Administración del Cambio (Tomado de Kotonya, Sommerville (1998))
1. Se identifican algunos problemas en los requerimientos por algún
involucrado en el sistema. El requerimiento es analizado usando la información del problema y se proponen cambios.
2. Se analizan los cambios propuestos para identificar cuántos
requerimientos serán afectados por el cambio y aproximadamente cuál será el costo, en tiempo y dinero para realizar el cambio.
3. Se implementa el cambio. Se producirá un conjunto de enmiendas a la
documentación de requerimientos o se crea una nueva versión del documento.
El proceso especifico para analizar un problema e implementar el cambio depende del tipo de cambio, los requerimientos afectados y el tipo de requerimiento documentado, como se muestra en la Figura 6 [Kotonya y Sommerville, 1998],
Solicitud
Información Cliente InformaciónCliente
Figura 6. El Proceso de Análisis y Costeo en el Cambio ( Tomado de Kotonya, Sommerville (1998))
El proceso de análisis del cambio está compuesto por seis actividades básicas.
1. Se evalúa la solicitud de cambio para observar si es válida. Algunas veces los clientes malinterpretan los requerimientos y sugieren cambios innecesarios.
2. Se descubre el requerimiento afectado directamente por el cambio.
3. Se utiliza la trazabilidad de la información para encontrar requerimientos dependientes, los cuales también serán afectados por el cambio.
4. Se propone el cambio que debe realizarse. Debe de haber una consulta con los clientes, para garantizar que están de acuerdo con los cambios.
5. Se estima el costo de realizar los cambios. La estimación debe de incluir el esfuerzo requerido para realizarlo y el tiempo necesario en el calendario, considerando los recursos disponibles.
6. Se efectúa una negociación con los clientes para decidir si el costo del cambio es aceptable. En esta etapa es posible regresar a la etapa cuatro para proponer cambios alternos, si el cliente piensa que los cambios propuestos son muy caros.
Ningún enfoque o modelo es universalmente correcto, ya que los proyectos difieren en la flexibilidad de sus características, el equipo, el presupuesto, el programa de actividades y la calidad deseada [Wiegers 1996],
En cualquier modelo es importante tener almacenada la información del proceso de cambios en los requerimientos, para poder observar, trazar y controlar la evolución de los requerimientos durante el proyecto.
2.8 Trazabilidad de Requerimientos
Cambios simples en los requerimientos pueden tener grandes impactos, al necesitar que varios elementos sean modificados. En general es difícil encontrar todos los componentes que serán afectados por la modificación de un requerimiento [Wiegers, 2003], lo cual constituye un problema.
Un análisis del impacto al cambio será fácil si se tiene un mapa de la ruta que muestra dónde fue implementado cada requerimiento o regla del negocio [Wiegers, 2003], Para crear una ruta, es necesario que cada requerimiento sea enlazado, por medio de algún criterio, con otro requerimiento.
Los enlaces en los requerimientos permitirán seguir su vida [Gotel y Finkelstein, 1994] o evolución, así como su dependencia con otros requerimientos. Con esta información es posible crear la trazabilidad de los requerimientos del proyecto.
Para que exista trazabilidad, cada requerimiento debe de ser único y etiquetado persistentemente, para que pueda referirse sin ninguna ambigüedad durante el proyecto.
Figura 7. Cuatro tipos de Trázabilidad dé Requerimientos (Adaptado de Wiegers, 2003)
Desde las “necesidades del cliente” se trazan los requerimientos asociados, este trazo permitirá decir que “requerimientos” serán afectados, si dichas necesidades cambian durante o después del desarrollo. A la vez dará certeza que el documento de Especificación de Requerimientos de Software (SRS) cubrió todas las Necesidades del Cliente.
De manera inversa se podrá trazar la raíz del requerimiento. Desde el origen de cada requerimiento del software se puede identificar las Necesidades del Cliente.
El enlace Producto Asociado va de los Requerimientos individuales a los elementos específicos del producto. Esté enlace asegura que se satisfacen todos los Requerimientos porque se sabe a qué elementos específicos pertenece.
El cuarto tipo de enlace Requerimiento Raíz traza los elementos específicos del producto a los Requerimientos, se sabe por qué fue creado cada elemento.
Estos tipos de enlaces revelan la propagación que pude resultar de un cambio, cuando un requerimiento específico es borrado o modificado.
Un nivel básico en el trazado de los requerimientos provee una manera de demostrar el consentimiento de un contrato, especificación o regulación. En un nivel más formal, el trazado de los requerimientos pueden proveer las bases de la calidad de los productos, reducir costos de mantenimiento y facilitar el reuso [Ramesh, 1998].
Los requerimientos no funcionales, como son las metas de desempeño y atributos de calidad, no siempre son trazados directamente en el código del proyecto.
La manera más simple de representar los requerimientos y otros elementos del sistema es por medio de una matriz de trazabilidad de los requerimientos o tabla de trazabilidad [Sommerville y Sawyer, 1997],
Las relaciones entre los elementos del proyecto, como por ejemplo casos de uso con requerimientos funcionales, se pueden definir uno a uno, uno a muchos, muchos a muchos. En la práctica la trazabilidad de la relación muchos a muchos puede llegar a ser compleja y difícil de manejar [Wiegers, 2003].
Otra manera de representar la trazabilidad de la información es mediante una matriz que define pares de enlaces sobre elementos del sistema. Se pueden usar este tipo de matrices que definen varias relaciones posibles entre pares de requerimientos . Por ejemplo, “especifica / esta especificado por”, “depende de ”, “es padre de ” y “restringe/ está restringido por ” [Sommerville y Sawyer, 1997],
El símbolo “ ” en la Tabla 1 indica que ciertos requerimientos funcionales están
trazados desde un caso de uso particular, se pueden usar diferentes símbolos en las celdas de la matriz para indicar “traza a ”, “trazado desde” u otro tipo de pares de relaciones.
Tabla 1. Trazado de Requerimientos por Caso de Uso (Adaptado de Kotonya, Sommerville (1998))
Requerimiento
Funcionales Caso de Uso
CU-1 CU-2 CU-3 CU-4 CU-5
RF-1
RF-2
RF-3
RF-4
RF-5
RF-6
Este tipo de representación es posible en sistemas con pocos requerimientos, en donde es posible trabajar con una hoja de cálculo, sin embargo, conforme el número de requerimientos aumenta dentro de la matriz, está se volverá inmanejable [Kotonya y Sommerville 1998]. En sistemas más grandes se demanda una solución más robusta [Wiegers, 2003],
Tabla 2. Lista de Trazabilidad ( Tomado de Kotonya, Sommerville (1998))
Requerimiento Depende de
R1 R3,R4
R2 R5,R6
R3 R4, R5
R4 R2
R5 R6
Dos enfoques existentes que realizan algún tipo de trazabilidad entre requerimientos son:
AORE (Ingeniería de Requerimientos Orientada a Aspectos) [Chitchyan Sampaio, Rashid Rayson], Este enfoque identifica los requerimientos y su influencia sobre otros requerimientos desde el análisis de un texto, detecta los conflictos existentes entre requerimientos, realiza la representación de los requerimientos analizados en un documento estructurado, todo ésto con la finalidad de realizar un análisis rápido y efectivo para documentos muy extensos.
La segunda opción es un marco de trabajo probabilístico que integra el análisis de impacto de un requerimiento [Lock y Kotonya 1999]. Se platea un marco que crea relaciones con técnicas definidas, realiza el análisis de un requerimiento nuevo sobre los requerimientos ya establecidos, generando como resultado un diagrama de impacto causado por el requerimiento nuevo.
Para el desarrollo de la herramienta que aquí se reporta se selecciona la segunda opción por las razones siguientes: presenta menos problemas para automatizarse, se obtuvo más información de cómo se aplica el análisis de impacto de un requerimiento nuevo, y además, se pudo contactar por medio de correo electrónico al Dr. Simón Lock , uno de los autores de dicho marco de trabajo, para preguntar detalles que no quedaron claros en la documentación.
En la siguiente sección se explica más a detalle el marco de trabajo mencionado.
2.9 Impacto en los Requerimientos
El problema del impacto en la administración de requerimientos no es simple de resolver, debido a la complejidad de la información y a las relaciones entre todos los artefactos que los conforman.
Para determinar el impacto de un requerimiento, es necesario conocer todos los artefactos que conformarán el sistema, esto es necesario para crear las relaciones, a esta información se le conoce como trazabilidad lateral. Sí se desea realizar un análisis de impacto primero se debe de obtener la trazabilidad lateral del sistema [Bennett 1996].
Para ejemplificar el proceso de análisis del impacto de un requerimiento propuesto, se realizará un análisis con los requerimientos de un Sistema Bibliotecario! Ejemplo adaptado de Lock y Kotonya, 1999], Se muestran en ía
Tabla 3 la Línea Base de Requerimientos y en la Tabla 4 la Lista de Requerimientos Cambiados. Las tablas muestran el ID del requerimiento, una etiqueta corta para identificar el requerimiento y una pequeña descripción del mismo.
Tabla 3. Requerimientos de Sistema Bibliotecario
ID Etiqueta Descripción
1R Alta
Se da de alta un libro en la base de datos de la biblioteca para que puedan usado por los usuarios de la biblioteca
2R Baja Se da de baja un libro
3R Préstamo Se presta uno o mas libros a un usuario, el libro debe de ser regresado por el usuario en la fecha especificada
4R Devolución El usario devuelve uno o mas libros prestados
5R Renovación El usario renueva uno o mas libros prestados, para extender la fecha de entrega
6R Consulta El usuario realiza consultas de los libros disponibles para préstamo
La Tabla 4 muestra tres requerimientos propuestos para el Sistema Bibliotecario; los requerimientos “Consulta en Línea” y “Renovación en Línea” se les realizó un análisis para obtener el impacto sobre los otros requerimientos pertenecientes a la Línea Base original del sistema, éstos ya han sido implantados en el Sistema Bibliotecario; el último requerimiento “Pago en Línea” aun no se sabe su impacto sobre los demás requerimientos, es necesario realizar un análisis de este para determinar si se implantará; el ejemplo se centra en este requerimiento para explicar el proceso de análisis de impacto.
Tabla 4. Lista de Requerimientos Cambiados
ID Etiqueta Descripción
1C Consulta en
Línea
Se consultan los libros disponibles para préstamo en línea
2C Renovación
en Línea
Se renuevan los prestamos, para extender las fechas de entrega
3C Pago en
Línea
Se paga el adeudo de libros prestados, que han sido entregados en fechas atrasadas
que será afectada por un cambio propuesto. El conjunto de entidades impactables está limitado a la Línea Base de Requerimientos de un sistema o a cualquier cambio existente o propuesto sobre estos requerimientos [Lock y Kotonya, 1999]. Incluyendo los cambios anteriores de los requerimientos como entidades impactables, se puede soportar el proceso evolutivo de los requerimientos.
La determinación del impacto se basa en la información de trazabilidad lateral, esta información se unirá en una estructura final, que posteriormente será usada como base directa para el análisis del impacto y para la producción de una visualización del cambio propuesto [Lock y Kotonya, 1998], El proceso de análisis de impacto incluye dos grandes etapas: la Extracción de la Trazabilidad y posteriormente la realización del Análisis de Trazabilidad, las cuales se explican a continuación.
2.9.1 Extracción de Trazabilidad
El primer paso para determinar el impacto es establecer la información del sistema con técnicas de trazabilidad. HEARS usa cinco técnicas diferentes para extraer información de trazabilidad al nivel de los requerimientos, las cuales se explican a continuación.
2.9.1.1 Análisis de la Trazabilidad Pregrabada
Es una técnica que usa información que ha sido obtenida por los desarrolladores y usuarios finales para determinar el potencial de trazabilidad entre los enlaces impactables [Arnold y Bohner, 1996], Este análisis se puede realizar a través del ciclo de vida del sistema, desde la formulación de requerimientos iniciales hasta la implementación.
Esta técnica almacena la relación existente entre todos los artefactos que conforman el sistema por medio de palabras clave o etiquetas que unen la relación. Cada relación almacenada tiene el potencial de causar un impacto, que se propaga de un requerimiento impactable a otro [Lock y Kotonya, 1999],
La información usada para el desarrollo de análisis de trazabilidad pregrabada debe ser registrada por los ingenieros de requerimientos cuando estos están siendo especificados. En la Tabla 5 se muestra la Trazabilidad Pregrabada del Sistema Bibliotecario con sus etiquetas y las relaciones inversas. Los trazos inversos se deben de considerar para la evaluación de un cambio propuesto [Lock y Kotonya, 1999],
2.9.1.2 Análisis de Dependencia
Es una técnica que tiene como objetivo representar las dependencias entre los requerimientos del sistema. Las relaciones Forward (depende sobre) y Backward (dependiente de) se extraen para asegurarse que todos los caminos del impacto son identificados [Paakki, Salminen y Koskinen, 1996],
Se muestra en la Tabla 6 los trazos de dependencia de los requerimientos del Sistema Bibliotecario, se incluye la relación inversa para la evaluación de un cambio propuesto.
Tabla 5. Trazabilidad Pregrabada de Sistema Bibliotecario
Pago en Línea afecta Préstamo Pago en Linea afecta Renovación Pago en Línea afecta Devolución Alfa afecta Consulta Baja afecta Consulta Préstamo afecta Devolución Préstamo afecta Renovación Préstamo afecta Consulta Devolución actualiza Préstamo Devolución actualiza Consulta Renovación actualiza Préstamo Renovación actualiza Devolución Renovación actualiza Consulta
Préstamo Renovación Devolución Consulta Consulta Devolución Renovación Consulta Préstamo Consulta Préstamo Devolución Consulta afectado por afectado por afectado por afectado por afectado por afectado por afectado por actualizado por actualizado por actualizado por actualizado por actualizado por
Pago en Línea Pago en Línea Pago en Línea
Alta Baja Préstamo Préstamo Préstamo Devolución Devolución Renovación Renovación Renovación
Tabla 6. Trazabilidad de Dependencia de Sistema Bibliotecario
Baja Alta Préstamo Renovación Consulta depende sobre depende sobre depende sobre depende sobre depende sobre Alta Préstamo Devolución Préstamo Devolución Alta Préstamo Devolución Préstamo Devolución dependiente de dependiente de dependiente de dependiente de dependiente de Baja Alta Préstamo Renovación Consulta
2.9.1.3 Análisis de Experiencia Plana
Esta técnica guarda y usa un registro de los cambios previos hechos en el sistema como base para extraer relaciones de trazabilidad. Para un cambio dado, las relaciones de trazabilidad se asumen entre el cambio y sus impactables directos.
Cada cambio previo genera un conjunto de impactables, los cuales representan un pequeño segmento de la estructura completa de trazabilidad. Se llama análisis de experiencia plana porque usa caminos previos de propagación que se usan para construir caminos, para ser aplicados directamente al cambio actual y al modelo potencial de propagación del impacto [Lock y Kotonya 1999],
Tabla 7. Trazabilidad de Experiencia Plana de Sistema Bibliotecario
Consulta en
Línea Impacta a Consulta con una probabilidad de .6 Renovación
en Línea Impacta a Devolución con una probabilidad de .5 Renovación
en Línea Impacta a Renovación con una probabilidad de .6 Renovación
en Línea Impacta a Consulta con una probabilidad de .8
Consulta ■
Impactado por
Consulta en
Línea con una probabilidad de .6
Devolución
Impactado por
Renovación
en Línea con una probabilidad de .5
Renovación
Impactado por
Renovación
en Línea con una probabilidad de .6
Consulta
Impactado por
Renovación
en Línea con una probabilidad de .8
2.9.1.4 Análisis de Extrapolación
La técnica se realiza comparando los impactos directos del cambio propuesto con los impactos directos de cambios previos. El cambio previo con mayor similitud en sus impactos directos con los impactos directos del cambio propuesto, es seleccionado como el conjunto final de impactos directos para extrapolar el cambio propuesto.
En la Figura 8 se muestra que se seleccionó el cambio previo “Renovación en Línea” por ser el de mayor similitud al cambio propuesto “Pago en Línea” en sus impactos directos.
Figura 8. Trazabilidad de Extrapolación de Sistema Bibliotecario
2.9.1.5 Análisis de Certeza
Esta técnica tiene el objetivo de medir la confiabilidad de la información de los requerimientos que conforman el sistema. El análisis se basa en dos métricas que son recogidas para cada impactable por los desarrolladores y son las siguientes:
• Grado de Definición-. La medida en la cual el impactable ha sido completamente especificado [Ecklund, Delcambre y Freiling, 1996].
• Certeza de Definición: La confianza con la cual los desarrolladores creen
que la información ingresada es correcta.
Usando estas dos métricas es posible dar una estimación cuantitativa de la confianza de información para cada impactable.
La asignación y mantenimiento de los valores de Grado de Definición y Certeza de Definición se confían al juicio y experiencia de los ingenieros. Los valores de estas métricas están en el rango desde 0 para una completa incertidumbre y 1 para una completa certeza. Para producir el valor de certeza total para un impactable en particular, las dos métricas se combinan en la siguiente formula:
Ctotal — GoD * CoD
Donde Ctotal es el valor de certeza total, GoD es el grado de definición y CoD es la certeza de definición.En la Tabla 8 se muestra la certeza total de cada impactable del Sistema Bibliotecario.
Tabla 8. Certeza Total de Requerimientos
Impactable Total de Certeza
Alta 0.7
Baja 0.8
Préstamo 0.6
Devolución 0.7
Renovación 0.8
Consulta 0.5
Consulta en Línea 0.7 Renovación en Línea 0.8 Pago en Línea 0.7
2.9.2 Análisis de Trazabilidad
Una vez que se ha extraído la trazabilidad primaria por una o más de las técnicas mencionadas, estas se combinan en una sola. Esto se hace para crear una estructura concreta mostrando todos los caminos directos e indirectos de propagación para un cambio que estará siendo analizado.
Ciclo Nuevo
Figura 9. Generación de la Estructura de Propagación [Lock y Kotonya 1999).
2.9.3 Composición Lateral
En esta etapa se combinan las salidas de todas las técnicas de extracción, sumando todos los caminos de propagación identificados [Lock y Kotonya 1999] ver la Figura 10.
Clave
Requerimiento
Propagación
1 del Impacto
Método1 Método 2 Híbrido M1yM2 Resultado
X
Entrada= A
O ® © Salida= By C
Figura 10. Generación de la Composición Lateral [Lock y Kotonya 1999)
2.9.4 Composición Vertical
Este método consiste en encadenar los ciclos de cada análisis (composición lateral), con el propósito de crear un camino que conforme una estructura completa, es decir crear capas adicionales (el conjunto total de impactos identificados por la composición lateral) para crear un árbol de propagación del impacto. Ver la Figura 11.
En Figura A-1 del apéndice se muestra la Composición Latera y Vertical del Sistema Bibliotecario, no se muestra en este apartado todas las Figuras con los resultados obtenidos del análisis debido a cuestiones de espacio.
® Clave Requerimiento Propagación del Impacto Ciclo 1
Método 1 Método 2 . Híbrido M1 y M2 Resultado
©
®
©
©
®
Entrada = A
Salida = B y C
Ciclo 2
Método 1 Método 2 Híbrido M1 y M2 Resultado
® © ® ® © © © ® © ©©©
Entrada = B y C
Salida = D, E y F
Ciclo 3
Método 1 Método 2 Híbrido M1 y M2 Resultado
©
+
-©
Q
©
©
©
©
D
©
©
E
)
©
Entrada = D,E y F Salida = G y HEstructura Completa ® / \ ® © © <E © © ©
Figura 11. Generación de la Composición Vertical [Lock y Kotonya 1999]
La probabilidad ajustada (Figura 12) se obtiene entre la relación de dos requerimientos, las probabilidades que se manejan para el análisis de un requerimiento son de dos tipos: Probabilidad de Certeza del Impacto y Probabilidad de Precaución del Impacto.
Figura 12. Probabilidad ajustada del impacto
Probabilidad de Certeza del Impacto: Es la probabilidad estimada de impacto calculado con la información disponible. El valor indica la certeza con la cual se predice que el impacto ocurrirá. Con valores bajos de certeza del requerimiento impactable, la probabilidad calculada se reduce debido a la falta de certeza de información. Para calcularla se usa la siguiente fórmula:
Pajustadac = Ppath * Cpath
Donde:
Ppath= probabilidad calculada por la técnica de extracción Cpath= certeza del impactable
Pajustadac = Probabilidad ajustada de certeza
Probabilidad de Precaución del Impacto: Representa el riesgo de impacto calculado con la información disponible. El valor indica una estimación del peligro de que el impacto ocurra. Con valores bajos de certeza del requerimiento, la probabilidad calculada se incrementa debido a la falta de certeza de información. Para calcularla se usa la siguiente fórmula:
Pajustadap = 1 - Cpath + ( Cpath * Ppath )
Donde :
Ppath= probabilidad calculada por la técnica de extracción Cpath= certeza del impactable
Pajustadap = Probabilidad ajustada de precaución
En la Figura A-6 del apéndice se muestra la Propagación de Precaución del Impacto con Caminos Duplicados del Sistema Bibliotecario.
Cada técnica de extracción que se realizó en la etapa de Composición Lateral tiene un peso específico, los pesos son relativos y pueden tener cualquier valor del rango mayor a cero y menor o igual a uno. La herramienta HEARS propone los siguientes pesos; que se podrán ajustar de acuerdo a la experiencia establecida:
Análisis de Trazabilidad Pregrabada = 0.8 Análisis de Dependencia = 0.8
Análisis de Experiencia Plana = 0.9 Análisis de Extrapolación = 0.9
2.9.5 Resolución de la Duplicación
Durante el análisis de composición lateral es posible encontrar un camino duplicado por las diferentes técnicas de extracción, la resolución de la duplicación tiene el objetivo de convertir los caminos duplicados en uno solo para minimizar el tamaño de estructura de la propagación final. Este proceso se realiza al final de cada ciclo para minimizar el número de salidas que pasan al siguiente ciclo de análisis y prevenir la complejidad del análisis. Ver la Figura 13.
Figura 13. Duplicación de Caminos [Lock y Kotonya 1999]
Para resolverlo se aplica la siguiente fórmula:
Pajustada — Pvieja + Pnueva (1- P vieja)
Donde Pnueva es una probabilidad adicional, Pvieja es la probabilidad actual
antes de la asimilación de la probabilidad adicional y Pajustada es la probabilidad
total después de ajusfar e integrar las probabilidades.
En la Figura A-3 y A-7 del apéndice se muestra la resolución de caminos de la Probabilidad de Certeza de Impacto y la Probabilidad de Precaución del Impacto respectivamente.
2.9.6 Aplicación de Decadencia
Al analizar el efecto total de un cambio dado, se debe de considerar la posición relativa del impactable en la estructura final de propagación. Por lo tanto al moverse a través de las capas de propagación de la estructura final, la probabilidad de alcanzar un punto en particular se decrementará, porque cada camino de propagación es transitivo y normalmente tendrá una probabilidad menor que uno, ver la Figura 14.
Estructura EstructuraDecadencia
(J) ®
.8 | .8 I ® .7 .7 *.8= .56
($) ©
.9 I .8 *.7 * .9 = 504 I
® ©
Figura 14. Aplicación de la Decadencia a la Estructura de Propagación
En la Figura A-4 y A-8 del apéndice se muestra la aplicación de decadencia de la Probabilidad de Certeza de Impacto y la Probabilidad de Precaución del Impacto respectivamente.
Finalmente para obtener la Estructura del Impacto completa, se debe combatir la complejidad de la misma; se usará la técnica de cortado de la probabilidad, esto es representar en una escala del cero al uno la probabilidad mínima que sea significativa para el análisis. El remover aquellos caminos en la estructura de propagación del impacto que no contribuyen a una evaluación, dará una estructura de propagación más significativa.
En la Figura A-5 y A-9 del apéndice se muestra el corté significativo de la Probabilidad de Certeza de Impacto y la Probabilidad de Precaución del Impacto respectivamente.
El análisis realizado al requerimiento “Pago en Línea” muestra que requerimientos serán impactados con mayor probabilidad con la información disponible, con este análisis el administrador podrá reportar las consecuencia de implantar el requerimiento propuesto.
3 ESTABLECIMIENTO DE REQUERIMIENTOS
El objetivo del presente capítulo es presentar la situación típica que actualmente se vive en empresas o departamentos de software respecto su administración de requerimientos, enfocar los problemas existentes con dicha administración y finalmente establecer una propuesta computacional mediante la aplicación HEARS.
3.1
Contexto y Situación Actual
En esta sección se explica el contexto de administrar requerimientos de software en un proyecto y la situación actual.
3.1.1 Contexto
El contexto actual en la administración de requerimientos radica en una completa y certera información sobre los requerimientos que debe cumplir el sistema, misma que será usada por todos los involucrados en el desarrollo del sistema, una correcta administración es importante debido a que algunos requerimientos del sistema evolucionan, cambian, se añaden e inclusive se eliminan durante el tiempo de desarrollo.
El actualizar los requerimientos no es una tarea fácil si estos están en papel o en texto digital; los nuevos requerimientos siempre van a afectar a otros requerimientos y es difícil detectar y mostrar ese impacto. Una herramienta que ayude a administrar los requerimientos del producto y proporcionar la probabilidad de impacto de un requerimiento nuevo, resultará de gran ayuda.
3.1.2 Situación Actual
La situación actual en la administración de los requerimientos depende mucho de la metodología de desarrollo del proyecto, otros factores que influyen son las políticas de la empresa, la interacción social entre los desarrolladores y clientes; estos elementos van más allá del alcance de este trabajo, sin embargo se propone la siguiente situación estereotipada (ver la Figura 15):
Guión: Administración de Escena 1: Petición de cambio
Requerimientos Cl realiza CR
Ad revisa CR
¿No es factible?
Papeles:
Cl = Cliente Ad = Administrador GD = Grupo Desarrollador
Utensilios:
Ad rechaza CR
Escena 2: Revisión de Imoacto
CR = cambio o inclusión de Ad plantea CR a GD
requerimientos GD revisa CR usando LBR
LBR = Línea Base de GD realiza PC
Requerimientos Ad recibe PC b
PC = Propuesta de Cambio Ad añade a PC el Co
Co = Costo (tiempo y dinero)
Escena 3: Presentación Propuesta
Condiciones de Entrada: Ad presenta PC_aí Cl
Cl quiere Cl Cl revisa PC
¿Cl no de acuerdo?
Condiciones de Salida:
Cl recibe PC
Clva a escena 1
Figura 15. Guión teórico de la Situación Actual
3.1.2.1 Diálogos de la Situación Actual
A continuación se presentan los diálogos de la situación actual que buscan aclarar algunos puntos del guión, posteriormente se explican los problemas que pueden surgir al trabajar con la situación actual.
En la primera escena surge una petición de cambio solicitada por el cliente, el administrador analiza el cambio y decide si el cambio solicitado es factible de realizarse. En la segunda escena el administrador plantea al equipo de desarrollo el cambio, posteriormente el equipo de desarrollo revisará el cambio tomando como base de evaluación la Línea Base de Requerimientos.
El administrador recibe la propuesta de posibles cambios a realizar, a estos nuevos cambios se les asigna un costo en tiempo y dinero. Finalmente en la tercera escena el administrador presenta la propuesta del cambio al cliente con su costo, el cliente decidirá si acepta el costo del cambio propuesto.
Durante las tres escenas de la situación actual pueden surgir varios problemas, destacándose los siguientes:
es muy difícil si estos sólo se encuentran en hojas de papel o en cualquier otro medio de almacenamiento.
Durante la segunda escena el administrador plantea el cambio al equipo de desarrollo, los desarrolladores probablemente aceptan los cambios sin darse cuenta que afectarán a todo lo que han realizado, lo que consumirá más tiempo y esfuerzo del estimado.
El administrador estimará cualitativamente el costo del cambio en tiempo y dinero; pero este costo probablemente sea mucho mayor de lo que en realidad se está estimando debido a la falta de una métrica.
El cliente recibe el costo del cambio, el cliente probablemente pensará que el costo final del cambio es elevado, el administrador no tendrá una manera de demostrarle porque sé llegó a ese costo, debido a que la información está sustentada en cálculos cualitativos, lo que hará difícil negociar el costo del requerimiento nuevo.
Otro problema común es que el administrador se comprometa a realizar un cambio que su equipo sea incapaz de cumplir.
3.1.3 Conclusión de la Situación Actual
Es posible encontrar varios problemas en todas las escenas, pero el problema que se aborda en este trabajo es la administración de los requerimientos y en determinar la probabilidad de impacto por un requerimiento nuevo. En cuanto al aspecto de control de los cambios esté dependerá mucho de las políticas del equipo de desarrollo, temas que se cubrirán en trabajos futuros.
3.2
Justificación del Nuevo Software
Los problemas a resolver con la computadora, basándose en la problemática de la situación actual están principalmente en una evaluación del cambio propuesto y reflejar el impacto sobre la Línea Base'de Requerimientos, HEARS podrá enfrentar esta problemática reportando un diagrama de impacto con métricas probabilísticas, sobre los requerimientos ya establecidos. También se resuelve el problema de almacenar requerimientos en hojas de papel o en un medio electrónico como Excel y no saber cómo están relacionados lógicamente los requerimientos.
3.3
Propuesta Computacional
La propuesta de la herramienta HEARS está compuesta principalmente por dos pistas, Requerimiento y Trazabilidad-Análisis, las cuales trabajan conjuntamente para administrar los requerimientos, crear la trazabilidad y finalmente poder analizar el impacto de un requerimiento propuesto.
A continuación se explicarán más a detalle las pistas Requerimiento y Trazabilidad-Análisis de la propuesta computacional.
3.3.1 Pista Requerimiento
HEARS podrá crear la Línea Base de Requerimientos, a los requerimientos pertenecientes a la LBR se les podrán crear nuevos atributos con sus valores válidos, se realizará la creación de reportes de al LBR (ver la Figura 16).
Guión: HEARS
Escena 1: Creación LBR Pista: Requerimiento
Papeles:
Importa AT de Proyecto y Involucrados
ADM: Administrador
Utensilios:
ADM crea RE de LBR ADM ingresa W de AT
RE: Requerimiento Escena 2: Crear Nuevo AT a RE
AT: Atributos
FEC: Fecha de Cambio CAL: Calendario
REP: Reporte
ADM crea Nuevo AT
LBR: Línea Base de Requerimientos
Condiciones de Entrada:
Escena 3: Actualiza Requerimiento
ADM actualiza RE
ADM necesita crear LBR, Nuevo AT, Capturar RE y Reporte de LBR
ADM ingresa nuevo Valor de AT
Condiciones de salida: ADM crea LBR,
Escena 4: Reporte LBR
Nuevo AT, Captura RE y Reporte de LBR
ADM imprime REP de LBR
Figura 16. Pista Requerimiento de HEARS
A Continuación se aclaran unas quintetas de la Pista Requerimiento
Pista-, Requerimiento ADM crea Nuevo AT
Pista: Requerimiento ADM actualiza RE
Escena 2: Actualiza Requerimiento El ADM cambia uno o varios AT del RE, una vez cambiados el ADM ingresa forzosamente la FEC.
Pista: Requerimiento ADM imprime REP de LRB
Escena 3: Reporte de LBR El Administrador podrá imprimir reportes de la Línea de Requerimientos Base, estos reportes serán creados en WORD y EXCEL.
3.3.2 Pista Trazabilidad-Análisis
Una vez que se han creado la Línea Base de Requerimientos del proyecto, es necesario crear la trazabilidad de los requerimientos, el administrador sólo podrá crear trazabilidad pregrabada y dependencia, las trazabilidades experiencia plana y extrapolación las realiza internamente HEARS.
La trazabilidad es necesaria para realizar el análisis de certeza de impacto y precaución de impacto; como resultado de este análisis HEARS imprimirá un diagrama de los requerimientos impactados con sus probabilidades de impacto, con esta información se podrán crear reportes y finalmente si el requerimiento candidato es aprobado se podrá agregar este a la Línea Base de Requerimientos (Figura 17).
Guión: HEARS
Pista: Trazabilidad-Análisis
Escena 1: Crear Trazabilidad
ADM crea Trazabilidad
Papeles: \ ¿No hay trazabilidad pregrabada o
ADM: Administrador de dependedencia?
Utensilios: RE: Requerimiento
'í ADM crea trazos entre RE
REC: Requerimiento Candidato NC: Nivelde Corte
Escena2:Analizar REC
GD: Grado Definición ADM crea REC y selecciona GDy GC
GC: Grado Certeza ADM crea trazos directos de REC
DIA: Diagrama deImpacto ADM selecciona NC
REP: Reporte deImpacto ADM analiza REC
LBR: Línea Base de Requerimientos
ADMvisualiza DIA y crea REP
Condicionesde Entrada: ¿ADM no está de acuerdo?
ADM necesita análisis de REC
Condicionesde salida:
' {ADM regresa Escena 2} ADM analiza REC, visualiza
DIA, crea REP, crea RE Nuevo ADM ingresa REC con RE Nuevo
Figura 17. Pista Trazabilidad de HEARS
A continuación se aclaran unas quintetas de la Pista Trazabilidad
Pista: Trazabilidad ADM crea trazos entre RE
Escena 1: Crear Trazabilidad El ADM podrá crear trazos directos de impacto entre un RE y otros RE’s (uno - muchos), los trazos podrán ser de Trazabilidad Pregrabada o de Dependencia.
Pista: Trazabilidad ADM crea trazos directos de REC
Escena 2: Analizar REC El ADM podrá crea trazos directos de impacto entre un REC y otros RE’s pertenecientes a la LBR (uno - muchos).
Pista-, Trazabilidad ADM selecciona NC
Escena 2: Analizar REC El ADM podrá selecciona el Nivel de Corte de significancia para el análisis del REC
Pista: Requerimiento ADM ingresa REC a LBR
3.4 Prototipo de HEARS
Un prototipo ofrece al usuario potencial una idea general de cómo estará integrada la aplicación, se mostrará en general la funcionalidad de las pantallas; para mayor detalle de operación se sugiere consultar el manual de operación que se presenta en el Apéndice B del trabajo.
En la Imagen 1 se muestra la pantalla principal del sistema, donde se podrá acceder a las opciones principales de la aplicación, se observa la opción “Requerimiento” estas opciones están principalmente enfocadas a la administración de los requerimientos del proyecto activo.
Imagen 2. Menú de Trazabilidad de HEARS
La Imagen 2 se muestra la opción de “trazabilidad”, estas opciones están enfocadas a la creación de trazabilidad de los requerimientos a si como también analizar el impacto de un requerimiento candidato.
■ • Nombre. ' ' ' Cargó . José Morales Programador Roberto Perez Analista Maria Salas Líder Equipo Laura Masías Programador
Requerimientos
Nombré ' Tipo Estado Prioridad ■ Reporte Altas Funcional Desarrollo Alta Repode Bajas Funcional Desarrollo Alta Calificación Final No Funcional Desarrollo Alta Promedio Funcional Desarrollo Alta Reporte Interno No Funcional Desarrollo Alta
"7
Cnnqnlta Funcional Desarmlln Alta
.-i.^+iBequerimiento...;;.-;
Imagen 3. Ventana de Creación de Linea de Requerimientos Base de HEARS
Se muestra en la Imagen 3 cómo estarán enlistados los requerimientos de la línea base del proyecto activo, desde esta pantalla se podrá agregar un requerimiento nuevo.
La Imagen 4 presenta la pantalla donde se podrá agregar un requerimiento con su respectiva información, misma que será almacenada en una base de datos.
Requerimiento Candidato Nombre [pago en Linea Descripción
Grado Definición j.5 | Certeza Definici... |.s j
fZJ
Nivel de Corte
- Impactados Directos Alta
Baja Préstamo Devolución
Renovación I '» I Consulta
Imprimir Análisis 1 í Guardar R a LBR
Imagen 6. Ventana para analizar un requerimiento nuevo en HEARS
En la Imagen 6 se muestra cómo el usuario puede analizar un requerimiento candidato sin implantarlo en el proyecto, solamente se le solicita información básica para poder realizar el análisis de impacto.
3.5
Bitácora de Desarrollo de HEARS
A continuación se muestra la bitácora de Desarrollo de HEARS, ésta muestra principalmente una guía del diseño funcional del sistema con su respectiva forma de comprobación, también es una forma de comprobar los tiempos propuestos y los tiempos reales de desarrollo.
3.5.1 Pista Requerimiento
Quinteta Forma de Comprobación Tiempo Estimado
Tiempo Real Importa AT de
Proyecto y Involucrados
Típico'. Se recupera el nombre del proyecto y los nombres de los involucrados
Indeseable: Se recupera la información incorrecta
Fallido: No se conecto a la base de datos
20 hrs.
ADM crea RE de LBR
Típico: Se activa interfaz para crear el RE
Indeseable: No se selecciona el botón de agregar
Fallido: No se muestra interfaz
10 hrs.
ADM ingresa W deAT
Típico: Se ingresan los valores validos y se almacenan en la base de datos
Indeseable: Se ingresan valores no validos
Fallido: No se guarda en la base de datos
14 hrs.
Escena 2: Crear Nuevo AT a RE
Quinteta Forma de Comprobación Tiempo
Estimado
Tiempo Real ADM crea Nuevo
AT
Típico: Se crea el nuevo atributo y se actualiza la base de datos, para que puedan ser ingresados.
Indeseable: No son ingresados AT Fallido: No se actualiza la base de datos
16 hrs.
Escena 3: Actualiza Requerimiento
Quinteta Forma de Comprobación Tiempo
Estimado
Tiempo Real
ADM actualiza RE Típico: Se enlista todos los
requerimientos, y se selecciona el que será actualizado
Indeseable: No es seleccionado ningún requerimiento
Fallido: No se recupera de la base de datos
10 hrs.
ADM ingresa nuevo Valor de AT
Típico: Se muestran los valores
almacenados, y se ingresan 15 hrs.
