UNIVERSIDAD DE GUAYAQUILrepositorio.ug.edu.ec › bitstream › redug › 11494 › 1 › PTG-B-CISC...VII CERTIFICADO DE ACEPTACIÓN DEL TUTOR En mi calidad de Tutor del proyecto

UNIVERSIDAD DE GUAYAQUIL

FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS

CARRERA DE INGENIERÍA EN SISTEMAS

COMPUTACIONELES

ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA "FRAMEWORK DE TRABAJO PARA PROYECTOS DE TITULACIÓN APLICANDO

METODOLOGÍA SCRUM EN LA INGENIERÍA DE SOFTWARE" ENFOCADO A LA ARQUITECTURA CAPA DE NEGOCIO DESARROLLANDO UN MODELO ENTIDAD RELACIÓN

QUE PERMITA SOPORTAR Y CONFIGURAR PROCEDIMIENTOS ALMACENADOS

PARA SU EJECUCIÓN DESDE UN SERVICIO

WEB

PROYECTO DE TITULACIÓN

Previa a la obtención del Título de:

INGENIERO EN SISTEMAS COMPUTACIONALES

AUTOR: ADOLFO ENRIQUE SOTOMAYOR SÁNCHEZ

TUTOR: LSI OSCAR OMAR APOLINARIO ARZUBE

GUAYAQUIL – ECUADOR 2015

REPOSITORIO NACIONAL EN CIENCIAS Y TECNOLOGÍA

FICHA DE REGISTRO DE TESIS

TÍTULO “ ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA "FRAMEWORK DE TRABAJO PARA

PROYECTOS DE TITULACIÓN APLICANDO METODOLOGÍA SCRUM EN LA INGENIERÍA DE

SOFTWARE" ENFOCADO A LA ARQUITECTURA CAPA DE NEGOCIO DESARROLLANDO UN MODELO

ENTIDAD RELACIÓN QUE PERMITA SOPORTAR Y CONFIGURAR PROCEDIMIENTOS

ALMACENADOS PARA SU EJECUCIÓN DESDE UN SERVICIO WEB”

REVISORES: ING. JORGE CHICALA LCD. PABLO ALARCON

INSTITUCIÓN: Universidad De Guayaquil FACULTAD: Ciencias Matemáticas Y Físicas

CARRERA: Ingeniería En Sistemas Computacionales

FECHA DE PUBLICACIÓN: Noviembre del 2015 N° DE PÁGS.: 124

ÁREA TEMÁTICA: METODOLOGÍAS, CALIDAD Y GESTIÓN DE PROYECTOS DE SOFTWARE

PALABRAS CLAVES: FRAMEWORK, SCRUM, MODELO ENTIDAD RELACIÓN, PROCEDIMIENTO ALMACENADO, SERVICIO WEB, CAPA DE NEGOCIO

RESUMEN: Capa de negocio con un modelo entidad relación para uso del servicio web el cual se basada en una estructura que brinda parametrización de los procedimientos a ejecutar.

N° DE REGISTRO(en base de datos): N° DE CLASIFICACIÓN: Nº

DIRECCIÓN URL (Tesis en la web):

ADJUNTO PDF X SI

NO

CONTACTO CON AUTOR: ADOLFO ENRIQUE SOTOMAYOR SÁNCHEZ

Teléfono: 0958931731

E-mail: adolfo_sotomayor_s @hotmail.com

CONTACTO DE LA INSTITUCIÓN Nombre:

Teléfono:

I

APROBACIÓN DEL TUTOR

En mi calidad de Tutor del trabajo de titulación, “ESTUDIO DE FACTIBILIDAD

PARA LA PROPUESTA "FRAMEWORK DE TRABAJO PARA PROYECTOS DE

TITULACIÓN APLICANDO METODOLOGÍA SCRUM EN LA INGENIERÍA DE

SOFTWARE" ENFOCADO A LA ARQUITECTURA CAPA DE NEGOCIO

DESARROLLANDO UN MODELO ENTIDAD RELACIÓN QUE PERMITA

SOPORTAR Y CONFIGURAR PROCEDIMIENTOS ALMACENADOS PARA SU

EJECUCIÓN DESDE UN SERVICIO WEB.” elaborado por el Sr.

ADOLFO ENRIQUE SOTOMAYOR SÁNCHEZ, Alumno no titulado de la

Carrera de Ingeniería en Sistemas Computacionales, Facultad de Ciencias

Matemáticas y Físicas de la Universidad de Guayaquil, previo a la obtención del

Título de Ingeniero en Sistemas, me permito declarar que luego de haber

orientado, estudiado y revisado, la Apruebo en todas sus partes.

Atentamente

LSI. OSCAR OMAR APOLINARIO ARZUBE

TUTOR

II

DEDICATORIA

El fruto de toda mi carrera que

se resume en este proyecto lo

dedico a Dios por darme la

vida, conocimiento y sabiduría

a lo largo de este camino.

Lo dedico a mi familia que me

ha apoyado durante toda la

carrera, de manera especial a

mis abuelos y mis padres

debido a ellos es que soy el

hombre que me he convertido.

III

AGRADECIMIENTO

Agradezco en primer lugar a

Dios porque gracias a Él tengo

vida, por haberme permitido

llegar hasta donde estoy, a mis

abuelos por su ayuda constante

a lo largo de toda la carrera, a

mis padres por enseñarme en

silencio con cada acto

desinteresado de ellos.

IV

TRIBUNAL PROYECTO DE TITULACIÓN

Ing. Eduardo Santos Baquerizo, M.Sc Ing. Inelda Martillo Alcívar, Mgs

DECANO DE LA FACULTAD DIRECTORA CIENCIAS MATEMATICAS Y CISC FISICAS

LSI. Oscar Apolinario Arzube Ing. Jorge Chicala Arroyave DIRECTOR DEL PROYECTO DE PROFESOR DEL ÁREA TITULACIÓN DEL TRIBUNAL

Lcd. Pablo Alarcon Salvatierra Ab. Juan Chávez A. PROFESOR DEL ÁREA Secretario DEL TRIBUNAL

V

DECLARACIÓN EXPRESA

“La responsabilidad del contenido de este Proyecto de Titulación, me corresponden exclusivamente; y el patrimonio intelectual de la misma a la UNIVERSIDAD DE GUAYAQUIL”

_________________________________________ ADOLFO ENRIQUE SOTOMAYOR SÁNCHEZ

VI

.

UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS

CARRERA DE INGENIERÍA EN SISTEMAS

COMPUTACIONALES

ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA "FRAMEWORK DE TRABAJO PARA PROYECTOS DE TITULACIÓN APLICANDO

METODOLOGÍA SCRUM EN LA INGENIERÍA DE SOFTWARE" ENFOCADO A LA ARQUITECTURA CAPA DE NEGOCIO DESARROLLANDO UN MODELO ENTIDAD RELACIÓN



WEB

Proyecto de Titulación que se presenta como requisito para optar por el título de

INGENIERO EN SISTEMAS COMPUTACIONALES

Autor: ADOLFO ENRIQUE SOTOMAYOR SÁNCHEZ

C.I. 0924849229

Tutor: LSI. OSCAR OMAR APOLINARIO ARZUBE

Guayaquil, Noviembre de 2015

VII

CERTIFICADO DE ACEPTACIÓN DEL TUTOR

En mi calidad de Tutor del proyecto de titulación, nombrado por el Consejo Directivo de la Facultad de Ciencias Matemáticas y Físicas de la Universidad de Guayaquil.

CERTIFICO:

Que he analizado el Proyecto de Titulación presentado por el estudiante ADOLFO ENRIQUE SOTOMAYOR SÁNCHEZ, como requisito previo para optar por el título de Ingeniero en Sistemas cuyo problema es: ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA "FRAMEWORK DE

TRABAJO PARA PROYECTOS DE TITULACIÓN APLICANDO METODOLOGÍA

SCRUM EN LA INGENIERÍA DE SOFTWARE" ENFOCADO A LA

ARQUITECTURA CAPA DE NEGOCIO DESARROLLANDO UN MODELO

ENTIDAD RELACIÓN QUE PERMITA SOPORTAR Y CONFIGURAR

PROCEDIMIENTOS ALMACENADOS PARA SU EJECUCIÓN DESDE UN

SERVICIO WEB.

Considero aprobado el trabajo en su totalidad.

Presentado por:

Adolfo Enrique Sotomayor Sánchez 0924829229_______ Apellidos y Nombres Completos Cédula de ciudadanía N°

Tutor: _______________________________

LSI. OSCAR OMAR APOLINARIO ARZUBE

Guayaquil, Noviembre de 2015

VIII


CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES

Autorización para Publicación de Proyecto de Titulación en Formato Digital

1. Identificación del Proyecto de Titulación Nombre Alumno: Adolfo Enrique Sotomayor Sánchez

Dirección: Garzota 2da etapa, Manzana 139, Villa 4

Teléfono: 0958931731 E-mail: [email protected]

Facultad: Ciencias Matemáticas y Físicas

Carrera: Ingeniería en Sistemas Computacionales

Proyecto de titulación al que opta: Ingeniero en Sistemas Computacionales

Profesor tutor: LSI. OSCAR OMAR APOLINARIO ARZUBE

Título del Proyecto de titulación: ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA "FRAMEWORK DE TRABAJO PARA PROYECTOS DE TITULACIÓN APLICANDO METODOLOGÍA SCRUM EN LA INGENIERÍA DE SOFTWARE" ENFOCADO A LA ARQUITECTURA CAPA DE NEGOCIO DESARROLLANDO UN MODELO ENTIDAD RELACIÓN QUE PERMITA SOPORTAR Y CONFIGURAR PROCEDIMIENTOS ALMACENADOS PARA SU EJECUCIÓN DESDE UN SERVICIO WEB

Tema del Proyecto de Titulación: FRAMEWORK, SCRUM, MODELO ENTIDAD RELACIÓN, PROCEDIMIENTO ALMACENADO, SERVICIO WEB, CAPA DE NEGOCIO

IX

2. Autorización de Publicación de Versión Electrónica del Proyecto de Titulación A través de este medio autorizo a la Biblioteca de la Universidad de Guayaquil y a la Facultad de Ciencias Matemáticas y Físicas a publicar la versión electrónica de este Proyecto de titulación. Publicación electrónica:

Inmediata X Después de 1 año

Firma Alumno:

3. Forma de envío: El texto del proyecto de titulación debe ser enviado en formato Word, como archivo .Doc. O .RTF y .Puf para PC. Las imágenes que la acompañen pueden ser: .gif, .jpg o .TIFF.

DVDROM X CDROM

X

ÍNDICE GENERAL

APROBACIÓN DEL TUTOR ...................................................................... I

DEDICATORIA ..........................................................................................II

AGRADECIMIENTO .................................................................................III

DECLARACIÓN EXPRESA ...................................................................... V

CERTIFICADO DE ACEPTACIÓN DEL TUTOR .................................... VII

ÍNDICE GENERAL ................................................................................... X

ÍNDICE DE CUADROS .......................................................................... XIV

ÍNDICE DE GRÁFICOS ......................................................................... XVI

RESUMEN.............................................................................................. XX

ABSTRACT ........................................................................................... XXI

INTRODUCCIÓN .......................................................................................1

CAPÍTULO I ...............................................................................................2

EL PROBLEMA ......................................................................................2

Ubicación del Problema en un Contexto .............................................2

Situación Conflicto Nudos Críticos ......................................................2

Causas y Consecuencias del Problema..............................................3

Delimitación del Problema ..................................................................5

Formulación del Problema ..................................................................5

Evaluación del Problema ....................................................................6

VARIABLES DE LA INVESTIGACION ................................................7

OBJETIVOS ...........................................................................................8

OBJETIVO GENERAL ........................................................................8

OBJETIVOS ESPECÍFICOS ...............................................................8

ALCANCES DEL PROBLEMA ...............................................................9

JUSTIFICACIÓN E IMPORTANCIA .....................................................10

METODOLOGÍA DEL PROYECTO: .....................................................11

CAPÍTULO II ............................................................................................13

ANTECEDENTES DEL ESTUDIO........................................................13

FUNDAMENTACIÓN TEÓRICA ...........................................................13

XI

FUNDAMENTACIÓN LEGAL ...............................................................22

PREGUNTA CIENTÍFICA A CONTESTARSE ......................................29

DEFINICIONES CONCEPTUALES ......................................................29

CAPÍTULO III ...........................................................................................31

• Análisis de factibilidad ....................................................................31

• Etapas de la metodología del proyecto ..........................................40

• Entregables del proyecto ...............................................................50

CRITERIOS DE VALIDACIÓN DE LA PROPUESTA ...........................51

CRITERIOS DE ACEPTACIÓN ........................................................51

JUICIO DE EXPERTOS ...................................................................53

PLAN DE PRUEBAS ........................................................................53

RESULTADO DE LAS ENCUESTAS ...............................................56

CAPÍTULO IV ..........................................................................................65

CONCLUSIONES ................................................................................67

RECOMENDACIONES ........................................................................68

BIBLIOGRAFÍA ........................................................................................69

ANEXO 1 .................................................................................................71

BASES ENCUESTA .............................................................................71

ANEXO 2 .................................................................................................81

ENCUESTA .........................................................................................81

ANEXO 3 .................................................................................................84

MANUAL DE USUARIO DEL SEP .......................................................84

XII

ABREVIATURAS

Ing. Ingeniero Lsi. Licenciado en Sistemas de Información CC.MM.FF Facultad de Ciencias Matemáticas y Físicas Mtra. Maestra Msc. Master URL Localizador de Fuente Uniforme www world wide web (red mundial) SEP Servicio Ejecuta Procedimientos SEC Servicio Ejecuta Consultas JPA Java Persistence API PMP Project Management Professional JDBC Java Database Connectivity

XIII

SIMBOLOGÍA

s Desviación estándar e Error E Espacio muestral E(Y) Esperanza matemática de la v.a. y s Estimador de la desviación estándar e Exponencial

XIV

ÍNDICE DE CUADROS

CUADRO N. 1 ...........................................................................................3

