ÍNDICE DE CONTENIDO

1. GENERALIDADES ............................................................................................1

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

1.2. ANTECEDENTES ................................................................................................2
1.3. PLANTEAMIENTO DEL PROBLEMA .............................................................6
1.3.1. Identificación del problema ...................................................................................6
1.3.2. Formulación del problema ....................................................................................7
1.3.3. Análisis Causa Efecto ...........................................................................................7
1.4. OBJETIVOS Y ACCIONES ...............................................................................7
1.4.1. Objetivo General ....................................................................................................7
1.4.2. Objetivos Específicos y Acciones........................................................................8
1.5. JUSTIFICACIÓN ...............................................................................................11
1.5.1. Justificación Técnica ...........................................................................................11
1.5.2. Justificación Económica......................................................................................11
1.5.3. Justificación Operativa ........................................................................................12
1.6. ALCANCE ..........................................................................................................12
1.6.1. Alcance Temático ................................................................................................12
1.6.2. Alcance Institucional ............................................................................................12
1.6.3. Alcance Temporal ................................................................................................12
1.7. HIPÓTESIS ........................................................................................................13
1.7.1. Análisis de Variables ............................................................................................13
1.7.2. Definición Conceptual ..........................................................................................13
1.7.3. Operativización de Variables ..............................................................................14
1.7.4. MATRIZ DE CONSISTENCIA ...................................................................... 15
2. MARCO TEÓRICO ...............................................................................................16

2.1. TÉCNICAS DE RECOPILACIÓN DE INFORMACIÓN ..................................16

2.1.1. Entrevistas .............................................................................................................16
2.1.2. Cuestionarios.........................................................................................................19
2.1.3. Observación...........................................................................................................20
2.2. METODOLOGÍAS DE DESARROLLO DE SOFTWARE ..............................21
2.2.1. Modelo Incremental ..............................................................................................22

I
2.2.2. Metodología Proceso Unificado de desarrollo de software ............................26
2.2.3. Modelo de desarrollo en V ..................................................................................37
2.3. MODELAMIENTO DE BASE DE DATOS. .......................................................41
2.3.1. Sistemas de Gestión de Bases de Datos ..................................................... 41
2.4. SERVICIOS WEB .................................................................................................49
2.4.1. XML .........................................................................................................................49
2.4.2. Modelo de los servicios web ...............................................................................50
2.4.3. Protocolos de comunicación para Servicios Web............................................53
2.4.4. WSDL .....................................................................................................................57
2.4.5. UDDI .......................................................................................................................59
2.5. TECNOLOGÍAS DE DESARROLLO DE APLICACIONES WEB ................62
2.5.1. Intranet ...................................................................................................................62
2.5.2. Internet ...................................................................................................................64
2.5.3. Extranet ..................................................................................................................65
2.5.4. Lenguajes de programación de aplicaciones web...........................................67
2.5.5. Arquitecturas de desarrollo de software ............................................................71
2.5.6. Frameworks ...........................................................................................................79
2.6. TECNOLOGÍAS MÓVILES DE DESARROLLO .............................................84
2.6.1. Lenguajes de Programación para aplicaciones móviles ................................88
2.7. PRUEBAS DE SOFTWARE ...............................................................................92
2.7.1. Pruebas de integración ........................................................................................92
2.7.2. Pruebas de validación y verificación..................................................................93
2.7.3. Pruebas de regresión ...........................................................................................93
3. MARCO PRÁCTICO ............................................................................................95

3.1. ANALISIS DE LOS PROCESOS DE LA GESTIÓN ACADÉMICA DE

CALIFICACIONES Y DISEÑO DEL MODELO DE NEGOCIO ACTUAL ...95
3.1.1. Modelo de negocio actual....................................................................................95
3.1.2. Modelo de negocio actual en tres niveles .........................................................96
3.1.3. Modelado de negocio actual de actividades.....................................................97
3.2. DISEÑO DEL MODELO DE NEGOCIO ALTERNATIVO .............................
CONSIDERANDO LA NECESIDAD DE UNA PLATAFORMA WEB Y
MÓVIL ....................................................................................................................98
3.2.1. Falencias existentes en el proceso actual de gestión de calificaciones ......98

II
3.2.2. Modelo de Negocio Alternativo ...........................................................................98
3.2.3. Modelado de negocio alternativo en tres niveles .............................................98
3.2.4. Selección del modelo de desarrollo de software ...........................................101
3.2.5. Planificación de incrementos ............................................................................103
3.3. DISEÑO E IMPLEMENTACIÓN DE LOS MÓDULOS DE GESTIÓN DE
ESTUDIANTES, DOCENTES, MATERIAS, ESPECIALIDADES,
CURSOS Y USUARIOS ADMINISTRATIVOS ..............................................104
3.3.1. Selección Gestor de Base de datos.................................................................104
3.3.2. Selección de lenguaje de programación WEB ...............................................107
3.3.3. Selección del framework....................................................................................109
3.3.4. Análisis del primer incremento..........................................................................113
3.3.5. Diseño...................................................................................................................114
3.3.6. Codificación .........................................................................................................134
3.3.7. Pruebas ................................................................................................................147
3.4. DESARROLLO DE UNA APLICACIÓN MOVIL PARA LA GESTION DE
CALIFICACIONES ..........................................................................................................151
3.4.1. Identificación y selección de herramientas de desarrollo para la
construcción de la aplicación android. .........................................................................151
3.4.2. Definición de actividades y servicios para la aplicación Android ................151
3.4.3. Selección del lenguaje de desarrollo para la construcción de la aplicación
android. .............................................................................................................................156
3.4.4. Análisis del segundo incremento......................................................................158
3.4.5. Diseño...................................................................................................................159
3.4.6. Codificación .........................................................................................................170
3.4.7. Pruebas ................................................................................................................179
3.5. GENERACIÓN DE REPORTES DE ACUERDO A LAS NECESIDADES DEL
CASO DE ESTUDIO .......................................................................................................181
3.5.1. Análisis del tercer incremento ...........................................................................181
3.5.2. Determinación de campos necesarios para cada tipo de reporte que se
quiera para el caso de estudio ......................................................................................184
3.5.3. Elaboración del módulo de generación de reportes ......................................184
3.6. REALIZACIÓN DE PRUEBAS PARA EL SISTEMA ...................................186
3.6.1. Pruebas de conectividad ...................................................................................186
3.6.2. Pruebas de integración ......................................................................................187

III
3.7. DEMOSTRACIÓN DE LA HIPÓTESIS ...........................................................194
3.7.1. Demostración de la primera variable dependiente ........................................194
3.7.2. Demostración de la segunda variable dependiente ......................................197
3.7.3. Demostración de la variable independiente ...................................................200
3.7.4. Definición de la hipótesis ...................................................................................202
3.7.5. Calculo estadístico T ..........................................................................................203
4. ANÁLISIS DE VIABILIDAD ..............................................................................206

4.1. VIABILIDAD TÉCNICA .....................................................................................206

4.2. VIABILIDAD ECONÓMICA ..............................................................................211
4.2.1. Análisis beneficio-costo .............................................................................. 223
4.3. VIABILIDAD OPERATIVA ................................................................................225

5. CONCLUSIONES Y RECOMENDACIONES .................................................228

5.1. CONCLUSIONES ...............................................................................................228

5.2. RECOMENDACIONES......................................................................................229

BIBLIOGRAFÍA ...............................................................................................................231

IV
 ÍNDICE DE TABLAS
Tabla 1: Objetivos específicos y acciones .............................................................. 8

Tabla 2: Operativizacion de variables. .................................................................. 14

Tabla 3: Matriz de consistencia. ........................................................................... 15

Tabla 4: Clasificación UDDI según el tipo de obtención de información ............... 60

Tabla 5: Selección del modelo de desarrollo de software ................................... 101

Tabla 6: Selección de Gestor de Base de datos. ................................................ 104

Tabla 7: Selección de lenguaje de programación WEB ...................................... 107

Tabla 8: Selección del framework. ...................................................................... 109

Tabla 9: Diccionario de datos de la base de datos. ............................................ 118

Tabla 10: Descripción caso de uso Administrar Cargos ..................................... 124

Tabla 11: Descripción caso de uso Administrar Estudiantes. ............................. 125

Tabla 12: Descripción de caso de uso administrar docentes .............................. 126

Tabla 13: Descripción de caso de uso administrar administrativos. ................... 127

Tabla 14: Descripción de caso de uso administrar materias .............................. 128

Tabla 15: Descripción caso de uso administrar cursos ....................................... 129

Tabla 16: Descripción caso de uso Administrar Cursos ..................................... 130

Tabla 17: Pruebas de requerimientos al sistema ................................................ 148

Tabla 18: Selección de servicios web ................................................................. 152

Tabla 19: Selección del lenguaje de desarrollo para la aplicación móvil ............ 156

Tabla 20: Descripción caso de uso registrar notas ............................................. 165

Tabla 21: Descripción caso de uso gestionar notas ........................................... 166

Tabla 22: Descripción caso de uso administrar notas en la aplicación web ....... 167

V
Tabla 23: Prueba: Desarrollo de una aplicación móvil para la gestión de
calificaciones ....................................................................................................... 180

Tabla 24: Descripción caso de uso generar reportes. ........................................ 183

Tabla 25: Descripción de caso de uso ................................................................ 184

Tabla 26: Pruebas de conectividad..................................................................... 186

Tabla 27: Prueba de integración caso de uso administrar cargos ...................... 188

Tabla 28: Prueba de integración caso de uso administrar estudiantes. .............. 188

Tabla 29: Prueba de integración caso de uso administrar docentes. ................. 189

Tabla 30: Prueba de integración caso de uso administrar administrativos. ........ 190

Tabla 31: Prueba de integración caso de uso administrar materias. .................. 190

Tabla 32: Prueba de integración caso de uso administrar especialidades. ........ 191

Tabla 33: Prueba de integración caso de uso administrar cursos. ..................... 192

Tabla 34: Prueba de integración caso de uso administrar notas. ....................... 193

Tabla 35: Prueba de integración caso de uso obtener reportes. ........................ 193

Tabla 36: Pasos para los procesos de entrega de reportes ............................... 195

Tabla 37: Cuadro de valores para la matriz de riesgos. ..................................... 198

Tabla 38: Matriz de riesgos................................................................................. 199

Tabla 39: Tabla comparativa de beneficios del sistema propuesto .................... 200

Tabla 40: Requisitos de hardware para el funcionamiento del servidor

del sistema .......................................................................................... 206

Tabla 41: Requisitos de hardware para el cliente PC. ........................................ 207

Tabla 42: Requisitos de hardware de la aplicación móvil. .................................. 208

Tabla 43: Requisitos de elementos software para el servidor............................. 209

Tabla 44: Requisitos de software para el cliente PC. ......................................... 210

Tabla 45: Requisitos de software de la aplicación móvil ..................................... 210

VI
Tabla 46: Costos de hardware y software del servidor ....................................... 211

Tabla 47: Costos de hardware y software del cliente PC ................................... 212

Tabla 48: Costos de hardware y software para la aplicación móvil ................... 213

Tabla 49: Valores constantes por nodo de desarrollo ......................................... 214

Tabla 50: Ecuación básica del esfuerzo en COCOMO ....................................... 215

Tabla 51: Ecuación básica del tiempo en COCOMO .......................................... 215

Tabla 52: Factores de costo en COCOMO ......................................................... 216

Tabla 53: Gastos estimados en el desarrollo del proyecto para la institución. ... 221

Tabla 54: Gastos estimados para el desarrollo del proyecto. ............................. 222

Tabla 55: Tabla de costo con y sin sistema ........................................................ 223

VII
 ÍNDICE DE FIGURAS
Figura 1: Modelo Incremental ............................................................................... 23

Figura 2: Representación de Diagramas de casos de uso ................................... 30

Figura 3: Representación de un Actor .................................................................. 31

Figura 4: Diagrama de comunicación ................................................................... 32

Figura 5: Diagrama de actividades ....................................................................... 33

Figura 6: Diagrama de actividades ....................................................................... 34

Figura 7: Instancia de un nodo ............................................................................. 34

Figura 8: Estereotipo de un nodo ......................................................................... 35

Figura 9: Artefacto ................................................................................................ 35

Figura 10: Asociación de nodos ........................................................................... 36

Figura 11: Contenedor de nodos .......................................................................... 36

Figura 12: Diagrama de clases............................................................................. 37

Figura 13: El modelo en V .................................................................................... 40

Figura 14: Esquema de un DBMS ........................................................................ 42

Figura 15: Componentes de un sistema PostgreSQL .......................................... 44

Figura 16: Roles, Operaciones y Artefactos de los Servicios Web....................... 51

Figura 17: Pila de Servicios Web ......................................................................... 52

Figura 18: Estructura de un mensaje SOAP......................................................... 54

Figura 19: Arquitectura XML-RPC ........................................................................ 56

Figura 20: Esquema de un WSDL ........................................................................ 59

Figura 21: Cliente-Servidor................................................................................... 74

Figura 22: Arquitectura de 3 niveles ..................................................................... 76

Figura 23: Esquema MVC .................................................................................... 79

VIII
Figura 24: Estructura Móvil Android ..................................................................... 85

Figura 25: Modelo de negocio actual en tres niveles ........................................... 96

Figura 26: Modelado de negocio actual de actividades ........................................ 97

Figura 27: Modelo de negocio alternativo en tres niveles .................................... 99

Figura 28: Modelado de negocio alternativo ...................................................... 100

Figura 29: Diagrama de clases........................................................................... 116

Figura 30: Diagrama de base de datos del sistema ........................................... 117

Figura 31: Diagrama de despliegue ................................................................... 121

Figura 32: Diagrama de casos de uso del primer incremento. ........................... 123

Figura 33: Caso de uso administrar cargos. ....................................................... 123

Figura 34: Caso de uso Administrar Estudiantes ............................................... 124

Figura 35: Caso de uso administrar Docentes ................................................... 125

Figura 36: Caso de uso administrar administrativos ........................................... 126

Figura 37: Caso de uso administrar materias. .................................................... 127

Figura 38: Caso de uso administrar especialidades. .......................................... 128

Figura 39: Caso de uso Administrar Cursos ....................................................... 129

Figura 40: Diagrama de comunicación Administrar Cargos ............................... 131

Figura 41: Diagrama de comunicación administrar estudiantes ......................... 131

Figura 42: Diagrama de comunicación administrar docentes ............................. 132

Figura 43: Diagrama de comunicación administrar administrativos ................... 132

Figura 44: Diagrama de comunicación administrar materias.............................. 133

Figura 45: Diagrama de comunicación administrar especialidades .................... 133

Figura 46: Diagrama de comunicación administrar cursos ................................. 134

Figura 47: Diseño de la arquitectura de la aplicación web. ................................ 135

IX
Figura 48: Interfaz Ingresar al Sistema .............................................................. 136

Figura 49: Interfaz Menú Principal jefe de escuadrón de evaluación. ................ 137

Figura 50: Interfaz registro de cargos. ................................................................ 137

Figura 51: Interfaz listado y registro finalizado del cargo. .................................. 138

Figura 52: Interfaz Registro de estudiante ......................................................... 138

Figura 53: Interfaz listado de estudiantes. .......................................................... 139

Figura 54: Interfaz registro de docentes. ............................................................ 140

Figura 55: Interfaz Formulario de registro de materias. ...................................... 140

Figura 56: Interfaz formulario de registro de materias. ....................................... 141

Figura 57: Interfaz Mostrar Materias .................................................................. 142

Figura 58: Interfaz asignar materias a docente. ................................................. 142

Figura 59: Interfaz Mostrar Asignaciones de materias a docentes. .................... 143

Figura 60: Interfaz Registro de Especialidades. ................................................. 143

Figura 61: Interfaz Mostrar Especialidades ........................................................ 144

Figura 62: Interfaz Registrar Cursos .................................................................. 144

Figura 63: Interfaz Mostrar Cursos ..................................................................... 145

Figura 64: Interfaz Asignar Curso a Estudiante .................................................. 145

Figura 65: Interfaz asignar materias a curso ...................................................... 146

Figura 66: Interfaz Mostrar cursos asignados a estudiantes .............................. 146

Figura 67: Interfaz mostrar asignaciones de materias a curso ........................... 147

Figura 68: Actividades de la aplicación Android ................................................. 152

Figura 69: Diagrama de clases........................................................................... 160

Figura 70: Diagrama de base de datos del sistema ........................................... 161

Figura 71: Diagramas de despliegue .................................................................. 162

X
Figura 72: Diagrama de casos de uso de la aplicación móvil ............................. 164

Figura 73: Caso de uso registrar notas .............................................................. 164

Figura 74: Caso de uso Gestionar Notas. .......................................................... 165

Figura 75: Caso de uso Administrar Notas en la aplicación web........................ 167

Figura 76: Diagrama de comunicación registrar notas. ...................................... 168

Figura 77: Diagrama de comunicación gestionar notas ..................................... 169

Figura 78: Diagrama de comunicación administrar notas en la aplicación web . 169

Figura 79: Diseño de la arquitectura de software de la aplicación móvil. ........... 170

Figura 80: Arquitectura de software segundo incremento de la aplicación web. 171

Figura 81: Icono de la aplicación móvil en el dispositivo .................................... 172

Figura 82: Interfaz ingresar al sistema ............................................................... 173

Figura 83: Interfaz del menú del estudiante ....................................................... 174

Figura 84: Interfaz del personal del escuadrón de evaluación. .......................... 175

Figura 85: Interfaz de registrar notas ................................................................. 176

Figura 86: Interfaz de gestionar notas ................................................................ 177

Figura 87: Interfaz de mostrar notas .................................................................. 178

Figura 88: Interfaz de modificar nota .................................................................. 179

Figura 89: Diagrama de casos de uso del tercer incremento ............................. 183

Figura 90: Codificación de módulo de generación de reporte de notas ............. 185

Figura 91: Reporte de notas por estudiante ....................................................... 185

Figura 92: Reporte de notas por estudiante en PDF .......................................... 186

Figura 93: Prueba de integración por niveles ..................................................... 187

Figura 94: Campana de Gauss. ......................................................................... 205

Figura 95: Cantidad Línea de código aplicación web ......................................... 218

XI
Figura 96: Cantidad líneas de código aplicación móvil ....................................... 218

XII
1. GENERALIDADES
1.1. INTRODUCCIÓN

En la actualidad la información es un recurso de vital importancia en las

instituciones, estas pueden representar recursos como materiales, materias primas,
energía y recursos humanos, todas ellas sujetas a restricciones en su uso y
disponibilidad.

Las instituciones académicas necesitan poder interconectar los procesos, personas

e información tanto con la propia organización como atravesando sus fronteras con
instituciones académicas externas a estas. La falta de integración entre los
componentes de IT (Tecnologías de información), sistemas, aplicaciones y datos
hace difícil obtener una respuesta rápida y efectiva ante los cambios que afectan de
forma natural a los negocios. La inflexibilidad genera costes, reduce la capacidad
de respuesta ante los clientes, compromete el cumplimiento de la normativa legal y
afecta negativamente a la productividad de los empleados. En suma, una deficiente
integración es uno de los problemas más importantes a los que las organizaciones
deben hacer frente para mantener su competitividad y garantizar su crecimiento.
(Microsoft Corporation, 2006)

La telefonía móvil está cambiando la sociedad actual de una forma tan significativa
como lo ha hecho Internet. Esta revolución no ha hecho más que empezar, los
nuevos terminales ofrecen unas capacidades similares a un ordenador personal, lo
que permite que puedan ser utilizados para leer nuestro correo o navegar por
Internet. Pero a diferencia de un ordenador, un teléfono móvil siempre está en el
bolsillo del usuario. Esto permite un nuevo abanico de aplicaciones mucho más
cercanas al usuario. De hecho, muchos autores coinciden en que el nuevo
ordenador personal del siglo veintiuno será un terminal móvil. (Universidad
Politécnica de Valencia, 2012).

En la actualidad la administración de los datos se ha hecho cada vez más compleja,

la información debe estar presente y disponible en todo momento ya que es muy

1
valiosa para tomar decisiones estratégicas para la institución, pero se dificulta la
labor de recolectar esta información debido a que esta se encuentra dispersa en
diferentes sistemas(computacionales y manuales escritos).

En la actualidad el Politécnico Militar de Aeronáutica Sbtte José Max Ardiles

Monrroy no cuenta con ninguna herramienta computarizada que ayude al manejo
de procedimientos administrativos de acuerdo a las necesidades y requerimientos
de las áreas existentes en la institución, algunas de estas áreas son la parte
académica, contable, disciplinaria y comando que se encuentran en distintas
ubicaciones físicas dentro de la institución, esto dificulta y genera retrasos en la
obtención de reportes necesarios para los distintos departamentos de la institución.

1.2. ANTECEDENTES

El Politécnico Militar de Aeronáutica Sbtte José Max Ardiles Monrroy, después de

haber desarrollado sus actividades académicas en la ciudad de La Paz por más de
33 años en 1987 por motivos pedagógicos y dinámica institucional es trasladado a
la ciudad de Cochabamba en la zona de Valle Hermoso.

Hasta el año 1995, el Instituto estaba enmarcado en los lineamientos de formación

profesional de la IAAFA (Académica Interamericana de la Fuerza Aérea),
posteriormente al incorporar a jóvenes bolivianos de ambos sexos para formarse
como técnicos aeronáuticos civiles, se reformularon los Planes y Programas
Académicos, para su certificación ante la D.G.A.C., cumpliendo las disposiciones
del “BAR” (Regulación Aeronáuticas Bolivianas), trámite que permite la Certificación
del Instituto como Centro de Instrucción de Técnicos de Mantenimiento de
Aeronaves, con el Certificado No. 001/98. Por otro lado, el año 2000 el Ministerio de
Educación, previa presentación de documentos e inspección ocular, otorgó la
Resolución Ministerial No.100/00, con la cual los alumnos (as) pueden optar al Título
en Provisión Nacional como Técnico Superior.

2
De acuerdo a normas de la Universidad Militar de las FF.AA. del Estado, al culminar
tres años de estudios, se obtiene el grado militar de Sargento Inicial Técnico y el
título

Académico de Técnico Superior en Ciencias y Artes Militares Aeronáuticas, en una

de las siguientes especialidades:

● Técnico Aeronáutico en Aviónica.

● Técnico Aeronáutico en Motores.
● Técnico Aeronáutico en Naves.
● Técnico en Seguridad Aeronáutica.

Los egresados del Técnico Aeronáutico Militar están formados y capacitados para
realizar trabajos de diagnóstico, reparación y mantenimiento de aeronaves, apoyo
administrativo, y efectuar operaciones de Seguridad a los medios Aeronáuticos de
la Fuerza Aérea de acuerdo a su nivel, especialidad y competencia.

Dentro del POLMILAE, se manejan lo que vienen a ser las calificaciones o notas,
estas notas se ponderan de la siguiente manera:

● Participación en clases 10%

● Promedio de controles 20%
● Examen Parcial 30%
● Examen Final 40%

Los exámenes de las asignaturas que son impartidas en las distintas especialidades
del curso se califican de 0 a 100 puntos y con redondeos decimales de 1 a 5
(inmediato inferior) y 6 a 9(inmediato superior). Es responsabilidad del docente
hacer entrega de sus planillas de notas y de los exámenes escritos, calificados y
revisados previamente por los estudiantes al encargado del escuadrón de
evaluación, una vez realizado la respectiva corrección y revisión de los exámenes,
el docente elabora sus planillas y las entrega al escuadrón de evaluación académica
junto a los exámenes corregidos.

3
El encargado del escuadrón de evaluación se encarga de hacer una planilla general
en Excel de cada curso existente dentro del área académica, luego de llenar dichas
planillas debe realizar un reporte general donde figuran los promedios generales de
cada estudiante para así obtener nombres de los estudiantes más destacados en el
área académica, estos estudiantes destacados tienen opción a una beca completa
para culminar sus estudios técnicos en el exterior del País.

Los exámenes calificados deben ser entregados en el día al comandante del

escuadrón de evaluación para el procesado de notas, se eleva el parte
correspondiente a la autoridad superior, en caso de que se detecte fuga de
información por los docentes se procede a realizar un nuevo examen, para más
detalles de la forma de evaluación ver el Anexo A.

Los estudiantes militares son identificados por su nombre dentro de la institución y

no así con un código único, esto genera problemas al momento de identificar a los
estudiantes militares ya que han existido casos en los cuales los nombres y/o
apellidos estaban mal escritos.

En caso de que el estudiante militar haya obtenido un rendimiento en sus parciales

con una calificación mayor o igual a 90/100 este es eximido del examen final.

El encargado del escuadrón de evaluación es cambiado cada gestión, es decir que

cada año se tiene un nuevo encargado, las planillas realizadas en la gestión del
anterior encargado son impresas y estas entregadas al nuevo encargado, el nuevo
encargado debe usar como referencia estas planillas impresas para la culminación
trimestral de la gestión, ya que esto es de utilidad para poder calcular la antigüedad
de cada estudiante militar.

Estas notas al finalizar el curso son impresas y son de carácter confidencial es por
eso que el estudiante militar para conocer su rendimiento académico debe
aproximarse al departamento de escuadrón de evaluación para solicitar mediante
un formulario la impresión de sus notas.

4
En caso de que el estudiante militar haya reprobado la asignatura tiene derecho a
un examen de segunda instancia, siempre y cuando esté llevando más de 2
asignaturas en el trimestre, las fechas de estos exámenes son dadas a conocer en
el tablero de novedades previa aprobación y revisión de notas hechas por el jefe del
escuadrón de evaluación.

Para los estudiantes militares de 3er año se aplican las siguientes modalidades de
exámenes:

❖ Materias Generales y Aerotécnicas:

Los exámenes según disponga el docente pueden ser orales o escritos, el

tribunal examinador lo conforman técnicos especialistas, 1 Presidente y 2
Vocales.

❖ Sub-Especialidad:

Los exámenes finales para las sub-especialidades, se administran de forma

práctica, ante un Tribunal Examinador conformado por personal especialista
invitado de la Guarnición Aérea de Cochabamba, siendo este tribunal conformado
por tres miembros examinadores (Un Presidente y Dos Vocales).

❖ Taller de Proyecto de Grado

Los Estudiantes militares deben aprobar esta modalidad dando cumplimiento a los
lineamientos establecidos en el procedimiento general para la elaboración,
preparación, presentación y defensa del Proyecto de Grado Técnico, siendo la nota
mínima de aprobación de 60%.

En caso de que el Estudiante Militar repruebe el Taller de Proyecto de Grado, será

considerada como materia reprobada, ingresando así a un examen de segunda
instancia, a la vez tendrá opción de pasar una semana de reforzamiento. La misma
será ponderada en su Evaluación Académica.

5
1.3. PLANTEAMIENTO DEL PROBLEMA

A continuación se mencionan los siguientes puntos que permitirán determinar el

problema de manera clara y precisa.

1.3.1. Identificación del problema

El proceso manual actual de gestión de planillas de notas provoca dificultad en la

rápida obtención de información, perdida de información personal de los estudiantes
y retrasos en la publicación de notas.

1.3.1.1. Identificación de la situación problemática

● El registro Manual de planillas realizadas por el encargado del escuadrón de

evaluación provoca retrasos en la publicación de notas.
● La verificación de planillas por parte del encargado del escuadrón de
evaluación para la impresión de notas del estudiante provoca una pérdida de
tiempo considerable.
● El almacenamiento actual de calificaciones dificulta la rápida obtención del
reporte respectivo.
● Los estudiantes militares no cuentan con la información oportuna de su
historial de calificaciones, provocando incertidumbre por parte de estos hacia
los servicios brindados por el escuadrón de evaluación.

1.3.1.2. Identificación de las causas

● El registro Manual de planillas realizadas por el encargado del escuadrón de

evaluación.
● La verificación de planillas por parte del encargado del escuadrón de
evaluación para la impresión de notas del estudiante.
● El almacenamiento actual de calificaciones.
● Los estudiantes militares no cuentan con la información oportuna de su
historial de calificaciones.

6
1.3.2. Formulación del problema

Los procedimientos manuales actuales en la gestión calificaciones del POLMILAE,

provoca perdida de información personal y de notas de los estudiantes militares,
exceso de tiempo en la generación de reportes solicitados por los distintos
miembros del escuadrón de evaluación.

1.3.3. Análisis Causa Efecto

Causa:

● Los procedimientos manuales actuales en la gestión académica de notas

del POLMILAE.

Efectos:

● Perdida de información personal y de notas de los estudiantes

militares.
● Exceso de tiempo en la generación de reportes solicitados por los
distintos miembros del escuadrón de evaluación.

1.4. OBJETIVOS Y ACCIONES

1.4.1. Objetivo General

Desarrollar una Intranet Corporativa con comunicación Android para el proceso de

gestión de calificaciones, para reducir tiempos de entrega de reportes, evitar perdida
de información de los estudiantes militares. Caso de estudio: Politécnico Militar de
Aeronáutica Sbtte José Max Ardiles Monrroy.

7
1.4.2. Objetivos Específicos y Acciones

● Analizar los procesos de la gestión académica, de calificaciones y Diseñar el

Modelo de negocio actual.
● Diseñar el modelo de negocio alternativo considerando la necesidad de una
plataforma web y móvil.
● Diseñar e implementar los módulos de gestión de Estudiantes, Docentes,
Materias, Especialidades, Cursos y Administrativos.
● Desarrollar una aplicación móvil para la gestión de calificaciones.
● Generar reportes de acuerdo a las necesidades del caso de estudio.
● Realizar Pruebas del sistema.

Tabla 1: Objetivos específicos y acciones

OBJETIVOS ESPECÍFICOS ACCIONES

● Realizar entrevistas con el personal

a cargo del escuadrón de
Analizar los procesos de la gestión evaluación.
académica, de calificaciones y Diseñar el ● Analizar el procedimiento de gestión
Modelo de negocio actual. académica.
● Esquematizar el modelo de negocio
actual.

● Identificar las falencias existentes en

el proceso actual de gestión de

Diseñar el modelo de negocio alternativo calificaciones.

considerando la necesidad de una ● Realizar el modelado de negocio

plataforma web y móvil. alternativo de acuerdo al sistema

propuesto.
● Validar el modelo con los actores del
sistema.

8
 ● Seleccionar el modelo de desarrollo
de software.

● Seleccionar el gestor de base de

datos.
● Seleccionar el lenguaje de
programación.
● Seleccionar el framework.
● Seleccionar el entorno de desarrollo.
● Analizar los requerimientos sobre la
Gestión de Calificaciones.
● Elaborar modelamiento usando
UML2.
● Seleccionar arquitectura de

Diseñar e implementar los módulos de software.

gestión de Estudiantes, Docentes, ● Diseñar la arquitectura de software.

Materias, Especialidades, Cursos y ● Elaborar Diagrama de base de

Administrativos. datos.
● Elaborar diseño de interfaz.
● Diseñar los módulos para la gestión
de estudiantes, docentes, materias,
especialidades, cursos y
administrativos.
● Implementar todos los módulos
diseñados.
● Realizar Pruebas a los módulos
codificados.

9
 ● Identificar y seleccionar
herramientas de desarrollo para la
construcción de la aplicación
android.
● Definir actividades y servicios para la
aplicación android.
● Seleccionar el lenguaje de
programación para el desarrollo de
la aplicación móvil.
● Analizar y diseñar el módulo de
calificaciones de la aplicación web.
Desarrollar una aplicación móvil para la ● Implementar el módulo de
gestión de calificaciones. calificaciones en la aplicación web.
● Diseñar la interfaz para la aplicación
móvil.
● Seleccionar la arquitectura de
software para la aplicación móvil.
● Diseñar la arquitectura de software
para la aplicación móvil.
● Implementar módulo de gestión de
calificaciones de la aplicación móvil.
● Realizar la conexión para integrar los
módulos móvil y web.

 Determinar los tipos de reportes que

Generar reportes de acuerdo a las se quieren para el caso de estudio.

necesidades del caso de estudio.  Determinar los campos necesarios

para cada tipo de reporte que se
quiera para el caso de estudio.

10
  Elaborar Modulo de Generación de
Reportes.

● Identificar pruebas de acuerdo al

sistema elaborado.
● Aplicar las pruebas al código
Realizar Pruebas del sistema.
implementado.
● Corregir fallas encontradas por las
pruebas.

Fuente: [Elaboración Propia].

1.5. JUSTIFICACIÓN

A continuación se describen las justificaciones del proyecto propuesto:

1.5.1. Justificación Técnica

La Intranet Corporativa con comunicación Android para el proceso de gestión de

calificaciones en el Politécnico Militar de Aeronáutica, permitirá la integración de
recursos tecnológicos existentes dentro de la institución (Computadoras y
dispositivos móviles con android) con las tecnologías que se implementen de
acuerdo al crecimiento institucional, y permitirá brindar la integridad de datos para
el personal administrativo, y estos podrán acceder a los mismos a través de
dispositivos tecnológicos como ser computadoras de escritorio, computadoras
portátiles, teléfonos inteligentes, tabletas, etc. Ya que estos mismos cuentan con
servicio de internet Wi-Fi en toda la institución.

1.5.2. Justificación Económica

La Intranet Corporativa con comunicación Android permitirá la disminución en

costos de material de escritorio, lo cual podría implicar la reducción de gastos en

