Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 128

UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES


CARRERA DE INFORMATICA

PROYECTO DE GRADO

“SISTEMA DE INFORMACION VIA WEB


CASO: UNIDAD EDUCATIVA REPUBLICA DE CUBA”

PARA OPTAR AL TÍTULO DE LICENCIATURA EN INFORMÁTICA


MENCIÓN: INGENIERIA DE SISTEMAS INFORMÁTICOS

POSTULANTE: OMAR QUISPE RODRIGUEZ


TUTOR METODOLOGICO: LIC. HAVIER HUGO REYES PACHECO

ASESOR: M. Sc. CARLOS MULLISACA CHOQUE

LA PAZ – BOLIVIA

2015
UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA

LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y


NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE
DOCUMENTO SI LOS PROPÓSITOS SON ESTRICTAMENTE ACADÉMICOS.

LICENCIA DE USO

El usuario está autorizado a:

a) visualizar el documento mediante el uso de un ordenador o dispositivo móvil.


b) copiar, almacenar o imprimir si ha de ser de uso exclusivamente personal y privado.
c) copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.

El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este


material, sin la autorización correspondiente.

TODOS LOS DERECHOS RESERVADOS. EL USO NO AUTORIZADO DE LOS


CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARA EN EL INICIO DE
ACCIONES LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
DEDICATORIA
Este proyecto va dedicado a
mis padres Cristóbal y Eliza
por el apoyo y confianza
incondicional durante estos
años de estudio siendo ellos
un impulso y una razón para
luchar hacia adelante en la
vida
AGRADECIMIENTOS
A mi docente tutor Lic. Javier Hugo Reyes Pacheco por
su ayuda desinteresada y su ayuda en el desarrollo del
proyecto en cada uno de los capítulos.
Gratitud con mi asesor Lic. Carlos Mullisaca Choque por
su confianza, paciencia y colaboración con el proyecto
brindándome consejos necesarios para un adecuado
desarrollo.
A la Lic. Mary Medina Vega por darme la oportunidad de
realizar el proyecto en la Unidad Educativa República de
Cuba además de brindarme su apoyo en cada paso
requerido.
A mi compañero Ronald Conde por la ayuda en cuanto a
distintas tareas a lo largo del camino.
A los docentes de la carrera de informática por brindarme
la guía y enseñanzas en cada una de las materias sin lo
cual fuese imposible realizar de una buena manera el
proyecto.
A mis compañeros de la carrera de Informática por la
amistad en momentos malos y buenos siempre con una
ayuda constante
RESUMEN

El Sistema De Información Vía Web para la Unidad Educativa República de Cuba fue
desarrollado para reemplazar el estereotipo de manejo de información de una manera
manual porque como sabemos el control en una institución educativa es incomoda ya
que la institución cuenta con estudiantes en los niveles primario y secundario por lo
que el registro genera bastante papeleo innecesario provocando muchas veces
perdida de información no se cuenta con una aval en cuanto a estudiantes, docentes,
inventario entre otros por lo que el Sistema de información automatizara estos
procesos mencionados.

La metodología que se empleó para el desarrollo del presente proyecto es la


metodología ágil XP Programación Extrema con el apoyo de UML y los diagramas
WebML .El lenguaje de programación PHP con un servidor APACHE Utilizando un
motor de Base de Datos MySQL.

Uno de los primeros pasos fue obtener una base de datos que contenga información
relevante acerca de la institución y de cada uno de los elementos y actores que
participan según los requerimientos de la administración de la institución.

Se desarrollaron los módulos de Registro de docentes, estudiantes, inventario y


calificaciones en el caso del módulo de calificaciones el registro de notas por materia
y la generación de boletines estudiante que es de imperiosa necesidad, los informes
son un punto que se realiza en el proyecto en cuanto a docentes, estudiantes e
inventario.

En cuanto a la evaluación del Sistema En cuanto a calidad se utilizó el modelo ISO-


9126 con las debidas normas de seguridad con las respectivas autenticaciones de
usuario realizando la respectiva estimación de costos y beneficios.
Contenido
CAPITULO 1 MARCO REFERENCIAL ................................................................................... 1
1.1 ANTECEDENTES ...................................................................................................................... 2
1.1.1 Antecedentes Institucionales ....................................................................................... 2
1.2 PROYECTOS SIMILARES ....................................................................................................... 3
1.3 PLANTEAMIENTO DEL PROBLEMA................................................................................... 3
1.3.1 Problema Central.............................................................................................................. 3
1.3.2 Problema Secundario ....................................................................................................... 4
1.4 PREGUNTA................................................................................................................................. 5
1.5 OBJETIVOS ................................................................................................................................ 5
1.5.1 Objetivo General ................................................................................................................ 5
1.5.2 Objetivos Específicos ...................................................................................................... 5
1.6 JUSTIFICACION ........................................................................................................................ 6
1.6.1 Justificación Tecnológica ............................................................................................... 6
1.6.2 Justificación Social .......................................................................................................... 6
1.6.3 Justificación Económica ................................................................................................. 6
1.7 ALCANCES Y LIMITES ............................................................................................................ 7
1.7.1 Alcances .............................................................................................................................. 7
1.7.2 Limites .................................................................................................................................. 7
1.8 APORTES .................................................................................................................................... 7
1.9 METODOLOGIA Y TÉCNICAS A EMPLEAR ....................................................................... 8
1.9.1 Metodología ........................................................................................................................ 8
1.9.2 Técnicas............................................................................................................................... 9
CAPITULO 2 MARCO TEORICO ......................................................................................... 10
2.1 SITUACION ACTUAL DEL SISTEMA.................................................................................. 10
2.2 INGENIERIA DE SOFTWARE .................................................................................................. 10
2.3 METODOLOGIAS DE DESARROLLO AGIL .......................................................................... 11
2.4 PROGRAMACION EXTREMA .................................................................................................. 12
2.4 1 Planeación......................................................................................................................... 13
2.4.2 Diseño ............................................................................................................................... 17
2.4.3 Codificación .................................................................................................................. 18
2.4.4 Pruebas ............................................................................................................................. 19
2.5 INGENIERIA WEB ................................................................................................................. 20
2.5.1 Marco De Trabajo Para La Ingeniería Web ................................................................................. 21
2.6 UML ............................................................................................................................................ 24
2.6.1 Casos De Uso ................................................................................................................. 25
2.6.2 Diagrama De Actividades ........................................................................................... 26
2.7 WEBML ..................................................................................................................................... 27
2.7.1 Modelo Estructural.......................................................................................................... 29
2.7.2 Modelo De Hipertexto .................................................................................................. 29
2.7.3 Modelo De Presentación .......................................................................................... 32
2.7.4 Modelo De Personalización ............................................................................................. 33
2.8 CALIDAD Y SEGURIDAD DE SOFTWARE ................................................................... 33
2.8.1 Calidad De Software (NORMA ISO_9126)..................................................................... 33
2.8.2 Seguridad De La Información ................................................................................... 36
2.9 Marco Tecnológico ................................................................................................................... 37
2.9.1 Gestor De Base De Datos MYSQL .................................................................................. 37
2.9.2 Servidor Web “APACHE" .............................................................................................. 37
2.9.3 Lenguaje De Programación PHP ................................................................................. 38
2.9.4 Dreamweaver .................................................................................................................... 38
2.9.5 XAMPP................................................................................................................................ 39
2.9.6 Hojas De Estilo................................................................................................................. 40
CAPITULO 3 MARCO APLICATIVO ..................................................................................... 41
3.1 UTILIZACIÓN Y MANEJO DE XP EN EL PROYECTO .................................................... 41
3.2 PROCEDIMIENTO DE ELABORACIÓN DEL PROYECTO ............................................. 43
3.3 Planeación ................................................................................................................................ 43
3.3.1 Historias de Usuario ....................................................................................................... 43
3.3.2 Actores ............................................................................................................................... 53
3.3.3 Iteraciones y Velocidad Del Proyecto ........................................................................ 54
3.4 Diseño y Codificación ........................................................................................................... 56
3.4.1 Primer Incremento .......................................................................................................... 56
3.4.2 Segundo Incremento ...................................................................................................... 61
3.4.3 Tercer Incremento ........................................................................................................... 67
3.4.4 Cuarto Incremento .......................................................................................................... 72
3.4.5 Quinto Incremento .......................................................................................................... 77
3.4.6 Sexto Incremento ............................................................................................................ 83
3.5 Pruebas ..................................................................................................................................... 91
3.5.1 Modelo de Personalización........................................................................................... 91
CAPITULO 4 EVALUACION DEL SISTEMA......................................................................... 94
4.1 CALIDAD DE SOFTWARE .................................................................................................... 94
4.1.1 Funcionalidad................................................................................................................... 94
4.1.2 Confiablidad...................................................................................................................... 96
4.1.3 Mantenibllidad .................................................................................................................. 97
4.1.4 Portabilidad....................................................................................................................... 98
4.1.5 Usabilidad.......................................................................................................................... 98
4.2 SEGURIDAD DEL SOFTWARE ............................................................................................ 99
4.2.1 Autenticación De Usuario ........................................................................................... 100
4.4.2 Seguridad en la Base de Datos ................................................................................. 100
4.3 ANALISIS DE COSTO/BENEFICIO DEL SISTEMA....................................................... 102
CAPITULO 5 CONCLUSIONES Y RECOMENDACIONES ................................................. 106
5.1 Conclusiones ......................................................................................................................... 106
5.2 Recomendaciones ................................................................................................................ 106
INDICE DE FIGURAS

Figura 2. 1Actividades de XP ........................................................................................................................... 13


Figura 2. 2 Modelo de Proceso Para WebApp ................................................................................................. 21
Figura 2. 3 Diagrama de Casos de Uso ............................................................................................................. 25
Figura 2. 4 Diagrama de Actividades con swinlene .......................................................................................... 27
Figura 2. 5 Ciclo de Vida WebML ..................................................................................................................... 28
Figura 2. 6 Fases del Modelado WebML .......................................................................................................... 28
Figura 2. 7 Modelo Estructural ........................................................................................................................ 29
Figura 2. 8 Modelo de Composición ................................................................................................................ 31
Figura 2. 9 Modelo de Navegación .................................................................................................................. 32
Figura 2. 10 Modelo de Personalización .......................................................................................................... 33

Figura 3. 1 Descripción de los Incrementos. .................................................................................................... 55


Figura 3. 2 Cronograma de Actividades ........................................................................................................... 55
Figura 3. 3 Caso de Uso Registro de Información Docente .............................................................................. 56
Figura 3. 4 D.A. de Registro de Información docente ...................................................................................... 58
Figura 3. 5 Diagrama de Clases Registro de Información Docente ................................................................... 58
Figura 3. 6 Modelo de Hipertexto Registro Docente ....................................................................................... 60
Figura 3. 7 Modelo de Presentación Registro Docente .................................................................................... 61
Figura 3. 8 CU proceso de Generación de Informe (Docentes) ........................................................................ 62
Figura 3. 9 DA de CU del Proceso de Generación informe Docentes ................................................................ 63
Figura 3. 10 Diagrama de Clases Generación de Informe Docentes ................................................................. 64
Figura 3. 11 Diagrama de Hipertexto Generación de Informe Docentes .......................................................... 66
Figura 3. 12 Modelo de Presentación Formulario De Modificación ................................................................. 67
Figura 3. 13 Modelo de Presentación Informe Docente .................................................................................. 67
Figura 3. 14 CU Registro de Información Estudiante ....................................................................................... 68
Figura 3. 15 Diagrama de Clases Registro Estudiante ...................................................................................... 69
Figura 3. 16 Modelo de Hipertexto Registro Estudiante .................................................................................. 71
Figura 3. 17 Modelo de Presentación Registro Estudiantes ............................................................................. 71
Figura 3. 18 CU Proceso de Generación Informe Estudiante ............................................................................ 72
Figura 3. 19 Diagrama de clases Generación de Informe Estudiante ............................................................... 73
Figura 3. 20 Modelo de Hipertexto Generación de Informe Estudiante........................................................... 75
Figura 3. 21 Modelo de Presentación de Modificación Datos Estudiante ........................................................ 76
Figura 3. 22 Modelo de Presentación Informe Estudiante ............................................................................... 76
Figura 3. 23 CU Modulo de Inventarios ........................................................................................................... 77
Figura 3. 24 DA Modulo de Inventario ............................................................................................................ 79
Figura 3. 25 Diagrama de Clases Modulo de Inventarios ................................................................................. 81
Figura 3. 26 Modelo de Hipertexto Modulo de Inventario .............................................................................. 81
Figura 3. 27 Modelo de Presentación Registro Inventario ............................................................................... 82
Figura 3. 28 Modelo de Presentación Informe Inventario ............................................................................... 83
Figura 3. 29 CU Modulo de Calificaciones........................................................................................................ 83
Figura 3. 30 DA Modulo de Calificaciones ....................................................................................................... 85
Figura 3. 31 Diagrama de Clases Modulo de Calificaciones ............................................................................. 86
Figura 3. 32 Modelo de Hipertexto Modulo de Calificaciones ......................................................................... 88
Figura 3. 33 Modelo de Presentación Registro de Calificaciones ..................................................................... 89
Figura 3. 34 Modelo de Presentación Boletín de Calificaciones ....................................................................... 90
Figura 3. 35 Banner ......................................................................................................................................... 91
Figura 3. 36 Diagrama de Clases Administrativo ............................................................................................. 91
Figura 3. 37 Diagrama de Componentes Registro ............................................................................................ 92
Figura 3. 38 Diagrama de componentes Generación de Informes ................................................................... 93
Figura 3. 39 Usuarios....................................................................................................................................... 99
Figura 3. 40 Autenticación de Usuario ...........................................................................................................100
Figura 3. 41 Panel de Activación XAMPP ........................................................................................................101
Figura 3. 42 Autenticación de Usuario PhpMyAdmin .....................................................................................101
INDICE DE TABLAS

Tabla 2. 1 Diferencia Entre Metodologías Agiles y Tradicionales ..................................................................... 12


Tabla 2. 2 Modelo Propuesto Para Una Historia de Usuario ............................................................................ 14
Tabla 2. 3 Tarjeta CRC ..................................................................................................................................... 17
Tabla 2. 4 Características de ISO-9126 y aspecto que articula cada una .......................................................... 34

Tabla 3. 1 Actividades fusionadas con Herramientas ..................................................................................... 41