Causas y Consecuencias ..........................................................................3

CUADRO N. 2 ...........................................................................................5

Delimitación del problema ..........................................................................5

CUADRO N. 3 .........................................................................................40

Factibilidad Económica ............................................................................40

CUADRO N. 4 .........................................................................................41

Sprints definidos para el proyecto. ...........................................................41

CUADRO N. 5 .........................................................................................52

Criterios de Aceptación ............................................................................52

CUADRO N. 6 .........................................................................................53

Cuadro del Plan de Pruebas ....................................................................53

CUADRO N. 7 .........................................................................................57

Pregunta 1 - Encuesta .............................................................................57

CUADRO N. 8 .........................................................................................58

Pregunta 2 – Encuesta ............................................................................58

CUADRO N. 9 .........................................................................................59

Pregunta 3 – Encuesta ............................................................................59

CUADRO N. 10 .......................................................................................60


CUADRO N. 11 .......................................................................................61


CUADRO N. 12 .......................................................................................62


CUADRO N. 13 .......................................................................................63


CUADRO N. 14 .......................................................................................64


CUADRO N. 15 .......................................................................................65

XV

Niveles de Cumplimiento por sprint .........................................................65

CUADRO N. 16 .......................................................................................93

Script de ejemplo – configuración de servicio ..........................................93

CUADRO N. 17 .......................................................................................95

Parámetros de Entrada en del procedimiento automático ........................95

Fuente: Datos del proyecto ......................................................................95

CUADRO N. 18 .......................................................................................95

Parámetros de Salida en del procedimiento automático ..........................95

CUADRO N. 19 .......................................................................................96

Script de ejecución de procedimiento almacenado ..................................96

CUADRO N. 20 .......................................................................................96

Sentencia de ejemplo asignación de permisos. .......................................96

CUADRO N. 21 .......................................................................................97

Ejecución del jar en modo consola 3DES ................................................97

CUADRO N. 22 .......................................................................................98

Ejecución del jar en modo consola blowfish .............................................98

CUADRO N. 23 ..................................................................................... 100

Revisión de bitácoras por error y éxito ................................................... 100

XVI

ÍNDICE DE GRÁFICOS

Gráfico 1 .................................................................................................14

Esquema básico Web Service - Xml ........................................................14

Gráfico 2 .................................................................................................16

Esquema básico de Jboss .......................................................................16

Gráfico 3 .................................................................................................17

IDE Netbeans ..........................................................................................17

Gráfico 4 .................................................................................................17

Diagrama de la función F de Blowfish ......................................................17

Gráfico 5 .................................................................................................18

Algoritmo 3DES .......................................................................................18

Gráfico 6 .................................................................................................19

Tablero en Trello – Metodología Kanban .................................................19

Gráfico 7 .................................................................................................20

Ventana de Soapui ..................................................................................20

Gráfico 8 .................................................................................................21

El proceso de registro de log de la aplicación ..........................................21

Gráfico 9 .................................................................................................32

Arquitectura de la Capa de Negocio ........................................................32

Gráfico 10 ...............................................................................................34

Modelo Entidad Relación de la capa de negocio .....................................34

Gráfico 11 ...............................................................................................35

Diagrama de clases de la Capa de Negocio ............................................35

Gráfico 12 ...............................................................................................36

Diagrama de componentes de la capa de negocio ..................................36

Gráfico 13 ...............................................................................................37

Diagrama de flujo de la Capa de Negocio - SEP .....................................37

Gráfico 14 ...............................................................................................38

Diagrama de Secuencia...........................................................................38

Gráfico 15 ...............................................................................................39

XVII

Diagrama Detallado de Componentes .....................................................39

Gráfico 16 ...............................................................................................43

Resumen Sprint 1 con Trello ...................................................................43

Gráfico 17 ...............................................................................................45

Actividades Sprint 1 con Trello.................................................................45

Gráfico 18 ...............................................................................................47


Gráfico 19 ...............................................................................................48


Gráfico 20 ...............................................................................................49


Gráfico 21 ...............................................................................................50


Gráfico 22 ...............................................................................................55

Análisis de Código JDBC .........................................................................55

Gráfico 23 ...............................................................................................56

Análisis de Código JPA ...........................................................................56

Gráfico 24 ...............................................................................................57


Gráfico 25 ...............................................................................................58


Gráfico 26 ...............................................................................................59


Gráfico 27 ...............................................................................................60


Gráfico 28 ...............................................................................................61


Gráfico 29 ...............................................................................................62


Gráfico 30 ...............................................................................................63


XVIII

Gráfico 31 ...............................................................................................64


Gráfico 32 ...............................................................................................72

Total Encuestas Realizadas ....................................................................72

Gráfico 33 ...............................................................................................73

Resultados de surveymonkey de pregunta 1 ...........................................73

Gráfico 34 ...............................................................................................74


Gráfico 35 ...............................................................................................75


Gráfico 36 ...............................................................................................76


Gráfico 37 ...............................................................................................77


Gráfico 38 ...............................................................................................78


Gráfico 39 ...............................................................................................79


Gráfico 40 ...............................................................................................80


Gráfico 41 ...............................................................................................87

Tabla del SEP – sep_grupo_servicios .....................................................87

Gráfico 42 ...............................................................................................88

Tabla del SEP – sep_historial_objetos.....................................................88

Fuente: Datos del proyecto ......................................................................88

Gráfico 43 ...............................................................................................89

Tabla del SEP – sep_objetos_bd .............................................................89

Gráfico 44 ...............................................................................................89

Tabla del SEP – sep_parametros_objetos_bd .........................................89

Gráfico 45 ...............................................................................................90

Tabla del SEP – sep_roles ......................................................................90

XIX

Gráfico 46 ...............................................................................................90

Tabla del SEP – sep_servicio_roles ........................................................90

Gráfico 47 ...............................................................................................91

Tabla del SEP – sep_servicio_usuarios ...................................................91

Gráfico 48 ...............................................................................................91

Tabla del SEP – sep_servicios ................................................................91

Gráfico 49 ...............................................................................................92

Tabla del SEP – sep_tipo_datos ..............................................................92

Gráfico 50 ...............................................................................................92

Tabla del SEP – sep_usuarios .................................................................92

Gráfico 51 ...............................................................................................99

Ejecución de Servicio del SEP .................................................................99

XX


CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES

ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA "FRAMEWORK

DE TRABAJO PARA PROYECTOS DE TITULACIÓN APLICANDO METODOLOGÍA SCRUM EN LA INGENIERÍA DE SOFTWARE"

ENFOCADO A LA ARQUITECTURA CAPA DE NEGOCIO DESARROLLANDO UN MODELO ENTIDAD RELACIÓN



WEB

RESUMEN

Capa de negocio con un modelo entidad relación para uso del servicio web el cual

se basa en una estructura que brinda una parametrización de los procedimientos

a ejecutar. El servicio web maneja una capa JPA que extraer la información de las

tablas de parametrización del modelo entidad relación creado, permitiendo al

servicio web la interoperabilidad con otras capas. El desarrollo de este framework

está basado en la metodología Scrum comprobando científicamente las

metodologías ágiles. Este sistema está orientado para cualquier proyecto que

tenga la necesidad de una capa de negocio con un modelo entidad relación para

la ejecución de procedimientos que se encuentran parametrizados en tablas. El

uso de este framework permite agilizar los procesos y disminuir tiempos de

desarrollo debido a que el servicio web ejecutará los procedimientos almacenados

en la capa de datos con tan solo configurarlos en las tablas de uso del SEP.

Autor: Adolfo Sotomayor Sánchez Tutor: Lsi. Oscar Apolinario

XXI

UNIVERSIDAD DE GUAYAQUIL

FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES

FEASIBILITY STUDY FOR THE PROPOSAL "WORKING FRAMEWORK FOR TITLING PROJECTS USING THE SCRUM METHODOLOGY IN SOFTWARE

ENGINEERING" FOCUSED ON THE BUSINESS LAYER ARCHITECTURE DEVELOPING A ENTITY

RELATIONSHIP MODEL THAT ALLOW SUPPORT AND SET OF STORED

PROCEDURES FOR ITS EXECUTION FROM

A WEB SERVICE

ABSTRACT

Business layer with an entity relationship model for web service use which is based

on a structure that provides a parameterization of the procedures to execute. The

web service handles a JPA layer to extract information from tables

parameterization entity relationship created model, allowing the web service

interoperability with other layers. The development of this framework is based on

the Scrum methodology scientifically proving agile methodologies. This system is

geared for any project that has the need from a business layer with a entity

relationship model for the execution of procedures that are parameterized in tables.

Using this framework can streamline processes and reduce development time

because the web service allow execute stored procedures of the data layer with

just configure them using tables of the SEP.

Autor: Adolfo Sotomayor Sánchez Tutor: Lsi. Oscar Apolinario

1

INTRODUCCIÓN

En la actualidad muchos de los sistemas web interactúan directamente con la base

de datos, siendo este uno de los grandes problemas de performance en el servicio,

debido a que no cuentan con una capa de negocio que interconecta las capas de

presentación con la capa de datos.

Debido a la necesidad que tiene el proyecto en que exista una capa de negocio

cuya funcionalidad sea el de interconectar la capa de presentación y la capa de

datos y seguir las normar de desarrollo.

Este documento se encuentra dividido en 4 capítulos, que se detallan

brevemente a continuación:

Capítulo I: En este capítulo se describe el planteamiento del problema del

proyecto, se verá cuáles son las causas y consecuencias del problema así

como los objetivos y alcances para su desarrollo, presentaremos la

justificación y la importancia del proyecto y cuál es la metodología que se

usó.

Capítulo II: En este capítulo se describe cual es la teoría y los conceptos

que se utilizaron en el proyecto para el desarrollo del modelo entidad

relación de capa de negocio, podremos observar los términos que fueron

usados en el proyecto así como la fundamentación legal.

Capítulo II: En este capítulo se describe la propuesta tecnológica para el

proyecto, en este también se encuentra los análisis de factibilidad y las

etapas del proyecto con sus respectivos entregables. En las etapas del

proyecto se podrá observar los sprints con sus respectivas actividades que

se desarrollaron durante todo el proyecto. El resultado de las encuestas

con su análisis se podrá observar al final del capítulo.

Capítulo IV: En este capítulo se describe cuáles fueron los criterios de

aceptación del proyecto en cada sprints y su cumplimiento de las

actividades que se tenían asignados para la capa de negocio.

2

CAPÍTULO I

EL PROBLEMA

PLANTEAMIENTO DEL PROBLEMA

Ubicación del Problema en un Contexto

El problema está ubicado en el proyecto “ESTUDIO DE FACTIBILIDAD PARA LA

PROPUESTA "FRAMEWORK DE TRABAJO PARA PROYECTOS DE


SOFTWARE" ENFOCADO A ARQUITECTURA CAPA DE NEGOCIO.” al existir la

necesidad de crear una capa de negocio que permita la comunicación y

sincronización entre la capa de datos y la de presentación; y la necesidad de crear

un modelo entidad relación exclusivo para la capa de negocio.

Situación Conflicto Nudos Críticos

En la actualidad el avance tecnológico ha permitido automatizar los procesos de

una institución o empresa mediante el uso de aplicaciones web embebidas dentro

de la capa de negocio de cada entidad.

La mayoría de estas aplicaciones están basadas en metodologías de desarrollo

de software tradicionales lo cual genera un costo elevado al tratar de mantener o

mejorar la comunicación hacia la capa de datos mediante la serialización de las

acciones interpretadas en la capa de presentación.

El problema se encuentra en que la capa de presentación al interactuar

directamente con la base de datos se hace una difícil administración en la base

de datos; esto debido a que cada usuario utilizaría la base de datos mediante la

capa de presentación.

3

Otro de los problemas es que al interactuar con la capa de datos, se debe realizar

un desarrollo en la capa de presentación para poder consumir los procedimientos

almacenados, esto involucraría que por cada cambio en la capa de datos se deba

realizar un cambio en la interfaz de usuario.

Causas y Consecuencias del Problema

CUADRO N. 1

Causas y Consecuencias

Causas Consecuencias

La capa de negocio del proyecto

está basado en una tecnología

antigua que no permite cubrir a

totalidad los nuevos requerimientos

de los usuarios.

Los cambios desarrollados serán

basados en la misma tecnología por

ende el rendimiento de la aplicación

disminuirá.

El proyecto está atado a un plan

inicial de desarrollo.

Los cambios deben seguir las

normas y políticas que fueron

planteadas desde un inicio del

proyecto las cuales podrían no estar

enfocadas a la nueva necesidad.

Resistencia a aceptar nuevas

tecnologías de comunicación entre

capas.

El proyecto o aplicación no tendrá

una escalabilidad óptima.

Dependencia de la arquitectura de

software mediante modelos

El sistema podrá será dependiente

de uno o más procesos informáticos

y para cada proceso involucrado se

deberá iniciar otro proceso de

desarrollo.

4

Desarrollos se encuentran ligados

a la capa de datos.

Tiempos altos de entrega en

desarrollos por actualizaciones y/o

mejoras por parte de la capa de

datos.

No existe dinamismo en la

interacción con la capa de datos.

Por cada desarrollo que realice la

capa de datos, se deberá realizar un

nuevo desarrollo en la capa de

presentación y/o negocio.

Elaboración: Adolfo Enrique Sotomayor Sánchez Fuente: Investigación del proyecto

5

Delimitación del Problema

CUADRO N. 2

Delimitación del problema

CAMPO SOCIAL

ÁREA METODOLOGÍAS, CALIDAD Y GESTIÓN DE PROYECTOS DE

SOFTWARE

ASPECTO TECNOLÓGICO

TEMA

ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA "FRAMEWORK DE

TRABAJO PARA PROYECTOS DE TITULACIÓN APLICANDO

METODOLOGÍA SCRUM EN LA INGENIERÍA DE SOFTWARE"

ENFOCADO A LA ARQUITECTURA CAPA DE NEGOCIO


SOPORTAR Y CONFIGURAR PROCEDIMIENTOS ALMACENADOS PARA

