b Universidad Nacional Autónoma de Nicaragua

UNAN-Managua
Facultad de Ciencias e Ingenierías

Departamento de Computación

Tema: Aplicación Web para Matrícula, Registro de Calificaciones y

Control de Pagos de la secretaría académica del Colegio Bautista
Libertad de Managua en el Segundo Semestre 2017

Autores:
 Br. Jimmy Antonio Alemán Leiva
 Br. Harruin Ricardo Álvarez Hernández
 Br. Kevin Josué Solís Cruz

Tutor: Msc. Reynerio Bermúdez Díaz

Managua, 31 de Enero del 2018

DEDICATORIA
Harruin Álvarez

A Dios por haberme permitido llegar hasta este punto y haberme dado salud, fuerzas
e inteligencias para lograr mis objetivos, además de su infinita bondad y amor, a mis
padres que me brindaron todo su apoyo y que estuvieron siempre ayudándome, a
Ruth que siempre creyó en mí y por sus motivaciones constantes, a mis docentes y
compañeros.

Kevin Solís

Esta tesis es dedicada a Dios, a mi madre Corina Leiva por haberme apoyado en
todo momento, por sus consejos, sus valores, por la motivación constante que me
ha permitido ser una persona de bien, pero más que nada, por su amor.

Jimmy Alemán

“Primeramente a Dios por brindarme salud y a mis padres por apoyarme en cada
paso de mi vida, a los docentes que se esforzaron día a día compartiendo un poco
de sus conocimientos conmigo y mis compañeros”

2
AGRADECIMIENTO
Harruin Álvarez

Le agradezco a Dios por haberme acompañado y guiado a lo largo de mi carrera,

por ser mi fortaleza en los momentos de debilidad y por brindarme una vida llena de
aprendizajes, experiencias y sobre todo felicidad. A mis padres por apoyarme en
todo momento, por los valores que me han inculcado y por haberme dado la
oportunidad de tener una educación en el transcurso de mi vida. A Ruth, por ser una
parte muy importante de mi vida, por haberme apoyado en las buenas y en las
malas, sobre todo por su paciencia y amor incondicional.

Kevin Solís

Primeramente, gracias a Dios por ser mi guía, a mis maestros por sus conocimientos
impartidos y a mis padres porque ellos siempre están conmigo apoyándome,
algunos presentes y otros ausentes, pero igual siempre se hacen notar, porque
hicieron de mí una persona de bien para conducirme correctamente.

Jimmy Alemán

“Primeramente agradezco a Dios por permitirme llegar hasta este momento por
brindarme las fuerzas para culminar mis estudios, además quiero dar un
agradecimiento especial a mis padres quienes fueron mi principal apoyo en mi
desarrollo tanto personal como profesional, que han confiado siempre en mí y en
todo lo que me he propuesto.”

3
CARTA AVAL DEL TUTOR

4
RESUMEN

La Tecnología avanza rápidamente, en un mundo cambiante además de

competitivo, en el ámbito de la educación no es la excepción los centros escolares
están implementando el uso de sistemas de información para automatizar y agilizar
sus diferentes procesos académicos.

Esta investigación está orientada al desarrollo e implementación de una aplicación

web para matricula, control de pago y registro de calificaciones en el centro escolar
Bautista Libertad.

Desde su fundación en el año 2000 el centro ha experimentado un crecimiento en

la población estudiantil, eso vino a provocar un problema en el proceso de matrícula
debido a que se convirtió en un proceso tedioso de realizar, provocando un aumento
de la cantidad de papel que maneja el centro debido a que todo esto se realizaba
de manera manual y en el mejor de los casos en hojas de cálculo de Excel.

De ahí la necesidad de hacer uso de una aplicación web, la cual permita dar solución
a esta problemática, en este caso se optó por una aplicación web gracias a las
bondades que brinda este tipo de aplicaciones como son: disponibilidad de la
información en tiempo real y funcionamiento con bajos recursos en pc, la portabilidad.

5
INDICE
DEDICATORIA ................................................................................................................................. 2
AGRADECIMIENTO......................................................................................................................... 3
CARTA AVAL DEL TUTOR ............................................................................................................ 4
RESUMEN.......................................................................................................................................... 5
CAPÍTULO 1 ...................................................................................................................................... 8
moto1. Introducción ........................................................................................................................ 8
2. Planteamiento del Problema ...................................................................................................... 10
3. Justificación............................................................................................................................... 12
4. Objetivos de la Investigación ................................................................................................ 14
4.1. General ............................................................................................................................. 14
4.2. Específicos....................................................................................................................... 14
CAPÍTULO 2 ................................................................................................................................... 15
5. Marco Referencia ................................................................................................................... 15
5.1. Antecedentes................................................................................................................... 15
5.2. Marco Teórico .................................................................................................................... 16
5.3. Marco Conceptual........................................................................................................... 56
5.4. Marco Legal ..................................................................................................................... 57
6. Hipótesis .................................................................................................................................. 59
CAPÍTULO 3 ................................................................................................................................... 60
7. Diseño Metodológico ............................................................................................................. 60
7.1. Tipo de Investigación ..................................................................................................... 60
7.2. Descripción Población de Estudio................................................................................ 60
7.3. Tipo de Método de investigación a aplicar ................................................................. 61
7.4. Técnicas de recolección de datos ................................................................................ 61
7.5. Procedimiento para la recolección de información .................................................... 62
7.6. Herramientas de desarrollo ............................................................................................ 64
7.7. Operacionalización de Variables .................................................................................. 65
7.8. Presupuesto ..................................................................................................................... 69
7.9. Aplicando Métricas ......................................................................................................... 71
CAPÍTULO 4 ................................................................................................................................... 72
8. Análisis y Discusión de los Resultados .............................................................................. 72
CAPÍTULO 5 ................................................................................................................................. 108

6
10. Recomendaciones ............................................................................................................. 108
11. Referencias y Bibliografía ................................................................................................. 109
9. Conclusiones ........................................................................................................................ 112
12. Cronograma ........................................................................................................................... 113
13. Anexos ................................................................................................................................. 115
Manual básico de usuario ................................................................................................... 134

7
CAPÍTULO 1
moto1. Introducción
La presente investigación se refiere al tema de “Aplicación Web de Matrícula,
Registro de Calificaciones y Control de Pagos para la secretaría académica del
Colegio Bautista Libertad de Managua en el segundo semestre 2017.”, que se define
como un conjunto de elementos que interactúan entre sí. Actualmente las empresas
optan mayormente en emplear un sistema web que los tradicionales de escritorio
debido a las diferentes bondades que ofrecen.

Entre las características principales que poseen los Sistemas informáticos de

plataforma web están la disponibilidad de la información en tiempo real, el acceso a
la misma desde la comodidad del hogar a través diferentes dispositivos, la
compatibilidad multiplataforma con los diferentes sistemas operativos y los bajos
requerimientos de hardware, ya que se puede acceder a estos sin contar con
grandes capacidades en los dispositivos (Memoria RAM, Procesador, Tarjeta
Gráfica, etc).

Esta investigación tiene razón de ser por una serie de causas que es necesario
mencionar. Una de ellas es la creciente población estudiantil en el Colegio Bautista
Libertad, ya que la cantidad de datos que se obtienen por las diferentes actividades
como la matricula, el registro de notas, control de pagos aumentan de forma
significativa influyendo en el registro, control y procesamiento de los mismos, lo que
representa mayor consumo de recursos para el personal de secretaría académica
tanto en material, esfuerzo y sobre todo tiempo.

El principal interés de llevar a cabo esta investigación es aplicar las nuevas

tecnologías de diseño y desarrollo de software en el ambiente de .NET para brindar
una herramienta (Aplicación Web) que colabore con la eficiencia operacional en el
área de secretaría académica.

Además, otra de las razones para realizar este trabajo es para adquirir experiencia
en el campo del desarrollo de software, puesto que es una gran oportunidad de
emplear los conocimientos adquiridos durante el transcurso de la carrera y también
poder aportar a la solución de dicha problemática.

8
Para la realización de esta investigación, será necesario efectuar una serie de
entrevistas a Directores, Secretarías y docentes del colegio Bautista Libertad.
Considerando a estos como informantes clave. Un informante clave es una
característica de la muestra no probabilística conocida como intencional.

Para llevar a cabo esta investigación se empleará la metodología ágil de

programación extrema (Metodología XP), la cual consta de cuatro etapas
principales siendo la primera la planeación: en esta etapa es donde se empieza a
interactuar con el cliente básicamente para identificar los requerimientos del sistema
a través de diferentes prácticas y valores planteados por la teoría, en segundo lugar
se continua con la etapa de diseño y cabe destacar que es una tarea permanente
durante la vida del proyecto puesto que se van realizando pequeños módulos y
partiendo de un diseño inicial que va siendo mejorado.

En tercer lugar, está la etapa de codificación la cual es paralela con el diseño puesto
que cuando se diseña a la vez se codifica ya que la metodología sugiere entregar
pequeños módulos pero que sean funcionales. Y por último la etapa de pruebas es
de suma importancia para seguir avanzando con el desarrollo y alcance del proyecto
puesto que del buen uso de estas se tendrán como terminados y listos para usarse
los diferentes módulos.

9
2. Planteamiento del Problema
Actualmente la tecnología avanza rápidamente teniendo gran repercusión en los
diferentes campos y la educación no es la excepción, ya que en todas las áreas
donde se implementa pueden obtenerse resultados muchos mejores que
prescindiendo de esta. En este mundo cambiante y competitivo el buen uso de la
tecnología y aprovechamiento de la información puede marcar la diferencia en un
mercado laboral. Hoy en día no es suficiente solamente el planificar, organizar,
ejecutar y controlar diferentes planes sin el uso de las tecnologías de la información.

En consideración con lo mencionado anteriormente se determinó que el principal

problema en el área de secretaría académica del Colegio Bautista Libertad está
orientado a la necesidad de brindar una respuesta a la deficiencia en los
procesos de matrícula, registro de calificaciones (parciales, semestrales y
finales) y control de pagos a través de la implementación de una Aplicación
Web.

Sin embargo, en el plan operativo anual para el año 2017 del Colegio Bautista
Libertad no se contempla la adquisición de una Aplicación Web por medio de algún
consultor o empresa dedicada al desarrollo de sistemas a medida. Durante este
periodo la dirección del centro educativo priorizo la instalación de cámaras para
tener un mayor monitoreo en las áreas sensibles, así como la compra de mejores
computadoras para el laboratorio.

Esta institución educativa aplicaba un sistema manual que consistía en realizar el

ingreso, registro y control de los datos de los estudiantes, por ejemplo, de
matrículas, notas pagos, etc. En hojas de papel archivándolas en bodegas de
carpetas, y en el mejor de los casos llevando los registros en hojas de cálculo de
Excel.

Para conocer un poco mejor la situación se consideró importante conocer la forma

en que aplicaban dicho sistema manual. En primer lugar, el proceso de matrícula se
volvía muy tedioso debido a la tarea repetitiva del llenado de extensos formularios
por alumno de cada año. Con respecto al control de pagos no era rígido y además

10
desordenado aparte de repetitivo ya que se realizaban dos recibos por cada pago
efectuado.

Asimismo, el registro de la carga académica y el control de notas era una tarea

costosa en cuanto a tiempo ya que se realizaba un proceso extenso por la creciente
población estudiantil, lo cual ocasiono un mayor esfuerzo tanto para la secretaría
como para los docentes.

El tiempo que invertía el personal de secretaría académica tanto directora,

secretaría como docentes era considerable, al querer procesar la información y
presentarla en diferentes reportes provenientes de los procedimientos relacionados
con el registro académico, además cabe destacar la vulnerabilidad que se presentó
en el resguardo de la información, ya que tenerla solamente de forma física está
expuesta a cualquier siniestro o extravío de la misma.

A pesar de no considerar la adquisición de una aplicación web, todo lo expuesto

anteriormente llevo a la institución a que sea mayor el esfuerzo en el intento por
mejorar la ejecución de sus procesos haciendo mayor uso de herramientas
tecnológicas tales como: hojas de cálculo Excel, formularios de Excel y
procesadores de texto. No obstante, dichas aplicaciones no proporcionaban una
herramienta a la medida que sea óptima que se ajuste a las necesidades específicas
del centro, que sí lo hará en su caso la aplicación web ajustada a los requerimientos
y necesidades del centro escolar.

Para esta investigación se puedo plantear la siguiente pregunta:

¿Trascenderá la implementación de una aplicación web para la automatización del

registro de matrícula, registro de notas y control de pagos de los estudiantes del
Colegio Bautista Libertad del colegio de Managua?

11
3. Justificación
Con el desarrollo y la implementación de la Aplicación Web de matrícula registro de
notas y control de pagos que se denominó APGA (Aplicación Web para Gestión
Académica), se brindará una herramienta integral que aportará para dar una
solución a la deficiencia en la gestión de las actividades académicas tales
como: Matrícula, Control de notas (parciales, semestrales y finales), y control
de pagos.

El APGA ayudará a reducir el tiempo invertido en cada uno de los procesos tanto
en el de matrícula, el registro de notas y el control de pagos, además proporcionará
seguridad en el manejo de la información puesto que brindara un módulo de
seguridad para que solo aquellos usuarios privilegiados tengan acceso de la misma,
también procesar y generar reportes que brinden información para la toma de
decisiones y por último como resultado de lo mencionado dar una mejor experiencia
para los usuarios finales al proporcionar una interfaz amigable que se ajuste a las
necesidades de la secretaría académica del Colegio Bautista Libertad.

Con esta herramienta habrá una mejoría apreciable en el desempeño de las

actividades académicas, se tendrá un mejor trámite, procesamiento, obtención,
centralización y almacenamiento de la información. Explícitamente la APGA
proporcionará al área de Secretaría Académica un control más riguroso en el acceso
de la información, procesos más agiles por ejemplo en la elaboración de certificados
de notas, asignación de carga académica, entrega de calificaciones y el control de
los pagos de mensualidades de cada alumno.

La Aplicación Web le permitirá al personal docente tener un mejor control de las

calificaciones y facilidad de acceso a la información de los alumnos al tenerla en
línea y de igual manera los padres de familia y alumnos se beneficiarán al realizar
matrícula y obtener reporte de notas, de forma rápida y precisa.

Desde el punto de vista técnico el centro educativo cuenta con los recursos
necesarios para llevar acabo el desarrollo e implementación de la aplicación web,
desde el punto de vista económico a la institución el desarrollo del sistema no

12
represento un valor monetario, puesto que se realizó como trabajo final monográfico
para optar al título de:

Licenciado en Ciencias de la Computación, además que para la interacción con el

personal involucrado para realizar la recolección de información se hizo en horas no
laborales para que no represente ningún costo extra para la sustitución de algún
docente o para la secretaría. Es importante mencionar que el costo económico que
asumió el centro educativo fue por la adquisición de un nombre de dominio y el
alquiler de hosting para alojar la aplicación de gestión académica.

13
4. Objetivos de la Investigación
4.1. General
Desarrollar un Aplicación Web de matrícula, registro de notas y control de pagos,
que optimice la calidad en los servicios y operaciones del Colegio Bautista Libertad.

4.2. Específicos
 Caracterizar el proceso de matrícula, registro de calificaciones y control de
pagos, a través de la implementación de los mecanismos necesarios para la
coordinación entre dichos módulos.
 Seleccionar una herramienta tecnológica que mejor se adecue a la capacidad
económica, infraestructura, recursos humanos, para el desarrollo de la
Aplicación Web
 Diseñar la Aplicación web que optimice los procesos de matrícula, control de
pago y control de nota del colegio Bautista Libertad, de igual modo que
permita generar reportes que sirvan de apoyo en la toma de decisiones.
 Evaluar la calidad de la Aplicación Web desarrollada aplicando métricas de
proyecto webapp y Facilidad de Uso al producto software.

14
CAPÍTULO 2
5. Marco Referencia
5.1. Antecedentes
El mundo avanza a pasos agigantados y la tecnología se ha vuelto un factor
indispensable para el desarrollo, con la creación de sistemas informáticos para
escritorio, así como las aplicaciones web, se han vuelto un factor importante para la
automatización de procesos que ayudan a realizar diversas tareas de manera más
rápida.
En el área de la educación estas tecnologías se adecuan para la automatización de
procesos como matriculas, control de pago, registro de calificaciones entre otras.
Los países desarrollados como Estados Unidos, Japón, Rusia, aplican estos
sistemas en todos sus centros educativos con el fin de dar mejor atención a padres
de familias, así como facilitar el trabajo para los docentes.
En Centroamérica uno de los primeros países en adoptar esta innovación fue Costa
Rica, con la implementación de sistemas informáticos que agilizan los procesos en
los diferentes centros escolares.
A medida que avanzó el tiempo esta innovación llego a los demás países de la
región, en Nicaragua no fue la excepción uno de los primeros centros en hacer uso
de estas tecnologías fue el Instituto La Salle, luego siguió sus paso centros
escolares como Manuel Olivares, Colegio Centroamérica y Colegio
Latinoamericano adoptando el uso de sistemas informáticos de escritorio para
matriculas, registro de calificaciones y el control de notas.
Posteriormente con la popularización del internet el cual paso de ser un lujo a ser
una necesidad, ha tomado impulso la utilización de aplicaciones web para
sustitución de los sistemas de escritorios.

15
5.2. Marco Teórico
5.2.1. Sistema de Información
Los sistemas de información (SI) están cambiando la forma en que operaban las
organizaciones actuales. A través de su uso se logran importantes mejoras, pues
automatizan los procesos operativos de las empresas, proporcionan información de
apoyo al proceso de toma de decisiones, lo que es más importante, facilitan el logro
de ventajas competitivas a través de su implantación en las empresas (Cohen,
2009)

Los SI (Sistemas de Información) se desarrollan para distintos fines, dependiendo

de las necesidades de los usuarios humanos y la empresa. Cuando se habla del
nivel operacional de la organización son los sistemas de procesamiento de
transacciones (TPS) que funcionan en dicho nivel (Kendall, 2011).

5.2.1.1. Tipos de Sistemas de Información

Los tipos de sistemas de información se clasifican de la siguiente forma.
 Sistemas de Información Administrativa
 Sistema de Soporte de Decisiones
 Sistema de Automatización de oficina y sistemas de trabajo de conocimiento
 Inteligencia artificial y sistemas expertos
 Sistemas de Soporte de Decisiones en Grupo y Sistemas de Trabajo
Colaborativo Asistido por Computadora
 Sistema de Soporte Ejecutivo
En la presente investigación se utilizó el sistema de información administrativa ya
que se caracteriza por las constantes actividades relacionadas entre los equipos,
personas e instalaciones que intervienen en generar información para dirigir
subsistemas y la compañía en su conjunto.
5.2.1.1.1. Sistema de Información Administrativa
Los sistemas de información administrativa (MIS) no sustituyen a los sistemas de
procesamiento de transacciones; más bien, todos los sistemas MIS incluyen el
procesamiento de transacciones. (Kendall, 2011, p.3).

Los MIS son sistemas de información computarizados que funcionan debido a la

decidida interacción entre las personas y las computadoras. Al requerir que las
personas, el software y el hardware funcionen en concierto, los sistemas de
información administrativa brindan soporte a los usuarios para realizar un espectro

16
más amplio de tareas organizacionales que los sistemas de procesamiento de
transacciones, incluyendo los procesos de análisis y toma de decisiones.