11
recursos humanos y técnicos. Además que se utilizará software libre, lo cual no
proporcionará gastos en licencias a la institución.

1.5.3. Justificación Operativa

El desarrollo de este proyecto implica mejorar los tiempos en los procesos de

obtención de la información y entrega de reportes de notas para los distintos
usuarios como ser al Jefe de Escuadrón de Evaluación, Comandante de la
institución y estudiantes.

1.6. ALCANCE

A continuación se describen los alcances del proyecto:

1.6.1. Alcance Temático

Las áreas sobre las cuales se ubica el siguiente trabajo son Tecnologías de la
Comunicación y Redes, Ingeniería del Software, Paradigmas de Análisis y Diseño
de Sistemas, Sistemas Operativos, Sistemas Distribuidos, Gestión de Base de
Datos, Sistemas De Desarrollo Móvil, Sistemas de Información.

1.6.2. Alcance Institucional

La Intranet Corporativa con comunicación Android será diseñada e implementada

para la obtención de reportes del área de gestión académica en el Politécnico Militar
de Aeronáutica Sbtte José Max Ardiles Monrroy.

1.6.3. Alcance Temporal

La Intranet Corporativa con comunicación Android, se terminará en la siguiente

gestión 2015, y este tendrá vigencia hasta la modificación o cambio en los procesos
de gestión de calificaciones actualmente utilizados dentro de la institución, con un
tiempo aproximado de 5 años.

12
1.7. HIPÓTESIS

La Intranet Corporativa con comunicación Android para el Politécnico Militar de

Aeronáutica, permitirá reducir los tiempos de entrega de reportes y el riesgo de
pérdida de información personal y de notas de los estudiantes militares.

1.7.1. Análisis de Variables

Variables independientes

● La Intranet Corporativa con comunicación Android de gestión de

calificaciones.

Variables dependientes

● Tiempo de entrega de reportes.

● Riesgo de pérdida de información personal y calificaciones de estudiantes
militares.

1.7.2. Definición Conceptual

Variable Independiente

Intranet Corporativa con comunicación Android permite la obtención oportuna de

información de reportes, evita el riesgo de pérdida de información personal y
calificaciones de los estudiantes militares.

Variables dependientes

○ Tiempos de entrega de reportes.

Se refiere al tiempo empleado en la elaboración y entrega de reportes, el cual será

reducido al emplear la intranet desarrollada ya que al contar con información
organizada y gracias a los protocolos y arquitecturas a emplear, se podrá emitir
cualquier información de una manera más rápida.

13
 ○ Riesgo de pérdida de información personal y calificaciones de
estudiantes militares.

Permite tener toda la información de la institución almacenada en una base de

datos, sin correr el riesgo de pérdida y/o extravío de documentos en papel donde
se posea información de importancia.

1.7.3. Operativización de Variables

Tabla 2: Operativizacion de variables.

VARIABLE DIMENSIÓN INDICADOR

Variable Independiente: Desarrollo de la intranet Comparación de

Corporativa y la aplicación beneficios con y sin el
La Intranet Corporativa con
móvil. sistema.
comunicación Android.

Variable Dependiente: La cantidad de tiempo en Tiempo

los procesos manuales en
Tiempos de entrega de
la gestión de calificaciones.
reportes

Variable Dependiente: Matriz de riesgo. Nivel de riesgo

Riesgo de pérdida de
información personal y
calificaciones de
estudiantes militares.

Fuente: [Elaboración Propia].

14
1.7.4. MATRIZ DE CONSISTENCIA

Tabla 3: Matriz de consistencia.

PROBLEMA OBJETIVO HIPÓTESIS

Intranet Corporativa con comunicación Android para el proceso de gestión

de calificaciones. Caso de estudio: Politécnico Militar de Aeronáutica Sbtte
José Max Ardiles Monrroy.

Desarrollar Intranet
Corporativa con La Intranet
comunicación Corporativa con
Los procedimientos comunicación Android
manuales actuales en la Android para el
proceso de gestión para proceso de
gestión de calificaciones gestión de
del POLMILAE. de calificaciones en
el Politécnico Militar calificaciones en el
de Aeronáutica Sbtte Politécnico Militar de
José Max Ardiles Aeronáutica.
Provoca Monrroy.

Permitirá
Perdida de
información
personal de los Reducir los Tiempos
estudiantes de entrega de
Para reportes y el riesgo
militares y exceso
de tiempo en la de pérdida de
Reducir tiempos de información personal
generación de entrega de reportes,
reportes solicitados y notas de los
evitar perdida de estudiantes militares.
por los distintos información personal
miembros del de los estudiantes
escuadrón de militares.
evaluación.

Fuente: [Elaboración Propia].

15
2. MARCO TEÓRICO
2.1. TÉCNICAS DE RECOPILACIÓN DE INFORMACIÓN

En este segmento se describen los métodos y técnicas que serán utilizados para
recopilar datos sobre la situación actual del Politécnico Militar de Aeronáutica Sbtte
Jose Max Ardiles Monrroy.

Existen tres métodos interactivos conocidos para obtener los requerimientos de

información de los miembros de la institución, ellos son: Entrevistas, cuestionarios,
y observación.

2.1.1. Entrevistas

Antes de empezar una entrevista se necesita conocer los prejuicios y cómo

afectarán éstos sus percepciones. La educación, intelecto, formación, emociones y
marco ético actúan como filtros poderosos de lo que se oirá en la entrevistas. Es
necesario pensar detalladamente en las entrevistas antes de hacerlas. Visualizar
por qué las va a hacer, qué se va a preguntar y qué es lo que a su juicio hará que
esta entrevista tenga éxito. Asimismo, debe pensar cómo se logrará que la
entrevista sea satisfactoria para el individuo al que se entreviste.

Una entrevista para recabar información es una conversación dirigida con un

propósito específico que utiliza un formato de preguntas y respuestas. En la
entrevista es necesario obtener las opiniones de los entrevistados y su parecer
acerca del estado actual del sistema, metas organizacionales, personales y
procedimientos informales. Las metas son información importante que se puede
recabar de las entrevistas. Los hechos que obtenga de los datos concretos y reales
podrían explicar el desempeño pasado, pero las metas reflejan el futuro de la
organización. Es necesario averiguar lo más que se pueda acerca de las metas de
la organización por medio de las entrevistas. Éste quizá sea el único método de
recopilación de datos efectivo para determinar las metas de la organización
(Kendall, 2011).

16
 Para realizar las entrevistas se deben tomar en cuenta los siguientes aspectos:

 Tener presente que información se necesita.

 Formulación de preguntas adecuadas para obtener la información necesaria.
 Resumir el contenido y significado de las respuestas.
 Se debe elaborar preguntas sencillas y no complejas.

TIPOS DE PREGUNTAS

Preguntas abiertas

Estas preguntas incluyen aquellas como "¿Qué piensa de poner a todos los
gerentes en una intranet?" y "Explique por favor cómo toma una decisión de
programación de producción". Considere el término abiertas. En realidad, "abiertas"
describe las opciones del entrevistado para responder. La respuesta puede ser de
dos palabras o dos párrafos.

Las ventajas de utilizar las preguntas abiertas son muchas e incluyen las siguientes
(Sampieri, 2003):

a) Hacen que el entrevistado se sienta a gusto.

b) Permiten al entrevistador entender el vocabulario del entrevistado, el cual refleja su
educación, valores, actitudes y creencias.
c) Proporcionan gran cantidad de detalles.
d) Revelan nuevas líneas de preguntas que pudieron haber pasado desapercibidas.
e) Hacen más interesante la entrevista para el entrevistado.
f) Permiten más espontaneidad.
g) Facilitan la forma de expresarse al entrevistador.
h) Son un buen recurso si el entrevistador no está preparado para la entrevista.

Las preguntas abiertas tienen varias ventajas. Sin embargo, también tienen muchas
desventajas:

17
a) Podrían dar como resultado muchos detalles irrelevantes.
b) Posible pérdida del control de la entrevista.
c) Permiten respuestas que podrían tomar más tiempo del debido para la cantidad útil
de información obtenida.
d) Dan la impresión de que el entrevistador es inexperto.
e) Podrían dar la impresión de que el entrevistador "anda de pesca" sin un objetivo
real en la entrevista.

Se debe considerar con cuidado las implicaciones de utilizar las preguntas abiertas
para entrevistar. Preguntas cerradas la alternativa a las preguntas abiertas se
encuentra en el otro tipo de pregunta básica (Salkind, 1999).

Preguntas cerradas

Tales preguntas son de la forma básica: "¿Cuántos subordinados tiene?" Las

respuestas posibles se cierran al entrevistado, debido a que sólo puede contestar
con un número finito como "Ninguno", "Uno" o "Quince

Una pregunta cerrada limita la respuesta disponible para el entrevistado. Es muy

similar a las preguntas cerradas a través de los exámenes de opción múltiple de la
universidad. Dan una pregunta y cinco respuestas, pero no le permiten anotar su
propia respuesta y aun así se espera que se conteste la pregunta correctamente
(Salkind, 1999).

Las ventajas de utilizar preguntas cerradas incluyen lo siguiente:

 Ahorro de tiempo.
 Comparar las entrevistas fácilmente.
 Ir al grano.
 Mantener el control durante la entrevista.
 Cubrir terreno rápidamente.
 Conseguir datos relevantes.

18
 Sin embargo, las desventajas de utilizar preguntas cerradas son considerables.
Dichas desventajas incluyen lo siguiente:

 Aburren al entrevistado.
 No permiten obtener gran cantidad de detalles [debido a que el entrevistador
proporciona el marco de referencia para el entrevistado].
 Olvidar las ideas principales por la razón anterior.
 No ayudan a forjar una relación cercana entre el entrevistador y el entrevistado.

Así, en la calidad de entrevistador, se debe pensar cuidadosamente los tipos de

pregunta que utilizará. (Salkind, 1999)

2.1.2. Cuestionarios

El uso de cuestionarios es una técnica de recopilación de información que permite

a los analistas de sistemas estudiar las actitudes, creencias, comportamiento y
características de muchas personas importantes en la organización que podrían
resultar afectadas por los sistemas actuales y los propuestos. Las actitudes
consisten en lo que las personas de la organización dicen que quieren (en un nuevo
sistema, por ejemplo); las creencias son lo que las personas realmente piensan que
es verdad; el comportamiento es lo que los miembros de la organización hacen, y
las características son propiedades de las personas o cosas. Es posible cuantificar
las respuestas conseguidas a través de cuestionarios (también conocidos como
encuestas) que usan preguntas cerradas (Kendall, 2011).

Ventajas

 Facilitan la recopilación de información y no se necesitan muchas

explicaciones ni una gran preparación para aplicarlos.
 Evitan la dispersión de la información, al concentrarse en preguntas de
elección forzosa.

19
  En el ambiente de sistemas es fácil capturar, concentrar y obtener
información útil a partir de las respuestas, mediante el uso de la
computadora. Incluso se puede proyectar los datos y hacer gráficas.
 Hacen impersonal la aportación de respuestas, por lo tanto ayudan a obtener
información útil y confiable si se plantean bien las preguntas.

Desventajas

 Falta de profundidad en las respuestas y no se pueden ir más allá del

cuestionario.
 Se necesita una buena elección del universo y de las muestras utilizadas.
 Pueden provocar la obtención de datos equivocados si se formulan
deficientemente, las preguntas, si se distorsionan o si se utilizan términos
ilegibles, poco usados o estereotipados.
 La interpretación y el análisis de los datos pueden ser muy simples si el
cuestionario no está bien estructurado o no contempla todos los puntos
requeridos.

2.1.3. Observación

La observación es la técnica de investigación básica, sobre las que se sustentan

todas las demás, ya que establece la relación básica entre el sujeto que observa y
el objeto que es observado, que es el inicio de toda comprensión de la realidad
(Kendall, 2011).

La observación es un procedimiento científico se caracteriza por ser:

 Intencionada: porque coloca las metas y los objetivos que los seres humanos
se proponen en relación con los hechos, para someterlos a una perspectiva
teleológica.
 Ilustrada: porque cualquier observación para ser tal está dentro de un cuerpo
de conocimientos que permite ser tal; solo se observa desde una perspectiva
teórica.

20
  Selectiva: porque necesita a cada paso discriminar aquello que interesa
conocer y separarlo del cúmulo de sensaciones que invade a cada momento.
 Interpretativa: en la medida en que se trata de describir y de explicar aquello
que se observando. Al final de una observación científica se dota de algún
tipo de explicación acerca de lo que se ha captado, al colocarlo en relación
con otros datos y con otros conocimientos previos.

En el proceso de observación se distinguen cinco elementos (Sampieri, 2003):

 Sujeto u observador, en el que se incluyen los elementos constituyentes de

este, tanto los sociológicos como los culturales, además de las experiencias
específicas del investigador.
 Objeto de la observación: que es la realidad, pero en donde se han
introducido procedimientos de selección y de discriminación, para separarlo
de otras sensaciones.
 Circunstancias de la observación: son las condiciones concretas que rodean
al hecho de observar y que terminan por formar parte de la propia
observación.
 Los medios de la observación: son los sentidos y los instrumentos
desarrollados por los seres humanos para extender los sentidos o inventar
nuevas formas y campos para la observación.
 Cuerpo de conocimientos: es el conjunto de saberes debidamente
estructurados en campos científicos que permiten que haya una observación
y que los resultados de esta integren a un cuerpo más amplio de
conocimientos (Sampieri, 2003).

2.2. METODOLOGÍAS DE DESARROLLO DE SOFTWARE

Metodología de desarrollo de software en ingeniería de software es un marco de

trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en
sistemas de información.

21
A lo largo del tiempo, una gran cantidad de métodos han sido desarrollados
diferenciándose por su fortaleza y debilidad. (Kendall, 2011).

El Framework para metodología de desarrollo de software consiste en:

• Una filosofía de desarrollo de programas de computación con el enfoque

del proceso de desarrollo de software

• Herramientas, modelos y métodos para asistir al proceso de desarrollo

de software

Estos Framework son a menudo vinculados a algún tipo de organización, que

además desarrolla, apoya el uso y promueve la metodología. La metodología es a
menudo documentada en algún tipo de documentación formal.

Cada metodología de desarrollo de software tiene más o menos su propio enfoque

para el desarrollo de software.

2.2.1. Modelo Incremental

El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el
enfoque incremental de desarrollo como una forma de reducir la repetición del
trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de
decisiones en los requisitos hasta adquirir experiencia con el sistema. Este modelo
se conoce también bajo las siguientes denominaciones:

 Método de las comparaciones limitadas sucesivas.

 Ciencia de salir del paso.
 Método de atacar el problema por ramas.

22
El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la
filosofía interactiva de Construcción de Prototipos. Como se muestra en la Figura 1,
el modelo incremental aplica secuencias lineales de forma escalonada mientras
progresa el tiempo en el calendario. Cada secuencia lineal produce un incremento
del software. El primer incremento generalmente es un producto esencial
denominado núcleo.

En una visión genérica, el proceso se divide en 4 partes:

 Análisis
 Diseño
 Código
 Prueba

Se puede ver en la figura 1 de mejor manera los 4 componentes del modelo

incremental.

Figura 1: Modelo Incremental

Fuente: (Calero, 2010).

El Modelo Incremental es de naturaleza interactiva brindando al final de cada

incremento la entrega de un producto completamente operacional. Este modelo es
particularmente útil cuando no se cuenta con una dotación de personal suficiente.

23
Los primeros pasos los pueden realizar un grupo reducido de personas y en cada
incremento se añadirá personal, de ser necesario. Por otro lado los incrementos se
pueden planear para gestionar riesgos técnicos (Calero, 2010).

Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al

final terminará siendo la solución completa requerida por el cliente, pero éstas partes
no se pueden realizar en cualquier orden, sino que dependen de lo que el cliente
este necesitando con más urgencia, de los puntos más importantes del proyecto,
los requerimientos más básicos, difíciles y con mayor grado de riesgo, ya que estos
se deben hacer al comienzo, de manera que se disminuya la dificultad y el riesgo
en cada versión.

De este modo podemos terminar una aplicación ejecutable (primera versión) que
podrá ser entregada al cliente para que éste pueda trabajar en ella y el programador
pueda considerar las recomendaciones que el cliente efectúe para hacer mejoras
en el producto. Estas nuevas mejoras deberán esperar a ser integradas en la
siguiente versión junto con los demás requerimientos que no fueron tomados en
cuenta en la versión anterior.

El modelo incremental consiste en un desarrollo inicial de la arquitectura completa

del sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene
su propio ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus
interfaces. Una vez entregado un incremento, no se realizan cambios sobre el
mismo, sino únicamente corrección de errores. Dado que la arquitectura completa
se desarrolla en la etapa inicial, es necesario conocer los requerimientos completos
al comienzo del desarrollo.

Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos, las
funcionalidades que proporcionará el sistema. Se confecciona un bosquejo de
requisitos funcionales y será el cliente quien se encarga de priorizar que
funcionalidades son más importantes. Con las funcionalidades priorizadas, se
puede confeccionar un plan de incrementos, donde en cada incremento se indica
un subconjunto de funcionalidades que el sistema entregará. La asignación de
24
funcionalidades a los incrementos depende de la prioridad dada a los requisitos.
Finalizado el plan de incrementos, se puede comenzar con el primer incremento
(Sommerville, 2011).

Características:

 Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con

cierta frecuencia.
 El usuario se involucra más.
 Difícil de evaluar el costo total.
 Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados
y a operar como un todo.
 Requiere gestores experimentados.
 Los errores en los requisitos se detectan tarde.
 El resultado puede ser positivo.

Ventajas (Sommerville, 2011):

 Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya

que se implementa la funcionalidad parcial.
 También provee un impacto ventajoso frente al cliente, que es la entrega
temprana de partes operativas del software.
 El modelo proporciona todas las ventajas del modelo en Cascada
realimentado, reduciendo sus desventajas sólo al ámbito de cada
incremento.
 Resulta más sencillo acomodar cambios al acotar el tamaño de los
incrementos.

Desventajas (Sommerville, 2011):

 El modelo incremental no es recomendable para casos de sistemas de

tiempo real, de alto nivel de seguridad, de procesamiento distribuido y/o de
alto índice de riesgos.

25
  Requiere de mucha planeación, tanto administrativa como técnica.
 Requiere de metas claras para conocer el estado del proyecto.

2.2.2. Metodología Proceso Unificado de desarrollo de software

El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es

un marco de desarrollo de software que se caracteriza por estar dirigido por casos
de uso, centrado en la arquitectura y por ser iterativo e incremental.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo

extensible que puede ser adaptado a organizaciones o proyectos específicos.

Características:

Iterativo e Incremental

El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto

de cuatro fases denominadas Inicio, Elaboración, Construcción y Transición. Cada
una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio
puede incluir varias iteraciones en proyectos grandes). Estas iteraciones ofrecen
como resultado un incremento del producto desarrollado que añade o mejora las
funcionalidades del sistema en desarrollo.

Dirigido por los casos de uso

En el Proceso Unificado los casos de uso se utilizan para capturar los requisitos
funcionales y para definir los contenidos de las iteraciones. La idea es que cada
iteración tome un conjunto de casos de uso o escenarios y desarrolle todo el camino
a través de las distintas disciplinas: diseño, implementación, prueba, etc. El proceso
dirigido por casos de uso es el rup. Nota: en UP se está Dirigido por requisitos y
riesgos de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el tema.

Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que
recuerdan a las definidas en el ciclo de vida clásico o en cascada: Análisis de

26
requisitos, Diseño, Implementación y Prueba. Aunque todas las iteraciones suelen
incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una
de ellas varía a lo largo del proyecto.

Enfocado en los riesgos

El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los
riesgos críticos en una etapa temprana del ciclo de vida. Los resultados de cada
iteración, en especial los de la fase de Elaboración deben ser seleccionados en un
orden que asegure que los riesgos principales son considerados primero.

Ventajas

 Mitigación temprana de posibles riesgos altos

 Progreso visible en las etapas tempranas
 El conocimiento adquirido en una iteración puede aplicarse de iteración a
iteración
 Los usuarios están involucrados continuamente

Desventajas

 Requiere costos de dedicación altos por lo que no es conveniente usarlo en

procesos de un proyecto pequeño.
 Si el proceso no se aplica bien desde el inicio, se puede volver muy grande
y difícil, tanto para aprender como para administrar.
 Se basa mucho en la documentación.

Lenguaje unificado de modelado

El Lenguaje unificado de modelado, no es el sucesor de la oleada de métodos de

análisis y diseño orientados a objetos que surgió a finales de la década de los 1980
y principios de la siguiente. El UML unifica, sobre todo, los métodos de Booch,
Rumbaugh, Brühl (OMT) y Jacobson, pero su alcance ha llegado a formar parte

27
fundamental de la Ingeniería de Software tras su estandarización en 1997 con el
OMG (Object Management Group o Grupo de administración de objetos).

Para este proyecto se optó por trabajar con UML en su versión 2.0, que se detallara
en el siguiente punto.

2.2.2.1. UML 2.0

El Lenguaje unificado de modelado, no es el sucesor de la oleada de métodos de

análisis y diseño orientados a objetos que surgió a finales de la década de los 1980
y principios de la siguiente. El UML unifica, sobre todo, los métodos de Booch,
Rumbaugh, Brühl (OMT) y Jacobson, pero su alcance ha llegado a formar parte
fundamental de la Ingeniería de Software tras su estandarización en 1997 con el
OMG (Object Management Group o Grupo de administración de objetos).

Cuando se modela algo, se crea una simplificación de la realidad para comprender

mejor el sistema que se está desarrollando se utilizan los diagramas que ofrece
UML 2.0.

Los diagramas son los medios para ver estos bloques de construcción. Un diagrama
es una presentación grafica de un conjunto de elementos, que la mayoría de las
veces se dibuja con un grafo, conexo de nodos (elementos) y arcos (relaciones).
Los diagramas se utilizan para visualizar desde diferentes perspectivas.

Los diagramas de UML 2.0 nos permiten ver dos tipos aspectos al momento de
hacer el diseño que son los aspectos dinámicos o también llamados elementos de
comportamiento y estáticos también llamados elementos estructurales, a
continuación se muestra que diagramas pertenecen a qué tipo de elementos:

Diagramas estructurales:

 Diagramas de clases.
 Diagramas de componentes.
 Diagramas de estructura compuesta.
28
  Diagramas de objetos.
 Diagramas de artefactos.
 Diagramas de despliegue.

Diagramas de comportamiento:

 Diagramas de casos de uso.

 Diagramas de secuencia.
 Diagramas de comunicación.
 Diagramas de estados.
 Diagramas de actividades.

Estos diagramas nos permiten elaborar un diseño más entendible a la hora de

realizar el modelado del software. A continuación se detallarán los diagramas de
UML 2.0.

Diagramas de casos de uso

Un caso de uso es una unidad coherente de funcionalidad, externamente visible,

proporcionada por una unidad del sistema y expresada por secuencias de mensajes
intercambiados por la unidad del sistema y uno o más actores. Su propósito es
definir una pieza de comportamiento coherente, sin revelar la estructura interna del
sistema, ver figura 2.

29
 Figura 2: Representación de Diagramas de casos de uso

Fuente: (Hernández, 1995).

Actor

Es una idealización de una persona externa, de un proceso, o de una cosa que

interactúa con un sistema, un subsistema, o una clase. Un actor caracteriza las
interacciones que los usuarios exteriores pueden tener con el sistema, ver figura 3.

30
 Figura 3: Representación de un Actor

Fuente: (Hernández, 1995).

Un caso de uso puede participar en varias relaciones, además de poderse asociar

con actores.

Diagramas de comunicación

En el Lenguaje Unificado de Modelado (UML) 2.0, un diagrama de comunicación es

una versión simplificada del diagrama de colaboración de la versión de UML 1.x.

Un diagrama de comunicación modela las interacciones entre objetos o partes en

términos de mensajes en secuencia. Los diagramas de comunicación representan
una combinación de información tomada desde el diagrama de clases, secuencia,
y diagrama de casos de uso describiendo tanto la estructura estática como el
comportamiento dinámico de un sistema.

Los diagramas de comunicación y de secuencia describen información similar, y con

ciertas transformaciones, pueden ser transformados unos en otros sin dificultad.

Para mantener el orden de los mensajes en un diagrama de comunicación, los

mensajes son etiquetados con un número cronológico y colocado cerca del enlace
por el cual se desplaza el mensaje. Leer un diagrama de comunicación conlleva

31
comenzar en el mensaje 1.0, y seguir los mensajes desde un objeto hasta el
siguiente, sucesivamente, ver figura 4.

Figura 4: Diagrama de comunicación

Fuente: (Arlow, 2001).

Diagramas de actividades

En UML un diagrama de actividades se usa para mostrar la secuencia de

actividades. Los diagramas de actividades muestran el flujo de trabajo desde el
punto de inicio hasta el punto final detallando muchas de las rutas de decisiones
que existen en el progreso de eventos contenidos en la actividad. Estos también
pueden usarse para detallar situaciones donde el proceso paralelo puede ocurrir en
la ejecución de algunas actividades. Los Diagramas de Actividades son útiles para
el Modelado de Negocios donde se usan para detallar el proceso involucrado en las
actividades de negocio

32
 Figura 5: Diagrama de actividades

Fuente: (Arlow, 2001).

Diagramas de despliegue

Un Diagrama de Despliegue modela la arquitectura en tiempo de ejecución de un

sistema. Esto muestra la configuración de los elementos de hardware (nodos) y
muestra cómo los elementos y artefactos del software se trazan en esos nodos.

Nodo

Un Nodo es un elemento de hardware o software. Esto se muestra con la forma de

una caja en tres dimensiones, ver figura 6.

33
 Figura 6: Diagrama de actividades

Fuente: [ (Arlow, 2001)].

Instancia de nodo

Una instancia de nodo se puede mostrar en un diagrama. Una instancia se puede

distinguir desde un nodo por el hecho de que su nombre esta subrayado y tiene dos
puntos antes del tipo de nodo base. Una instancia puede o no tener un nombre
antes de los dos puntos. La figura 7 muestra una instancia nombrada de una
computadora.

Figura 7: Instancia de un nodo

Fuente: (Arlow, 2001).

Estereotipo de nodo

Un número de estereotipos estándar se proveen para los nodos, nombrados

«cdrom», «cd-rom», «computer», «disk array», «pc», «pc client», «pc server»,
«secure», «server», «storage», «unix server», «user pc». Estos mostrarán un icono
apropiado en la esquina derecha arriba del símbolo nodo, ver figura 8.

34
 Figura 8: Estereotipo de un nodo

Fuente: (Arlow, 2001).

Artefacto

Un artefacto es un producto del proceso de desarrollo de software, que puede incluir

los modelos del proceso (modelos de Casos de Uso, modelos de Diseño, etc.),
archivos fuente, ejecutables, documentos de diseño, reportes de prueba, prototipos,
manuales de usuario y más.

Un artefacto se denota por un rectángulo mostrando el nombre del artefacto, el

estereotipo «artifact» y un icono de documento, ver figura 9.

Figura 9: Artefacto

Fuente: (Arlow, 2001).

Asociación

En el contexto del diagrama de despliegue, una asociación representa una ruta de

comunicación entre los nodos. La figura 10 diagrama muestra un diagrama de
despliegue para una red, mostrando los protocolos de red como estereotipos y
también mostrando multiplicidades en los extremos de la asociación.

35
 Figura 10: Asociación de nodos

Fuente: (Arlow, 2001).

Nodo contenedor

Un nodo puede contener otros elementos, como componentes o artefactos. La

figura 11 muestra un diagrama de despliegue para una parte del sistema embebido
y muestra un artefacto ejecutable como contenido por el nodo madre (motherboard).

Figura 11: Contenedor de nodos

Fuente: (Arlow, 2001).

36
Diagramas de Clases

El diagrama de clases muestra un conjunto de clases, interfaces y sus relaciones.

Éste es el diagrama más común a la hora de describir el diseño de los sistemas
orientados a objetos. En la figura 12 se muestran las clases globales, sus atributos
y las relaciones de una posible solución al problema de la venta de artículos.

Figura 12: Diagrama de clases

Fuente: (Hernández, 1995).

2.2.3. Modelo de desarrollo en V

El método-v define un procedimiento uniforme para el desarrollo de productos para

las TIC. Es el estándar utilizado para los proyectos de la administración federal
alemán y de defensa. Como está disponible públicamente muchas compañías lo
usan. Es un método de gestión de proyectos comparable a prince2 y describe tanto
métodos para la gestión como para el desarrollo de sistemas (Sommerville, 2011).

La versión actual del método-v es el método-v xt que se terminó en febrero del 2005.
No es comparable con cmmi. Mientras que cmmi solo describe "qué" se ha hecho,

37
el método-v describe el "cómo" y el "cuándo" y "quién" es el responsable de haberlo
hecho.

El método-v fue desarrollado para regular el proceso de desarrollo de software por

la administración federal alemana. Describe las actividades y los resultados que se
producen durante el desarrollo del software.

El método-v es una representación gráfica del ciclo de vida del desarrollo del
sistema. Resume los pasos principales que hay que tomar en conjunción con las
correspondientes entregas de los sistemas de validación.

La parte izquierda de la v representa la corriente donde se definen las

especificaciones del sistema. La parte derecha de la v representa la corriente donde
se comprueba el sistema (contra las especificaciones definidas en la parte
izquierda). La parte de abajo, donde se encuentran ambas partes, representa la
corriente de desarrollo (Sommerville, 2011) ver figura 13.

La corriente de especificación consiste principalmente de:

 Especificaciones de requerimiento de usuario.

 Especificaciones funcionales.
 Especificaciones de diseño.

La corriente de pruebas, por su parte, suele consistir de:

 Calificación de instalación.
 Calificación operacional.
 Calificación de rendimiento.

Objetivos

El Método-V fue desarrollado para regular el proceso de desarrollo de software por

la Administración Federal Alemana. Describe las actividades y los resultados que
se producen durante el desarrollo del software.

38
Proporciona una guía para la planificación y realización de proyectos. Los siguientes
objetivos están destinados a ser alcanzados durante la ejecución del proyecto:

 Minimización de los riesgos del proyecto

Mejora la transparencia del proyecto y control del proyecto, especificando los

enfoques estandarizados, describe los resultados correspondientes y funciones de
responsabilidad. Permite una detección temprana de las desviaciones y los riesgos
y mejora la gestión de procesos, reduciendo así los riesgos del proyecto
(Sommerville, 2011).

 Mejora y Garantía de Calidad

Como un modelo de proceso estándar, asegura que los resultados que se

proporcionan sean completos y contengan la calidad deseada. Los resultados
provisionales definidos se pueden comprobar en una fase temprana. La uniformidad
en el contenido del producto mejora la legibilidad, comprensibilidad y verificabilidad.

 Reducción de los gastos totales durante todo el proyecto y sistema de Ciclo de

Vida

El esfuerzo para el desarrollo, producción, operación y mantenimiento de un sistema

puede ser calculado, estimado y controlado de manera transparente mediante la
aplicación de un modelo de procesos estandarizados. Reduciendo la dependencia
en los proveedores y el esfuerzo para las siguientes actividades y proyectos.

 Mejora de la comunicación entre todos los inversionistas

La descripción estandarizada y uniforme de todos los elementos pertinentes y

términos es la base para la comprensión mutua entre todos los inversionistas. De
este modo, se reduce la pérdida por fricción entre el usuario, comprador, proveedor
y desarrollador.

39
 Figura 13: El modelo en V

Fuente: (Marick, 2005).

El nivel 1 está orientado al “cliente”. El inicio del proyecto y el fin del proyecto
constituyen los dos extremos del ciclo. Se compone del análisis de requisitos y
especificaciones, se traduce en un documento de requisitos y especificaciones.

El nivel 2 se dedica a las características funcionales del sistema propuesto. Puede

considerarse el sistema como una caja negra, y caracterizarla únicamente con
aquellas funciones que son directa o indirectamente visibles por el usuario final, se
traduce en un documento de análisis funcional.

El nivel 3 define los componentes hardware y software del sistema final, a cuyo
conjunto se denomina arquitectura del sistema.
40
El nivel 4 es la fase de implementación, en la que se desarrollan los elementos
unitarios o módulos del programa. (Marick, 2005)

Ventajas (Marick, 2005):

 La relación entre las etapas de desarrollo y los distintos tipos de pruebas

facilitan la localización de fallos.
 Es un modelo sencillo y de fácil aprendizaje
 Hace explícito parte de la iteración y trabajo que hay que revisar
 Especifica bien los roles de los distintos tipos de pruebas a realizar
 Involucra al usuario en las pruebas

Desventajas (Marick, 2005):

 Es difícil que el cliente exponga explícitamente todos los requisitos

 El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de
vida
 Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas
 El producto final obtenido puede que no refleje todos los requisitos del
usuario.

2.3. MODELAMIENTO DE BASE DE DATOS.

2.3.1. Sistemas de Gestión de Bases de Datos

Es el software que permite la utilización y/o la actualización de los datos

almacenados en una (o varias) base(s) de datos por uno o varios usuarios desde
diferentes puntos de vista y a la vez, se denomina sistema de gestión de bases de
datos (SGBD).

Por medio de la figura 14 se observa el esquema de un Sistema de Gestor de Base

de Datos.

41
 Figura 14: Esquema de un DBMS

Usuarios / Programadores
SISTEMA DE
BASE DE DATOS
Programas de Aplicación / Consultas