SU EJECUCIÓN DESDE UN SERVICIO WEB

Elaboración: Adolfo Enrique Sotomayor Sánchez

Fuente: Investigación

El desarrollo está dirigido a quienes necesiten un framework de trabajo que

permita la interacción de manera dinámica y automática entre la capa de

presentación y la capa de datos, por tal motivo es de carácter Social.

Formulación del Problema

Usualmente una de las malas prácticas en la ingeniería de software es de conectar

la capa de presentación directamente con la capa de datos, provocando así un

pésimo rendimiento a la medida que los usuarios aumenta.

El uso de este modelo implica que cualquier cambio en la capa de datos significa

que hay un impacto para la capa visual, ya que hay nuevos desarrollos y un

aumento por el tiempo de desarrollo a emplearse.

6

El uso de esta mala práctica nos lleva a una falta de interoperabilidad con otros

sistemas.

Por estos motivos es complicado mantener una plataforma con este tipo de

tecnología, lo que acarrea que no haya aumento en la productividad y no se utiliza

correctamente el tiempo habiendo pérdida de tiempo, dinero y personal.

Evaluación del Problema

Delimitado: El no contar con una capa de negocio nos dificultaría la

interoperabilidad con otros sistemas, además que cualquier cambio realizado en

la capa de datos implica que la cada visual tenga un impacto en desarrollos,

recursos y tiempos empleados en los desarrollos de las nuevas características.

Debemos aclarar que en la actualidad no existe una solución de capa de datos

que permita la automatización de los consumos de los procedimientos

almacenados en la capa de datos.

Claro: En el proyecto podemos identificar de manera clara que nos ayuda a

integrar las capas de presentación con la capa de datos utilizando el servicio web

como la capa de datos para mejorar la eficiencia en recursos y tiempos de

desarrollo.

Relevante: El proyecto para la comunidad educativa es importante, debido a que

aporta en el desarrollo una metodología ágil SCRUM en Ingeniería de software,

con esta metodología el proyecto puede ser reutilizado por la comunidad para

realizar mejoras en el procedimiento y tecnologías que se usaron, para así

aplicarlo y resolverlo científicamente.

Original: El proyecto no ha sido desarrollado en otro lugar, se puede considerar

una solución original y novedosa ya que ayuda a la necesidad de la existencia de

la capa de presentación con una interacción dinámica con la capa de datos.

7

Factible: El desarrollo de este proyecto es factible debido al bajo costo en

desarrollo y el dinamismo al consumir los procedimientos almacenados de la capa

de datos, y con la metodología que se usa en el desarrollo del proyecto este puede

ser mejorado siguiendo las normas y directrices de la metodología aplicada.

Identifica los productos esperados: El proyecto contribuye con una solución

para la necesidad de la existencia de una capa de negocio, y mediante el uso de

la metodología aplicada en este proyecto se puede continuar con un estudio y

mejorar del proyecto para la comunidad.

VARIABLES DE LA INVESTIGACION

Variables independientes

Capa de Negocio

La capa de negocio es la que permite interconectar las capas de dato con la visual,

siendo esta las que nos ayuda a ejecutar las consultas y los procedimientos

almacenados de la base de dato.

Variables dependientes

Capa Visual – Capa de Datos

Son todas las transacciones que fluyen a través de la capa visual hacia la capa de

datos mediante la capa de negocio.

8

OBJETIVOS

OBJETIVO GENERAL

Desarrollar una capa de negocio bajo el esquema de un servicio web en lenguaje

Java Empresarial y un modelo entidad relación que permita, la interoperabilidad

con sistemas heterogéneos y se convierta en el mecanismo de comunicación para

que la capa visual pueda interactuar con la capa de datos, con un modelo entidad

relación que permita a la capa de negocio conocer las reglas y configuraciones de

los procedimientos almacenados de la capa de datos que se van a ejecutar.

OBJETIVOS ESPECÍFICOS

Analizar, diseñar y desarrollar un modelo entidad relación para el servicio

web que ejecuta los procedimientos almacenados en la base de datos ya

así el SEP pueda tener la lógica que permita la ejecución de los

procedimientos almacenados en la capa de datos, utilizando las tablas

para la parametrización de los procedimientos de la capa de datos.

Desarrollar y mapear las tablas del modelo entidad relación a objetos java

a través del uso de JPA y así poder agilizar su desarrollo.

Parametrizar los procedimientos almacenados en las tablas propietarias

del servicio web convirtiéndolas en servicios para la ejecución de la capa

de presentación.

Utilizar buenas prácticas para el desarrollo de la capa de persistencia

(JPA) validando el código con el servicio SONAR.

Aplicar la metodología Scrum para el desarrollo e implementación del

sistema cumpliendo un rol como parte del Scrum Team.

9

ALCANCES DEL PROBLEMA

El diseño y desarrollo del Modelo Entidad Relación será mediante el uso

de la herramienta Erwin, el cual se generaran los scripts para la creación

de las tablas.

En el desarrollo de la capa de persistencia, será mediante el uso del

lenguaje Java y permitirá la comunicación con la base de datos mediante

los objetos java a través del uso de JPA.

La capa de persistencia es para el uso del servicio web que ejecuta los

procedimientos almacenados en la base de datos.

La capa de negocio contara con validaciones de los usuarios para la

ejecución de cada uno de los procedimientos almacenados.

La capa de negocio contara con un módulo de encriptación para poder

validar las contraseñas de los usuarios.

Se realizarán pruebas en la capa de persistencia de la aplicación.

El proyecto se desarrollara en 6 sprint usando la metodología Scrum.

10

JUSTIFICACIÓN E IMPORTANCIA

Una vez culminado el desarrollo del modelo entidad relación de la capa de

negocio, este servirá para el proyecto “ESTUDIO DE FACTIBILIDAD PARA LA



SOFTWARE" ENFOCADO A ARQUITECTURA CAPA DE NEGOCIO.”, ya que no

cuenta con una capa de negocio y un modelo entidad relación que permite manejar

dinamismo en las ejecuciones de los procedimientos almacenados y que sirve de

conector entre la capa de presentación y la capa de datos, mejorando los tiempos

de desarrollo y el performance del sistema.

Con esta investigación podremos demostrar científicamente el uso de esta nueva

metodología con la cual se desarrolló el proyecto, esta nueva metodología

permiten el desarrollo de las aplicaciones de manera ágil y teniendo como objetivo

realizar una entrega de un sistema funcional en cada sprint.

Mediante el desarrollo de este framework podrá ser utilizado por cualquier sistema

el cual necesite del uso de una capa de negocio ayudando a resolver la

problemática que existe en las aplicaciones al no contar con una capa de negocio,

ayudando así a mejorar el perfomance de los sistemas y bajando los tiempos de

desarrollo.

Además con la investigación del proyecto hemos usado para desarrollarlo la

metodología ágil Scrum con lo cual podremos demostrar que es factible el uso de

este tipo de metodología ágil para el desarrollo de proyectos; esto debido a que

las aplicaciones que se desarrollen con esta metodología y siguiendo todas las

normas se pueden realizas aplicaciones de manera fácil y eficiente; dejando así

para la comunidad un proyecto el cual puede ser utilizado para realizar mejoras

siguiendo con la metodología.

11

METODOLOGÍA DEL PROYECTO:

1.- Metodología de Desarrollo

La metodología que se va a usar en el desarrollo de este proyecto es SCRUM, el

cual es denominada metodología ágiles para el desarrollo de software, este tipo

de metodología tiene interacciones, cada interacción se llama sprint.

Esta metodología nos definen roles, en el cual en este proyecto vamos a formar

parte del Scrum Team con el rol de Development Team, ya que vamos a tener que

desarrollar la capa de negocio.

Se deberá definir cuáles son los sprint, que va a tener nuestro proyecto, estos

sprint van a depender del Product Backlog, el cual es una lista de las

características que definen a nuestro producto.

De toda la lista Product Backlog, se debe organizar y separas tareas para

agruparlas en el sprint, cada término del sprint se debe entrega al usuario un

producto funcional según cada sprint definido.

Dentro de esta metodología, debemos tener en cuenta que el equipo de desarrollo

(Development Team) debe tener reuniones diarias en las que debemos hacernos

las siguientes preguntas: ¿Qué voy hacer? y ¿Qué impedimentos tengo para el

desarrollo de la tarea?, esto para poder estar sincronizado todo el equipo.

Para llevar el control en el desarrollo del proyecto manejaremos la herramienta

Trello para monitorear las actividades.

2.- Supuestos y restricciones

Los supuestos de este proyecto son los siguientes:

Hay un total de 6 sprint en el desarrollo de este proyecto

Los sprints tienen un tiempo de desarrollo de una semana

Debe haber reuniones de seguimiento diaria de no más allá 15 min.

12

El grupo SCRUM TEAM debe ser un grupo estable, constante, a niveles

de conocimiento en la herramienta de trabajo.

Las restricciones d este proyecto son las siguientes:

El equipo de desarrollo tiene disponibilidad de 6 horas al día

El desarrollo del proyecto debe estar listo en los 6 sprint.

3.- Plan de Calidad

El plan de calidad de este proyecto se basa en dos puntos, el primero consiste en

que el código fuente de la aplicación tenga los estándares en la programación, el

segundo punto consiste en que el servicio web SEP (Servicio ejecuta

procedimientos) no contenga errores técnicos al momento de la ejecución de los

procedimientos que se encuentran parametrizados dentro de las tablas de uso del

SEP.

Para el primer punto se usará la herramienta de análisis de código SONAR, el cual

permitirá señalar observaciones en el código que no estén de acuerdo al estándar

de programación.

Para el segundo punto se usara un plan de pruebas en el cual servirá de control

para el análisis del SEP y comprobar que este no contenga errores técnicos al

momento de la ejecución.

13

CAPÍTULO II

MARCO TEÓRICO

ANTECEDENTES DEL ESTUDIO

Con el pasar del tiempo las nuevas metodologías y desarrollos de software se van

actualizando, en las cuales vemos mejoras y diferentes tipos de programación, por

este motivo surge la idea del desarrollo de un framework de trabajo el cual sirva

para aquellos sistemas y proyectos que se vean en la necesidad de contar con

una capa de negocio. Durante nuestra investigación se encontraron las soluciones

de n capas y 3 capas, las cuales se acogen a nuestro framework pero no del todo,

viendo así la necesidad de mejorar la capa de negocio adaptándole una lógica que

no existe en el mercado con otras ya existentes.

FUNDAMENTACIÓN TEÓRICA

Framework.- Un framework es un marco de trabajo en el cual incluyen un conjunto

de librerías que permiten al desarrollador poder reutilizar y facilitar las actividades

de algún sistema, así mismo podemos decir que un framework:

“automatiza muchos de los patrones de programación para

orientarlos a un determinado propósito, proporcionando una

estructura al código, mejorándolo y haciéndolo más entendible y

sostenible, y permite separar en capas la aplicación (MARTÍNEZ

VILLALOBOS, CAMACHO SÁNCHEZ, & BIANCHA GUTIÉRREZ, 2010)

14

Web Services.- “Un servicio web es cualquier servicio que está disponible a

través de Internet, utiliza un sistema de mensajería XML estandarizada, y no está

ligada a ningún sistema operativo o de un lenguaje de programación” (O'Reilly,

2002).

Gráfico 1

Esquema básico Web Service - Xml

Elaboración: O’Reilly Fuente: Web Services Essentials O’Reilly, 2002

Capa de Negocio.- “La capa lógica de negocios ocupa un lugar preeminente en

la construcción de una infraestructura de software, al permitir el crecimiento y la

extensión de servicios para todas las aplicaciones existentes y futuras.”

(Andalucia, s.f.). En la capa de negocio también podemos decir que “Esta capa

intermedia es la que conlleva capacidad de mantenimiento y de reutilización.”

(Moquillaza Henríquez, Vega Huerta, & Guerra Grados)

JPA (Java Persistence API).- “La API de Java Persistence proporciona un

modelo de persistencia POJO para el mapeo objeto-relacional” (Oracle, s.f.), asi

mismo esta API “también ofrece soluciones a los retos arquitectónicos de la

integración de la persistencia en aplicaciones empresariales escalables” (Keith &

Schnicariol, 2009)

Ingeniería de software.- La ingeniería de software es:

“el establecimiento y uso de principios fundamentales de la ingeniería

con objeto de desarrollar en forma económica software que sea

confiable y que trabaje con eficiencia en máquinas reales”.

(Pressman, 2010)

15

Otro concepto clave de la ingeniería de software es “una disciplina de la ingeniería

que comprende todos los aspectos de la produccion de software desde las etapas

iniciales de la especificacion del sistema, hasta el mantenimiento de este despues

de que se utilizan.” (Sommerville)

Scrum.- Es un método para el desarrollo ágil del software, esta metodología indica

que siempre se debe entregar un desarrollo funcional para el cliente, estas

entregas se les denomina sprint.

“Scrum no es un proceso o una técnica para construir productos; en lugar de eso,

es un marco de trabajo dentro del cual se pueden emplear varias técnicas y

procesos. Scrum muestra la eficacia relativa de las prácticas de gestión de

producto y las prácticas de desarrollo, de modo que podamos mejorar.” (Schwaber

& Sutherland, 2013).

Interoperabilidad.- “La interoperabilidad es la capacidad que tiene un producto o

un sistema, cuyas interfaces son totalmente conocidas, para funcionar con otros

productos o sistemas existentes o futuros y eso sin restricción de acceso o de

implementación.” (Interoperability, s.f.)

Kanban.- Es un método que nos permite manejar el trabajo intelectual de cada

trabajado para que el trabajador no tenga recarga de trabajo, ahora en el

desarrollo de sistemas “utilizamos un sistema Kanban virtual para limitar el trabajo

en curso. A pesar de que el nombre se origina del idioma japonés "Kanban", y se

traduce aproximadamente como "tarjeta de señal", y hay tarjetas utilizadas en la

mayoría de las implementaciones de Kanban en desarrollo de software, estas

tarjetas no funcionan en realidad como señales para realizar más trabajo.