5.2.1.1.1.1. Funciones
Los MIS y sus sistemas aledaños contribuyen a la solución de problemas a través
de dos formas básicas: los recursos de información que abarcan a toda la
organización, y la identificación y comprensión de los problemas.

Los recursos de información que abarcan toda la organización se refieren a que el

MIS es un esfuerzo que requiere de toda la organización y que busca proporcionar
información importante para la toma de decisiones. (McLeod, 2000).

5.2.1.1.1.2. Propósito
Permite a los administradores analizar en forma sistemática cada una de las tareas
de una organización y compararlas con las capacidades de la computadora.

5.2.2. Sistemas web

Tradicionalmente los TPS están basados en tecnología para ambiente de escritorio,
es decir aplicaciones que dependen de diferentes componentes para poder ser
ejecutadas en una determinada computadora, sin embargo, a medida que el tiempo
avanza surgen nuevas TI (Tecnologías de Información) que presentan grandes
beneficios y por tanto son adoptadas por los desarrolladores en virtud de brindar
una mejor solución a los usuarios.

Tal es el caso de los Sistemas Web o más bien conocidos como aplicaciones web,
que son definidas como aquellos sistemas que están alojados en un servidor web
ya sea en internet o en una red local (Intranet) y que son accedidos a través de
solicitudes por el protocolo http. Y cuya arquitectura está basada en el modelo
cliente/ servidor, el cual propone que una serie de clientes, que pueden ser cualquier
dispositivo (computadora, laptop, Tablet, teléfono), realizan peticiones a un servidor
(Mateu, 2004).

5.2.2.1. Beneficios
Como se ha dicho los Sistemas Web proveen muchos beneficios, por ejemplo:

 Aumentan el número de usuarios que se enteran de la disponibilidad de un

servicio, producto, industria, persona o grupo.

17
  Los usuarios tienen la posibilidad de acceder las 24 horas del día.
 Se puede mejorar la utilidad y capacidad de uso del diseño de la interfaz.
 Se puede expandir un sistema globalmente en vez de permanecer en el
entorno local, con lo cual se puede establecer contacto con personas en
ubicaciones remotas sin preocuparse por la zona horaria en la que se
encuentren. (Kendall, 2011, P.5).

5.2.2.2. Estructura de una Sistema web

Con respecto a su estructura “…los sistemas web aprovechan la infraestructura de
la WWW. Diseñada en su día para publicar documentos entrelazados, para facilitar
la ejecución remota y distribuida de programas almacenados en un servidor”
(Charte, 2013, P.30). La estructura de estos sistemas se ajusta a la arquitectura
clásica cliente/servidor, según la cual existe un servidor y uno o varios clientes
accediendo al mismo.

5.2.2.3. Arquitectura Cliente/ Servidor

Es decir, esta arquitectura consiste en “…un modelo de aplicación distribuida en el
que las tareas se reparten entre los proveedores de recursos o servicios, llamados
servidores, y los demandantes, llamados clientes” (Lujan, 2002, p.39). Uno o varios
clientes pueden realizar peticiones a otro programa, el servidor, es quien se encarga
de darle respuesta.

5.2.2.3.1. Cliente
En particular un cliente es definido como la entidad que realiza peticiones a través
del protocolo HTTP (Hipertext Transfer Protocol) a un Servidor, solicitando recursos
y servicios (Lujan,2002). Hay que destacar que un cliente puede ser cualquier
dispositivo capaz de ejecutar un navegador Web, mostrando la información que
reciba del servidor. Dicha información será un flujo de datos compuesto
principalmente de código HTML, CSS Y JavaScript, dando forma a lo que será la
interfaz de usuario de la aplicación.

5.2.2.3.1.1. Navegador Web

Así pues, un navegador web se define una aplicación de software que permite a los
usuarios de Internet acceder, navegar y buscar información, servicios o productos
a nivel mundial. Los navegadores web interpretan enlaces de hipertexto que

18
permiten leer documentos formateados en HTML, JavaScript y AJAX de tal manera
que puedan ser vistos en la pantalla del computador.

5.2.2.3.2. Servidor
Por su parte, el servidor “…será el que ejecute la mayor parte de la lógica de la
aplicación, procesando la información recibida en las solicitudes, estableciendo el
nuevo estado que debe adoptar la interfaz de usuario y enviándola de vuelta al
cliente” (Charte,2013, p.31).

5.2.2.3.2.1. Servidor Web

Un servidor web o servidor HTTP es un programa informático que procesa una
aplicación del lado del servidor, realizando conexiones bidireccionales o
unidireccionales y síncronas o asíncronas con el cliente y generando o cediendo
una respuesta en cualquier lenguaje o Aplicación del lado del cliente.
Hay que tener en cuenta un elemento fundamental, el cual es el servidor web, que
será el encargado de la comunicación entre el equipo servidor y los dispositivos
que actúen como clientes, liberando la aplicación de los detalles de bajo nivel a la
aplicación.

5.2.3. Infraestructura y elementos de comunicación requeridos por un Sistema

Web
5.2.3.1. Internet
Para el funcionamiento de un sistema web es necesario contar una adecuada
infraestructura que se encargue de proveer todos los recursos necesarios para que
esta pueda desempeñar las diferentes funciones que encapsula. Así pues, Internet
que se define como “…un conjunto descentralizado de redes comunicación
interconectadas entre sí” (Cardador,2014) es una posible alternativa que pueda
gestionar los diferentes requisitos de la aplicación para poder ser ejecutada.

Hay que destacar que más de una de esas redes que conforman el internet no tienen
la misma tecnología ni topología, por lo cual se hace necesario el concepto de
protocolos que es a través de los mismos que se hace posible la comunicación entre
las diferentes redes.

Este es otro punto importante a considerar y es que para pueda existir comunicación
entre cliente y servidor pertenecientes a la misma o a diferentes redes, de modo

19
que sea posible transportar paquetes de información de a un extremo a otro y
viceversa se necesita un conjunto de elementos, reglas, estándares, que son
conocidos como protocolos.

De allí pues, que existan diferentes protocolos de internet cada cual, para una
función específica, es uno el que permite conectar al cliente con el servidor cuyo
nombre es HTTP.

5.2.3.1.1. Protocolo HTTP

Es decir, que HTTP es descrito como “…un protocolo de red situado en la capa de
aplicación, orientado a transacciones que utiliza conexiones TCP (Transfer Control
Protocol) en el nivel de transporte” (Charte,2013, P.34), Con la finalidad de
establecer una conexión entre cada cliente y servidor creando un circuito virtual por
el que irán viajando los paquetes de datos.

Asimismo, hay que destacar que toda la información que el cliente de una aplicación
tenga que enviar al servidor, y viceversa, ha de ser transferida utilizando el protocolo
HTTP. Este es el utilizado desde el nacimiento de la Web para acceder a las páginas
(Charte, 2013).

También, vale la pena decir que su esquema de funcionamiento es siempre

exactamente el mismo, por ejemplo: un cliente, habitualmente un navegador web,
hace llegar al servidor una solicitud, esta irá siempre acompañada de un URL que
por sus siglas en ingles significa Uniform Resource Locator y puede ser de forma
opcional, información adicional como son los datos contenidos en un formulario.

5.2.3.1.1.1. Estructura de una solicitud HTTP

Con respecto a las solicitudes estas son las que dan inicio a una transacción HTTP,
y poseen una estructura en particular, por ejemplo:

GET /index.htm HTTP/1.1

Host: www.fcharte.com

User-Agent: Id-Navegador

20
En primer lugar, se especifica el comando que debe ejecutar el servidor, el recuso
asociado y la versión del protocolo que está utilizando el cliente, seguido de la
segunda línea que identifica el servidor lógico al que se dirige la solicitud y la última
facilita al servidor información sobre el software cliente que ha enviado la solicitud.

5.2.3.1.1.2. Estructura de una respuesta HTTP

Ahora bien, una vez que el cliente ha transmitido su solicitud el protocolo HTTP, se
quedará a la espera aguardando la respuesta del servidor, en caso de no llegar en
un tiempo máximo, el cliente notificará al usuario (esto se conoce como timeout)
(Charte, 2013). La respuesta del servidor, que normalmente llegará antes de que
expire ese tiempo máximo, tendrá un formato como el siguiente:

HTTP/1.1 200 OK

Content-Type: text/html

Content-Length: nnn

<html>

</html>

La primera línea indica la versión del protocolo que se está utilizando y, la parte más
interesante, se notifica mediante un código si la operación ha tenido éxito o no, o si
ha sido imposible satisfacerla. El código 200 OK indica que todo ha ido bien, por lo
que el cliente puede interpretar el cuerpo de la respuesta según el tipo de contenido
que establece la cabecera Content-Type.

5.2.3.1.1.3. Información de Estado

Por otra parte, es importante comprender que la conexiones que un cliente abre
para enviar la solicitud al servidor es cerrada por este en cuanto devuelve su
respuesta, de manera que cualquier transacción HTTP posterior debe abrir una
nueva conexión, de forma que surge la interrogante de ¿cómo es posible, entonces
mantener información de estado entre solicitudes? Esa información será la que

21
permita a una aplicación web comportarse como tal, como una aplicación, y no como
un conjunto de páginas sin conexión entre sí.

Así pues, la respuesta a dicha pregunta es que la responsabilidad de mantener esa

información de estado corresponde a la propia aplicación o, en su defecto, a la
infraestructura sobre la que está construida.

5.2.3.1.1.3.1. Dominio
Ahora bien, para acceder a una aplicación o sistema web cuya infraestructura sea
Internet, es necesario un nombre de dominio, que en términos generales “…es un
nombre que puede ser alfanumérico que generalmente se vincula a una dirección
física que puede ser de una computadora o cualquier dispositivo electrónico”
(Cardador,2017). Hay que destacar que, sin nombres de dominio, las URL serían
una serie de números, o direcciones IP, casi imposibles de recordar. Sin embargo,
un nombre de dominio brinda una dirección fácil de recordar.

5.2.3.1.1.3.2. Alojamiento Web (Hosting)

En relación con el alojamiento web, este se define como “…el servicio que provee
a los usuarios de Internet un sistema para poder almacenar información, imágenes,
vídeo, o cualquier contenido accesible vía web” (Cardador,2017). Además de forma
más específica proporcionan un entorno para albergar sitios web, al igual que
sistemas o aplicaciones web.

Es decir, ponen a disposición del cliente una serie de tecnologías que le permitan
alojar páginas web estáticas, así como también sistemas web. Entre las más
importantes por decirlo de alguna manera se encuentran las plataformas de
desarrollo para soportar un determinado sistema, por ejemplo (PHP, Java,
ASP.NET), asimismo servidores web para gestionar los diferentes sitios que se
tengan y los sistemas gestores de bases de datos tales como: MySQL, SQL Server,
PostgreSQL, etc.

Hay que tener en cuenta, que existen diferentes tipos de alojamientos en la internet,
pero el que más conviene emplear es aquel que tiene un costo por su contratación,
además de una serie tecnologías y capacidades que garanticen el buen
funcionamiento de un sistema web.

22
5.2.3.2. Intranet
A diferencia de la Internet una Intranet “…es un sitio web interno, diseñado y
desarrollado para trabajar dentro de los límites de una determinada compañía”
(Cardado,2017). Cabe decir que la mayor diferencia con Internet es que este es
público frente a la Intranet que es normalmente privada y que tiene como objetivo
facilitar a los trabajadores el desarrollo de su trabajo para una mayor eficiencia de
la empresa.

5.2.4. Tecnologías para el desarrollo de Aplicaciones Web en .NET

Acerca del desarrollo de la aplicación web existe una gran variedad de tecnologías
disponibles, por ejemplos frameworks (entorno de trabajo) para el diseño que
corresponde a lo que se conoce como front-end y asimismo para el desarrollo
correspondiente al back-end de una aplicación.

5.2.4.1. Microsoft .NET

En particular, Microsoft .NET proporciona un entorno de programación orientada a
objetos y un entorno de ejecución para construir aplicaciones de escritorio o para la
web. Este consta de dos componentes principales: el CLR (Common Language
Runtime), este es el motor de ejecución que controla las aplicaciones en ejecución,
y la biblioteca de clases que proporciona una serie de librerías de código para ser
reutilizado (Ceballos, 2013).

De acuerdo con (Ceballos, 2013) el CLR no es más que una máquina virtual que
administra la ejecución del código de una aplicación, y la Biblioteca de clases de
.NET según (Ceballos, 2013) es una biblioteca orientada a objetos que permite
realizar tareas habituales de programación, como, por ejemplo: recolección de
datos, conectividad de bases de datos, así como desarrollar diferentes tipos de
aplicaciones entre las cuales se encuentran las aplicaciones para la web de
ASP.NET.

5.2.4.2. Net Framework

Ahora bien, .Net Framework proporciona una infraestructura que facilita el desarrollo
de aplicaciones, también provee un entorno unificado para todos los lenguajes de
programación. En particular Microsoft ha incluido en este marco de trabajo los
lenguajes C#, Visual Basic, C++ y F#, y, además, ha dejado la puerta abierta para

23
que otros fabricantes puedan incluir sus lenguajes. Cabe destacar que ahora se
tiene la capacidad de poder escribir una misma aplicación utilizando diferentes
lenguajes.

En efecto, un código puede interactuar con cualquier otro independientemente del

lenguaje utilizado gracias a que .Net Framework proporciona la “especificación
común para los lenguajes” (Ceballos,2013), (CLS-Common Language Specification)
que define las características fundamentales del lenguaje y las reglas de cómo
deben ser utilizadas.

También define un conjunto de tipos de tatos comunes (Common Type System o

CTS) el cual indica qué tipos de datos se pueden manejar, cómo se declaran y cómo
se utilizan. De esta forma, aunque cada lenguaje .NET utilice una sintaxis diferente
para cada tipo de datos, por ejemplo, C# utiliza int un número entero de 32 bits y
Visual Basic utiliza Integer, estos nombres no son más que sinónimos del tipo
común System.32. De esta forma, las bibliotecas que utilicen datos definidos en el
CTS no presentarán problemas a la hora de ser utilizadas desde cualquier otro
código escrito en la plataforma .NET, permitiendo así la interoperabilidad entre
lenguajes.

También además del CLR, el CLS y los lenguajes, forman parte de este marco de
trabajo las bibliotecas que permiten crear aplicaciones Windows Forms (WinForms)
o aplicaciones WPF (Windows Presentation Foundation), la plataforma de desarrollo
web ASP.NET, la biblioteca para desarrollo de servicios web, la biblioteca ADO.NET
o ADO.NET Entity Framework para acceso a bases de datos, la combinación de
extensiones al lenguaje y bibliotecas (LINQ y sus proveedores de datos) que
permiten expresar como parte del lenguaje consultas a datos, etc.

Así pues, el desarrollo de aplicaciones web empleando la plataforma de .NET se

vuelve más rápido, fácil e intuitivo y aún más teniendo en cuenta que se dispone de
un entorno de desarrollo integrado como lo es Visual Studio.

5.2.4.3. Visual Studio

Además de proveer una plataforma con diferentes componentes que simplifican el
trabajo de desarrollo de aplicaciones, Microsoft.Net provee un IDE (Entorno de
24
desarrollo integrado) llamado Visual Studio que es definido como “…un conjunto
completo de herramientas de desarrollo para construir aplicaciones web, servicios
web, aplicaciones Windows o de escritorio y aplicaciones para dispositivos móviles”
(Ceballos, 2013, p.13).

También el entorno de desarrollo integrado ofrece esta plataforma con todas su

herramientas y con la biblioteca de clases .NET Framework es compartido en su
totalidad por Visual C#, Visual Basic Y Visual C++, permitiendo así crear con
facilidad soluciones en las que intervengan varios lenguajes y en las que el diseño
se realiza separadamente respecto a la programación.

5.2.4.4. Tecnologías del lado del servidor

A diferencia de las tecnologías cliente, estas radican en un servidor web, además
través de ellas se realizan funciones de suma importancia como por ejemplo el
acceso y gestión de una base de datos, control del acceso y los usuarios de un
determinado sistema y es con la implementación de estas tecnologías que se logra
desarrollar aplicaciones dinámicas.

5.2.4.4.1. ASP.NET
Ahora bien, ASP.NET “…es una tecnología del lado del servidor que trabaja sobre
la plataforma de .NET, la cual proporciona un modelo de desarrollo web unificado
que incluye los elementos necesarios para crear aplicaciones web” (Ceballos, 2013,
p.743). Provee un entorno que permite construir aplicaciones en cualquier lenguaje
compatible con .NET, como por ejemplo C#, Visual Basic, F#, etc.

5.2.4.4.1.1. Lenguaje de Programación C#

Sin duda alguna C# es un poderoso lenguaje de programación y una alternativa
indiscutible a la hora de elegir un lenguaje para escribir una aplicación y es que, C#
“es un lenguaje de programación elegante, con seguridad de tipos y orientado a
objetos, derivado de C++ y Java” (Bell,2010). Este permite a los desarrolladores
crear una gran variedad de aplicaciones seguras y sólidas que se ejecutan en .NET
Framework, cabe destacar que su sintaxis es muy expresiva, pero también sencilla
y fácil de aprender.

25
Por otro lado, como lenguaje orientado a objetos que es admite una serie de
conceptos tales como: encapsulación, herencia y polimorfismo, además de estos
C# facilita el desarrollo de componentes de software mediante varias construcciones
de lenguaje innovadoras, por ejemplo: firmas de métodos encapsulados,
propiedades, atributos, comentarios documentación XML insertados, Language-
Integrated Query (LINQ), etc.

5.2.4.5. Patrón de Diseño MVC (Modelo Vista Controlador)

En cuanto al diseño de una aplicación, desde hace mucho tiempo existen distintos
patrones bien probados para aplicar en el desarrollo de una aplicación,
particularmente entre esos se encuentra el patrón Modelo-Vista-Controlador,
abreviado habitualmente como MVC.

5.2.4.5.1. Patrón Arquitectónico MVC

Este tipo de patrón se encuentra entre los grupos conocidos como patrones de
arquitectura, patrones de diseño, o patrones arquitectónicos, que se distinguen
particularmente por afectar a un componente sino a la estructura general de una
parte del proyecto o incluso el proyecto completo (Charte,2013). MVC tuvo sus
inicios a finales de la década de los 70 y actualmente está considerado un estándar,
aplicándose casi en cualquier proyecto de aplicación con interfaz de usuario.

5.2.4.5.2. Arquitectura MVC

Este patrón ofrece una plantilla para la arquitectura de una aplicación que se
compone de tres elementos fundamentales, estos son: en primer lugar, está el
modelo, el cual representa el estado de la aplicación en un momento dado,
ofreciendo los medios para consultar y modificar dicho estado (Charte,2013). En
otras palabras, puede traducirse como una serie de clases que equivalen a
entidades de una base de datos, junto con sus propiedades para consultar y
métodos para actuar sobre ellas.

También otro de los elementos es el controlador, que se encarga de responder a

las acciones del usuario, traduciéndolas en alteraciones sobre la vista o bien sobre
el modelo (Charte, 2013). Es algo habitual que exista un componente por cada
funcionalidad del sistema, determinando de esta forma globalmente el
comportamiento de la aplicación.
26
En último lugar, se encuentra la vista que equivale a la interfaz con la que interactúa
el usuario de la aplicación, la cual es generada a partir de la información obtenida
del modelo (Charte, 2013). La vista cambiará de acuerdo a la demanda del
controlador, cuando una acción de usuario así lo requiera.

5.2.4.5.3. Ventajas del patrón MVC