Software del
DBMS
Software para procesar Consultas /
Programas

Software para tener acceso a los datos

almacenados

Definición de la Base Base de Datos

de Datos almacenada Almacenada

Fuente: (Ableson, 2013).

El objetivo fundamental de un SGBD consiste en suministrar al usuario las

herramientas que le permitan manipular, en términos abstractos, los datos, o sea,
de forma que no le sea necesario conocer el modo de almacenamiento de los datos
en la computadora, ni el método de acceso empleado.

Los programas de aplicación operan sobre los datos almacenados en la base

utilizando las facilidades que brindan los SGBD, los que, en la mayoría de los casos,
poseen lenguajes especiales de manipulación de la información que facilitan el
trabajo de los usuarios.

42
Estos lenguajes estándar son:

1. DDL (Data Definition language): Lenguaje de Definición de Datos. Por

medio de este el DBMS identifica las descripciones de los elementos de las
tablas y almacena la descripción de las tablas en el catálogo del DBMS.

2. SDL (Store Definition language): Lenguaje de definición de

almacenamiento. Es utilizado por el DBMS para especificar el esquema
interno que corresponde a la Base de Datos Almacenada.

3. VDL (View Definition language): Lenguaje de Definición de Vistas. Es

utilizado por el DBMS para especificar las vistas del usuario y sus
correspondencias con el esquema conceptual.

4. DML (Data Manipulation language): Lenguaje de Manipulación de Datos.

Permite la manipulación de las operaciones de Inserción, Eliminación y
Modificación. Tipos de DML's: De alto Nivel o No por procedimientos: SQL.
De bajo Nivel o por procedimiento

Los SGDB brindan facilidad a la hora de elaborar tablas y establecer relaciones

entre las informaciones contenidas en ellas. Pueden mantener la integridad de una
base de datos permitiéndole a más de un usuario actualizar un registro al mismo
tiempo y también puede impedir registros duplicados en una BD. (Kinderman, 2014).

2.3.1.1. PostgreSQL

PostgreSQL es un sistema de gestión de bases de datos objeto-relacional,

distribuido bajo licencia BSD y con su código fuente disponible libremente. Es el
sistema de gestión de bases de datos de código abierto más potente del mercado y
en sus últimas versiones no tiene nada que envidiarle a otras bases de datos
comerciales.
43
PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez de
multihilos para garantizar la estabilidad del sistema. Un fallo en uno de los procesos
no afectará el resto y el sistema continuará funcionando.

A continuación en la figura 15 se ilustra de manera general los componentes más

importantes en un sistema PostgreSQL.

Figura 15: Componentes de un sistema PostgreSQL

Fuente: (Kinderman, 2014).

 Aplicación cliente: Esta es la aplicación cliente que utiliza PostgreSQL

como administrador de bases de datos. La conexión puede ocurrir vía
TCP/IP o sockets locales.

44
  Demonio postmaster: Este es el proceso principal de PostgreSQL. Es el
encargado de escuchar por un puerto/socket por conexiones entrantes de
clientes. También es el encargado de crear los procesos hijos que se
encargaran de autentificar estas peticiones, gestionar las consultas y
mandar los resultados a las aplicaciones clientes.
 Ficheros de configuración: Los 3 ficheros principales de configuración
utilizados por PostgreSQL, postgresql.conf, pg_hba.conf y pg_ident.conf
 Procesos hijos postgres: Procesos hijos que se encargan de
autentificar a los clientes, de gestionar las consultas y mandar los
resultados a las aplicaciones clientes.
 PostgreSQL share buffer cache: Memoria compartida usada por
PostgreSQL para almacenar datos en caché.
 Write-Ahead Log (WAL): Componente del sistema encargado de
asegurar la integridad de los datos (recuperación de tipo REDO).
 Kernel disk buffer cache: Caché de disco del sistema operativo
 Disco: Disco físico donde se almacenan los datos y toda la información
necesaria para que PostgreSQL funcione.

Ventajas (Kinderman, 2014):

 Ampliamente popular - Ideal para tecnologías Web.

 Fácil de Administrar.
 Su sintaxis SQL es estándar y fácil de aprender.
 Footprint bajo de memoria, bastante poderoso con una configuración adecuada.
 Multiplataforma.
 Capacidades de replicación de datos.
 Soporte empresarial disponible.

Desventajas (Kinderman, 2014):

 Sin experticia, configurar llega a ser un caos.

 Es fácil de vulnerar sin protección adecuada.

45
 El motor MyISAM es instalado por defecto y carece de capacidades de
integridad relacional.
 InnoDB genera mucho footprint en memoria al indizar.
 El toolset empresarial tiene un costo adicional por suscripción anual.
 Realizar revisiones llegar a ser una labor manual y tediosa para el DBA.
 Reducida cantidad de tipos de datos.

2.3.1.2. Mysql

MySQL es un gestor de base de datos sencillo de usar e increíblemente rápido.

También es uno de los motores de base de datos más usados en Internet, la
principal razón de esto es que es gratis para aplicaciones no comerciales.

Las características principales de MySQL son (Microsoft Corporation, 2014):

Es un gestor de base de datos.

Una base de datos es un conjunto de datos y un gestor de base de datos es una

aplicación capaz de manejar este conjunto de datos de manera eficiente y cómoda.

Es una base de datos relacional.

Una base de datos relacional es un conjunto de datos que están almacenados en

tablas entre las cuales se establecen unas relaciones para manejar los datos de una
forma eficiente y segura. Para usar y gestionar una base de datos relacional se usa
el lenguaje estándar de programación SQL.

Es Open Source.

El código fuente de MySQL se puede descargar y está accesible a cualquiera, por

otra parte, usa la licencia GPL para aplicaciones no comerciales.
46
Es una base de datos muy rápida:

Segura y fácil de usar. Gracias a la colaboración de muchos usuarios, la base de

datos se ha ido mejorando optimizándose en velocidad. Por eso es una de las bases
de datos más usadas en Internet.

Ventajas (Microsoft Corporation, 2014):

 MySQL software es Open Source.

 Velocidad al realizar las operaciones, lo que le hace uno de los gestores con
mejor rendimiento.
 Bajo costo en requerimientos para la elaboración de bases de datos, ya que
debido a su bajo consumo puede ser ejecutado en una máquina con escasos
recursos sin ningún problema.
 Baja probabilidad de corromper datos, incluso si los errores no se producen
en el propio gestor, sino en el sistema en el que está.
 Su conectividad, velocidad, y seguridad hacen de MySQL Server altamente
apropiado para acceder bases de datos en Internet.
 El software MySQL usa la licencia GPL.

Desventajas (Microsoft Corporation, 2014):

 Un gran porcentaje de las utilidades de MySQL no están documentadas

 Los privilegios de una tabla no se eliminan automáticamente cuando se borra
una tabla.
 No es intuitivo, como otros programas (Access).

2.3.1.3. Microsoft SQL Server

Microsoft SQL Server es un sistema para la gestión de bases de datos producido

por Microsoft basado en el modelo relacional. Sus lenguajes para consultas son T-
SQL y ANSI SQL. Microsoft SQL Server constituye la alternativa de Microsoft a otros

47
potentes sistemas gestores de bases de datos como son Oracle, PostgreSQL o
MySQL.

Microsoft SQL Server revoluciona el concepto de Base de datos para la Empresa.

Reúne en un sólo producto la potencia necesaria para cualquier aplicación
empresarial, crítica junto con unas herramientas de gestión que reducen al mínimo
el coste de propiedad. Con Microsoft SQL Server, la empresa tiene todo de serie.

Ventajas (Microsoft Corporation, 2014):

 Soporte de transacciones.
 Escalabilidad, estabilidad y seguridad.
 Soporta procedimientos almacenados.
 Incluye también un potente entorno gráfico de administración, que permite el
uso de comandos DDL y DML gráficamente.
 Permite trabajar en modo cliente-servidor, donde la información y datos se
alojan en el servidor y los terminales o clientes de la red sólo acceden a la
información.
 Además permite administrar información de otros servidores de datos.

Desventajas (Kinderman, 2014):

 MSSQL usa Address Windowing Extensión (AWE) para hacer el

direccionamiento de 64-bit. Esto le impide usar la administración dinámica de
memoria y sólo le permite alojar un máximo de 64GB de memoria compartida.

MSSQL no maneja compresión de datos (en SQL Server 2005 y 2000, solamente
la versión 2008 Enterprise Edition incluye esta característica), por lo que ocupa
mucho espacio en disco.

48
2.4. SERVICIOS WEB

El consorcio W3C define los servicios web como sistemas software diseñados para
soportar una interacción interoperable maquina a máquina sobre una red. Los
Servicios Web suelen ser APIs Web que pueden ser accedidas dentro de una red
(principalmente Internet) y son ejecutados en el sistema que los aloja. (W3C, 2004)

Un servicio web es un estándar de comunicación entre procesos y componentes,

diseñado para ser multiplataforma y multilenguaje, es decir, no importa en qué
lenguaje este programado un servicio web como ser Visual Basic, C# o Java, o en
que plataforma este corriendo, ya sea Windows, UNIX o Linux estos serán
accesibles y utilizables por otras aplicaciones desarrolladas en otras plataformas o
lenguajes de programación. Antiguamente se utilizaban otros estándares como
DCOM (DistributedComponentObjectModel) introducido por Microsoft e
implementado por otras plataformas, y CORBA
(CommonObjectRequestBrokerArchitecture) introducido por el OMG (Object
Management Group). Estos estándares tenían bastantes problemas de
configuración, especialmente en entornos en que se encontraban firewalls de por
medio en los cuales era imposible (debido a estándares de seguridad de muchas
compañías) habilitar ciertos puertos de comunicación para que estos componentes
funcionaran. De esta manera la preferencia por utilizar el puerto 80 de HTTP, que
normalmente se encuentra habilitado en la mayoría de los servidores y firewalls
debido al uso de navegadores y servidores web, no traería complicaciones el uso
de una tecnología que utilice este protocolo y puerto de TCP/IP. (Principios de Web
Services, 2006)

2.4.1. XML

XML es el acrónimo de eXtensibleMarkupLanguage o “Lenguaje de Marcas

Extensible” fue desarrollado por el W3C en 1998. XML es un documento bien
estructurado que es legible tanto para un humano como una máquina. Es una
versión más ligera y más flexible de su predecesor Standard

49
GeneralizedMarkupLanguage o "Estándar de Lenguaje de Marcado Generalizado"
(SGML). XML proporciona la sintaxis para el documento de marcado y proporciona
la sintaxis para declarar la estructura de los documentos.

XML y HTTP

Ambos protocolos son la base para llamar a los servicios web. Un usuario interactúa
a través de las interfaces de los servicios web mediante el envío de mensajes XML
a través de HTTP. XML y HTTP son útiles para crear y enviar mensajes porque son
ampliamente flexibles en múltiples plataformas y lenguajes. Esta interoperabilidad
permite que las aplicaciones se comuniquen utilizando diferentes lenguajes,
plataformas o middlewares que utilizan esta tecnología en común. (Wolfram, 2008)

2.4.2. Modelo de los servicios web

La arquitectura de los servicios web se basa en las interacciones entre tres

funciones: servicio, proveedor, registro de servicios y solicitante del servicio. Las
interacciones implican la publicación, búsqueda y enlace de las operaciones. En
conjunto, estas funciones y operaciones actúan sobre los artefactos de los servicios
web: el módulo del software de servicios web y su descripción. El servicio proveedor
define una descripción de servicio para el servicio web y lo publica en un servicio
solicitante o el registro de servicios. El solicitante del servicio utiliza una operación
de búsqueda para recuperar el servicio descrito localmente o desde el registro de
servicios y utiliza la descripción del servicio para enlazar con el proveedor de
servicios e invocar o interactuar con la implementación del servicio web, ver figura
16. (Heather Kreger, IBM Software Group, 2001).

50
 Figura 16: Roles, Operaciones y Artefactos de los Servicios Web

Descripción de
los Servicios

Registro de
Servicios
Publicación
Búsqueda WSDL, UDDI
WSDL. UDDI

Solicitante del Proveedor del

Servicio
Servicio Servicio

Enlace
Descripción de
los Servicios

Fuente: [ (Heather Kreger, IBM Software Group, 2001)].

2.4.2.1. Roles en una Arquitectura de Servicios Web

Proveedor de Servicios: Desde una perspectiva empresarial, este es el titular del

servicio. Desde un punto de vista arquitectónico, esta es la plataforma que aloja el
acceso al servicio.

Solicitante del servicio: Desde una perspectiva empresarial, este es el negocio

que requiere ciertas funciones que deben cumplir.

Registro de servicios: Se trata de un registro de búsquedas de descripciones de

servicios, donde los proveedores de servicio publican sus descripciones de los
servicios.

2.4.2.2. Operaciones en una Arquitectura de Servicios Web

Para obtener una solicitud por parte de los servicios, tres comportamientos deben
tener lugar: publicación de las descripciones de los servicios, operaciones de

51
búsqueda o hallazgo de descripciones de servicios y la vinculación o invocación de
servicios basados en la descripción del servicio, los servicios constan de los
siguientes componentes.

 Publicar: Para tener acceso, una descripción del servicio tiene que ser
publicado para que el solicitante del servicio puede encontrarlo. Cuando se
publicó pueden variar dependiendo de los requisitos de la aplicación.
 Buscar: En la operación de búsqueda, el solicitante del servicio recupera
una descripción de servicio directamente o consulta el registro de servicios
para el tipo de servicio requerido.
 Invocar: Con el tiempo, un necesaria la invocación de los servicios ofrecidos
por los proveedores.

2.4.2.3. Especificaciones del modelo

Los servicios web se definen a partir de las siguientes especificaciones, ver figura
17:

Figura 17: Pila de Servicios Web

Fuente: (Principios de Web Services, 2006).

 UDDI: Esta especificación define un modo de publicar y encontrar información

sobre servicios Web.
 WSDL: Es un formato XML que se utiliza para describir servicios Web

52
 SOAP: Es un protocolo estándar que define cómo dos objetos en diferentes
procesos pueden comunicarse por medio de intercambio de datos XML.

2.4.2.4. Ciclo de vida del desarrollo de los servicios web

El ciclo de vida para el desarrollo de los servicios web comprende la fase de

construcción, despliegue, ejecución y administración.

 Construcción: Esta fase implica el desarrollo y pruebas de la

implementación de los servicios.
 Despliegue: Esta fase comprende lo respectivo a la publicación de las
definiciones de los servicios.
 Ejecución: Durante esta fase los servicios web se encuentran disponibles
para su invocación.
 Administración: La fase de gestión implica un control y administración de
las aplicaciones de los servicios en base a parámetros como ser seguridad,
disponibilidad, rendimiento, calidad del servicio, etc.

2.4.3. Protocolos de comunicación para Servicios Web

A continuación se describen de manera general las arquitecturas más utilizadas

para la implementación de servicios web, ya que estos serán considerados para el
desarrollo del proyecto:

2.4.3.1. SOAP

SOAP (Simple Object Access Protocol) es el protocolo base de los servicios web.
Este protocolo está basado en XML y no se encuentra atado a ninguna plataforma
o lenguaje de programación. A su vez, también es el protocolo más aceptado para
la mayoría de las plataformas.

Si bien SOAP es un protocolo, este no es exactamente un protocolo de

comunicación entre mensajes como lo es HTTP. Básicamente, SOAP son
documentos XML y se necesita algún protocolo para la transmisión de estos

53
documentos como lo es HTTP o cualquier otro protocolo de comunicación capaz de
transmitir textos. Los mensajes SOAP están compuestos por una etiqueta principal
llamado “sobre o envoltura”, que está dividido en una cabecera y en un cuerpo,
como se observa en la Figura 18. (Principios de Web Services, 2006)

Figura 18: Estructura de un mensaje SOAP

Fuente: [ (Principios de Web Services, 2006)].

Partes de un mensaje SOAP

El envelope es el elemento más importante y de mayor jerarquía dentro del

documento XML y representa al mensaje que lleva almacenado dicho documento.

El header es un mecanismo genérico que se utiliza para añadir características

adicionales al mensaje SOAP. El modo en la que se añadan cada uno de los campos
dependerá exclusivamente del servicio implementado entre cliente y servidor, de
forma que cliente y servidor deberán estar de acuerdo con la jerarquía con la que
se hayan añadido los distintos campos.

El body es un contenedor de información en el cual se almacenarán los datos que

se quieran transmitir de lado a lado de la comunicación. Dentro de este campo,
SOAP define un elemento de uso opcional denominado Fault utilizado en los
mensajes de respuesta para indicar al cliente algún error ocurrido en el servidor.

54
Reglas de Codificación

Las reglas de codificación son usadas para determinar cómo se realiza la

codificación de los datos de los mensajes SOAP en XML.

SOAP define sus propias reglas de codificación, identificadas por los nombres e
espacio, pero no mandata el uso de las mismas, sino que las distintas
implementaciones del protocolo SOAP pueden definir sus propias reglas de
codificación.

La codificación definida por SOAP se basa en un sistema simple de tipos de datos

que es la generalización de las características comunes de los sistemas de tipos de
datos, tanto de los lenguajes de programación, como de las bases de datos y datos
semiestructurados.

2.4.3.2. XML-RPC

XML-RPC es un protocolo de llamada a procedimiento remoto que usa XML para

codificar los datos y HTTP como protocolo de transmisión de mensajes.

Es un protocolo muy simple ya que solo define unos cuantos tipos de datos y
comandos útiles, además de una descripción completa de corta extensión. La
simplicidad del XML-RPC contrasta con la mayoría de protocolos RPC que tiene
una documentación extensa y requiere considerable soporte de software para su
uso.

En XML-RPC siempre se habla en términos de cliente/servidor, existe un sistema

que realiza la solicitud ("el cliente") y otro que la atiende ("el servidor"), y como es
de imaginarse un elemento clave en ambos puntos es: el parser XML, como se
puede observar en la figura 19:

55
 Figura 19: Arquitectura XML-RPC

Fuente: [ (Principios de Web Services, 2006)].

2.4.3.3. REST

Es un estilo de arquitectura de software para sistemas distribuidos tales como la

web, a diferencia de SOAP, se centra en el uso de los estándares HTTP y XML para
la transmisión de datos sin la necesidad de contar con una capa adicional. Las
operaciones(o funciones) se solicitarán mediante GET, POST, PUT y DELETE, por
lo que no requiere de implementaciones especiales para consumir estos servicios.
Además se podrá utilizar JSON en vez de XML como contenedor de la información,
por lo que será aconsejable utilizar este protocolo cuando busquemos mejorar el
rendimiento, o cuando disponemos de escasos recursos, como sería el caso de los
dispositivos móviles.

Cabe destacar que REST no es un estándar, ya que es tan solo un estilo de

arquitectura. Aunque REST no es un estándar, está basado en estándares:

 HTTP
 URL
 Representación de los recursos: XML/HTML/GIF/JPEG/…
 Tipos MIME: text/xml, text/html,

56
Los objetivos de este estilo de arquitectura se listan a continuación:

Escalabilidades la interacción con los componentes. La Web ha crecido

exponencialmente sin degradar su rendimiento. Una prueba de ellos es la variedad
de clientes que pueden acceder a través de la Web: estaciones de trabajo, sistemas
industriales, dispositivos móviles,…

Puesta en funcionamiento independiente. Este hecho es una realidad que debe

tratarse cuando se trabaja en Internet. Los clientes y servidores pueden ser puestas
en funcionamiento durante años. Por tanto, los servidores antiguos deben ser
capaces de entenderse con clientes actuales y viceversa. Diseñar un protocolo que
permita este tipo de características resulta muy complicado.

Compatibilidad con componentes intermedios. Los más populares

intermediaros son varios tipos de proxys para Web. Algunos de ellos, las caches,
se utilizan para mejorar el rendimiento.

2.4.4. WSDL

WSDL (Web Services Description Language) es un protocolo basado en XML que

describe los accesos a servicios web. (Cerami, 2002)

WSDL es el lenguaje propuesto por el W3C para la descripción de Servicios Web y

permite describir la interfaz de un servicio web en un formato XML. Una de sus
ventajas es que permite separar la descripción abstracta de la funcionalidad ofrecida
por un servicio, es decir, de los detalles concretos del mismo, como puede ser el
enlace a un protocolo de red o un formato de mensaje concreto que puede ser
SOAP, HTTP o MIME.

Componentes de un WSDL son (ver figura 20).

57
Elemento Types

El elemento Types contiene información de esquema referenciado en el documento

WSDL.

Elemento message

Puede Aparecer y normalmente aparecerán, múltiples elementos Message en un

documento WSDL, uno para cada mensaje que se comunica entre el cliente y el
servidor.

Elemento PortType

El elemento portType contiene un conjunto de operaciones abstractas que

representan los tipos de correspondencia que pueden producirse entre el cliente y
el servidor.

Un porttype se compone de un conjunto definido de operaciones que determinan

una acción. Los elementos para las operaciones se componen de mensajes
definidos en el documento WSDL. WSDL define cuatro tipos de operaciones
denominadas tipo operaciones:

 Request-response (petición-respuesta) comunicación del tipo RPC en la que

le cliente realiza una petición y el servidor envía la correspondiente
respuesta.
 One-way (un-sentido) Comunicación del estilo documento en la que el cliente
envía un mensaje pero no recibe una respuesta del servidor indicando el
resultado del mensaje procesado.
 Solicit-response (solicitud-respuesta) La contraria a la operación petición-
respuesta. El servidor envía una petición y el cliente le envía de vuelta una
respuesta.
 Notification (Notificación) La contraria a la operación un-sentido el servidor
envía una comunicación del estilo documento al cliente.

58
Elemento Binding

El elemento binding contiene las definiciones de la asociación de un protocolo como

SOAP a un determinado bindingType. Las definiciones binding especifican detalles

de formatos del mensaje y el protocolo.

Elemento Service

Un servicio es un grupo de puertos relacionados y se definen en el elemento service.

Un puerto es un extremo concreto de un Servicio Web al que se hace referencia por

una dirección única. Los puertos que se definen en determinado servicio son
independientes.

Figura 20: Esquema de un WSDL

Fuente: [ (Cerami, 2002)].

2.4.5. UDDI

Son directorios donde es posible publicar los servicios web, lo que permite a los
posibles usuarios obtener información referente a la invocación y ejecución de los
servicios. Los directorios UDDI ofrecen grupos de interfaces que posibilitan la

59
publicación y obtención de los recursos disponibles, cuya información es clasificada
según se desee obtener el servicio.

Tabla 4: Clasificación UDDI según el tipo de obtención de información

Archivos Descripción
Información del negocio Aquí podemos encontrar información sobre quien
publica el servicio
Información de servicio Se refiere a la descripción del tipo de servicio ofrecido
Información de enlace Se entrega la dirección para acceder al servicio

Fuente: (Principios de Web Services, 2006).

Estructura de Datos

Las estructuras de datos conforman un modelo de información que almacena de

forma persistente en el registro todos los elementos necesarios para su
funcionamiento. Estas estructuras de datos se expresan en varios esquemas XML.
Cada estructura de datos tiene un identificador único o UDDI Key.

La estructura que almacena la sección blanca es de tipo bussiness Entity, esta

estructura describe a un proveedor de servicios Web.

Para almacenar la sección amarilla se utiliza la estructura tipo bussiness Service,

que describe una familia de servicios Web ofrecidos por el proveedor descrito en el
bussinness Entity.

La sección verde se almacena entre las estructuras tipo binding Template, que
describen la información técnica de acceso a un servicio Web concreto y las
estructuras tipo tModel, que describen modelos técnicos o metadatos reutilizables
que pueden representar cualquier concepto como el tipo de servicio Web, algún
protocolo usado por los servicios o un sistema de categorización. (OASIS, 2014).

60
BussinessService

La estructura business Service representa un servicio lógico, conteniendo

información descriptiva empresarial del servicio. La información técnica se
encuentra en los bindingTemplate. El businessService tiene dos atributos
opcionales, el identificador del proveedor de servicios, businessKey y el identificador
del servicio, serviceKey, que funciona de forma análoga al bussinessKey en el
proveedor de servicios, en cuanto a su opcionalidad.

BindingTemplate

Contiene las descripciones técnicas de los servicios web. Cada uno describe una
instancia de un servicio web ofrecido normalmente a través de una URL, también
describe el tipo de servicio web ofrecido utilizando modelos técnicos, parámetros de
aplicaciones específicas y diferentes configuraciones. Cada bindingTemplate está
contenido en un businessService y tiene dos atributos opcionales, uno identifica al
servicio (serviceKey) y otro al propio bindingTemplate (bindingKey).

tModel

Se trata de una estructura que permite describir especificaciones, conceptos o

diseños compartidos, proporcionan un sistema de referencia basado en
abstracciones. Se utilizan también como fuente para determinar la compatibilidad
entre servicios y como referencias a espacios de nombres o sistemas de
codificación de cualquier tipo.

PublisherAssertion

La última estructura de datos importante de UDDI es publisherAssertion, que

permite representar y almacenar relaciones entre proveedores de servicio en el
registro UDDI. Deben publicarse por las dos entidades relacionadas.

61
2.5. TECNOLOGÍAS DE DESARROLLO DE APLICACIONES WEB

Los "sistemas Web" o también conocido como "aplicaciones Web" son aquellos que
están creados e instalados no sobre una plataforma o sistemas operativos
(Windows, Linux). Sino que se alojan en un servidor en Internet o sobre una intranet
(red local). Su aspecto es muy similar a páginas Web que vemos normalmente, pero
en realidad los 'sistemas Web' tienen funcionalidades muy potentes que brindan
respuestas a casos particulares, los sistemas Web se pueden utilizar en cualquier
navegador Web (chrome, firefox, Internet Explorer,etc) sin importar el sistema
operativo. Para utilizar las aplicaciones Web no es necesario instalarlas en cada
computadora ya que los usuarios se conectan a un servidor donde se aloja el
sistema.

Las aplicaciones Web trabajan con bases de datos que permiten procesar y mostrar
información de forma dinámica para el usuario.

Los sistemas desarrollados en plataformas Web, tienen marcadas diferencias con

otros tipos de sistemas, lo que lo hacen muy beneficioso tanto para las empresas
que lo utilizan, como para los usuarios que operan en el sistema.

2.5.1. Intranet

Intranets es un sistema privado de información y colaboración que utiliza estándares

y programas de Internet. Podemos considerarla como una red interna diseñada para
ser utilizada dentro del ámbito de una universidad, organización o empresa.

Hasta hace poco, las empresas dependían de sistemas informáticos llamados

«propietarios» para poner sus ordenadores en red, un proceso costoso que
consume mucho tiempo. Al usar las nuevas tecnologías de Internet, las Intranets
resuelven este problema, simplificando la comunicación y colaboración interna.

Una Intranet consiste en organizar la información interna de una organización

utilizando para ello las herramientas que nos brinda Internet. Lo que distingue una
Intranet de la Internet libremente accesible es que las Intranets son privadas.

62
Por tanto, no sería más que una agrupación dentro de una misma web,
especializada y restringida al público en general, de un número determinado de
personas con objetivos comunes y conocimientos y características similares. En
esta web, los/as usuarios/as podrán informarse de todo aquello que pudiera
interesarles respecto a su trabajo o interés común.

Las Intranets están transformando las comunicaciones internas y la concepción del

trabajo, gracias a sus posibilidades de intercambio de información y de cooperación
entre equipos, poniendo en manos del trabajador/a toda la información que necesita
de una manera sencilla y rápida. Tecnológicamente, el punto de partida es el mismo
que el de un sitio Web, lo que difiere claramente es su orientación estratégica. Así
pues, una Intranet está basada en tecnología Web y está orientada a los empleados
de una organización.

Ventajas

 Suministrar acceso a la información reciente.

 Mejorar las comunicaciones de la empresa.
 Mejorar la gestión de recursos humanos
 Proveen eficiencias operacionales y administrativas que ahorran tiempo y
dinero.
 Son fáciles de usar.
 Están basadas en estándares de conexión.

Desventajas

 Riesgos de seguridad.
 Caos potencial, en cuanto al cambio de procesos y sistemas.
 Miedos o paradigmas de los altos directivos.

63
2.5.2. Internet

Podemos definir a Internet como una "red de redes", es decir, una red que no sólo
interconecta computadoras, sino que interconecta redes de computadoras entre sí.

Una red de computadoras es un conjunto de máquinas que se comunican a través

de algún medio (cable coaxial, fibra óptica, radiofrecuencia, líneas telefónicas, etc.)
con el objeto de compartir recursos.

De esta manera, Internet sirve de enlace entre redes más pequeñas y permite
ampliar su cobertura al hacerlas parte de una "red global". Esta red global tiene la
característica de que utiliza un lenguaje común que garantiza la intercomunicación
de los diferentes participantes; este lenguaje común o protocolo (un protocolo es el
lenguaje que utilizan las computadoras al compartir recursos) se conoce como
TCP/IP.

Internet es la "red de redes" que utiliza TCP/IP como su protocolo de comunicación.

Internet es un acrónimo de INTERconectedNETworks (Redes interconectadas).

Para otros, Internet es un acrónimo del inglés INTERnational NET, que traducido al
español sería Red Mundial.

Ventajas

 Hace la comunicación mucho más sencilla.

 Es posible conocer e interactuar con muchas personas de todas partes del
mundo.
 La búsqueda de información se vuelve mucho más sencilla, sin tener que ir
forzadamente a las bibliotecas tradicionales.
 Es posible encontrar muchos puntos de vista diferentes sobre alguna noticia.
 Es posible la creación y descarga de software libre, por sus herramientas
colaborativas.

64
  La computadora se actualiza periódicamente más fácil que si no tuviéramos
internet.
 Es posible encontrar soporte técnico de toda clase sobre alguna herramienta
o proceso.
 El seguimiento de la información a tiempo real es posible a través del Internet.
 Es posible comprar fácilmente a otras tiendas de otros p
 Y es posible compartir muchas cosas personales o conocimientos que a otro
le puede servir, y de esa manera, se vuelve bien provechoso.

Desventajas

 Así como es de fácil encontrar información buena, es posible encontrar de la

misma forma información mala, desagradable (pornografía, violencia
explícita, terrorismo) que puede afectar especialmente a los menores.
 Te genera una gran dependencia o vicio del internet, descuidándote de
muchas cosas personales o laborales.
 Hace que los estudiantes se esfuercen menos en hacer sus tareas, debido a
la mala práctica del copy/paste.
 El principal puente de la piratería es el internet
 Dependencia de procesos. Si hay un corte de internet, hay muchos procesos
que se quedan varados por esa dependencia.
 Dependencia de energía eléctrica. Si hay un corte de energía en la casa,
adiós internet (no es el caso de la telefonía convencional).
 Hace que nazcan otros males tales como el spam, el malware, la proliferación
de los virus, el phising, etc.

2.5.3. Extranet

Es una Intranet "extendida", que permite el acceso no sólo al personal de la

organización sino también a usuarios autorizados que sin pertenecer a ella, se
relacionan a través de procesos o transacciones, como pueden ser clientes,
proveedores, empresas vinculadas, etc.

65
Una Extranet permite a éstos tener acceso limitado a la información que necesitan
de la Intranet de la empresa, con la intención de aumentar la velocidad y la eficiencia
de su relación de negocio. Estos sistemas son el siguiente elemento a incorporar
por las empresas en su transición tecnológica (después de los sitios en Internet y
las intranets), ya que permiten obtener beneficios tangibles de un sitio web. Ya no
se trata únicamente de un sitio informativo que explica la misión, historia e
infraestructura de la empresa, o expone la forma de contactar con ella, lo que
comúnmente se denomina un "sitio institucional" de la empresa, sino de un espacio
en línea donde se pueden incorporar aplicaciones y herramientas tecnológicas para
acelerar los procesos diarios de negocio. Por ejemplo, se pueden crear aplicaciones
para realizar órdenes de compra en forma automatizada, o bien crear reportes de
venta. Además, las Extranet ayudan a disminuir los costos de operación, debido a
que reducen los gastos administrativos, los de telefonía y papel.

Ventajas

 Intercambio de grandes volúmenes de datos.

 Compartir catálogos de productos exclusivamente.
 Colaborar con otras empresas.
 Desarrollar conjuntamente programas de capacitación.
 Proporcionar acceso a los servicios prestados por una empresa a un grupo
de otras empresas.
 Compartir noticias de interés común.

Desventajas

 Pueden ser caros de aplicar y mantener dentro de una organización.

 La seguridad puede ser una gran preocupación cuando se trate de
