propuesta para trabajo de grado - trabajos de grado de …... uno de ellos es sap, el cual ofrece...

Prototipo de un Sistema de Información para la administración de datos en una

Cooperativa con sección de Aporte y Crédito

CIS1530AP01

OSCAR JAVIER REY CARO

PONTIFICIA UNIVERSIDAD JAVERIANAFACULTAD DE INGENIERIA

CARRERA DE INGENIERIA DE SISTEMASBOGOTÁ, D.C.

2015

Pontificia Universidad Javeriana Memoria de Trabajo de Grado – Aplicación Práctica

CIS1530AP01Prototipo de un Sistema de Información para la administración de datos en una Cooperativa

multiactiva con sección de crédito y aportes

Autor(es):

OSCAR JAVIER REY CARO

MEMORIA DEL TRABAJO DE GRADO REALIZADO PARA CUMPLIR UNO DE LOS REQUISITOS PARA OPTAR AL TITULO DE INGENIERO DE SISTEMAS

Director

MARIA CONSUELO FRANKY

Jurados del Trabajo de Grado

Efrain Ortiz Pabón

Luis Fernanda Barrera

Página web del Trabajo de Grado

http://pegasus.javeriana.edu.co/~CIS1530AP01


CARRERA DE INGENIERIA DE SISTEMASBOGOTÁ, D.C.Noviembre, 2015


CARRERA DE INGENIERIA DE SISTEMAS

Página 1

Ingeniería de Sistemas Istar - CIS1530AP01

Rector Magnífico

Jorge Humberto Peláez Piedrahita, S.J.

Decano Facultad de Ingeniería

Ingeniero Jorge Luis Sánchez Téllez

Director de la Carrera de Ingeniería de Sistemas

Ingeniero Germán Alberto Chavarro Flórez

Director Departamento de Ingeniería de Sistemas

Ingeniero Rafael Andrés González Rivera

Página 2


Artículo 23 de la Resolución No. 1 de Junio de 1946

“La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la Justicia”

Página 3


AGRADECIMIENTOS

En primer lugar deseo expresar mis agradecimientos a mis padres que han realizado un gran esfuerzo, para que este culminando esta etapa, y por el apoyo constante durante toda la carrera, sin este apoyo hubiera sido difícil llegar a estas últimas instancias.

Página 4


CONTENIDO

CONTENIDO...............................................................................................................5

INTRODUCCIÓN.....................................................................................................10

I - DESCRIPCIÓN GENERAL................................................................................12

1 OPORTUNIDAD, PROBLEMÁTICA, ANTECEDENTES.................................................12

2 FORMULACIÓN DEL PROBLEMA QUE SE RESOLVIÓ................................................14

3 JUSTIFICACIÓN DEL PROBLEMA..............................................................................14

4 IMPACTO ESPERADO...............................................................................................14

5 DESCRIPCIÓN DEL PROYECTO................................................................................145.1 Objetivo General....................................................................................................145.2 Objetivos Específicos..............................................................................................155.3 Supuestos y restricciones........................................................................................15

6 ESTÁNDARES..........................................................................................................15

7 METODOLOGÍA.......................................................................................................167.1 Modelo de Ciclo de Vida........................................................................................167.2 Etapas en cada Iteración........................................................................................17

II – MARCO TEÓRICO...........................................................................................19

1 MARCO CONTEXTUAL............................................................................................19

2 MARCO CONCEPTUAL............................................................................................222.1 Aplicación Empresarial Web..................................................................................222.2 Entorno WEB..........................................................................................................25

3 METODOLOGÍAS DE DESARROLLO DE PROYECTOS DE SOFTWARE..........................253.1 Metodologías Agiles...............................................................................................26

III – ANÁLISIS..........................................................................................................36

1 DESCRIPCIÓN DE LA COOPERATIVA COOCREDIMAR CASO DE ESTUDIO.................36

2 FLUJO CORE DEL NEGOCIO....................................................................................372.1 Descripción del proceso.........................................................................................372.2 Generación Datos de Entrada al Sistema Actual...................................................382.3 Proceso de Negocio................................................................................................392.4 Proceso Solicitud Crédito.......................................................................................392.5 Proceso Abono a Crédito o Registro Cuota Aportes..............................................40

Página 5


3 ANÁLISIS DEL SISTEMA DE INFORMACIÓN SISINFOCOOP..................................413.1 Levantamiento de Requerimientos..........................................................................413.2 Requerimientos del Sistema por Módulos..............................................................433.3 Distribución de los Requerimientos en Módulos....................................................453.4 Casos de Uso del Sistema de Información SISINFOCOOP por Módulos.............463.5 Perfiles de Seguridad..............................................................................................473.6 Priorización de Requerimientos.............................................................................483.7 Restricciones del prototipo.....................................................................................50

4 PLAN DE PRUEBAS..........................................¡ERROR! MARCADOR NO DEFINIDO.4.1 Estrategia de Pruebas..............................................¡Error! Marcador no definido.4.2 Artefactos de Prueba................................................¡Error! Marcador no definido.4.3 Resultados de las pruebas........................................¡Error! Marcador no definido.

IV – DISEÑO..............................................................................................................52

1 LENGUAJES Y HERRAMIENTAS SELECCIONADAS....................................................521.1 Plataforma .NET......................................................¡Error! Marcador no definido.1.2 .NET Framework......................................................¡Error! Marcador no definido.1.3 Java EE 7.................................................................¡Error! Marcador no definido.1.4 Java EE o .NET........................................................¡Error! Marcador no definido.1.5 AJAX........................................................................¡Error! Marcador no definido.1.6 Netbeans o Eclipse...................................................¡Error! Marcador no definido.

2 MODELO DE ENTIDADES PERSISTENTES.................................................................53

3 DIAGRAMA DE CONTEXTO.....................................................................................54

4 OVERVIEW DE LA ARQUITECTURA.........................................................................55

5 VISTA LÓGICA DEL SISTEMA...................................................................................56

6 VISTA FÍSICA DEL SISTEMA.....................................................................................576.1 Diagrama de despliegue.........................................................................................576.2 Relaciones entre componentes:..............................................................................576.3 Diagrama de Componentes....................................................................................59

V – DESARROLLO DE LA SOLUCIÓN...............................................................61

1 COMO SE CONCIBIÓ EL PROTOTIPO........................................................................611.1 Usuarios y Caracterización....................................................................................611.2 Diseño Centrado en el Usuario..............................................................................63

2 ESTRATEGIAS DE DISEÑO.......................................................................................632.1 Estrategia de diseño de Código y vista del prototipo.............................................642.2 Seguridad a las páginas y EJB´s............................................................................69

VI – RESULTADOS..................................................................................................79

1 PRUEBAS.................................................................................................................79

Página 6


2 VALIDACIÓN DEL PROTOTIPO.................................................................................79

VI – CONCLUSIONES.............................................................................................81

1 ANÁLISIS DE IMPACTO DEL DESARROLLO..............................................................81

2 CONCLUSIONES Y TRABAJO FUTURO.....................................................................83

IV- REFERENCIAS Y BIBLIOGRAFÍA...............................................................85

IV – ANEXOS............................................................................................................91

ANEXO 1. GLOSARIO....................................................................................................91

ANEXO 2. DIAGRAMA DE ENTIDADES..........................................................................91

ANEXO 3. REQUERIMIENTOS DEL PROTOTIPO..............................................................91

ANEXO 4. INVENTARIO DE MÓDULOS Y CASOS DE USO..............................................91

ANEXO 5. SPMP...........................................................................................................91

ANEXO 6. SRS..............................................................................................................91

ANEXO 7. SDD.............................................................................................................91

ANEXO 8. MANUAL DE INSTALACIÓN..........................................................................91

ANEXO 9. MANUAL DE MANTENIMIENTO....................................................................91

ANEXO 10. MANUAL DE USUARIO...............................................................................92

ANEXO 11. CÓDIGO DEL PROTOTIPO...........................................................................92

ANEXO 12. PLAN DE PRUEBAS.....................................................................................92

ANEXO 13. CRONOGRAMA...........................................................................................92

ANEXO 14. ACTAS........................................................................................................92

ANEXO 15. HERRAMIENTAS DE DESARROLLO.............................................................92

ANEXO 16. ARCHIVOS EAR.........................................................................................92

ANEXO 17. ENCUESTAS DE SATISFACCIÓN..................................................................92

ANEXO 18. PROPUESTA TRABAJO DE GRADO..............................................................92

ANEXO 19. POSTER......................................................................................................92

Página 7


ABSTRACT

Throughout this document, the development process to be followed to obtain a 100% func-tional prototype for managing information in a cooperative, prototype solve problems in the administration and management of associated information, and presents contributions credit management; for this solution is comprised of the following modules:

Security Module Management Module Asóciate Module Transaction Module Credit Module Report Module

This system was developed using an application server; is Wildfly [8] Java EE7 [9] and PrimeFaces technology [7] JSF. This application makes use of security features, use of a security domain, generating PDF and XLS files reports with ITEX [10] t. All input and credit unions; all cooperatives can use this application, since it can be adapted to information in the data model.

Página 8


RESUMEN

A lo largo de este documento, se presenta el proceso de desarrollo que se siguió hasta obtener un prototipo funcional para la administración de la información de una Cooperativa de aporte y crédito, prototipo que solucionará problemas en la administración y gestión de la informa-ción de asociados, aportes y manejo de créditos; para ello la solución está conformado por los siguientes módulos:

Módulo de Seguridad Modulo Administración Modulo Asociado Módulo Transacción Modulo Crédito Modulo Reporte

Este sistema fue desarrollado utilizando un servidor de aplicaciones Wildfly[1], Java EE7[2] y tecnología PrimeFaces[3] JSF. Esta aplicación hace uso de funciones de seguridad, el uso de un dominio de seguridad, la generación de archivos PDF y XLS de informes con iTex[4]t. Todas las cooperativas de aporte y crédito; pueden utilizar esta aplicación, ya que se puede adaptar a la información en el modelo de datos.

Página 9


INTRODUCCIÓN

“Las compañías que tengan éxito en la próxima década serán aquéllas capaces de utilizar las herramientas digitales para reinventar la manera en la que trabajan y el flujo de información como una parte intrínseca de su actividad”. B. Gates y J. A. Bravo. [5]

"La función principal del discernimiento empresarial consiste en localizar e identificar en su constante evolución los datos reales y las circunstancias tocantes a la tecnología, el mercado y demás por el estilo. La rapidez del moderno cam-bio técnico convierte la búsqueda de datos en una necesidad permanente".

Alfred Sloan "Mis años con la General Motors" Año 1958

Las tecnologías de la información y la comunicación (TIC) en las empresas colombianas van tejiendo procesos de comunicación para el mejoramiento de procesos, ganar o perder depen-derá de cómo obtengamos, gestionemos y manejemos la información; para poder ganar de-penderá como desarrollemos un sistema de información adecuado o un sistema nervioso digi-tal1 como se refiere Bill Gates en su libro los negocios en la era digital[5].

En Colombia esta evolución histórica no ha sido ajena a los avances habidos en el resto del mundo. Según el informe elaborado por Manuel José Cárdenas, publicado en junio de 2012 por el Ministerio de las Tecnologías de la Información y las Comunicaciones (MinTIC), Co-lombia ha pasado por dos etapas en lo que respecta a la historia de las telecomunicaciones; llamó a la primera “tecnologías de comunicación tradicionales”, que abarca un periodo esti-mado de 140 años entre 1851 y 1990, y a la segunda, “tecnologías de la información y comu-nicaciones”, que va de 1990 hasta hoy; a pesar de los importantes progresos en penetración de Internet, la brecha entre las empresas grandes frente a las Pymes, comparando sus inver-siones en TIC es de grandes proporciones. Colombia es un país donde 98% de las empresas son Pymes y de este porcentaje sólo 2%, que corresponde a las empresas medianas, están preparadas para competir. Y aunque más de 80% de las Pymes invierten en computadores, sólo 55% tienen página web y apenas un 33% invierten en sistemas de información de gestión [6].

El sector cooperativo en Colombia no es ajeno a esta brecha que presenta deficiencias en sus sistemas de información, por el constante cambio en la normatividad donde cada vez se exi -ge más información relevante sobre las actividades que estas llevan a cabo en especial a la actividad de crédito; todo dentro del ámbito legal donde entidades estatales cada vez se están

1 Un sistema nervioso digital comprende los procesos digitales que encadena estrechamente todos los aspectos de pensamiento y acción en la empresa. La disponibilidad inmediata de informaciones exactas introduce un cambio en la reflexión estratégica que pasa de ser un aspecto aislado a convertirse en un proceso continúo e integrado con las actividades normales de la empresa.

Página 10


pasando a sistemas de información más robustos donde requieren mayores volúmenes de información; al igual la Superintendencia de la Economía Solidaria desde hace dos años viene solicitando informes periódicos, donde solicitan información sobre los asociados; que en muchas ocasiones las cooperativas no tienen o esta desactualizada. Basándonos en estas defi-ciencias en los sistemas de información en las Cooperativas que se dedican a la actividad crediticia; surge la oportunidad para desarrollar un prototipo de un sistema de información para el sector cooperativo.

El cual representó un reto llevarlo a cabo; a lo largo de este documento abordaremos los dis -tintos aspectos técnicos, de diseño, requerimientos, y la metodología empleada para crear este sistema de información; prototipo que fue desarrollado utilizando la tecnología Java EE 7[7][8] que proporciona un conjunto de frameworks, para la construcción de aplicaciones empre-sariales entre los cuales se encuentran log4j, Seguridad por roles, anotaciones, Java Server Faces (JSF) [8] [9], y un módulo dedicado a la persistencia de los datos en este tipo de aplica-ciones Web.

El prototipo generado se compone de 6 módulos establecidos a partir del trabajo realizado con el cliente; éstos ofrecen los componentes necesarios para realizar la administración de la información. En el presente documento se describe el proceso detallado de todo lo que fue utilizado para el desarrollo del prototipo final y se describe el modo en que fueron utilizadas cada una de las herramientas y las razones por las cuales fueron utilizadas.

Página 11


I - DESCRIPCIÓN GENERAL

1 Oportunidad, Problemática, Antecedentes

La aparición de Internet y el desarrollo de las nuevas tecnologías de la información y comuni -cación (TIC’s), ha originado grandes cambios en la sociedad en general y en las empre-sas[10]. El sector cooperativo en Colombia, en especial las cooperativas multiactivas, que “son las que se organizan para atender varias necesidades, mediante concurrencia de servicios en una sola entidad jurídica” [11] [12], en el desarrollo de su objeto social están expuestas a diferentes riesgos como los siguientes:

Riesgo de Mercado: Son aquellas pérdidas que se tienen cuando cambian las tasas de interés [13].

Riesgo de Liquidez: Es la contingencia de que la cooperativa incurra en pérdidas excesivas por la venta de activos a descuentos inusuales y significativos, con el fin de disponer rápidamente de los recursos necesarios para cumplir con sus obligaciones contractuales[13].

Riesgo de Crédito: Es la posibilidad de que la cooperativa incurra en pérdidas, como consecuencia de que un deudor o contraparte incumpla sus obligaciones [13].

Riesgo Operativo: Se cuenta con los sistemas, programas y procedimientos necesa-rios que garantizan la adecuada operación del área de Créditos [13].

Riesgo Legal: Es aquel no previsto y que determina una ley o una norma o disposi-ción regulatoria de la Superintendencia Bancaria que obligatoriamente hay que cum-plirla [13].

Teniendo en cuenta lo anterior, la Gestión de los Riesgos en las Cooperativas es considerada como un elemento fundamental para la consecución de los objetivos. Con la gestión de ries-gos se está contribuyendo a la eficaz identificación, medición, análisis, tratamiento, comuni-cación y monitoreo de los riesgos del negocio, con el objetivo de preservar la eficacia, efi-ciencia y efectividad de su gestión y la capacidad operativa.

Se ha identificado un componente del riesgo operacional que involucra la tecnología de la información, y es allí donde se centra la problemática que se va a tratar de solucionar. En la Ilustración 1podemos observar los factores que componen el riesgo operacional.

Página 12


Ilustración 1 Componentes del riesgo Operacional

Esta situación genera doble trabajo por parte de los empleados de las Cooperativas con sec-ción de aporte y crédito. En la Ilustración 2 se observan las causas que conllevan a generar la problemática que actualmente se viene presentando en estas Cooperativas, estas causas se evidencia a nivel general, sin embargo las que a continuación se presentan, corresponde a las causas de la cooperativa caso de estudio.

Ilustración 2 Causas de la Problemática

Página 13

Procesos

Personas

Tecnología de

Información

Riesgo Operacional

Tecnología de Información

Perdida de InformaciónProcedimientos Inadecuados.Errores Humanos.

Inconsistencia de información

Falta de Información

Obsolescencia de los equipos de computo

Descuadres Contables


2 Formulación del Problema que se resolvió

¿Cómo una cooperativa multiactiva [14] con sección de crédito y aportes, puede solucionar los problemas de pérdida e inconsistencia de información para mejorar y aumentar la produc-tividad?

3 Justificación del problema

Para responder la pregunta anterior se propone construir un sistema de información con un manejo adecuado de la información acorde con los requerimientos que la Cooperativa necesi-ta y con los requerimientos necesarios para dar cumplimiento a la circular externa 002 de 2014[15] de la Superintendencia de la Economía Solidaria, la cual exige presentación de in-formación de los asociados, los créditos otorgados y los aportes sociales.

En el mercado de las tecnologías de la información se encuentran desarrollos que pueden ser ajustados a las necesidades específicas de cada cooperativa; no obstante, estos sistemas que se encuentran en el mercado requieren el pago de licencias propietarias y aquéllos que se ofrecen como gratis o software libre no ofrecen cubrir todos los requerimientos básicos, para el adecuado manejo de la información.

4 Impacto Esperado

El presente proyecto espera tener dos frentes de impacto; por una parte, se espera la acepta-ción del prototipo por parte de un cliente, de ser así se continuará con el desarrollo del proto-tipo hasta obtener una aplicación 100% funcional que cumpla con todas las características que la cooperativa requiera y poder llegar a nuevas cooperativas, obteniendo alguna retribu-ción económica.

