UNIVERSIDAD REGIONAL AUTÓNOMA DE LOS ANDES “UNIANDES”
FACULTAD DE SISTEMAS MERCANTILES CARRERA DE SISTEMAS E INFORMATICA
TESIS DE GRADO
PREVIA A LA OBTENCIÓN DEL TÍTULO DE
INGENIERO EN SISTEMAS E INFORMÁTICA
TEMA:
Sistema Informático de matrículas y control de notas online para el Centro de Educación Básica Fisco Misional “Mons. Tomás Romero Gross”
AUTOR: Tnlgo. Naranjo Michael ASESOR: Ing. Rodrigo Aguilar
ii
CERTIFICACIÓN
Ing. Rodrigo Aguilar, docente de la Universidad Regional Autónoma de los Andes extensión Puyo, certifico que la presente tesis ha sido elaborada por el Tnlgo. Michael Naranjo; bajo mi dirección, control y seguimiento. El presente trabajo reúne los requisitos de una investigación y programación concluida mediante el esfuerzo, dedicación y constancia, lo que permite otorgar su originalidad.
Para constancia y validez, firmo el documento
Atentamente,
iii
DECLARACIÓN DE AUTORÍA
Yo, Naranjo Zumba Michael Leopoldo, declaro que la presente tesis constituye un requisito previo a la obtención del título de Ingeniero en Sistemas e Informática bajo la supervisión del Ing. Rodrigo Aguilar.
Autorizo a la Universidad para que el presente trabajo se convierta en un documento de lectura, de acuerdo a los requisitos establecidos por la Institución. Finalmente expreso que el presente trabajo investigativo ha sido de mi autoría, razón por la cual cedo los derechos a la Universidad Regional Autónoma de los Andes.
Tnlgo. Michael Naranjo
iv
DEDICATORIA
v
AGRADECIMIENTO
Agradezco a Dios y a la virgen María, quienes me han guiado y me han dado la fortaleza para poder superar los obstáculos de la vida y forjarme un futuro mejor.
vi
INDICE GENERAL
Carátula i
Certificación de asesoría ii
Declaración de la autoría iii
Dedicatoria iv
Agradecimiento v
Índice vi
Resumen ejecutivo xxii
Executive Summary xxiii
Introducción 1
CAPITULO I EL PROBLEMA
1.1 Planteamiento del problema 2
1.1.1 Formulación del problema 2
1.1.2 Delimitación del problema 3
1.2 Objetivos 3
1.2.1 Objetivo general 3
1.2.2 Objetivos específicos 3
1.3 Línea de investigación 3
vii CAPITULO II MARCO TEÓRICO
2.1 Antecedentes investigativos 5
2.2 Fundamentación teórica 6
2.2.1 Ingeniería del software 6
2.2.1.1 Ciclo de vida 6
2.2.1.2 Modelos 7
2.2.1.2.1 Diagrama de casos de uso 7
2.2.1.2.2 Diagrama de secuencia 8
2.2.1.2.3 Diagrama de colaboración 8
2.2.2 Proyectos informáticos 8
2.2.2.1 Planeación del proyecto 9
2.2.2.2 Objetivos de la planificación del proyecto 10 2.2.2.2.1 Actividades asociadas al proyecto de software 10 2.2.2.2.2 Estimación del proyecto de software 11 2.2.2.2.3 Estimación basada en el proceso 12
2.2.3 Xampp 12
2.2.3.1 Características y requisitos 13
2.2.3.2 Aplicaciones 13
2.2.4 Apache 13
2.2.4.1 Uso 14
2.2.4.2 Configuración 14
2.2.5 PHP 14
2.2.5.1 Características 15
2.2.5.2 Inconvenientes 16
viii
2.2.6.1 Aplicaciones 17
2.2.7 Java Script 17
2.2.7.1 Características 17
2.2.8 Ext JS 20
2.2.8.1 Funcionalidades 20
2.2.9 Arquitectura Cliente – Servidor 21
2.2.9.1 Características 22
2.2.9.2 Arquitectura multi – capas 23
2.2.9.3 Ventajas 23
2.2.9.4 Desventajas 24
2.2.10 GPL 25
2.2.10.1Validez legal 25
2.3 Idea a defender 25
CAPITULO III MARCO METODOLÓGICO
3.1 Modalidad de la investigación 26
3.2 Tipos de investigación 26
3.3 Población y muestra 26
3.4 Métodos, técnicas e instrumentos 27
3.4.1 Métodos 27
3.4.2 Técnicas 27
3.4.3 Instrumentos 28
ix CAPITULO IV MARCO PROPOSITIVO
4.1 Título 37
4.2 Justificación 37
4.3 Objetivos 37
4.3.1 Objetivo General 37
4.3.2 Objetivos Específicos 38
4.4 Desarrollo de la propuesta 38
4.4.1 Factibilidad 38
4.4.1.1 Factibilidad Técnica 38
4.4.1.2 Factibilidad Operativa 39
4.4.1.3 Factibilidad Económica 39
4.4.2 Metodología 40
4.4.3 Acercamiento preliminar 42
4.4.4 Análisis 43
4.4.4.1 Requerimientos funcionales 43
4.4.4.2 Requerimientos no funcionales 45
4.4.4.3 Lista de eventos 46
4.4.4.4 Diagramas de casos de uso 47
4.4.4.4.1 Módulo Administrador 50
4.4.4.4.2 Módulo Secretaría 64
4.4.4.4.3 Módulo Docente 83
4.4.4.4.4 Módulo Alumno 87
4.4.4.5 Diagramas de Secuencia 90
4.4.4.5.1 Módulo Administrador 90
x
4.4.4.5.3 Módulo Docente 107
4.4.4.5.4 Módulo Alumno 109
4.4.4.6Diagramas de Clase 111
4.4.4.6.1 Módulo Administrador 111
4.4.4.6.2 Módulo Secretaría 112
4.4.4.6.3 Módulo Docente 113
4.4.4.6.4 Módulo Alumno 113
4.4.4.7 Diccionario de datos 114
4.4.5 Diseño 117
4.4.5.1 Diseño conceptual de la base de datos 117
4.4.5.2 Diseño lógico de la base de datos 118
4.4.5.3 Diseño físico de la base de datos 119
4.4.5.4 Arquitectura Cliente – Servidor 120
4.4.5.5 Diseño Navegacional 121
4.4.5.5.1 Diseño Navegacional – Administrador 121 4.4.5.5.2 Diseño Navegacional – Secretaria 122 4.4.5.5.3 Diseño Navegacional – Docente 123 4.4.5.5.4 Diseño Navegacional – Estudiante 123
4.4.5.6 Interfaces 124
4.4.5.6.1 Interfaz de acceso principal 124 4.4.5.6.2 Interfaz – Módulo Administrador 125 4.4.5.6.3 Interfaz – Módulo Secretaría 130
4.4.5.6.4 Interfaz – Módulo Docente 138
4.4.5.6.5 Interfaz – Módulo Alumno 140
xi
4.4.7 Pruebas 143
4.4.7.1 Pruebas unitarias 143
4.4.7.2 Pruebas del sistema 144
4.4.7.3 Pruebas de integración 145
4.4.7.4 Pruebas funcionales 146
4.4.7.5 Pruebas de seguridad 147
4.4.7.6 Evaluación de pruebas ejecutadas 148
4.4.7.7 Lista de chequeo 151
Conclusiones 152
Recomendaciones 153
Bibliografía 154
xii
INDICE DE TABLAS
Tabla 1.- Factibilidad Técnica 38
Tabla 2.- Factibilidad Económica 39
Tabla 3.- Requerimientos funcionales – Administrador 43
Tabla 4.- Requerimientos funcionales – Secretaría 44
Tabla 5.- Requerimientos funcionales – Docente 44
Tabla 6.- Requerimientos funcionales – Alumno 45
Tabla 7.- Requerimientos no funcionales 45
Tabla 8.- Lista de eventos 46
Tabla 9.- Descripción diagrama de casos de uso – Administrador – Nuevo Periodo 50 Tabla 10.- Descripción diagrama de casos de uso – Administrador – Modificar Periodo 51 Tabla 11.- Descripción diagrama de casos de uso – Administrador – Nuevo Curso 52
Tabla 12.- Descripción diagrama de casos de uso – Administrador – Modificar Curso 53 Tabla 13.- Descripción diagrama de casos de uso – Administrador – Nueva Asignatura 54 Tabla 14.- Descripción diagrama de casos de uso – Administrador – Modificar Asignatura 55
Tabla 15.- Descripción diagrama de casos de uso – Administrador – Nuevo Docente 56 Tabla 16.- Descripción diagrama de casos de uso – Administrador – Modificar Docente 57
xiii
Tabla 20.- Descripción diagrama de casos de uso – Administrador – Modificar Tipo de
Nota 61
Tabla 21.- Descripción diagrama de casos de uso – Administrador – Nuevo Personal 62
Tabla 22.- Descripción diagrama de casos de uso – Administrador – Modificar Personal 63 Tabla 23.- Descripción diagrama de casos de uso – Secretaria – Nuevo Alumno 64
Tabla 24.- Descripción diagrama de casos de uso – Secretaria – Modificar Alumno 65 Tabla 25.- Descripción diagrama de casos de uso – Secretaria – Reporte Nómina de
Alumnos 66
Tabla 26.- Descripción diagrama de casos de uso – Secretaria – Nuevo Docente 67 Tabla 27.- Descripción diagrama de casos de uso – Secretaria – Modificar Docente 68
Tabla 28.- Descripción diagrama de casos de uso – Secretaria – Reporte Nómina de
Docentes 69
Tabla 29.- Descripción diagrama de casos de uso – Secretaria – Nuevo Representante 70
Tabla 30.- Descripción diagrama de casos de uso – Secretaria – Modificar Representante 71 Tabla 31.- Descripción diagrama de casos de uso – Secretaria – Reporte Nómina de
Representantes 72
Tabla 32.- Descripción diagrama de casos de uso – Secretaria – Modificar Periodo 73 Tabla 33.- Descripción diagrama de casos de uso – Secretaria – Modificar Clase 74
xiv
Tabla 37.- Descripción diagrama de casos de uso – Secretaria – Reporte Detalle de
Matrículas 78
Tabla 38.- Descripción diagrama de casos de uso – Secretaria – Promoción 79
Tabla 39.- Descripción diagrama de casos de uso – Secretaria – Modificar Promoción 80 Tabla 40.- Descripción diagrama de casos de uso – Secretaria – Ingresar Notas 81
Tabla 41.- Descripción diagrama de casos de uso – Secretaria – Reporte de Calificaciones 82 Tabla 42.- Descripción diagrama de casos de uso – Docente – Ingresar Notas 83 Tabla 43.- Descripción diagrama de casos de uso – Docente – Reporte de Calificaciones 84
Tabla 44.- Descripción diagrama de casos de uso – Docente – Modificar Datos 85 Tabla 45.- Descripción diagrama de casos de uso – Docente – Cambiar Contraseña 86
Tabla 46.- Descripción diagrama de casos de uso – Alumno – Reporte de Calificaciones 87 Tabla 47.- Descripción diagrama de casos de uso – Alumno – Modificar Alumno 88 Tabla 48.- Descripción diagrama de casos de uso – Alumno – Modificar Alumno 89
Tabla 49.- Diccionario de datos – Tabla Alumno 114
Tabla 50.- Diccionario de datos – Tabla Docente 114
Tabla 51.- Diccionario de datos – Tabla Asignatura 114
Tabla 52.- Diccionario de datos – Tabla Clase 114
Tabla 53.- Diccionario de datos – Tabla Curso 115
Tabla 54.- Diccionario de datos – Tabla Matrícula 115
Tabla 55.- Diccionario de datos – Tabla Nota 115
xv
Tabla 57.- Diccionario de datos – Tabla Personal 116
Tabla 58.- Diccionario de datos – Tabla Registro 116
Tabla 59.- Diccionario de datos – Tabla Representante 116
Tabla 60.- Diccionario de datos – Tabla Tipo 116
Tabla 61.- Descripción de Pruebas – Pruebas Unitarias 143
Tabla 62.- Descripción de Pruebas – Pruebas del Sistema 144
Tabla 63.- Descripción de Pruebas – Pruebas de Integración 145
Tabla 64.- Descripción de Pruebas – Pruebas Funcionales 146
Tabla 65.- Descripción de Pruebas – Pruebas de Seguridad 147 Tabla 66.- Evaluación de pruebas ejecutadas – Criterios de evaluación 148
Tabla 67.- Evaluación de pruebas ejecutadas – Pruebas Unitarias 149 Tabla 68.- Evaluación de pruebas ejecutadas – Pruebas del Sistema 149 Tabla 69.- Evaluación de pruebas ejecutadas – Pruebas de Integración 150
Tabla 70.- Evaluación de pruebas ejecutadas – Pruebas de Seguridad 150
xvi
INDICE DE FIGURAS
Figura 1.- Diagrama de casos de uso Nivel 0 - General 47
Figura 2.- Diagrama de casos de uso Nivel 0 - Detallado 47
Figura 3.- Diagrama de casos de uso Nivel 1 – Administrador 48
Figura 4.- Diagrama de casos de uso Nivel 1 – Secretaria 48
Figura 5.- Diagrama de casos de uso Nivel 1 – Docente 49
Figura 6.- Diagrama de casos de uso Nivel 1 – Alumno 49
Figura 7.- Diagrama de casos de uso Nivel 2 – Administrador – Gestionar Periodo 50 Figura 8.- Diagrama de casos de uso Nivel 2 – Administrador – Gestionar Curso 52
Figura 9.- Diagrama de casos de uso Nivel 2 – Administrador – Gestionar Asignatura 54 Figura 10.- Diagrama de casos de uso Nivel 2 – Administrador – Gestionar Docente 56 Figura 11.- Diagrama de casos de uso Nivel 2 – Administrador – Gestionar Clase 58
Figura 12.- Diagrama de casos de uso Nivel 2 – Administrador – Gestionar Tipo de Nota 60 Figura 13.- Diagrama de casos de uso Nivel 2 – Administrador – Gestionar Personal 62 Figura 14.- Diagrama de casos de uso Nivel 2 – Secretaria – Gestionar Alumno 64
Figura 15.- Diagrama de casos de uso Nivel 2 – Secretaria – Gestionar Docente 67 Figura 16.- Diagrama de casos de uso Nivel 2 – Secretaria – Gestionar Representante 70
xvii
Figura 20.- Diagrama de casos de uso Nivel 2 – Secretaria – Gestionar Registro 79 Figura 21.- Diagrama de casos de uso Nivel 2 – Secretaria – Gestionar Nota 81 Figura 22.- Diagrama de casos de uso Nivel 2 – Docente – Gestionar Nota 83
Figura 23.- Diagrama de casos de uso Nivel 2 – Docente – Gestionar Docente 85 Figura 24.- Diagrama de casos de uso Nivel 2 – Alumno – Gestionar Notas 87
Figura 25.- Diagrama de casos de uso Nivel 2 – Alumno – Gestionar Alumno 88 Figura 26. Diagrama de secuencia, caso de uso Gestionar Periodo, escenario Agregar. 90 Figura 27. Diagrama de secuencia, caso de uso Gestionar Periodo, escenario Modificar. 91
Figura 28. Diagrama de secuencia, caso de uso Gestionar Curso, escenario Agregar. 91 Figura 29. Diagrama de secuencia, caso de uso Gestionar Curso, escenario Modificar. 92
Figura 30. Diagrama de secuencia, caso de uso Gestionar Asignatura, escenario Agregar. 92 Figura 31. Diagrama de secuencia, caso de uso Gestionar Asignatura, escenario Modificar.93 Figura 32. Diagrama de secuencia, caso de uso Gestionar Docente, escenario Agregar. 93
Figura 33. Diagrama de secuencia, caso de uso Gestionar Docente, escenario Modificar. 94 Figura 34. Diagrama de secuencia, caso de uso Gestionar Clase, escenario Agregar. 94 Figura 35. Diagrama de secuencia, caso de uso Gestionar Clase, escenario Modificar. 95
Figura 36. Diagrama de secuencia, caso de uso Gestionar Tipo de Nota, escenario Agregar.95 Figura 37. Diagrama de secuencia, caso de uso Gestionar Tipo de Nota, escenario
Modificar. 96
xviii
Figura 40. Diagrama de secuencia, caso de uso Gestionar Alumno, escenario Agregar. 97 Figura 41. Diagrama de secuencia, caso de uso Gestionar Alumno, escenario Modificar. 98 Figura 42. Diagrama de secuencia, caso de uso Gestionar Alumno, escenario Generar
Lista. 98
Figura 43. Diagrama de secuencia, caso de uso Gestionar Docente, escenario Agregar. 99
Figura 44. Diagrama de secuencia, caso de uso Gestionar Docente, escenario Modificar. 99 Figura 45. Diagrama de secuencia, caso de uso Gestionar Docente, escenario Generar
Lista. 100
Figura 46. Diagrama de secuencia, caso de uso Gestionar Representante, escenario
Agregar. 100
Figura 47. Diagrama de secuencia, caso de uso Gestionar Representante, escenario
Modificar. 101
Figura 48. Diagrama de secuencia, caso de uso Gestionar Representante, escenario
Generar Lista. 101
Figura 49. Diagrama de secuencia, caso de uso Gestionar Periodo, escenario Modificar. 102 Figura 50. Diagrama de secuencia, caso de uso Gestionar Clase, escenario Modificar. 102
Figura 51. Diagrama de secuencia, caso de uso Gestionar Representante, escenario
Generar Lista. 103
Figura 52. Diagrama de secuencia, caso de uso Gestionar Matrícula, escenario Agregar. 103 Figura 53. Diagrama de secuencia, caso de uso Gestionar Matrícula, escenario Modificar.104 Figura 54. Diagrama de secuencia, caso de uso Gestionar Representante, escenario
xix
Figura 55. Diagrama de secuencia, caso de uso Gestionar Promoción, escenario Promover.105 Figura 56. Diagrama de secuencia, caso de uso Gestionar Promoción, escenario Modificar.105 Figura 57. Diagrama de secuencia, caso de uso Gestionar Notas, escenario Ingresar. 106
Figura 58. Diagrama de secuencia, caso de uso Gestionar Notas, escenario Reporte. 106 Figura 59. Diagrama de secuencia, caso de uso Gestionar Notas, escenario Ingresar. 107
Figura 60. Diagrama de secuencia, caso de uso Gestionar Notas, escenario Reporte. 107 Figura 61. Diagrama de secuencia, caso de uso Gestionar Docente, escenario Modificar. 108 Figura 62. Diagrama de secuencia, caso de uso Gestionar Docente, escenario Cambiar
Contraseña. 108
Figura 63. Diagrama de secuencia, caso de uso Gestionar Notas, escenario Reporte. 109
Figura 64. Diagrama de secuencia, caso de uso Gestionar Alumno, escenario Modificar. 109 Figura 65. Diagrama de secuencia, caso de uso Gestionar Alumno, escenario Reporte. 110
Figura 66. Diagrama de clases – Administrador 111
Figura 67. Diagrama de clases – Secretaría 112
Figura 68. Diagrama de clases – Docente 113
Figura 69. Diagrama de clases – Alumno 113
Figura 70. Diseño Conceptual de la Base de Datos 117
Figura 71.- Diseño Lógico de la Base de Datos 118
Figura 72.- Diseño Lógico de la Base de Datos 119
Figura 73. Interfaz de Acceso 124
xx
Figura 75. Interfaz – Administrador – Menú Reportes – Submenú Acceso al Sistema 125 Figura 76. Interfaz – Administrador – Menú Reportes – Submenú Ingreso de Notas 126 Figura 77. Interfaz – Administrador – Menú Personal – Submenú Datos 126
Figura 78. Interfaz – Administrador – Menú Cargar Datos – Submenú Periodos 127 Figura 79. Interfaz – Administrador – Menú Cargar Datos – Submenú Cursos 127
Figura 80. Interfaz – Administrador – Menú Cargar Datos – Submenú Docentes 128 Figura 81. Interfaz – Administrador – Menú Cargar Datos – Submenú Asignaturas 128 Figura 82. Interfaz – Administrador – Menú Cargar Datos – Submenú Clases 129
Figura 83. Interfaz – Administrador – Menú Cargar Datos – Submenú Notas 129
Figura 84. Interfaz – Secretaría – Página de Inicio 130
Figura 85. Interfaz – Secretaría – Menú Matrículas – Submenú Matricular 130 Figura 86. Interfaz – Secretaría – Menú Matrículas – Submenú Promociones 131 Figura 87. Interfaz – Secretaría – Menú Calificaciones – Submenú Cargar Notas 131
Figura 88. Interfaz – Secretaría – Menú Calificaciones – Submenú Reportes Grupales 132 Figura 89. Interfaz – Secretaría – Menú Calificaciones – Submenú Reportes Individuales 132 Figura 90. Interfaz – Secretaría – Menú Reportes – Submenú Alumnos 133
Figura 91. Interfaz – Secretaría – Menú Reportes – Submenú Docentes 133 Figura 92. Interfaz – Secretaría – Menú Reportes – Submenú Representantes 134
xxi
Figura 96. Interfaz – Secretaría – Menú Cargar Datos – Submenú Docentes 136 Figura 97. Interfaz – Secretaría – Menú Cargar Datos – Submenú Representantes 136 Figura 98. Interfaz – Secretaría – Menú Cargar Datos – Submenú Periodos 137
Figura 99. Interfaz – Secretaría – Menú Cargar Datos – Submenú Clases 137
Figura 100. Interfaz – Docente – Página de Inicio 138
Figura 101. Interfaz – Docente – Menú Nóminas – Submenú Alumnos 138 Figura 102. Interfaz – Docente – Menú Calificaciones – Submenú Cargar Notas 139 Figura 103. Interfaz – Docente – Menú Calificaciones – Submenú Reportes 139
Figura 104. Interfaz – Alumno – Página de Inicio 140
Figura 105. Interfaz – Alumno – Menú Reportes – Submenú Parcial 140
xxii
RESUMEN EJECUTIVO
En la actualidad las instituciones públicas y privadas no pueden prescindir de los adelantos tecnológicos, la informática se ha vuelto una herramienta indispensable para el desarrollo y servicio a la comunidad.
Toda la información recopilada que sirvió como argumento para respaldar este programa, se basa en años de observaciones a los problemas vividos a diario en esta institución por la falta de un sistema basado en un software de fácil manejo, el cual dará un cambio total a la atención de la institución hacia la comunidad educativa del sector.
xxiii
EXECUTIVE SUMMARY
Nowadays, public and private institutions cannot prescind from the technological advances, computing has become an indispensable tool for development and service to community.
All information collected which served as an argument to support this program, is based in years of observation the problems daily in this institution by lack system based a software easy to handle, which give a total change to the attention of the institution to the educational community sector.
This application will be an indispensable support for administration of the information in the institution.
1
INTRODUCCIÓN
Desde su aparición los sistemas informáticos y las aplicaciones online se han convertido en herramientas valiosas en el campo empresarial a nivel mundial, es tal que las instituciones académicas, públicas y privadas, las han adoptado rápidamente debido a las grandes ventajas que estas ofrecen como seguridad y gran capacidad de almacenamiento de información.
El Centro de Educación Básica Fisco Misional “Mons. Tomás Romero Gross”, institución educativa ubicada en la ciudad de Puyo, provincia de Pastaza, es una institución educativa que brinda servicios de enseñanza a los niveles pre-primario y primario en las modalidades presencial y vespertina.
Actualmente la institución lleva el registro de sus estudiantes y el control académico por escrito, en libros de matrículas, libros de promociones y en libros de actas, por tal razón no generan respuestas de información rápida y oportuna.
Los reportes sobre el rendimiento académico estudiantil son entregados por los profesores a cada uno de los padres de familia, pero al no generarse un respaldo físico para la institución, ocasiona problemas a los directivos al final del periodo académico debido al reclamo de puntajes que pudieran suscitarse.
2
CAPITULO I
EL PROBLEMA
1.1 PLANTEAMIENTO DEL PROBLEMA
Los procesos de matriculación, registro de notas, consulta y entrega de reportes, que se realizan en el Centro de Educación Básica Fisco Misional “Mons. Tomás Romero Gross” generan malestar a la comunidad educativa, como son: Docentes, Alumnos y Padres de Familia; debido a la lentitud de los procesos. La entrega de reportes que se realizan mes a mes, es uno de los procesos que mayor malestar ocasiona, debido a que los padres de familia deben asistir a las reuniones convocadas por los docentes, y algunos de ellos no pueden asistir por diversas causas.
Otro factor negativo que se visualiza en la institución es el registro de notas, que se realiza de forma manual, generando errores en los cálculos y reclamos por parte de los padres de familia hacia los docentes.
Finalmente se puede constatar que la información generada durante todos los años lectivos de vida institucional, se encuentra depositada en registros, libros y agendas, al alcance de cualquier persona y con el peligro latente de que se puedan adulterar, dañar o sustraerse sin un respaldo adecuado que lo pueda sustituir.
1.1.1 FORMULACIÓN DEL PROBLEMA
3 1.1.2 DELIMITACIÓN DEL PROBLEMA
Sistema Informático de matrículas y control de notas online para el Centro de Educación Básica Fisco Misional “Mons. Tomás Romero Gross”, que se encuentra ubicado en la ciudad de Puyo, provincia de Pastaza.
1.2 OBJETIVOS
1.2.1 OBJETIVO GENERAL
• Implementar un Sistema de Información que permita el registro de matrículas y control de notas online para el Centro de Educación Básica Fisco Misional “Mons. Tomás Romero Gross”.
1.2.2 OBJETIVOS ESPECÍFICOS
• Fundamentar bibliográficamente el diseño de un sistema informático de consultas de notas online para un centro de educación básica.
• Determinar los requisitos del software para cumplir con las expectativas del cliente
• Desarrollar los componentes del sistema académico online “TREDU” para la institución educativa.
1.3 LÍNEA DE INVESTIGACIÓN
• Desarrollo de software y programación de sistemas.
1.4 JUSTIFICACIÓN
4
La presente aplicación es una solución a la problemática suscitada en la institución, la cual permite mejorar de forma eficiente el manejo de la información.
Su interfaz interactiva permite ingresar y visualizar la información académica de la institución y de los estudiantes de forma detallada. Otra ventaja fundamental es que la aplicación es web, para que pueda ser visualizada desde cualquier terminal con conexión a internet, además del hecho que puede consultarse en la institución de la forma tradicional.
Los docentes pueden ingresar la información desde la institución, desde sus domicilios o de cualquier parte del país con un equipo con conexión a internet y la información es actualizada al instante para que pueda ser consultada inmediatamente.
5
CAPITULO II
MARCO TEÓRICO
2.1 ANTECEDENTES INVESTIGATIVOS
“El Ministerio de Educación ha iniciado un proceso sobre la base del esquema de modernización, encaminado al mejoramiento de la gestión y al desarrollo profesional de sus servidores. El objetivo principal del Nuevo Modelo de Gestión Educativa es renovar procesos y automatizar procedimientos para mejorar la atención al público.”
En la web se pueden encontrar un gran número de sitios dedicados a la gestión de instituciones educativas entre las cuales se puede mencionar el sitio www.eskolare.com con su Sistema de Administración y Control Escolar “ESKOLARE” que facilita a los usuarios llevar un control escolar en la gestión de calificaciones. Aunque esta herramienta no está acorde a las nuevas disposiciones del Ministerio de Educación del Ecuador.
El sitio web www.compumax.ec tiene a su disposición la herramienta “EDUMAX”, y como lo menciona en su sitio, es un software de calificaciones diseñado para trabajar a través de la web.
El Tnlgo. José Gabriel Macías Zambrano afirma en su proyecto de tesis “Desarrollar un Sistema Informático de ingreso de matriculas y control de notas para la escuela Fiscal Mixta Portete de Tarqui de la parroquia Colón, ciudad de Portoviejo”, mejorar los procesos mediante la implementación de un sistema informático para llevar los registros
de matriculas y control de notas (pag14).
6
logrado disminuir tiempos y errores en la entrega de la documentación con toda la
información actualizada, ordenada y confiable (pag12).
Con el antecedente expuesto, me permito desarrollar mi trabajo de investigación.
2.2 FUNDAMENTACIÓN TEÓRICA
2.2.1 INGENIERIA DEL SOFTWARE
La aparición de componentes que cada dos años doblan la capacidad de sus antecesores nos ha rodeado en menos de cuatro décadas de máquinas capaces de procesar miles de millones de operaciones por segundo (MTOPS).
En la actualidad son cuatro los factores que imprimen un ritmo acelerado a la industria del hardware: Incremento constante de la capacidad de operación, miniaturización y reducción de costes para la producción de hardware y el avance de las comunicaciones entre sistemas. Estos cuatro factores han extendido el ámbito de aplicación del hardware, e incrementado al mismo ritmo exponencial la complejidad de los sistemas en los que se integra. Este es el escenario creado por la industria del hardware, y que en las tres últimas décadas ha implicado a los desarrolladores de software en retos a los que no han sabido responder con solvencia.
2.2.1.1 Ciclo de vida
Definición.- Conjunto de actividades y tareas relacionadas, que al ejecutarse de forma conjunta transforman una entrada en una salida.
Procesos primarios del ciclo del software:
• Adquisición.- Proceso global que sigue el adquiriente para obtener el producto. • Suministro.- Proceso global que sigue el suministrador para proporcionar el producto. • Desarrollo.- Proceso empleado por el suministrador para el diseño, construcción y
pruebas del producto.
7
• Mantenimiento.- Proceso empleado para mantener el producto, incluyendo tanto los cambios en el propio producto como en su entorno de operación.
2.2.1.2 Modelos
Un modelo representa a un sistema software desde una perspectiva específica. Al igual que la planta y el alzado de una figura en dibujo técnico nos muestran la misma figura vista desde distintos ángulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema.
Los modelos de UML que se tratan en esta parte son los siguientes:
• Diagrama de Estructura Estática. • Diagrama de Casos de Uso. • Diagrama de Secuencia. • Diagrama de Colaboración. • Diagrama de Estados.
2.2.1.2.1 Diagrama de casos de uso
Un diagrama de casos de uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa.
Los elementos que pueden aparecer en un diagrama de casos de uso son: actores, casos de uso y relaciones entre casos de uso.
• Actores.- Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organización, y que realiza algún tipo de interacción con el sistema.
8 2.2.1.2.2 Diagrama de secuencia
Un diagrama de secuencia muestra una interacción ordenada según la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interacción y los mensajes que intercambian ordenados según su secuencia en el tiempo. Cada objeto o actor tiene una línea vertical, y los mensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye de arriba abajo.
2.2.1.2.3 Diagrama de colaboración
Un diagrama de colaboración muestra una interacción organizada basándose en los objetos que toman parte en la interacción y los enlaces entre los mismos. A diferencia de los diagramas de secuencia, los diagramas de colaboración muestran las relaciones entre los roles de los objetos.
En cuanto a la representación, un diagrama de colaboración muestra a una serie de objetos con los enlaces entre los mismos, y con los mensajes que se intercambian dichos objetos.
2.2.2 PROYECTOS INFORMÁTICOS
Es el proceso de gestión para la creación de un sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimación, estimar es echar un vistazo al futuro y aceptar resignados cierto grado de incertidumbre. Aunque la estimación, es más un arte que una ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación de costes de tiempo. Y dado que la estimación es la base de todas las demás actividades de planificación del proyecto y sirve como guía para una buena ingeniería de sistemas y software.
9 2.2.2.1 Planeación del proyecto
La planeación efectiva de un proyecto de software depende de la planeación detallada de su avance, anticipando problemas que puedan surgir y preparando con anticipación soluciones tentativas a ellos. Se supondrá que el administrador del proyecto es responsable de la planeación desde la definición de requisitos hasta la entrega del sistema terminado.
Los puntos analizados posteriormente generalmente son requeridos por grandes sistemas de programación, sin embargo estos puntos son validos también para sistemas pequeños
• Panorama. Hace una descripción general del proyecto detalle de la organización del plan y resume el resto del documento.
• Plan de fases. Se analiza el ciclo de desarrollo del proyecto como es: análisis de requisitos, fase de diseño de alto nivel, fase de diseño de bajo nivel, etc. Asociada con cada fase debe de haber una fecha que especifique cuando se debe terminar estas fases y una indicación de cómo se pueden solapar las distintas fases del proyecto.
• Plan de organización. Se definen las responsabilidades específicas de los grupos que intervienen en el proyecto.
• Plan de pruebas. Se hace un esbozo general de las pruebas y de las herramientas, procedimientos y responsabilidades para realizar las pruebas del sistema.
• Plan de control de modificaciones. Se establece un mecanismo para aplicar las modificaciones que se requieran a medida que se desarrolle el sistema.
• Plan de documentación. Su función es definir y controlar la documentación asociada con el proyecto.
• Plan de capacitación. Se describe la preparación de los programadores que participan en el proyecto y las instrucciones a los usuarios para la utilización del sistema que se les entregue.
• Plan de revisión e informes. Se analiza cómo se informa del estado del proyecto y se definen las revisiones formales asociadas con el avance de proyecto.
• Plan de instalación y operación. Se describe el procedimiento para instalar el sistema en la localidad del usuario.
10
• Índice. Se muestra en donde encontrar las cosas dentro del plan.
• Plan de mantenimiento. Se establece un bosquejo de los posibles tipos de mantenimiento que se tienen que dar para futuras versiones del sistema.
2.2.2.2 Objetivos de la planificación del proyecto
El objetivo de la planificación del proyecto de software es proporcionar un marco de trabajo que permita al gestor de planificación hacer estimaciones razonables de recursos, costos y planificación temporal.
Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberían actualizarse regularmente a medida que progresa el proyecto. Además las estimaciones deberían definir los escenarios del mejor caso, y peor caso, de modo que los resultados del proyecto pueden limitarse.
2.2.2.2.1 Actividades asociadas al proyecto de software
• Ámbito del software.
Es la primera actividad de llevada a cabo durante la planificación del proyecto de software. En esta etapa se deben evaluar la función y el rendimiento que le asignaron al software durante la ingeniería del sistema de computadora para establecer un ámbito de proyecto que no sea ambiguo, e incomprensible para directivos y técnicos.
Describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalúan las funciones del ámbito y en algunos casos se refinan para dar más detalles antes del comienzo de la estimación. Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los límites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes.
• Recursos.
11
pirámide donde las herramientas (hardware y software), son la base proporcional de soporte al esfuerzo de desarrollo, en segundo nivel de la pirámide se encuentran los componentes reutilizables.
Y en la parte más alta de la pirámide se encuentra el recurso primario, las personas (el recurso humano).
- Recursos humanos
- Componentes reutilizables
- Herramientas de software y hardware
Cada recurso queda especificado mediante cuatro características:
- Descripción del recurso. - Informes de disponibilidad.
- Fecha cronológica en la que se requiere el recurso. - Tiempo durante el que será aplicado el recurso.
2.2.2.2.2 Estimación del proyecto de software
En el principio el costo del software constituía un pequeño porcentaje del costo total de los sistemas basados en computadoras. Hoy en día el software es el elemento más caro de la mayoría de los sistemas informáticos.
Es una pequeña planeación sobre qué es lo que va a ser mi proyecto. Una de las actividades cruciales del proceso de gestión del proyecto del software es la planificación.
Cuando se planifica un proyecto de software se tiene que obtener estimaciones de esfuerzo humano requerido, de la duración cronológica del esfuerzo humano requerido, de la duración cronológica del proyecto y del costo.
12
proyecto requiera aproximadamente la misma cantidad de esfuerzo, que dure aproximadamente lo mismo que el trabajo anterior.
Pero qué pasa si el proyecto es totalmente distinto entonces puede que las experiencias obtenidas no sean suficientes.
Se han desarrollado varias técnicas de estimación para el desarrollo de software, aunque cada una tiene sus puntos fuertes y sus puntos débiles, todas tienen en común los siguientes atributos:
• Se han de establecer de antemano el ámbito del proyecto.
• Como bases para la realización de estimaciones se usan métricas del software de proyectos pasados.
• El proyecto se desglosa en partes más pequeñas que se estiman individualmente.
2.2.2.2.3 Estimación basada en el proceso
La técnica más común para estimar un proyecto es basar la estimación en el proceso que se va a utilizar, es decir, el proceso se descompone en un conjunto relativamente pequeño de actividades o tareas, y en el esfuerzo requerido para llevar a cabo la estimación de cada tarea.
Al igual que las técnicas basadas en problemas, la estimación basada en el proceso comienza en una delineación de las funciones del software obtenidas a partir del ámbito del proyecto. Se mezclan las funciones del problema y las actividades del proceso. Como último paso se calculan los costos y el esfuerzo de cada función y la actividad del proceso de software.
2.2.3 XAMPP
13
El programa está liberado bajo la licencia GNU y actúa como un servidor web libre, fácil de usar y capaz de interpretar páginas dinámicas. Actualmente XAMPP está disponible para Microsoft Windows, GNU/Linux, Solaris y MacOS X.
2.2.3.1 Características y requisitos
XAMPP solamente requiere descargar y ejecutar un archivo zip, tar o exe, con unas pequeñas configuraciones en alguno de sus componentes que el servidor Web necesitará. XAMPP se actualiza regularmente para incorporar las últimas versiones de Apache/MySQL/PHP y Perl. También incluye otros módulos como OpenSSL y phpMyAdmin. Para instalar XAMPP se requiere solamente una pequeña fracción del tiempo necesario para descargar y configurar los programas por separado.
2.2.3.2 Aplicaciones
Oficialmente, los diseñadores de XAMPP sólo pretendían su uso como una herramienta de desarrollo, para permitir a los diseñadores de sitios webs y programadores testear su trabajo en sus propios ordenadores sin ningún acceso a Internet. En la práctica, sin embargo, XAMPP es utilizado actualmente como servidor de sitios Web, ya que, con algunas modificaciones, es generalmente lo suficientemente seguro para serlo.
2.2.4 APACHE
El servidor HTTP Apache es un servidor web HTTP de código abierto, para plataformas Unix (BSD, GNU/Linux, etc.), Microsoft Windows, Macintosh y otras, que implementa el protocolo HTTP/1.1 y la noción de sitio virtual.
El servidor Apache se desarrolla dentro del proyecto HTTP Server (httpd) de la Apache Software Foundation.
14 2.2.4.1 Uso
Apache es usado principalmente para enviar páginas web estáticas y dinámicas en la World Wide Web. Muchas aplicaciones web están diseñadas asumiendo como ambiente de implantación a Apache, o que utilizarán características propias de este servidor web.
Apache es el componente de servidor web en la popular plataforma de aplicaciones LAMP, junto a MySQL y los lenguajes de programación PHP/Perl/Python (y ahora también Ruby).
Este servidor web es redistribuido como parte de varios paquetes propietarios de software, incluyendo la base de datos Oracle y el IBM WebSphereapplication server. Mac OS X integra apache como parte de su propio servidor web y como soporte de su servidor de aplicaciones WebObjects. Es soportado de alguna manera por Borland en las herramientas de desarrollo Kylix y Delphi. Apache es incluido con Novell NetWare 6.5, donde es el servidor web por defecto, y en muchas distribuciones GNU/Linux.
Apache es usado para muchas otras tareas donde el contenido necesita ser puesto a disposición en una forma segura y confiable. Un ejemplo es al momento de compartir archivos desde una computadora personal hacia Internet. Un usuario que tiene Apache instalado en su escritorio puede colocar arbitrariamente archivos en la raíz de documentos de Apache, desde donde pueden ser compartidos.
2.2.4.2 Configuración
La mayor parte de la configuración se realiza en el fichero apache2.conf o httpd.conf, según el sistema donde esté corriendo. Cualquier cambio en este archivo requiere reiniciar el servidor, o forzar la lectura de los archivos de configuración nuevamente.
2.2.5 PHP
15
Fue uno de los primeros lenguajes de programación del lado del servidor que se podían incorporar directamente en el documento HTML en lugar de llamar a un archivo externo que procese los datos. El código es interpretado por un servidor web con un módulo de procesador de PHP que genera la página Web resultante.
PHP ha evolucionado por lo que ahora incluye también una interfaz de línea de comandos que puede ser usada en aplicaciones gráficas independientes. PHP puede ser usado en la mayoría de los servidores web al igual que en casi todos los sistemas operativos y plataformas sin ningún costo.
PHP es un acrónimo recursivo que significa PHP Hypertext Pre-processor (inicialmente PHP Tools, o, Personal Home Page Tools). Fue creado originalmente por RasmusLerdorf; sin embargo la implementación principal de PHP es producida ahora por The PHP Group y sirve como el estándar de facto para PHP al no haber una especificación formal. Publicado bajo la PHP License, la Free Software Foundation considera esta licencia como software libre
2.2.5.1 Características
• Orientado al desarrollo de aplicaciones web dinámicas con acceso a información almacenada en una base de datos.
• Es considerado un lenguaje fácil de aprender, ya que en su desarrollo se simplificaron distintas especificaciones.
• El código fuente escrito en PHP es invisible al navegador web y al cliente, ya que es el servidor el que se encarga de ejecutar el código y enviar su resultado HTML al navegador. Esto hace que la programación en PHP sea segura y confiable.
• Capacidad de conexión con la mayoría de los motores de base de datos que se utilizan en la actualidad, destaca su conectividad con MySQL y PostgreSQL.
• Capacidad de expandir su potencial utilizando módulos (llamados ext's o extensiones).
• Posee una amplia documentación en su sitio web oficial, entre la cual se destaca que todas las funciones del sistema están explicadas y ejemplificadas en un único archivo de ayuda.
16
• Permite aplicar técnicas de programación orientada a objetos.
• No requiere definición de tipos de variables aunque sus variables se pueden evaluar también por el tipo que estén manejando en tiempo de ejecución.
• Tiene manejo de excepciones (desde PHP5).
• Debido a su flexibilidad ha tenido una gran acogida como lenguaje base para las aplicaciones WEB de manejo de contenido, y es su uso principal.
2.2.5.2 Inconvenientes
• Como es un lenguaje que se interpreta en ejecución, para ciertos usos puede resultar un inconveniente que el código fuente no pueda ser ocultado. La ofuscación es una técnica que puede dificultar la lectura del código pero no necesariamente impide que el código sea examinado.
• Debido a que es un lenguaje interpretado, un script en PHP suele funcionar considerablemente más lento que su equivalente en un lenguaje de bajo nivel, sin embargo este inconveniente se puede minimizar con técnicas de cache tanto en archivos como en memoria.
• Las variables al no ser tipificadas dificulta a los diferentes IDEs para ofrecer asistencias para el tipificado del código, aunque esto no es realmente un inconveniente del lenguaje en sí. Esto es solventado por Zend Studio añadiendo un comentario con el tipo a la declaración de la variable.
2.2.6 MYSQL
MySQL es un sistema de gestión de bases de datos relacional, multihilo y multiusuario con más de seis millones de instalaciones. MySQL AB —desde enero de 2008 una subsidiaria de Sun Microsystems y ésta a su vez de Oracle Corporation desde abril de 2009— desarrolla MySQL como software libre en un esquema de licenciamiento dual.
17 2.2.6.1 Aplicaciones
MySQL es muy utilizado en aplicaciones web, como Drupal o phpBB, en plataformas (Linux/Windows-Apache-MySQL-PHP/Perl/Python), y por herramientas de seguimiento de errores como Bugzilla. Su popularidad como aplicación web está muy ligada a PHP, que a menudo aparece en combinación con MySQL.
MySQL es una base de datos muy rápida en la lectura cuando utiliza el motor no transaccional MyISAM, pero puede provocar problemas de integridad en entornos de alta concurrencia en la modificación. En aplicaciones web hay baja concurrencia en la modificación de datos y en cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones.
Sea cual sea el entorno en el que va a utilizar MySQL, es importante monitorizar de antemano el rendimiento para detectar y corregir errores tanto de SQL como de programación.
2.2.7 JAVASCRIPT
Java Script es un lenguaje de programación interpretado, dialecto del estándar ECMAScript. Se define como orientado a objetos, basado en prototipos, imperativo, débilmente tipado y dinámico.
Se utiliza principalmente en su forma del lado del cliente (client-side), implementado como parte de un navegador web permitiendo mejoras en la interfaz de usuario y páginas web dinámicas, en bases de datos locales al navegador...4 aunque existe una forma de Java Script del lado del servidor (Server-sideJava Script o SSJS). Su uso en aplicaciones externas a la web, por ejemplo en documentos PDF, aplicaciones de escritorio (mayoritariamente widgets) es también significativo.
2.2.7.1 Características
18
• Imperativo y estructurado
JavaScript soporta gran parte de la estructura de programación de C (por ejemplo, sentencias if, bucles for, sentencias switch, etc.). Con una salvedad, en parte: en C, el ámbito de las variables alcanza al bloque en el cual fueron definidas; sin embargo en JavaScript esto no es soportado, puesto que el ámbito de las variables es el de la función en la cual fueron declaradas. Esto cambia con la versión de JavaScript 1.7, ya que soporta block scoping por medio de la palabra clave let. Como en C, JavaScript hace distinción entre expresiones y sentencias. Una diferencia sintáctica con respecto a C es la inserción automática de punto y coma, es decir, en JavaScript los puntos y coma que finalizan una sentencia pueden ser omitidos.16
• Dinámico
o Tipado dinámico
Como en la mayoría de lenguajes de scripting, el tipo está asociado al valor, no a la variable. Por ejemplo, una variable x en un momento dado puede estar ligada a un número y más adelante, religada a una cadena. JavaScript soporta varias formas de comprobar el tipo de un objeto, incluyendo duck typing.17 Una forma de saberlo es por medio de la palabra clave typeof.
o Objetual
19
o Evaluación en tiempo de ejecución
JavaScript incluye la función eval que permite evaluar expresiones como expresadas como cadenas en tiempo de ejecución. Por ello se recomienda que eval sea utilizado con precaución y que se opte por utilizar la función JSON.parse() en la medida de lo posible, pues resulta mucho más segura.
• Funcional
o Funciones de primera clase
A las funciones se les suele llamar ciudadanos de primera clase; son objetos en sí mismos. Como tal, poseen propiedades y métodos, como .call() y .bind().18 Una función anidada es una función definida dentro de otra. Esta es creada cada vez que la función externa es invocada. Además, cada función creada forma una clausura; es el resultado de evaluar un ámbito conteniendo en una o más variables dependientes de otro ámbito externo, incluyendo constantes, variables locales y argumentos de la función externa llamante. El resultado de la evaluación de dicha clausura forma parte del estado interno de cada objeto función, incluso después de que la función exterior concluya su evaluación.19
• Prototípico
o Prototipos
JavaScript usa prototipos en vez de clases para el uso de herencia.20 Es posible llegar a emular muchas de las características que proporcionan las clases en lenguajes orientados a objetos tradicionales por medio de prototipos en JavaScript.21
o Funciones como constructores de objetos
20
explícita de una instancia sin tener que heredar automáticamente del prototipo de Object (en entornos antiguos puede aparecer el prototipo del objeto creado como null).23 La propiedad prototype del constructor determina el objeto usado para el prototipo interno de los nuevos objetos creados. Se pueden añadir nuevos métodos modificando el prototipo del objeto usado como constructor. Constructores predefinidos en JavaScript, como Array u Object, también tienen prototipos que pueden ser modificados. Aunque esto sea posible se considera una mala práctica modificar el prototipo de Object ya que la mayoría de los objetos en Javascript heredan los métodos y propiedades del objeto prototype, objetos los cuales pueden esperar que estos no hayan sido modificados.
2.2.8 ExtJS
ExtJS (pronunciado como "ekst") es una biblioteca de Java Script para el desarrollo de aplicaciones web interactivas usando tecnologías como AJAX, DHTML y DOM. Fue desarrollada por Sencha.
Originalmente construida como una extensión de la biblioteca YUI por Jack Slocum, en la actualidad puede usarse como extensión para las bibliotecas jQuery y Prototype. Desde la versión 1.1 puede ejecutarse como una aplicación independiente.
2.2.8.1 Funcionalidades
Dispone de un conjunto de componentes (widgets) para incluir dentro de una aplicación web, como:
• Cuadros y áreas de texto.
• Campos para fechas.
• Campos numéricos.
• Combos.
• Radiobuttons y checkboxes.
• Editor HTML.
21
• Árbol de datos.
• Pestañas.
• Barra de herramientas.
• Menús al estilo de Windows.
• Paneles divisibles en secciones.
• Sliders.
• Gráficos
Varios de estos componentes están capacitados para comunicarse con el servidor usando AJAX. También contiene numerosas funcionalidades que permiten añadir interactividad a las páginas HTML, como:
• Cuadros de diálogo.
• Quicktips para mostrar mensajes de validación e información sobre campos individuales.
2.2.9 ARQUITECTURA CLIENTE - SERVIDOR
La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, quien le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.
En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.
22
de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma.
La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico.
2.2.9.1 Características
En la arquitectura C/S el remitente de una solicitud es conocido como cliente. Sus características son:
• Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo).
• Espera y recibe las respuestas del servidor.
• Por lo general, puede conectarse a varios servidores a la vez.
• Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario.
• Al contratar un servicio de redes, se debe tener en cuenta la velocidad de conexión que le otorga al cliente y el tipo de cable que utiliza, por ejemplo: cable de cobre ronda entre 1 ms y 50 ms.
Al receptor de la solicitud enviada por el cliente se conoce como servidor. Sus características son:
• Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo).
• Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente.
• Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos casos el número máximo de peticiones puede estar limitado).
23 2.2.9.2 Arquitecturas multi-capas
La arquitectura cliente/servidor genérica tiene dos tipos de nodos en la red: clientes y servidores. Consecuentemente, estas arquitecturas genéricas se refieren a veces como arquitecturas de dos niveles o dos capas.
Algunas redes disponen de tres tipos de nodos:
• Clientes que interactúan con los usuarios finales.
• Servidores de aplicación que procesan los datos para los clientes.
• Servidores de la base de datos que almacenan los datos para los servidores de aplicación.
Esta configuración se llama una arquitectura de tres-capas.
• Ventajas de las arquitecturas n-capas:
o La ventaja fundamental de una arquitectura n-capas comparado con una arquitectura de dos niveles (o una tres-capas con una de dos niveles) es que separa hacia fuera el proceso, eso ocurre para mejorar el balance la carga en los diversos servidores; es más escalable.
• Desventajas de las arquitecturas de la n-capas:
o Pone más carga en la red, debido a una mayor cantidad de tráfico de la red.
o Es mucho más difícil programar y probar el software que en arquitectura de dos niveles porque tienen que comunicarse más dispositivos para terminar la transacción de un usuario.
2.2.9.3 Ventajas
24
Escalabilidad: se puede aumentar la capacidad de clientes y servidores por separado. Cualquier elemento puede ser aumentado (o mejorado) en cualquier momento, o se pueden añadir nuevos nodos a la red (clientes y/o servidores).
Fácil mantenimiento: al estar distribuidas las funciones y responsabilidades entre varios ordenadores independientes, es posible reemplazar, reparar, actualizar, o incluso trasladar un servidor, mientras que sus clientes no se verán afectados por ese cambio (o se afectarán mínimamente). Esta independencia de los cambios también se conoce como encapsulación.
Existen tecnologías, suficientemente desarrolladas, diseñadas para el paradigma de C/S que aseguran la seguridad en las transacciones, la amigabilidad de la interfaz, y la facilidad de empleo.
2.2.9.4 Desventajas
La congestión del tráfico ha sido siempre un problema en el paradigma de C/S. Cuando una gran cantidad de clientes envían peticiones simultáneas al mismo servidor, puede ser que cause muchos problemas para éste (a mayor número de clientes, más problemas para el servidor). Al contrario, en las redes P2P como cada nodo en la red hace también de servidor, cuantos más nodos hay, mejor es el ancho de banda que se tiene.
El paradigma de C/S clásico no tiene la robustez de una red P2P. Cuando un servidor está caído, las peticiones de los clientes no pueden ser satisfechas. En la mayor parte de redes P2P, los recursos están generalmente distribuidos en varios nodos de la red. Aunque algunos salgan o abandonen la descarga; otros pueden todavía acabar de descargar consiguiendo datos del resto de los nodos en la red.
El software y el hardware de un servidor son generalmente muy determinantes. Un hardware regular de un ordenador personal puede no poder servir a cierta cantidad de clientes. Normalmente se necesita software y hardware específico, sobre todo en el lado del servidor, para satisfacer el trabajo. Por supuesto, esto aumentará el coste.
25
directamente sobre las impresoras sin sacar antes la ventana previa de impresión de los navegadores.
2.2.10 GPL
La Licencia Pública General de GNU o más conocida por su nombre en inglés GNU General PublicLicense o simplemente sus siglas del inglés GNUGPL, es una licencia creada por la Free Software Foundation en 1989 (la primera versión, escrita por Richard Stallman), y está orientada principalmente a proteger la libre distribución, modificación y uso de software. Su propósito es declarar que el software cubierto por esta licencia es software libre y protegerlo de intentos de apropiación que restrinjan esas libertades a los usuarios.
2.2.10.1 Validez legal
La licencia GPL, al ser un documento que cede ciertos derechos al usuario, asume la forma de un contrato, por lo que usualmente se la denomina contrato de licencia o acuerdo de licencia. En los países de tradición anglosajona existe una distinción doctrinal entre licencias y contratos, pero esto no ocurre en los países de tradición civil o continental. Como contrato, la GPL debe cumplir los requisitos legales de formación contractual en cada jurisdicción.
2.3 IDEA A DEFENDER
26
CAPITULO III
MARCO METODOLÓGICO
3.1 MODALIDAD DE LA INVESTIGACIÓN
La modalidad aplicada al presente trabajo fue la investigación de campo, donde se recopiló información del personal administrativo y docente de la institución sobre sus inquietudes y necesidades. Se constató la situación real de la gestión y manejo de la información académica y se plantearon los requerimientos para la elaboración de la aplicación.
3.2 TIPOS DE INVESTIGACIÓN
• Documental – Bibliográfica.- Por cuanto se utilizó un amplio marco bibliográfico referente a los componentes, equipos y metodologías que se imparten en la institución.
• De campo.- Ya que se realizó directamente en la institución, esto permitió obtener información amplia y objetiva, que ha sido procesada y analizada, cuyos resultados favorecen al desarrollo de la propuesta.
3.3 POBLACIÓN Y MUESTRA
27 La población considerada para esta investigación:
UNIDADES DE OBSERVACION POBLACIÓN MUESTRA
Personal Administrativo 2 2
Personal Docente 22 22
Como la población del personal administrativo y docente es menor a 100, se trabajará con toda la población. Por lo tanto la muestra es del 100% de la población.
3.4 MÉTODOS, TÉCNICAS E INSTRUMENTOS
3.4.1 MÉTODOS
• Lógico – Inductivo.- Es un método científico que saca conclusiones generales de algo particular. El inductivismo se caracteriza por tener 4 etapas básicas:
o Observación y registro de todos los hechos
o Análisis y clasificación de los hechos
o Derivación inductiva de una generalización a partir de los hechos
o Contrastación
• Bibliográfico.- Ayudó a recabar información para la investigación. Para ello se consultó en libros, folletos y páginas web.
3.4.2 TÉCNICAS
• Entrevista: Técnica que complementa los requerimientos de la investigación. Esta técnica es personal, directa con la persona entrevistada. Se aplicará a los directivos y personal docente de la institución.
28 3.4.3 INSTRUMENTOS
• Cuestionario: Es un instrumento que recaba información dedicada a obtener información a través de un sistema de preguntas, estructurado en formularios impresos, que el informante responde por sí mismo y servirá de enlace entre los objetivos de la investigación y la realidad estudiada. Este instrumento sirvió de guía para aplicar la entrevista a los Directivos y a los Docentes de la Institución.
• Ficha de observación: Son instrumentos donde se registra la descripción detallada de lugares, personas, etc., que forman parte de la investigación. Las fichas de observación directa se usan especialmente para iniciar el proceso de observación, pueden acompañar a una entrevista para reforzar la información.
3.5 INTERPRETACIÓN DE RESULTADOS
La Entrevista es una conversación entre dos o más personas, en la cual uno es el que pregunta (entrevistador). Estas personas dialogan con arreglo a ciertos esquemas o pautas de un problema o cuestión determinada, teniendo un propósito profesional. Presupone la existencia de personas y la posibilidad de interacción verbal dentro de un proceso de acción recíproca. Como técnica de recolección va desde la interrogación estandarizada hasta la conversación libre, en ambos casos se recurre una guía que puede ser un formulario o esquema de cuestiones que permita orientar la conversación.
Composición de la muestra de la investigación
COMPONENTES NR
Personal Administrativo – Director y Secretaria
2
Personal Docente 22
29
ENTREVISTA PERSONAL ADMINISTRATIVO DIRECTOR DE LA INSTITUCIÓN
Pregunta 1.- ¿Cuáles son sus actividades y responsabilidades en la institución?
• Análisis
Ley Orgánica de Educación Intercultural. Art 44, numerales del 1 al 21.
o Dirigir y controlar la implementación eficiente de programas académicos. (…)
o Autorizar las matriculas ordinarias y extraordinarias, y los pases de los estudiantes.
o Legalizar los documentos estudiantiles y responsabilizarse, junto con el Secretario del plantel, de la custodia del expediente académico de los estudiantes.
o Aprobar el distributivo de trabajo de docentes. (…)
o Elaborar, (…), el cronograma de actividades, el calendario académico, (…).
o Aprobar los horarios de clases, de exámenes, (…).
o Remitir oportunamente los datos estadísticos veraces, informes y más documentos (…).
• Interpretación
o Autorizar la creación, modificación de: años lectivos, cursos, asignaturas y clases académicas para el nuevo periodo escolar.
o Autorizar el ingreso de estudiantes en la fase de matriculas extraordinarias.
o Aprobar el calendario académico, autorizar el ingreso de notas parciales, exámenes quimestrales, notas rezagadas.
30
Pregunta 2.- ¿Qué tipo de documentación académica se le solicita como director de la institución?
• Análisis
Documentos, reportes, informes, nóminas, actas.
• Interpretación
o Reportes de notas,
o Informes académicos,
o Nóminas de docentes
o Nóminas de estudiantes.
Pregunta 3.- ¿Considera que el método utilizado en la institución para la generación de la documentación académica es el óptimo? ¿Cómo mejorarla?
• Análisis
No es el óptimo, para mejorar el proceso, los documentos académicos: reportes, nóminas, informes, se deben generar automáticamente.
• Interpretación
31
Pregunta 4.- ¿Qué requisitos se requieren para la matriculación de los estudiantes en la institución?
• Análisis
La matriculación es única, para los estudiantes nuevos se requiere:
o Copia de la partida de nacimiento y/o cédula de identidad
o 2 fotos tamaño carnet
o Datos personales del representante.
o Pase de año, libreta de calificaciones o reporte de notas finales del año anterior.
• Interpretación
o Datos personales del estudiantes: Apellidos y nombres completos, lugar y fecha de nacimiento, número de cédula (opcional)
32
Pregunta 5.- ¿Qué persona o personas tienen la responsabilidad del ingreso de las notas académicas de los estudiantes?
• Análisis
o Los docentes ingresan las notas, de forma digital o manual. Emiten los reportes de notas de los estudiantes a los padres de familia personalmente. (1ro a 7mo AEB)
o El profesor designado como secretario de la institución emite los reportes de notas. Se entrega a los tutores (8vo a 10mo AEB)
• Interpretación
o Los docentes ingresan las notas (parciales) digitalmente.
o Los reportes de notas se generan automáticamente. Se genera un informe de ingreso de notas (fecha, hora, responsable)
33
ENTREVISTA PERSONAL ADMINISTRATIVO SECRETARIO DE LA INSTITUCIÓN
Pregunta 1.- ¿Cuáles son sus actividades y responsabilidades en la institución?
• Análisis
Ley Orgánica de Educación Intercultural. Art 57, numerales del 1 al 6.
o Llevar los libros, registros y formularios oficiales y responsabilizarse de su conservación, integridad, inviolabilidad y reserva;
o Organizar, centralizar y mantener actualizada la estadística y el archivo del establecimiento;
o Ingresar con exactitud los datos y registros académicos que requiera el sistema de información del Ministerio de Educación;
o Conferir, previa autorización del Rector o Director, copias y certificaciones;
o Suscribir, de conformidad con las disposiciones reglamentarias, y junto con el Rector o Director, los documentos de matrícula y promoción, y los formularios o registros de datos requeridos por el Sistema de información del Ministerio de Educación.
• Interpretación
o Ingresar y/o modificar datos de alumnos, representantes y docentes.
o Actualizar los datos de años lectivos y clases.
o Emitir reportes, informes y certificaciones.