información valiosa.
 Pueden reducir el contacto personal (cara a cara con los clientes y socios
comerciales.

66
2.5.4. Lenguajes de programación de aplicaciones web

A continuación se han de mencionar los lenguajes candidatos para el desarrollo de

la aplicación web de este proyecto.

2.5.4.1. Java (JSP)

La tecnología JSP (Java Server Pages) es una especificación abierta desarrollada

por SunMicrosystems como una alternativa a Active Server Pages (ASP) de
Microsoft, y son un componente dominante de la especificación de Java 2 Enterprise
Edition (J2EE). Muchos de los servidores de aplicaciones comercialmente
disponibles (como BEA WebLogic, IBM WebSphere, Live JRun, Orion, etcétera) ya
utilizan tecnología JSP.

Esta tecnología permite desarrollar páginas web con contenido dinámico y supone
una evolución frente a la tecnología CGI, y los Servlets. Un fichero JSP puede
contener etiquetas HTML normales, y elementos especiales para generar el
contenido dinámico.

Al mismo tiempo permite una separación en n capas de la arquitectura de la

aplicación web y se integra perfectamente con todas las API's empresariales de
Java: JDBC, RMI (y CORBA), JNDI, EJB, JMS, JTA, etc.

Estructura de una página JSP

Una página JSP es básicamente una página Web con HTML tradicional y código
Java. La extensión de fichero de una página JSP es ".jsp" en vez de ".html" o".htm",
y eso le dice al servidor que esta página requiere un manejo especial que se
conseguirá con una extensión del servidor o un plug-in.

67
Ventajas:

 Ejecución rápida del servlets.

 Crear páginas del lado del servidor.
 Multiplataforma.
 Código bien estructurado.
 Integridad con los módulos de Java.
 La parte dinámica está escrita en Java.
 Permite la utilización se servlets.

Desventajas:

 Complejidad de aprendizaje
 El hosting que precisa son más caros.

2.5.4.2. PHP

Es un lenguaje de programación utilizado para la creación de sitio web. PHP es un

acrónimo recursivo que significa “PHP Hypertext Pre-processor”, (inicialmente se
llamó Personal Home Page). Surgió en 1995, desarrollado por PHP Group.

PHP es un lenguaje de script interpretado en el lado del servidor utilizado para la

generación de páginas web dinámicas, embebidas en páginas HTML y ejecutadas
en el servidor. PHP no necesita ser compilado para ejecutarse. Para su
funcionamiento necesita tener instalado Apache o IIS con las librerías de PHP. La
mayor parte de su sintaxis ha sido tomada de C, Java y Perl con algunas
características específicas. Los archivos cuentan con la extensión (.php).

68
Ventajas:

 Muy fácil de aprender.

 Se caracteriza por ser un lenguaje muy rápido.
 Soporta en cierta medida la orientación a objeto. Clases y herencia.
 Es un lenguaje multiplataforma: Linux, Windows, entre otros.
 Capacidad de conexión con la mayoría de los manejadores de base de datos:
MysSQL, PostgreSQL, Oracle, MS SQL Server, entre otras.
 Capacidad de expandir su potencial utilizando módulos.
 Posee documentación en su página oficial la cual incluye descripción y
ejemplos de cada una de sus funciones.
 Es libre, por lo que se presenta como una alternativa de fácil acceso para
todos.
 Incluye gran cantidad de funciones.
 No requiere definición de tipos de variables ni manejo detallado del bajo nivel.

Desventajas:

 Se necesita instalar un servidor web.

 Todo el trabajo lo realiza el servidor y no delega al cliente. Por tanto puede
ser más ineficiente a medida que las solicitudes aumenten de número.
 La legibilidad del código puede verse afectada al mezclar sentencias HTML
y PHP.
 La programación orientada a objetos es aún muy deficiente para aplicaciones
grandes.
 Dificulta la modularización.
 Dificulta la organización por capas de la aplicación.

Seguridad:

PHP es un poderoso lenguaje e intérprete, ya sea incluido como parte de un servidor

web en forma de módulo o ejecutado como un binario CGI separado, es capaz de

69
acceder a archivos, ejecutar comandos y abrir conexiones de red en el servidor.
Estas propiedades hacen que cualquier cosa que sea ejecutada en un servidor web
sea insegura por naturaleza.

PHP está diseñado específicamente para ser un lenguaje más seguro para escribir
programas CGI que Perl o C, y con la selección correcta de opciones de
configuración en tiempos de compilación y ejecución, y siguiendo algunas prácticas
correctas de programación.

2.5.4.3. ASP.NET

Este es un lenguaje comercializado por Microsoft, y usado por programadores para

desarrollar entre otras funciones, sitios web. ASP.NET es el sucesor de la tecnología
ASP, fue lanzada al mercado mediante una estrategia de mercado denominada
.NET.

El ASP.NET fue desarrollado para resolver las limitantes que brindaba tu antecesor
ASP. Creado para desarrollar web sencillas o grandes aplicaciones. Para el
desarrollo de ASP.NET se puede utilizar C#, VB.NET o J#. Los archivos cuentan
con la extensión (aspx). Para su funcionamiento de las páginas se necesita tener
instalado IIS con el Framework .Net. Microsft Windows 2003 incluye este framework,
solo se necesitará instalarlo en versiones anteriores.

Ventajas:

 Completamente orientado a objetos.

 Controles de usuario y personalizados.
 División entre la capa de aplicación o diseño y el código.
 Facilita el mantenimiento de grandes aplicaciones.
 Incremento de velocidad de respuesta del servidor.
 Mayor velocidad.
 Mayor seguridad.

70
Desventajas:

 Mayor consumo de recursos.

2.5.5. Arquitecturas de desarrollo de software

2.5.5.1. Arquitectura Cliente-Servidor

Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro

programa (el servidor) que le da respuesta. Aunque esta idea se puede aplicar a
programas que se ejecutan sobre una sola computadora es más ventajosa en un
sistema operativo multiusuario distribuido a través de una red de computadoras. La
interacción cliente-servidor es el soporte de la mayor parte de la comunicación por
redes. Ayuda a comprender las bases sobre las que están construidos los
algoritmos distribuidos, ver figura 21.

Partes que componen el sistema:

 Cliente: Programa ejecutable que participa activamente en el establecimiento

de las conexiones. Envía una petición al servidor y se queda esperando por
una respuesta. Su tiempo de vida es finito una vez que son servidas sus
solicitudes, termina el trabajo.
 Servidor: Es un programa que ofrece un servicio que se puede obtener en
una red. Acepta la petición desde la red, realiza el servicio y devuelve el
resultado al solicitante. Al ser posible implantarlo como aplicaciones de
programas, puede ejecutarse en cualquier sistema donde exista TCP/IP y
junto con otros programas de aplicación. El servidor comienza su ejecución
antes de comenzar la interacción con el cliente. Su tiempo de vida o de
interacción es “interminable”.

Los servidores pueden ejecutar tareas sencillas (caso del servidor hora día que
devuelve una respuesta) o complejas (caso del servidor ftp en el cual se deben
realizar operaciones antes de devolver una respuesta). Los servidores sencillos

71
procesan una petición a la vez (son secuenciales o interactivos), por lo que no
revisan si ha llegado otra petición antes de enviar la respuesta de la anterior.

Los más complejos trabajan con peticiones concurrentes aun cuando una sola
petición lleve mucho tiempo para ser servida (caso del servidor ftp que debe copiar
un archivo en otra máquina). Son complejos pues tienen altos requerimientos de
protección y autorización. Pueden leer archivos del sistema, mantenerse en línea y
acceder a datos protegidos y a archivos de usuarios. No puede cumplir a ciegas las
peticiones de los clientes, deben reforzar el acceso al sistema y las políticas de
protección. Los servidores por lo general tienen dos partes:

 Programa o proceso que es responsable de aceptar nuevas peticiones:

Maestro o Padre.
 Programas o procesos que deben manejar las peticiones individuales:
Esclavos o Hijos.

Tareas del programa maestro

 Abrir un puerto local bien conocido al cual puedan acceder los clientes.
 Esperar las peticiones de los clientes.
 Elegir un puerto local para las peticiones que llegan en informar al cliente del
nuevo puerto, (innecesario en la mayoría de los casos).
 Iniciar un programa esclavo o proceso hijo que atienda la petición en el puerto
local, (el esclavo cuando termina de manejar una petición no se queda
esperando por otras).
 Volver a la espera de peticiones mientras los esclavos, en forma concurrente,
se ocupan de las anteriores peticiones.

Ventajas:

La posibilidad de utilizar máquinas mucho más baratas que las requeridas por una
solución centralizada, basada en sistemas grandes (mainframes). Además, se
pueden utilizar componentes, tanto de hardware como de software, de varios

72
fabricantes, lo cual contribuye considerablemente a la reducción de costos y
favorece la flexibilidad en la implantación y actualización de soluciones.

 Facilita la integración entre sistemas diferentes y comparte información,

permitiendo por ejemplo que las máquinas ya existentes puedan ser
utilizadas pero utilizando interfaces más amigables el usuario. De esta
manera, se puede integrar PCs con sistemas medianos y grandes, sin
necesidad de que todos tengan que utilizar el mismo sistema operativo.
 Al favorecer el uso de interfaces gráficas interactivas, los sistemas
construidos bajo este esquema tienen una mayor y más intuitiva con el
usuario. En el uso de interfaces gráficas para el usuario, presenta la ventaja,
con respecto a uno centralizado, de que no siempre es necesario transmitir
información gráfica por la red pues esta puede residir en el cliente, lo cual
permite aprovechar mejor el ancho de banda de la red.
 La estructura inherentemente modular facilita además la integración de
nuevas tecnologías y el crecimiento de la infraestructura computacional,
favoreciendo así la escalabilidad de las soluciones.
 Contribuye además a proporcionar a los diferentes departamentos de una
organización, soluciones locales, pero permitiendo la integración de la
información.

Desventajas:

 El mantenimiento de los sistemas es más difícil pues implica la interacción

de diferentes partes de hardware y de software, distribuidas por distintos
proveedores, lo cual dificulta el diagnóstico de fallas.
 Cuenta con muy escasas herramientas para la administración y ajuste del
desempeño de los sistemas.
 Es importante que los clientes y los servidores utilicen el mismo mecanismo
(por ejemplo sockets o RPC), lo cual implica que se deben tener mecanismos
generales que existan en diferentes plataformas.

73
  Hay que tener estrategias para el manejo de errores y para mantener la
consistencia de los datos.
 El desempeño (performance), problemas de este estilo pueden presentarse
por congestión en la red, dificultad de tráfico de datos, etc.

Figura 21: Cliente-Servidor

Fuente: (Ableson, 2013).

2.5.5.2. Arquitectura de tres niveles

También conocida como arquitectura de tres capas, la arquitectura de tres capas,

define cómo organizar el modelo de diseño en capas, que pueden estar físicamente
distribuidas, lo cual quiere decir que los componentes de una capa sólo pueden
hacer referencia a componentes en capas inmediatamente inferiores. Este patrón
es importante porque simplifica la comprensión y la organización del desarrollo de
sistemas complejos, reduciendo las dependencias de forma que las capas más
bajas no son conscientes de ningún detalle o interfaz de las superiores. Además,
nos ayuda a identificar qué puede reutilizarse, y proporciona una estructura que nos
ayuda a tomar decisiones sobre qué partes comprar y qué partes construir.

Para enfrentarse a estos temas, la comunidad de software desarrolló la noción de

una arquitectura de tres niveles. La aplicación se divide en tres capas lógicas
distintas, cada una de ellas con un grupo de interfaces perfectamente definido. La

74
primera capa se denomina capa de presentación y normalmente consiste en una
interfaz gráfica de usuario de algún tipo.

La capa intermedia, o capa de empresa, consiste en la aplicación o lógica de

empresa, y la tercera capa, la capa de datos, contiene los datos necesarios para la
aplicación. La capa intermedia (lógica de aplicación) es básicamente el código al
que recurre la capa de presentación para recuperar los datos deseados. La capa de
presentación recibe entonces los datos y los formatea para su presentación.

Esta separación entre la lógica de aplicación de la interfaz de usuario añade una

enorme flexibilidad al diseño de la aplicación. Pueden construirse y desplegarse
múltiples interfaces de usuario sin cambiar en absoluto la lógica de aplicación
siempre que está presente una interfaz claramente definida a la capa de
presentación, ver figura 22.

Capa de presentación

Es la que se encarga de que el sistema interactúe con el usuario y viceversa,

muestra el sistema al usuario, le presenta la información y obtiene la información
del usuario en un mínimo de proceso. En el mundo de la informática es conocida
como interfaz gráfica y debe tener la característica de ser amigable, o sea,
entendible y fácil de usar para el usuario. Esta capa se comunica únicamente con
la capa intermedia o de negocio.

Capa de negocio

Es donde residen las funciones que se ejecutan, se reciben las peticiones del
usuario, se procesa la información y se envían las respuestas tras el proceso. Se
denomina capa de negocio o capa de lógica del negocio, porque es aquí donde se
establecen todas las reglas que deben cumplirse. Esta capa se comunica con la de
presentación, para recibir las solicitudes y presentar los resultados, y con la capa
de acceso a datos, para solicitar al gestor de base de datos almacenar o recuperar
datos de él.

75
Capa de acceso a datos

Esta capa es la encargada de almacenar los datos del sistema y de los usuarios.
Su función es almacenar y devolver datos a la capa de negocio, aunque para esto
también es necesario en algunos casos, que tengan procedimientos almacenados
y funciones dentro de la capa. En una arquitectura de tres capas, esta capa es la
única que puede acceder a los mismos. Está formada por uno o varios sistemas
gestores de bases de datos, localizados en un mismo servidor o en varios.

Estas capas, pueden estar localizadas todas en un mismo ordenador, si el programa

o software informático que se desarrolla es de baja complejidad, porque si, por el
contrario, fuera de gran complejidad tanto los datos como la lógica de negocio,
entonces cada una de las capas pudiera estar situada en diferentes ordenadores,
para mejorar la funcionalidad de las mismas, incluso, en productos de gran
complejidad, existen varios ordenadores para la capa de acceso a datos, y varios
ordenadores para la capa de negocio.

Figura 22: Arquitectura de 3 niveles

Fuente: (Ableson, 2013).

76
2.5.5.3. Modelo Vista Controlador

Modelo Vista Controlador (MVC). Es un estilo de arquitectura de software que

separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en
tres componentes distintos. El estilo de llamada y retorno MVC, se ve
frecuentemente en aplicaciones web, donde la vista es la página HTML y el código
que provee de datos dinámicos a la página. El modelo es el Sistema de Gestión de
Base de Datos y la Lógica de negocio, y el controlador es el responsable de recibir
los eventos de entrada desde la vista.

El Modelo es el objeto que representa los datos del programa. Maneja los datos y
controla todas sus transformaciones. El Modelo no tiene conocimiento específico de
los Controladores o de las Vistas, ni siquiera contiene referencias a ellos. Es el
propio sistema el que tiene encomendada la responsabilidad de mantener enlaces
entre el Modelo y sus Vistas, y notificar a las Vistas cuando cambia el Modelo.

La Vista es el objeto que maneja la presentación visual de los datos representados

por el Modelo. Genera una representación visual del Modelo y muestra los datos al
usuario. Interactúa con el Modelo a través de una referencia al propio Modelo.

El Controlador es el objeto que proporciona significado a las órdenes del usuario,

actuando sobre los datos representados por el Modelo. Cuando se realiza algún
cambio, entra en acción, bien sea por cambios en la información del Modelo o por
alteraciones de la Vista. Interactúa con el Modelo a través de una referencia al
propio Modelo, ver figura 23.

Ventajas:

Una separación total entre lógica de negocio y presentación. A esto se le pueden

aplicar opciones como el multilenguaje, distintos diseños de presentación, etc. sin
alterar la lógica de negocio. La separación de capas como presentación, lógica de
negocio, acceso a datos es fundamental para el desarrollo de arquitecturas

77
consistentes, reutilizables y más fácilmente mantenibles, lo que al final resulta en
un ahorro de tiempo en desarrollo en posteriores proyectos.

Al existir la separación de vistas, controladores y modelos es más sencillo realizar

labores de mejora como:

 Agregar nuevas vistas.

 Agregar nuevas formas de recolectar las órdenes del usuario (interpretar sus
modelos mentales).
 Modificar los objetos de negocios bien sea para mejorar el performance o
para migrar a otra tecnología.
 Las labores de mantenimiento también se simplifican y se reduce el tiempo
necesario para ellas. Las correcciones solo se deben hacer en un solo lugar
y no en varios como sucedería si tuviésemos una mezcla de presentación e
implementación de la lógica del negocio.
 Las vistas también son susceptibles de modificación sin necesidad de
provocar que todo el sistema se paralice. Adicionalmente el patrón MVC
propende a la especialización de cada rol del equipo, por tanto en cada
liberación de una nueva versión se verán los resultados.

Desventajas:

 La separación de conceptos en capas agrega complejidad al sistema.

 La cantidad de archivos a mantener y desarrollar se incrementa
considerablemente.
 La curva de aprendizaje del patrón de diseño es más alta usando otros
modelos más sencillos.

78
 Figura 23: Esquema MVC

Fuente: [Elaboración Propia].

2.5.6. Frameworks

Un framework para aplicaciones web es un framework diseñado para apoyar el

desarrollo de sitios web dinámicos, aplicaciones web y servicios web. Este tipo de
frameworks intenta aliviar el exceso de carga asociado con actividades comunes
usadas en desarrollos web. Por ejemplo, muchos framework proporcionan
bibliotecas para acceder a bases de datos, estructuras para plantillas y gestión de
sesiones, y con frecuencia facilitan la reutilización de código.

A Continuación se nombraran tres Frameworks candidatos para el desarrollo de

este proyecto.

2.5.6.1. Laravel

Laravel es un framework de código abierto para desarrollar aplicaciones y servicios

web con PHP 5. Su filosofía es desarrollar código PHP de forma elegante y simple,

79
evitando el "código espagueti". Fue creado en 2011 y tiene una gran influencia de
frameworks como Ruby onRails, Sinatra y ASP.NET MVC. Laravel propone en el
desarrollo usar 'Routes with Closures', en lugar de un MVC tradicional con el objetivo
de hacer el código más claro. Aun así tiene integrado el uso de MVC tradicional.

Características

 Sistema de ruteo, también RESTful

 Blade, Motor de plantillas
 Peticiones Fluent
 Eloquent ORM
 Basado en Composer
 Soporte para el caché
 Soporte para MVC
 Usa componentes de Symfony

Laravel 'entrega la opción' de seguir usando la metodología tradicional MVC. Sin

embargo, el framework propone una vía más rápida en PHP, la cual consiste en
programar la interacción HTTP directamente como una función anónima asociada
a una Ruta.

Laravel incluye una valiosa pieza de software, llamada Eloquent ORM. Este ORM
se funda en patrón active record y su funcionamiento es en extremo sencillo.

Un ORM (ObjectRelationalMapper) en PHP es un software que permite tratar la

capa de persistencia de los datos, como simples accesos a métodos de una Clase
u Objeto en PHP.

La funcionalidad interna del ORM es mapear los objetos de PHP a las tablas en la
base de datos, para el caso en que la persistencia de los datos de la aplicación es
proporcionada por una DB.

80
En Laravel es opcional el uso de Eloquent, pues también dispone de otros recursos
que nos facilitan interactuar con los datos, o específicamente la creación de
modelos.

Laravel incluye de paquete un sistema de procesamiento de plantillas llamado

Blade. Este sistema de plantillas, Blade favorece un código mucho más limpio en
las Vistas, además de incluir un sistema de Caché que lo hace mucho más rápido.

Los Sistemas de Cache, evitan el tener que procesar el código una y otro vez en
cada petición. Para lo cual, estos sistemas generan versiones estáticas en memoria
o disco duro con archivos que corresponden a peticiones previamente procesadas.
Y con esta técnica se logra mejorar el rendimiento de la aplicación.

Ventajas

 Capacidad de asociar una ruta a un controlador y una vista.

 La creación de RestfulAPIs es más sencilla.
 Cuenta con un ORM tan practico que se basa en un patrón ActiveRecod.

Desventajas

 Excesiva cantidad de clases y métodos estáticos.

2.5.6.2. Phalcon

Phalcon es un framework web implementado como una extensión C que ofrece un

alto rendimiento y consume menos recursos.

No se necesita aprender o usar C, toda su funcionalidad está expuesta como clases

PHP listas para usar. Phalcon está también débilmente acoplado permitiendo usar
clases como componentes de acuerdo a como la aplicación lo requiera.

81
¿Cómo trabaja una extensión C en PHP?

Las extensiones en C se cargan una vez junto con PHP al iniciar el servicio/demonio
de PHP

Las clases y funciones proporcionadas por la extensión están listas para ser usadas
por cualquier aplicación

El código no es interpretado porque ya está compilado para una plataforma y

procesador específicos

Ventajas

 Los componentes están libremente acoplados. Con Phalcon, nada está

impuesto: tienes la libertad de usar todo el framework, o solo las partes que
necesites
 Optimizaciones de bajo nivel ayudan a reducir la sobrecarga requerida para
correr aplicaciones MVC
 Las operaciones con base de datos se efectúan con la máxima eficiencia al
usar un ORM para PHP escrito en C
 Phalcon accede directamente a las estructuras internas de PHP optimizando
además cada ejecución

Desventajas

 Hay que “instalar” el framework en el servidor web, y esto puede ser un gran
freno a la hora de desplegar la aplicación.
 A la hora de utilizar el framework en tu proyecto, debes crear de forma manual
el archivo que carga los componentes de Phalcon (un archivo de
inicialización del framework, boostrap).

82
2.5.6.3. Codeigniter

CodeIgniter es un framework para aplicaciones web de código abierto para crear

sitios web dinámicos con PHP. Su objetivo es permitir que los desarrolladores
puedan realizar proyectos mucho más rápido que creando toda la estructura desde
cero, brindando un conjunto de bibliotecas para tareas comunes, así como una
interfaz simple y una estructura lógica para acceder esas bibliotecas.

También hay que destacar que CodeIgniter es más rápido que muchos otros
entornos. Incluso en una discusión sobre entornos de desarrollo con PHP,
RasmusLerdorf, el creador de PHP, expresó que le gustaba CodeIgniterporque es
rápido, ligero y parece poco un entorno.

Ventajas

 Es muy liviano. La última versión, la 1.7.2 apenas supera 1Mb.

 Ofrece un gran rendimiento.
 Ofrece compatibilidad con varias versiones de PHP. Concretamente desde
la 4.3.2 a la 5.3.0
 Apenas requiere configuración.
 No requiere de línea de comandos para generar las aplicaciones.
 No sigue una línea de reglas estricta. Podemos adaptarlo a nuestras
necesidades.
 No es una gran librería al estilo PEAR.
 No requiere aprender un lenguaje de platillas. Es opcional.
 Genera SEO urls para los buscadores.
 Tiene una documentación clarísima.

83
Desventajas

 Pertenece a una empresa. La cual puede decidir un día dejar de actualizarlo,

dar soporte o hacerlo de pago.
 La compatibilidad con tantas versiones de PHP hace que no podamos hablar
de un framework completamente Orientado a Objetos.

No trabaja con módulos por lo que separar la aplicación en éstos requiere de

plugins, modificación de la estructura básica o ser muy ordenados.

2.6. TECNOLOGÍAS MÓVILES DE DESARROLLO

En los últimos años los teléfonos móviles han experimentado una gran evolución,
desde los primeros terminales, grandes y pesados, pensados sólo para hablar por
teléfono en cualquier parte, a los últimos modelos, con los que el término “medio de
comunicación” se queda bastante pequeño.

Es así como nace Android. Android es un sistema operativo y una plataforma

software, basado en Linux para teléfonos móviles. Además, también usan este
sistema operativo (aunque no es muy habitual), tablets, netbooks, reproductores de
música e incluso PC’s. Android permite programar en un entorno de trabajo
(framework) de Java, aplicaciones sobre una máquina virtual Dalvik (una variación
de la máquina de Java con compilación en tiempo de ejecución). Además, lo que le
diferencia de otros sistemas operativos, es que cualquier persona que sepa
programar puede crear nuevas aplicaciones, widgets, o incluso, modificar el propio
sistema operativo, dado que Android es de código libre, por lo que sabiendo
programar en lenguaje Java, va a ser muy fácil comenzar a programar en esta
plataforma.

Fue desarrollado por Android Inc., empresa que en 2005 fue comprada por Google,
aunque no fue hasta 2008 cuando se popularizó, gracias a la unión al proyecto de
Open Handset Alliance, un consorcio formado por 48 empresas de desarrollo
hardware, software y telecomunicaciones, que decidieron promocionar el software

84
libre. Pero ha sido Google quien ha publicado la mayor parte del código fuente del
sistema operativo, gracias al software Apache, que es una fundación que da soporte
a proyectos software de código abierto.

Dado que Android está basado en el núcleo de Linux, tiene acceso a sus recursos,
pudiendo gestionarlo, gracias a que se encuentra en una capa por encima del
Kernel, accediendo así a recursos como los controladores de pantalla, cámara,
memoria flash…

En la Figura 24, abajo, se muestran las capas que conforman el sistema operativo
Android:

Figura 24: Estructura Móvil Android

Fuente: (Ableson, 2013).

Dentro del desarrollo de aplicaciones móviles, existen tres tipos de aplicaciones que
son: Nativas, Webs e Hibridas.

85
Nativas

Una app nativa, en principio (y solo en principio), es una aplicación que se desarrolla
directamente en el lenguaje nativo de cada terminal. Por eso, si vamos desarrollar
una App nativa tendremos que utilizar un lenguaje diferente para cada Sistema
Operativo. Los lenguajes de programación serán por tanto los siguientes:

 iOS: Objective C
 Android: Java
 Windows: C# y Visual Basic .NET.
 BlackBerry 10: C++

Obviamente todo depende del nivel y experiencia del equipo de desarrollo y de que
el código resultante de su trabajo sea el correcto, pero en principio, una App nativa
es la opción cuyo resultado es el más robusto y fluido ya que se desarrolla
directamente para integrarse en el Sistema Operativo. Si tu App surge de una buena
idea y un diseño bien trabajado a todos los niveles, la experiencia de usuario será
completa ya que su funcionamiento, rendimiento y respuesta será el más inmediato
de todas las opciones de desarrollo incluso en los diseños más complejos y
personalizados.

Híbridas

Generalmente consisten en Apps que contiene en su interior el navegador web del

dispositivo. Para su desarrollo se utilizan frameworks de desarrollo basados en
lenguajes de programación web (HTML, CSS y JS). Actualmente Phonegap es el
más conocido (aunque no el único) y el que concentra mayor número de
desarrolladores a su alrededor.

En este tipo de Apps el nivel de integración con el SO dependerá del framework de

desarrollo utilizado y como de abierto sea el SO (BlackBerry 10 es todo un ejemplo),
teniendo cada uno de ellos sus ventajas e inconvenientes. Actualmente con esta
opción tendrás bastante acceso al hardware del teléfono e incluso en algunos casos

86
a las librerías del SO, pero lo cierto es que aunque de momento no se ha conseguido
igualar la respuesta y la experiencia de usuario de una App nativa, hay que
reconocer que va camino de hacerlo.

De todas maneras, la cosa ha ido evolucionando a desarrollos más complejos en

los que ciertas funcionalidades se ejecutan como una web y otras en nativo, como
por ejemplo Instagram que utiliza nativo para hacer y publicar la fotografía, pero web
para desplegar las fotografías y perfil.

Su uso es una opción muy económica y muy interesante para llegar al mayor
número de usuarios repartidos en las diferentes plataformas y dispositivos aunque
por el momento sus limitaciones son claras.

Aplicaciones Web

Aplicación Web o Web App es precisamente eso, una web a la que se accede a
través de una URL en el navegador del dispositivo (Safari, Chrome o el que sea) y
se adapta al formato de tu pantalla para que tenga aspecto de navegación App. Los
navegadores de los móviles permiten crear un acceso directo en nuestro escritorio
de esta web, así que esa será la manera de “instalarla” (si se le puede llamar así)
en nuestro dispositivo.

En función de cómo sea nuestro proyecto tecnológico quizá solo nos interese
adaptar nuestra web a formato móvil con lo que hacer una Web App se convierte en
una solución estupenda. O quizá consideremos necesario que además de tener
nuestra App en las diferentes tiendas, tener una versión web a la que se acceda
desde un navegador, en ese caso es importante que tengas en cuenta que muchos
de los diferentes frameworks de desarrollo híbridos que existen (y también
TitaniumAppcelerator) te permitirán un desarrollo multiplataforma completo que
incluirá también la web.

87
A nivel de lenguajes de programación pues efectivamente es lo que estás
suponiendo: al ser una web deberás usar lenguajes de programación web (HTML,
CSS y Javascript).

2.6.1. Lenguajes de Programación para aplicaciones móviles

A continuación se hará mención de los lenguajes candidatos para la elaboración de

la aplicación móvil de este proyecto:

2.6.1.1. Visual Basic .NET

Visual Basic .NET (VB.NET) es un lenguaje de programación orientado a objetos

que se puede considerar una evolución de Visual Basic implementada sobre el
framework .NET. Su introducción resultó muy controvertida, ya que debido a
cambios significativos en el lenguaje VB.NET no es retro compatible con Visual
Basic, pero el manejo de las instrucciones es similar a versiones anteriores de Visual
Basic, facilitando así el desarrollo de aplicaciones más avanzadas con herramientas
modernas. Para mantener eficacia en el desarrollo de las aplicaciones. La gran
mayoría de programadores de VB.NET utilizan el entorno de desarrollo integrado
Microsoft Visual Studio en alguna de sus versiones (desde el primer Visual Studio
.NET hasta Visual Studio .NET 2013, que es la última versión de Visual Studio para
la plataforma .NET), aunque existen otras alternativas, como SharpDevelop (que
además es libre) (Microsoft Corporation, 2006).

Al igual que con todos los lenguajes de programación basados en .NET, los
programas escritos en VB .NET requieren el Framework .NET o Mono para
ejecutarse.

Ventajas (Microsoft Corporation, 2006):

 Posee una curva de aprendizaje muy rápida.

 Integra el diseño e implementación de formularios de Windows.

88
  Permite usar con facilidad la plataforma de los sistemas Windows, dado que
tiene acceso prácticamente total a la API de Windows, incluidas librerías
actuales.
 Es uno de los lenguajes de uso más extendido, por lo que resulta fácil
encontrar información, documentación y fuentes para los proyectos.
 Fácilmente extensible mediante librerías DLL y componentes ActiveX de
otros lenguajes.
 Posibilita añadir soporte para ejecución de scripts, VBScript o JScript, en las
aplicaciones mediante Microsoft Script Control.
 Tiene acceso a la API multimedia de DirectX (versiones 7 y 8). También está
disponible, de forma no oficial, un componente para trabajar con OpenGL.
 Existe una versión, VBA, integrada en las aplicaciones de Microsoft Office,
tanto Windows como Mac, que permite programar macros para extender y
automatizar funcionalidades en documentos, hojas de cálculo, bases de
datos (access).
 Si bien permite desarrollar grandes y complejas aplicaciones, también provee
un entorno adecuado para realizar pequeños prototipos rápidos.

Desventajas (Ableson, 2013):

 Problema de versionado asociado con varias librerías runtimeDLL´s,

conocido como DLL Hell.
 Pobre soporte para programación orientada a objetos.
 Incapacidad para crear aplicaciones multihilo, sin tener que recurrir a
llamadas de la API de Windows.
 Dependencia de complejas y frágiles entradas de registro COM.

2.6.1.2. Java

Java es un lenguaje de programación y una plataforma informática comercializada

por primera vez en 1995 por Sun Microsystems. Hay muchas aplicaciones y sitios
web que no funcionarán a menos que tenga Java instalado y cada día se crean más.

89
Java es rápido, seguro y fiable. Desde portátiles hasta centros de datos, desde
consolas para juegos hasta súper computadoras, desde teléfonos móviles hasta
Internet, Java está en todas partes.

Java presenta las siguientes características (Oracle, 2014):

Lenguaje simple

Java posee una curva de aprendizaje muy rápida. Resulta relativamente sencillo
escribir applets interesantes desde el principio. Todos aquellos familiarizados con
C++ encontrarán que Java es más sencillo, ya que se han eliminado ciertas
características, como los punteros. Debido a su semejanza con C y C++, y dado
que la mayoría de la gente los conoce aunque sea de forma elemental, resulta muy
fácil aprender Java. Los programadores experimentados en C++ pueden migrar
muy rápidamente a Java y ser productivos en poco tiempo.

Orientado a objetos

Java fue diseñado como un lenguaje orientado a objetos desde el principio. Los
objetos agrupan en estructuras encapsuladas tanto sus datos como los métodos (o
funciones) que manipulan esos datos. La tendencia del futuro, a la que Java se
suma, apunta hacia la programación orientada a objetos, especialmente en
entornos cada vez más complejos y basados en red.

Distribuido

Java proporciona una colección de clases para su uso en aplicaciones de red, que
permiten abrir sockets y establecer y aceptar conexiones con servidores o clientes
remotos, facilitando así la creación de aplicaciones distribuidas interpretado y
compilado a la vez

Java es compilado, en la medida en que su código fuente se transforma en una

especie de código máquina, los bytecodes, semejantes a las instrucciones de
ensamblador. Por otra parte, es interpretado, ya que los bytecodes se pueden

90
ejecutar directamente sobre cualquier máquina a la cual se hayan portado el
intérprete y el sistema de ejecución entiempo real (run-time).

Robusto

Java fue diseñado para crear software altamente fiable. Para ello proporciona
numerosas comprobaciones en compilación y en tiempo de ejecución. Sus
características de memoria liberan a los programadores de una familia entera de
errores (la aritmética de punteros), ya que se ha prescindido por completo los
punteros, y la recolección de basura elimina la necesidad de liberación explícita de
memoria.

Ventajas:

 El JDK es una herramienta libre de licencias (sin costo), creada por Sun.-
Está respaldado por un gran número de proveedores.
 Existe soporte dado por Sun.
 Debido a que existen diferentes productos de Java, hay más de un proveedor
de servicios.
 Sun saca al mercado cada 6 meses una nueva versión del JDK.
 Es independiente de la plataforma de desarrollo.
 Existen dentro de su librería clases gráficas como awt y swing, las cuales
permiten crear objetos gráficos comunes altamente configurables y con una
arquitectura independiente de la plataforma.
 Java permite a los desarrolladores aprovechar la flexibilidad de la
Programación Orientada a Objetos en el diseño de sus aplicaciones.
 El conocimiento sobre tecnología Java está en alto crecimiento en el
mercado.
 Se puede acceder a bases de datos fácilmente con JDBC,
independientemente de la plataforma utilizada. O El manejo de las bases de
datos es uniforme, es decir transparente y simple.

91
  Existen las herramientas CrystalReports o herramientas libres como iText
que los genera en formato pdf.o La API que utilizan estas herramientas en
Java, es la más recomendable para generar reportes en Web.

Desventajas:

 Hay diferentes tipos de soporte técnico para la misma herramienta, por lo que
el análisis de la mejor opción se dificulta.
 Para manejo a bajo nivel deben usarse métodos nativos, lo que limita la
portabilidad.
 El diseño de interfaces gráficas con awt y swing no es simple. O Existen
herramientas como el JBuilder que permiten generar interfaces gráficas de
manera sencilla, pero tienen un costo adicional.
 Puede ser que no haya JDBC para bases de datos poco comerciales.

Algunas herramientas tienen un costo adicional.

2.7. PRUEBAS DE SOFTWARE

A continuación se hará mención y especificación de las pruebas candidatas de

software.

2.7.1. Pruebas de integración

La prueba de integración es una técnica sistemática para construir la estructura del

programa mientras al mismo tiempo, se lleva a cabo pruebas para detectar errores
asociados con la interacción. El objetivo es tomar los módulos probados en unidad
y estructurar un programa que esté de acuerdo con el que dicta el diseño. La
integración puede ser descendente si se integran los módulos desde el control o
programa principal, o bien, ascendente, si la verificación del diseño empieza desde
los módulos más bajos y de allí al principal. La selección de una estrategia de
integración depende de las características depende de las características del

92
software y, a veces, del plan del proyecto, en algunos de los casos se puede
combinar ambas estrategias.

2.7.2. Pruebas de validación y verificación

Al conjunto de actividades que aseguran que el software implementa correctamente

una función específica se denomina verificación. La validación se refiere a un
conjunto de actividades que aseguran que el software construido se ajusta a los
requerimientos y necesidades del cliente.

La definición de verificación validación envuelve lo que se conoce como calidad del

software. Las revisiones técnicas formales ayudan (inspección) ayudan a asegurar
la calidad de los productos, a lo largo del proceso la medición y l control se aplica
sobre cada elemento de una construcción del software. La prueba construye un
elemento importante desde el que se puede evaluar la calidad y, de forma más
práctica, de cubrir los errores.

Una vez que se culminó la etapa de integración se puede decir que el software está
completamente ensamblado, se ha encontrado y corregido errores de la interfaces
y se puede comenzar una serie final de prueba del software. La prueba de validación
se logra cuando la expectativas razonable del cliente se cumplen en donde incluye
la especificación de requisitos, documentos en donde se describen los atributos del
software que son visibles para el usuarios, esta información forma la base del
enfoque a la prueba de validación.

Cuando se construye el software para llevar a cabo de validación es casi imposible

que el desarrollador pueda prever como un cliente usara realmente el programa es
por ello se hace una serie de prueba de aceptación que puede permitir que un cliente
valide todos los requisitos, se puede dar el caso de las pruebas alfa y beta.

2.7.3. Pruebas de regresión

Se denominan pruebas de regresión a cualquier tipo de pruebas de software que

intentan descubrir errores (bugs), carencias de funcionalidad, o divergencias

93
funcionales con respecto al comportamiento esperado del software, causados por
la realización de un cambio en el programa.

Este tipo de cambio puede ser debido a prácticas no adecuadas de control de

versiones, falta de consideración acerca del ámbito o contexto de producción final y
extensibilidad del error que fue corregido (fragilidad de la corrección), o simplemente
una consecuencia del rediseño de la aplicación.

Por lo tanto, en la mayoría de las situaciones del desarrollo de software se considera

una buena práctica que cuando se localiza y corrige un bug, se grabe una prueba
que exponga el bug y se vuelvan a probar regularmente después de los cambios
subsiguientes que experimente el programa.

Existen herramientas de software que permiten detectar este tipo de errores de

manera parcial o totalmente automatizada, la práctica habitual en programación
extrema es que este tipo de pruebas se ejecuten en cada uno de los pasos del ciclo
de vida del desarrollo del software.

94
3. MARCO PRÁCTICO
3.1. ANÁLISIS DE LOS PROCESOS DE LA GESTIÓN ACADÉMICA
DE CALIFICACIONES Y DISEÑO DEL MODELO DE NEGOCIO
ACTUAL

A continuación se realizará la representación mediante diagramas, la especificación

detallada sobre el estado de los procedimientos actuales para la administración de
la evaluación académica y gestión de calificaciones.

Para realizar el modelo de negocio actual, se ha recolectado los datos mediante

técnicas de observación al escuadrón de evaluación quienes han proporcionado
información referente a las formas en el cual los docentes llevan el proceso de
evaluación académica hacia los estudiantes, y como el escuadrón de evaluación
realiza el proceso de llenado de planillas para el informe general.

Para representar de mejor manera este procedimiento, ver la figura 25 y figura 26.

3.1.1. MODELO DE NEGOCIO ACTUAL

El modelo de negocio actual permite representar de manera gráfica la información

adquirida mediante las técnicas de recolección de datos. Para representación de
este modelo se consideran dos elementos: Una representación por niveles que
divide a la institución en 3 niveles (Objetivos, procesos y sistemas) para facilitar la
alineación de los sistemas a los objetivos, procesos y una representación de
actividades de la institución. Las representaciones se muestran en el siguiente
apartado:

95
3.1.2. Modelo de negocio actual en tres niveles

Figura 25: Modelo de negocio actual en tres niveles

Fuente: [Elaboración Propia].

96
3.1.3. Modelado de negocio actual de actividades

Figura 26: Modelado de negocio actual de actividades

act Modeloactual

Modelo de negocio actual

Inicio
Inicio

Confeccion del calendario Los docentes finalizando Los estudiantes tienen

academico cada etapa de ev aluacion acceso a sus notas y
debera llenar y entregar las examenes realizando una
planillas y examenes solicitud prev ia con 24hrs
de anticipacion

SI
¿Existe
Registro? Hallar porcentaj es de acuerdo a:
¿Estudiante NO *Participacion en clases 10%
de 3er año? *Promedio de controles 20%
*Examen Parcial 30%
No *Examen Final 40%

Registro de estudiantes,
materias, cursos y SI
horarios

Hallar porcentaj es teniendo en cuenta:

Materias generales, aeronauticas y El encargado recibe
sub especialidades. planillas de notas y
Taller de proyecto de grado 60%(Nota minima) examenes
Examen de grado 75% (Nota minima).

El encargado realiza el
archiv ado de planillas de
notas y examenes en el
dpto de ev aluacion

El encargado de escuadron de
El encargado de escuadron elabora
Estudiantes mas ev aluacion realiza un reporte general
un listado de los estudiantes
destacados tienen opcion con el desempeño academico de
destacados en base al reporte de
a becas todos los estudiantes dentro de la
desempeño academico
institucion

El encargado debe entregar el

informe realizado al j efe de
escuadron de ev aluacion y
posteriormente elev ado al
comandante de la institucion FIN

Fuente: [Elaboración Propia].

97
3.2. DISEÑO DEL MODELO DE NEGOCIO ALTERNATIVO
CONSIDERANDO LA NECESIDAD DE UNA PLATAFORMA WEB Y
MÓVIL
3.2.1. Falencias existentes en el proceso actual de gestión de calificaciones

 Existe tiempo excesivo en el proceso de inscripción y de generación de

reportes de rendimiento académico debido a que estos procesos son
manuales.
 La verificación de planillas realizadas por el encargado del escuadrón de
evaluación para la impresión de planillas provoca pérdida de tiempo
considerable.
 Las planillas de notas y exámenes son almacenadas en el departamento de
escuadrón de evaluación, por lo cual el estudiante debe aproximarse y
solicitar con 24 horas de anticipación la solicitud para ver sus notas esto
provoca incertidumbre por parte de los estudiantes hacia los servicios
brindados por la institución.
 El almacenamiento actual con el cual se manejan las planillas de notas, y
exámenes y datos personales de los estudiantes puede provocar el extravió
de estos importantes documentos.

3.2.2. Modelo de Negocio Alternativo

Este modelo surge como una propuesta que permita solucionar las deficiencias
encontradas en el modelado actual y las ya mencionadas en el punto anterior, en la
figura 27 se ilustra el modelado de negocio alternativo.

3.2.3. Modelado de negocio alternativo en tres niveles

Para representar la solución propuesta, se utilizara el esquema de 3 niveles que

indica la optimización de procedimientos y de recursos que tiene la institución.

98
Figura 27: Modelo de negocio alternativo en tres niveles

Fuente: [Elaboración Propia].

99
 act ModeloAlternativ o

NIVEL DE SISTEMA DE INFORMACION ALTERNATIVO

Encargado de escuadrón Jefe de escuadrón de Docente

Aplicación Web Aplicación Móv il Estudiante
de ev aluación ev aluación

A B C
Inicio
Encargado de escuadrón Inicio
selecciona en la interfaz
la operacion que desea

Figura 28: Modelado de negocio alternativo

Usuario ingresa al
realizar sistema El docente ingresa a la
El j efe ingresa a la opción registrar notas El Estudiante
opción de Administrar ingresa a la
Notas opcion de v er
notas
Fuente: [Elaboración Propia].

Usuario se autentica con

¿Interfaz su respectiv o login y Selecciona el curso
Web? passw ord asignado por el Usuario ingresa a la correspondiente
sistema aplicación móv il El estudiante
SI El j efe ingresa a la opción escoge el curso
de reporte de notas del cual desea
Interfaz Web: Se da la opción de obtener el reporte
*Administrar Cargos calificar a los estudiantes de sus notas
*Administrar Estudiantes Si ¿Encargado
segun las materias que
de escuadrón
100

*Administrar Docentes tenga asignado

A de
*Administrar
Administrativos ev aluación?
NO
*Administrar Se genera el pdf con
Especialidades ¿Desea No las notas del
*Administrar Materias imprimir estudiante
Si reportes?
*Administrar Cursos No
*Administrar Notas D ¿Desea Si
registrar otra
¿Es el j efe de
escuadrón? ¿Es el Si materia?
Interfaz Móv il docente?
*Registrar Notas No
*Mostrar Notas El j efe imprime los
reportes y los entrega al
No
No
comandante de la
Si Si institución
¿Es
estudiante?
B
No C

Si
No ¿Salir del Sesion Finalizada
sistema?
FIN
D
3.2.4. Selección del modelo de desarrollo de software

A continuación se muestra una tabla contiene las ventajas y desventajas

identificadas de los modelos de desarrollo de software mencionados en el marco
teórico:

Tabla 5: Selección del modelo de desarrollo de software

Modelo de Desarrollo de Ventajas Desventajas
Software


El modelo
Con un paradigma
incremental no es
incremental se reduce
recomendable para
el tiempo de desarrollo
casos de sistemas
inicial, ya que se
de tiempo real, de
implementa la
alto nivel de
funcionalidad parcial.
seguridad, de
 También provee un
procesamiento
impacto ventajoso
distribuido y/o de
frente al cliente, que es
alto índice de
la entrega temprana de
riesgos.

partes operativas del
Modelo Incremental Requiere de mucha
software.
planeación, tanto
 El modelo proporciona administrativa como
todas las ventajas del técnica.
modelo en Cascada  Requiere de metas
realimentado, claras para conocer
reduciendo sus el estado del
desventajas sólo al proyecto.
ámbito de cada
incremento.

 Resulta más sencillo

acomodar cambios al

101
 acotar el tamaño de los
incrementos.

 Mitigación temprana  Requiere costos de

de posibles riesgos dedicación altos por
altos lo que no es
 Progreso visible en conveniente usarlo
las etapas en procesos de un
tempranas proyecto pequeño.
 El conocimiento  Si el proceso no se
adquirido en una aplica bien desde el
Modelo UP
iteración puede inicio, se puede
aplicarse de volver muy grande y
iteración a iteración difícil, tanto para
 Los usuarios están aprender como para
involucrados administrar.
continuamente  Se basa mucho en
la documentación.

 La relación entre  Es difícil que el

las etapas de cliente exponga
desarrollo y los explícitamente
distintos tipos de todos los
pruebas facilitan la requisitos
localización de  El cliente debe
Modelo en V fallos. tener paciencia
 Es un modelo pues obtendrá el
sencillo y de fácil producto al final
aprendizaje del ciclo de vida
 Hace explícito  Las pruebas
parte de la pueden ser caras
iteración y trabajo y, a veces, no lo

102
 que hay que suficientemente
revisar efectivas
 Especifica bien los  El producto final
roles de los obtenido puede
distintos tipos de que no refleje
pruebas a realizar todos los
 Involucra al requisitos del
usuario en las usuario.
pruebas.

Fuente: [Elaboración Propia].

El Politécnico Militar de Aeronáutica Sbtte Jose Max Ardilles no cuenta con ningún
sistema informático que le permita realizar el proceso de gestión de calificaciones,
el modelo UP funciona mejor con empresas que tienen objetivos volátiles, en este
caso no se aplica, ya que el POLMILAE tiene los objetivos claros como se ven
reflejados en el modelo de 3 niveles del negocio actual, el modelo en V suele tender
a no satisfacer todos los requisitos que el cliente requiere, y además el cliente no
ve ningún resultado sino hasta haber finalizado el proyecto, por la comparativa de
estos tres modelos, se ha optado realizar para este proyecto el modelo incremental
por su objetividad clara y entregas tempranas de pequeños avances del sistema al
cliente, esto reflejara positivamente que el proyecto va por buen camino.

3.2.5. Planificación de incrementos

Primer incremento

Diseñar e implementar los módulos de gestión de usuarios, estudiantes, docentes,

administrativos, materias, especialidades y cursos

Segundo Incremento

Desarrollar una aplicación móvil para la gestión de calificaciones.

103
Tercer Incremento

Generar reportes de acuerdo a las necesidades del caso de estudio.

3.3. DISEÑO E IMPLEMENTACIÓN DE LOS MÓDULOS DE

GESTIÓN DE ESTUDIANTES, DOCENTES, MATERIAS,
ESPECIALIDADES, CURSOS Y USUARIOS ADMINISTRATIVOS
3.3.1. Selección Gestor de Base de datos

Tabla 6: Selección de Gestor de Base de datos.

Gestor de base de datos Ventajas Desventajas

 Ampliamente popular  Sin experticia, configurar
Ideal para llega a ser un caos.
tecnologías Web.  Es fácil de vulnerar sin
 Fácil de Administrar. protección adecuada.
 Su sintaxis SQL es  El motor MyISAM es
estándar y fácil de instalado por defecto y
aprender. carece de capacidades
 Footprint bajo de de integridad relacional.
memoria, bastante  InnoDB genera mucho
poderoso con una footprint en memoria al
configuración indizar.
PostgreSQL
adecuada.  El toolset empresarial
 Multiplataforma. tiene un costo adicional
 Capacidades de por suscripción anual.
replicación de datos.  Realizar revisiones
 Soporte empresarial llegar a ser una labor
disponible. manual y tediosa para el
DBA.
 Reducida cantidad de
tipos de datos.

104
  MySQL software es  Un gran porcentaje de
Open Source. las utilidades de MySQL
 Velocidad al realizar las no están documentadas
operaciones, lo que le  Los privilegios de una
hace uno de los tabla no se eliminan
gestores con mejor automáticamente
rendimiento. cuando se borra una
 Bajo costo en tabla.
requerimientos para la  No es intuitivo, como
elaboración de bases otros programas
de datos, ya que (Access).
debido a su bajo
consumo puede ser
ejecutado en una
máquina con escasos
recursos sin ningún
MySQL
problema.
 Baja probabilidad de
corromper datos,
incluso si los errores no
se producen en el
propio gestor, sino en el
sistema en el que está.
 Su conectividad,
velocidad, y seguridad
hacen de MySQL
Server altamente
apropiado para acceder
bases de datos en
Internet.
 El software MySQL usa
la licencia GPL

105
  Soporte de  MSSQL usa
transacciones. AddressWindowing
 Escalabilidad, Extensión (AWE) para
estabilidad y seguridad. hacer el
 Soporta direccionamiento de 64-
procedimientos bit. Esto le impide usar la
almacenados. administración dinámica
 Incluye también un de memoria y sólo le
potente entorno gráfico permite alojar un
de administración, que máximo de 64GB de
permite el uso de memoria compartida.
comandos DDL y DML  MSSQL no maneja
gráficamente. compresión de datos (en
Microsoft SQL SERVER  Permite trabajar en SQL Server 2005 y
modo cliente-servidor, 2000, solamente la
donde la información y versión 2008 Enterprise
datos se alojan en el Edition incluye esta
servidor y los característica), por lo
terminales o clientes de que ocupa mucho
la red sólo acceden a la espacio en disco.
información.
 Además permite
administrar información
de otros servidores de
datos.

Fuente: [Elaboración Propia].

Para este proyecto se ha optado por el gestor de base de datos MySQL ya que el
sistema necesita de un gestor que sea robusto en la cantidad de datos que puedan
soportar las tablas, SQL Server requiere de una licencia de pago y además requiere

106
de mucha memoria. Tampoco se aceptó PostgreSql debido a su reducida cantidad
de manejo de datos y no exige integridad relacional. MySQL ofrece una licencia bajo
la GNU GPL para cualquier uso, además de ser multiplataforma, permite manejar
bases de datos relacionales, flexibilidad a la hora de crear tablas y alta
compatibilidad con muchos lenguajes de programación.

3.3.2. Selección de lenguaje de programación WEB

Tabla 7: Selección de lenguaje de programación WEB

Lenguaje de Ventajas Desventajas
programación
 Ejecución rápida del  Complejidad de
servlets. aprendizaje
 Crear páginas del lado  El hosting que precisa
del servidor. son más caros.
 Multiplataforma.
 Código bien
Java(JSP) estructurado.
 Integridad con los
módulos de Java.
 La parte dinámica está
escrita en Java.
 Permite la utilización se
servlets.
 Completamente  Mayor consumo de
orientado a objetos. recursos
 Controles de usuario y  Su desarrollo impone
ASP.NET personalizados. sistema operativo
 División entre la capa Windows.
de aplicación o diseño
y el código.

107
  Facilita el
mantenimiento de
grandes aplicaciones.
 Incremento de
velocidad de respuesta
del servidor.
 Mayor velocidad.
 Mayor seguridad.
 Muy fácil de aprender.  Se necesita instalar un
 Se caracteriza por ser servidor web.
un lenguaje muy  Todo el trabajo lo
rápido. realiza el servidor y no
 Soporta en cierta delega al cliente. Por
medida la orientación a tanto puede ser más
objeto. Clases y ineficiente a medida
herencia. que las solicitudes
 Es un lenguaje aumenten de número.
multiplataforma: Linux,  La legibilidad del
Windows, entre otros. código puede verse
 Capacidad de conexión afectada al mezclar
con la mayoría de los sentencias HTML y
PHP
manejadores de base PHP.
de datos: MysSQL,  La programación
PostgreSQL, Oracle, orientada a objetos es
MS SQL Server, entre aún muy deficiente
otras. para aplicaciones
 Capacidad de expandir grandes.
su potencial utilizando  Dificulta la
módulos. modularización.
 Posee documentación  Dificulta la
en su página oficial la organización por capas
cual incluye de la aplicación.
descripción y ejemplos

108
 de cada una de sus
funciones.
 Es libre, por lo que se
presenta como una
alternativa de fácil
acceso para todos.
 Incluye gran cantidad
de funciones.
 No requiere definición
de tipos de variables ni
manejo detallado del
bajo nivel.

Fuente: [Elaboración Propia].

El desarrollo de la aplicación que sirva de presentación para los usuarios será

desarrollado bajo PHP, ya que este es un lenguaje rápido, ligero y portable. Además
de que es multiplataforma y su consumo de recursos no es muy elevado a
comparación de los otros lenguajes que fueron mencionados.

3.3.3. Selección del framework

A continuación se presenta una tabla que representa las ventajas y desventajas de

los frameworks de desarrollo, que se consideran como candidatos a ser utilizados
para el desarrollo del sistema.

Tabla 8: Selección del framework.

Framework Ventajas Desventajas

 Capacidad de  Excesiva cantidad
asociar una ruta a de clases y
Laravel
un controlador y una métodos estáticos.
vista.

109
  La creación de
Restful APIs es más
sencilla.
 Cuenta con un ORM
tan practico que se
basa en un patrón
ActiveRecord.
 Los componentes  Hay que “instalar” el
están libremente framework en el
acoplados. Con servidor web, y esto
Phalcon, nada está puede ser un gran
impuesto: tienes la freno a la hora de
libertad de usar todo desplegar la
el framework, o solo aplicación.
las partes que  A la hora de utilizar
necesites el framework en tu
 Optimizaciones de proyecto, debes
bajo nivel ayudan a crear de forma
reducir la manual el archivo
Phalcon
sobrecarga que carga los
requerida para componentes de
correr aplicaciones Phalcon (un archivo
MVC de inicialización del
 Las operaciones framework,
con base de datos boostrap).
se efectúan con la
máxima eficiencia al
usar un ORM para
PHP escrito en C
 Phalcon accede
directamente a las

110
 estructuras internas
de PHP
optimizando
además cada
ejecución
 Es muy liviano. La  Pertenece a una
última versión, la empresa. La cual
1.7.2 apenas puede decidir un
supera 1Mb. día dejar de
 Ofrece un gran actualizarlo, dar
rendimiento. soporte o hacerlo
 Ofrece de pago.
compatibilidad con  La compatibilidad
varias versiones de con tantas
PHP. versiones de PHP
Concretamente hace que no
desde la 4.3.2 a la podamos hablar de
5.3.0 un framework
CodeIgniter
 Apenas requiere completamente
configuración. Orientado a
 No requiere de línea Objetos.
de comandos para  No trabaja con
generar las módulos por lo que
aplicaciones. separar la
 No sigue una línea aplicación en éstos
de reglas estricta. requiere de plugins,
Podemos adaptarlo modificación de la
a nuestras estructura básica o
necesidades. ser muy ordenados.

111
  No es una gran
librería al estilo
PEAR.
 No requiere
aprender un
lenguaje de platillas.
Es opcional.
 Genera SEO urls
para los
buscadores.
 Tiene una
documentación
clarísima.

Fuente: [Elaboración Propia].

Para el desarrollo de la aplicación web se consideró el framework más adecuado y

compatible con el lenguaje escogido en el punto anterior (PHP), también se
consideró su conexión a la base de datos MySQL, el framework escogido es Laravel
y este framework maneja la arquitectura MVC (Modelo Vista Controlador, referencia
en la página 83).

El primer incremento definido en la planificación de incrementos consiste en diseñar

e implementar los módulos de administración de usuarios, estudiantes, docentes,
materias, especialidades y cursos, en este incremento se definen 4 etapas para su
desarrollo del primer incremento y que son: Análisis, Diseño, Codificación y
Pruebas.

112
3.3.4. Análisis del primer incremento

En el primer incremento se necesitan las participaciones de los actores que

intervienen en el módulo de gestión de usuarios, estudiantes, docentes,
administrativos, materias especialidades y cursos.

A continuación se muestran los requerimientos funcionales y no funcionales para el

módulo desarrollado.

3.3.4.1. Análisis de requerimientos

 Requerimientos funcionales

Creación y gestión de cuentas de usuarios, estudiantes, docentes,

administrativos, materias, especialidades y cursos.

 El encargado de escuadrón de evaluación deberá tener la posibilidad de

poder registrar usuarios, estudiantes, docentes, administrativos, materias,
especialidades y cursos en el sistema.
 El sistema deberá permitir asignar a los distintos miembros de la institución
una cuenta de usuario.
 El sistema deberá permitir la visualización de los datos del personal
administrativo, personal estudiantil y docentes, así mismo poder gestionar
esta información.
 El sistema deberá permitir la asignación de materias a los docentes.
 El sistema deberá permitir la asignación de especialidades a los estudiantes.
 El sistema deberá permitir la asignación de cargos al personal estudiante,
administrativo y docente.
 El sistema deberá permitir la asignación de materias a los distintos cursos
que existen en la institución.
 Requerimientos no funcionales
 Debe ser orientado a la web.
 Utilizar arquitectura MVC.

113
  Debe tener una interfaz amigable.

3.3.4.2. Identificación de actores

Los actores que participan en este incremento son:

 Encargado de escuadrón de evaluación.

Descripción de los actores: Los actores se describen a continuación:

 Encargado de escuadrón de evaluación: Es una autoridad dentro de lo

que viene a ser el escuadrón de evaluación, en este incremento tiene las
siguientes funciones:
Administrar cargos, administrar estudiantes, administrar docentes,
administrar administrativos, administrar materias, administrar especialidades
y administrar cursos.

3.3.5. Diseño

Describe la realización física de los casos de uso y crea una base al modelo de
implementación.

En la etapa de diseño en base a la teoría de la página 31, se dividirá este trabajo en

el diagramado de los aspectos dinámicos y estáticos en base a los diagramas de
estructura y de comportamiento que a continuación se muestran:

3.3.5.1. Diagramas estructurales

Los diagramas estructurales permitirán visualizar, especificar, construir y

documentar los aspectos estáticos del sistema propuesto. Para esto se consideran
los siguientes diagramas:

 Diagramas de clases
 Diagramas de despliegue

114
a) Diagramas de clases