Tabla 3. 2 Historia de Usuario nª1 Registro Docentes ..................................................................................... 44
Tabla 3. 3 tarea 1.1 Diseñar el módulo de Registro ......................................................................................... 44
Tabla 3. 4 Tarea 1.2 Asignación de Aulas......................................................................................................... 45
Tabla 3. 5 Historia de usuario nº2 Generación de informe docente ................................................................ 45
Tabla 3. 6 tarea 2.1 modificación de datos ...................................................................................................... 46
Tabla 3. 7 tarea 2.2 Generación de informe .................................................................................................... 46
Tabla 3. 8 Historia de Usuario nª3 Registro de Estudiante .............................................................................. 47
Tabla 3. 9 Tarjeta de tarea 3.1 Verificación de Estudiante ............................................................................... 47
Tabla 3. 10 Tarea 3.2Registro del Estudiante .................................................................................................. 48
Tabla 3. 11 Tarea 3.3 Asignación de aulas a Estudiantes ............................................................................... 48
Tabla 3. 12 Historia de Usuario nª4 Generación de informe Estudiante .......................................................... 48
Tabla 3. 13 Tarea 4.1 Modificar Datos Estudiante ........................................................................................... 49
Tabla 3. 14 Tarea 4.2 Generar informe Estudiante .......................................................................................... 50
Tabla 3. 15 Historia de Usuario nª5 Inventario ................................................................................................ 50
Tabla 3. 16 Tarea 5.1 Registro del Inventario .................................................................................................. 51
Tabla 3. 17 Tarea 5.2 Verificación de datos Inventario .................................................................................... 51
Tabla 3. 18 Tarea 5.3 Generación de Informe Inventario ................................................................................ 51
Tabla 3. 19 Historia de Usuario nª6 Calificaciones ........................................................................................... 52
Tabla 3. 20 Tarea 6.1 Registro de Calificaciones .............................................................................................. 52
Tabla 3. 21 Tarea 6.2 Generación de Boletín de Calificaciones ........................................................................ 53
Tabla 3. 22 Actores del Proyecto ..................................................................................................................... 53
Tabla 3. 23 Interacción Actor Sistema en el Registro Docente ......................................................................... 57
Tabla 3. 24 Tarjeta CRC Registro de Docente................................................................................................... 59
Tabla 3. 25 Interacción Actor Sistema Generación de Información Docente ................................................... 62
Tabla 3. 26 Tarjeta CRC Modificación de Datos ............................................................................................... 65
Tabla 3. 27 Tarjeta CRC Generación de Informe .............................................................................................. 65
Tabla 3. 28 Interacción Actor Sistema Generación de Informe Estudiante ...................................................... 68
Tabla 3. 29 Tarjeta CRC Registro de Estudiantes ............................................................................................. 70
Tabla 3. 30 Interacción Actor y Sistema en la Generación de Informe Estudiante ........................................... 73
Tabla 3. 31 Tarjeta CRC Modificación de Datos ............................................................................................... 74
Tabla 3. 32 Tarjeta CRC Generación de Informe Estudiante ............................................................................ 74
Tabla 3. 33 Interacción Actor y Sistema en el Módulo de Inventarios ............................................................. 78
Tabla 3. 34 Tarjeta CRC Registro de Inventario ............................................................................................... 79
Tabla 3. 35 Tarjeta CRC Generación de Informe Inventario ............................................................................. 80
Tabla 3. 36 Interacción Actor Sistema Modulo de Calificaciones ..................................................................... 84
Tabla 3. 37 Tarjeta CRC Registro de Calificaciones .......................................................................................... 86
Tabla 3. 38 Informe de Calificaciones .............................................................................................................. 87
Tabla 4. 1 Cálculo de Punto Funcion 94
Tabla 4. 2 Valores de Ajuste de Complejidad 95
Tabla 4. 3 Evaluación de Usabilidad 98
Tabla 4. 4 Modelo COCOMO 102
Tabla 4. 5 Costo de Implementación 104
Tabla 4. 6 Gastos 104
como sabemos en este tiempo vivimos nuevos tiempos de cambio, la educación La
educación tiene nuevas reglas esto por la nueva ley “Avelino Siñani-Elizardo Perez” la
cual define nuevas políticas para los estudiantes del Estado Plurinacional de Bolivia
todo esto en un marco de respeto a la diversidad y pluralidad de todo tipo.

En este sentido la Unidad Educativa República de Cuba que se encuentra ubicado en


el distrito 2 de la ciudad de el alto zona “Villa Ingenio” actualmente está a cargo de la
Directora Mary Medina Vega con la formación a nivel licenciatura plantea las siguientes
políticas educativas: educación para producir gente innovadora, educación
comunitaria con los demás miembros de la sociedad, educación para la vida que
promueva el respeto mutuo entre las personas enriqueciéndolas de valores entre otros.

En cuanto al diseño curricular se recoge un enfoque práctico- teórico interrelacionando


estos dos campos obtenemos un desarrollo integral para formar así al futuro
profesional, fortaleciendo así el desarrollo económico de toda una región.

Vivimos tiempos de cambio donde la revolución de las tecnologías de la información


hace más necesario el uso del tratamiento automatizado de la información
produciendo un manejo más adecuado de la información, más comodidad al momento
de intercambiar información y el compartimiento de saberes tecnológicos
disminuyendo así el trabajo arduo y redundante, optimizando de esta manera el flujo
de información.

Es así que la información se va convirtiendo en el motor principal de nuestras vidas


haciendo más fácil el trabajo en instituciones que manejan bastante información en
grandes cantidades ya que la demanda de estudiantes para mi caso va
incrementándose. La unidad educativa cuenta con los niveles primario secundario lo
cual conlleva la realización de varias actividades sobre todo al acabar un bimestre, de
esta forma es que al momento de realizar informes por alumno esto de manera manual
hace que los procesos sean morosos llevando al retraso de los procesos, ocasionando
dificultades dentro de la institución.

1
En este proyecto afrontare todos estos inconvenientes implementando un” Sistema de
Información Académico vía web para la Unidad Educativa República De Cuba que
coadyuve con los procesos en el área académica con información segura optima y en
tiempo real reduciendo la carga del personal administrativo.

1.1 ANTECEDENTES
1.1.1 Antecedentes Institucionales
La Unidad Educativa República de Cuba se encuentra ubicada en la ciudad de el alto
exactamente en el distrito 2 zona villa ingenio cuenta con los niveles de primaria y
secundaria.

Esta legalmente constituida y es dependiente del ministerio de educación por lo cual


se ve en la necesidad de tener informados a los padres de familia sobre el
comportamiento de sus hijos en la institución, informes inscritos a distrital de el Alto lo
cual conlleva bastante manejo de información tanto internamente y externamente.

Realizando el estudio correspondiente en la institución y la ingeniería de


requerimientos se logró evidenciar la ausencia de un sistema de información el cual
proporcione información sobre docentes y estudiantes de la Unidad Educativa
República de Cuba. Sin embargo me vi en la tarea de resolver estos problemas, el
problema comienza en la secretaria donde se lleva a cabo todas estas exigencias que
llevan a un problema al momento de brindar información en un determinado lapso de
tiempo ya que debe cumplir las normas establecidas por el ministerio de educación y
requisitos que deben cumplir docentes y estudiantes que es el punto en cuestión.

Secretaria no cuenta con un sistema de información que realice procesos como ser
registro de docentes y estudiantes (base de datos), emisión de boletines de
calificaciones para los padres de familia en tiempo real, un adecuado registro del
inventario, etc. Todas estas tareas se realizan utilizando Microsoft office Excel, es en
ese sentido que un sistema de información agilizaría y optimizaría el manejo de esta
información.

2
1.2 PROYECTOS SIMILARES
SISTEMA DE SEGUIMIENTO ACADÉMICO INSTITUTO NORMAL SUPERIOR
SIMON BOLIVAR

De las postulantes: Elizabeth Pérez y Laura Wendy cuyo objetivo era analizar,
diseñar e implementar un sistema de información para el seguimiento en el área
académica para resolver los problemas que se desarrollan internamente con el
módulo de registro de alumnos control de notas, reportes, emisión de certificados
de notas [PEREZ Y LAURA, 2001].

SISTEMA DE GESTION ACADEMICA PARA EL INSTITUTO MECAPACA

Del postulante Roly Carlos Mamani, este sistema se encarga de gestionar procesos
académicos, registró de estudiantes, inscripción e impresión de boletas, módulo de
registro y control, emisión de reportes y consulta empleando la metodología
SCRUM [Mamani Roly 2013].

SISTEMA DE INFORMACION DE SEGUIMIENTO ACADEMICO Y


ADMINISTRATIVO COLEGIO NACIONAL MIXTO ANTOFAGASTA

De la postulante Rosemary Cristina Barrios, este sistema se encarga del registro


de estudiantes emisión de notas control de inventario y seguimiento a los docentes
y estudiantes utilizando el análisis estructurado para el diseño y la metodología
estructurada para el desarrollo[Barrios Rosemary 2006].

1.3 PLANTEAMIENTO DEL PROBLEMA


1.3.1 Problema Central
En el transcurso de la gestión académica la unidad educativa realiza diferentes
tareas y actividades lo cual involucra la manipulación de una gran cantidad de
información. A medida que se desarrolla las actividades curriculares esto se
convierte en un trabajo arduo ya que no se cuenta con un sistema computarizado
que automática estos trabajos por lo que todo el trabajo es realizado de forma
manual y sin el uso de una metodología que ayude a llevar el trabajo en un orden
adecuado.

3
1.3.2 Problema Secundario
A continuación expongo los principales procesos que son realizados de una manera
manual:

1. Registro de alumnos
2. Seguimiento académico a los alumnos
3. Registro de notas(calificaciones)
4. Registro del plantel docente
5. Control del inventario de la unidad educativa
6. Plan curricular anual

En cada uno de estos problemas se pueden ver falencias que son los siguientes:

 Acumulación de información en redundancia, documentos que son


necesarios para el proceso de inscripciones y notas de los estudiantes.
 Presentación a destiempo de los estudiantes inscritos ya que muchas veces
el proceso de inscripción se lleva con lentitud.
 Morosidad en la búsqueda de datos informativos de un estudiante.
 Inexistencia de un historial académico de los estudiantes
 Transcripción de calificaciones a boletines bimestrales y libretas finales de
forma manual.
 Demora en la entrega de calificaciones.
 Falta de centralización de la información (información dispersa).
 Excesiva demora al momento de realizar cálculos para generar respuestas.
 Perdida de información por papeleo.
 Demora al momento de brindar una respuesta sobre el estado de los
estudiantes hacia los padres de familia.
 Asignación de paralelos y aulas a los docentes de una manera manual
 No se cuenta con un control adecuado del inventario del colegio
 Demora al momento de mostrar actividades a realizarse en el colegio

Entonces con la lista de problemas señaladas anteriormente nos vemos en la


necesidad de plantearnos la siguiente interrogante:

4
1.4 PREGUNTA
¿El Sistema de Información vía web para la Unidad Educativa República de Cuba
“SIW” podrá automatizar los procesos manuales citados anteriormente, para que
se pueda optimizar el tiempo, reducir los recursos que se emplean incrementando
de esta manera la confiabilidad de los procesos a realizarse?

1.5 OBJETIVOS
1.5.1 Objetivo General
Diseñar, desarrollar e implementar un Sistema de Información Vía Web solvente,
seguro y de fácil manejo para la Unidad Educativa República de Cuba que consiga
automatizar los procesos manuales identificados.

1.5.2 Objetivos Específicos


 Diseñar e implementar un módulo que se encargue del registro adecuado
del estudiante (inscripción).
 Establecer un módulo de calificaciones que se encargue de:
1. Registro de calificaciones
2. Generación de boletines de calificaciones
 Diseñar e implementar un módulo que se encargue de administrar al plantel
docente de la Unidad Educativa automatizando los siguientes procesos:
1. Registro del plantel docente administrativo
2. Asignación de aulas y paralelos
 Diseñar e implementar un módulo que manipule de una forma sistematizada
el inventario de la unidad educativa como ser inmobiliario, máquinas de
computación, pizarrones y otros. Tomando en cuenta el proceso de
generación de reportes
 Reducir el tiempo y demás recursos que son empleados a la hora de realizar
los procesos manuales, obteniendo así resultados confiables y en tiempo
real.
 Mejorar los procesos a través de un adecuado almacenamiento de la
información (digital), evitando de esta manera la duplicidad o error en los
datos y registros (BASE DE DATOS) esto generado por los procesos
manuales.

5
1.6 JUSTIFICACION
La justificación de un proyecto con estas características determinan la importancia
del mismo para con la sociedad y la institución tomando en cuenta este aspecto
consideraremos las siguientes:

1.6.1 Justificación Tecnológica


Estamos en tiempos donde la tecnología abarca prácticamente a una gran parte de
la población es por eso que es prácticamente imposible prescindir de esta área.

Por lo tanto aunque la Unidad Educativa República De Cuba no cuente con altos
recursos tecnológicas, con las maquinas que cuenta es suficiente para soportar el
sistema de información académico propuesto en el presente proyecto.

De esta manera es justificable la implementación de un software especializado que


pueda subsanar todos los problemas que existen en la institución educativa.

1.6.2 Justificación Social


Como sabemos actualmente existe una creciente demanda por servicios de
educación por lo que es justificable la necesidad de ofrecer y generar un mejor
servicio, entonces no tenemos mejor forma que la utilización de tecnología
informática que en estos tiempos está al alcance de todos mejorando así el
tratamiento de la información.

De la misma forma la Unidad Educativa República De Cuba precisa de esta


tecnología para satisfacer todas sus necesidades en cuanto a requerimientos y
obtención de información incrementando de esta manera su prestigio, calidad
educativa y su tiempo de ejecución de actividades brindando al estudiante una
mejor comodidad, poniendo así más énfasis al aprovechamiento del estudiante que
al papeleo actual que se realiza.

1.6.3 Justificación Económica


Existe una justificación económica ya que el sistema de información y de
seguimiento académico ayudara de gran manera al ahorro de tiempo en cuanto a
la inserción y emisión de datos lo cual será de mucha utilidad para la institución,

6
minimizando el papeleo que causa gastos insulsos de dinero maximizando así el
rendimiento del sistema.

1.7 ALCANCES Y LIMITES


1.7.1 Alcances
E n el desarrollo del presente proyecto se considera los siguientes módulos o
subsistemas

 Módulo de estudiantes el cual ofrece información acerca del registro de cada


uno de los estudiantes recabando toda la información necesaria para
procesos administrativos; generación de reportes por curso (datos
informativos, asignación a aulas).
 Módulo de docentes, donde se registra toda la información concerniente al
plantel docente que trabaja en la Unidad Educativa República De Cuba con
la respectiva asignación de paralelos, generando reportes en el momento
necesario
 Módulo de manejo de inventarios que se encarga de la manipulación de las
siguientes categorías de inventario; inmobiliario donde se registra la
información concerniente a mesas, sillas, pizarras ,estado de los cursos
entre otros , laboratorio de computación donde se registra información
concerniente a los equipos de computación
 Módulo de calificaciones donde registramos las notas del estudiante creando
los boletines mediante una búsqueda personalizada

1.7.2 Limites
El límite del proyecto es el acceso al internet ya que muchos padres de familia
no cuentan con el suficiente conocimiento para adecuarse a este nuevo método
de obtención de información ya que pocos son los sitios de acceso rápido a este
método el cual este proyecto efectúa.

1.8 APORTES
En este caso el sistema de información es considerado como el principal aporte ya
que el presente proyecto tendrá como pilar fundamental un aporte social puesto

7
que proporcionara una colaboración en cuanto a mejorar el desempeño del área
académico en la Unidad Educativa República De Cuba como una herramienta
informática que brinde ayuda a los procesos administrativos incrementando así el
prestigio con que actualmente cuenta la institución educativa.

1.9 METODOLOGIA Y TÉCNICAS A EMPLEAR


Para un adecuado y correcto desarrollo del proyecto, este estará basado en los
siguientes métodos que serán detallados a continuación:

1.9.1 Metodología
La unidad educativa requiere que los procesos citados anteriormente sean
realizados de una manera más rápida por lo que emplearemos herramientas que
ayuden al buen manejo del sistema siguiendo un proceso de análisis y diseño
adecuado a las necesidades.

En este proyecto utilizare una metodología ágil para mi casi la programación


extrema (XP,Extreme Programing) aplicando el modelado del lenguaje unificado
UML para establecer los procesos relacionados con la ingeniería de software para
de esta manera tener en claro lo que el sistema realiza.

Tomando esta metodología de trabajo el cual se basa principalmente en la


retroalimentación basándose en la simplicidad del software definiré las fases que
se aplicaran par los módulos descritos en anterioridad

Fase 1. Planificación

-historias de usuario (alumnos, docentes, administrativos).

