UNIVERSIDAD NACIONAL DE TRUJILLO

FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS

ESCUELA ACADEMICO PROFESIONAL DE INFORMÁTICA

“SOLUCIÓN INFORMÁTICA DE HOMOLOGACIÓN E INTEGRACIÓN DE DATOS

PARA MEJORAR EL PROCESO DE REGISTRO DE ALUMNOS EN LA
UNIVERSIDAD NACIONAL DE TRUJILLO”

TESIS PARA OPTAR POR EL TÍTULO DE

INGENIERO INFORMÁTICO

AUTOR:

Saráchaga Díaz, Raúl Martín

ASESOR:

Guevara Ruiz, Ricardo Manuel

TRUJILLO-PERÚ
2015

1
 DEDICATORIA

Dedico la presente tesis a los seres que más amo en este mundo: mis padres, Raúl Alejandro y
Rosa Elizabeth a mis hermanos, Martín Alejandro y Christian Alonso, a mi cuñada Beatriz
Colmenares y sobrino Matías Alejandro, por ser la fuente de mi inspiración y motivación para
superarme cada día más y así poder luchar para que la vida nos depare un futuro mejor. A mi
gran amigo Diego Flores Aguilar por su apoyo incondicional en los 5 años de carrera.

El Autor

2
 AGRADECIMIENTO

Deseo expresar mis más sinceras muestras de agradecimiento:

Al Señor Jesucristo, mi Señor y Dios, por enseñarme el camino correcto de la vida, guiándome y
fortaleciéndome cada día con su Santo Espíritu.

A mis Padres y Hermanos por creer y confiar siempre en mí, apoyándome en todas las decisiones
que he tomado en la vida y mi fuente de motivación para ser cada día mejor persona y
profesional.

A mis maestros, por sus consejos y por compartir desinteresadamente sus amplios conocimientos
y experiencia.

A mis amigos, por el apoyo y motivación que de ellos he recibido.

El Autor

3
 PRESENTACION

Señores Miembros del Jurado:

De conformidad y en cumplimiento con las disposiciones establecidas por el

Reglamento General de Graduados de la Escuela Académico Profesional de Informática de la
Universidad Nacional de Trujillo, para optar el título de Ingeniero Informático, tengo a bien
someter a vuestra consideración la tesis titulada:

“Solución Informática de Homologación e Integración de datos para mejorar el Proceso

de Registro de Alumnos en la Universidad Nacional de Trujillo”

Espero que el presente trabajo de_ investigación sirva de ayuda y/o referencia para
el desarrollo fututo de proyectos que se implementen en la Escuela Académico Profesional de
Informática de la Universidad Nacional de Trujillo y en otros lugares que se hagan uso de las
tecnologías de la información como herramientas de productividad, eficiencia y competitividad.

Trujillo, Marzo del 2015

Saráchaga Díaz, Raúl Martín

4
RESUMEN

El presente trabajo brinda una Solución Informática para la Homologación e Integración

de datos para el proceso de registro de alumnos de la Universidad Nacional de Trujillo.

En la actualidad para el proceso de registro de los alumnos se tienen diferentes

aplicaciones, cada aplicación realizada en diferentes lenguajes de programación, con
bases de datos independientes unas de otras y las cuales están hechas en diferentes
SGBD.

Por tal motivo en el presente trabajo de investigación se describen los pasos necesarios
para la implementación de una Solución Informática, que tomará de distintos repositorios
de datos, los cuales están independientes unos de otros y los integrarán en uno solo,
creando así un nuevo Repositorio de Datos y un Software que utilice como Base de Datos
este Repositorio obtenido, para de esta forma mejorar el proceso del registro de los
alumnos.

Para la elaboración del Sistema se utilizará la Metología RUP, así mismo se hará uso de
patrón arquitectural como el de N-Capas, para de esta forma lograr más modularidad e
independencia en el desarrollo del Sistema que hará uilizará una nuevo Repositorio de
Datos, el cual pasará antes por un proceso ETL (Extraction, Transform and Load) que es
clave para lograr que los datos extraídos asíncronamente de orígenes heterogéneos se
integren.

De esta forma obteniéndose una disminución en el tiempo de registro de las fichas de los
alumnos y generación de reportes requeridos por la Oficina, así mismo aumentando el
grado de satisfacción del personal con el Software utilizado.

5
 INDICE

Contenido
LISTA DE FIGURAS ................................................................................................................. 9
LISTA DE TABLAS ..................................................................................................................10
INTRODUCCION .......................................................................................................................11
CAPÍTULO I ..............................................................................................................................12
PLANTEAMIENTO DEL ESTUDIO ............................................................................................12
1.1 Realidad Problemática ...................................................................................................12
1.2 Formulación del Problema ..............................................................................................13
1.3. Hipótesis ..........................................................................................................................13
1.3.1 Hipótesis Correlacional: ................................................................................................13
1.3.2 Hipótesis Nula: ............................................................................................................13
1.4. Objetivos ..........................................................................................................................13
1.4.1 Objetivos General .........................................................................................................13
1.4.2. Objetivos Específicos.............................................................................................14
1.5. Justificación del Problema ..................................................................................................14
1.6. Limitaciones del estudio .....................................................................................................15
1.7. Síntesis Organizativa del Informe ........................................................................................15
CAPITULO II .............................................................................................................................17
MARCO TEORICO ....................................................................................................................17
2.1. Antecedentes del Proyecto. .............................................................................................17
2.2 ETL .................................................................................... Error! Bookmark not defined.
2.2.1. Introducción................................................................................................................20
2.2.2. Definición...................................................................................................................20
2.2.3. Fases ..........................................................................................................................21
2.2.4. Data Warehouse ............................................................ Error! Bookmark not defined.
2.2.5. Arquitectura de un Data Warehouse............................ Error! Bookmark not defined.
2.3. Arquitectura en N-CAPAS ............................................... Error! Bookmark not defined.
CAPITULO III............................................................................................................................24
MATERIALES Y MÉTODOS ......................................................................................................24

6
 3.1. Tipo de Investigación .........................................................................................................24
3.2. Diseño de investigación ......................................................................................................24
3.3. Población, muestra y muestreo ............................................................................................25
3.4. Variables de Estudio ..........................................................................................................28
3.4.1. Operacionalización de variables ....................................................................................28
3.5. Técnicas e Instrumentos de recolección de datos....................................................................29
CAPITULO IV ...........................................................................................................................31
ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DEL SOFTWARE INFORMATICO ..........................31
4.1. Análisis: ...........................................................................................................................31
4.1.1. Definición de la Metodología de la Solución: .....................................................................31
4.1.1.1. Rational Unified Process(RUP) ..................................................................................31
4.1.1.2. Agile Unified Process(AUP) ......................................................................................32
4.1.3. Elección de la Metología: .................................................................................................33
4.1.4. Identificación de los Requerimientos: ................................................................................34
4.1.5. Consideraciones sobre el Sistema: .....................................................................................36
4.1.6. Análisis de la Solución:....................................................................................................38
4.1.5.1. Identificación de las necesidades del Cliente: ...................................................................38
4.1.5.2. Viabilidad Técnica........................................................................................................39
4.1.5.3. Asignaciones de Funciones a Hardware y Software ..........................................................40
4.1.5.4. Definiciones del Sistema ...............................................................................................42
4.1. Diseño: ........................................................................................................................43
4.2.1. Arquitectura de la Solución ..............................................................................................43
4.2.1.1. Representación de la Arquitectura ..................................................................................43
4.2.1.2. Arquitectura Orientada hacia la Implementación ..............................................................44
4.2.1.3. Diseño de la Arquitectura de la Solución .........................................................................46
4.2.1.4. Vista Lógica ................................................................................................................49
4.2.1.4. Vista de Despliegue ........................................................ Error! Bookmark not defined.
4.2.1.5. Diagrama de Clases ......................................................................................................50
4.2.1.6. Diagrama de Base de Datos ...........................................................................................50
4.2.1.7. Diseño de Interfaz Gráfica .............................................................................................51
4.3. Construcción: ....................................................................................................................54
4.3.1. Framework de Desarrollo: ................................................................................................54
4.3.2. Lenguaje de Programación: ..............................................................................................56

7
 4.3.3. Framework ORM: ...........................................................................................................57
4.3.4. IDE: ..............................................................................................................................59
4.3.6. Base de Datos: ................................................................................................................60
4.3.7 Otras Herramientas y librerías: ..........................................................................................61
4.4. Pruebas:............................................................................................................................61
4.4.1 Estrategia de Pruebas: .......................................................................................................61
4.4.2 Tipos de Pruebas: .............................................................................................................63
4.4.3 Pruebas de Integración: .....................................................................................................64
CAPITULO V.............................................................................................................................65
RESULTADOS...........................................................................................................................65
5.1. Obtención de los Datos para el Análisis: ...............................................................................65
5.2. Análisis Estadístico de los Resultados: .................................................................................66
5.2.1. Análisis Estadístico del Objetivo Especifico N° 1: ...........................................................66
5.2.2. Análisis Estadístico del Objetivo Especifico N° 2: ...........................................................70
CAPITULO IV ...........................................................................................................................73
DISCUSIÓN DE RESULTADOS .................................................................................................73
CAPITULO VI ...........................................................................................................................75
CONCLUSIONES .......................................................................................................................75
REFERENCIAS ..........................................................................................................................76

8
 LISTA DE FIGURAS
Figura 1 Arquitectura de un Data Warehouse……………………………………………23
Figura 2 Tabla de Valores Nulos…...……………………………………………………29
Figura 3 Tabla de Datos erróneos………………………………………………..………31
Figura 4 Gráfico del Diseño de la Investigación………………………………...………35
Figura 5 Fórmula para el cálculo de la muestra..………………………………...………36
Figura 6 Grafico de características principales dela solución informática………………43
Figura 7 Diseño de Ventana de Historial de Alumnos ……..…………………...………46
Figura 8 Diseño de Ventana de Registro de Alumnos en el Sistema …………...………46
Figura 9 Implementación del Proceso Personal de Software …………………...………47
Figura 10 Ventana de Registro de Alumnos……………………………………..………48
Figura 11 Capa de Acceso a Datos-Clase CADUsuario…………………………...……49
Figura 12 Diagrama del Data Warehouse………….……………………………...…..…52
Figura 13 Procedimiento Almacenado de Limpieza de Data Warehouse………………..52
Figura 14 Vista de Data Flows del Proyecto SSIS…………………………….…………53
Figura 15 Orígenes de las principales fuentes de datos……….…………….……………54
Figura 16 Vista de Conversión de Datos dentro del Data Flow………...……………….54
Figura 17 Carga de las Tablas al Data Warehouse ………………...…………….………55
Figura 18 Ejecución de los paquetes para la Carga en el Data Warehouse………………56
Figura 19 Modelo de Caso de Uso del Negocio………………………………….………57
Figura 20 Modelo de Objetos del Negocio……………………………………….………57
Figura 21 Diagrama de Actividades…………………………. ………………….………58
Figura 22 Diagrama de Paquetes…………………………. ……………………..………59
Figura 23 Gráfico de Barras de Reportes Generados……………………………….……62
Figura 24 Gráfico de Curvas obtenido del Objetivo Específico 1………………..………64
Figura 25 Gráfico de Barras de Nivel de Satisfacción del Personal ……………..………65
Figura 26 Gráfico de Curvas obtenido del Objetivo Específico 2………………..………67

9
 LISTA DE TABLAS
Figura 1 Arquitectura de un Data Warehouse……………………………………………23
Figura 2 Tabla de Valores Nulos…...……………………………………………………29
Figura 3 Tabla de Datos erróneos………………………………………………..………31
Figura 4 Gráfico del Diseño de la Investigación………………………………...………35
Figura 5 Fórmula para el cálculo de la muestra..………………………………...………36
Figura 6 Grafico de características principales dela solución informática………………43
Figura 7 Diseño de Ventana de Historial de Alumnos ……..…………………...………46
Figura 8 Diseño de Ventana de Registro de Alumnos en el Sistema …………...………46
Figura 9 Implementación del Proceso Personal de Software …………………...………47
Figura 10 Ventana de Registro de Alumnos……………………………………..………48
Figura 11 Capa de Acceso a Datos-Clase CADUsuario…………………………...……49
Figura 12 Diagrama del Data Warehouse………….……………………………...…..…52
Figura 13 Procedimiento Almacenado de Limpieza de Data Warehouse………………..52
Figura 14 Vista de Data Flows del Proyecto SSIS…………………………….…………53
Figura 15 Orígenes de las principales fuentes de datos……….…………….……………54
Figura 16 Vista de Conversión de Datos dentro del Data Flow………...……………….54
Figura 17 Carga de las Tablas al Data Warehouse ………………...…………….………55
Figura 18 Ejecución de los paquetes para la Carga en el Data Warehouse………………56
Figura 19 Modelo de Caso de Uso del Negocio………………………………….………57
Figura 20 Modelo de Objetos del Negocio……………………………………….………57
Figura 21 Diagrama de Actividades…………………………. ………………….………58
Figura 22 Diagrama de Paquetes…………………………. ……………………..………59
Figura 23 Gráfico de Barras de Reportes Generados……………………………….……62
Figura 24 Gráfico de Curvas obtenido del Objetivo Específico 1………………..………64
Figura 25 Gráfico de Barras de Nivel de Satisfacción del Personal….…………..………65
Figura 26 Gráfico de Curvas obtenido del Objetivo Específico 2………………..………67