Permite ver las relaciones entre entidades de manera general, considerando la

cardinalidad entre las mismas, el diagrama de base de datos se construirá en base
a este diagrama aplicando reglas de normalización.

En la figura 29 se puede observar el diagrama de clases realizado para este

incremento

115
Figura 29: Diagrama de clases

Fuente: [Elaboración Propia].

116
  Diagramas de bases de datos

El diagrama de base de datos del sistema, se ha elaborado a partir del diagrama de

clases, se pueden identificar fácilmente las llaves primarias y las llaves foráneas
para una mejor comprensión.

La figura 30 muestra el diagrama de base de datos del sistema.

Figura 30: Diagrama de base de datos del sistema

Fuente: [Elaboración Propia].

117
  Diccionario de datos de la base de datos.

En la tabla 8 se ha construido el diccionario de datos, explicando los atributos de las

diferentes tablas utilizadas en la base de datos de la propuesta.

Tabla 9: Diccionario de datos de la base de datos.

Tipo de Longit Tipo de

Tabla Atributo Descripción
dato ud clave
Id Entero Primaria Identificador de la tabla
Login Cadena 50 Nombre de usuario
Password Cadena 50 Contraseña del usuario
Tipo de usuario se le
Nivel Entero
asigna un numero
Almacena 0 si la
Users
cuenta esta
Estado Entero
deshabilitada y 1 si
esta activa.
Este campo almacena
Remember_token Cadena 100 la sesión realizada por
el usuario.
Id Entero Primaria Identificador de la tabla
ID que pertenece a la
Persona_id Entero Foránea
AsignacionCuen tabla Persona
taUsuario ID del usuario que
Users_id Entero Foránea pertenece a la tabla
users
Id Entero Primaria Identificador de la tabla
Persona
Cedula de identidad de
CI Cadena 15
la persona.
Nombre Cadena 50 Nombre de la persona.

118
 Apellido Paterno de la
ApellidoPaterno Cadena 45
persona.
Persona
Apellido Materno de la
ApellidoMaterno Cadena 45
persona.
Dirección domiciliar de
Direccion Cadena 45
la persona.
Número telefónico de
Telefono Entero
la persona.
Sexo de la persona
Sexo Cadena 15 (Masculino o
Femenino)
IdEspecialidad Entero Primaria Identificador de la tabla
Nombre de la
Nombre Cadena 50
Especialidad Especialidad
Nota Mínima de
NotaAprobacion Float
Aprobación
Id Entero Primaria Identificador de la tabla
Cargo
Nombre Cadena 45 Nombre del cargo.
Id Entero Primaria Identificador de la tabla
Identificar de la tabla
Persona_id Entero Foránea
Asignarcargo Persona.
Identificador de la tabla
Cargo_id Entero Foránea
Cargo
Id Entero Primaria Identificador de la tabla
Identificador de la tabla
Persona_id Entero Foránea
Persona

Asignarespeciali Identificador de la tabla

Especialidad_id Entero Foránea
dad Especialidad.

Identificador de la
Materia Id Entero Primaria
tabla.

119
 Codmateria Cadena 10 Código de la materia.
Nombremateria Cadena 45 Nombre de la materia.
Sigla Cadena 10 Sigla de la materia
Identificador de la
Id Entero Primaria
tabla.
Gestión
Gestion Entero correspondiente al
curso (año).
Curso
Paralelo
Paralelo Cadena 50 correspondiente al
curso.
Identificador de la tabla
Especialidad_id Entero Foránea
Especialidad.
Identificador de la
Id Entero Primaria
tabla.
Identificador
Asignarmateriac Curso_id Entero Foránea perteneciente a la
urso tabla curso
Identificador
Materia_id Entero Foránea perteneciente a la
tabla materia
Identificador
Id Entero Primaria perteneciente a la
tabla.
Asignarmateriad
Clave perteneciente a
ocente Persona_id Entero Foránea
la tabla Persona
Clave perteneciente a
Materia_id Entero Foránea
la tabla Materia.
Asignarcursoest Identificador de la
Id Entero Primaria
udiante tabla.

120
 Identificador de la tabla
Persona_id Entero Foránea
persona.
Identificador de la tabla
Curso_id Entero Foránea
curso.

Fuente: [Elaboración Propia].

b) Diagramas de despliegue

Los diagramas de despliegue nos permiten ver los dispositivos que interactúan entre
sí para el funcionamiento del sistema y qué tipo de información se envían unos a
otros.

En la figura 31 podemos observar como los dispositivos están conectados y que

parámetros reciben o se envían.

Figura 31: Diagrama de despliegue

deployment Diagramas De Despliegue

Serv idor Base

de Datos M ySQL
Router T CP/IP

Respuesta
HT T P-GET
Sol i ci tud Restful
(HT T P-POST ) Serv idor Web
IP Apache

IP
Sw itch
IP

IP
Clientes
Dispositiv os
Cliente Laptop M ov iles Android

Clientes PC

Fuente: [Elaboración Propia].

121
En la representación del diagrama de despliegue para el sistema propuesto, se
puede observar como varios dispositivos a través de una conexión de Red (Wi-fi o
Ethernet) están conectados al servidor web apache es decir mediante un protocolo
HTTP pueden acceder al servicio que proporciona este servidor que es donde se
encontrará alojado el sistema propuesto, también tienen acceso mediante un
protocolo IP/TCP al servidor de base de datos, pero no de manera directa sino
mediante la interfaz que proporcionará el sistema propuesto.

3.3.5.2. Diagramas de comportamiento

Los diagramas de comportamiento se emplean para visualizar, especificar, construir

y documentar los aspectos dinámicos del sistema.

Para esto se consideran los siguientes diagramas:

 Diagramas de casos de uso.

 Diagramas comunicación.

Casos de uso general del sistema

En base a los requerimientos funcionales determinados en secciones anteriores y

utilizando los actores encontrados, se ha determinado el siguiente diagrama de
casos de uso para el sistema propuesto.

122
 Figura 32: Diagrama de casos de uso del primer incremento.
uc Casos de uso del sistema

Ingresar al sistema

Administrar Cargos

Administrar
Estudiantes

Encargado de escuadron
de ev aluacion
Administrar Docentes

Administrar
Administrativ os

Administrar Materias

Administrar
Especialidades

Administrar Cursos

Fuente: [Elaboración Propia].

Caso de uso Administrar Cargos

Figura 33: Caso de uso administrar cargos.

uc Administrar Cargos

Caso de uso Adm i ni strar Cargos

M odificar

«extend»
Administrar Cargos M ostrar Cargos

«extend»

Eliminar
Encargado de
escuadrón de Registrar Cargos
ev aluación

Fuente: [Elaboración Propia].

123
Descripción de caso de uso: A continuación se muestra una explicación del caso
de uso administrar estudiantes a su función y actores.

Tabla 10: Descripción caso de uso Administrar Cargos

Nombre de caso de uso: Administrar Cargos

Actor: Encargado de Escuadrón de evaluación
Permitir registrar los cargos existentes
dentro de la institución y la habilitación de
Función: los mismos, además de poder gestionar a
los mismos (ver datos, modificar y
eliminar).
Jefe de Escuadrón de evaluación:

Descripción: El Registrará los cargos y los habilitara en

el sistema para poder definir el cargo que
cumple.

Fuente: [Elaboración Propia].

Caso de uso Administrar Estudiantes

Figura 34: Caso de uso Administrar Estudiantes

uc Administrar Estudiantes

Caso de uso Admi ni strar Estudi antes

Modificar

Administrar Mostrar Estudiantes «extend»

Estudiantes