-definir las iteraciones que para nuestro caso son los módulos descritos
anteriormente

Fase 2.Diseño

 WebML

-modelo de hipertexto

-modelo de presentación

8
Fase 3. Codificación

-programación en PHP

-Gestor de base de datos MY SQL

-servidor Apache

Fase 4.Pruebas

-Unitarias

-Aceptación

1.9.2 Técnicas
Revisión Bibliográfica, esta es una de las técnicas más utilizadas a la hora de
realizar el desarrollo del proyecto de grado empezando con la estructuración delo
perfil hasta la conclusión del mismo.

Lectura, esto trabaja conjuntamente con la técnica de revisión bibliográfica. Esta


técnica debe estar presente durante el transcurso de desarrollo del proyecto hasta
su culminación.

Observación, esto se aplica acorde al comportamiento de las variables que se ven


dentro de la institución, donde se pueden explayar detalles importantes que afectan
al sistema actual, esta técnica por lo general es realizada en la etapa de análisis
del sistema.

Entrevistas, desarrolladas también durante la fase de análisis, realizando


entrevistas al personal adecuado para recolectar la información sobre las
experiencias personales que cada miembro cuenta obteniendo así parámetros
experimentales.

9
2.1 SITUACION ACTUAL DEL SISTEMA

En la Unidad Educativa República de Cuba actualmente se realizan todos los


procesos de manera manual al referirme de manera manual hago inca pie al
registro de notas en hojas de cálculo de Excel lo cual conlleva una gran
responsabilidad al momento de datos erróneos en los datos que son facultados por
secretaria lo cual conlleva una gran pérdida de tiempo y distintos problemas con los
padres de familia de la Unidad Educativa República de Cuba muchas veces se
requiere información rápida de cada una de las materias para así tomar las
decisiones correspondientes. Esta información está totalmente desordenada
muchas veces por las peticiones que día a día se dan en la institución sin embargo
el acceso a esta información es realmente difícil ya que por estas situaciones
muchas veces no se cuenta con dicha información ya que la perdida de información
se vio muchas veces en el transcurso del avance curricular de los docentes.

Es por eso que se tiene la necesidad de ordenar esta información de manera


ordenada para ayudar a todos los requerimientos a nivel institucional y general, un
Sistema Automatizado cambiaria de gran manera a la situación actual tanto con los
docentes y el correcto manejo de la información para las diversas exigencias de los
distintos entes tanto educativos como disciplinarios, así es que es preponderante
la construcción de una solución factible y cómoda.

Con todo lo expuesto comienzo a desarrollar en el presente proyecto los puntos


señalados en los objetivos propuestos para esta situación.

2.2 INGENIERIA DE SOFTWARE

10
La aplicación de la Ingeniería de Software y la utilización de los conceptos
relacionados con el presente proyecto, se fundamenta en el establecimiento de las
teorías de use, prácticas y principios de ingeniería que proponen soluciones
adecuados a problemas de administración y gestión, para obtener un software que
sea confiable superando pruebas de control de calidad y ofreciendo seguridad.
Entendiendo ingeniería de software como una forma de aplicar lo aprendido
para resolver problemas prácticos de la Sociedad, construyendo un sistema de
calidad y que responda las necesidades del cliente, con una documentación sólida
y que ofrezca soluciones acertadas. Al fundamento de la ingeniería de software es
la capa de proceso. El proceso se puede caracterizar con un marco de trabajo,
donde se definen un pequeño número de actividades independientes en tamaño y
complejidad y que a su vez están conformados de tareas, hitos de proyectos,
productos de trabajo y puntos de garantía de calidad. [PRESSMAN, R. 1999].

2.3 METODOLOGIAS DE DESARROLLO AGIL

Lo que motivo desarrollar la Metodología Ágil, fue los continuos errores que
conllevaban las metodologías tradicionales, como ser: Alto número de proyectos
que se retrasan o fracasan y la baja calidad del software, o bien el proyecto
concluía no se implementaba, per que los requisitos cambiaban en el camino, y las
metodologías tradicionales no aceptan el cambio, o la retroalimentación.

Es por eso que en febrero de 2001, tras una reunión celebrada en Utah—EEUU,
nace en término ágil aplicado at desarrollo de software. El objetivo fue esbozar los
valores y principios que deberían permitir a los equipos a desarrollar software
rápidamente y respondiendo a los cambios que puedan surgir a lo largo del
proyecto.

La filosofía ágil" se encuentra plasmada en el “manifiesto ágil”, que valora:

Al individuo y las iteraciones del equipo de desarrollo sobre el proceso y


las herramientas.

11
Desarrollar software que funciona más que conseguir una buena documentación;
La colaboración con los clientes más que la negociación de un contrato
Responder a los cambios más que seguir estrechamente un plan.

Tabla 2. 1 Diferencia Entre Metodologías Agiles y Tradicionales

Metodologias Agiles Metodologias Tradicionales


Basados en heurísticos provenientes Basados en normas provenientes de
de prácticas de producción de código estándares seguidos por el entorno de
Especialmente preparados para cierta resistencia a los cambios
desarrollo
cambios
Impuestas internamente por el equipo Impuestas externamente
durante el
Proceso proyecto
menos controlado, con pocos Proceso mucho más controlado, con
principios numerosas políticas y normas
No existe contrato tradicional o al menos Existe un contrato prefijado
es bastante flexible
El cliente es parte del equipo de El cliente interactúa con el equipo de
desarrollo desarrollo mediante reuniones.
Grupos pequeños menor a 10 integrantes Grupos grandes y distribuidos

Pocos artefactos Mas artefactos


Pocos roles Mas roles
Menos énfasis en la arquitectura del La arquitectura del software es esencial y se
software expresa mediante modelos

[Fuente. LETELIER, P., PENADES, M. (n. d.).]

En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser


más efectivo, y según esto ajusta su comportamiento. [LETELIER, P., PENADES, M
(n.d.).]

2.4 PROGRAMACION EXTREMA

XP es una metodología ágil centrada en potenciar las relaciones interpersonales


como clave para el éxito en desarrollo de software, promoviendo el trabajo en
equipo, preocupándose per el aprendizaje de los desarrolladores, y propiciando un

12
buen clima de trabajo. XP se basa en realimentación continua entre el cliente y el
equipo de desarrollo, comunicación fluido entre todos los participantes, simplicidad en las
soluciones implementadas y coraje para enfrentar los cambios. XP utiliza un
enfoque OO, como su paradigma de desarrollo preferido. La XP abarca reglas y
prácticas que ocurren en el contexto de 4 actividades del marco de trabajo.
[ECHEVERRY, L.DELGADO, L2007].

Figura 2. 1Actividades de XP

FUENTE [ECHEVERRY, L.DELGADO, L2007].

2.4 1 Planeación

La planeación es la etapa inicial de todo proyecto en XP En este punto se comienza


a interactuar con el cliente y el resto del grupo de desarrollo para describir los

13
requerimientos del sistema. En este punto se identifican en número y tamaño de
las iteraciones el igual que se plantean ajustes necesarios a la metodología según
las características del proyecto. . [ECHEVERRY, L.DELGADO, L2007].

2.4. 1.1. Historias De Usuario

Son la técnica utilizada para especificar los requisitos del software. Se trata de
tarjetas de papel en las cuales el cliente describe brevemente las características
que el sistema de be poseer, sean requisitos funcionales o no funcionales. El
tratamiento de las historias de usuario es muy dinámico y flexible al modelo de
HISTORIA DE USUARIO propuesto per Kent Beck es el siguiente:

Tabla 2. 2 Modelo Propuesto Para Una Historia de Usuario

HISTORIA DE USUARIO

NOMBRE HISTORI A DE USUARIO: Enviar articulo

PRIORIDAD EN NEGOGIO: Alto

(ALTA/MEDIA//BA]A)
RIESGO EN DESARROLLO:

(ATA/MEDIA/BA]A)
DESCRIPCION:

Se introducen los datos del articulo (Titulo, fichero adjunto, tópicos) y de los autores
(nombre, e-mail, afiliación). Uno de los autores debe indicarse como autor de contacto. El
sistema confirma la correcta recepción del artículo enviado un e-mail al autor de contacto con
su login y password para que el autor pueda posteriormente acceder al artículo.

[Fuente; KENT BECK-2002]

14
2.4. 1.2. Velocidad Del Proyecto

Es una medida de la capacidad que tiene el equipo de desarrollo para evacuar las
historias de usuario en una determinada iteración. Esta medida se calcula
totalizando el número de Historias de Usuario realizadas en una iteración. Para la
iteración siguiente se podrá implementar el mismo número de historias de usuario
que en la iteración anterior. [Fuente; KENT BECK-2002]

2.4. 1.2.1 I iteraciones

En la metodología XP, la creación del sistema de información se divide en etapas


para facilitar su iteración, estas etapas se encaminan iteraciones, la duración de
cada iteración es de una a tres semanas.

Para cada iteración se define un módulo a conjunto de historias de usuario que se


van a implementar, al final de cada iteración se tiene un la entrega de un producto,
el cual de be superar las pruebas de aceptación que establece el cliente para dar
cumplimiento a los requisitos, las tareas que no se vean cubiertas per el productos
deberán ser tomadas en cuenta para la siguiente iteración. [Fuente; KENT BECK-
2002]

2.4. 1.2.2 Entregas Pequeñas

Al final de cada iteración habrá una entrega de avances del producto, los cuales
deberán ser completamente funcionales, y estas se caracterizan por ser frecuente.
[Fuente; KENT BECK-2002]

2.4. 1.2.3 Reuniones


El planeamiento es esencial para cualquier tipo de metodología, es por ello que XP
requiere de una revisión continua del plan de trabajo a pesar de ser una
metodología que evita la documentación exagerada, es muy estricta en la
organización del trabajo. [Fuente; KENT BECK-2002].

15
2.4.1.2.4 Roles XP

Los roles de acuerdo con la propuesta original de KENT BECK-2002 son:


a) Programador. El programador escribe las pruebas unitarias y produce el
código del Sistema. [Fuente; KENT BECK-2002].

b) Cliente. Escribe las historias de usuario y las pruebas funcionales para validar
su implementación. Además, asigna la prioridad a las historias de usuario y decide
cuales se implementan en cada iteración centrándose en aportar mayor valor al
negocio. [Fuente; KENT BECK-2002].

c) Encargado de pruebas (Ayuda al cliente a escribir las pruebas funcionales).


[Fuente; KENT BECK-2002].

d) Encargado de seguimiento (Tracked. Proporciona realimentacion al equipo. Verifica


el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado,
para mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada
iteración. [Fuente; KENT BECK-2002]

e) Entrenador (Bosch). Es responsable del proceso global. Debe proveer guías al


equipo de forma que se apliquen las practicas XP y se siga el proceso
correctamente. [Fuente; KENT BECK-2002]

f) Consultor. Es un miembro externo del equipo con un conocimiento específico


en algún tema necesario para el proyecto, en el que puedan surgir problemas.
[Fuente; KENT BECK-2002]

g) Gestor (Big boss). Es el vínculo entre clientes y programadores, ayuda a que el


equipo trabajo efectivamente creando las condiciones adecuadas Su labor esencial es
de coordinación. [Fuente; KENT BECK-2002].

16
2.3.1.2.5 TRASLADO DE PERSONAL
Al mover el personal se evitan problemas relacionados con la pérdida de
conocimiento y Cuellos de botella. [Fuente; KENT BECK-2002].

2.3.1.2.6 AJUSTAR A XP
Todos los proyectos tienen características específicas por to cual XP puede ser
modificado para ajustarse bien al proyecto en cuestión. Al iniciar el proyecto se
debe aplicar XP tal como es, sin embargo no se debe dudar en modificar aquellos
aspectos en que no funcione. [ECHEVERRY, L.DELGADO, L2007].
2.4.2 Diseño

En XP se diseñan aquellas Historias de Usuario que el cliente ha seleccionado


para la iteración actual por dos motivos' por un lado se considera que no es posible
tener un diseño completo del sistema y sin errores desde el principio. El segundo
motivo es que dada la naturaleza cambiante del proyecto, el hacer un diseño muy
extenso en las fases iniciales del proyecto para luego modificarlo, se considera
un desperdicio de tiempo.
[ECHEVERRY, L.DELGADO, L2007].

2.4.2.1 Tarjetas CRC

La principal funcionalidad que tienen estas tarjetas, es ayudar a dejar el


pensamiento procedimental para incorporarse al enfoque orientado a objetos.

Tabla 2. 3 Tarjeta CRC

NOMBRE DE LA CLASE : una clase es cualquier persona, cosa, evento,


concepto, pantalla o reporte

RE5PONSABILIDADES COLABORADORES
Los cosas que conoce y las Las demás clases con los que trabaja en
realizan, sus atributos y métodos. conjunto para llevar a cabo sus
responsabilidades.

17
FUENTE [ECHEVERRY, L.DELGADO, L2007].

En la práctica conviene tener pequeñas tarjetas de ocasión, de manera que se


pueda llegar a un acuerdo sobre la validez de las abstracciones propuestas. Los
pasos a seguir para llenarlas son: encontrar las clases, encontrar
responsabilidades, definir colaboradores y disponer las tarjetas. [ECHEVERRY,
L.DELGADO, L2007].

2.4.2.2 No Solucionar Antes De Tiempo

En XP solo se analiza lo que se desarrollara en la iteración actual, olvidando por


completo cualquier necesidad que se pueda presentar en el futuro. [ECHEVERRY,
L.DELGADO, L2007].

2.4.3 Codificación

La codificación es un proceso que se realiza en forma paralela con el diseño.


[ECHEVERRY, L.DELGADO, L2007].

2.4.3.1 Cliente Siempre Presente

Uno de los requerimientos de XP es que los clientes este siempre presentes


disponible. No solamente para solucionar las dudas del grupo de desarrollo,
debería ser parte de este. [ECHEVERRY, L.DELGADO, L2007].

2.4.3.2 Codificar Primero La Prueba

18
Cuando se crea la primera prueba, se ahorra mucho tiempo elaborando el
código que la haga pasar, siendo menor el tiempo de hacer ambos procesos que
crear el código solamente. [ECHEVERRY, L.DELGADO, L2007].

2.4.3.3 Integración Secuencial

Uno de los mayores inconvenientes presentados en proyectos de software tiene


que ver con la Integración. XP propone emplear un sistema de turnos, para
saber cuál es la última versión. [ECHEVERRY, L.DELGADO, L2007].

2.4.3.4. Integraciones Frecuentes

Se deben hacer integraciones en pocas horas y siempre que sea posible no debe
transcurrir más de un día entre una iteración y otra.[ECHEVERRY, L.DELGADO,
L2007].

2.4.4 Pruebas

XP enfatiza mucho los aspectos relacionados con las pruebas, clasificándolas en


diferentes tipos y funcionalidades específicas, indicando quien, cuando y como
deben ser implementadas y ejecutadas. [ECHEVERRY, L.DELGADO, L2007].

2.4.4.1 Pruebas Unitarias

Estas pruebas se aplican a todos los métodos no triviales de todas las clases del
proyecto con la condición que no se liberara ninguna clase que no tenga asociada
su correspondiente paquete de pruebas. [ECHEVERRY, L.DELGADO, L2007].

2.4.4.2 Pruebas De Aceptación

19
También llamadas pruebas funcionales son supervisadas per el cliente basándose
en los requerimientos tornados de las historias de usuario. Las pruebas de
aceptación son pruebas de caja negra, que representan un resultado esperado de
d determinada transacción con el sistema. . [ECHEVERRY, L.DELGADO, L2007].