Representan los elementos de trabajo. De ahí el término "virtual" porque no existe

una tarjeta física.” (Wikipedia, Wikipedia, s.f.)

JBOSS.- “Es un servidor de aplicaciones Java EE de código

abierto implementado en Java puro. Al estar basado en Java, JBoss puede ser

utilizado en cualquier sistema operativo para el que esté disponible la máquina

virtual de Java” (Wikipedia, Wikipedia Jboss, s.f.).

16

Gráfico 2

Esquema básico de Jboss

Elaboración: Francesco Marchioni

Fuente: JBoss As 7. Configiration, Deployment, and Administration.

Netbeans.- “La plataforma NetBeans es un marco amplio de Java donde puede

basar las aplicaciones de escritorio de gran tamaño. NetBeans IDE es uno de los

cientos de aplicaciones basadas en la plataforma NetBeans. La plataforma

NetBeans contiene APIs que simplifican el manejo de ventanas, acciones,

archivos y muchas otras cosas típicas en las aplicaciones” (Netbeans, s.f.)

http://platform.netbeans.org/screenshots.html

http://platform.netbeans.org/screenshots.html

17

Gráfico 3

IDE Netbeans


Fuente: Desarrollo e Investigación del Proyecto de Tesis

Blowfish.- “Blowfish usa bloques de 64 bits y claves que van desde los 32 bits

hasta 448 bits. Es un codificador de 16 rondas Feistel y usa llaves que dependen

de las Cajas-S. Tiene una estructura similar a CAST-128, el cual usa Cajas-Sfijas”

(Wikipedia, Wikipedia Blowfish, s.f.)

Gráfico 4

Diagrama de la función F de Blowfish

Elaboración: Wikipedia

Fuente: https://upload.wikimedia.org/wikipedia/commons/a/a3/BlowfishFuncionF.png

https://es.wikipedia.org/wiki/Bit

https://es.wikipedia.org/wiki/Red_de_Feistel

https://es.wikipedia.org/wiki/CAST-128

https://es.wikipedia.org/wiki/Cajas-S

18

3DES.- Es un algoritmo de encriptación. “El triple DES (3DES) se estandarizo

inicialmente para aplicaciones financieras en el estándar ANSI X9.17 en 1985. El

3DES se incorporó como parte del DES en 1999m con la publicación FIPS PUB

46-3” (Stallings, 2004)

Gráfico 5

Algoritmo 3DES

Elaboración: Erika Aguillón Martínez

Fuente: http://redyseguridad.fi-p.unam.mx/proyectos/criptografia/criptografia/index.php/4-

criptografia-simetrica-o-de-clave-secreta/41-introduccion-a-la-criptografia-simetrica/413-principales-

algoritmos-simetricos?showall=&start=5

Trello.- Es una aplicación web que se basa en el método Kanban, esta

herramienta sirve para la administración de los proyectos mediante el uso de

tarjetas en un tablero virtual. El tablero usualmente contiene 3 columnas: Lo que

hay por hacer, lo que está haciendo y lo que finalizó.

19

Gráfico 6

Tablero en Trello – Metodología Kanban

Elaboración: Trello.com

Fuente: https://trello.com/b/I7TjiplA/trello-tutorial

Erwin.- “CA ERwin Data Modeler es una solución de modelado de datos líder en

la industria que ofrece una interfaz sencilla y visual para administrar el entorno de

datos complejos” (Erwin, s.f.)

Soapui.- “SoapUI es una solución multiplataforma, en el cual se pueden realizar

pruebas funcionales libre y de código abierto. Con una características fáciles de

usar interfaz gráfica, y de clase empresarial, SoapUI le permite crear y ejecutar

pruebas funcionales, de regresión, de cumplimiento y de carga automatizadas con

facilidad y rapidez” (SOAPUI, s.f.)

20

Gráfico 7

Ventana de Soapui

Elaboración: Trello.com

Fuente: https://trello.com/b/I7TjiplA/trello-tutorial

Loggin.- “El registro es una manera sistemática y controlada de lo que representa

el estado de una aplicación de forma legible (…)

Un punto importante acerca del registro es que no es sinónimo de la depuración

de los rastros en una aplicación. El registro de la información puede ofrecer más

que la mera información de depuración. Sin embargo, su utilidad depende

totalmente de cómo aplicamos el registro dentro de una aplicación. El registro de

la información puede ser de gran valor para analizar el rendimiento de una

aplicación. Por otra parte, podemos agrupar los estados internos de la aplicación

de la información de registro y almacenar esa información de manera estructurada

para reutilizar en el futuro.

En esta definición podemos destacar los siguientes puntos importantes:

• Es sistemática.

• Se controla.

• Representa el estado de una aplicación” (Gupta)

21

Gráfico 8

El proceso de registro de log de la aplicación

Elaboración: Samudra Gupta

Fuente: Pro apache log4j

22

FUNDAMENTACIÓN LEGAL

“LEY DE COMERCIO ELECTRÓNICO, FIRMAS ELECTRÓNICAS Y

MENSAJES DE DATOS”

TÍTULO I

DE LOS MENSAJES DE DATOS

CAPÍTULO I

Articulo. 1.- Objeto de la Ley.- Esta Ley regula los mensajes de datos, la firma

electrónica, Los servicios de certificación, la contratación electrónica y telemática,

la prestación de Servicios electrónicos, a través de redes de información, incluido

el comercio Electrónico y la protección a los usuarios de estos sistemas.

Articulo. 4.- Propiedad Intelectual.- Los mensajes de datos estarán sometidos a

las leyes, Reglamentos y acuerdos internacionales relativos a la propiedad

intelectual.

Artículo 5.- Confidencialidad y reserva.- Se establecen los principios de

confidencialidad y reserva para los mensajes de datos, cualquiera sea su forma,

medio o intención. Toda violación a estos principios, principalmente aquellas

referidas a la intrusión electrónica, transferencia ilegal de mensajes de o violación

del secreto profesional, será sancionada conforme a lo dispuesto en esta Ley y

demás normas que rigen la materia.

Artículo 9.- Protección de datos.- Para la elaboración, transferencia o utilización

de bases de datos, obtenidas directa o indirectamente del uso o transmisión de

mensajes de datos, se requerirá el consentimiento expreso del titular de éstos,

quien podrá seleccionar la información a compartirse con terceros.

La recopilación y uso de datos personales responderá a los derechos de

privacidad, intimidad y confidencialidad garantizados por la Constitución Política

de la República y esta Ley, los cuales podrán ser utilizados o transferidos

únicamente con autorización del titular u orden de autoridad competente.

23

No será preciso el consentimiento para recopilar datos personales de fuentes

accesibles al público, cuando se recojan para el ejercicio de las funciones propias

de la administración pública, en el ámbito de su competencia, y cuando se refieran

a personas vinculadas por una relación de negocios, laboral, administrativa

o contractual y sean necesarios para el mantenimiento de las relaciones o para

el cumplimiento del contrato.

El consentimiento a que se refiere este artículo podrá ser revocado a criterio del

titular de los datos; la revocatoria no tendrá en ningún caso efecto retroactivo.

CONSTITUCIÓN DE LA REPÚBLICA DEL ECUADOR

Sección octava

Ciencia, tecnología, innovación y saberes ancestrales

Art. 385.- El sistema nacional de ciencia, tecnología, Innovación y saberes

ancestrales, en el marco del respeto al ambiente, la naturaleza, la vida, las culturas

y la soberanía, tendrá como finalidad:

a) Generar, adaptar y difundir conocimientos científicos y tecnológicos.

b) Desarrollar tecnologías e innovaciones que impulsen la producción

nacional, eleven la eficiencia y productividad, mejoren la calidad de vida y

contribuyan a la realización del buen vivir.

Art. 386.- El sistema comprenderá programas, políticas, recursos, acciones, e

incorporará a instituciones del Estado, universidades y escuelas politécnicas,

institutos de investigación públicos y privados, empresas públicas y privadas,

organismos no gubernamentales y personas naturales o jurídicas, en tanto

realizan actividades de investigación, desarrollo tecnológico, innovación…

El Estado, a través del organismo competente, coordinará el sistema, establecerá

los objetivos y políticas, de conformidad con el Plan Nacional de Desarrollo, con

la participación de los actores que lo conforman.

Art. 387.- Será responsabilidad del Estado:

24

a) Facilitar e impulsar la incorporación a la sociedad del conocimiento para

alcanzar los objetivos del régimen de desarrollo.

b) Promover la generación y producción de conocimiento, fomentar la

investigación científica y tecnológica…

c) Asegurar la difusión y el acceso a los conocimientos científicos y

tecnológicos, el usufructo de sus descubrimientos y hallazgos en el marco

de lo establecido en la Constitución y la Ley.

d) Garantizar la libertad de creación e investigación en el marco del respeto

a la ética, la naturaleza, el ambiente…

e) Reconocer la condición de investigador de acuerdo con la Ley.

Art. 388.- El Estado destinará los recursos necesarios para la investigación

científica, el desarrollo tecnológico, la innovación, la formación científica,… la

recuperación y desarrollo de saberes ancestrales y la difusión del conocimiento.

Un porcentaje de estos recursos se destinará a financiar proyectos mediante

fondos concursables. Las organizaciones que reciban fondos públicos estarán

sujetas a la rendición de cuentas y al control estatal respectivo.

La fundamentación legal para los estudios según la nueva ley de educación

superior se refleja en los artículos:

Art. 8.- Serán Fines de la Educación Superior.- La educación superior tendrá los

siguientes fines:

a) Aportar al desarrollo del pensamiento universal, al despliegue de la

producción científica y a la promoción de las transferencias e innovaciones

tecnológicas;

b) Fortalecer en las y los estudiantes un espíritu reflexivo orientado al logro

de la autonomía personal, en un marco de libertad de pensamiento y de

pluralismo ideológico;

25

c) Contribuir al conocimiento…

d) Formar académicos y profesionales responsables, con conciencia ética y

solidaria, capaces de contribuir al desarrollo de las instituciones de la

República, a la vigencia del orden democrático, y a estimular la

participación social;

e) Aportar con el cumplimiento de los objetivos del régimen de desarrollo

previsto en la Constitución y en el Plan Nacional de Desarrollo;

f) Fomentar y ejecutar programas de investigación de carácter científico,

tecnológico y pedagógico que coadyuven al mejoramiento y protección del

ambiente y promuevan el desarrollo sustentable nacional;

g) Constituir espacios para el fortalecimiento del Estado Constitucional,

soberano, independiente, unitario, intercultural, plurinacional y laico;

h) Contribuir en el desarrollo local y nacional de manera permanente, a través

del trabajo comunitario o extensión universitaria.

Art. 71.- Principio de igualdad de oportunidades.- El principio de igualdad de

oportunidades consiste en garantizar a todos los actores del Sistema de

Educación Superior las mismas posibilidades en el acceso, permanencia,

movilidad y egreso del sistema, sin discriminación de género, credo, orientación

sexual, etnia, cultura, preferencia política, condición socioeconómica o

discapacidad.

Las instituciones que conforman el Sistema de Educación Superior propenderán

por los medios a su alcance que, se cumpla en favor de los migrantes el principio

de igualdad de oportunidades. Se promoverá dentro de las instituciones del

Sistema de Educación Superior el acceso para personas con discapacidad bajo

las condiciones de calidad, pertinencia y regulaciones contempladas en la

presente Ley y su Reglamento. El Consejo de Educación Superior, velará por el

cumplimiento de esta disposición.

26

Art. 80.- Gratuidad de la educación superior pública hasta el tercer nivel.- Se

garantiza la gratuidad de la educación superior pública hasta el tercer nivel. La

gratuidad observará el criterio de responsabilidad académica de los y las

estudiantes, de acuerdo con los siguientes criterios:

a) La gratuidad será para los y las estudiantes regulares que se matriculen

en por lo menos el sesenta por ciento de todas las materias o créditos que

permite su malla curricular en cada período, ciclo o nivel;

b) La gratuidad será también para los y las estudiantes que se inscriban en

el nivel preuniversitario, pre politécnico o su equivalente, bajo los

parámetros del Sistema de Nivelación y Admisión.

c) La responsabilidad académica se cumplirá por los y las estudiantes

regulares que aprueben las materias o créditos del período, ciclo o nivel,

en el tiempo y en las condiciones ordinarias establecidas. No se cubrirán

las segundas ni terceras matrículas, tampoco las consideradas especiales

o extraordinarias.

d) El Estado, por concepto de gratuidad, financiará una sola carrera o

programa académico de tercer nivel por estudiante. Se exceptúan los

casos de las y los estudiantes que cambien de carrera o programa, cuyas

materias puedan ser revalidadas.

e) La gratuidad cubrirá exclusivamente los rubros relacionados con la primera

matrícula y la escolaridad; es decir, los vinculados al conjunto de materias

o créditos que un estudiante regular debe aprobar para acceder al título

terminal de la respectiva carrera o programa académico; así como los

derechos y otros rubros requeridos para la elaboración, calificación, y

aprobación de tesis de grado.

f) Se prohíbe el cobro de rubros por utilización de laboratorios, bibliotecas,

acceso a servicios informáticos e idiomas, utilización de bienes y otros,

27

correspondientes a la escolaridad de los y las estudiantes universitarios y

politécnicos.

g) Para garantizar un adecuado y permanente financiamiento del Sistema de

Educación Superior y la gratuidad, la Secretaría Nacional de Educación

Superior, Ciencia, Tecnología e Innovación desarrollará un estudio de

costos por carrera/programa académico por estudiante, el cual será

actualizado periódicamente.

h) Se pierde de manera definitiva la gratuidad, si un estudiante regular

reprueba, en términos acumulativos, el treinta por ciento de las materias o

créditos de su malla curricular cursada.

i) La gratuidad cubrirá todos los cursos académicos obligatorios para la

obtención del grado.

Art. 117.- Tipología de instituciones de Educación Superior.- Las instituciones de

Educación Superior de carácter universitario o politécnico se clasificarán de

acuerdo con el ámbito de las actividades académicas que realicen. Para