«extend»
Encargado de escuadrón
de ev aluación Eliminar

Registrar Estudiantes

Fuente: [Elaboración Propia].

124
Descripción de caso de uso: A continuación se muestra una explicación del caso
de uso administrar docentes a su función y actores.

Tabla 11: Descripción caso de uso Administrar Estudiantes.

Nombre de caso de uso: Administrar Estudiantes

Actor: Encargado de Escuadrón de evaluación.
Permite registrar los estudiantes en el
sistema, además de poder gestionar a
Función:
los mismos (ver datos, modificar y
eliminar).
Encargado de Escuadrón de evaluación:

Descripción: Registrará a los estudiantes y los

habilitara para el proceso de evaluación
académica.

Fuente: [Elaboración Propia].

Caso de uso Administrar Docentes

Figura 35: Caso de uso administrar Docentes

uc Administrar Docentes

Caso de uso Admi ni strar Docentes

Modificar
Mostrar Docentes «extend»

Administrar Docentes «extend»

Encargado de Eliminar
escuadrón de
ev aluación
Registrar Docentes

Fuente: [Elaboración Propia].

125
Descripción de caso de uso: A continuación se muestra una explicación del caso
de uso administrar especialidades a su función y actores.

Tabla 12: Descripción de caso de uso administrar docentes

Nombre de caso de uso: Administrar Docentes

Actor: Encargado de Escuadrón de evaluación.
Función: Permite registrar a los docentes que
existen dentro de la institución, y
además permite la gestión de los
mismos.
Descripción: Encargado de escuadrón de evaluación:
Permitirá el registro de los docentes y la
gestión de los mismos, que servirán para
el proceso de evaluación académica.

Fuente: [Elaboración Propia].

Caso de uso administrar administrativos

Figura 36: Caso de uso administrar administrativos

uc Administrar Administrativ os

Caso de uso Administrar Administrativos

Modificar

Administrar Mostrar «extend»

Administrativ os Administrativ o

Encargado de
escuadrón de «extend»
ev aluación
Eliminar

Registrar
Administrativ o

Fuente: [Elaboración Propia].

126
Descripción de casos de uso: A continuación se muestra una explicación del caso
de uso administrar administrativos a su función y actores.

Tabla 13: Descripción de caso de uso administrar administrativos.

Nombre de caso de uso: Administrar administrativos.

Actor: Jefe de Escuadrón de Evaluación.
Permite gestionar al personal
administrativo que existe dentro del
Función: escuadrón de evaluación, a su vez
permite la asignación de cuentas de
usuario y cargos.
Encargado de escuadrón de evaluación:
Podrá acceder al registro y gestión de
Descripción: administrativos, así mismo asignarle
cuentas de usuario y cargos
correspondientes a cada administrativo.

Fuente: [Elaboración Propia].

Caso de uso administrar materias

Figura 37: Caso de uso administrar materias.

uc Administrar Materias

Caso de uso Admi ni strar Materi as

Modificar

Administrar Materias Mostrar Materias «extend»

«extend»

Eliminar
Encargado de
escuadrón de
ev aluación «i ncl ude»
«i ncl ude»
«i ncl ude»

Registrar Materias
Asignar Materia a
Mostrar Materias
Docente
asignadas a
Docentes

Fuente: [Elaboración Propia].

127
Descripción de caso de uso: A continuación se muestra una explicación del caso
de uso de administrar materias a su función y actores.

Tabla 14: Descripción de caso de uso administrar materias

Nombre de caso de uso: Administrar materias

Actor: Encargado de Escuadrón de Evaluación.
Permite registrar y gestionas las materias
Función: existentes en la institución, además de
asignarles una materia a los docentes.
Encargado de escuadrón de evaluación:
Podrá acceder al registro y gestión de
Descripción: materias, así mismo asignarle las
especialidades correspondientes a cada
persona.

Fuente: [Elaboración Propia].

Caso de uso administrar especialidades

Figura 38: Caso de uso administrar especialidades.

uc Administrar Especialidades

Caso de uso Administrar Especialidades

Modificar

«extend»
Administrar Mostrar
Especialidades Especialidades

«extend»
Eliminar
Encargado de escuadrón «include»
de ev aluación
Mostrar
«include» «include» Especialidades
asignadas a
Estudiantes

Registrar Asignar Especialidad a

Especialidad Estudiante

Fuente: [Elaboración Propia].

128
Descripción de caso de uso: A continuación se muestra una explicación del caso
de uso administrar cursos a su función y actores.

Tabla 15: Descripción caso de uso administrar cursos

Nombre caso de uso: Administrar Especialidades.

Actor: Encargado de Escuadrón de Evaluación.
Este caso de uso permitirá el registro y la
gestión de las especialidades existentes,
Función:
así mismo la asignación de estas a los
estudiantes.
Encargado de Escuadrón de Evaluación:
Podrá registrar y gestionar las distintas
Descripción: especialidades existentes, y así mismo a
los estudiantes habilitados en el sistema
les asignara una especialidad.

Fuente: [Elaboración Propia].

Caso de uso Administrar Cursos

Figura 39: Caso de uso Administrar Cursos

uc Administrar Cursos

Caso de uso Admi ni strar Cursos

Mostrar Asignacion
de Cursos a
Estudiantes
Administrar Cursos «extend»

Encargado de escuadrón
de ev aluación «extend»
Mostrar asignacion
«extend» de Materias a Curso
«i ncl ude» «i ncl ude»
«i ncl ude»

Mostrar Cursos
Registrar Cursos Asignar Materias a
Curso Asignar Curso a
Estudiante

«extend»
«extend»

Modificar
Eliminar

Fuente: [Elaboración Propia].

129
 Tabla 16: Descripción caso de uso Administrar Cursos

Nombre del caso de uso: Administrar Cursos

Actor: Encargado de escuadrón de evaluación.
Función: Este caso de uso permitirá el registro de
todos los cursos que hayan existido en la
institución, además de permitir la
asignación de materias y estudiantes a
estos.
Descripción: Encargado de escuadrón de evaluación:
Podrá registrar y gestionar los cursos, las
asignaciones de materias y estudiantes
de estos cursos.

Fuente: [Elaboración Propia].

Diagramas de comunicación

Este diagrama es una versión simplificada del diagrama de colaboración de la

versión tradicional de UML, nos permiten ver las interacciones de los objetos
mediantes mensajes.

130
Caso de uso Administrar Cargos

Figura 40: Diagrama de comunicación Administrar Cargos

sd Administrar Cargos

0.1: Accede a la vista() Vista Administrar

Cargos

Encargado de escuadron 0.2: Cargar Parametros()

de ev aluacion

0.11: Cargar Parametros()

0.3: Envio de parametros()
Ciclo Registrar
Modificar Cargo Controlador Cargos
Cargo
0.4: Cargo Modificado()

0.13: Fin registro()

0.9: Cargar Parametros() 0.12: Cargo registrado()

0.5: Eliminar Cargo()
0.8: Asignacion registrada()
0.10: Asignaciones registradas()

0.6: Cargo Eliminado()

Registro Cargo
Eliminar Cargo

0.7: Enviar Parametros()

Asignar cargo a Mostrar asignaciones

persona de cargos a personas

Fuente: [Elaboración Propia].

Caso de uso Administrar Estudiantes

Figura 41: Diagrama de comunicación administrar estudiantes

sd Administrar Estudiantes

Vista Administrar
Estudiantes
0.1: Accede a la vista()

0.2: Cargar Parametros()

Encargado de 0.3: Cargar Parametros()

escuadron de Controlador
Ciclo Crear
ev aluacion Estudiante
Estudiante

0.5: Acceder a la funcion() 0.6: Listado de estudiantes() 0.4: Fin Registro()

Mostrar Estudiantes Registro Estudiante

Fuente: [Elaboración Propia].

131
Caso de uso Administrar docentes

Figura 42: Diagrama de comunicación administrar docentes

sd Administrar Docentes

Controlador
0.1: Accede a la vista()
Administrar Docentes

Encargado de escuadron 0.2: Cargar Parametros()

de ev aluacion

0.3: Cargar Parametros()

Controlador Ciclo Crear
Docente Docente

0.4: Acceder a la funcion() 0.5: Listado de Docentes() 0.6: Fin registro() 0.7: Docente Registrado()

Mostrar Docentes
Registro Docente

Fuente: [Elaboración Propia].

Caso de uso Administrar administrativos

Figura 43: Diagrama de comunicación administrar administrativos

sd Administrar Administrativ os

Vista Administrar
1: Accede a la vista() Administrativ os

1.1: Cargar Parametros()

Encargado de 1.2: Cargar Parametros()

escuadrón de Controlador
Ciclo Crear
ev aluación Administrativ os
Administrativ os

1.3: Accede a la funcion() 1.4: Listado de administrativos() 1.5: Fin Registro()

Mostrar Registro
Administrativ os Administrativ os

Fuente: [Elaboración Propia].

132
Caso de uso administrar materias

Figura 44: Diagrama de comunicación administrar materias

sd Administrar Materias

0.1: Acceso a la vista()

Vista Administrar
Materias

Encargado de escuadron
0.2: Cargar Parametros()
de ev aluacion

0.7: Listado de Materias() 0.3: Cargar Parametros()

Mostrar Materias Controlador Ciclo Registrar
Materias Materia
0.6: Enviar Parametros()

0.10: Enviar Parametros()

0.4: Fin Registro()

0.8: Enviar Parametros()
0.9: Asignacion registrada() 0.5: Materia Registrada()

0.11: Listado de asignaciones()

Asignar Materia a
Docente
Mostrar Asignaciones de Registro Materia
Materias a Docentes

Fuente: [Elaboración Propia].

Caso de uso administrar especialidades

Figura 45: Diagrama de comunicación administrar especialidades

sd Administrar Especialidades

0.1: Accede a la vista()

Vista Administrar
Especialidades

Encargado de escuadron
de ev aluacion 0.2: Cargar Parametros()

0.6: Enviar Parametros() 0.3: Cargar Parametros()

Mostrar Materias Controlador Ciclo crear
Especialidades especialidad
0.7: Listado de Especialidades()

0.8: Enviar Parametros()

0.10: Enviar Parametros() 0.4: Fin registro() 0.5: Especialidad registrada()

0.9: Asignacion registrada() 0.11: Listado de asignaciones()

Asignar
Especialidad a
Mostrar asignaciones de Registro de
Estudiante
especialidad a estudiante especialidad

Fuente: [Elaboración Propia].

133
Caso de uso administrar cursos

Figura 46: Diagrama de comunicación administrar cursos

sd Administrar Cursos

Mostrar Cursos
0.1: Accede a la vista() asignados a
Vista Administrar 0.14: Enviar Parametros() estudiantes
Cursos

0.15: Listado de asignaciones()

Encargado de escuadron
de ev aluacion 0.2: Cargar parametros()

0.9: Enviar parametros() 0.3: Cargar Parametros()

Mostrar Cursos Controlador Curso

Ciclo Crear Curso

0.8: Listado materias()

0.4: Fin del registro() 0.5: Curso registrado()

0.10: Asignacion realizada()

0.11: Enviar parametros()

Registro Curso
Asignar Curso a
0.12: Enviar parametros()
Estudiante
0.6: Enviar parametros()

0.7: Listado de materias asignadas a cursos()

0.13: Asignacion registrada() Mostrar Materias

asignadas a cursos

Asignar Materias a
Curso

Fuente: [Elaboración Propia].

3.3.6. Codificación

Para la codificación del sistema se utilizan las anteriores etapas que son análisis y
diseño, para elaborar las interfaces e implementarlas en funcionamiento.

3.3.6.1. Arquitectura de la aplicación web

En la figura 47 se muestra el diseño de la arquitectura basada en MVC (Modelo

Vista controlador).

134
Figura 47: Diseño de la arquitectura de la aplicación web.

Fuente: [Elaboración Propia].

135
3.3.6.2. Interfaces del sistema

Figura 48: Interfaz Ingresar al Sistema

Fuente: [Elaboración Propia].

La interfaz está establecida gracias al framework elegido en la selección de

frameworks (ver página 113), está basado en normativas W3C por lo tanto las vistas
generadas son multiplataforma.

Interfaz Menú Administrador

En la figura 49 se puede observar el menú principal del encargado de escuadrón de

evaluación

136
 Figura 49: Interfaz Menú Principal jefe de escuadrón de evaluación.

Fuente: [Elaboración Propia].

Interfaz de registro de cuenta de usuario

En la figura 50 se puede observar el formulario de registro de cargos.

Figura 50: Interfaz registro de cargos.

Fuente: [Elaboración Propia].

En la figura 51 se muestra la lista de cargos registrados dentro del sistema y un

mensaje notificando el registro realizado del cargo.

137
 Figura 51: Interfaz listado y registro finalizado del cargo.

Fuente: [Elaboración Propia].

Interfaz registro estudiante

En la figura 52 se puede observar el formulario de registro de estudiantes, contiene

3 bloques en los cuales se registra el estudiante, se le asigna una cuenta de usuario
y el cargo que este ocupara (estudiante).

Figura 52: Interfaz Registro de estudiante

Fuente: [Elaboración Propia].

138
Interfaz listado de estudiantes

En la figura 53 se puede observar un listado de los estudiantes registrados en el

sistema.

Figura 53: Interfaz listado de estudiantes.

Fuente: [Elaboración Propia].

Interfaz registro de docentes

En la figura 54 se puede observar el formulario de registro de docentes, en el cual

se procede a registrar al docente, asignarle una cuenta de usuario y asignarle su
cargo como docente para que el docente pueda acceder al sistema y se le habilite
las opciones de registro de notas.

139
 Figura 54: Interfaz registro de docentes.

Fuente: [Elaboración Propia].

Interfaz listado de docentes

En la siguiente figura se puede observar un listado con los docentes registrados en

el sistema.

Figura 55: Interfaz Formulario de registro de materias.

Fuente: [Elaboración Propia].

140
Interfaz Registrar Materias

En la siguiente figura se puede apreciar el formulario de registro de materias.

Figura 56: Interfaz formulario de registro de materias.

Fuente: [Elaboración Propia].

Interfaz Mostrar Materias

En la figura 57 se puede apreciar un listado de todas las materias existentes de la

institución registradas en el sistema.

141
 Figura 57: Interfaz Mostrar Materias

Fuente: [Elaboración Propia].

Interfaz asignar materias a docente

En la figura 58 se puede observar un formulario de asignación con un listado de

materias y de docentes.

Figura 58: Interfaz asignar materias a docente.

Fuente: [Elaboración Propia].

142
Interfaz Mostrar Asignaciones de materias a docentes

En la figura 59 se puede observar un listado de las materias que fueron asignadas

a cada docente.

Figura 59: Interfaz Mostrar Asignaciones de materias a docentes.

Fuente: [Elaboración Propia].

Interfaz Registro de Especialidades

En la figura 60 se puede observar el formulario de registro de especialidades que

brinda el sistema propuesto.

Figura 60: Interfaz Registro de Especialidades.

Fuente: [Elaboración Propia].

143
Interfaz Mostrar Especialidades

En la figura 61 se puede observar un listado con todas las especialidades

registradas exitosamente en el sistema.

Figura 61: Interfaz Mostrar Especialidades

Fuente: [Elaboración Propia].

Interfaz Registrar Cursos

En la figura 62 se puede observar un formulario de registro de cursos.

Figura 62: Interfaz Registrar Cursos

Fuente: [Elaboración Propia].

144
Interfaz Mostrar Cursos

En la figura 63 se puede observar un listado de los cursos existentes en la

institución.

Figura 63: Interfaz Mostrar Cursos

Fuente: [Elaboración Propia].

Interfaz Asignar Curso a Estudiante

En la figura 64 se puede observar un formulario de registro de asignación de curso

a estudiante.

Figura 64: Interfaz Asignar Curso a Estudiante

Fuente: [Elaboración Propia].

145
Interfaz Asignar materias a curso

En la figura 65 se puede observar un formulario de asignación de materias a curso.

Figura 65: Interfaz asignar materias a curso

Fuente: [Elaboración Propia].

Interfaz Mostrar cursos asignados a estudiantes

En la figura 66 se puede observar un listado de estudiantes a los cuales se les fue

asignado un curso.

Figura 66: Interfaz Mostrar cursos asignados a estudiantes

Fuente: [Elaboración Propia].

146
Interfaz Mostrar asignaciones de materias a curso

En la figura 67 se puede observar un listado con los estudiantes a los que se le

asignaron un curso.

Figura 67: Interfaz mostrar asignaciones de materias a curso

Fuente: [Elaboración Propia].

3.3.7. Pruebas
3.3.7.1.1 Pruebas de requerimientos

Las pruebas de requerimientos corresponden a la fase de análisis de

requerimientos, determinan si se cumplen los requerimientos establecidos por el
Politécnico Militar de Aeronáutica. Para ello se realizó la tabla 17 donde se ingresan
los valores de entrada, se determinan los valores de salida y se determina si el
requisito se cumple mediante el caso de uso especificado.

147
 Tabla 17: Pruebas de requerimientos al sistema

CASOS DE USO DATOS DE RESULTADO RESULTADO

ENTRADA ESPERADO OBTENIDO
Conexión a la Base El sistema ingresa
de Datos y solicitud correctamente
Datos de inicio de
de autorización para verificando que tipo
sesión (login y
ingresar al sistema y de cuenta hace su
Ingresar al sistema. password) en el
poder manipular las inicio de sesión,
formulario
funcionalidades retornando la vista
correspondiente.
expuestas del correspondiente.
servicio.
El usuario El administrador El sistema muestra
administrador busca en el listado un mensaje de
logueado obtenido de los confirmación si
correctamente, usuarios registrados, desea modificar o
Administrar Cargos
campos modificados al usuario a modificar eliminar los datos de
del formulario y procede a modificar ese usuario.
correspondiente al los campos del
caso de uso. formulario.
El usuario El administrador El sistema muestra
administrador busca en el listado un mensaje de
Administrar logueado obtenido de los confirmación si
Estudiantes correctamente usuarios registrados, desea eliminar o
al usuario a eliminar. modificar los datos
de ese usuario.
El usuario Se recibe los datos El sistema muestra
administrador del formulario de en caso de registro,
logueado registro de docentes, modificación o
Administrar correctamente. estos datos se eliminación exitosa,
Docentes Registro de registran en el un mensaje
Docentes, listado de sistema y habilita al notificando el
los registros de docente en el proceso realizado
sistema, se visualiza correctamente.

148
 docentes existentes un listado con todos
en el sistema. los docentes
registrados, donde
se muestran
opciones de
modificación y
eliminación de estos.
El usuario Se recibe los datos El sistema muestra
administrador del formulario de en caso de registro,
logueado registro de modificación o
correctamente. administrativos, eliminación exitosa,
Registro de estos datos se un mensaje
Administrativos, registran en el notificando el
listado de los sistema y habilita al proceso realizado
Administrar registros de administrativo en el correctamente.
Administrativos administrativos sistema, se visualiza
existentes en el un listado con todos
sistema. los administrativos
registrados, donde
se muestran
opciones de
modificación y
eliminación de estos.
El usuario Se recibe los datos El sistema muestra
administrador del formulario de en caso de registro,
logueado registro de materias, modificación o
correctamente. estos datos se eliminación exitosa,
Registro, registran en el un mensaje
Administrar Materias modificación y sistema, se visualiza notificando el
eliminación de un listado con todas proceso realizado
materias en el las materias correctamente.
sistema. registradas, donde
se muestran
opciones de

149
 modificación y
eliminación de estas.
El usuario Se recibe los datos El sistema muestra
administrador del formulario de en caso de registro,
logueado registro de modificación o
correctamente. especialidades, eliminación exitosa,
Registro, estos datos se un mensaje
modificación y registran en el notificando el
eliminación de sistema, se visualiza proceso realizado
Administrar Especialidades en el un listado con todas correctamente.
Especialidades sistema. las especialidades
registradas, donde
se muestran
opciones de
modificación y
eliminación de estas.

El usuario Se recibe los datos

administrador del formulario de
logueado registro de
correctamente. especialidades, El sistema muestra
Registro, estos datos se en caso de registro,
modificación y registran en el modificación o
eliminación de sistema, se visualiza eliminación exitosa,
Administrar Cursos
cursos en el sistema. un listado con todos un mensaje
los cursos notificando el
registrados, donde proceso realizado
se muestran correctamente.
opciones de
modificación y
eliminación de estos.

Fuente: [Elaboración Propia].

150
3.4. DESARROLLO DE UNA APLICACIÓN MOVIL PARA LA
GESTION DE CALIFICACIONES

En este capítulo se procederá a la implementación del módulo de gestión de

calificaciones a la aplicación web, así también se desarrollará una aplicación móvil
para que pueda gestionar las calificaciones.

3.4.1. Identificación y selección de herramientas de desarrollo para la

construcción de la aplicación android.

Para la selección de las herramientas de desarrollo que se usaran en la construcción

de la aplicación Android, se lograron identificar las siguientes herramientas:

 Android Studio + SDK Android

 Eclipse + SDK Android

Ambas plataformas de desarrollo nos permiten la construcción de la aplicación, pero

se optó la selección de Android Studio debido a la compatibilidad con varios
dispositivos móviles actuales, es decir maneja la tecnología que llevan los celulares
actuales de gama alta.

3.4.2. Definición de actividades y servicios para la aplicación Android

Una actividad en Android representa una unidad de interacción con el usuario, es lo

que comúnmente se llama una pantalla de aplicación.

En este punto se logró identificar las actividades necesarias para la construcción de

la aplicación Android, que se pueden ver en la figura 68.

151
 Figura 68: Actividades de la aplicación Android

Fuente: [Elaboración Propia].

Luego de haber definido las actividades necesarias para la construcción de la

aplicación Android, se seleccionó el servicio a utilizar para la comunicación entre la
aplicación web y móvil. Los servicios web candidatos se muestran en la tabla 18,
junto con sus características.

Tabla 18: Selección de servicios web

Servicios web Ventajas Desventajas

 Los servicios Web  La seguridad es una
RESTful son deficiencia y puede
completamente sin llegar a ser una tarea
estado, ello puede ser muy difícil de
comprobado implementarla
mediante el reinicio el correctamente.
RESTful servidor y  No hay un estándar
comprobando si las en sus respuestas
interacciones son por lo que no se
capaces de sobrevivir. definen tipos de
 Rest es muy ligero, datos.
sus respuestas
contienen

152
 exactamente la
información que se
necesita
 Servicios RESTful
proporcionan una
buena infraestructura
de almacenamiento
en caché a través de
HTTP método GET
(para la mayoría de
los servidores), esto
mejorará el
rendimiento, si los
datos que devuelve el
servicio Web no se
altera con frecuencia
y no son de
naturaleza dinámica.
 Servicios REST son
fáciles de integrar con
los sitios web
existentes y están
expuestos a XML para
que las páginas HTML
pueden consumir la
misma con facilidad.
Casi no hay
necesidad de
refactorizar la
arquitectura de sitio
web existente. Esto
hace que los
desarrolladores sean
más productivos y

153
 cómodo, ya que no
tendrán que volver a
escribir todo desde
cero y sólo hay que
añadir la
funcionalidad
existente.
 El Web Services  Si se desea modificar
Description Language algo en el servidor
(WSDL) contiene y esto impacta de una
describe el conjunto forma negativa en los
de normas comunes clientes ya que ellos
para definir los realizar varias
mensajes, los modificaciones al
enlaces, las código.
operaciones y la  Si no se cuenta con
ubicación del servicio las herramientas
Web. WSDL es un correctas, la
tipo de contrato formal interpretación puede
para definir la interfaz tornarse demasiado
SOAP que ofrece el servicio compleja y difícil.
Web.
 SOAP requiere
menos código de
plumbing code de
servicios REST, (es
decir, las
transacciones, la
seguridad, la
coordinación,
direccionamiento, la
confianza, etc) La
mayoría de las
aplicaciones en el

154
 mundo real no son
simples y apoyar las
operaciones
complejas, que
requieren para
mantener el estado de
conversación y la
información
contextual. Con el
enfoque de SOAP, los
desarrolladores no
tienen que
preocuparse acerca
de cómo escribir el
código de plomería en
la capa de aplicación
a sí mismos.
 Es más seguro debido
a que su
implementación
siempre o la mayoría
de las veces se hace
del lado del servidor.
 Soporta varios
protocolos y
tecnologías,
incluyendo WSDL,
XSD, SOAP y WS-
Addressing.

Fuente: [Elaboración Propia].

El servicio escogido para la comunicación entre la aplicación móvil y web es

RESTful, debido a que el tiempo de respuesta es menor en consideración al del

155
servicio SOAP, además que el framework escogido para el desarrollo de la
aplicación web utiliza RESTful esto facilita la compatibilidad entre ambas
aplicaciones.

3.4.3. Selección del lenguaje de desarrollo para la construcción de la

aplicación android.

Para la selección del lenguaje de programación que se usara en este proyecto se

optó por dos opciones que se muestran en la tabla 19.

Tabla 19: Selección del lenguaje de desarrollo para la aplicación móvil

Lenguajes de programación Ventajas Desventajas

 Java permite a los  El diseño de interfaces

desarrolladores gráficas con awt y
aprovechar la swing no es simple. O
flexibilidad de la Existen herramientas
Programación como el JBuilder que
Orientada a Objetos en permiten generar
el diseño de sus interfaces gráficas de
aplicaciones manera sencilla, pero
Java  El conocimiento sobre tienen un costo
tecnología Java está adicional.
en alto crecimiento en  Para manejo a bajo
el mercado nivel deben usarse
 Debido a que existen métodos nativos, lo
diferentes productos que limita la
de Java, hay más de portabilidad
un proveedor de
servicios.

156
  Permite usar con  Pobre soporte para
facilidad la plataforma programación
de los sistemas orientada a objetos.
Windows, dado que  Dependencia de
tiene acceso complejas y frágiles
prácticamente total a la entradas de registro
API de Windows, COM.
incluidas librerías
actuales.
 Integra el diseño e
Visual Basic implementación de
formularios de
Windows.
 Es uno de los
lenguajes de uso más
extendido, por lo que
resulta fácil encontrar
información,
documentación y
fuentes para los
proyectos.

Fuente: [Elaboración Propia].

El desarrollo de una aplicación móvil que sirva de presentación para los usuarios
será desarrollada bajo el lenguaje de programación Java, ya que este es un lenguaje
independiente del sistema operativo en el cual se trabaje, además que existe una
buena compatibilidad con el lenguaje utilizado para la aplicación web que es PHP.

157
3.4.4. Análisis del segundo incremento

En el segundo incremento se determinan los requerimientos funcionales y no

funcionales además de los actores que participan, a continuación se muestra el
detalle de los mismos.

3.4.4.1. Análisis de requerimientos

 Requerimientos funcionales para el sistema web y móvil.

Creación del módulo de registro y visualización de notas.

 El sistema deberá permitir el registro, eliminación y modificación de

notas de los estudiantes.
 El sistema deberá permitir la visualización de las notas de los
estudiantes.
 Requerimientos no funcionales
 El sistema debe ser orientado a la web y móvil.
 El sistema debe utilizar arquitectura MVC.
 El sistema debe tener una interfaz amigable.

3.4.4.2. Identificación de los actores

Los actores que participan en este incremento son:

 Encargo de escuadrón de evaluación.

 Jefe de escuadrón de evaluación.
 Docente.

Descripción de los actores: Los actores se describen a continuación:

 Jefe de escuadrón de evaluación: Es la máxima autoridad dentro de lo que

viene a ser el escuadrón de evaluación, en este incremento tiene las
siguientes funciones:
Obtención de reportes de notas.

158
  Encargado de escuadrón de evaluación: Es quien se encarga de administrar
los datos personales de los estudiantes, almacena los exámenes que los
docentes entregan junto con las planillas, en el sistema se encargara de
gestionar las notas de los estudiantes.
 Docente: En la institución es quien se encarga de evaluar a los estudiantes,
a ellos se les asignan materias y cursos para que estos para que estos
puedan calificar a los estudiantes, en el sistema se encargaran de registrar
notas, obtener reporte final de las notas y se les asignara una cuenta de
usuario para poder acceder tanto a la aplicación web y móvil.

3.4.5. Diseño

Describe la realización física de los casos de uso y crea una base al modelo de
implementación.

Esta etapa de diseño se divide en dos fases, que son diseño estructural y de
comportamiento.

3.4.5.1.1 Diagramas estructurales

Los diagramas estructurales permitirán visualizar, especificar, construir y

documentar los aspectos estáticos del sistema propuesto.

En esta primera fase se elabora el diseño de los siguientes diagramas:

 Diagramas de clases.
 Diagramas de despliegue.
a) Diagramas de clases
De acuerdo a los requisitos funcionales identificados anteriormente, se ha elaborado
el siguiente diagrama de clases del sistema, mostrado en la figura 69

159

class Diagramas de clases
1
AsignarEspecialidad
- Id: int
- Persona_id: int
- Especialidad_id: int
+ Registrar() : void
N -
1 -
Especialidad
- Id: int
- Nombre: char
- NotaAprobacion: float
+ Registrar() : void
+ Buscar() : void
+ Modificar() : void
+ Eliminar() : void
Diagrama de base de datos
El diagrama de base de datos del sistema, se ha elaborado a partir del diagrama de
clases, se pueden identificar fácilmente las llaves primarias y las llaves foráneas
para una mejor comprensión.
Figura 69: Diagrama de clases
Persona
- Id: int
- CI: char AsignarCargo Cargo
- ApellidoPaterno: char 1 - Id: int 1 - Id: int
N
- ApellidoMaterno: char - Persona_id: int - Nombre: char
- Direccion: char 1 1 - Cargo_id: int
- Telefono: int + Registrar() : void
- Sexo: char + Registrar() : void + Buscar() : void
+ Modificar() : void
+ Registrar() : void + Eliminar() : void
+ Buscar() : void
1
1 + Modificar() : void
+ Eliminar() : void
1
1 Asignarcuentausuario
- id: int
Persona_id: int
- users_id: int Users
N 1
- Id: int
+ Registrar() : void
1 - login: char
AsignarCursoEstudiante
- password: char
Id: int - nivel: int
- Persona_id: int - estado: int
- Curso_id: int
+ Registrar() : void Nota
1
N - Id: int
N - Nota: float
- tipoevaluacion: char
N
- Materia_id: int
- asignarcursoestudiante_id: int
1 Asignarmateriadocente
1
+ Registrar() : void
- Id: int
Curso + Buscar() : void
- Persona_id: int
+ Modificar() : void
- Id: int - materia_id: int
N + Eliminar() : void
- Gestion: int
- Paralelo: char N + Registrar() : void
- Especialidad_id: int
N
1
+ Registrar() : void
+ Buscar() : void Materia
+ Modificar() : void
+ Eliminar() : void - Id: int 1
- codmateria: char
- nombremateria: int
- sigla: char
+ Registrar() : void
+ Buscar() : void
+ Modificar() : void
+ Eliminar() : void
Fuente: [Elaboración Propia]
160
La figura 70 muestra el diagrama de base de datos del sistema.

Figura 70: Diagrama de base de datos del sistema

Fuente: [Elaboración Propia].

b) Diagramas de despliegue

Los diagramas de despliegue nos permiten ver los dispositivos que interactúan entre
sí para el funcionamiento del sistema y qué tipo de información se envían unos a
otros.

161
En la figura 71 podemos observar como los dispositivos están conectados y que
parámetros recién o se envían.

Figura 71: Diagramas de despliegue

deployment Diagramas De Despliegue

Serv idor Base

de Datos MySQL
Router TCP/IP

Respuesta
HTTP-GET
Solicitud Restful
(HTTP-POST) Serv idor Web
IP Apache

IP
Sw itch
IP

IP
Clientes
Dispositiv os
Cliente Laptop Mov iles Android

Clientes PC

Fuente: [Elaboración Propia].

En la representación del diagrama de despliegue para el sistema propuesto, se

puede observar como varios dispositivos a través de una conexión de Red (Wi-fi o
Ethernet) están conectados al servidor web apache es decir mediante un protocolo
HTTP pueden acceder al servicio que proporciona este servidor que es donde se
encontrara alojado el sistema propuesto, también tienen acceso mediante un

162
protocolo IP/TCP al servidor de base de datos, pero no de manera directa sino
mediante la interfaz que proporcionara el sistema propuesto.

En este caso tenemos a la aplicación web como servicio y a la aplicación móvil como
cliente, la aplicación móvil consumirá el servicio proporcionado por la aplicación web
a través de un servicio Restful.

3.4.5.2. Diagramas de comportamiento

Los diagramas de comportamiento se emplean para visualizar, especificar, construir

y documentar los aspectos dinámicos del sistema.

En esta segunda fase se elabora el diseño de los siguientes diagramas:

 Diagramas de casos de uso.

 Diagramas de comunicación.

Casos de uso del sistema

En base a los requerimientos funcionales determinados en secciones anteriores y

utilizando los actores encontrados, se ha determinado el siguiente diagrama de
casos de uso para el sistema propuesto.

163
 Figura 72: Diagrama de casos de uso de la aplicación móvil

uc Caso de uso de la aplicacion mov il

Casos de uso de la aplicacion movil

Ingresar a la
aplicacion mov il

Docente

Registrar Notas
Encargado de
escuadrón de
ev aluación

Jefe de escuadrón
de ev aluación
Gestionar Notas

«include»
«include»