2.5 INGENIERIA WEB

La ingeniería web está relacionada con el establecimiento y utilización de principios


científicos, de ingeniería y de gestión, y con enfoques sistemáticos y disciplinados
del éxito del desarrollo, empleo y mantenimiento de sistemas y aplicaciones basados
en web de alta calidad. Las actividades del marco de trabajo se realizan para todas
las Web Apps, mientras que las tareas se adaptan at tamaño y a la complejidad de la
Web App que se va a desarrollar.

Entre los atributos que podemos mencionar de WebApps, tenemos Intensivas de red
(Reside en una red y da servicio a diferentes necesidades de una comunidad diversa
de clientes. Una WebApp puede residir en Internet, intranet o extranet) , controlada pero
el contenido (Utilizar hipermedia para presentar al usuario el contenido de textos,
gráficos, sonido y video) , evolución continua (Un cuidado y una alimentación continua
permite que un sitio web crezca(en robustez e importancia) y deben adaptarse
a las necesidades de los clientes).

inmediatez(para desarrollar WebApps, los desarrolladores deberán usar


métodos de planificación, análisis, diseño e implementación, que se hayan
adaptado a planificaciones apretadas de tiempo para el desarrollo de WebApps)
seguridad(dado que las WebApps están disponibles en la red, se deberán

proporcionar formas seguras de transmisión de datos, deberán implementarse


fuertes medidas de seguridad) , estética(una parte innegable del atractivo de
una WebApp es su apariencia e interacción) . [PRESSMAN, R, 1999].

20
2.5.1 Marco De Trabajo Para La Ingeniería Web

Figura 2. 2 Modelo de Proceso Para WebApp

[Fuente: PRESSMAN, R, 1999].

2.5.1.1. Formulación

Para comenzar con esta etapa se deben plantear las siguientes preguntas: ¿Cuál
es la motivación principal para la Web App? ¿Por qué es necesaria la Web App?
¿Quién va a utilizar la WebApp?

La respuesta a estas preguntas deben ser de lo más sencillo posible. Es


importante destacar que en esta frase no se ha proporcionado ningún detalle. El
objetivo es delimitar la intención global del sitio Web. Para luego definir las metas'.

Metas informativas.’ indican la intención de proporcionar el contenido y la


información específica para el usuario final.

Metas aplicables.’ indican la habilidad de realizar algunas tareas dentro de la WebApp.

Una vez que han identificado todas las metas aplicables e informativas se desarrolla
el perfil del cliente. El perfil del usuario recoge las características relevantes de

21
los usuarios potenciales incluyendo antecedentes, conocimiento y p referencias.
[PRESSMAN, R, 1999].

2.5.1.2 Análisis

Durante el análisis de la Ingeniería Web se realizan cuatro tipos de análisis diferentes:

a) Análisis del contenido. Se trata de la identificación del aspecto completo de


contenido que se va a proporcionar. En el contenido se incluyen datos de texto,
gráficos, imágenes, video y sonido.

b) Análisis de la interacción Se trata de la descripción detallada de la interacción


del usuario y la WebApp Para proporcionar descripciones detalladas de esta
interacción se pueden desarrollar casos prácticos.

Análisis funcional. Los escenarios de utilización (casos de uso) son parte


del análisis de interacción .Definen las operaciones que se aplicaran en el contenido
de la WebApp e implicaran otras funciones de procesamiento. Aquí se realiza una
descripción detallada de todas las funciones y operaciones.

[PRESSMAN, R, 1999].

2.5.1.3 Diseño

La modularidad eficaz (exhibida con una cohesión alta y con un acoplamiento bajo),
la elaboración paso a paso, y cualquier otra heurística de diseño del software conducirá
a sistemas y aplicaciones basados en Web aires de adaptar, mejorar, probar y utilizar.
Para lo que se toman en cuenta:

Configuraciones de diseño. Las configuraciones de diseño se pueden aplicar


no solo a los elementos funcionales de una aplicación, sino también a los
documentos, gráficos y estética general de un sitio Web.

22
Plantillas. Las plantillas se pueden utilizar para proporcionar un marco de trabajo
esquemático de cualquier configuración de diseño o documento a utilizar dentro de una
WebApp.

Diseño arquitectónico. El diseño arquitectónico para los sistemas y aplicaciones


basados en Web se centra en la definición de la estructura global hipermedia
para la WebApp, y en la aplicación de las configuraciones de diseño y plantillas
constructivas para popularizar la estructura (y aligerar la reutilización).
[PRESSMAN, R, 1999].

Diseño de navegación. Una vez establecida una arquitectura de WebApp, una vez
identificados los componentes (paginas, guiones y cifras funciones de proceso de la
arquitectura, el diseñador deben definir las rutas de navegación que permitan al usuario
acceder al contenido y a los servicios de la WebApp. [PRESSMAN, R, 1999].

Diseño de la Interfaz. La interfaz de usuario de una WebApp es la (primera


impresión) Independientemente del valor del contenido la satisfacción de las
capacidades, los servicios de procesamiento y el beneficio global de la WebApp en sí.
[PRESSMAN, R, 1999].

2.5.1.4 PRUEBAS

El enfoque de las pruebas de las WebApps adopta los principios básicos de todas
las pruebas del software y aplica estrategias y tácticas que ya han sido
recomendadas para los sistemas orientados a enfoque se resume en los pasos
siguientes:

a) El modelo de contenido de las WebApp es revisado para descubrir errores. Esta


actividad de se asemeja en muchos aspectos a la de un corrector de un documento
escrito.

b) El modelo de diseño para la WebApp es revisado para descubrir error de


navegación. Los casos prácticos derivados como parte de la actividad de análisis
permiten que un ingeniero Web ejercite cada escenario de utilización frente al
diseño arquitectónico y de navegación.

23
c) Se aplican pruebas de unidad a los componentes de proceso seleccionados y las
páginas Web. Cuando lo que se tiene en consideración es el tema de las WebApps el
concepto de unidad cambia. Cada una de las páginas Web encapsulara el contenido,
los enlaces de navegación y los elementos de procesamiento (formularios, guiones).

d) Se construye esta arquitectura, se realizan las pruebas de Integración. La


estrategia para la prueba de integración depende de la arquitectura que se haya
elegido para la WebApp.

e) La WebApp ensamblada se prueba para conseguir una funcionalidad global y un


contenido. AI igual que la validación convencional, la validación de los sistemas y
aplicaciones basados en Web se centra en acciones visibles del usuario y en
salidas reconocibles para el usuario que procedan del sistema.

f) La WebApp se comprueba con una población de usuarios finales controlada y


monitorizada. Se selecciona un grupo de usuarios que abarque todos los roles
posibles de usuarios. La WebApp se pone en práctica con estos usuarios y se
evalúan los resultados de su interacción con el sistema para ver los errores de
contenido y de navegación, los intereses en usabilidad, compatibilidad, fiabilidad y
rendimiento de la WebApp. [PRESSMAN, R. 1999].

2.6 UML
El Lenguaje Unificado de Modelado es un lenguaje estándar para modelar
software, puede ser usado para visualizar, especificar, construir y documentar los
artefactos de un sistema. UML es apropiado para modelar diferentes tipos de
sistemas, desde sistemas de información hasta aplicaciones basados en la web.
Es un lenguaje muy expresivo, direccionando todas las vistas necesarias para
desarrollar sistemas. UML es solo un lenguaje y puede ser utilizado como parte
de un método de desarrollo de software guiado por cases, centrado en la
arquitectura, iterativo e incremental.[ BOOCH, G., RUMBAUGH,]. JACOBSON, I.,
1998.]

24
2.6.1 Casos De Uso
Los diagramas de casos de uso son fundamentales para la modelización del
comportamiento de un sistema, un subsistema o una clase. Cada uno muestra un
conjunto de casos de uso y actores y sus relaciones. En su mayor parte, este
consiste en modelar el contexto de un sistema, subsistema o una clase, o
modelado de los requisitos del comportamiento de estos elementos.

Los diagramas de casos de uso son importantes para visualizar, especificar


documentar el comportamiento de un elemento. Ellos hacen que los sistemas,
subsistemas y clases accesible y comprensible para presentar una visi6n exterior
de cómo estos elementos se pueden utilizar en su contexto.

Figura 2. 3 Diagrama de Casos de Uso

[Fuente. BOOCH, G., RUMBAUGH,]. JACOBSON, I., 1998.]

Para modelar el contexto de un sistema,


Identificar a los actores que rodean el sistema y los grupos interactúan con los
sistemas, y las funciones secundarias de administración y mantenimiento.

25
Llenar un diagrama de casos de uso con estos actores y especificar las
vías de comunicación de cada actor para los cases de uso del sistema.
Para modelar los requisitos de un sistema.

Establecer el contexto del sistema mediante la identificación de los actores que lo


rodean. Para cada actor, tenga en cuenta el comportamiento que cada uno espera o
requiere que el sistema.

Por cada caso de uso en diagrama, identificar su flujo de eventos y su flujo excepcional
de eventos.

En función de la profundidad con que usted elija para poner a prueba, generar un
script de prueba para cada flujo, utilizando el flujo de las condiciones previas como el
estado inicial de prueba y sus condiciones posteriores ya que su éxito criterios. [BOOCH,
G., RUMBAUGH, J., JACOB SON, I., 1998.].

2.6.2 Diagrama De Actividades

Un diagrama de actividades es esencialmente un diagrama de flujo, que


muestra el flujo de control de la actividad a la actividad. Puede utilizar los
diagramas de actividad para modelar los aspectos dinámicos de un sistema.

Con un diagrama de actividades, también se puede modelar el flujo de un objeto


mientras se mueve de un estado a otro en diferentes puntos en el flujo de control.
Diagramas de actividad pueden estar solos para visualizar, especificar, construir y
documentar la dinámica de una sociedad de objetos, o pueden ser utilizados para
modelar el flujo de control de una operación.

Swimlanes. Usted lo encontrara útil, especialmente cuando se está modelando


los flujos de trabajo de precedes de negocio, para partición de los estados de
actividad en un diagrama de actividades en grupos, cada grupo que representa

26
a la empresa responsable de las actividades de la organización. [BOOCH, G.,
RUMBAUGH,]. JACOBSON, I., 1998.]

Figura 2. 4 Diagrama de Actividades con swinlene

[Fuente. ‘ BOOCH, G., RUMBAUGH,]. JACOBSON, I., 1998.]

2.7 WEBML

WebML es un lenguaje de modelado grafico utilizado para apoyar las actividades


del diseño de sitios Web.

Sirve para especificar complejos sitios web en el ámbito conceptual, que permite
apoyar las actividades del diseño, a partir de su descripción desde distintos puntos
de vista como son el conceptual, el navegacional y el de presentación, entre otros.
Provee gráficos de diseño, los cuales se desarrollan a través de las diferentes
fases de su ciclo de vida, el cual se observa en la siguiente figura. [MUÑOZ, P. (n.
d.).].

27
Figura 2. 5 Ciclo de Vida WebML

[Fuenle. http//.www.Isi. us.es/docs /doctorado /tesis /tesis.pdf ]

Web ML es un lenguaje conceptual para diseño de alto nivel de sitios web datos
intensivos, no así para sitios web pequeños o estáticos. A continuación
ofrecemos una breve explicación de la estructura del modelado WebML.

Figura 2. 6 Fases del Modelado WebML

[Fuente.” http. ’’www.webml. org]

28
2.7.1 Modelo Estructural

Cuando se trabaja con WebML el proceso de desarrollo comienza con la


descripción conceptual del sistema, en la cual, utilizando herramientas CASE para
modelado, como UML, DIA, Enterprise Architect, se representa la estructura
estática del sistema, mediante la definición de entidades (contenedores de datos)
y las relaciones deben tener una cardinalidad y un rol asociado.

Una característica a destacar de WebML es que no exige ninguna herramienta


específica para hacer este modelo. Por lo que se puede utilizar'

a) Diagramas de Entidad—Relación (E—R) que muestran todas las tablas, los


diferentes campus de cada tabla, y las relaciones entre ellas;
b) Diagramas de clases que pueden representar la misma información que un
diagrama de Entidad Relación (per lo que puede usarse de manera equivalente) ,
e incluso información adicional sobre el modelo de datos. [MUÑOZ, P. (n.d.).]

Figura 2. 7 Modelo Estructural

[Fuente.” http. ’’www.webml. org]

2.7.2 Modelo De Hipertexto

Luego de haber cumplido con en el anterior, se establecen las páginas y las


relaciones entre las entidades del esquema de estructura, con lo que se obtiene un

29
"esqueleto’ del sitio Web. Para luego concentrar las particularidades de cada
página y unidad, estructura, contenidos, objetos, experiencia, y cualquier otro
elemento integrante de las páginas, en el que se describen los diferentes
hipertextos que van a ser publicados en el sitio Web. Cada uno de estos define una
vista del sitio y su descripción se realiza mediante dos modelos el de composición,
que define las páginas que componen la estructura del hipertexto, así como el
contenido de éstas; y el de navegación, que describe cómo se podrá navegar a
través de ellas, especificando los vínculos .) entre páginas y entre unidades de
una misma página.[MUÑOZ, P (n. d.).].

2.7.2.1 Modelo De Composición

El propósito del diagrama de composición es definir los nodos que forman parte
del hipertexto contenido en el sitio Web, es decir, se especifican las páginas y
las unidades que componen el sitio Web.

WebML soporta seis tipos de unidades que pueden ser usadas para componer
hipertexto'.

Unidades de Datos. Muestran información sobre un solo objeto, son definidas para
seleccionar una mezcla de información.

Unidad Multldatos. Muestra información sobre un conjunto de objetos, presentes


múltiples instancias de una entidad o componente. Tiene dos partes: un contenedor que
incluye las instancias que se desean mostrar y la unidad de datos usada para la
presentación de cada instancia.

Unidad Índice. presenta múltiples instancias de una unidad o componente como una
lista, esta unidad tiene dos partes principales: Un contenedor que incluye las
instancias que se desean mostrar y los atributos usados como clave del índice.

d) Unidad Scroller. Provee comandos para desplazarse a través de los objetos en un


contenedor.

30
e) Unidad Filtró. provee campos de entrada para buscar los objetos en en un
contenedor, esta unidad es normalmente usada junto con una unidad in dice o
multidatos, la cual muestra los objetos que coinciden con las condiciones de
búsqueda.

f) Unidad Directa. Expresa un tipo particular de índice, el cual contiene un solo objeto
asociado a otro objeto para una relación uno a uno. [MUÑOZ,(P.N.D) 2011].

Figura 2. 8 Modelo de Composición

[Fuente.” http. ’’www.webml. org]

2.7.2.2 Modelo De Navegación

El propósito del diagrama de navegación es especificar la forma en la cual las unidades de


las páginas son conectadas para formar un hipertexto, para esto WebML provee la noción
de enlaces, de los cuales hay dos tipos.

31
Figura 2. 9 Modelo de Navegación

[Fuente.” http. ’’www.webml. org]

Enlaces contextuales: conectan unidades de una forma coherente a la expresada por el


diagrama de estructura de la aplicación. Un enlace contextual lleva información (de
contexto) de la unidad de origen a la unidad destino, esta información es usada
para determinar el objeto o conjunto de objetos a ser mostrados en la unidad
destine. Enlaces no contextuales: conectan páginas libremente,
independientemente del contexto. [MUÑOZ, P (n.d.).]

2.7.3 Modelo De Presentación


En esta fase se define claramente la apariencia grafica de cada una de las páginas
que conformaran el proyecto. Permite definir la posición de las unidades en la
página. WebML no incluye un modelo específico para establecer la presentación
a nivel conceptual. [MUÑOZ, P. (n.d.).].