Teniendo en cuenta, que diseñar (y especialmente mantener) un sistema en el que
unos componentes cambian dinámicamente durante la ejecución y a lo largo del
tiempo, MVC se pronuncia en este contexto puesto que facilita el desacoplamiento
de dichos componentes, posibilitando de esta forma cambiar de vista con gran
sencillez sin necesidad de alterar el modelo.

Asimismo, resulta muy fácil dividir el proyecto en partes de forma que pueda ir
desarrollándose en paralelo, por parte de varios grupos, también el
desacoplamiento de los componentes simplifica la realización de pruebas de
software, de tal manera que es posible realizar pruebas sobre el modelo de manera
independiente al controlador y la vista.

Otra ventaja destacable es el mantenimiento de un sistema, puesto que pueden

presentarse diferentes cambios en un futuro y hay que tener en cuenta que la mayor
parte del ciclo de vida de un proyecto se emplea en mantenimiento y no en el
desarrollo inicial.

5.2.4.5.4. ASP.NET MVC.

Como parte de la plataforma de desarrollo de .NET de Microsoft se encuentra
ASP.NET MVC el cual “…es un framework, un marco para el desarrollo de
aplicaciones” (Charte, 2013, P.74). La primera versión de ASP.NET MVC surgió
con ASP.NET 3.5 SP1. Actualmente se encuentra en la versión cinco (MVC 5), que
es soportado a partir del framework 4.5.

Por otro lado, hay que tener en cuenta que el desarrollo de aplicaciones a través de
ASP.NET MVC representa solamente una alternativa a la metodología clásica no
un esquema que vaya a sustituirla, debido a que para proyectos que no sean de
envergadura el uso de los tradicionales formularios web de .NET son una alternativa

27
más simple y rápida, en cambio que para el resto ASP.NET MVC por todas las
bondades que puede aportar.

Además, ASP.NET MVC aporta todos los beneficios que ofrece el patrón MVC, pero
desligando al desarrollador de controlar todos los detalles, particularmente la
definición de las interfaces e implementación de patrones software que hacen
posible la comunicación entre el controlador y, las vistas y el modelo.