establecer esta clasificación se tomará en cuenta la distinción entre instituciones

de docencia con investigación, instituciones orientadas a la docencia e

instituciones dedicadas a la educación superior continua.

En función de la tipología se establecerán qué tipos de carreras o programas

podrán ofertar cada una de estas instituciones, sin perjuicio de que únicamente

las universidades de docencia con investigación podrán ofertar grados

académicos de PHD o su equivalente.

Esta tipología será tomada en cuenta en los procesos de evaluación, acreditación

y categorización.

Art. 118.- Niveles de formación de la educación superior.- Los niveles de

formación que imparten las instituciones del Sistema de Educación Superior son:

a) Nivel técnico o tecnológico superior, orientado al desarrollo de las

habilidades y destrezas que permitan al estudiante potenciar el saber

28

hacer. Corresponden a éste los títulos profesionales de técnico o tecnólogo

superior, que otorguen los institutos superiores técnicos, tecnológicos,

pedagógicos, de artes y los conservatorios superiores. Las instituciones

de educación superior no podrán ofertar títulos intermedios que sean de

carácter acumulativo.

b) Tercer nivel, de grado, orientado a la formación básica en una disciplina o

a la capacitación para el ejercicio de una profesión. Corresponden a este

nivel los grados académicos de licenciado y los títulos profesionales

universitarios o politécnicos, y sus equivalentes. Sólo podrán expedir

títulos de tercer nivel las universidades y escuelas politécnicas. Al menos

un 70% de los títulos otorgados por las escuelas politécnicas deberán

corresponder a títulos profesionales en ciencias básicas y aplicadas.

c) Cuarto nivel, de postgrado, está orientado al entrenamiento profesional

avanzado o a la especialización científica y de investigación.

Corresponden al cuarto nivel el título profesional de especialista; y los

grados académicos de maestría, PhD o su equivalente. Para acceder a la

formación de cuarto nivel, se requiere tener título profesional de tercer nivel

otorgado por una universidad o escuela politécnica, conforme a lo

establecido en esta Ley.

Las universidades y escuelas politécnicas podrán otorgar títulos de nivel

técnico o tecnológico superior cuando realicen alianzas con los institutos

de educación superior o creen para el efecto el respectivo instituto de

educación superior, inclusive en el caso establecido en la Disposición

Transitoria Vigésima Segunda de la presente Ley.

29

PREGUNTA CIENTÍFICA A CONTESTARSE

¿Por qué es necesario la implementación de un servicio web como parte

fundamental de la capa de negocio del proyecto “ESTUDIO DE FACTIBILIDAD

PARA LA PROPUESTA”FRAMEWORK DE TRABAJO PARA PROYECTOS DE


SOFTWARE” ENFOCADO A LA ARQUITECTURA DE CAPA DE NEGOCIO”?

DEFINICIONES CONCEPTUALES

Web Services.- Es un servicio que se encuentra disponible y operativo en el

internet, el servicio web pude ejecutarse en cualquier plataforma permitiendo

interoperabilidad.

Capa de Negocio.- Contiene la lógica para la comunicación entre las capas de

presentación y la de base de datos ayudando así a la mejora de rendimiento en la

base de datos y usando la arquitectura de programación de capas.

JPA (Java Persistence API).- Es un API que permite el mapeo del modelo entidad

relación convirtiéndolos en objetos.

Ingeniería de software.- Son principios de la ingeniería que permiten el correcto

desarrollo de software mediante el uso de herramientas y normas.

SCRUM.- Es una metodología ágil, que permiten llevar a cabo el desarrollo de

sistemas, cuenta con interacciones que se los denomina sprint, cada sprint que se

entrega ofrece al usuario que tengan un producto funcional para que pueda ser

probado.

Interoperabilidad.- La interoperabilidad quiere decir la capacidad que tiene los

sistemas de trabajar con otras plataformas sin realizar cambios.

Kanban.- Es una herramienta de ayuda que permite controlar las tareas de

desarrollo mediante el uso de tableros y tarjetas, las cuales indicaran si el

30

desarrollador se encuentra sobrecargado de actividades, además facilitara al

desarrollador poder visualizar las tareas que tienen pendientes, las que se

encuentre realizando y las tareas que las tengan culminadas.

JBOSS.- Es un servidor de aplicaciones web, el cual permite subir las aplicaciones

web para que se encuentren habilitadas. En nuestro proyecto permite desplegar

nuestro servicio web para que se encuentre disponible.

Netbeans.- Esta plataforma permite el desarrollo de aplicaciones mediante el uso

de lenguajes de programación. Para este proyecto se usó este IDE de desarrollo

con el lenguaje de programación Java para poder implementar el servicio web.

3DES.- Es un algoritmo de encriptación con el uso de 3 llaves, este algoritmo

usualmente era usado para aplicaciones financieras.

Trello.- Es una aplicación web que permite la administración de las actividades

que se están llevando a cabo, esta herramienta se basa en la metodología

Kanban.

Erwin.- Es una herramienta que facilita la creación de los modelados de datos,

esta herramienta permite la generación de los scripts del modelo entidad relación

que se creó.

Soapui.- El soapui es una herramienta que permite realizar pruebas soap y

diferentes protocolos. Esta herramienta fue utilizada en el proyecto para la

verificación de los servicios del SEP se encuentren disponibles y funcionando.

Loggin(Log).- Es una herramienta que permite realizar bitácoras en las

aplicaciones, esto ayuda a la verificación del software al momento que se

encuentre activo y mediante esta herramienta poder visualizar si el software está

funcionando de manera correcta o tiene algún inconveniente.

31

CAPÍTULO III

PROPUESTA TECNOLÓGICA

Proveer un modelo entidad relación para uso exclusivo de la capa d negocio con

una estructura dinámica que le permita resolver los procedimientos que se

encuentren almacenados para la ejecución dinámica, así proporcionar un modelo

de persistencia mediante Java Persistence API (JPA) que proporcione mapear

las tablas de uso de la capa de negocio.

• Análisis de factibilidad

- Factibilidad Operacional

El proyecto es factible operacionalmente debido a que el desarrollo del mismo es

por la necesidad que existe para la conexión entre la capa de presentación y la

capa de datos.

Los usuarios se ven en la necesidad que exista la capa de negocio y estos mismos

usuarios han participado en la planeación y en el desarrollo del proyecto, por lo

que este proyecto es la solución al problema que ellos tienen.

- Factibilidad técnica Para determinar la factibilidad técnica del proyecto se detalla cómo se encuentra

conformado la capa de negocio.

Arquitectura de la Capa de Negocio.- La arquitectura de la capa de negocio va

a trabajar con el lenguaje JAVA para el desarrollo del servicio web, el cual va a

estar subida en un servidor de aplicaciones, esta servicio web es desarrollado por

un grupo de desarrolladores que denominados “Scrum Team”, así como vemos

en el Gráfico 9

32

Gráfico 9

Arquitectura de la Capa de Negocio


Fuente: Investigación y desarrollo del proyecto.

33

Modelo Entidad Relación de la capa de Negocio.- Para que el servicio web de

la capa de negocio pueda tener una parametrización de los procedimientos de la

capa de datos, se desarrolla un modelo entidad relación para que mediante este

modelo el servicio pueda hacer uso de él y pueda ejecutar los procedimientos sin

tener que compilar nuevamente el código fuente, así como lo vemos en el Gráfico

9.

Diagrama de clase de la Capa de Negocio.- Para que el servicio web pueda

conectarse a las tablas del MER desarrollado, se crea una capa adicional dentro

del servicio web, la misma que es una capa de persistencia. El diagrama de la

clase la podemos ver en el Gráfico 10.

34

Gráfico 10

Modelo Entidad Relación de la capa de negocio


Fuente: Investigación y desarrollo del proyecto.

35

Gráfico 11

Diagrama de clases de la Capa de Negocio


Fuente: Datos del Proyecto

36

Componentes de la capa de negocio.- Los componentes que interactúan con el

servicio web SEP (Servicio Ejecuta Procedimientos) serían el cliente que consume

el SEP, las tablas las cuales son de uso único del SEP y los procedimientos de la

capa de datos. Podemos apreciar en el Gráfico 12 el modelo de los componentes

del SEP.

Gráfico 12

Diagrama de componentes de la capa de negocio

Modelo SEP



37

Gráfico 13

Diagrama de flujo de la Capa de Negocio - SEP

INICIO

Request

Request

correcta

Obtener

Configuración de

BD

Configuración

Correcta

Generar script para

ejecutar proceso

Ejecuta Proceso

Proceso

Ejecutado

correctamente

Genera Response

con la respuesta

del proceso

Inserta ejecución

de Proceso

Inserta ejecución

en bitácora

Generar Response

de Error

FIN

NO

NO

NO

Obtener

Validaciones de

Usuarios

Usuario

correcto

NO



Flujo de la capa de negocio.- En el Gráfico 13. podemos apreciar el flujo

que tiene la capa de negocios, donde el servicio web comienza su flujo

transaccional con la llegada del request, este request contiene el xml con

los datos necesarios para la ejecución del servicio, el SEP realiza la

validación del xml donde si es incorrecto manda a grabar en la bitácora y

genera el xml del response terminando así el flujo; en caso de que el XML

fuera exitoso el SEP procederá a realizar las validaciones si es un usuario

correcto o incorrecto, en caso de que el fuera un usuario incorrecto termina

el flujo grabando una bitácora y generando el xml de response; en caso de

que el usuario fuera correcto el SEP revisa las configuraciones correctas

38

del xml, en caso de que fueran correctas generaría un script para la ejecución

del procedimiento para luego ejecutarlo, terminado esto el SEP obtiene la

información del proceso y genera el XML de response y lo envía al cliente que

ejecuto el request.

En el Gráfico 14 tenemos el diagrama de secuencia en el cual se puede ver la

como trabaja el servicio web y con qué componentes interactúa, así como los

procesos internos que realiza.

Gráfico 14

Diagrama de Secuencia

Elaborado por: Adolfo Enrique Sotomayor Sánchez

Fuente: Datos del proyecto

39

En el Gráfico 15 se detalla el diagrama de red servicio web, así como las capas

del JPA para que pueda interactuar con la base de datos.

Gráfico 15

Diagrama Detallado de Componentes



- Factibilidad Legal En el desarrollo del proyecto podemos decir que es factible legalmente, esto

debido a que las herramientas que se utilizaron para llevarlo a cabo son open

source, es decir utilizan licenciamiento GPL (Licencia Pública General de GNU).

El proyecto desarrollado cumple es un proyecto inédito siguiendo las directrices y

normas de las metodologías que se aplicaron.

40

- Factibilidad Económica

El desarrollo de este proyecto podemos decir que es factible económicamente

debido a que no hay ningún costo de licenciamiento en las herramientas que

fueron usadas a lo largo del desarrollo. El licenciamiento de las herramientas que

fueron usadas bajo la licencia GNU (Licencia Pública General).

CUADRO N. 3

Factibilidad Económica

NOMBRE

HERRAMIENTA

LICENCIA COSTO

NetBeans CDDL o GPL2 $0.00

Java Freeware $0.00

JBOSS LGPL $0.00

ERWIN Versión Trial $0.00

SQL SERVER Convenio con la

Universidad de

Guayaquil

$0.00



• Etapas de la metodología del proyecto

Las estepas en el desarrollo de este proyecto fueron divididas en 6 sprint,

mediante el uso de la metodología Scrum. A continuación se detalla de manera

resumida cada uno de los sprints de todo el proyecto con la duración de las

mismas.

https://en.wikipedia.org/wiki/CDDL

https://en.wikipedia.org/wiki/Freeware

https://es.wikipedia.org/wiki/GNU_Lesser_General_Public_License

41

CUADRO N. 4

Sprints definidos para el proyecto.

N° de Sprint

Fecha de Inicio

Fecha de Fin

Duración en

semanas Actividades

1 12-Ago-15 2-Sept-15 3 Análisis, Diseño y Desarrollo del sep y sec versión jdbc

2 3-Sept-15 25-Sept-

15 3

Análisis, Diseño y Desarrollo sep y sec versión jpa.

Soporte de configuraciones a los integrantes de la capa de datos y consumos de servicios a los integrantes de la capa visual

3 28-Sept-

15 9-Oct-15 2

Agregar validaciones de servicios, encriptación, instalación y pruebas de monitoreo con logstash y elastisearch y kibana. Soporte de configuraciones a los integrantes de la capa de datos y consumos de servicios a los integrantes de la capa visual

4 12-Oct-15 16-Oct-15 1

Mejoras con sonar, generación de gráficos de pastel y barra. Soporte de configuraciones a los integrantes de la capa de datos y consumos de servicios a los integrantes de la capa visual

5 19-Oct-15 23-Oct-15 1

Elaboración documentación, manual de usuario y actualización de manual de diseño.


6 26-Oct-15 30-Oct-15 1

Documento de Diseño y Desarrollo de la capa rest/json del sep y sec.



Fuente: Investigación, Levantamiento de Información.

Habiendo detallado de manera resumida los sprints, a continuación se detallan

cada uno de ellos con sus respectivas actividades realizadas:

42

Sprint 1.- Este sprint fue el inicial, antes de comenzar con el desarrollo del

proyecto se definieron actividades y se les asigno a cada uno de los integrantes

del grupo, esto dependiendo de los perfiles de desarrollador, en este sprint fue

donde se definió la lógica interna de trabajo y la elección de las herramientas que

se iban a utilizar a lo largo del proyecto.

A lo largo del sprint 1 se llevaron reuniones diarias de sincronización del equipo,

en las que se llevaba la metodología SCRUM, estas reuniones no eran más de 15

minutos y se realizaban las siguientes preguntas: ¿Qué he hecho?, ¿Qué voy

hacer? y ¿Qué impedimentos tengo para el desarrollo de la tarea?.

Las actividades que se desarrollaron fueron las siguientes:

Se desarrolló el modelo entidad relación que es de uso exclusivo para el

SEP (Servicio Ejecuta Procedimientos)

Se desarrolló el servicio web con el uso de JDBC, para que la capa de