10
INTRODUCCION
Este proyecto de tesis tiene por finalidad presentar una solución informática dirigida a la
problemática presente actualmente en la Oficina de Registro Técnico de la Universidad Nacional
de Trujillo. Dicha solución posibilitará la administración de información vinculada a los alumnos
de pregrado, postgrado y docentes de la institución.

A largo plazo el objetivo esperado con este proyecto es implantarlo en las demás Oficinas de la
Universidad Nacional de Trujillo, para de esta forma integrar sus procesos con una herramienta
apta para gestionar el registro y consulta de datos adquiridos de los alumnos de la institución.

A su vez apoyaría la descentralización del proceso de registro de alumnos para la obtención de su

título, a las propias Universidades de otras localidades.

Ambos contextos en la última década no han sido ajenos a la realidad educativa peruana: si bien
aparecen novedosos sistemas de información, su mercado objetivo no cumple con todos los
requerimientos propios de la misma Institución, ocasionando así el aumento de tiempo y costo a
la hora de realizar sus funciones.

En los primeros capítulos se abordará la problemática que existe en la ORT, determinándose así
los objetivos y metas que se cumplirán para darle solución.

Posteriormente a eso, se procederá a realizar el análisis, diseño e implementación del Sistema,

integrándose finalmente con la nueva Base de Datos que contendrá toda la Data de los distintos
repositorios de datos de la ORT.

11
CAPÍTULO I
PLANTEAMIENTO DEL ESTUDIO

1.1 Realidad Problemática

Con la aparición de nuevas y mejores herramientas en tecnologías de información

orientadas a la automatización de sus procesos y el cumplimiento de los objetivos en las
organizaciones, actualmente éstas se consideran en todo ámbito un factor de cambio
determinante para el mejoramiento y desarrollo de las actividades del sector educación.

Las Instituciones Universitarias vienen incorporando herramientas de apoyo para el

control y registro de alumnos, llevando así un historial de estos.

La ORT de la Universidad Nacional de Trujillo implantó un Sistema de Registro de

Alumnos para la obtención de su Título y Grados en los años noventa, este Sistema no
era propietario y había sido brindado por la ANR (Asociación Nacional de Rectores).

Este Sistema fue realizo en Visual FoxPro ya que ese lenguaje era muy popular en la
época donde que fue implementado.

A la par de ese Sistema (SISGRADO), se implementó otro Sistema desarrollado en PHP

y con Base de Datos en MYSQL, este Sistema fue desarrollado con la finalidad para que
todas las sub-oficinas puedan consultar datos de los alumnos egresados de la
Universidad, así mismo la ORT tiene una lista de todos los alumnos graduados con sus
respectivos códigos de facultad, códigos de escuela, códigos de ficha, pero estos se
encuentran en documentos de EXCEL , ya que son brindados en este formato por el
Centro de Cómputo de la Universidad.

Esto implica que las oficinas de la ORT no cuenten con una aplicación que permita
generar reportes que integren todos los repositorios de datos, creando en la mayoría de
los casos pérdida de tiempo.

12
1.2 Formulación del Problema

En la Oficina de Registro Técnico de la Universidad Nacional de Trujillo, existe carencia de

Software y tecnología capaz de integrar toda la data que existen de las diferentes aplicaciones
para de esta forma realizar de manera más eficiente el registro de alumnos para la obtención de
sus grados.

De esta manera se concretiza el enunciado del problema del siguiente trabajo:

¿Cómo mejorar el proceso de registro de los alumnos en la UNT a través de una Solución
informática de Homologación e Integración de datos.

1.3. Hipótesis

1.3.1 Hipótesis Correlacional:

 Mediante la Solución Informática de Homologación e Integración de datos se mejora

el proceso de registro de alumnos en la Universidad Nacional de Trujillo.

1.3.2 Hipótesis Nula:

 Sin la Solución Informática de Homologación e Integración de datos no se mejora el

proceso de registro de alumnos en la Universidad Nacional de Trujillo.

1.4. Objetivos

Los siguientes objetivos son los que se pretenden conseguir en la investigación, con el fin de
mejorar el Registro de Alumnos.

1.4.1 Objetivos General

Desarrollar una Solución Informática para la Homologación e Integración de datos para

mejorar el proceso de registro de alumnos en la Universidad Nacional de Trujillo.

13
1.4.2. Objetivos Específicos

 Optimizar el tiempo en el Proceso de Registro de Alumnos.

 Analizar el nivel de satisfacción por parte del personal en el Proceso de Registro de

Alumnos.

 Diseño, Construcción e Implementación de una Base de Datos que integre todos los
repositorios de Datos de la ORT.

1.5. Justificación del Problema

A medida que los avances tecnológicos facilitan el uso de herramientas que ayudan a
desempeñar una mejor labor para obtener información, se hace uso de estas, para satisfacer
la demanda que tiene la Oficina de Registro Técnico y solventar las necesidades de
información que solicita la Universidad Nacional de Trujillo.

Actualmente el sistema no da cobertura total a todos los requerimientos de los usuarios, los
cuales están expuestos a tener dificultades cuando realizan algún tipo de trámite usando el
Sistema. Por estas razones es necesario darle una nueva estructura a la forma como se
desarrollan los procesos actuales, para mejorar los servicios que los alumnos y docentes
requieran.

El Sistema rediseñado tendrá una nueva estructura de base de datos, garantías de la

integridad de los datos y la recuperación de los mismos en caso de fallos en el sistema.

14
1.6. Limitaciones del estudio

El estudio se centra en mejorar el proceso del registro de los alumnos, por ello es que presentan
ciertas limitaciones de acceso a datos y de dominio del proyecto.

 Escasa información, respecto a antecedentes, que hayan realizado un proyecto de este

tipo.
 El acceso a los repositorios de datos de la oficina de registro técnico, debido a las
políticas de seguridad que maneja la entidad.
 Al desarrollarse el proyecto, quizás se dé el caso, que se necesiten más recursos
hardware, (servidor especializado para base de datos) para optimizar y desarrollar de
forma eficiente el software; mermando así la solvencia económica estimada para el
proyecto.

1.7. Síntesis Organizativa del Informe

El presente trabajo de investigación cuenta con seis Capítulos, los cuales se describen
brevemente:

El primer capítulo, contiene el planteamiento del problema a estudiar, desde la realidad

problemática, la hipótesis, los objetivos, justificación del problema, limitaciones del estudio y
síntesis organizativa del informe.

El segundo capítulo, desarrolla el marco teórico, es decir el conjunto de conocimientos teóricos

que sustentan el estudio realizado.

El tercer capítulo, comprende los materiales y métodos utilizados para realizar la presente
investigación y poder comprobar la hipótesis planteada.

El Cuarto capítulo, comprende el análisis, diseño e implementación del prototipo de aplicación

que integre los datos de la organización mencionada.

15
El Quinto capítulo, comprende los resultados que se buscan obtener luego de haber ejecutado y
probado la aplicación, para luego proceder a dar un análisis y discusión minuciosa de estos.

El Sexto capítulo, comprende el análisis de los resultados, luego que estos han sido probados y
validados correctamente.

El Séptimo capítulo, comprendido por la conclusiones obtenidas luego de la investigación y las

recomendaciones que el estudio presenta como resultado como resultado de la investigación
realizada , así como trabajos futuros.

Finalmente el informe incluye las referencias bibliográficas, y las referencias web usadas.

16
CAPITULO II
MARCO TEORICO
2.1. Antecedentes del Proyecto.

Automatización del Sistema de Registro Académico y Propuesta de Red Informática

Educativa en el Instituto Nacional Prof. Francisco Ventura Zelaya de Santa Rosa de
Lima, Graciela Ivonne Guevara Benites-Mirna Lizeth Cardoza Sánchez, 2004 [3]. Esta
tesis trata en elaborar un Sistema de Registro Académico para le efectiva fluidez de los
procesos de la comunidad educativa, ya que la información se manejaba en PASCAL,
que no es propiamente un manejador de Base de Datos Relacional; no pudiendo explotar
todas las posibilidades que surgen teniendo una relación convenientemente organizada de
tablas dentro de la Base de Datos. Este nuevo rediseño del sistema contempla nuevos
informes y constancias que el anterior sistema no contenía, así mismo brinda una
propuesta de la Red Informática, de cómo debería diseñarse para la reducción de costos.

Análisis, Diseño e Implementación de un Sistema de Información aplicado a la Gestión

Educativa en Centros de Educación Especial, Raúl Romero Galindo, 2012 [4].
Esta Tesis trata en todo el proceso de la elaboración de un Sistema de Información en
Centro de Educación Especial, desde el levantamiento de los requisitos hasta su
implementación, utilizando Padrones Arquitecturales para su implementación, así mismo
como metodología de desarrollo de Software fue seleccionada la metodología Agile
Unified Process (AUP) por su mayor afinidad y claridad de actividades en la etapa de
diseño y construcción de este Sistema.

17
2.2. Arquitectura en N-CAPAS

La programación por capas es una arquitectura cliente-servidor en el que el objetivo

primordial es la separación de la lógica de negocios de la lógica de diseño; un ejemplo
básico de esto consiste en separar la capa de datos de la capa de presentación al usuario.

La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios
niveles y, en caso de que sobrevenga algún cambio, sólo se ataca al nivel requerido sin
tener que revisar entre código mezclado. Un buen ejemplo de este método de
programación sería el modelo de interconexión de sistemas abiertos.

Además, permite distribuir el trabajo de creación de una aplicación por niveles; de este
modo, cada grupo de trabajo está totalmente abstraído del resto de niveles, de forma que
basta con conocer la API que existe entre niveles.

En el diseño de sistemas informáticos actual se suelen usar las arquitecturas multinivel o

Programación por capas. En dichas arquitecturas a cada nivel se le confía una misión
simple, lo que permite el diseño de arquitecturas escalables (que pueden ampliarse con
facilidad en caso de que las necesidades aumenten).

El diseño más utilizado actualmente es el diseño en tres niveles (o en tres capas).

a) Capas y niveles

1. Capa de presentación:

Es la que ve el usuario (también se la denomina "capa de usuario"), presenta el

sistema al usuario, le comunica la información y captura la información del
usuario en un mínimo de proceso (realiza un filtrado previo para comprobar que
no hay errores de formato). También es conocida como interfaz gráfica y debe
tener la característica de ser "amigable" (entendible y fácil de usar) para el
usuario. Esta capa se comunica únicamente con la capa de negocio.

2. Capa de negocio:

Es donde residen los programas que se ejecutan, se reciben las peticiones del
usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio (e
incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas

18
 que deben cumplirse. Esta capa se comunica con la capa de presentación, para
recibir las solicitudes y presentar los resultados, y con la capa de datos, para
solicitar al gestor de base de datos almacenar o recuperar datos de él. También se
consideran aquí los programas de aplicación.

3. Capa de datos:

Es donde residen los datos y es la encargada de acceder a los mismos. Está

formada por uno o más gestores de bases de datos que realizan todo el
almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación
de información desde la capa de negocio.
Todas estas capas pueden residir en un único computador, si bien lo más usual es
que haya una multitud de computadoras en donde reside la capa de presentación
(son los clientes de la arquitectura cliente/servidor). Las capas de negocio y de
datos pueden residir en el mismo computador, y si el crecimiento de las
necesidades lo aconseja se pueden separar en dos o más computadoras. Así, si el
tamaño o complejidad de la base de datos aumenta, se puede separar en varias
computadoras los cuales recibirán las peticiones del computador en que resida la
capa de negocio. Si, por el contrario, fuese la complejidad en la capa de negocio
lo que obligase a la separación, esta capa de negocio podría residir en uno o más
computadores que realizarían solicitudes a una única base de datos. En sistemas
muy complejos se llega a tener una serie de computadores sobre los cuales corre
la capa de negocio, y otra serie de computadores sobre los cuales corre la base de
datos.

19
2.3. Patrón de Diseño

2.3.1. DAO (Data Access Object)

Este patrón de diseño divide más las responsabilidades en la aplicación de tal forma que
tendremos unas clases que se encargaran de la lógica de negocio y otras clases la
responsabilidad de persistencia.

A veces es difícil decidir que patrón de diseño elegir para nuestra casuística. Cuanta
mayor flexibilidad necesitemos en la capa de persistencia más nos encajará el uso de un
patrón DAO. Cuanto más aislada este la aplicación y menos flexibilidad necesite más nos
encajará un Active Record. Por poner un ejemplo sencillo imaginemos que el concepto de
Factura es necesario para un módulo diferente de la aplicación que se encarga de
imprimir PDFs con los datos de la Factura. En este caso no estamos en una situación de
aislamiento sino en lo contrario. El módulo que se encarga de imprimir la factura
trabajara de una forma más cómoda con business objects sencillos que con Active
Records. Por lo tanto es una casuística en la que encajará mejor el patrón DAO que el
ActiveRecord.

2.4. ETL (Extraction , Transform and Load)

2.4.1. Definición

Los procesos ETL son un término estándar que se utiliza para referirse al movimiento y
transformación de datos. Se trata del proceso que permite a las organizaciones mover
datos desde múltiples fuentes, reformatearlos y cargarlos en otra base de datos con el
objeto de analizarlos. También pueden ser enviados a otro sistema operacional para
apoyar un proceso de negocio.

En definitiva, el principal objetivo de este proceso es facilitar el movimiento de los datos

y la transformación de los mismos, integrando los distintos sistemas y fuentes en la
organización moderna.

El término ETL corresponde a las siglas en inglés de:

 Extract: extraer.
 Transform: transformar.
 Load: cargar.

20
2.4.2. Fases

Las distintas fases o secuencias de un proceso ETL son las siguientes:

 Extracción

La primera parte del proceso ETL consiste en extraer los datos desde los sistemas de origen. La
mayoría de los proyectos de almacenamiento de datos fusionan datos provenientes de diferentes
sistemas de origen. Cada sistema separado puede usar una organización diferente de los datos o
formatos distintos. Los formatos de las fuentes normalmente se encuentran en bases de datos
relacionales o ficheros planos, pero pueden incluir bases de datos no relacionales u otras
estructuras diferentes.

La extracción convierte los datos a un formato preparado para iniciar el proceso de

transformación.

Una parte intrínseca del proceso de extracción es la de analizar los datos extraídos, de lo que
resulta un chequeo que verifica si los datos cumplen la pauta o estructura que se esperaba. De no
ser así los datos son rechazados.

Un requerimiento importante que se debe exigir a la tarea de extracción es que ésta cause un
impacto mínimo en el sistema origen. Si los datos a extraer son muchos, el sistema de origen se
podría ralentizar e incluso colapsar, provocando que éste no pueda utilizarse con normalidad para
su uso cotidiano. Por esta razón, en sistemas grandes las operaciones de extracción suelen
programarse en horarios o días donde este impacto sea nulo o mínimo. [5]

 Transformación

La fase de transformación de un proceso de ETL aplica una serie de reglas de negocio o

funciones sobre los datos extraídos para convertirlos en datos que serán cargados. Algunas
fuentes de datos requerirán alguna pequeña manipulación de los datos. No obstante en otros
casos pueden ser necesarias aplicar algunas de las siguientes transformaciones:

 Seleccionar sólo ciertas columnas para su carga (por ejemplo, que las columnas con valores
nulos no se carguen).

 Traducir códigos (por ejemplo, si la fuente almacena una “H” para Hombre y “M” para
Mujer pero el destino tiene que guardar “1″ para Hombre y “2″ para Mujer).

21
 Codificar valores libres (por ejemplo, convertir “Hombre” en “H” o “Sr” en “1″).

 Obtener nuevos valores calculados (por ejemplo, total_venta = cantidad * precio).

 Unir datos de múltiples fuentes (por ejemplo, búsquedas, combinaciones, etc.).

 Calcular totales de múltiples filas de datos (por ejemplo, ventas totales de cada región).

 Generación de campos clave en el destino.

 Transponer o pivotar (girando múltiples columnas en filas o viceversa).

 Dividir una columna en varias (por ejemplo, columna “Nombre: García, Miguel”; pasar a dos
columnas “Nombre: Miguel” y “Apellido: García”).

 Carga

La fase de carga es el momento en el cual los datos de la fase anterior (transformación) son
cargados en el sistema de destino. Dependiendo de los requerimientos de la organización, este
proceso puede abarcar una amplia variedad de acciones diferentes. En algunas bases de datos se
sobrescribe la información antigua con nuevos datos. Los data warehouse mantienen un historial
de los registros de manera que se pueda hacer una auditoría de los mismos y disponer de un
rastro de toda la historia de un valor a lo largo del tiempo.

Existen dos formas básicas de desarrollar el proceso de carga:

 Acumulación simple: La acumulación simple es la más sencilla y común, y consiste en

realizar un resumen de todas las transacciones comprendidas en el período de tiempo
seleccionado y transportar el resultado como una única transacción hacia el data warehouse,
almacenando un valor calculado que consistirá típicamente en un sumatorio o un promedio
de la magnitud considerada.

Rolling: El proceso de Rolling por su parte, se aplica en los casos en que se opta por
mantener varios niveles de granularidad. Para ello se almacena información resumida a
distintos niveles, correspondientes a distintas agrupaciones de la unidad de tiempo o
diferentes niveles jerárquicos en alguna o varias de las dimensiones de la magnitud
almacenada (por ejemplo, totales diarios, totales semanales, totales mensuales, etc.).

22
La fase de carga interactúa directamente con la base de datos de destino. Al realizar esta
operación se aplicarán todas las restricciones y triggers (disparadores) que se hayan definido
en ésta (por ejemplo, valores únicos, integridad referencial, campos obligatorios, rangos de
valores). Estas restricciones y triggers (si están bien definidos) contribuyen a que se garantice
la calidad de los datos en el proceso ETL, y deben ser tenidos en cuenta.
Aunque podría entenderse como una acción integrada en la fase de transformación de datos,
en la actualidad la tendencia es considerar la limpieza de datos como una fase separada del
proceso ETL.

Esta visión corresponde a una concepción más moderna y práctica del proceso. Para ahorrar
tiempo y ganar en efectividad es conveniente unificar criterios, por ejemplo introduciendo
“av” en vez de “avenida” en todos los registros de una base de datos de direcciones postales,
ANTES de empezar el proceso ETL propiamente dicho.

Tan importante es tener la información consolidada como que todos los datos sean correctos
y con una visión única para todos los usuarios. Solo así se pueden lograr unos circuitos de
trabajo y análisis de dichos datos realmente óptimos y efectivos.

23
CAPITULO III
MATERIALES Y MÉTODOS

3.1. Tipo de Investigación

Estudio Explicativo.

3.2. Diseño de investigación

a) Tipo de diseño:
Diseño No Experimental - Descriptivo

b) Explicación del tipo:

Se llevan a cabo cuando se desea encontrar la solución de los problemas que surgen en
organizaciones educacionales, gubernamentales, industriales o políticas. Se efectúan
minuciosas descripciones de los fenómenos a estudiar, a fin de justificar las
disposiciones y prácticas vigentes o elaborar planes más inteligentes que permitan
mejorarlas. Su objetivo no es sólo determinar el estado de los fenómenos o problemas
analizados, sino también en comparar la situación existente con las pautas aceptadas. El
alcance de estos estudios varía considerablemente; pueden circunscribirse a una nación,
región, Estado, sistema escolar de una ciudad o alguna otra unidad. Los datos pueden
extraerse a partir de toda la población o de una muestra cuidadosamente seleccionada.
La información recogida puede referirse a un gran número de factores relacionados con
el fenómeno o sólo a unos pocos aspectos recogidos. Su alcance y profundidad
dependen de la naturaleza del problema. [7]

24
3.3. Población, muestra y muestreo

“Desarrollar una Solución Informática para la Homologación e Integración de datos para mejorar
el proceso de registro de alumnos en la Universidad Nacional de Trujillo.”

En base a la hipótesis planteada, se plantea la siguiente interrogante

¿Se desea saber si la solución informática mejoró el proceso de registro de alumnos de la
Universidad Nacional de Trujillo?

 Para definir el universo, población y muestra de la hipótesis y poder demostrarla se debe

definir en base a los objetivos específicos planteados con anterioridad.

1. Se desea saber si Aumentó el nivel de satisfacción por parte del personal en el proceso
de registro de alumnos.

UNIVERSO: Empleados de la Universidad Nacional de Trujillo

POBLACION: 45 Empleados que laboran en todas las Oficinas de Registro Técnico.
MUESTRA: 20 empleados de la Oficina de Registro Técnico
TIPO DE MUESTRA: Muestreo Aleatoria Simple.

Cálculo de la muestra:

Para calcular el tamaño de la muestra suele utilizarse la siguiente fórmula:

Figura 5
Fuente del Investigador

Donde:

n = el tamaño de la muestra.
N = tamaño de la población.

25
 Desviación estándar de la población que, generalmente cuando no se tiene su valor, suele
utilizarse un valor constante de 0,5.
Z = Valor obtenido mediante niveles de confianza. Es un valor constante que, si no se tiene
su valor, se lo toma en relación al 95% de confianza equivale a 1,96 (como más usual) o en
relación al 99% de confianza equivale 2,58, valor que queda a criterio del investigador.
e = Límite aceptable de error muestral que, generalmente cuando no se tiene su valor, suele
utilizarse un valor que varía entre el 1% (0,01) y 9% (0,09), valor que queda a criterio del
encuestador.
En nuestro caso:
ELEVADO AL
CUADRADO
N (POBLACION) 45 441
e (MARGEN DE ERROR) 0.05 0.0025
σ (DESVIACION
ESTANDAR) 0.5 0.25
Z (NIVEL DE
CONFIANZA) 1.96 3.8416

REDONDEANDO
n (TAMAÑO DE LA
MUESTRA) 19.9608076 20

Tabla 2: Tabla para el cálculo de la Muestra

2. Se desea saber si se Optimizó el tiempo en el proceso de registro de alumnos.

UNIVERSO: Empleados de la Universidad Nacional de Trujillo

POBLACION: 45 Empleados que laboran en todas las Oficinas de Registro Técnico.
MUESTRA: 20 empleados de la Oficina de Registro Técnico
TIPO DE MUESTRA: Muestreo Aleatoria Simple.

Cálculo de la muestra:

Para calcular el tamaño de la muestra suele utilizarse la siguiente fórmula:

26
 Figura 5
Fuente del Investigador

Donde:

n = el tamaño de la muestra.
N = tamaño de la población.
Desviación estándar de la población que, generalmente cuando no se tiene su valor, suele
utilizarse un valor constante de 0,5.
Z = Valor obtenido mediante niveles de confianza. Es un valor constante que, si no se tiene
su valor, se lo toma en relación al 95% de confianza equivale a 1,96 (como más usual) o en
relación al 99% de confianza equivale 2,58, valor que queda a criterio del investigador.
e = Límite aceptable de error muestral que, generalmente cuando no se tiene su valor, suele
utilizarse un valor que varía entre el 1% (0,01) y 9% (0,09), valor que queda a criterio del
encuestador.
En nuestro caso:
ELEVADO AL
CUADRADO
N (POBLACION) 45 441
e (MARGEN DE ERROR) 0.05 0.0025
σ (DESVIACION
ESTANDAR) 0.5 0.25
Z (NIVEL DE
CONFIANZA) 1.96 3.8416

REDONDEANDO
n (TAMAÑO DE LA
MUESTRA) 19.9608076 20

Tabla 2: Tabla para el cálculo de la Muestra

27
3.4. Variables de Estudio

3.4.1. Operacionalización de variables

a) IDENTIFICACION DE VARIABLES:

 VARIABLE INDEPENDIENTE:
Solución Informática de Homologación e Integración de datos.

 VARIABLE DEPENDIENTE: Mejorar el proceso de registro de alumnos en la

Oficina de Registro Técnico

b) DEFINICION CONCEPTUAL:

Solución Informática de Homologación e Integración de datos:

Software encargado de registrar a los alumnos homologando e integrando los datos de los
diferentes aplicativos de la Oficina de Registro Técnico.

Mejorar el proceso de registro de alumnos en la Oficina de Registro Técnico:

Es lo que se pretende conseguir, integrar todos los datos en un mismo repositorio de datos, para
de esta forma obtener reportes en tiempo real y con el menor tiempo posible.

c) INDICADORES:

o I1: Reducir el tiempo en el registro de ficha de alumnos para su Grado.

Variables utilizadas:
TPA : TIEMPO PROMEDIO ANTES

TPD : TIEMPO PROMEDIO DESPUES

28
o I2: Aumentar el nivel de satisfacción del personal
Variables utilizadas:
NPPSA : NUMERO PROMEDIO DE PERSONAL SATISFFECHO ANTES

NPPSD : NUMERO PROMEDIO DE PERSONAL SATISFECHO DESPUES

FORMULAS:
I1: TPA - TPD
I2: NPPSA - NPPSD

d) ESCALA DE MEDICIÓN

-BAJO: % TIEMPO REQUERIDO <30%

 I1 -MEDIO: % TIEMPO REQUERIDO >30% & <50%