32
2.7.4 Modelo De Personalización

La personalización tiene tres facetas

 Control de acceso' login/logo , operaciones para el reconocimiento de usuario.


 Asignación de Site view' basa do en el grupo al que el usuario pertenece.
 Personalización de la página: usuarios y grupos dependiendo del contenido.

En principio un grupo es definido para todos (default) y estos usuarios no


necesitan login. Cada grupo puede contener uno o más usuarios y puede estar
en el grupo estos si tiene que tener login. Cada usuario puede estar en uno a mas
grupos y tiene un grupo por defecto, y cada grupo está asociado a una vista del
sitio.

Figura 2. 10 Modelo de Personalización

[Fuente.” http. ’’www.webml. org]

Se realiza una asignación de roles de usuario y de las reglas de negocio que pueden
garantizar una electiva personalización del sitio Web. [PARAMETERS &
PERSONALIZATION. (n.d.).].

2.8 CALIDAD Y SEGURIDAD DE SOFTWARE


2.8.1 Calidad De Software (NORMA ISO_9126)
La calidad de software puede ser evaluado midiendo atributos internos
(únicamente, medidas estéticas de productos intermedios), o puede ser evaluada
midiendo atributos externos (típicamente, medidas de comportamiento del c6digo
cuando se está ejecutando).

33
La I SO, bajo la norma ISO 912 6, ha establecido un estándar internacional para la
evaluación de la calidad de productos de software el cual fue publicado en 1992
con e1 nombre de “Información /tecnology software product evaluation : Quality
and characteristiques and guidelines for their user”, en el cual se establecen las
características de calidad para productos de software que se describen a través
de una o más de seis características básicas, las cuales son: funcionalidad,
confiabilidad, usabilidad, eficiencia, mantenibllidad y portabilidad; cada una de las
cuales se detalla a través de un conjunto de sub características que permiten
profundizar en la evaluación de la calidad de productos de software.

Tabla 2. 4 Características de ISO-9126 y aspecto que articula cada una

Características Pregunta Central

Funcionalidad ¿Las funciones y propiedades satisfacen las necesidades


explicitas e implícitas; esto es, el que…?

Confiabilidad ¿Puede mantener el nivel de rendimiento, bajo ciertas


condiciones y por cierto por tiempo?

Usabilidad ¿El software es fácil de usar y aprender?

Eficiencia ¿Es rápido y minimalista en cuanto al uso de recursos?

Mantenibllidad ¿Es fácil de modificar y verificar?

Portabilidad ¿Es fácil de transferir de un lugar a otro?

[Fuente.‘ ABUD, M. (n. d.).]

2.8.1.1 Funcionalidad

Según ABUD:

En este grupo se conjunta una serie de atributos que permiten calificar si un


producto de software maneja en forma adecuada el conjunto de funciones que

34
satisfagan las necesidades para las cuales fue diseñado. Para este propósito se
establecen los siguientes atributos:

 Adecuación. Se enfoca a evaluar si el software cuenta con un conjunto


de funciones apropiadas para efectuar las tareas que fueron especificadas
en su definición;
 Exactitud. Este atributo per mite evaluar si el software presenta
resultados o efectos
 acordes a las necesidades para las cuales fue creado.
 Interoperabilidad. Permite evaluar la habilidad del software de
interactuar con otros sistemas previamente especificados.
2.8.1.2 Confiabilidad

Se establece, hasta donde se puede esperar que un programa lleve a cabo su función
con la exactitud requerida. En términos estadísticos como la probabilidad de
operación libre de fallos de un programa de computadora en un entorno determinado
y durante un tiempo específico. Este atributo mide la cantidad de tiempo que el
software está disponible para usarlo según los siguientes sub atributos: madurez,
tolerancia a las fallas, y facilidad de recuperación.

2.8.1.3 Usabilidad

La usabilidad es el esfuerzo necesario para aprender a operar con el Sistema,


preparando los datos de entrada e interpretar los datos de salida (resultados) de
un programa.

2.8.1.4 Eficiencia

Es el grado en el que el software emplea de manera óptima los recursos del sistema,
como lo indica los siguientes sub-atributos: comportamiento en el tiempo y

35
comportamiento de los recursos.

2.8.1.5 Portabilidad

Es el esfuerzo necesario para transferir el programa de un entorno hardware/software


a otro entorno diferente, es decir, la facilidad con que se lleva de un entorno a otro
según los siguientes sub-atributos: adaptabilidad, facilidad de instalarse,
cumplimiento y facilidad para reemplazarse.

2.8.2 Seguridad De La Información

La seguridad informática relaciona a diversas técnicas, aplicaciones y


dispositivos encargados de asegurar la integridad y privacidad de la información
de un sistema informático y sus usuarios. Existen dos tipos de seguridad con
respecto a la naturaleza de la amenaza'

Seguridad lógica: aplicaciones para seguridad, herramientas


informáticas, etc.
Seguridad física' mantenimiento eléctrico, anti incendio, humedad, etc.
Amenazas a la seguridad de un sistema tutor informático o computadora'.
Programas malignos: virus, espías, troyanos, gusanos, phishing, spamming, etc.

Siniestros' robos, incendio, humedad, etc. pueden provocar pérdida de información.

Intrusos' piratas informáticos pueden acceder remotamente (si está conectado a


una red) o físicamente a un sistema para provocar danos.

A Operadores: los propios operadores de un sistema pueden debilitar y ser amenaza


a la seguridad de u n sistema no solo por boicot, también por falta de capacitación o
de interés.

36
2.9 Marco Tecnológico

2.9.1 Gestor De Base De Datos MYSQL

MySQL es un Sistema Gestor de Bases de Datos relacional, fue creado por la empresa
sueca MySQL AB, la cual tiene el copyright del código fuente del servidor SQL, asi
como también de la marca, es un software de código abierto, con licencia GPL de la
GNU, aunque MySQL AB distribuye una versión comercial, en lo único que se diferencia
de la versión libre, es en el soporte técnico que se ofrece, y la posibilidad de integrar
este gestor en un software propietario, ya que de otra manera, se vulneraría la licencia
GPL. [Enríquez et al, 2005]

MySQL tiene las siguientes características:

 El principal objetivo de MySQL es velocidad y robustez


 Soporta gran cantidad de tipos de datos para las columnas.
 Gran portabilidad entre sistemas, puede trabajar en distintas plataformas y
sistemas operativos. Cada base de datos cuenta con 3 archivos: Uno de
estructura, uno de datos y uno de índice y soporta hasta 32 índices por
tabla.
 Aprovecha la potencia de sistemas multiproceso, gracias a su
implementación multihilo, Flexible sistema de contraseñas (passwords) y
gestión de usuarios, con un muy buen nivel de seguridad en los datos.
 El servidor soporta mensajes de error en distintas lenguas.

2.9.2 Servidor Web “APACHE"

Apache es programa de servidor HTTP Web de código abierto. Fue desarrollado en


1995 y actualmente es uno de los servidores web más utilizados en la red.
El servidor Apache se desarrolla dentro del proyecto HTTP Server (HTTP) de la
Apache Software Foundation.

37
2.9.3 Lenguaje De Programación PHP

PHP es un lenguaje interpretado de propósito general ampliamente usado y que está


diseñado especialmente para desarrollo Web y puede ser incrustado dentro de
código HTML.
Generalmente se ejecuta en un servidor Web, tomando el código en PHP como su
entrada y creando páginas Web como salida. Puede ser desplegado en la mayoría de
los servidores Web y en casi todos los sistemas operativos y plataformas sin costo
alguno.

PHP se encuentra instalado en más de 20 millones de sitios Web y en un millón de


servidores, aunque el número de sitios en PHP ha compartido algo de su
preponderante sitio con otros nuevos lenguajes no tan poderosos desde agosto de
2005. Es también el módulo Apache más popular entre las computadoras que utilizan
Apache como servidor Web La versión más reciente de PHP es la 5.3.0 (para
Windows] del 30 de junio de 2009. [PHP, 2009].El gran parecido que posee PHP con
los lenguajes más comunes de programación estructurada, como C y Perf, permiten a
la mayoría de los programadores crear aplicaciones complejas con una curva de
aprendizaje muy corta, también les permite involucrarse con aplicaciones de contenido
dinámico sin tener que aprender todo un nuevo grupo de funciones.

PHP también tiene la capacidad de ser ejecutado en la mayoría de los sistemas


operativos, tales como UNIX, Linux o Mac OS X y Windows, y puede interactuar con
los servidores de Web más populares ya que existe en versión CGI, módulo para
Apache.

2.9.4 Dreamweaver

Macromedia Dreamweaver es un editor de código HTML profesional para el diseño


visual y la administración de sitios y páginas Web. Tan si prefiere controlar
manualmente el código HTML como si prefiere trabajar en un entorno de edición visual,
Dreamweaver le permite ponerse manos a la obra rápidamente y le facilita

38
herramientas útiles para mejorar su experiencia en diseño Web.
Dreamweaver incluye numerosas herramientas y funciones de edición de código:
referencias HTML, CSS y JavaScript, un depurador JavaScript y editores de código (la
vista de Código y el inspector de código) que permiten editar JavaScript, XML y otros
documentos de texto directamente en Dreamweaver. La tecnología Roundtrip HTML
de Macromedia importa documentos HTML sin necesidad de cambiar el formato del
código y, además, es posible configurar Dreamweaver para limpiar y cambiar el
formato HTML cuando lo desee.

Las funciones de edición visual de Dreamweaver también le permiten añadir diseño y


funcionalidad rápidamente sin escribir una sola línea de código. Puede ver todos los
elementos o activos del sitio y arrastrarlos desde un panel fácil de usar directamente
hasta un documento. Agilice su flujo de trabajo de desarrollo mediante la creación y
edición de imágenes en Macromedia Fireworks y su importación directa a
Dreamweaver,
o bien añadiendo objetos Flash que puede crear directamente en
Dreamweaver.[Fuente:http://recursos.fundacionesplai.org/intranet/dinamizadores/
recursos_tecnologicos].

2.9.5 XAMPP

XAMPP, es un servidor de plataforma libre, es un software que integra en una sola


aplicación, un servidor web Apache, intérpretes de lenguaje de scripts PHP, un
servidor de base de datos MySQL, un servidor de FTP FileZilla, el popular
administrador de base de datos escrito en PHP, MySQL, entre otros módulos.
Te permite instalar de forma sencilla Apache en tu propio ordenador, sin importar
tu sistema operativo (Linux, Windows, MAC o Solaris). Y lo mejor de todo es que
su uso es gratuito.

Xampp es una herramienta muy práctica que nos permite instalar el entorno
MySQL, Apache y PHP, suficiente para empezar proyectos web o revisar alguna
aplicación localmente. Además trae otros servicios como servidor de correos y

39
servidor FTP.

Si alguna vez has intentado instalar Apache, sabes que no es una tarea fácil, sin
embargo con XAMPP todo es diferente. Una de las ventajas de usar XAMPP es
que su instalación es de lo más sencilla, basta descargarlo, extraerlo y comenzar
a usarlo. En general es bastante fácil la instalación de apache y PHP sobre Unix,
sobre todo si dispone de un manejador de paquetes.

[Fuente:www.um.es/docencia/barzana/DAWEB/Desarrollo-de-aplicaciones-web-
Xampp.html].

2.9.6 Hojas De Estilo

Las hojas de estilo representan un avance importante para los diseñadores de


páginas web, al darles un mayor rango de posibilidades para mejorar la apariencia
de sus páginas. En los entornos científicos en que la Web fue concebida, la gente
estaba más preocupada por el contenido de sus páginas que por su presentación.
A medida que

La Web era descubierta por un espectro mayor de personas de distintas


procedencias, las limitaciones del HTML se convirtieron en fuente de continua
frustración, y los autores se vieron forzados a superar las limitaciones estilísticas
del HTML. Aunque las intenciones han sido buenas -- mejorar la presentación de
las páginas web, las técnicas para conseguirlo han tenido efectos secundarios
negativos. Entre estas técnicas, que dan buenos resultados para algunas personas,
algunas veces, pero no siempre ni para todas las personas, se incluyen:

 La utilización de extensiones propietarias del HTML.


 Conversión del texto en imágenes.
 Utilización de imágenes para controlar el espacio en blanco.
 La utilización de tablas para la organización de las páginas.
 Escribir programas en lugar de usar HTML.
