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


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


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


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


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


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%20Vision%20FV-GAIA%20v0.7.docx


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.


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.

http://www.etestinghub.com/requirements_traceability_matrix.php


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.


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


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


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.


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


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


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]


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.


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.


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.


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.


20

Ilustración 12: Nivel de zoom aplicado a grafos (1) [11]



21


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.


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]


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


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.


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.


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



transformación puede aplicar a nodos que

tienen la propiedad de anclas.

Funcional



transformación puede aplicar si es un grupo de

nodos.

Funcional

R010 El framework debe organizar los elementos de

grafos con layouts circulares.

Funcional


grafos con layouts jerárquicos.

Funcional


grafos con layouts ortogonales.

Funcional


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


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


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?


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.


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.


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


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.


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


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


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.


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


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


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?


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


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.


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

fv-gaia - trabajos de grado de la facultad de …pegasus.javeriana.edu.co/~cis1210tk05/documento srs...

Documents