-ALTO: % TIEMPO REQUERIDO >50%

-BAJO: N° PERSONAL >50%

 I2 -MEDIO: N° PERSONAL >30% & <50%

-ALTO: N° PERSONAL <30%

3.5. Técnicas e Instrumentos de recolección de datos

Técnicas e instrumentos de recolección de datos En la actualidad, en la investigación

científica hay gran variedad de técnicas o instrumentos para la recolección de información en
el trabajo de campo de una determinada investigación.
De acuerdo con el método y el tipo de investigación a realizar se utilizan unas u otras
técnicas. Para esta tesis se utilizarán las siguientes técnicas:

29
 Encuesta: Se realizarán encuestas a los empleados involucrados en el proceso de
registro, para poder así obtener el grado de satisfacción que tienen, con el sistema
antiguo y con el nuevo sistema implantado.

 Medición de tiempo: Se medirá el tiempo en cada una de las consultas para el registro de
ficha de alumnos para su grado en la Oficina de Registro Técnico.

30
CAPITULO IV
ANÁLISIS, DISEÑO E IMPLEMENTACIÓN DEL
SOFTWARE INFORMATICO
Para el desarrollo utilizaremos una mezcla de las fases del ciclo de vida de un sistema que
integre y homologue data con las fases típicas del desarrollo de software (análisis, diseño,
implementación y pruebas).

4.1. Análisis:

En esta parte del desarrollo damos los primeros pasos: definimos el software,
identificamos características, decidimos los pasos a dar y realizamos ciertas etapas relacionadas
con la obtención de conocimiento.

4.1.1. Definición de la Metodología de la Solución:

A continuación se presentan las dos metodologías candidatas para el desarrollo de la

solución. Posteriormente se exponen las justificaciones respecto a la elección de una de
estas propuestas.

4.1.1.1. Rational Unified Process(RUP)

RUP es una metodología de desarrollo de software basada en un enfoque iterativo con

una adecuada adaptación de los cambios durante el proceso de desarrollo, sumada a la
correcta gestión de requerimientos incorporando al diseño de software el lenguaje UML
definido como un sistema de modelamiento visual para la representación gráfica de caso
de uso, clases de análisis, componentes de software entre otros. Un elemento clave en la
concepción de RUP es el aseguramiento de la calidad del software.
Los proyectos se organizan en fases y cada una demanda un conjunto de iteraciones, en
ambas se van emitiendo entregables y prototipos de software con miras a la culminación
del producto. Este enfoque trae como beneficios la atenuación de riesgos desde ciclos

31
 tempranos del proceso alineando las necesidades de los usuarios a las funcionalidades del
producto. A su vez promueve una correcta administración del cambio y la configuración.
Esta metodología engloba una serie de entregables o artefactos del ciclo de desarrollo del
producto, constituyéndose así como el activo más importante después del producto final
pues en éstos se documentan los alcances técnicos y funcionales definitivos del producto
desarrollado en el presente proyecto de fin de carrera.
Pese a sus prestaciones, RUP enfrenta críticas por cuando prioriza el avance
documentario y la elaboración de entregables como prioritarios para el software (en
ciertos casos extensos y complejos en su administración) relegando otros factores tales
como la modalidad de trabajo durante la codificación del producto. Sumado a lo anterior,
la adopción de RUP como metodología conlleva al establecimiento de flujos de trabajo
roles en el equipo de proyecto la cual, de no contar con una eficiente gestión del equipo
de proyecto, recaería en una alta jerarquización de funciones aumentando la burocracia
en el trabajo.

4.1.1.2. Agile Unified Process(AUP)

AUP es una metodología de desarrollo ágil heredera de otros paradigmas como

laprogramación extrema (XP) y RUP. Esta metodología consta de principios y prácticas
influyentes en la construcción del software en armonía con la documentación esencial de
entregables específicos para el entendimiento de la solución. Entre sus objetivos destaca
la reducción del costo del cambio en el proyecto en base a procedimientos iterativos
(característica propia de RUP) donde La codificación y pruebas del software se llevan a
cabo paralelamente (según XP). Por experiencia de proyectos anteriores se recomienda la
aplicación de esta metodología en equipos con menos de diez integrantes aunque cuenta
con casos de éxito en proyectos de mayor envergadura (Ambysoft 2005).Además de la
estructura metodológica fijada por RUP (como el desarrollo deproducto por iteraciones y
presentación de prototipos en modo incremental), AUP introduce propuestas como la
programación por pares (“todos los desarrolladores conocen el código implementado por
todos”), la gestión de requerimientos por niveles de prioridad (toda solicitud de cambio es
analizada y/o ejecutada durantela construcción del software), independencia entre

32
 herramientas para la concepción del producto y el refactoring o la modificación del
código del programa sin alterar su comportamiento original mejorando en su estructura,
performance y diseño. Asimismo propone el desarrollo dirigido por pruebas (TDD) a
partir de un concepto denominado unidad de prueba (sincronizando tanto la construcción
como las pruebas en el prototipo) de carácter reutilizable. Pese a su evolución y demanda
como metodología de desarrollo en la última década, por sus semejanzas con el
paradigma XP enfrenta críticas dado el enfoque orientado a la optimización en la
programación en lugar de la documentación del producto así como por la no
profundización en ámbitos como la gestión de costo. A su vez, XP no provee plantillas de
proyecto para facilitar la adaptación de esta metodología: particularmente en proyectos
con mayor número de programadores, propuestas como la programación por pares
terminan siendo una labor crítica.

4.1.3. Elección de la Metología:

Tabla 4.2 Comparación de Metodologías

RUP AUP
Basta Documentación del Diseño. Falta de Documentación del Diseño
Ninguna restricción por el tamaño del Restricciones en cuanto a tamaño de los
proyecto. proyectos.
Ninguna dependencia de las personas. Fuerte dependencia de las personas.
Demora a cambios en los requisitos. Respuesta rápida a cabio de requisitos.
Reuniones del Equipo con el Cliente Reuniones del Equipo con el Cliente

Para el desarrollo del Sistema se consideraron dos metodologías, la Tabla 4.2 nos muestra
una comparativa de las metodologías teniendo en cuenta sus características principales.
La metodología elegida para el proyecto es RUP, ya que a pesar de que AUP es
considerada una buena metodología para el desarrollo de Sistemas por su Agilidad en el
desarrollo de la misma, estas ventajas con obtenidas cuando se cuenta con un mayor
grupo de personas, en este caso como el desarrollo solo lo realizará una persona (tesista)

33
 se eligió RUP, por ser una metodología estándar que se adapta muy bien a cualquier tipo
de desarrollo de Sistemas

4.1.4. Identificación de los Requerimientos:

Los requerimientos funcionales y no funcionales de las tablas 2.2 y 2.5 respectivamente

fueron recopilados durante las entrevistas con consultores, especialistas y personal de la
ORT.

4.1.4.1. Requerimientos Funcionales:

La presentación de estos requerimientos fue separada por cada módulo identificado en la

tabla 2.2.
Tabla 4.2 Requerimientos Funcionales del Sistema
Módulo Seguridad
N° Descripción Tipo
1 El sistema permitirá el mantenimiento de los usuarios de la ORT. Funcional
2 El sistema permitirá el mantenimiento de los perfiles de usuario y accesos Funcional
al sistema. El perfil especifica las acciones permitidas y restringidas
durante la navegación en la aplicación.
3 El sistema permitirá la asignación del perfil de usuario a uno o varios Funcional
usuarios.
4 El sistema permitirá la personalización de accesos al sistema para una Funcional
cuenta de usuario.
5 El sistema permitirá al usuario el cambio de su contraseña de acceso al Funcional
sistema.
6 El sistema permitirá cambiar de sesión al usuario para poder acceder con Funcional
otro usuario.
Módulo de Mantenimientos
N° Descripción Tipo
1 El sistema permitirá el mantenimiento de las Universidades Peruanas. Funcional

34
2 El sistema permitirá el mantenimiento del Tipo de Sexo de las Personas Funcional
3 El sistema permitirá el mantenimiento de los Tipos de Ficha que existen Funcional
(Grado, Maestría, Doctorado, etc.)
4 El sistema permitirá el mantenimiento de los Tipos de Estudiantes que Funcional
existen (Pregrado, Maestría, Complementación, etc.)
5 El sistema permitirá el mantenimiento de los Tipos de Colegios que Funcional
existen (Particulares, Estatales, Especiales, etc.)
6 El sistema permitirá el mantenimiento de los Tipos de Documentos de las Funcional
Personas
7 El sistema permitirá el mantenimiento de las Facultades de la Universidad Funcional
8 El sistema permitirá el mantenimiento de las Escuelas de la Universidad Funcional
Módulo Movimientos
N° Descripción Tipo
1 El sistema permitirá consultar el historial de los alumnos graduados. Funcional
2 El sistema permitirá el mantenimiento todos los alumnos de la Funcional
Universidad.
3 El sistema permitirá el mantenimiento las Autoridades de la Universidad. Funcional
4 El sistema permitirá el mantenimiento de los Docentes de la Universidad Funcional
5 El sistema permitirá el mantenimiento de los alumnos Graduados dela
Universidad.
Módulo Reportes
N° Descripción Tipo
1 El sistema permitirá visualizar el listado de todos los Docentes de la Funcional
Universidad.
2 El sistema permitirá visualizar el listado de todos los Docentes de la Funcional
Universidad categorizado por su Cargo
3 El sistema permitirá visualizar el listado de todos los Alumnos de la Funcional
Universidad agrupados por Facultad
4 El sistema permitirá visualizar el listado de todos los Alumnos Funcional
5 El sistema permitirá visualizar el listado de todos los Graduados

35
 6 El sistema permitirá visualizar el listado de todos los Graduados de la Funcional
Universidad agrupados por Facultad y Escuela

4.1.4.2. Requerimientos No Funcionales:

La tabla 2.5 agrupa los requerimientos a nivel de arquitectura y tecnologías.

Tabla 4.2 Requerimientos No Funcionales del Sistema

N° Descripción Tipo
1 El sistema será desarrollado con una interfaz gráfica de usuario basada en No Funcional
controles Windows.
2 El sistema será soportado por diferentes distribuciones de Windows No Funcional
3 El sistema contará con su propio instalador. No Funcional
4 El sistema trabajará con el Gestor de Base de Datos SQL Server. No Funcional
5 Se realizarán Backups automáticos para resguardar la información No Funcional

4.1.5. Consideraciones sobre el Sistema:

Como alcance de la propuesta quedan excluidas las automatizaciones de los procesos en

contabilidad, logística, gestión de planillas y recursos humanos de las instituciones
educativas. En contraparte, se respetarán las siguientes restricciones:
 Validación: La información ingresada por teclado es verificada como
medida preventiva ante posibles errores en el proceso.
 Seguridad: Acceso al sistema a personas mediante cuentas de usuario y
contraseña. En función a los perfiles y accesos se controlará el nivel de
visibilidad de la información.
 Escalabilidad: La arquitectura posibilitará la incorporación de nuevas
funcionalidades y módulos flexiblemente sin procedimientos drásticos
para el desarrollador.

36
  Usabilidad: Para la familiarización del usuario con el software se requiere
una interfaz gráfica ligera e intuitiva sumada a una correcta emisión de
avisos de error y advertencia. El usuario iniciará todas las operaciones
requeridas.
 Performance: Garantiza un tiempo de acceso no mayor a siete (3)
segundos.

Como consecuencia de las entrevistas efectuadas y según los requerimientos analizados a

partir de la lista de exigencias, se presenta a continuación la descripción de los actores
participantes del sistema (ver figura 2.1):
 Usuario: Toda persona con una cuenta y accesos autorizados al sistema.
 Supervisor Matrícula: Realiza funciones de verificación de datos de las
matrículas de los alumnos.
 Supervisor Académico: Realiza funciones de elaborar y verificar los datos para
los certificados de estudios.
 Supervisor Grados: Realiza funciones del registro de alumnos en la ORT para
sus Grados y Títulos.
 Administrador del Sistema: Realiza funciones tales como administrar cuentas,
perfiles de usuario y monitorear el funcionamiento del sistema.

37
 Figura 2.1. Actores del Sistema.

4.1.6. Análisis de la Solución:

Se presenta a continuación el trabajo llevado a cabo durante el análisis de la solución

tomando como base las recomendaciones establecidas por Roger Pressman (Pressman
2002) desde la relación de funcionalidades deseadas, la viabilidad técnica y económica, el
análisis costo – beneficio del proyecto, la asignación de funciones a los elementos del
sistema hasta el establecimiento de restricciones en costo y tiempo y la definición del
producto.

4.1.5.1. Identificación de las necesidades del Cliente:

Estas necesidades indicadas quedan cubiertas por los requerimientos del sistema dada la
similitud entre las expectativas de usuarios con las funcionalidades del nuevo sistema.

A partir de la lista de exigencias y habiendo identificado las necesidades de los usuarios

