SRS
SISINFOCOOP
1
SRS
Software Requirements Specification.
Oscar Rey
Pontificia Universidad Javeriana Facultad de Ingeniería
SRS
SISINFOCOOP
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
SRS
SISINFOCOOP
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 ... 81.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
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
SRS
SISINFOCOOP
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
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
SRS
SISINFOCOOP
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
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.
SRS
SISINFOCOOP
1.4 Referencias1.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
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.
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
SRS
SISINFOCOOP
2.1.3 Interfaces de Hardware y ComunicaciónEl 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 proporcionar la base de encarga 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
SRS
SISINFOCOOP
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
SRS
SISINFOCOOP
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
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
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
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
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
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
Riesgo de la dificultad y elriesgo 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
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.
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.
SRS
SISINFOCOOP
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).
SRS
SISINFOCOOP
35 Nodo Cliente Nombre del nodo ClienteEspecificació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
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. M od u lo d e Se gu ri d ad • Administr acion de Roles. • Administr acion de Usuarios. • Asignacio n de roles a usuarios. M od u lo d e Adm in is tr ac io n • Administr acion de Personas. • Administr acion de Asesores Comercial es. • Administr acion de Proveedo res. • Administr acion de Pagaduri as. M od u lo d e As oc ia d os • Administr acion de Asociados . • Administr acion de Vinculaci ones. Mod u lo d e Cr ed it o • Administr acion de Creditos. • Administr acion Solicitud Credito M od u lo d e T ra n sa cc io n es • Administr acion Transacci ones Credito • Administr acion Transacci ones Aportes • Administr acion Documen to Contable. M od u lo d e R ep or te s •Reportes Creditos • Reportes Aportes • Reportes Pagaduri a • Reportes Proveedo r • 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
4.2.2.13 Administración Transacciones AportesSubcategorí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
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
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