5 Descripción Del Proyecto

El producto es un Prototipo de un Sistema de Información para la administración de datos en una Cooperativa multiactiva con sección de crédito y aportes, llamado SISINFOCOOP, el cual está orientado al manejo de la información tanto de un asociado, sus aportes y sus crédi-tos.

El propósito del prototipo a desarrollar es ofrecer un sistema de información, acorde a las necesidades y requerimientos de las cooperativas. Entre los requerimientos podemos generali-zar los siguientes: manejo de la información de un asociado, manejo de los aportes sociales de cada uno de los asociados y el manejo de los créditos de los asociados.

Página 14


5.1 Objetivo General

Desarrollar un prototipo de un sistema de información en la web, que gestione la administra-ción de Asociados, Créditos y Aportes de una Cooperativa multiactiva con sección de aporte y crédito, con el fin de aumentar y mejorar la productividad.

5.2 Objetivos Específicos

Identificar el contexto actual de la administración de la información de la Cooperati -va.

Levantar Requerimientos en este tipo de Cooperativas, que el sistema debe cumplir.

Implementar el prototipo funcional del sistema, que incluye análisis, diseño y desa-rrollo del prototipo.

Validar el presente prototipo en la cooperativa caso de estudio, “Coocredimar”.

Página 15


5.3 Supuestos y restricciones

5.3.1 Supuestos El cliente no cambiará los requerimientos durante el desarrollo del proyecto. Por lo menos uno de los clientes, estará disponible para las retroalimentaciones del

proyecto, las cuales se realizarán 1 vez cada quince días o más, de ser necesario. Las herramientas que se usarán para el desarrollo del prototipo “SISINFOCOOP”

funcionarán en un computador de la Cooperativa, igualmente en el computador del estudiante.

5.3.2 Restricciones Se deben realizar los documentos o entregables que sustentan el prototipo. (ver

SPMP sección 1.4: entregables). El prototipo desarrollado por el estudiante, debe funcionar por completo en los com-

putadores de la Cooperativa y del mismo estudiante. El prototipo desarrollado, debe incluir conexión cliente - servidor, persistencia y

altos componentes de GUI. El proyecto deberá realizarse en 85 días de acuerdo a lo estipulado en el trabajo de

grado y en el cronograma del proyecto.

6 Estándares

Para controlar la evolución, este documento está basado en los siguientes estándares y plantillas:

International Standard Systems and Software Engineering--Life Cycle Pro-cesses--Project Management ISO/IEC/IEEE 16326-2009[16]

IEEE Standard for Information Technology--Systems Design--Software Design Descriptions IEEE Std 1016-2009[17].

IEEE Recommended Practice for Software Requirements Specifications 830-1998[18]

ISO 13407:1999[19]

7 Metodología

7.1 Modelo de Ciclo de Vida

El ciclo de vida que se definió para el desarrollo del prototipo es la metodología XP “EXTREME PROGRAMMING” [20], con alguna modificación basada en la metodología en

Página 16


espiral[21]. XP es una metodología de desarrollo ágil [22][23][24]; dentro de esta modifica-ción se adicionó el análisis de riesgos; la determinación que conllevó a seleccionar a XP como modelo fueron entre otras la retroalimentación continua entre el cliente y el equipo de desarrollo, ya que en el desarrollo del prototipo se tendrá constante comunicación con el cliente del caso de estudio seleccionado . El ciclo de vida estará compuesto por iteraciones que tendrán duración entre 3 días y 20 días la más larga. Las iteraciones se dividirán en las siguientes etapas:

Al inicio de la metodología tenemos las siguientes fases:

Planeación. Análisis de riesgos.

En cada iteración se tienen las siguientes fases:

Diseño detallado Desarrollo Código. Pruebas.

Planeación

Las actividades a realizar para cada una de las iteraciones son:

Plan de desarrollo: Basados en la metodología de PSP [25] se lleva a cabo la fase de pla-neación donde se seleccionan los requerimientos a implementar y tiempo estimado. (ver anexo: plan de desarrollo).

Plan de pruebas: Se define el cómo y cuándo se realizan las pruebas unitarias y las de integración; estas pruebas se realizan por cada caso de uso.

Caso de Uso: Inicialmente se levanta un inventario de casos de uso a desarrollar.

Análisis de riegos

Al inicio del proyecto se analizaron los posibles riesgos que pudieran afectar directamente o indirectamente el desarrollo del prototipo; para ello se seleccionó el top 5 de riesgos y a estos se les aplica el control de riesgos donde se evalúa el impacto y la probabilidad de que ocu -rran, (ver sección 7.5 análisis y administración de riesgos del SPMP), a estos se les realizará un monitoreo durante el tiempo de ejecución del proyecto.

7.2 Etapas en cada Iteración

Diseño detallado

Las actividades definidas en esta fase serán:

Página 17


Ejecución plan de documentación y configuraciones: Se llevará a cabo una documenta-ción de los artefactos en todas las iteraciones, para las iteraciones donde se implementa el incremento se realizará la documentación del manual de instalación y de usuario.

Requerimientos de software: Se realiza un análisis de requerimientos implementados, y de ser necesario se ajustaran, se analizaran los próximos requerimientos a implementar.

Documento SDD: Esta actividad se encarga de realizar el documento de diseño de so-ftware, la arquitectura de la aplicación con base a los requerimientos previamente estable-cidos.

Desarrollo Código

Las actividades definidas en esta fase serán:

Ejecución plan de desarrollo: Se implementará un incremento de acuerdo a las especifi-caciones realizadas en la etapa anterior, basándonos en metodología de PSP [25] imple-mentaremos la fase de desarrollo donde se realizará la implementación del diseño, y detec-ción de errores. (ver anexo: plan de desarrollo).

Pruebas: Se llevan a cabo las pruebas unitarias, de integración y de software con el fin de verificación, detección y reducir defectos.

Pruebas

Cada iteración tendrá una duración entre 3 y 20 días la de mayor alcance donde se llevará a cabo una retroalimentación con el cliente uno de los días de la semana (sección 7.5: control de calidad del SPMP) con el objetivo de validar los artefactos para las siguientes fases.

Cada una de las anteriores etapas conforma la metodología de desarrollo ágil XP, que se apli -có para el desarrollo del prototipo del sistema de información “SISINFOCOP”. Podemos indicar que esta metodología es basada en el desarrollo iterativo e incremental, es por ello que se decidió utilizar esta metodología adaptada a las necesidades del proyecto, adicionalmente la adaptabilidad a cualquier cambio en cualquier etapa como medio para reducir el riesgo de fracaso o atraso en desarrollo.

De acuerdo al cronograma, las iteraciones y los avances del prototipo fueron debidamente presentadas al cliente en cada una de las reuniones semanales que se acordaban, reuniones donde se realizaba la presentación del avance del proyecto y se recibían las retroalimentacio-nes, (Ver Anexos Actas).

Página 18


II – MARCO TEÓRICO

1 Marco Contextual

En los últimos años, en especial estas dos últimas décadas la sociedad ha cambiado más que en los últimos siglos, lo que conocimos como la “economía industrial” hoy se ha volcado a llamarse “economía digital”[26], las nuevas tecnologías han generado un cambio en la forma de hacer negocios, con sus beneficios y sus inconvenientes. Las tecnologías relacionadas con la Electrónica y las Tecnologías de la Información y de las Comunicaciones (ETIC) juegan un papel decisivo y determinante[27].

La falta de formación e información, y el desconocimiento de la utilidad de las aplicaciones de las tecnologías, hacen que muchas empresas sean aun reacias a implantar la tecnología como elemento estratégico clave en sus negocios [19]. “En muchas casos las empresas ad-quieren la tecnología sin ninguna estructura ni orden, es totalmente desintegrado” comenta Jean Paul Bing-Zaemba, gerente general de ADV[28]; el sector solidario no es ajeno a esta problemática, y se viene presentando atrasos tecnológicos que afectan directamente la pro-ductividad de las cooperativas.

Con el fin de aumentar y mejorar la productividad las cooperativas deben evaluar las técnicas actuales y la tecnología disponible con la finalidad de obtener sistemas de información que brinden eficiencia y eficacia en la gestión de la información relevante para desarrollar su actividad económica u objeto social.

La implementación de estos sistemas brinda grandes ventajas como la reducción de costos y el aumento en la agilidad de los procesos que contribuye a que las cooperativas sean más competitivas. Dadas las circunstancias, es claro que las cooperativas que no se pongan al día, quedaran relegadas a una inevitable pérdida de competitividad o en el peor de los casos a su desaparición.

Actualmente en el mercado Colombiano, se encuentran gran variedad de Aplicaciones o Sis-temas de información enfocados al sector solidario, o empresas dedicadas a ofrecer desarro-llos de software a la medida, según las necesidades de la empresa. Dentro de la gran variedad de aplicaciones encontramos las más importantes o las más representativos al momento de referirnos a sistemas de información como son los ERPs[29], uno de ellos es SAP, el cual ofrece gran variedad de módulos según las necesidades de la empresa, y otras herramientas no tan comunes como SICOOPWEB[30] y SAFIX[31]. Dentro de la soluciones open source encontramos OpenERP[32] y adempiere[33].

Las anteriores soluciones todas de pago, tienen unos costos asociados distintos a los valores de las licencias, como son: capacitación, integración y pruebas, consultoría antes y después de la puesta en marcha, costo de nuevo hardware, mantenimiento y actualizaciones, entre otros costos. Costos que las cooperativas, al pertenecer al grupo de las microempresa[34] no puede asumir en este momento de acuerdo al flujo de caja y presupuestos actuales de inver -sión.

Página 19


Funcionalidad o Característica

SAP[35] SICOOPWEB[30] SAFIX[31] Ope-nERP[32]

Licencia Propietario Propietario Propietario Libre

Funcionalidad Incluye funcio-nes Innecesa-rias como centro de costos, sucur-sales, que la cooperativa no utilizaría

Se adapta a la cooperativa

Incluye funcio-nes Innecesa-rias, como ma-nejo de nómina entre otros módulos como inventarios.

Incluye fun-ciones Inne-cesarias que la cooperati-va no haría el uso adecua-do como el manejo de inventarios o centro de costos.

Costo Elevado Costo Elevado Costo Elevado Costo No tiene Costo

Mantenimiento Se contrata al proveedor

Se contrata al proveedor

Se contrata al proveedor

Se requiere Un consultor

Código No se entrega No se entrega No se entrega Si lo entrega

Sistema Operati-vo

UNIX, Linux , Windows

UNIX, Linux , Win-dows

Windows, Li-nux, Solaris

Linux , Win-dows

Base de Datos bases de da-tos Oracle

Utiliza una base de datos propia orientada a obje-tos.

Solamente DB Oracle

PostgreSQL

Capacitación Elevado Costo de Capacita-ción

Incluida en el Valor del software por 3 meses.

Entrenamiento incluido y so-porte por un año

Se requiere de un terce-ro con costo.

Página 20


Documentación La documen-tación es res-tringida por políticas de confidenciali-dad

Documentación poca, no tiene soporte externo

Contrato de Mantenimiento y soporte.

Documenta-ción en línea.

Tabla 1 Comparación Aplicaciones ERP

Los sistemas ERPs unifican información de las diferentes áreas de la cooperativa en un solo lugar, sin embargo la implementación de algunos de los ERPs anteriormente mencionados no son fáciles, se requiere de un periodo largo de implementación, y adicional tiene unos costos asociados altos para una microempresa[36] como las cooperativas; es por ello que sólo las grandes empresas podían adquirir este tipo sistemas, sin embargo en la actualidad las peque -ñas y medianas empresas están incursionando en la implementación de dichos sistemas.

Por otro lado las aplicaciones que fueron sujeto del análisis y de la viabilidad de ser imple-mentadas en cooperativas del mismo tamaño tanto en activos como en la cantidad de asocia-dos a la del caso de estudio; fueron SAFIX y SICOOPWEB, por lado SAFIX tiene el mayor costo ya que asciende a la suma de aproximadamente de $35´000,000, sin incluir costos aso-ciados, como capacitación, nuevo hardware y cabe resaltar que solo funciona con bases de datos Oracle, esta aplicación fue desarrollada con las herramientas Developer y Designer de ORACLE. SICOOPWEB fue la propuesta más económica ya que se cotizo en $11´340,000, su diseño estaba basado en C++, y el código fuente en ninguna de las aplicaciones son entre-gados.

A la hora de evaluar es importante en sí las funcionalidades o servicios que uno provee y el otro no, ya que mañana los dos la proveerán. A la hora de hacer comparaciones es justo tomar las últimas versiones, evaluar el estado de arte de ambos lados de la balanza.

Según Adrian Paredes, consultor de Epidata Consulting “Todos nosotros, en general, usamos versiones antiguas en el trabajo. Es perfectamente normal, ya que no se comienzan proyectos con la velocidad con la que salen frameworks y especificaciones Open Source. Pero si tene-mos que comenzar un nuevo proyecto, para que nuestra evaluación de tecnologías sea válida, tenemos que actualizar las versiones, e incluso mirar más allá, mirar hacia el futuro, hacia las versiones beta, las funcionalidades futuras que se discuten en las comunidades y las especifi-caciones draft”.[37]

Con base en los distintos criterios de comparación, y en las fichas técnicas que se encuentran online de cada una de las soluciones, cabe resaltar que comparar las funcionalidades en si no es importante ya que tarde o temprano cada solución las podrá proveer, pero es importante comprar las tecnologías sobre las cuales estas herramientas están implementadas. Con esta restricción se desarrolló una nueva aplicación utilizando Java EE 7[38], PrimeFaces[39] y PostgreSQL[40] sobre un servidor de aplicaciones Wildfly[41]; adicionalmente la cooperati-va caso de estudio tendrá el código fuente para desarrollar nuevas funcionalidades de acuerdo

Página 21


a las necesidades que llegaran a requerir. La implementación de este desarrollo a la medida, estuvo en marcada en gran medida en la adaptación, disponibilidad y evolución que el proto-tipo ofrece frente a las soluciones existentes actualmente, el prototipo se adaptó perfectamen-te a la cooperativa cumpliendo con cada uno de los requerimientos; el prototipo solucionara los procesos de negocio de la cooperativa; adicionalmente el prototipo podrá ser evoluciona-do a medida que hayan nuevas necesidades por parte de la cooperativa. Las aplicaciones ERP existentes no ofrecían una solución concreta como es el manejo de cuentas de aportes de asociados, administración de información sobre el asociado, como son fecha de expedición del documento de identificación, fecha de ingreso a la cooperativa, tipo de asociado, activi-dad económica del asociado, entre otros datos relevantes tanto del asociado, de la cuenta de aportes de esta mismo y sus créditos; datos que son relevantes para las cooperativas con sec-ción de aporte y crédito para realizar los distintos informes que deben presentar antes las distintas entidades gubernamentales. Estas características precisas sobre el manejo de la in-formación condujeron que la solución era el desarrollo de un software a la medida, que cum-pliera y satisficiera las necesidades de la Cooperativa caso de estudio.

2 Marco Conceptual

A lo largo de este capítulo, se presentarán los conceptos relevantes e importantes del proyecto realizado; para ello es indispensable el conocimiento previo de la arquitectura multicapa de las aplicaciones web y conocimientos básicos de navegación en internet.

2.1 Aplicación Empresarial Web

En la ingeniería de software se denomina aplicación web a aquellas herramientas que los usuarios pueden utilizar accediendo a un servidor web a través de Internet o de una intranet mediante un navegador.

La ventaja significativa de las aplicaciones web, es que funcionan independientemente de la versión del sistema operativo instalado en el cliente. En vez de tener aplicaciones stand alone en cada cliente, la aplicación web se escribe una vez y se ejecuta igual en todas partes. El desarrollo de aplicaciones para la Web es una disciplina cada vez más compleja y que utiliza muchísimas tecnologías diferentes, como XHTML[58] , JavaScript[59] , PHP[59], XML[60], CSS[61], entre otras; la elección de una herramienta u otra es bastante engorroso ya que se debería tener conocimiento sobre todas estas herramientas y optar por la que más se ajuste a las necesidades; sin embargo las ventajas de las aplicaciones web es la facilidad de mantener y actualizar dichas aplicaciones sin la necesidad de distribuir e instalar un software en algunos o miles de clientes; otra de las ventajas es la posibilidad de ser ejecutadas en múltiples plataformas como se había indicado anteriormente. Una aplicación web es un tipo especial de aplicación multicapa, donde el cliente (el navegador o explorador) , el servidor (el servidor web) y el protocolo mediante el que se comunica (HTTP[62]) están estandarizados y no son creados por el programador [63]. El protocoló HTTP forma parte del protocolo de comunicación TCP/IP[62], que son los empleados en internet. Lo que facilita el intercambio de información entre distintos computadores. HTTP se ubica en el nivel 7 del modelo OSI[64].

Página 22


En las últimas dos décadas ha habido un cambio considerable en herramientas de desarrollo y arquitectura disponibles para construir aplicaciones bajo medida como son las aplicaciones web; existen muchos lenguajes que son utilizados por los desarrolladores para implementar aplicaciones web, entre ellos Java, Php, Perl, Python, C#, entre otros, los cuales pueden hacer uso de AJAX[65]para mejorar el uso de los recursos que se encuentran en internet, sin embar-go algunos de estos lenguajes requieren o no el uso de servidores de aplicación.

a) Servidor de Aplicación:

El concepto de servidor de aplicaciones está relacionado con el concepto de sistema distribui-do. Un sistema distribuido, permite mejorar tres aspectos fundamentales en una aplicación: la alta disponibilidad, la escalabilidad y el mantenimiento. Usualmente se trata de un dispositivo de software que proporciona servicios de aplicación a los computadores del cliente. Para nuestro caso ofrecerá servicios al navegador web. Un servidor de aplicaciones generalmente gestiona la gran parte de las funciones de lógica de negocio y de acceso a los datos de la apli-cación[66].

A continuación se presenta algunas de las características de un servidor de aplicación:

La alta disponibilidad hace referencia a que un sistema debe estar funcionando las 24 horas del día los 365 días al año. Para poder alcanzar esta característica es necesario el uso de técnicas de balanceo de carga y de recuperación ante fallos. Para el caso del presente proyecto, la disponibilidad estará dada de acuerdo al horario laboral de las cooperativas; para el caso de estudio la cooperativa tiene el siguiente horario de lunes a viernes de 8am a 5pm en jordana continua.

La escalabilidad es la capacidad de hacer crecer un sistema cuando se incrementa la carga de trabajo (el número de peticiones). Cada máquina tiene una capacidad finita de recursos y por lo tanto sólo puede servir un número limitado de peticiones.

El mantenimiento tiene que ver con la versatilidad a la hora de actualizar, depurar fallos y mantener un sistema. La solución al mantenimiento es la construcción de la lógica de negocio en unidades reusables y modulares. La arquitectura utilizada en el prototipo fue MVC[67], lo cual permite el fácil mantenimiento de la solución.

En la actualidad el término servidor de aplicaciones hace referencia a un servidor de aplica-ciones Java EE. Entre los servidores de aplicación Java EE; más conocidos se encuentran WebLogic de Oracle[68] y WebSphere de IBM[69]. Entre los servidores de aplicaciones de software libre; se encuentran JOnAS soporta hasta Java EE 6 del consorcio OW2 [70], JBoss AS de JBoss (división de Red Hat) actualmente la versión más reciente ha tomado el nombre WildFly [1] con soporte para Java EE 7, GlassFish de Oracle con soporte para java EE 7[71].

A continuación se observa la participación de los distintos servidores de aplicación en el mer-cado global; para ello se analizaron 758 instalaciones de las cuales el 58% pertenecen a insta-laciones Tomcat seguido por instalaciones Jboss.

Página 23


Ilustración 3 Utilización de servidores de aplicaciones en 2015. Fuente: Plumbr[72]

Con respecto a la versión del JDK utilizado, observamos que se están adoptando las nuevas versiones. Para empezar, Java7 domina el mercado, habiendo tocado techo. Java8 va subien-do y Java6 camino de desaparecer ver Ilustración 4 Utilización de las versiones de Java en2015. Fuente: Plumbr[72]

Ilustración 4 Utilización de las versiones de Java en 2015. Fuente: Plumbr[72]

Página 24


b) Servidor de Aplicación Utilizado

Para el presente proyecto se ha seleccionado como servidor de aplicación a WildFly[41] 8.1.0 sucesor del servidor de aplicación Jboss. Porque Wildfly al ser un servidor de aplicaciones Java EE de código abierto implementado en Java puro, puede ser utilizado en cualquier siste-ma operativo para el que esté disponible la máquina virtual de Java; generando portabilidad.

2.2 Entorno WEB

Las aplicaciones web pueden emplear o utilizar tres entornos, que pueden confundirse entre sí: Internet, intranet y extranet.

2.2.1 Internet

Podemos encontrar una gran variedad de significados sobre que es Internet, sin embargo para este trabajo de grado, vamos a definir a internet como una red de redes que permite la interco-nexión descentralizada de computadores a través de un conjunto de protocolos denominado TCP/IP. Tuvo sus orígenes en 1969, cuando una agencia del Departamento de Defensa de los Estados Unidos comenzó a buscar alternativas ante una eventual guerra atómica que pudiera incomunicar a las personas. Para acceder a internet el método común es obtener acceso a través de proveedores de servicio de internet llamados ISP.[64]

2.2.2 Intranet

Una intranet es una red de computadores basados en protocolos de comunicación TCP/IP. Comúnmente se conoce como una red privada, hoy en día este tipo de redes las vemos con más frecuencia en cualquier tipo de organización sea empresarial, o familiar, la red de nues -tros hogares por ejemplo.[64]

2.2.3 Extranet[64]

Como la palabra lo indica “Extra”, se refiera a que se le adiciona algo a la red, con ello pode-mos decir que a la intranet se le puede acceder desde otro lugar, con diferentes niveles de acceso a personas que se encuentran al exterior de la intranet, por ejemplo los empleados que acceden desde su hogar a la red de la empresa donde labora. Para efectos del presente trabajo, la aplicación cuenta con roles para poder acceder desde afuera de la Cooperativa.

3 Metodologías de desarrollo de proyectos de software

Para el desarrollo de cualquier software, llámese aplicación, sistema operativo, etc., estos debieron seguir un proceso de varias fases en el que, partiendo de una necesidad, se ha gene-rado un producto u artefacto que satisface los requisitos iniciales [21]. Este proceso de desa-rrollo, es el tema de estudio de la Ingeniería de software, a continuación se expondrá algunas fases que conforman el proceso de desarrollo.

Página 25


3.1 Metodologías Agiles

Las metodologías ágiles son una serie de técnicas para la gestión de proyectos que han surgi-do como contraposición a los métodos clásicos de gestión como CMMI[73].

Todas las metodologías que se consideran ágiles cumplen con el manifiesto ágil que no es más que una serie de principios que se agrupan en 4 valores[73]:

Los individuos y su interacción, por encima de los procesos y las herramientas. El software que funciona, frente a la documentación exhaustiva. La colaboración con el cliente, por encima de la negociación contractual. La respuesta al cambio, por encima del seguimiento de un plan.

Entre las metodologías ágiles más usadas se encuentran[74]:

SCRUM [75]: Desarrollada por Ken Schwaber, Jeff Sutherland y Mike Beedle. Define un marco para la gestión de proyectos, que se ha utilizado con éxito du-rante los últimos 10 años. Está especialmente indicada para proyectos con un rápido cambio de requisitos. Sus principales características se pueden resumir en dos. El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días. El resultado de cada sprint es un incremen-to ejecutable que se muestra al cliente. La segunda característica importante son las reuniones a lo largo proyecto. Éstas son las verdaderas protagonistas, espe-cialmente la reunión diaria de 15 minutos del equipo de desarrollo para coordi-nación e integración.

Crystal Methodologies [23]: Se trata de un conjunto de metodologías para el desarrollo de software caracterizadas por estar centradas en las personas que componen el equipo y la reducción al máximo del número de artefactos produci-dos. El desarrollo de software se considera un juego cooperativo de invención y comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas.

Dynamic Systems Development Method (DSDM) [76]: Define el marco para desarrollar un proceso de producción de software. Nace en 1994 con el objetivo el objetivo de crear una metodología RAD unificada. Sus principales característi-cas son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan juntos. Propone cinco fases: estudio viabilidad, estudio del ne-gocio, modelado funcional, diseño y construcción, y finalmente implementación. Las tres últimas son iterativas, además de existir realimentación a todas las fa-ses.

Adaptive Software Development (ASD) [22]: Su impulsor es Jim Highsmith. Sus principales características son: iterativo, orientado a los componentes so-ftware más que a las tareas y tolerante a los cambios. El ciclo de vida que propo-ne tiene tres fases esenciales: especulación, colaboración y aprendizaje. En la

Página 26


primera de ellas se inicia el proyecto y se planifican las características del so-ftware; en la segunda desarrollan las características y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo.

Feature-Driven Development (FDD) [77]: Define un proceso iterativo que consta de 5 pasos. Las iteraciones son cortas (hasta 2 semanas). Se centra en las fases de diseño e implementación del sistema partiendo de una lista de caracte-rísticas que debe reunir el software.

Lean Development (LD) [78]: En LD, los cambios se consideran riesgos, pero si se manejan adecuadamente se pueden convertir en oportunidades que mejoren la productividad del cliente. Su principal característica es introducir un mecanis-mo para implementar dichos cambios.

Extreme Programming (XP) [24] [79] : Es una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendi-zaje de los desarrolladores y propiciando un buen clima de trabajo.

En la Ilustración 5 Comparación metodologías agiles[80], compara las distintas aproximacio-nes agiles en base a tres parámetros: vista del sistema como algo cambiante, colaboración entre los miembros del equipo, y algunas características específicas como: simplicidad, exce-lencia técnica, resultados, adaptabilidad, etc.

CMM ASD Crystal DSDM FDD LD Scrum XP

Sistema como algo cam-biante 1 5 4 3 3 4 5 5

Colaboración 2 5 5 4 4 4 5 5

Características Metodolo-gía (CM)

Resultados 2 5 5 4 4 4 5 5

Simplicidad1 4 4 3 5 3 5 5

Adaptabilidad 2 5 5 3 3 4 4 3

Excelencia técnica 4 3 3 4 4 4 3 4

Página 27


Prácticas de colabo-ración 2 5 5 4 3 3 4 5

Media CM 2.2 4.4 4.4 3.6 3.8 3.6 4.2 4.4

Media Total 1.7 4.8 4.5 3.6 3.6 3.9 4.7 4.8

Ranking de “agilidad” (Los valores más altos representan una mayor agilidad)

Ilustración 5 Comparación metodologías agiles[80]

Como se observa en la Ilustración 5 Comparación metodologías agiles[80], todas las metodo-logías tienen diferencias significativas respecto a CMM, las más destacadas son ASD, SCRUM y XP.

Justificación:

No existe una metodología universal para hacer frente con éxito a cualquier proyecto de desa-rrollo de software. Toda metodología debe ser adaptada al contexto del proyecto, sin embargo las metodologías tradicionales exigen un esfuerzo considerable para ser adaptadas, en proyec-tos pequeños, mientras que las metodologías agiles ofrecen una solución casi a medida, la cualidad de estas metodologías es la sencillez en la aplicación y su aprendizaje. Para ampliar la información de las sobre las metodologías y una comparación con las demás se recomienda (ver el anexo SPMP).

4 Lenguajes y herramientas candidatas para implantar el sistema.

Las herramientas de programación, son aquellas que permiten realizar aplicativos, programas y sistemas para que el hardware del computador, funcione y pueda producir resultados. Hoy en día existen múltiples herramientas de programación en el mercado a continuación se ex -pondrán algunas de las posibles herramientas a utilizar:

4.1 Plataforma .NET

Microsoft .NET ofrece independencia de lenguaje e interoperabilidad, pero no portabilidad. Un componente de .NET puede ser escrito en cualquier lenguaje (VB.NET, C #) ya que el código fuente es traducido a un lenguaje intermedio (IL – Intermediate Language) análogo al bytecode de Java, que es interpretado por CLR[81] (Common Language Runtime) análogo al JRE. Esto es lo que se denomina .NET Framework[82].

Página 28


4.2 .NET Framework

. NET Framework es un entorno de ejecución runtime que administra aplicaciones cuyo des-tino es .NET Framework. Incorpora Common Language Runtime (CLR), que proporciona administración de la memoria y otros servicios del sistema, y una biblioteca de clases com-pleta (BCL)[83]. Todos estos componentes están divididos en tres grupos principales:

Windows Forms ASP.NET y servicios Web XML ADO.NET

Microsoft proporciona, junto con el .NET Framework, las implementaciones de cuatro len-guajes compatibles con CLS (Common Language Specification) y son[82]:

Microsoft Visual Basic .NET Microsoft Visual C# .NET Microsoft Visual J# .NET Microsoft Visual C++ .NET

4.3 Java EE 7

Java EE 7 [42]: plataforma de programación JAVA para desarrollar y ejecutar software y aplicaciones en este lenguaje de programación. Dentro de la utilización de esta plata-forma de programación, se utilizó EJB 3.0 [43], los cuales tienen la lógica del negocio, definen patrones de arquitectura y responsabilidades dentro del sistema.

La plataforma Java EE está destinada a desarrollar aplicaciones empresariales, con una arqui-tectura multi-capa, escritas en el lenguaje de programación Java y que se ejecutan en un ser-vidor de aplicaciones, como se indicó anteriormente nuestro servidor es WildFly. Java, es un conjunto de especificaciones que permiten soluciones para el desarrollo, despliegue y gestión de aplicaciones multicapa centradas en servidor [2] [38].

“Java EE7 es una plataforma de Programación para el Desarrollo de Aplicaciones Empresa-riales en el lenguaje Java, es un conjunto de especificaciones y tecnologías desarrolladas por la compañía Oracle. Integrada por diversas tecnologías y frameworks de cada capa como Java Server Faces (JSF2), Weld CDI, Enterprise Java Beans (EJB3.2) y JPA2, Layout HTML5/CSS3 entre otras”.[2]

La plataforma Java EE ha ido cambiando con el tiempo, en sus inicios se denominó Java 2 EE hasta la versión 1.4, posteriormente cambió a Java EE 5, luego a Java EE 6 y la versión actual es la Java EE 7. Cabe señalar que se tiene previsto el lanzamiento de la versión Java EE 8.

Página 29


Ilustración 6 Java EE Evolución. Fuente: Oracle

Las especificaciones más importantes que incluye Java EE 7 son las siguientes:

JSF (2.2): Para desarrollar aplicaciones web [84]. Servlets (3.1) y JSPs (2.3): Los servlets son la base a partir de la cual desarrollar aplica-

ciones web dinámicas y los JSP una forma de servlet en el que la mayor parte del código HTML, similar a PHP [84].

CDI (1.0): Proporciona inyección de dependencias [84]. EJB (3.2): Beans gestionados por un contenedor administrando su ciclo de vida y propor-

cionales funcionalidades como persistencia y transacciones. Suelen usarse para incluir la lógica de negocio de la aplicación [84].

Bean Validation (1.1): Funcionalidad que mediante anotaciones permite indicar restric-ciones sobre los valores que pueden contener los beans [84].

JPA (2.1): Especificación que proporciona persistencia en una base de datos [84]. JTA (1.2): Especificación que proporciona transaccionalidad [84]. JMS (2.0): Especificación que permite a las aplicaciones comunicarse mediante mensa-

jes de forma desacoplada [84]. JAX-RS (2.0): Especificación sobre los servicios web basados en el modelo REST sobre

el protocolo HTTP [84]. JAX-WS (1.3): Especificación sobre servicios web basados en XML [84]. JavaMail (1.5): Especificación para el envío de mensajes de correo electrónico [84].

4.4 Java EE o .NET

La plataforma para escoger depende de la situación y de las necesidades de la aplicación. Seleccionar entre una y otra no iría mal. Sin embargo, la elección no debe ser sobre la base de

Página 30


cual tiene mejor arquitectura sino que debe basarse en las fortalezas y debilidades de las tec -nologías y cual ofrece una mejor solución para la tarea en cuestión.

Servicio o Característica Java .NET

Runtime JVM CLR

Naming JNDI ADSI

Portabilidad Se puede ejecutar en distin-tos sistemas operativos (Windows, Linux).

Solo se puede ejecutar en sistemas Windows

Costo Open Source Propietario

Acceso a DB JDBC ADO.NET

Interprete JRE CLR

Lenguajes de programación Java, Scala, PHP, Python, JavaScript, entre otros

C#, VB.NET, PHP, entre otros

Ilustración 7 Comparación entre Java y .NET[82]

“SISINFOCOOP”, fue desarrollado en Java EE 7, a continuación algunas consideraciones que se tuvieron en cuenta para seleccionar a Java como plataforma de desarrollo. Java EE, es sin duda la plataforma de desarrollo de aplicaciones más popular en el ámbito empresarial. Ofrece una serie de ventajas que hacen posible el desarrollo de aplicaciones potentes, flexi-bles, extensibles, ligeras, etc.[84] Elimina la complejidad en cuanto a código y cuenta con la posibilidad de reutilizar código en los archivos de aplicaciones web, lo anterior llevo a selec -cionar a Java, luego viene que versión utilizar 5 , 6 o 7, sin embargo este proceso de selec -ción fue más rápido, primero en cuanto a las últimas versiones disponibles en el mercado y segundo la disponibilidad de tutoriales y bibliografía sobre la versión seleccionada, como último punto de influencia en la selección de la versión, fue que ya se había trabajado previa-mente con esta versión en la Carrera de Ingeniera de Sistemas.

4.5 AJAX

Ajax [49]: Ajax es una tecnología asíncrona, en el sentido de que los datos adicionales se solicitan al servidor y se cargan en segundo plano sin interferir con la visualización ni el comportamiento de la página.

Página 31


AJAX es el acrónimo de (Asynchronous Javascript + XML). Éste término, se presentó por primera vez en el artículo “Ajax: A New Approach to Web Appllications” publicado por Jesse James Garret el 18 de Febrero de 2005 [65] [60].

El artículo define AJAX así:

“Ajax no es una tecnología en sí mismo. En realidad, se trata de varias tecnologías indepen-dientes que se unen de formas nuevas y sorprendentes”[65].

Las tecnologías que conforman AJAX son:

XHTML y CSS: Para crear una página web basada en estándares. DOM: (Document Object Model) Manejo de la interacción y manipulación dinámi-

ca de la página web. XML, XSLT y JSON: Para el intercambio y manipulación de la información. XMLHttpRequest: Para el intercambio asíncrono de información. JavaScript: Para reunir las de más tecnologías.

Ilustración 8 Comparación de Modelos de aplicación Web Clásico y AJAX. Fuente: Adaptive Path

Página 32


4.5.1 Para Que Sirve AJAX

La principal razón de utilizar AJAX, es intercambiar información entre el servidor y el cliente (navegadores) sin la necesidad de recargar toda la página. De esta forma, ganamos en usabili-dad, experiencia y productividad del usuario final. AJAX permite mejorar completamente la interacción del usuario con la aplicación, evitando las recargas constantes de la página, ya que el intercambio de información con el servidor se produce en un segundo plano [59] [60] [85]. La diferencia al utilizar AJAX es que no es necesario recargar toda la página web, como ocurre normalmente cuando damos clics sobre algún botón o link.

c) Ventajas

Rapidez en las operaciones. Menos carga del servidor, menos transferencia de datos entre el cliente y el servidor. Hoy en día soportada por la mayoría de navegadores. Interactividad ( el usuario no tiene que esperar hasta que llegue los datos o informa-

ción del servidor) Portabilidad Usabilidad Velocidad ( como la página no se recarga toda, solamente una parte)

d) Desventajas

El concepto de “volver a la página anterior” se pierde, ya no existe. Problemas con versiones antiguas de navegadores. Se requiere conocimiento sobre las tecnologías que conforman AJAX. Los buscadores no indexan la información recibida vía AJAX.