es factible construir el diagrama de casos de uso y actores.

38
 Figura 2.3. Diagrama de Casos de Uso del Sistema.

4.1.5.2. Viabilidad Técnica

Para la viabilidad técnica se presentan las restricciones en hardware y software con miras
a la construcción de la solución planteada, así como su disponibilidad.
Con la salvedad del software de ofimática para labores documentarias, las restricciones
técnicas identificadas son las siguientes:
(1) Disponibilidad del equipo de cómputo/servidor para albergar a la base de datos.
(2) Disponibilidad del equipo de cómputo para las labores de análisis, diseño,
construcción y pruebas.
(3) Herramientas CASE para el modelamiento UML y construcción de la base de datos
de la solución.
(4) Herramienta IDE para la construcción de la interfaz gráfica y codificación de las
funcionalidades bajo la plataforma NET.
(5) Sistema administrador de base de datos con capacidad para soportar múltiples
conexiones.
(6) Librerías DLL con capacidad de transmisión de datos entre aplicaciones en .NET y
servidor de base de datos SQLServer. A su vez, compatible con las operaciones de
persistencia de datos en ADO.NET Entity Framework (EF4).
(7) El lenguaje de programación y sus características para la construcción bajo el
paradigma orientado a objetos.
(8) Integrador de diferentes repositorios de datos como Integration Services 2008.

Este proyecto es técnicamente viable porque el tesista cuenta con todos los requisitos
citados. Bajo una adecuada planificación de recursos y con miras maximizar las
capacidades logísticas existentes, se adoptarán las siguientes medidas:

39
  Los requerimientos (1) y (2) quedan cubiertos empleando una computadora con
procesador Intel de séptima generación y memoria RAM de 4GB, dadas las
exigencias del servidor de base de datos y sistema operativo.
 Para el requisito (3) existen productos como Visual Paradigm CE, ArgoUML y
IBM Rational Rose, sujetos a las exigencias técnicas propias de la documentación
con RUP y además son de libre distribución. En el proyecto se hará uso del
software IBM Rational Rose. Los requerimientos (5) y (6) se encuentran cubiertos
con la incorporación de las herramientas IDE Microsoft Visual Web Developer
2012 Express (una versión gratuita y liviana para el desarrollo) y del
administrador de base de datos SQLServer.
 La elección del lenguaje C# y de Integration Services 2008comprenden los
requerimientos (7) y (8).

4.1.5.3. Asignaciones de Funciones a Hardware y Software

Las funciones asignadas al hardware durante el proyecto son:

 Como servidor de base de datos, cumplir con el almacenamiento físico del

servidor de base de datos.
 Albergar aplicaciones ofimáticas y herramientas CASE e IDE requeridas para
labores de análisis, diseño, construcción y pruebas.

Las funciones asignadas al software durante el proyecto son:

 Asistir al tesista en las actividades de diagramación, modelamiento y

documentación durante las fases de análisis y diseño.
 Permitir la codificación óptima y eficiente de los módulos, componentes y
funcionalidades de la solución.

40
  Permitir la construcción de la interfaz gráfica de la aplicación vía código o por
arrastre de elementos gráficos (drag & drop).

En cuanto al producto software, como principales funciones comprometidas se tienen:

 Interactuar con los servidores y el computador cliente desde el cual se conecta el

usuario.
 Cumplir con la ejecución de los procesos de gestión educativa obtenidos a partir
de la lista de exigencias de la solución.

Las funciones asignadas a nivel de base de datos a lo largo del proyecto son:

 Almacenar una base de datos única para las operaciones de lectura y escritura.
 Permitir el almacenamiento y recuperación de la información necesaria.
 Permitir la realización de copias de seguridad de la información albergada en la
base de datos.
 De ser necesario, admitir las configuraciones de conexión con la base de datos
realizadas dentro o fuera del motor de base de datos.
 Permitir que la Base de Datos sea capaz de integrar varios repositorios de datos.

Las funciones asignadas a los usuarios durante el transcurso del proyecto son:

 Colaborar con el levantamiento de información de los requerimientos.

 Ingresar los datos apropiados de acuerdo con los propósitos de cada módulo
incorporado a la solución.
 Cumplir con las pruebas de software necesarias
 Participar activamente en las reuniones de coordinación e implantación del
sistema.

Las funciones asignadas al equipo (tesista) a lo largo del proyecto son:

41
  Dirigir, coordinar y ejecutar las actividades técnicas y funcionales.
 Según el perfil del especialista (analista, programador, entre otros) cumplir con
las funciones competentes.

4.1.5.4. Definiciones del Sistema

Se presenta la definición del sistema a partir del diagrama de paquetes involucrando a las
entidades principales en el modelamiento del escenario de negocio. Este análisis
favorecerá al establecimiento y definición de la arquitectura final junto con las clases de
diseño necesarias para su construcción. La solución cubre los requerimientos revisado en
la sección 2.2 a través de 3 paquetes representados en el diagrama de paquetes (ver figura
2.3).

42
 Figura 2.3. Diagrama de Paquetes

4.1. Diseño:

Esta etapa comprende el diseño en alto nivel de la arquitectura justificando la elección de un

patrón arquitectónico. Respecto a la interfaz gráfica, se mencionan los patrones estándares
adoptados para uniformizar el aspecto visual y la interacción con el usuario.

4.2.1. Arquitectura de la Solución

En esta sección se explica el diseño a alto nivel y los paradigmas arquitectónicos evaluados
para posteriormente presentar la arquitectura final.

4.2.1.1. Representación de la Arquitectura

De acuerdo con capítulos anteriores la arquitectura está orientada a un Sistema de Escritorio.

Es así como el diseño debe garantizar un óptimo aprovechamiento de las capacidades propias
de los sistemas de escritorio satisfaciendo adecuadamente los requisitos no funcionales del
producto. Entre las fortalezas exigidas a la arquitectura se encuentran:

 La arquitectura respetará el paradigma de programación orientado a objetos.

Esta característica si bien depende del lenguaje de programación utilizado, la
propuesta de diseño debe asegurar la manipulación de los datos y operaciones de
manera encapsulada a través de clases y objetos interrelacionados entre sí por
invocaciones a los métodos respectivos. El manejo de cambios en el producto se logra
modificando las características de un número determinado de componentes sin
comprometer el funcionamiento del resto de módulos.

43
  Para la lógica de negocio la arquitectura trabajará bajo el patrón Modelo de
Dominio (Microsoft 2009). Este patrón consta de un conjunto de objetos de negocio
representando las entidades en un dominio y sus relaciones entre ellos.
El modelo representa en forma abstracta el negocio real encapsulando las reglas de
negocio y recreando así un flujo de trabajo habitual. Bajo este patrón no se tiene
conocimiento del mecanismo de persistencia de los datos, delegando esta
responsabilidad a otro ámbito.

 La arquitectura, para el manejo de la capa de datos, adoptará el patrón de diseño DAO

(Data Access Object). Un DAO encapsula un conjunto de objetos “persistidos” en
una base de datos junto con sus operaciones de lectura y escritura. Este esquema
provee una visión más orientada a objetos en la capa de persistencia logrando dos
metas: brindar una clara separación y dependencia en un solo sentido entre el modelo
de dominio y el mapeo de datos colocando una “fachada” sobre el nivel de
persistencia, eximiendo así a la capa de lógica de negocio de la responsabilidad del
funcionamiento del mecanismo de persistencia de datos (Microsoft 2007).

4.2.1.2. Arquitectura Orientada hacia la Implementación

El patrón de arquitectura en N-Capas (Mancini 2003) comprende la implementación de la

presentación, la lógica de negocio y la base de datos en capas por separado donde N
representa el número de capas conformadas en la arquitectura. Los componentes
residentes en una determinada capa pueden interactuar con sus pares ubicados en la
misma capa o con componentes residentes en capas inferiores. Cada capa podría residir
físicamente en ambientes diferentes favoreciendo así a la escalabilidad del software (ver
figura 3.2).

44
La interacción con las capas inferiores presenta dos enfoques. El enfoque estricto en
capas ocurre cuando interactúan una capa (J) y la capa inmediata inferior (J-1).
El enfoque flexible ocurre con la interacción entre una capa (capa N) con otras ubicadas
en niveles inferiores y en cualquier orden (capas J, J-1, J-3, entre otras).
El enfoque flexible ofrece mejoras en eficiencia pues los tiempos de respuesta de las
llamadas entre capas son inferiores a diferencia del primer enfoque. No obstante podría
presentar conflictos en caso amerite el cambio en el orden de capas, pues no provee el
mismo nivel de aislamiento a diferencia del primer enfoque (Mancini
2003).

Debido al acoplamiento y cohesión entre las capas la implementación de cambios recae

sobre una parte de la solución, minimizando el impacto hacia otras capas reduciendo así
el esfuerzo a invertir en la depuración y corrección de errores. La separación de
componentes en capas incrementa la flexibilidad y escalabilidad posibilitando la
reutilización de componentes y la ejecución de pruebas unitarias de software. Para fines
de performance, la seguridad y accesibilidad de la aplicación es altamente valorada. Esto
bien se logra distribuyendo la aplicación sobre niveles físicos (hardware) aplicando
políticas de seguridad como cortafuegos para determinados componentes. Así, la
distribución de las capas en niveles físicos favorece al incremento de la tolerancia a fallos
y rendimiento de la solución.
Por otro lado, como la interacción de un componente con otro ubicado en niveles
inferiores requiere el pase obligatorio por el resto de capas intermedias, se produce una
sobrecarga en el tiempo de respuesta en perjuicio de la performance. Este escenario
podría evitarse bajo un enfoque relajado sacrificando propiedades como el aislamiento de
capas. A su vez, este patrón para una aplicación con funcionalidades sencillas no resulta
óptimo dado el nivel de complejidad incorporado. En similar situación, para aplicaciones
dependientes de operaciones intensivas con bases de datos su adaptación no es viable.

45
4.2.1.3. Diseño de la Arquitectura de la Solución

Para la implementación de esta solución se aplicará la arquitectura en N-Capas, debido a

su diseño altamente escalable ante la incorporación de nuevos módulos y funcionalidades
a futuro. Además posibilita la distribución de componentes (capas) entre varios niveles de
hardware, obteniendo mayor seguridad y rendimiento ante numerosas peticiones al
servidor Web. Esta arquitectura orientada a objetos no presenta obstáculos para adaptar
tanto el patrón de modelo de dominio en la capa de lógica de negocio como el patrón de
repositorio en la capa de acceso a datos, cumpliendo así con los lineamientos base de
diseño indicados a comienzos del capítulo. La arquitectura queda dividida en 3 capas
descritas a continuación
(ver figura 3.3):

Figura 2.3. Diagrama de Paquetes

46
 Capa de Presentación: Esta capa integra los elementos de la interfaz gráfica y las
clases con la lógica del comportamiento de las ventanas para su interacción con el
usuario.

 Capa de Lógica de Negocios: Conformada por clases cuyas funciones recaen en la

implementación de la lógica de negocio atendiendo el requerimiento de usuario.
Interactúa con la capa de base de datos de acuerdo con el tratamiento deseado de la
información intercambiada.

 Capa de Acceso a Datos: En esta capa se ubicarán las clases DAO y librerías de
conexión encargadas de administrar las operaciones CRUD (Create – Read – Update
– Delete) y sentencias SQL a nivel de base de datos. La codificación de esta capa
sigue el patrón.

Diagrama de Componentes

Para el intercambio de información entre las capas tratadas, se hace uso de un conjunto de
entidades de negocio, cuyas clases representan el escenario real del negocio. La
arquitectura propuesta satisface los requerimientos no funcionales de diseño definidos en

47
el capítulo anterior. La tabla 3.1 refleja cómo esta elección satisface los requerimientos
de diseño.
Tabla 3.1 Requerimientos de Diseño vs. Solución Arquitectónica
Requerimiento No Funcional Solución Propuesta
El sistema será desarrollado con una La codificación de la Capa de Presentación
interfaz gráfica de usuario basada en no será controlada por la Capa de Lógica,
controles Windows. otorgando mayor libertad para incorporar
los elementos gráficos y adecuados.
El sistema contará con su propio instalador Se creó una nueva capa de ayuda donde
que servirá para generar el Instalador de la
Aplicación cada vez que se requiera.
El sistema trabajará con el administrador de En la Capa de Acceso a Datos se ubicará el
base de datos SQL Server. componente de conexión a la base de datos
deseada, independiente del resto de la
aplicación.

Entre los objetivos y restricciones aplicables a esta arquitectura destacan:

 Validación de información: Para la validación de los datos de entrada y salida se
contará con funciones de validación (ubicadas en la Capa de Presentación) y con
las reglas impuestas en la Capa de Lógica.

 Performance: Para fines de implantación la arquitectura es afín al establecimiento