presentación pueda hacer uso del mismo.

Se realizó el desarrollo de la lógica de Inserción del Histórico de la tabla

del SEP (Servicio Ejecuta Procedimiento)

Se realizó el desarrollo e Integración de la lógica de consulta de

configuración con la lógica ejecución de procedimientos de manera

automática y parametrizable desde las tablas del SEP.

Se realizó correcciones de servicio web SEP (Servicio Ejecuta

Procedimiento).

Se realizó la instalación en el servidor de desarrollo, para los cuales se

ejecutaron las siguientes actividades:

o Generación de Scripts para ejecución en ambiente de desarrollo

o Ejecución de scripts en base de datos

o Se desplego el war del SEP en el servidor Jboss.

o Se configuro el data source en desarrollo.

Pruebas con sep en desarrollo

Corrección de errores del sonar del sep e integración con log4j 2

o Cambiar impresiones por consola por un log

43

Quitar métodos que no están en uso

Comentarios de código

Cambiar nombre de variables siguiendo estándar de programación

Integración con log4j

Ingresar logs en excepciones controladas del sep

Gráfico 16

Resumen Sprint 1 con Trello


Fuente: Herramienta Trello para monitorear las actividades del desarrollo del proyecto

Sprint 2.- Este sprint fue la segunda interacción del proyecto, a diferencia del

primero en este sprint ya teníamos definidas las actividades por lo cual cada uno

ya sabía que debía hacer.

En este sprint también se llevaron a cabo las reuniones diarias de no más de 15

minutos, en los cuales se realizaba una sincronización del Scrum Team, en estas

reuniones se realizaban las siguientes preguntas: ¿Qué he hecho?, ¿Qué voy

hacer? y ¿Qué impedimentos tengo para el desarrollo de la tarea?

44

Las actividades desarrolladas en este sprint fueron las siguientes:

A lo largo de todo este sprint se brindó soporte a capa de datos y a la capa

de presentación para la integración con nuestro framework, durante este

soporte las actividades realizadas fueron las configuraciones de los

procedimientos que la capa de datos nos proporcionaban, esto para que

la capa de presentación pudiera hacer uso de los mismos.

Durante el desarrollo se corrigieron observaciones dadas por el primer

análisis de sonar hacia el SEP(Servicio Ejecuta Procedimientos), en el

informe inicial de sonar las correcciones fueron las siguientes:

o Se quitaron los métodos que no estaban en uso

o Se quitó los comentarios que se encontraban en el código.

o Se realizó el cambio para imprimir por consola mediante la

herramienta Log4j.

o Se cambiaron el nombre de variables siguiendo estándares de

programación

Se implementó la Integración con un sistema de bitácoras usando la

herramienta log4j

Se ubicó logs en las excepciones controladas del SEP

Se inició con la incorporación de encriptación a la claves que se guardaran

en las tablas del SEP

Se desarrolló un procedimiento almacenado, para la configuración de los

servicios del SEP. procedimiento

Durante este sprint se realizaron configuraciones y Validaciones de

Procedimientos utilizando el SP de configuración automática.

o Configuración de Servicio Login

o Configuración de Servicio Sp_consulta

o Configuración de Servicio Consulta Asistencia

o Configuración de Servicio Consulta Notas por estudiante por

materia

o Configuración de porcentaje Asistencia

Creación y actualización de documentos de Ejecución del SEP.

Creación de Documentación SEP

Se agrega a la documentación estructura del Método de Login.

45

Estructura de Consulta de Notas por estudiante

Estructura de Consulta de Asistencias

Estructura de Consulta Estudiantes por Materia por Profesor

Se agrega a la documentación los parámetros de salida para los mensajes

y códigos de error.

Estructura de porcentaje Asistencia

Se agregó la información de la ip del cliente y del server a la bitácora de tablas y

de archivo en el SEP

Se actualizó el formato de bitácora de archivo en el SEP

Gráfico 17

Actividades Sprint 1 con Trello


Fuente: Herramienta trello para monitorear las actividades del desarrollo del proyecto

Sprint 3.- Este sprint fue la tercera interacción del proyecto, las actividades que

estaban asignadas desde el sprint 1 fueron avanzando y continuando con los

desarrollos definidos.

46

Las actividades desarrolladas durante esta interacción fueron las que se detallan

a continuación:

A lo largo de todo este sprint 3 se brindó soporte a capa de datos y a la

capa de presentación para la integración con nuestro framework, durante

este soporte las actividades realizadas fueron las configuraciones de los



Soporte a capa visual para configuraciones de procedimientos.

o Configuraciones del Servicio: 19 – Anular Materias Registradas por

Ciclo - Carrera

o Configuraciones del Servicio: 21 – Mantenimiento Usuario

o Configuraciones del Servicio: 22 – Generar orden de Pago

o Configuraciones del Servicio: 23 – Consultar Estudiantes por

materia, por profesor, por Parcial

o Configuraciones del Servicio: 24 – Consulta Estudiantes por

materia, por profesor, por Parcial, por Notas, por estudiante

o Configuraciones del Servicio: 25 – Consultar Orden de Pago

Se agregó las encriptaciones de Usuario en el SEP usando 3DES con 3

llaves.

Se desarrolló una librería unificando con la encriptación para el uso del

SEP.

Se desarrolló un nuevo algoritmo para agregar las encriptaciones de

Usuario en el SEP usando blowfish

47

Gráfico 18




Sprint 4.- Este sprint fue la cuarta interacción del proyecto. Las actividades

realizadas durante esta interacción son las siguientes:






48

Gráfico 19




Sprint 5.- Este sprint fue la quinta interacción del proyecto, en las cuales se

definieron nuevas actividades y entregables funcionales para el equipo.

Las actividades realizadas durante esta interacción son las siguientes:

Se modifica el servicio web para que soporte el tipo de datos time.






Se desarrolló un script de partición de la tabla histórica de procedimientos.

Se realizaron pruebas de tabla histórica con las particiones.

Se desarrolló la lógica de la encriptación con el algoritmo blowfish.

Se desarrolló la lógica de la encriptación con el algoritmo 3DES.

Se unificaron los algoritmos en la librería para el uso del SEP.

Creación de método para ejecutar librería desde consola.

49

Gráfico 20




Sprint 6.- Este sprint fue la sexta y última interacción del proyecto, en estas

actividades realizadas fueron a necesidad del usuario, ya que fue donde se

desarrolló la documentación final y los manuales a entregar.

Las actividades realizadas durante esta interacción son las siguientes:






Se documentó el Manual de Usuario del SEP.

Se realizó soporte a capa de datos del SEP

Se agregaron en el modelo entidad relación del SEP comentarios a las

tablas y los campos.

50

Gráfico 21




• Entregables del proyecto

El proyecto cuenta con los siguientes entregables que se detallan a continuación:

Manual de Diseño del SEP

Manual de Usuario del SEP

Manuales de ejecución de los servicios.

Diagrama de Clase

Librería de Encriptación de Claves

Servicio Web SEP (.war)

51

CRITERIOS DE VALIDACIÓN DE LA PROPUESTA

Como política de aceptación del proyecto se deben cumplir la entrega de los seis

Sprint, los mismos que fueron evaluados y revisados por el Scrum Master del

grupo de la Capa de Negocio – Sr. Héctor Ortega.

Este criterio de validación será supervisado por la PMP – Srta. Iliane Vera; que

se encargará de validar y constatar que las pruebas se realicen de manera

efectiva.

Para poder validar que los datos devueltos por los procedimientos almacenados

sean correctos se constató conjuntamente con el Scrum Master de la Capa de

Datos - Srta. Cinthya Rivadeneira.

Dentro de las validaciones realizadas se verifico que los datos que el servicio web

devolvía a la capa visual se verificaron con el Scrum Master de la Capa Visual -

Sr. Juan Carlos Tamayo.

Así mismo al finalizar todos los Sprint, la app desarrollada pasará a un grupo de

pruebas asignado para el proyecto, dando por terminada la validación de la

propuesta; esto será realizado por – Srta. Anabell Tingo

CRITERIOS DE ACEPTACIÓN

Se certifica que una vez terminado la etapa de verificación y pruebas finales del

proyecto ESTUDIO DE FACTIBILIDAD PARA LA PROPUESTA "FRAMEWORK

DE TRABAJO PARA PROYECTOS DE TITULACIÓN APLICANDO

METODOLOGÍA SCRUM EN LA INGENIERÍA DE SOFTWARE" ENFOCADO A

LA ARQUITECTURA CAPA DE NEGOCIO DESARROLLANDO UN MODELO

ENTIDAD RELACIÓN QUE PERMITA SOPORTAR Y CONFIGURAR

PROCEDIMIENTOS ALMACENADOS PARA SU EJECUCIÓN DESDE UN

SERVICIO WEB, los elementos verificados no contienen errores

52

Por lo que se certifica que el modelo entidad relación desarrollado cuenta con la

lógica dinámica para que el SEP pueda realizar la ejecución de los procedimientos

almacenados que se encuentren en la capa de datos.

Presentando un modelo entidad relación con un servicio web en el cual es

parametrizable para la ejecución de procedimientos almacenados de manera

dinámica; teniendo un servicio web que puede ser consumido por cualquier

aplicación o sistema.

CUADRO N. 5

Criterios de Aceptación

Responsables

Firma

Scrum Master Capa de Negocio

Sr. Héctor Ortega

Product Mananger

Srta. Iliana Vera

Scrum Master Capa de Negocio

Srta. Cinthya Rivadeneira.

Tester

Sr. Anabell Tingo

Elaborado: Adolfo Enrique Sotomayor Sánchez

Fuente: Datos de la investigación

53

JUICIO DE EXPERTOS

En la propuesta que fue presentada a la PMP del Scrum Team de todo el proyecto

se indica el alcance del proyecto y la necesidad que existe para la implementación

de un modelo entidad relación para uso del servicio web perteneciente a la capa

de negocio.

Como PMP del proyecto se realizó de parte de ella el seguimiento y control de las

actividades correspondientes al alcance.

Se indicó a la líder de la capa de datos con sus conocimientos sea ella que

monitorice que los resultados de la ejecución de la capa de datos sean los

correctos y estos datos sean íntegros con respecto a la información devuelta por

los procedimientos almacenados.

PLAN DE PRUEBAS

CUADRO N. 6

Cuadro del Plan de Pruebas

Actividad Escenario de prueba

Resultado esperado

Resultado obtenido

Observaciones

Verificar tablas del SEP

Ingresar datos en las tablas de la configuración del SEP y verificar que se encuentren correctamente relacionadas.

Todas las tablas se encuentran correctamente relacionadas.

Los resultados fueron los esperados

Sin novedades.

Configuraciones de nuevos servicios.

Crear una nueva configuración en las tablas del SEP y luego enviar peticiones xml al servicio web.

Comunicación con la base de datos debe ser transparente y debe ejecutar el procedimiento de manera satisfactoria.


Sin novedades.

Configuración de nuevo servicio

Crear una nueva configuración

La ejecución del servicio web debe devolver

Los resultados

Sin novedades.

54

usando la herramienta automática.

de un servicio usando el SP que crea automáticamente, luego enviar una petición al servicio web.

todos los valores esperados del procedimiento almacenado de la capa de negocio.

fueron los esperados

Validación de usuarios del SEP.

Enviar peticiones con usuarios correctos e incorrectos al servicio web.

Usuarios correctos la validación debe ser exitosa, los incorrectos no debe permitir la ejecución.

Los resultados fueron los esperados.

Sin novedades.

Validación de roles de usuarios del SEP.

Enviar peticiones con roles de usuarios asociados y no asociados a los servicios.

Los roles que no tengan permisos no debe permitirse la ejecución.


Sin novedades.

Validación de Servicios no activos.

Enviar peticiones de servicios que no se encuentren activos en el SEP.

Los servicios no activos de debe permitirse la ejecución.


Sin novedades.

Pruebas de estrés el en servicio web.

Realizar carga transaccional al servicio web de procedimientos.

El servicio web mantuvo tiempos de respuestas aceptables.


Sin novedades.

Elaboración: Adolfo Enrique Sotomayor Sánchez Fuente: Plan de Pruebas del proyecto

55

ANÁLISIS DE CÓDIGO

Para poder validar que el proyecto cumpla con los requerimientos y los estándares

de programación, se usó la herramienta de SONAR para poder realizar un análisis

de nuestro código, para ello se analizaron los proyectos del SEP en sus diferentes

versiones en el transcurso del proyecto, el servicio web con el uso de JDBC y JPA.

En el Gráfico 22 podremos apreciar el informe del análisis con el proyecto con

JDBC.

Gráfico 22

Análisis de Código JDBC


Fuente: Desarrollo del proyecto – Análisis de Código

56

En el Gráfico 23 podremos apreciar el informe del análisis con el proyecto con

JPA.

Gráfico 23

Análisis de Código JPA


Fuente: Desarrollo del proyecto – Análisis de Código

RESULTADO DE LAS ENCUESTAS

Las encuestas se encuentran dirigidas a los participantes del proyecto, debido y

con la información recopilada podremos apreciar los criterios de validación de la

propuesta.

Detallamos los resultados de las encuestas realizadas a los usuarios del servicio.

57

PREGUNTA 1

¿Está usted de acuerdo con que exista una capa de negocio que conecta las

capas de presentación con la capa de datos?

CUADRO N. 7

Pregunta 1 - Encuesta

Pregunta % Totalmente

de acuerdo % De

acuerdo % En

desacuerdo % Totalmente en desacuerdo

1 82,76% 17,24% 0,00% 0,00%

Elaboración: Adolfo Enrique Sotomayor Sánchez Fuente: Resultados de la encuesta realizada mediante https://es.surveymonkey.com

Gráfico 24



Fuente: Resultados de la encuesta realizada mediante https://es.surveymonkey.com

Análisis.- Como podemos observar en los resultados, del total de 29 personas

encuestadas que participan en el proyecto, el número de usuarios que

respondieron que están “totalmente de acuerdo” con la existencia de una capa de

negocio que comunique a las capas de presentación y la capa de datos fue el