4.6 Netbeans o Eclipse

La elección del IDE, estuvo en marcada más por gusto y sugerencias de otros colegas que han trabajado previamente en ambos ambientes de desarrollo, basados en la experiencia de ellos y sugerencias entre otras de la Directora del Trabajado de Grado, se escogió a Eclipse como el IDE, para el desarrollo del prototipo.

Eclipse Luna [52]: Eclipse[53] es una plataforma de desarrollo integrado (IDE), diseña-da para ser extendida de forma indefinida a través de plug-ins. Eclipse tiene un conjunto de complementos, incluidas las Herramientas de Desarrollo de Java (JDT).

Página 33


4.7 PrimeFaces

Prime Faces 5.2 [3]: PrimeFaces es una librería de componentes visuales open source que extiende a JSF [3], desarrollada y mantenida por Prime Technology [3], el objetivo es ofrecer un conjunto de componentes para facilitar la creación y el diseño de aplicacio-nes web, los componentes de PrimeFaces cuentan con soporte nativo de Ajax, pero no se encuentra implícito, de tal manera que se tiene que especificar que componentes se de-ben actualizar al realizar una petición proporcionando así mayor control sobre los even-tos.

Las principales características de Primefaces son:

Posee un gran set de componentes UI (HtmlEditor, Dialog, AutoComplete, Charts, DatePicker, DataTables, TreeComponent, etc).

Tecnología Ajax basada en la API Ajax JSF 2.2. Muy liviana. Solo un archivo jar. No se requiere configuración. Soporta Skinning y posee más de 35 temas pre construidos.

4.8 PostgreSQL

PostgreSQL 9.3[44]: sistema de gestión de la base de datos, con el cual se realizó la creación y manejo de la misma dentro del sistema, PostgreSQL es un sistema de gestión de bases de datos objeto relacional, distribuido bajo licencia BSD y su código fuente está disponible libremente [44].

“Su desarrollo comenzó hace más de 16 años, y durante este tiempo, estabilidad, potencia, robustez, facilidad de administración e implementación de estándares han sido las características que más se han tenido en cuenta durante su desarrollo. PostgreSQL funciona muy bien con grandes cantidades de datos y una alta concurrencia de usuarios accediendo a la vez a el sistema.” [45].

En el presente proyecto se podía usar cualquier otro motor de base de datos, sin embargo se escogió a postgresql por su tipo de licencia y la facilidad de configuración con Eclipse Luna. Igualmente se puede cambiar en cualquier momento gracias a la estandarización de JPA.

4.9 Servidor WildFly

Servidor Wildfly 8 [1]: es un servidor de aplicaciones de software libre, que implemen-ta las tecnologías definidas en la plataforma Java EE y permite ejecutar aplicaciones que siguen esta especificación.

Página 34


4.10 Java Server Faces 2.2

Java Server Faces 2.2 [46]: tecnología para desarrollo en aplicaciones en lenguaje JAVA, que permite hacer despliegue de las páginas y facilita integración con otras tec-nologías. Igualmente, provee la base estructural para el framework de presentación, ges-tionado por Prime Faces [3]:

o Define un conjunto simple de clases base de Java para componentes de la inter-faz de usuario, estado de los componentes y eventos de entrada.

o Proporciona un conjunto de componentes para la interfaz de usuario, incluyendo los elementos estándares de HTML para representar un formulario.

o Proporciona un modelo de JavaBeans para enviar eventos desde los controles de la interfaz de usuario del lado del cliente a la aplicación del servidor.

4.11 Otras Herramientas

JPA 2.1 [47]: framework del lenguaje de programación que maneja los datos relaciona-les en aplicaciones usando JAVA (manejo de la persistencia y bases de datos).

Maven 4.0 [48]: es una herramienta de código abierto para administración y gestión de proyectos de software. Es decir, gestionar el ciclo de vida desde la creación de un pro-yecto en un lenguaje dado, hasta la generación de un binario que pueda distribuirse con el proyecto.

Microsoft Office 2010[50]: Se trata de un conjunto de aplicaciones que realizan tareas ofimáticas, entre las cuales utilizaremos WORD, EXCEL, POWERPOINT Y OUTLOOK. La licencia viene incluida en cada equipo.

Microsoft Project 2010[51]: Solución que proporciona las herramientas de planifica-ción, administración y colaboración, que organiza tareas, subtareas, horas de trabajo, personas y recursos implicados.

Enterprise Architect 7.5.844 [54]: Herramienta de diagramación, la cual soporta len-guaje UML y demás. Adicionalmente, ofrece plugins para estimación.

Bizagi 2.5.1.1 [55]: Herramienta CASE, adecuada para diagramas de BPMN. Licencia Freeware.

Zotero [56]: Zotero es un sistema de gestión de referencias bibliográficas, que permite organizar la información bibliográfica e incluye soporte para Word.

Trello [57]: Trello es un gestor de tareas que permite el trabajo de forma colaborativa mediante tableros (board) compuestos de columnas (llamadas listas) que representan distintos estados.

4.12

Página 35


III – ANÁLISIS

En este capítulo, se dará a conocer las variables que se consideraron para el desarrollo del prototipo. Para ello se realizó una primera fase de exploración, sobre el actual funcionamien-to del sistema de información y los procedimientos internos de una cooperativa, que generan los datos de entrada al sistema. Empezaremos por hacer una descripción de la Cooperativa y como se modela el negocio.

1 Descripción de la Cooperativa Coocredimar caso de estudio

La Cooperativa es una entidad sin ánimo de lucro, la cual ofrece servicios financieros a sus asociados a través de la modalidad de préstamo por Libranza. Para ser Asociado de la coope-rativa debe pertenecer a alguna Entidad con la cual la Cooperativa tiene convenio o código de descuento, en el sector Cooperativo a estas entidades se les denomina Pagadurías, entre estas encontramos:

Secretaria de Educación de Soacha Fopep Colpensiones Previsora Caja de Retiro de las Fuerzas Militares Caja General PONAL Consorcio FPB Foncep Consorcio Pensiones de Cundinamarca Secretaria de Educación Bogotá Secretaria de Educación Cundinamarca

Razón Social COOPERATIVA DE CREDITO Y SERVICIOS MARINOS DE COLOMBIA LTDA - COOCREDIMAR

Nit 800162528

Ciudad Bogotá

Departamento Cundinamarca

Tabla 2 Datos de la Cooperativa

Página 36


2 Flujo Core del Negocio

Tabla 3 Flujo Core del Negocio

En la gráfica anterior se describe el proceso de cómo se obtiene un préstamo, en el evento que el asociado o posible asociado pertenezca a cualquiera de las anteriores Pagadurías.

2.1 Descripción del proceso En primer lugar el Asesor Comercial le solicita al asociado su último desprendible de

pago y obtiene el cupo de endeudamiento que de acuerdo a la Pagaduría. Si el asesor comercial ve que hay cupo de endeudamiento procede a diligenciar la

solicitud de crédito y que el asociado firme la solicitud y la libranza. La libranza junto con los demás documentos (Solicitud de crédito, desprendible de

pago y fotocopia del documento de identidad), son radicados en la Cooperativa. Allí la persona encargada, verifica los documentos, cupo y las referencias. Si esta lo

aprobará, la libranza se diligencia y se pasa a la persona encargada de tesorería para la elaboración del comprobante de egreso y del cheque.

La persona de tesorería firma el cheque y junto con los documentos se los pasa al representante legal de la Cooperativa para la segunda firma y ultima verificación de documentos.

Luego la secretaria de la cooperativa, se comunica con el asociado para indicarle que ya puede pasar por el cheque.

Cuando el asociado reclama el cheque se procede a Grabar la libranza en el Sistema. Este proceso puede tomar hasta 48 horas.

Página 37

Solicitud CreditoVerificacion Cupo

endudamientoDatacredito

Verificacion DatosAutorizacion Credito

Rechazo CreditoAmpliar Datos o

Codeudor

Diligenciamiento Libranza

Desembolso del prestamo.


2.2 Generación Datos de Entrada al Sistema Actual

Tabla 4 Generación Datos del Sistema Actual

Actualmente el sistema de información que maneja la cooperativa, ha quedado rezagado, ya que al cumplir más de 10 años, y sin poder hacer mantenimiento debidamente ha perdido la capacidad de administrar adecuadamente la información y de los nuevos requerimientos que surge a través del tiempo. Entre otras debilidades que se han encontrado son:

Accesibilidad e integridad: o No existe un nombre de usuario y contraseña para cada usuario del sistema.o No existe manejo de roles.o Se pueden hacer modificaciones sin autorización, o que no se deberían per-

mitir Mantenibilidad:

o Como es un sistema de más de 10 años, a lo largo de los cuales los diferentes ingenieros que han pasado le han hecho cambios sin tener ningún tipo de documentación.

o El sistema está hecho PHP y PostgreSQLo No existen capas lógicas de negocio, está en la misma capa de presentación.

Disponibilidad:o Se puede acceder desde los computadores de la Cooperativa (3 Actualmente).

El sistema actual es aplicación PHP, con integración de postgresql, no se manejan roles, ni usuarios, la capa de negocio está dentro de la misma capa de presentación; esta aplicación funciona sobre el sistema operativo Red Hat.

Como empleado de la Cooperativa se propuso cambiar el sistema actual, desarrollando un prototipo funcional, que con llevaría en un futuro a la respectiva implementación. Prototipo que se desarrolló a lo largo del Segundo semestre del 2015.

Página 38

Solicitud Credito

Datos del AsociadoDatos del ProveedorDatos de la Pagaduria

Libranza

Datos del PrestamoMonto desembolsadoPlazo en MesesValor CuotaFecha Primer Descuento


2.3 Proceso de Negocio

Las cooperativas de aporte y crédito, se dedican a la actividad crediticia bien de manera espe-cializada o como parte de un objeto social más amplio. Esta prestación de servicios va dirijo a los asociados que tiene la cooperativa; para la prestación del servicio crediticio el asociado debe autorizar que le descuente de su pensión, o de su sueldo, mediante la firma de una li -branza, donde el deudor autoriza a su entidad empleadora a descontar de su nómina mensual una suma determinada por un plazo pactado.

2.4 Proceso Solicitud Crédito

El Proceso de Solicitud Crédito gestiona las actividades necesarias para recibir, analizar y aprobar solicitudes registradas por los asociados. Este proceso consta del registro de la solici-tud, la verificación de la información del asociado y el estudio del crédito; capacidad de pago, comportamiento crediticio entre otras variables. Al registrar la solicitud el asociado manifies-ta su interés de adquirir un crédito y presenta la documentación requerida a la cooperativa. Luego el departamento de cartera y crédito realiza la verificación de la información presenta -da por el asociado, y posteriormente el comité de crédito realiza estudio de la solicitud. Por último se realizan las actividades necesarias para desembolsar el monto solicitado o informar el rechazo de la solicitud al asociado.

El proceso anterior es representado mediante el siguiente diagrama BPMN:

Ilustración 9 BPMN Solicitud Crédito

Página 39


2.5 Proceso Abono a Crédito o Registro Cuota Aportes

El Proceso de Abono a un crédito o el registro de Aporte, gestiona las actividades necesarias para recibir, analizar y registrar estos procesos en el sistema. Este proceso consta del registro del documento contable, y el registro de las respectivas transacciones. Al registrar el docu-mento contable en el sistema, se habilita el registro de las transacciones; que se reciben de la respectiva pagaduría. Luego el departamento de operaciones realiza la respectiva aplicación de estas transacciones en el sistema, y posteriormente se emite el reporte de estas transaccio -nes.

El proceso anterior es representado mediante el siguiente diagrama BPMN:

Ilustración 10 BPMN Registro Abono

Página 40


3 Sistema Actual de la Cooperativa Caso de Estudio

Actualmente la Cooperativa “Coocredimar”, tiene un sistema de información obsoleto en la medida que ha dejado de cumplir con los requerimientos que la cooperativa necesita, adicio-nalmente este sistema fue construido utilizando herramientas como PHP y Mysql; este siste-ma maneja la lógica de negocio en la misma capa de presentación sin ningún mecanismo de seguridad ni de persistencia; tampoco se cuenta con validaciones sobre los campos, permi-tiendo que el usuario pueda ingresar información errónea, caso que ha sido constante al mo-mento de solicitar informes, actualmente las Cooperativas con sección de aporte y crédito deben presentar informes a la superintendencia de economía solidaria sobre los asociados, aportes y créditos, dentro de algunos de los datos que se deben enviar esta como la fecha de nacimiento del asociado, los códigos de departamento y ciudad del asociado, fecha y valor del último pago realizado a un crédito, estos son algunos de los datos que se solicitan y que la Cooperativa no tiene registrado en su sistema de información; para ello la cooperativa hace una consulta sobre la base de datos y descarga la información a un archivo de Excel, y allí hacen la depuración de la información y adicionan los campos que necesiten de forma ma-nual, digitando información alzar sin verificación o respaldo de esta. Dando como resultado informes pocos fiables y verificables.

4 Análisis del Sistema de Información SISINFOCOOPA lo largo de esta sección, se darán a conocer aspectos relevantes para el diseño posterior del Prototipo (Ver Sección

Página 41


). SISINFOCOOP, es un sistema de información para las Cooperativas multiactivas de tercer grado con sección de Aportes y Créditos, para nuestro caso se tomó a la Cooperativa Coocre-dimar (Ver Sección 1 Descripción de la Cooperativa Coocredimar), A continuación se descri-birá el proceso de desarrollo del prototipo, sus etapas y demás detalles del mismo como:

Módulos que conformaran el prototipo del Sistema de Información. Los requerimientos más relevantes del prototipo del Sistema de Información. Los Casos de uso más relevantes del prototipo del Sistema de Información. Descripción del diagrama de entidades del prototipo del Sistema de Información.

4.1 Levantamiento de Requerimientos

Este proceso de levantamiento de requerimientos se realizó en las instalaciones de la Coope-rativa caso de estudio, con el acompañamiento de los siguientes miembros:

Representante Legal Secretaria Tesorera Presidente del Consejo de Administración. Estudiante del Trabajo de Grado

Se realizaron 3 reuniones para plasmar las ideas que ellos tenían de cómo desearían que fuera el nuevo sistema. Como son personas un poco ajenas al modelamiento de este tipo de siste -mas, se unificaron varias ideas y se propuso realizar este análisis, por módulos para que flu-yera más rápido este levantamiento, ya que todos proponían que el sistema realizara una ope-ración de varias formas, a continuación se explican los módulos.

e) Módulos

Modulo Descripción

Módulo de Seguridad Este módulo estará disponible y será admi-nistrado por el usuario que tenga el rol de Administrador, para controlar roles, usua-rios y asignación de roles a usuarios.

Módulo de Administración En este módulo, se administrara las Perso-nas, Asesores Comerciales, Proveedores y Pagadurías.

Módulo de Asociados En este módulo, se administrara los asocia-dos de la cooperativa y se asignara la cuen-

Página 42


ta aporte del asociado.

Módulo de Crédito En este módulo, se administrara la solicitud del crédito y la libranza del asociado.

Módulo de Transacciones En este módulo, se administrara el docu-mento contable y las transacciones de los aportes y de los créditos.

Módulo de Reportes En este módulo, se podrán realizar consul-tas e impresiones sobre aportes, créditos, pagadurías, proveedores y asesores comer-ciales.

Tabla 5 Módulos del Sistema de Información SISINFOCOOP

Página 43


4.2 Requerimientos del Sistema por MódulosID Requeri-

miento Descripción

RF 1 El sistema debe permitir a un usuario iniciar sesión proporcionando el nombre de usuario y contraseña.

RF 2 El sistema debe permitir a un usuario cerrar la sesión cuando esta autenticado.RF 3 El sistema debe permitir a un usuario el cambio de contraseña de ingreso al sistema.RF 4 El sistema debe permitir a un usuario crear, actualizar y eliminar a un usuario del sistema.RF 5 El sistema debe permitir a un usuario crear, actualizar y eliminar roles de seguridad.RF 6 El sistema debe permitir a un usuario activar, o desactivar a un usuario.

RF 7 El sistema deberá contar con mecanismos que permitan el registro de actividades conidentificación de los usuarios que los realizaron para las transacciones de aportes y créditos

RF 8El sistema debe permitir el ingreso sólo a las personas que estén registradas,estos usuarios serán clasificados en varios tipos de usuarios (o roles) con acceso a las opcio-nes de trabajo definidas para cada rol.

RF 9 El sistema debe permitir a un usuario crear, listar, actualizar y eliminar información de una persona

RF 10 El sistema debe permitir a un usuario crear, listar, actualizar y eliminar información de un Asesor Comercial

RF 11 El sistema debe permitir Asignar a una persona el estado de Asesor Comercial

RF 12 El sistema debe permitir a un usuario crear, listar, actualizar y eliminar información de un Proveedor

RF 13 El sistema debe permitir a un usuario crear, listar, actualizar y eliminar información de una Pagaduría

RF 14 El sistema debe permitir a un usuario registrar una solicitud de créditoRF 15 El sistema debe permitir a un usuario asignar el estado de una solicitud de créditoRF 16 El sistema debe permitir a un usuario registrar nuevos créditos.RF 17 El sistema debe permitir a un usuario actualizar y eliminar un Crédito según rol.RF 18 El sistema debe permitir a un usuario crear, actualizar y eliminar un memo

RF 19 El sistema debe permitir a un usuario asignar un proveedor, un asesor, una pagaduría y un codeudor a un crédito

RF 20 El sistema debe permitir a un usuario realizar registros de abonos a un crédito

Página 44


RF 21 El sistema debe permitir a un usuario registrar devoluciones de cuotas por mayor valor de un crédito

RF 22 El sistema debe permitir a un usuario realizar abonos masivos por pagaduría

RF 23 El sistema debe permitir a un usuario modificar un abono, según rol del usuario

RF 24 El sistema debe permitir a un usuario eliminar un abono según rol del usuario

RF 25 El sistema debe permitir a un usuario registrar un documento contable