de diferentes niveles físicos (o de hardware) por capa mejorando el rendimiento.
Respecto a los clientes, la arquitectura soporta la ejecución de múltiples
transacciones desde otras conexiones en simultáneo.

 Protección: La autenticación y validación de acciones al usuario queda a cargo del

módulo Seguridad en la Capa de Acceso a Datos, es ahí donde se recupera la
información de los permisos de Usuario.

48
  Unicidad: La arquitectura en su Capa de acceso a datos permite la interacción con
una base de datos a la vez, canalizando todas las operaciones de lectura y escritura
hacia ésta.

4.2.1.4. Vista Lógica

La figura 3.4 representa la vista lógica del software con las 3 capas descritas, así como
los principales componentes encargados de su funcionamiento.

Figura 3.4 Vista Lógica del Sistema

49
4.2.1.5. Diagrama de Clases

4.2.1.6. Diagrama de Base de Datos

Se presenta a continuación en la figura 3.9 las principales tablas del diagrama de base de
datos para las operaciones del sistema. El diccionario de datos se encuentra en el Anexo
J: Documento de diseño de base de datos.

50
4.2.1.7. Diseño de Interfaz Gráfica

Todas las páginas del sistema (con excepción de la interfaz de inicio de sesión) seguirán
el patrón gráfico mostrado en la figura 3.13.

 Título de la ventana: El título de la ventana en todo momento albergará los

nombres de los distintos formularios.

 Barra de Menú: Sirve para elegir una de las funcionalidades del módulo (por
ejemplo, hacer un nuevo registro, editarlo o eliminarlo).

 Barras de desplazamiento: Para el traslado por cada registro se contará con barras
de desplazamiento situadas en la parte superior del formulario.

 Grid de Datos: Donde se podrán visualizar todos los registros del formulario a
consultar, se hace con la finalidad de ya no acceder a otro formulario para poder
ver algún registro.

A continuación se muestran los prototipos de las pantallas de registro de alumnos(figura

3.14) , registro de fichas(figura 3.15) y acceso al sistema(figura 3.15).

51
 Figura 7
Diseño de Ventana de Historial de Alumnos

52
 Figura 8
Diseño de Ventana de Registro de Alumnos en el Sistema

53
 Figura 8
Diseño de Ventana de Registro de Alumnos en el Sistema

4.3. Construcción:

En esta sección se hace un resumen de las características de las principales tecnologías,

motores y frameworks empleados en la implementación como el lenguaje de
programación, librerías, motor de base de datos entre otros.

4.3.1. Framework de Desarrollo:

Para este proyecto el framework seleccionado es Microsoft .Net Framework 4.5. Es un

componente del sistema operativo Windows con características de desarrollo e
integración de diferentes lenguajes de programación con el propósito de construir
aplicaciones reutilizables y escalables en ambientes cliente/servidor, Web, dispositivos
móviles, de escritorio, entre otros. En su transformación a partir de la API de Windows se
presentaron factores de carácter evolutivo como la compatibilidad hacia atrás con otros
lenguajes de programación demandando así una mayor complejidad en integración. .NET
Framework 4.0 se adapta a la reutilización de códigos provenientes de diferentes
lenguajes de programación, sin perder la característica de independencia del lenguaje
(Freeman 2011). Entre las características más resaltantes destacan:

 Common Language Specification o CLS: Encargado de la compatibilidad de

código entre lenguajes. Conjunto mínimo de estándares para la interoperabilidad
de código generado a partir de diferentes lenguajes. Todo compilador para .NET
debe generar código compatible con este estándar. Representa un subconjunto de
las características ofrecidas por .NET (Freeman 2011).

 Compilación Just-in-Time o JIT: La máquina virtual de .NET utiliza un

compilador para convertir el código IL a código máquina justo antes de ser
ejecutado. Esto permite eficiencia al ejecutar un programa, pues solo compila el
fragmento de código en uso. La compilación JIT solo se realiza una vez por cada

54
 porción de código ejecutado. Si un código es ejecutado por segunda vez se utiliza
su versión compilada.

 El conjunto unificado de bibliotecas de clase proporciona las funciones estándar

para entrada y salida de datos, manipulación de cadenas y XML, entre otros
ofreciendo una interfaz de desarrollo común para todos los lenguajes compatibles
con .NET Framework.

Por otro lado la curva de aprendizaje bajo esta tecnología es inferior en comparación con
otras tecnologías Web y en cuanto al tiempo dedicado a la construcción de la solución.

Entre otras capacidades logradas con la utilización de este framework destacan:

 Ofrece herramientas y recursos para una mejor experiencia en programación

orientada a objetos promoviendo la reutilización de código fuente.

 La configuración de la seguridad es realizada sea con autenticación nativa de

Windows o vía configuración individual por aplicación.

 Durante el desarrollo se tiene acceso a toda la librería de clases de .NET.

Independiente del lenguaje de programación.

 Integra el framework ADO.NET Entity Framework para el trabajo con los

mecanismos de persistencia de datos en cualquier base de datos.

De este framework se hará uso de la tecnología.NET por ser considerada como la

plataforma ad hoc para la creación de aplicaciones en .NET Framework complejas y
limitadas con contenido dinámico integrando las mismas prestaciones. Asimismo todas
las aplicaciones construidas a partir de.NET son compatibles con la mayoría de
distribuciones de Windows y simplifica los procedimientos en configuración reduciendo
significativamente la dependencia por medio de un fichero XML de configuración

55
 denominado WEB.CONFIG diferente por cada ambiente de desarrollo, pruebas o
producción.

4.3.2. Lenguaje de Programación:

NET Framework permite trabajar con más de veinte lenguajes de programación

integrados entre ellos C# y Visual Basic. Si bien el tesista reúne la preparación y
experiencia frente a ambos candidatos, se seleccionó en lenguaje C# por las razones
expuestas a continuación:

 En búsqueda de construir una solución desde una perspectiva orientada a objetos

estricta, este lenguaje ofrece capacidades maduras en términos de sintaxis y
estructura de código; respetando principios como el encapsulamiento, abstracción
y polimorfismo en un nivel avanzado respecto a Visual Basic.

 C# reúne un nutrido conjunto de librerías y componentes en una estructura de

código cercana al lenguaje Java y C++.

 Las librerías y componentes de software integradas al proyecto ofrecen una mejor

performance con proyectos en el lenguaje C# (como el driver de conexión
Npgsql).

 C# posee control de excepciones de forma estructurada.

 Los patrones de desarrollo de software a seguir en el proyecto exigen un lenguaje

orientado estrictamente a objetos.

 La programación orientada a objetos con C# alcanza una mayor libertad en la

implementación de mecanismos de encapsulamiento, herencia, polimorfismo,
sobrecarga, entre otros. Mientras su contraparte Visual Basic no reúne estos
conceptos mínimos para plasmar esta óptica.

56
  La programación en el lenguaje Visual Basic no exige la declaración de variables
a diferencia del lenguaje C#. Dicha omisión afecta la estandarización de la
programación y a las pruebas de producto. Sumado a lo anterior, considerando un
paradigma ágil donde se pretende optimizar las labores de codificación adecuando
buenas prácticas en programación, dicha carencia es calificada como
contraproducente.

4.3.3. Framework ORM:

Para las operaciones de lectura y escritura en base de datos, en la evaluación de este

proyecto los frameworks candidatos fueron NHibernate y ADO.NET Entity Framework
(EF). Entre las similitudes de ambos frameworks valen mencionar:

 Soportan operaciones con bases de datos Oracle, SQL Server, MySQL,

PostgreSQL, entre otras.

 Todas las operaciones CRUD se realizan a partir de objetos.

 Incluyen lenguajes de consultas específicos como HQL (Hibernate Query

Language) o LINQ (Language Integrated Query).

 Para su funcionamiento requieren del mapeo del modelo de dominio.

Finalmente, se optó por trabajar con ADO.NET Entity Framework por las razones
detalladas a continuación:

 Se reduce drásticamente el tiempo a invertir en el mapeo entre entidades y tablas

de bases de datos. Para este fin el programa ORegistro.exe recibe la cadena de
conexión de una determinada base de datos (propietaria o de libre distribución) y
genera en la carpeta de proyecto los mapas y clases del modelo de datos

57
 homologando a su vez los tipos de datos entre ambos entornos. Como flujo
alternativo, también es posible retornar clases POCO (Plain Old Class Object)
depurando aún más la definición de las clases. A diferencia del otro framework
donde la labor de mapeo es manual incrementando los tiempos en la
programación.

 NHibernate cuenta con el lenguaje HQL para la construcción de consultas en la

base de datos. En cambio ADO.NET EF ofrece hasta tres niveles de consultas,
cada uno con diferentes tiempos de respuesta y por ende afectando en diferente
grado a la performance global: Entity SQL, LINQ to Entities y LINQ to SQL.
LINQ le otorga a todo lenguaje de programación de la plataforma .NET la
capacidad de construcción de sentencias SQL nativas como parte de su sintaxis
propia.

 ADO.NET EF soporta funciones canónicas (como las funciones Count, Max,

Min, Avg, entre otras) comunes e implementadas por todas los motores de bases
de datos compatibles con este framework. Asimismo, dichos motores aportan al
framework nuevos tipos de datos para reforzar la compatibilidad en la solución a
implementar.

 ADO.NET EF es un proyecto integrado a la plataforma .NET Framework 4.0

desde el año 2008 constituyéndose como una tecnología en constante evaluación
y evolución a futuro (Lerman 2010).

El factor rendimiento entre ambos frameworks es un criterio de medición despreciable

por cuanto ambos responden satisfactoriamente a los límites de tolerancia fijados en las
pruebas preliminares de selección de herramientas. Es común, tendencioso y arriesgado
señalar un candidato como el más óptimo, sin conocer previamente cómo efectuar la
configuración de ambos productos bajo las buenas prácticas recomendadas por sus
fabricantes.

58
4.3.4. IDE:

Entre los candidatos para la elección de la entorno de desarrollo fueron los productos
SharpDevelop, MonoDevelop y Visual Studio Developer 2012 Express Edition
(VSD2012). Además de presentarse en versiones no comerciales, dichos entorno
permiten el desarrollo de aplicaciones orientadas a objetos con el lenguaje C#, a partir de
la versión de .NET Framework 4.0.

Sin embargo la elección de la herramienta IDE decantó en Visual Studio Developer

2012 Express Edition por las siguientes consideraciones:

 SharpDevelop y MonoDevelop son entornos de programación para propósitos

generales. Visual Studio Developer 2012 Express Edition en cambio ofrece una
gama de comandos, frameworks y plantillas de proyectos para una avanzada
experiencia en la construcción de aplicaciones desde cero.

 Realiza la validación automática del código junto con las notaciones de los
estándares.

 VSD2012 ofrece un mejor control para la visualización del diseño de formularios

tanto en modo código y modo diseño (interface).

 Para propósitos de pruebas VSD2010 permite trabajar hasta con un servidor de

prueba (el servidor de desarrollo.NET), a diferencia de los otros editores los
cuales carecen de esta integración.

 VSD2012 simplifica el mantenimiento de los ficheros de configuración en.NET

(WEB.CONFIG), para el establecimiento de la conexión con la base de datos del
sistema así como el registro de errores y excepciones en línea. Además permite el
manejo de hasta dos versiones de un mismo fichero de configuración para los

59
 ambientes de desarrollo y pruebas, evitando posibles pérdidas o errores en
configuración entre dichos ámbitos.

 La administración de archivos y librerías en VSD2012 se basa en proyectos de

librería de clases (con propiedades de configuración similares ofrecidas por
Visual Studio Professional Edition).

4.3.6. Base de Datos:

En esta categoría los precandidatos fueron los motores SQLServer y MySQL, siendo
elegido el primero por las siguientes razones:

 SQLServer garantiza una mejor integridad de los datos forzando a mantener una
integridad referencial entre tablas. Dicha característica es opcional en MySQL
(por defecto, desactivada a fin de no afectar la performance). No obstante para los
propósitos de la solución a implementar es crucial contar con esta capacidad.

 En MySQL la inclusión de llaves foráneas en las tablas de la base de datos sólo se

encuentran en tablas InnoDB. Para simular este comportamiento se necesitan
disparadores (triggers).

 En líneas generales, SQLServer provee herramientas y alternativas de

configuración con fines de otorgar mayor seguridad e integridad en los datos. En
el caso de MySQL ofrece un mejor rendimiento y tiempo de respuesta frente a
operaciones específicas de lectura y escritura. Sin embargo, para escenarios con
una importante carga de conexiones ambos motores obtienen tiempos de respuesta
promedio similares (por ejemplo, joins en sentencias SQL).

 Finalmente, en cuanto al tema de licencias de pago y/o libre distribución (como

hasta la fecha ocurre con MySQL, concebido como producto) con SQLServer se

60
 puede adquirir una licencia Express para su uso, por tanto las restricciones de este
nivel no representa inconveniente alguno.

4.3.7 Otras Herramientas y librerías:

La librería SQLClient (SQLServer2008) es un proveedor (driver) de datos para

aplicaciones .NET conectadas a una base de datos en SQLServer desarrollado en el
lenguaje C#. Asimismo soporta operaciones de persistencia de datos con ADO.NET
Entity Framework.
Para la ejecución de Tareas Programadas (Jobs) se utilizó una herramienta propia del
SQLServer, el cual es el SQLAgent que te permite programar la ejecución de cualquier
tarea, esta se utilizó para la generación de Backups por las noches.
Como apoyo para la elaboración de los Reportes se utilizó Crystal Reports por su
capacidad de integración con VSD2012 y ayuda en la generación de estos.
Por su parte, para la Integración de los Datos se utilizó Integration Services 2008, este
contribuyó a la extracción de los diferentes repositorios de los datos, su posterior
transformación para que puedan ser cargados en la Base de Datos de la Aplicación.
Finalmente, para la generación de un Instalador para la aplicación se contó con
InstallShield, este un software de código abierto para la generación de instaladores
personalizados.

4.4. Pruebas:

En esta sección se detalla el procedimiento de pruebas durante la verificación y

validación del software, desde los tipos de pruebas seleccionados junto con las
justificaciones de sus respectivas elecciones, así como la estrategia desarrollada.

4.4.1 Estrategia de Pruebas:

61
El objetivo global de la estrategia de pruebas es demostrar el funcionamiento completo
del software a nivel de eficiencia de código y funcionalidad. En otras palabras, verificar
la interacción e integración de los componentes y validar la implementación de todos los
requerimientos de producto.

Para el cumplimiento de lo descrito anteriormente, la estrategia establecida será como

sigue:

Recopilar, diseñar y documentar los casos de prueba de software a nivel de

módulo y de producto en el catálogo de pruebas. Los casos de prueba deben
cubrir la revisión de más de un requerimiento funcional.
Cuantificar el esfuerzo estimado en horas de cada uno de los recursos por
emplear bajo estas pruebas.
Las pruebas unitarias serán ejecutadas en paralelo con la codificación teniendo
como propósito el funcionamiento correcto del código fuente implementado bajo
el lenguaje de programación.
Sobre la aplicación del desarrollo guiado por pruebas (TDD), en el marco de la
metodología AUP, ésta reúne como etapas la elección de requisitos a codificar,
seguida de la escritura y ejecución de las pruebas de dichos requisitos, la
implementación del código de solución a las pruebas para culminar aplicando la
refactorización y actualización de la lista de requisitos. Debido a la extensión en
el número de requerimientos de software del proyecto se aplicarán, de las
etapas descritas, la programación del código de solución de las pruebas del
sistema y la refactorización del software.
Como siguiente instancia de pruebas se desarrollarán las pruebas de
integración en modo incremental. Se pretende con ello el acoplamiento
satisfactorio y paulatino de cada módulo así como la validación de las
funcionalidades provistas por todos los módulos integrados anteriormente. Con
la integración del último módulo, las pruebas de integración pasarían
formalmente a supervisarse como pruebas del sistema.
Como apoyo al proceso anterior, dichas pruebas contarán con la participación

62
 de los usuarios finales de los centros educativos (previa coordinación de fechas
de pruebas integrales).
Para el monitoreo en base de datos así como desde un navegador Web de los
errores y excepciones arrojados durante las pruebas, se integrará la librería
ELMAH a la solución final ASP.NET, manteniéndose hasta una vez concluida la
implantación o en su defecto para las actividades de mejora continua al
producto.
Para la automatización de las entradas de datos en las ventanas de usuario, se
trabajará con un plugin en el navegador Web Firefox denominado Selenium
IDE. Dicho plugin permite grabar y ejecutar scripts de forma directa desde este
navegador simulando así la interacción del usuario.
Ante cada flujo aprobado por el usuario, se contará con actas de aceptación
constatando la revisión de los requerimientos funcionales completados.

4.4.2 Tipos de Pruebas:

Estas pruebas de software se dirigen a componentes menores como los módulos de un sistema,
probando los caminos de control importantes con el fin de descubrir errores dentro de esta
instancia (Dávila 2005). Es así como el equipo logrará identificar los defectos en fases tempranas
de codificación sin esperar la realización de pruebas integrales. Las técnicas consideradas son:

 Pruebas de Caja Blanca: Examinan la estructura de un código fuente según la lógica

implementada evaluando la ejecución correcta a nivel de sentencia, estructuras selectivas
e iterativas (Dávila 2005). No obstante, este ámbito queda cubierto dentro del marco de
pruebas de código a realizarse durante la codificación del producto adoptada como
práctica ágil.

 Pruebas de Caja Negra: Estas pruebas se realizan sobre las interfaces gráficas buscando
comprobar la funcionalidad, comportamiento en la entrada y salida de datos así como la
integridad de la información enviada y recibida. Por lo tanto las pruebas de caja negra

63
 serán efectuadas considerando la documentación de los casos sujetos a los requerimientos
del negocio a partir de la identificación y evaluación de diversos juegos de datos en las
entradas del sistema para así observar la coherencia con las salidas del sistema. Como
patrón de documentación se adopta el modelo presentado en la tabla 4.1.

4.4.3 Pruebas de Integración:

Bajo estas pruebas todos los módulos revisados e integrados en diferentes secuencias de
procesos y llamadas, son evaluados con el propósito de comprobar la ejecución correcta
conforme al proceso de negocio esperado. Un factor clave es la capacidad de
identificación de todos los esquemas de llamadas para una buena cobertura de casos de
prueba integral. Las pruebas integrales se clasifican en:

 No incremental: Requiere tener todos los módulos del producto software

culminados para así concretar en su conjunto estas pruebas.

 Incremental: Cada módulo es acoplado a los componentes existentes, así las

pruebas futuras no afectarán los avances y correcciones de fases anteriores, en la
búsqueda de un software robusto desde el inicio de las pruebas.

La prueba de integración incremental fue adoptada para esta etapa, pretendiendo demostrar
así el funcionamiento del software sin errores desde el inicio de su creación. Esto puede
afectar en mediano grado los tiempos globales, pero asegura calidad en la construcción y está
alineado con la metodología iterativa incremental.

Involucrando a los usuarios en las pruebas, trae como ventaja la simulación de los escenarios
reales de los procesos de negocio midiendo así el grado de satisfacción de los requerimientos
funcionales.

64
CAPITULO V
RESULTADOS

5.1. Obtención de los Datos para el Análisis:

Los datos necesarios para el análisis estadístico se obtendrán siguiendo algunos procedimientos
y mediciones específicas:

a. Para el PIMER OBJETIVO ESPECIFICO , reducción del tiempo en la generación de

reportes:
 Se utilizará una medición de tiempo en MILISEGUNDOS, para poder calcular cuánto
demora cada reporte en generarse.

b. Para el SEGUNDO OBJETIVO ESPECIFICO, Aumentar la usabilidad del personal

 Se utilizará un criterio cualitativo:
 Bajo
 Medio
 Alto

65
 Este criterio, está basado en el nivel de satisfacción que tiene cada empleado en relación con el
uso del sistema actual que presenta la entidad y la solución informática presentada como
solución.

5.2. Análisis Estadístico de los Resultados:

5.2.1. Análisis Estadístico del Objetivo Especifico N° 1:

Hi: La Solución Informática para la Homologación e Integración de datos disminuye el

tiempo en la generación de reportes.

Ho: La Solución Informática para la Homologación e Integración de datos incrementa el

tiempo en la generación de reportes.

Tabla 6
Cuadro de resultados obtenidos en los niveles de utilización de tiempo antes y después
del uso de la solución informática. (Los datos del test – se encuentra en el ANEXO 1)

Tabla 6: Nro. de Reportes clasificados según nivel de tiempo

Nro. de Reportes

Nivel bajo Nivel medio Nivel Alto Total Reportes

Pre-Test 0 8 12 20
Post-Test 4 11 5 20

66
 En el Cuadro Nº 1 se representan los resultados obtenidos en los niveles de uso de
tiempo, antes y después de la implementación de la solución informática; y se observó
que en el pre-test, el nivel bajo de reportes está representado por cero reportes, ocho nivel
Medio y doce en el nivel alto. En el post-test; en el nivel bajo se encontró cuatro
reportes, en el nivel medio once, y en el nivel alto se observaron cinco reportes; lo que
indica la efectividad de la solución informática y el objetivo de disminución de tiempo
fue conseguido exitosamente.

Gráfica de resultados obtenidos en los niveles de Tiempo Utilizado antes y después del uso de la
solución informática para la Generación de un Reporte.

Tiempo Utilizado
12
12 11

10
8
8
N° Reportes

6 5
4 Pre test
4 Post-test

2
0
Figura 76
0
baja media alta
Gráfico de Barras del Nro. De Reportes Generados.
Pre test 0 8 12
Post-test 4 11 5
Niveles

Figura 23 : Gráfico de Nro. de Reportes Generados

67
La gráfica representa los resultados comparativos de los niveles de tiempo utilizado antes y
después de utilizado la solución informática; donde se aprecia que disminuyo en relación a la
generación de reportes sin la solución informática, por lo tanto que el uso de la solución
informática para disminuir el tiempo utilizado fue efectivo.

Tabla 7
Tabla de puntajes de los niveles de tiempo utilizado antes y después del uso de la
solución informática
Tabla de Comprobación de Objetivo Específico Nº 1
Nivel Bajo Nivel Medio Nivel Alto Total Reportes
Pre-Test F0 0 F0 8 F0 12 20
Fe 2 Fe 9.5 Fe 8.5
Post-Test F0 4 F0 11 F0 5 20
Fe 2 Fe 9.5 Fe 8.5
∑ 4 19 17 40
.

𝟒 𝒙 𝟐𝟎 𝟏𝟗 𝒙 𝟐𝟎 𝟏𝟕 𝒙 𝟐𝟎
Celda 1: =𝟐 Celda 2: = 𝟗. 𝟓 Celda 3: = 𝟖. 𝟓
𝟒𝟎 𝟒𝟎 𝟒𝟎
𝟒 𝒙 𝟐𝟎 𝟏𝟗 𝒙 𝟐𝟎 𝟏𝟕 𝒙 𝟐𝟎
Celda 4: = 𝟐 Celda 5: = 𝟗. 𝟓 Celda 6: = 𝟖. 𝟓
𝟒𝟎 𝟒𝟎 𝟒𝟎

Desarrollo de la prueba estadística (Chi-cuadrado):

𝟐
(𝑶𝒊 − 𝑬𝒊)𝟐
𝑿 = ∑
𝑬𝒊

68
 (𝟎 − 𝟐)𝟐 (𝟖 − 𝟗. 𝟓)𝟐 (𝟏𝟐 − 𝟖. 𝟓)𝟐 (𝟒 − 𝟐)𝟐 (𝟏𝟏 − 𝟗. 𝟓)𝟐
𝑿𝟐 = + + + +
𝟐 𝟗. 𝟓 𝟖. 𝟓 𝟐 𝟗. 𝟓
(𝟓 − 𝟖. 𝟓)𝟐
+
𝟖. 𝟓
𝑿𝟐 = 𝟕. 𝟑𝟔
Los Grados de Libertad son los siguientes:
G.L. = (F-1) (C-1)
En donde:
F = Número de Filas
C = Número de Columnas
G.L. = (F-1) (C-1)
G.L. = (2-1) (3-1)
G.L. = (1) (2)
G.L. = 2
Nivel de Significación = 5%
Chi-cuadrado (X²) de Tabla = 5.99
Chi-cuadrado (X²) calculada = 𝟕. 𝟑𝟔

Se puede observar que Chi-cuadrado (X²) calculada (𝟕. 𝟑𝟔) es mayor de la que aparece
en la tabla (5.99); por lo tanto, se acepta la hipótesis de trabajo (Hi) y se rechaza la
hipótesis nula (Ho).

7.36

Figura 24 : Gráfico de Curva de Resultados Obtenidos del Objetico Específico Nº 1

69
5.2.2. Análisis Estadístico del Objetivo Especifico N° 2:

Hi: La solución informática Aumenta el nivel de satisfacción del personal, en el proceso

de proceso de registro de alumnos en la Universidad Nacional de Trujillo.
Ho: La solución informática disminuye el nivel de satisfacción del personal, en el
proceso de proceso de registro de alumnos en la Universidad Nacional de Trujillo.

Tabla 8
Cuadro de resultados obtenidos en los niveles de satisfacción del personal antes y después del
uso de la solución informática. (Los datos del test – se encuentra en el ANEXO 2)

Tabla 8: Tabla de Nivel de Satisfacción del Personal

Satisfacción del Personal

Nivel bajo Nivel medio Nivel Alto Total

Empleados
Pre-Test 12 6 2 20
Post-Test 2 8 10 20

En el Cuadro Nº 2 se representan los resultados obtenidos en los niveles de Satisfacción del

