universidad regional autÓnoma de los …dspace.uniandes.edu.ec/bitstream/123456789/5258/1/... ·...
TRANSCRIPT
UNIVERSIDAD REGIONAL AUTÓNOMA DE LOS ANDES
“UNIANDES”
FACULTAD DE SISTEMAS MERCANTILES
CARRERA DE SISTEMAS
PROYECTO DE INVESTIGACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO DE
INGENIERO EN SISTEMAS E INFORMATICA
TEMA:
HERRAMIENTA ORM PARA MEJORAR LA PRODUCTIVIDAD DE LA
EMPRESA INTERFASES SOFTWARE GROUP.
AUTOR: CHINGO ESQUIVEL WASHINGTON BRYAN
TUTOR: ING. BAÑO NARANJO FREDDY PATRICIO, M.Sc.
AMBATO – ECUADOR
2016
APROBACIÓN DEL ASESOR DEL TRABAJO DE TITULACIÓN:
CERTIFICACIÓN:
Quien subscribe, legalmente CERTIFICA QUE: El presente Trabajo de Titulación realizado
por el señor Washington Bryan Chingo Esquivel, estudiante de la carrera de sistemas,
facultad de Sistemas Mercantiles, con el Tema “HERRAMIENTA ORM PARA MEJORAR
LA PRODUCTIVIDAD DE LA EMPRESA INTERFASES SOFTWARE GROUP”, ha sido
prolijamente revisado, y cumple con todos requisitos establecidos en la normativa pertinente
de la Universidad Regional Autónoma de los Andes -UNIANDES-, por lo que apruebe su
presentación.
Ambato, Julio 2016
Ing. Freddy Baño, M.Sc.
ASESOR
DECLARACIÓN DE LA AUTENTICIDAD
Yo, Washington Bryan Chingo Esquivel, estudiante de la carrera de Sistemas, facultad
de sistemas mercantiles, declaro que todos los resultados obtenidos en el presente trabajo
de investigación, previo a la obtención del título de INGENIERO EN SISTEMAS E
INFORMÁTICA, son absolutamente originales, auténticos y personales; a excepción de las
citas, por lo que son de mi exclusiva responsabilidad.
Ambato, Julio 2016
Sr. Washington Bryan Chingo Esquivel
CI. 0502803307
AUTOR
DERECHOS DE AUTOR
Yo, Washington Bryan Chingo Esquivel, declaro que conozco y acepto la disposición
constante en el literal d) del Art. 85 del Estatuto de la Universidad Regional Autónoma de
Los Andes, que en su parte pertinente textualmente dice: El Patrimonio de Ia UNIANDES,
está constituido por: La propiedad intelectual sobre las Investigaciones, trabajos científicos
o técnicos, proyectos profesionales y consultaría que se realicen en la Universidad o por
cuenta de ella;
Ambato, Julio de 2016
Sr. Washington Bryan Chingo Esquivel
CI. 0502803307
AUTOR
DEDICATORIA
Con todo mi cariño y mi amor
para las personas que hicieron todo en la vida
para que yo pudiera lograr mis sueños,
por motivarme y darme la mano cuando
sentía que el camino se terminaba,
a ustedes por siempre mi corazón y
mi agradecimiento.
Washington Bryan Chingo Esquivel
AGRADECIMIENTOS
A mis abuelitos por siempre estar a mi lado.
A mis padres por todo su cariño y compresión.
A mi tía Mery por ser una madre más para mí.
A mis hermanos por ayudarme y brindarme su apoyo.
A mis profesores por brindarme todo su conocimiento.
Washington Bryan Chingo Esquivel
RESUMEN EJECUTIVO
El Desarrollo de software busca mejorar la productividad de las empresas por medio de la
automatización de ciertos procesos, pero las propias empresas dedicadas a este ámbito se
olvidan de su productividad y de usar herramientas en el desarrollo, haciendo de este un
proceso lento y con varios defectos.
Con el presente proyecto se fundamentó bibliográficamente los diferentes paradigmas de
programación, los Sistemas Gestores de bases de Datos, los patrones de diseño, ingeniería
de software y los ORM que son fundamentales para entender la investigación.
Se utilizó una metodología de investigación acorde a la propuesta y se utilizaron diferentes
técnicas e instrumentos para recolectar la información.
Se recurrió al Proceso de Software Personal como metodología para desarrollar la
propuesta, lo que permitió un desarrollo rápido de la herramienta admitiendo realizar los
cambios necesarios tanto en diseño como en codificación sin tener que replantear toda la
metodología.
Al final se logró alcanzar un buen resultado no solo para la empresa sino para el
investigador que reforzó los conocimientos previos y adquirió otros nuevos de gran
importancia para su vida profesional.
ABSTRACT
Software development seeks to improve the business productivity through automation of
certain processes, but the own companies dedicated to this area forget their productivity and
use tools in developing, making this a slow process and several defects.
With this project bibliographically based upon different programming paradigms, Systems
Managers databases, design patterns, software engineering and ORM that are fundamental
to understanding research.
A research methodology according to the proposal was used and different techniques and
instruments were used to collect the information.
Personal Software Process was used as a methodology for developing the proposal,
allowing rapid development of the tool admitting changes in both design and coding without
having to rethink the methodology.
At the end, a good result is achieved not only for the company but for the researcher who
reinforced previous knowledge and acquired new ones of great importance for his
professional life.
INDICE GENERAL
Pág.
APROBACIÓN DEL ASESOR DEL TRABAJO DE TITULACIÓN
DECLARACIÓN DE LA AUTENTICIDAD
DERECHOS DE AUTOR
DEDICATORIA
AGRADECIMIENTOS
RESUMEN EJECUTIVO
ABSTRACT
INTRODUCCIÓN ............................................................................................................... 1
ANTECEDENTES DE LA INVESTIGACIÓN ................................................................................. 1
FORMULACIÓN DEL PROBLEMA ............................................................................................ 2
OBJETO DE INVESTIGACIÓN ................................................................................................. 3
IDENTIFICACIÓN DE LA LÍNEA DE INVESTIGACIÓN ................................................................... 3
IDEA A DEFENDER ............................................................................................................... 4
JUSTIFICACIÓN .................................................................................................................... 4
CAPÍTULO I. ..................................................................................................................... 5
1. MARCO TEÓRICO............................................................................................. 5
1.1. INGENIERÍA DE SOFTWARE .................................................................................... 5
1.1.1. Definición .................................................................................................. 5
1.1.2. Características del Software .................................................................... 5
1.1.2.1. El software se desarrolla ................................................................................. 5
1.1.2.2. El software no se estropea .............................................................................. 6
1.1.2.3. El software se construye a medida ................................................................. 7
1.1.3. Capas de la Ingeniería de Software ......................................................... 7
1.1.3.1. Procesos ........................................................................................................... 8
1.1.3.2. Métodos ............................................................................................................ 9
1.1.3.3. Herramientas .................................................................................................... 9
1.1.4. Ciclo de Vida de desarrollo de Software ................................................. 9
1.1.4.1. Modelos de ciclo de vida del software .................................................. 10
1.2. BASES DE DATOS .............................................................................................. 12
1.2.1. Introducción ............................................................................................ 12
1.2.2. Sistemas Gestores de Bases de Datos ................................................. 12
1.2.2.1. Funciones de los SGBD ................................................................................. 13
1.2.3. Tipos de Modelos ................................................................................... 15
1.2.3.1. Modelo jerárquico .......................................................................................... 15
1.2.3.2. Modelo en red (Codasyl) ................................................................................ 16
1.2.3.3. Modelo de bases de datos orientadas a objetos .......................................... 17
1.2.3.4. Bases de datos objeto-relacionales .............................................................. 18
1.2.3.5. Modelo Relacional .......................................................................................... 18
1.2.3.6. Modelo Entidad-Relación ............................................................................... 19
1.2.4. Gestores de Bases de Datos SQL ......................................................... 19
1.2.4.1. SQL Server ...................................................................................................... 19
1.2.4.2. MYSQL ............................................................................................................ 20
1.2.4.3. PostgreSQL .................................................................................................... 21
1.3. PARADIGMAS DE PROGRAMACIÓN ...................................................................... 22
1.3.1. Programación Estructurada .......................................................................... 22
1.3.2. Programación Orientada a Objetos ............................................................... 23
1.4. Lenguajes de Programación .................................................................. 24
1.4.1. JAVA ............................................................................................................... 24
1.4.2. C Sharp ........................................................................................................... 25
1.5. Lenguajes de Modelado Conceptual ..................................................... 25
1.5.1. Lenguaje Unificado de Modelado .................................................................. 26
1.5.2. ORM ................................................................................................................. 26
1.6. Mapeo Objeto Relacional ....................................................................... 27
1.6.1. Patrones de Diseño ................................................................................ 28
1.6.1.1. Patrón Repository .......................................................................................... 28
1.6.1.2. Patrón Active Record ..................................................................................... 28
1.7. PRODUCTIVIDAD ................................................................................................ 30
1.7.1. Introducción ............................................................................................ 30
1.7.2. Productividad y Competitividad ............................................................ 31
1.7.2.1. Competitividad ............................................................................................... 31
1.7.3. Tecnología y Productividad ................................................................... 31
1.8. CONCLUSIONES PARCIALES DEL CAPITULO ......................................................... 32
CAPÍTULO II. .................................................................................................................. 34
2. MARCO METODOLÓGIO ................................................................................ 34
2.1. CARACTERIZACIÓN DEL SECTOR......................................................................... 34
2.2. DESCRIPCIÓN DE PROCEDIMIENTO METODOLÓGICO ............................................. 35
2.2.1. Métodos de Investigación ...................................................................... 35
2.2.1.1. Histórico-Lógico ............................................................................................... 35
2.2.1.2. Sintético ............................................................................................................. 35
2.2.1.3. Sistémico ........................................................................................................... 35
2.2.2. Modalidad de la Investigación ............................................................... 35
2.2.3. Métodos Técnicas e Instrumentos ........................................................ 36
2.2.4. Población y Muestra ............................................................................... 37
2.2.5. Análisis e Interpretación de Resultados ............................................... 37
2.2.5.1. Entrevista al Ingeniero Henry Baño Jefe de Desarrollo de Interfases Software
Group. ............................................................................................................................. 37
2.2.5.2. Entrevista al Ingeniero Guillermo Núñez Programador de Interfases Software
Group. ............................................................................................................................. 41
2.2.5.3. Resultados de la Observación al proceso de programación. ........................ 43
2.2.6. Conclusiones parciales de Capítulo ...................................................... 44
CAPÍTULO III. ................................................................................................................. 45
3. DESARROLLO DE LA PROPUESTA .............................................................. 45
3.1. TÍTULO DE LA PROPUESTA .................................................................................. 45
3.2. OBJETIVOS ........................................................................................................ 45
3.2.1. Objetivo General ..................................................................................... 45
3.2.2. Objetivos Específicos............................................................................. 45
3.3. DESARROLLO DEL SISTEMA ................................................................................ 46
3.3.1. Definición de la metodología de desarrollo de software ................... 46
3.3.2. Proceso de Software Personal .............................................................. 46
3.4. DECLARACIÓN REQUISITOS ................................................................................ 47
3.4.1. Casos de Uso .......................................................................................... 48
3.4.1.1. Caso de Uso de Codificación ........................................................................ 48
3.4.1.2. Caso de uso Conectar .................................................................................... 49
3.5. PLANEACIÓN ..................................................................................................... 53
3.6. DISEÑO ............................................................................................................. 54
3.6.1. Formulario Login .................................................................................... 54
3.6.2. Formulario Básico .................................................................................. 55
3.6.4. Formulario Informe ................................................................................. 57
3.7. CODIFICACIÓN ................................................................................................... 58
3.8. REVISIÓN DE CÓDIGO ......................................................................................... 61
3.9. COMPILACIÓN .................................................................................................... 62
3.11. ANÁLISIS DE ERRORES ....................................................................................... 64
3.12. CUADERNO DE REGISTRO DE DEFECTOS ............................................................. 65
3.13. REGISTRO DE TIEMPOS ....................................................................................... 66
3.14. GRÁFICOS COMPARATIVOS ................................................................................ 69
CONCLUSIONES ............................................................................................................ 70
RECOMENDACIONES .................................................................................................... 71
BIBLIOGRAFIA
ANEXOS
Índice Figuras
Figura 1. Curvas de falla del software .............................................................................. 6
Figura 2. Capas de la Ingeniería de Software. ............................................................... 8
Figura 3. Flujo del Proceso .............................................................................................. 11
Figura 4. Función de descripción .................................................................................... 13
Figura 5. Modelos de Datos ............................................................................................. 15
Figura 6. Modelo Jerárquico ............................................................................................ 16
Figura 7. Modelo Codasyl ................................................................................................. 17
Figura 8.Modelo de Datos Orientado a Objetos ........................................................... 18
Figura 9. Estructuras Básicas .......................................................................................... 23
Figura 10.Clases e Instancias ......................................................................................... 24
Figura 11. Patrón Repository ........................................................................................... 28
Figura 12. Patrón Active Record ..................................................................................... 29
Figura 13.Hibernate ........................................................................................................... 30
Figura 14. Flujo de procesos del Modelo PSP .............................................................. 47
Figura 15. Caso de uso de Codificación ........................................................................ 48
Figura 16.Caso de Uso Conexión ................................................................................... 50
Figura 17. Diagrama del ORM ......................................................................................... 52
Figura 18. Formulario Login ............................................................................................. 54
Figura 19. Diseño Formulario Básico ............................................................................. 55
Figura 20. Panel Opciones ............................................................................................... 56
Figura 21. Formulario Informe ......................................................................................... 57
Figura 22. Comparativa Plan-Real .................................................................................. 69
Figura 23. Comparativa Defectos ................................................................................... 69
INDICE TABLAS
Tabla 1. Población ............................................................................................................. 37
Tabla 2. Ficha de Observación ........................................................................................ 43
Tabla 3. Diccionario de Actores ....................................................................................... 48
Tabla 4. Descripción de los Procesos ............................................................................ 49
Tabla 5. Descripción de los Actores ............................................................................... 50
Tabla 6. Descripción de los Procesos ............................................................................ 51
Tabla 7. Descripción del Diagrama de ORM ................................................................. 52
Tabla 8. Formulario de Resumen del Plan .................................................................... 53
Tabla 9. Ficha de estándar de codificación ................................................................... 58
Tabla 10. Ficha de codificación de conexión ................................................................ 59
Tabla 11. Ficha de estandarización ................................................................................ 60
Tabla 12. Ficha de Revisión de Código ......................................................................... 61
Tabla 13.Ficha de Prueba 1 ............................................................................................. 62
Tabla 14.Ficha de Prueba 2 ............................................................................................. 62
Tabla 15.Ficha de Prueba 10 ........................................................................................... 63
Tabla 16.Ficha de Prueba 15 ........................................................................................... 63
Tabla 17. Análisis de Errores ........................................................................................... 64
Tabla 18. Cuaderno de Registro de Defectos ............................................................... 65
Tabla 19. Cuaderno de registro de tiempos .................................................................. 66
1
INTRODUCCIÓN
Antecedentes de la Investigación
En una investigación preliminar llevado a cabo en la biblioteca UNIANDES y en algunos
repositorios web de algunas universidades del Ecuador pudimos encontrar algunas tesis de
grado que nos han servido como antecedentes investigativos del presente trabajo de
titulación, entre las tesis realizadas tenemos:
La tesis de Freire Reyes Tatiana Alexandra, Sistema de gestión de información
odontológica utilizando ORM para el Departamento de Bienestar Uni como objetivo el
estudio de la persistencia de objetos Java en una base de datos relacional, utilizando para
ello una de las soluciones disponibles para esta integración denominada ORM (Mapeo
Objeto – Relacional), en donde la persistencia se realiza de forma totalmente automática y
transparente a la lógica de la aplicación. También se incluye el análisis, diseño e
implementación del Sistema de Gestión de Información Odontológica para el Departamento
de Bienestar Universitario de la UTN. Todo este desarrollo se enmarca en un ámbito de
ejecución Web con requerimientos clásicos de una aplicación empresarial.
La primera revolución en la información fue el invento de la escritura, la segunda la generó
el libro, la tercera la imprenta (Drucker, 1999) y, por último, la cuarta y actual revolución en
la información es resultado de las innovaciones tecnológicas de las últimas seis décadas
en el campo de la electrónica y las comunicaciones, y está modificando muchos aspectos
de la vida. (Gutiérrez Pulido, 2010)
Uno de las aspectos modificados por esta revolución es la misma forma de almacenar la
información que hasta hace unas décadas se realizaba de forma manual, y era muy difícil
acceder a esta, con la innovación tecnológica aparecieron programas que podían
almacenar cierta cantidad de datos.
En un principio los programas accedían físicamente al disco para escribir los datos, algo
que implicaba que el programa tuviese que implementar toda la lógica de una base de datos
para permitir agregar, modificar o eliminar datos. Con el tiempo se han desarrollado lo que
2
se conoce como sistemas de bases de datos, que permiten mantener entidades, sus
respectivas relaciones y sus atributos. (Sánchez Asenjo, 2009)
Las bases de Datos Relacionales son las predilectas para almacenar la información de la
mayoría de sistemas. Para acceder a esta información se desarrollan interfaces para cada
sistema de base de datos con sentencias SQL específicas. (Aramburu Cabo & Sanz Blasco,
2013)
La realización de estas sentencias está plenamente ligado a la base de datos por lo cual
cuando una de las entidades de esta cambia, las sentencias que se realizan en el software
tienen que cambiar, cuando el proceso de desarrollo de software ha llegado a la fase de
codificación hace que estos cambios sean una gran pérdida de tiempo lo cual repercute en
la calidad final del software.
Para evitar estos problemas se han desarrollado diferentes herramientas orientadas hacia
la persistencia de datos que permiten reducir el tiempo de desarrollo, estandarizar la capa
de abstracción de datos y también atenuar los problemas de un cambio brusco en la base
de datos , existen gran variedad de ORM como Hibernate, Doctrine y Core Data.
Formulación del Problema
El desarrollo de software siempre busca mejorar la productividad de las empresas, pero al
enfocarse tanto en las necesidades de otras, muchas veces esto hace que la empresa
dedicada a su desarrollo olvide su propia productividad.
Al enfocarse en trabajos de codificación repetitivos, es muy frecuente cometer errores ya
que el trabajo se vuelve tedioso y aburrido, lo que fácilmente desconcentra a los
desarrolladores.
En ocasiones los nuevos desarrolladores omiten ciertas reglas definidas por las empresas
por facilidad propia en desmedro de la calidad y las buenas prácticas de ingeniería de
software.
3
El tiempo de desarrollo de las clases dependiendo de la magnitud de la base de datos es
muy alto, a partir de ello el tiempo de pruebas incrementa aún más la entrega de estos
componentes para iniciar el desarrollo de las reglas de negocio.
Por todo esto es necesario preguntarse como mejorar la productividad de la empresa
Interfases Software Group en el desarrollo de software.
Delimitación del Problema
La presente investigación se realizara en la empresa Interfases Software Group que está
ubicada en el Km5½ vía a Baños. En el periodo de enero a agosto del 2016 y pretende
mejorar la productividad en el desarrollo de software de la empresa Interfases Software
Group.
Objeto de Investigación
Desarrollo de Software
Campo de Acción
Mapeo objeto-relacional(ORM)
Identificación de la Línea de Investigación
Desarrollo de Software y Programación de Sistemas
Objetivos:
Objetivo General:
Desarrollar una herramienta ORM para la mejorar la productividad de aplicaciones de la
empresa Interfases Software Group.
Objetivos Específicos
Fundamentar científicamente los componentes que forman un ORM, la persistencia
de datos y el desarrollo de software.
4
Realizar una investigación de campo que determine el estado actual de
productividad de la empresa Interfases Software Group
Diseñar un modelo de mapeo objeto relacional, que permita mejorar la productividad
de la empresa Interfaces Software Group.
Validar la propuesta
Idea A Defender
Con el uso de una herramienta ORM se mejorará la eficiencia, eficiencia y efectividad en
el desarrollo de aplicaciones en la empresa Interfases software Group.
Justificación
El desarrollo de software busca mejorar la productividad de una empresa por medio de la
automatización y el uso de herramientas, las empresas que se dedican al desarrollo de
software tienen como objetivo ayudar a otras empresas en la automatización y desarrollo
de herramientas para este fin, pero muchas veces las mismas olvidan su propia
productividad.
Las Herramientas ORM se han desarrollado con este fin, al evitarnos repetir muchas líneas
de programación en la capa de abstracción pero cada una tiene su estándar o su propio
lenguaje por lo cual se requeriría tiempo adicional para ocuparlas.
El desarrollo de este ORM tiene como objetivo proveernos una herramienta acorde a
nuestras necesidades y estándar de programación haciendo que el desarrollo de software
se centre únicamente al diseño de la base de datos, interfaz y la capa de negocios,
olvidándonos casi al completo de la capa de abstracción.
Al reducir ese tiempo de desarrollo de la capa de abstracción, este tiempo se puede utilizar
para mejorar las otras áreas de desarrollo de software mejorando la calidad, reduciendo las
5
incidencias y permitiendo un mejor mantenimiento de los programas desarrollados por la
empresa Interfases Software Group.
CAPÍTULO I.
1. MARCO TEÓRICO
1.1. Ingeniería de software
1.1.1. Definición
La ingeniería del software es la aplicación de un enfoque sistemático, disciplinado y
cuantificable para el desarrollo, operación y mantenimiento del software, que es la
aplicación de la ingeniería del software. (IEEE, 1990)
La ingeniería de Software es el establecimiento y uso de principios fundamentales de la
ingeniería con objeto de desarrollar en forma económica software que sea confiable y que
trabaje con eficiencia en máquinas reales. (Pressman, 2010)
En base a estas definiciones podemos decir que la ingeniería de software es una disciplina
que nos ayuda a llevar un desarrollo organizado de software asegurando su calidad.
1.1.2. Características del Software
El software es un elemento lógico y se diferencia del hardware, un elemento físico, en sus
características.
1.1.2.1. El software se desarrolla
No se fabrica en el sentido clásico. Aunque existen similitudes entre el desarrollo del
software y la construcción del hardware, ambas actividades son fundamentalmente
distintas. (INTECO, 2009)
6
Cada producto software es diferente porque se construye para cumplir los requisitos únicos
de un cliente. Cada software necesita, por lo tanto, ser construido usando un enfoque de
ingeniería. (INTECO, 2009)
1.1.2.2. El software no se estropea
Los defectos no detectados harán que falle el programa durante las primeras etapas de su
vida. Sin embargo, una vez que se corrigen (suponiendo que no se introducen nuevos
errores) los fallos disminuyen. (INTECO, 2009)
Figura 1. Curvas de falla del software
Fuente: Ingeniería de Software. Un Enfoque Práctico
El software no se estropea, pero se deteriora. Durante su vida, el software sufre cambios
(mantenimiento). Conforme se hacen los cambios, es bastante probable que se introduzcan
nuevos defectos, lo que hace que el software se vaya deteriorando debido a los cambios.
(INTECO, 2009)
7
1.1.2.3. El software se construye a medida
A medida que evoluciona una disciplina de ingeniería, se crea un conjunto de componentes
estandarizados para el diseño. Los tornillos estándar y los circuitos integrados pre
construidos son sólo dos de los miles de componentes estándar que utilizan los ingenieros
mecánicos y eléctricos conforme diseñan nuevos sistemas. Los componentes reutilizables
han sido creados para que el ingeniero pueda concentrarse en los elementos
verdaderamente innovadores de un diseño; es decir, en las partes de éste que representan
algo nuevo. (Pressman, 2010)
Aunque la mayoría de la industria tiende a ensamblar componentes, en el caso del software,
la mayoría se construye a medida. Aunque la reutilización y ensamblaje de componentes
está aumentando, el software con frecuencia se construye de acuerdo a los requisitos
específicos de un cliente. (INTECO, 2009)
1.1.3. Capas de la Ingeniería de Software
El enfoque de ingeniería del software cuenta con un compromiso organizacional con la
calidad porque no es posible incorporar la ingeniería del software en una organización que
no está centrada en conseguir calidad. (INTECO, 2009)
La ingeniería del software es una tecnología multicapa. Se puede ver como un conjunto de
componentes estratificados, que reposan sobre ese enfoque de calidad.
8
Figura 2. Capas de la Ingeniería de Software.
Fuente: Figura Propia Basado en Curso de Introducción
A la Ingeniería de Software
1.1.3.1. Procesos
El fundamento de la ingeniería del software es la capa de proceso. El proceso define un
marco de trabajo para un conjunto de áreas clave de proceso que se deben establecer para
la entrega efectiva de la tecnología de la ingeniería del software. (INTECO, 2009)
La capa de proceso define el proceso que se usará para construir el software y las
actividades y tareas que un jefe de proyecto tiene que gestionar. Por lo tanto, las áreas
claves del proceso forman la base del control de gestión de proyectos del software y
establecen el contexto en el que se aplican los métodos técnicos, se obtienen productos de
trabajo (modelos, documentos, datos, informes, formularios, etc.), se establecen hitos, se
asegura la calidad y el cambio se gestiona adecuadamente. (INTECO, 2009)
La estructura del proceso establece el fundamento para el proceso completo de la
ingeniería de software por medio de la identificación de un número pequeño de actividades
estructurales que sean aplicables a todos los proyectos de software, sin importar su tamaño
o complejidad. Además, la estructura del proceso incluye un conjunto de actividades
sombrilla que son aplicables a través de todo el proceso del software. (Pressman, 2010)
9
1.1.3.2. Métodos
Los métodos de la ingeniería de software proporcionan la experiencia técnica para elaborar
software. Incluyen un conjunto amplio de tareas, como comunicación, análisis de los
requerimientos, modelación del diseño, construcción del programa, pruebas y apoyo.
(Pressman, 2010)
La capa de métodos contiene los métodos definidos para realizar esas actividades de forma
eficiente. Se centra en cómo se han de realizar las actividades técnicas. Los personas
involucradas usan los métodos para realizar las actividades de ingeniería fundamentales
necesarias para construir el software. (INTECO, 2009)
Para varias actividades de proceso, la capa de métodos contiene el correspondiente
conjunto de métodos técnicos para usar. Esto abarca un conjunto de reglas, los modos de
representación gráficos o basados en texto, y las guías relacionadas para la evaluación de
la calidad de la información representada. (INTECO, 2009)
1.1.3.3. Herramientas
La capa de herramientas proporciona soporte a las capas de proceso y métodos
centrándose en el significado de la automatización de algunas de las actividades manuales.
(INTECO, 2009)
Cuando se usan herramientas, la documentación se convierte en una parte integral del
trabajo hecho, en vez de ser una actividad adicional. De ahí que la documentación no se
tenga que realizar como actividad adicional. Las herramientas se pueden utilizar para
realizar actividades de gestión de proyecto así como para actividades técnicas. (INTECO,
2009)
1.1.4. Ciclo de Vida de desarrollo de Software
El ciclo de vida es el conjunto de fases por las que pasa el sistema que se está desarrollando
desde que nace la idea inicial hasta que el software es retirado o remplazado (muere).
10
También se denomina a veces paradigma. Un ciclo de vida para un proyecto se compone
de fases sucesivas compuestas por tareas que se pueden planificar. (INTECO, 2009)
Una estructura general para la ingeniería de software define cinco actividades estructurales:
comunicación, planeación, modelado, construcción y despliegue. (Pressman, 2010)
1.1.4.1. Modelos de ciclo de vida del software
La ingeniería del software se vale de una serie de modelos que establecen y muestran las
distintas etapas y estados por los que pasa un producto software, desde su concepción
inicial, pasando por su desarrollo, puesta en marcha y posterior mantenimiento, hasta la
retirada del producto. A estos modelos se les denomina “Modelos de ciclo de vida del
software”. El primer modelo concebido fue el de Royce, más comúnmente conocido como
“Cascada” o “Lineal Secuencial”. Este modelo establece que las diversas actividades que
se van realizando al desarrollar un producto software, se suceden de forma lineal. (INTECO,
2009)
Un flujo de proceso lineal ejecuta cada una de las cinco actividades estructurales en
secuencia, comenzando por la comunicación y terminando con el despliegue. Un flujo de
proceso iterativo repite una o más de las actividades antes de pasar a la siguiente. Un flujo
de proceso evolutivo realiza las actividades en forma “circular”. A través de las cinco
actividades, cada circuito lleva a una versión más completa del software. Un flujo de proceso
paralelo ejecuta una o más actividades en paralelo con otras (por ejemplo, el modelado de
un aspecto del software tal vez se ejecute en paralelo con la construcción de otro aspecto
del software). (Pressman, 2010)
11
Figura 3. Flujo del Proceso
Fuente: Ingeniería de Software. Un Enfoque Práctico
12
1.2. Bases de Datos
1.2.1. Introducción
En informática se conoce como dato a cualquier elemento informativo que tenga relevancia
para un usuario. Desde el primer momento de esta ciencia se ha reconocido al dato como
al elemento fundamental de trabajo en un ordenador. Por ello se han realizado numerosos
estudios y aplicaciones para mejorar la gestión que desde las computadoras se realiza de
los datos. (Sánchez Asenjo, 2009)
La escritura fue la herramienta que permitió al ser humano poder gestionar bases cada vez
más grandes de datos. Con el tiempo aparecieron herramientas como archivos, cajones,
carpetas y fichas en las que se almacenaban los datos. Antes de la aparición del ordenador,
el tiempo requerido para manipular estos datos era enorme. Sin embargo el proceso de
aprendizaje era relativamente sencillo ya que se usaban elementos que el usuario
reconocía perfectamente. (Sánchez Asenjo, 2009)
Por esa razón, la informática ha adaptado sus herramientas para que los elementos que el
usuario maneja en el ordenador se parezcan a los que utilizaba manualmente. Así en
informática se sigue hablado de ficheros, formularios, carpetas, directorios. (Sánchez
Asenjo, 2009)
1.2.2. Sistemas Gestores de Bases de Datos
Se define un Sistema Gestor de Base de Datos, en adelante SGBD, como el conjunto de
herramientas que facilitan la consulta, uso y actualización de una base de datos. (Lopez
Moltalbán & De Castro Vázquez, 2014)
Un sistema gestor de bases de datos o SGBD (aunque se suele utilizar más a menudo las
siglas DBMS procedentes del inglés, Data Base Management System) es el software que
permite a los usuarios procesar, describir, administrar y recuperar los datos almacenados
en una base de datos. (Sánchez Asenjo, 2009)
13
En estos Sistemas se proporciona un conjunto coordinado de programas, procedimientos y
lenguajes que permiten a los distintos usuarios realizar sus tareas habituales con los datos,
garantizando además la seguridad de los mismos. (Sánchez Asenjo, 2009)
1.2.2.1. Funciones de los SGBD
Función de descripción o definición
Permite al diseñador de la base de datos crear las estructuras apropiadas para integrar
adecuadamente los datos. Esta función es la que permite definir las tres estructuras de la
base de datos (relacionadas con sus tres esquemas). (Sánchez Asenjo, 2009)
Figura 4. Función de descripción
Fuente: https://basesdedatosavanzadas.wikispaces.com/
Bases+de+Datos+Multimedia
Esta función se realiza mediante el lenguaje de descripción de datos o DDL (Data Definition
Language). Este lenguaje permite crear toda la estructura de una base de datos (desde
tablas hasta usuarios). Sus cláusulas son del tipo DROP (Eliminar objetos) y CREATE
(Crear objetos). (Lopez Moltalbán & De Castro Vázquez, 2014)
14
Función de manipulación
Permite modificar y utilizar los datos de la base de datos. Se realiza mediante el lenguaje
de modificación de datos o DML (Data Manipulation Language). Este lenguaje permite con
4 sentencias sencillas seleccionar determinados datos (SELECT), insertar datos (INSERT),
modificarlos (UPDATE) o incluso borrarlos (DELETE). (Lopez Moltalbán & De Castro
Vázquez, 2014)
Actualmente se suele distinguir aparte la función de buscar datos en la base de Datos
(función de consulta). Para lo cual se proporciona un lenguaje de consulta de datos o DQL.
(Sánchez Asenjo, 2009)
Función de control
Mediante esta función los administradores poseen mecanismos para proteger las visiones
de los datos permitidas a cada usuario, además de proporcionar elementos de creación y
modificación de esos usuarios. (Sánchez Asenjo, 2009)
El lenguaje que implementa esta función es el lenguaje de control de datos o DCL (Data
Control Language) incluye comandos (GRANT y REVOKE) que permiten al administrador
gestionar el acceso a los datos contenidos en la base de datos. (Lopez Moltalbán & De
Castro Vázquez, 2014)
SGBD: Estructura Multicapa
El proceso que realiza un SGBD está en realidad formado por varias capas que actúan
como interfaces entre el usuario y los datos. Fue el propio organismo ANSI (en su modelo
X3/SPARC que luego se comenta) la que introdujo una mejora de su modelo de bases de
datos en 1988 a través de un grupo de trabajo llamado UFTG (User Facilities Task Group,
grupo de trabajo para las facilidades de usuario). Este modelo toma como objeto principal
al usuario habitual de la base de datos y modela el funcionamiento de la base de datos en
una sucesión de capas cuya finalidad es ocultar y proteger la parte interna de las bases de
datos. (Sánchez Asenjo, 2009)
15
1.2.3. Tipos de Modelos
Se pueden clasificar los SGBD de muchas formas, por ejemplo, según las bases de datos
que gestionan, clasificando los SGBD según traten bases de datos relaciónales, bases de
datos orientadas a objetos, etc. Puesto que en la actualidad, la mayoría de los SGBD
integran múltiples filosofías y tipos de funcionamiento. (Lopez Moltalbán & De Castro
Vázquez, 2014)
Figura 5. Modelos de Datos
Fuente: sistemas gestores de bases de datos
El modelo lógico está más cerca del modelo físico, el que utiliza internamente el ordenador,
el modelo conceptual es el más cercano al usuario, el lógico es el encargado de establecer
el paso entre el modelo conceptual y el modelo físico del sistema. (Sánchez Asenjo, 2009)
1.2.3.1. Modelo jerárquico
Era utilizado por los primeros SGBD, desde que IBM lo definió para su IMS (Information
Management System, Sistema Administrador de Información) en 1970. Se le llama también
modelo en árbol debido a que utiliza una estructura en árbol para organizar los datos.
(Sánchez Asenjo, 2009)
16
Figura 6. Modelo Jerárquico
Fuente: http://www.nosolousabilidad.com/articulos/
clas_facetadas1.htm
Los datos de este modelo se almacenan en estructuras lógicas llamadas segmentos. Los
segmentos se relacionan entre sí utilizando arcos. La forma visual de este modelo es de
árbol invertido, en la parte superior están los padres y en la inferior los hijos. (Sánchez
Asenjo, 2009)
1.2.3.2. Modelo en red (Codasyl)
Es un modelo que ha tenido una gran aceptación (aunque apenas se utiliza actualmente).
En especial se hizo popular la forma definida por Codasyl a principios de los 70 que se ha
convertido en el modelo en red más utilizado. (Sánchez Asenjo, 2009)
17
Figura 7. Modelo Codasyl
Fuente:http://www.sites.upiicsa.ipn.mx/polilibros/portal/polilibros/P_proceso/Lengua
jes_de_Programacion_I/Lenguajes_de_Programacion_I/POLILIBRO/UNIDAD2/13.
htm
El modelo en red organiza la información en registros (también llamados nodos) y enlaces.
En los registros se almacenan los datos, mientras que los enlaces permiten relacionar estos
datos. Las bases de datos en red son parecidas a las jerárquicas sólo que en ellas puede
haber más de un padre. (Sánchez Asenjo, 2009)
1.2.3.3. Modelo de bases de datos orientadas a objetos
Desde la aparición de la programación orientada a objetos (POO u OOP) se empezó a
pensar en bases de datos adaptadas a estos lenguajes. La programación orientada a
objetos permite cohesionar datos y procedimientos, haciendo que se diseñen estructuras
que poseen datos (atributos) en las que se definen los procedimientos (operaciones) que
pueden realizar con los datos. En las bases orientadas a objetos se utiliza esta misma idea.
(Sánchez Asenjo, 2009)
Adopta como modelo de datos el de los lenguajes orientados a objetos, permitiendo así el
uso de estructuras de datos tan complejas como sea necesario, y eliminando en gran
medida las barreras entre el desarrollo de aplicaciones y la gestión de datos y permiten la
extensibilidad con nuevos tipos de datos complejos, permitiendo incorporar operaciones
arbitrarias sobre ellos. (Aramburu Cabo & Sanz Blasco, 2013)
18
Figura 8.Modelo de Datos Orientado a Objetos
Fuente: https://sites.google.com/site/manipulacionbasededatos/
home/modelo-de-base-de-datos
1.2.3.4. Bases de datos objeto-relacionales
En las bases de datos objeto relacional se intenta conseguir una compatibilidad relacional
dando la posibilidad de integrar mejoras de la orientación a objetos. (Sánchez Asenjo, 2009)
Estas bases de datos se basan en el estándar SQL 99. En ese estándar se añade a las
bases relacionales la posibilidad de almacenar procedimientos de usuario, triggers, tipos
definidos por el usuario, consultas recursivas, bases de datos OLAP, tipos LOB. (Sánchez
Asenjo, 2009)
Las últimas versiones de la mayoría de las clásicas grandes bases de datos relacionales
(Oracle, SQL Server, Informix) son objeto relacionales. (Sánchez Asenjo, 2009)
1.2.3.5. Modelo Relacional
El modelo relacional se ha establecido actualmente como el principal modelo de datos para
las aplicaciones de procesamiento de datos. Ha conseguido la posición principal debido a
su simplicidad, que facilita el trabajo del programador en comparación con otros modelos
anteriores como el de red y el jerárquico. (Silberschatz & Henry F., 2002)
Una base de datos relacional consiste en un conjunto de tablas, a cada una de las cuales
se le asigna un nombre exclusivo. Cada fila de la tabla representa una relación entre un
19
conjunto de valores. Dado que cada tabla es un conjunto de dichas relaciones, hay una
fuerte correspondencia entre el concepto de tabla y el concepto matemático de relación, del
que toma su nombre el modelo de datos relacional. (Silberschatz & Henry F., 2002)
1.2.3.6. Modelo Entidad-Relación
El modelo de datos entidad-relación (E-R) está basado en una percepción del mundo real
consistente en objetos básicos llamados entidades y de relaciones entre estos objetos. Se
desarrolló para facilitar el diseño de bases de datos permitiendo la especificación de un
esquema de la empresa que representa la estructura lógica completa de una base de datos.
El modelo de datos E-R es uno de los diferentes modelos de datos semánticos; el aspecto
semántico del modelo yace en la representación del significado de los datos. El modelo E-
R es extremadamente útil para hacer corresponder los significados e interacciones de las
empresas del mundo real con un esquema conceptual. Debido a esta utilidad, muchas
herramientas de diseño de bases de datos se basan en los conceptos del modelo E-R.
(Silberschatz & Henry F., 2002)
1.2.4. Gestores de Bases de Datos SQL
La principal herramienta de un gestor de base de datos es la interfaz de programación con
el usuario. Este interfaz consiste en un lenguaje muy sencillo mediante el cual el usuario
realiza preguntas al servidor, contestando este a las demandas del usuario.
Este lenguaje comúnmente se denomina SQL, Structured Query Language, está
estandarizado por la ISO, es decir, todas las bases de datos que soporten SQL deben tener
la misma sintaxis a la hora de aplicar el lenguaje. Se divide en 4 sublenguajes, el total de
todos ellos permite al SGBD cumplir con las funcionalidades requeridas por CODD. (Lopez
Moltalbán & De Castro Vázquez, 2014)
1.2.4.1. SQL Server
SQL Server de Microsoft es un sistema gestor de bases de datos relacionales que se usa
desde en portátiles y ordenadores de sobremesa hasta en servidores corporativos, con una
versión compatible, basada en el sistema operativo PocketPC, disponible para dispositivos
20
de bolsillo, tales como PocketPCs y lectores de código de barras. SQL Server se desarrolló
originalmente en los años 80 en SyBase para sistemas UNIX y posteriormente pasado a
sistemas Windows NT para Microsoft. Desde 1994 Microsoft ha lanzado versiones de SQL
Server desarrolladas independientemente de Sybase, que dejó de utilizar el nombre SQL
Server a finales de los años 90. (Silberschatz & Henry F., 2002)
SQL Server proporciona servicios de réplica entre varias copias de SQL Server así como
con otros sistemas de bases de datos. Sus Analysis Services (servicios de análisis), una
parte integral del sistema, incluye dispositivos de procesamiento en conexión analítico
(OLAP, Online Analytical Processing) y recopilación de datos. SQL Server proporciona una
gran colección de herramientas gráficas y «asistentes» que guían a los administradores de
las bases de datos por tareas tales como establecer copias de seguridad regulares, réplica
de datos entre servidores y ajuste del rendimiento de una base de datos. Muchos entornos
de desarrollo soportan SQL Server, incluyendo Visual Studio de Microsoft y productos
relacionados, en particular los productos y servicios .NET. (Silberschatz & Henry F., 2002)
1.2.4.2. MYSQL
MySQL es un sistema gestor de bases de datos (SGBD, DBMS por sus siglas en inglés)
muy conocido y ampliamente usado por su simplicidad y notable rendimiento. Aunque
carece de algunas características avanzadas disponibles en otros SGBD del mercado, es
una opción atractiva tanto para aplicaciones comerciales, como de entretenimiento
precisamente por su facilidad de uso y tiempo reducido de puesta en marcha. Esto y su
libre distribución en internet bajo licencia GPL le otorgan como beneficios adicionales (no
menos importantes) contar con un alto grado de estabilidad y un rápido desarrollo. (Camps
Paré, y otros, 2007)
Para todos aquellos que son adeptos a la filosofía de UNIX y del lenguaje C/C++, el uso de
MySQL les será muy familiar, ya que su diseño y sus interfaces son acordes a esa filosofía:
“crear herramientas que hagan una sola cosa y que la hagan bien”. MySQL tiene como
principal objetivo ser una base de datos fiable y eficiente. Ninguna característica es
implementada en MySQL si antes no se tiene la certeza que funcionará con la mejor
velocidad de respuesta y, por supuesto, sin causar problemas de estabilidad. (Camps Paré,
y otros, 2007)
21
Está desarrollado en C/C++.
Se distribuyen ejecutables para cerca de diecinueve plataformas diferentes.
Está optimizado para equipos de múltiples procesadores.
Es muy destacable su velocidad de respuesta.
Soporta múltiples métodos de almacenamiento de las tablas, con prestaciones y
rendimiento diferentes para poder optimizar el SGBD a cada caso concreto.
Su administración se basa en usuarios y privilegios.
Se tiene constancia de casos en los que maneja cincuenta millones de registros,
sesenta mil tablas y cinco millones de columnas.
Sus opciones de conectividad abarcan TCP/IP, sockets UNIX y sockets NT, además de
soportar completamente ODBC.
1.2.4.3. PostgreSQL
El origen de PostgreSQL se sitúa en el gestor de bases de datos POSTGRES desarrollado
en la Universidad de Berkeley y que se abandonó en favor de PostgreSQL a partir de 1994.
Ya entonces, contaba con prestaciones que lo hacían único en el mercado y que otros
gestores de bases de datos comerciales han ido añadiendo durante este tiempo. (Camps
Paré, y otros, 2007)
PostgreSQL se distribuye bajo licencia BSD, lo que permite su uso, redistribución,
modificación con la única restricción de mantener el copyright del software a sus autores,
en concreto el PostgreSQL Global Development Group y la Universidad de California.
(Camps Paré, y otros, 2007)
22
Está desarrollado en C, con herramientas como Yacc y Lex.
La API de acceso al SGBD se encuentra disponible en C, C++, Java, Perl, PHP, Python
y TCL, entre otros.
Su administración se basa en usuarios y privilegios.
Sus opciones de conectividad abarcan TCP/IP, sockets Unix y sockets NT, además de
soportar completamente ODBC.
Es altamente confiable en cuanto a estabilidad se refiere.
1.3. Paradigmas De Programación
El mundo del desarrollo de software está sometido a un proceso evolutivo constante.
Actualmente, podemos ver cómo ha sufrido una gran evolución desde el código máquina y
el ensamblador a través de conceptos como la programación procedural, la programación
estructurada, la programación lógica, etcétera hasta llegar a la programación orientada a
objetos, que es el paradigma más extendido hoy en día. (Rodríguez Echeverría, Sosa
Sánchez, & Prieto Ramos, 2011)
1.3.1. Programación Estructurada
Distinta abstracción del mundo. La programación clásica se centra en el comportamiento,
normalmente representado por verbos, mientras que nuestra mente se centra en los seres,
a los que, normalmente, identificamos con sustantivos. (Rodríguez Echeverría, Sosa
Sánchez, & Prieto Ramos, 2011)
Dificultad en modificación y actualización. Los programas suelen tener datos compartidos
por varios subprogramas, esto puede provocar que cualquier ligera modificación en un
módulo afecte indirectamente al resto. (Rodríguez Echeverría, Sosa Sánchez, & Prieto
Ramos, 2011)
23
Figura 9. Estructuras Básicas
Fuente: https://sistemasumma.files.wordpress.com/2012/09/programacion-
estructurada.png
1.3.2. Programación Orientada a Objetos
La Programación Orientada a Objetos supone un cambio en la concepción del mundo de
desarrollo de software, introduciendo un mayor nivel de abstracción que permite mejorar
las características del código final. (Rodríguez Echeverría, Sosa Sánchez, & Prieto Ramos,
2011)
Conceptos de clase y objeto, que proporcionan una abstracción del mundo centrada en los
seres y no en los verbos. (Rodríguez Echeverría, Sosa Sánchez, & Prieto Ramos, 2011)
Los datos aparecen encapsulados dentro del concepto de clase. El acceso a los datos se
produce de manera controlada e independiente de la representación final de los mismos.
Como consecuencia, se facilita el mantenimiento y la evolución de los sistemas, al
desaparecer las dependencias entre distintas partes del sistema. (Rodríguez Echeverría,
Sosa Sánchez, & Prieto Ramos, 2011)
24
Figura 10.Clases e Instancias
Fuente: https://docs.sencha.com/extjs/6.0/other_resources/oop_concepts.html
1.4. Lenguajes de Programación
Los lenguajes de programación son idiomas artificiales diseñados para expresar cálculos y
procesos que serán llevados a cabo por ordenadores. Un lenguaje de programación está
formado por un conjunto de palabras reservadas, símbolos y reglas sintácticas y semánticas
que definen su estructura y el significado de sus elementos y expresiones. El proceso de
programación consiste en la escritura, compilación y verificación del código fuente de un
programa. (Martínez, 2011)
1.4.1. JAVA
Java es un lenguaje de programación desarrollado por Sun Microsystems. Java fue
presentado en la segunda mitad del año 1995 y desde entonces se ha convertido en un
lenguaje de programación muy popular. (Martínez, 2011)
25
“Write Once, Run Anyware”, que podría traducirse como “programar una sola vez y después
ejecutar los programas en cualquier sistema operativo”, era el objetivo del equipo de
desarrollo de Java. (Martínez, 2011)
Los programas Java se compilan a un lenguaje intermedio, denominado Bytecode. Este
código es interpretado por la máquina virtual de Java del entorno de ejecución (JRE) y así
se consigue la portabilidad en distintas plataformas. El JRE es una pieza intermedia entre
el código Bytecode y los distintos sistemas operativos existentes en el mercado. (Martínez,
2011)
1.4.2. C Sharp
Uno de los lenguajes que está adquiriendo gran popularidad es C#, un lenguaje sencillo,
amigable y poderoso. Con C# se pueden crear todo tipo de aplicaciones, desde programas
de consola para Windows y para páginas web en unión con ASP, hasta video juegos para
Xbox 360 con XNA. (Landa Cosio, 2010)
En lenguajes no administrados como C y C++ el programador es responsable de la
administración de memoria, en programas grandes esto puede ser una labor complicada,
que puede llevar a errores durante la ejecución del programa. Afortunadamente lenguajes
administrados como C# tienen un modelo en el cual nosotros como programadores ya no
necesitamos ser responsables por el uso de la memoria. El recolector de basura se encarga
de eliminar todos los objetos que ya no son necesarios, cuando un objeto deja de ser útil el
recolector lo toma y lo elimina. De esta forma se liberan memoria y recursos. (Landa Cosio,
2010)
1.5. Lenguajes de Modelado Conceptual
Los lenguajes de modelado semántico se utilizan para capturar formalmente un universo
de trabajo. A menudo vienen en una notación gráfica, conocida como diagrama de modelo
de datos o diagrama de estructura de datos. Originalmente, estos diagramas fueron
introducidos por Bachman para el diseño de esquema lógico de bases de datos de la red.
26
Desde entonces, han evolucionado para muchas anotaciones de gráficos simples marcadas
en las normas gráficas detalladas. (Voß, 2013)
1.5.1. Lenguaje Unificado de Modelado
El lenguaje de modelado Unificado (UML) fue desarrollado en la década de 1990 como
lenguaje de modelado de sistemas de software orientado a objetos. Fue estandarizado por
el Object Management Group (OMG), publicada como especificación ISO en 2005, y desde
entonces se extendió a UML 2.4.1. Al igual que en CORBA, otro estándar popular del ORM,
UML en general es bastante complejo y expresivo. (Voß, 2013)
UML proporciona notaciones gráficas para varios tipos de diagramas, que también se
pueden combinar entre sí. Las principales clases de UML diagramas son diagramas de
estructura y diagramas de comportamiento. (Voß, 2013)
Los principales tipos de diagramas de estructura mencionados por Jakob Voß (2013, pág.
148) son: “Los diagramas de clase, diagramas de objetos, diagramas de componentes y
paquetes, diagramas de despliegue, diagramas de perfil y los diagramas de estructura
compuesta”.
1.5.2. ORM
A diferencia de ERM y UML, ORM (Object-Role Modeling) es construir a partir de una base
lingüística utilizando frases estructuradas en lenguaje natural como punto de partida. ORM
no hace uso de la noción de atributos, pero considera el universo de trabajo en términos de
objetos que juegan papeles. Los objetos se clasifican en grupos de tipos de entidades y
tipos de valor. (Voß, 2013)
Las entidades pueden ser cualquiera de los conceptos abstractos (posiblemente) y son
referencias de valores. Por ejemplo, una persona (entidad) puede ser referenciada por su
nombre (valor). Modelado comienza con ejemplos concretos que se dividen en hechos
elementales y se convierten a predicados. (Voß, 2013)
27
1.6. Mapeo Objeto Relacional
El mapeo objeto-relacional es una técnica de programación para convertir datos del sistema
de tipos utilizado en un lenguaje de programación orientado a objetos al utilizado en una
base de datos relacional. En la práctica esto crea una base de datos virtual orientada a
objetos sobre la base de datos relacional. Esto posibilita el uso de las características
propias de la orientación a objetos (esencialmente la herencia y el polimorfismo). (Yanes
Enriquez & Gracia del Busto, 2011)
Las bases de datos relacionales solo permiten guardar tipos de datos primitivos (enteros,
cadenas de texto, etc.) por lo que no se pueden guardar de forma directa los objetos de la
aplicación en las tablas, sino que estos se deben de convertir antes en registros, que por lo
general afectan a varias tablas. En el momento de volver a recuperar los datos, hay que
hacer el proceso contrario, se deben convertir los registros en objetos. Es entonces cuando
ORM cobra importancia, ya que se encarga de forma automática de convertir los objetos
en registros y viceversa, simulando así tener una base de datos orientada a objetos (Yanes
Enriquez & Gracia del Busto, 2011)
Ventajas
Facilidad y velocidad de uso
Abstracción de la base de datos usada.
Seguridad de la capa de acceso a datos contra ataques.
Desventajas
En entornos con gran carga poner una capa más en el proceso puede mermar el
rendimiento.
Aprender el nuevo lenguaje del ORM.
28
1.6.1. Patrones de Diseño
1.6.1.1. Patrón Repository
El patrón Repository utiliza un repositorio para separar la lógica que recupera los datos y
los mapea al modelo de entidades, de la lógica del negocio que actúa en el modelo. El
repositorio media entre la capa de fuente de datos y la capa de negocios de la aplicación;
encuesta a la fuente de datos, mapea los datos obtenidos de la fuente de datos a la entidad
de negocio y persisten los cambios de la entidad de negocio a la fuente de datos. (Yanes
Enriquez & Gracia del Busto, 2011)
Los repositorios son puentes entre los datos y las operaciones que se encuentran en
distintos dominios. Un repositorio elabora las consultas correctas a la fuente de datos y
mapea los resultados a las entidades de negocio expuestas externamente. Los repositorios
eliminan las dependencias a tecnologías específicas proveyendo acceso a datos de
cualquier tipo. (Yanes Enriquez & Gracia del Busto, 2011)
Figura 11. Patrón Repository
Fuente: https://msdn.microsoft.com/en-us/library/ff649690.aspx
1.6.1.2. Patrón Active Record
Active Record es un patrón en el cual, el objeto contiene los datos que representan a una
fila (o tupla) de nuestra tabla o vista, además de encapsular la lógica necesaria para acceder
a la base de datos. De esta forma el acceso a datos se presenta de manera uniforme a
29
través de la aplicación (lógica de negocio + acceso a datos en una misma clase). (Yanes
Enriquez & Gracia del Busto, 2011)
Una clase Active Record consiste en el conjunto de propiedades que representa las
columnas de la tabla más los típicos métodos de acceso como las operaciones CRUD
(Create, Read, Update, Delete), búsqueda (Find), validaciones, y métodos de negocio.
(Yanes Enriquez & Gracia del Busto, 2011)
Figura 12. Patrón Active Record
Fuente: https://thedotnetexperience.wordpress.com/2010
/09/14/patron-activerecord/
1.6.1.3. Hibernate
Es una herramienta de Mapeo objeto-relacional (ORM) para la plataforma Java (y disponible
también para .Net con el nombre de Hibernate) que facilita el mapeo de atributos entre una
base de datos relacional tradicional y el modelo de objetos de una aplicación, mediante
archivos declarativos (XML) o anotaciones en los beans de las entidades que permiten
establecer estas relaciones. (Yanes Enriquez & Gracia del Busto, 2011)
Al usar Hibernate para el acceso a datos el desarrollador se asegura de que su aplicación
es agnóstica en cuanto al motor de base de datos a utilizar en producción, pues Hibernate
30
soporta los más habituales en el mercado: MySQL, PostgreSQL, Oracle, MS SQL Server,
etc. Sólo se necesita cambiar una línea en el fichero de configuración para que podamos
utilizar una base de datos distinta. (Yanes Enriquez & Gracia del Busto, 2011)
Figura 13.Hibernate
Fuente: http://www.it610.com/article/2472285.
htm
1.7. Productividad
1.7.1. Introducción
La Productividad en todo sistema de operación de bienes o servicios obedece a la relación
que guardan los resultados obtenidos con los recursos empleados en el logro de los mimos,
este factor es de vital importancia ya que de ser favorable se estará en condiciones de
permanecer en el mercado cada vez más competitivo. Esta premisa ha llevado a las
empresas establecer diversos mecanismos de control con la convicción de elevar su
31
desempeño a través de la mejora de sus indicadores de operación. (García Muela, Álvarez
Bernal, & Ramírez Cárdenas, 2012)
1.7.2. Productividad y Competitividad
1.7.2.1. Competitividad
La competitividad se entiende como la capacidad de una empresa para generar un producto
o servicio de mejor manera que sus competidores. Esta capacidad resulta fundamental en
un mundo de mercados globalizados, en los que el cliente por lo general puede elegir lo
que necesita de entre varias opciones. Así, cada vez más las organizaciones, ya sea un
fabricante, un hotel, una escuela, un banco, un gobierno local o un partido político, compiten
por los clientes, por los estudiantes, por los recursos de apoyo, etc. Esto lleva a que las
compañías busquen mejorar la integración e interrelación de sus diversas actividades.
(Gutiérrez Pulido, 2010)
1.7.2.2. Productividad
La productividad tiene que ver con los resultados que se obtienen en un proceso o un
sistema, por lo que incrementar la productividad es lograr mejores resultados considerando
los recursos empleados para generarlos. En general, la productividad se mide por el
cociente formado por los resultados logrados y los recursos empleados. Los resultados
logrados pueden medirse en unidades producidas, en piezas vendidas o en utilidades,
mientras que los recursos empleados pueden cuantificarse por número de trabajadores,
tiempo total empleado, horas máquina, etc. En otras palabras, la medición de la
productividad resulta de valorar adecuadamente los recursos empleados para producir o
generar ciertos resultados. (Gutiérrez Pulido, 2010)
1.7.3. Tecnología y Productividad
La primera revolución en la información fue el invento de la escritura, la segunda la generó
el libro, la tercera la imprenta y, por último, la cuarta y actual revolución en la información
es resultado de las innovaciones tecnológicas de las últimas seis décadas en el campo de
la electrónica y las comunicaciones, y está modificando muchos aspectos de la vida. La
32
posibilidad de intercambiar información y comunicarse instantáneamente, a escala mundial
y a bajo costo, a través de internet y otros medios satelitales, ha provocado el debilitamiento
de las fronteras y el mutuo contacto de los pueblos del mundo. (Gutiérrez Pulido, 2010).
Hoy en día podemos decir que casi cualquier actividad humana eficiente viene marcada
por una característica común, el uso de algún tipo de tecnología que hace que el proceso
sea más eficiente, más rápido en su entrega o se puedan obtener resultados en mayor
cantidad y precisión. Desde consultar una agenda de teléfonos ubicada en la Red con el
último modelo de Smartphone, poder videochatear con la otra parte del mundo con un
mínimo de infraestructura de comunicaciones e incluso evaluar el crecimiento y engorde
de cerdos ibéricos mediante chips implantados bajo su piel y con sistemas de
radiofrecuencia. Este progreso hace que la sociedad use la tecnología como un medio para
mejorar sus procesos, su calidad de vida u obtener mejores resultados.
(PortalProgramas.com, Gather Estudios, 2011)
1.8. Conclusiones Parciales del Capitulo
La ingeniería de software es una disciplina que nos ayuda a comprender que es el software,
su ciclo de vida desde su concepción hasta su descontinuación y las diferentes formas en
que este ciclo puede manejarse. Además nos permite desarrollar software de calidad en
base a métodos y herramientas.
Las bases de datos son de gran importancia en esta época siendo las más usadas las del
tipo relacional, gran parte del proyecto a realizarse gira entorno a este apartado por lo cual
es de vital importancia conocer los diferentes Sistemas gestores de bases datos que se
encuentran entre los más usados en la actualidad y cuáles son sus prestaciones.
Los patrones de programación nos muestran como ha avanzado el concepto del desarrollo
de junto con las bases de datos y como han cambiado la forma de interpretar el mundo a
33
través de los lenguajes de Programación. De este apartado nacen los diferentes lenguajes
de programación y en este analizamos Java y CSharp.
Lenguajes de Modelado Conceptual nos indican de manera más concreta los métodos y
herramientas que mencionamos en la ingeniería de software y como han mejorado y
disminuido el tiempo de desarrollo de software.
Patrones de Diseño siendo el tema base de este proyecto y una vez explicado el por qué y
para qué a través de los temas previos explicamos la forma de acceso a la base de un
patrón de diseño, la forma de codificación del mismo y cómo cambia la forma de diseño de
Software, sus ventajas y desventajas, además de los diferentes programas o librerías que
nos ayudan en este proceso y a las que se emulará en este proyecto.
Al final pero no menos importante analizamos la importancia de la tecnología en la
productividad de las empresas en todo ámbito que se pueda imaginar por lo tanto el área
de desarrollo de software también debe hacer uso de toda herramienta o método que le
ayude en el desarrollo rápido de software de calidad.
34
CAPÍTULO II.
2. MARCO METODOLÓGIO
2.1. Caracterización del Sector
La empresa Interfases Software Group, fue creada en el mes de Septiembre del año 2001,
siendo sus actividades principales el diseño de páginas Web, desarrollo de aplicaciones
multimedia y soporte informático.
Con el paso de los años, la cartera de clientes fue creciendo, igualmente la empresa fue
adecuando sus servicios y enfocándose en un mercado especifico, el desarrollo de
aplicaciones educativas, que se han implementado con éxito en varias instituciones.
El cliente más frecuente es la Universidad regional Autónoma de los Andes UNIANDES, en
donde el software de Gestión Académica y financiera SIGAFI, fue implementado y ha
recibido constantes actualizaciones a lo largo de los años.
El Software SIGAFI funciona en la matriz de UNIANDES y en sus siete extensiones a mas
de las instituciones en las cuales existen convenios como la universidad de Cuenca y la de
Guayaquil.
Actualmente el departamento de desarrollo de software de Interfases funciona dentro de la
estructura física de la UNIANDES en donde presta servicios directos de outsorcing, para la
realización de nuevos módulos y actualizaciones requeridas por las instancias de
Educación Superior.
Con su consolidación como empresa sus clientes no solo necesitan un mayor grado de
atención sino que exigen gran calidad en su software, así como un servicio al cliente
personalizado.
35
2.2. Descripción de Procedimiento Metodológico
2.2.1. Métodos de Investigación
2.2.1.1. Histórico-Lógico
Por medio este método se llegó al conocimiento de las distintas etapas y evolución del
desarrollo de software, cómo este proceso ha ido cambiando de paradigmas y seguirá en
proceso constante de cambio. El método lógico se basa en el estudio histórico poniendo de
manifiesto la lógica interna de desarrollo, de su teoría y nos permite hallar las semejanzas
y diferencias entre los distintos procesos que se han estudiado.
2.2.1.2. Sintético
Es un proceso mediante el cual se relacionan hechos aparentemente aislados y se formula
una teoría que unifica los diversos elementos. Consiste en la reunión racional de varios
elementos dispersos en una nueva totalidad, este se presenta más en el planteamiento de
la hipótesis.
2.2.1.3. Sistémico
Está dirigido a modelar el objeto mediante la determinación de sus componentes, así como
las relaciones entre ellos, que serán analizados y diseñados para llegar al objetivo de la
presente investigación.
2.2.2. Modalidad de la Investigación
Las modalidades que se aplicarán en la presente investigación son:
Bibliográfica o documentada, ya que se ha tomado información de libros electrónicos,
digitales, tesis, blogs, citas entre otros.
36
Aplicada, ya que se orienta a la resolución de problemas. En esta modalidad podemos
encontrar la innovación técnica, artesanal e industrial, entre otras modalidades.
2.2.3. Métodos Técnicas e Instrumentos
La recopilación de antecedentes se realizará a través de documentos gráficos formales e
informales, cualquiera que éstos sean, donde se fundamentará la presente investigación.
Los materiales de consulta serán las fuentes bibliográficas y algunos medios digitales.
La investigación se realizará directamente en el medio donde se presenta el fenómeno de
estudio, para lo cual las herramientas de apoyo para esta investigación serán:
La observación: Uno de los principales medios para realizar una investigación es la
observación, a través de esta podemos distinguir las características del caso, tomar la
información y posteriormente analizarla.
La entrevista: para la recopilación verbal, se utilizará la guía de entrevista.
37
2.2.4. Población y Muestra
Tabla 1. Población
UNIDAD Ámbito Número
Jefe de Desarrollo Jefe de Desarrollo de
Interfases Software Group 1
Programadores Programadores de
Interfases Software Group 2
Elaborado por: Bryan Chingo Fuente: Interfases Software Group.
Debido al número de integrantes de esta población se utilizara la totalidad de la misma y se
aplicaran la entrevista y la observación.
2.2.5. Análisis e Interpretación de Resultados
La entrevista se realizó a 2 personas involucradas en el desarrollo de software de la
empresa Interfases Software Group, la misma consta de 7 preguntas.
A continuación se presenta el resultado de las entrevistas a cada uno de los participantes
en las cuales se abordará los temas involucrados en el proceso de desarrollo y las
complicaciones que presentan en este ciclo.
2.2.5.1. Entrevista al Ingeniero Henry Baño Jefe de Desarrollo de Interfases Software
Group.
La entrevista se realizó de la mejor manera con total apoyo por parte del Ingeniero Henry
Baño a quien se le agradece su tiempo y amabilidad durante todo la entrevista.
38
Pregunta N°1
¿Cuál es el proceso para el desarrollo de aplicaciones en su empresa?
Objetivo: Determinar la metodología de desarrollo de software que se ocupa en el
desarrollo de la Empresa Interfases Software Group.
El principal proceso es una petición que se hace al departamento de desarrollo, esta
petición viene marcada con los parámetros que nos piden los clientes, una vez que se ha
tenido entrevistas con los clientes se intenta recoger la mayor cantidad de información y se
designa a la persona correspondiente para que realice el modulo o proceso que se necesita.
Análisis: Con esta información podemos concluir que la metodología utilizada para el
desarrollo de software de la empresa es la clásica.
Pregunta N°2
¿Qué herramientas usa en el proceso de desarrollo de software de su empresa?
Objetivo: Determinar los IDE, herramientas, lenguajes de programación utilizados en el
desarrollo de software
Nosotros manejamos específicamente lo que es la tecnología Microsoft dentro de lo que
.NET tanto en ambiente Windows como web.
Análisis: En esta pregunta podría parecer una respuesta general sobre el ambiente en el
que se trabaja que sería Microsoft pero al saber que se refiere a la línea de desarrollo
tenemos como IDE Visual Studio el soporta varios Lenguajes de Programación como C# y
Visual Basic además de contar con varias herramientas.
Pregunta N°3
¿Qué tan acertadas son las estimaciones de tiempo y recursos en los desarrollos de su
empresa?
39
Objetivo: Analizar la realidad del desarrollo de software en contraste con el estimado en
un plan de trabajo.
La verdad no son tan acertadas debido a que nuestro departamento es bastante pequeño
y realiza varias acciones al mismo tiempo no nos dedicamos 100% a la parte de desarrollo
sino también se divide el tiempo en lo que es Soporte técnico y algunas otras actividades
que solicita la institución.
Análisis: Esta respuesta nos muestra la realidad de muchas empresas, departamentos de
desarrollo de software en los cuales los ingenieros no realizan una sola función, lo cual
repercute directamente en su productividad en lo que refiere a desarrollo de software.
Pregunta N°4
¿Considera que es medible la productividad de sus desarrolladores?
Objetivo: Pregunta ligada a la anterior busca determinar los puntos mejorables en el
proceso desarrollo de software.
Actualmente no tenemos un proceso de medición, se debería implementar un proceso para
medición, pero actualmente no manejamos un proceso.
Análisis: La falta de una herramienta que permita la planificación, control y cumplimiento
de planes y objetivos de trabajo, sumado a las múltiples funciones de los ingenieros de la
empresa hace imposible medir la productividad de los programadores.
Pregunta N°5
¿A su criterio sería conveniente mejorar la productividad de sus programadores?
Objetivo: Determinar la necesidad de la empresa para mejorar su proceso de desarrollo de
software
Obviamente que sería conveniente
40
Análisis: Una pregunta que raya en lo trillado pero necesaria luego de todas las preguntas
anteriores en las que se llegó a esta conclusión.
Pregunta N°6
¿Conoce los ORM?
Objetivo: Pregunta relacionada directamente al tema de tesis que busca ahondar en los
temas que ayudan a la productividad.
He escuchado de las herramientas case, no sé si viene al caso, existen algunos que vienen
integrados a la plataforma de Microsoft que nos permiten generar a través de las clases
toda la estructura de la Base de Datos.
Análisis: Una respuesta bastante encaminada a lo que es un ORM incluso en una de sus
funciones de generar clases nos muestra de donde se deriva esta herramienta.
Pregunta N°7
¿Considera que la utilización de un ORM, generaría una mayor productividad en sus
desarrolladores?
Objetivo: Justificar el desarrollo del proyecto de investigación.
Si.
Análisis: En las anteriores preguntas hemos analizado los problemas desarrollo de
aplicaciones en esta se justifica la herramienta ORM en la mejora de la productividad de
Interfases Software Group.
41
2.2.5.2. Entrevista al Ingeniero Guillermo Núñez Programador de Interfases Software
Group.
La entrevista se realizó dela mejor manera al igual que la anterior con total apoyo por parte
del Ingeniero Guillermo Núñez a quien se le agradece su tiempo y amabilidad durante toda
la entrevista.
Pregunta N°1
¿Cuál es el proceso para el desarrollo de aplicaciones en su empresa?
Objetivo: Determinar la metodología de desarrollo de software que se ocupa en el
desarrollo de la Empresa Interfases Software Group.
Un estudio pertinente acerca de las necesidades que en este caso la universidad necesita
para la recopilación de la información.
Análisis: La recopilación de la información e identificación de necesidades (requisitos)
forma parte de la fase inicial del desarrollo de software.
Pregunta N°2
¿Qué tan acertadas son las estimaciones de tiempo y recursos en los desarrollos de su
empresa?
Objetivo: Analizar la realidad del desarrollo de software en contraste con el estimado en
un plan de trabajo.
Dependiendo del estudio o dependiendo de la necesidad de la empresa nosotros tratamos
de realizar lo más pronto posible los sistemas para que entren en producción.
Análisis: A pesar de las distintas funciones que cumplen los programadores intentan
cumplir los plazos de desarrollo.
42
Pregunta N°3
¿Considera que es medible la productividad de los desarrolladores?
Objetivo: Pregunta ligada a la anterior busca determinar los puntos mejorables en el
proceso desarrollo de software.
Bueno, ahí varía un poco por el conocimiento de la persona que está desarrollando el
sistema; o del software que vaya a ocupar para realizar el sistema.
Análisis: Aquí el programador nos presenta diferentes condiciones que contribuyen o
afectan al momento de desarrollar software desde su punto de vista.
Pregunta N°4
¿A su criterio sería conveniente mejorar la productividad de sus programadores?
Objetivo: Determinar la necesidad de la empresa para mejorar su proceso de desarrollo de
software
Por supuesto con cursos, actualización de conocimientos o autoeducación para que puedan
conocer más sobre las herramientas y nuevas tecnologías que están llegando para
desarrollar nuevos sistemas
Análisis: El programador vuelve a ofrecer más y acertadas contribuciones para el problema
que pueden enfrentar las empresas o departamentos que se dediquen al desarrollo de
software.
Pregunta N°5
¿Conoce los ORM?
Objetivo: Pregunta relacionada directamente al tema de tesis que busca ahondar en los
temas que ayudan a la productividad.
43
Desconozco sobre ese tema
Análisis: Los ORM son un tema desconocido al tratarse de un derivado de las herramientas
case pero a su vez ampliar ciertos métodos y ayudara a mejorar el desarrollo de sistemas.
Nota:
La última pregunta no se realizó al ser directamente relacionada con la anterior.
2.2.5.3. Resultados de la Observación al proceso de programación.
Tabla 2. Ficha de Observación
Ficha de Observación del proceso de Programación
Actividad Descripción
Programación de Clases Se realiza a partir de las tablas de la bases
de datos yendo una a otra vez de los
campos a los métodos get y set
Programación de la Capa de
Abstracción
Se realiza de igual manera realizando los
métodos de insertar, listar, seleccionar y
eliminar de las mismas tablas.
Elaborado por: Bryan Chingo Fuente: Observación Interfases Software Group
Análisis: Muchos de los procesos de programación por capas se realizan de la misma
forma es decir una capa como la de clase siempre va a tener la misma o parecida estructura,
la capa de abstracción igual. Al final este proceso se vuelve repetitivo y un tanto tedioso.
Propuesta del Investigador
En base a la investigación de campo desarrollada, el investigador considera pertinente
proponer la implementación de una herramienta ORM que permita:
44
Desarrollar una herramienta ORM que permita conectarse a los siguientes Sistemas
Gestores de Bases de Datos: SQL Server, MySql y PostgreSQL debido a que estas son las
de mayor además de SQL Server ser el principal gestor utilizado por la empresa, no
descartando los otros gestores al serlibres y que ya se utilizan en varios proyectos dentro
de la empresa.
La Herramienta deberá tener la funcionalidad de generar Store Procedures en base a las
tablas y campos pertenecientes a la base de Datos Seleccionada lo que facilitara las
funciones de CRUD (Crear, Leer, Actualizar y Borrar).
Adicionalmente podrá generar las clases y la capa de abstracción de la base de Datos
siendo los lenguajes destinatarios java o CSharp, considerando que el primero es uno de
los lenguajes más utilizados en el desarrollo de aplicaciones de código libre y el segundo
es el lenguaje predilecto de Microsoft y el más utilizado en la empresa.
2.2.6. Conclusiones parciales de Capítulo
Las principales herramientas usadas por Interfases software Group son de Microsoft por lo
cual C# es uno de los lenguajes utilizados en el desarrollo de sus aplicaciones, además de
SQL server como Gestor de Bases de Datos por lo cual se necesita una herramienta
enfocada a estas tecnologías.
La productividad de la empresa es un gran problema debido a las distintas funciones de sus
integrantes por lo cual una herramienta que ayude directamente en el proceso de desarrollo
sería de gran ayuda.
Las herramientas ORM en si no son muy conocidas en la empresa pero sus prestaciones
si y su jefe de desarrollo entiende que la implementación de una herramienta de esta clase
mejoraría la productividad de su empresa.
45
CAPÍTULO III.
3. DESARROLLO DE LA PROPUESTA
3.1. Título de la propuesta
Herramienta ORM para mejorar la productividad de la empresa INTERFASES SOFTWARE
GROUP.
3.2. Objetivos
3.2.1. Objetivo General
Desarrollar una herramienta ORM que cumpla los estándares de codificación actuales
mediante el uso de Java y que ayude a mejorar la productividad de la empresa Interfases
Software Group.
3.2.2. Objetivos Específicos
Analizar los requerimientos de la empresa en cuanto al desarrollo de
aplicaciones.
Diseñar los casos de uso y clase necesarios para el desarrollo de la herramienta
ORM.
Determinar el proceso de desarrollo que se va a utilizar en el desarrollo de la
herramienta.
Determinar los módulos necesarios para el desarrollo de la herramienta ORM
para cada una de las tecnologías agrupadas en la misma.
46
3.3. Desarrollo del Sistema
3.3.1. Definición de la metodología de desarrollo de software
Al momento de desarrollar software siempre se busca garantizar la calidad del mismo por
lo cual la metodología seleccionada para su desarrollo debe tomar en cuenta los diferentes
factores involucrados en el desarrollo.
Para el desarrollo de software en este caso se ha seleccionado PSP (Proceso de software
personal) ya que se concentra en las prácticas de trabajo de los ingenieros de forma
individual, se aplica a programas pequeños de menos de 10000 líneas de código.
3.3.2. Proceso de Software Personal
La estructura del proceso de PSP se muestra a partir de una declaración requisitos, el
primer paso en el proceso de PSP es la planificación. Mientras que los ingenieros están
siguiendo el script para hacer el trabajo, registran su tiempo y datos de defectos en los
registros de tiempo y defectos. Al final del trabajo, durante la fase de post-mortem (PM),
que resumen los datos de tiempo y defectos de los registros, medir el tamaño del programa,
y entran estos datos en el formulario de resumen del plan.
47
Figura 14. Flujo de procesos del Modelo PSP
Fuente: http://www.scielo.cl/scielo.php?pid=S071807642014000200007&script=sci
_arttext
3.4. Declaración Requisitos
De acuerdo a los requerimientos de la empresa se han desarrollado los siguientes
diagramas: diagramas de caso de uso, diagramas de secuencia y diagramas de clases, los
mismos que nos ayudaran a desarrollar los distintos módulos del software.
48
3.4.1. Casos de Uso
3.4.1.1. Caso de Uso de Codificación
El caso de uso indica cómo se realiza por lo general el proceso de codificación de la
empresa el cual se da en base a las tablas que se encuentran en el sistema gestor de base
de datos.
Figura 15. Caso de uso de Codificación
Fuente: Imagen Propia
3.4.1.1.1. Diccionario de Datos de Actores
Tabla 3. Diccionario de Actores
N° Actor Descripción
1 Programador
Persona encargada de codificar los store procedure, las clases,
la capa de abstracción y la presentación de datos en los
informes.
2 SGBD Sistema encargado de la gestión de las bases de datos (Pueden
ser MySQL, SQL o PostgreSQL).
Elaborado por: Bryan Chingo Fuente: Caso de uso de Codificación
49
3.4.1.1.2. Descripción de los Procesos
Tabla 4. Descripción de los Procesos
N° Proceso Descripción
1 Conectar El programador se conecta al SGBD
2 Codificar Store
Procedure
En este proceso el programador codifica los SP en base
a las tablas del Sistema Gestor de Bases de Datos.
3 Codificar Capa de
Datos
En este proceso el programador codifica las
transacciones que el programa lleva a cabo con la base
de datos.
4 Codificar Informes En este proceso el programador codifica la presentación
de ciertos datos de interés del usuario.
Elaborado por: Bryan Chingo Fuente: Caso de uso de Codificación
3.4.1.2. Caso de uso Conectar
El caso de uso indica cómo se realiza por lo general el proceso conexión al sistema gestor
de base de datos.
50
Figura 16.Caso de Uso Conexión
Fuente: Imagen Propia
3.4.1.2.1. Diccionario de Datos de Conexión
Tabla 5. Descripción de los Actores
N° Actor Descripción
1 Programador Persona que accede al Sistema Gestor de Bases de Datos
2 SGBD Sistema encargado de la gestión de las bases de datos (Pueden
ser MySQL, SQL o PostgreSQL).
Elaborado por: Bryan Chingo Fuente: Caso de uso Conexión
51
3.4.1.2.2. Descripción de los Procesos
Tabla 6. Descripción de los Procesos
N° Proceso Descripción
1 Acceder al SGBD En este proceso el programador se conectara a al SGBD
previamente ingresan su usuario y clave a través de ORM
2 Verificar Datos El SGBD comprobara el usuario y clave
3 Permitir acceso En caso de que el usuario y contraseña estén correctos
el SGBD nos permitirá el acceso a los datos necesitados
4 Mostrar Resultados En este caso el ORM mostrará las bases de datos
disponibles en el SGBD
5 Conectar Una vez seleccionada la base de datos desea se
conectará a la misma y el ORM pasará a otro formulario
Elaborado por: Bryan Chingo Fuente: Caso de uso Conexión
3.4.2. Diagrama de Clase
El presente diagrama nos muestra cómo se distribuirán los diferentes módulos de la
aplicación, estando los mismos separados por tipo de gestor de Base de Datos, lenguaje
de programación relacionado y unidos por un módulo en común que intentará generalizar
los datos provenientes de cada uno de estos módulos.
Además se recuerda que este no es un diagrama definitivo sino solo un patrón de diseño
que se intentará seguir, debido al enfoque seguido PSP el mismo se puede reconsiderar en
caso de ser necesario o se encuentre una mejor solución que no solo reduzca las líneas de
codificación sino que también ayuden con la optimización del programa. Por lo cual es
posible que la estructura del programa final difiera ligeramente del modelo mostrado a
continuación.
52
Figura 17. Diagrama del ORM Fuente: Imagen Propia
Tabla 7. Descripción del Diagrama de ORM
Paquete/Clase Detalle
FORMS Este paquete contiene los form que serán el interfaz para
el usuario
FrmLogin Esta clase permite la conexión a los diferentes SGDB
1FrmBasico Esta clase permite la realización de SP, clases y
abstracción
PanelOpciones Permite la selección de Campos de una Base de Datos
FrmInforme Permite la realización de informes con itext e itextsharp
SQL/MYSQL/POSTGRESQL Estos paquetes son muy parecidos y contienen las clases
de conexión a cada SGDB.
JAVA/CSHARP Estos paquetes contienen los estándares de codificación
correspondiente a cada lenguaje.
ESTANDARIZACIÓN Este paquete maneja los datos haciéndolos accesibles a
los distintos módulos que los necesiten.
Elaborado por: Bryan Chingo Fuente: Diagrama del ORM
53
3.5. Planeación
Tabla 8. Formulario de Resumen del Plan
Desarrollador: Bryan Chingo Fecha: 05-08-2016
Programa: ORM Programa #: 1
Instructor: Ing. Freddy Baño Lenguaje Java
Resumen/LOC Plan Real Hasta la Fecha
1140 1374 100
Programa(LOC) Plan Real Hasta la Fecha
Minutos/LOC 2 3 -
LOC/Hora 30 20 -
Tiempo Fase (min). Plan Real Hasta la Fecha Hasta la Fecha %
Planeación 200 100 - 100%
Diseño 400 500 - 100%
Codificación 1500 2305 - 100%
Revisión 360 230 - 100%
Compilación 200 123 - 100%
Pruebas 360 835 - 100%
Total 2280 4123 - 100%
Tiempo Máximo 3000 - - 100%
Tiempo Mínimo 2200 - - 100%
Defectos Introducidos Real Hasta la Fecha Hasta la Fecha %
Planeación 100 - 100%
Diseño 200 - 100%
Codificación 1420 - 100%
Revisión 230 - 100%
Compilación 123 - 100%
Pruebas 835 - 100%
Total 2908 - 100%
Defectos Eliminados Real Hasta la Fecha Hasta la Fecha %
Planeación 0 - 100%
Diseño 150 - 100%
Codificación 600 - 100%
Revisión 150 - 100%
Compilación 0 - 100%
Pruebas 315 - 100%
Total 1215 - 100%
Elaborado por: Bryan Chingo Fuente: The Personal Software ProcessSM (PSPSM)
54
3.6. Diseño
3.6.1. Formulario Login
Figura 18. Formulario Login
Fuente: Imagen Propia
En el formulario de login podemos encontrar el JComboBox que contiene los Sistemas
Gestores de Bases de datos compatibles con el ORM, un JTextField en el cual se ingresa
la dirección del SGBD, dos JTextField para usuario y contraseña, un JButton para el acceso
al SGBD que nos devuelve la Bases de Datos disponibles al segundo JComboBox y por
ultimo un JButton con el cual se realiza la conexión a la Base de Datos específica y nos
muestra el siguiente formulario.
55
3.6.2. Formulario Básico
Figura 19. Diseño Formulario Básico
Fuente: Imagen Propia
Este formulario contiene un JTextField que nos permite ingresar el directorio donde se va a
guardar los Store Procedure y las clases de las distintas opciones elegidas a través del
JButton Directorio o bien sea del Guardar, el JButton Ejecutar nos permitirá crear los Store
Procedure en los distintos SGBD.
A continuación se encuentra un JComboBox donde se presentan la diferentes tablas que
se encuentran en la Base de Datos seleccionada al final tenemos dos JButton que nos
permiten crear un Store Procedure o un segmento de código personalizado por medio del
JTable de la parte inferior en la cual podemos seleccionar los campos que se van a usar, el
nombre de estos Segmentos lo podremos en el JTextField que se encuentra antes de estos
componentes y bajo el mismo dos JRadioButton donde seleccionar el lenguaje de
programación en que se generarán todos los códigos que precisemos.
Antes de la JTable se hallan agrupadas la mayoría de las acciones básicas y principales
del ORM a través de 4 JButton, el primero “Store P.” nos permite generar los Store
56
Procedure para insertar, actualizar, listar, seleccionar y eliminar una tabla de la Base de
Datos, luego se encuentra el botón “Clases” que nos generan la tabla como un objeto con
sus atributos y respectivos métodos get y set, el botón “Datos” nos crea la capa de
abstracción de Datos en base a los Store Procedure o directamente a través de consultas
directas en clase a su la tenemos un JCheckBox que nos permitirá elegir como se realizará
esta abstracción, al final de este grupo termina con el botón “Informe” que nos presentará
el Panel Opciones. Por ultimo tenemos un JTextArea que presentara todo el código o Store
Procedure generados.
3.6.3. Panel Opciones
Figura 20. Panel Opciones
Fuente: Imagen Propia
El Panel Opciones se muestra a través de un mensaje con opción de Aceptar contiene un
JTree que muestra las tablas con sus respectivos campos y dos Jbutton con los cuales
podemos seleccionar los campos a sus respectivos JList que representan al select y where
de una consulta compleja
57
3.6.4. Formulario Informe
Figura 21. Formulario Informe Fuente: Imagen Propia
El presente diseño no representa la forma final del formulario, contiene dos tablas donde se
presentan las relaciones y campos seleccionados en el panel opciones, 2 botones para
agregar campos calculados dos opciones en forma de jcheckbox para las relaciones, dos
botones donde se generan los sp o código de itext/itextsharp y el JTextArea que presenta
este código.
58
3.7. Codificación
Tabla 9. Ficha de estándar de codificación
Estándar de Codificación
Función Estándares Fecha
Versión 1 Autor Bryan Chingo
Descripción: Esta Ficha es una guía general de cómo se va a codificar el ORM.
public class Ejemplo {
//Función que devuelve la existe de un carácter en una palabra
public boolean EncontrarZeta(String palabra) {
String Caracter;
boolean respuesta=false;
for(int i; i<palabra.length(); i++){
Caracter=palabra.substring(i);
if(Caracter.equals(“z”) {
respuesta=true;
}
}
return respuesta;
}
}
Notas: Clases: El nombre de las clases hace referencia a la actividad o Lenguaje.
Funciones: El nombre de la función hace referencia a su actividad o valor de retorno.
El inicio de la función se realiza en la misma línea, Se deben considerar formatos de salida y
entrada de las funciones.
Variables: El nombre de las variables debe ser referente al dato que representa.
* Se permite la i como contador estandarizado de los bucles.
Espacios en blancos: Escribir los programas con los suficientes espacios en blanco para facilitar
la lectura, Se debe sangrar los bucles y los condicionadores.
Comentarios: Los comentarios beben ir en la línea anterior a la codificación a la que pertenecen,
Se permiten comentarios en la línea en casos específicos.
Elaborado por: Bryan Chingo Fuente: The Personal Software ProcessSM (PSPSM)
59
Tabla 10. Ficha de codificación de conexión
Codificación de Conexión
Función Conexión Fecha
Versión 1 Autor Bryan Chingo
Descripción: Esta Ficha representa la codificación de la clase de conexión a los diferentes SGBD.
public class conexion {
public Connection Conexion (String driver,String servidor,String usuario,String clave) {
Connection conexion =null;
try{
Class.forName(driver);
conexion=(Connection) DriverManager.getConnection(servidor,usuario,clave);
} catch (SQLDataException ex){
JOptionPane.showMessageDialog(null, ex.getMessage());
}
catch (Exception ex){
JOptionPane.showMessageDialog(null, ex.getMessage());
}
finally{
return conexion;
}
}
public ResultSet bases(Connection cn,String sentencia){
ResultSet rs=null;
try{
Statement s = cn.createStatement();
rs = s.executeQuery(sentencia);
} catch (Exception ex){
JOptionPane.showMessageDialog(null,ex.getMessage() );
}
finally{
return rs;
}
}
}
Notas: El parámetro driver recibe la clase de conexión a los diferentes SGBD.
Elaborado por: Bryan Chingo Fuente: The Personal Software ProcessSM (PSPSM)
60
Tabla 11. Ficha de estandarización
Función de Estandarización
Función Estandarización Fecha
Versión 1 Autor
Descripción: Parte de la función de estandarización (MYSQL)
try {
ms.setconexion(Dconexion.getServidor(), Dconexion.getUsuario(), Dconexion.getPass());
rs=ms.campos(tabla);
if (rs.last()) {
vCampo=new String[rs.getRow()];
vTipo=new String[rs.getRow()];
rs.beforeFirst();
}
while (rs.next()) {
if(rs.getString(4).equals("PRI")){
CamposDB.setPrimaria(rs.getString(1));
vSplit=rs.getString(2).split("\\(");
CamposDB.setTipo(tipo(vSplit[0]));
if(rs.getString(6).equals("auto_increment")) CamposDB.setAuto(true);
}else{
vCampo[i]=rs.getString(1);
vSplit=rs.getString(2).split("\\(");
vTipo[i]=tipo(vSplit[0]);
i=i+1;
}
}
}catch (Exception ex) {
Logger.getLogger(TipoDatos.class.getName()).log(Level.SEVERE, null, ex);
}
Notas: Por motivos de espacio se han omitido la estandarización de sql y postgresql al ser muy
parecidos, además de la declaración de variables.
Elaborado por: Bryan Chingo Fuente: The Personal Software ProcessSM (PSPSM)
61
3.8. Revisión de Código
Tabla 12. Ficha de Revisión de Código
Encargado: Versión: Lenguaje: Java
Descripción: Anotar el tipo de defectos que se ha encontrado en la casilla (#). Si no hay
ninguno se coloca (0), (-) No aplica.
Propósito Guía de código de errores #10
#20
#30
#40
#50
#60
#70
#80
#90
#C
Total %
Completo Verifica que todas las funciones del diseño están programadas
0 0 - 0 - - 0 0 - - 0 100
Import Verifica los import de librerías 0 0 0 0 - 0 - 0 0 0 0 100
Inicialización Comprueba la inicialización de parámetros y variables
- 0 0 0 - - - 0 - - 0 100
Llamadas Comprobar los formatos de las llamadas a los procedimientos
- 0 - 0 - 0 0 0 0 - 0 100
Nombres Comprobar la ortografía de los nombres y si su utilización es consistente?
- 0 - 0 - - 0 0 0 - 0 100
Formato de Salida
Es adecuada la presentación del valor de salida
- 4 0 0 0 0 0 0 0 - 4 100
Operadores lógicos
Verificar la utilización correcta de todos los operadores lógicos
- 0 0 - - 0 0 3 0 - 3 100
Estándares Asegurarse que la programación se adapta a los estándares
0 0 0 0 1 - - - - - 1 100
Elaborado por: Bryan Chingo Fuente: The Personal Software ProcessSM (PSPSM)
Como se puede observar debido a la inexperiencia del investigador en cuanto a la revisión
de código muchos errores de estándar que se podrían haber detectado en la misma fueron
obviados hasta que se llegó a la fase de pruebas.
Nota: La tabla con los códigos de errores se encuentra en el anexo 03 al ser utilizada en
varias fichas.
62
3.9. Compilación
Los errores de compilación de haberse producido se encuentran en el apartado de análisis
de errores.
3.10. Pruebas
Tabla 13.Ficha de Prueba 1
Prueba N°: 1
Objetivo: Comprobar la conexión a los diferentes SGBD
Descripción: Se realizan las diferentes conexiones a los SGBD con
los usuarios administradores
Mysql
Usuario: root Calve: xxxxx
Sql Server
Usuario: sa Clave: xxxxx
PostgreSql
Usuario: postgres Clave: xxxxx
Resultado Esperado: Conexiones exitosas a los SGBD
Resultado Obtenido: La conexión a PostgreSql no se realiza
Elaborado por: Bryan Chingo Fuente: The Personal Software ProcessSM (PSPSM)
Tabla 14.Ficha de Prueba 2
Prueba N°: 2
Objetivo: Comprobar el listado de campos de la base de datos.
Descripción: Se seleccionó una base de datos de prueba creada en
cada SGDB y se comprobó que liste las tablas en el
combobox y los campos en la jtable.
Resultado Esperado: Mostrar los campos de las bases de datos
Resultado Obtenido: La prueba finalizó con éxito.
Elaborado por: Bryan Chingo Fuente: The Personal Software ProcessSM (PSPSM)
63
Tabla 15.Ficha de Prueba 10
Prueba N°: 10
Objetivo: Comprobar los Datos de Salida de C#
Descripción: Comprobar el estándar de codificación de C #.
Resultado Esperado: La codificación de salida de C# cumpla con las reglas
establecidas.
Resultado Obtenido: Falla en el formato de salida de los métodos Get y Set
de los diferentes tipos de datos.
Elaborado por: Bryan Chingo Fuente: The Personal Software ProcessSM (PSPSM)
Tabla 16.Ficha de Prueba 15
Prueba N°: 15
Objetivo: Comprobar el listado de relaciones entre campos que
conforman el informe en PostgreSql.
Descripción: Se realiza una consulta de la relación existente entre
los campos seleccionados por medio de su respectiva
tabla.
Resultado Esperado: Mostrar las relaciones de las distintas tablas.
Resultado Obtenido: No se obtiene el nombre de la relación solo el código
de objeto
Elaborado por: Bryan Chingo Fuente: The Personal Software ProcessSM (PSPSM)
Al ser el proceso de pruebas uno de los que más se documenta debido a los numerosos
ensayos que este particular caso se realizaron las demás fichas pertenecientes a este
apartado se incluirán de los anexos 03 al 10.
64
3.11. Análisis de Errores
Tabla 17. Análisis de Errores
Análisis de Errores
Tipo Introducido Eliminado Omitido
Diseñar Codificar Otros Revisión Compilar Pruebas En
Revisión
10 - - - - - - -
20 - 1 - 4 - 1 -
30 - - - - - - -
40 - 1 - - - 1 -
50 1 - - 1 - - -
60 - - - - - - -
70 - 1 - - - 1 -
80 - 2 - 3 - 1 -
90 - 1 - - - 1 -
100 - - - - - - -
Total 1 6 0 8 0 5 0
Elaborado por: Bryan Chingo Fuente: The Personal Software ProcessSM (PSPSM)
Esta ficha presenta de manera general los errores introducidos al momento de diseñar,
codificar o cualquier otro defecto que se pueda generar al momento de desarrollar el
sistema, además también presenta el número de estos defectos que se eliminó y en fase
del desarrollo se lo corrigió pudiendo ser en las fases de revisión, compilación o de pruebas.
Esta ficha hace uso de la tabla que se encuentra en el anexo 03.
65
3.12. Cuaderno de Registro de Defectos
Tabla 18. Cuaderno de Registro de Defectos
Encargado
Programa: ORM
Fecha Número Tipo Introducido Eliminado Tiempo de
Corrección
Defecto
Corregido
10-03-2016 1 50 Diseño Revisión 30
Descripción: Cambio de Interfaz del formulario básico haciendo más intuitiva la
misma.
15-03-2016 1 80 Codificación Revisión 40
Descripción: Se realizaba la misma función dos veces en cada clase (Java/CSharp)
por lo cual se la generalizó en la clase Estandarización.
20-01-2016 1 30 Codificación Pruebas 15
Descripción: No se referenció el conector de PostgreSql en su lugar se referenció el
de conector de Mysql.
17-03-2016 10 20 Codificación Pruebas 30
Descripción: Los métodos get y set se generaban con letra minúscula (getint/setint)
teniendo los mismos que ser con mayúscula (getInt/setInt).
13-04-2016 12 80 Codificación Pruebas 90
Descripción: Las consultas de metadatos a los SGBD no devolvían las relaciones
entre las tablas.
16-06-2016 13 100 Codificación Pruebas 30
Descripción:
Error en la configuración de variables de entorno de PostgreSQL.
20-07-2016 14 20 Codificación Pruebas 150
Descripción: Errores de Estándares de Codificación de CSharp
20-07-2016 15 100 Codificación Pruebas 150
Descripción: La consulta solo devuelve el id de la relación
Elaborado por: Bryan Chingo Fuente: The Personal Software ProcessSM (PSPSM)
66
3.13. Registro de tiempos
Tab
la 1
9.
Cu
ad
ern
o d
e r
egis
tro
de t
iem
pos
67
68
Ela
bo
rad
o p
or:
Bry
an C
hin
go
Fue
nte
: T
he
Pers
onal S
oft
wa
re P
rocessS
M (
PS
PS
M)
69
3.14. Gráficos Comparativos
Figura 22. Comparativa Plan-Real Fuente: Imagen Propia
Los presentes gráficos nos dan constancia de los aspectos que el investigador tiene que
mejorar como podemos ver el apartado más alejado de las expectativas y el que más se
tuvo que corregir fue el de codificación, mientras que en la revisión no se puso énfasis por
lo cual muchos errores se detectaron al momento de Realizar las pruebas.
Figura 23. Comparativa Defectos Fuente: Imagen Propia
70
CONCLUSIONES
El marco teórico constituye un análisis del cambio de paradigmas de desarrollo de software
a lo largo del tiempo y como este ha evolucionado a diferentes patrones siendo el más
utilizado el orientado a objetos distribuido capas en software y las bases de datos
relacionales en SGDB mientras que en ingeniería de software el modelo en cascada sigue
siendo muy utilizado pero también han aparecido metodologías denominadas agiles.
La empresa Interfases Software Group es un claro reflejo del problema de las pequeñas
empresas en las cuales sus trabajadores cumplen distintas funciones y en las que la
utilización de software puede afectar la productividad de estas empresas mejorándolo no
solo en tiempo sino en calidad.
El Proceso de Software Personal (PSP) es una gran disciplina que nos ayuda en el
mejoramiento de hábitos de programación además de permitirnos conocer la realidad sobre
el tiempo de desarrollo y nos permite ver los errores más comunes que se comenten como
programador para poder mejorar esos aspectos.
Las herramientas ORM no son muy conocidas por los programadores nuevos, mientras que
los más experimentados conocen sus funcionalidades como parte de las herramientas
CASE esto hace que su campo sea una gran novedad y de gran ayuda en el desarrollo de
software.
Una herramienta ORM ayuda en el desarrollo de software al permitirnos generar código
para el encapsulamiento y capa de abstracción bajo estándares preestablecidos siendo un
aliciente para esta herramienta la generación de Store Procedures e Informes con
itext/itextsharp que permiten al desarrollador realizar los informes más sencillos sin la
necesidad de grandes librerías.
71
RECOMENDACIONES
Se recomienda tomar en consideración PSP como parte de la disciplina de Ingeniería de
Software ya que es una metodología que sera de gran ayuda en el desarrollo de programas
a pequeña escala y de manera personal.
El uso de herramientas CASE sería muy bueno llegado a cierto grado de conocimiento por
lo cual se debería tener en cuenta para su aplicación en los niveles superiores de ingeniería
para que los estudiantes sepan que es lo que realiza esta herramienta en caso de necesitar
corregir algún método.
Se recomienda fomentar el estudio de las nuevas tecnologías en el ámbito de desarrollo
ya que muchas veces los ingenieros en sistemas se quedan con los estándares aprendidos
durante su periodo académico olvidándose que los mismos van evolucionado y por lo tanto
las herramientas cambian o nuevas aparecen enfocadas a estos nuevos paradigmas.
La herramienta ORM realizada en este proyecto se trató de realizar de la manera más
modular posible haciendo que la misma se pueda escalar a más lenguajes sin necesidad
de grandes cambios en la misma por lo cual se puede ampliar a mas lenguajes de manera
sencilla.
Bibliografía
Aramburu Cabo, M. J., & Sanz Blasco, I. (2013). Bases de Datos Avanzadas. Castellón de la
Plana: Universitat Jauime I.
Camps Paré, R., Casillas Santillán, L. A., Costal Costa, D., Ginestà, M. G., Martín Escofet,
C., & Pérez Mora, Ó. (2007). Bases de Datos. Barcelona: Eureca Media. Obtenido de
http://ocw.uoc.edu/computer-science-technology-and-multimedia/bases-de-
datos/bases-de-datos/P06_M2109_02151.pdf
García Muela, M. L., Álvarez Bernal, C., & Ramírez Cárdenas, E. (2012). Productividad y
Desarrollo: Gestión y aplicación del conocimiento en la mejora del desempeño de
operación. México: ITSON.
Gutiérrez Pulido, H. (2010). Calidad Total y Productividad. México D.F.: McGraw-Hill.
IEEE. (1990). IEEE Standard Glossary of Software Engineering Terminology.
INTECO. (2009). Curso de Introducción a la Ingeniería de Software. España: Creative
Commons.
Landa Cosio, N. A. (2010). C#. Buenos Aires: Fox Andina.
Lopez Moltalbán, I., & De Castro Vázquez, M. (2014). Gestión de Bases de Datos. Madrid:
Ibergarceta.
Martínez, J. (2011). Fundamentos de Programación en Java. Madrid: EME.
PortalProgramas.com, Gather Estudios. (2011). Valoración del Software Libre en la sociedad
2011. Obtenido de www.portalprogramas.com/software-libre/informe/2011
Pressman, R. S. (2010). Ingeniería de Software. Un Enfoque Práctico. New York: McGraw-
Hill.
Rodríguez Echeverría, R., Sosa Sánchez, E., & Prieto Ramos, Á. (2011). Programación
Orientada a Objetos. Obtenido de https://openlibra.com/es/book/programacion-
orientada-a-objetos-2
Sánchez Asenjo, J. (2009). Sistemas Gestores de Bases de Datos. Creative Commons.
Silberschatz, A., & Henry F., K. (2002). Fundamentos de Bases de Datos. Madrid: S.A.
McGraw-Hill / Interamericana de España.
Voß, J. (2013). Describing Data Patterns-A general deconstruction of metadata standards
(Tesis Doctoral). Universidad de Humboldt: Berlin.
Yanes Enriquez, O., & Gracia del Busto, H. (2011). Mapeo Objeto/Relacional (ORM).
Revista Telem@tica[En línea], 10(7), 7. Obtenido de
http://revistatelematica.cujae.edu.cu/index.php/tele/article/view/23
Anexos
Anexo 01
Ficha de Entrevista
Anexo 02
Diagrama de Secuencia
Anexo 03
Tabla de Códigos de Errores
# Tipo Nombre Tipo Descripción
10 Documentación Comentarios, mensajes, estándar.
20 Sintaxis Ortografía, puntuación, formato de instrucción
30 Construir
Paquetes
Gestión del cambio, librerías o versión
40 Asignación Declaración, nombres duplicados, ámbito, limites
50 Interfaz Llamadas a procedimientos y referencias, E/S
60 Chequeo Mensajes de Error, chequeos inadecuados
70 Datos Estructura, contenido
80 Función Lógica, punteros, bucle, recursión, defectos de función
90 Sistema Configuración, temporización, memoria
100 Entorno Diseño, compilación, pruebas y otros problemas
Anexo 04
Prueba 3
Prueba N°: 3
Objetivo: Comprobar las sentencias SQL para la creación de SP
de MySQL
Descripción: Validar que las sentencias SQL se ejecuten
correctamente en MYSQL
Resultado Esperado: Generación de los Store Procedure
Resultado Obtenido: Los Store Procedure se generan correctamente
Anexo 05
Prueba 4
Prueba N°: 4
Objetivo: Comprobar las sentencias SQL para la creación de SP
de SQL Server
Descripción: Validar que las sentencias SQL se ejecuten
correctamente en SQL Server
Resultado Esperado: Generación de los Store Procedure
Resultado Obtenido: Los Store Procedure se generan correctamente
Anexo 06
Prueba 5
Prueba N°: 5
Objetivo: Comprobar las sentencias SQL para la creación de
funciones de PostgreSQL
Descripción: Validar que las sentencias SQL se ejecuten
correctamente en PostgreSQL
Resultado Esperado: Generación de las Funciones
Resultado Obtenido: Las funciones se generan correctamente
Anexo 07
Prueba 6
Prueba N°: 6
Objetivo: Comprobar la clases de encapsulamiento de Java
Descripción: Ver si la clase de encapsulamiento genera los datos de
la base de datos en el tipo equivalente en Java además
de sus respectivos métodos get y set.
Resultado Esperado: Clase de encapsulamiento lista para usar
Resultado Obtenido: Las clases
Anexo 08
Prueba 7
Prueba N°: 12
Objetivo: Comprobar las Relaciones de Informe
Descripción: Que los SGDB devuelvan las relaciones entre las
tablas seleccionadas.
Resultado Esperado: Relaciones en la Tablas del Formulario Informe.
Resultado Obtenido: Fallan relaciones en todos los SGDB
Anexo 09
Prueba 8
Prueba N°: 13
Objetivo: Generar funciones desde el ORM
Descripción: Se realiza la ejecución de Consultas SQL a través de
CMD hacia PostgreSQL desde Java.
Resultado Esperado: Crear funciones en PostgreSQL
Resultado Obtenido: No se puede generar las Funciones
Anexo 10
Prueba 9
Prueba N°: 14
Objetivo: Comprobar los Datos de Salida de C#
Descripción: Comprobar el estándar de codificación de C #.
Resultado Esperado: La codificación de salida de C# cumpla con las reglas
establecidas.
Resultado Obtenido: Falla en el formato de salida de los métodos Get y Set
de los diferentes tipos de datos.