[Fuente: http://html.conclase.net/w3c/html401-es/present/styles.html].

40
3.1 UTILIZACIÓN Y MANEJO DE XP EN EL PROYECTO
Como ya se había dicho en el presente proyecto se hará uso de la metodología ágil
XP(Programación Extrema) dando así una atribución a los distintos elementos que
son parte de ¡esta metodología realizando un trabajo conjunto con las herramientas
designadas para el proyecto como ser UML y los elementos gráficos de WebML
para que de esta manera se dé un na firme explicación a los procesos diversos
que se darán explicando así de una manera sólida de esta manera ajustarnos a
este método de trabajo para mantener el orden de las distintas encomiendas del
proyecto.

En la siguiente tabla mostraremos la forma de trabajo entre las actividades,


procesos y módulos con las herramientas ya dichas.

Tabla 3. 1 Actividades fusionadas con Herramientas

Actividades a realizarse en el Herramientas a utilizar


proyecto

(Planeación del proyecto XP


formulación y planificación )IWeb

1.Historias de usuario

2.Tiempo del proyecto(velocidad)

3.Despliegue de las iteraciones

4.Entregagasprevias(pequeñas
entregas)

5 Reuniones con dirección y


secretaria

41
6 Adecuación de la metodología XP
al proyecto.

Diseño y Análisis IWeb

1.Analisis de la simplicidad en el Casos de uso(UML)


proyecto
Diagrama de actividades(UML)
2.tarjetas CRC
Modelo estructural (WebMl)
3.buen manejo del tiempo
Diagrama de clases(UML)
4.refactorizacion

Codificación XP

1.Trabajo combinado con el cliente

2.codificacion de la pruebas previas

3.Integracion secuencial y frecuente Modelo de Hipertexto(WebMl)


para la oportuna solución a los
Modelo de Presentación
errores posibles

Pruebas XP e IWeb Diagrama de componentes(UML)

1.Pruebas unitarias

2.Pruebas de aceptación

[Fuente: Elaboración Propia]

42
Cabe recalcar que en el presente proyecto se utilizara un trabajo conjunto al ser
una metodología ágil el diseño y la codificación será llevada de una manera
conjunta para que de esta manera se tenga firmeza en cada uno de los puntos a
tratarse a medida que el presente proyecto avance se ira adecuando a los distintos
eventos comenzando con las historia s de usuario combinados con las distintas
iteraciones XP trabajara conjuntamente a la ingeniería web (IWeb )que será un
punto importante en todo el proceso.

3.2 PROCEDIMIENTO DE ELABORACIÓN DEL PROYECTO

En el anterior capitulo dimos una explicación detallada del trabajo en XP y el ciclo


de vida que tiene esta metodología todo resumido en cuatro actividades
importantes ,fusionado con las herramientas ya previstas como ser UML y WebML
conjunto Los pasos que nos ofrece la ingeniería WEB.

3.3 Planeación
La Unidad Educativa República De Cuba dependiente del ministerio de Educación
en sus niveles primario y secundario perteneciente al gobierno autónomo municipal
de El Alto.

La cual presta una educación integral a todos sus estudiantes pero para el caso
un adecuado orden con la información requiere de un sitio WEB de información
para que de esta manera la administración mejore de gran manera y las quejas y
solicitudes de personas adyacentes decremente, es necesario demostrar con datos
numéricos la necesidad que existe en el manejo de información de una manera
confortable para reducir el excesivo trabajo que se realiza en la institución con el
afán de satisfacer las necesidades colectivas.

3.3.1 Historias de Usuario


La historia de usuario numero trata sobre un asunto muy importante lo cual es
importante para mantener un orden y de esta manera generar informes
rápidamente ya que muchas veces no se cuenta con información básica de los
docentes para la realización de distintos trámites para el profesor de la institución.

43
Tabla 3. 2 Historia de Usuario nª1 Registro Docentes

HISTORIA DE USUARIO

NUMERO:1 Nombre De Historia De caso De


Uso: Registro docentes

Prácticamente el registro docente es una tarea que no está detallada en


la institución ya que el nuevo docente solo llega con una carta de
recomendación por parte del ministerio de educación y la dirección distrital
de El Alto.

Esto incluye el número de horas que el docente tiene en la institución


como ser la carga horaria, el registro a cada docente es inexistente
simplemente cada uno de los docentes entrega un curriculum y en otros
casos simplemente presentan un informe o hoja de vida y esto queda
archivado en un almacén de la institución, entonces no se tiene una
adecuada información de los docentes lo cual dificulta la planificación. Al
final se realiza una entrevista al docente para conocer su personalidad

[Fuente: Elaboración Propia]

Tareas

Para dar el tratamiento adecuado a la historia de usuario n#1 determinamos las


siguientes tareas adecuadas a esta necesidad esto va acompañado del módulo de
registro docente con un reporte general de los datos concernientes al plantel
docente

Tabla 3. 3 tarea 1.1 Diseñar el módulo de Registro

Tarea 1.1 DISEÑAR EL MODULO DE REGISTRO DE DOCENTES

Se toma datos concernientes al docente en el formulario de registro con los


datos personales del docente para lo cual se deberá considerar dos aspectos

44
importantes si el docente es perteneciente a una materia técnica o a una
materia general (un solo curso a cargo).

[Fuente: Elaboración Propia]

Muchas veces se tropieza con el problema de la asignación de las aulas y no se


tiene información del aula que le corresponde a cada docente para los respectivos
reclamos o solicitudes que se dan en la institución.

Tabla 3. 4 Tarea 1.2 Asignación de Aulas

Tarea 1.2 asignación de aulas a docentes

Los docentes en cuanto a la asignación de aulas tendrán un distinto trato ya


que por una parte los docentes de primaria están encargados netamente de
un solo curso, los docentes de secundaria simplemente tienen a cargo varios
cursos por lo cual las materia técnicas tienen a cargo varios cursos según el
número de docentes por materia inclusive existen docentes que son únicos
en la materia lo cual hace que el diseño se torne mucho más interesante

[Fuente: Elaboración Propia]

Tabla 3. 5 Historia de usuario nº2 Generación de informe docente

HISTORIA DE USUARIO

NUMERO:2 Nombre De Historia De caso De


Uso: generación de informe
secretaria

45
Una vez obtenido el registro de los docentes se debe proceder a tener
información actualizada de los docentes para lo cual se procede a la
generación de reportes en el momento que se requiera esta información
para planificar las actividades según el aspecto que cada docente tenga
en apoyo a la comunidad con sus características

[Fuente: Elaboración Propia]

TAREAS

En este caso también se necesitara actualizar los datos de los docentes después
de que el docente requiera que sus datos sean cambiados por distintos aspectos.

Tabla 3. 6 tarea 2.1 modificación de datos

Tarea 2.1 modificar datos docente

Para esto seleccionamos con un selector radio el id del docente que se desea
cambiar sus datos personales modificar los datos para que posteriormente se
realice la correspondiente actualización en la base de datos.

[Fuente: Elaboración Propia]

Luego se requiere obtener la información de forma impresa para lo cual realizamos


el reporte correspondiente.

Tabla 3. 7 tarea 2.2 Generación de informe

Tarea 2.2 generar reporte docente

Mediante una opción generamos el reporte de los docentes de los cuales se


requiera la información para tener esa información de una manera impresa(por
docente), de la misma manera un reporte con los datos de todos los docentes
de la institución (general)

[Fuente: Elaboración Propia]

46
Tabla 3. 8 Historia de Usuario nª3 Registro de Estudiante

HISTORIA DE USUARIO

NUMERO:3 Nombre De Historia De caso De


Uso: registro de Estudiantes de
secundaria y primaria

No se cuenta con información almacenada de los estudiantes por lo que


se hace imperiosa la necesidad de tener a los estudiantes en la base de
datos para que asi no se tenga el terrible problema de datos erróneos y
falta de datos personales respecto al alumno el manejo de documentación
se torna dificultoso al momento de tener información del estudiantado ya
que la información se encuentra simplemente almacenada en folders que
muchas veces corren el riesgo de extravió por las basta cantidad de
cursos y alumnos.

[Fuente: Elaboración Propia]

TAREAS

Para dar el tratamiento adecuado a esta historia de usuario determinamos las


siguientes tareas que son imprescindibles para el adecuado manejo de esta
información vital

Tabla 3. 9 Tarjeta de tarea 3.1 Verificación de Estudiante

Tarea 3.1 verificación de datos estudiante

Antes de todo se debe de dar un reconocimiento al nivel que el alumno será


asignado, ya que un alumno de primaria en su mayoría pasa clases con un
solo docente incorporando algunas materia técnicas pero el alumno
perteneciente al nivel secundario tiene un docente por materia y una mayor
cantidad de materias

[Fuente: Elaboración Propia]

47
Una vez hecha la verificación del nivel del estudiante en el caso de ser de primaria
procedemos a registrarlo.

Tabla 3. 10 Tarea 3.2Registro del Estudiante

Tarea3.2 Registro de Estudiantes

Los alumnos de primaria en su mayoría contaran con un solo docente y


algunas materias técnicas entonces ingresamos sus datos en el formulario en
la tabla correspondiente a los alumnos de primaria para mantener un orden

[Fuente: Elaboración Propia]

Muchas veces se tropieza con el problema de la asignación de las aulas por ser
varios alumnos entonces debemos asignar a cada estudiante el aula
correspondiente.

Tabla 3. 11 Tarea 3.3 Asignación de aulas a Estudiantes

Tarea 3.3 Asignación de aulas a alumnos

Una vez registrado el estudiante lo más importante es el aula al cual este


será provisto, entonces debemos tomar en cuenta la protestad de dirección
y secretaria para asignar al alumno al aula registrando esto en una variable
de asignación de manera sencilla en la base de datos.

[Fuente: Elaboración Propia]

Tabla 3. 12 Historia de Usuario nª4 Generación de informe Estudiante

HISTORIA DE USUARIO

NUMERO:4 Nombre De Historia De caso De Uso:


Generación de Informe estudiante

48
Es imperiosa la necesidad de generar informes rápidos sobre la
información concerniente a los estudiantes dirección muchas veces pasa
un gran trabajo recabando esta información que se encuentra como ya
había señalado, guardada en folders por lo cual muchas veces se tiene
un gran trabajo moroso en secretaria para brindar esta información a
distintas instancias

[Fuente: Elaboración Propia]

TAREAS

Para dar el tratamiento adecuado a esta historia de usuario determinamos las


siguientes tareas importantes para explicar esta acción.

Se debe tener el cuidado respectivo con los datos que deben ser solventados con
los datos provistos en la documentación o por respuesta directa de algunos de los
entes directos.

Tabla 3. 13 Tarea 4.1 Modificar Datos Estudiante

Tarea 4.1 modificar datos estudiante

Hasta esta instancia el estudiante cuenta con el registro correspondiente pero


al momento de solicitar esta información a secretaria nos topamos con el
problema de datos erróneos entonces se procede a la verificación,
modificación de datos antes de la impresión del informe

[Fuente: Elaboración Propia]

Luego se deben tomar consideraciones al momento de entregar el informe por lo


cual:

49
Tabla 3. 14 Tarea 4.2 Generar informe Estudiante

Tarea 4.2 generar informe Estudiante

Mediante una opción en el formulario generamos el reporte correspondiente


tomando en cuenta las anteriores consideraciones se imprime la Pagina Web
correspondiente recalcando el nivel.

[Fuente: Elaboración Propia]

Tabla 3. 15 Historia de Usuario nª5 Inventario

HISTORIA DE USUARIO

NUMERO:5 Nombre De Historia De caso De


Uso: Inventario

Muchas veces existen demandas de distintos tipos por parte de los padres
de familia para la unidad educativa que en su mayoría consta de
inmobiliario y equipos de computación pero existe una dificultad al
momento de obtener esta información de una manera rápida ya que se
debe realizar un informe el cual es tardío, la razón es que la junta de
padres de familia debe de pasar curso a curso para realizar el respectivo
conteo de sillas, mesas, equipos de computación, etc.

[Fuente: Elaboración Propia]

TAREAS

Entonces en esta historia de usuario se mostrara el proceso de registro de lo ya


mencionado para que de esta manera sea fácil obtener esta información.

50
Tabla 3. 16 Tarea 5.1 Registro del Inventario

Tarea 5.1 Registro de Inventario

Se verifica y consulta la distinta información acumulada en los documentos


para que posteriormente se realice el respectivo registro de todos los
inmobiliarios bancos sillas y equipo de computación.

[Fuente: Elaboración Propia]

Luego se deben tomar consideraciones al momento de entregar el informe por lo


cual:

Tabla 3. 17 Tarea 5.2 Verificación de datos Inventario

Tarea 5.2 Verificación de datos Inventario

Puede existir errores en los datos es por eso que antes de generar el informe
respectivo se realiza la verificación de los datos existentes en el informe
general del inventario consultando al personal administrativo para la respectiva
actualización de los datos.

[Fuente: Elaboración Propia]

Ahora si procedemos a generar el respectivo informe del inventario

Tabla 3. 18 Tarea 5.3 Generación de Informe Inventario

Tarea 5.3 Generación de reporte

Una vez completada la verificación de datos simplemente generamos el


informe con una simple opción que se encuentra en el módulo de registro de
inventario para la respectiva aprobación de dirección para las demandas
correspondientes.

[Fuente: Elaboración Propia]

51
Tabla 3. 19 Historia de Usuario nª6 Calificaciones

HISTORIA DE USUARIO

NUMERO:6 Nombre De Historia De caso De


Uso: Calificaciones

El principal problema de la dirección es la realización de las notas por lo


cual muchas veces ha conllevado muchos problemas entre dirección y
secretaria al momento de ver las notas o escrudiñar las notas de los
estudiantes por lo cual el papeleo de notas es inminente y sumamente
peligroso por la basta cantidad de registros de Excel por lo cual es el
tiempo el cual se ve entremezclada en esta cuestión al momento de
generar rápidamente las notas entonces la generación de boletines debe
ser rápida.

[Fuente: Elaboración Propia]

Esta historia de usuario estará basada en XP lo cual conlleva la simplicidad


primeramente se debe de realizar el registro correspondiente en el formulario.

TAREAS

Tabla 3. 20 Tarea 6.1 Registro de Calificaciones

Tarea 6.1 Registro de Calificaciones

Antes de la generación de boletines se debe de registrar las notas por lo cual


nos damos a la tarea de ingresar en la entidad calificaciones el código del
estudiante la materia y la correspondiente nota total bimestral

[Fuente: Elaboración Propia]

Luego se debe de generar el boletín respectivo de la nota del estudiante en


cuestión.

52
Tabla 3. 21 Tarea 6.2 Generación de Boletín de Calificaciones

Tarea 6.2 Generación de boletín de calificación

Simplemente damos un llamado a la entidad de calificaciones para que nos


muestre la nota del estudiante en la materia(s) en cuestión. Secretaría es la
encargada de emitir estos boletines

[Fuente: Elaboración Propia]

3.3.2 Actores
Basándonos en el manual de procedimientos en las historias de usuario ya
presentadas, en las distintas tareas y diagramas de actividades presentados
procedemos a determinar a los actores del sistema.

Tabla 3. 22 Actores del Proyecto

ACTOR ROL

Director Es la persona encargada de


supervisar todo lo concerniente a las
actividades a realizarse en la Unidad
Educativa República De Cuba, dando
el seguimiento respectivo a docentes
y estudiantes tomando así las
decisiones respectivas en bien de
toda la comunidad estudiantil.

Secretaria Persona encargada del registro de


docentes estudiantes así mismo de la
generación de informes en un
determinado momento.

Docente Los docentes son los encargados de


impartir conocimiento a los
estudiantes para una formación

53
integral según actividades
curriculares planificadas.

Estudiante Es el pilar fundamental en el sistema


ya que todo el procedimiento se lleva
a cabo dentro de esta entidad el cual
realiza actividades curriculares
planificadas por el docente.

administrativos Prácticamente esta entidad


simplemente está conformada por
tres personas la portera, regenta de
primaria y regente de secundaria
cumpliendo funciones auxiliares en la
institución.

Padres de familia Los padres de familia son los


encargados de los estudiantes los
cuales muchas veces requieren
información sobre los estudiantes.

[Fuente: Elaboración Propia]

3.3.3 Iteraciones y Velocidad Del Proyecto


El anterior punto nos da la partida para describir las iteraciones en 6 historias de
usuario:

 H.U. #1 Registro docente.


 H.U. #2 generación de informe docente secretaria.
 H.U. #3 Registro de estudiantes de primaria y secundaria.
 H.U. #4 generación de informe estudiante.
 H.U. #5 Modulo de inventarios.
 H.U. #6 Modulo de calificaciones.

54
Ahora debemos basarnos en las historias de usuario ya señaladas por lo que se
debe de realizar una planificación de seis incrementos que se encargaran de
estimar el tiempo agrupando las funcionalidades para que de esta manera se dé un
escape a cada una de las historias de usuario

.Una vez determinado los seis incrementos procedemos a procesar cada historia
de usuario en cada iteración.

En la siguiente figura se muestra la descripción de cada uno de los incrementos


siguiendo un orden en específico en lo que cada iteración será entregada tomando
en cuenta que el desarrollo comenzó en el mes de agosto obtenemos un estimado
de la duración de cada iteración para nuestro caso 1 a 2 semanas por iteración.

Figura 3. 1 Descripción de los Incrementos.

[Fuente: Elaboración Propia]

Figura 3. 2 Cronograma de Actividades

agosto septiembre octubre noviembre diciembre


TAREAS DURACION
primer incremento 75 dias
segundo incremento 68 dias
tercer incremento 79 dias
cuarto incremento 65 dias
quinto incremento 45 dias
sexto incremento 72 dias

[Fuente: Elaboración Propia]

55
3.4 Diseño y Codificación
3.4.1 Primer Incremento
a) Caso de uso

En el siguiente caso de uso mostramos el proceso que sigue el registro del docente
en la base de datos verificando previamente la documentación existente.

Figura 3. 3 Caso de Uso Registro de Información Docente

[Fuente: Elaboración Propia]

Ahora mostraremos el curso que sigue cada uno de los eventos en el caso de
registrar a un docente, este proceso será llevado a cabo por la secretaria que
tomara los datos.

56
Tabla 3. 23 Interacción Actor Sistema en el Registro Docente

ACTOR(SECRETARIA) SISTEMA

1.Pregunta si el docente forma parte


de una materia técnica o general

2.abre el formulario de registro

3.muestra el formulario de registro

4.Rellena los datos

5.Se validan los datos

6..guarda los datos

7.Almacena los datos

[Fuente: Elaboración Propia]

a) Diagrama de actividades del registro de información docente

Se verifican los datos y se procede a abrir el formulario para rellenar los datos
concernientes al docente.