5.2.4.6. LINQ
A causa de ofrecer la posibilidad de expresar las operaciones de consulta en el
propio lenguaje (C#, por ejemplo) y no como literales de cadena pertenecientes a
otro lenguaje incrustados en el código de aplicación o como procedimientos
almacenados es que LINQ por sus siglas en inglés (Language Integrated Query) fue
incorporado con .NET Framework 3.0, (Ceballos,2013) sin embargo, a partir de la
versión 3.5 es cuando totalmente queda integrado en este marco de trabajo.

Ahora bien, LINQ es definido como “…una combinación de extensiones al lenguaje

y bibliotecas de código administrado que permite expresar de manera uniforme
consultas sobre colecciones de datos de diversa procedencia” (Ceballos, 2013,
P.631). Por ejemplo, sobre objetos en memoria, sobre bases de datos relacionales
o sobre documentos XML.

5.2.4.7. Entity Framework

Con respecto a Entity Framework este es un conjunto de tecnologías que permiten
el desarrollo de aplicaciones de software orientadas a datos (Ceballos,2013). Y que
además hace posible que los desarrolladores creen aplicaciones que acceden a
base de datos elevando el nivel de abstracción, del nivel lógico relacional al nivel
conceptual. En ese nivel de abstracción superior, Entity Framework admite código
que es independiente de cualquier motor de almacenamiento de datos.

De acuerdo a lo antes dicho, utilizando LINQ, específicamente el proveedor LINQ

to entities, es posible consultar las entidades que define el modelo conceptual de
Entity Framework. Las consultas que se realizan en dicho lenguaje serán
convertidas a SQL y enviadas a la base de datos para su ejecución. De igual forma

28
se encarga de realizar el proceso inverso cuando la base de datos devuelve los
resultados.

5.2.4.7.1. Modelo de trabajo Code First

Por otra parte, Entity Framework a partir de su versión 4.1 pone a disposición un
nuevo modelo de trabajo llamado Code First (Los enfoques previos son Database
First y Model First) el cual permite diseñar el modelo de entidades haciendo uso
solamente de código (Ceballos,2013).

Como bien lo indica su nombre, se basa en codificar primero, es decir crear clases
POCO (Plain Old CLR Objects), empleando el lenguaje de preferencia que esté
dentro de la plataforma .NET (VB.NET, C#, F#, etc) y luego crear la base de datos.
Esta es su principal característica, aunque también se puede extraer el modelo de
relaciones a partir de una base de datos existente.

También este modelo permite a los desarrolladores enfocarse completamente en el

desarrollo de la aplicación, persiguiendo unos de los objetivos de la plataforma .NET
Framework que es el desarrollo de aplicaciones que contengan únicamente código
.NET.

5.2.4.8. SQL Server

Se puede definir como una plataforma de base de datos que se utiliza en el
procesamiento de transacciones en línea (OLTP) a gran escala, el almacenamiento
de datos y las aplicaciones de comercio electrónico; es también una plataforma de
Business Intelligence para soluciones de integración, análisis y creación de informes
de datos.
5.2.4.8.1. Reporting Services
SQL Server Reporting Services es una solución que los clientes implementan en
sus propias instalaciones para crear, publicar y administrar informes, y luego
entregárselos a los usuarios correctos de diferentes maneras, ya sea que los
visualicen en el navegador web, en su dispositivo móvil o como un correo electrónico
en su bandeja de entrada.

5.2.5. Tecnologías del lado del cliente

Con respecto a las tecnologías del lado del cliente, estas son aquellas “…que se
ejecutan en el navegador del usuario” (Pavón, 2014). El navegador es conocido
como cliente puesto que funciona con la siguiente lógica: Cuando una persona va a

29
comprar algo a una tienda, comer en restaurante llega y solicita un servicio entonces
pregunta por algo o simplemente lo toma y se va, pero siempre le están atendiendo
de una forma: le cobran, le dan el producto o servicio que solicitó, así que esa
persona es un cliente.

De la misma manera en que se comporta un cliente solicitando un servicio o un

producto determinado así también un navegador solicita a un servidor web, una
página web especificada o cualquier otro recurso alojado en el servidor. A
continuación, se presentan dos principales tecnologías del lado del cliente.

5.2.5.1. Lenguaje de Marcado

En primer lugar, está HTML, por sus siglas en inglés “Hypertext Markup Language”,
que significa “Lenguaje de Marcado de Hypertexto” el cual es un lenguaje con el
que definen las páginas web que permite describir el contenido de una página,
incluyendo texto y otros elementos como, por ejemplo: (imágenes, videos,
pequeñas aplicaciones, etc.)

Cabe destacar que HTML no es un lenguaje de programación puesto que solamente

describe la estructura básica de una página y organiza la forma en que se mostrará
su contenido, dando, así como resultado únicamente páginas web estáticas. Sin
embargo, se puede usar con diferentes lenguajes de programación para la creación
de aplicaciones web.

5.2.5.2. CSS
En segundo lugar, CSS es el acrónimo de Cascading Styles Sheets (es decir, hojas
de estilo en cascada) este es un lenguaje de estilo que define la presentación de los
documentos HTML, abarca todo lo referente a fuentes, colores, márgenes, líneas,
alturas, anchura, imágenes, posicionamiento.

5.2.5.3. Lenguaje de Programación JavaScript

En tercer lugar, JavaScript “…es un lenguaje interpretado, basado en objetos (no
es un lenguaje orientado a objetos puro) y multiplataforma, inventado por
NETSCAPE COMMUNICATION CORPORATION” (Lujan,2002), el cual es usado
para crear pequeños bloques de código con una función específica dentro del
ámbito de una página web. Hay que destacar que su uso se basa fundamentalmente

30
en la creación de efectos especiales en las páginas y la definición de
interactividades con el usuario.

5.2.5.3.1. Librería JQUERY

También es importante mencionar que JQUERY es parte de las tecnologías cliente
para el diseño de aplicaciones y que es definida como “…una librería JavaScript
open-source, que funciona con múltiples navegadores” (Charte,2013) y cuyo
principal objetivo es hacer la programación “scripting” más fácil y rápida del lado del
cliente.

Asimismo, cabe destacar que haciendo uso de esta da la posibilidad de realizar

tareas complejas en JavaScript de una manera mucho más sencilla y es que provee
un conjunto de utilidades que ya han sido programadas y probadas para ser utilizada
permitiendo así lograr los mismos resultados que con JAVASCRIPT, pero en un
menor tiempo.

Otra ventaja de esta librería es la facilidad que brinda para trabajar con AJAX por
sus siglas en inglés (Asynchronous JavaScript And XML) que quiere decir que es
una técnica de desarrollo para crear aplicaciones interactivas, también conocida por
ser una tecnología asíncrona puesto que los datos se solicitan al servidor y se
cargan en segundo plano.

5.2.5.3.1.1. AJAX
A continuación, se define en su forma más simple que AJAX por sus siglas en inglés
(Asynchronous Javascript and XML) “…es una técnica que permite mediante
programas escritos en Javascript, que un Servidor y un navegador (cliente)
intercambien información, posiblemente en XML, de forma asíncrona”
(Charte,2013).

Se caracteriza principalmente por mejorar completamente la interacción del usuario

con la aplicación, evitando las recargas constantes de la página, puesto que el
intercambio de información con el servidor se produce en segundo plano.

5.2.5.4. Bootstrap
Según su sitio web oficial (https://getbootstrap.com/) Bootstrap se define como un
kit de herramientas de código abierto para desarrollar con HTML, CSS y JS. Permite

31
crear aplicaciones completa con una serie de variables y mixins de Sass, sistema
de cuadrícula sensible, componentes precompilados extensos y potentes
complementos basados en jQuery.

5.2.6. Bases de Datos

El termino base de datos los podemos definir como un conjunto estructurado de
datos registrados sobre soportes accesibles por ordenador para satisfacer
simultáneamente a varios usuarios de forma selectiva y en tiempo oportuno”,
(Delobel, 1982).

5.2.6.1. Tipos de Bases de Datos

5.2.6.1.1. Según la Variabilidad de Datos Almacenados
Las operaciones que pueden realizarse sobre una base de datos dependerán del
tipo de información que se encuentre almacenada en ella. Se clasifican en:

Estáticas: Los datos que contienen son de solo lectura. Se utiliza para almacenar
datos históricos, útiles para comparar el comportamiento de los mismos a través del
tiempo.

Dinámicas: Pueden realizarse diversas operaciones sobre los datos que contiene,
entre ellas: consulta, actualización, adición y eliminación.

5.2.6.1.2. Según su Contenido

Bibliográficas: Su contenido es solo una representación de la fuente primaria. La
información se utiliza como guía para conocer su ubicación. Por ejemplo: Sistema
bibliotecario.

Numéricas: Este tipo de bases de datos, solamente almacena datos numéricos,

por ejemplo: estadísticas, cálculos matemáticos, edades, etc…

Directorios: Son aquellos cuyo contenido está referido a la descripción de otros

recursos de información. Este tipo de bases de datos, son los directorios y agendas
que se encuentran en los organizadores electrónicos, tales como las direcciones
electrónicas y en archivos físicos como las agendas o directorios electrónicos.

Banco de Imágenes: Como su nombre lo indica, almacenan información en

distintos formatos compatibles con visores de imágenes, audio, video, multimedia.

32
5.2.6.2. Modelo de Bases de Datos
Un modelo de datos es básicamente una "descripción" de algo conocido como
contenedor de datos (algo en donde se guarda la información), así como de los
métodos para almacenar y recuperar información de esos contenedores. Los
modelos de datos no son cosas físicas: son abstracciones que permiten la
implementación de un sistema eficiente de base de datos; por lo general se refieren
a algoritmos, y conceptos matemáticos.

5.2.6.2.1. Bases de Datos Jerárquicas

Almacenan su información en una estructura jerárquica, representando los datos en
forma de árbol, donde un nodo padre de información puede tener varios hijos
(ramificaciones). El nodo que no tiene padres se llama nodo raíz y los nodos que no
tienen hijos se conocen como hojas. Este modelo es bastante útil cuando la cantidad
de información es pequeña. Por su estructura, no puede representar eficientemente
la redundancia de datos.

5.2.6.2.2. Base de Datos en Red

Los datos se representan como colecciones de registros y las relaciones entre los
datos se representan mediante conjuntos que son punteros en la implementación
física. Este sistema permite que un nodo tenga más de un padre. Esta característica
puede considerarse como una mejora al sistema jerárquico.

5.2.6.2.3. Base de Datos Relacional (Modelo Utilizado)

Un modelo de datos es una colección de herramientas conceptuales para la
descripción de datos, relaciones entre datos, semántica de datos y restricciones de
consistencia. El modelo E-R está basado en una percepción del mundo real
consistente en objetos llamados Entidades de Relaciones entre estos objetos.

Su idea fundamental es el uso de "relaciones". Estas relaciones podrían

considerarse en forma lógica como conjuntos de datos llamados "tuplas". Esto es
pensando en cada relación como si fuese una tabla que está compuesta por
registros (las filas de una tabla), que representarían las tuplas, y campos (las
columnas de una tabla).

La información puede ser recuperada o almacenada mediante "consultas" que

ofrecen una amplia flexibilidad y poder para administrar la información. Durante su

33
diseño, una base de datos relacional pasa por un proceso al que se le conoce como
normalización de una base de datos.
5.2.6.2.3.1. SGBD
Son las siglas que significan Sistema de Gestión de Bases de Datos; es un sistema
software que permite a los usuarios definir, crear, mantener y controlar el acceso a
los datos. Es el software que interactúa con los programas de aplicación del usuario
y con las bases de datos.

5.2.6.2.3.2. Consulta
Es una petición al SGBD para que procese un determinado comando SQL. Esto
incluye tanto peticiones de datos como creación de bases de datos, tablas,
modificaciones, inserciones, etc. Redundancia de los datos decimos que hay
redundancia de datos cuando la misma información es almacenada varias veces en
la misma base de datos. Esto es siempre algo a evitar, la redundancia dificulta la
tarea de modificación de datos, y es el motivo más frecuente de inconsistencia de
datos. Además requiere un mayor espacio de almacenamiento, que influye en
mayor coste y mayor tiempo de acceso a los datos.

5.2.6.2.3.3. Inconsistencia de los Datos

Sólo se produce cuando existe redundancia de datos. La inconsistencia consiste en
que no todas las copias redundantes contienen la misma información; la
inconsistencia tiene como resultado la dificultad de acceso a los datos.

5.2.6.2.3.4. Integridad de los Datos

Los valores de todos los datos almacenados en la base de datos deben satisfacer
ciertos tipos de restricciones de consistencia.

5.2.6.2.3.5. Entidad
Es una cosa u objeto en el mundo real que es distinguible entre todos los demás
objetos. Ej. Una persona, un carro, etc. Cada entidad tiene un conjunto de
propiedades, y los valores pueden identificar una entidad de forma unívoca; ej.
Número de cédula identifica a una persona de otra, la placa de un carro lo
identificará de cualquier otro.

34
5.2.6.2.3.6. Conjunto de Entidades
Conjunto de entidades del mismo tipo que comparten las mismas propiedades o
atributos. Ej. El conjunto de los alumnos matriculados en un centro escolar, podría
definirse como el conjunto de entidades alumno.

5.2.6.2.3.7. Atributo
Los atributos describen las propiedades que posee cada miembro de un conjunto
de entidades; cada entidad puede tener su propio valor para cada atributo.

5.2.6.2.3.8. Dominio
Conjunto de valores posibles para un atributo. Una fecha de nacimiento o de
matriculación tendrá casi siempre un dominio, aunque generalmente se usará el de
las fechas posibles. Por ejemplo, ninguna persona puede haber nacido en una fecha
posterior a la actual. Si esa persona es un empleado de una empresa, su fecha de
nacimiento estará en un dominio tal que actualmente tenga entre 16 y 65 años;
generalmente, los dominios nos sirven para limitar el tamaño de los atributos.

5.2.6.2.3.9. Relación
Una relación “es la asociación o conexión entre conjuntos de entidades”. Como
ejemplo de relación podemos mencionar lo siguiente: tenemos dos conjuntos:
alumnos y matrícula. Podemos encontrar una interrelación entre ambos conjuntos
a la que llamaremos posee, y que asocie una entidad de cada conjunto, de modo
que un alumno posea una matrícula.

5.2.6.2.3.10. Clave
Una clave permite identificar de un conjunto de atributos, suficiente para distinguirlas
entre sí de forma única.

5.2.6.2.3.10.1. Súper Clave

Conjunto de uno o más atributos, que tomados colectivamente, permiten identificar
de forma única cada entidad en el conjunto de entidades. Por ejemplo, el atributo
ID-estudiante es una súper clave ya que permite identificarlos de las otras
entidades, también lo es el conjunto de entidades ID-estudiante, nombre, apellidos,
ya que en su conjunto daría el mismo resultado.

35
5.2.6.2.3.10.2. Clave Candidata
Una característica que debemos buscar siempre en las claves es que contengan el
número mínimo de atributos, siempre que mantengan su función. Diremos que una
clave es mínima cuando si se elimina cualquiera de los atributos que la componen,
deja de ser clave. Si en una entidad existe más de una de estas claves mínimas,
cada una de ellas es una clave candidata. Es decir cada una de las claves mínimas
existente en un conjunto de entidades es una clave candidata. Clave principal(o
primaria) Es cuando se denota una clave candidata, por el diseñador de la base de
datos, como elemento principal para identificar las entidades dentro de un conjunto
de entidades. Si disponemos de varias claves candidatas no usaremos cualquiera
de ellas según la ocasión. Esto sería fuente de errores, de modo que siempre
usaremos la misma clave candidata para identificar la entidad. Claves de
interrelaciones para identificar interrelaciones el proceso es similar, aunque más
simple. Tengamos en cuenta que para definir una interrelación usaremos las claves
primarias de las entidades interrelacionadas. De este modo, el identificador de una
interrelación es el conjunto de las claves primarias de cada una de las entidades
interrelacionadas. Por ejemplo, en las tablas que se utilizarán para la elaboración
de este sistema se tendrá la matrícula y los datos generales de los estudiantes por
lo que las clave a relacionar deberá ser ID del estudiante.

5.2.6.2.3.11. Entidades Fuertes y Débiles

Entidad Fuerte, es una entidad cuya existencia no depende de ningún otro tipo de
entidad. Cada instancia de la entidad puede identificarse de manera unívoca
utilizando el atributo de la clave principal de dicha entidad; ejemplo podemos
identificar a un alumno de forma única de todos los demás con su nº de
identificación. Entidad Débil, es una entidad cuya existencia depende de algún otro
tipo de entidad. La característica de la entidad débil es que no podemos identificar
de manera unívoca utilizando solamente los atributos asociados con este tipo de
entidad. Por ejemplo, no podemos saber a quién pertenece una matrícula de
manera única solamente con el identificador de la matrícula, sino hasta que
utilizamos la relación con la entidad alumno, que es el identificador del alumno. A
menudo la clave de una entidad está ligada a la clave principal de otra, aún sin

36
tratarse de una interrelación. Por ejemplo, en la matrícula de un estudiante, que usa
la clave de los datos generales del estudiante y añade otros atributos como fecha
de nacimiento, sexo, nombres, apellidos. Decimos que la entidad matrículas una
entidad débil, en contraposición a la entidad estudiante, que es una entidad fuerte.
La diferencia es que las entidades débiles no necesitan una clave primaria, sus
claves siempre están formadas como la combinación de una clave primaria de una
entidad fuerte y otros atributos. Además, la existencia de las entidades débiles está
ligada o subordinada a la de la fuerte. Es decir, existe una dependencia de
existencia. Por ejemplo, hagamos la siguiente pregunta: ¿Cómo podríamos
matricular un estudiante sin sus datos generales? Por consiguiente, la matrícula
depende de los datos del estudiante, como si no dejaría de existir.

5.2.6.2.3.12. Dependencia de Existencia

Decimos que existe una dependencia de existencia entre una entidad, subordinada,
y otra, dominante, cuando la eliminación de la entidad dominante, conlleva también
la eliminación de la entidad o entidades subordinadas.

5.2.6.2.4. Bases de Datos Orientadas a Objetos

Este modelo es uno de las más recientes, almacena en la base tanto el estado
como el comportamiento del objeto. Algunas de las propiedades de este modelo
son: la encapsulación (para permitir ocultar la información al resto de objetos, para
impedir accesos incorrectos o conflictos); herencia (los objetos heredan
comportamiento dentro de una jerárquica de clases) y polimorfismo (permite que
una operación pueda ser aplicada a distintos tipos de objetos).

5.2.6.2.5. Bases de Datos Documentales

Permite realizar diferentes actividades sobre el texto, una de las más importantes
es la búsqueda de textos, que se puede realizar dentro de un documento.

5.2.7. Metodología Ágil de Desarrollo XP (Programación Extrema)

5.2.7.1. Introducción a XP
XP (Beck, 1999) 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 por el aprendizaje de los desarrolladores, y
propiciando un buen ambiente de trabajo. Se basa en retroalimentación continua

37
entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los
participantes, simplicidad en las soluciones implementadas y coraje para enfrentar
los cambios.

Cabe destacar, que es una opción adecuada para proyectos con requisitos
imprecisos y muy cambiantes, y donde existe un alto riesgo técnico. Esta
metodología resalta una serie de valores y principios que deben tenerse en cuenta
y practicarlos durante el tiempo de desarrollo que dure el proyecto.

A continuación, se detalla cada uno de esos valores y principios que juegan un papel
esencial en aquellos proyectos de desarrollo de software que emplean Xp como
guía.

5.2.7.2. Valores
Más que una metodología, XP se considera una disciplina, la cual está sostenida
por valores y principios propios de las metodologías ágiles. Existen cuatro valores
que cumplen un papel fundamental en el desarrollo de las metodologías livianas.

5.2.7.2.1. La comunicación
Es muy importante que exista un ambiente de colaboración y comunicación al
interior del equipo de desarrollo, así como en la interacción de éste con el cliente.
Un aspecto en particular de esta metodología es que el cliente es considerado como
parte del equipo de desarrollo debido a la constante interacción que sostendrá con
los desarrolladores.

5.2.7.2.2. La Simplicidad
Este valor se aplica en todos los aspectos de la programación extrema, desde
diseños sencillos donde lo más relevante es la funcionalidad necesaria que requiere
el cliente, hasta la simplificación del código mediante la refactorización del mismo.
Además, la programación extrema no utiliza sus recursos para la realizar
actividades complejas, puesto que únicamente se desarrolla lo que el cliente
demanda, en su forma más sencilla.

5.2.7.2.3. La retroalimentación
Este valor se presenta desde el comienzo del proyecto, ayuda a encaminarlo y darle
forma. También en los dos sentidos, es decir, por parte del equipo de trabajo hacia

38
el cliente, con el fin de brindarle información sobre la evolución del sistema, y desde
el cliente hacia el equipo en los aportes a la construcción del proyecto.

5.2.7.2.4. El coraje
Por último, el equipo de desarrollo debe estar preparado para enfrentarse a los
continuos cambios que se presentarán en el transcurso de la actividad. Asimismo,
cada integrante debe tener el valor de exponer los problemas o dudas que halle en
la realización del proyecto.

5.2.7.3. Prácticas
A partir de los valores se plantea una serie de prácticas que sirven de guía para los
desarrolladores en esta metodología. Una de los aspectos más importantes para
XP son las doce reglas que se plantean, las cuales se caracterizan por su grado de
simplicidad y por su enfoque en la practicidad, además de que cada regla se
complementa con las demás. A continuación, una breve descripción de cada una.

5.2.7.3.1. Desarrollo dirigido por pruebas

Antes de realizar una unidad de código, es necesario contar con su respectiva
unidad de pruebas. El programador realiza pruebas dirigidas al funcionamiento de
nuevas adiciones o módulos al sistema, además de esto el cliente con ayuda del
tester se encarga de diseñar las pruebas de aceptación, cuyo propósito es verificar
que historias de usuario se hayan implementado correctamente.

5.2.7.3.2. El juego de la planificación

Desde el comienzo del desarrollo se requiere que el grupo y el cliente tengan una
visión general y clara del proyecto, es decir, deben entender y estar de acuerdo con
lo que el otro plantee. En el transcurso del proyecto se realizan diferentes reuniones,
con el fin de organizar las tareas e ideas que surgen tanto por parte del cliente como
por el equipo.

5.2.7.3.3. Cliente in-situ

El cliente, o un representante del mismo, deben estar en el sitio de desarrollo para
solucionar las preguntas o dudas que se puedan presentar a medida que se realice
el proyecto.

39
5.2.7.3.4. Programación en parejas
Xp propone que exista una pareja de programadores por monitor y teclado, como
medida para aumentar la calidad del código. Con esta práctica se busca reducir los
errores de codificación, mientras uno de los programadores busca una forma de dar
funcionalidad a un módulo, el otro programador aprueba dicho código y busca la
forma de simplificarlo.

5.2.7.3.5. Entregas pequeñas

En la programación extrema se realizan entregas constantes de módulos
funcionales completos, de tal forma que en todo momento el cliente una parte de
aplicación funcionando. En XP no existe el desarrollo incompleto de una tarea, ésta
se ejecuta en su totalidad o no se hace.

5.2.7.3.6. Refactorización sin piedad

El código se revisa de forma permanente para depurarlo y simplificarlo, buscando
la forma de mejorarlo. La refactorización se realiza durante todo el proceso de
desarrollo.

5.2.7.3.7. Integración continúa del código

El código de los módulos debe ser integrado a cortos plazos de tiempo,
preferiblemente no mayores a un día. Esto facilita la búsqueda y la corrección de
errores de codificación e integración que se presenten en el proceso.

5.2.7.3.8. Diseño simple

Sólo se realiza lo necesario para que la aplicación cumpla con la funcionalidad
requerida por el cliente. No es conveniente realizar diseños complejos que
posiblemente no aporten soluciones claras al proyecto, y que a la hora de cambiar
los requerimientos se conviertan en una gran barrera de tiempo.
5.2.7.3.9. Utilización de metáforas del sistema
Para el mejor entendimiento de los elementos del sistema por parte del equipo de
desarrollo se acude a la utilización de metáforas, como una forma de universalizar
el lenguaje del sistema.

5.2.7.3.10. Propiedad colectiva del código

El código no es conocido por una sola persona del grupo de trabajo, esto facilita
implementar cambios al programa por parte de otros integrantes del equipo.

40
5.2.7.3.11. Convenciones de código
La aplicación de estándares de programación al código fuente de la aplicación,
permite que todas las cosas personas que conforman el grupo de trabajo puedan
entender y realizar modificaciones al código del sistema.

5.2.7.3.12. No trabajar horas extras

Es preferible volver a estimar los tiempos de entrega. Con esta práctica se busca
utilizar al máximo el rendimiento y energía del programador.

5.2.7.4. Alcance de XP
Ahora bien, por otra parte, la programación extrema es conveniente en ciertas
situaciones, pero también es necesario saber que presenta controversia en otras.
Esta metodología es aplicable con resultados positivos a proyectos de mediana y
pequeña envergadura, donde los grupos de trabajo no superan 20 personas.

Otro aspecto importante en la selección de esta metodología radica en el ambiente

cambiante que se presenta en los requerimientos de la aplicación. Xp está
encaminada hacia los desarrollos que requieren de cambios continuos en el
transcurso de un proyecto. Así pues, es recomendada para proyectos en los cuales
el costo de cambio no se incremente a medida que transcurre vida del mismo.

Por último, los trabajos realizados bajo esta metodología cumplen con lo
estrictamente necesario en su funcionalidad en el momento necesario: hacer lo que
se necesita cuando se necesita. Cuando se emplead programación extrema no
conviene precipitarse o adelantarse a las taras que se han establecido previamente
sin el consentimiento del cliente, estos hechos conllevan a inyectar complejidad al
sistema, alejándolo del concepto de simplicidad.

5.2.7.5. Fases de la programación extrema

5.2.7.5.1. Planeación
En primer lugar, se encuentra la planeación como etapa inicial en todo proyecto XP.
En este punto comienza a interactuar con el cliente y el resto del grupo de desarrollo
para descubrir los requerimientos del sistema. Aquí es donde se identifican el
número y tamaño de las iteraciones al igual que se plantean ajustes necesarios a la
metodología según las características del proyecto.

41
A continuación, se presentan ocho elementos a tenerse en cuenta dentro de esta
fase. Ellos se conforman por: Historias de Usuario, Velocidad de proyecto,
iteraciones, entregas pequeñas, reuniones, roles en XP, traslado del personal y
ajusto XP.

5.2.7.5.2. Historias de Usuario

Este elemento sugiere que el cliente es quien desarrolla el sistema, puesto que el
cliente es quien decide que hacer. Pero Como primer paso, se debe proporcionar
una idea clara de lo que será el proyecto en sí. También son utilizadas como
herramienta para dar a conocer los requerimientos del sistema al equipo de
desarrollo, su redacción se realiza bajo la terminología del cliente quien la describe
de forma clara y sencilla.

Análogamente las historias de usuario juegan un papel similar a los casos de uso
en otras metodologías, sin embargo, son en realidad diferentes. Estas muestran
solo la silueta de una tarea a realizarse. Por esta razón es fundamental que el
usuario o un representante del mismo se encuentran disponibles se encuentren en
todo momento para solucionar dudas, estas proporcionan información detallada
acerca de una actividad específica.

También son empleadas para estimar el tiempo que el que el equipo de desarrollo
tomará para realizar las entregas. En una entrega se puede desarrollar una o varias
historias de usuario, esto depende del tiempo que demore la implementación de
cada una de las mismas.

5.2.7.5.3. 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á (teóricamente) implementar el mismo número de
historias de usuario que en la iteración anterior.

Cabe recordar que la velocidad del proyecto ayuda a determinar la cantidad de

historias que se pueden implementar en las siguientes iteraciones, aunque no de
manera exacta. La revisión continua de esta métrica en el transcurso del proyecto

42
se hace necesaria, ya que las historias varían según su grado de dificultad, haciendo
inestable la velocidad de realización del sistema.

5.2.7.5.4. Iteraciones
En la metodología XP, la creación del sistema se divide en etapas para facilitar su
realización. Por lo general, los proyectos constan de más de tres capas, las cuales
toman el nombre de iteraciones, de allí se obtiene el concepto de metodología
iterativa. La duración ideal de una iteración es de una a tres semanas.

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

implementar. Al final de la iteración se obtiene como resultado la entrega del módulo
correspondiente, el cual debe haber superado las pruebas de aceptación que
establece el cliente para verificar el cumplimiento de los requisitos. Las tareas que
no se realicen en una iteración son tomadas en cuenta para la próxima iteración,
donde se define, junto al cliente, si se deben realizar o si deben ser removidas de la
planeación del sistema.

5.2.7.5.5. Entregas pequeñas

La duración de una iteración varía entre una y tres semanas, al final de la cual habrá
una entrega de los avances del producto, los cuales deberán ser completamente
funcionales. Estas entregas se caracterizan por que deben ser frecuentes.

5.2.7.5.6. 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.

5.2.7.5.7. Plan de entregas

Al comenzar el proyecto se realiza una reunión entre el equipo de trabajo y los
clientes. En dicha reunión se define el marco temporal de la realización del sistema.
El cliente exponer las historias de usuario a los integrantes del grupo, quienes
estimarán el grado de dificultad de la implementación de cada historia.

Las historias de usuarios asignados a las diferentes iteraciones según su orden de

relevancia para el proyecto. En el proceso de selección de las historias de usuario

43
para iteración, se tiene en cuenta que la suma de las estimaciones se aproximaba
a la velocidad del proyecto de la iteración pasada.

Además, en esta reunión se predicen los tiempos que se utilizaran en la realización

de las diferentes etapas del proyecto, los cuales no son datos exactos, pero
proporciona una base del cronograma.

Finalmente, a partir de las historias de usuario, el cliente plantea las pruebas de

aceptación con las cuales se comprueba que cada una de estas ha sido
correctamente implementada.

5.2.7.5.8. Inicial Iteración

Al comenzar una iteración se realiza una reunión de la misma, donde se organizan
las actividades de programación a realizar. Las historias de usuario son traducidas
a tareas y asignadas a los desarrolladores y estos estiman los tiempos para la
realización de las mismas. Estando en este punto las estimaciones son más exactas
que las realizadas en la planeación de entregas, por lo tanto, no deben exceder la
velocidad de proyecto de la iteración anterior.

De ser así, se consulta con el cliente para determinar que historias de usuario se
pospondrán para iteraciones futuras.

5.2.7.5.9. Roles XP
En esta metodología se utiliza el concepto de roles para organizar quienes se
encargarán de cada una de las actividades que deben realizarse en el transcurso
del proyecto. Cada uno de estos papeles son desempeñados por uno o varios
integrantes del grupo, sin descartar la posibilidad de rotar los roles entre el equipo
durante la realización del sistema.

El jefe de proyecto tiene como responsabilidad la dirección y organización de las

reuniones que se realizan durante el proyecto. Es erróneo afirmar que entre sus
tareas se encuentra decir que hacer, cuando hacer y de revisar cómo se desarrolla
el sistema, para ello se cuenta con el apoyo del cliente, el tracker y lo demás
miembros del grupo.

44
El usuario o cliente determina qué se va construir en el sistema, además de decidir
el orden en que se entregarán cada segmento del proyecto. Este, además, tiene
como tarea establecer las pruebas de aceptación, las cuales determinan si el
sistema cumple con los requerimientos del usuario.

Los programadores son quienes construyen el sistema y realizan las pruebas

correspondientes a cada módulo o unidad de código. Como en todo proceso de
desarrollo surgen diferentes dudas de lo que en realidad necesita el cliente, los
programadores no deben de hacer suposiciones respecto a esto, sino que deben
dirigirse al cliente y aclarar la situación.

El entrenador (coach) es el responsable de que el proceso se realice de forma

correcta. Se asegura de que los conceptos de la metodología se apliquen al
proyecto, además de brindar ayuda continua a los demás de integrantes del equipo.

El tester o quien realiza las pruebas, colabora en la realización de las pruebas de

aceptación y es quien muestra los resultados de las mismas, asimismo es quien
ayuda al cliente a diseñar tales pruebas y a verificar que las pruebas sean
aprobadas.

Por último, se encuentra el rastreador (tracker) el cual tiene como tarea observar la
realización del sistema, también cuestionar a los integrantes del equipo para anotar
sus logros y avances.

5.2.7.5.10. Traslado de personal

Al mover el personal se evitan problemas relacionados con la pérdida de
conocimiento y cuellos de botella, puesto que todos los miembros del grupo deben
tener suficiente conocimiento de la estructura del código de modo tal que se eviten
las islas de conocimiento las cuales son susceptibles de generar pérdidas de
información importante.

En la medida que todos los programadores entiendan todas las partes del programa
se evita que unos tengan carga de trabajo muy alta mientras que otros no tengan
mucho trabajo por hacer, además la programación en parejas se convierte en una
herramienta muy importante para lograr el objetivo del traslado de personal sin que

45
se pierda el rendimiento. Esto es posible haciendo que un miembro de la pareja se
traslade mientras que el otro continúe el desarrollo con un nuevo compañero.

5.2.7.5.11. Ajustar XP
Todos los proyectos tienen características específicas por lo cual XP puede ser
modificado para ajustarse bien al proyecto en cuestión. Al iniciar el proyecto debe
aplicarse XP tal como es, sin embargo, no se debe dudar en modificar aquellos
aspectos en que no funcione.

5.2.7.5.12. Diseño
En XP solo se diseñan aquellas historias de usuario que el cliente ha seleccionado
para la iteración actual por dos motivos: En primer lugar, 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.

Hay que destacar que esta tarea es permanente durante la vida del proyecto
partiendo de un diseño inicial que va siendo corregido y mejorado en el transcurso
del proyecto.

5.2.7.5.13. Simplicidad en el diseño

Una de las partes más importantes de la filosofía XP es la simplicidad en todos los
aspectos. Se considera que un diseño sencillo se logra más rápido y se implementa
en menos tiempo, por lo cual es lo que se busca. La idea es que se haga el diseño
más sencillo que cumpla con los requerimientos de las historias de usuario.

Por otro lado, acerca de los diagramas, claramente se pueden usar siempre y
cuando que no tome mucho tiempo en realizarlos, y que sean de verdadera utilidad.
En la programación extrema se prefiere tener una descripción del sistema o parte
de él, en lugar de una serie de complejos diagramas que probablemente tomen más
tiempo y sean menos instructivos.

5.2.7.5.14. Metáfora del Sistema

Se trata de plasmar la arquitectura de sistema en una historia con la cual se le dé al
grupo de desarrollo una misma visión sobre el proyecto además de brindarles un

46
primer vistazo muy completo a los nuevos integrantes del grupo para hacer su
adaptación más rápida.

Asimismo, es muy importante dentro del desarrollo de la metáfora darles nombres

adecuados a todos los elementos del sistema constantemente, y que estos
correspondan a un sistema de nombres consistente ya que esto será de mucha
utilidad en fases posteriores del desarrollo para identificar aspectos importantes del
sistema.

5.2.7.5.15. Tarjetas de clase, responsabilidad, colaboración (CRC Cards)

La principal funcionalidad que tienen estas, es ayudar a dejar el pensamiento
procedimental a para incorporarse al enfoque orientado a objetos. Cada tarjeta
representa una clase con su nombre en la parte superior, en la sección inferior
izquierda están descritas las responsabilidades y a la derecha las clases que le
sirven de soporte.

En el proceso de diseñar el sistema por medio de estas tarjetas como máximo dos
personas se ponen de pie adicionando o modificando las tarjetas, prestando
atención a los mensajes que éstas se transmiten mientras los demás miembros del
grupo que permanecen sentados, participan en la discusión obteniendo así lo que
puede considerarse un diagrama de clases preliminar-

5.2.7.5.16. Soluciones Puntuales (Spike Solution)

En muchas ocasiones los equipos de desarrollo se enfrentan a requerimientos de
los clientes (en este caso historias de usuario) los cuales generan problemas desde
el punto de vista del diseño o la implementación, sin embargo, gracias a Spike
Solution se puede abordar este inconveniente.

Esta herramienta consiste en una pequeña aplicación completamente

desconectada del proyecto con la cual se intenta explorar el problema y propone
una solución potencial, además puede ser burda y simple, siempre que brinde la
información suficiente para enfrentar el problema encontrado.

47
5.2.7.5.17. No solucionar antes de tiempo
En XP solo se analiza lo que se desarrollará en la iteración actual, olvidando por
completo cualquier necesidad que se pueda presentar en el futuro, lo que supone
uno de los preceptos más radicales de la programación extrema.

5.2.7.5.18. Refactorización (Refactoring)

Como se dijo al principio de este apartado, el diseño es una tarea permanente
durante la vida del proyecto y la refactorización concreta este concepto. Como en
cualquier metodología tradicional en XP se inicia el proceso de desarrollo con un
diseño inicial. Sin embargo, la diferencia es que en las metodologías tradicionales
este diseño es tan global y completo como se es posible tomando generalmente
mucho tiempo en lograrse y con la incertidumbre de que si hay una modificación
será un fracaso para el grupo de desarrollo.

Por el contrario, ocurre con XP puesto que se parte de un diseño muy general y
simple que no debe tardar en conseguirse, al cual se le hacen adiciones y
correcciones a medida que el proyecto avanza, con el fin de mantenerlo tanto
correcto como simple.

Ahora bien, la refactorización en el código pretende consérvalo tan sencillo y fácil

de mantener como sea posible. En cada inspección que se encuentre alguna
redundancia, funcionalidad no necesaria o aspecto en general por corregir, se debe
rehacer esa sección de código con el fin de lograr las metas de sencillez tanto en el
código en sí mismo como en la lectura y mantenimiento.

5.2.7.5.19. Codificación
La codificación es un proceso que se realiza en forma paralela con el diseño y la
cual está sujeta a varias observaciones por parte de XP consideradas
controversiales por algunos expertos tales como la rotación de los programadores
o la programación en parejas. Además de los mencionados temas, el lector
encontrará a continuación una descripción de los siguientes temas: cliente siempre
presente, codificar primero la prueba, integración secuencial e integraciones
frecuentes.

48
5.2.7.5.20. Cliente siempre presente
Uno de los requerimientos de XP es que el cliente esté siempre disponible, puesto
que juega un papel importante a la hora de solucionar las dudas del grupo de
desarrollo, considerándolo así parte de este. En este sentido se convierte en gran
ayuda al solucionar todas las dudas que puedan surgir, especialmente cara a cara,
para garantizar que lo implementado cubre con las necesidades planteadas en las
historias de usuario.

5.2.7.5.21. Codificar primero la prueba

Cuando se crea primero una 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. Asimismo, una de las ventajas de crear una prueba antes que el
código es que permite identificar los requerimientos de dicho código, es decir que al
escribir primero las pruebas se encuentran de una forma más sencilla y con mayor
claridad todos los casos especiales que debe considerar el código a implementar.

5.2.7.5.22. Programación en parejas

Todo el código debe ser creado por parejas de programadores sentados ambos
frente a un único computador lo que en principio representa una reducción de un
50% en productividad, sin embargo, según XP no es tal la pérdida. Debido a que no
hay mucha diferencia, en lo que a cantidad se refiere, entre el código producido por
una pareja bajo estas condicionas que el creado por mismos miembros trabajando
en forma separada, con la excepción que uno o ambos programadores sean muy
expertos en la herramienta en cuestión.

5.2.7.5.23. Integración secuencial

Uno de los mayores inconvenientes presentados en proyectos de software tiene que
ver con la integración, sobre todo si todos los programadores son dueños de todo
el código. Para saldar este problema han surgido muchos mecanismos, como darle
propiedad de determinadas clases a algunos desarrolladores, los cuales son los
responsables de mantenerlas actualizadas y consistentes.

Sin embargo, sumado al hecho que esto va en contra de la propiedad colectiva del
código no se solucionan los problemas presentados por la comunicación entre
clases. Xp propone que se emplee un esquema de turnos con el cual solo una pareja

49
de programadores integre a la vez. De tal forma se tiene plena seguridad de cuál es
la última versión liberada y se le podrán hacer todas las pruebas para garantizar
que funcione correctamente. A esto se le conoce como integración secuencial.

5.2.7.5.24. Integraciones frecuentes

Se deben hacer integraciones en periodos de tiempo pequeño y siempre que sea
posible no debe transcurrir más de un día entre una integración y otra. De esta se
garantiza surjan problemas como que un programador trabaje sobre versiones
obsoletas de alguna clase.

Es evidente que entre más se tarde en encontrar un problema más costoso será
resolverlo y con la integración frecuente se garantiza que dichos problemas se
encuentren más rápido o aún mejor, sean evitados por completo.

5.2.7.5.25. Estándares y propiedad colectiva del código

Así como se recomienda que la programación se haga siempre en parejas ubicadas
en un único computador, también se aconseja que estas se vayan rotando no solo
de compañero sino de partes del proyecto a implementar, con el fin de que se logre
tener una propiedad colectiva del código. Todos y cada uno de los programadores
tienen suficiente conocimiento del código de los demás de modo tal que en cualquier
momento puedan continuar la codificación que alguien más empezó sin que
represente un traumatismo para nadie.

Uno de los principales motivos por los que se promueve esta práctica dentro de la
programación extrema es la posibilidad que brinda de evitar los cuellos de botella.
Si una pareja de programadores se retrasa debido a inconvenientes no estimadas
pueden ser ayudados o reemplazados por otra pareja que al conocer el código no
tendrá que familiarizarse con él.

Para lograr lo anterior se recomienda el establecimiento de estándares en la

codificación, de modo tal que todo el código escrito por el grupo de desarrollo
parezca hecho por una sola persona. No se establecen los aspectos específicos a
tener en cuenta dentro de estos estándares, sin embargo, se aconseja que sean de
total de aceptación por parte del equipo.

50
5.2.7.6. Pruebas
La programación extrema enfatiza mucho los aspectos relacionados con las
pruebas, clasificándolas en diferentes tipos y funcionalidades específicas, indicando
quién cuándo y cómo deber ser implementadas y ejecutadas.

Del buen uso de las pruebas depende el éxito de otras prácticas, tales como la
propiedad colectiva del código y la refactorización. Cuando se tienen bien
implementadas las pruebas no habrá temor de modificar el código del otro
programador en el sentido que, si se daña alguna sección, las pruebas mostrarán
el error y permitirán encontrarlo, el mismo criterio se aplica a la refactorización.

Hay que señalar que uno de los elementos que podría obstaculizar que un
programador cambie una sección de código funcional es precisamente hacer que
este deje de funcionar, pero si se tiene un grupo de pruebas que garantice su buen
funcionamiento, este temor se mitiga en gran medida.

Según XP se debe ser muy estricto con las pruebas, sólo se deberá liberar una
nueva versión si esta ha pasado con el cien por ciento de la totalidad de las pruebas.
En caso contrario se empleará el resultado de estas para identificar el error y
solucionarlo con mecanismos ya definidos.

5.2.7.6.1. Pruebas unitarias

Estas se aplican a todos los métodos no triviales de todas las clases del proyecto
con la condición que no se liberará ninguna clase que no tenga asociada su
correspondiente paquete de pruebas. Uno de sus elementos más importantes es
que idealmente deben ser construidas antes que los métodos mismos,
permitiéndole al programador tener máxima claridad sobre lo que va a programar
antes de hacerlo, así como conocer cada uno de los casos de prueba que deberá
pasar, lo que optimizará su trabajo y su código será de mejor calidad.

Deben ser construidas por los programadores con el empleo de algún mecanismo
que permita automatizarlas de modo tal que tanto su implementación y ejecución
consuman el menor tiempo posible permitiendo sacarles el mejor provecho. El
empleo de pruebas unitarias completas facilita la liberación continua de versiones
por cuanto al implementar algo nuevo y actualizar la última versión, solo es cuestión

51
de ejecutar de forma automática las pruebas unitarias ya creadas para saber que la
nueva versión no contiene errores.

5.2.7.6.2. Pruebas de aceptación

Las pruebas de aceptación, también llamadas pruebas funcionales son
supervisadas por el cliente basándose en los requerimientos tomados de las
historias de usuario. En todas las iteraciones, cada una de las historias de usuario
seleccionadas por el cliente deberá tener una o más pruebas de aceptación, de las
cuales deberán determinar las cosas de prueba e identificar los errores que serán
corregidos.

Las pruebas de aceptación son pruebas de caja negra, que representan un

resultado esperado de determinada transacción con el sistema. Para que una
historia de usuario se considere aprobada, deberá pasar todas las pruebas de
aceptación elaboradas para dicha historia. Es importante resaltar la diferencia entre
las pruebas de aceptación y las unitarias en lo que al papel del usuario se refiere.

Mientras que en las pruebas de aceptación juega un papel muy importante

seleccionando los casos de prueba para cada historia de usuario e identificando los
resultados esperados, en las segundas no tiene ninguna intervención por ser de
competencia del equipo de programadores.

5.2.7.7. Cuando se encuentra un error

Al momento de encontrar un error debe escribirse una prueba antes de intentar
corregirlo. De esta forma tanto el cliente logrará tener completamente claro cuál fue
y dónde se encontraba el mismo como el equipo de desarrollo podrá enfocar mejor
sus esfuerzos para solucionarlo.

Si el error fue reportado por el cliente y este creó la correspondiente prueba de

aceptación junto al equipo de desarrollo, el programador encargado podrá a su vez
producir nuevas pruebas unitarias que le permita ubicar la sección la específica
donde el error se encuentra.

A continuación, se muestra una imagen que ilustra las fases de las fases de la
metodología de Programación Extrema.

52
5.2.8. Métricas de Desarrollo de Software
La metrica es la evaluacion del grado en que un sistema, componente o proceso
posee un atributo determinado. (por ejemplo, el numero promedio de errores que se
encuentran por revision o el numero promedio de errores que se encuentran por
unidad de prueba)

5.2.8.1. Métricas de proyecto webapp

El diseño de webapps incluye actividades técnicas y no técnicas que incluyen lo
siguiente: establecer la vista y sensación de la webapp, creando la distribución
estética de la interfaz de usuario, definiendo la estructura arquitectónica general,
desarrollando el contenido y la funcionalidad que residen en la arquitectura y plana.

5.2.8.1.1. Seguridad
Las webapps se han integrado mucho con bases de datos críticas, corporativas y
gubernamentales. Las aplicaciones de comercio electrónico extraen y después
almacenan información delicada para el cliente. Por estas y muchas otras razones,
la seguridad de las webapps tiene importancia capital en muchas situaciones. La
medida clave de la seguridad de una webapp y de su ambiente de servidor es su
capacidad para rechazar los accesos no autorizados o para detener un ataque
proveniente del exterior.

5.2.8.1.2. Disponibilidad
Aun la mejor webapp será incapaz de satisfacer las necesidades de los usuarios si
no se encuentra disponible. En sentido técnico, la disponibilidad es la medida
porcentual del tiempo que una webapp puede utilizarse. El usuario final común
espera que las webapps se hallen disponibles las 24 horas de los 365 días del año.

5.2.8.1.3. Escalabilidad
¿Una webapp y su ambiente de servidor pueden crecer para que manejen
100,1000,10000 o 100 000 usuarios? ¿La webapp y los sistemas con los que tiene
interfaz son capaces de manejar una variación significativa del volumen o su
respuesta se desplomará (o cesará), no basta construir una webapp exitosa.

5.2.8.1.4. Tiempo para llegar al mercado

Aunque el tiempo que toma llegar al mercado en realidad no es un atributo de la
calidad en el sentido técnico, sí lo es desde el punto de vista de la empresa. Es

53
frecuente que la primera webapp que llega a un segmento específico del mercado
obtenga un número desproporcionado de usuarios finales.

5.2.8.1.5. Pirámide del diseño de webapps

La webapps abarca seis diferentes tipos de diseño cada uno contribuye a la calidad
global de la web esto se puede ver por medio de la pirámide siguiente:

 Diseño d la Interfaz
 Diseño estético
 Diseño del contenido
 Diseño de la navegacion
 Diseño de la arquitectura
 Diseño de los componentes

5.2.9. Métricas para calidad de Software

La calidad de un sistema, aplicación o producto sólo es tan buena como los
requerimientos que describen el problema, el diseño que modela la solución, el
código que conduce a un programa ejecutable y las pruebas que ejercitan el
software para descubrir errores. Conforme el software se somete a ingeniería,
pueden usarse mediciones para valorar la calidad de los modelos de requerimientos
y de diseño, el código fuente y los casos de prueba que se crearon. Para lograr esta
valoración en tiempo real, las métricas de producto (capítulo 23) se aplican a fin de
evaluar la calidad de los productos operativos de la ingeniería del software en forma
objetiva, en lugar de subjetiva.

5.2.9.1. Medición de la Calidad

5.2.9.1.1. Facilidad de Uso
El calificativo "amigable con el usuario" se ha transformado universalmente en
disputas sobre productos de software. Si un programa no es "amigable con el
usuario", prácticamente está próximo al fracaso, incluso aunque las funciones que
realice sea valiosas. La facilidad de uso es un intento de cuantificar lo amigable que
puede ser con el usuario y se consigue medir en función de cuatro características

1. Destreza intelectual o física solicitada para aprender el sistema

54
2. El tiempo requerido para alcanzar a ser moderadamente eficiente en el uso del
sistema

3. Aumento neto de productividad sobre el enfoque que el sistema reemplaza

medida cuando alguien emplea la aplicación moderadamente y eficiente

4. Valoración subjetiva a veces obtenida mediante un cuestionario de la disposición

subjetiva de la disposición de los usuarios hacia el sistema.

55
5.3. Marco Conceptual
5.3.1. Sistema
Se puede definir un sistema como un conjunto de partes o elementos organizados
y relacionados que interactúan entre sí para lograr un objetivo. Los sistemas reciben
(entrada) datos, energía o materia del ambiente y proveen (salida) información,
energía o materia.
5.3.1.1. Sistema de información
Un sistema de información es un conjunto de elementos interrelacionados con el
propósito de prestar atención a las demandas de información de una organización,
para elevar el nivel de conocimientos que permitan un mejor apoyo a la toma de
decisiones y desarrollo de acciones. (Ayala, 2006).
5.3.2. Programación Extrema
La programación extrema es una metodología de desarrollo ágil que tiene como
principal objetivo aumentar la productividad a la hora de desarrollar un proyecto
software.
5.3.4. Cliente
Programa ejecutable que participa activamente en el establecimiento de
las conexiones. Envía una petición al servidor y se queda esperando por una
respuesta. Su tiempo de vida es finito una vez que son servidas sus solicitudes,
termina el trabajo.
5.3.5. Servidor
Es un programa que ofrece un servicio que se puede obtener en una red. Acepta la
petición desde la red, realiza el servicio y devuelve el resultado al solicitante. Al ser
posible implantarlo como aplicaciones de programas, puede ejecutarse en cualquier
sistema donde exista TCP/IP y junto con otros programas de aplicación. El servidor
comienza su ejecución antes de comenzar la interacción con el cliente.
5.3.6. Base de datos
Una base de datos es una colección de información organizada de tal modo que
sea fácilmente accesible, gestionada y actualizada.
5.3.7. Plataforma .NET
La plataforma .NET se define como un conjunto de tecnologías para desarrollar y
utilizar componentes que nos permitan crear formularios web, servicios web y
aplicaciones Windows.

56
5.4. Marco Legal
Le centro escolar Bautista Libertad de la ciudad de Managua se rige bajo la Ley de
educación del gobierno de Nicaragua, la cual se detalla en la constitución política y
se presenta a continuación:

LEY GENERAL DE EDUCACIÓN

LEY No. 582, Aprobada el 22 de Marzo del 2006
Publicado en La Gaceta No. 150 del 03 de Agosto del 2006
EL PRESIDENTE DE LA REPÚBLICA DE NICARAGUA
Hace saber al pueblo nicaragüense que:
LA ASAMBLEA NACIONAL DE LA REPÚBLICA DE NICARAGUA

CAPÍTULO VII
DE LAS INSTITUCIONES EDUCATIVAS DEL SISTEMA

Centros Educativos Públicos

Arto. 50.- En los Centros Educativos Públicos, no se podrá llevar a cabo, ni
promover ningún tipo de actividad político-partidista, ni religiosa. El Estado ejercerá
supervisión de los centros educativos dentro de los términos que se fijen en los
reglamentos respectivos.

Arto. 51.- El Ministerio de Educación, Cultura y Deportes (MINED), establecerá los

requisitos mínimos de infraestructura, pedagogía, administración, financiamiento y
dirección que deben cumplir los centros educativos públicos y privados de la
educación inicial, general básica, media, especial y formación docente para
autorizar su funcionamiento y para su posterior certificación y el Instituto Nacional
Tecnológico (INATEC), tendrán iguales facultades en relación con los centros y
programas integrados en el subsistema de educación técnica y profesional.

Centros Educativos Privados

Arto. 52.- Las Instituciones Educativas Privadas son personas jurídicas de derecho
privado, creadas por iniciativa de personas naturales o jurídicas, autorizadas por las
instancias de cada subsistema educativo. El Estado en concordancia con la libertad
de enseñanza, el derecho de aprender y la promoción de la pluralidad de la oferta
educativa, reconoce, valora y supervisa la educación privada.

57
Centros Educativos Subvencionados

Arto.53.- Centros subvencionados son colegios con infraestructura educativa

privada que reciben transferencia de fondos por parte del Estado, para el pago de
salarios de docentes, quienes serán considerados como personas que laboran al
gobierno.

Se transfiere al Ministerio de Educación, Cultura y Deportes la obligación de pagar

en concepto de salario, vacaciones y treceavo mes, a los educadores de dichos
centros de enseñanza.

Arto. 54.- Los Centros Subvencionados para gozar de este reconocimiento

económico deberán de cumplir las disposiciones legales o administrativas dictadas
por las autoridades correspondientes. Los centros que ya gozan de la subvención,
al entrar en vigencia esta ley, mantendrán la misma. El MINED solo podrá
suspender la subvención si se comprueba violación a normas y procedimiento
acordado entre las partes.

El Gobierno deberá incluir en el Presupuesto General de la República una partida

presupuestaria para cubrir el costo de salario, vacaciones y treceavo mes de los
educadores de dichos centros de enseñanza, incluyendo al personal administrativo.

El Estado en concordancia con la libertad de enseñanza y el derecho de aprender,

reconoce, valor y supervisa la educación en los centros subvencionados.

Arto. 55.- Las instalaciones de los Centros Privados Religiosos de Educación y sus
respectivos predios destinados, exclusivamente al servicio de la educación, que
tuvieren problemas legales con personas particulares serán traspasadas a Título
Gratuito a favor de los respectivos Centros Privados Religiosos, libre de toda
contribución fiscal y municipal. El Estado subsanará a los particulares afectados.
Esta medida también se aplicará cuando los terrenos sean propiedad del estado o
de las municipalidades.

58
6. Hipótesis
A través, del desarrollo e implementación de una Aplicación Web se optimizará la
gestión en los procesos de Matrícula, registro de calificaciones y control de pagos
del Colegio Bautista Libertad, de manera que los servicios brindados sean eficientes
y que la información procesada sea pertinente para correcta toma de decisiones.
CAPÍTULO 3
7. Diseño Metodológico
7.1. Tipo de Investigación
De acuerdo a la naturaleza del problema planteado, el presente estudio es de tipo
descriptivo, explicativo y de campo:

Un estudio descriptivo, porque se analizará y describirá la deficiencia en la

gestión de los procesos tales como: Matrícula, registro de notas (parciales,
semestrales y finales), control de pagos, con lo cual se medirá, evaluara y se
recolectara datos sobre la información requerida, específicamente para el Sistema
de Información Web y sobre que o quienes se recolectaran los datos.

Un estudio explicativo porque se buscó las evidencias de las causas que

provocaron realizar el estudio, es decir, el porqué de la realización del desarrollo de
la Aplicación Web para el área de Secretaría Académica del Colegio Bautista
Libertad.

Un estudio de campo porque se realizó en un lugar determinado que sería el

Colegio Bautista Libertad, específicamente en el área de Secretaría Académica, la
cual es responsable de realizar las actividades que se pretende automatizar; por
consiguiente, en esta área se realizará el levantamiento de la información con el
objetivo de comprender la lógica de negocio que aplican en la realización de las
actividades que se pretenden analizar y automatizar.

Un estudio aplicativo, porque se implementó una herramienta tecnológica

(Aplicación Web) para la solución y automatización de los procesos que se llevan a
cabo en la secretaria académica del centro escolar Bautista Libertad, la cual se
desarrolló haciendo uso de los conocimientos sobre programación adquiridos a lo
largo de la carrera.

7.2. Descripción Población de Estudio

Para poder determinar la población de estudio, se tiene que definir la unidad de
análisis, es decir que es lo que se pretende medir, por lo tanto, es necesario precisar
claramente el problema y los objetivos de la investigación; de esta forma, tomando

60
en cuenta a los implicados en los procesos de registro académico se puede definir
lo siguiente:

• Universo: Colegio Bautista Libertad de Managua

• Campo de Acción: Área de Secretaría Académica

• Objeto de Estudio: Procesos de registro académico (Matrícula, Carga

Académica, Control de Notas)

• Integrantes Internos: Personal de Secretaría Académica (Directora,

Secretaría, Docentes)

• Integrantes Externos: Padres de Familia, Estudiantes.

7.2.1. Población de Estudio

 Directora
 Secretaria
 Docentes
 Estudiantes

7.2.2. Muestra
Se calculará una muestra de tipo probabilística, donde todos los elementos de la
población tienen la misma posibilidad de ser escogidos, sea tanto personal de
secretaría académica como estudiantes, los cuales serán un conjunto de personas
representativas de la población universo. Lo anterior nos servirá para conocer qué
es lo que esperarían del sistema de registro académico web.

7.3. Tipo de Método de investigación a aplicar

El método de investigación de este estudio es de tipo inductivo puesto que de casos
particulares se ha tomado la opinión para conocer lo que se desea y espera con el
desarrollo de un sistema de registro académico web.

7.4. Técnicas de recolección de datos

Fuentes primarias:

1. Entrevistas a personal que pertenece al área de secretaría académica.

61
 2. Observación de los procesos tanto de matrícula, registro de notas y de control
de pagos.

Fuentes secundarias:

Representada por toda la documentación proporcionada por el centro educativo

como formatos de matrícula, archivos de Excel para el control de notas de los
estudiantes, fichas de la carga académica de cada docente, etc, así como todos los
recursos encontrados en internet relacionados al tema en estudio.

7.5. Procedimiento para la recolección de información

Para la recolección de información en base a lo anterior se ocuparán métodos
interactivos, así como no intrusivos.

• Los métodos interactivos que aplicaremos serán la entrevista y la aplicación

de encuestas mediante cuestionarios.

• Los métodos no intrusivos que aplicaremos serán investigación y la

observación.

Los pasos que se pretenden llevar para la planeación de la entrevista son:

1. Establecer los objetivos de la entrevista: Los objetivos que se pretende

plantear estarán relacionados en conocer la lógica de negocio de las
actividades que se pretenden automatizar.
2. Decidir a quién entrevistar: Las entrevistas se van enfocar al área de
secretaría académica, a los implicados en los procesos de registro
académicos (Directora, Secretaria, Docentes y Estudiantes).
3. Decidir el tipo de preguntas y la estructura: Se ocuparán preguntas
abiertas (para concederle al entrevistado opciones libres para responder),
preguntas cerradas (para limitar al entrevistado en sus opciones de
repuestas) y sondeos.

Encuestas: Estas estarán formada por un cuestionario bien diseñado cuyo objetivo
será conocer el punto de vista de los usuarios finales y la aceptación de la

62
aplicación. Las preguntas que integren el cuestionario serán sencillas, especificas,
cortas en su mayoría de selección múltiple, técnicamente precisas y escritas con un
nivel de lectura apropiado.

Investigación: Investigar todos aquellos procedimientos, formatos, formularios,

archivos, libros digitales, reportes o información que estén relacionados a las
actividades que se pretenden automatizar y las tecnologías a aplicar.

Observación: Para determinar de una manera rápida el flujo de trabajo del área de
secretaría académica, así como el ambiente del centro.

63
7.6. Herramientas de desarrollo
Para el desarrollo de la Aplicación Web de Matrícula registro de notas y control de pagos se emplearán las siguientes
herramientas:

Imagen de Herramientas de Desarrollo de la aplicació

7.7. Operacionalización de Variables

Variable Independiente Definición Indicadores Técnicas Unidades de

Operacional Observación
Desarrollo e Es el proceso que Procesos Observación Docentes y
Implementación de una consiste en una serie Automatizados. personal de oficina.
Aplicación Web. de etapas para darle
solución a una
problemática, a
través de un conjunto
de recursos
informáticos
produciendo como
resultado una
herramienta
automatizada para
ser empleada por
usuarios finales.

Variable Dependiente Definición Indicadores Técnicas Unidades de

Operacional Observación
Caracterizar el proceso de Proceso por medio Los procesos de Observación y Docentes y
matrícula, registro de del cual se recolecta matrícula, control de Entrevista personal de oficina.
calificaciones y control de la información pago y registro de
pagos, a través de la necesaria de las calificaciones se
implementación de los diversas tareas que realizan de manera
mecanismos necesarios se realizan en la manual
para la coordinación entre secretaria
dichos módulos. académica, para dar
paso al diseño de la
aplicación

Variable Dependiente Definición Indicadores Técnicas Unidades de

Operacional Observación
Seleccionar una En este proceso se Aceptación de Documentación Programadores.
herramienta tecnológica toman en cuenta herramientas óptimas
que mejor se adecue a la todas las posibles para el desarrollo de la
capacidad económica, herramientas aplicación
infraestructura, recursos tecnológicas que se
humanos, para el podrían implementar,
desarrollo de la Aplicación seleccionando
Web aquella que mejor se
adapte a las
necesidades

66
Variable Dependiente Definición Indicadores Técnicas Unidades de
Operacional Observación
Diseñar la Aplicación web Este proceso se  Proteger la Análisis y Docentes y
que optimice los procesos refiere a la información observación personal de
de matrícula, control de codificación de los  Verificar accesos de oficina.
pago y control de nota del diferentes módulos usuarios a la
colegio Bautista Libertad, que interactúan para aplicación
de igual modo que permita darle funcionamiento  Facilidad de uso
generar reportes que a la aplicación  Generar reportes
sirvan de apoyo en la toma
de decisiones.

Variable Dependiente Definición Indicadores Técnicas Unidades de

Operacional Observación
Evaluar la calidad de la En este proceso se Detección de errores y Pruebas Programador y
Aplicación Web evalúa el producto tiempo de respuesta de secretaria
desarrollada aplicando final la calidad de la la aplicación académica
métricas de proyecto aplicación en cuanto
a su manejo y

67
webapp y Facilidad de Uso errores que se
al producto software. puedan producir

68
7.8. Presupuesto
A continuación se detallara el costo que implico el desarrollo de la aplicación web:
Recolección de información:
Detalles Costo
Papelería para encuestas $30
Transporte $20
Gastos de fotocopias $30
Salario Encuestadores $150
Total $230

Desarrollo de la Aplicación:
Detalle Costo
Salario programadores $600
Licencias de aplicaciones utilizadas $300
Pago de servicios para pruebas de la $65
aplicación en línea
Pago de Tester $100
Total $1065

Implementación de la aplicación
Detalles Costo
Pago de Hosting $15
Pago de Certificación SSL $20
Servicios de Internet $60
Capacitación del personal $300
Mantenimiento de la aplicación $200
Total $595

Equipos utilizados (Depreciación)

Detalle Costo
Laptop Hp Envy DV 7 $50
DELL PowerEdge T20 Escritorio $50
Laptop Toshiba $50
Total $150
Documentación Entregada
Detalles Costo
Impresión documentación del Sistema $30
Impresión manual de Usuario $60
Total $90

Compras Extras
Detalle Costo
Disco duro externo 3 terabytes $135
UPS forza 750VA NT-751D $43
Total $178

70
7.9. Aplicando Métricas
Facilidad de Uso
Si un programa no es fácil de usar, con frecuencia está condenado al fracaso,
incluso si las funciones que realiza son valiosas.
APGA proporciona interfaces las cuales suelen ser amigables con los clientes, en
el test de la aplicación los clientes determinaron que la aplicación cuenta con
interfaces amigables y fáciles de usar, por lo tanto cuenta como una medición de
calidad apta para su determinado uso.
Métricas de proyecto webapp aplicadas al APGA
El objetivo de todos los proyectos webapp es entregar al usuario final una
combinación de contenido y funcionalidad. Las medidas y métricas usadas para este
proyecto tradicionales de ingeniería del software son difíciles de traducir
directamente a webapps. Sin embargo, es posible desarrollar una base de datos
que permita el acceso a medidas productivas y calidad internas derivadas de
algunos proyectos. Entre las medidas que pueden recopilarse están:
Número de páginas web estáticas: 6
Número de páginas web dinámicas: 7
Número de vínculos de página internos: 9
Número de sistemas externos puestos en interfaz: 0
Número de objetos de contenido estáticos: 6
Número de objetos de contenido dinámicos: 4
Número de funciones ejecutables: 1
El Índice de personalización, C es:
Npe: Número de páginas Estáticas
Npd: Número de páginas dinámicas
C: (Npd) / (Npd+Npe)
C: 7 / (7+6)
C: 0.53
El valor de C varía de 0 a 1. Conforme C se hace más grande, el nivel de
personalización de la webapp se convierte en un problema técnico considerable.

71
CAPÍTULO 4
8. Análisis y Discusión de los Resultados

Durante el primer encuentro con la Secretaria Académica del centro nos plantearon
sus principales problemáticas relacionadas con los procesos administrativos y
financieros, de esta manera se levantaron los requerimientos y en base a los cuales
se determinaron los módulos que debía llevar la Aplicación web para matrícula,
registro de notas y control de pagos los cuales son:

 Administración Académica
 Carga Académica
 Matrícula
 Gestión de Notas
 Control de Pagos
 Gestión de Seguridad

Para esto al reunirnos con el usuario se han definido las siguientes historias
de usuario.

Historias de Usuario

A continuación, se detalla un listado de las historias de usuarios para la Aplicación

Web de Matrícula, registro de notas y control de pagos.

 Seguridad del sistema

 Creación de periodos lectivos
 Creación de Cortes académicos
 Creación de Periodos de matrícula
 Creación de Turnos
 Creación de Grados
 Creación de Secciones
 Asignación de Carga Académica.
 Generación de matrícula

72
  Gestión de matrículas
 Registro de Notas
 Consulta de Notas
 Realizar nuevos pagos
 Gestión de pagos
 Creación de Usuarios
 Creación de Roles
 Inicio de Sesión
 Recuperación de Contraseña
 Control de accesos con Bitácora
 Generación de Reportes

Metáfora del Sistema de Gestión de Presupuestos.

El Colegio Bautista Libertad registra las matrículas y los datos de cada estudiante
en hojas tamaño legal con un seria de campos cada año, una hoja de matrícula
puede ser anulada por varias razones ya sea porque el alumno se retira o por que
sea expulsado; los registros de notas son responsabilidad de cada docente y lo
hacen para cada grupo asignado. Los docentes a partir de los registros de notas
tienen que generar tres tipos de reportes para entregarlos a dirección los cuales son
registrados en el libro de actas enviado al MINED.

Estos reportes son una boleta de calificaciones que es generada por Parcial en la
cual se reflejan las notas por cada estudiante, reporte de Sabana de calificaciones
que es un compendio por cada grupo con las notas por cada clase de todos los
estudiantes y por último una estadística que contiene porcentaje de aprobados,
reprobados etc.

En cuanto al control de pagos, la secretaría del centro educativo es quien lleva el

control a través de recibos los cuales tienen un código y a través del mismo en una
hoja de Excel se realizan las sumas de las cantidades reflejadas en los recibos para
de esa forma totalizar. La secretaría emite reportes de los alumnos que están
retrasados en sus pagos para así orientar a los docentes a que alumnos no emitirán
su boleta de calificaciones.
73
CICLO DE VIDA DE LA APLICACIÓN DE MATRICULA, REGISTRO ACADEMICO
Y CONTROL DE PAGOS.

Primera Iteración

Para esta iteración se han desarrollado los módulos de Administración

Académica, Carga Académica, para esto se han utilizado y aplicado las
herramientas que destaca la metodología XP.

A continuación, se muestra un resumen de las herramientas desarrolladas

en esta iteración; en la sección de Anexos del documento se detallada cada
una de dichas herramientas.

Historias de usuario

Tabla 1. Historias de usuario de la primera iteración

Número Nombre
1 Gestión de Periodos lectivos
2 Gestión de Cortes académicos
3 Gestión de Grados Académicos
4 Gestión de Secciones
5 Gestión de Docentes
6 Gestión de Carga Académica

Tareas de Ingeniería

Tabla 2. Tareas de ingeniería de la Primera iteración

Numero Número Nombre de la Tarea

de Tarea de
Historia
1 1 Codificación del modelo y controlador de los
periodos lectivos.
2 1 Diseño de la Vista de los periodos lectivos.
3 2 Codificación del modelo y controlador de los
cortes académicos.

74
 4 2 Diseño de la Vista de los cortes académicos.
5 3 Codificación del modelo y controlador de
Grados académicos.
6 3 Diseño de la vista de las Grados.
7 4 Codificación del modelo y controlador de las
secciones.
8 4 Diseño de la vista.
9 5 Codificación del modelo y controlador de
docentes.
10 5 Diseño de la interfaz de docentes.
11 5 Codificación para asociar docente creado con
usuario del sistema.
12 6 Codificación del modelo y controlador de
Carga Académica.
13 6 Diseño de la interfaz de la carga académica

Pruebas de Aceptación

Tabla 3. Pruebas de aceptación de la primera iteración

Numero Número Nombre de la Prueba

de de
Prueba Historia
1 1 Creación y edición de Periodos Lectivos.
2 1 Listado de Periodos Lectivos
3 1 Suspensión de periodos lectivos.
4 2 Creación y edición de Cortes Académicos.
5 2 Listado de cortes de académicos
6 2 Suspensión de cortes académicos
7 3 Creación y edición de grados académicos
8 3 Listado de grados académicos
9 3 Suspensión de grado académico
10 4 Creación y edición de secciones

75
11 4 Listado de secciones
12 4 Suspensión de sección
13 5 Creación y edición de docentes
14 5 Listado de docentes
15 5 Suspensión de docentes
16 5 Acceso al sistema con Rol de docente
17 6 Creación de carga académica

Resultados de la Primera Iteración

Imagen 1. Pantalla Catálogo de Periodos Académicos

76
Imagen 2. Bosquejo de la pantalla de Gestión Académica

Imagen 3. Bosquejo de la pantalla de Gestión de Secciones

77
Imagen 4. Listado de Secciones

Imagen 5. Grado Académico

78
Imagen 6. Listado de Grados Académicos

Imagen 7. Listado de Docentes

79
Imagen 8. Nuevo Docente

80
Segunda Iteración

Para esta iteración se han desarrollado los módulos de Gestión de Pagos,

gestión de Matrículas.

A continuación, se muestra un resumen de las herramientas desarrolladas

en esta iteración; en la sección de Anexos del documento se detalla cada
una de dichas herramientas.

Historias de usuario

Tabla 4. Historias de usuario de la Segunda iteración

Número Nombre
1 Gestión de Control de Pagos
2 Comprobante de Pago
3 Generación de Matrícula de Nuevo Ingreso
4 Generación de Matrícula de Reingreso
5 Comprobante de Matrícula

Tareas de Ingeniería

Tabla 5. Tareas de ingeniería de la Segunda iteración

Numero Número Nombre de la Tarea

de Tarea de
Historia
1 1 Codificación del modelo y controlador de la
gestión de pagos.
2 1 Diseño de la Vista de la Gestión de Pagos.
3 2 Diseño del Comprobante de pago.
4 3 Codificación del modelo y controlador de
matrícula de nuevo ingreso.

81
 5 3 Diseño de la vista de la matrícula de nuevo
ingreso.
6 5 Diseño de comprobante de matrícula de
nuevo ingreso.
7 4 Codificación del modelo y controlador de
matrícula de reingreso.
8 4 Diseño de la vista de matrícula de reingreso.
9 5 Diseño de comprobante de matrícula
reingreso.

Pruebas de Aceptación

Tabla 6. Pruebas de aceptación de la Segunda iteración

Numero Número Nombre de la Prueba

de de
Prueba Historia
1 1 Registro de Nuevo de Pago.
2 1 Reporte generado por nuevo pago.
3 3 Registro de Estudiante de Nuevo Ingreso.
4 4 Registro de Matrícula de Estudiante de
reingreso.
5 5 Hoja de matrícula generada por matrícula de
nuevo y reingreso

82
Resultados de la Segunda Iteración

Imagen 9. Matrícula de Nuevo Ingreso

83
Imagen 10. Matrícula de Nuevo Ingreso
(Pestaña “Datos Personales Alumno”)

Imagen 11. Matrícula de Nuevo Ingreso

(Pestaña “Datos del Padre”)

84
Imagen 12. Matrícula de Nuevo Ingreso
(Pestaña “Datos de la Madre”)

Imagen 13. Matrícula de Nuevo Ingreso

85
(Pestaña “Datos del Tutor”)

Imagen 14. Matrícula de Nuevo Ingreso

(Pestaña “Datos Académicos”)

86
Imagen 15. Matrícula de Reingreso (Pestaña “Comprobar Pago”)

Imagen 16. Matrícula de Reingreso (Pestaña “Buscar Estudiante”)

Imagen 17. Matrícula de Reingreso (Pestaña “Datos Académicos”)

87
Imagen 18. Listado de Matrículas

Imagen 19. Reporte de matriculados por grupo

88
Imagen 20. Reporte de Carga Académica por grupo

Imagen 21. Reporte de Total de Matriculados por grupo

89
Imagen 22. Control de Pagos

Imagen 23. Confirmar Pago

90
Imagen 24. Comprobante de Pago

91
Imagen 25. Comprobante de Matrícula

92
Tercera Iteración

Para esta iteración se han desarrollado los módulos de Registro de Notas y

Gestión de Seguridad.

A continuación, se muestra un resumen de las herramientas desarrolladas

en esta iteración; en la sección de Anexos del documento se detallada cada
una de dichas herramientas.

Historias de usuario

Tabla 7. Historias de usuario de la Tercera iteración

Número Nombre
1 Registro de Notas
2 Verificación de Notas
3 Reporte de Notas por Grupo
4 Gestión de Seguridad

Tareas de Ingeniería

Tabla 8. Tareas de ingeniería de la Tercera iteración

Numero Número Nombre de la Tarea

de Tarea de
Historia
1 1 Codificación del modelo y controlador del
registro de Notas.
2 1 Diseño de la Vista del Registro de Notas.
3 2 Codificación y Controlador de la verificación
de Notas.
4 3 Codificación del Procedimiento almacenado
para reporte.
5 3 Diseño del reporte de notas.

93
 6 4 Codificación de los modelos y controladores
de seguridad.
7 5 Diseño de la vista para agregar nuevos
usuarios.
Pruebas de Aceptación

Tabla 9. Pruebas de aceptación de la Tercera iteración

Numero Número Nombre de la Prueba

de de
Prueba Historia
1 1 Registro de Notas por grupo y asignatura de
cada alumno.
2 2 Consulta de las notas registradas por grupo
asignado de cada docente.
3 3 Reporte de Notas de cada grupo.
4 4 Registro de Usuarios y Roles de Seguridad.
5 4 Verificación en Dos Pasos para acceso al
sistema.
6 4 Recuperación de Contraseña vía Correo
Electrónico y Celular.

94
Resultados de la Tercera Iteración

Imagen 26. Registro de Notas

95
Imagen 27. Consultar Notas

Imagen 28. Hoja de Calificaciones

96
Imagen 29. Registro de Usuario del Sistema

Imagen 30. Recuperación de Contraseña vía correo electrónico

97
Imagen 31. Inicio de Sesión

98
Evaluación de la Aplicación
Cada resultado de las iteraciones ha sido presentado al personal que hará uso de
la aplicación y para poder tener una mejor retroalimentación se elaboró y se empleó
una encuesta en línea siguiendo ciertas métricas que orientan para conocer el grado
de aceptación respecto a la experiencia de cada usuario, entre las cuales se
encuentran la funcionalidad, la usabilidad y facilidad de uso.

En su mayoría de los encuestados fueron usuarios con Rol de Docente

99
100
101
Resultados de la Encuesta Respecto al Diseño de la Aplicación

Se puede observar a partir de las gráficas que la aceptación de los usuarios

encuestados respecto al diseño es bastante positiva. Puesto que el 60% considera
que el tipo de fuente que presenta la aplicación en el diseño es apropiado, así como
también su tamaño siendo apreciable con un 60.6% y un 52.9% aprueba los colores
y sobre todo un 54.3% aprueba el diseño de forma general y un 100% afirma que el
diseño se ajusta a sus labores.

102
103
104
105
106
Resultados de la Encuesta Respecto a la Funcionalidad de la Aplicación

Se puede observar a partir de las gráficas que la aceptación de los usuarios

encuestados respecto a la funcionalidad es muy positiva. Puesto que el 42.9%
califica como “Excelente” los tiempos de respuesta al solicitar información y un
48.6% también califica de “Excelente” el tiempo de respuesta al generar, asimismo
los usuarios califican la Fiabilidad de la aplicación como “Muy Fiable” con 54.3% y
también el 97.1% de los encuestados afirma que la aplicación presenta
consistencia, el 100% cree que los mensajes presentados por la aplicación al
registrar de forma errónea un formulario son “acertados”, y por otro lado muy
importante que es la seguridad el 54.3% califica de “Muy Buena” la seguridad al
acceder a la aplicación y para finalizar un 48.6% de los usuarios califica de “Muy
Buena” en términos generales el desempeño de la aplicación.

Como objetivo principal al haber ejecutado dicha encuesta se espera conocer la

aceptación de los usuarios al usar la aplicación tanto por el diseño y sobre todo por
el funcionamiento. Se tomó como muestra personal de la secretaría académica con
varios de los roles que el sistema admite siento un total de 35 encuestados entre
docentes y personal administrativo.

107
CAPÍTULO 5
10. Recomendaciones
Dada la investigación y análisis de resultados se recomienda:

 Dar mantenimiento constante al sistema.

 Adiestrar a cada uno de los operadores de la Aplicación Web, de tal manera
que se haga un buen uso de la herramienta aprovechado la misma de la
mejor manera posible.
 Además, se deben hacer jornadas periódicas de actualización de datos, tanto
en lo que tiene que ver con la información curricular de los docentes como
de sus estudiantes, esto considerando los nuevos ingresos de personal y el
crecimiento en la población estudiantil.
 Administrar la información institucionalmente por alguna autoridad de
secretaría académica del centro educativo. Se recomienda que ésta sea
revisada continuamente de manera que se pueda garantizar un excelente
servicio con una información actual y confiable.
 A futuros desarrolladores, en caso de ampliar la aplicación web deben tener
conocimiento a nivel medio sobre programación en .NET
 Crear políticas de seguridad para el respaldo de la información que genera
la base de datos SQL Server.
 Que el usuario con el perfil administrador genere nuevas contraseñas para
todos los usuarios al momento del primer ingreso a la aplicación, como
medida de seguridad.
 Conformar un área de informática que este encargada de dar mantenimiento,
capacitación y desarrollo de nuevas funcionalidades de la aplicación web.
 Se sugiere en un futuro a mediano plazo que se adquieran equipos
servidores de gama baja, para poder administrar la información solo dentro
del centro escolar.

108
11. Referencias y Bibliografía
 ALERO SOLIS, Manuel. Una explicación de la programación extrema (XP):
V Encuentro usuarios x Base 2003. Madrid: 2003.
 Beck, K. (1999). Extreme Programming Explained. Embrace Change.
(1999). Pearson Education, 1999.Traducido al español como: Una
explicación de la programación extrema. Aceptar el cambio", Addison
Wesley, 2000
 Ceballos, Francisco. (2013). Enciclopedia de Microsoft Visual C#. Cuarta
Edición. Madrid. Ra-Ma. Capítulo 1. Introducción a Microsoft .Net. Pág. 4.
 Ceballos, Francisco. (2013). Enciclopedia de Microsoft Visual C#. Cuarta
Edición. Madrid. Ra-Ma. Capítulo 1. Introducción a Microsoft .Net. Pág. 13.
 Ceballos, Francisco. (2013). Enciclopedia de Microsoft Visual C#. Cuarta
Edición. Madrid. Ra-Ma. Capítulo 14. LINQ. Pág. 631.
 Ceballos, Francisco. (2013). Enciclopedia de Microsoft Visual C#. Cuarta
Edición. Madrid. Ra-Ma. Capítulo 14. Entity Framework. Pág. 654.
 Ceballos, Francisco. (2013). Enciclopedia de Microsoft Visual C#. Cuarta
Edición. Madrid. Ra-Ma. Capítulo 14. Code First. Pág. 715.
 Ceballos, Francisco. (2013). Enciclopedia de Microsoft Visual C#. Cuarta
Edición. Madrid. Ra-Ma. Capítulo 14. ASP.NET. Pág. 741
 Charte, Francisco. (2013). ASP.NET 4.5 /MVC 4. Cuarta Edición. Madrid.
ANAYA Multimedia. Capítulo 1. Estructura de una aplicación Web.Pág. 30
 Charte, Francisco. (2013). ASP.NET 4.5 /MVC 4. Cuarta Edición. Madrid.
ANAYA Multimedia. Capítulo 1. El protocolo HTP. Página 34.
 Charte, Francisco. (2013). ASP.NET 4.5 /MVC 4. Cuarta Edición. Madrid.
ANAYA Multimedia. Capítulo3. El patrón Modelo-Vista-Controlador. Página
67.
 Charte, Francisco. (2013). ASP.NET 4.5 /MVC 4. Cuarta Edición. Madrid.
ANAYA Multimedia. Capítulo 17. ASP.NET Y AJAX. Página 377.
 Kenneth C. Laudon & Jane P. Laudon (2012). Administración de los Sistemas
de Información. México: Pearson Educación. Décimo-Segunda Edición, Pág.
15.
 Kenneth. Kendall (2011). Análisis y Diseño de Sistemas. México: Pearson
Educación. Octava Edición.

110
Web Grafía
 ¿Qué es un dominio?, 29 de Junio del 2017. https://web-
gdl.com/servicios/dominios/que-es-un-dominio/.
 Cliente/Servidor, 28 de octubre del 2010.
http://robiniclienteservidor.weebly.com/ventajas---desventajas.html.
 Concepto de las URL, 07 de marzo del 2016.
http://aprenderinternet.about.com/od/ConceptosBasico/a/Que-Es-Url.htm.
 Definición de IIS (Internet Information Services), 05 de diciembre 2010.
http://www.alegsa.com.ar/Dic/iis.php.
 Ejemplo de desarrollo de software utilizando la metodología XP, 9 de julio de
2007. http://www.dsic.upv.es/asignaturas/facultad/lsi/ejemplo/.
 Sistemas de Información Web, 20 de Octubre de 2012.
http://www.knowdo.org/knowledge/39-sistemas-web.

111
9. Conclusiones

Realizado el análisis de los procesos de la Secretaría Académica del Colegio Bautista Libertad se observó que a pesar de
emplear tecnología los procesos seguían ejecutándose manualmente, lo que significaba en trabajo redundante y bastante
tiempo empleado al realizar los reportes de notas de los alumnos cada corte académico, asimismo para matricular y llevar
el control de pagos.
A partir del análisis de la situación actual se comenzó a automatizar los procesos de carga académica, matrícula, y
subsecuentemente los demás que estaban dentro del alcance de esta investigación. Una vez se dio inició a la
automatización de procesos se diseñó la aplicación por partes según establecía la metodología empleada y a partir del uso
de esta se optimizaron los diferentes procesos en la secretaria académica del colegio Bautista Liberta de la ciudad de
Managua.
Se brindó una solución tecnológica, que permite realizar eficientemente tareas que conllevaban un tiempo considerable por
parte del personal de secretaria académica.
Las herramientas tecnológicas seleccionadas, facilitaron el desarrollo de la aplicación web, ya que cuentan con
características innovadoras que permiten la reducción del código y además garantizar la escalabilidad y el mantenimiento
de la misma.
La aplicación web demostró un buen funcionamiento hasta donde ha sido desarrollada y fue bien vista al momento de la
evaluación con métricas de facilidad de uso y webapps ya que los resultados mostraron un alto grado de aceptación por
parte de los usuarios finales.
 12. Cronograma
Julio Agosto Septiembre Octubre Noviembre Diciembre Enero
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 5 1 2 3 4 5 1 2 3 4
Meses/Semanas

Actividades
1 Elección del tema y
formulación de objetivos.
2 Aprobación del tema.

3 Elaboración de Protocolo

4 Análisis y Diseño de la
aplicación
5 Planeación
6 Historias de Usuario
Tareas de Ingeniería

Pruebas de Aceptación
7 Diseño
8 Metáfora del Sistema

113
 Tarjetas CRC

9 Codificación
10 Pruebas
11 Implementación

114
13. Anexos
Diagrama Relacional
Historias de Usuario

Número de Historia Fecha Entrevistado Tiempo

(Usuario) Estimado
01 24 de julio Directora del 3 horas
del 2017 centro
Iteración Asignada: Primera
educativo.
Nombre Historia: Gestión de periodos lectivos
Roles de Usuarios: Super-Administrador, Administrador
Prioridad en Negocio: Alta
Descripción Se debe registrar cada año un periodo lectivo sobre el cual se
realizarán todas las operaciones del colegio, por ejemplo,
asignar carga académica, matriculación etc, además de
establecer el porcentaje de actividades y de examen
normados por el ministerio de educación.
Observaciones Solo los usuarios con los roles especificados tendrán
el privilegio de crear un periodo lectivo.

Número de Historia Fecha Entrevistado Tiempo

(Usuario) Estimado
02 25 de julio Directora del 2 horas
del 2017 centro
Iteración Asignada: Primera
educativo.
Nombre Historia: Gestión de Cortes académicos
Roles de Usuarios: Super-Administrador, Administrador
Prioridad en Negocio: Alta
Descripción Una vez registrado un periodo lectivo, por ende, habilitado se
debe registrar cada corte académico para la fecha que así lo
establezca la dirección del centro educativo.
Observaciones
Número de Historia Fecha Entrevistado Tiempo
(Usuario) Estimado
03 26 de julio Directora del 2 horas
del 2017 centro
Iteración Primera
educativo.
Asignada:
Nombre Historia: Gestión de Periodos de matrícula.
Roles de Usuarios: Super-Administrador, Administrador
Prioridad en Negocio: Alta
Descripción Esta funcionalidad permitirá el control de la matrícula de
forma que podrá gestionar por periodos, además
estableciendo los costes determinados para cada periodo.
Observaciones Únicamente los administradores del sistema podrán tener
acceso a esta función previamente con autorización de la
dirección.

Número de Historia Fecha Entrevistado Tiempo

(Usuario) Estimado
04 27 de julio Directora del 2 horas
del 2017 centro
Iteración Primera
educativo.
Asignada:
Nombre Historia: Gestión de Tipos de Tipos de Periodo de
Matrícula.
Roles de Usuarios: Super-Administrador, Administrador
Prioridad en Negocio: Alta
Descripción Con esta función del sistema se podrá manejar los tipos de
periodos de matrícula.
Observaciones Únicamente los administradores del sistema podrán tener
acceso a esta función previamente con autorización de la
dirección. Normalmente se maneja que son 3 (Ordinaria,
Extraordinaria, Especial traslado por ejemplo).

117
Número de Historia Fecha Entrevistado Tiempo
(Usuario) Estimado
05 28 de julio Directora del 2 horas
del 2017 centro
Iteración Segunda
educativo.
Asignada:
Nombre Historia: Gestión de Asignaturas
Roles de Usuarios: Super-Administrador, Administrador.
Prioridad en Negocio: Alta
Descripción Permitirá realizar las diferentes operaciones sobre las
asignaturas. De esta forma se podrá tener un listado de todas
las asignaturas que el centro imparte y a la vez ser utilizadas
para la gestión de los módulos requeridos.
Observaciones

Número de Historia Fecha Entrevistado Tiempo

(Usuario) Estimado
06 29 de julio Directora del 2 horas
del 2017 centro
Iteración Primera
educativo.
Asignada:
Nombre Historia: Gestión de Turnos
Roles de Usuarios: Super-Administrador, Administrador.
Prioridad en Negocio: Alta
Descripción Permitirá realizar las operaciones básicas, normalmente son 2
y además muy difícilmente sufren algún cambio .
Observaciones

Número de Historia Fecha Entrevistado Tiempo

(Usuario) Estimado
07 29 de julio Directora del 2 horas
del 2017 centro
Iteración Primera
educativo.
Asignada:
Nombre Historia: Gestión de Grados
Roles de Usuarios: Super-Administrador, Administrador.
Prioridad en Negocio: Alta
Descripción Permitirá realizar las diferentes operaciones básicas sobre los
registros de los diferentes grados siendo estos poco variables
puesto que ya hay una cantidad determinada.
118
Observaciones

Número de Historia Fecha Entrevistado Tiempo

(Usuario) Estimado
08 30 de julio Directora del 2 horas
del 2017 centro
Iteración Primera
educativo.
Asignada:
Nombre Historia: Gestión de Secciones
Roles de Usuarios: Super-Administrador, Administrador.
Prioridad en Negocio: Alta
Descripción Permitirá realizar las diferentes operaciones básicas sobre los
registros de las secciones y claro está que ya hay una
cantidad determinada pero siempre pueden surgir cambios y
por ende mantener los datos actualizados.
Observaciones

Número de Historia Fecha Entrevistado Tiempo

(Usuario) Estimado
09 31 de julio Secretaria y 12 horas
del 2017-al docentes.
Iteración Primera
10 de
Asignada:
agosto
Nombre Historia: Asignación de Carga Académica.
Roles de Usuarios: Super-Administrador, Administrador,
secretaria.
Prioridad en Negocio: Alta
Descripción Permitirá realizar la asignación de carga académica para cada
grupo conformado, los cuales se crearán a partir del turno y
grado y a la vez especificando los diferentes docentes y
asignaturas que impartirán.
Observaciones

Número de Historia Fecha Entrevistado Tiempo

(Usuario) Estimado
10 01 de Secretaria y
agosto del docentes.
Iteración Segunda
2017-al 15
Asignada:
de agosto
Nombre Historia: Gestión de Control de Pagos.

119
Roles de Usuarios: Super-Administrador, Administrador,
secretaria. Cajero.
Prioridad en Negocio: Alta
Descripción Permitirá registrar los pagos por diferentes conceptos de los
estudiantes, tanto de matrícula, mensualidad, escarapela,
camisa, etc.
Observaciones

Número de Historia Fecha Entrevistado Tiempo

(Usuario) Estimado
11 15 de Secretaria y
agosto del docentes.
Iteración Segunda
2017-al 18
Asignada:
de agosto
Nombre Historia: Comprobante de pago.
Roles de Usuarios: Super-Administrador, Administrador,
secretaria. Cajero.
Prioridad en Negocio: Alta
Descripción Mostrará la información del pago realizado.
Observaciones

Número de Historia Fecha Entrevistado Tiempo

(Usuario) Estimado
12 18 de Secretaria y
agosto del docentes.
Iteración Segunda
2017-al 05
Asignada:
de
septiembre.
Nombre Historia: Generación de Matrícula de Nuevo Ingreso.
Roles de Usuarios: Super-Administrador, Administrador,
secretaria. docente.
Prioridad en Negocio: Alta
Descripción Permitirá el registro de nuevos estudiantes, así como de la
información de sus padres y tutor y sobre todo los datos de
matrícula el grupo, etc.
Observaciones

Número de Historia Fecha Entrevistado Tiempo

(Usuario) Estimado
13

120
Iteración Segunda 05 de Secretaria y
Asignada: septiembre docentes.
del 2017-al
15 de
septiembre.
Nombre Historia: Generación de Matrícula de Reingreso.
Roles de Usuarios: Super-Administrador, Administrador,
secretaria. Docente.
Prioridad en Negocio: Alta
Descripción Permitirá el registro estudiante de reingreso, así como de la
información de matrícula el grupo, etc.
Observaciones

Número de Historia Fecha Entrevistado Tiempo

(Usuario) Estimado
14 15 de Secretaria y
septiembre docentes.
Iteración Segunda
del 2017-al
Asignada:
18 de
septiembre.
Nombre Historia: Comprobante de Matrícula.
Roles de Usuarios: Super-Administrador, Administrador,
secretaria. Docente.
Prioridad en Negocio: Alta
Descripción Permitirá visualizar la información del estudiante matriculado.
Observaciones

Número de Historia Fecha Entrevistado Tiempo

(Usuario) Estimado
15 18 de Secretaria y
septiembre docentes.
Iteración Tercera
del 2017-al
Asignada:
05 de
octubre.
Nombre Historia: Registro de Notas.
Roles de Usuarios: Super-Administrador, Administrador,
secretaria. Docente.
Prioridad en Negocio: Alta
Descripción Permitirá el registro de notas por grupo asignado de cada
alumno.
Observaciones

121
Número de Historia Fecha Entrevistado Tiempo
(Usuario) Estimado
16 05 de Secretaria y
octubre del docentes.
Iteración Tercera
2017-al 15
Asignada:
de octubre.
Nombre Historia: Verificación de Notas.
Roles de Usuarios: Super-Administrador, Administrador,
secretaria. Docente.
Prioridad en Negocio: Alta
Descripción Permitirá visualizar las notas por grupo de cada alumno.
Observaciones

Número de Historia Fecha Entrevistado Tiempo

(Usuario) Estimado
17 15 de Secretaria y
octubre del docentes.
Iteración Tercera
2017-al 20
Asignada:
de octubre.
Nombre Historia: Reporte de Notas por Grupo.
Roles de Usuarios: Super-Administrador, Administrador,
secretaria. Docente.
Prioridad en Negocio: Alta
Descripción Permitirá visualizar las notas de cada y sus alumnos.
Observaciones

Número de Historia Fecha Entrevistado Tiempo

(Usuario) Estimado
18 15 de Secretaria y
octubre del docentes.
Iteración Tercera
2017-al 20
Asignada:
de octubre.
Nombre Historia: Gestión de Seguridad.
Roles de Usuarios: Super-Administrador, Administrador.
Prioridad en Negocio: Alta
Descripción Permitirá ingresar nuevos usuarios con sus roles.
Observaciones

122
Formatos para registro y consulta de notas en el Colegio.

123
124
 Diccionario de Datos

Esquema Tabla Columna Tipo Longitud Nulo Llave Primaria

dbo AspNetRoles 2 Tabla None None None
dbo AspNetRoles Id nvarchar 128 No Null Yes
dbo AspNetRoles Name nvarchar 256 No Null None
dbo AspNetUserClaims 4 Tabla None Nole None
dbo AspNetUserClaims Id int No Null Yes
dbo AspNetUserClaims UserId nvarchar 128 No Null None
dbo AspNetUserClaims ClaimType nvarchar max No Null None
dbo AspNetUserClaims ClaimValue nvarchar max No Null None
dbo AspNetUserLogins 3 Tabla None None None
dbo AspNetUserLogins LoginProvider nvarchar 128 No Null Yes
dbo AspNetUserLogins ProviderKey nvarchar 128 No Null None
dbo AspNetUserLogins UserId nvarchar 128 No Null None
dbo AspNetUserRoles 2 Tabla None None None
dbo AspNetUserRoles UserId nvarchar 128 No Null Yes
dbo AspNetUserRoles RoleId nvarchar 128 No Null None
dbo AspNetUsers 11 None Tabla None None
dbo AspNetUsers Email nvarchar 256 No Null Yes
dbo AspNetUsers EmailConfirmed bit 1 No Null None
dbo AspNetUsers PasswordHash nvarchar max No Null None
dbo AspNetUsers SecurityStamp nvarchar max No Null None
dbo AspNetUsers PhoneNumber nvarchar max No Null None
dbo AspNetUsers PhoneNumberConfirmed bit 1 No Null None
dbo AspNetUsers TwoFactorEnabled bit 1 No Null None
dbo AspNetUsers LockoutEndDateUtc datetime None No Null None
dbo AspNetUsers LockoutEnabled bit 1 No Null None
dbo AspNetUsers AccessFailedCount int None No Null None
dbo AspNetUsers UserName nvarchar 256 No Null None
dbo CivilStates 2 None Tabla None None
dbo CivilStates CivilStateId int None No Null Yes
dbo CivilStates Description nvarchar max No Null None
dbo Classrooms 3 Tabla None No Null None
dbo Classrooms ClassroomId int 1 No Null Yes
dbo Classrooms ClassroomCode nvarchar 4 No Null None
dbo Classrooms Description nvarchar 50 No Null None
dbo Classrooms Capacity int None No Null None
dbo CodePeriodLearnings 2 None Tabla None None
dbo CodePeriodLearnings CodePeriodLearningId int max No Null Yes
dbo CodePeriodLearnings CodePeriod nvarchar 5 No Null None
dbo Coins 3 None Tabla None None
dbo Coins CoinId int max No Null Yes
dbo Coins Description nvarchar max No Null None
dbo Coins Symbol nvarchar max No Null None
dbo Concepts 4 None Tabla None None
dbo Concepts ConceptId int None No Null Yes
dbo Concepts Code nvarchar 3 No Null None
dbo Concepts Name nvarchar max No Null None
dbo Concepts Status int max No Null None
dbo EnrollmentDetails 3 None Tabla None None
dbo EnrollmentDetails EnrollmentDetailsId int None No Null Yes
dbo EnrollmentDetails EnrollmentId int max No Null None
dbo EnrollmentDetails RequirementId int max No Null None
dbo EnrollmentPeriods 6 None Tabla None None
dbo EnrollmentPeriods EnrollmentPeriodId int max No Null Yes

126
dbo EnrollmentPeriods InitialDate datetime None No Null None
dbo EnrollmentPeriods FinalDate datetime None No Null None
dbo EnrollmentPeriods SchoolYearId int None No Null None
dbo EnrollmentPeriods TypePeriodEnrollmentId int None No Null None
dbo EnrollmentPeriods IsClosed bit None No Null None
dbo Enrollments 11 None Tabla None None
dbo Enrollments EnrollmentId int None No Null YES
dbo Enrollments NumberEnrollment int None No Null None
dbo Enrollments PaymentNumber int None No Null None
dbo Enrollments TypeEnrollmentId int None No Null None
dbo Enrollments StudentId int None No Null None
dbo Enrollments GroupId int None No Null None
dbo Enrollments DateEnrollment datetime None No Null None
dbo Enrollments CollegeOrigin nvarchar max No Null None
dbo Enrollments Remarks nvarchar max No Null None
dbo Enrollments StateEnrollment int None No Null None
dbo Enrollments PaymentsEnrollment_PaymentEnrollmentId int None No Null None
dbo GradeSubjectDetails 3 None Tabla None None
dbo GradeSubjectDetails GradeSubjectDetailId int None No Null Yes
dbo GradeSubjectDetails LevelId int None No Null None
dbo GradeSubjectDetails SubjectId int None No Null None
dbo GroupDetails 4 None Tabla None None
dbo GroupDetails GroupDetailId int max No Null Yes
dbo GroupDetails GroupId int max No Null None
dbo GroupDetails TeacherId int max No Null None
dbo GroupDetails SubjectId int max No Null None
dbo Groups 7 None Tabla None None
dbo Groups GroupId int Max No Null Yes

127
dbo Groups CodeGroup nvarchar 11 No Null None
dbo Groups SchoolYearId int Max No Null None
dbo Groups LevelId int Max No Null None
dbo Groups ShiftId int Max No Null None
dbo Groups ClassroomId int Max No Null None
dbo Groups Teacher nvarchar max No Null None
dbo LearningPeriods 7 None Tabla None None
dbo LearningPeriods LearningPeriodId int max No Null Yes
dbo LearningPeriods InitialDate datetime None No Null None
dbo LearningPeriods FinalDate datetime None No Null None
dbo LearningPeriods SchoolYearId int None No Null None
dbo LearningPeriods Description nvarchar max No Null None
dbo LearningPeriods State bit None No Null None
dbo LearningPeriods CodePeriodLearningId int None No Null None
dbo Levels 3 None Tabla None None
dbo Levels LevelId int max No Null Yes
dbo Levels Name nvarchar max No Null None
dbo Levels Code int max No Null None
dbo Months 4 None Tabla None None
dbo Months MonthId int max No Null Yes
dbo Months Code nvarchar 3 No Null None
dbo Months Name nvarchar max No Null None
dbo Months Status int max No Null None
dbo NoteBooks NoteBookID int max No Null Yes
dbo NoteBooks BookCode nvarchar max No Null None
dbo NoteBooks LearningPeriodId int max No Null None
dbo NoteBooks GroupId int max No Null None
dbo NoteBooks State bit 2 No Null None

128
dbo NotesBookDetails 6 None Tabla None None
dbo NotesBookDetails NotesBookDetailsId int max No Null Yes
dbo NotesBookDetails NoteBookId int max No Null None
dbo NotesBookDetails StudentId int max No Null None
dbo NotesBookDetails SubjectId int max No Null None
dbo NotesBookDetails Accumulated float max No Null None
dbo NotesBookDetails ExaminationCualification float max No Null None
dbo Payers 3 None Tabla None None
dbo Payers PayerId int 250 No Null Yes
dbo Payers Name nvarchar max No Null None
dbo Payers Identification nvarchar max No Null None
dbo PaymentDetails 7 None Tabla None None
dbo PaymentDetails PaymentDetailsId int max No Null Yes
dbo PaymentDetails PaymentId int max No Null None
dbo PaymentDetails ConceptId int max No Null None
dbo PaymentDetails MonthId int max No Null None
dbo PaymentDetails Amount float max No Null None
dbo PaymentDetails Quantity int max No Null None
dbo PaymentDetails Arrears float max No Null None
dbo Payments 8 None Tabla None None
dbo Payments PaymentId int max No Null Yes
dbo Payments PaymentNumber int max No Null None
dbo Payments PaymentDate datetime max No Null None
dbo Payments SchoolYear int max No Null None
dbo Payments StudentId int max No Null None
dbo Payments PayerId int max No Null None
dbo Payments Status bit max No Null None
dbo Payments Cash int max No Null None

129
dbo PaymentsEnrollments 10 None Tabla None None
dbo PaymentsEnrollments PaymentNumber int max No Null Yes
dbo PaymentsEnrollments PaymentDate datetime None No Null None
dbo PaymentsEnrollments SchoolYearId int max No Null None
dbo PaymentsEnrollments AName nvarchar max No Null None
dbo PaymentsEnrollments IdentificationCard nvarchar max No Null None
dbo PaymentsEnrollments Amount float max No Null None
dbo PaymentsEnrollments Remarks nvarchar max No Null None
dbo PaymentsEnrollments Status nvarchar max No Null None
dbo PaymentsEnrollments CellPhone nvarchar max No Null None
dbo PaymentsEnrollments PaymentEnrollmentId int 250 No Null None
dbo RelationShips 2 None Tabla None None
dbo RelationShips RelationShipId int max No Null Yes
dbo RelationShips Relation nvarchar max No Null None
dbo Requirements 2 None Tabla None None
dbo Requirements RequirementId int max No Null Yes
dbo Requirements Description nvarchar max No Null None
dbo Responsibles 12 None Tabla None None
dbo Responsibles ResponsibleId int max No Null Yes
dbo Responsibles Names nvarchar max No Null None
dbo Responsibles Lastname nvarchar max No Null None
dbo Responsibles MotherLastName nvarchar max No Null None
dbo Responsibles CivilStateId int max No Null None
dbo Responsibles Address nvarchar max No Null None
dbo Responsibles Phone nvarchar max No Null None
dbo Responsibles CellPhone nvarchar max No Null None
dbo Responsibles Email nvarchar max No Null None
dbo Responsibles RelationShipId nvarchar max No Null None

130
dbo Responsibles Permissions bit 2 No Null None
dbo Responsibles LiveWith bit 2 No Null None
dbo SchoolYearDetails 4 None Tabla None None
dbo SchoolYearDetails DetailsId int max No Null Yes
dbo SchoolYearDetails SchoolYearId int max No Null None
dbo SchoolYearDetails ConceptId int max No Null None
dbo SchoolYearDetails Price float max No Null None
dbo SchoolYears 12 None Tabla None None
dbo SchoolYears SchoolYearId int max No Null Yes
dbo SchoolYears Year int max No Null None
dbo SchoolYears Motto nvarchar max No Null None
dbo SchoolYears Director nvarchar max No Null None
dbo SchoolYears VicePrincipal nvarchar max No Null None
dbo SchoolYears Secretary nvarchar max No Null None
dbo SchoolYears Numberofperiods int max No Null None
dbo SchoolYears ExamPercentage int max No Null None
dbo SchoolYears AccumulatedPercentage int max No Null None
dbo SchoolYears CloseYear bit max No Null None
dbo SchoolYears Payday int max No Null None
dbo SchoolYears Arrears float max No Null None
dbo Shifts 2 None Tabla None None
dbo Shifts ShiftId int max No Null Yes
dbo Shifts Name nvarchar max No Null None
dbo States 2 None Tabla None None
dbo States StateId int max No Null Yes
dbo States Description nvarchar 256 No Null None
dbo StudentResponsibleDetails StudentResponsibleDetailsId int max No Null Yes
dbo StudentResponsibleDetails StudentId int max No Null None

131
dbo StudentResponsibleDetails ResponsibleId int max No Null None
dbo Students StudentId int max No Null Yes
dbo Students NoCarnet nvarchar max No Null None
dbo Students Names nvarchar max No Null None
dbo Students Lastname nvarchar max No Null None
dbo Students MotherLastName nvarchar max No Null None
dbo Students BirthDate datetime None No Null None
dbo Students TGenderId int 256 No Null None
dbo Students Address nvarchar max No Null None
dbo Students Phone nvarchar max No Null None
dbo Students CellPhone nvarchar max No Null None
dbo Students Email nvarchar max No Null None
dbo Students StateId int 256 No Null None
dbo Students UserName nvarchar max No Null None
dbo Subjects 4 None Tabla None None
dbo Subjects SubjectId int 256 No Null Yes
dbo Subjects Code nvarchar 4 No Null None
dbo Subjects Name nvarchar max No Null None
dbo Subjects IsAverage bit 2 No Null None
dbo Teachers 10 None Tabla None None
dbo Teachers TeacherId int 256 No Null Yes
dbo Teachers Names nvarchar max No Null None
dbo Teachers LastName nvarchar max No Null None
dbo Teachers MotherLastName nvarchar max No Null None
dbo Teachers IdentificationCard nvarchar max No Null None
dbo Teachers PhoneNumber nvarchar max No Null None
dbo Teachers TGenderId int 256 No Null None
dbo Teachers StateId int 256 No Null None

132
dbo Teachers UserName nvarchar max No Null None
dbo Teachers Email nvarchar max No Null None
dbo TGenders 2 None Tabla None None
dbo TGenders TGenderId int 256 No Null Yes
dbo TGenders Description nvarchar max No Null None
dbo TypeEnrollments 2 None Tabla None None
dbo TypeEnrollments TypeEnrollmentId int 256 No Null Yes
dbo TypeEnrollments Description nvarchar max No Null None
dbo TypePeriodEnrollments 2 None Tabla None None
dbo TypePeriodEnrollments TypePeriodEnrollmentId int 250 No Null Yes
dbo TypePeriodEnrollments Type nvarchar max No Null None

133
Manual básico de usuario
Vista de acceso a la aplicación

1
2

5
4

1
Escudo del colegio Bautista Libertad

2 Campo del Usuario

En este campo se debe ingresar el

usuario que será autenticado en la
base de datos.

3 Campo de la contraseña

En este campo de debe ingresar la

contraseña que será autenticada en
la base de datos.
 3 Botón Acceder
Al dar clic en este botón se validará si los datos son
auténticos para luego determinar el rol correspondiente y
acceder al menú que le corresponda.

4 Recordar Credenciales

Al chequear esta opción permite que sus credenciales

sean recordadas por el navegador para cuando vuelva
a usar la aplicación.

5 Enlace para recuperar contraseña

Al hacer clic sobre este enlace lo redirigirá hacia una
vista que le solicitará el correo electrónico para
poder recuperar su contraseña.
6 Vista para recuperar contraseña

En esta vista deberá proporcionar la dirección de correo electrónico asociada con

su cuenta de usuario para proceder a validar si existe y en caso positivo enviarle un
enlace al correo para proceder a crear una nueva contraseña.

135
 7
Menú principal de administrador

8 Catálogo de periodos lectivos

En esta vista se realizarán las siguientes operaciones:

 Agregar nuevo periodo.
 Editar un periodo.
 Suspender o cerrar un periodo.
 Visualizar detalles de un periodo.

136
 9 Catálogo de Secciones

En esta vista se realizarán las siguientes operaciones:

 Agregar nueva seccion.
 Editar una seccion.
 Suspender o cerrar una seccion.
 Visualizar detalles de una seccion.

137
 10 Catálogo de Docentes

En esta vista se realizarán las siguientes operaciones:

 Agregar nuevo docente.
 Editar docente.
 Suspender un docente.
 Visualizar detalles de un docente.

10

Para Agregar un nuevo docente debe realizar lo siguiente:

1.  Dar clic al botón y se mostrará la siguiente ventana

modal donde se ingresará los datos del nuevo
docente:

138
2. Completará los campos, teniendo en cuenta que no puede dejar
ninguno vacío a excepción del número de teléfono convencional, si
algún otro campo diferente a este es dejado vacío se mostrará el
siguiente mensaje:

2.1. Los campos tienen ciertas validaciones que deberán cumplirse para
proceder al registro de un docente por ejemplo la siguiente en el campo
del apellido no puede ser de un carácter únicamente.

139
 3. Si completa correctamente el formulario guardará el nuevo docente
dando clic al botón y se mostrará el siguiente mensaje de
éxito:

Editar un docente
Para editar un docente se deben realizar siguiente:

140
1.  Seleccionar un docente en la lista, haciendo clic sobre el boton

Y se mostrara la ventana siguiente con los datos del docente

solo tendrán que ingresar nuevos datos y hacer clic en el botón

Y mostrara nuevamente el siguiente mensaje de confirmación

11 Agregar carga académica

En esta vista se podrá registrar la carga académica correspondiente al año en

curso, asignando a cada maestro los grupos y clases que les sean dadas.

141
Para registrar una carga academica deberá primeramente seguir el orden que
posee el formulario, en seleccionar de arriba hacia debajo de izquiera a derecha
cada opción presentada. Por ejemplo
Debera especificar el año lectivo seleccionando
en la lista desplegable

Luego deberá especificar el turno, la seccion y el

grado académico a registrar.

Ahora deberá especificar el docente guía que tendrá

ese grupo haciendo clic en el botón
mostrará una lista de los docentes activos
del colegio y tendrá que seleccionar quien
será el guía.

142
 A continuación, se muestra
la lista de docentes donde
deberá hacer clic sobre el
docente que desee
seleccionar y luego de
eso hacer clic sobre el
botón

También en esta ventana modal se

presentan las opciones de cerrar, para cerrar
la ventana y refrescar que actualizara la lista
de docentes en caso de no aparecer un docente que halla sido registrado
recientemente por otro usuario.
Otra de las opciones destacadas de esta ventana es la búsqueda que puede
realizar, especificando el filtro que desee sobre este cuadro texto

Luego tendrá que seleccionar el docente o los docentes con las clases que se les
asignaran seleccionándolo de la lista desplegable o bien buscándolo en la ventana
mostrada anteriormente para buscar el docente guía.

143
 Luego de seleccionar el docente
deberá hacer clic sobre cada
asignatura mostrada en la lista que
corresponde a un grado y hacer clic
en el botón

Las asignaturas se mostrarán

en la lista de detalles,
presentando la opción de
quitarla de lista con el botón

Finalmente, luego de seleccionar las opciones y completar el formulario para

guardar la carga académica debe hacer clic en el botón

144
 Si el grupo asignado esta registrado
presentara un mensaje de error.

De lo contrario mostrara un mensaje de confirmación como el siguiente.

12 Matricula Nuevo Ingreso

Para matricular un alumno de nuevo ingreso deberá primeramente seguir

ordenadamente los pasos tal y como el formulario está diseñado.

145
 1. Primeramente, especificar el número de recibo que le fue proporcionado
ingresándolo en el siguiente campo

Y luego hacer clic en el botón

En caso de estar correcto el número proporcionado y ser valido es decir que no

sea un numero de pago que corresponde a otro pago mostrara los datos de la
persona que pago en la siguiente seccion

Y luego hacer clic en el boton

2. Ahora deberá proporcionar los datos del alumno completando cada uno de
los campos

146
3. Si completo correctamente los campos ahora debe proceder a llenar los
datos del padre

4. Posteriormente completara los datos de la madre y del tutor

5. Datos del tutor

147
 6. Completadas cada una de estas pestañas por último especificara los datos
académicos del alumno para ser matriculado.

Deberá completar cada uno de los campos, una validación importante es que al
momento de seleccionar el grupo académico se validara si hay cupo disponible en
ese grupo y mostrara una ventana con los datos estadísticos de ese grupo.

Luego de completar todos los campos deberá hacer clic en el boton guardar y
automáticamente si el registro es correcto le será generada la hoja de matricula
para imprimirla si así lo requiere.

148