Personal, antes y después de la implementación de la solución informática; y se observó que en
el pre-test, el nivel bajo de satisfacción del personal está representado por doce empleados, seis
nivel Medio y dos en el nivel alto. En el post-test; en el nivel bajo se encontró dos empleados, en
el nivel medio ocho, y en el nivel alto se observaron diez empleados; lo que indica la efectividad
de la solución informática y el objetivo de aumento de satisfacción del personal, fue conseguido
exitosamente.

Gráfica de resultados obtenidos en los niveles de satisfacción del personal antes y después del
uso del software de riego inteligente.

Satisfaccion del Personal 70

12
12
10
 Figura 25: Gráfico de Barras del Nivel de Satisfacción del Personal

La gráfica representa los resultados comparativos de los niveles de satisfacción del

personal antes y después de utilizado la solución informática; donde se aprecia que el
nivel de satisfacción del personal aumento en relación al uso actual del sistema que
poseen en registro técnico y por lo tanto que el uso de la solución informática para
aumentar el nivel se satisfacción del personal fue efectivo.

Comprobación de Objetivo Específico Nº 2

Tabla 9
Tabla de puntajes de los niveles de satisfacción del personal antes y después del uso del
software de riego inteligente

Tabla de Comprobación de Objetivo Específico Nº 2

Nivel Bajo Nivel Medio Nivel Alto Total Riegos

Pre-Test F0 12 F0 6 F0 2 20
Fe 7 Fe 7 Fe 6
Post-Test F0 2 F0 8 F0 10 20

71
 Fe 7 Fe 7 Fe 6
∑ 14 14 12 40

.
𝟏𝟒𝒙 𝟐𝟎 𝟏𝟒𝒙 𝟐𝟎 𝟏𝟐 𝒙 𝟐𝟎
Celda 1: = 𝟕 Celda 2: =𝟕 Celda 3: =𝟔
𝟒𝟎 𝟒𝟎 𝟒𝟎
𝟏𝟒𝒙 𝟐𝟎 𝟏𝟒𝒙 𝟐𝟎 𝟏𝟐 𝒙 𝟐𝟎
Celda 4: = 𝟕 Celda 5: =𝟕 Celda 6: =𝟔
𝟒𝟎 𝟒𝟎 𝟒𝟎

Desarrollo de la prueba estadística (Chi-cuadrado):

(𝑶𝒊 − 𝑬𝒊)𝟐
𝑿𝟐 = ∑
𝑬𝒊

(𝟏𝟐 − 𝟕)𝟐 (𝟔 − 𝟕)𝟐 (𝟐 − 𝟔)𝟐 (𝟐 − 𝟕)𝟐 (𝟖 − 𝟕)𝟐 (𝟏𝟎 − 𝟔)𝟐

𝑿𝟐 = + + + + +
𝟕 𝟕 𝟔 𝟕 𝟕 𝟔
𝑿𝟐 = 𝟏𝟐. 𝟖𝟐

Los Grados de Libertad son los siguientes:

G.L. = (F-1) (C-1)
En donde:
F = Número de Filas
C = Número de Columnas
G.L. = (F-1) (C-1)
G.L. = (2-1) (3-1)
G.L. = (1) (2)
G.L. = 2
Nivel de Significación = 5%
Chi-cuadrado (X²) de Tabla = 5.99
Chi-cuadrado (X²) calculada = 12.82

Se puede observar que Chi-cuadrado (X²) calculada (12.82) es mayor de la que aparece
en la tabla (5.99); por lo tanto, se acepta la hipótesis de trabajo (Hi) y se rechaza la
hipótesis nula (Ho).

Representación de la Curva de los Resultados Obtenidos del Objetico Específico Nº

2

72
 Figura 26 : Gráfico de Curva de Resultados Obtenidos del Objetico Específico Nº 2

CAPITULO IV
DISCUSIÓN DE RESULTADOS
De acuerdo con los resultados obtenidos nos podemos dar cuenta que se pueden distinguir los
siguientes aspectos:

1. La arquitectura propuesta está diseñada de tal manera que permite una mejora en el
desarrollo del software, debido a que se ha realizado utilizando patrones de arquitecturales,
que implementan las buenas prácticas de la programación, a comparación de cómo estaba
estructurado antes.

2. La disminución del tiempo requerido por los trabajadores de la Oficina de Registro Técnico
para el registro de alumnos, obtención de reportes, exportación de datos y medición de sus
indicadores.

73
3. El Desarrollo de un Software adaptable a los requerimientos de la Oficina de Registro
Técnico mejoró el proceso de registro de los alumnos.

4. Los diagramas UML presentados, en la etapa de análisis, diseño e implementación del

software, permitieron poder llevar la programación de forma más rápida y ordenada.

En cuanto a LAS PRUEBAS ESTADISTICAS:

Se puedo verificar los 2 objetivos específicos planteado de forma correcta.

 Disminuir el tiempo en el proceso de registro de alumnos de la ORT.

-> VERIFICADO CORRECTAMENTE (Ver Anexo Nro. 1)

 Aumentar el nivel de satisfacción por parte del personal en el proceso de registro de alumnos
->VERIFICADO CORRECTAMENTE(Ver Anexo Nro. 2)

Dado que los objetivos específicos han sido verificados correctamente la hipótesis nula general,
es rechazada, y la hipótesis planteada es aceptada.

74
CAPITULO VI
CONCLUSIONES

1. Durante el desarrollo del presente trabajo de tesis se efectúo la investigación bibliográfica y

de información en internet, determinando las características y conceptos relacionados con el
diseño y desarrollo de un software que acabase en un Sistema que utilice la data integrada de
la ORT ya integrada en una nueva Base de Datos. Véase el CAPITULO II.

2. Como primer paso para llevar a cabo la implementación del Sistema, en el CAPITULO II
sección 2.2, se eligió la metodología de RUP, posteriormente en el CAPITULO IV sección
4.3. se aplicó esta metodología, pudiendo de esta manera luego lograr la integración de toda
la Data con este nuevo Sistema, así mismo en el CAPITULO IV sección 4.2. se aplicó un
patrón arquitectural, pudiendo de esta manera, lograr crear una arquitectura adecuada para el
desarrollo.

3. Luego de definir la arquitectura de software en el CAPITULO IV sección 4.2, se definió

cuáles serían las interfaces requeridas por los usuarios para de esta manera lograr mayor nivel
de satisfaccion con el Software y los reportes más requeridos por ellos.

4. Para los repositorios de datos requeridos para la Integración, se tuvo que utilizar repositorios
de datos antiguos y generar en muchos casos el Excel, debido a temas de confidencialidad de
la misma Oficina, los datos que se presentan en los anexos, son los mejores datos que se
pudieron conseguir de las diferentes muestras que se tomaron.

5. Para el análisis estadístico, se optó por elegir el método de CHI-CUADRADO, debido a que
la tesis aquí presentada, tiene una relación causa efecto que se pretende probar, la cual es,
que con la solución informática se mejorar el proceso de registro de alumnos, por ello se optó
por realizar un análisis PRE-TEST y POST-TEST, realizando medidas específicas, para
poder comparar y verificar que con la solución informática se consiguió una mejora.

75
REFERENCIAS

1. Bibliografía general

[1] WILLIAM INMOM. (2000) Building the Data Warehouse. Four Edition.
[2] CHRISTIN SANCHEZ FLORES (2012) Inteligencia de Negocios.

2. Bibliografía específica
[3] GRACIELA IVONNE GUEVARA BENITEZ. (2004).Automatización del Sistema de
Registro Académico y Propuesta de Red Informática Educativa en el Instituto Nacional Prof.
Francisco Ventura Zelaya de Santa Rosa de Lima.

[4] RAÚL MIGUEL ROMERO GALINDO. (2012). Análisis, Diseño e Implementación de

un Sistema de Información Aplicado a la Gestión Educativa en Centros de Educación
Especial.

3. Web grafía

[5] ELIZABETH DEL CARMEN ZARATE GALLARDO (2013) Técnicas Modernas de

Automática. Recuperado el 05 de Junio del 2014, de
http://www.gestiopolis.com/administracion-estrategia-2/inteligencia-de-negocios.htm

[6] JORGE PAZ FLORES (2010) La Importancia de la Inteligencia de Negocios Aplicada a

las Empresas Medianas, de http://www.ibm.com/developerworks/ssa/local/data/dm-bi-
pymes/

[6] JUAN JOSE GONZLES (2013) Implementación del Proceso Personal del Software, de
https://jjegonzalezf.wordpress.com/tag/ingenieria-de-software-2/

76
 [7] DEEBOLD B. VAN DALEN (2006) Manual de Técnica de la Investigación
Educacional, de http://noemagico.blogia.com/2006/091301-la-investigacion-descriptiva.php

ANEXOS
ANEXO 1: DATOS DEL PRE Y POST TEST PARA LA MEDIR LA REDUCCION DE
TIEMPO EN GENERAR REPORTES.

Se debe tomar en cuenta que el tiempo presentado para el PRE-TEST es, LA SUMA TOTAL DE
TODO LAS ACTIVIDADES QUE SE REALIZAN PARA PODER TOMAR UN REPORTE,
mientras que para el POST-TEST, es la utilización de la solución informática integrando en los
datos, se probó para las siguientes consultas:
 Reporte 1 - 10  Reporte de consulta de datos Alumno
 Reporte 11 - 16  Reporte de consulta de datos Bachiller
 Reporte 17 - 19  Reporte de consulta de datos Maestría
 Reporte 20  Reporte de estadísticos de Doctorado

DATOS PRE -TEST

RANGO N° REPORTES COLOR

BAJO <30% 0
MEDIO > 30 % Y < 50% 8
ALTO > 50% 12

N° REPORTE t(tiempo ) ms PORCENTAJE

1 1920000 53.33%
2 2040000 56.67%
3 600000 16.67%
4 2400000 66.67%
5 2100000 58.33%
6 840000 23.33%
7 2220000 61.67%
8 2280000 63.33%
9 660000 18.33%
10 2220000 61.67%
11 552000 15.33%
12 2700000 75.00%
13 720000 20.00%

77
 14 1860000 51.67%
15 1980000 55.00%
16 660000 18.33%
17 2400000 66.67%
18 600000 16.67%
19 3000000 83.33%
20 594000 16.50%
CANTIDAD DE TIEMPO UTILIZADO
NORMALMENTE AL 100 % SIN SOLUCION
INFORMATICA 3600000

DATOS POST -TEST

RANGO N° REPORTES COLOR

BAJO <30% 4
MEDIO > 30 % Y < 50% 11
ALTO > 50% 5

N° REPORTE t(tiempo ) ms PORCENTAJE

1 36000 60.00%
2 24000 40.00%
3 27000 45.00%
4 21000 35.00%
5 15600 26.00%
6 24000 40.00%
7 28800 48.00%
8 12600 21.00%
9 23340 38.90%
10 40200 67.00%
11 14400 24.00%
12 44400 74.00%
13 25800 43.00%
14 21600 36.00%
15 22920 38.20%
16 28980 48.30%
17 16800 28.00%
18 19500 32.50%
19 46920 78.20%
20 16440 27.40%
CANTIDAD DE TIEMPO UTILIZADO
NORMALMENTE AL 100 % CON
SOLUCION INFORMATICA 60000

78
 ANEXO 2: DATOS DEL PRE Y POST TEST PARA LA MEDIR EL NIVEL DE
SATISFACCION DEL PERSONAL

Para este análisis se realizó un cuestionario con la siguiente pregunta:

¿Si tuvieras que definir en qué nivel se encuentra la solución informática en el tema de
generación de reportes a tiempo, donde lo clasificarías?

CANTIDAD
EMPLEADOS COLOR
BAJO 12
MEDIO 6
ALTO 2

N°
EMPLEADO BAJO MEDIO ALTO
1 0 1 0
2 1 0 0
3 1 0 0
4 0 1 0
5 1 0 0
6 0 1 0
7 1 0 0
8 1 0 0
9 0 0 1
10 1 0 0
11 0 1 0
12 1 0 0

79
 13 1 0 0
14 0 1 0
15 1 0 0
16 0 0 1
17 1 0 0
18 0 1 0
19 1 0 0
20 1 0 0
TOTAL 12 6 2
DATOS PRE –TEST

80
 DATOS POST–TEST

CANTIDAD
EMPLEADOS COLOR
BAJO 2
MEDIO 8
ALTO 10

N°
EMPLEADO BAJO MEDIO ALTO
1 0 1 0
2 0 1 0
3 1 0 0
4 0 1 0
5 1 0 0
6 0 1 0
7 0 1 0
8 0 0 1
9 0 0 1
10 0 0 1
11 0 1 0
12 0 0 1
13 0 0 1
14 0 1 0
15 0 0 1
16 0 0 1
17 0 0 1
18 0 1 0
19 0 0 1
20 0 0 1
TOTAL 2 8 10

81