Modificar
Eliminar

Fuente: [Elaboración Propia].

Caso de uso Registrar Notas

Figura 73: Caso de uso registrar notas

uc Registrar Notas

Caso de uso registrar notas

Registrar Notas
Encargado de escuadron
de ev aluacion
Docente

Jefe de escuadron de
ev aluacion

Fuente: [Elaboración Propia].

164
Especificación de casos de uso: A continuación se muestra una especificación
del caso de uso registrar notas de acuerdo a su función y actores.

Tabla 20: Descripción caso de uso registrar notas

Nombre de caso de uso: Registrar notas

Actor: Jefe de escuadrón de evaluación,
Docente y Encargado de escuadrón de
evaluación.
Función: Permitir registrar las notas
correspondientes a las materias que este
o haya cursado el estudiante.
Descripción: Los tres actores mencionados podrán
realizar el registro de las notas.

Fuente: [Elaboración Propia].

Caso de uso gestionar notas

Figura 74: Caso de uso Gestionar Notas.

uc Gestionar notas

Caso de uso gestionar notas

Gestionar Notas

Jefe de escuadron de
ev aluacion
«include» «include»
Encargado de escuadron
de ev aluacion

Eliminar Modificar

Fuente: [Elaboración Propia].

165
Especificación de casos de uso: A continuación se muestra una especificación
del caso de uso gestionar notas a su función y actores.

Tabla 21: Descripción caso de uso gestionar notas

Nombre del caso de uso: Gestionar notas

Jefe de escuadrón de evaluación y
Actor:
encargado de escuadrón de evaluación.
Permitir la gestión de las notas, es decir
Función: la búsqueda, modificación y eliminación
de las notas.
Jefe de escuadrón de evaluación y
encargado de escuadrón de evaluación:
El sistema permitirá la búsqueda de notas
ya sea por estudiante, asignatura o curso.
Descripción:
La modificación o eliminación de estas
notas se hará a un determinado
estudiante.

Fuente: [Elaboración Propia].

166
Caso de uso Administrar Notas en la aplicación web

Figura 75: Caso de uso Administrar Notas en la aplicación web

uc Administrar Notas

Caso de uso administrar notas

Modificar

«extend»
Administrar Notas Listar Notas

«extend»
Eliminar
Jefe de escuadrón «include»
de ev aluación

Registrar Notas

Encargado de
escuadrón de
ev aluación

Fuente: [Elaboración Propia].

Especificación de casos de uso: A continuación se muestra una especificación

del caso de uso gestionar notas a su función y actores.

Tabla 22: Descripción caso de uso administrar notas en la aplicación web

Nombre del caso de uso: administrar notas en la aplicación web

Jefe de escuadrón de evaluación y
Actor:
encargado de escuadrón de evaluación.
Permitir la gestión de las notas, es decir
Función: la búsqueda, modificación y eliminación
de las notas.
Jefe de escuadrón de evaluación y
encargado de escuadrón de evaluación:
Descripción:
El sistema permitirá la búsqueda de notas
ya sea por estudiante, asignatura o curso.

167
 La modificación o eliminación de estas
notas se hará a un determinado
estudiante.

Fuente: [Elaboración Propia].

Diagramas de comunicación

Este diagrama es una versión simplificada del diagrama de colaboración de la

versión tradicional de UML, nos permiten ver las interacciones de los objetos
mediantes mensajes.

Caso de uso registrar notas

Figura 76: Diagrama de comunicación registrar notas.

sd Administrar Notas

1: Accede a la vista()
1.1: Accede a la vista()
Vista Registrar
Notas

Docente Encargado de escuadrón

de ev aluación
1.2: Cargar Parametros()

1.3: Cargar Parametros()

Controlador Notas Ciclo Registro de

notas

1.4: Envio de parametros() 1.5: Fin registro()

Registro de nota

Fuente: [Elaboración Propia].

168
Caso de uso gestionar notas

Figura 77: Diagrama de comunicación gestionar notas

sd Gestionar Notas

1: Acceder a la vista() 1.1: Acceder a la vista()

Vista Gestionar
Notas

Jefe de escuadrón de Encargado de escuadrón

ev aluación de ev aluación

1.2: Cargar Parametros()

1.5: Nota a eliminar() 1.3: Nota a modificar()

Eliminar Controlador Modificar
Gestionar Notas
1.4: Nota Modificada()

1.6: Notificación de nota eliminada()

Fuente: [Elaboración Propia].

Caso de uso registrar notas

Figura 78: Diagrama de comunicación administrar notas en la aplicación web

sd Administrar Notas

1: Ingresar a la vista()
Vista Administrar 1.1: Ingresar a la vista()
Notas

Encargado de escuadrón Jefe de escuadrón de

de ev aluación ev aluación

1.2: Cargar Parametros()

1.3: Acceder a la funcion() 1.4: Cargar Parametros()

Listar Notas 1.8: Listado de notas() Controlador Notas Ciclo Registrar

Notas

1.6: Notas eliminadas()

1.7: Notas Modificadas()
1.5: Fin Registro()

Modificar Eliminar Registro Nota

Fuente: [Elaboración Propia].

169
3.4.6. Codificación

Para la codificación del sistema se utilizan las anteriores etapas que son análisis y
diseño, para elaborar las interfaces e implementarlas en funcionamiento.

3.4.6.1. Arquitectura de desarrollo de software de la aplicación móvil

En la siguiente figura se muestra el diseño de la arquitectura basada en la

arquitectura cliente servidor.

Figura 79: Diseño de la arquitectura de software de la aplicación móvil.

deployment ClienteServ idor

Arquitectura Cliente Servidor

Nivel de aplicación
Nivel de Presentación

«interface» Peticion HttpPost «device» Aplicación Web

Aplicación Móv il (TCP/IP) Router Solicitud Entrante HttpPost
«device»
+ PostProcesos() : void
Dispositiv o + Gestionar Notas() : void
Móv il + Registrar Notas() : void
+ Ver Notas PDF() : void

Cliente Serv idor (Aplicación Web)

Respueta a la consulta

Nivel de base de datos

Conexión
LocalHost

Base de Datos Consultas

Politécnico MySQL a la BD

Serv idor de base de datos

Fuente: [Elaboración Propia].

170
Luego de haber diseñado el segundo incremento la arquitectura de desarrollo de
software de la aplicación web quedo de la siguiente manera:

Figura 80: Arquitectura de software segundo incremento de la aplicación web.

Fuente: [Elaboración Propia].

Se instala la aplicación en el dispositivo móvil y permite acceder a la aplicación, en

la figura 81 se muestra el icono.

171
 Figura 81: Icono de la aplicación móvil en el dispositivo

Fuente: [Elaboración Propia].

3.4.6.2. Interfaces del sistema

Permite al usuario colocar su nombre de usuario y contraseña para iniciar sesión,

en la

Figura 82 se muestra la interfaz, con los cuadros de texto y el botón para ingresar
como usuario dentro del sistema.

172
 Figura 82: Interfaz ingresar al sistema

Fuente: [Elaboración Propia].

Interfaz del menú del estudiante

Se puede observar que al ingresar el estudiante se le muestra los datos de este que
ha sido logueado en la figura 83 se ve como el usuario ha sido identificado como
estudiante y se muestra el menú correspondiente con la opción de ver notas en pdf.

173
 Figura 83: Interfaz del menú del estudiante

Fuente: [Elaboración Propia].

Interfaz del personal de escuadrón de evaluación.

Esta interfaz le pertenece tanto al jefe de escuadrón de evaluación como al

encargado de escuadrón de evaluación, una vez logueado dentro de la aplicación
se le muestra el menú de la figura 84.

174
 Figura 84: Interfaz del personal del escuadrón de evaluación.

Fuente: [Elaboración Propia].

Interfaz de registrar notas

En esta interfaz se muestra en una lista desplegable los cursos registrados, los
estudiantes pertenecientes a ese curso y las materias que pertenecen a ese curso,
como se puede observar en la figura 85.

175
 Figura 85: Interfaz de registrar notas

Fuente: [Elaboración Propia].

Interfaz de gestionar notas

En esta interfaz nos muestra en una lista desplegable los cursos registrados, los
estudiantes pertenecientes a estos y la materia la cual queremos ver las notas que
se tienen registradas, como se observa en la figura 86.

176
 Figura 86: Interfaz de gestionar notas

Fuente: [Elaboración Propia].

Interfaz de mostrar notas

En esta interfaz nos muestra un listado de las notas de la materia escogida en la

anterior interfaz, en la figura 87 se puede observar que cuando elegimos alguna de
estas notas nos muestra un menú con 3 opciones: Eliminar, modificar y cancelar.

177
 Figura 87: Interfaz de mostrar notas

Fuente: [Elaboración Propia].

Interfaz de modificar nota

En la figura 88 se puede observar la interfaz donde se muestra un campo de texto

que se debe llenar con la nueva nota que va a reemplazar a la anterior escogida en
la figura 87.

178
 Figura 88: Interfaz de modificar nota

Fuente: [Elaboración Propia].

3.4.7. Pruebas

En esta etapa se realiza pruebas de funcionalidad por casos de uso tomando los
casos de uso correspondientes al segundo incremento.

179
 Tabla 23: Prueba: Desarrollo de una aplicación móvil para la gestión de
calificaciones

CONDICIONES RESULTADO RESULTADO

CASO DE USO
INICIALES ESPERADO OBTENIDO
 Se requiere El sistema obtiene El sistema muestra
tener información un mensaje
instalada la necesaria para el notificando:
aplicación proceso de registro
Si el registro fue
Android en el de notas, y se
ingresado
dispositivo procede al registro
correctamente o no.
móvil de las notas desde
 Loguearse la aplicación móvil.
con una
cuenta de
Registrar Notas usuario en la
aplicación
móvil.
 El sistema
recupera la
información
del curso,
estudiante y
asignatura a
calificar.

 Se requiere El sistema obtiene El sistema devuelve

tener información un mensaje
instalada la necesaria para el notificando la
Gestionar Notas
aplicación proceso de gestión acción realizada por
Android en el de notas, y se el usuario ya sea
procede ya sea a tanto para

180
 dispositivo la modificación o modificación como
móvil eliminación de las para eliminación de
 Loguearse notas desde la notas.
con una aplicación móvil.
cuenta de
usuario en la
aplicación
móvil.
 El sistema
recupera la
información
del curso,
estudiante y
asignatura a
gestionar.

Fuente: [Elaboración Propia].

3.5. GENERACIÓN DE REPORTES DE ACUERDO A LAS

NECESIDADES DEL CASO DE ESTUDIO

En este punto se procederá a la realización de reportes que el sistema brindara a

los usuarios.

3.5.1. Análisis del tercer incremento

3.5.1.1. Determinación de tipos de reportes que se requieren para el
caso de estudio

Los tipos de reportes que fueron identificados gracias a la entrevista hecha al

personal de escuadrón de evaluación se pueden ver con más detalle en el anexo
“B”.

181
Tipos de reportes identificados:

 Reporte de notas por estudiante

 Reporte de notas por curso
 Reporte de estudiantes
 Reporte de docentes
 Reporte de cursos y que estudiantes pertenecen a este.
 Reporte de materias y a que curso pertenecen.
 Reportes estadísticos de aprobación y reprobación.
 Reportes de estudiantes de 2do turno.
 Reportes por año, semestre o trimestre.
 Reporte de estudiantes aprobados y reprobados por curso, materia o
especialidad.

A continuación se muestra los actores identificados para este incremento:

 Jefe de escuadrón de evaluación

 Estudiante

Descripción de los actores: Los actores se describen a continuación.

Jefe de escuadrón de evaluación: Es la máxima autoridad dentro de lo que viene

a ser el escuadrón de evaluación, en este incremento tiene la función de generar
reportes de acuerdo a las necesidades del departamento de escuadrón de
evaluación.

Estudiante: Dentro del sistema es la persona que puede acceder al sistema

mediante una cuenta de usuario que se le asignara al momento de su registro, tiene
como opción la de poder ver un reporte de sus notas actuales.

182
 Figura 89: Diagrama de casos de uso del tercer incremento

uc Tercer incremento

Diagramas de casos de uso 3er incremento

Generar Reportes

Jefe de escuadrón de
ev aluación

Ver Notas PDF

Estudiante

Fuente: [Elaboración Propia].

Especificación de casos de uso: A continuación se muestra una especificación
de casos de uso del tercer incremento:
Tabla 24: Descripción caso de uso generar reportes.

Nombre de caso de uso: Generar Reportes

Actor: Jefe de escuadrón de evaluación.
Función: Permite la generación de los distintos
reportes que se identificaron en este
incremento, además de la opción de
poder imprimir dichos reportes con
resultados estadísticos.
Descripción: El jefe de escuadrón de evaluación debe
ingresar al sistema con su respectivo
login y password para poder generar
dichos reportes a través de la aplicación
web.
Fuente: [Elaboración Propia].

183
 Tabla 25: Descripción de caso de uso

Nombre de caso de uso: Ver notas PDF

Actor: Estudiante.
Función: Permite al estudiante obtener un reporte
de sus notas, además de poder
descargar dicho reporte en un PDF.
Descripción: El estudiante debe ingresar al sistema
con su respectivo login y password para
poder generar dichos reportes a través de
la aplicación web y/o móvil.

Fuente: [Elaboración Propia].

3.5.2. Determinación de campos necesarios para cada tipo de reporte que se

quiera para el caso de estudio

Una vez identificados los reportes necesarios, se procede a la identificación de los

campos necesarios que se verán en estos reportes, a continuación se muestran los

campos necesarios para cada uno de los reportes:

 Reporte de notas por estudiante (Materia, Primer Parcial, Segundo Parcial,

Apreciación Docente, Parcial Final, Segunda Instancia y Nota Final).
 Reporte de notas por curso (Nombre del estudiante, Materia, Primer Parcial,
Segundo Parcial, Apreciación Docente, Parcial Final, Segunda Instancia y
Nota Final).

3.5.3. Elaboración del módulo de generación de reportes

En este punto se procede a la implementación del módulo de generación de

reportes.

184
En la siguiente figura se puede observar la codificación del módulo de generación
de reporte de notas.

Figura 90: Codificación de módulo de generación de reporte de notas

Fuente: [Elaboración Propia].

Una vez codificado el módulo de generación de reportes se procede a la

implementación de este a la aplicación web, en la figura 90 tenemos como resultado
la vista que genera dicho módulo de generación de reportes.

Figura 91: Reporte de notas por estudiante

Fuente: [Elaboración Propia].

185
En la siguiente figura se muestra el mismo reporte solo que este lo genera la
aplicación móvil, es un PDF que permite ver las notas a los estudiantes.

Figura 92: Reporte de notas por estudiante en PDF

Fuente: [Elaboración Propia].

3.6. REALIZACIÓN DE PRUEBAS PARA EL SISTEMA

3.6.1. Pruebas de conectividad
En la siguiente tabla 26 se tienen las pruebas que se realizaron al sistema, y los
resultados obtenidos.

Tabla 26: Pruebas de conectividad.

Ping Principal. Ping destino Paquete Paquete Paquete Resultado

perdidos enviado recibido
10.0.0.2 10.0.0.6 0 4 4 Factible.
10.0.0.2 10.0.0.8 0 4 4 Factible.
10.0.0.2 10.0.0.9 0 4 4 Factible.
10.0.0.2 10.0.0.12 0 4 4 Factible.
10.0.0.2 10.0.0.13 0 4 4 Factible.
Fuente: Elaboración Propia.

186
Esta prueba permite verificar que la información que se intercambia entre el sistema
web y la aplicación móvil se envía y se recibe en la misma proporción.

Después de realizar las pruebas de conectividad se demuestra que se cumple con

los puntos de conectividad, ya que los paquetes enviados son iguales a la cantidad
de paquetes recibidos.

3.6.2. Pruebas de integración

En la siguiente figura se puede observar cómo se realiza la prueba de integración
de los distintos casos de usos por niveles, es decir tomando en cuenta la
dependencia uno de otro de caso de uso.

Figura 93: Prueba de integración por niveles

Fuente: [Elaboración Propia].

187
Nivel 0

El nivel 0 es un caso especial en el cual el caso de uso que pertenece a este nivel
no depende de nadie, es decir es el único caso de uso independiente.

Tabla 27: Prueba de integración caso de uso administrar cargos

CASO DE
CASO DE USO USO PRUEBAS ESTADO
ANTECESOR

No tiene caso
Administrar
de uso Ninguno. Satisfactorio
Cargos
antecesor.

DESCRIPCIÓN

En este caso de uso se administran los cargos existentes dentro de la

institución y que serán asignados a los distintos usuarios, los cuales no
necesitan datos de otros casos de uso.

Fuente: [Elaboración Propia].

Nivel 1

Son los casos de uso que dependen del nivel 0, en el cual se administran los
estudiantes, docentes y administrativos se utilizan para ingresar al sistema y se
puede acceder a los casos de uso de acuerdo al tipo de usuario.

Tabla 28: Prueba de integración caso de uso administrar estudiantes.

CASO DE CASO DE USO

PRUEBAS ESTADO
USO ACTUAL ANTECESOR

 Registro de
Administrar Administrar Estudiante.

Satisfactorio
Estudiantes. Cargos Comprobar tipo
de usuario

188
 DESCRIPCION

El caso de uso actual depende de los registros de cargos, en el caso de

que no existan cargos, no se podrá ingresar al sistema para realizar la
administración de estudiantes

Fuente: [Elaboración Propia].

Tabla 29: Prueba de integración caso de uso administrar docentes.

CASO DE CASO DE USO

PRUEBAS ESTADO
USO ACTUAL ANTECESOR

 Registro de
Administrar Administrar Docente.

Satisfactorio
Docentes. Cargos Comprobar tipo
de usuario

DESCRIPCION

El caso de uso actual depende de los registros de cargos, en el caso de

que no existan cargos, no se podrá ingresar al sistema para realizar la
administración de docentes.

Fuente: [Elaboración Propia].

189
 Tabla 30: Prueba de integración caso de uso administrar administrativos.

CASO DE USO CASO DE USO

PRUEBAS ESTADO
ACTUAL ANTECESOR

 Registro de
Administrar Administrar Administrativo.

Satisfactorio
Administrativos. Cargos Comprobar tipo
de usuario

DESCRIPCION

El caso de uso actual depende de los registros de cargos, en el caso de

que no existan cargos, no se podrá ingresar al sistema para realizar la
administración de administrativos.

Fuente: [Elaboración Propia].

Nivel 2

Este nivel depende del nivel 0 y del nivel 1, para poder administrar materias y
especialidades se debe previamente haber administrado los cargos, docentes,
administrativos y estudiantes.

Tabla 31: Prueba de integración caso de uso administrar materias.

CASO DE USO CASO DE USO

PRUEBAS ESTADO
ACTUAL ANTECESOR

 Administrar
Cargos  Registro de
Administrar  Administrar Materias.
Satisfactorio
Materias. Estudiantes  Listado de
 Administrar Materias
Docentes

190
  Administrar  Asignación de
Administrativ materias a
os docentes.

DESCRIPCION

El caso de uso actual depende de los registros de cargos, docentes,

estudiantes y administrativos en el caso de que no existan alguno de estos
casos de uso, no se podrá realizar la administración de materias.

Fuente: [Elaboración Propia].

Tabla 32: Prueba de integración caso de uso administrar especialidades.

CASO DE USO CASO DE USO

PRUEBAS ESTADO
ACTUAL ANTECESOR

 Administrar
Cargos  Registro de

 Administrar Especialidades.

Estudiantes  Listado de
Administrar
 Administrar Especialidades Satisfactorio

Especialidades.
Docentes Asignación de

 Administrar Especialidades a

Administrativ estudiantes.

os
DESCRIPCION

El caso de uso actual depende de los registros de cargos, docentes,

estudiantes y administrativos en el caso de que no existan alguno de estos
casos de uso, no se podrá realizar la administración de especialidades.

Fuente: [Elaboración Propia].

191
Nivel 3

Este nivel depende del nivel 1 y del nivel 2, para poder Administrar Cursos se debe
previamente haber registrado estudiantes, docentes, especialidades,
administrativos y materias.

Tabla 33: Prueba de integración caso de uso administrar cursos.

CASO DE USO CASO DE USO

PRUEBAS ESTADO
ACTUAL ANTECESOR

 Administrar
Materias.  Registro de

 Administrar Cursos.

Especialidad  Listado de

es Cursos.
Administrar  Administrar  Asignación de
Satisfactorio
Cursos. Estudiantes Cursos a

 Administrar estudiantes.

Docentes  Asignación de

 Administrar materias a

Administrativ cursos.

os
DESCRIPCION

El caso de uso actual depende de los registros de materias,

especialidades, estudiantes, docentes y administrativos en el caso de que
no existan alguno de estos casos de uso, no se podrá realizar la
administración de cursos.

Fuente: [Elaboración Propia].

Nivel 4

Este nivel depende del nivel 3 y del nivel 1, para poder Administrar Notas se debe
previamente haber registrado cursos y administrativos.

192
 Tabla 34: Prueba de integración caso de uso administrar notas.

CASO DE USO CASO DE USO

PRUEBAS ESTADO
ACTUAL ANTECESOR

 Administrar  Registro de
Administrativ Notas.
Administrar

os. Satisfactorio
Notas. Listado de Notas.
 Administrar  Gestión de notas.
Cursos.
DESCRIPCION

El caso de uso actual depende de los registros de administrativos y cursos

en el caso de que no existan alguno de estos casos de uso, no se podrá
realizar la administración de notas.

Fuente: [Elaboración Propia].

Nivel 5

Este nivel depende del nivel 41, para poder Obtener reportes se debe previamente
haber registrado las notas.

Tabla 35: Prueba de integración caso de uso obtener reportes.

CASO DE USO CASO DE USO

PRUEBAS ESTADO
ACTUAL ANTECESOR

 Obtener reporte
de notas por
curso.
Administrar  Administrar  Generar reportes
Satisfactorio
Notas. Notas. estadísticos.

193
 DESCRIPCION

El caso de uso actual depende de los registros de notas en el caso de que

no existan notas, no se podrá realizar la obtención de reportes.

Fuente: [Elaboración Propia].

3.7. DEMOSTRACIÓN DE LA HIPÓTESIS

La hipótesis planteada de este proyecto es la siguiente: “La intranet corporativa con

comunicación android, permitirá reducir los tiempos de entrega de reportes y el
riesgo de pérdida de información y de notas de los estudiantes militares”. Para
demostrar la hipótesis es necesario analizar las variables dependientes de la
hipótesis.

 Tiempo de entrega de reportes

 Riesgo de pérdida de información personal y de calificaciones de estudiantes
militares.
3.7.1. Demostración de la primera variable dependiente
En la demostración se hace uso de un tiempo promedio invertido para cada
actividad que presenta el sistema en el tiempo de obtención de entrega de reportes
necesarios por el escuadrón de evaluación. Esto permitirá realizar el análisis del
tiempo en la institución sin el uso del sistema y los tiempos que se tiene con el uso
del sistema desarrollado.

Las actividades de la siguiente tabla se las ha obtenido del modelado de negocio

actual y alternativo reflejado en el marco práctico en el punto 3.1.1 (modelo de
negocio actual) y en el punto 3.2.2 (modelo de negocio alternativo).

El tiempo promedio se ha obtenido por medio de entrevistas con las personas

involucradas y responsables de llevar a cabo las tareas correspondientes y
realizando observaciones directas, y mediante un cuestionario realizado al personal
involucrado.

194
 Tabla 36: Pasos para los procesos de entrega de reportes

Pasos sin Tiempo sin Pasos con Tiempo con

Actividad
sistema sistema [min] sistema sistema [min]

Registrar
Nombre, CI,
Apellido
Se pide la
Proceso de paterno,
información
registro de 10 min. Apellido 1 min.
personal del
estudiantes materno,
estudiante nuevo.
Dirección,
Teléfono y
Sexo.

Proceso de Se pide la Registrar

registro de información Nombre, CI,
docentes personal del Apellido
docente paterno,
perteneciente a la 10 min Apellido 1 min
institución. materno,
Dirección,
Teléfono y
Sexo.

Se procede a Se procede a
registrar todas las registrar todas
materias que se las materias
Proceso de
encuentran en la existentes con el
registro de 30 min. 10 min.
malla curricular de formulario de
materias
la institución en registro
una hoja de excel. proporcionado
por el sistema

195
 Se procede a Se procede a
registrar todos los registrar todos
cursos que existen los cursos
Proceso de en la institución en existentes así
registro de hojas de Excel 30 min mismo 10 min
cursos asignándoles a
que
especialidad
pertenecen

Se registran las Se procede al

especialidades en registro de todas
una hoja Excel las
especialidades
Proceso de
existentes
registro 5 min 2 min
dentro de la
Especialidades
institución con el
formulario
brindado por el
sistema.

El docente se El Docente
encarga de realizar ingresa al
las evaluaciones módulo de
correspondientes, registro de
Registro de estas son notas,
120 min 20 min.
notas entregadas al selecciona la
encargado de materia que
escuadrón de tiene asignada y
evaluación y este procede a la
transcribe estas evaluación

196
 notas a una hoja
Excel.

Se buscan todos Se selecciona el

los archivos Excel tipo de reporte
que contengan que se necesita
Reportes 35 min. 1 min
información sobre y procede a la
las notas para impresión de
realizar un reporte. este.

Total en horas: 4 hrs y 0 min. Total en Minutos 45 minutos

:

Fuente: [Elaboración Propia].

Después de haber analizado el tiempo invertido en la realización de los proceso de

registro y obtención de reportes, se concluye que: El tiempo invertido sin el uso del
sistema es aproximadamente de 4 horas y 0 minutos para realizar todos los
procesos, con el uso del sistema se realiza aproximadamente en 45 minutos, por
lo tanto el tiempo invertido con el uso del sistema es relativamente menor que sin el
uso del sistema.

3.7.2. Demostración de la segunda variable dependiente

Para la demostración de la segunda variable se utilizará una matriz de

riesgos, donde se evaluará una o más amenazas, y también las vulnerabilidades
que se pueden presentar en el uso del sistema o sin el uso del sistema.

Se cuenta con la siguiente tabla de valores que utilizaremos para la elaboración

de la matriz de riesgos, ver Tabla 37:

197
 Tabla 37: Cuadro de valores para la matriz de riesgos.
PROBABILIDAD

I 1 2

M MUY ALTO ALTO

P
A
C 3 4
T
MEDIO BAJO
O

RIESGO

Fuente: [Elaboración Propia].

En la tabla siguiente se contemplara la comparación de las amenazas que existen

antes y después de la implementación del sistema para demostrar que se reduce el
nivel de riesgo en el registro y almacenamiento de información de calificaciones y
datos personales de los estudiantes militares.

Es necesario mencionar que para el desarrollo de la tabla tanto con sistema como
sin sistema se tomó en cuenta las tablas de matriz de riesgo anteriormente
presentadas.

Cabe resaltar que la estimación del nivel de riesgo para el sistema propuesta para
el procedimiento de evaluación académica se hace en base a experiencia del
personal que durante varias gestiones ha estado involucrado en esta actividad, ver
tabla 38.

198
 Tabla 38: Matriz de riesgos

R
P P I
I MECANISMOS DE I
R R E
AMENAZA VULNERABILIDAD M RIESGO M
O CONTROL O S
P P
B B G
O

No se tiene un Al momento de
respaldo de la realizar el registro de
información los estudiantes estos
Registro de
registrada, porque 2 1 1.5 se almacenan en una 4 1 2.5
Estudiantes.
puede llegar a base de datos, la cual
dañarse los tiene opción a un
archivos manuales backup.
de los registros.
El registro en el
Registro de
Pueden llegar a sistema mantendrá
planillas de
dañarse o 2 1 1.5 seguro la información, 4 1 2.5
notas forma
extraviarse. en backup y
manual.
disponible para
cualquier momento.

Búsqueda de
Los reportes
información La búsqueda se la
brindaran información
sobre el realiza manualmente
rápida y detallada del
rendimiento y se pierde bastante 1 4 2,5 4 2 3
rendimiento
académico de tiempo en buscar la
académico de todos
los información.
los estudiantes.
estudiantes.

RIESGO
SIN SISTEMA 1.83 CON SISTEMA 2.67
TOTAL

Fuente: [Elaboración Propia].

199
Utilizando los valores para la matriz de riesgos, se realiza el cálculo de la media
del riesgo total sin sistema y con sistema

El riesgo total sin sistema se calcula por la sumatoria de los riesgos en las
vulnerabilidades sobre el número de riesgos evaluados. Y el riesgo total con
sistema se calcula de la sumatoria con sistema, por la sumatoria de los riesgos en
el mecanismo de control sobre el número de mecanismos evaluados.

El resultado nos indica que sin sistema el riesgo total es de 1.83, y con sistema
es de 2.67 y de acuerdo con la tabla 38, el análisis realizado detalla que el riesgo
total es menor con el sistema que con el riesgo total sin sistema o con el sistema
manual.

3.7.3. Demostración de la variable independiente

Para esta demostración se realiza el análisis a través de una muestra de todos los
beneficios que tiene el sistema El sistema de registro y usando aplicación web y
móvil para el proceso de evaluación académica en el Politécnico Militar de
Aeronáutica Subtte Jose Max Ardiles Monrroy. . Calificando como un beneficio con
la palabra “Sí”, y rechazando el beneficio con la palabra “No”.

Tabla 39: Tabla comparativa de beneficios del sistema propuesto

Numero
de Factores Tomados en Cuenta Como Beneficio Actual Sistema
factores

Se realiza el registro y el control de cuentas

1 No Si
de los usuarios, por parte del administrador.

Se realiza el control y registro de los datos

2 Si Si
personales del personal de la institución.

Se realiza el registro de información de

3 Si Si
materias existentes en la institución.

200
 Numero
de Factores Tomados en Cuenta Como Beneficio Actual Sistema
factores

Se realiza el control de registro de

4 No Si
especialidades existentes.

Se realiza la asignación de cursos a

5 estudiantes. Si Si

Se realiza el control y asignación de

6 especialidades al personal de la institución Si Si

Se realiza el control de evaluación sobre el

7 No Si
campo apreciación docente.

Permite obtener reportes de notas

8 No Si
clasificados por estudiante, cursos o gestión.

Permitir el acceso a los usuarios al sistema

9 usando una aplicación móvil, para realizar No Si
consultas de notas y datos personales.

TOTAL BENEFICIOS 4 (Si) 9 (Si)

Fuente: [Elaboración Propia].

Teniendo como resultado del análisis de estas muestras, se concluye que el total
de beneficios por el proceso del sistema manual tiene la cantidad de 4, y con el
proceso de la herramienta la cantidad es de 9. Estos resultados se tomarán en
cuenta en el cálculo de estadístico T para realizar la aceptación o rechazo de la
hipótesis que está detallado más adelante en el documento

201
3.7.4. Definición de la hipótesis
Para la definir la hipótesis se considera el análisis de aceptación y rechazo de la
misma, haciendo referencia a un Pn que representa una probabilidad, en nuestro
caso tenemos que:

 P1 = Los procedimientos manuales usados en la actualidad para el proceso

de evaluación académica del Politécnico Militar de Aeronáutica Subtte Jose
Max Ardiles Monrroy.
 P2 = El sistema de registro y utilizando una aplicación web y móvil el
proceso de evaluación académica del Politécnico Militar de Aeronáutica
Subtte Jose Max Ardiles Monrroy.

Hipótesis Nula (Ho).

 H0: P1 = P2 (El sistema manual usado en la actualidad para el proceso de

evaluación académica del Politécnico Militar de Aeronáutica Subtte Jose Max
Ardiles Monrroy. es igual al sistema de registro propuesto usando una
aplicación web y móvil para el proceso de evaluación académica del Politécnico
Militar de Aeronáutica Subtte Jose Max Ardiles Monrroy).Tomando en cuenta
que el sistema actual no genera más beneficios que el sistema no se toma en
cuenta a la hipótesis nula.

Hipótesis Alternativa (Ho).

 H0: P1 > P2 (Sistema manual usado en la actualidad para el proceso de

evaluación académica del Politécnico Militar de Aeronáutica Subtte Jose Max
Ardiles Monrroy. tiene mayores beneficios que el sistema de registro
propuesto usando una aplicación web y móvil para el proceso de evaluación
académica del Politécnico Militar de Aeronáutica Subtte Jose Max Ardiles
Monrroy).

 H1: P1 < P2 (Sistema manual usado en la actualidad para el proceso de

evaluación académica del Politécnico Militar de Aeronáutica Subtte Jose Max
Ardiles Monrroy. tiene menores beneficios que el sistema de registro
propuesto usando una aplicación web y móvil para el proceso de evaluación

202
 académica del Politécnico Militar de Aeronáutica Subtte Jose Max Ardiles
Monrroy).

3.7.5. Calculo estadístico T

Este cálculo permite conocer la aceptación de la hipótesis, teniendo en cuenta que

existe un rango de aceptación. Luego con el dato encontrado con las probabilidades
se ubica si está dentro del rango de aceptación o rechazo.

Para dicho cálculo se utiliza las siguientes formulas:


Xn
P =

 Q = −P

α

 gl = n −

 t =
P −P
∗ ∗
√ n +
n

Donde:

 P = Probabilidad de ocurrencia de uno de los casos.

 X = Numero de aciertos en la muestra de la probabilidad P .
 n = Numero de muestras beneficios analizados .
 Q = Probabilidad de ocurrencia de uno de los casos.