82,76%, el porcentaje de usuarios que respondieron que están “de acuerdo” fue

el 17,24%, por tanto vemos que la mayoría de los encuestados se encuentran a

favor de la existencia de la capa de negocio.

Pregunta 1

% Totalmente de acuerdo % De acuerdo

% En desacuerdo % Totalmente en desacuerdo

58

PREGUNTA 2

¿Está usted de acuerdo con que el servicio web maneje tablas de configuración

para la parametrización de los procedimientos?

CUADRO N. 8

Pregunta 2 – Encuesta


de acuerdo % De

acuerdo % En


2 62,07% 34,48% 3,45% 0,00%



Gráfico 25






respondieron que están “totalmente de acuerdo” con la existencia de una capa de

negocio que comunique a las capas de presentación y la capa de datos fue el

62,07%, el porcentaje de usuarios que respondieron que están “de acuerdo” fue

el 34,48%, y los usuarios que respondieron que están “en desacuerdo” fue el

3,45% por tanto vemos que el 96,55% de los encuestados se encuentran a favor

de que el servicio web maneja parametrizaciones en las tablas para la ejecución

automática de los procedimientos almacenados de la capa de datos.

Pregunta 2



https://es.surveymonkey.com/

59

PREGUNTA 3

¿Está usted de acuerdo con que exista una herramienta de configuración

automática de los servicios de la capa de negocio?

CUADRO N. 9

Pregunta 3 – Encuesta

Pregunta % Si % No

3 93,10% 6,90%



Gráfico 26






respondieron que están de acuerdo con la existencia de una herramienta de

configuración de servicios automática fue del 93,10%, el porcentaje de usuarios

que respondieron no estaba de acuerdo fue el 6,90%, por tanto vemos que la

mayoría se encuentra a favor de la existencia de esta herramienta para la

configuración automática de los servicios.

Pregunta 3

% Si % No

60

PREGUNTA 4

¿Está usted de acuerdo con que la capa de negocio tenga implementado JPA en

el servicio web?

CUADRO N. 10



de acuerdo % De

acuerdo % En


4 55,17% 44,83% 0,00% 0,00%


Gráfico 27






respondieron que están “totalmente de acuerdo” que el servicio web utilice JPA

fue el 55,17%, el porcentaje de usuarios que respondieron que están “de acuerdo”

fue el 44,83%, por tanto vemos que el 100% de los encuestados se encuentran a

favor de que el servicio web maneja una capa de JPA.

Pregunta 4



61

PREGUNTA 5

¿Indique el grado de complejidad al momento de configurar un nuevo servicio en

la capa de negocio?

CUADRO N. 11


Pregunta % Fácil % Medio % Difícil

5 35,71% 60,71% 3,57%


Gráfico 28





encuestadas que participan en el proyecto, al preguntarle sobre la dificultad de

configurar los servicios en el SEP, el número de usuarios que respondieron que le

pareció “fácil” fue el 35,71%, el porcentaje de usuarios que respondieron que la

dificultad es “media” fue el 60,71%, y el porcentaje de usuarios que respondieron

que la dificultad es “difícil” fue el 3,57%, por tanto podemos apreciar que la no

tuvieron mayor dificultad al momento de realizar las configuraciones en el servicio

web.

Pregunta 5

% Fácil % Medio % Difícil

62

PREGUNTA 6

¿Indique el grado de disponibilidad luego de la configuración del servicio en la

capa de negocio?

CUADRO N. 12


Pregunta % Alto % Medio % Bajo

6 64,29% 35,71% 0,00%


Gráfico 29





encuestadas que participan en el proyecto, al preguntarle sobre disponibilidad

luego de haber configurado el servicio, el número de usuarios que respondieron

que tuvieron disponibilidad “alta” fue el 64,29%, el porcentaje de usuarios que

respondieron que la disponibilidad es “media” fue el 35,71%, y el porcentaje de

usuarios que respondieron que la disponibilidad estuvo “baja” fue el 0,00%, por

tanto podemos que después de haber configurado el servicio la disponibilidad es

alta.

Pregunta 6

% Alto % Medio % Bajo

63

PREGUNTA 7

¿Tuvo algún inconveniente al momento de configurar los servicios en la capa de

negocio?

CUADRO N. 13


Pregunta % Si % No

7 35,71% 64,29%


Gráfico 30






respondieron no tuvo inconvenientes al configurar un servicio fue del 64,29%, el

porcentaje de usuarios que respondieron si hubieron dificultades fue el 35,71%,

por tanto vemos que la mayoría no se encontró con problemas al configurar los

servicios del SEP.

Pregunta 7

% Si % No

64

PREGUNTA 8

¿Cómo calificaría el funcionamiento de la capa de negocio luego de la

configuración de los servicios?

CUADRO N. 14


Pregunta Excelente Bueno Regular Malo Muy malo

8 60,71% 39,29% 0,00% 0,00% 0,00%


Gráfico 31






respondieron que están después de haber configurado el servicio el

funcionamiento del SEP es “excelente” fue el 60,71% el porcentaje de usuarios

que respondieron que están el funcionamiento del SEP es “bueno” fue el 39,29%,

por lo tanto podemos ver que con la parametrización del servicio web luego de

haber configurado ayuda al usuario a tener un mejor servicio.

Pregunta 8

Excelente Bueno Regular Malo Muy malo

65

CAPÍTULO IV

Criterios de aceptación del producto o Servicio

Como política de aceptación del proyecto se deben cumplir los seis sprint

CUADRO N. 15

Niveles de Cumplimiento por sprint

SPRINT NIVEL DE

CUMPLIMENTO

Sprint 1

100% Análisis, Diseño y Desarrollo del SEP y SEC

versión JDBC

Sprint 2

100%

Análisis, Diseño y Desarrollo SEP y SEC versión

JPA.

Soporte de configuraciones a los integrantes de

la capa de datos y consumos de servicios a los

integrantes de la capa visual

Sprint 3

100%

Agregar validaciones de servicios, encriptación,

instalación y pruebas de monitoreo con logstash

y elastisearch y kibana. soporte de

configuraciones a los integrantes de la capa de

datos y consumos de servicios a los integrantes

de la capa visual

Sprint 4

100%

Mejoras con sonar, generación de gráficos de

pastel y barra. soporte de configuraciones a los

integrantes de la capa de datos y consumos de

servicios a los integrantes de la capa visual

66

Sprint 5

100%

Elaboración documentación, manual de usuario

y actualización de manual de diseño.




Sprint 6

100%

Documento de Diseño y Desarrollo de la capa

rest/json del SEP y SEC.




Elaboración: Adolfo Enrique Sotomayor Sánchez Fuente: Plan de Pruebas del proyecto

67

CONCLUSIONES

Podemos concluir que en la implementación realizada de una capa de negocio

dinámica para la ejecución de procedimientos ayuda y mejora los tiempos de

ejecución y entrega de productos.

Tener un framework de trabajo que se incorpore a cualquier sistema y así poder

manejar alta disponibilidad al momento de cambios en la capa de datos, siendo

este framework un marco de trabajo y mejorando los modelos de programación.

Conseguir que la capa de negocio pueda ejecutar procedimientos almacenados

de la capa de datos de manera automática, mediante la configuración de los

mismos, ganando agilidad en los procesos y mejoras en tiempos de desarrollo

teniendo un framework estable.

Al hacer uso de metodologías ágiles scrum podemos concluir que si se puede

aplicar este tipo de metodologías en el desarrollo de aplicaciones, siendo este tipo

de metodologías muy útiles y prácticas ya que ayudan al desarrollador para no

sobrecargarse de actividades y mejorando la productividad.

Con este tipo de metodologías scrum

68

RECOMENDACIONES

En el servicio web SEP (Servicio Ejecuta procedimiento) de la capa de negocio

recomendamos los siguientes puntos:

Continuar con el uso de metodologías ágiles Scrum para mejoras en el

servicio web.

Continuar con el uso de la herramienta Trello para el control de las

actividades a realizar.

Que el servicio web use un mecanismo de autenticación como header en

el xml.

Realizar una interfaz web que permita administrar la configuración de los

servicios del SEP.

En el servicio web implementar modo asincrónico al momento de guardar

en la tabla histórica.

69

BIBLIOGRAFÍA

Andalucia, J. d. (s.f.). Marco de Desarrollo de la Junta de Andalucia. Obtenido de

http://www.juntadeandalucia.es/servicios/madeja/contenido/subsistemas/

arquitectura/capa-negocio

Erwin. (s.f.). Erwin. Obtenido de http://erwin.com/products/data-modeler

Gupta, S. (s.f.). Pro apache log4j . Apress.

Interoperability. (s.f.). Interoperability. Obtenido de http://interoperability-

definition.info/es/

Keith, M., & Schnicariol, M. (2009). Pro JPA 2. Apress.

MARTÍNEZ VILLALOBOS, G., CAMACHO SÁNCHEZ, G. D., & BIANCHA

GUTIÉRREZ, D. A. (2010). DISEÑO DE FRAMEWORK WEB PARA EL

DESARROLLO DINÁMICO DE APLICACIONES. Scientia Et Technica

2010 XVI(44), 178-183.

Moquillaza Henríquez, S. D., Vega Huerta, H., & Guerra Grados, L. (s.f.).

Programación en N capas. Revista de Ingeniería de Sistemas e

Informática vol. 7, N.º 2, Julio - Diciembre 2010, 57-67.

Netbeans. (s.f.). Netbeans. Obtenido de

https://netbeans.org/features/platform/all-docs.html

Oracle. (s.f.). Oracle. Obtenido de

http://www.oracle.com/technetwork/java/javaee/tech/persistence-jsp-

140049.html

O'Reilly. (2002). Web Services Essentials.

Pressman, R. S. (2010). Ingeniería del Software, Un enfoque práctico. McGraw-

Hill.

Schwaber, K., & Sutherland, J. (2013). La Guía de Scrum.

SOAPUI. (s.f.). SOAPUI. Obtenido de http://www.soapui.org/about-soapui/what-

is-soapui-.html

Sommerville, I. (s.f.). Ingeniería del Software. Pearson Educacion S.A.

Stallings, W. (2004). Fundamentos de seguridad en redes: aplicaciones y

estándares. Pearson Educación s.a.

Wikipedia. (s.f.). Wikipedia. Obtenido de

https://es.wikipedia.org/wiki/Kanban_(desarrollo)

70

Wikipedia. (s.f.). Wikipedia Blowfish. Obtenido de

https://es.wikipedia.org/wiki/Blowfish

Wikipedia. (s.f.). Wikipedia Jboss. Obtenido de https://es.wikipedia.org/wiki/JBoss

71

ANEXO 1

BASES ENCUESTA

72

Gráfico 32

Total Encuestas Realizadas


Fuente: Resultado Encuestas desde: es.surveymonkey.com

73

Gráfico 33

Resultados de surveymonkey de pregunta 1



74

Gráfico 34




75

Gráfico 35




76

Gráfico 36




77

Gráfico 37




78

Gráfico 38




79

Gráfico 39




80

Gráfico 40




81

ANEXO 2

ENCUESTA

82

Universidad de Guayaquil Facultad de Ciencias Matemáticas y Físicas

Carrera de Ingeniería en Sistemas Computacionales Carrera de Ingeniería en Networking y Telecomunicaciones

ENCUESTA DEL PROYECTO DE TITULACIÓN

ENCUESTA DEL PROYECTO: ESTUDIO DE FACTIBILIDAD PARA LA



SOFTWARE" ENFOCADO A LA ARQUITECTURA CAPA DE NEGOCIO


SOPORTAR Y CONFIGURAR PROCEDIMIENTOS ALMACENADOS PARA SU

EJECUCIÓN DESDE UN SERVICIO WEB.

NOMBRE ENCUESTA: CAPA DE NEGOCIO/WEB SERVICES-JPA SEP

1. ¿Está usted de acuerdo con que exista una capa de negocio que conecta

las capas de presentación con la capa de datos?

Totalmente de acuerdo

De acuerdo

En desacuerdo

Totalmente en desacuerdo

2. ¿Está usted de acuerdo con que el servicio web maneje tablas de

configuración para la parametrización de los procedimientos?


De acuerdo

En desacuerdo


3. ¿Está usted de acuerdo con que exista una herramienta de configuración

automática de los servicios de la capa de negocio?

Si

No

83

4. ¿Está usted de acuerdo con que la capa de negocio tenga implementado

JPA en el servicio web?


De acuerdo

En desacuerdo


5. ¿Indique el grado de complejidad al momento de configurar un nuevo

servicio en la capa de negocio?

Fácil

Medio

Difícil

6. ¿Indique el grado de disponibilidad luego de la configuración del servicio

en la capa de negocio?

Alto

Medio

Bajo

7. ¿Tuvo algún inconveniente al momento de configurar los servicios en la

capa de negocio?

Si

No

8. ¿Cómo calificaría el funcionamiento de la capa de negocio luego de la

configuración de los servicios?

Excelente

Bueno

Regular

Malo

Muy malo

84

ANEXO 3

MANUAL DE USUARIO DEL SEP

85

––

86

Objetivo

Presentar una guía sencilla para el usuario explicando el funcionamiento del

servicio web del SEP (Servicio Ejecuta Procedimientos) y las configuraciones

necesarias para el correcto funcionamiento.

87

Manual de Usuario del SEP.

Explicación de las Tablas

A continuación se detallan las tablas usadas en el SEP con sus respectivas

definiciones:

Definición de la tabla sep_grupos_servicios

Esta tabla agrupa los servicios para tener una administración de las

configuraciones de procedimientos que se encuentren activos.

Gráfico 41

Tabla del SEP – sep_grupo_servicios

Elaborado por: Adolfo Enrique Sotomayor Sánchez Fuente: Datos del proyecto

88

Definición de la tabla sep_historial_objetos

Esta tabla graba un registro de las ejecuciones realizadas al SEP, aquí se

grabara la información de los parámetros recibidos y los parámetros

devueltos así como si la ejecución fue exitosa o no.

Gráfico 42

Tabla del SEP – sep_historial_objetos