RF 26 El sistema debe permitir a un usuario realizar registros de aporte a un asociado

RF 27 El sistema debe permitir a un usuario realizar devoluciones de aportes de un asociado

RF 28 El sistema debe permitir a un usuario modificar un aporte.

RF 29 El sistema debe permitir a un usuario ver en pantalla información del Asociado.RF 30 El sistema debe permitir a un usuario ver en pantalla información de un crédito

RF 31 El sistema debe permitir a un usuario ver en pantalla información de los créditos otorgados en un lapso de tiempo

RF 32 El sistema debe permitir a un usuario ver en pantalla los créditos próximos a incorporarse a una pagaduría.

RF 33 El sistema debe permitir a un usuario ver en pantalla créditos otorgados por proveedorRF 34 El sistema debe permitir a un usuario ver en pantalla créditos otorgados por pagaduría

RF 35 El sistema debe permitir a un usuario ver en pantalla créditos otorgados por un asesor co-mercial

RF 36 El sistema debe permitir a un usuario ver en pantalla créditos otorgados a un asociado (Mas de un crédito)

RF 37 El sistema debe permitir a un usuario ver en pantalla informe respecto a los abonos recibi-dos por proveedor

RF 38 El sistema debe permitir a un usuario ver en pantalla informe respecto a los abonos recibi-dos por pagaduría.

RF 39 El sistema debe permitir a un usuario asignar a una persona el estado de Asociado y el Tipo de Asociado

RF 40 El sistema debe permitir a un usuario modificar y eliminar un asociadoRF 41 El sistema debe permitir a un usuario registrar una cuenta de aporte a un asociadoRF 42 El sistema debe permitir a un usuario modificar y eliminar una cuenta de aporte

Página 45


Para ampliar el detalle de los requerimientos del sistema de información SISINFOCOOP, (Ver Anexo Documento: SRS).

4.3Distribución de los Requerimientos en Módulos

A continuación se observa la distribución de los requerimientos funcionales en los distintos módulos del sistema de información SISINFOCOOP.

Se observa que el módulo de reportes, módulo de transacciones y el módulo de seguridad representan la mayor concentración de los requerimientos.

Modulo Seguridad19%

Modulo Asociado10%

Modulo Credito14%

Modulo Transacciones

21%

Modulo de Adminis-tracion

12%

Modulo Reportes24%

Requerimientos Funcionales

Ilustración 11 Distribución RF en Módulos

4.4 Casos de Uso del Sistema de Información SISINFOCOOP por Módulos

Página 46

Tabla 6 Requerimientos del Sistema de Información SISINFOCOOP


Módulo Caso de Uso

Descripción CU

Módulo de Seguridad CU01 CRUD de roles: consulta de la lista de roles, registro de un nuevo rol, modificación, eliminación.

CU02 CRUD de usuarios: Consulta usuarios, Re-gistro, Modificación y Eliminación de usua-rios

CU03 Asignar Rol a un Usuario

CU04 Actualizar Contraseña por parte de un Usuario

CU05 Ingresar al sistema (Usuario y Password)

CU06 Salir del SistemaMódulo Administración CU07 CRUD Personas

CU08 CRUD Asesores ComercialesCU09 CRUD ProveedorCU10 CRUD PagaduríaCU11 Asignar una persona como Asesor Comer-

cialMódulo de Asociados CU12 CRUD de Asociado

CU13 Asignar a una persona como Asociado

CU14 CRUD Cuenta AporteCU15 Registrar una cuenta de aporte a un asocia-

doMódulo de Crédito CU16 CRUD de Crédito

CU17 Registrar un crédito a un asociadoCU18 CRUD Solicitud CréditoCU19 Registrar una solicitud de crédito de un

asociadoCU20 CRUD memoCU21 Registrar un memo a un crédito

Módulo Transacciones CU22 CRUD Transacción CréditoCU23 Registrar un abono de cuota sobre un cré-

ditoCU24 Registrar una devolución de cuota sobre un

créditoCU25 CRUD Documento Contable

Página 47


CU26 Registrar un documento contableCU27 CRUD Transacción Aporte

CU28 Registrar un aporte a una Cuenta aporte de un asociado

CU29 Registrar Devolución de aporte de un aso-ciado

Módulo Reportes CU30 Reporte de Aporte por Asociado CU31 Reporte de Crédito por AsociadoCU32 Reporte de Aporte por PagaduríaCU33 Reporte de Crédito por PagaduríaCU34 Reporte de Crédito por ProveedorCU35 Reporte de Crédito por Asesor Comercial

Tabla 7 Casos de uso del Sistema Información SISINFOCOOP

Para ver en detalle los casos de uso del sistema de información SISINFOCOOP (Ver Anexo: InventarioCasosUso.xls).

Para ver los diagramas de los casos de SISINFOCOOP (Ver Anexo: DiagramasCasosdeUso.-docx).

4.5 Perfiles de Seguridad

A continuación se expondrá los distintos perfiles de seguridad, que pueden tener acceso al sistema de información SISINFOCOOP.

Perfil de Seguridad Descripción

Administrador del Sistema Este perfil, tiene acceso total al sistema y puede la potestad de hacer cualquier modi-ficación en cualquier modulo.

Empleado Este perfil tiene acceso a todos los módulos excepto al módulo de seguridad, y podrá hacer

Asesor Comercial Este perfil tiene acceso los módulos de

Página 48


reporte con todas las opciones habilitadas.

Asociado Este perfil tiene acceso al módulo de re-portes pero solo podrá verificar sus aportes y sus créditos.

4.6 Priorización de Requerimientos

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.

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 "Índi-ce del Valor de Negocio" como el valor en el eje X, y el "Índice de Riesgo" en el eje Y, obte -niendo 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.

Página 49


Ilustración 12. Plano Cartesiano de la Priorización

Como se puede apreciar, se definen cuatro grados de prioridad: Baja, Media, Alta y Evitar:

Grado de Prioridad Descripción

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

Página 50


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.7 Restricciones del prototipo

Las restricciones presentes se dividen en 2 categorías:

4.7.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).

4.7.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 usua -rio (Ver SPMP 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 SPMP sección 2.1.2. Interfaces con el usuario), como el encender y apagar los dispositi-vos 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 SPMP 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 funciona-miento del prototipo SISINFOCOOP. (Ver SPMP sección 2.1.5. Restric-ciones de memoria).

Restricciones del sitio: Estas restricciones, se basan en los requerimientos de adaptación del sitio (Ver SPMP sección 2.1.7. Requerimientos de

Página 51


Adaptación del Sitio) en donde el prototipo SISINFOCOOP debe funcio-nar de manera adecuada.

Restricciones de Hardware:

A partir de las interfaces de hardware (Ver SPMP 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 ("Coocredimar", Cooperativa).

Página 52


IV – DISEÑO

En este capítulo se encuentra la propuesta de diseño para el prototipo a partir del análisis realizado anteriormente y de las herramientas seleccionadas para el desarrollo del mismo.

1 Lenguajes y herramientas seleccionadas.

SISINFOCOOP, implemento distintas herramientas, para el desarrollo de aplicaciones web, la elección de estas herramientas permitió satisfacer algunas de las características que las aplicaciones empresariales deben cumplir como ser robustas, escalables y con un mayor ren-dimiento; dentro de la amplia variedad de las nuevas tecnologías que han surgido se seleccio-naron las siguientes:

Java EE 7, se divide en dominios lógicos llamados contenedores. Cada contenedor tiene una función específica, soporta un conjunto de APIs y ofrece servicios a los componentes como seguridad, acceso a base de datos, gestión de transacciones, nom-bres de directorios, e inyección de recursos. La plataforma Java EE está definida por una especificación, y se considera un estándar. Java EE incluye la especificación de distintas APIs, y define como se deben coordinar las mismas. Esto permite crear apli-caciones empresariales escalables y portables entre distintas plataformas.

JavaServer Faces (JSF) que es la tecnología estándar de la edición empresarial de Java (Java Enterprise Edition, Java EE) para la creación de interfaces de usuario en la web y que permite integrar otras tecnologías como las hojas de estilo en cascada (CSS) que describen como se va a mostrar una página web.

Ajax (Asynchronous JavaScript And XML); un modelo de desarrollo web para crear aplicaciones interactivas, JavaBeans empresariales (Enterprise JavaBeans, EJB).

API (Application Programming Interface) de Java para el manejo de entidades persis-tentes (Java Persistence API, JPA) sobre bases de datos relacionales.

Primefaces componentes para JavaServer Faces (JSF) que facilita la creación de las aplicaciones web.

PostgreSQL que es un sistema de gestión de bases de datos, Eclipse IDE de desarrollo que ofreció integración con Maven y con otros plugins

para Java EE. WildFly como servidor de aplicaciones.

La elección de estas herramientas ofreció una serie de ventajas que hacen posible el desarro-llo de aplicaciones potentes, flexibles, extensibles, ligeras, etc. Adicionalmente esta elección estuvo en marcada por algunos de los siguientes criterios:

Conocimiento de las distintas herramientas de programación y sus librerías. Documentación detallada de las herramientas a utilizar en especial la de Primefaces. Facilidad en el aprendizaje de los Componentes y librerías como fue el caso de Pri-

mefaces y Ajax.

Página 53


La integración de estas herramientas permitió el desarrollo de una aplicación web empresa-rial, que cumplió con los requerimientos y las expectativas de la cooperativa; por un lado JAVA EE 7 dispone de componentes de aplicación, que ofrecen una gran variedad de servi-cios a los mismos (persistencia, seguridad, transacciones, mensajería, conectores, servicios de nombrado, etc...). Así, debido a todos estos servicios ofrecidos por los distintos contenedo-res, se seleccionó a JAVA y el desarrollador puede centrarse en el desarrollo de la lógica de negocio de los componentes en lugar de en tareas de mantenimiento de bajo nivel. Por otro lado los beneficios de utilizar estas herramientas son la escalabilidad, disponibilidad, extensi-bilidad y rendimiento de la aplicación. Una de las ventajas de la solución fue el uso de AJAX como una herramienta para hacer páginas web enriquecidas, que se complementó con la utili-zación de la librería Primefaces para JSF que ofrece una calidad de componentes y la estabili -dad en los cambios de versión e integración con otros estándares.

2 Modelo de Entidades Persistentes

El modelo de entidades (ver Ilustración Modelo de entidades persistentes 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 continua-ción encontrara el diagrama y por otra parte la explicación de todos los elementos del diagra-ma del dominio para explicar las entidades que forman parte del prototipo.

Página 54


Ilustración 13 Modelo de entidades persistentes de SISINFOCOOP

3 Diagrama de Contexto

El diagrama de contexto, representa como interactúa el prototipo con otras entidades al inte -rior o exterior del mismo.

Exterior de la Entidad: En este entorno encontramos el actor asociado que podría acceder desde un navegador web.

Interior de la Entidad: En este entorno encontramos los actores del sistema y la base de datos.

Página 55


Ilustración 14 Diagrama de Contexto

4 Overview de la Arquitectura

A continuación se muestra el overview de la arquitectura del prototipo.

Ilustración 15 Overview de la Arquitectura

Como se puede observar en la Ilustración 15 Overview de la Arquitectura, este representa a modo general el sistema “SISINFOCOOP”. Las principales partes del overview son:

Página 56


Cliente web: Permite a los usuarios que tienen acceso vía web, utilizando un canal como internet o la intranet, acceder a la aplicación por medio de un navegador web.

Servidor web: Contiene el servidor de aplicaciones y la lógica del prototipo.

5 Vista lógica del sistema

La vista lógica del sistema, permite visualizar a partir de un diagrama de componentes, la estructura general del prototipo y el comportamiento de los servicios que los componentes brindan, usando las interfaces que los relacionan.

“Un componente es una unidad modular que puede reemplazarse en su propio entorno. Sus elementos internos quedan ocultos, pero tiene una o varias interfaces proporcionadas bien definidas a través de las cuales se puede obtener acceso a sus funciones.” [2]

Ilustración 16 Diagrama Vista Lógica

En este diagrama se muestra lo siguiente:

Capa de Presentación: Se encuentran los componentes SISINFOCOOP, que representa el web de la aplicación, el cual se conecta a la capa de negocio.

Página 57


Capa de Negocio: Contiene la lógica del negocio.

Capa de Persistencia: Contiene el componente PostgreSQL, encargado de gestionar y mane-jar la base de datos.

6 Vista física del sistema

La vista física del sistema, proporciona al personal de desarrollo, el conocimiento necesario sobre los componentes de hardware que utilizará y aquellos componentes de software que serán instalados, para el correcto funcionamiento del prototipo.

Por lo anterior, el diagrama de despliegue ver (Ilustración 17 Diagrama de despliegueError:Reference source not found) muestra la arquitectura en tiempo de ejecución de los elementos de hardware y artefactos de software con las respectivas asociaciones que están presentes entre estos. , el diagrama resultante es bastante simple, pues en términos de comunicación el prototipo no es complejo.

6.1 Diagrama de despliegue

Ilustración 17 Diagrama de despliegue

6.2 Relaciones entre componentes:

Página 58


Proyecto.ear: Archivo de almacenamiento empresarial Proeyecto.war: archivo de almacenamiento web

org.proyecto.bean: Son los controladores, también conocidos como @ Ma-nagedBean, estos backing beans procesa lógica de negocio, hace llamados a los EJBs, adicionalmente se utilizan para el manejo de excepciones y mensa-jes, para mostrar esta por pantalla, haciendo un llamado a facescontext.add-Message(). Para ello y con el fin de reutilizar código se tiene una clase utili -tario.java de la cual heredan todos los backing beans.

org.proyecto.converter: los Converter forman parte del Framework de JSF, y como su nombre lo indica sirven para convertir la entrada desde las páginas JSF (desde algún input, selectOneMenu, etc.) de String a algún tipo de Dato complejo como un objeto por ejemplo de tipo Persona. Las entradas de datos en JSF se procesan como String y a través de los Converter pueden transfor-marse en el tipo de dato u objeto que se necesite.

org.proyecto.util: Aquí se tienen algunas clases que se han utilizado en al-gún momento durante el desarrollo del proyecto, estas tienen métodos para la reutilización de código, como es el caso de la clase utilitario.java, donde se tiene métodos para poner en pantalla el manejo de mensajes.

Capa Web: Contiene las distintas páginas web, que conforman el prototipo. Proyecto-ejb.jar: Archivo de almacenamiento Java; modulo donde encontramos

empaquetados los Enterprise JavaBeans. org.proyecto.dao: Capa de persistencia, utilizando el patrón DAO, como su

nombre lo indica es un patrón de diseño que busca reutilizar código mediante la implementación de operaciones básicas que se desea implementar en va-riedad de clases, un ejemplo de ello son las operaciones de crear, consultar, listar, eliminar, y modificar (CRUD), por cada una de las entidades tenemos un DAO. A continuación vemos la clase Genérico, de la cual se extienden aquellas clases que necesitan tener el acceso a los datos, para nuestro caso será una clase por cada una de las distintas entidades de nuestro sistema.

org.proyecto.enumerado: En esta carpeta se encontrara con las clases de tipo enum.

org.proyecto.modelo: En esta carpeta encontramos las entidades del siste-ma, con sus respectivas anotaciones JPA.

org.proyecto.servicio: Encontramos las clases que tiene reglas de negocio, y se procesan estas mismas, o en el evento que se desee guardar información en más de una tabla, se pasa por la capa de servicio

Página 59


6.3 Diagrama de Componentes

A continuación se muestra un diagrama de los diferentes componentes que conforman e inte-ractúan dentro del sistema SISINFOCOOP.

Página 60


Ilustración 18 Diagrama de Componentes

Página 61


V – DESARROLLO DE LA SOLUCIÓN

Este capítulo explica las estrategias utilizadas para la implementación y construcción del prototipo garantizando los objetivos específicos de este trabajo de grado.

1 Como se concibió el Prototipo

Luego de realizar las fase de planeación, y análisis explicadas en capítulos anteriores, se pro-cedió a realizar los primeros acercamientos con algunas directivas de la cooperativa caso de estudió, con la finalidad de finiquitar como les gustaría que la aplicación interactuará con el usuario.

Para ello se hizo uso de algunos conceptos de diseño centrado en el usuario (DCU), “el DCU es un proceso cíclico en el que las decisiones de diseño están dirigidas por el usuario y los objetivos que pretende satisfacer el producto, y donde la usabilidad del diseño es evaluada de forma iterativa y mejorada incrementalmente”[86].

De acuerdo a la norma ISO 13407[19], se tienen cuatro fases, las cuales se realizaron de forma informal sobre algunos posibles usuarios del sistema; estas fases son:

Entender y especificar el contexto de uso: Identificar a las personas a las que se diri-ge el producto, para qué lo usarán y en qué condiciones.

Especificar requisitos: Identificar los objetivos del usuario y del proveedor del pro-ducto deberán satisfacerse.

Producir soluciones de diseño: Esta fase se puede subdividir en diferentes etapas secuenciales, desde las primeras soluciones conceptuales hasta la solución final de diseño.

Evaluación: Es la fase más importante del proceso, en la que se validan las soluciones de diseño (el sistema satisface los requisitos) o por el contrario se detectan problemas de usabilidad, normalmente a través de test con usuarios.

1.1 Usuarios y Caracterización

A continuación se realiza una descripción de cada uno de los usuarios del sistema

Página 62

Administrador del SistemaEdad: 30 a 50 años.Escolaridad: Titulo Universitario .Experiencia: 3 años en el cargo. En cargado de la administracion general del sistema y de la DB.

Secretaria de la CooperativaEdad: 28a 40 años.Escolaridad: Tecnologo o Titulo Universitario.Experiencia: 1 año en el cargo.Debe ingresar la informacion concerniente y requerida por el sistema.

Asesor Comercial de la CooperativaEdad: 30 a 50 años.Escolaridad: Técnico o Tecnólogo.Experiencia: 3 a 5 años en el cargo.Debe poder ver reportes que el sistema genere.

Asociado de la CooperativaEdad: 30 a 70 años.Debe por ver su informacion sobre creditos y aportes.


1.2 Diseño Centrado en el Usuario

La primera etapa consistió en hablar con el administrador, la secretaria y con un asesor, cada uno de ellos planteo como les gustaría que fuera la interacción, para ello cada uno realizó un boceto, posterior a eso se realizó una interfaz de menús horizontal y otra de menús vertical; sin embargó no fueron muy bien aceptados, ya que era muy similar al programa actual, y ellos querían algo más novedoso, las sugerencia fue realizar iconos que representaran la acti-vidad a realizar; fue así que surgió la idea de tener módulos; y en cada uno de ellos opciones asociada al módulo. Fue así que se llegó a obtener la página principal del sistema; luego de que el usuario se ha validado. Con este primer diseño se implementó el uso de la plantilla, la cual estaría en cada una de las distintas páginas del sistema.

Ilustración 20 Diseño página principal de SISINFOCOOP

En la ilustración anterior, se observa que cada módulo tiene una imagen representativa, el título del módulo y una descripción de las actividades que se pueden realizar. Este es el punto de partida para el diseño de la aplicación, donde se tuvo en cuenta al usuario, para que el diseño que se ajustara a los requerimientos y expectativas del usuario.

2 Estrategias de Diseño

Desde el inicio el patrón que se iba a regir el prototipo era el patrón MVC, donde se tiene separado los datos y la lógica de negocio de la interfaz de usuario. El talón de Aquiles fue como iba a ser la implementación de la vista, ya que se quería que la capa de presentación fuera uniforme en cada una de sus páginas y surge el concepto de plantilla, donde se tienen partes fijas y otras partes variables. Es así que se empezó la búsqueda de librerías para hacer paginas JSF (Java Server Faces), luego de una búsqueda intensiva sobre el desarrollo de páginas JSF se encontró el siguiente link http://www.jtech.ua.es/j2ee/publico/jsf-2012-13/se-sion01-apuntes.html donde se dan los primeros conceptos para el diseño de este tipo de pági-nas y surge el concepto de RIA (Rich Internet Applications). Fue aquí el punto de partida

Página 63

http://www.jtech.ua.es/j2ee/publico/jsf-2012-13/sesion01-apuntes.html

http://www.jtech.ua.es/j2ee/publico/jsf-2012-13/sesion01-apuntes.html


que permitió introducir el concepto de “Single Page” donde en una sola página podíamos hacer todas las operaciones CRUD de una entidad. Fue así que se llegó a implementar Prime-Faces como complemento para el desarrollo de la capa de presentación.

Con la implementación de PrimeFaces se tuvieron las siguientes características:

Un interesante conjunto de componentes (editor HTML, autocompletado, entre otras.)

Soporte para Ajax, basándose en el estándar JSF 2.2 Ajax API Sin dependencias, ni configuraciones, Múltiples temas de apariencia, listos para usar. La documentación, que se encuentra es bastante detalla. Amplia difusión del framework, con lo cual existe una comunidad que respalda al

proyecto y blogs donde se explican distintos procedimientos.

Para ampliar la información sobre las estrategias de diseño en la realización de las operacio -nes CRUD y demás información acerca del despliegue de la información a lo largo del proto-tipo se recomienda ver el anexo Manual_de_Mantenimiento.docx

2.1 Estrategia de diseño de Código y vista del prototipo

A continuación se presenta una fracción de código para mostrar una tabla con los datos y los botones de edición y eliminación; también se muestra otro componente del dataTable para la inserción de datos a la DB, este proceso fue llevado a cabo utilizando el tutorial de “JSF 2.2 Table CRUD Ajax Example”[87] disponible online en el link http://memorynotfound.com/jsf-2-2-table-crud-ajax-example/ ; adicionalmente se tuvieron en cuenta otros recursos online disponibles en los siguientes links:

http://jdevelopment.nl/sample-crud-app-with-jsf-and-richfaces/ http://memorynotfound.com/jsf-2-2-basic-ajax-example/ https://primefacesfacil.wordpress.com/2014/08/20/realizando-filtros-en-componente-

datatable-primefaces/ http://www.javacodegeeks.com/2013/11/using-jsf-2-2-features-to-develop-ajax-scro -

llable-lazy-loading-data-table.html

2.1.1 Código para edición y eliminación[87]<p:dataTable value="#{personaBean.listaPersonas}" id="tblPersona"

paginator="#{personaBean.listaPersonas.size() > 5}" rows="10"paginatorTemplate="{CurrentPageReport} {FirstPageLink} {PreviousPageLink}

{PageLinks} {NextPageLink} {LastPageLink} {RowsPerPageDropdown}" rowsPerPageTemplate="5,10,15" filteredVlue= "#{persona

Bean.listaPersonasFilter}"emptyMessage="No se han registrado personas" var="persona"> <p:column style="width:16px"> <p:rowToggler /> </p:column> <p:column sortBy="#{persona.tipoIdentificacion}" headerText="Tipo de identi

ficación"> <h:outputText value="#{persona.tipoIdentificacion}" />

Página 64

http://www.javacodegeeks.com/2013/11/using-jsf-2-2-features-to-develop-ajax-scrollable-lazy-loading-data-table.html

http://www.javacodegeeks.com/2013/11/using-jsf-2-2-features-to-develop-ajax-scrollable-lazy-loading-data-table.html

https://primefacesfacil.wordpress.com/2014/08/20/realizando-filtros-en-componente-datatable-primefaces/

https://primefacesfacil.wordpress.com/2014/08/20/realizando-filtros-en-componente-datatable-primefaces/

http://memorynotfound.com/jsf-2-2-basic-ajax-example/

http://jdevelopment.nl/sample-crud-app-with-jsf-and-richfaces/

http://memorynotfound.com/jsf-2-2-table-crud-ajax-example/

http://memorynotfound.com/jsf-2-2-table-crud-ajax-example/


</p:column> <p:column sortBy="#{persona.numeroDocumento}" fil

terBy="#{persona.numeroDocumento}" filterMatchMode="contains" headerText="No. Identificación"> <h:outputText value="#{persona.numeroDocumento}" />

<p:column headerText="Editar"><p:commandButton icon="ui-icon-pencil" update=":formPersona:tab" pro

cess="@this" action="#{personaBean.seleccionarParaEditar(persona)}" /></p:column><p:column headerText="Eliminar" rendered="#{p:ifGranted('Administrador')}"><p:commandButton icon="ui-icon-trash" update=":formPersona:tab, :formCon-

firm" action="#{personaBean.seleccionarParaEliminar(persona)}" process="@this :formPersona:tab:tblPersona" oncomplete="PF('confirmDlg').show()" />

</p:column>

Ilustración 21 Fracción de código para mostrar tabla con opciones de edición y elimina-ción

Ilustración 22 Resultado del datatable

2.1.2 Código para Crear[87]<p:fieldset id="fieldGeneral" styleClass="fieldSet" legend="Datos generales"> <h:panelGrid columns="4" style="margin: 0 auto; text-align: center;"> <h:outputLabel styleClass="label" value="Tipo de identificación:" />

<p:selectOneMenu style="width: 202px" id="tipoIde" va lue="#{personaBean.nuevaPersona.tipoIdentificacion}"

required="true" requiredMessage="Campo tipo de identifica ción requerido!">

<f:selectItem itemValue="" itemLabel="-- Seleccione un Tipo --" /><f:selectItems value="#{personaBean.tiposIdentificacion}" var="tipoI" itemVa

lue="#{tipoI.nemonico}" itemLabel="#{tipoI.nemonico}" /></p:selectOneMenu>

<h:outputLabel styleClass="label" value="No. Identificación:" /> <p:inputText styleClass="input" id="numDoc" val ue="#{personaBean.nuevaPersona.numeroDocumento}" required="true" maxlength="16" requiredMessage="Campo numero de identificación requerido" onkeypress="return aceptarNumeros(event);"> <p:ajax event="blur" listener="#{personaBean.buscarPersona}" upda te=":formPersona:tab" process="@this tipoIde, numDoc" /> </p:inputText> <p:commandButton update=":formPersona:tab" process="@this fieldGeneral" style="margin-top: 1em; margin-bottom: 1em" value="Guardar"

Página 65


rendered="#{!personaBean.editar}" action="#{personaBean.guardar}" /> <p:commandButton update=":formPersona:tab" process="@this fieldGeneral" style="margin-top: 1em; margin-bottom: 1em" value="Guardar"

rendered="#{personaBean.editar}" action="#{personaBean.editar}" /> <p:commandButton update=":formPersona:tab" process="@this" style="margin-top: 1em; margin-bottom: 1em" value="Cancelar" action="#{personaBean.inicializarPersona}" />

Ilustración 23 Fracción de código para mostrar campos inputText y outputLabel y po-derlos insertar a la DB

Ilustración 24 Resultado del componente fieldset

2.1.3 Generación de Reportes PDF y XLS

Para generar archivos PDF[88] (sigla del inglés Portable Document Format, “formato de documento portátil”); se tenía la opción de utilizar la librería de JasperReports[89], sin em-bargo se utilizó otro componente que ofrece PrimeFaces, este es el componente <pe:exporter>, el cual da la posibilidad de exportar los datos de formularios a archivos PDF o de tipo XLS para ser editados con la aplicación de Microsoft Excel[90]. Para utilizar este componente debe agregar la dependencia al descriptor pom.xlm así:

DataExporter (PDF)

<dependency><groupId>com.lowagie</groupId><artifactId>itext</artifactId><version>2.1.7</version>

</dependency>

DataExporter (Excel)

<dependency><groupId>org.apache.poi</groupId>

Página 66


<artifactId>poi</artifactId><version>3.12</version>

</dependency>

A continuación se observa una fracción de código, donde se utiliza el componente <pe:expor-ter>

<p:panel header="Exportar Reporte (PDF y Excel)"> <p:commandLink id="pdf" ajax="false"> <p:graphicImage library="images" name="pdf.png" /> <pe:exporter type="pdf" target="tblInforme,tblAsociado,tblTrxAporte" fileName="TransaccionesDeAporte" facetBackground="#34495E" facetFontColor="#FFFFFF" facetFontStyle="BOLD" cellFontSize="10" cell FontStyle="NORMAL" encoding="iso-8859-1" /> </p:commandLink> <p:commandLink id="xls" ajax="false"> <p:graphicImage library="images" name="excel.png" /> <pe:exporter type="xlsx" target="tblAsociado,tblTrxAporte" facetFontColor="#FFFFFF" facetFontStyle="BOLD" cellFontSize="10" cell FontStyle="NORMAL" fileName="TransaccionesDeAporte" facetBack-ground="#34495E" /> </p:commandLink> </p:panel>

El resultado de utilizar este componente, en la generación de un archivo PDF se muestra a continuación:

Página 67


Ilustración 25 Reporte en PDF

2.1.4 Búsqueda con el filtro filterBy

Las búsquedas por cualquiera de los parámetros, que previamente se establecieron en el le-vantamiento de requerimientos, y que fueron incluidos cuando se muestra la información en el formulario, se hacen a través del componente <filterBy> que ofrece PrimeFaces; la utiliza-ción de este filtro permite hacer la búsqueda en tiempo de ejecución, sobre la tabla, sin nece-sidad de hacer llamados al servidor y sin generar sentencias SQL. A continuación se muestra fracción del código y el diseño de la interfaz:

<p:column sortBy="#{persona.numeroDocumento}" fil terBy="#{persona.numeroDocumento}" filterMatchMo de="contains" headerText="No. Identificación"> <h:outputText value="#{persona.numeroDocumento}" /></p:column>

Ilustración 26 Código para utilizar filterBy

Página 68


Ilustración 27 Interfaz con el uso de filtros

2.2 Seguridad a las páginas y EJB´s

En esta sección se darán a conocer detalles sobre la implementación de seguridad utilizada en el prototipo; usando el estándar de JAAS[91] (Java Authentication and Authorization Servi-ce); JAAS es una interfaz que permite a las aplicaciones Java acceder a servicios de control de autenticación y acceso. La solución ha implementado seguridad a nivel de la capa web y de la capa de negocio, a continuación se darán a conocer las configuraciones realizadas en cada de una de las capas.

2.2.1 Seguridad en la capa web

En la fase de Autenticación el usuario envía al servidor su nombre y su password y el servi-dor comprueba contra la DB; si el usuario es válido o no .Una vez que el usuario ha sido vali-dado pasamos la segunda fase que es la fase de Autorización en la que se comprueba que el usuario tiene permisos para acceder a los recursos. En el standard de JAAS la fase de Autori-zación asociada a la gestión de roles. A continuación se muestra como el standard JAAS se encarga de definir los recursos y roles en la aplicación web. Para ello deberemos modificar el fichero web.xml y añadir etiquetas de seguridad.

<security-constraint> <web-resource-collection> <web-resource-name>seguridad</web-resource-name> <url-pattern>/faces/index.xhtml</url-pattern> <url-pattern>/faces/principal.xhtml</url-pattern> <url-pattern>/faces/pages/*</url-pattern> <http-method>POST</http-method> <http-method>GET</http-method> <http-method>PUT</http-method> <http-method>DELETE</http-method> </web-resource-collection> <auth-constraint> < role-name > Administrador </role-name> <role-name>Empleado</role-name> <role-name>Asesor</role-name> <role-name>Asociado</role-name> </auth-constraint></security-constraint>

Página 69


Ilustración 28 Etiquetas de seguridad en el descriptor web.xml

Como se observa en la anterior ilustración la etiqueta de <url-pattern> define que recursos son protegidos y la etiqueta <role-name> que roles tiene acceso a estos. Una vez realizada esta operación se da por terminada la fase de Autorización.

En el mismo descriptor web.xml se adicionan los 4 roles que se han establecido con anteriori-dad, El contenido de los campos <role-name> debe corresponder con el nombre de los perfi-les en base de datos.

<security-role> <role-name>Administrador</role-name></security-role> <security-role> <role-name>Empleado</role-name></security-role> <security-role> <role-name>Asesor</role-name></security-role><security-role> <role-name>Asociado</role-name></security-role>

Ilustración 29 Roles de la Aplicación

Ahora se define el método de autenticación (a través de formulario), la página de login y la página que aparecerá tras un error en el login.

<login-config> <auth-method>FORM</auth-method> <realm-name>cooperativa</realm-name> <form-login-config> <form-login-page>/faces/index.xhtml</form-login-page> <form-error-page>/faces/index.xhtml</form-error-page> </form-login-config></login-config>

Ilustración 30 Método de autenticación por formulario

Por último tenemos que hacer uso del componente rendered sobre las paginas XHTML; este permite mostrar u ocultar controles dependiendo del valor de una expresión de JSF, en este prototipo se utilizó este procedimiento para limitar el acceso a los botones de edición y elimi-nación dependiendo del rol. A continuación se muestra una fracción de código donde se apli-ca este concepto:<p:column headerText="Eliminar" rendered="#{p:if-Granted('Administrador')}"> <p:commandButton icon="ui-icon-trash" update=":formPersona:tab, :formConfirm" action="#{personaBean.seleccionarParaEliminar(persona)}" process="@this :formPersona:tab:tblPersona" oncom plete="PF('confirmDlg').show()" /></p:column>

Página 70


Ilustración 31 Uso del componente rendered

Como se observar en la anterior ilustración el componente rendered = "#{p:ifGranted('Admi-nistrador')}" indica que la columna “Eliminar” está disponible, si la sesión actual tiene el rol de “Administrador”. Otro ejemplo del uso de rendered es el siguiente:<p:panelGrid columns="6" rendered="#{p:ifGranted('Administrador') || p:ifGranted('Empleado') || p:ifGranted('Asesor')}"> <h:outputText styleClass="label" value="No. Identificación:" /> <p:inputText styleClass="input" value="#{reporteBean.numeroIdentificacion}" onkeypress="return aceptarNumeros(event);" maxlength="16" /> <h:outputText styleClass="label" value="Primer Nombre:" /> <p:inputText styleClass="input" value="#{reporteBean.primerNombre}" /> <h:outputText styleClass="label" value="Primer Apellido:" /> <p:inputText styleClass="input" value="#{reporteBean.primerApellido}" /></p:panelGrid>

Ilustración 32 Uso del componente rendered sobre un panelGrid

En la anterior ilustración se observa que si la sesión tiene el rol de Administrador, Empleado o Asesor tiene acceso al componente panelGrid y a los componentes que conforman el panel-Grid como los outputtext y los inputText.

2.2.2 Seguridad en la capa de negocio

Para mayor seguridad sobre el prototipo se realizó seguridad a los métodos Java sobre los EJB´s; con anotaciones en el código fuente, la ventaja de la anotación es que el código queda más claro y autocontenido se hizo uso de las siguientes anotaciones

Anotación Descripción

@DeclareRoles Específica los roles de seguridad asociado con el Bean.

@RolesAllowed Sólo los roles declarados en esta anotación podrán invocar el método. Se pueden espe-cificar los roles permitidos a nivel de clase o a nivel de método.

@PermitAll Permite la invocación por todos los roles definidos. Se puede especificar a nivel de clase o a nivel de método.

Ilustración 33 Anotaciones de seguridad utilizadas

Página 71


A continuación se observa fracciones de código donde se hace uso de las anotaciones ante -riormente descritas:

@RolesAllowed({"Administrador", "Empleado", "Asesor"}) public List<Credito> buscarTodos(){

Ilustración 34 Uso de la anotación @RolesAllowed

En la anterior ilustración se observa que el método buscarTodos() solamente podrá ser acce-dido si la sesión tiene el rol de Administrador, Empleado o Asesor.

@PermitAllpublic List<Ciudad> buscarTodas(){

Ilustración 35 Uso de la anotación @PermitAll

En la anterior ilustración se observa que el método buscarTodas() es accedido por todas las sesiones sin importar el rol.

@DeclareRoles({"Administrador", "Empleado", "Asesor", "Asociado"})public class DocumentoContableDao extends Generico <DocumentoContable> {

Ilustración 36 Uso de la anotación @DeclareRoles

En la anterior ilustración se observa que la clase DocumentoContableDao solamente podrá ser accedida si la sesión tiene el rol de Administrador, Empleado, Asesor, o Asociado.

@RolesAllowed("Administrador") public void eliminarPersona(Persona persona){

Ilustración 37 Uso de la anotación @RolesAllowed

En la anterior ilustración se observa que el método eliminarPersona() solamente podrá ser accedido si la sesión tiene el rol de Administrador.

Para ampliar la información sobre las estrategias aplicadas ver el anexo (Anexo 9. Ma-nual de Mantenimiento )

Página 72


3 Plan de Pruebas

El objetivo principal del Plan de Pruebas de Software del prototipo “SISINFOCOOP”, es describir los pasos a seguir para llevar a cabo la fase de pruebas sobre el producto , teniendo en cuenta la calidad que debe poseer los incrementos que se realicen para cumplir con el al -cance del producto.

Al desarrollar el plan de pruebas, se puede obtener información sobre los errores, defectos o fallas que tiene el prototipo, así se realizan las correcciones pertinentes, según el caso y se asegura la calidad del producto que se está entregando al cliente.

3.1 Estrategia de Pruebas

La estrategia del proceso del plan de pruebas se implementará de acuerdo al esquema de acti-vidades que se representa en la siguiente ilustración.

Ilustración 38 Actividades en la estrategia de pruebas

Página 73

Planificación

Diseño de las Pruebas

Ejecución

Evaluación


La ilustración anterior específica las actividades a seguir en el plan de pruebas, a continua-ción se explican las tareas a desarrollar en cada una de las actividades:

Proceso Descripción

Planificación Es importante la ejecución del plan de pruebas, haciendo necesario la pla-nificación.

Se definen los niveles de pruebas a aplicar. Se establece el tiempo para la ejecución de cada una de las pruebas. Uso de herramientas. Criterios de aceptación.

Diseño de las Pruebas Se tendrá en cuenta aspectos que permitan encontrar defectos en el ciclo de desarrollo, la realización de pruebas de verificación y validación de da-tos.

Ejecución Las pruebas se extienden a lo largo de todo el ciclo de vida del desarrollo, mientras se realizan las fases de requerimientos, análisis, diseño e imple-mentación se van diseñando las pruebas del mismo nivel. Que incluyen las pruebas unitarias hasta las pruebas funcionales. (ver ilustración 17 de procedimiento de ejecución)

Evaluación Se presentará un resultado donde se documentará el resultado de cada una de las diferentes pruebas ejecutas, que se llevará en la tabla de prue-bas en Excel.

Ilustración 39 Descripción de las actividades

Página 74


Ilustración 40 Procedimiento de Ejecución

Se asume que antes de probar cada componente habrá una revisión informal y solo el código que ha sido revisado y aceptado como exitoso será probado, se asume que el código es aquel que hace referencia al requerimiento. A continuación se describen las diferentes pruebas a ser aplicadas [1]:

TIPO DE PRUEBA DESCRIPCIÓN

UNITARIAS

INTEGRACIÓN

Unitarias: Permite verificar la funcionalidad y estructura de cada componente individualmente del sistema una vez que ha sido codificado e implementado.

Integración: Permite verificar el correcto ensamblaje entre los distintos módulos que componen el desarrollo.

NO FUNCIONALES:

Concurrencia, Interfaz de Usuario Rendimiento Integridad de las BD

Sistema: Estas pruebas buscan diferencias entre la solución desarrollada y los requerimientos, con el fin de identificar erro-res que se puedan generar entre la especificación funcional y el diseño del sistema.

Concurrencia: Valida la capacidad del sistema de atender múlti-ples solicitudes de parte de los usuarios que acceden a un mis-mo recurso.

Página 75

Ejecutar

Resultado

Comprobar

Evaluación de Resultados

Repetición Pruebas


Interfaz de usuario: Permite verificar que la navegación a través de los elementos que se están probando, reflejen las funciones del negocio y los requerimientos funcionales.

Rendimiento: Permite validar si la aplicación cumple los crite-rios de tiempos de respuesta establecidos.

Integridad de las bases de datos: Consiste en asegurar que los métodos y procesos de acceso a la base de datos funcionan correctamente y sin corromper datos.

FUNCIONALES Funcional: La prueba funcional es un proceso para procurar encontrar discrepancias entre el programa y la especificación funcional.

Usabilidad: Esta prueba permite encontrar problemas de facto-res humanos, o usabilidad.

ACEPTACIÓN

Es la prueba final basada en las especificaciones de la cooperati-va caso de estudio; quién determinará si acepta o no el produc-to hasta el momento.

Página 76


3.2 Artefactos de Prueba

3.2.1 Módulos del programa

Página 77


Página 78

Módulo Pruebas Descripción

Base de Datos Prueba de Sistema

Integridad de DB

Consiste en asegurar que los métodos y procesos de acceso a la base de da-tos funcionan correctamente y sin corromper datos.

Iniciar Sesión y Cerrar Sesión Prueba Funcional Las pruebas funcionales serán realiza-das para verificar que todos los reque-rimientos funcionales se cumplen satisfactoriamente.

Módulo de Seguridad Prueba Funcional Las pruebas funcionales serán realiza-das para verificar que todos los reque-rimientos funcionales se cumplen satisfactoriamente.

Módulo de Administración Prueba Funcional Consiste en validar que los métodos y procesos funcionan correctamente con base al requerimiento

Módulo de Asociados Prueba Funcional Consiste en validar que los métodos y procesos funcionan correctamente con base al requerimiento

Módulo de Crédito Prueba Funcional Consiste en validar que los métodos y procesos funcionan correctamente con base al requerimiento.

Módulo de Transacciones Prueba Funcional Consiste en validar que los métodos y procesos funcionan correctamente con base al requerimiento.

Módulo de Reportes Prueba Funcional Consiste en validar que los métodos y procesos funcionan correctamente con base al requerimiento.

Interfaz GUI Prueba Funcional

Usabilidad

Prueba de Sistema

Interfaz de usuario

Las pruebas de interfaz de usuario verifican la interacción del usuario con el software. El objetivo de las pruebas de la interfaz de usuario es asegurar que dicha interfaz proporciona al usuario el acceso y la navegación apropiados a través de las funcionali-dades del elemento objetivo de la prueba.

Requerimientos No Funciona-les

Prueba Funcional

Concurrencia Interfaz de Usuario Rendimiento Integridad de las BD

La prueba funcional es un proceso para procurar encontrar discrepancias entre el programa y la especificación no funcional.


3.2.2 Características que NO serán probadas

Característica Descripción Módulos

Requerimientos No Funcio-nales

Verificar que lo que exige el requerimiento, cumple con el criterio de aceptación. Las pruebas no funcionales incluyen pruebas de rendi-miento, de usabilidad, man-tenibilidad, fiabilidad y por-tabilidad.

No realizara verificación a los requerimientos No fun-cionales (Ver Anexo: Tabla de Requerimientos)

Requerimientos Funciona-les

No se realizara pruebas de ningún tipo a los requeri-mientos de baja prioridad

Se no realizara verificación a los requerimientos No fun-cionales con baja prioridad (Ver Anexo: Tabla de Re-querimientos)

Ilustración 41 Características que no serán probadas

3.3 Resultados de las pruebas

Al finalizar el desarrollo del prototipo “SISINFOCOP”, se hicieron pruebas funcionales, pruebas de integridad y pruebas de aceptación de la plataforma web, este registro está debi -damente detallado en el archivo designado para tal fin. (Ver anexo Tabla pruebas de código. -xls)

4

Página 79


VI – RESULTADOS

1 Pruebas

SISINFCOOP, fue evaluado mediante los siguientes tipos de prueba y sus resultados están debidamente tabulados en la tabla de pruebas (Ver anexo: Pruebas), las cuales fueron realiza-das por el líder de desarrollo. Y se dividieron en dos tipos de pruebas:

Unitarias Integración Aceptación

Para las pruebas unitarias se miró el inventario de casos de uso y se aplicaba a cada módulo que componía al sistema 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 para cumplir con las pruebas de integración, estas pruebas se realizaban a medida que se realizaba un incremento.

Los resultados de la validación se encuentran en los siguientes anexos:

Anexo 12. Plan de Pruebas Anexo 17. Encuestas de Satisfacción

2 Validación del Prototipo

SISINFOCOOP, se validó en las instalaciones de la Cooperativa el día 11 de noviembre del 2015; para esta reunión se contó con la presencia de empleados de la cooperativa y miembros administrativos.

Proceso donde se analizaron los distintos casos de uso, en especial los casos de uso de nego-cio, que eran los más sensibles a errores u omisiones, sin embargo la lógica de negocio fue muy bien concebida motivo por el cual fue validado sin contratiempos.

Dentro del proceso de validación, se encontraron fallas como el manejo de excepciones, cam-pos que no estaban siendo validados como la fecha de nacimiento, campo de identificación único, los datos de usuario y password para los asociados eran opcionales, entre otras valida-ciones; estas fueron corregidas en su momento y están contempladas dentro del código dispo-nible para descarga.

El modulo que más llamo la atención fue el de reportes, ya que se puede exportar la informa-ción a un archivo PDF o XLS, y el caso de uso más llamativo fue el de un asociado que ingre-sa al sistema y solo ve información de aporte y crédito de él.

Página 80


Los resultados de la validación se encuentran en los siguientes anexos:

Anexo 12. Plan de Pruebas Anexo 17. Encuestas de Satisfacción

Página 81


VI – CONCLUSIONES

1 Análisis de Impacto del Desarrollo

Los Sistemas de Información, han cambiado la forma en que operan las organizaciones actua-les llámense Empresas, Pymes o Cooperativas entre otras formas de asociación. A través de su uso se logran importantes mejoras, pues automatizan los procesos operativos, suministran una plataforma de información necesaria para la toma de decisiones y su implantación logra ventajas competitivas o en su defecto se reduce la ventaja frente a los competidores.

La información se ha colocado en un buen lugar como uno de los principales recursos que poseen las empresas actualmente. Los entes que se encargan de las tomas de decisiones han comenzado a comprender que la información, alimenta a los negocios y puede ser uno de los tantos factores críticos que pueden determinar el éxito o fracaso.

SISINFOCOOP, fue desarrollado tomando los lineamientos que la disciplina de la ingeniería de sistemas, ofrece en la construcción de software; herramientas base para que el producto en mención cumpliera con las expectativas de la Cooperativa caso de estudio; con el seguimien-to de estos lineamientos se cumplió con el objetivo de ofrecer un sistema de información que pudiera realizar las actividades de:

Entrada de información. Almacenamiento de información. Procesamiento de la información. Salida de información.

Adicionalmente con el seguimiento constante de la metodología propuesta XP, se pudo desa-rrollar un producto de calidad que puede ser modificado y mejorado por su alta modularidad en el corto y largo plazo.

SISINFOCOOP, como sistema de información puede incrementar y maximizar la utilidad de las cooperativas de aporte y crédito, ya que al tener un manejo adecuado a la información, los administradores podrán responder de manera más rápida a las necesidades de los asociados, obteniendo valores agregados al core del negocio, que se verían reflejados en el aumento de sus activos y en el aumento de su cartera.

SISINFOCOOP, como sistema de información, permitió la reducción de tiempos, ya que permite la obtención de la información del Asociado, de la cuenta de aporte y/o de los crédi-tos del asociado en tiempo real, sin necesidad de ir a los documentos físicos, ya que el siste -ma tiene la información completa y relevante que la Cooperativa requiere en determinado momento; adicionalmente el proceso de realizar transacciones sobre una cuenta de aporte o sobre un crédito esta automatizado permitiendo al usuario realizarla de forma sencilla y ágil, sobre una cuenta de aporte o varias al mismo tiempo, igualmente sucede sobre un crédito o varios sin necesidad de repetir transacciones iguales. A simple vista este proceso recude el tiempo para el usuario, ya que no necesita realizar procesos manuales como buscar el docu-mento físico para obtener algún dato.

Página 82


SISINFOCOOP, como sistema de información tiene un impacto indirecto sobre lo social, porque a través de las cooperativas, al tener más accesible a la información de sus asociados, pueden crear nuevos servicios para sus asociados; para que ellos puedan suplir las necesida-des que tengan en un determinado momento. Y así cumplir con uno de los principios coope-rativos que es el “compromiso con la comunidad”.

2 Cumplimiento de los Objetivos

SISINFOCOOP, cumplió con el alcancé y con cada uno de los objetivos específicos propues-tos (Ver Sección 5 Descripción Del Proyecto); con la metodología seleccionada, se siguieron una serie de pasos donde se da cumplimiento al objetivo, a continuación se describen los pasos que otorgaron el cumplimiento de estos:

a. Para dar cumplimiento al primer objetivo específico (Identificar el contexto actual de la administración de la información de la Cooperativa), se realizó un análisis de las Cooperativas con sección de aporte y crédito; para identificar la problemática sobre las deficiencias en la utilización de los sistemas de información y/o carencias de estos en el manejo adecuado de la información. El resultado fue obtener las causas que generaban la problemática en la Cooperativa caso de estudio (Ver Sección 1 Oportu-nidad, Problemática, Antecedentes)

b. Para dar cumplimiento al segundo objetivo específico (Levantar Requerimientos en este tipo de Cooperativas, que el sistema debe cumplir), se realizó un proceso de levantamiento de los requerimientos que la cooperativa caso de estudio necesitaba que fueran incluidos en el prototipo, estos requerimientos fueron asociados a cada uno de los casos de uso, para ello se realizó un inventarió de estos mismos. El resul-tado fue la obtención de un inventario de casos de uso y dentro de estos una serie de requerimientos que la Cooperativa caso de estudio requeria. (Ver Anexo Inventario-CasoUsos.xls)

c. Para dar cumplimiento al tercer objetivo específico (Implementar el prototipo funcio-nal del sistema, que incluye análisis, diseño y desarrollo del prototipo), se procedió con el diseño, análisis y desarrollo del prototipo, para ello se realizó la arquitectura del prototipo, donde se formalizaron los diagramas de contexto, overview, lógica del sistema y vista física del sistema, estos fueron el soporte para el desarrollo del proto-tipo.

d. Para dar cumplimiento al cuarto y último objetivo específico (Validar el sistema de información en la Cooperativa), se realizaba en cada una de las distintas iteraciones la validación del incremento con la Cooperativa caso de estudio, en estas validacio-nes se llevaron a cabo las pruebas unitarias y de integración a medida que se cons-truía el prototipo. El resultado de cada una de estas pruebas se encuentran debida-

Página 83


mente descritas en la plantilla utilizada para tal fin (Ver Anexo_PruebasCasosUso.-xls).

Estos son los pasos que otorgaron el cumplimiento de cada uno de los objetivos específicos.

3 Conclusiones y Trabajo Futuro

Una vez más, se demuestra la importancia de la planeación, en el desarrollo de un proyecto; es clave definir los lineamientos bajo los cuales el proyecto se va a realizar de no ser así, es posible que el resultado no sea el esperado.

SISINFOCOOP, fue concebido como un sistema de información, para que las cooperativas de aporte y crédito; automatizaran algunos de sus procesos ayudando a sus administradores en la toma de decisiones; y a partir que estos nuevos procesos disminuyeran los tiempos en la realización de cada uno de los procesos, donde más se notó la disminución o el ahorro en tiempo, fue en el proceso de registro de transacciones ya que paso de una forma manual don-de se digitaba número de documento, numero de crédito, a una forma automática donde con un solo clic se hacia el mismo proceso, disminuyendo la realización de este proceso, cabe resaltar que no se analizaron técnicamente los análisis de tiempos y movimientos.

Con el objetivo de desarrollar el prototipo, se realizó inicialmente el proceso de Ingeniería de Requerimientos. Esto se hizo partiendo de las necesidades particulares de la Cooperativa caso de estudio, las cuales fueron identificadas en las reuniones que se mantuvieron a lo largo del periodo Julio – Noviembre de 2015. A la par con este trabajo, se realizó una indagación de las herramientas que más se adaptaban para la realización de este tipo de aplicaciones; luego de establecer las necesidades y las herramientas seleccionadas, se diseñó la arquitectura del pro-totipo. Esto permitió el detalle y definición de los casos de uso, que constituyen las funciona-lidades del mismo.

Finalmente, se implementó el prototipo funcional, el cual mediante cada uno de los módulos previamente definidos, y para cada uno de los roles asignados, permite desarrollar distintas operaciones dentro de la aplicación. Al prototipo se le realizó la verificación, por medio de pruebas funcionales y de integración. La validación del prototipo se realizó a través de prue-bas de aceptación para un grupo de usuarios de la cooperativa caso de estudio.

Una de las ventajas de SISINFOCOOP es que su arquitectura permite la escalabilidad con respecto a extender nuevo módulos o funcionalidades como se detalla en la sección de traba-jos futuros.

Un punto importante sobre el desarrollo e implementación de este sistema, fue el hecho de poder realizar unas pruebas sobre datos reales, con usuarios de la cooperativa caso de estudio y asociados. Esto permitió evaluar el impacto del prototipo sobre los procesos de negocio.

Página 84


Las herramientas de desarrollo, las librerías y frameworks que se utilizaron fueron importan-tes dentro del desarrollo de SISINFOCOOP, la selección adecuada de las herramientas permi-tió que no se tuvieran atrasos importantes durante la ejecución del plan de desarrollo.

Sin embargo esta selección de estas herramientas no fue fácil, ya que en el mercado se en-cuentra gran variedad de herramientas que pueden ofrecer similitud de opciones de desarro-llo. Gracias a esta elección de la metodología XP y de las herramientas de desarrollo se pue-do lograr el objetivo general de este trabajo de grado. Adicionalmente los incrementos o itera-ciones permitieron un constante ajuste, que se recibían de las retroalimentaciones para ofrecer un producto que satisficiera los requerimientos de la Cooperativa caso de estudio.

Por último se demuestra que es posible desarrollar aplicaciones con calidad y con diseño centrado en el usuario; con el prototipo se logró demostrar que es posible tener sistemas de información a la medida.

Como trabajo futuro, SISINFOCOOP puede ser extendido en sus funcionalidades, dentro de estas tenemos las siguientes:

Cargue de información, mediante archivos planos. Ejecución de tareas por lotes o modo batch. Web service para conectarse con la parte contable. Implementación de la API JMS, para implantar tareas asincrónicas periódicas. Seguridad de la Información. Log de Operaciones. Generación de archivos planos, según requerimientos de cada pagaduría y proveedor. Extender el aplicativo, para que trabaje con diferentes sistemas como nomina, conta-

bilidad y demás.

Página 85


IV- REFERENCIAS Y BIBLIOGRAFÍA

[1] “WildFly Homepage · WildFly”. [En línea]. Disponible en: http://wildfly.org/. [Accedi-do: 06-oct-2015].

[2] “Formación BDI TI Java EE7 - Weld CDI, JSF2, EJB3 y JPA2 Capacitación de Nuevas Tecnologías de Información”. [En línea]. Disponible en: http://www.bolsadeideas.com/java-ee7-weld-cdi-jsf2-ejb3-y-jpa2.html. [Accedido: 09-oct-2015].

[3] “PrimeFaces”. [En línea]. Disponible en: http://primefaces.org/. [Accedido: 04-oct-2015].

[4] “iText, Programmable PDF software | iText Software”. [En línea]. Disponible en: http://itextpdf.com/. [Accedido: 13-nov-2015].

[5] B. Gates y J. A. Bravo, Los negocios en la era digital. Plaza & Janés, 1999.

[6] “Con la aplicación en TIC tendremos en Colombia empresas más competitivas”. [En línea]. Disponible en: http://www.edatel.com.co/empresas/blog-empresas/414-con-la-aplicacion-en-tic-%20%20%20%20%20tendremos-en-colombia-empresas-mas-competi-tivas. [Accedido: 10-ago-2015].

[7] “AcoplarJavaEE6JavaFX2.pdf”. .

[8] A. Goncalves, Beginning Java EE 6 with GlassFish 3. Apress, 2010.

[9] “Introducción a JavaServer Faces”. [En línea]. Disponible en: http://www.jtech.ua.es/j2ee/publico/jsf-2012-13/sesion01-apuntes.html#Especificaciones+de+JSF. [Accedido: 28-may-2015].

[10]“EVA1.pdf”. .

[11]Sena, “CLASIFICACIÓN DE LAS COOPERATIVAS | banrepcultural.org”. [En línea]. Disponible en: http://www.banrepcultural.org/node/66199. [Accedido: 20-mar-2015].

[12]“Normatividad colombiana | Ascoop”. .

[13]R. E. Gaitán, Administración de riesgos E R M y la auditoria interna. ECOE EDICIONES, 2006.

[14]“Aspectos prácticos”. [En línea]. Disponible en: http://www.confecoop.coop/index.php/cooperativismo/aspectos-practicos. [Accedido: 08-mar-2015].

[15]“Supersolidaria”. [En línea]. Disponible en: http://www.supersolidaria.gov.co/. [Acce-dido: 13-nov-2015].

Página 86


[16]“IEEE SA - 16326-2009 - ISO/IEC/IEEE International Standard Systems and Software Engineering--Life Cycle Processes--Project Management”. [En línea]. Disponible en: https://standards.ieee.org/findstds/standard/16326-2009.html. [Accedido: 15-jul-2015].

[17]“IEEE SA - 1016-2009 - IEEE Standard for Information Technology--Systems Design--Software Design Descriptions”. [En línea]. Disponible en: https://standards.ieee.org/find-stds/standard/1016-2009.html. [Accedido: 18-nov-2015].

[18]“IEEE SA - 830-1998 - IEEE Recommended Practice for Software Requirements Speci-fications”. [En línea]. Disponible en: https://standards.ieee.org/findstds/standard/830-1998.html. [Accedido: 18-nov-2015].

[19]“ISO 13407:1999 - Human-centred design processes for interactive systems”. [En línea]. Disponible en: http://www.iso.org/iso/catalogue_detail.htm?csnumber=21197. [Acce-dido: 16-nov-2015].

[20]O. Pastor y J. C. Molina, Model-Driven Architecture in Practice: A Software Production Environment Based on Conceptual Modeling. Springer Science & Business Media, 2007.

[21]I. Sommerville y M. I. A. Galipienso, Ingeniería del software. Pearson Educación, 2005.

[22]J. Highsmith, Adaptive Software Development: A Collaborative Approach to Managing Complex Systems. Pearson Education, 2013.

[23]R. C. Martin, Agile Software Development: Principles, Patterns, and Practices. Pearson Education, 2003.

[24]“Programación Extrema (XP) - Aprende a Programar - Codejobs”. [En línea]. Disponible en: http://www.codejobs.biz/es/blog/2013/06/05/programacion-extrema-xp#sthash.gmI-IUToG.XWonZc9M.dpbs. [Accedido: 27-abr-2015].

[25]W. S. Humphrey, “The personal software process (PSP)”, 2000.

[26]“¿Cómo afecta el impacto de la tecnología a la pyme?”, Diseño Web Alicante Diseño Web Madrid. [En línea]. Disponible en: http://www.digiworks.es/blog/2012/03/12/como-afecta-el-impacto-de-la-tecnologia-a-la-pyme/. [Accedido: 29-abr-2015].

[27]“5_Plan_Nacional_de_CTI.pdf”. .

[28]“Analfabetismo tecnológico afecta productividad de pymes”, Portafolio.com.co. [En línea]. Disponible en: http://www.portafolio.co/economia/analfabetismo-tecnologico-afecta-productividad-pymes. [Accedido: 29-abr-2015].

[29]R. Malhotra y C. Temponi, “Critical Decisions for ERP Integration: Small Business Is -sues”, Int J Inf Manag, vol. 30, no 1, pp. 28–37, feb. 2010.

Página 87


[30]“SICOOPWEB”. [En línea]. Disponible en: http://www.jorjweb.com/index.php/modulos-basicos/cartera. [Accedido: 21-mar-2015].

[31]“SAFIX”. [En línea]. Disponible en: http://www.xenco.com.co/producto/safix. [Accedi-do: 21-mar-2015].

[32]“Portal OpenErp (Odoo) en España.”, Odoo - OpenERP - ERP, CRM, MRP, SGA 100% Libre - | Sin Licencias. [En línea]. Disponible en: http://openerpspain.com/. [Accedido: 17-may-2015].

[33]“Home | ADempiere”. [En línea]. Disponible en: http://adempiere.org/site/. [Accedido: 21-nov-2015].

[34]“Bancóldex • Banco de desarrollo empresarial • Clasificación de empresas en Colombia”. [En línea]. Disponible en: http://www.bancoldex.com/Sobre-microempresas/Clasifica-cion-de-empresas-en-Colombia315.aspx. [Accedido: 05-may-2015].

[35]S. N. Padhi, SAP® ERP Financials and FICO Handbook. Jones & Bartlett Learning, 2009.

[36]“Definición Tamaño Empresarial Micro, Pequeña, Mediana o Grande”. .

[37]“Arquitectura de Software: Spring V.S. Java EE”. [En línea]. Disponible en: http://elblo-gdelfrasco.blogspot.com.co/2012/07/spring-vs-java-ee.html. [Accedido: 06-oct-2015].

[38]A. Goncalves, Beginning Java EE 7. Apress, 2013.

[39]“PrimeFaces”. .

[40]“Sobre PostgreSQL | www.postgresql.org.es”. .

[41]“WildFly Homepage · WildFly”. .

[42]“Java Platform, Enterprise Edition: The Java EE Tutorial Release 7 - Contents”. [En línea]. Disponible en: https://docs.oracle.com/javaee/7/tutorial/. [Accedido: 06-oct-2015].

[43]“Enterprise JavaBeans Technology”. [En línea]. Disponible en: http://www.oracle.com/technetwork/java/javaee/ejb/index.html. [Accedido: 06-oct-2015].

[44]“PostgreSQL: File Browser”. [En línea]. Disponible en: http://www.postgresql.org/ftp/source/v9.3.0/. [Accedido: 16-jul-2015].

[45]“Sobre PostgreSQL | www.postgresql.org.es”. [En línea]. Disponible en: http://www.pos-tgresql.org.es/sobre_postgresql. [Accedido: 10-oct-2015].

Página 88


[46]“Apuntes de Java: Tutorial JavaServer Faces 2.2 - Java EE 7 - Sesión 1”. [En línea]. Dis-ponible en: http://www.apuntesdejava.com/2013/09/tutorial-javaserver-faces-22-java-ee-7.html. [Accedido: 06-oct-2015].

[47]“JPA 2.1 Overview - 12 features every developer should know”, Thoughts on Java. [En línea]. Disponible en: http://www.thoughts-on-java.org/jpa-21-overview/. [Accedido: 06-oct-2015].

[48]“Maven – Welcome to Apache Maven”. [En línea]. Disponible en: https://maven.apa-che.org/. [Accedido: 06-oct-2015].

[49]“Using Ajax with JavaServer Faces Technology - The Java EE 6 Tutorial”. [En línea]. Disponible en: http://docs.oracle.com/javaee/6/tutorial/doc/gkiow.html. [Accedido: 06-oct-2015].

[50]“Activate Office 2010”. [En línea]. Disponible en: https://support.office.com/en-us/arti-cle/Activate-Office-2010-1fe7340c-50e2-458f-8677-f57f5a140f46. [Accedido: 16-jul-2015].

[51]“Project Management Software | Microsoft Project”. [En línea]. Disponible en: https://products.office.com/en-us/project/project-and-portfolio-management-software. [Accedi-do: 27-abr-2015].

[52]“Eclipse Downloads”. [En línea]. Disponible en: https://eclipse.org/downloads/. [Accedi-do: 15-jul-2015].

[53]“Eclipse Downloads”. [En línea]. Disponible en: https://eclipse.org/downloads/. [Acce-dido: 16-nov-2015].

[54]“UML tools for software development and modelling - Enterprise Architect UML model-ing tool”. [En línea]. Disponible en: http://www.sparxsystems.com.au/. [Accedido: 16-jul-2015].

[55]“Bizagi - Business Process Management (BPMS) and Workflow software”. [En línea]. Disponible en: http://www.bizagi.com/. [Accedido: 16-jul-2015].

[56]“Zotero | Home”. [En línea]. Disponible en: https://www.zotero.org/. [Accedido: 15-jul-2015].

[57]“Trello”. [En línea]. Disponible en: https://trello.com/. [Accedido: 15-jul-2015].

[58]M. E. Davis y J. A. Phillips, Learning PHP & MySQL: Step-by-Step Guide to Creating Database-Driven Web Sites. O’Reilly Media, Inc., 2007.

[59]Ballard, Phil, Ajax, JavaScript y PHP, 1st ed. Ediciones Anaya Multimedia.

Página 89


[60]A. S. M. Kom (Amikom Yogyakarta), Ajax Membangun Web dengan Teknologi Asyn-chronouse JavaScript&XML. Penerbit Andi.

[61]“Introducción a JavaServer Faces”. .

[62]A. A. Castillo, Curso de Programación Web. Javascript, Ajax y jQuery: 2015.

[63]Desarrollo Web con JSP. 2002.

[64]S. L. Mora, Programación de aplicaciones web: historia, principios básicos y clientes web. Editorial Club Universitario, 2002.

[65]J. J. Garrett, “Ajax: A New Approach to Web Applications | Adaptive Path”. .

[66]“Servidores de aplicaciones”. [En línea]. Disponible en: http://www.jtech.ua.es/j2ee/2003-2004/abierto-j2ee-2003-2004/sa/sesion1-apuntes.htm. [Accedido: 08-oct-2015].

[67]“46-mvc.pdf”. .

[68]“El servidor de aplicaciones - Oracle WebLogic Server | Oracle LATAM”. [En línea]. Disponible en: http://www.oracle.com/lad/products/middleware/cloud-app-foundation/weblogic/overview/index.html. [Accedido: 08-oct-2015].

[69]“IBM - WebSphere Application Server”. [En línea]. Disponible en: http://www-03.ibm.-com/software/products/es/appserv-was. [Accedido: 08-oct-2015].

[70]“OW2 JOnAS - JOnAS”. [En línea]. Disponible en: http://jonas.ow2.org/xwiki/bin/view/Main/. [Accedido: 08-oct-2015].

[71]“GlassFish Server”. [En línea]. Disponible en: https://glassfish.java.net/. [Accedido: 08-oct-2015].

[72]“Most popular Java EE containers: 2015 edition – Plumbr”. [En línea]. Disponible en: https://plumbr.eu/blog/java/most-popular-java-ee-containers-2015-edition. [Accedido: 08-oct-2015].

[73]R. Raya, “¿Qué son las metodologías ágiles?”, LeanMonitor Blog. .

[74]P. Letelier y M. C. Penadés, “Métodologías ágiles para el desarrollo de software: eXtre -me Programming (XP)”, www.cyta.com.ar/ta0502/v5n2a1.htm, 15-abr-2006. [En línea]. Disponible en: http://www.cyta.com.ar/ta0502/v5n2a1.htm. [Accedido: 14-jul-2015].

[75]K. Schwaber y M. Beedle, Agile Software Development with Scrum. Pearson Education International, 2008.

[76]J. Stapleton, DSDM, Dynamic Systems Development Method: The Method in Practice. Addison-Wesley, 1997.

Página 90


[77]P. Coad, E. Lefebvre, y J. De Luca, Java Modeling in Color with UML: Enterprise Com-ponents and Process. Prentice Hall PTR, 1999.

[78]M. Poppendieck y T. Poppendieck, Lean Software Development: An Agile Toolkit. Addi-son-Wesley, 2003.

[79]K. Beck y C. Andres, Extreme Programming Explained: Embrace Change. Pearson Edu-cation, 2004.

[80]J. A. Highsmith, Agile Software Development Ecosystems. Addison-Wesley, 2002.

[81]Programación con ASP.NET. 2002.

[82]U. Staff, Desarrollador .NET. Usershop.

[83]“Introducción a .NET Framework”. [En línea]. Disponible en: https://msdn.microsoft.-com/es-es/library/hh425099(v=vs.110).aspx. [Accedido: 16-nov-2015].

[84]“javaee7-whitepaper-1956203.pdf”. .

[85]S. Jacobs, Beginning XML with DOM and AJAX from novice to professional. Apress, 2006.

[86]“Informe APEI sobre Usabilidad : Diseño Centrado en el Usuario (DCU)”. [En línea]. Disponible en: http://www.nosolousabilidad.com/manual/3.htm. [Accedido: 16-nov-2015].

[87]MemoryNotFound, “JSF 2.2 Table CRUD Ajax Example”, Memory Not Found. [En línea]. Disponible en: http://memorynotfound.com/jsf-2-2-table-crud-ajax-example/. [Accedido: 16-nov-2015].

[88]“Archivos PDF, formato de documento portátil de Adobe | Adobe Acrobat DC”. [En línea]. Disponible en: https://acrobat.adobe.com/la/es/products/about-adobe-pdf.html. [Accedido: 16-nov-2015].

[89]“Jaspersoft Community”, Jaspersoft Community. [En línea]. Disponible en: http://com-munity.jaspersoft.com/. [Accedido: 16-nov-2015].

[90]“Programas de software de hoja de cálculo | Prueba gratuita de Excel”. [En línea]. Dispo-nible en: https://products.office.com/es/excel. [Accedido: 16-nov-2015].

[91]“JAAS Reference Guide”. [En línea]. Disponible en: http://docs.oracle.com/javase/7/docs/technotes/guides/security/jaas/JAASRefGuide.html. [Accedido: 17-nov-2015].

[92]“Aspectos prácticos”. .

Página 91


IV – ANEXOS

Los siguientes documentos forman parte de los anexos y se encuentran disponibles en la pági-na del presente trabajo de grado en el siguiente link http://pegasus.javeriana.edu.co/~CIS1530AP01/ :

Anexo 1. Glosario

Definiciones de términos que se utilizan a lo largo del presente trabajo de grado.

Anexo 2. Diagrama de Entidades

Este anexo contiene el diagrama de entidades del prototipo SISINFOCOOP.

Anexo 3. Requerimientos del Prototipo

Este anexo contiene la plantilla de los requerimientos Funcionales y No Funcionales del pro-totipo SISINFOCOOP.

Anexo 4. Inventario de Módulos y Casos de Uso

Este anexo contiene la plantilla del inventario de módulos y casos de uso del prototipo SISINFOCOOP.

Anexo 5. SPMP

Documento Software Project Management Plan.

Anexo 6. SRS

Documento Software Requirement Specification

Anexo 7. SDDDocumento Software design description

Anexo 8. Manual de Instalación

Este anexo contiene el manual de instalación del prototipo SISINFOCOOP.

Anexo 9. Manual de Mantenimiento

Este anexo contiene el manual de mantenimiento del prototipo SISINFOCOOP.

Página 92

http://pegasus.javeriana.edu.co/~CIS1530AP01/

http://pegasus.javeriana.edu.co/~CIS1530AP01/


Anexo 10. Manual de Usuario

Este anexo contiene el manual de usuario del prototipo SISINFOCOOP.

Anexo 11. Código del Prototipo

Archivo con extensión rar que contiene el código del prototipo SISINFOCOOP.

Anexo 12. Plan de Pruebas

Este anexo contiene el plan de pruebas realizadas sobre el prototipo SISINFOCOOP.

Anexo 13. Cronograma

Este anexo el cronograma que se siguió durante el desarrollo del prototipo SISINFOCOOP.

Anexo 14. Actas

Este anexo contiene las actas, que se realizan con cada uno de los incrementos con la Coope-rativa caso de estudio.

Anexo 15. Herramientas de Desarrollo

Archivo con extensión rar que contiene los instaladores de las herramientas de desarrollo.

Anexo 16. Archivos EAR

Archivo con extensión rar con el ear del prototipo.

Anexo 17. Encuestas de Satisfacción

Documento con extensión .rar con archivos digitalizados con las encuestas realizadas.

Anexo 18. Propuesta trabajo de Grado

Documento con la propuesta del trabajo de grado.

Anexo 19. Poster

Imagen del poster.

Página 93

propuesta para trabajo de grado - trabajos de grado de …... uno de ellos es sap, el cual ofrece...

Documents