srs software requirements specification.pegasus.javeriana.edu.co/~cis1530ap01/documentos/srs.pdf ·...
TRANSCRIPT
SRS SISINFOCOOP
1
SRS Software Requirements Specification.
Oscar Rey
Pontificia Universidad Javeriana
Facultad de Ingeniería
Agosto de 2015
SRS SISINFOCOOP
2
1 Historial de Cambios
Encargado Rol Versi
ón
Secció
n
Fecha Tipo Descripción
Oscar Rey Director de
Calidad
0.1 1,2,3,4 30/08/2015 Promoción Creación del
documento línea base,
con sus respectivas
secciones.
Oscar Rey Director de
Documentación
0.2 1.1 30/08/2015 Promoción Definición del
propósito del
documento.
Oscar Rey Director de
Documentación
0.3 2.1.1 30/08/2015 Promoción Definición de interfaces
con el sistema.
Oscar Rey Director de
Documentación
0.4 2.1.4 30/08/2015 Promoción Definición de interfaces
de software.
Oscar Rey Director de
Documentación
0.5 2.3 30/08/2015 Promoción Definición de
características de
usuario
Oscar Rey Director de
Calidad
0.6 1.5 30/08/2015 Promoción Definición de la
Apreciación global
Oscar Rey Director de
Calidad
0.7 2.1.3 30/08/2015 Promoción Definición de las
interfaces con el
hardware
Oscar Rey Gerente 0.8 2,1,2 01/09/2015 Promoción Definición de interfaces
con el usuario
Oscar Rey Director de
calidad
0.9 2.6 01/09/2015 Promoción Definición de las
suposiciones y
dependencias del
producto
Oscar Rey Director de
documentación
1.0 2.2 01/09/2015 Promoción Definición de las
funciones del producto
Oscar Rey Gerente 1.1 1 y 2 01/09/2015 Modificación Se modificaron las
SRS SISINFOCOOP
3
Tabla 1. Historial de cambios
secciones 1 y 2
Oscar Rey Director de
calidad
1.3 3.5 01/09/2015 Promoción Definición de
subcategorías.
Oscar Rey Director de
documentación
1.3.1 3.5 02/09/2015 Modificación Refinamiento de las
subcategorías por
medio de párrafos
explicativos.
Oscar Rey Director de
documentación
1.4 3.6 02/09/2015 Promoción Definición de las
especificaciones.
Oscar Rey Director de
calidad
1.4.1 3.6 02/09/2015 Modificación Refinamiento de las
especificaciones por
medio de una tabla de
requerimientos
implementados.
Oscar Rey Líder de
Desarrollo
1.7 3.4 03/09/2015 Promoción Se definió las
trazabilidades de los
requerimientos
Oscar Rey Analista de
Requerimientos
1.8 3.3 03/09/2015 Promoción Se definió las
prioridades de los
requerimientos
Oscar Rey Analista de
Requerimientos
1.9 4.5 13/09/2015 Promoción Se definió las
prioridades usada para
los requerimientos
SRS SISINFOCOOP
4
2 Tabla de contenido
1 Historial de Cambios ......................................................................................................... 2
2 Tabla de contenido ............................................................................................................. 4
3 Lista de Tablas ..................................................................................................................... 6
4 Lista de Ilustraciones ........................................................................................................ 7
1 Introducción ......................................................................................................................... 8
1.1 Propósito .................................................................................................................................. 8
1.2 Alcance ...................................................................................................................................... 8
1.3 Definiciones, Acrónimos, y Abreviaciones ..................................................................... 8
1.4 Referencias ............................................................................................................................ 10
1.5 Apreciación Global .............................................................................................................. 10
2 Descripción Global .......................................................................................................... 11
2.1 Perspectiva del Producto .................................................................................................. 11
2.1.1 Interfaces con el sistema ............................................................................................................... 11
2.1.2 Interfaces con el usuario................................................................................................................ 12
2.1.3 Interfaces de Hardware y Comunicación ............................................................................... 14
2.1.4 Interfaces con el Software ............................................................................................................. 14
2.1.5 Restricciones de Memoria ............................................................................................................. 15
2.1.6 Operaciones ......................................................................................................................................... 15
2.1.7 Requerimientos de Adaptación del Sitio ................................................................................ 16
2.2 Funciones del Producto ..................................................................................................... 16
2.3 Características del Usuario ............................................................................................... 17
2.4 Restricciones ......................................................................................................................... 17
2.4.1 Restricciones del Proyecto: .......................................................................................................... 18
2.4.2 Restricciones del Producto:.......................................................................................................... 18
2.5 Modelo del Dominio ............................................................................................................ 19
2.6 Suposiciones y Dependencias .......................................................................................... 23
2.7 Distribución de Requerimientos..................................................................................... 25
3 Descripción de requerimientos .................................................................................. 27
3.1 Especificaciones ................................................................................................................... 27
3.1.1 Requerimientos Funcionales ....................................................................................................... 27
3.1.2 Requerimientos No funcionales ................................................................................................. 28
3.1.3 Validaciones ......................................................................................................................................... 29
3.1.4 Dashboard............................................................................................................................................. 29
3.2 Priorización ........................................................................................................................... 29
3.3 Trazabilidad .......................................................................................................................... 30
3.4 Pruebas ................................................................................................................................... 31
4 Proceso Ingeniería de Requerimientos .................................................................... 32
4.1 Incremento ............................................................................................................................ 32
SRS SISINFOCOOP
5
4.1.1 Arquitectura......................................................................................................................................... 32
4.2 Origen de requerimientos................................................................................................. 35
4.2.1 Especificación de categorías ........................................................................................................ 36
4.2.2 Especificación de las subcategorías ......................................................................................... 36
4.3 Priorización de los Requerimientos .............................................................................. 38
4.3.1 Proceso de Priorización ................................................................................................................. 38
4.4 Trazabilidad de los Requerimientos ............................................................................. 40
4.5 Verificación ........................................................................................................................... 40
5 Anexos ................................................................................................................................. 41
SRS SISINFOCOOP
6
3 Lista de Tablas Tabla 1. Historial de cambios ....................................................................................................................................... 3
Tabla 2. Definiciones, acrónimos y abreviaciones ............................................................................................. 9
Tabla 4. Interfaces de software ................................................................................................................................ 15
Tabla 5. Restricciones de memoria......................................................................................................................... 15
Tabla 6 Características del Usuario ........................................................................................................................ 17
Tabla 7. Priorizaciones ................................................................................................................................................. 30
Tabla 8 Modelo Vista Controlador .......................................................................................................................... 32
Tabla 9 Nodo Cliente ..................................................................................................................................................... 35
SRS SISINFOCOOP
7
4 Lista de Ilustraciones
Ilustración 1. Interfaces de Hardware -1 ............................................................................................................. 12
Ilustración 2. Interfases con el Hardware -2 ...................................................................................................... 13
Ilustración 3 Modelo de Dominio de SISINFOCOOP ....................................................................................... 20
Ilustración 4. Suposiciones y dependencias ....................................................................................................... 24
Ilustración 5 Clasificación de requerimientos .................................................................................................. 25
Ilustración 6 Patrón MCV ilustración tomada de http://patternmoy.com/mvc-pattern-
example/ ............................................................................................................................................................................. 33
Ilustración 7 Arquitectura MVC en Java EE ........................................................................................................ 34
Ilustración 8 Diagrama Modelo Despliegue ....................................................................................................... 34
Ilustración 9 Subcategorías de los requerimientos ........................................................................................ 36
Ilustración 10. Plano Cartesiano de la Priorización........................................................................................ 39
SRS SISINFOCOOP
8
1 Introducción
1.1 Propósito
Este artefacto tiene la intención de especificar los requerimientos de software,
mediante diferentes herramientas y procesos, para identificar y definir los
componentes del prototipo desarrollado por el estudiante de Ingeniería de Sistemas
Oscar Javier Rey, llamado SISINFOCOOP (Ver Sección 3. Descripción de
requerimientos) Las características que posea el producto serán las encargadas de
medir y controlar su alcance. Al ser un proyecto académico para obtener el Título de
Ingeniero de Sistemas, el artefacto está dirigido a los clientes Maria Consuelo Frankly
de Toro y la Cooperativa “Coocredimar”, brindando una visión del alcance del
producto, (Ver Sección 1.2. Alcance).
1.2 Alcance
El alcance definido por el estudiante, para el prototipo SISINFOCOOP, se basa en la
priorización de requerimientos (Ver sección 3: Priorización). Las siguientes son las
funcionalidades implementadas en el prototipo:
El desarrollo del prototipo esta compuesto por módulos, los cuales tiene asociados los
requerimientos que se ha obtenido (Ver. Tabla de Requerimientos.), estos módulos
que se han definido son:
Módulo de Seguridad: Este módulo ofrecerá al administrador del sistema,
administrar los distintos roles y asignar a los usuarios el rol o roles
autorizados, para que se valide ante el sistema, y tenga acceso a los módulos y
acciones según el rol.
Módulo de Administración: Modulo para el manejo de asesores comerciales,
proveedores, pagadurías, personas y empleados.
Módulo de Asociados: Modulo que permitirá la administración de asociados y
sus vinculaciones a las pagadurías.
Módulo de Crédito: Modulo que permitirá la administración de los créditos de
la cooperativa.
Módulo de Transacciones: Modulo que permitirá realizar las distintas
transacciones sobre los créditos y aportes de la cooperativa.
Modulo Reportes: Modulo que ofrecerá obtener los distintos reportes que
según los requerimientos definidos previamente.
1.3 Definiciones, Acrónimos, y Abreviaciones
A continuación se describe los acrónimos, definiciones y abreviaciones que se
encuentran dentro de este artefacto.
SRS SISINFOCOOP
9
RFC Request For Comments
SDD Software Design Description
SRS Software Requirement Specification
TCP Transmission Control Protocol
TCP/IP Transmission Control Protocol – Internet Protocol
GB Giga Bytes
Producto o Prototipo
Nombre asignado al prototipo con cierto tipo de funcionalidades implementadas.
Proyecto Asignado para desarrollar en el periodo semestral 2015 – 3 para la materia Trabajo de Grado.
Diagrama de navegabilidad
Diagrama donde se muestran las funcionalidades del producto.
Drivers Controlador de dispositivo para equipos con sistema operativo Windows, es un programa cuya finalidad es relacionar el sistema operativo con los dispositivos hardware.
SPMP Software Project Management Plan.
Tabla 2. Definiciones, acrónimos y abreviaciones
SRS SISINFOCOOP
10
1.4 Referencias
1.5 Apreciación Global
Este artefacto estará distribuido en dos partes: La primera parte (Ver Sección 2.
Descripción Global) tratará de la descripción global del prototipo SISINFOCOOP!, la
cual brinda una descripción de todo el sistema y de los factores generales que afectan
el producto. La segunda parte (Ver Sección 3. Descripción de
requerimientos)contendrá la especificación de los requerimientos del producto, la
cual le brindará al gerente la posibilidad de conocer el avance, tanto del proyecto
como del producto.
Este artefacto se encuentra organizado de la siguiente manera:
DESCRIPCIÓN GLOBAL DEL PRODUCTO
o Perspectiva del Producto:
Interfaces con el sistema.
Interfaces con el usuario.
Interfaces con el Hardware y Comunicación.
Interfaces con el Software.
Restricciones de Memoria.
Operaciones.
Requerimientos de Adaptación del Sitio.
o Funciones del Producto.
o Características del Usuario.
o Restricciones .
o Modelo del Dominio.
o Suposiciones y Dependencia.
o Distribución de Requerimientos.
DESCRIPCIÓN DE REQUERIMIENTOS.
o Especificaciones de Requerimientos
Requerimientos Funcionales
Requerimientos No Funcionales
o Priorización
o Trazabilidad
o Pruebas
SRS SISINFOCOOP
11
2 Descripción Global
2.1 Perspectiva del Producto
El prototipo SISINFOCOOP, es un producto totalmente nuevo con un origen netamente
académico. El estudiante Oscar Javier Rey, incursiona en el campo del desarrollo de
aplicaciones JAVA EE7, basándose en los diversos temas aprendidos en las distintas
materias de la carrera de Ingeniería de Sistemas, los cuales son aplicados para la
definición, el seguimiento y el desarrollo del producto ya mencionado.
Para los usuarios finales, el beneficio que les traerá el producto es poder confrontar el
resultado final, con el progreso que tuvo el estudiante en el periodo de 2015-3 y poder
analizar la coherencia que tuvo con la planeación inicial del proyecto, y si el producto
cumplió con la calidad esperada.
2.1.1 Interfaces con el sistema
El prototipo desarrollado por el estudiante, es un sistema nuevo, por lo cual no posee
dependencias con otros sistemas.
SRS SISINFOCOOP
12
TECLADO
Interfaz usada que permite al usuario:
● Ingresar datos de registro o de ingreso al sistema.
● Realizar todas las operaciones de digitacion.
ESPECIFICACIONES: Los teclados de la cooperativa son:
SPARE 435382-161 ASSY 434821-161 Modelo KU - 0316 Power Rating 5V = 50 mA
Puerto: USB
MOUSE
Interfaz usada que permite al jugador:
● Hacer click sobre los distintos iconos o links de la aplicacion.
Los mouse de la cooperativa son:
Recepcion Compu. 1 - 4
marca HP HP
SPARE 390938-001 537749-001
ASSY 265986-003 590509-002
Puerto USB USB
2.1.2 Interfaces con el usuario
Las interfaces presentes son las que permiten la interacción entre el producto y el
usuario.
Ilustración 1. Interfaces de Hardware -1
SRS SISINFOCOOP
13
INTERFAZ GUI Interfaz usada que permite al usuario:
● Interactuar directamente con el protopito: Navegar por
los distintos menús. ● Comprender los textos, el idioma es en español.
MONITOR
Interfaz usada que permite al usuario:
● Observar las distintas GUIs que presenta el prototipo(a través de la interfaz gráfica) .
● La pantalla debe soportar una resolucion minima de 800*600.
Recepcion Compu. 1 - 4 Marca DELL DELL Monitor DELL LA2006x S1933
Ilustración 2. Interfases con el Hardware -2
SRS SISINFOCOOP
14
2.1.3 Interfaces de Hardware y Comunicación
El producto SISINFOCOOP posee interacción con componentes de hardware, tales
como los equipos de la Cooperativa [1]. Algunas de las características de estos equipos
son:
Intel core I3 de 2.10Ghz
4Gb de memoria RAM
Discos duros de 500 GB
Sistemas operativos (Windows 8, Linux Centos).
Es necesario disponer del protocolo TCP/IP orientado a conexión, entre la
aplicación y el servidor central que proveerá el flujo constante de datos. Las
aplicaciones indispensables, tanto el cliente como el servidor, harán uso del
puerto destinado por el entorno de programación y de acuerdo al protocolo
especificado
Cable UTP Nivel 5E, permite una buena velocidad de transferencia y una
transmisión confiable.
Navegador Web: para ingresar al prototipo se debe realizar a través de
navegadores web como Mozilla, Chrome y Explorer entre otros.
2.1.4 Interfaces con el Software
Las interfaces de software son importantes pues describen otros productos de
software que son necesarios para el correcto funcionamiento del prototipo
SISINFOCOOP. A continuación se describen dichas interfaces:
Producto de
software
Linux Centos Wildfly Postgresql DB
Descripción Es un sistema operativo
de código abierto, basado
en la distribución Red
Hat Enterprise Linux,
operándose de manera
similar, y cuyo objetivo
es ofrecer al usuario un
software de "clase
empresarial" gratuito. Se
define como robusto,
estable y fácil de instalar
y utilizar.
Servidor de
aplicaciones
que adquirió
RedHat de la
comunidad
JBoss pero al
contrario que
Oracle y
Weblogic con
licencia libre
de software
libre.
Es un Sistema de
gestión de bases de
datos relacional
orientado a objetos y
libre, publicado bajo la
licencia PosgreSQL ,
similar a la BSD o la
MIT.
SRS SISINFOCOOP
15
Propósito de uso
Entorno que permitirá la ejecución del prototipo.
Para desplegar el prototipo.
Se encarga de proporcionar la base de datos del prototipo
Versión Linux Centos 7. 8.1.0 9.3
Fuente centos.org [2] wildfly.org [3] Postgresql [4]
Tabla 3. Interfaces de software
2.1.5 Restricciones de Memoria
De acuerdo a los requerimientos del prototipo se deben tener en cuenta ciertas
restricciones que tiene el producto para su correcto funcionamiento, las cuales son:
Servidor Cliente
Procesador Intel core
I3 de 2.10Ghz
4Gb de memoria RAM
Disco duro de 500 GB
Sistemas operativo
(Linux centos 7).
Procesador de 2,33 GHz o Intel Atom de 1,6 GHz o superior
RAM: 1 GB – 32 bits o 2 GB – 64 bits
Espacio en disco duro: 16 GB – 32 bits o 20
GB – 64 bits
Tarjeta de Red 10/100
Windows Vista
Windows 8
Tabla 4. Restricciones de memoria
2.1.6 Operaciones
El producto SISINFOCOOP, posee modos de operación de acuerdo al rol asignado a los
usuarios al momento de escribir este documento se cuenta con los siguientes roles:
Administrador
Empleado
Asesor Comercial
Asociado
SRS SISINFOCOOP
16
El Usuario interactúa con el prototipo a través del teclado y el mouse y observa los resultados en la pantalla. Sobre las funcionalidades de cada rol ver los diagramas de caso de uso. (Ver documento CasosdeUso.docx).
2.1.6.1 Fallos conexión.
Inicio de sesión: No se podrá entrar al sistema si no hay conexión a internet para acceso externo o si no hay red para el acceso interno.
2.1.7 Requerimientos de Adaptación del Sitio
Para que el prototipo SISINFOCOOP tenga una correcta ejecución en los computadores
de la Cooperativa, se debe cumplir con lo siguiente:
Debe tener instalado un navegador web.
Debe tener conexión a la red.
La pantalla debe soportar una resolución mínima de 800 * 600 pixeles.
Sistema Operativo Windows 7 o superior.
Sistema Operativo Linux con navegador web.
2.2 Funciones del Producto
Como un sistema de información para el manejo de asociados, aportes y créditos, las
funcionalidades del producto SISINFOCOOP, están debidamente relacionadas con los
requerimientos que previamente se han levantado, el desarrollo de los casos de uso
con la respectiva iteración con los actores, para cada tipo de rol (ver sección
Operaciones 2.1.6) el sistema según el rol asociado al usuario permitirá la ejecución
de algunas tareas.
Un resumen de las principales funcionalidades independientemente del rol son:
Mostrar la pantalla principal para hacer inicio de sesión e ingresar al sistema
Permitir al usuario cambiar la clave de ingreso al sistema.
Permitir al Usuario hacer búsqueda de asociados, créditos y aportes.
Permitir al Usuario buscar créditos asociados a una pagaduría, proveedor o
asesor comercial.
Ofrecer al Usuario crear nuevos asociados, empleados, proveedores,
pagadurías y créditos.
SRS SISINFOCOOP
17
2.3 Características del Usuario
Los stakeholders se encuentran definidos en el documento de Casos de uso (Ver
documento CasosdeUso.docx), a continuación se muestran las características de los
usuarios que usan la aplicación, teniendo en cuenta que los stakeholders vinculados al
producto SISINFOCOOP, son un sistema y un usuario.
Stakeholder Uso Experiencia
técnica
Privilegios
Usuario
(Empleado,
Asociado,
Asesor
Comercial)
Interacción con la
Aplicación
Conocimiento
básico en manejo
de programas de
computador
Podrá interactuar
con la aplicación de
forma superficial, no
podrá modificar
nada de la lógica del
prototipo.
Administrador
Administrar la
información de los
usuarios.
No Aplica. Permite modificar,
eliminar, crear datos
sin la necesidad de
conectar con la
aplicación de manera
directa.
Desarrollador Interacción con la
implementación
No Aplica. Puede modificar la
lógica y la
presentación del
prototipo
Tabla 5 Características del Usuario
2.4 Restricciones
Las restricciones presentes se dividen en 2 categorías:
SRS SISINFOCOOP
18
2.4.1 Restricciones del Proyecto:
Son las restricciones que fueron definidas al inicio del proyecto, tanto por los clientes
como por el estudiante Oscar Javier Rey. (Ver SPMP. Sección 6.3. Supuestos y
restricciones).
2.4.2 Restricciones del Producto:
Estas restricciones se definieron teniendo en cuenta las características de hardware y
software necesarias para el funcionamiento del producto SISINFOCOOP.
Restricciones Generales:
Restricciones de Interacción con el Usuario: Teniendo en cuenta las características del
usuario (Ver sección 2.3. Características del Usuario), se derivan ciertas restricciones
en cuanto la experiencia técnica y al idioma.
Experiencia Técnica: El usuario debe tener un conocimiento básico, del
manejo de las interfaces con las que interactuará (Ver sección 2.1.2.
Interfaces con el usuario), como el encender y apagar los dispositivos
periféricos, escribir en teclado, hacer click con el mouse, ejecutar
aplicaciones.
Idioma: La interfaz gráfica de la aplicación, el manual de usuario y el
manual de instalación, deben estar en el idioma Español (Colombia).
Restricciones de Software:
A partir de las interfaces de software (Ver sección 2.1.4. Interfaces con el software),
se derivan las siguientes restricciones:
Restricciones de memoria: Dichas restricciones describen lo que ocupa en
memoria la instalación del software requerido para el correcto
funcionamiento del prototipo SISINFOCOOP. (Ver sección 2.1.5.
Restricciones de memoria).
Restricciones del sitio: Estas restricciones, se basan en los requerimientos
de adaptación del sitio (Ver sección 2.1.7. Requerimientos de Adaptación
del Sitio) en donde el prototipo SISINFOCOOP debe funcionar de manera
adecuada.
Restricciones de Hardware:
A partir de las interfaces de hardware (Ver sección 2.1.3. Interfaces de hardware y
comunicación), se derivan restricciones como el que el prototipo SISINFOCOOP debe
poder ejecutarse en equipos de cómputo de la cooperativa [1].
SRS SISINFOCOOP
19
2.5 Modelo del Dominio
El modelo de dominio (ver Ilustración 3 Modelo de Dominio de SISINFOCOOP) se creó con
el fin de identificar los elementos de negocio y las relaciones que hay entre ellos,
otorgando al Líder de desarrollo una vista amplia de la interacción de todos los
componentes pertenecientes al prototipo SISINFOCOOP
Según Larman [5] el modelo del domino podría considerarse como un diccionario
visual de las abstracciones relevantes, vocabulario del dominio e información del
dominio. A continuación encontrara el diagrama y por otra parte la explicación de
todos los elementos del diagrama del dominio para explicar las entidades que forman
parte del prototipo.
SRS SISINFOCOOP
20
Ilustración 3 Modelo de Dominio de SISINFOCOOP
Entidad Descripción Relaciones
Persona Clase Padre, de esta heredan
asociado, codeudor,
empleado y asesor comercial.
La entidad tiene una relación
de muchas direcciones.
Usuario Entidad que contiene el
usuario y password, para
validarse ante el sistema
Un usuario puede tener
muchos roles y viceversa.
SRS SISINFOCOOP
21
UsuarioRol Entidad que agrupa un
usuario y sus respectivos
roles
Rol Entidad con los roles del
sistema
Empleado Entidad que hereda de
Persona, y es la
representación de empleado
Puede tener un usuario
Asociado Es la representación de
asociado de la cooperativa y
hereda de persona
Puede tener una solicitud de
crédito y un crédito o
créditos.
Codeudor Entidad que hereda de
persona y es la
representación de codeudor
de un crédito
Puede ser codeudor de un
crédito.
AsesorComercial Entidad que hereda de
persona, representa un
asesor comercial
Puede tener cero o más
créditos asociados.
Pagaduría Es la representación de una
pagaduría
Tiene una dirección.
Tiene cero o más créditos
asociados.
Dirección Es la representación de una
dirección
Pertenece a una Ciudad.
Ciudad Es la representación de una
ciudad de Colombia
Una ciudad pertenece a un
departamento.
Departamento Es la representación de un
departamento de Colombia
Puede tener una o más
ciudades.
Crédito Es la representación de un
crédito
Tiene asociada una
pagaduría, un proveedor y un
asesor comercial.
Puede tener una o más
transacciones.
Puede Tener memos, que son
observaciones o algún evento
SRS SISINFOCOOP
22
que ha surgido y se debe
dejar documentado.
Puede tener una solicitud de
crédito.
SolicitudCredito Es la representación de una
solicitud de crédito.
Se relaciona con asociado y
con crédito.
Referencia Es la representación de una
referencia.
Se relaciona con una
solicitud de crédito.
VinculacionAporte Es la representación de una
vinculación de un asociado a
una pagaduría.
Se relaciona con asociado y
con pagaduría.
DocumentoContable Es la representación de un
documento contable
Se relaciona con una
pagaduría.
Se relaciona con
transacciones de créditos y
de aportes.
Transacción Crédito Representa la transacción de
un crédito
Se relaciona con un crédito.
Se relaciona con un
documento contable.
Se relaciona con un tipo de
transacción.
Transaccion Aporte Representa la transacción de
aporte.
Se relaciona con una
vinculación aportes.
Se relaciona con un
documento contable.
Se relaciona con una
SRS SISINFOCOOP
23
pagaduría.
TipoTransaccion Es la representación de los
tipos de transacción.
Se relacionada con
transacción crédito y de
aporte.
2.6 Suposiciones y Dependencias
A continuación se describe una lista de suposiciones en caso de no cumplirse afectará
el funcionamiento del producto y por el lado de las dependencias se lista todos
aquellos factores de los cuales resultan necesarios para el producto SISINFOCOOP:
SRS SISINFOCOOP
24
Ilustración 4. Suposiciones y dependencias
SUPOSICIONES
El servidor de la Cooperativa esta debidamente
configurado.
La red interna de la cooperativa esta
debidamente configurada.
El cliente no hará ningún cambio de los
requerimientos.
Se elegirá un puerto que no este restringido.
DEPENDENCIAS
Buen Funcionamiento del servidor de aplicaciones.
Estabilidad de la conexión de la red.
Estabilidad del sistema operativo Linux Centos.
SRS SISINFOCOOP
25
2.7 Distribución de Requerimientos
Se ha realizado una clasificación de requerimientos, partiendo de una división inicial.
Los requerimientos funcionales, describen la funcionalidad del prototipo y los
procesos de negocio que cumple el sistema, por otra parte los no funcionales se
utilizaron para definir las restricciones del producto.
La siguiente ilustración muestra el agrupamiento por subcategorías tanto de los
requerimientos funcionales como de los no funcionales. Esta clasificación permite
obtener una trazabilidad coherente de fácil lectura.
Ilustración 5 Clasificación de requerimientos
Las subcategorías para los requerimientos funcionales fueron agrupadas en 6
categorías, definidos en el diagrama de navegabilidad y de los casos de uso.
En cuanto a los requerimientos no funcionales, las subcategorías fueron tomadas en
base al documento “Gestión de los requisitos” Cristóbal González Almirón [6].
Clasificación
Funcionales
Modulo Seguridad
Modulo de Administracion
Modulo Asociados
Modulo de Credito
Modulo de Transacciones
Modulo Reportes
No funcionales
Almacenamiento
Portabilidad
Rendimiento
Calidad
Disponibilidad
Escalabilidad
SRS SISINFOCOOP
26
La especificación de esta distribución se encuentra en la sección 3 (Ver sección 3.1.
Especificación de Requerimientos).
SRS SISINFOCOOP
27
3 Descripción de requerimientos
3.1 Especificaciones
Se tiene un archivo de requerimientos (Ver Archivo Requerimientos: Tabla de
Requerimientos V.7) la cual consta de las siguientes hojas:
Portada
Contenido
Historial de cambios
Guía
R. Funcionales
R. No funcionales
Validaciones
Dashboard
Bibliografía
A continuación se hará una breve descripción de las hojas más relevantes para el
proyecto, puesto que son las que tienen relación directa con los requerimientos.
3.1.1 Requerimientos Funcionales
En esta hoja se encuentran los requerimientos funcionales del producto SISINFOCOOP.
Esta hoja posee los siguientes campos:
El ID Del Requerimiento
La Descripción, Autor Del Requerimiento
Ids De Requerimientos Asociados
Origen Del Stakeholder
El Estado
Prioridad
Índice Del Valor De Negocio
Índice De Riesgo
Verificación
Fecha De Modificación
Autor Modificación
Versión
Sección
Fecha De Implementación
Tipo De Pruebas
ID De Prueba Asociada
SRS SISINFOCOOP
28
La explicación de los campos mencionados anteriormente se encuentra en la hoja Guía
del archivo de la tabla de requerimientos. (Ver Archivo Requerimientos: Tabla de
Requerimientos).
3.1.2 Requerimientos No funcionales
En la hoja de los requerimientos no funcionales se encuentran los mismos campos que
se mencionaron en los requerimientos funcionales, sin embargo no se presentan los
campos de priorización (prioridad, índice de valor, índice de riesgo), esto se debe a
que no es necesario priorizar los no funcionales ya que son restricciones del sistema
que se deben tener en cuenta al momento de implementar el producto y depende del
requerimiento que se debe implementar se revisa el requerimiento no funcional.
Los demás campos de la tabla de requerimientos no funcionales estén definidos en la
guía de Tabla de requerimientos (Ver Archivo Requerimientos: Tabla de
requerimientos)
La explicación de las categorías del campo de subclasificación son las siguientes:
3.1.2.1 Almacenamiento
Son todos los requerimientos que tienen relación con la conexión del prototipo con la
DB de postgresql [4] para el almacenamiento de los datos.
3.1.2.2 Calidad
Son todos aquellos requerimientos asociados a la especificación y normas impuestas
para el código.
3.1.2.3 Disponibilidad
Son todos los requerimientos asociados al porcentaje de tiempo que va a estar
disponible el prototipo en el año.
3.1.2.4 Portabilidad
Todos los requerimientos asociados a las plataformas que soporta el prototipo.
3.1.2.5 Rendimiento
Son todos los requerimientos asociados a la respuesta del prototipo a los diferentes
estados.
SRS SISINFOCOOP
29
3.1.3 Validaciones
La hoja de validación (Ver Archivo: Tabla de Requerimientos), tiene como propósito
desglosar y realizar una explicación del significado de los campos de la tabla de
requerimiento que hacen uso de validaciones y por lo tanto en donde se definieron
valores específicos o rangos definidos. Por lo tanto se puede apreciar una tabla donde
se explican los posibles valores específicos que pueden obtener las columnas de las
tablas llamadas: Estado, Prioridad, Índice del Valor del Negocio, Índice de Riesgo, y
Verificación.
3.1.4 Dashboard
El propósito de la hoja de Dashboard (Ver Archivo Requerimientos: Tabla de
Requerimientos), tiene como propósito brindar información estadística de los
requerimientos realizados. Más específicamente hace un recuento de cuántos
requerimientos de cada subcategoría de las categorías funcionales y no funcionales se
realizaron y comparando estas con el total se realizó un gráfico que muestra el
porcentaje de requerimientos que hay para cada subcategoría de ambas categorías. Al
mismo tiempo, también para cada categoría, se realizó un recuento del número de
requerimientos por estado de los mismos, lo cual brinda información sobre el
progreso del producto y cuánto hace falta por implementar.
3.2 Priorización
En la tabla de requerimientos definida se encuentran tres columnas asociadas a la
priorización. Estas son:
Descripción Responsable Momento
Índice del
Valor del
Negocio
Denota la relevancia
que tiene el
requerimiento con
respecto al objetivo del
producto. Se mide en un
rango de 1 a 5; siendo 1
el menos relevante y 5
el más relevante.
Analista de
Requerimientos
Siempre que el
Analista de
Requerimientos
tenga acceso a la
tabla y encuentre
un requerimiento
nuevo aprobado.
Inmediatamente
se tiene la
disponibilidad.
Índice de Se define dependiendo Líder de Desarrollo Siempre que el
SRS SISINFOCOOP
30
Riesgo de la dificultad y el
riesgo que conlleva
implementar el
requerimiento al
momento de
desarrollarlo. Se mide
en un rango de 1 a 5;
siendo 1 el menos
relevante y 5 el más
relevante.
Líder de
Desarrollo abra la
tabla y encuentre
un requerimiento
nuevo aprobado.
Inmediatamente
se tiene la
disponibilidad.
Prioridad Define qué tan
pertinente es que se
implemente el
requerimiento. Ésta
prioridad se calcula a
partir de los datos del
Índice del Valor del
Negocio y el Índice de
Riesgos, y puede tomar
uno de los siguientes
valores: Baja, Media,
Alta, Evitar.
Analista de
Requerimientos.
Inmediatamente
se llenan las
columnas de
Índice del Valor
del Negocio y el
Índice de Riesgos.
Tabla 6. Priorizaciones
De esta manera se llenan los valores asociados a la prioridad de los requerimientos.
Sin embargo, en el proyecto se manejaron más temas sobre la metodología
implementada y el significado de los valores de priorización (Ver Sección 4.5:
Priorización de los Requerimientos), en el cual se explica el paso a paso del proceso
de priorización que se llevó acabo.
3.3 Trazabilidad
Para la trazabilidad se definió la relación entre los requerimientos, módulos y los
casos de uso, para ello se cuenta con una tabla debidamente definida, para hacer esta
relación. (Ver Archivo InventarioCasosUso.xls).
SRS SISINFOCOOP
31
Esta trazabilidad, se organizó con el modulo al que pertenece cada caso de uso y por
último se asociaron los requerimientos a cada uno de los casos de uso.
Inventario de Casos de Uso
Módulo Caso de
Uso Descripción
CU Complejidad
Requerimientos Asociados
Esfuerzo Estimado CU
(horas)
Esfuerzo Estimado
Módulo (horas)
Recursos asignados
Se podría decir que un requerimiento es trazable si se pueden identificar todas las
partes del producto existente relacionadas con ese requerimiento y con ese caso de
uso.
3.4 Pruebas
El archivo de pruebas tiene las siguientes hojas:
Portada
Historial de cambios
Guía
Funcionales
No funcionales
Validaciones
Bibliografía
La explicación de cómo se debe llenar las hojas de funcionales y no funcionales se
encuentra en la hoja Guía, en la cual se explican cada uno de los campos. (Ver Anexos:
Tabla Pruebas de código)
SRS SISINFOCOOP
32
4 Proceso Ingeniería de Requerimientos
4.1 Incremento
Para esta entrega se implementó los requerimientos según la priorización (Ver
sección 3.7. Priorización) de estos, los cuales están relacionados con la conexión a
Postgresql para el registro y el login de los usuarios.
4.1.1 Arquitectura
A continuación especificara el patrón de arquitectura [7] y el diagrama de despliegue,
que se utilizara durante el desarrollo de la aplicación.
4.1.1.1 Patrón modelo vista controlador
Estilos Ventajas Desventajas Modelo Vista Controlador
[8].
La aplicación está
implementada modularmente.
Sus vistas muestran
información actualizada
siempre.
El programador no debe
preocuparse de solicitar que las
vistas se actualicen, ya que este
proceso es realizado
automáticamente por el modelo
de la aplicación.
MVC es un patrón de diseño
orientado a objetos por lo que su
implementación es sumamente
costosa y difícil en lenguajes que
no siguen este paradigma.
MVC requiere la existencia de
una arquitectura inicial sobre la
que se deben construir clases e
interfaces para modificar y
comunicar los módulos de una
aplicación, aunque esta
desventaja ya no es problema
porque se tiene una arquitectura
de punta que es la de cliente
servidor.
Tabla 7 Modelo Vista Controlador
SRS SISINFOCOOP
33
Ilustración 6 Patrón MCV ilustración tomada de http://patternmoy.com/mvc-pattern-example/
La ilustración anterior nos indica que el patrón MCV [9] es el escogido, ya que la
aplicación está orientada a la web y es necesario manejar algún modulo vista para
todos los usuarios y facilita el llamado de los datos.
Servelets: Facilitan el tratamiento de las peticiones que llegan al servidor.
o Tratamiento de datos de formularios.
o Permite re direccionar las peticiones.
JSP: Facilitan el tratamiento de las peticiones que llegan al servidor.
o Para páginas de formato establecido.
Java Beans y Enterprise Beans: Facilitan la implementación de la lógica de
negocio.
o Independiente de la presentación de los resultados.
SRS SISINFOCOOP
34
Ilustración 7 Arquitectura MVC en Java EE
4.1.1.2 Diagrama de despliegue
“Un diagrama de despliegue muestra las relaciones físicas entre los componentes
hardware y software en un sistema” [10] . A continuación se mostrara el diagrama de
despliegue del producto SISINFOCOOP, el cual muestra la arquitectura física del
sistema, es decir en el numeral 4.2.1.1 (Ver Sección 4.2.1.1 Patrón Modelo Vista
Controlador).
Ilustración 8 Diagrama Modelo Despliegue
SRS SISINFOCOOP
35
Nodo Cliente
Nombre del
nodo
Cliente
Especificación Las especificaciones de los
equipos de Cooperativa son:
Procesador: Intel Core I3
RAM: 4Gb Disco Duro: 500Gb Sistema operativo:
Windows 7
Ubicación Centro - Bogota.
Cll 17 # 8-49 of. 409
Componentes Comentarios adicionales
Navegador Web Tabla 8 Nodo Cliente
Nodo Servidor
La aplicación que desarrolla el estudiante Oscar Rey utilizara los servicios que
provee WildFly 8.1, tanto de servidor y como de bases de datos PostgreSQL,
herramientas que se utilizan para la implementación de prototipo
SISINFOCOOP.
4.2 Origen de requerimientos
Se realizó una investigación de distintas plantillas para el manejo de los
requerimientos, buscando que dichas plantillas que se adaptaran a las necesidades del
trabajo de grado y tuvieran en cuenta los requisitos mínimos que deben existir para
un correcto manejo de los requerimientos.
Las plantillas encontradas fueron las siguientes:
Plantilla de Karl Wiggers [11]
Template de matriz de trazabilidad de requerimientos [12]
Plantilla Dharma Consulting [13]
Se analizaron todas las matrices y templates encontrados y, se decidió que la plantilla
más completa, que poseía el nivel de detalle adecuado para el proyecto era la matriz
de Dharma Consulting.
Los responsables de llenar dicha plantilla son (Líder de desarrollo, arquitecto y
analista de requerimientos).Cabe resaltar que el estudiante Oscar Rey, será el
SRS SISINFOCOOP
36
mismo que ocupara todos esos roles, por esta misma razón, fue quien decidió las
categorías y subcategorías se usaron en la tabla de requerimientos.
4.2.1 Especificación de categorías
Se optó por hacer la división de los requerimientos en seis categorías: funcionales [14]
y no funcionales [15]. Esta escogencia es debido a que, los requerimientos
funcionales definen las características con los que el sistema deberá contar. Al mismo
tiempo, como el sistema debe actuar ante diferentes circunstancias, los
requerimientos no funcionales definen restricciones adicionales con las que el
sistema deberá contar e indica las limitaciones, prohibiciones y propiedades
emergentes del sistema.
4.2.2 Especificación de las subcategorías
Para las subcategorías de los requerimientos funcionales, las puede encontrar (Ver
sección 2.7 Distribución de los requerimientos).
Ilustración 9 Subcategorías de los requerimientos
A continuación se describirá cada una de las subcategorías definidas.
4.2.2.1 Administración de Roles
Subcategoría, para la administración de roles que la Cooperativa crea conveniente,
cualquier modificación a la entidad roles, debe ser realizada por personal con
conocimiento en Java EE, puesto que deberá realizar las modificaciones en el código
también.
Mo
du
lo d
e S
eg
uri
da
d
• Administracion de Roles.
• Administracion de Usuarios.
• Asignacion de roles a usuarios.
Mo
du
lo d
e A
dm
inis
tra
cio
n
• Administracion de Personas.
• Administracion de Asesores Comerciales.
• Administracion de Proveedores.
• Administracion de Pagadurias.
Mo
du
lo d
e A
soci
ad
os • Administr
acion de Asociados.
• Administracion de Vinculaciones. M
od
ulo
de
Cre
dit
o
• Administracion de Creditos.
• Administracion Solicitud Credito
Mo
du
lo d
e T
ran
sacc
ion
es • Administr
acion Transacciones Credito
• Administracion Transacciones Aportes
• Administracion Documento Contable.
Mo
du
lo d
e R
ep
ort
es • Reportes
Creditos • Reportes
Aportes • Reportes
Pagaduria
• Reportes Proveedor
• Reporte Asesor Comercial
SRS SISINFOCOOP
37
4.2.2.2 Administración de Usuarios
Subcategoría, con el propósito de autorizar, actualizar, desactivar e incluir nuevos
usuarios que tendrán acceso al sistema.
4.2.2.3 Asignación de Roles a Usuarios
Subcategoría, donde se podrá asignar rol o roles a un usuario, que dependiendo del rol
tendrá opciones habilitadas o deshabilitadas en el sistema.
4.2.2.4 Administración de Personas
Esta subcategoría, permite realizar el respectivo CRUD de la entidad persona, también
es la clase padre de la cual hereda Asociado, Empleado, Codeudor, y Asesor Comercial.
4.2.2.5 Administración Asesores Comerciales
Subcategoría para asignar a una persona como asesor comercial de la cooperativa.
4.2.2.6 Administración Proveedores
Subcategoría para realizar las operaciones de CRUD sobre la entidad proveedor de la
cooperativa para luego asignar un proveedor a un crédito.
4.2.2.7 Administración Pagadurías
Subcategoría, para realizar las operaciones de CRUD sobre la entidad pagaduría que
luego va hacer asociada a un crédito.
4.2.2.8 Administración de Asociados
Subcategoría, para asignar los asociados de la Cooperativa, previamente el asociado debe
estar registrado como persona y luego pasa a la Categoría de asociado.
4.2.2.9 Administración de Vinculaciones
Subcategoría, donde a un asociado se le relaciona con una pagaduría y queda vinculado, puede
tener varias vinculaciones.
4.2.2.10 Administración de Créditos
Subcategoría para realizar las operaciones de CRUD sobre la entidad crédito.
4.2.2.11 Administración Solicitud Crédito
Subcategoría, para realizar las operaciones de CRUD sobre la entidad solicitud crédito.
4.2.2.12 Administración Transacciones de Crédito
Subcategoría, para realizar las operaciones de CRUD sobre la entidad transacciones crédito,
consiste en realizar abonos, devoluciones, descontar intereses no causados sobre algún
crédito.
SRS SISINFOCOOP
38
4.2.2.13 Administración Transacciones Aportes
Subcategoría, para realizar las operaciones de CRUD sobre la entidad transacción aportes,
consiste en realizar los abonos de aportes que los clientes hacen en la Cooperativa y también
la devolución de estos mismos.
4.2.2.14 Administración Documento Contable
Subcategoría, para realizar las operaciones de CRUD sobre la entidad documento contable,
para realizar cualquier tipo de transacción es indispensable asociar un documento contable.
4.2.2.15 Reportes Créditos
Subcategoría, para gestionar un reporte de créditos en un rango de fechas.
4.2.2.16 Reportes Aportes
Subcategoría, para la gestión de los aportes que tiene la cooperativa por cada uno de los
asociados.
4.2.2.17 Reportes Pagaduría
Subcategoría, para la gestión de los créditos asociados a una pagaduría.
4.2.2.18 Reportes Proveedor
Subcategoría, para la gestión de los créditos asociados a un proveedor.
4.2.2.19 Reporte Asesor Comercial
Subcategoría, para la gestión de créditos asociados a un Asesor comercial.
4.3 Priorización de los Requerimientos
4.3.1 Proceso de Priorización
Para realizar la priorización de los Requerimientos se utilizó el método que consiste
en definir dos variables, Índice del Valor de Negocio, e índice de Riesgo, en un rango
numérico propuesto de 1 a 5, los cuales se genera un punto en un plano cartesiano, el
cual se divide en cuatro cuadrantes (Ilustración 10. Plano Cartesiano de la
Priorización). Por lo tanto, dependiendo de qué cuadrante está ubicado el punto, esta
será la prioridad que se le asignará al requerimiento asociado a ese punto. A
continuación se detalla más las características del método.
Índice del Valor del Negocio: Denota la relevancia que tiene el requerimiento
con respecto al objetivo del producto. Se mide en un rango de 1 a 5; Siendo 1 el
menos relevante y 5 el más relevante.
Índice de Riesgo: Se define dependiendo de la dificultad y el riesgo que
conlleva implementar el requerimiento al momento de desarrollarlo. Se mide
en un rango de 1 a 5; Siendo 1 el menos relevante y 5 el más relevante.
SRS SISINFOCOOP
39
Por lo tanto el grado de prioridad otorgado a un requerimiento se deriva haciendo uso
de la gráfica que se muestra a continuación [Ilustración 14] en donde se toman los
valores de "Índice del Valor de Negocio" como el valor en el eje X, y el "Índice de
Riesgo" en el eje Y, obteniendo un punto en el mapa cartesiano que lo representa. A
partir de la posición en el que éste punto se encuentre se le asignará la prioridad
correspondiente.
Ilustración 10. Plano Cartesiano de la Priorización
Como se puede apreciar, se definen cuatro grados de prioridad: Baja, Media, Alta y
Evitar:
Evitar si es posible: Agregan poco valor a el producto y al mismo tiempo tiene un riesgo asociado alto
Alta: Le agregan un gran valor al producto y al mismo tiempo significan un riesgo alto al implementarlos
Baja: Tienen un valor de negocio y un riesgo bajo, por lo tanto no es tan pertinente implementarlos lo antes
posible. Media: Valor de negocio alto pero un riesgo de
implementación bajo.
Ahora bien, a partir de la experiencia adquirida realizando la priorización de los casos
de uso implementando este método, se puede resumir con las siguientes reglas una
SRS SISINFOCOOP
40
fórmula para adquirir esta prioridad sin necesidad de trazar los puntos en un plano
cartesiano:
Si el Índice del Valor es menor a 3 y el Índice de Riesgo es
mayor a 2 la prioridad es Evitar.
Si el Índice del Valor es menor a 3 y el Índice de Riesgo es
menor a 3 la prioridad es Baja.
Si el Índice del Valor es mayor a 2 y el Índice de Riesgo es
menor a 3 la prioridad es Media.
Si el Índice del Valor es mayor a 2 y el Índice de Riesgo es
mayor a 2 la prioridad es Alta.
4.4 Trazabilidad de los Requerimientos
La trazabilidad entre los requerimientos y los casos de uso nos ayuda a detectar el
origen del requerimiento y el estado del prototipo al que pertenece. (Ver Archivo:
InventarioCasosUso.xls).
Para realizar la trazabilidad el Líder de desarrollo se encargó de llenar la tabla de
requerimientos contra los casos de uso, en la cual se miraba requerimiento por
requerimiento, a que caso de uso pertenece y se realizaba la conexión en la tabla y de
esa forma se verifica que los requerimientos estén adecuadamente correctos.
4.5 Verificación Para realizar la pruebas se utilizó la tabla de pruebas (Ver anexo: Tabla de pruebas), las cuales
fueron realizadas por el líder de desarrollo. Y se dividieron en dos tipos de pruebas:
Unitarias
Integración
Para las pruebas unitarias se miró requerimiento por requerimiento y se probó si cumplía con
lo solicitado un vez comprobados los requerimientos se agruparon por categorías y se
comprobaron la funcionalidad entre estos requerimientos.
SRS SISINFOCOOP
41
5 Anexos
Todos los anexos se encuentran en la carpeta de Anexos. (Ver Carpeta Anexos)