89

Definición de la tabla sep_objetos_bd

En esta tabla se encuentra el nombre de los procedimientos que va a

ejecutar el servicio web.

Gráfico 43

Tabla del SEP – sep_objetos_bd



Definición de la tabla sep_parametros_objetos_bd

En esta tabla tendremos las configuraciones de cada uno de los

parámetros de los procedimientos.

Gráfico 44

Tabla del SEP – sep_parametros_objetos_bd


90

Definición de la tabla sep_roles

En esta tabla se graban los roles que tendrá el SEP.

Gráfico 45

Tabla del SEP – sep_roles


Definición de la tabla sep_servicio_roles

En esta tabla contiene los permisos que tendrá cada rol para la ejecución

del servicio.

Gráfico 46

Tabla del SEP – sep_servicio_roles



91

Definición de la tabla sep_servicio_usuarios

En esta tabla contiene los permisos que tendrá directamente cada usuario

para la ejecución del servicio.

Gráfico 47

Tabla del SEP – sep_servicio_usuarios


Definición de la tabla sep_servicios

En esta tabla contiene los servicios que se encuentran configurados para

la ejecución del procedimiento de la base de datos.

Gráfico 48

Tabla del SEP – sep_servicios


92

Definición de la tabla sep_tipos_datos

En esta tabla se encuentran las configuraciones de los tipos de datos de

cada uno de los parámetros de los procedimientos configurados.

Gráfico 49

Tabla del SEP – sep_tipo_datos


Definición de la tabla sep_usuarios

En esta tabla se encuentran los usuarios configurados para la ejecución

del servicio del SEP.

Gráfico 50

Tabla del SEP – sep_usuarios


93

Configuración de Un nuevo Servicio

Existen dos formar de configurar los servicios en el SEP, de manera

manual y de manera automática, a continuación detallamos cada una de

ellas:

Configuración de Servicio Manual

Para realizar la configuración manualmente debemos seguir el siguiente

orden de inserción en las tablas:

procedimiento.sep_objetos_bd

procedimiento.sep_servicios

procedimiento.sep_parametros_objetos_bd

A continuación se adjunta un ejemplo de la inserción de datos en las tablas

del SEP (Servicio Ejecuta Procedimientos)

CUADRO N. 16

Script de ejemplo – configuración de servicio

/* sep_objetos_bd */ INSERT [procedimiento].[sep_objetos_bd] ([id_objeto_bd], [nombre_objeto], [descripcion], [cantidad_parametros]) VALUES (10, N'sp_Consulta_Asistencias_Estudiantes', N'Consulta la asistencia de los estudiantes', N'12') /* sep_servicios */ INSERT [procedimiento].[sep_servicios] ([id_servicio], [nombre], [descripcion], [fecha_desde], [fecha_hasta], [estado], [autenticacion], [id_objeto_bd], [id_grupo_servicio]) VALUES (9, N'Consultar Asistencias de Estudiantes', N'Permite al profesor consultar la Asistencia de los Estudiantes', CAST(N'2015-09-15' AS Date), NULL, N'1', N'S', 10, 2) /* sep_parametros_objetos_bd */ INSERT [procedimiento].[sep_parametros_objetos_bd] ([id_parametro_objeto_bd], [nombre_parametro], [descripcion], [entrada_salida], [orden], [id_tipo_dato], [id_objeto_bd]) VALUES (50, N'pv_fechaInicio', N'Descripcion @pv_fechaInicio', N'E', 1, 2, 10) INSERT [procedimiento].[sep_parametros_objetos_bd] ([id_parametro_objeto_bd], [nombre_parametro], [descripcion], [entrada_salida], [orden], [id_tipo_dato], [id_objeto_bd]) VALUES (51, N'pv_fechaFin', N'Descripcion @pv_fechaFin', N'E', 2, 2, 10)

94

INSERT [procedimiento].[sep_parametros_objetos_bd] ([id_parametro_objeto_bd], [nombre_parametro], [descripcion], [entrada_salida], [orden], [id_tipo_dato], [id_objeto_bd]) VALUES (52, N'pi_idProfesor', N'Descripcion @pi_idProfesor', N'E', 3, 1, 10) INSERT [procedimiento].[sep_parametros_objetos_bd] ([id_parametro_objeto_bd], [nombre_parametro], [descripcion], [entrada_salida], [orden], [id_tipo_dato], [id_objeto_bd]) VALUES (53, N'pi_idMateria', N'Descripcion @pi_idMateria', N'E', 4, 1, 10) INSERT [procedimiento].[sep_parametros_objetos_bd] ([id_parametro_objeto_bd], [nombre_parametro], [descripcion], [entrada_salida], [orden], [id_tipo_dato], [id_objeto_bd]) VALUES (54, N'pi_idParalelo', N'Descripcion @pi_idParalelo', N'E', 5, 1, 10) INSERT [procedimiento].[sep_parametros_objetos_bd] ([id_parametro_objeto_bd], [nombre_parametro], [descripcion], [entrada_salida], [orden], [id_tipo_dato], [id_objeto_bd]) VALUES (55, N'pi_anio', N'Descripcion @pi_anio', N'E', 6, 1, 10) INSERT [procedimiento].[sep_parametros_objetos_bd] ([id_parametro_objeto_bd], [nombre_parametro], [descripcion], [entrada_salida], [orden], [id_tipo_dato], [id_objeto_bd]) VALUES (56, N'pi_ciclo', N'Descripcion @pi_ciclo', N'E', 7, 1, 10) INSERT [procedimiento].[sep_parametros_objetos_bd] ([id_parametro_objeto_bd], [nombre_parametro], [descripcion], [entrada_salida], [orden], [id_tipo_dato], [id_objeto_bd]) VALUES (57, N'px_Salida', N'Descripcion @px_Salida', N'S', 8, 5, 10) INSERT [procedimiento].[sep_parametros_objetos_bd] ([id_parametro_objeto_bd], [nombre_parametro], [descripcion], [entrada_salida], [orden], [id_tipo_dato], [id_objeto_bd]) VALUES (58, N'PI_ESTADO', N'Descripcion @PI_ESTADO', N'S', 9, 1, 10) INSERT [procedimiento].[sep_parametros_objetos_bd] ([id_parametro_objeto_bd], [nombre_parametro], [descripcion], [entrada_salida], [orden], [id_tipo_dato], [id_objeto_bd]) VALUES (59, N'PV_MENSAJE', N'Descripcion @PV_MENSAJE', N'S', 10, 2, 10) INSERT [procedimiento].[sep_parametros_objetos_bd] ([id_parametro_objeto_bd], [nombre_parametro], [descripcion], [entrada_salida], [orden], [id_tipo_dato], [id_objeto_bd]) VALUES (60, N'PV_CODTRANS', N'Descripcion @PV_CODTRANS', N'S', 11, 2, 10) INSERT [procedimiento].[sep_parametros_objetos_bd] ([id_parametro_objeto_bd], [nombre_parametro], [descripcion], [entrada_salida], [orden], [id_tipo_dato], [id_objeto_bd]) VALUES (61, N'PV_MENSAJE_TECNICO', N'Descripcion @PV_MENSAJE_TECNICO', N'S', 12, 2, 10)


Configuración de Servicio Automático

Para configurar un nuevo servicio de manera automática es necesario

ejecutar el siguiente procedimiento almacenado:

crea_servicio_procedimiento_aut

A continuación se explica los parámetros de entrada para la ejecución del

procedimiento:

95

CUADRO N. 17

Parámetros de Entrada en del procedimiento automático

Parámetros de Entrada del Procedimiento


Nombre Descripción

@nombre_servicio Ingresar el nombre con el cual identificaremos

al servicio.

@descripcion_servicio Ingresar una descripción del Servicio a

configurar.

@nombre_objeto Se deberá ingresar el nombre del

procedimiento que se requiera configurar.

@descripcion_objeto Descripción del procedimiento almacenado.

@id_grupo Id del grupo al que se va a pertenecer el

servicio.


CUADRO N. 18

Parámetros de Salida en del procedimiento automático

Parámetros de Salida del Procedimiento


Nombre Descripción

@id_servicio Id del Servicio con que se registró el servicio en la

tabla sep_servicios.

@id_objeto Id del objeto con que se registró el nombre del

procedimiento en la tabla sep_objetos_bd.

@codigo_salida Código de ejecución del procedimiento de

servicios.

@mensaje_salida Mensaje de ejecución del procedimiento.


96

Se adjunta ejemplo de ejecución del procedimiento almacenado.

CUADRO N. 19

Script de ejecución de procedimiento almacenado

USE [saug] GO DECLARE @return_value int, @id_servicio int, @id_objeto int, @codigo_salida int, @mensaje_salida varchar(max) EXEC @return_value = [dbo].[crea_servicio_procedimiento_aut] @nombre_servicio = N'Graba Horario Manual Profesor', @descripcion_servicio = N'Graba el horario Manuel profesor', @nombre_objeto = N'sp_Graba_Horario_Manual_Profesor', @descripcion_objeto = N'Permite Grabar el horario del profesor.', @id_grupo = 4, @id_servicio = @id_servicio OUTPUT, @id_objeto = @id_objeto OUTPUT, @codigo_salida = @codigo_salida OUTPUT, @mensaje_salida = @mensaje_salida OUTPUT SELECT @id_servicio as N'@id_servicio', @id_objeto as N'@id_objeto', @codigo_salida as N'@codigo_salida', @mensaje_salida as N'@mensaje_salida' SELECT 'Return Value' = @return_value GO


Requisitos necesarios para activar el Servicio

Al terminar el registro del servicio se deberá dar el grant del procedimiento

que se configuro.

A continuación se detalla la sentencia a ejecutar:

CUADRO N. 20

Sentencia de ejemplo asignación de permisos.

grant execute on nombre_del_procedimiento to nombre_de_usuario;


97

Configuración de Un nuevo usuario con encriptación.

Existen dos métodos para la encriptación del password de los usuarios, se

detalla cada uno de ellos, aunque el que se usa es el 3DES.

Configuración password Encriptado con 3DES

Para Encriptar el password del usuario con el método 3DES se debe

ejecutar mediante consola la librería saug_1_0.jar.

La línea de ejecución en el CMD es la siguiente:

CUADRO N. 21

Ejecución del jar en modo consola 3DES

java -jar saug_1_0.jar "D" "ClaveEnClaro" "91BA835FD6CD6A1C" "D59B3CA154FC1BCE" "D59B3CA154FC1BCE"


A continuación se detalla cada parámetro para la ejecución de la librería

por consola:

Primer Parámetro.- Indica el tipo de encriptación, deberá ir el valor

“D” que indica que es 3DES

Segundo Parámetro.- Deberá ir la clave que se requiere encriptar.

Tercer Parámetro.- Llave 1 de encriptación en hexadecimal, la

longitud es de 16 caracteres.

Cuarto Parámetro.- Llave 2 de encriptación en hexadecimal, la


Quinto Parámetro.- Llave 3 de encriptación en hexadecimal, la


Configuración password Encriptado con BLOWFISH

Para Encriptar el password del usuario con el método blowfish se debe

ejecutar mediante consola la librería saug_1_0.jar.

La línea de ejecución en el CMD es la siguiente:

98

CUADRO N. 22

Ejecución del jar en modo consola blowfish

java -jar saug_1_0.jar "B" "claveEnClaro" "1jherp9jnfrjqp" "1fgt7uj8"


A continuación se detalla cada parámetro para la ejecución de la librería

por consola:

Primer Parámetro.- Indica el tipo de encriptación, deberá ir el valor

“B” que indica que es blowfish.

Segundo Parámetro.- Deberá ir la clave que se requiere encriptar.

Tercer Parámetro.- Llave 1 de encriptación, la longitud máxima es

de 14 caracteres.

Cuarto Parámetro.- Llave 2 de encriptación, la longitud es de 8

caracteres.

99

Verificación que el Servicio se encuentre configurado y

activo.

Prueba del nuevo servicio haciendo uso del soapui

Cuando el servicio este configurado en las tablas del SEP, se deberá

realizar la prueba con la herramienta SOAPUI, a continuación se anexa un

ejemplo de la ejecución del servicio:

Gráfico 51

Ejecución de Servicio del SEP

Elaborado por: Adolfo Fuente: Datos del proyecto

100

Revisión de Bitácora por éxito y por error en tablas y en

log de archivo

Para la revisión de las bitácoras en las tablas del SEP se debe distinguir por los

siguientes qwerys:

CUADRO N. 23

Revisión de bitácoras por error y éxito

Revisión por éxito

select * from saug.procedimiento.sep_historial_objetos where codigo_salida = 0

Revisión por error

select * from saug.procedimiento.sep_historial_objetos where codigo_salida != 0


Para la revisión de las bitácoras en el archivo log del SEP, se deberá tomar en

cuenta los siguientes parámetros:

Ruta del Archivo: /opt/jboss-as-7.1.1.Final/standalone/log/SEP

Nombre del Archivo: sepJPA.log

101

Errores comunes

A continuación se presentan los errores comunes al trabajar con los servicios del

SEP.

No se dieron los permisos al usuario.

Se modificaron (agregaron o eliminarlos) los parámetros del servicio pero

no se actualizo la cantidad de parámetros en la tabla sep_objetos_bd.

No se encuentra configurado correctamente el dataSource.

Están enviando los parámetros incorrectos.

Preguntas Frecuentes

A continuación se detallan las preguntas que se presentan frecuentemente en la

comunicación con el SEP (Servicio Ejecuta Procedimientos).

¿Si se actualiza un procedimiento es necesario volver a configurar la

parametrización en el SEP?

Sí, es necesario volver a actualizar en la tabla de parámetros, los últimos

que se agregaron en el procedimiento. No olvidar también que en la tabla

objetos se debe actualizar el número de parámetros.

Documents

UNIVERSIDAD DE GUAYAQUILrepositorio.ug.edu.ec › bitstream › redug › 11494 › 1 › PTG-B-CISC...VII CERTIFICADO DE ACEPTACIÓN DEL TUTOR En mi calidad de Tutor del proyecto