57
Figura 3. 4 D.A. de Registro de Información docente

[Fuente: Elaboración Propia]

b) Diagrama estructural

En este diagrama de clases mostraremos las clases por las cuales está conformado
este evento importante para nuestro caso es importante la clase docente técnico,
La clase docente general y la clase materia para la correspondencia en el caso de
los docentes generales.

Figura 3. 5 Diagrama de Clases Registro de Información Docente

[Fuente: Elaboración Propia]

58
c) Tarjetas CRC

Tabla 3. 24 Tarjeta CRC Registro de Docente

Nombre de la clase :Registro docente

Responsabilidades Colaboradores

Se verifican los datos Secretaria

Se introducen los datos personales. Secretaria

Se introducen datos referentes a la institución como el Secretaria


curso a cargo

Se asigna el aula correspondiente al docente


Secretaria

[Fuente: Elaboración Propia]

d) Modelo de hipertexto registro docente

Para este incremento número uno mostraremos el formulario de registro, para este
caso dos con lo cual podremos observar la secuencia que siguen los datos al
guardarse para impedir de esta manera las distintas opciones en cuanto al registro.

59
Figura 3. 6 Modelo de Hipertexto Registro Docente

[Fuente: Elaboración Propia]

60
e) Modelo de presentación

Para el llenado del formulario correspondiente secretaria se encarga de introducir


los datos en el formulario correspondiente.

Figura 3. 7 Modelo de Presentación Registro Docente

[Fuente: Elaboración Propia]

3.4.2 Segundo Incremento


a) Caso de uso

El caso de uso citado a continuación mostraremos el proceso que se sigue al


momento de generar el informe por parte de secretaria el cual contempla un orden
de procesos.

61
Figura 3. 8 CU proceso de Generación de Informe (Docentes)

[Fuente: Elaboración Propia]

En el siguiente cuadro mostramos el orden de eventos y procesos en el caso de la


generación del informe

Tabla 3. 25 Interacción Actor Sistema Generación de Información Docente

ACTOR(SECRETARIA) SISTEMA

1.Verificacion de los datos

2.Oprime la opción genera informe

3. Modificación de datos

62
4.Muestra el informe detallado en
HTML

5.Imprime el informe

[Fuente: Elaboración Propia]

b) Diagrama de actividades de caso de uso proceso de generación de informe


(docentes).

Figura 3. 9 DA de CU del Proceso de Generación informe Docentes

[Fuente: Elaboración Propia]

63
c) Diagrama estructural
El siguiente diagrama de clases nos muestra las entidades relacionadas con
el evento de generación del informe de docentes el cual cabe recalcar se
dará en tiempo real.

Figura 3. 10 Diagrama de Clases Generación de Informe Docentes

[Fuente: Elaboración Propia]

d) Tarjetas CRC

Para la generación del informe respectivo sabemos que los datos del anterior
incremento solventan el proceso por lo cual la generación de informe está ligada a
la modificación de datos del docente.

64
Tabla 3. 26 Tarjeta CRC Modificación de Datos

Nombre de la clase :Modificación de datos

Responsabilidades Colaboradores

Verificación de datos Secretaria,


administrativos

Modificación de los datos en el formulario


Docentes, secretaria

Muestra siguiente modificación


Secretaria

[Fuente: Elaboración Propia]

Tabla 3. 27 Tarjeta CRC Generación de Informe

Nombre de la clase : Generación del informe

Responsabilidades Colaboradores

Selecciona opción de generación de informe Secretaria

Impresión del informe Secretaria

[Fuente: Elaboración Propia]

65
e) Modelo de hipertexto Generación del informe Docente

Con el diagrama de hipertexto señalaremos la secuencia de procesos existentes


para la generación del informe esquematizados para un buen entendimiento interno
de los procesos donde tenemos el formulario de modificación para que
posteriormente se llame a la tabla de docentes para la importación de datos.

Figura 3. 11 Diagrama de Hipertexto Generación de Informe Docentes

[Fuente: Elaboración Propia]

f) Modelo de presentación generación de informe docente

Una vez se tiene la correcta verificación de los datos ingresamos al formulario de


modificación.

66
Figura 3. 12 Modelo de Presentación Formulario De Modificación

[Fuente: Elaboración Propia]

Posteriormente procedemos a la generación del informe respectivo

Figura 3. 13 Modelo de Presentación Informe Docente

[Fuente: Elaboración Propia]

3.4.3 Tercer Incremento


a) Caso de uso

El caso de uso refleja el curso que sigue la información al momento del registro de
los estudiantes por lo que procedemos al llenado del formulario correspondiente.

67
Figura 3. 14 CU Registro de Información Estudiante

[Fuente: Elaboración Propia]

A continuación en el siguiente cuadro mostramos de una manera más explícita el


proceso que conlleva el registro de la información concerniente al alumno.

Tabla 3. 28 Interacción Actor Sistema Generación de Informe Estudiante

ACTOR(SECRETARIA) SISTEMA

1.verificacion del estudiante(afiliación)

2.abre el formulario de registro

68
3.muestra el formulario de registro

4.Rellena los datos

Se validan los datos

5.guarda los datos

6.Almacena los datos

[Fuente: Elaboración Propia]

b) Diagrama estructural

Este diagrama nos mostrara un panorama mejor explicado de las entidades


comprometidas con este incremento para una mejor explicación y una buena
manera de observar el tratamiento de los datos.

Figura 3. 15 Diagrama de Clases Registro Estudiante

[Fuente: Elaboración Propia]

c) Tarjetas CRC

69
En cuanto al registro se debe tomar una especial consideración con el nivel del
estudiante por lo que se debe tomar en cuenta el nivel.

Tabla 3. 29 Tarjeta CRC Registro de Estudiantes

Nombre de la clase :registro de estudiantes secundaria

Responsabilidades Colaboradores

Se introducen los datos personales. Estudiante

Se introducen datos referentes a la institución Secretaria,docente

Asigna aula Secretaria,


docente

[Fuente: Elaboración Propia]

d) Modelo de hipertexto registro Estudiante

En cuanto a este incremento es necesario observar el esquema del módulo el cual


está compuesto por el formulario respectivo entonces ahora mostraremos la
adecuación de los procesos en el sistema.

70
Figura 3. 16 Modelo de Hipertexto Registro Estudiante

[Fuente: Elaboración Propia]

e) Modelo de presentación

Secretaria se encarga del llenado del formulario correspondiente. A continuación


mostramos el formulario designado al registro de los estudiantes.

Figura 3. 17 Modelo de Presentación Registro Estudiantes

[Fuente: Elaboración Propia]

71
3.4.4 Cuarto Incremento

a) Caso de uso

En el siguiente caso de uso mostraremos el procedimiento que se sigue en el


manejo de la generación de informes.

Figura 3. 18 CU Proceso de Generación Informe Estudiante

[Fuente: Elaboración Propia]

A continuación mostramos el proceso de los eventos que se suscitan en el presente


incremento.

72
Tabla 3. 30 Interacción Actor y Sistema en la Generación de Informe Estudiante

ACTOR(SECRETARIA,DOCENTE) SISTEMA

1.Verificacion de los datos

2.Oprime la opción genera informe

3. Modificación de datos

4.Muestra el informe generado en


HTML con código PHP

5.Imprime el informe

[Fuente: Elaboración Propia]

b) Diagrama estructural

El siguiente diagrama de clases nos muestra las entidades relacionadas con


el evento de generación del informe de docentes el cual cabe recalcar se
dará en tiempo real.

Figura 3. 19 Diagrama de clases Generación de Informe Estudiante

[Fuente: Elaboración Propia]

73
c) Tarjetas CRC

Para la generación del informe respectivo sabemos que los datos del anterior
incremento solventan el proceso por lo cual la generación de informe está ligada a
la modificación de datos del docente.

Tabla 3. 31 Tarjeta CRC Modificación de Datos

Nombre de la clase :Modificación de datos

Responsabilidades Colaboradores

Verificación de datos Secretaria,


administrativos

Docentes,Secretaria,
Modificación de los datos en el formulario
Padre de familia,

Muestra siguiente modificación


docente, secretaria

[Fuente: Elaboración Propia]

Tabla 3. 32 Tarjeta CRC Generación de Informe Estudiante

Nombre de la clase : Generación del informe

Responsabilidades Colaboradores

74
Selecciona opción de generación de informe Secretaria,
docente

Impresión del informe


Secretaria,
docente

[Fuente: Elaboración Propia]

d) Modelo de hipertexto Generación del informe Estudiante

Con esto observaremos el proceso referido al proceso de generación del informe


con el formulario de modificación de los datos correspondientes al estudiante.

Figura 3. 20 Modelo de Hipertexto Generación de Informe Estudiante

[Fuente: Elaboración Propia]

e) Modelo de presentación generación de informe Estudiante

75
A continuación mostramos la interfaz encargada del trabajo de generación de
informes del estudiante.

Figura 3. 21 Modelo de Presentación de Modificación Datos Estudiante

[Fuente: Elaboración Propia]

Figura 3. 22 Modelo de Presentación Informe Estudiante

[Fuente: Elaboración Propia]

76
3.4.5 Quinto Incremento
a) Caso de uso

El registro de la información concerniente al inventario es un punto importante y la


información es ingresada al formulario siguiendo respectivos procesos que serán
detallados a continuación.

Figura 3. 23 CU Modulo de Inventarios

[Fuente: Elaboración Propia]

77
A continuación en el siguiente cuadro mostramos de una manera más explícita el
proceso que se realiza en el registro de datos.

Tabla 3. 33 Interacción Actor y Sistema en el Módulo de Inventarios

ACTOR(SECRETARIA) SISTEMA

1. verificación de la documentación de
inventarios.

2.abre el formulario de registro

3.muestra el formulario de registro

4.Rellena los datos del inmobiliario

5.Ingresa otros datos correspondientes al


laboratorio de computación

6. inserta datos correspondientes a la


instrumentación de música.

7.validacion de datos

8.muestra formulario de
modificación

9.modifica datos

9.Genera informe

[Fuente: Elaboración Propia]

b) Diagrama Actividades del procedimiento con el inventario

78
Este diagrama nos mostrara el proceso que conlleva el procesado de la información
del registro hasta la generación del informe respectivo

Figura 3. 24 DA Modulo de Inventario

[Fuente: Elaboración Propia]

c) Tarjetas CRC

En cuanto al registro se debe tomar una especial consideración con los tres tipos
de inventario como ser:

 Inmobiliario
 Equipo de computación
 Artefactos de música

Tabla 3. 34 Tarjeta CRC Registro de Inventario

Nombre de la clase :registro de inventarios

Responsabilidades Colaboradores

79
Se obtiene información correspondiente a este asunto Secretaria,
docente

Tener cuidado con el manejo de cantidades de inventario


en un determinado tipo Administrativos

Inserción de datos Administrativos


secretaria,
docente

[Fuente: Elaboración Propia]

Tabla 3. 35 Tarjeta CRC Generación de Informe Inventario

Nombre de la clase :Generación de informe inventario

Responsabilidades Colaboradores

Se verifican los datos ingresados Administrativos,


secretaria

Secretaria
Modificación de los datos

secretaria
Impresión de datos

[Fuente: Elaboración Propia]

a) Diagrama estructural módulo de inventarios

80
A continuación mostraremos las clases que actúan en la aplicación del inventario
directamente.

Figura 3. 25 Diagrama de Clases Modulo de Inventarios

[Fuente: Elaboración Propia]

b) Modelo de hipertexto módulo de inventarios

Este incremento se basa en el módulo de inventarios por lo cual mostraremos el


desarrollo por el cual pasa este módulo con el respectivo formulario y la generación
del informe demostrando los procesos que se ven entremezclados en este asunto.

Figura 3. 26 Modelo de Hipertexto Modulo de Inventario

81
[Fuente: Elaboración Propia]

e) Modelo de presentación

Secretaria a voz de dirección se encarga de la generación del informe de


inventarios por el pedido de los padres de familia u otras instancias previo el registro
de todos los elementos correspondientes.

Figura 3. 27 Modelo de Presentación Registro Inventario

[Fuente: Elaboración Propia]

82
Figura 3. 28 Modelo de Presentación Informe Inventario

[Fuente: Elaboración Propia]

3.4.6 Sexto Incremento


a) Caso de uso

Secretaria obtiene todos los datos informativos de los docentes por lo que el
siguiente paso es introducir los datos al sistema para que así se tengan
almacenados todos estos datos sumamente importantes.

Figura 3. 29 CU Modulo de Calificaciones

83
[Fuente: Elaboración Propia]

En el siguiente cuadro mostramos de una manera didáctica el proceso que siguen


secretaria y el sistema para la obtención de calificaciones.

Tabla 3. 36 Interacción Actor Sistema Modulo de Calificaciones

ACTOR(docente) SISTEMA

1. Realiza una rápida verificación de las


notas anticipando errores técnicos.

2.abre el formulario de calificaciones

3.muestra el formulario de
calificaciones

4.Rellena los datos correspondientes a la


nota conferida

5.guarda la información

6.Validacion de datos

7.Registra otra calificación

8.muestra formulario de
modificación

9.modifica datos

10.genera informe

[Fuente: Elaboración Propia]

b) Diagrama Actividades del procedimiento con las calificaciones

84
En este diagrama de actividad solventaremos funciones importantes que quedaron
en duda desde el proceso desde el registro de la nota hasta la generación del
respectivo informe.

Figura 3. 30 DA Modulo de Calificaciones

[Fuente: Elaboración Propia]

c) Modelo estructural

Se puede evidenciar que la clase calificaciones toma en cuenta la relación con las
clases estudiante docente y aula por lo que se debe de tomar en cuenta los distintos
atributos que generan un orden y credibilidad en los datos.

85
Figura 3. 31 Diagrama de Clases Modulo de Calificaciones

[Fuente: Elaboración Propia]

d) Tarjeta CRC

En este módulo interviene primeramente el registro de las calificaciones


elaborándose el formulario donde se introducen estos datos.

Tabla 3. 37 Tarjeta CRC Registro de Calificaciones

Nombre de la clase :registro de calificaciones

Responsabilidades Colaboradores

86
Registro de datos por parte de cada docente docente

Verificación de datos técnicos. docente

Inserción de datos docente

[Fuente: Elaboración Propia]

Tabla3.22 Tarjeta CRC Generación de informe calificaciones

Tabla 3. 38 Informe de Calificaciones

Nombre de la clase :boletín de calificaciones

Responsabilidades Colaboradores

Se verifican las calificaciones ingresadas docentes

Modificación de las calificaciones Secretaria

Impresión de boletines Secretaria, docente

[Fuente: Elaboración Propia]

e) Modelo de hipertexto módulo de calificaciones

El tratamiento de las calificaciones es un asunto delicado por lo que el


manejo de SQL será vital en este modelo de hipertexto mostramos la
conformación del módulo desde el formulario hasta la generación del
informe.

87
Figura 3. 32 Modelo de Hipertexto Modulo de Calificaciones

88
[Fuente: Elaboración Propia]

e) Modelo de Presentación

Primeramente se muestra el formulario de registro de calificaciones donde se


introducen los respectivos datos importantes para el estudiante.

Figura 3. 33 Modelo de Presentación Registro de Calificaciones

[Fuente: Elaboración Propia]

89
Posteriormente se genera el respectivo boletín de calificaciones ingresando
previamente el código del estudiante en el formulario de búsqueda de
calificaciones.

Figura 3. 34 Modelo de Presentación Boletín de Calificaciones

[Fuente: Elaboración Propia]

90
3.5 Pruebas
Una tarea importante para el sistema es la consolidación del banner por lo cual:

Figura 3. 35 Banner

[Fuente: Elaboración Propia]

3.5.1 Modelo de Personalización


El control de acceso es una tarea importante, entonces cada usuario contendrá un
usuario y un password el cual estar a cargo del administrador. A continuación
mostramos la clase administrador que se encarga de la administración de usuarios
y contraseñas.

Figura 3. 36 Diagrama de Clases Administrativo

[Fuente: Elaboración Propia]

91
a) Diagrama De Componentes

El actor (secretaria) al momento de verificar los datos del docente, estudiante,


inventario entre otros realiza el procedimiento de ingreso a los distintos formularios
de registro. A continuación detallamos la ruta de acceso a tales sitios.

Figura 3. 37 Diagrama de Componentes Registro

[Fuente: Elaboración Propia]

92
En cualquier momento director, padres de familia o docentes requieren información
impresa en informes por lo cual la ruta específica se detalla a continuación.

Figura 3. 38 Diagrama de componentes Generación de Informes

[Fuente: Elaboración Propia]

93
4.1 CALIDAD DE SOFTWARE
Para medir la calidad de software empleamos modelos que especifican el conjunto
de características y atributos que debe cumplir todo sistema mediante las tan
conocidas métricas las cuales señalamos a continuación.

4.1.1 Funcionalidad
Cuantificaremos el tamaño y el grado de complejidad que tiene el sistema en
términos del usuario, puede ser valorado mediante el Punto Función determinando
las cinco características del dominio.

Tabla 4. 1 Cálculo de Punto Funcion

Parametro Cuenta Multiplicación Factor de ponderado total

# entradas 7 * 3 4 6 28
de usuario

#salidas de 7 * 4 5 7 35
usuario

#consultas 5 * 3 4 6 20
de usuario

#archivos 0 * 2 10 15 0

#interfaces 15 * 5 7 10 105
eternas

TOTAL 188

[Fuente: Elaboración Propia]

94
Donde el punto función está dado por:

PF (real)=cuenta total *[0.65+0.01*∑F1] (1)

Donde PF es el ajuste de la complejidad respecto a la cuenta total y F1 con (i=1 a


14) son ajustes de complejidad según el factor cuyo valor puede ser de 1 a 5.

Además que 0.65 es el valor mínimo de ajuste respecto a la cuenta total y 0.01 es
el factor de conversión.

Tabla 4. 2 Valores de Ajuste de Complejidad

# VALORES DE AJUSTE VALOR

1 ¿Requiere el sistema de copias de seguridad fiables? 3

2 ¿Requiere de comunicación de datos? 5

3 ¿Es crítico el rendimiento? 2

4 ¿Se ejecutara el sistema en un entorno operativo existente y 5


fuertemente utilizado?

5 Requiere el sistema entrada de datos interactivos (múltiples 6


pantallas).

6 ¿Requiere el sistema entrada de datos interactiva sobre varias 5


ventanas?

7 ¿Actualización de datos de forma interactiva? 3

8 ¿Son complejas las entradas, salidas y consultas? 2

9 ¿Es complejo el procesamiento? 2

10 ¿Código reutilizable? 6

11 ¿El sistema puede soportar múltiples instalaciones? 2

12 ¿Se ha diseñado la aplicación para facilitar? 3

95
13 ¿Se ha diseñado el sistema de información para facilitar cambios 6
y es de fácil uso?

50

[Fuente: Elaboración Propia]

Calculo de Punto Función reemplazando en (1)

PF=188*[0.65+0.01*50]

PF=216.2

El ajuste tomado a un 100% con una taza de error del 1%tenemos la funcionalidad
esperada de:

PF (esperado)=188*[1+0.01*50] (3)

PF (esperado)=282 (4)

FUNCIONALIDAD=[216.2/282]=0.77

Entonces la funcionalidad del sistema es de un 77% con un margen de error del


23%.

4.1.2 Confiablidad
Nos ayuda a medir la cantidad de tiempos que el software está disponible .Para
observar la madurez en los fallos calculando la confidencialidad del sistema
tomando en cuenta un periodo de tiempo obteniéndose muestras.

F(t) = f ∗ er −⋋∗T (5)

El inicio de ejecución del sistema se define en el instante t 0 =0, lo que significa el


tiempo inicial en el cual dará inicio el funcionamiento del sistema:

Para t=0, F=1, se observa el trabajo del sistema hasta que produce una falla en el
instante T, el cual va aproximado a una variable aleatoria continua. Como se

96
aproxima a variables aleatorias continuas. Como se aproxima a variables
aleatorias continuas, la confidencialidad será obtenida en términos probabilísticos.
Por lo que:

(3) probabilidad de fallas

(4) probabilidad de trabajo sin fallas

En un periodo de 12 meses como tiempo de prueba se define de cada 10 ejecuciones


una falla. Conociendo que la funcionalidad del 80% del sistema calculamos para el
periodo establecido.
P (T>=t) =1-F (t)

1
P (T>=t) =1-80(−10∗12)

P (T>=12) =0.76

La confiabilidad o la inexistencia de fallas en el presente sistema es de un 76% en


el periodo de un año y con fallas es de un 24 %

4.1.3 Mantenibllidad
La mantenibllidad se la mide de la siguiente
forma:
IMS= [Mt — (Fa+ Fc+Fd)]/MT

Mt: número de módulos en la versión actual.


Fc: número de módulos en la versión actual que se han
cambiado Fa: número de módulos de la versión actual
que se han añadido
Fd: número de módulos de la versión anterior que se han borrado en la versión
actual Calculando los valores tenemos:
IMS= [5— (1+ 0+0)]/5=0.8

97
A medida que la IMS se aproxima a 1.0 se dice que el producto se encuentra en
un estado estable. Esto quiere decir que el 0.80 es próximo a 1.

4.1.4 Portabilidad

Para la portabilidad se tomara en cuenta dos aspectos, a nivel de aplicación y a


nivel de hardware. A nivel de software. El sistema es portable bajo los siguientes
sistemas operativos de la familia Microsoft Windows 2007, Microsoft ,
Microsoft XP se recomienda usar:
 Microprocessor Pentium de 900 MHz o superior.
 Memoria RAM de 256 Mb.
 Espacio en disco duro de 5 Gb.

4.1.5 Usabilidad

El sistema cuenta con una interfaz amigable e intuitiva lo cual hace que sea
fácil usar y comprender su comportamiento para el fácil manejo

Tabla 4. 3 Evaluación de Usabilidad

RESPUESTAS
PREGUNTA RESULTAD
SI NO
O
¿Puede utilizar con facilidad el sistema? 8 2 80%

¿Puede controlar las operaciones del sistema que 7 3 70%


solicita?
¿Las salidas del sistema son entendibles? 9 90%

¿el entorno grafico del sistema es agradable? 8 80%

¿Las salidas son las esperadas? 8 2 80%

¿Le parece fácil el manejo del sistema? 8 2 80%

98
¿Los reportes ayudan en el trabajo? 80%
8
2
TOTAL 80%

[Fuente. Elaboración Propia]

Como resultado tenemos un 80% de aceptación de la usabilidad del


sistema, con datos proporcionados, por los usuarios del sistema.

4.2 SEGURIDAD DEL SOFTWARE


Para esto tomaremos dos aspectos importantes en cuanto a seguridad se trata la
autenticación de usuarios y el correcto manejo de la seguridad en la Base de Datos.

Figura 3. 39 Usuarios

[Fuente: Elaboración Propia]

99
4.2.1 Autenticación De Usuario
Para nuestro caso la clase administrador es la encargada de facilitar usuario y
contraseña para el ingreso al sistema en el momento que así se amerite.

Figura 3. 40 Autenticación de Usuario

[Fuente: Elaboración Propia]

4.4.2 Seguridad en la Base de Datos


XAMPP actúa de una manera específica al momento de activar o desactivar las
herramientas de servidor y base de datos tanto en el servidor apache y MySQL
controlando de esta manera el flujo de información.

100
Figura 3. 41 Panel de Activación XAMPP

[Fuente: Elaboración Propia]

PhpMyAdmin es la herramienta web para el manejo de base de datos de XAMPP


el cual tiene una autentificación de usuarios propio para el acceso a la Base de
Datos.

Figura 3. 42 Autenticación de Usuario PhpMyAdmin

[Fuente: Elaboración Propia]

101
4.3 ANALISIS DE COSTO/BENEFICIO DEL SISTEMA
En este punto se cuantifica la inversión de los recursos que se empleó en el
desarrollo del sistema. Para el cálculo de esfuerzo y costo del desarrollo del
software se utilizara el COCOMO para lo cual se emplea la siguiente tabla:

Tabla 4. 4 Modelo COCOMO

Proyecto de o‘ b‘ c‘ d‘
software
Orgánico 2.4 1.05 2. 5 0.38
Semiocoplodo 3.0 1.12 2. 5 0.3 5
Rígido 3.6 1.2 2.5 0.32

[Fuente PRESSMAN,R,1999]

Con el modelo del COCOMO se realiza el cálculo del esfuerzo puesto para el
desarrollo del

Sistema en función del tamaño del programa expresado en líneas de código


(LCD).

Para el presente proyecto el valor de LCD=2100.


Estimacion de esfuerzo necesario'

E 2.4 (2.100)

E= 5.04 personas/mes

Redondeando

E= 5personas/mes

102
Estimación de tiempo necesario

𝐷 = 𝐶 𝑏 ∗ 𝐸𝑑

𝐷 = 2.5 ∗ 50.38
𝐷 = 4.60 𝑚𝑒𝑠𝑒𝑠
Redondeando

D= 5

meses Número de personas para

el proyecto

N = E/D

N = 5/5

N =1 persona

Estudiar del sistema, se toma en cuenta que un ingeniero de software percibe


un salario de 400 a 600 $us, lo que en Bolivia nos significa, de 1600 a 2400
Bs. Con lo que calculamos el costo del sistema en:

Costos=salario mínimo*tiempo necesario*# de personas para el


proyecto

Costos=1600*5*1=8000 Bs

Costos operacionales. Una vez instalado un sistema, al usuario le costara dinero

103
continuar operándolo. Aquí se tiene los típicos operacionales:

R Costo de hardware, e implementación. El software utilizado para el proyecto es


libre, por lo que no representa gastos, en cuanto el hardware, Se cuenta con un
modem perteneciente a la empresa viva de la fundación estas vivo que se encuentra
en el laboratorio de computación para lo cual se debe de llevar la conexión desde el
laboratorio de computación hasta la secretaria y dirección por lo que es necesario
cable blindado

Tabla 4. 5 Costo de Implementación

Descripción Costos
material de escritorio 200
Costo de software Bs0
Costos de hardware Bs
0
Cable de fibra optica 500Bs
Total Bs
700
Bs
[Fuente: Elaboración Propia]

Tabla 4. 6 Gastos

DESCRIPCION COSTO
Costo de desarrollo 8000
Costo de mantenimiento 500

Total 8500

[Fuente: Elaboración Propia]

El costo total del proyecto se determina con la suma del estudio del Sistema
y el costo.

104
ANALISIS DE LOS BENEFICIOS
Para nuestro caso los beneficios son intangibles por lo que con la implementación del sistema
obtendremos los siguientes beneficios.

 Decremento de tiempo en los procesos a realizarse


 Integración de la información
 Datos fiables
 Orden de información
 Adquisición de conocimiento.

105
Ahora menciono los logros conseguidos con el presente sistema y recomendaciones
que contemplan una mejora aun a futuro y en el ámbito social correspondiente.

5.1 Conclusiones
 Se pudo crear una base de datos para los principales ámbitos de la institución.
 El registro de estudiantes y docentes es una tarea importante lo cual se llevó a
cabo en el presente proyecto.
 La elaboración de informes era imprescindible ya que este proceso conllevaba
varios problemas en la institución.
 El manejo del inventario quedo consolidado con el registro y la generación del
informe respectivo.
 El punto más importante el manejo adecuado de las calificaciones y la
generación de boletines bimestrales para los padres de familia para llevar a
cabo el control adecuado a los estudiantes.

5.2 Recomendaciones
 Desarrollar un módulo que contemple la búsqueda en cada una de las
iteraciones realizadas.
 Desarrollar tecnologías de aprendizaje en los estudiantes.
 Desarrollar un sistema que realice el seguimiento académico al estudiante de
una manera más profunda.
 Desarrollar un sistema de gestión académica para entablar problemas con
mayor dificultad.
 Ampliar este conocimiento para más instituciones públicas y privadas en un
ámbito socio tecnológico.

106
BIBLIOGRAFIA

[BOOCH, G., RUMBAUGH, J., JA COBSON, I., 1998. The Unified Modeling Language
User Guide].

[LETELIER, P., PENADES, M. (n. d.). Metodologías agiles para el desarrollo de software].

[PRESSMAN, R. 1999 (5ta Edición) Ingeniería de Software, Un enfoque práctico].

[ECHEVERRY, L, DELGADO, L.2007 .Caso práctico de la metodología ágil XP.

[MUÑOZ, P. (n.d.).]. Modelado Web

[ABUD, M. (n. d.). Calidad en la Industria de Software. La Norma ISO-9126

[KENT BECK, 2002] Extreme Programming Explained Embrace Change


REFERENCIAS WEB

[Manual de usuario de apache, 2009]


http://quark.fe.up.pt/ApachES/manual-es/howto/cgi.html
[Recursos Tecnológicos]

http://recursos.fundacionesplai.org/intranet/dinamizadores/recursos_tecnologicos].

[Aplicaciones WEB XAMPP]

www.um.es/docencia/barzana/DAWEB/Desarrollo-de-aplicaciones-web-Xampp.html.

http//.www.Isi. us.es/docs /doctorado /tesis /tesis.pdf

http://’www.webml. org

107
108
Árbol de Problemas

Consumo de tiempo prolongado y


realización de procesos a destiempo

Búsqueda de Demora en la Incoherencias en los


calificaciones, ineficacia entrega de informes Extravió de datos de estudiantes y
con los horarios bimestrales documentos docentes

Procesos realizados manualmente en la institución (grandes


cantidades de información)

Manipulación manual Acumulación drástica de la


de los procesos información (documentación)
académicos en la Transcripción de
papeles
institución (docentes y calificaciones de forma
Complicación al
estudiantes) manual
momento de
verificar los
horarios Papeles

Registro de docentes y
estudiantes de manera
manual (actas)

Falta de
control en
el
inventario
de la
institución

109
Árbol de Objetivos

Procesos más rápidos y eficientes mejorando el trabajo realizado


optimizando el tiempo empleado en cada uno de estos procesos

Búsqueda de Rapidez con la Información Exactitud con los datos de los


calificaciones, eficiencia y generación de correctamente estudiantes y docentes
rapidez con los horarios reportes almacenada calificaciones en tiempo real

Diseñar, desarrollar e implementar un sistema de información der seguimiento académico solvente,


seguro y de fácil manejo para la unidad educativa republica de cuba que consiga automatizar los
procesos manuales identificados.

Asignación Registro Registro Almacenamiento Transcripción de


automática automatizado automatizado adecuado de la calificaciones de forma
de los de la de la información de automática
Horarios información información manera más
de institucional eficiente (base de
(docentes) estudiantes y datos)
docentes precisos

Papeles
Registro
automatizado
de la
información
concerniente
al inventario

110
PAGINA PRINCIPAL ESTUDIANTES

PAGINA PRINCIPAL DOCENTES

111
PAGINA PRINCIPAL INVENTARIO

PAGINA PRINCIPAL CALIFICACIONES

112
IMÁGENES

113
114
LABORATORIO DE COMPUTACION

115
116

También podría gustarte