α
= Grado de error

 gl = Grado de libertad.
 t = Valor estadistico para la aceptacion o rechazo de la hipotesis.

num de exitos
P =
tamano de muestra

P = = , → P alcanzó un % de los beneficios de la muestra.

Q = ⁄

203
 num de existos
P =
tamano de muestra

P = = → P alcanzó un % de los beneficios de la muestra.

Q =

Según el cálculo T-student se considera el valor de α de acuerdo con el número

de muestras que se tiene. En este caso, considerándose de una muestra menor
a 100, el valor es de 0.05 para hacer el cálculo del grado de error.

α⁄ = %⁄ → , ⁄ = ,

n = => gl =

t α⁄ , − =t , , 8 = ,

Para los rangos de rechazo de la hipótesis se calcula por el valor del grado
de libertad obtenido y el valor del grado de error; se busca en la tabla y se tienen
los rangos, en este caso es de -2.3060 y 2.3060, es decir, cualquier valor dentro
de este rango demostrará que la hipótesis es nula (H0) y la aceptación (hipótesis
alternativa H1) de la hipótesis se encuentra fuera de estos rangos

P1 = 4/9 = 0.44 Entonces Q1 = 1 - (5/9) = 0.66

P2 = 9/9 = 1 Entonces Q2 = 1 - 1 = 0

⁄ − − ⁄ − ⁄
t = = =
,
√ , +
√ ⁄ ∗ ⁄ + ∗

t =|− , |

|− , |< ,

204
 Figura 94: Campana de Gauss.

Fuente: [Elaboración propia].

Después de haber realizado el análisis del cálculo del T-Student, se puede indicar
que el valor obtenido está en el rango de la hipótesis alternativa H1, donde se tiene
P1 < P2 concluyendo que dicha hipótesis alternativa H1 indica que: “Los
procedimientos manuales usados en la actualidad para el proceso de evaluación
académica del Politécnico Militar de Aeronáutica Subtte Jose Max Ardiles Monrroy.
Tiene menores beneficios que el sistema de registro propuesto, por lo que queda
demostrado que se rechaza la hipótesis nula H0 y se acepta la alternativa H1
por tanto la herramienta propuesta es mejor que el procedimiento actual que se
tiene en la institución.

205
4. ANÁLISIS DE VIABILIDAD
4.1. VIABILIDAD TÉCNICA

Para la parte del análisis de viabilidad se busca la disponibilidad de tecnología que

satisfaga las necesidades de todo el funcionamiento en la construcción de la
herramienta del sistema y la aplicación móvil para el proceso de gestión de
calificaciones para el Politécnico Militar de Aeronáutica José Max Ardiles Monrroy.

Para desarrollar la herramienta de la aplicación web y móvil el proceso de gestión

de calificaciones, ha sido necesaria la utilización de los siguientes componentes de
hardware y software.

Los requerimientos de hardware para el servidor del sistema se especifican a

continuación:

Tabla 40: Requisitos de hardware para el funcionamiento del servidor del sistema.
Requerimiento Requerimiento Requerimiento
Hardware utilizado
Mínimo Disponible Ideal

Disco Duro. 2 GB (libres) 200Gb. 350 Gb. 1 Tb.

Core i2
Microprocesador. Core i2 2.27Ghz. Core i7 3.0Ghz.
2.27Ghz.

Tarjeta de Video. 64 Mb. 64 Mb. 128 Mb.

Monitor. 14 pulgadas. 14 pulgadas. 16 pulgadas.

BTC

Teclado. Compatible con OM 02 – Delux. K1890U – Delux

Windows.

Memoria RAM. 512 MB. 2GB. 4 GB.

206
 MiniDIM con 3
Mouse. M126 – Delux. M391 – Delux.
botones.

Fuente: [Elaboración Propia].

En base a los requerimientos establecidos para el servidor se especifican los

requerimientos para el cliente los cuales se indican a continuación.

Tabla 41: Requisitos de hardware para el cliente PC.

Requerimiento Requerimiento Requerimiento
Hardware utilizado
Mínimo Disponible Ideal

200 MB (libres)
Disco Duro. 350 GB. 1 Tb.
100Gb.

Microprocesador. Core i2 2.27Ghz. Core i3 2.27Ghz. Core i7 3Ghz

Tarjeta de Video. 128 Mb. 256 Mb. 512 Mb.

Monitor. 14 pulgadas. 14 pulgadas. 16 pulgadas.

BTC

Teclado. Compatible con K5015 – Delux. K1890U – Delux.

Windows.

Memoria RAM. 512 MB. 2 GB. 4 GB.

MiniDIM con 3
Mouse. M126 – Delux. M391 – Delux.
botones.

Fuente: [Elaboración Propia].

Finalmente se muestran en la tabla 42 los requerimientos de hardware necesarios

para la aplicación móvil.

207
 Tabla 42: Requisitos de hardware de la aplicación móvil.
Requerimiento Requerimiento Requerimiento
Hardware utilizado
Mínimo Disponible Ideal

Qualcomm Qualcomm
Procesador Snapdragon MSM8255 dual-core de 1GHz Snapdragon 800
1 GHz 2.3 GHz

Memoria 1GB 2GB 4GB

Memoria RAM 320MB 512MB 2GB

TFT LCD 480 x TFT LCD IPS LED

LCD 320 x 480 pixels,
Pantalla 800 pixels, 4.0 1080 x 1920
3 pulgadas
pulgadas píxeles

Wi-Fi 802.11 a/b/g/n/ac 802.11 a/b/g/n/ac 802.11 a/b/g/n/ac

Fuente: [Elaboración Propia].

En base a los requerimientos mencionados se puede concluir que todos los

requerimientos mínimos existen en la institución y por tanto no será necesario
realizar compra o adquisición de nuevas tecnologías.

Para los requerimientos de software a continuación se indican los requerimientos

necesarios para el servidor, para el cliente y para la aplicación móvil:

208
 Tabla 43: Requisitos de elementos software para el servidor

Características Requerimiento Requerimiento

Nombre
Mínimas Disponible Ideal

Herramienta de
Apache versión 2.0. Apache versión 2.4.
servidor web.

MySQL Community
Manejador de Base de Edition 4.X. MySQL Enterprise
Datos. Edition 5.X

Windows XP/Ubuntu Windows 7/Ubuntu

Sistema Operativo. Windows 7
Server 10.04 LTS. Server 14.04 LTS.

Lenguaje de
PHP 5.4 PHP 5.4 PHP 5.6
programación

Plataforma de desarrollo NotePad++ Netbeans 8.0

Framework Laravel 4.0 Laravel 4.2

Fuente: [Elaboración Propia].

209
 Tabla 44: Requisitos de software para el cliente PC.
Requerimiento Requerimiento
Software Utilizado Requerimiento Mínimo
Disponible Ideal

Sistema Operativo. Windows XP. Windows 7. Windows 7.

Google Chrome
Navegador Web Internet Explorer 10 Internet Explorer 11.
versión 41.

Fuente: [Elaboración Propia].

Tabla 45: Requisitos de software de la aplicación móvil

Requerimiento Requerimiento
Software Utilizado Requerimiento Mínimo
Disponible Ideal

Android 4.0 x Ice Cream Android 4.1Jelly

Sistema Operativo. Android 4.4 Kit Kat.
Sandwich. Bean.

Navegador Nativo
Navegador Web Google Chrome Google Chrome
Android

Aplicación lector PDF. Adobe Reader. OfficeSuite. Google Drive.

Fuente: [Elaboración Propia].

En base a los requerimientos mencionados se puede concluir que casi todos los
requerimientos mínimos existen en la institución, a excepción de unos cuantos para
el servidor, pero dado a que estos son de licencia gratuita no implican ningún costo
para la institución y por tanto no será necesario realizar una compra.

Como todo lo mencionado anteriormente se encuentra disponible en la institución

se considera viable técnicamente el desarrollo del sistema propuesto.

210
4.2. VIABILIDAD ECONÓMICA

Para el análisis de la viabilidad económica se realizará el análisis de costos que se

necesitan para un equipo medianamente equipado con los requerimientos
funcionales del hardware y software, además se tomará en cuenta el costo aplicado
en el esfuerzo de la programación, construcción del web y la aplicación móvil.

El proceso de estimación del coste de un producto software está formado por un

conjunto de técnicas y procedimientos que se usan para poder llegar a una
predicción fiable.

Para estimar el costo de las licencias de los programas y los componentes más
relevantes del equipo para el desarrollo y la ejecución del proyecto se detallan los
siguientes costos en dólares, ver tabla 46

Tabla 46: Costos de hardware y software del servidor

Requerimientos Requerimientos
Nombre Costo $us Costo $us
mínimos ideales
Disco Duro 500 GB 40 1TB 81
Microprocesador Core i2 200 Core i3 300
2.27Ghz.
Tarjeta de Video 64 MB 100 128 MB 150
Monitor 14 pulgadas 70 16 pulgadas 125
Teclado BTC compatible 10 K1890U – Delux 15
con Windows
Memoria RAM 128 MB 30 4 GB 95
MiniDIM con 3
botones
Mouse 10 M391- Delux 15

Herramienta de Apache versión Apache versión

0 0
servidor web. 2.0 2.4

211
 MySQL MySQL
Manejador de
Community 0 Enterprise 0
base de datos
Edition 4.X. Edition 5.X.
Sistema
Windows XP 60 Windows 7 80
Operativo
Lenguaje de
PHP 5.4 0 PHP 5.6 0
programación
Plataforma de
NotePad++ 0 Netbeans 8.0 0
desarrollo
Framework Laravel 4.0 0 Laravel 4.2 0
Total $us: 520 Total $us: 861

Fuente: [Elaboración Propia].

En la siguiente tabla se muestran los análisis de costos del Hardware y Software

para los clientes.

Tabla 47: Costos de hardware y software del cliente PC

Herramienta Costo mínimo $us. Costo ideal $us.

Procesador 120 200

Memoria RAM 12 280

Disco Duro 45 90

Tarjeta Gráfica VGA. 45 100

Monitor 60 90

Teclado y mouse 20 30

S.O. Windows 90 200

212
 Navegador 0 0

TOTAL 392. 990.

Fuente: [Elaboración Propia].

En la siguiente ver tabla 48 se muestran los análisis de costos y hardware para los
dispositivos móviles de los usuarios.

Tabla 48: Costos de hardware y software para la aplicación móvil

Herramienta Costo mínimo $us. Costo ideal $us.

Smartphone 100 400

Sistema operativo. 0 0

Total: 100 400

Fuente: [Elaboración Propia].

El modelo COCOMO es el modelo de estimación de costes más utilizado con el cual

se estima el “esfuerzo” para el proceso de desarrollo del software, en este caso el
proyecto de Trabajo de Grado.

En COCOMO es fundamental el término que hace referencia al modo de desarrollo

del proyecto, que influye directamente en el costo y duración del mismo, y que
puede ser:

1. Modelo Orgánico: cuando el proyecto es desarrollado en un ambiente

familiar y estable, y en el que el producto es similar a otros desarrollados
previamente. Son además productos pequeños y poco novedosos, con unos
requerimientos definidos y poco rígidos.
2. Modelo Semiacoplado: es un modelo para proyectos que presentan
características intermedias entre el orgánico y el empotrado, con un equipo

213
 formado por miembros de distintos niveles de experiencia, que trabajan sobre
un conjunto de requisitos más o menos flexibles.
3. Modelo empotrado: para proyectos caracterizados por unos requerimientos
y restricciones poco flexibles, que requieren un gran esfuerzo de innovación.
También poseen un elevado nivel de complejidad en hardware.

Sus valores constantes de cada parte se muestran en la siguiente tabla:

Tabla 49: Valores constantes por nodo de desarrollo

Modelo ai bi ai bi

Orgánico 2.4 1.05 2.5 0.38

Semiacoplado 3.0 1.12 2.5 0.35

Empotrado 3.6 1.2 2.5 0.32

Fuente: [Elaboración Propia].

Para el presente proyecto se utilizara el modo Orgánico, porque se tienen el

desarrollo del software se ha llevado acabo por una sola persona.

COCOMO está definido en términos de tres modelos diferentes: modelo básico,

intermedio y detallado, que reflejan el nivel de detalle considerado a la hora de
realizar la estimación del coste. Según la teoría, el modelo intermedio y el detallado,
usan un “Factor de Ajuste del Esfuerzo” (EAF), reflejados en la tabla 50.

214
 Tabla 50: Ecuación básica del esfuerzo en COCOMO

MODO DE
ECUACIÓN BÁSICA DEL ESFUERZO
DESARROLLO

ORGÁNICO ,
Esfuerzo = EAF ∗ , ∗ KSLOC

EMPOTRADO ,
Esfuerzo = EAF ∗ ∗ KSLOC

SEMIACOPLADO ,
Esfuerzo = EAF ∗ , ∗ KSLOC

Fuente: [Elaboración Propia].

Tabla 51: Ecuación básica del tiempo en COCOMO

MODO DE
ECUACIÓN BÁSICA DEL ESFUERZO
DESARROLLO

ORGÁNICO , 8
Tiempo Desarrollo = , ∗ Esfuerzo

EMPOTRADO ,
Tiempo Desarollo = , ∗ Esfuerzo

SEMIACOPLADO ,
Tiempo Desarrollo = , ∗ Esfuerzo

Fuente: [Elaboración Propia].

Según la tabla 50 y la tabla 51, la ecuación del Esfuerzo y del Tiempo de

Desarrollo que se utilizarán será el del Modo de Desarrollo Orgánico, a
continuación se describen las variables y sus unidades:

Persona
= Esfuerzo en unidades de [ ]
mes

�� = Kilolíneas o Miles de linea de código fuente.

� = Multiplicación de factores de costo.

215
 = Tiempo de duración del desarrollo en unidades de[Meses]

Este modelo intermedio obtiene mejores resultados, porque establece 15 factores

de costo, que determinan la duración y el coste del proyecto, como se muestra en
la Tabla 52.

Tabla 52: Factores de costo en COCOMO

FACTORES DE MUY MUY EXTRA

BAJO MEDIO ALTO
COSTO BAJO ALTO ALTO

Fiabilidad Requerida
RELY 0,75 0,88 1 1,15 1,4 -
del Software
ATRIBUTOS DEL
PRODUCTO

Tamaño de la Base de
DATA - 0,94 1 1,08 1,16 -
Datos

Complejidad del
CPLX 0,7 0,85 1 1,15 1,3 1,65
Producto

Restricciones del
TIME - - 1 1,11 1,3 1,66
Tiempo de Ejecución
ATRIBUTOS DEL COMPUTADOR

Restricciones del
Almacenamiento STOR - - 1 1,06 1,21 1,56
Principal

Volatilidad de la
VIRT - 0,87 1 1,15 1,3 -
Máquina Virtual

Tiempo de respuesta
TURN - 0,87 1 1,07 1,15 -
del ordenador

Capacidad del analist. ACAP 1,46 1,19 1 0,86 0,71 -

ATRIBUTOS

PERSONAL
DEL

Experiencia en
AEXP 1,29 1,13 1 0,91 0,82 -
Aplicaciones

216
 FACTORES DE MUY MUY EXTRA
BAJO MEDIO ALTO
COSTO BAJO ALTO ALTO

Capacidad de los
PCAP 1,42 1,17 1 0,86 0,7 -
programadores

Experiencia en
Sistema Operativo VEXP 1,21 1,1 1 0,9 - -
utilizado

Experiencia con el
Lenguaje de LEXP 1,14 1,07 1 0,95 - -
Programación

Prácticas de
programación MODP 1,24 1,1 1 0,91 0,82 -
ATRIBUTOS DEL PROYECTO

modernas

Utilización de
Herramientas de TOOL 1,24 1,1 1 0,91 0,83 -
Software

Limitaciones de
planificación del
SCED 1,23 1,08 1 1,04 1,1 -
desarrollo del
proyecto

Fuente: [Elaboración Propia].

Cálculo del valor de EAF

EAF = . ∗ . ∗ ∗ ∗ ∗ ∗ . ∗ . ∗ ∗ . ∗ . ∗ . ∗ ∗ . ∗ .
EAF = .

Para determinar la cantidad total de líneas de código fuente se ha contado las líneas
de cada clase de la arquitectura MVC de la aplicación web 6048 (ver figura 95) y

217
1152 (ver figura 96) de la aplicación móvil, encontrando 7200 líneas de código en
total.

Figura 95: Cantidad Línea de código aplicación web

Fuente: [Elaboración Propia].

Figura 96: Cantidad líneas de código aplicación móvil

Fuente: [Elaboración Propia].

218
Para determinar el valor de la variable KSLOC se van a usar unidades de SLOC
(Líneas de código fuente), con las siguientes restricciones: Sumar las líneas de
código creadas por el personal del proyecto (no el creado por generadores de
aplicaciones). Se considera que una instrucción es una línea de código. Las
declaraciones se toman como instrucciones. Los comentarios no se cuentan como
instrucciones.

Se determina que:

�� =

KSLOC = SLOC/1000

�� = �, �

Entonces, una vez encontradas los valores de EAF y KSLOC, se procede a

calcular el esfuerzo:

.
E = EAF ∗ . ∗ KSLOC
.
E= . ∗ . ∗ .
personas
E= . [ ]
mes

Obtenido el valor del esfuerzo se procede a calcular el tiempo de desarrollo:

. 8
T = . ∗ Esfuerzo
. 8
T= . ∗ .
T= . [meses]

Ahora se procede a calcular el “Personal Promedio” requerido para desarrollar el

proyecto:

Esfuerzo
Personal =
Tiempo de desarrollo
.
Personal = = . [personas]
.

219
Ahora de calcula la “Productividad”

SLOC SLOC
PR = = = . [ ∗ mes]
Esfuerzo . Persona

Interpretando los resultados obtenidos, se determina que para el proyecto se ha

escrito 7200 líneas de código, lo que se traduce en un esfuerzo aproximado de 17
personas por mes, el proyecto se ha desarrollado en 7 meses y lo ideal para el
desarrollo es contar con 2 a 3 programadores.

Pero la situación, es que en este caso, el proyecto ha sido desarrollado por una sola
persona, así que los costos de desarrollo se calcularan considerando tal situación.

El desarrollador ha trabajado dos horas al día, quien ha realizado las tareas de

análisis, diseño, codificación y pruebas del proyecto. Se ha considerado el trabajo
en días laborales de lunes a viernes, 2 horas al día, lo que supone unas 40 horas al
mes. Y según el tiempo estimado por la cantidad de horas al mes, se obtiene un
total de horas de trabajo de:

horas horas
→
dia mes
Total Horas de Trabajo = ∗ . = . [horas]

Para determinar una aproximación del costo de desarrollo del proyecto se ha

averiguado que el sueldo para el área de programación en Bolivia oscila el valor de
quinientos cincuenta dólares americanos (Bs. 3828). Tomando en cuenta que se
trabaja de lunes a viernes durante un mes (con cuatro semanas) por el lapso de
ocho horas diarias, ajustando los $us 550 a este horario, se determina que el costo
por hora es de $us 3.44 (Bs. 23.94).

$us mes dia laboral $us

∗ ∗ = . [ ]
mes dias laborales horas hora

Por lo tanto, ajustando el horario de trabajo del autor del proyecto (2 horas al día),
y considerando el pago por hora de $us 3.44, se procede a calcular el costo

220
estimado del proyecto, multiplicando la cantidad de horas a trabajar en el lapso de
tiempo estimado por el pago por hora determinado:

$us
. [horas] ∗ . [ ]= . [$us]
hora

Observando el resultado de la ecuación se determina que el costo estimado del

proyecto de es de $us 1011.293755 dólares americanos (Bs. 7038.604537).

De esta manera, se ha empleado el método de estimación de costos COCOMO,

calculando los valores para medir el esfuerzo (E), cantidad de líneas de código
fuente (KSLOC), el ajuste de los factores de esfuerzo (EAF) y el tiempo para el
desarrollo del proyecto, determinando así que el costo estimado de desarrollo del
proyecto es de $us 1011.293755 (dólares americanos), considerando que el
proyecto ha sido desarrollado por una sola persona.

Incluyendo los costos de las herramientas tanto de Software como Hardware, que
se tiene a continuación:

Tabla 53: Gastos estimados en el desarrollo del proyecto para la institución.

DESCRIPCIÓN MONTO MINIMO [$us.] MONTO IDEAL [$us.]
Adquisición de componentes
de software y hardware para el 520 861
servidor
Adquisición de componentes
de software y hardware para el 392 990
cliente PC
Adquisición de componentes
de software y hardware para la 100 400
aplicación móvil.
Costo desarrollo del proyecto 1011.293755 1011.293755

Total $us: 2093.293755 3262.293755

Fuente: [Elaboración Propia].

221
En la tabla 54 se muestran los costos del proyecto con los requisitos mínimos e
ideales, pero dado que la institución cuenta con los requisitos mínimos en hardware
tanto para el servidor como para el cliente, y además cuentan con disposición de
dispositivos móviles con sistema operativo Android se establece los siguientes
cambios en el monto mínimo:

Tabla 54: Gastos estimados para el desarrollo del proyecto.

DESCRIPCIÓN MONTO MINIMO [$us.] MONTO IDEAL [$us.]

Adquisición de componentes
de software y hardware para el 90 861
servidor
Adquisición de componentes
de software y hardware para el 0 990
cliente PC
Adquisición de componentes
de software y hardware para la 0 400
aplicación móvil.
Costo desarrollo del proyecto 1011.293755 1011.293755

Total $us: 1101.293755 3262.293755

Fuente: [Elaboración Propia].

Analizando el costo estimado del proyecto el cual se obtuvo gracias a la ecuación

planteada anteriormente, el costo estimado del proyecto es de $us 1011.293755
Dólares Americanos (Bs. 7038.604537) y con el monto mínimo hallado para la parte
de hardware y software necesario para el desarrollo del proyecto (ver tabla 40) el
costo total del proyecto sería de $us 1101.293755 (Bs. 7676.017472).

222
4.2.1. Análisis beneficio-costo

Para realizar el análisis de beneficio – costo del presente proyecto se emplearán los
siguientes datos:

 2,31% es la tasa de interés anual. (Fuente: BNB).

 Inversión inicial de 14569.32453Bs.

Teniendo en cuenta estos resultados podemos mencionar algunos beneficios

otorgados por el sistema (ver anexo D para más detalles de los costos) como se
puede ver en la siguiente tabla:

Tabla 55: Tabla de costo con y sin sistema

SIN SISTEMA CON SISTEMA

DESCRIPCIÓN
(Bs) (Bs)
Costo empleado en los registros de Bs. 931.2 Bs. 87.3
los procesos de la institución.
Costo invertido en obtención de las Bs. 465.6 Bs. 19.4
listas actualizadas de los
estudiantes, cursos, materias y
docentes.
Costo en el registro de planillas de Bs. 291 Bs. 38.8
notas.
Costo de elaboración de reportes de Bs. 465.6 Bs. 1.94
notas.
TOTAL COSTO/AÑO Bs. 2153.4 Bs. 147.44

Fuente: [Elaboración Propia].

La relación Beneficio / Costo (B/C), muestra la cantidad de dinero actualizado que

recibirá el Proyecto por cada unidad monetaria invertida. Este indicador mide la
relación que existe entre los ingresos de un Proyecto y los costos incurridos a lo
largo de su vida útil incluyendo la Inversión total.

223
  Si la relación B/C es mayor que la unidad, el Proyecto es aceptable, porque
el beneficio es superior al costo.
 Si la relación B/C es menor que la unidad, el proyecta debe rechazarse
porque no existe beneficio.
 Si la relación B/C es igual a la unidad, es indiferente llevar adelante el
Proyecto, porque no hay beneficio ni perdidas.

Para el cálculo de la relación beneficio / costo, se emplea la siguiente fórmula:

Y
∑ = +i
B/C =
C
I +∑ = +i

Y = Beneficio

C = Costos

n = tiempo de vida de duración del proyecto (5 años)

i = Tasa de interés

Teniendo en base al tiempo de vida establecido en el alcance temporal para el

proyecto se ha determinado utilizar los siguientes valores:

n= años.

Y = . − . = . Bs.

i= . %≅ .

+i = .

C = . Bs.

I = . Bs.

224
Donde reemplazando los valores en la ecuación se tiene:

B⁄
C
. . . . .
+ + + +
, , , , ,
=
. . . . .
. + + + + +
, , , , ,

B⁄ = .
C

. > => Genera beneficios.

Al obtener el resultado mayor a 1 se puede concluir que los beneficios que se

obtiene con la implantación del proyecto son justificables respecto al costo invertido
para su desarrollo del sistema, por lo tanto el proyecto es económicamente viable y
beneficiará al Politécnico Militar de Aeronáutica José Max Ardiles Monrroy.

4.3. VIABILIDAD OPERATIVA

La viabilidad operativa se demuestra mediante la aplicabilidad e importancia que

supone la implantación de la aplicación móvil, del sistema web y la aceptación del
personal implicado en este uso de ambos sistemas usados.

El desarrollo del proyecto agrupa un grupo de requerimientos respecto a recursos

humanos, se debe considerar las capacidades cognoscitivas del administrador del
sistema, encargado del escuadrón de evaluación, estudiante, docente.

225
1) Encargado de escuadrón.

La funcionalidad del encargado de escuadrón es de ser administrador del sistema,

es de gestionar a los usuarios, asignar cuentas de usuarios, gestionar estudiantes,
docentes, materias, cursos, cargos, especialidades y notas por lo cual el sistema le
permite:

 Disponibilidad inmediata de la información personal de los estudiantes y

docentes.
 Asignar cargos al personal de escuadrón de evaluación para el ingreso al
sistema.
 Permite obtener reportes actualizados de las calificaciones de los
estudiantes.
 El tiempo esperado por cada reporte realizado es bastante corto en
comparación al empleado actualmente.
 No se depende de terceras personas para la obtención de la información
necesaria por el administrador del sistema.
 Se requiere una capacitación de una hora para el correcto uso del sistema.

2) Jefe de escuadrón de evaluación.

El jefe del escuadrón de evaluación tiene la funcionalidad de obtener reportes de

los estudiantes, por lo tanto el sistema le permite:

 Disponibilidad inmediata de calificaciones oportunas sin importar la fecha y

hora.
 Permite realizar reportes de calificaciones
 Permite realizar reportes estadísticos de dichas calificaciones.
 Se requiere una capacitación de 1 hora para el correcto uso del sistema.

226
3) Estudiante

El estudiante tiene la funcionalidad de poder ver sus datos personales y también

ver sus calificaciones, por lo tanto el sistema le debe permitir:

 Ver sus datos personales.

 Obtener un listado de cursos que haya pasado o esté pasando.
 Obtener un reporte de sus notas.
 Se requiere una capacitación de 20 minutos para el correcto uso del
sistema.

4) Docente

El docente tiene la funcionalidad de poder registrar las notas de las materias que
tenga asignadas, para ello el sistema le permite:

 Registrar las notas de sus estudiantes.

 Ver sus datos personales.
 Se requiere de una capacitación de 30 minutos para el correcto uso del
sistema.

227
5. CONCLUSIONES Y RECOMENDACIONES
5.1. CONCLUSIONES

A continuación se detallan las conclusiones que se obtuvieron en base al proyecto

terminado.

 Mediante entrevistas y cuestionarios realizados al personal de escuadrón de

evaluación del Politécnico Militar de Aeronáutica Jose Max Ardilles Monrroy,
se llegó a determinar cómo actualmente los procesos de registro y búsqueda
de calificaciones, dichos procesos se plasmaron en un diagrama de
actividades el cual permite reflejar el flujo que se sigue actualmente.
 Después de evaluar las deficiencias del proceso actual de registro y
búsqueda de información de calificaciones de los estudiantes, considerando
las oportunidades y beneficios que ofrece una aplicación web y móvil para
realizar dichas tareas, se llevó a cabo el diseño del proceso alternativo
reflejado en un diagrama de actividades, en el cual se puede observar de
manera sencilla el nuevo procedimiento alternativo, que propone realizarse
con el uso de la aplicación web y móvil, se llevó a cabo también la selección
de la metodología de desarrollo incremental y la planificación de incrementos
que se realizaron en este proyecto.
 Para obtener el primer incremento se establecieron las herramientas que
permitieron el desarrollo de los módulos que se plantearon en la planificación
de incrementos, para ello se seleccionó el lenguaje de programación PHP
utilizando el framework Laravel que integra la arquitectura MVC, se
seleccionó también el gestor de base de datos MySQL para el desarrollo de
los módulos de administración de usuarios, cargos, estudiantes, docentes,
materias, especialidades y cursos una vez obtenidos todos los módulos
estos al ser empleados facilitan el proceso de gestión de calificaciones ya
que teniendo estos elementos codificados se pueden implementar en el
enrutamiento del framework Laravel para que estos puedan accederse a
través de la aplicación web.

228
  El desarrollo de la aplicación móvil permite al personal de escuadrón de
evaluación realizar registro y búsqueda de calificaciones, al docente poder
registrar las notas de las materias que tenga asignadas y a los estudiantes la
visualización de sus calificaciones, esto se logró gracias a las herramientas
seleccionadas como ser el lenguaje de programación Java, el IDE Android
Studio y el servicio RESTful utilizado para la sincronización entre la aplicación
web y la aplicación móvil.
 Para realizar la generación de reportes que son requeridas en la institución,
se determinó que tipos de reportes son estos y que campos precisan figurar
en los mismos, para ello se elaboró una entrevista al encargado y jefe de
escuadrón de evaluación, y se procedió a la codificación de estos.
 Mediante el uso de pruebas funcionalidades se logró verificar la correcta
funcionalidad de cada caso de uso de la herramienta web y la aplicación
móvil, determinando la correctividad del sistema y su robustez ante fallas.

De esta manera, se considera que se han alcanzado los objetivos trazados en el

presente proyecto, puesto que se ha dado solución al problema identificado,
realizando la demostración de la hipótesis planteada y de hecho el tiempo de
obtención de información de notas es reducido en comparación al que se tiene
actualmente.

Finalmente en función a las viabilidades descritas en el capítulo 4 se concluye que

el presente proyecto es totalmente viable, ya que el Politécnico Militar de
Aeronáutica José Max Ardiles Monrroy. Cuenta con los recursos suficientes para
cubrir el costo total del mismo.

5.2. RECOMENDACIONES

A continuación se describen algunas recomendaciones que deben ser consideradas

para la propuesta en marcha del sistema y otras que sirven para su crecimiento a
futuro.

229
Recomendaciones Funcionales

 Se recomienda implementar el sistema desarrollado para la gestión 2016.

 Para garantizar la seguridad de las contraseñas se recomienda al usuario
cambiarla de forma periódica, es decir cada cierto tiempo (cada mes por
ejemplo) también se le recomienda el uso de números y mayúsculas.
 Para un óptimo funcionamiento del sistema, se deben tener los
requerimientos mínimos establecidos en la viabilidad técnica.
 Se recomienda tener una fuente de energía de respaldo en caso de cortes
de electricidad.
 Para proteger la información, se recomienda realizar copias de respaldo para
mantener la información disponible.

Recomendaciones a futuro

 Se recomienda subir la aplicación a un servidor web, para que el sistema

pueda ser accedido desde cualquier parte del mundo.
 Se recomienda implementar un módulo que permita la gestión de otras áreas
afines de la institución, como ser el control de asistencia del personal y del
cuerpo estudiantil.
 Se recomienda la codificación de un módulo que permita al usuario recuperar
su contraseña a través de un correo electrónico o por SMS a su número de
celular.

230
BIBLIOGRAFÍA
 Ableson, F. (2 de Mayo de 2013). DeveloperWorks. Obtenido de Introduccion
Android: http://www.ibm.com/developerworks/ssa/library/os-android-devel/
 Boehm's, B. (2007). A Spiral Model of Software Development and
Enhancement
 Calero, W. (2010). Modelo Incremental.
 Coporation, M. (2006).
 Hernández, E. (1995). El Lenguaje de Modelado.
 Kendall, K. E. (4 de Agosto de 2011). Análisis y Diseño de Sistemas. En K.
E. Kendall, Análisis y Diseño de Sistemas (pág. 120). -: -.
 Kinderman. (15 de Marzo de 2014). Obtenido de http://indira-
informatica.blogspot.com/2007/09/qu-es-un-sistema-de-gestin-de-base-
de.html
 Marick, B. (2005). Clarus Concept of Operations.
 Microsoft Corporation. (2006). Sistemas Integrados. Microsoft® aplicada al
mundo real.
 Microsoft Corporation. (2014).
 Montenegro, M. (26 de Febrero de 2012). Introduccion a las tecnologias web.
Obtenido de http://dalila.sip.ucm.es/
 O’Reilly. (2004). Web services for the real world.
 Oracle, C. (2014). Java. Obtenido de
http://www.java.com/es/download/faq/whatis_java.xml
 Pressman, R. S. (2005). Ingenieria del software, un enfoque práctico.
 Salinas, D. C. (2007). Interoperabilidad e Integración de Sistemas
Informáticos de la Iglesia Católica en Chile.
 Salkind, N. (1999). Métodos de investigación. Mexico.
 Sampieri, H. (2003). Metodologias de la investigacion.
 Sommerville, I. (2011). Ingenieria de Software. Prentice Hall.

231