FV-GAIA - Trabajos de Grado de la facultad de …pegasus.javeriana.edu.co/~CIS1210TK05/Documento SRS...
Transcript of FV-GAIA - Trabajos de Grado de la facultad de …pegasus.javeriana.edu.co/~CIS1210TK05/Documento SRS...
FV-GAIA Framework para la Visualización de Grafos con Ayuda de Interfaces Aumentables
Documento: Especificación de Requerimientos de Software SRS Versión: 1.0
Autor: Federico Rodríguez Bravo
Documento Especificación de Requerimientos SRS ISTAR
1
Historial de Cambios
Fecha Versión Descripción de
cambio
Responsable
11/02/2012 0.1 Realización de la
plantilla del
documento
Federico
Rodriguez
Bravo
12/02/2012 0.2 Realizacion de
secciones 1 y 2
Federico
Rodriguez
Bravo
13/02/2012 0.3 Refinamiento
seccion 2 y
realización seccion
3.
Federico
Rodriguez
Bravo
14/02/2012 0.4 Documento
terminado.
Federico
Rodriguez
Bravo
17/02/2012 0.5 Presentacion del
documento.
Federico
Rodríguez
Bravo
27/02/2012 0.6 Revision del
documento.
Jaime
Pavlich-
Mariscal
29/02/2012 0.7 Revision de
comentarios de
Jaime Pavlich.
Federico
Rodríguez
Bravo
05/07/2012 0.8 Correccion de todo
el documento
teniendo presente la
implementacion de
FVGAIA.
Federico
Rodriguez
Bravo
06/07/2012 1.0 Revision de todo el
documento y
entrega.
Federico
Rodriguez
Bravo
Documento Especificación de Requerimientos SRS ISTAR
2
Tabla de Contenido
Historial de Cambios.................................................................................................................................. 1
Tabla de Contenido .................................................................................................................................... 2
Tabla de Tablas ............................................................................................................................................ 4
Tabla de Ilustraciones ............................................................................................................................... 5
1. Introducción ......................................................................................................................................... 6
1.1 Propósito ...................................................................................................................................... 6
1.2 Alcance........................................................................................................................................... 6
1.3 Definiciones, Acrónimos y Abreviaciones ........................................................................ 6
1.4 Referencias Bibliográficas ...................................................................................................... 7
1.5 Apreciación Global .................................................................................................................... 9
2. Descripción Global .......................................................................................................................... 10
2.1 Perspectiva del Producto .................................................................................................... 10
2.1.1 Interfaces con el Sistema ............................................................................................ 11
2.1.2 Interfaces con el Usuario ............................................................................................ 11
2.1.3 Interfaces con el Software .......................................................................................... 13
2.1.4 Interfaces con el Hardware ........................................................................................ 14
2.1.5 Restricciones Generales de Hardware .................................................................. 14
2.1.6 Operaciones ..................................................................................................................... 15
2.2 Funciones del Producto ....................................................................................................... 15
2.3 Características del Usuario ................................................................................................. 23
2.4 Restricciones ............................................................................................................................ 23
2.5 Suposiciones y Dependencias ............................................................................................ 24
3. Requerimientos Específicos ........................................................................................................ 25
3.1 Requerimientos Establecidos FV-GAIA .......................................................................... 25
3.2 Análisis de Requerimientos ................................................................................................ 28
3.2.1 Priorización ...................................................................................................................... 28
Documento Especificación de Requerimientos SRS ISTAR
3
3.2.2 Grafo de Dependencias y Grupos Coherentes .................................................... 31
3.2.3 Trazabilidad ..................................................................................................................... 34
3.3 Distribución de Requerimientos ...................................................................................... 35
3.3.1 Requerimientos Funcionales .................................................................................... 36
3.3.2 Requerimientos No Funcionales .............................................................................. 36
3.4 Restricciones de Diseño ....................................................................................................... 38
3.5 Requisitos de Verificación y Validación ......................................................................... 38
3.6 Riesgos ........................................................................................................................................ 39
Documento Especificación de Requerimientos SRS ISTAR
4
Tabla de Tablas
Tabla 1: Restricciones de memoria ................................................................................................... 14
Tabla 2: Restricciones ............................................................................................................................ 24
Tabla 3: Requerimientos establecidos FV-GAIA .......................................................................... 27
Tabla 4: Priorización por valor, costo y riesgo [11] ................................................................... 31
Tabla 5: Grupos coherentes ................................................................................................................. 34
Tabla 6: Medición requerimientos funcionales ............................................................................ 36
Tabla 7: Medición mantenibilidad [18] ........................................................................................... 37
Tabla 8: Aspectos de calidad requerimientos funcionales [24] [27] ................................... 39
Tabla 9: Aspectos de calidad requerimientos no funcionales [24] [27] ............................. 39
Tabla 10: Riesgos en requerimientos............................................................................................... 40
Tabla 11: Respuesta a riegos de requerimientos ........................................................................ 41
Documento Especificación de Requerimientos SRS ISTAR
5
Tabla de Ilustraciones
Ilustración 1: Descripción Global SRS .............................................................................................. 10
Ilustración 2: Perspectiva de FV-GAIA............................................................................................. 11
Ilustración 3: Interfaces con el Usuario .......................................................................................... 12
Ilustración 4: Interfaces con el Software ........................................................................................ 13
Ilustración 5: Creación de nodos y aristas por medio de primitivas gráficas [11] ......... 15
Ilustración 6: Elementos básicos de grafos [11] .......................................................................... 16
Ilustración 7: Transformaciones geométricas [11] .................................................................... 16
Ilustración 8: Nodos contenedores [11] ......................................................................................... 17
Ilustración 9: Grupos de nodos [11] ................................................................................................. 17
Ilustración 10: Nodos anclas [11] ...................................................................................................... 18
Ilustración 11: Barra de herramientas [11] .................................................................................. 19
Ilustración 12: Nivel de zoom aplicado a grafos (1) [11] ......................................................... 20
Ilustración 13: Nivel de zoom aplicado a grafos (2) [11] ......................................................... 20
Ilustración 14: Nivel de zoom aplicado a grafos (3) [11] ......................................................... 21
Ilustración 15: Layout de grafos [31] ............................................................................................... 22
Ilustración 16: Layout de nodos [11] ............................................................................................... 23
Ilustración 17: Layout de aristas [11] .............................................................................................. 23
Ilustración 18: Suposiciones y Dependencias ............................................................................... 25
Ilustración 19: Beneficio relativo y penalti relativo [12] ......................................................... 28
Ilustración 20: Valor total y porcentual [12] ................................................................................ 29
Ilustración 21: Costo relativo y porcentual [12] .......................................................................... 29
Ilustración 22: Riesgo relativo y porcentual [12]........................................................................ 30
Ilustración 23: Prioridad y factor de ponderación [12] ............................................................ 30
Ilustración 24: Campos Matriz de Trazabilidad [13] [14] [15] .............................................. 35
Documento Especificación de Requerimientos SRS ISTAR
6
1. Introducción
1.1 Propósito
El presente documento unifica y describe el proceso de análisis que se realizó durante la
fase de concepción del trabajo de grado FV-GAIA: Framework para la Visualización de
Grafos con Ayuda de Interfaces Aumentables, para hacer la especificación de
requerimientos. Se describe la interacción del sistema, influencia y restricciones del entorno
junto con características físicas. Esto con el fin de tener un correcto comienzo para el
desarrollo del software y cumplir con las necesidades del cliente. La forma y organización
de este documento se deben a las plantillas de IRONWORKS y a la modificación realizada
en la materia de Ingeniería de Software [22] [23].
1.2 Alcance
FV-GAIA es un framework que permite visualizar y manipular grafos de gran tamaño,
permitirá integrarse a sistemas más robustos de software que implementen herramientas
CASE [1]. Tiene dos funcionalidades principalmente:
Manipulación de grafos.
Visualización de grafos.
Para más detalle sobre las características y funcionalidad de FV-GAIA se presentan en el
documento Visión.
1.3 Definiciones, Acrónimos y Abreviaciones
CASE: Computer Aided Software Engineering, son un conjunto de métodos,
utilidades y técnicas que facilitan la automatización del ciclo de vida del desarrollo
de sistemas de información, completamente o en alguna de sus fases [28].
FRAMEWORK: Es una estructura software compuesta de componentes
personalizables e intercambiables para el desarrollo de una aplicación [4]
FV-GAIA: Framework para la visualización de grafos con ayuda de interfaces
aumentables (Ver Documento Visión).
SRS (Software Requirements Specification): Presenta los resultados de la
definición de necesidad, el concepto operacional, y el análisis de requerimientos.
Como tal, es una descripción de lo que los clientes del sistema esperan que haga, el
perfil del sistema de uso, sus parámetros de desempeño, la calidad esperada y
eficacia [3].
SVG: Es una especificación para describir gráficos vectoriales tanto estáticos como
animados [10].
ZUI: Zoomable User Interface o Interface de Usuario Aumentable, es un ambiente
gráfico donde los usuarios pueden cambiar la escala de la vista de un área específica
con el fin de ver más o menos detalle de la imagen [2].
Documento Especificación de Requerimientos SRS ISTAR
7
1.4 Referencias Bibliográficas
[1] Jaime A. Pavlich M, Hernan D. Veliz Q, steven A. Demurjian and Laurent D. Michel,
“Un ambiente de meta-modelamiento y visualización basado en el paradigma de zoomable
user interfaces”.
[2] Zoomable User Interface, consulta realizada 31/01/2012, [En línea] Disponible en:
http://www.usabilitypost.com/2009/02/09/zoomable-user-interfaces/, enero 31/2012.
[3] SRS, consulta realizada 05/02/2012, [En línea] Disponible en:
http://www.ts.mah.se/RUP/RationalUnifiedProcess/webtmpl/templates/req/rup_srs.htm#3.9
.3.
[4] Javier J. Gutiérrez, ¿Que es un framework web?, consulta realizada 31/01/2012, [En
línea] Disponible en: http://www.cssblog.es/guias/Framework.pdf.
[5] Máquina Virtual de Java (JVM), consulta realizada 12/02/2012, [En línea] Disponible
en: http://www.java.com/es/download.
[6] Windows 7, consulta realizada 12/02/2012, [En línea] Disponible en:
http://windows.microsoft.com/es-ES/windows7.
[7] Linux Ubuntu, consulta realizada 12/02/2012, [En línea] Disponible en:
http://www.ubuntu.com/ubuntu.
[8] Grafos, consulta realizada 11/02/12, [En línea] Disponible en:
http://www.itnuevolaredo.edu.mx/takeyas/Apuntes/Estructura%20de%20Datos/Apuntes/gr
afos/Apuntes_Grafos.pdf.
[9] ZVTM – Zoomable Visual Transformation Machine, consulta realizada 31/01/2012,
[En línea] Disponible en: http://zvtm.sourceforge.net/, enero 31/2012.
[10] Scalable Graphic Viewer, consulta realizada 31/01/2012 [En línea] Disponible
http://www.adobe.com/svg/viewer/install/main.html.
[11] Jaime A. Pavlich, ZooMEnv-2.0 Concrete Syntax Requirements, presentación power
point.
[12] Karl E. Wiegers, First Things First: Prioritizing Requirements, consulta realizada
04/02/2012, [En line] Disponible en:
http://www.processimpact.com/articles/prioritizing.html.
[13] I. Sommerville, Software Engineering, Ninth Edition. New York: Pearson Education
Inc. 2010.
Documento Especificación de Requerimientos SRS ISTAR
8
[14] Matriz de trazabilidad de requerimientos, , consulta realizada 05/02/2012, [En línea]
Disponible en:
http://webcache.googleusercontent.com/search?q=cache:V7vYWBg0DV8J:www2.cdc.gov/
cdcup/library/templates/CDC_UP_Requirements_Traceability_Matrix_Template.xls+Requi
rement+Traceability+Matrix&cd=2&hl=es&ct=clnk&gl=co.
[15] Requirements Traceability, , consulta realizada 05/02/2012, [En línea] Disponible en:
http://www.gatherspace.com/static/requirements_traceability.html.
[16] Software Testing-Requirements Traceability Matrix, consulta realizada 05/02/2012,
[En línea] Disponible en:
http://www.etestinghub.com/requirements_traceability_matrix.php.
[17] Elizabeth Hull, K. J. & Dick, J. Springer (Ed.), Requirements Engineering Segunda
Edición, 2005
[18] Breves notas sobre la Medición de los Atributos Externos del Software, Consulta
realizada 08/02/2012, [En línea] Disponible en:
http://www.sc.ehu.es/jiwdocoj/mmis/externas.htm.
[19] Bárbara Espinoza, Vanessa Quintas y Alexandra Vega, Pruebas de Desempeño,
consulta realizada 31/01/2012, [En línea] Disponible en:
http://carolina.terna.net/ingsw3/datos/Pruebas_de_Desempe%F1o.pdf.
[20] IEEE Std 1012-1986 IEEE Standard for software Verification and Validation Plans.
[21] IEEE Std 1012-2004 IEEE Standard for Software Verification and Validation.
[22] Plantilla Ironworks SRS. Pontificia Universidad Javeriana. Bogotá: 2008.
[23] Santiago Quintero, Danilo Andrés Escobar, Lina Correa, Federico Rodríguez, Ángela
Riveros y Juan Camilo Olaya, CromTech septiembre 2010.
[24] Construx Software Presents, Requirements Toolbox,
http://construx.com/Page.aspx?nid=204, febrero 4/2012.
[25] Requerimientos del Software, http://requerimientos.galeon.com/, febrero 4/2012.
[26] Wiegers, K. E. Press, M. (Ed.) Software Requirements. 2nd Edition, 2003.
[27] Camacho Z. Nicolas, Herramienta para el análisis de requerimientos dentro de la
pequeña empresa desarrolladora de software en Bogotá,
http://www.javeriana.edu.co/biblos/tesis/ingenieria/Tesis189.pdf, 2005.
Documento Especificación de Requerimientos SRS ISTAR
9
[28] Instituto nacional de estadística e informática, “Herramientas Case”, consulta realizada
20/08/2011, [En línea] Disponible en:
http://www.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5103/Libro.pdf.
[29] jgraph, 29/02/2012, [En línea] Disponible en: http://www.jgraph.com/jgraph.html.
[30] JUNG, 29/02/2012, [En línea] Disponible en: http://www.jgraph.com/jgraph.html.
[31] Major Layout Algotithms, 29/02/2012, [En línea] Disponible en:
http://docs.yworks.com/yfiles/doc/developers-guide/major_layouters.html.
1.5 Apreciación Global
Este documento contiene la descripción del proceso que se realizó durante la fase de
concepción del trabajo de grado FV-GAIA para la elaboración, seguimiento, validación y
control de los requerimientos establecidos, las características de hardware y software que
debe tener el entorno para que FV-GAIA funcione correctamente (Ver sección Descripción
Global). Se encuentran las especificaciones del framework y de los requerimientos (Ver
sección Requerimientos Específicos). El siguiente mapa muestra los elementos principales
que componen el documento.
Documento Especificación de Requerimientos SRS ISTAR
10
Ilustración 1: Descripción Global SRS
2. Descripción Global
2.1 Perspectiva del Producto
Esta sección presenta la especificación de FV-GAIA, el cual va a ser especificado a lo largo
del documento SRS.
SRS
Descripción Global
Perspectiva del Producto
Funciones del Producto
Restricciones
Suposiciones y dependencias
Requerimientos Específicos
Análisis de Requerimientos
Requerimientos
Resticciones y Requisitos
Documento Especificación de Requerimientos SRS ISTAR
11
FV-GAIA como producto presenta la siguiente característica principal.
Ilustración 2: Perspectiva de FV-GAIA
Para ver con mayor detalle las principales características y funcionalidades de FV-GAIA se
encuentran especificadas en el documento Visión.
2.1.1 Interfaces con el Sistema
El desarrollo de FV-GAIA se basa en un framework base que su proceso de elección y
selección se puede ver en el documento de Proceso de Escogencia del Framework Base,
este se integrará con FV-GAIA por medio de importación paquetes, clases e instancias.
Para el funcionamiento de FV-GAIA después de estar integrado con el framework base no
necesita integrarse con ningún sistema, pero su arquitectura debe permitir poder integrarse
con otros proyectos de software por medio de importación paquetes, clases e instancias
para que estos proyectos de software aprovechen toda su funcionalidad. FV-GAIA se
integrará con ZooMEnv pero también puede ser utilizado por otros sistemas de software
que su finalidad sea la creación de herramientas CASE.
2.1.2 Interfaces con el Usuario
La descripción de las interfaces con las que interactúa el usuario de FV-GAIA se pueden
observar en la ilustración 2:
• FV-GAIA será una mejora del componente de Visualizacion ZUI de ZooMEnv [1], ya que el existente presenta dificultades al manipular y visualizar grafos de gran tamaño, y no esta construido bajo buenas paracticas de ingeniería de software, lo que lo hace difícil de modificar y actualizar, pero este no solo será exclusivo de ZooMEnv sino que permitirá integrarse con desarrollos de software mas robustos para facilitar la vizualización y manipulación de grafos o modelos de software.
FV-GAIA es un producto nuevo
Documento Especificación de Requerimientos SRS ISTAR
12
Ilustración 3: Interfaces con el Usuario
La ilustración 3 presenta las interfaces de usuario que FV-GAIA utilizará para su
funcionamiento e interacción con el usuario. Estas cinco interfaces presentan usos muy
diferentes, las tres primeras son para que el usuario pueda interactuar con FV-GAIA de
forma que permitan al usuario explorar toda la funcionalidad que expone el framework, la
cuarta es un tipo de interfaz gráfica que se presenta de forma gráfica por medio de la
pantalla, es la única ventana de la aplicación donde el usuario visualizará e interactuará con
FV-GAIA y la quinta es el medio que el desarrollador de software usa para interactuar con
el diseño y desarrollo del framework.
Ratón: Es un dispositivo que ayuda al usuario a interactuar con la interfaz gráfica que provee FV-GAIA
Teclado: Es un dispositivo de entrada que el usuario necesitará para llenar primitivas graficas de texto y realizar alguna operacion entre nodos por medio de combinaciones de de teclas y clics.
Pantalla: Es un dispositivo de salida que despliega la interfaz grafica de FV-GAIA donde se interactua con la aplicación, sus componentes y ejecutables.
ZUI: Posibilita la interacción entre el usuario y el sistema por medio de primitivas gráficas. Las interfaces gráficas serán desarrolladas en Java Swing ayudado de los graficos que proveera el framework base seleccionado.
Código Fuente: Son los conjunto de archivos fuentes que contienen todas las estructuras de datos y logica de FV-GAIA, es provisto a los usuarios para realizar la integración con otros proyectos de software, realizar modificaciones o mejoras.
Documento Especificación de Requerimientos SRS ISTAR
13
2.1.3 Interfaces con el Software
Esta sección describe las interfaces de software. Son componentes reutilizados desde otra
aplicación como bibliotecas que contienen código y datos, las cuales proporcionan servicios
a programas independientes y ayudan al desarrollo del software.
Los elementos de software que interactúan con FV-GAIA son:
Ilustración 4: Interfaces con el Software
2.1.3.1 ZVTM
A continuación se listan las características más importantes y esenciales que maneja ZVTM
[4].
Windows 7.
Descripción: Windows 7 es una versión de un sistema opertivo de Microsoft Windows. Tiene versiones para 32 y 64 bits.
Versión: Home Premium.
Fuente: [6]
Linux Ubuntu. Descripcion : Ubuntu es una version del sistema operativo Linux es facil de usar, libre y esta en versiones para 32 y 64 bits.
Version actual : 11.10
Fuente: [7]
Java Virtual Machine.
Descripción: Es un programa que interpreta código hecho en Java [2].
Propósito de Uso: es una aplicación hecha en Java el cual necesita el JVM para un correcto funcionamiento.
Versión: Versión 6 Update 21
Fuente : [5]
ZVTM.
Es un herramienta implementada en Java2D diseñada para facilitar la tarea de creación de complejos editores visuales en los que una gran cantidad de objetos se mostrarán, o que contienen formas geométricas complejas[9]. Sera la libreria base que se utilizara para el desarrollo de FV-GAIA.
Fuente: [9]
JUNG
• Java Universal Network / Graph es una librería que provee un común y extensible lenguaje para modelar, analizar y visualizar datos que se puede representar por medio de grafos o redes. Esta desarrollado sobre Java [30].
Documento Especificación de Requerimientos SRS ISTAR
14
Es capaz de manejar grandes cantidades de objetos de forma eficiente.
Se basa en la metáfora de los universos que se pueden observar a través de cámaras
móviles inteligentes de acercamiento y de movimiento.
Ofrece soporte para vistas en múltiples capas y trasparencia de objetos.
Tiene facilidades de utilizar animaciones en primitivas gráficas.
Diferentes tipos de visualización pueden ser activados durante la visualización de
grafos.
El modelo de objetos gráficos permiten que tareas como crear, modificar y animar
entidades sea más fácil.
Soporta subconjuntos de SVG [10].
2.1.3.2 JUNG
A continuación se listan las características más importantes y esenciales que maneja JUNG
[4].
La arquitectura de JUNG está diseñada para soportar una variedad de
representaciones de entidades y sus relaciones, como grafos directos, indirectos y
grafos multi modales.
Incluye una variada implementación de algoritmos de teoría de grafos, minería de
datos, y análisis de redes sociales.
Provee un framework de visualización que hace más fácil la construcción de
herramientas interactivas para la exploración de redes o grafos, por medio de
diferentes tipos de layout.
2.1.4 Interfaces con el Hardware
En este caso FV-GAIA no se va a preocupar por las interfaces con el hardware que están
relacionadas, de este aspecto se encargará ZVTM. ZVTM tendrá responsabilidades dentro
de FV-GAIA como lo es: el manejo de primitivas gráficas, movimientos de cámara, y
eventos relacionados con las primitivas gráficas que maneja, el desempeño en cuanto a los
recursos de hardware que consume al visualizar e interactuar con grafos de gran tamaño en
el lienzo y en el manejo de interfaces ZUI [2].
2.1.5 Restricciones Generales de Hardware
Componente Disco Duro Memoria RAM Uso de CPU Monitor
Java Virtual
Machine [5]
98MB 64MB 15% -35% No se
especifica
Microsoft Windows 7
32 bits [6]
16 GB de espacio
libre
1 GB 10 % 800x600 -
1366x768
Linux Ubuntu
32 bits [7]
15 GB de espacio
libre
1 GB 5 % 800x600 -
1366x768
Tabla 1: Restricciones de memoria
Documento Especificación de Requerimientos SRS ISTAR
15
2.1.6 Operaciones
FV-GAIA se enfocará a desarrolladores de software. Este usuario se describió en detalle en
la sección de características del usuario (Ver sección Características del Usuario).
FV-GAIA es un framework basado en visualizar objetos, su ejecución no necesita de
internet ni de acceso a bases de datos así que no se manejarán periodos de actividad e
inactividad los cuales se usan para realizar mantenimiento a la aplicación ni operaciones de
soporte a procesamiento, actualización o mantenimiento de bases de datos ya que no es una
aplicación que maneja persistencia ni conexiones con las mismas.
Sin embargo, cuenta con un proceso de recuperación ante fallos, el cual detecta un error en
el sistema y muestra un mensaje en la pantalla al usuario sobre el fallo, dependiendo del fin
con que el usuario use el framework este se mostrará en tiempo de ejecución o en tiempo
de compilación.
2.2 Funciones del Producto
Las funciones del FV-GAIA se enuncian en el documento Visión y se puede identificar
mejor en la sección Requerimientos Establecidos FV-GAIA (Ver Requerimientos
Establecidos FV-GAIA) en donde se especifica cada uno de los requerimientos. Pero a
continuación se hace una explicación más detallada de cada funcionalidad y su relación con
cada uno de los requerimientos establecidos.
Crear nodos y aristas por medio de primitivas gráficas: El usuario puede crear
nodos y aristas [8] por medio de la barra de herramientas en los botones y menús
correspondientes, estos nodos y aristas son primitivas gráficas como: líneas, splines,
rectángulos, óvalos, polígonos, imágenes y texto, esta función de producto hace
referencia al requerimiento R001 (Ver Requerimientos Establecidos FV-GAIA)
[11]. En la ilustración 5 se muestra los tipos de primitivas gráficas que FV-GAIA
debe manejar para crear nodos y aristas, y la ilustración 6 presenta los elementos
básicos de un grafo.
Ilustración 5: Creación de nodos y aristas por medio de primitivas gráficas [11]
Documento Especificación de Requerimientos SRS ISTAR
16
Ilustración 6: Elementos básicos de grafos [11]
Transformaciones geométricas a nodos, aristas y grafos: El usuario puede
manipular nodos y aristas por medio de trasformaciones geométricas (translación,
rotación y escalamiento), teniendo en cuenta que pueden ser aplicadas a nodos y
aristas contenedores, grupos de nodos o nodos anclas, esta función de producto hace
referencia a los requerimientos R006, R007, R008 y R009 (Ver Requerimientos
Establecidos FV-GAIA) [11]. En la ilustración 7 se muestran las trasformaciones
geométricas que FV-GAIA debe manejar para aplicar a nodos y aristas.
Ilustración 7: Transformaciones geométricas [11]
Crear grupos de nodos, nodos y aristas contenedores: El usuario podrá agrupar
nodos, esta operación se refiere a que el usuario podrá seleccionar varios nodos para
formar un grupo de nodos, también crear nodos y aristas contenedores los cuales
dentro ellos se podrán incluir otros nodos estos nodos son primitivas graficas como
se explicó en la primera función de producto, estas funciones de producto hacen
referencia a los requerimientos R003 y R004 (Ver Requerimientos Establecidos FV-
GAIA) [11]. En la ilustración 8 se muestra como FV-GAIA debería manejar nodos
y aristas contenedores, y en la ilustración 9 se muestra como FV-GAIA debería
manejar grupos de nodos.
Documento Especificación de Requerimientos SRS ISTAR
17
Ilustración 8: Nodos contenedores [11]
Ilustración 9: Grupos de nodos [11]
Pegar nodos por medio de anclas: El usuario puede acercar un nodo a otro nodo y
este nodo se tratará como solo uno para aplicar de trasformaciones geométricas, esta
función de producto hacen referencia al requerimiento R005 (Ver Requerimientos
Establecidos FV-GAIA) [11]. En la ilustración 10 se muestra como FV-GAIA
debería manejar nodos anclas.
Documento Especificación de Requerimientos SRS ISTAR
18
Ilustración 10: Nodos anclas [11]
Crear grafos, nodos y aristas en un nivel de zoom específico: El usuario al
navegar a través de zoom o panning sobre algún punto del plano 2D podrá crear
nodos y aristas, esta función de producto hacen referencia al requerimiento R002
(Ver Requerimientos Establecidos FV-GAIA) [11].
Eliminar y modificar nodos y aristas: La barra de herramientas que se presenta en
la ilustración 11 es la que le permite al usuario realizar todas las operaciones
posibles de manipulación a grafos, nodos y aristas, esta función de producto hacen
referencia al requerimiento R024 (Ver Requerimientos Establecidos FV-GAIA) [8]
[11].
Utilizar la barra de herramientas: La barra de herramientas que se presenta en la
ilustración 11 es la que le permite al usuario realizar todas las operaciones posibles
de manipulación y visualización a grafos, nodos y aristas, esta función de producto
hacen referencia al requerimiento R023 (Ver Requerimientos Establecidos FV-
GAIA) [8] [11]. En la ilustración 11 se muestra como FV-GAIA debe manejar una
barra de herramientas.
Documento Especificación de Requerimientos SRS ISTAR
19
Ilustración 11: Barra de herramientas [11]
Navegar a través de zoom y panning: El usuario navegará a través de la
aplicación por medio de zoom y panning, el zoom se utiliza para controlar la
profundidad y el panning para la navegación de un lado a otro lado en determinada
profundidad, esta función de producto hacen referencia al requerimiento R019 (Ver
Requerimientos Establecidos FV-GAIA) [11].
Visualizar grafos dependiendo del nivel de zoom: El usuario al navegar por
medio del zoom podrá visualizar cada uno de los grafos, nodos y aristas creadas, y
podrá explorar a fondo cada uno de estos elementos haciendo zoom para obtener
más detalle de cada uno. A mayor nivel de zoom más elementos se podrán
visualizar y a menor nivel de zoom los elementos más pequeños serán escondidos,
esta función de producto hacen referencia los requerimientos R020 y R021 (Ver
Requerimientos Establecidos FV-GAIA) [11]. La ilustración 12 tiene dos cuadros,
en el de la izquierda se ve el grafo a visualizar sin realizar ninguna navegación por
zoom y en la de la derecha se ve como al realizar zoom sobre el grafo se muestran
más detalles, nodos e información. La ilustración 13 también tiene dos cuadros en el
de la izquierda se ve el grafo a visualizar sin realizar ninguna navegación por zoom,
y en el de la derecha se ve como se acomodan los elementos al hacer zoom sobre el
grafo. La ilustración 14 es otro ejemplo del explicado para la ilustración 13.
Las siguientes ilustraciones muestran como FV-GAIA debe manejar el nivel de
zoom aplicado a grafos y como esconder o mostrar más detalles sobre un elemento
dependiendo del nivel de zoom.
Documento Especificación de Requerimientos SRS ISTAR
20
Ilustración 12: Nivel de zoom aplicado a grafos (1) [11]
Ilustración 13: Nivel de zoom aplicado a grafos (2) [11]
Documento Especificación de Requerimientos SRS ISTAR
21
Ilustración 14: Nivel de zoom aplicado a grafos (3) [11]
Manipular el layout grafos, nodos y aristas: El usuario podrá manipular los
distintos layout que manejan un grafo, un nodo o una arista este depende del tipo de
elemento que se manipule, el tipo de instancia y un rango. Esta función de producto
hacen referencia los requerimientos R010, R011, R012, R013, R014, R015, R016 y
R017 (Ver Requerimientos Establecidos FV-GAIA) [11]. La ilustración 15 muestra
los distintos layouts de grafos [31], estos pueden:
o Circulares: organiza los elementos de un grafo en forma de anillo o estrella
manteniendo las conexiones entre todos sus elementos.
o Jerárquicos: organiza los elementos respetando la jerarquía que tienen los
elementos creados donde estos pueden ser padres o hijos, los padres se
ponen arriba de los hijos.
o Ortogonales: Trata los elementos de grafos como elementos que tengan
fuerza dirigida como por ejemplo protones y electrones, de esta forma
organiza los elementos de un grafo.
o En Árbol: Organiza los elementos de un grafo en forma de árboles no
dirigidos o dirigidos.
La ilustración 16 muestra los distintos layouts de nodos que aplican a nodos
contenedores o grupos de nodos estos pueden ser:
o Matriciales: Se organizan los nodos en forma de filas y columnas alineados.
Documento Especificación de Requerimientos SRS ISTAR
22
o Padre: Se organizan los nodos con respecto a la posición medida desde el
origen del nodo padre.
La ilustración 17 muestra los distintos layouts de aristas estos pueden ser:
o Coordenadas: que los hijos se acomoden por medio de coordenadas y
distancia de una arista.
o Posicionamiento: los hijos de las aristas se acomoden o se organicen de
forma que no se oculten unos con otros.
En las siguientes ilustraciones se muestra como FV-GAIA debe manejar layouts en
grafos, nodos y aristas.
Ilustración 15: Layout de grafos [31]
Documento Especificación de Requerimientos SRS ISTAR
23
Ilustración 16: Layout de nodos [11]
Ilustración 17: Layout de aristas [11]
2.3 Características del Usuario
Las características de los usuarios que interactuarán con FV-GAIA se describieron en el
documento Visión en la sección Perfiles de Stakeholders.
2.4 Restricciones
Las restricciones que se muestran en la tabla 2 están basadas en las necesidades de los
clientes previamente impuestas en documento visión en la sección alcance y otras
identificadas durante el desarrollo de este documento y de actividades asociadas al análisis
de requerimientos.
Restricciones Generales Restricciones de Software Restricciones de Hardware
El framework debe El lenguaje de FV-GAIA debe tener
Documento Especificación de Requerimientos SRS ISTAR
24
manejar un bloque
de construcción de
clases y objetos que
haga consistente el
grafo visualizado
como el que se está
guardando en objetos
e instancias, debe ser
el mismo.
El framework de
poder integrarse con
otros proyectos de
software o
herramientas CASE.
La navegación por
zoom y panning
debe hacerse de
forma fluida y
animada.
FV-GAIA debe
proveer un API y
ejecutables que
presenten las
funcionalidades del
framework,
incluyendo el código
fuente de dichos
ejecutables.
Esta versión de FV-
GAIA no presentará
internacionalización.
programación que se
usará para implementar el
producto será Java 6.
un alto desempeño al
manejar grafos de
grandes cantidades de
elementos y debe ser
fluido la interacción
con la interfaz ZUI y
grafos [2].
Al ejecutar el
framework este no
debe usar más del 50
% de la memoria, ni
más del 50 % de la
CPU.
El hardware mínimo
con que FV-GAIA se
espera que función
debe tener 1GB en
memoria, una tarjeta
de video integrada o
independiente de
128MB y en cuanto al
espacio en disco no se
especifica por qué no
lo requiere para su
funcionamiento.
Tabla 2: Restricciones
2.5 Suposiciones y Dependencias
FV-GAIA tiene como suposiciones y dependencias para la realización del proyecto de
desarrollo de software y para la ejecución del framework los siguientes aspectos que se
muestran en la ilustración 18.
Documento Especificación de Requerimientos SRS ISTAR
25
Ilustración 18: Suposiciones y Dependencias
3. Requerimientos Específicos
Esta sección tiene como propósito describir el procedimiento que se llevó a cabo para el
análisis de los requerimientos establecidos para el desarrollo de FV-GAIA, como estos
requerimientos fueron dados y establecidos por el director de proyecto no se presentan los
casos de uso sino todo el estudio que se llevó a cabo acerca de los requerimientos dados.
3.1 Requerimientos Establecidos FV-GAIA
Los requerimientos establecidos para FV-GAIA se presentan a continuación en la tabla 3.
Código
Requerimiento
Requerimiento Tipo
R001 El framework debe permitir crear nodos y
aristas por medio de primitivas gráficas en
forma vectorial (líneas, splines, rectángulos,
óvalos, polígonos, imágenes y texto).
Funcional
R002 El framework debe permitir crear y manejar
elementos básicos de grafos (nodo y aristas).
Funcional
R003 El framework debe manejar nodos que tenga la
propiedad de anclas.
Funcional
R004 El framework debe manejar aristas y nodos
contenedores.
Funcional
R005 El framework debe manejar nodos que tenga la
propiedad de realizar grupos de nodos.
Funcional
R006 El framework debe manejar transformaciones
geométricas aplicadas a nodos y aristas.
Funcional
Suposiciones • Una vez que el cliente ha aprobado los requerimientos, no habrá modificaciones de
éstos en ningún hito.
• La maquina vitural de Java esta instalada.
Dependencias • La velocidad de la tarjeta gráfica es pertinente para que la aplicación se ejecute y
funcione correctamente.
• La reutilización de codigo de la librería base seleccionada.
• La utilización y aprendizaje del uso de la aplicación depende del tiempo que el usuario se gaste en familiarizarse con ella, con su código y los manuales de usuario.
Documento Especificación de Requerimientos SRS ISTAR
26
R007 El framework debe manejar trasformaciones
geométricas teniendo en cuenta como la
transformación puede aplicar a un nodo o arista
contenedor.
Funcional
R008 El framework debe manejar transformaciones
geométricas teniendo en cuenta como la
transformación puede aplicar a nodos que
tienen la propiedad de anclas.
Funcional
R009 El framework debe manejar transformaciones
geométricas teniendo en cuenta como la
transformación puede aplicar si es un grupo de
nodos.
Funcional
R010 El framework debe organizar los elementos de
grafos con layouts circulares.
Funcional
R011 El framework debe organizar los elementos de
grafos con layouts jerárquicos.
Funcional
R012 El framework debe organizar los elementos de
grafos con layouts ortogonales.
Funcional
R013 El framework debe organizar los elementos de
grafos con layouts en árbol.
Funcional
R014 El framework debe organizar nodos que
pertenezcan a un contenedor o a un grupo de
nodos por medio del layout matricial.
Funcional
R015 El framework debe organizar nodos que
pertenezcan a un contenedor o a un grupo de
nodos por medio del layout padre (con respecto
a la posición medida desde el origen del nodo
padre).
Funcional
R016 El framework debe organizar los nodos
contenidos dentro de una arista con layout de
coordenadas (que los hijos se acomoden por
medio de coordenadas y distancia de una
arista).
Funcional
R017 El framework debe organizar los nodos
contenidos dentro de aristas con layout de
posicionamiento (Los hijos de las aristas se
acomoden en el espacio de forma que no se
oculten unos objetos con otros).
Funcional
R018 El framework debe tener estructuras de datos
que guarden la geometría de primitivas gráficas
y los datos expuestos en el grafo.
Funcional
Documento Especificación de Requerimientos SRS ISTAR
27
R019 El framework debe permitir visualizar y
navegar de forma animada a través de grafos
por medio del nivel de zoom dependiendo de
este, algunos elementos deben mostrarse u
ocultarse.
Funcional
R020 El framework debe manejar representaciones
de nodos que dependiendo del nivel de zoom,
este puede cambiar.
Funcional
R021 El framework debe permitir que el layout de
elementos pueda cambiar de acuerdo al nivel
de zoom.
Funcional
R022 El framework al realizar un nivel de zoom alto
sobre un nodo en específico debe manejar el
layout de nodos adyacentes, que se refiere a
reposicionar los nodos con que se relaciona
directamente el nodo enfocado.
Funcional
R023 El framework debe manejar una barra de
herramientas que permita la creación y
modificación de elementos de grafos (nodos y
aristas), cuadros de texto, imágenes.
Funcional
R024 El framework debe permitir eliminar, modificar
su contenido y modificar la forma de nodos,
aristas y grafos. Las modificaciones pueden
ser: traslación, escalamiento.
Funcional
R025 El framework debe manejar alta cohesión y
bajo acoplamiento para realizar actualizaciones
y modificaciones futuras al sistema.
No
Funcional
R026 El framework debe tener un desempeño y
procesamiento que logre pasar el protocolo de
pruebas especificado en el documento estudio
de librerías.
No
Funcional
R027 El framework debe brindar a los usuarios una
descripción de los pasos requeridos para
realizar cada uno de las funcionalidades que
ofrece el sistema por medio de manuales de
usuario e instalación.
No
Funcional
R028 El framework debe ofrecer formas de
integración con otros sistemas como con
ZooMEnv.
No
Funcional
Tabla 3: Requerimientos establecidos FV-GAIA
Documento Especificación de Requerimientos SRS ISTAR
28
3.2 Análisis de Requerimientos
En esta sección se describe el proceso de análisis de los requerimientos establecidos para
FV-GAIA de acuerdo a la tabla 3 de requerimientos establecidos que son los cuales FV-
GAIA tiene que satisfacer como herramienta de software.
3.2.1 Priorización
Para el proceso de priorización de requerimientos se tuvo en cuenta la medición de tipo
cuantitativo.
El proceso de priorización de requerimientos se basa en dos etapas:
Selección de criterios cuantitativos definidos para priorizar los requerimientos.
Estos criterios pueden ser basados en el negocio como las necesidades de los
clientes, el costo, el riesgo y los recursos [12].
La determinación de un ordenamiento especifico de acuerdo a los criterios para los
desarrolladores y el cliente. La priorización ayuda al desarrollador implementar el
producto de software de acuerdo a los criterios de priorización que ellos eligieron en
conjunto con los de los clientes.
La priorización tiene como objetivo hallar los requerimientos más importantes para
implementar al empezar el desarrollo del framework y cuales se puede dejar para después.
A continuación se presenta los criterios cuantitativos que se tuvo en cuenta para realizar la
priorización.
Criterios de Priorización basada en valor, costo y riesgo
Ilustración 19: Beneficio relativo y penalti relativo [12]
Relative Benefit (Beneficio relativo)
Se maneja una escala del 1-9 donde 1 significa que este requerimiento trae muy pocos
beneficios y 9 es que trae muchos beneficios.
El beneficio se refiere como tal a la perspectiva del negocio del producto de software, es decir,
el requerimineto al ser implementado qué grado de beneficio trae al ser implementarlo.
Pregunta rápida: ¿Qué tan importante es?
Relative Penalty (Penalty relativo)
Se maneja una escala del 1-9 donde 1 representa pocos inconvenientes a
la hora de la implementación y 9 significa que trae consigo muchos
inconvenientes a la hora de la implementacion .
Pregunta rápida: ¿Que tan difícil es de realizar?
Documento Especificación de Requerimientos SRS ISTAR
29
Ilustración 20: Valor total y porcentual [12]
Ilustración 21: Costo relativo y porcentual [12]
Total Value (Valor total)
Fórmula: Factor de ponderación del beneficio relativo * beneficio
relativo + factor de ponderación de penalty relativo * penalty relativo.
Es la suma del beneficio relativo y la multa.
Value % (% valor)
Fórmula: 100*valor total / total del porcentaje del valor.
Proporciona una característica a cada función.
Relative Cost (Costo relativo)
Se maneja una escala de 1-9 donde 1 es el más bajo y 9 es el más alto. Este cálculo se basa en la complejidad del requerimiento, la extensión de la interfaz de usuario de trabajo, la reutilización
de diseños existentes, niveles de prueba y de documentación.
Tiene que ver tanto el empalme del código con el proyecto y la adaptación del código
reutilizado al proyecto.
Pregunta rápida: ¿Cuánto me demoro haciéndolo?
Cost % (% costo)
Fórmula: 100*costo relativo/total del costo relativo.
Proporciona un porcentaje del costo.
Documento Especificación de Requerimientos SRS ISTAR
30
Ilustración 22: Riesgo relativo y porcentual [12]
Ilustración 23: Prioridad y factor de ponderación [12]
En la siguiente tabla 4 se muestra los resultados de la priorización realizada a cada uno de
los requerimientos establecidos, esta presenta la priorización por valor, costo y escala. Para
un mejor entendimiento de la priorización, en la sección anterior se presentó la lista de
requerimientos establecidos.
Relative Risk (riesgo relativo)
Se maneja una escala de 1-9 donde 1 representa programar sin ninguna dificultad y 9 representa un
nivel de dificultad alto al programar.
La dificultad hace referencia a serias preocupaciones de viabilidad, disponibilidad del personal con experiencia, uso de herramientas no
familiares.
Pregunta rápida: ¿Sabemos implementarlo?
Risk % (% Riesgo)
Fórmula: 100*riesgo relativo / total del riesgo relativo.
Proporciona un porcentaje de riesgo.
Priority (Prioridad)
Fórmula: (% costo * costo + %riesgo *
riesgo)/% valor
Es el resultado del analisis de la prioridad
para cada requerimiento teniendo en cuenta los beneficios, penalties,
costo y riesgo.
Relative Weights (factor de
ponderacion)
Representa la importancia que se le da
a un campo ya sea al beneficio relativo,
penalty relativo, costo o riesgo.
No todas las perspectivas son iguales, ya que unos se enfocan en los deseos
del cliente y otros son necesarios para realizar otros requerimientos.
Prioridad(Risk/cost)
Formula :(% costo * costo + %riesgo * riesgo)
Es el resultado de la priorizacion del
requerimiento teniendo en cuenta el costo y el
riesgo de cada requerimiento.
Documento Especificación de Requerimientos SRS ISTAR
31
Número de requerimiento
Relative Benefit
Relative Penalty
Total Value
Value %
Relative Cost
Cost %
Relative Risk
Risk %
Priority Priority
(Risk/Cost)
R001 9 7 45 45,0 5 2,6 5 2,6 0,6 6,5077
R002 9 7 49 49,0 7 3,6 5 2,6 0,8 6,5077
R003 7 8 55 55,0 8 4,1 8 4,1 1,2 16,6597
R004 8 7 48 48,0 7 3,6 5 2,6 0,8 6,5077
R005 7 8 54 54,0 8 4,1 7 3,6 1,1 12,7551
R006 7 9 56 56,0 7 3,6 8 4,1 1,0 16,6597
R007 7 9 56 56,0 7 3,6 8 4,1 1,0 16,6597
R008 7 9 56 56,0 7 3,6 8 4,1 1,0 16,6597
R009 7 9 56 56,0 7 3,6 8 4,1 1,0 16,6597
R010 7 9 61 61,0 9 4,6 9 4,6 1,4 21,0850
R011 7 9 61 61,0 9 4,6 9 4,6 1,4 21,0850
R012 7 9 61 61,0 9 4,6 9 4,6 1,4 21,0850
R013 7 9 61 61,0 9 4,6 9 4,6 1,4 21,0850
R014 7 9 61 61,0 9 4,6 9 4,6 1,4 21,0850
R015 7 9 61 61,0 9 4,6 9 4,6 1,4 21,0850
R016 7 9 61 61,0 9 4,6 9 4,6 1,4 21,0850
R017 7 9 61 61,0 9 4,6 9 4,6 1,4 21,0850
R018 9 5 37 37,0 5 2,6 3 1,5 0,5 2,3428
R019 9 9 53 53,0 5 2,6 7 3,6 0,7 12,7551
R020 7 9 55 55,0 7 3,6 7 3,6 0,9 12,7551
R021 7 9 55 55,0 7 3,6 7 3,6 0,9 12,7551
R022 7 9 61 61,0 9 4,6 9 4,6 1,4 21,0850
R023 9 4 34 34,0 5 2,6 3 1,5 0,5 2,3428
R024 9 4 30 30,0 3 1,5 3 1,5 0,3 2,3428
R025 9 5 33 33,0 3 1,5 3 1,5 0,3 2,3428
R026 9 7 51 51,0 7 3,6 7 3,6 1,0 12,7551
R027 9 5 39 39,0 5 2,6 5 2,6 0,7 6,5077
R028 9 7 48 48,0 5 2,6 8 4,1 0,9 16,6597
Tabla 4: Priorización por valor, costo y riesgo [11]
3.2.2 Grafo de Dependencias y Grupos Coherentes
El grafo de dependencias representa los requerimientos, uno por cada nodo, haciendo una
ruta de dependencias, con el fin de hacer un seguimiento a estos requerimientos. Este grafo
Documento Especificación de Requerimientos SRS ISTAR
32
de dependencia muestra al desarrollador el posible impacto que tenga un cambio en
determinado requerimiento, el camino de dependencias que se tiene que seguir para llegar a
un requerimiento, el orden que da un requerimiento según sus dependencias que tenga, en
este caso sería desarrollar primero los menos dependientes para luego desarrollar los más
dependientes y también muestra la posible cascada de cambio ocasionada que se encuentra
latente en el sistema [14].
El grafo de dependencias se presenta a continuación. El resultado de este grafo es la
distribución de los requerimientos en varios grupos coherentes, mostrado en la distribución
de requerimientos realizada en el documento medición de requerimientos con el fin de
llevar un registro del estado de cada uno de los requerimientos a lo largo del desarrollo de
la aplicación.
Documento Especificación de Requerimientos SRS ISTAR
33
R001
R002
R003
R004
R005
R006
Creación y
manipulación
de grafos R010
Distribución de grafos en el espacio
R018
Bloques de
construcción de
grafos
R019
R024
R023
R021
R020
Visualización
de grafos
R025
R027
R028
Reglas de
Negocio
R026
R007
R008
R009
R011
R017
R016
R022
R014
R015
R013
R012
Documento Especificación de Requerimientos SRS ISTAR
34
Los grupos coherentes son un orden que recopila de una forma no estructurada ni
organizada los requerimientos, agrupándolos en grupos relacionados como son la creación
y manipulación de grafos, la distribución de grafos en el espacio, los bloques de
construcción de grafos, la visualización de grafos y las reglas de negocios. Estos grupos
salen de la realización del grafo de dependencias y permiten mirar cuales son los
requerimientos que más relación tiene entre sí [13].
Los grupos coherentes junto con los requerimientos asociados a cada grupo se encuentran
en el documento medición de requerimientos en la pestaña grupos coherentes.
Los grupos coherentes establecidos son el resultado de todos los requerimientos
establecidos del documento provistos por el director del proyecto [11]. La tabla 5 muestra
los grupos coherentes identificados y sus requerimientos asociados.
Grupo Coherente Requerimientos Asociados
Creación y manipulación de grafos R001, R002, R003, R004, R005, R006, R007,
R008, R009, R023 y R024.
Distribución de grafos en el espacio R010, R011, R012, R013, R014, R015, R016,
R017 y R022.
Bloques de construcción de grafos R018
Visualización de grafos R019, R020, R021
Reglas de negocios R025,R026,R027,R028
Tabla 5: Grupos coherentes
3.2.3 Trazabilidad
El propósito de la trazabilidad es determinar el impacto de un posible cambio [14]. El
proceso de trazabilidad ayuda a gestionar los cambios que se presenten en los
requerimientos, usando como elementos la matriz de trazabilidad realiza en el documento
matriz de trazabilidad y el grafo de dependencias mencionado con anterioridad [13] [14]
[15].
Documento Especificación de Requerimientos SRS ISTAR
35
La matriz de trazabilidad contiene los siguientes campos descritos a continuación:
Ilustración 24: Campos Matriz de Trazabilidad [13] [14] [15]
3.3 Distribución de Requerimientos
La distribución de requerimientos que se hará a continuación se clasificará de acuerdo al
grupo que pertenece, funcional o no funcional y su correspondiente grupo coherente. La
documentación de la distribución de requerimientos se encuentra el documento Medición
de Requerimientos.
ID
•Número de identificación único utilizado para
identificar el elemento de la matriz de trazabilidad de
requerimientos.
ID ´s Necesarios Asociados
•Esta columna debe contener los ID´s de los
requerimientos asociados.
Suposiciones Técnicas y/o Necesidades del cliente
•Esta columna se rellena con una descripción de las
hipótesis técnicas o necesidad de los clientes
relacionados con el requerimiento funcional.
Descripcion del requerimiento
•Esta columna se rellena con una descripción del
requerimiento funcional.
Estado
•Esta columna se rellena con el estado actual de la
condicióndel requerimiento funcional.
Componentes del Sistema Asosiados
•Esta columna se rellena con una descripción de los
componentes del sistema vinculado al requerimiento
funcional.
Módulos de Softwarre Asociados
• Esta columna se rellena con una descripción del módulo de software vinculado a la
condición funcional.
Implementado
•Esta columna se rellena de acuerdo a si el requerimiento
esta implementado o no.
Implementado en
•Esta columna se rellena con el o los métodos donde el
requerimiento a sido implementado.
Casos de pruebas relacionados
•Esta columna se rellena con los casos de prueba relacionados al requerimiento
funcional.
Comentarios
•Esta columna debe rellenarse con cualquier comentario adicional.
Documento Especificación de Requerimientos SRS ISTAR
36
3.3.1 Requerimientos Funcionales
La documentación de cada uno de los requerimientos funcionales organizados por grupos
coherentes se presenta a continuación. Esta documentación presentada no es la misma que
se lleva en la matriz de trazabilidad (Ver Sección 3.1.3 Trazabilidad), ya que presenta
campos que permite relacionar el requerimiento con la prioridad asociada, los riesgos
establecidos y un versiona miento del requerimiento. El formato para documentar cada uno
de los requerimientos funcionales se presenta en la tabla 6.
Numero de
Requerimiento
Tipo de
Requerimiento
Descripción
Criterio de
medición
Prioridad Grupo Coherente
Versión
Formato de
implementación Requerimientos
necesarios
Volatilidad
Riesgos Asociados
Tiempo Estado
Tabla 6: Medición requerimientos funcionales
3.3.2 Requerimientos No Funcionales
La documentación de cada uno de los requerimientos no funcionales organizados por
grupos coherentes se trató de diferente forma que para los requerimientos funcionales, ya
que para cada uno de estos se encontraron diferentes métricas de medición.
A continuación se presenta cada uno de los requerimientos no funcionales y su forma de
documentación y medición.
3.3.2.1 Mantenibilidad
Para el requerimiento no funcional de que FV-GAIA que en un futuro luego de su primera
versión, este se pudiera mantenerse se realizó una tabla en forma de encuesta que permite
medir que tan fácil se puede realizar el mantenimiento a un componente de FV-GAIA o a
todo el framework. La tabla 7 presenta cuatro aspectos a tener en cuenta a la hora de
realizar mantenimiento a un componente de software con el propósito que se especificará y
documentará lo más detallado posible el proceso de mantenimiento de software [19].
ID Mantenibilidad
Stakeholder
asociado
Documento Especificación de Requerimientos SRS ISTAR
37
Responsable
Mantenimiento al
Componente
Descripción
Tiempo en
realizar el
mantenimiento
Comentarios
acerca del
mantenimiento
Mantenimiento
Correctivo (e.g corregir errores)
Mantenimiento
Adaptativo (e.g modificar el software de acuerdo
con el entorno)
Mantenimiento
Perfectivo (e.g añadir nueva funcionalidad)
Mantenimiento
Preventivo (e.g cambiar el producto pensando en
mejoras futuras)
Tabla 7: Medición mantenibilidad [18]
3.3.2.2 Desempeño
Para el requerimiento no funcional que el framework presentará un buen desempeño se
realizaron la pruebas de desempeño en las que se evaluaron las Pruebas de Benchmark, las
Pruebas de Stress, las Pruebas de perfil de desempeño y las Pruebas de Carga [19]. En cada
una de ellas se evaluaron aspectos de rendimiento de hardware y tiempos de compilación
que permitieron medir mejor librería base candidata, también permitirá medir con mayor
precisión si FV-GAIA soporta el requerimiento durante su desarrollo y la culminación.
Para ver con más detalle las pruebas de desempeño consultar el documento estudio de
librerías en la pestaña plantilla prueba de desempeño.
3.3.2.3 Usabilidad
Para el requerimiento no funcional que el framework presentará usabilidad se realizó una
plantilla en forma de encuesta que midiera ciertos aspectos en cuanto a la funcionalidad que
presta FV-GAIA a un usuario final y que este lo pudiera usar de forma sencilla como lo
hace en una aplicación que presenta la característica de drag and drop y la interacción con
la interfaz gráfica. La plantilla de usabilidad se encuentra en el documento de medición de
requerimientos.
3.3.2.4 Integración
Para el requerimiento no funcional que el framework presentará facilidad de integración
con otros proyectos de software, se realizó una plantilla en forma de encuesta que midiera
aspectos de importancia para un desarrollador a la hora de explorar una nueva librería. Se
midieron aspectos como la exploración a su código fuente, si se podía compilar y ejecutar,
y si fue posible la reutilización de código por medio de la importación de paquetes e
instancias. Estos aspectos de medición surgieron de la tabla realizada para medir cada una
Documento Especificación de Requerimientos SRS ISTAR
38
de las librerías candidatas como framework base donde los aspectos en esta tabla se
trataban como facilidad de instalación y usabilidad. La plantilla de integración se encuentra
en el documento de medición de requerimientos.
3.4 Restricciones de Diseño
Para FV-GAIA se contemplan las siguientes restricciones de diseño:
La programación de FV-GAIA se realizará en Java.
El diseño y la arquitectura del mismo se basará en la estructura que maneja ZVTM,
que es la librería escogida.
ZVTM será el único componente de FV-GAIA que se comunicara con el hardware.
3.5 Requisitos de Verificación y Validación
En esta sección se encuentra el proceso que se realizó para hacer el control de calidad de
los requerimientos cuyo resultado se encuentra en el documento de revisión de calidad de
requerimientos. Con este proceso se va a asegurar que:
Los errores sean detectados y corregidos a tiempo.
Evitar los retrasos en el calendario.
Mejorar el proceso de la planeación de requerimientos.
Evaluar los cambios.
Certificar que los requerimientos estén escritos de forma correcta.
Para la revisión de calidad, los requerimientos establecidos se dividieron en requerimientos
funcionales y no funcionales. Para cada grupo se hizo una lista chequeo con el fin de
garantizar la calidad de los requerimientos [24] [25] [26] [27].
Para la verificación de la calidad de los requerimientos funcionales, se tuvo en cuenta que
cada requerimiento cumpliera con todas las características que debe tener un buen
requerimiento. La tabla 8 y la tabla 9 muestran las características que se tomaron en cuenta
para evaluar la calidad de los requerimientos funcionales y los no funcionales.
REQUERIMIENTOS FUNCIONALES
¿El requerimiento es completo?
¿El requerimiento es factible?
¿El requerimiento es necesario?
¿El requerimiento es priorizable?
¿El requerimiento es no ambiguo?
¿El requerimiento es verificable?
¿El requerimiento es claro?
¿El requerimiento tiene un identificador único?
¿El requerimiento está dentro del alcance?
¿El requerimiento es modificable?
Documento Especificación de Requerimientos SRS ISTAR
39
¿El requerimiento está escrito en el lenguaje del cliente, es decir,
usando la terminología del cliente?
¿El requerimiento es trazable?
Tabla 8: Aspectos de calidad requerimientos funcionales [24] [27]
REQUERIMIENTOS NO FUNCIONALES
¿Existen requerimientos de tiempo respuesta?
¿Existen requerimientos que especifiquen alguna restricción
operacional?
¿Todas las especificaciones de desempeño requeridas están listadas?
¿Están especificados los requerimientos de compatibilidad?
¿Están especificados los requerimientos de usabilidad?
¿Hay requerimientos de detección de errores o de recuperación del
sistema?
¿Existen requerimientos de persistencia?
¿Existen requerimientos que especifiquen la compatibilidad del sistema?
¿Hay requerimientos que se refieran a seguridad del sistema?
¿Hay requerimientos que especifiquen el rendimiento del sistema?
¿Los requerimientos son medibles?
Tabla 9: Aspectos de calidad requerimientos no funcionales [24] [27]
3.6 Riesgos Para el manejo de riesgos en los requerimientos se establecieron los siguientes riesgos de la
tabla 10, estos son esenciales para tenerlos en cuenta, para poder abordarlos y mitigarlos de
manera correcta.
ID Riesgos Requerimientos
RR01 Un requerimiento descrito tiene
más de una única interpretación.
RR02 El requerimiento no incluye todos
los requisitos significativos del
software.
RR03 Contradicción entre
requerimientos.
RR04 Un requerimiento no está descrito
en una forma verificable.
RR05 Designar de forma inadecuada la
prioridad
Documento Especificación de Requerimientos SRS ISTAR
40
RR06
La especificación de
requerimientos no maneja una
organización coherente y
manejable.
RR07 Requerimientos repetidos.
RR08 Un requerimiento afecta a otros si
es modificado.
RR09 Un requerimiento no es trazable.
Tabla 10: Riesgos en requerimientos
Dependiendo de los riesgos establecidos en la tabla anterior se presenta el siguiente
escenario de la tabla 11 de respuesta de riesgo el cual presenta el escenario para evitar y
mitigar un posible riesgo que llegue a pasar durante el desarrollo de FV-GAIA.
Documento Especificación de Requerimientos SRS ISTAR
41
Técnicas de respuesta a los riesgos
Posible Riesgo Evitar Mitigar Plan de Contingencia
Un requerimiento descrito tiene más de una única
interpretación.
Análisis riguroso del lenguaje de los requerimientos
escritos Listas de chequeo
Replantear el requerimiento
El requerimiento no incluye todos los requisitos
significativos del software.
Reuniones constantes con el cliente
Estudio del contexto del negocio
Corregir los requerimientos
Contradicción entre requerimientos.
Lectura cruzada de la lista de requerimientos
Reescribir el requerimiento
Eliminar el requerimiento que menos se acomode al
proyecto
Un requerimiento no está descrito en una forma
verificable.
Si el requerimiento tiene como resultado algo que
pertenece al producto final del proyecto
Listas de chequeo Corregir los
requerimientos
Designar de forma inadecuada la prioridad.
Una investigación adecuada de la priorización de
requerimientos
Usando adecuadamente las
plantillas de priorización
Realizar de nuevo las prioridades de los
requerimientos
La especificación de requerimientos no maneja
una organización coherente y manejable.
Teniendo claro los grupos coherentes de los
requerimientos
Correcta identificación de los grupos
coherentes y de los requerimientos
asociados
Reasignando los requerimientos a los
grupos coherentes de manera adecuada
Requerimientos que se repiten.
Revisión de los requerimientos identificados
Listas de chequeo Eliminar el requerimiento
que se repite
Un requerimiento no es trazable.
Realizando un grafo de dependencias y asociaciones
Análisis del grafo de dependencias y
asociaciones
Eliminar el requerimiento que no es trazable
Tabla 11: Respuesta a riegos de requerimientos