Universidad Nacional de Ingeniería Facultad de Ciencias Y Sistemas Ingeniería de Sistemas

UNIVERSIDAD NACIONAL DE INGENIERÍA
FACULTAD DE CIENCIAS Y SISTEMAS

INGENIERÍA DE SISTEMAS
MONOGRAFÍA PARA OPTAR AL TÍTULO DE INGENIERO DE SISTEMAS
TEMA:
DESARROLLO DE UNA APLICACIÓN WEB DE GESTIÓN ACADÉMICA Y

CONTROL DE PAGOS DEL TÉCNICO SUPERIOR DE INFORMÁTICA Y
SISTEMAS TSIS.
AUTORES:
BR. GERALD DE JESÚS GONZÁLEZ ZELEDÓN 2010 – 33312

BR. ESTEFAN ANTONIO MENOCAL ZAMORA 2010 – 33577
BR. JORGE ERNESTO QUINTANA JAENZ 2010 – 33139
TUTOR:
MSC. ING. YASSER MEMBREÑO GUDIEL
Managua, Septiembre del 2018
1
DEDICATORIA.
A Dios, porque siempre estuvo a nuestro lado en todo el transcurso de esta

etapa, por concedernos la motivación y de su sabiduría para la finalización de
nuestros estudios.
A nuestros padres, por su apoyo en la elección de nuestra carrera universitaria,

y de su esfuerzo en concedernos la oportunidad de estudiar a lo largo de
nuestras vidas.
A nuestros hermanos, parientes y amigos, por sus consejos, paciencia y toda

la ayuda que nos brindaron para concluir nuestros estudios.
2
RESUMEN.
El presente documento, brinda al programa del Técnico Superior de

Informática y Sistemas (TSIS), una herramienta de apoyo en la gestión
académica y control de pagos.
El objetivo es desarrollar un sistema que se ajuste a los procesos del TSIS y

dar solución a la problemática que experimenta respecto a la descentralización
de la información y documentación de los mismos. El desarrollo se hizo en el
leguaje C# con IDE Visual Studio .NET 2012 y SQL Server 2014 como gestor
de base de datos.
Así mismo, se presenta un estudio de factibilidad para la aceptación que tiene

el proyecto en el TSIS. La aplicación web SISTSIS (Sistema del Técnico
Superior de Sistemas) contempla 2 procesos fundamentales:
 Procesos académicos que engloba: el registro de docentes, estudiantes,

matrícula, Inscripción de asignaturas, Registro de notas, monografía, y
examen de suficiencia.
 Registro y control de pagos (pago de aranceles.)
Entre los beneficios de este proyecto, podemos mencionar:

 El uso de una herramienta que centralice la información académica del TSIS.
 Beneficios económicos del TSIS en concepto de ahorros en materiales de
oficina.
 Reducción en los tiempos de respuesta al generar reportes académicos.
Finalmente, mediante los formatos de reportes propuestos, se presenta al

TSIS una alternativa en la estandarización en la documentación de sus
procesos ajustados a sus necesidades.
3
ÍNDICE.
INTRODUCCIÓN. .................................................................................................................. 7
OBJETIVOS. ........................................................................................................................... 8
Objetivo general: ................................................................................................................ 8
Objetivo específico: ............................................................................................................ 8
JUSTIFICACIÓN. ................................................................................................................... 9
ANTECEDENTES. ............................................................................................................... 10
DISEÑO METODOLÓGICO. .............................................................................................. 11
Descripción del tipo de trabajo a realizar. .................................................................... 11
Descripción del universo e integrantes del estudio .................................................... 11
Descripción de fuentes de información......................................................................... 14
Instrumentos para la recopilación de datos. .................................................................... 16
1. Entrevista formal- no estructurada: ....................................................................... 16
2. Encuesta: ................................................................................................................... 16
Procedimiento para la recolección de los datos. ............................................................. 17
Procesamiento de la información. ..................................................................................... 17
Tipo de análisis que se realizará a la información. ......................................................... 18
MARCO TEÓRICO .............................................................................................................. 19
1. Sistemas de información. ........................................................................................ 19
2. Tipos de sistemas de información. ........................................................................ 20
2.1. Sistemas de información y procesamiento de datos. ..................................... 20
2.2. Procesos de sistemas de información. ............................................................. 21
3. Ingeniería Web ............................................................................................................. 21
3.1. Proceso de la Ingeniería Web. ............................................................................... 22
3.2. Diferencia con la Ingeniera de Software........................................................... 23
3.3. Tecnología en el desarrollo web. ........................................................................... 24
3.4. Motores de bases de datos. ................................................................................... 28
4. Ingeniería web basada en UML (UWE.) ................................................................... 29
5. Aspectos metodológicos. ............................................................................................ 37
4
5.1. Metodología de la iWeb. ......................................................................................... 37
6. Etapas de pruebas. .................................................................................................. 40
7. Arquitectura web. ......................................................................................................... 41
7.1. Arquitectura en capas.......................................................................................... 42
CAPÍTULO I: ......................................................................................................................... 45
ENFOQUE SISTÉMICO...................................................................................................... 45
1. ASPECTOS ORGANIZACIONALES......................................................................... 46
1.1. Misión del TSIS. ................................................................................................... 46
1.2. Visión del TSIS. .................................................................................................... 46
1.3. ESTRUCTURA ORGANIZACIONAL DEL TSIS.............................................. 47
1.4. DEFINICIÓN DEL PROBLEMA. ....................................................................... 48
1.4.1. Diagrama causa y efecto de la problemática en el TSIS. .......................... 49
1.5. OBJETIVOS DEL SISTEMA............................................................................... 50
1.6. DEFINICIÓN DE ACTORES. ............................................................................. 50
CAPÍTULO II: ........................................................................................................................ 52
ESTUDIO DE FACTIBILIDAD. ........................................................................................... 52
2.1. FACTIBILIDAD TÉCNICA. .................................................................................. 53
2.1.1. Requerimientos de hardware. ........................................................................ 54
2.1.2. Requerimientos de software. .......................................................................... 56
2.2. FACTIBILIDAD ECONÓMICA. ........................................................................... 58
2.2.1. Costos de equipos a adquirir. ..................................................................... 58
2.2.2. Estimación de costo del software. ............................................................. 59
2.2.3. Costos del servicio de alojamiento de la base de datos. ....................... 61
2.2.4. Costos totales de inversión......................................................................... 61
2.3. FACTIBILIDAD FINANCIERA. ........................................................................... 62
2.3.1. Ahorros estimados por el uso del sistema. .................................................. 62
2.3.2. Evaluación financiera....................................................................................... 63
2.3.2.6. Análisis Costo-Beneficio. ................................................................................ 70
2.3.2.7. Beneficios del sistema. .................................................................................... 72
CAPÍTULO III: ....................................................................................................................... 73
5
ANÁLISIS DE REQUERIMIENTOS. ................................................................................. 73
3.1. DESCRIPCIÓN DEL MODELADO DEL NEGOCIO. .......................................... 74
3.1.1. Gestión de requerimientos ................................................................................. 74
CAPÍTULO IV:....................................................................................................................... 83
DISEÑO DEL SISTEMA...................................................................................................... 83
4.1. MODELOS UWE. ................................................................................................. 84
4.1.1. Modelo de caso de uso del negocio. ............................................................. 84
4.1.2. Diagramas de actividad del negocio. ................................................................ 85
4.1.3. Modelo de caso de uso del sistema. ............................................................. 86
4.1.4. Caso de uso. ......................................................................................................... 87
4.1.5. Diagrama de secuencia. ..................................................................................... 89
4.1.6. Diagrama de colaboración. ................................................................................. 92
4.1.7. Diagrama conceptual. .......................................................................................... 96
4.1.9. Diagrama de estado............................................................................................. 98
4.1.10. Diagrama de paquete. ..................................................................................... 98
4.1.11. Diagrama de componentes............................................................................. 99
4.1.12. Diagrama navegacional................................................................................. 101
4.1.13. Diagramas de procesos. ............................................................................... 102
4.1.14. Diagramas de actividad de proceso. ........................................................... 103
4.1.15. Diagramas de presentación. ......................................................................... 105
CONCLUSIONES. ............................................................................................................. 106
RECOMENDACIONES. .................................................................................................... 107
BIBLIOGRAFÍA. .................................................................................................................. 108
ANEXOS .............................................................................................................................. 110
6
INTRODUCCIÓN.
La Facultad de Ciencias y Sistemas del Recinto Universitario Pedro Arauz

Palacios de la Universidad Nacional de Ingeniería ofrece la carrera: Técnico
Superior en Informática y Sistemas dirigida a estudiantes egresados de la
educación media con el objetivo de formar técnicos competentes a nivel
superior en las especialidades de informática y administración.
En la actualidad la gestión académica de esta carrera se realiza de forma

manual y semi computarizada, haciendo uso de varias herramientas para el
desarrollo de los procesos, lo que hace que la información esté
descentralizada y que la generación de reportes académicos sea compleja.
La gestión se realiza a través de las herramientas: Microsoft Access, Excel,

Word, en donde se almacenan los datos del estudiante, registro de matrícula,
inscripción de asignatura, registro de notas. Así mismo, se realizan otros
procesos de manera manual como lo son la emisión de esquela y creación del
ciclo académico.
Para ello se determinó la viabilidad del desarrollo de la aplicación Web

mediante un estudio económico y financiero, se analizó la información
recopilada de cada uno de los procesos que se efectúan en el TSIS,
obteniendo los requerimientos funcionales y no funcionales. Se modelaron los
procesos que forman parte de la gestión, haciendo uso del enfoque de
ingeniera de software UWE.
Finalmente se desarrolló la aplicación web de Gestión académica del TSIS

centralizando la información, dirigido a facilitar la generación de informes
académicos.
7
OBJETIVOS.
Objetivo general:
Desarrollar una aplicación web para la gestión académica y control de pagos

del TSIS de la Facultad de Ciencias y Sistemas en la Universidad Nacional de
Ingeniería.
Objetivo específico:
 Determinar la viabilidad del desarrollo de la aplicación Web mediante un

estudio económico y financiero.
 Analizar la información recopilada de cada uno de los procesos que se
efectúan en el Técnico de Sistemas obteniendo los requerimientos
funcionales y no funcionales.
 Diseñar los procesos que forman parte de la gestión del TSIS haciendo uso
de la metodología UWE para el modelado.
 Implementar el análisis y diseño mediante la programación de los módulos
que conformarán la aplicación web.
8
JUSTIFICACIÓN.
Los beneficios que se obtendrán con el desarrollo de la aplicación web serán

para los estudiantes y el personal del TSIS encargado de la gestión, este último
tendrá la oportunidad, facilidad de interactuar con una nueva herramienta de
control, registro y manipulación de la información, que centralizará la
información académica agilizando la generación de los informes académicos,
facilitando de esta forma el procesamiento de los datos en el trabajo diario.
Así mismo el estudiante será beneficiado, ya que, con la creación de la

aplicación web, podrá tener disponible la información académica de su interés
desde cualquier lugar con acceso a internet de manera rápida y sencilla
cuando ellos así lo requieran, esto con el desarrollo de un módulo en la
aplicación web destinado para ellos, así no tendrán que ir al técnico para
consultas de notas, horario asignados, asignaturas inscritas, grupo al que
pertenecen u otros aspectos de información académica.
Esta aplicación permitirá al Técnico Superior en Informática y Sistemas

adaptarse a las demandas de los usuarios de manera más eficaz, logrando la
integración de varios procesos en una sola herramienta.
Entre otros beneficios se hace mención a la disminución sustantiva de los

costos por materiales de oficina, así como la capacidad de brindar un mejor
servicio a la comunidad estudiantil.
9
ANTECEDENTES.
El Programa Técnico Superior en Informática y Sistemas está ubicado en el

costado sur de Villa Progreso en el Recinto Universitario Pedro Arauz Palacios
de la Universidad Nacional de Ingeniería, el TSIS comenzó sus servicios
académicos en el año 2011.
La gestión de los procesos que se incurren para dar el servicio a los

estudiantes no cuenta con un sistema a la medida que se adapte a las
necesidades, la mayoría de los procesos se realizan con Microsoft Excel 2010,
Microsoft Access 2010, otros que se llevan de manera manual y archivados en
espacios físicos, por lo que la información académica esta descentralizada.
Desde la creación de la carrera técnica (2011) hasta la actualidad se ha hecho

un solo estudio en cuanto a automatizar los procesos en un software a la
medida.
En abril del año 2014 se realizó dicho estudio por parte de un grupo de
alumnos egresados como trabajo final del mismo técnico, pero no se
implementó porque el sistema no contó con las opciones y tareas que los
procesos del TSIS necesitaban para su ejecución, de modo que los
encargados de la gestión prefirieron seguir con el método anterior y trabajar
con el paquete Office que es el mismo que se usa actualmente.
10
DISEÑO METODOLÓGICO.
Descripción del tipo de trabajo a realizar.
Se realiza una investigación proyectiva (La investigación proyectiva-

Investigación holística, 2016) ya que este tipo de investigación consiste en la
elaboración de una propuesta, un plan, un programa o un modelo, a partir de
un diagnóstico preciso de las necesidades del momento, los procesos
explicativos, involucrados y de las tendencias futuras (curva tecnológica), es
decir, con base en los resultados de un proceso investigativo.
En esencia es lo que se hará, una propuesta de mejora mediante una

aplicación web que permita centralizar la información para facilitar la
generación de reportes académicos del TSIS y cambiar de métodos manuales
y semi computarizados a métodos computarizados.
Así mismo el estudiante podrá tener disponible la información académica de

su interés desde cualquier lugar con acceso a internet de manera rápida y
sencilla cuando ellos así lo requieran.
Descripción del universo e integrantes del estudio
Universo: La Facultad de Ciencias y Sistemas.
Se denomina la Facultad como el universo ya que es la que regula y controla

el Técnico Superior.
Sistema: Técnico Superior de Informática y Sistemas (TSIS).
11
Es el centro de estudio, en el cual se analizarán los aspectos a considerar,
cómo se ejecutan los procesos en el TSIS, para dar un diagnóstico y brindar
soluciones para mejora del sistema mediante una metodología establecida.
Integrantes:
 El coordinador.
 Asistente de coordinación del TSIS.
 Docente.
 Estudiante.
 Caja
Selección de la población y muestra.
 El cálculo de la muestra de estudiantes se estimó con una media

aritmética de la cantidad de estudiantes de los 3 últimos años del TSIS
en las distintas modalidades.
Tabla 1.
Historial de estudiantes matriculados del 2013 al 2015 año.
Integrante 2013 2014 2015 Promedio
Estudiantes 75 71 46 64
Nota: fuente, TSIS.
Obteniendo una población de 64 estudiantes en promedio en los últimos 3

años de operación del TSIS.
Para la selección de la muestra en estudio se utiliza la ecuación 1 (Aguilar-

Barojas, 2005), en el caso de una población finita.
12
Ecuación 1
𝑁 ∗ 𝑍2 ∗ 𝑝 ∗ 𝑞
𝑛= 2
𝑑 ∗ (𝑁 − 1) + 𝑍 2 ∗ 𝑝 ∗ 𝑞
Dónde:
N: Tamaño de la población
n: Tamaño de la muestra
Z: Valor correspondiente a la distribución de Gauss (Zúniga, 2016) según el

grado de confianza. (En este caso 90%, para lo cual Z=1.645)
P=Proporción esperada (en este caso 0.5)
Q: 1-P (en este caso 0.5)
d: Error que se prevé cometer (en este caso 10%)
El tamaño de la muestra para la población estudiantil es:
64 ∗ 1.6452 ∗ 0.5 ∗ 0.5

𝑛= = 32.89
0.12 ∗ (64 − 1) + 1.6452 ∗ 0.5 ∗ 0.5
En base a los resultados obtenidos se requiere realizar la encuesta a 33

estudiantes de las distintas modalidades del TSIS.
13
Descripción de fuentes de información.
Las fuentes de información son los instrumentos para el conocimiento,

búsqueda y acceso a la información, estas se dividen en dos: fuentes primarias
y secundarias, las fuentes en el caso de la gestión del TSIS son las siguientes:
Fuentes primarias:
1. Documentos y formatos que se generan al momento de la gestión de los

procesos.
2. Encuestas y entrevistas a los participantes definido como fuentes, entre
ellos:
 El coordinador.
 Estudiante.
14
Fuentes secundarias:
I. Estudios realizados anteriormente sobre la gestión de los procesos del

TSIS.
Tipo de información requerida de las fuentes
Tabla 2.
Información requerida de las fuentes de información.
INVOLUCRADOS DATOS INFORMACION
1. Cantidad de procesos.
2. Tiempo en cada proceso.
Planes de mejoras de procesos.
3. Número de tareas en cada proceso.
Coordinador 4. Tecnologías que usan.

5. Cantidad de computadoras para la
gestión.
6. Infraestructura.
1. Precio de matrícula. 1. Satisfacción con la ejecución
2. Cantidad de estudiantes de los procesos.
matriculados. 2. Comodidad que brindan las
3. Porcentaje de tendencia de instalaciones.
crecimiento de matriculas. 3. Pronóstico de crecimiento del
Asistente de 4. Porcentaje de cumplimiento de proyecto TSIS.
coordinacion pagos. 4. Cumplimiento de actividades
5. Cantidades de docentes. 5. Faltas en la atención por
6. Modalidades en el curso. ausencia de recursos.
7. Cantidad de asignaturas. 6. Requerimientos y necesidades
8. Porcentaje de satisfacción para la para automatización de los
realización de los procesos. procesos.
9. Programas que usan.
10. Tareas que desempeñan.
11. Cantidad de visitantes.
12. Cantidad de procesos
automatizados.
13. Cantidad de procesos semi
computarizado.
14. Cantidad de procesos manuales.
15
1. Tiempo empleado en la gestión. 1. Satisfacción con la ejecución
2. Número de actividades que requiere de los procesos.
el período de matrícula. 2. Aceptación al cambio en los
3. Tiempo empleado por consulta. procesos.
4. Cantidad de estudiantes con 3. Accesibilidad de la
Estudiante smartphone. información.
5. Porcentaje de aceptación de
procesos empleado en la gestión.
Nota: fuente. TSIS.
Instrumentos para la recopilación de datos.
Se plantean los siguientes instrumentos de recopilación de datos para la

investigación:
1. Entrevista formal- no estructurada:
Aplica al personal encargado de la gestión del TSIS (coordinador y secretaria)

de la Facultad de Ciencias y Sistemas. Este instrumento se diseña debido que
la cantidad de la población de estos integrantes no es grande.
2. Encuesta:
Dirigida a los Estudiantes del Técnico. Se usará un 90% de confiabilidad en la

información con una distribución estadística de Gauss (Zúniga, 2016).
Aplicar estos tipos de instrumentos es de suma importancia ya que se

procesan datos y estos generan información, para obtener conocimientos
necesarios y brindar las mejoras respectivas a los procesos de gestión
académica del TSIS.
16
Procedimiento para la recolección de los datos.
Para la recolección de datos necesarios de los estudiantes el equipo visitará

las secciones en donde se imparten las clases del técnico en las distintas
modalidades y grado académico, aplicando la encuesta elaborada.
En el caso de las demás fuentes de información se les realizará una entrevista

formal - no estructurada con preguntas prediseñadas y específicas, sujetas a
cambio al momento de la ejecución, según sea el entrevistado y tipo de
autoridad relacionada con la gestión del TSIS.
Procesamiento de la información.
Para el procesamiento de los datos, primero se enumerarán las encuestas

para un mayor orden y entendimiento, posteriormente se utilizará la
herramienta informática SPSS Statistics 23, que es un sistema estadístico, en
el cual se digitarán cada uno de los resultados de las preguntas formuladas,
hasta cumplir con el número realizado. Una vez obtenidos los datos se
procederá a generar las estadísticas, datos agrupados y gráficas
correspondientes.
De esta manera se tendrá lo necesario para empezar a relacionar los datos

tanto de las respuestas a las preguntas de la misma, a como también
relacionar una encuesta con otra, y así convertir esos datos generados en
información valiosa para determinar posibles causas del mal funcionamiento
en el sistema de gestión, dando paso a la construcción de ideas y soluciones
para las mejoras en el proceso.
17
Tipo de análisis que se realizará a la información.
El objetivo del análisis de información es obtener ideas relevantes, de las

distintas fuentes de información, lo cual permite expresar el contenido sin
ambigüedades.
El análisis que se aplicará en el procesamiento de la información es con

enfoque cualitativo ya que se necesita determinar el grado de aceptación de
las mejoras que se obtendrán al pasar de procedimientos realizados de
manera semi computarizado a procesos completamente automatizados,
información que se obtendrá mediante los instrumentos que se aplicarán a
cada uno de los integrantes.
18
MARCO TEÓRICO
1. Sistemas de información.
Los sistemas de información (SI) están cambiando la forma que operan 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 y, lo que es más
importante, facilitan el logro de ventajas competitivas a través de su
implementación en las empresas.
Un sistema de información está constituido por personas, datos que generan

información en una organización, e incluso pueden incluir procesos manuales
y automatizados. Un sistema de información realiza cuatro actividades básicas
que son: entrada, almacenamiento, procesamiento y salida de información.
Según Laudon & Laudon (2012) ve un sistema de información como un

conjunto de componentes interrelacionados que recolectan (o recuperan),
procesan, almacenan y distribuyen información para apoyar los procesos de
toma de decisiones y de control en una organización. Además de apoyar la
toma de decisiones, la coordinación y el control, los sistemas de información
también pueden ayudar a los gerentes y trabajadores del conocimiento a
analizar problemas, visualizar temas complejos y crear nuevos productos.
(pág. 15)
Los sistemas de información contienen datos sobre personas, lugares y cosas

importantes dentro de la organización, o en el entorno que la rodea. Por
información se hace referencia a los datos que se han modelado en una forma
significativa y útil para los seres humanos. Por el contrario, los datos son flujos
de elementos en bruto que representan los eventos que ocurren en las
19
organizaciones o en el entorno físico antes de ordenarlos e interpretarlos en
una forma que las personas puedan comprender y usar.
Según Laudon & Laudon (2012) La introducción de un nuevo sistema de

información implica mucho más que nuevo hardware y software. También
implica cambios en los trabajos, habilidades, administración y organización. Al
diseñar un nuevo sistema de información, se rediseña la organización. Los
creadores de sistemas deben comprender la forma en que un sistema afectará
a los procesos de negocios específicos y a la organización como un todo. (pág.
489)
2. Tipos de sistemas de información.
Debido a que el principal uso que se da a los SI es el de optimizar el desarrollo

de las actividades de una organización con el fin de ser más productivos y
obtener ventajas competitivas, puesto que hay distintos intereses,
especialidades y niveles en una organización, hay distintos tipos de sistemas.
Ningún sistema individual puede proveer toda la información que necesita una
organización.
2.1. Sistemas de información y procesamiento de datos.
Los sistemas de Información de procesamiento de datos, son un conjunto de

métodos y procedimientos que permiten obtener información, estos métodos
pueden ser distinguidos entre manuales, electromecánicos y electrónicos.
Según Heredero (2008) son los sistemas básicos de negocio que dan servicio
al nivel operativo de la organización. Es un sistema computarizado que efectúa
y registra las transacciones diarias para dirigir negocios (pág. 113.)
20
2.2. Procesos de sistemas de información.
El propósito global de los sistemas de información es ayudar a los empleados

de una empresa a obtener y utilizar la información, a comunicarse con otras
personas dentro y fuera de la empresa y tomar decisiones eficaces.
Un sistema de información realiza cuatro actividades básicas:
 Entrada de información: proceso en el cual el sistema toma los datos

que requiere.
 Almacenamiento de información: puede hacerse por computadora o
archivos físicos para conservar la información.
 Procesamiento de la información: permite la transformación de los datos
fuente en información que puede ser utilizada para la toma de
decisiones
 Salida de información: es la capacidad del sistema para producir la
información procesada o sacar los datos de entrada al exterior.
Según Valencia (2015) Los sistemas de información en las organizaciones

capturan y administran datos para producir información útil que respalda a la
misma organización y sus empleados, clientes, proveedores y socios. Muchas
organizaciones consideran que los sistemas de información son esenciales
para su capacidad de competir u obtener una ventaja competitiva.
3. Ingeniería Web
La ingeniería web es la aplicación de metodologías sistemáticas, disciplinadas

y cuantificables al desarrollo eficiente, operación y evolución de aplicaciones
de alta calidad en la World Wide Web.
21
Rodriguez (2009). Comenta que la Ingeniería Web (IWeb) aplica “sólidos
principios científicos, de ingeniería y de administración, y enfoques
disciplinados y sistemáticos para el desarrollo, despliegue y mantenimiento
exitoso de sistemas y aplicaciones basados en Web de alta calidad”.
Actualmente existen millones de sitios web que cubren diferentes necesidades
de la vida, seguramente la comunicación es la más importante teniendo en
cuenta que las distancias pasaron a un segundo plano.
Otra definición de la IWEB es la que plantea S. Murugesan, Y. Deshpande, S.

Es el proceso utilizado para crear, implantar y mantener aplicaciones y
sistemas Web de alta calidad.
De hecho la WWW (World Wide Web) se ha establecido como una plataforma

común para el desarrollo de sistemas de software. Las aplicaciones Web se
han generalizado y se encuentran desarrollos importantes en diferentes
ámbitos de la vida humana tales como la economía, industria, educación,
administración pública, etc.
3.1. Proceso de la Ingeniería Web.
La inmediatez, evolución y crecimiento continuos, son características de las

aplicaciones Web, esto nos lleva a un proceso incremental y evolutivo, que
permite que el usuario se involucre activamente, facilitando el desarrollo de
productos que se ajustan a sus requerimientos.
Según Pressman 2015) enumera siete actividades que forman parte del
proceso de la IWeb y que son aplicables a cualquier aplicación web
independientemente de su tamaño y complejidad. (pág. 183) Las mismas son:
22
1. La formulación identifica objetivos y establece el alcance de la primera
entrega.
2. La planificación genera la estimación del coste general del proyecto,
la evaluación de riesgos y el calendario del desarrollo y fechas de
entrega.
3. El análisis especifica los requerimientos e identifica el contenido.
4. La modelización se compone de dos secuencias paralelas de tareas.
Una consiste en el diseño y producción del contenido que forma parte
de la aplicación. La otra, en el diseño de la arquitectura, navegación e
interfaz de usuario. Es importante destacar la importancia del diseño de
la interfaz. Independientemente del valor del contenido y servicios
prestados, una buena interfaz mejora la percepción que el usuario tiene
de éstos.
5. En la generación de páginas se integra contenido, arquitectura,
navegación e interfaz para crear estática o dinámicamente el aspecto
más visible de la aplicación: las páginas.
6. El test busca errores en todos los niveles: contenido, funcional,
navegacional, rendimiento, etc. El hecho de que las aplicaciones
residan en la red, y que inter operen en plataformas muy distintas, hace
que el proceso de test sea especialmente difícil.
7. Finalmente, el resultado es sometido a la evaluación del cliente.
3.2. Diferencia con la Ingeniera de Software.
Una de las principales diferencias es que la Ingeniería Web para el desarrollo

de una aplicación web es un esfuerzo multidisciplinario debido al manejo de
múltiples formatos, con una mezcla de atención social para saber su efecto
ético y legal.
23
Según Rodriguez (2009) define como Ingeneria de software como la disciplina
o área de la informática que ofrece métodos y técnicas para desarrollar y
mantener software de calidad. (pág. 9.)
La Ingeniería Web (IWeb) está relacionada con el establecimiento y utilización

de principios científicos, de ingeniería y de gestión, y con enfoques
sistemáticos y disciplinados del éxito del desarrollo, empleo y mantenimiento
de sistemas y aplicaciones basados en web de alta calidad.
La Ingeniera Web no es un clon de la Ingeniera de Software. El desarrollo de

aplicaciones web es distinto respecto al desarrollo de software de otras
categorías.
Según Rodriguez (2009) en muchas ocasiones, en el desarrollo de

aplicaciones web, se aplican, herramientas de Ingeniería de Software, sin
tener en cuenta que contienen características especiales como: usabilidad,
navegabilidad, seguridad, mantenimiento, escalabilidad, entre otras. (pág. 13.)
3.3. Tecnología en el desarrollo web.
Gallego Micael (2014) Desarrollo de aplicaciones web, Universidad Rey Juan

Carlos, España expresa que: El desarrollo de aplicaciones web ha
evolucionado enormemente en la última década, tanto desde el punto de vista
del desarrollo de software como a nivel de administración de sistemas. Se han
creado multitud de tecnologías, frameworks de desarrollo de aplicaciones,
bibliotecas, aplicaciones configurables, arquitecturas, modelos de publicación
de versiones (Pág.3.)
24
Layouts aplicación para CSS
Layouts es un sencillo simple Creador de CSS que puede ser usado para crear
web, soporta estándares de diseños de página. Layouts se inspiró en Yahoo!
‘s Grids CSS y oece 5 opciones predefinidas de anchos que soporta ancho
tipo líquido o fijo.
Layouts también tiene una web basada en patrones prediseñados que fue
desarrollado para el navegador Firefox. Precaución: el diseño de patrones está
todavía en sus primeras etapas de desarrollo, por lo que puede generar
algunos errores.
Lenguaje del lado del servidor y del cliente.
Adebal de la Torre (2006) afirma que los lenguajes de lado servidor son
aquellos lenguajes que son reconocidos, ejecutados e interpretados por el
propio servidor y que se envían al cliente en un formato comprensible para él
(Pág.1.)
Por otro lado, los lenguajes de lado cliente (entre los cuales no sólo se
encuentra el HTML sino también Java y JavaScript los cuales son simplemente
incluidos en el código HTML) son aquellos que pueden ser directamente
"digeridos" por el navegador y no necesitan un pre- tratamiento.
Cada uno de estos tipos tiene por supuesto sus ventajas y sus inconvenientes.
Así, por ejemplo, un lenguaje de lado cliente es totalmente independiente del
servidor, lo cual permite que la página pueda ser albergada en cualquier sitio
sin necesidad de pagar más ya que, por regla general, los servidores que
aceptan páginas con scripts de lado servidor son en su mayoría de pago o sus
prestaciones son muy limitadas.
25
Lenguajes del lado del servidor
C# es un lenguaje elegante, con seguridad de tipos y orientado a objetos, que

permite a los desarrolladores crear una gran variedad de aplicaciones seguras
y sólidas que se ejecutan en .NET Framework .NET. Puede usar C# para crear
aplicaciones cliente de Windows, servicios web XML, componentes
distribuidos, aplicaciones cliente-servidor, aplicaciones de base de datos y
muchas, muchas más cosas. Visual C# proporciona un editor de código
avanzado, prácticos diseñadores de interfaz de usuario, un depurador
integrado y muchas otras herramientas que facilitan el desarrollo de
aplicaciones basadas en el lenguaje C# y .NET Framework. (Microsoft, 2015)
Active Server Pages (ASP):
Es una tecnología del lado servidor de Microsoft para páginas web generadas
dinámicamente, que ha sido comercializada como un anexo a Internet
Information Server (IIS). EL estándard ASP permite utilizar cualquier lenguaje
para la programación, si bien Microsoft favorece que se utilice el VBScript, y
en segundo término el JScript (versión del estándard Javascript hecha por
Microsoft). (gallego Micael 2014.)
Lenguajes del lado del cliente.
Según el Instituto Tecnológico de Matehuala, Programación web, México

(2012): Los lenguajes de programación del lado cliente se usan para su
integración en páginas web. Un código escrito en un lenguaje de script se
incorpora directamente dentro de un código HTML y se ejecuta interpretado,
no compilado. (Pág. 102)
26
Con la programación del lado del cliente se pueden validar algunos de los
datos en la máquina cliente antes de enviarlos al servidor. Esto proporciona a
los usuarios informes de error inmediatos, mientras siguen en esa página de
formulario y sin necesidad de volver atrás tras recibir un mensaje de error.
Puede resultar necesario acceder a una base de datos para validar
determinados valores, mientras que no suele disponer de un acceso directo a
la base de datos en la máquina del cliente, aunque ese acceso a la base de
datos es factible.
Instituto Tecnológico de Matehuala, Programación web, México (2012)

expresa que significa que un código escrito en un lenguaje de script no sufre
ninguna transformación previa a su ejecución. Cada línea de código es
traducida a lenguaje máquina justo antes de su ejecución. Después es
ejecutada y la traducción no se conserva en ningún sistema de
almacenamiento (como discos, cintas, etc.)
JavaScript:
JavaScript es un lenguaje de scripts compacto basado en objetos (y no

orientado a objetos). Originariamente era denominado LiveScript, y fue
desarrollado por Netscape para su navegador Netscape Navigator 2.0. Fue
éste el primer cliente en incorporarlo. Se ejecuta sobre 16 plataformas
diferentes, incluyendo los entornos de Microsoft. (Instituto Tecnológico de
Matehuala, Programación web, México ,2012.)
Por ejemplo, una aplicación escrita en JavaScript puede ser incrustada en un

documento HTML proporcionando un mecanismo para la detección y
tratamiento de eventos, como pulsación del ratón o validación de entradas
realizadas en formularios. Sin existir comunicación a través de la red una
página HTML con JavaScript incrustado puede interpretar, y alertar al usuario
con una ventana de diálogo, de que las entradas de los formularios no son
27
válidas. O bien realizar algún tipo de acción como ejecutar un fichero de
sonido, un applet de Java, etc. (Instituto Tecnológico de Matehuala,
Programación web, México ,2012.)
3.4. Motores de bases de datos.
Yomar Altamar (2013), expresa que: Los Motores de Bases de Datos, son
programas específicos, dedicados a servir de intermediarios entre las bases
de datos y las aplicaciones que las utilizan como función principal, cada uno
de estos cumple una tarea específica, que van desde crear la Base de Datos
hasta administrar el uso y acceso a ésta (Pg. 9.)
Un MBD está compuesto principalmente por tres lenguajes, siendo estos DDL
(Lenguaje de definición de datos), DML (Lenguaje de manipulación de datos),
y finalmente el SQL (Lenguaje de consulta.)
Principal motor de bases de datos.
Microsoft® SQL Server™ es un sistema de administración y análisis de bases

de datos relacionales de Microsoft para soluciones de comercio electrónico,
línea de negocio y almacenamiento de datos. En esta sección, encontrará
información sobre varias versiones de SQL Server. También encontrará
artículos sobre bases de datos y aplicaciones de diseño de bases de datos,
así como ejemplos de los usos de SQL Server. (Microsoft, 2015)
Entornos de desarrollo integrados.
Microsoft Visual Studio 2012 es un conjunto de herramientas para crear

software, desde la fase de diseño pasando por las fases de diseño de la
interfaz de usuario, codificación, pruebas, depuración, análisis de la calidad y
28
el rendimiento del código, implementación en los clientes y recopilación de
telemetría de uso. Estas herramientas están diseñadas para trabajar juntas de
la forma más eficiente posible y todas se exponen a través del Entorno de
desarrollo integrado (IDE) de Visual Studio. (Microsoft, 2013)
4. Ingeniería web basada en UML (UWE.)
Modelos.
Según Cachero Castro (2008), UWE es una propuesta basada en el proceso

unificado y UML pero adaptados a la web. En requisitos separa las fases de
captura, definición y validación. Hace además una clasificación y un
tratamiento especial dependiendo del carácter de cada requisito. OO-H: Una
extensión de los métodos OO para el modelado y generación automática de
interfaces hipermedia (pg. 28.)
Según Schwabe G. Rossi (2008), es una metodología detallada para el

proceso de autoría de aplicaciones con una definición exhaustiva del proceso
de diseño que debe ser utilizado. Este proceso, iterativo e incremental,
incluye flujos de trabajo y puntos de control, y sus fases coinciden con las
propuestas en el Proceso Unificado de Modelado. UWE está especializada
en la especificación de aplicaciones adaptativas, y por tanto hace especial
hincapié en características de personalización, como es la definición de un
modelo de usuario o una etapa de definición de características adaptativas
de la navegación en función de las preferencias, conocimiento o tareas de
usuario. Desarrollo de Aplicaciones Hipermedia con OOHDM. Taller sobre el
Proceso de Desarrollo de Hipermedia, Métodos y Modelos, Hypertext98,
Pittsburg, EE.UU (Pg. 31.)
29
Otras características relevantes del proceso y método de autoría de UWE
son el uso del paradigma orientado a objetos, su orientación al usuario, la
definición de una meta-modelo (modelo de referencia) que da soporte al
método y el grado de formalismo que alcanza debido al soporte que
proporciona para la definición de restricciones sobre los modelos.
El método y sus seis modelos:
1. Modelo de casos de uso para capturar los requisitos del sistema.

2. Modelo conceptual para el contenido (modelo del dominio.)
3. Modelo de usuario: Modelo de navegación que incluye modelos estáticos
y dinámicos.
4. Modelo de estructura de presentación, modelo de flujo de presentación.
5. Modelo abstracto de interfaz de usuario y modelo de ciclo de vida
del objeto.
6. Modelo de adaptación.
Modelo de casos de usos.
De acuerdo con la Universidad Nacional de la Plata (2009), La calidad de

datos es considerada un aspecto importante en relación con el éxito o fracaso
de las tareas cotidianas en una organización. Hoy en día, la mayoría de estas
tareas se encuentran soportadas por aplicaciones de software, Metodologías
de diseño usadas en ingeniería web, su vinculación con las NTICS (Pg. 75).
La especificación temprana de los requisitos que deben cumplir esas

aplicaciones es un desafío para la Ingeniería del Software.
30
Dichos requisitos serán capturados desde modelos de procesos de negocio
descritos con BPMN (Business Process Model and Notation), y expresados
mediante casos de uso de UML (Unified Model Language.)
Con este propósito se propone un método mediante el cual, de manera

ordenada y sistemática, los expertos del negocio pueden modelar procesos
de negocio consciente de la calidad de datos y obtener desde dichos modelos
artefactos útiles para la creación de software.
Según Hammon & Wolf(2011) y Recker, (2010), Los lenguajes más usados
para el modelado de BP son UML y BPMN, siendo este último el más utilizado
en la industria por lo que es ampliamente reconocido como el estándar de
facto para el modelado de BP.
Bocciarelli & D’Ambrogio(2011), entre las extensiones propuestas en la

literatura se pueden mencionar algunas orientadas a: expresar algunas
necesidades de los clientes, tales como tiempo, costo y fiabilidad, especificar
propiedades no funcionales como desempeño y fiabilidad, así mismo modelar
requisitos de seguridad en BP, representar explícitamente restricciones
legales (Goldner&Papproth, 2011), analizar el desempeño de los procesos
de negocio (Lodhi, Veit, &Saake, 2011) y expresar requisitos de calidad de
datos, entre otras.(Págs. 19-22.)
Modelo conceptual para el contenido.
Un concepto para este caso, en términos de la Programación Orientada a

Objetos, es un objeto del mundo real; es decir, es la representación de cosas
del mundo real y no de componentes de software.
31
Informalmente se puede decir que un concepto es una idea, cosa u objeto.
Para descubrirlos se debe analizar los sustantivos en las descripciones
textuales del dominio del problema, es decir, de la descripción del sistema,
de los requerimientos y de los Casos de uso.
Modelo de usuario
Según Bocciarelli & D'Ambrogio (2011), la arquitectura de la interfaz de

usuario se define teniendo en cuenta diferentes aspectos que introducen
modelos para soportar el modelado de rol usuario, el modelado de contexto,
el modelado de tareas, el modelado de dominio y los modelos de
presentación. Nuestro principal interés en el desarrollo de la interfaz de
usuario se centra en los modelos de presentación de la interfaz de usuario
como factor esencial incluso para Desarrollo basado en modelos de la
interfaz de usuario de sistemas propiedades no funcionales como
desempeño y fiabilidad (Pg.24.)
Se definen cuatro etapas para la presentación de la interfaz de usuario: en la

primera etapa, el modelo de contexto de la interfaz de usuario que define los
componentes de la presentación de la interfaz de usuario en una forma
menos detallada y de manera general. Cada etapa añade información más
detallada hasta llegar a una interfaz de usuario final.
Un modelo de dominio especifica los datos que los usuarios manipulan

acerca de las entidades del mundo real y sus interacciones tal como son
entendidas por los usuarios en relación con las acciones que son posibles
sobre estos conceptos.
De acuerdo con J. William & C. Collazos (2009), la arquitectura de la interfaz

de usuario se define teniendo en cuenta diferentes aspectos que introducen
32
modelos para soportar el modelado de rol-usuario, el modelado de contexto,
el modelado de tareas, el modelado de dominio y los modelos de
presentación. (Pg. 198.)
Se usarán los diagramas de clases UML como la base para expresar un

modelo de dominio, ya que es el estándar de facto en modelado de
diagramas de clases.
Un modelo de usuario se compone de una lista de roles de usuario

identificados. Un rol de usuario es un conjunto de usuarios que comparten
características similares y que pueden ser dispuestos de forma jerárquica. La
información del usuario representa un conjunto de intereses comunes, sus
conductas y responsabilidades.
Un modelo de usuario se define por la comprensión del uso del sistema y son
muy indicados para alcanzar fines de usabilidad. Ellos identifican y
representan los aspectos esenciales de las necesidades y requerimientos de
los usuarios.
Modelo de estructura de presentación.
Según Cristina Cachero Castro (2008), OO-H: Una extensión de los métodos
OO para el modelado y generación automática de interfaces hipermedia.’ Un
diagrama de estructura compuesta es un diagrama que muestra la estructura
interna de un clasificador, incluyendo sus puntos de interacción a otras partes
del sistema’’. Esto muestra la configuración y relación de las partes que juntas
realizan el comportamiento de clasificador contenido (Pg. 14.)
33
Modelo abstracto de interfaz
Diseño de interfaz abstracta
J. William & C. Collazos (2009), Las interfaces de usuario abstractas modelan

información que es independiente de la modalidad en la cual será
implementada la interfaz. Estas corresponden a modelos que son
independientes de la tecnología en la cual se decide realizar la interfaz de
usuario final.
(Pg.204.)
Una separación ordenada entre ambas preocupaciones, de navegación y

diseño de interfaz abstracta, permite construir interfaces diferentes para el
mismo modelo de navegación, llevando a un grado más alto de
independencia de tecnología de la interfaz de usuario. En suma, esta
separación permite entender mejor la aplicación global de la estructura para
indicar qué transformaciones claramente en la interfaz serán
transformaciones navegacionales.
Ellos relegan la especificación para herramientas de implementación-

dependientes, y por consiguiente las decisiones de diseño en este nivel
raramente se documentan. Es más, como llevar a cabo la interfaz de la web
normalmente se hacen aplicaciones por medio de los editores de HTML
especializados, muchos críticos pueden ignorar aspectos de la interfaz
En OOHDM, se usa un acercamiento del diseño de datos de vista abstractos

(ADVs), para describir la interfaz del usuario de una aplicación de hipermedia
ADVs son objetos en los que tienen un estado y una interfaz, donde la interfaz
34
puede ser ejercido a través de mensajes (en particular, eventos externos
generados por el usuario).
Las ADVs son abstractas en el sentido de que ellos sólo representan la

interfaz y el estado, y no la aplicación. Las ADVs han sido usados para
representar interfaces entre dos medios de comunicación diferentes como un
usuario, una red o un dispositivo (un cronómetro, por ejemplo) o como una
interfaz entre dos o más objetos de datos abstractos (ADOs.)
Los ADOs son objetos que no soportan externamente eventos generados por
el usuario [Cowan 95]. Desde un punto de vista arquitectónico, las ADVs son
observadores para ADOss, para que el protocolo de comunicación entre la
interfaz y los objetos de aplicación siga las reglas descritas en el modelo de
diseño de observador [Gamma 95].
Un ADV usado en el diseño de aplicaciones web puede verse como un objeto

de interfaz. Comprende un conjunto de atributos (y objetos de interfaz
anidado) qué define sus propiedades de percepción, y el conjunto de eventos
que puede manejar, como eventos generados por el usuario. Los ejemplos
de eventos generados por el usuario son MouseClick, MouseDoubleClick,
MouseOn, etc.
De acuerdo con Schwabe, G. Rossi (2008). Pueden definirse valores del

atributo como constantes y pueden definirse estilos particulares de apariencia
como posición, color, o sonido. Los modelos de interfaz ADV unen al modelo
que permite tratar estos rasgos de una manera abstracta y los relega al paso
de la aplicación. Las ADVs pueden ser fácilmente implementadas en
ambientes orientados a objetos para el web o puede traducirse a documentos
HTML (Pg.17.)
35
En general, los ADVs especifican la organización y el comportamiento de la
interfaz, pero la apariencia física real o de los atributos, y el diseño de la ADV
en la pantalla real se hace en la fase de la implementación. En el contexto de
OOHDM, los objetos de navegación como nodos, e índices actuarán como
ADOs, y su ADVs asociados se usará para especificar su apariencia al
usuario.
Cuando se implementa esta aplicación web usando un ambiente de soporte

de ciertos tipos de objetos de interfaz, se puede usar como ADVs primitivos
para producir esta especificación de diseño.
Ventajas del uso del UWE.
Una de las ventajas que UWE extienda el estándar UML es la flexibilidad de

éste para la definición de un lenguaje de modelado específico para el dominio
web y sobretodo la aceptación universal de dicho estándar en el campo de la
Ingeniería del Software.
Permite especificar de mejor manera una aplicación web en su proceso de

creación mantiene una notación estándar basada en el uso de UML (Unified
Modeling Language para sus modelos y sus métodos, lo que facilita la
transición.
La metodología define claramente la construcción de cada uno de los

elementos del modelo y mantiene una notación estándar basada en el uso de
UML (Unified Modeling), además de almacenar las propiedades que describen
a los diferentes tipos de usuarios.
Otra gran ventaja es que actualmente existen múltiples herramientas CASE

basadas en UML, con lo cual es relativamente sencillo su utilización y
36
ampliación para utilizar los objetos de modelado definidos en UWE. Éste, hace
uso de notación UML pura y los tipos de diagramas UML en donde sea posible
para el análisis y diseño de aplicaciones web. En adición, la extensión de UWE
cubre la navegación, presentación, lógica del negocio y aspectos de
adaptación. La notación UWE se define como una extensión "ligera" de UML.
5. Aspectos metodológicos.
5.1. Metodología de la iWeb.
5.1.1. Ingeniería Web
Según manifiesta la Universidad Nacional de la Plata, Argentina (2009), la

Ingeniería Web (IWeb) aplica “sólidos principios científicos, de ingeniería y
de administración, y enfoques disciplinados y sistemáticos para el desarrollo,
despliegue y mantenimiento exitoso de sistemas y aplicaciones basados en
web de alta calidad” (Pg. 32.)
Según expresa Granollers, T., et al. Integración de la IPO y la Ingeniería de

Software: Taller en Sistemas Hipermedia Colaborativos y Adaptativos (2007).
Granada España, el avance de Internet y las nuevas tecnologías de
comunicación, marcan una nueva tendencia en el mercado del software. La
exigencia de los usuarios, cada vez más numerosos, hizo que Internet
creciera en forma acelerada y desprolija, produciendo un impacto social,
económico y político impensado (Pg. 42.)
El nacimiento de las aplicaciones web no se hizo esperar, aquellos sitios que

en un comienzo fueron sólo páginas informativas, se vieron obligadas a
brindar a sus visitantes algún tipo de servicio que conjugue páginas planas
37
con datos almacenados. Todo este proceso, caótico, dio lugar al nacimiento
de sitios no planificados en los que no se empleó una metodología apropiada.
5.1.2. Fases de la IWeb.
La inmediatez, evolución y crecimiento continuos, son características de las

aplicaciones web, esto nos lleva a un proceso incremental y evolutivo, que
permite que el usuario se involucre activamente, facilitando el desarrollo de
productos que se ajustan a sus requerimientos.
Pressman (2015) enumera siete actividades que forman parte del proceso de
la IWeb y que son aplicables a cualquier aplicación web independientemente
de su tamaño y complejidad. Las mismas son:
5.1.2.1. Formulación.
Identifica objetivos y establece el alcance de la primera entrega. Identificar

los requerimientos y metas de la empresa para la construcción de la
aplicación web mediante el uso de entrevistas, cuestionarios y muestreo.
5.1.2.2. Planificación
Estimar el costo global del proyecto y evaluar los riesgos asociados al

desarrollo de la aplicación.
1. Definir el ámbito y los recursos de los gestores de la Ingeniería Web,

personal técnico y cliente.
2. Definir los costos y planificación temporal para la revisión de la gestión.
3. Proporcionar un enfoque general del desarrollo de la Iweb para todo el
personal relacionado con el proyecto.
4. Describir cómo se garantizará la seguridad de la aplicación.
38
5.1.2.3. Análisis.
Establecer los requisitos técnicos para la aplicación web, identificar los

elementos del contenido y requisitos de diseño gráfico que se van a incorporar
mediante cuatro tipos de análisis.
➢ Análisis de contenido.
Se trata de la investigación del espectro completo de contenido que se va a
proporcionar tales como: datos de texto, gráficos, imágenes, vídeo y sonido.
➢ Análisis de interacción.
Descripción detallada de la interacción del usuario y la web.
➢ Análisis funcional.
Descripción detallada de todas las funciones y operaciones.
➢ Análisis de configuración.
Descripción del entorno y de la infraestructura en donde reside la web.
Diseño arquitectónico.
Definición de la estructura global hipermedia para la aplicación web, y en la

aplicación de las configuraciones de diseño y plantillas constructivas para
popularizar la estructura (y lograr la reutilización.)
Diseño del contenido.
Estructura y formato detallados del contenido de la información que se

presentará. Las estructuras pueden ser lineales, reticulares, jerárquicas y las
estructuras de red o de web pura.
39
Diseño de navegación.
Definir las rutas de navegación que permitan al usuario acceder al contenido

y a los servicios de la aplicación.
1. Identificar la semántica de la navegación para diferentes usuarios del

sitio.
2. Definir la mecánica (sintaxis) para lograr la navegación.
Diseño de interfaz de usuario.
El diseño identifica los objetos y las acciones de la interfaz y crea entonces un

formato de pantalla que formará la base del prototipo de interfaz de usuario. El
diseño de la interfaz comienza con la identificación de los requisitos del
usuario, de la tarea y el entorno.
Generación de páginas.
Es una actividad de construcción que hace mucho uso de las herramientas

automatizadas para la creación de la web.
6. Etapas de pruebas.
Busca errores en todos los niveles: contenido, funcional, navegacional,

rendimiento, etc. El hecho de que las aplicaciones residan en la red y que
interpelen en plataformas muy distintas, hace que el proceso de test sea
especialmente difícil.
Finalmente, el resultado es sometido a la evaluación del cliente. Una de las

tareas colaterales que forman parte del proceso es el control y garantía de la
calidad. Este proceso, que se cumple en la Ingeniería de Software tradicional,
40
implica actividades tales como: establecimiento y supervisión de estándares,
revisiones técnicas formales, análisis, seguimiento y registro de informes, etc,
son igualmente aplicables a la Ingeniería web. Sin embargo, en la Web toman
especial relevancia para valorar la calidad, aspectos como: usabilidad,
funcionalidad, fiabilidad, seguridad, eficiencia y mantenibilidad.
7. Arquitectura web.
Algunos investigadores definen a la arquitectura de un sistema de software

como el conjunto de decisiones de diseño tomadas para el sistema (RN Taylor,
N. Medvidovic, EM Dashofy , 2009). Haciendo una análoga con la construcción
de edificios, se puede decir que la arquitectura representa los planos (de
diseño, de organización y de construcción) del software.
La arquitectura de software (Mora, 2011, pág. 39) es una pieza central del
desarrollo de sistemas de software modernos. El objetivo de la arquitectura
consiste en desarrollar sistemas de software grandes de forma eficiente,
estructurada y con capacidad de reuso. La arquitectura forma parte del
proceso de diseño de software el cual también forma parte del proceso de
desarrollo de software que comprende, requerimientos, diseño,
implementación, prueba y mantenimiento.
La arquitectura de software nos ayuda a comprender mejor las necesidades
que debe de cumplir el producto de software.
La arquitectura web (Ferrer, 2012), es la disciplina encargada de estructurar,

organizar y etiquetar el contenido como también establecer los puntos de
acceso, sistemas de búsqueda y recuperación de información de cualquier
aplicación soportada en la Web, con el fin de que el usuario cumpla con los
objetivos y su experiencia sea óptima. De la misma forma en que los
41
arquitectos tradicionales diseñan y coordinan la construcción de edificios, los
arquitectos web diseñan y coordinan el desarrollo de sitios web.
7.1. Arquitectura en capas.
El patrón multicapa descompone una aplicación monocapa en varias capas.

El objetivo principal es separar los componentes de acuerdo con su función,
por ejemplo, en las aplicaciones hay componentes encargados de la
presentación, otros de la lógica de negocio y otros de la persistencia de los
datos.
En ocasiones se confunde el término “capas” (Mora, 2011, pág. 44) con el

término “nivel”. El primer término se utiliza para referenciar las distintas
“partes” en las que una aplicación se divide desde el punto de vista lógico,
mientras que el segundo término corresponde a la forma física en que una
aplicación se organiza.
Un ejemplo muy simple y que es muy común encontrar, es una aplicación que
tiene dos niveles (nivel de aplicación y nivel de datos), en donde cada nivel
puede tener varias capas. (Mora, 2011, pág. 44)
En este caso, el nivel de aplicación puede estar constituido por la capa de

presentación y por la capa de lógica de negocio y el nivel de datos puede
contener solo la capa de datos.
Esta interfaz permite a la capa de lógica de negocio proveer los recursos que
necesita la capa de presentación. Las capas inferiores se encargarán de
brindar sus servicios a las capas superiores por medio de sus interfaces.
42
Al separar una aplicación en capas y niveles permite modificar de forma
independiente cada capa. De acuerdo al nivel de complejidad de la aplicación
se pueden seguir incorporando capas o niveles de acuerdo a las necesidades.
(Mora, 2011, pág. 44.)
Modelo de tres capas.
La arquitectura está basada en un modelo de tres capas: capa de datos, capa

de lógica de negocio y capa de presentación, que soportan todas las
funcionalidades necesarias (NEWCOMLAB, 2013.)
Capa de datos.
Sobre un modelo de base de datos predefinido sobre el que se aplican las

distintas especificaciones de datos tales como categorías, subcategorías,
colecciones, productos, datos de los productos, etc. Dicho modelo puede
nutrirse de la exportación de los datos contenidos en diferentes aplicaciones
de base de datos, como Microsoft SQL Server.
El repositorio de datos descansa sobre XML para la correcta construcción

posterior de la capa de presentación y está formada por uno o más gestores
de bases de datos que realizan todo el almacenamiento de datos, reciben
solicitudes de almacenamiento o recuperación de información desde la capa
de negocio. (Mora, 2011, página 34.)
Capa de lógica de negocio.
En esta capa se establecen todas las reglas que deben cumplirse en el

comercio electrónico. Esta capa se comunica con la capa de presentación,
para recibir las solicitudes y presentar los resultados, y con la capa de datos,
43
para solicitar al gestor de base de datos almacenar o recuperar datos de él.
(NEWCOMLAB 2013.)
Capa de presentación.
Por último, existe una tercera capa denominada de presentación, en la que se

representan todos los aspectos relacionados con la presentación y diseño de
la solución. (NEWCOMLAB 2013.)
44
CAPÍTULO I:
ENFOQUE SISTÉMICO.
45
1. ASPECTOS ORGANIZACIONALES.
1.1. Misión del TSIS.
La Facultad de Ciencias y Sistemas de la Universidad Nacional de Ingeniería

se ha propuesto crear la carrera de Técnico Superior en Informática y
Sistemas, dirigida a estudiantes egresados de la educación media, con el
objetivo de formar técnicos competentes a nivel superior en las especialidades
de informática y administración, capaces de gestionar conocimiento de forma
autónoma y permanente con valores éticos, morales y sociales, que les
permitan contribuir en la elaboración de soluciones informáticas y de gestión
administrativa asociadas con el área de desarrollo, mejoramiento y evaluación
de sistemas empresariales, en contextos heterogéneos y cambiantes,
mediante un plan de estudio actualizado, un cuerpo docente especializado y
una infraestructura adecuada.
1.2. Visión del TSIS.
Consolidar la carrera Técnico Superior en Informática y Sistemas de la

Facultad de Ciencias y Sistemas de la Universidad Nacional de Ingeniería,
como una carrera autosuficiente, alternativa viable y eficaz a las necesidades
y demandas del mercado laboral en la formación Técnico superior con un
cuerpo docente altamente calificado y una infraestructura adecuada.
46
1.3. ESTRUCTURA ORGANIZACIONAL DEL TSIS.
En la estructura organizacional que posee la Facultad de Ciencias y Sistemas

del Recinto Universitario Pedro Aráuz Palacios, se encuentra el Técnico
Superior de Informática y Sistemas TSIS, teniendo al coordinador como líder
del TSIS, quien coordina el programa, además, cuenta con un asistente el
cual se encarga de las gestiones académicas y otras tareas administrativas.
El organigrama Actual se encuentra estructurado de la siguiente manera:
Figura 1. Organigrama de la Facultad de Ciencias y Sistemas UNI.

Fuente: Diseño curricular de la carrera de Ingeniería de Sistemas mejorado y actualizado en 2015
Nota: el TSIS ocupa el lugar del Centro de Nivelación de Estudios Generales en el organigrama.
47
1.4. DEFINICIÓN DEL PROBLEMA.
Actualmente la administración y gestión académica de este técnico superior

se ha realizado de forma manual y semi computarizada con la ayuda de
distintas herramientas, lo que hace que la información esté descentralizada y
que no esté disponible al momento de generar informes académicos, que lo
solicitan en un tiempo determinado. Además, al tener la información en
distintas herramientas es más complejo hacer el cruce y limita la toma ágil de
decisiones.
La gestión se realiza a través de las herramientas: Microsoft Access 2010,

Microsoft Excel 2010, Microsoft Word 2010, con las que se realizan algunos
procesos académicos tales como: Registro de Estudiante, Matricula,
Inscripción de Asignatura, Registro de notas. Así mismo, otros procesos que
se ejecutan de forma manual, como la emisión de esquela y creación del ciclo
académico (carga académica, horario, grupo.)
48
1.4.1. Diagrama causa y efecto de la problemática en el TSIS.
COORDINACIÓN EQUIPO
Falta de iniciativa
en la innovación y
mejoras en los Los equipos
procesos. informáticos que se
utilizan actualmente
Estrategias enfocadas son de baja
fuera del ámbito
tecnológico.
DESCENTRALIZA
CIÓN DE LA
INFORMACIÓN
Los procesos ACADEMICA DEL
Se hacen de forma TSIS
Almacenamiento
manual y semi de información en
computarizados. diferentes
herramientas de
Software.
MÉTODO TECNOLOGIA
Figura 2. Diagrama de causa y efecto.
49
1.5. OBJETIVOS DEL SISTEMA.
De acuerdo con el análisis de requerimientos se obtuvieron los siguientes

objetivos del sistema:
 Gestionar estudiante.
 Gestionar docente.
 Gestionar asignaturas.
 Gestionar ciclo académico.
 Gestionar monografía.
 Gestionar reportes académicos.
1.6. DEFINICIÓN DE ACTORES.
Los actores del sistema de información son los que iniciarán acciones dentro
del mismo, estos se definen a continuación:
 El coordinador.
 Docente.
 Estudiante.
 Caja
Coordinador del TSIS:

 Generar reportes de cursos asignados a un
docente determinado.
 Consolidar matrículas por periodo del día.
 Gestionar docentes asignados a un grupo
determinado.
 Gestionar de suficiencias y monografía.
 Crear nuevo ciclo.
50
 Crear nuevo horario.
 Crear nuevo grupo.
Asistente de coordinación del TSIS:
 Registrar docente.
 Registrar estudiante.
 Registrar asignaturas.
 Registrar matrículas.
Docente:
 Registrar notas de los estudiantes por cursos a

cargos.
Docente
Estudiante:
 Realizar pago de matrícula, mensualidad y

solicitud de constancias.
 Solicitar de formas de culminación de estudios.
 Solicitar de suficiencias.
Caja:
 Efectuar el pago de los aranceles de los

estudiantes del TSIS.
Caja
51
CAPÍTULO II:
ESTUDIO DE FACTIBILIDAD.
52
2.1. FACTIBILIDAD TÉCNICA.
El estudio de factibilidad técnica consistió en realizar una evaluación de la

tecnología existente en la empresa, tanto hardware como software,
determinando los componentes técnicos que tiene actualmente el TSIS y los
componentes necesarios para la ejecución del sistema.
Se realizará una comparación entre ambos para definir aquellos componentes

existentes que pueden ser reutilizables y así establecer la cantidad exacta de
nuevos componentes a adquirir.
Antes de iniciar el desarrollo de una aplicación web, es recomendable analizar

las condiciones actuales con las que cuenta el TSIS donde se implementará,
para constatar si existen las condiciones técnicas necesarias, las cuales van
desde la realización del análisis del sistema hasta los recursos tecnológicos
necesarios para el desarrollo e implementación de la aplicación web. Una vez
conocidas, se puede comenzar a desarrollar la aplicación con la certeza que
al terminarlo, se encontrarán con todas las condiciones necesarias para su
implementación.
El Técnico Superior de Informática y Sistemas (TSIS), ofreció la

documentación técnica necesaria para desarrollar la aplicación web, de igual
manera permitió conocer el estado de los equipos informáticos en los que el
asistente de coordinación del TSIS y el coordinador del TSIS del Sistema
desarrollarán sus funciones y el servidor que almacenará los datos que
necesitará y generará la aplicación.
53
La documentación técnica estuvo suministrada por las siguientes personas:
Tabla 3.
Documentación técnica.
Tipo de información Fuentes de información Medio
Información general del TSIS Asistente de Coordinación del TSIS Documentado
Formato de registro académico Asistente de Coordinación del TSIS Documentado
Formato de pagos Asistente de Coordinación del TSIS Documentado
Especificaciones del Sistema Asistente de Coordinación del TSIS Documentado

Entrevista
Medios tecnológicos del TSIS Asistente de Coordinación del TSIS. Entrevista
Administración DTIC
Nota. Fuente: elaboración propia.
2.1.1. Requerimientos de hardware.
2.1.1.1. Hardware disponible.
Los medios tecnológicos con que cuenta actualmente el TSIS para la

administración es el siguiente:
Tabla 4.
Características técnicas de Computadora.
Computadora Sistema Memoria Velocidad CPU Tamaño del disco
operativo RAM duro
Usado Disponible
Pentium 4
PC1 Asistente de Windows 7 1GB 63.45 16.55 GB
3.00 GHZ
Coordinación del TSIS Ultimate 32 Bits GB
Nota. Fuente: Elaboración propia.
54
Tabla 5.
Características técnicas de Impresoras.
Impresora Marca Modelo
Impresora Multi Funcional. HP DeskJet F4218
Tabla 6.
Infraestructura de comunicación.
Infraestructura de comunicación
Estructura de red LAN
Router
2.1.1.2. Equipos por adquirir.
Se considera que el equipo disponible no es suficiente para que cumpla con

los requerimientos técnicos especificados, y se plantea que se debe actualizar
o renovar el equipo que actualmente ocupa el asistente de Coordinación, así
mismo, la adquisición de una máquina para el Coordinador TSIS, ya que solo
existe una máquina para un personal.
Tabla 7.
Equipos por adquirir.
Equipo SO Marca Ram Procesador Disco
Laptop1 Asistente de Coordinación del TSIS

Windows 10 Lenovo 4G Celeron 1TB
Laptop2 Coordinador general del TSIS
Nota. Cotizaciones (ver anexo 8.)
55
2.1.2. Requerimientos de software.
2.1.2.1. Software disponible.
Actualmente el TSIS dentro de sus recursos tecnológicos cuenta con

herramientas utilizadas para el registro de sus actividades académicas. Los
equipos tecnológicos detallados anteriormente tienen instalados las siguientes
aplicaciones básicas:
 Sistemas operativos Windows 7.

 Microsoft Office 2010.
 Navegador web Chrome 67.0 y Mozilla Firefox 52.0.2
2.1.2.2. Software necesario para ejecución del sistema.
Como se ha mencionado, el sistema está desarrollado en lenguaje C# como

Framework ASP.NET, con el Gestor de Base de Datos SQL Server
requerimiento a lado del servidor. En la siguiente tabla se muestran los
requerimientos de software para el funcionamiento del sistema en las
estaciones de trabajo:
Tabla 8.
Software necesario
Nombre Descripción
Sistema Operativo Windows 10
Acrobat Reader Lector de PDF
Explorador de Internet (Chrome o Firefox) Aplicación para la navegación en Internet.
56
2.1.3. Servicios disponibles
El principal medio de comunicación entre el TSIS, sus estudiantes y docentes

es el servicio de internet tanto en red local como en red wifi.
2.1.4. Servicios requeridos
Para el alojamiento exclusivo de la base de datos y la aplicación, el TSIS

tendrá soporte de parte de la División de Tecnología de la Información y
Comunicación. (ver anexo 7). Este servidor estará disponible para el TSIS y
que la aplicación pueda operar correctamente. Las especificaciones mínimas
necesarias de este servidor se describen a como sigue:
 Procesador: 3.60 GHz.

 Memoria: 8GB de RAM.
 Disco Duro: 500 GB.
 Sistema operativo: Windows server 2012/ Linux.
Con respecto a la seguridad del servidor web será necesario:
 Certificado Digital (SSL.)
Resultados obtenidos.
Para este estudio se determinaron los recursos disponibles para el TSIS y los
recursos requeridos de acuerdo a las necesidades del proyecto, equipo de
cómputo y alojamiento de la aplicación web. En lo que respecta a los equipos
de cómputo se realizó la cotización de dos laptops para el uso del asistente de
coordinación y el coordinador. Una de las ventajas es el apoyo por parte del
DTIC en proporcionar el alojamiento de la aplicación web sin incurrir en gastos,
además que el ambiente estará adaptado a las necesidades de la misma.
57
2.2. FACTIBILIDAD ECONÓMICA.
El estudio de factibilidad económica consiste en la determinación de costos de

los equipos que se debe adquirir, además se determinan los costos de
desarrollo mediante el COCOMO II y Puntos de Función; esto dará como
resultado un estimado de la inversión inicial que el TSIS deberá realizar para
la adquisición del software, en este caso, la aplicación web.
Para conocer el costo asociado al desarrollo de este, se utilizó la herramienta
COCOMO II (Modelo Constructiva de Coste), la cual, en base a estimación de
Puntos de Función, permite conocer el tiempo de desarrollo y la cantidad de
personal para realizarlo, para así poder estimar su valor.
2.2.1. Costos de equipos a adquirir.
Según lo visto anteriormente, se deberán adquirir un total de 2 computadoras

de escritorio y la distribución de las máquinas se muestra en la tabla n°6.
La siguiente tabla muestra la inversión que deberá hacer el TSIS para la

adquisición de los equipos señalados tomando como referencia los de menor
precio (Ver anexo 8.)
Tabla 9.
Inversión necesaria.
Personal Equipo Cantidad Costo Costo
Unitario Total
Laptop1 Asistente de NOT LENOVO 320 15.6" 1 $ 368.22 $ 368.22

Coordinación del TSIS N3350 CELERON
Laptop2 Coordinador general NOT LENOVO 320 15.6" 1 $ 368.22 $ 368.22

del TSIS N3350 CELERON
Costo Total $ 736.44
58
2.2.2. Estimación de costo del software.
Para esta etapa se hace uso COCOMO II, permitiendo determinar con cierto
grado de certeza, el costo del software (medidos en dólares $), tiempo de
desarrollo (días - semanas) y esfuerzo (t/hombre.)
Para el cálculo, primero mediremos el aproximado del tamaño del software

aplicando los puntos de función, donde se requerirá conocer las siguientes
características de dominio de información:
 Número de entradas de usuario.

 Número de salidas de usuario.
 Número de consultas de usuario.
 Número de archivos lógicos (ficheros.)
 Número de interfaces externas.
2.2.2.1. Metodología:
En esta sección se aborda el cálculo más fundamental en el modelo de COCOMO,

el uso de las ecuaciones de esfuerzo para estimar el número de personas-meses
exigido desarrollar un proyecto. La mayoría de los otros resultados de COCOMO,
incluso las estimaciones para la duración, requisitos y mantenimiento, se deriva
de esta cantidad.
Líneas de Código Fuente (SLOC.)

Los cálculos de COCOMO están basados en tu estimación del tamaño de un
proyecto, medio en las líneas de código fuente (SLOC.)
El manual de definición del modelo COCOMO II define las líneas de código fuente
usando listas de control adaptadas del Instituto de Ingenierías de software.
59
Existen herramientas que examinan archivos fuentes y cuentan las líneas de
código fuentes usando las definiciones de COCOMO II.
El modelo original COCOMO 81 fue definido en términos de instrucciones fuentes

entregadas, el cual es muy similar a líneas de código fuente. El modelo más
reciente de COCOMO II está definido en términos de líneas de código fuente. La
principal diferencia entre IFE y LCF es que una sola línea lógica de código fuente
puede ser varias líneas físicas.
A continuación, se muestra el detalle de las fórmulas aplicadas para el cálculo

de los puntos de función y de COCOMO (ver anexo 1), así como las tablas en
las que se establecen los valores de las variables, dando como resultado los
siguientes valores:
Puntos de función ajustados TDES (meses) = 9 meses.

PFA = 352.26
Cantidad de desarrolladores:
Líneas de código requerido: Cp. (personas) =
TLDC = 10,567.8 𝟐. 𝟑 𝒑𝒆𝒓𝒔𝒐𝒏𝒂𝒔 ~ 𝟑 𝒑𝒆𝒓𝒔𝒐𝒏𝒂𝒔.
El costo de desarrollo del
Fórmula para cálculo del software:
COCOMO II: Costo total ($) = $ 𝟔, 𝟖𝟒𝟒. 𝟐𝟓.
Tiempo de desarrollo:
En resumen, mediante los cálculos de COCOMO II, podemos decir:
El tiempo en el cual se desarrollará el sistema será 9 meses.

La cantidad de personal para desarrollar el software será 3 personas.
El costo total de desarrollo bajo estas condiciones será de $ 𝟔, 𝟖𝟒𝟒. 𝟐𝟓
60
2.2.3. Costos del servicio de alojamiento de la base de datos.
Para el alojamiento exclusivo de la base de datos del sistema, y el sitio Web,

así como el certificado digital, el TSIS no debe asumir ningún costo ya que se
alojará en los servidores del DTIC.
2.2.4. Costos totales de inversión.

Considerando los tres elementos previamente señalados: (Costo por
adquisición de equipos, desarrollo del software, alojamiento del sitio,
certificado y alojamiento de base de datos), se puede indicar el monto total
aproximado de la inversión inicial a la que deberá incurrir la empresa.
Tabla 10.
Costos de Inversión Inicial para el Sistema de Información.
DESCRIPCIÓN COSTO ($)
Adquisición de equipos. $ 736.44
Desarrollo del software. $ 6,844.25
Costo de alojamiento del sistema web (SISTSIS.) $0
Costos de alojamiento de la base de datos. $0
Costo de certificado digital (SSL.) $0
Costo total U$ 7,580.69
Nota. Fuente: Elaboración Propia.
A través del estudio con apoyo del modelo de costo COCOMO II se concluye
que es necesario un tiempo de 9 meses para desarrollo de la aplicación web,
con una cantidad de personal de 3 desarrolladores, bajo estas condiciones
el costo estimado de la aplicación es de U$ 𝟔, 𝟖𝟒𝟒. 𝟐𝟓 en sus tres etapas,
añadiendo la adquisición de equipos con un monto de U$ 736.44, da como
resultado una inversión de U$ 7,580.69.
61
2.3. FACTIBILIDAD FINANCIERA.
El estudio financiero consiste en la utilización de varias técnicas que ayuda a

tomar decisión acerca de la realización de gastos de capital, estas técnicas
expresan la aceptación o rechazo a proyectos, en nuestro caso el desarrollo
de la aplicación web.
Para el desarrollo de la aplicación es necesario ver la viabilidad del proyecto y
aceptación, así mismo determinar el periodo de recuperación de la inversión y
los beneficios que generará dicho proyecto. Para esto determinamos los flujos
de efectivos a 5 años, basándose en los ahorros que el sistema de información
originaría a la empresa y los gastos que ocasionaría, considerando el factor
de inflación actual de Nicaragua.
2.3.1. Ahorros estimados por el uso del sistema.
Tabla 11.
Ahorros originados por el Sistema.
TIPO DE AHORRO CANTIDAD ANUAL PRECIO AHORRO TOTAL(C$)
UNITARIO (C$)
Resma de papel BOND 12 121.47 1457.64

XEROX
Sobre plástico 3 59.00 177
Tóner de impresora 1 2,948.12 2948.12

HP
Lapicero Papermate 15 4.54 68.1
Resaltador 6 18.67 112.02
Corrector 3 24.77 74.31
62
TIPO DE AHORRO CANTIDAD ANUAL PRECIO AHORRO TOTAL(C$)
UNITARIO (C$)
Corrector en cinta 5 78.60 393
Caja de folder Ampo 6 145.46 872.76
Engrapadora 1 59.91 59.91
Caja de grapas 6 20.79 124.74
Fastener 1 35.36 35.36
Caja de clip 2 19.53 39.06
Perforadora 1 133.22 133.22
TOTAL, C$ C$ 6,495.24
Tasa al día 16/12/17 30.7292

(ver anexo 5)
TOTAL $ $ 211.37
2.3.2. Evaluación financiera.
La siguiente tabla muestra los flujos netos de efectivos proyectados para los
próximos 5 años de la inversión por la adquisición del sistema, con una tasa
promedio de inflación del 5.5 %.
Tabla 12.
Inflación actual al mes de noviembre 2017 y premio al riesgo.
PAIS INFLACIÓN 2017 PREMIO AL RIESGO
Nicaragua 5.35 % 5,5 %
Nota. Ver anexos 6 y 12.
63
2.3.2.1. Depreciación de equipos
El método de depreciación que se utilizará para las 2 computadoras será el de
línea recta en base al arto. 45 de la ley 822, Ley de Concertación Tributaria y
arto. 34 numeral 3 del reglamento inciso d, el cual establece una vida útil de 2
años para depreciación de equipos de cómputo.
Formula:
Depreciación = Costo equipo – Valor de rescate

Vida Útil
DepreciacionE1 = ($ 368.22 – 0) / 2 años

DepreciacionE1 = $ 184.11
DepreciacionE2 = ($ 368.22 – 0) / 2
DepreciacionE2 = $ 184.11
Depreciación total = $ 368.22
2.3.2.2. Ingresos estimados del TSIS
Los ingresos anuales se estimaron de acuerdo con los aranceles de la matrícula y

mensualidad (Ver anexo 14) de un promedio de 64 estudiantes.
Tabla 13.
Ingresos anuales estimados.
Calculo de Ingresos
Pago por matricula nuevo ingreso y reingreso. U$ 2,240

Pago por mensualidad. U$ 26,880
Total ingresos anuales. U$ 29,120

64
2.3.2.3. Egresos estimados del TSIS
Tabla 14.
Egresos anuales estimados.
Cálculo de gastos de administración
Salario coordinador. C$ 4,200
Salario asistente coordinador. C$ 12,600

Total anual (Córdobas.) C$ 201,600
Total anual al día 16/12/17 (ver anexo 5) = 30.7292 U$6,560.54
2.3.2.4. Flujo neto de efectivo con financiamiento.
2.3.2.4.1. Cálculo del préstamo.

VA = VI ∗ 60%
Donde VA: Valor del préstamo
VI: valor de la inversión
Para el cálculo del préstamo se utilizó la tasa de interés de 18% anual (Ver anexo 13)
que ofrece el Banco de la Producción que en comparación con demás bancos brinda
la menor tasa de interés y se determinó una cantidad de cuotas de 5 anualmente
correspondientes a los 5 años del flujo del proyecto.
VA = $ $ 𝟕, 𝟓𝟖𝟎. 𝟔𝟗 ∗ 0.60
𝐕𝐀 = $ 𝟒, 𝟓𝟒𝟖. 𝟒𝟏
65
2.3.2.4.2. Cálculo de amortización.
𝑃𝑀𝑇 = 𝑉𝐴/[1 − (1 + 𝑖)−𝑛 /𝑖]
Donde VA: Valor del préstamo 4,548.41

𝑃𝑀𝑇 =
1 − (1 + 0.18)−5
PMT: Cuota resultante del préstamo [ 0.18 ]
i: Tasa de interés 4,548.41

𝑃𝑀𝑇 =
3.1272
n: Número de cuotas.
𝑷𝑴𝑻 = $ 1,454.48 por año
Tabla 15.
Amortización del préstamo.
Período Cuota Interés Amortización Saldo
0 4548.41
1 1,454.48 818.71 635.77 3912.64
2 1,454.48 704.28 750.20 3162.44
3 1,454.48 569.24 885.24 2277.20
4 1,454.48 409.90 1044.58 1232.61
5 1,454.48 221.87 1232.61 0
66
2.3.2.4.3. Flujo de caja con financiamiento.
Tabla 16.
Flujo de Efectivo con Financiamiento.
Concepto. 0 1 2 3 4 5
Ingresos. 29120.00 30677.92 32319.19 34048.27 35869.85
Ahorros totales. 211.37 222.68 234.59 247.14 260.36
Egresos. 6560.54 6911.52 7281.29 7670.84 8081.23

Depreciación. 368.22 368.22 0.00 0.00 0.00
Utilidad 22402.61 23620.86 25272.49 26624.57 28048.98
operativa.
Gastos 818.71 704.28 569.24 409.90 221.87
financiero.
Utilidad después 21583.90 22916.58 24703.25 26214.67 27827.11
de gastos
financieros.
IR(30%.) 6475.17 6874.97 7410.97 7864.40 8348.13

Utilidad después 15108.73 16041.61 17292.27 18350.27 19478.98
de impuesto.
Amortización de 635.77 750.20 885.24 1044.58 1232.61
préstamo.
Depreciación. 368.22 368.22 0.00 0.00 0.00
FLUJO NETO. -7580.69 14841.18 15659.62 16407.03 17305.68 18246.37
(costo software.)
Tabla 17.
Flujo de Efectivo Acumulado.
Periodos. 0 1 2 3 4 5
Flujo de caja -7580.69 14841.18 15659.62 16407.03 17305.68 18246.37

Flujo -7580.69 7260.49 22920.12 39327.15 56632.83 74879.20
acumulado
67
2.3.2.5. Flujo de caja sin financiamiento.
Tabla 18.
Flujo de Efectivo sin Financiamiento.
Concepto. 0 1 2 3 4 5
Ingresos. 29120.00 30677.92 32319.19 34048.27 35869.85
Ahorros
211.37 222.68 234.59 247.14 260.36
Totales.
Egresos. 6560.54 6911.52 7281.29 7670.84 8081.23
Depreciación. 368.22 368.22 0.00 0.00 0.00

Utilidad
22402.61 23620.86 25272.49 26624.57 28048.98
Operativa.
IR (30%.) 6720.78 7086.26 7581.75 7987.37 8414.69
Utilidad
después de 15681.83 16534.60 17690.74 18637.20 19634.28
impuesto.
Depreciación. 368.22 368.22 0.00 0.00 0.00

FLUJO NETO
(costo -7580.69 16050.05 16902.82 17690.74 18637.20 19634.28
software.)
Nota. Fuente: Elaboración propia
Tabla 19.
Flujo de Efectivo Acumulado.
Períodos. 0 1 2 3 4 5
Flujo de caja. -7580.69 16050.05 16902.82 17690.74 18637.20 19634.28
Flujo
-7580.69 8469.36 25372.18 43062.92 61700.12 81334.40
acumulado.
68
Determinación de costo de capital (TMAR): refleja las expectativas de
ganancia que se desean obtener a cambio de invertir el dinero, calculándose
de la siguiente manera:
TMAR = i + f
Donde i es el premio a riesgo, y f la inflación.
TMAR = 5.5 % + 5.35 %

TMAR = 10.85 %
TIR: Representa la tasa de rendimiento anual compuesta que ganará el TSIS,

si se invierte en el proyecto, la TIR es de 200% que corresponde al flujo de
caja con financiamiento y una TIR de 216% correspondiente al flujo de caja sin
financiamiento, el costo de capital (TMAR) es de 10.85 %.
Por lo tanto, el proyecto debe ser aceptado ya que TIR > TMAR.
Valor Presente Neto (VPN): Siendo la inversión inicial de $ 7,580.69 y el costo

de capital (TMAR) de 10.85 %, el VPN calculado con el flujo de caja con
financiamiento es de $ 46,920.11 y un VPN de $ 51,206.78 correspondiente al
flujo de caja sin financiamiento, mayor que $0, lo cual indica la aceptación del
proyecto con el resultado de ambos escenarios, el TSIS obtendrá esta
ganancia tomando en cuenta el valor del dinero en el tiempo (ver anexo 2.)
69
2.3.2.6. Análisis Costo-Beneficio.
Tabla 20.
Gastos operativos.
Gastos operativos
Resma de papel BOND 12 121.47 1457.64
XEROX
Sobre plástico 3 59.00 177
Tóner de impresora 1 2,948.12 2948.12
HP
Lapicero Papermate 15 4.54 68.1
Resaltador 6 18.67 112.02

Corrector 3 24.77 74.31
Corrector en cinta 5 78.60 393
Caja de folder Ampo 6 145.46 872.76

Engrapadora 1 59.91 59.91
Caja de grapas 6 20.79 124.74

Fastener 1 35.36 35.36
Caja de clip 2 19.53 39.06

Perforadora 1 133.22 133.22
TOTAL, C$ C$ 6,495.24
Tasa al día 16/12/17 30.7292

TOTAL $ U$ 211.37
70
Tabla 21.
Cálculo de ingresos.
Calculo de ingresos
Concepto.
Pago por matricula nuevo ingreso y reingreso. U$ 2,240
Pago por mensualidad. U$ 26,880
Total ingresos anual. U$ 29,120

Tabla 22.
Gasto total de la inversión
Gasto total de la inversión
Costo total de equipos. U$ 736.44
Costo total del sistema. U$ 6,844.25
Inversión aproximada del proyecto U$ 7,580.69
Tabla 23.
Análisis costo beneficio.
Análisis costo beneficio
Gasto anual aprox. por la operación (ahorro.) U$ 211.37
Ingresos anuales. U$ 29,120
Beneficio totales. U$ 29,331.37
Inversión aproximada del proyecto (costo.) U$ 7,580.69
Costo-beneficio(beneficio/costo.) 3.87
71
La relación costo beneficio es un indicador que ayuda a determinar si un
proyecto es viable o no. Si el resultado es < 1 el proyecto no se debe aceptar,
si el resultado es = 1 es indiferente y si es > 1 es recomendable llevarlo a cabo.
Según los cálculos hechos se recomienda llevar a cabo el proyecto, con una
relación costo-beneficio de 3.87, el sistema es viable.
2.3.2.7. Beneficios del sistema.
2.3.2.7.1. Beneficios tangibles.

 Reducción de costos de papelería y desechos.
 Resguardo de la información.
 Mayor control en el registro de pagos por matrícula.
 Control eficiente de la información.
2.3.2.7.2. Beneficios intangibles.

 Prestigio y proyección universitaria.
 Mejor comunicación y atención a los estudiantes.
 Facilita la información para la toma de decisiones.
 Fomento a la cultura tecnológica en la universidad.
Por medio del estudio financiero se determinaron los diferentes indicadores

para la aceptación del proyecto, tales como: un VPN calculado con el flujo de
caja con financiamiento es de U$ 46,993.26 y un VPN de U$ 51,206.78
correspondiente al flujo de caja sin financiamiento, una TIR de 200% y 216%
respectivamente y la fórmula de costo-beneficio con un valor de 3.87, por tanto
se concluye que es viable llevar a cabo el proyecto en ambos escenarios.
72
CAPÍTULO III:
ANÁLISIS DE REQUERIMIENTOS.
73
3.1. DESCRIPCIÓN DEL MODELADO DEL NEGOCIO.
El TSIS en un programa académico que brinda estudios de nivel técnico a

estudiantes provenientes de los diferentes departamentos. Por lo que es de
sus labores cotidianas realizar gestión académica, como control de pagos,
inscripción de asignaturas, registro de notas, entre otras. El Técnico está en la
búsqueda de estandarizar estos procesos, con el uso de una herramienta
informática que se ajuste a los requerimientos.
A continuación, se explicarán los procesos estandarizados llevados a cabos

en el TSIS.
3.1.1. Gestión de requerimientos
Los requerimientos para un sistema son la descripción de los servicios

proporcionados por el sistema y sus restricciones operativas. Estos
requerimientos reflejan las necesidades de los clientes de un sistema que
ayude a resolver algún problema como el control de un dispositivo.
Un requerimiento es una característica que el sistema debe tener o es una

restricción que el sistema debe satisfacer para ser aceptada por el cliente, para
la buena gestión de los datos.
A continuación, se describen los procesos académicos que se identificación

con la ejecución de las herramientas de recolección de datos dirigidas a los
actores del sistema:
74
Registro de estudiantes y docentes.
Registro de docentes:
En este proceso, el coordinador solicita al departamento de informática los

docentes tanto de la facultad como externos que se requieren para el TSIS
según la carga horaria y las asignaturas que se impartirán en un periodo
académico. Luego, el departamento de sistemas se encarga de realizar dicha
gestión, que, según disponibilidad de los docentes, serán asignados a impartir
determinada asignatura, según el dominio.
A continuación, el Coordinador recibe listado de los docentes disponibles para

el TSIS. Asistente de coordinación recibe el listado con los datos y procede a
registrarlos, en caso de existir registro, actualizarlo.
Registro de asignaturas:
En este proceso, el asistente de coordinación TSIS, almacena los datos

propios de todas las asignaturas que forman parte de un ciclo académico, sin
embargo, este proceso se repite en caso de que se imparta una nueva
asignatura en el pensum.
Creación del ciclo académico:
En este proceso se realizan todos los subprocesos que son necesarios para
apertura de un ciclo académico en el TSIS, entre ellos, creación de la carga
académica, creación de grupos, creación de cursos y creación de horarios de
clases, a continuación, se detallan cada uno:
75
1. Creación de la carga académica:
Contempla el origen del ciclo, el coordinador crea una las cargas académicas,
por cada régimen y por cada año lectivo, junto con otros datos que contempla
la carga, y queda activa para asignársele, una por cada grupo.
2. Creación de grupos:
Una vez que se crean las cargas, el asistente de coordinación crea los grupos,
en dependencia de la cantidad de cursos que van a impartir, luego se le asigna
una carga activa y se lleva un registro de todos los cursos por cada ciclo
académico.
3. Creación de cursos:
En este subproceso el asistente de coordinación crea los cursos disponibles
para el ciclo académico actual, la creación de estos va en dependencia a las
asignaturas que se van impartir, con ello también se registra el docente que va
a impartir el curso y el grupo en el cual se va impartir.
4. Creación de horario:
Una vez creado los cursos y sus dependencias el coordinador procede a crear
y registrar los horarios según las distintas modalidades que ofrecen y los
cursos que impartirán en cada día de la semana, en cada grupo académico.
En caso de que haya un choque de horarios se harán las correcciones
pertinentes para ese ciclo.
Registro de estudiante:
En este proceso, cuando el estudiante se dirige al TSIS para realizar su
matrícula, y este es nuevo ingreso, el asistente de coordinación del TSIS se
encarga de registrar la inscripción, y consigo todos los datos personales de
interés que se le solicitan por medio de documentos tales como: fotocopia de
76
cédula, fotocopia de las notas de 4to y 5to año aprobados de la Educación
Secundaria y una foto tamaño carnet.
Una vez registrado se procede a realizar la matrícula de éste. En caso de ser

reingreso antes de matricular se le da la opción al estudiante si desea
actualizar su información.
Registro de Matrícula:
En este proceso el estudiante solicita matricularse y el asistente de

coordinación le elabora una esquela con el concepto del pago que se va
realizar junto con otros dos pagos necesarios para la matrícula, como lo son
laboratorio y solvencia de biblioteca. Una vez elaborada la esquela, el
estudiante se dirige a caja a realizar el pago. Luego de realizar el pago, el
estudiante se dirige al TSIS con el recibo y el asistente de coordinación verifica
el pago, si el estudiante es de nuevo ingreso se registran los datos personales,
en caso de ser reingreso se busca al estudiante registrado y se procede a
matricular y se imprime la hoja de matrícula con las asignaturas inscritas.
Gestión de monografía:
En este proceso, los estudiantes ingresan una solicitud de aprobación de tema

para su monografía. Cada tema puede desarrollarse por uno hasta tres
estudiantes. Una vez aprobado el tema, se les solicita a los estudiantes realizar
el pago del arancel por monografía, posteriormente se le asigna al estudiante
o grupo de estudiantes un tutor encargado de revisar detenidamente el
documento monográfico.
Suficiencia:
Este proceso ocurre cuando el estudiante requiere ingresar carta de solicitud

para realizar un examen de suficiencia. Una vez ingresada dicha solicitud, el
77
coordinador evalúa si acepta o rechaza la solicitud de suficiencia. Aceptada la
solicitud de suficiencia, se envía al estudiante a realizar el pago de arancel.
TSIS programa fecha de realización de la suficiencia y le asigna al docente.
Realizada la suficiencia, el docente registra la nota obtenida del estudiante.
Solicitud de Documento Académicos:
Este proceso se da al momento que un estudiante solicita documentación

académica en el TSIS. Estos documentos pueden ser: historial académico,
certificado de notas, constancia de alumno activo, entre otros. Luego, el
asistente del TSIS verifica información solicitada y envía al estudiante a
realizar el pago de arancel. Una vez que el estudiante realiza el pago, el
asistente registra el pago y programa fecha de entrega del tipo de documento
solicitado. Por último, se emite el documento solicitado al coordinador quien lo
sella y firma.
Control de pagos.
Este proceso se da al momento que el estudiante solicita el pago de un arancel

para la emisión de un documento, pago de matrícula, mensualidad, entre otros,
luego el asistente de coordinación genera la esquela con el concepto del
arancel, el estudiante se dirige a caja para realizar el pago, una vez efectuado,
el estudiante se dirige nuevamente al TSIS, le proporciona el recibo al
asistente, este registra el número de recibo asociándolo al estudiante.
78
3.1.2. Diagrama del proceso actual.
Figura 3. Diagrama del proceso actual.
79
3.1.3. Diagrama del proceso optimizado.
Figura 4. Diagrama del proceso optimizado.
80
3.1.4. Requerimientos del sistema.
3.1.4.1. Requerimientos funcionales.
Son declaraciones de los servicios que debe proporcionar el sistema, de la

manera en que éste debe reaccionar a entradas particulares y de cómo se
debe comportar en situaciones particulares. En algunos casos, los
requerimientos funcionales de los sistemas también pueden declarar
explícitamente lo que el sistema no debe hacer.
3.1.4.2. Requerimientos no funcionales.
Son restricciones de los servicios o funciones ofrecidos por el sistema.

Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares.
Los requerimientos no funcionales a menudo se aplican al sistema en su
totalidad. Normalmente apenas se aplican a características o servicios
individuales del sistema.
3.1.5. Requerimientos de software.
Son las aplicaciones o programas que la aplicación requiere para poder

ejecutarse en un ordenador.
3.1.6. Requerimientos de hardware.
Los requerimientos de hardware son las características que debe tener el

hardware de una computadora para poder soportar o ejecutar una aplicación
o un dispositivo específico.
3.1.7. Requerimientos de red.
Son los requerimientos que necesita la aplicación para poder trabajar en un

entorno cliente-servidor.
81
Una vez descrito los procesos, se llevó a cabo el análisis con ayuda de la
herramienta REM 1.2.2, en la cual se definen la organización, actores,
desarrolladores, objetivos del sistema, requerimientos funcionales y no
funcionales (ver anexo 3.)
Se elaboró una matriz de rastreabilidad en la cual se hizo una relación entre

los objetivos del sistema vs requerimientos funcionales.
3.1.8. Matriz de rastreabilidad.
3.1.8.1. Requerimientos funcionales vs objetivos del sistema.
La matriz de rastreabilidad es una herramienta que se utiliza para saber que

requerimientos funcionales cumplen con los objetivos del sistema. Se indican
las actualizaciones con respecto al avance del desarrollo de los requerimientos
originales para mantener una rastreabilidad de estos a lo largo de todo el
proyecto de software.
En la matriz se relacionan los requerimientos funcionales vs los objetivos del

sistema, de tal manera que se logra observar que requerimientos cumplen con
que objetivos.
Tabla 24.
Matriz de rastreabilidad.
82
CAPÍTULO IV:
DISEÑO DEL SISTEMA.
83
4.1. MODELOS UWE.
A continuación, se muestra el análisis del sistema donde se usó UWE, y la

herramienta MagicDraw 16.8, a través de la definición de diagramas de caso
de usos, presentación, navegacional, de componentes, de paquetes, actividad
del proceso, a fin de definir el sistema diagramando la realidad de utilización
de los requerimientos, apoyando la documentación y construcción del sistema.
4.1.1. Modelo de caso de uso del negocio.
El modelado del negocio es una técnica para comprender los procesos de

negocio de la organización. El objetivo es identificar los casos de uso del
software y las entidades del negocio relevantes que el software debe soportar,
de forma que se modela sólo lo necesario para comprender el contexto.
Figura 5: Caso uso del negocio.
84
4.1.2. Diagramas de actividad del negocio.
Representa los flujos de trabajo paso a paso de negocio y operacionales de

los componentes en un sistema, un diagrama de actividades muestra el flujo
de control general.
Diagrama de actividad de matrícula.
Figura 6: Diagrama de actividad registro de matrícula (Ver anexo 4.)
85
Aplicación Web de gestión académica y control de pagos en el TSIS
4.1.3. Modelo de caso de uso del sistema.
Figura 7. Modelo de caso de uso del Sistema (Ver anexo 4.)
86
4.1.4. Caso de uso.
Un diagrama de caso de uso es la representación gráfica de una serie de

tareas que deberán realizarse para completar un proceso dentro del sistema.
En la tabla 23 se describe el caso de uso de la figura 7; es el caso de uso
principal del sistema:
Caso de uso gestionar de matrícula.
Figura 8. Modelo de caso de uso Gestionar Matrícula (Ver anexo 4.)
Plantilla de Coleman.
Tabla 25.
Gestionar matrícula.
Caso de uso Gestionar matrícula
Definición La aplicación web permitirá registrar la matrícula, validando que se llenen

correcta y completamente.
Prioridad (1) Vital 2 Importante 3 Conveniente
Urgencia (1) Inmediata 2 Necesaria 3 Puede esperar
ACTORES
87
Nombre actor: Definición
Coordinador Es quién se encargará de manipular la aplicación web y realizar las

matrículas dependiendo de las solicitudes por registro de pagos realizados.
Asistente
ESCENARIO
Nombre Matrícula.
Precondiciones Que exista estudiante registrado y pago realizado y registrado.
Iniciado por: Coordinador, asistente.
Finalizado Por: Sistema.
Post-condiciones Se digiten correctamente los datos.
Excepciones Información incompleta: Falta llenar datos en matrícula.
Caso de uso gestionar de matrícula en línea.
Figura 9. Modelo de caso de uso Gestionar Matrícula en línea (Ver anexo 4.)
88
Tabla 26.
Gestionar matrícula en línea.
Caso de uso Gestionar matrícula en línea
Definición La aplicación web permitirá registrar la matrícula, validando que se llenen

correcta y completamente.
ACTORES
Estudiante Es quién se encargará de manipular la aplicación web y realizar la

matrícula del ciclo en cuso.
ESCENARIO
Nombre Matrícula.
Precondiciones Que exista estudiante registrado y pago realizado y registrado.
Iniciado por: Estudiante.
Finalizado Por: Sistema.
Post-condiciones Se digiten correctamente los datos.
Excepciones Información incompleta: Falta llenar datos en matrícula.
4.1.5. Diagrama de secuencia.
Muestra la forma en que los objetos se comunican entre sí al transcurrir el

tiempo. Formalmente se utilizan para validar los casos de uso. Todos los
diagramas de secuencia representan el flujo que se sigue para cada escenario
en el proceso del sistema (ver anexo 4.) A continuación, se muestra el
diagrama del proceso principal del sistema que es gestionar matrícula.
89
4.1.5.1. Diagrama de secuencia de guardar de matrícula.
Figura 10. Diagrama de secuencia guardar matrícula (Ver anexo 4.)
90
4.1.5.2. Diagrama de secuencia de modificar matrícula.
Figura 11. Diagrama de secuencia modificar matrícula (Ver anexo 4.)
91
4.1.6. Diagrama de colaboración.
Nueva matrícula.
Figura 12. Diagrama de colaboración nueva matrícula.
Modificar matrícula.
Figura 13. Diagrama de colaboración modificar matrícula.
92
Activar/desactivar matrícula.
Figura 14. Diagrama de colaboración activar/desactivar matrícula.
Finalizar matrícula.
Figura 15. Diagrama de colaboración finalizar matrícula.
93
Nueva matrícula en línea.
Figura 16. Diagrama de colaboración nueva matrícula en línea.
Modificar matrícula en línea.
Figura 17. Diagrama de colaboración modificar matrícula en línea.
94
Activar/desactivar matrícula en línea.
Figura 18. Diagrama de colaboración activar/desactivar matrícula en línea.
95
4.1.7. Diagrama conceptual.
Describe los conceptos involucrados en el sistema, que en programación orientado a objetos se identifican como objetos del mundo real.
Figura 19: Diagrama de actividad modificar matricula (Ver anexo 4.)
96
DetallePago
4.1.8. Modelo relacional. IdDetallePago
AspNetUsers Idpago
Id
IdDetalleEsquelaPago
Id_rol
Pago
Estado
Id_pago
Id_persona
Fecha
Estado
NumFactura
Email
EstadoPago
EmailConfirmed
Departamento IdEsquela
PasswordHash Pais
Id_departamento
SecurityStamp Id_pais
Nombre
PhoneNumber Nombre
Descripcion
Opcion PhoneNumberConfirmed Descripcion DetalleEsquelaPago
Id_pais IdDetalleEsquelaPago
Id_opcion
TwoFactorEnabled
Id_modulo IdEsquela
LockoutEndDateUtc
Url IdCategoriaPago
LockoutEnabled
Descripcion IdRegimen
AccessFailedCount
Rol_opcion Estado IdCargaAcademica
UserName
Id_usuario_opcion Id_padre Mes
Id_rol Nacionalidad Municipio Estado

Id_nacionalidad Id_municipio
Id_opcion Porcentaje
Id_pais Nombre
Estado MontoPago
Id_persona Descripcion
Id_padre
Id_departamento
Esquela
IdEsquela
Fecha
Modulo InscripcionEspecial
ActaNotaEspecial Observacion
Id_modulo Id_inscripcionespecial
Id_actanotaespecial IdEstudiante
modulo Id_cargaacademica
Id_inscripcionespecial Persona Estado
descripcion Id_docente CategoriaPago
Id_evaluacion Id_persona NumeroEsquela
Rol Id_asignatura Id_categoriapago
Id_rol Nota PrimerNombre
NumeroAutorizacion Id_padre
rol SegundoNombre
Fecha_autorizacion Descripcion
descripcion PrimerApellido
Fecha_realizacion Arancel
SegundoApellido
Estado DependeRegimen
FechaNac
Descripcion Estado
TipoSanguineo
Nota TipoPago
Evaluacion Foto
Regimen Id_Matricula Id_evaluacion
Cedula
Id_regimen Evaluacion
Direccion
Regimen
EstadoCivil
AnoAcademico
Celular
Frecuencia EstudianteTrabajo
Telefono
Ciclo Id_estudiantetrabajo
Genero Estudiante
Id_estudiante
Id_estudiante
Estado
Nombre_centro
DoncenteEstudio Id_persona
Id_municipio
Cargo
Id_docenteestudio Docente Carnet
Id_docente FechaInicio
CargaAcademica Id_docente Estado
Id_persona FechaFin
Id_cargaacademica Estudio
NumeroINSS Telefono
AñoLectivo Centro
RegimenAsignatura Id_regimen FechaInicio Estado Direccion
Id_regimenasignatura
Modalidad FechaCulminacion
Id_asignatura
Turno Estado
Id_regimen
Estado Nivel
Modalidad EstudiantePadre
Fecha EstudianteEstudio
Id_estudiantepadre
Tipocarga Id_estudianteestudio
Id_persona
Monografia
Id_estudiante Id_monografia
Id_estudiante
Estudio Tema
Parentesco
FechaInicio Tutor
FechaCulminacion Categoria
CursoAcademico DetalleActa
Nivel Nota
Id_cursoacademico Id_detalleacta
Centro Estado
Id_actanormal
Id_asignatura
Asignatura FechaInicio
Id_inscripcionasignatura
Id_asignatura Grupo Id_docente
IE FechaFin
Nombre Id_grupo Id_grupo InscripcionAsignatura
Id_inscripcionasignatura IIE
Codigo Grupo Estado
Id_matricula IIIE
PlanEstudio Id_cargaacademica cupo
Id_cursoacademico IVE
Id_Disciplina Estado limite
Fecha IC
TipoAsignatura TipoGrupo
Estado IIC Matricula
HrsSemana Id_Salon
Fecha Id_matricula DetalleMonografia
HrsTotales
Id_detallemonografia
Id_estudiante
Creditos
Id_monografia
Fecha
Precedencia Horario
Id_matricula
Id_horario Estado
Prerequisito
Responsable
Id_cursoacademico
Estado
Estado
Id_Grupo
Dia
ActaNormal
HrEntrada
Id_actanormal
HrSalida
NumActa
Estado
FechaCreacion
Estado
Id_cursoacademico
Disciplina
Id_Disciplina
Nombre
Figura 20. Modelo relacional del sistema.
97
4.1.9. Diagrama de estado
Matrícula.
Figura 21. Diagrama de estado matrícula.
4.1.10. Diagrama de paquete.
Un diagrama de paquetes muestra cómo un sistema está dividido en

agrupaciones lógicas mostrando las dependencias entre esas agrupaciones.
Dado que normalmente un paquete está pensado como un directorio, los
diagramas de paquetes suministran una descomposición de la jerarquía lógica
de un sistema. Los paquetes están normalmente organizados para maximizar
la coherencia interna dentro de cada paquete y minimizar el acoplamiento
externo entre los paquetes. Con estas líneas maestras sobre la mesa, los
paquetes son buenos elementos de gestión.
98
Figura 22. Diagrama de paquete del sistema.
4.1.11. Diagrama de componentes.
Un diagrama de componentes representa cómo un sistema de software es

dividido en componentes y muestra las dependencias entre estos
componentes. Los componentes físicos incluyen archivos, cabeceras,
bibliotecas compartidas, módulos, ejecutables, o paquetes.
99
Figura 23. Diagrama de paquete del sistema.
100
4.1.12. Diagrama navegacional.
Un diagrama de navegación nos indica las clases de navegación y de procesos que pertenecen a una página web. (Ver anexo 4.)
Figura 24: Diagrama de navegación del ador (Ver anexo 4.)
101
4.1.13. Diagramas de procesos.
El diagrama de estructura de procesos tiene la finalidad de describir las

relaciones entre las diferentes clases de proceso, dentro del mismo se pueden
identificar todas las operaciones cruciales de una clase y sus atributos y
métodos. (Ver anexo 4.)
Diagrama de proceso gestionar matrícula.
Figura 25: Diagrama de proceso gestionar matrícula (Ver anexo 4.)
102
4.1.14. Diagramas de actividad de proceso.
El diagrama de estructura de procesos tiene la finalidad de describir las

relaciones entre las diferentes clases de proceso, dentro del mismo se pueden
identificar todas las operaciones cruciales de una clase y sus atributos y
métodos.
(ver anexo 4.)
Diagrama de actividad de proceso crear matrícula.
Figura 26: Diagrama de actividad de proceso crear Matrícula (Ver anexo 4.)
103
Diagrama de actividad de proceso modificar matrícula.
Figura 27: Diagrama de actividad modificar matricula (Ver anexo 4.)
104
4.1.15. Diagramas de presentación.
En los modelos de presentación se explica la distribución gráfica de los

formularios del sistema (Ver anexo 4.) A continuación, se describe el formulario
de inicio para el administrador del sistema.
Figura 28: Diagrama de presentación del formulario de inicio (Ver anexo 4.)
105
CONCLUSIONES.
Como resultados del desarrollo del presente trabajo monográfico, se

determinó un análisis de viabilidad, proporcionando resultados positivos y un
análisis costo-beneficio que igualmente refleja resultados positivos para la
aceptación del proyecto, lo cual indica que el desarrollo de la aplicación web
traerá consigo beneficios que están dirigidos al ahorro en material de oficina y
garantizar la centralización en los procesos de gestión de información y
reportes académicos que se ocupan tanto para satisfacer las necesidades del
estudiante.
Para el desarrollo del sistema se obtuvieron los requerimientos funcionales y

no funcionales a través del análisis de requerimientos de los procesos
académicos que gestiona el TSIS con ayuda de la herramienta REM 1.2.2,
definiendo sus relaciones, dependencias, prioridades y estableciendo estrecha
comunicación con los usuarios internos.
Para el diseño de los procesos que se definieron en el análisis de

requerimientos se utilizó la herramienta MagicDraw 16.8, definiendo cada uno
de los diagramas que implementa UWE.
Finalmente se desarrolló la aplicación web SISTSIS, el cual contempla los

módulos destinados a gestionar los procesos académicos tales como inicio de
un ciclo académico, registro de estudiantes, docentes, notas, monografías,
control de pagos y emisión de reportes. Todos estos procesos reflejados como
opciones a los usuarios estudiante, docente, coordinador y asistente, según
corresponda en su rol.
106
RECOMENDACIONES.
Es recomendable que el TSIS implemente la aplicación web desarrollada en

este proyecto, ya que se determinaron los beneficios que tendrán tanto a nivel
de optimización de procesos, como también el ahorro proporcionado en
materiales de oficina.
Se recomienda acondicionar un espacio, con infraestructura de red y equipo

de cómputo, donde el docente pueda acceder a la aplicación web y gestionar
las notas en periodo requerido del ciclo académico.
En caso de que se implemente, se recomienda gestionar con la DTIC para que

proporcionen el soporte de dicha aplicación web a lo largo de su vida de uso y
surgimiento de nuevas necesidades para el TSIS en sus labores académicas.
Así mismo brindar capacitaciones tanto al personal encargado de las gestiones

del TSIS, como a los estudiantes.
Se recomienda gestionar por medio de las autoridades pertinentes la

implementación del servicio de pago con el banco que proporcione la
información necesaria para el control de pago de los estudiantes.
107
BIBLIOGRAFÍA.
Booch G. & Rumbaugh J. (2011) UML el lenguaje unificado de modelado.
Bocciarelli & D'Ambrogio, (2011), modelar requisitos de seguridad en BP.
Cachero Castro, Cristina. (2008) OO-H: Una extensión de los métodos OO

para el modelado y generación automática de interfaces hipermedia.
Fernando Berzal, Francisco J. Cortijo & Juan Carlos Cubero. (s.f.). Desarrollo
Profesional de Aplicaciones Web con ASP.NET. Recuperado el 14 de febrero
de 2016, de http://elvex.ugr.es/decsai/csharp/pdf/web/web-book-a4.pdf
Ferrer, J. (2012). Conceptos generales de la arquitectura de aplicaciones web

en implantaciones de aplicaciones web. Madrid, España: Ra-Ma Editorial, S.A.
Gauchat, J. D. (septiembre de 2013). El gran libro de HTML5, CSS3 y

Javascript. Recuperado el 14 de febrero de 2016, de
https://adegiusti.files.wordpress.com/2013/09/el-gran-libro-de-html5-css3-y-
javascript.pdf
Gilfillán, I. (2008). La Biblia de MySQL. Recuperado el 14 de febrero de 2016,

de https://osmell.files.wordpress.com/2008/08/la-biblia-de-mysql-anaya-
multimedia.pdf
Heredero, C. d. (2008). Dirección y gestión de los sistemas de información en

la empresa. En C. d. Heredero. Madrid.
Hernandez Sampieri, Fernandez Collado, Baptista Lucío. (2009). Metodología

de la Investigación.
Investigacion holistica. (febrero 2008). Recuperado el 20 de abril de 2016, de

http://investigacionholistica.blogspot.com/2008/02/la-investigacin-
proyectiva.html
Jorge Ferrer, Víctor García, Rodrigo García. (s.f.). CURSO COMPLETO

HTML. Recuperado el 14 de febrero de 2016, de http://es.tldp.org/Manuales-
LuCAS/doc-curso-html/doc-curso-html.pdf
De acuerdo con J. William & C. Collazos (2009). Desarrollo basado en modelos

de la interfaz de usuario de sistemas groupware.
108
La propuesta de Ingeniería Web basada en UML (2012). Recuperado el 14 de

febrero de 2016, http://www.slideshare.net/coesiconsultoria/4-desarrollo-gil-
del-software http: //maestria-modulo7.blogspot.com/2012/04/procesos-de-
desarrollo-ligeros.
Laudon, K. C., &Laudon, J. P. (2012). Sistemas de Información Gerencial.

México.
Mora, J. T. (agosto de 2011). Arquitectura de software para aplicaciones web.

Recuperado el 27 de marzo de 2016, de Juan Tahuiton Mora.
NEWCOMLAB. (2013). Recuperado el 14 de febrero de 2016, de

http://www.newcomlab.com/default.aspx?id_seccion=936
Pérez, J. E. (s.f.). Introducción a JavaScript.
Pressman. (2015). Software Engineering.
Programación Luis Moquete. (12 de junio de 2013). Recuperado el 14 de

febrero de 2016, de http://programacionluismoquete.blogspot.com/2013/06/el-
iss-significa-internet-information.html
RN Taylor, N. Medvidovic, EM Dashofy . (2009). Software Architecture:

Foundations, Theory, and Practice.
Rodríguez, A. (2009). Metodología de Diseño usada en Ingeniería. México.
Seco, J. A. (s.f.). Lenguaje de Programación C#. Recuperado el 14 de Febrero

de 2016, de http://dis.um.es/~bmoros/privado/bibliografia/LibroCsharp.pdf.
Schwabe, G. Rossi (2008) Desarrollo de aplicaciones hipermedia con

OOHDM.
Universidad Nacional de la Plata (2009). Argentina. Metodologías de diseño

usadas en Ingeniería Web, su vinculación con las NTICS.
Wordpress. (25 de enero de 2013). Recuperado el 27 de marzo de 2016, de

https://fergarciac.wordpress.com/2013/01/25/entorno-de-desarrollo-integrado-
ide/
Zuniga. (s.f.). UV. Recuperado el 14 de Febrero de 2016, de

http://www.uv.es/zuniga/06_La_distribucion_normal_o_de_Gauss.pdf
109
ANEXOS
Anexo 1. COCOMO.
Factores de Escala.
Los cinco Factores de Escala de COCOMO II determinan el exponente usado

en la ecuación de Esfuerzo:
Tabla 27.
Descripción de factores de escala.
No Factores Referencia
1 Precedencia(PREC) Si un producto es similar a muchos
proyectos que se han desarrollado
previamente, entonces la precedencia es
alta.
2 Flexibilidad de desarrollo(FLEX.) El software debe ajustar a prerrequisitos,
finalización anticipada, especificaciones
de interfaz externa.
3 Arquitectura/Resolución de Minuciosidad del diseño y eliminación de
Riesgo(RESL.) riesgo por revisión de diseño preliminar.
4 Cohesión del equipo (TEAM.) Explica los recursos de turbulencia y
entropía del proyecto debido a
dificultades en la sincronización de los
implicados en el proyecto, usuario,
clientes, desarrolladores, etc.
5 Madurez del proceso (PMAT.) El procedimiento para determinar PMAT
se obtiene a través del Modelo de
Madurez de capacidad del instituto de
Ingeniería del Software (CMM). El periodo
de tiempo para medir la madurez del
proceso es el modelo donde el proyecto
comienza.
Factores de costo.
Cocomo II tiene 17 factores de costo, se tienen que evaluar el proyecto, el

ambiente de desarrollo y el equipo para fijar el valor de cada factor de costo.
Los factores de costos son factores multiplicativos que determinan el esfuerzo
requerido para completar el proyecto de software.
Tabla 28.
Descripción factores de costo.
No. Factor Referencia
1 Fiabilidad Esta es la medida de hasta qué punto el software debe
requerida de realizar su función esperada durante un periodo de tiempo.
software (RELY.) Si el efecto de un fracaso es solo una molestia ligera
entonces RELY es Bajo. Si un fallo arriesgase vidas
humanas entonces RELY es muy alto.
2 Medida del Esta medida intenta capturar como se afecta en el
volumen de datos desarrollo del producto, grandes requerimientos de datos,
(DATA.) La medida se determina calculando D/P. La razón por la
que es importante considerar el tamaño de la base de
datos es por esfuerzo necesario para generar datos de
prueba que se usarán para ejecutar el programa.
DATA se valora como bajo si D/P es menor que 10 y muy
alto si es mayor que 1000
3 Complejidad del La complejidad se decide en 5 áreas: Funcionamiento de
producto (CPLX.) control, funcionamiento computacional, funcionamiento de
dispositivos dependientes, funcionamiento del sector de
datos y funcionamiento del gestor de interfaz de usuario.
Se seleccionará el área o combinación de áreas que
caracterizan al producto o a un subsistema del producto.

4 Reutilización Este driver de coste explica el esfuerzo adicional necesario
Requerida para construir componentes pensados para ser reutilizados
(RUSE.) en proyectos presentes y futuros
5 Documentación Nivel de adecuación de la documentación del proyecto a
Asociada a las las necesidades de su ciclo de vida.
necesidades del
ciclo de vida
(DOCU.)
6 Restricción del Esta es una medida de la restricción del tiempo de ejecución
tiempo de impuesta en un sistema de software. Las medidas se
ejecución(TIME.) expresan en términos de porcentaje de tiempo de ejecución
disponible que se espera que sea usado por el subsistema
o sistema que consume el recurso de tiempo de ejecución.
7 Restricción de Esta medida representa el grado de restricción de
Almacenamiento almacenamiento principal impuesto a un sistema o
Principal subsistema software. Dado el notable aumento en el tiempo
(STOR.) de ejecución disponible del procesador y de almacenamiento
principal, uno puede cuestionar si estas variables de
restricción son todavía pertinentes. Los valores van desde
nominal, menos que el 50%, a Extra Alto 95%.
8 Volatilidad de la “Plataforma” se usa aquí para significar la complejidad del
Plataforma Hardware y Software (OS, DBMS, etc.) que el producto
(PVOL.) software necesita para realizar sus tareas. Si el software a
desarrollar es un sistema operativo, entonces la plataforma
es el hardware del ordenador. Si se desarrolla un gestor de
base de datos, entonces la plataforma es el hardware y el
sistema operativo.

9 Habilidad del Los analistas son personales que trabaja en los requisitos de
Analista (ACAP.) diseño de alto nivel y en diseño detallado. Los atributos
principales que deben considerarse en esta medida son la
habilidad de análisis y diseño, la eficiencia y minuciosidad y
la habilidad para comunicar y cooperar.
10 Habilidad del La evaluación debe basarse en la capacidad de los

Programador programadores como un equipo, más que individualmente.
(PCAP.) La habilidad del programador no debe considerarse aquí,
eso se mide con AEXP.
11 Continuidad del La escala de valores de PCON se mide en términos del
Personal movimiento de personal del proyecto anualmente: desde 3%
(PCON.) muy alto, hasta el 48% muy bajo
12 Experiencia en Esta medida depende del nivel de experiencia en
las Aplicaciones aplicaciones del equipo de proyecto al desarrollar sistemas
(AEXP.) o subsistemas software. Un valor muy bajo para experiencia
en aplicaciones es menos que 2 meses. Un valor muy alto
es por experiencia de 6 años o más.
13 Experiencia Este driver de coste de diseño anticipado combina los 3
Personal (PEXP.) driver de coste post-arquitectura siguiente:
Experiencia(AEXP), experiencia en la plataforma(PEXP) y
experiencia en el lenguaje y herramienta (LTEX). Un valor
extra bajo es menor igual que 3 meses y uno extra alto es
igual a 6 años.
14 Experiencia en la Esta es una medida del nivel de experiencia en el lenguaje
Herramienta y el de programación y en la herramienta software del equipo de
Lenguaje (LTEX.) proyecto que desarrolla el sistema o subsistema software.
Además de la experiencia programando en un lenguaje
especifico, las herramientas que dan soporte también
influyen en el tiempo de desarrollo.

15 Uso de Los valores para la herramienta van desde edición y código
herramientas simple, muy bajo, hasta herramientas integradas de gestión
Software (TOOL.) del ciclo de vida, muy alto.
16 Desarrollo Determinar la medida de este driver incluye el cálculo y la
multisitio (SITE.) medida de 2 factores: Localización de lugar (desde
totalmente localizado hasta distribución internacional) y
soporte de comunicación (desde correo de superficie y algún
acceso telefónico hasta multimedia totalmente interactivo)
17 Planificación Es usado para tomar en cuenta que un proyecto desarrollado
temporal (SCED.) en un calendario acelerado requerirá más esfuerzo que un
proyecto desarrollado en su calendario óptimo. Una
comprensión del calendario del 74% se evalué como muy
bajo. Un alargamiento del 160% se valora como muy bajo.
Factores de escala.
Los factores de escala se determinan de acuerdo a la siguiente matriz, donde

comprende un rango desde muy bajo hasta extra alto.
Tabla 29.
Descripción factores de escala.
Nota. Matriz de factores de escala. Fuente:

http://www.ttn.gov.ar/normas/Images/norma_24_tabla_6.gif
Tabla 30.
Calculo de Factor de ajuste.
Baja Media Alta Total
Entradas 15X3 = 45 10X4= 40 3X5= 15 100

Salidas 5X4 = 20 3X5 = 15 2X7 = 14 49
Consultas 10X3 = 30 5X4 = 20 0X6 =0 50
Archivo Lógico Interno 9X7 = 63 5X10 = 50 2X15 = 30 143
(ficheros)
Archivo Lógico Externo 0X5 = 0 0X7 = 0 0X10 = 0 0
(interfaces)
El Factor de Ajuste como: 342
Tabla 31.
Calculo de Factor de escala.
Factor Nombre Rango Justificación Valor
PREC Desarrollos Conlleva aspectos novedosos 1.24

previos similares
Nominal
FLEX Flexibilidad del Alto La flexibilidad entre el Sistema y los 1.01

desarrollo requerimientos no son rigurosos.
RESL Manejo de riesgos Muy No se realiza un plan que toma en cuenta los 4.24
y la Arquitectura bajo riesgos
TEAM Cohesión de Alto Existe consistencia en el trabajo en equipo, 1.10

equipo pero no en su totalidad.
PMAT Madurez del Nominal Las áreas de proceso principales están en un 1.56
proceso estado incipiente dentro de la organización.
∑SFI = 9.15
14
𝐴𝐹 = 0.65 + 0.01(∑ 𝐹𝑖 )
𝑖=1
AF = 0.65 + 0.01(38)
AF = 1.03
Puntos de función ajustados: Total de líneas de código fuente.
𝑃𝐹𝐴 = 𝑃𝐹 𝑋 𝐴𝐹 TLDC = N promedio de líneas de

código C# X PFA
Donde PF = 462
TLDC = 30 x 352.26
𝑃𝐹𝐴 = 342 X 1.03
TLDC = 10,567.8
PFA = 352.26
TLDC en miles de líneas de código (MF)
El lenguaje de programación utilizado para el desarrollo de la aplicación es C#, lo cual

es lenguaje orientado a objeto, por tanto, el valor de LDC según la tabla es de 30.
Tabla 32.
Líneas de código según lenguaje.
Lenguaje de Programación LDC/PF

Ensamblador. 320
C. 128
Cobol. 105
Fortran. 105
Pascal. 90
ADA. 70
Lenguajes orientados a objetos. 30
Lenguajes de cuarta generación. 20
Generadores de código. 15
Hojas de cálculo. 6
Íconos. 4
Nota. Fuente: http://ronald-fajardo.blogspot.com/2010/10/metricas-del-software.html.
𝑻𝑳𝑫𝑪 = 10,567.8/1000= 10.57 líneas de código (en miles.)

Estimación de esfuerzo B: Ahorro y gasto de software.
𝐸 = 𝐴 ∗ 𝑇𝐿𝐷𝐶 𝐵 ∗ 𝜋 ∑ 𝑀𝐼 πЕМІ = Factor de esfuerzo

completo.
Donde:
Ahorro y gasto de software de
A: Constante de calibración A =
escala:
2.94
TLDC = Total de líneas de código y 𝐵 = 0.91 + (0.01 ∗ ∑ 𝑆𝐹𝑖)
fuente en miles.
B = 0.91+ (0.01x 9.15) B= 1.0015
Cocomo II tiene 17 factores de costo, se tienen que evaluar el proyecto, el ambiente

de desarrollo y el equipo para fijar el valor de cada factor de costo. Los factores de
costos son factores multiplicativos que determinan el esfuerzo requerido para
completar el proyecto de software.
Tabla 33.
Calculo de factor de costo.
b Factor Muy Bajo Bajo Normal Alto Muy alto Extra Proyect
o
1 RELY Inconveniente Mínimas Perdidas Perdida Vida humana 0.92
s perdidas moderadas financiera en riesgo
insignificantes al al usuario elevada o
que afecta usuario, recuperable inconvenient
solamente a fácilmente s sin e humano
los recuperab grandes masivo
desarrolladore les inconvenie
s ntes
0.82 0.92 1.00 1.10 1.26 -
2 DATA DB 10 <=D/P < 100<=D/P < D/P>1000 1.0
bytes/Pg 100 1000
m SLOC
< 10
o
- 0.90 1.00 1.14 1.28 -
3 CPLX Pocas Estructura Uso Programació Codificación Planificació 1.0
estructuras sin s mayoritario n recursiva. n múltiple
anidamiento, anidadas de estructurada Manejo de de recursos
Composición sencillas anidamient con alto interrupcione con cambio
modular os grado de s con dinámico
simple por sencillos. anidamiento prioridad fija. de
medio de Algunos con Sincronizació prioridades.
llamadas a controles predicados n de tareas, Control al
procedimiento entre compuestos. complejas nivel de
o simples módulos. Control de llamadas o microcódig
script Tablas de cola y pila. subrutinas o. Control
decisión. Procesamien en tiempo
Pasaje de to distribuido. real
mensaje o Control en el distribuido.
llamadas o tiempo real
subrutinas. con un
procesador.
0.73 0.87 1.00 1.17 1.34 1.74
4 RUSE Reusable Reusabl 1.0
Ningún Reusa Reusabl
dentro e dentro
compon ble e dentro
de una de
ent e dentro de un
misma múltiple
reusabl del mismo
e línea de s líneas
mismo program
productos de
proyec a
producto
to
- 0.95 1.00 1.07 1.15 1.24
5 DOCU Necesida 1.0

Muchas Algunas Necesidad Necesidade
de s del
necesidade s necesida e s del s del
ciclo de
del ciclo de de s ciclo de ciclo de
vida
vida sin del ciclo vida vida
cubiertas
cubrir de vida cubiertas cubiertas
o
sin en su ampliament excesivam
cubrir justa e ent e
medida
0.81 0.91 1.00 1.11 1.23 -
6 TIME Uso de 1.0

<= 50%
70% 85% 95
del %
tiempo
de
ejecución
- - 1.00 1.11 1.29 1.
63
7 STOR Uso de 1.0
<= 50%
del 70% 85% 95
%
porcentaj
e total de
almacena
mi
ento
- - 1.00 1.05 1.17 1.
46
8 PVOL Un Cam 0.87
Cambio Cambio
cambio bio
principal principal
principal princ
cada 2 cada 2
cada 12 ipal
meses semana
meses. cada
Cambio s.
Un 6
menor uno Cambio
cambio mes
por menor
menor es.
semana cada 2
todos Cam
días
los bio
meses men
or
cada
o
2
semanas
- 0.87 1.00 1.15 1.30 -
9 ACAP 15 percentil 35 55 75 percentil 90 percentil - 0.85
percentil percentil
1.42 1.19 1.00 0.85 0.71
10 PCAP 15 percentil 35 55 75 percentil 90 percentil - 0.88

percentil percentil
1.34 1.15 1.00 0.88 0.76
11 PCON 48 % por 24 % 12 % por 0.81

6% por año 3 % por -
por
año año año
año
1.29 1.12 1.00 0.90 0.81
12 AEXP <= 2 meses <= 6 1 año 3 años 6 años - 1.10

meses
1.22 1.10 1.00 0.88 0.81
13 PEXP <= 2 meses <= 6 1 año 3 años 6 años - 1.09

meses
1.19 1.09 1.00 0.91 0.85
14 LTEX <= 2 meses <= 6 1 año 3 años 6 años - 1.00

meses
1.20 1.09 1.00 0.91 0.84
15 TOOL Herramient Herrami Herramient Herramient - 1.00

Herramien
as ent as as as
ta s
que simples robustas y altamente
básicas,
permiten con maduras, integradas
integradas
editar, escasa integradas a los
moderada
codificar, integrac moderada procesos,
m ente
depurar ión al m métodos y
proceso ente
reuso
de
desarrol
lo
1.17 1.09 1.00 0.90 0.78
o
16 SITE Internacion Multi- Multi- Misma Mismo Complet 0.80
al ciudad y ciudad o ciudad o edificio o a mente
multico multicom área complejo centraliz
mpañía pañía metropolita ado
n
a
1.22 1.09 1.00 0.93 0.86 0.
80
17 SCED 75% del 85% 100% 130% del 160% del 1.43
del del
nominal nominal nominal
nomin nominal
al
1.43 1.14 1.00 1.00 1.00 -
πEMi = (0.92 * 1.00 * 1.00 * 1.00 * 1.00 * 1.00 * 1.00 * 0.87 * 0.85 * 0.88 * 0.81
* 1.10 *1.09 *1.00 * 1.00 * 0.80 * 1.43)
πEMi = 0.67
De la tabla anterior se obtiene un valor para πEMi de 0.67. Sustituyendo en la

fórmula 5:
𝐸 = 2.94 ∗ 10.571.0015 ∗ 0.67
𝐸 = 20,89
𝐸 = 21 (Personas - mes)
Estimación del tiempo de desarrollo.
𝑇𝐷𝐸𝑆 = 3.67 ∗ (𝐸 0.28+(0.002∗∑ 𝑆𝐹𝑖) )
Sustituyendo valores en la fórmula tiene lo siguiente:
𝑇𝐷𝐸𝑆 = 3.67 ∗ (210.28+(0.002∗9.15) )

𝑇𝐷𝐸𝑆 = 9 𝑚𝑒𝑠𝑒𝑠
Estimación de cantidad de hombres.
La cantidad de personas necesarias se realiza a través de la siguiente

fórmula:
𝐶𝐻 = 𝐸⁄𝑇𝐷𝐸𝑆
CH = 21/9= 2.33
CH = 3 personas.
Estimación de la productividad.
𝑃 = (𝑇𝐿𝐷𝐶 ∗ 1000)⁄𝑇𝐷𝐸𝑆
Sustituyendo valores tenemos que:
𝑃 = (10.57 ∗ 1000)⁄9
𝑃 = 1,174 𝑙í𝑛𝑒𝑎𝑠 𝑑𝑒 𝑐ó𝑑𝑖𝑔𝑜 𝑝𝑜𝑟 ℎ𝑜𝑚𝑏𝑟𝑒 − 𝑚á𝑞𝑢𝑖𝑛𝑎
Cálculo de los costos del proyecto.
Para obtener el costo total en el cual incurrirá el TSIS, se deben realizar una
serie de cálculos relacionados a los costos directos e indirectos del desarrollo
de la Aplicación Web.
𝐶𝑇𝑃 = 𝐶𝐷 + 𝐶𝐼
Donde;
CTP: Costo de consumo de energía
CD: Costos directos = CFT (Costo de la Fuerza de Trabajo) + CUMT (costo de
utilización de medios técnicos)
CI: Costos indirectos = 15% CD.
Distribución de tiempo y esfuerzo por etapa.
Cuando el tamaño de un proyecto no se ajusta al de los valores estándares de

la siguiente tabla, la distribución del esfuerzo y el tiempo de desarrollo se
obtendrá través de interpolación.
Tabla 34.
Distribución de tiempo y esfuerzo por etapa.
INDICADOR FASES PEQUE INTERME MEDI GRAND MUY
2MF D 8MF 32MF 128MF GRAND
512MF
ESFUERZO
Porcentajes Estudio 7 7 7 7 7
(%) preliminar
Análisis 17 17 17 17 17
Diseño y 64 61 58 55 52
desarrollo
Diseño 27 26 25 24 23
Desarrollo 37 35 33 31 29
Prueba e 19 22 25 28 31
implementación
TIEMPO DE DESARROLLO
Porcentajes Estudio 16 18 20 22 24
(%) preliminar
Análisis 24 25 26 27 28
Diseño y 56 52 48 44 40
desarrollo
Prueba e 20 23 26 29 32
implementación
𝑀𝐹 − 𝑀𝐹1
%𝑝𝑟𝑜𝑔 = %𝑀𝐹1 + ∗ (%𝑀𝐹2 − %𝑀𝐹1 )
𝑀𝐹2 − 𝑀𝐹1
Porcentaje de esfuerzo y tiempo de desarrollo para un proyecto con MF no

estándar
10.57 − 8
= 0.1071
32 − 8
Cálculo del porcentaje de esfuerzo en la etapa de diseño y desarrollo:
%𝑝𝑟𝑜𝑔 = 61% + 0.1071% ∗ (58% − 61%) = 60.68%
Cálculo del porcentaje de esfuerzo en la etapa de prueba e implementación:
%𝑝𝑟𝑜𝑔 = 22% + 0.68% (25% − 22%) = 24.04%
Cálculo del porcentaje de tiempo de desarrollo en el estudio preliminar:

%𝑝𝑟𝑜𝑔 = 18% + 0.68% ∗ (20% − 18%) = 19.36%
Cálculo del porcentaje del tiempo de desarrollo en la etapa de análisis:
%𝑝𝑟𝑜𝑔 = 25% + 0.68% ∗ (26% − 25%) = 25.68%
Cálculo del porcentaje del tiempo de desarrollo en la etapa de diseño y

desarrollo:
%𝑝𝑟𝑜𝑔 = 52% + 0.68% ∗ (48% − 52%) = 49.28%
Cálculo del porcentaje del tiempo de desarrollo en la etapa de prueba e

implementación:
%𝑝𝑟𝑜𝑔 = 23% + 0.68% ∗ (26% − 23%) = 25.04%
Para calcular ESF:
ESF = Esfuerzo * %ESF
Estudio Preliminar = 21 * 7% = 1.47

Análisis = 21 * 17% = 3.57
Diseño y Desarrollo = 21 * 60.68% = 12.74
Prueba e Implementación = 21 * 24.04% = 5.05
Para calcular TDES:

Tdes = TDesarrollo * %Tdes
Estudio Preliminar = 9 * 19.36% = 1.74

Análisis = 9 * 25.68% = 2.31
Diseño y Desarrollo = 9 * 49.28% = 4.43
Prueba e Implementación = 9 * 25.04% = 2.25
De los cálculos obtenidos anteriormente se generan los valores detallados en

la siguiente tabla:
Tabla 35.
Calculo de la Distribución de tiempo y esfuerzo por etapa.
Etapa ESF% ESF TDES% TDES CH
Estudio preliminar 7 1.47 19.36 1.74 0.84
Análisis 17 3.57 25.68 2.31 1.54
Diseño y desarrollo 58.42 12.74 49.28 4.43 2.87
Prueba e implementación 24.04 5.05 25.04 2.25 2.24
Distribución del costo de fuerza de trabajo por etapa.
Para calcular el costo de la fuerza de trabajo (CFT) utilizaremos la siguiente

fórmula:
𝐶𝐹𝑇 = 𝑆𝑎𝑙𝑎𝑟𝑖𝑜 ∗ 𝐶𝐻 ∗ 𝑇𝐷𝐸𝑆
Se ha establecido un salario de C$ 8,000 por analista-programador.
CFT = SALARIO * CANTIDAD DE ANALISTA PROGRAMADOR (CH* Tdes)
Estudio preliminar.
CFT = C$ 8,000 x 0.84 analista-programador x 1.74
CFT1 = C$ 11,692.8
Análisis.
CFT2 = C$ 28,459.2
Diseño y desarrollo.
CFT3 = C$ 101,712.8
Prueba e implementación.
CFT4 = C$ 40,320
CFT=CFT1+ CFT2 +CFT3 + CFT4

CFT= C$ 11,692.8 + C$ 28,459.2 + C$ 101,712.8 + C$ 40,320
CFT=C$ 182,184.80
Distribución del costo de utilización de los medios técnicos
Para calcular el costo de utilización de medios técnicos (CUMT) es necesario

determinar el número de horas que cada analista-programador utilizará la
computadora que le ha sido asignada. Se laboran 25 horas a la semana, es
decir 100 horas al mes. Además, también se debe encontrar la cantidad de
energía que consume cada computadora.
Tabla 36.
Calculo de la Kilowatts por dispositivo.
Dispositivo Intensidad Voltaje Potencia
(Amperios) (Voltios) (Watts)
HDD 0.5 11.25 5.625
DVD-ROM 0.5 22.5 11.25
Tarjeta Madre 0.5 3.75 1.875
Mouse 0.1 5 0.5
Teclado 0.05 5 0.25
Monitor 0.7 110 77
TOTAL (Watts) 96.5
TOTAL (Kilowatts) 0.0965
𝐶𝐶𝑒 = 𝐶𝑒 ∗ 𝐶𝐾𝐻 ∗ 𝑁𝑜𝐻
Donde;
CCe: Costo de consumo de energía
Ce: Consumo de energía
CKH: Costo de kilowatts-hora
NoH: Número de horas utilizadas al mes.
CCe = Ce x CKH x NoH
CCe = 0.0965 KW/computadora x 2.62321 C$/KW-H x 5 Horas x 30 dias

CCe = C$ 37.97 /computadora-mes
Estudio Preliminar
CUMT = C$ 37.97 /Computadora-Mes x 2 computadora x 1.74 meses
CUMT1 = C$ 132.13
Análisis
CUMT = C$ 37.97 /computadora-mes x 2 computadora x 2.31 meses
CUMT2 = C$ 175.42
Diseño y desarrollo
CUMT = C$ 37.97 /computadora-mes x 2 computadoras x 4.43 meses
CUMT3 = C$ 336.41
Prueba e implementación
1
Fuente: http://www.ine.gob.ni/DGE/tarifasdge/2018/04/pt_abril18_BT1.pdf.
CUMT = C$ 37.97 /computadora-mes x 2 computadoras x 2.25 meses

CUMT4 = C$ 170.86
CUMT = CUMT1+CUMT2+CUMT3+CUMT4
CUMT = 132.13+175.42+336.41+170.86
CUMT = 814.82
Durante las 4 etapas del desarrollo del sistema se deberá de realizar una
inversión de C$ 814.82 mensual en gastos de consumo de energía eléctrica.
Sustituyendo en la fórmula:
CD = CFT + CCe CTP = C$ 182,999.62+27,449.943

CD = C$ 182,184.80+ C$ 814.82 CTP (Córdobas) = C$
CD = C$ 182,999.62 210,449.563
CI = CD * 15% Tasa de cambio para

CI = (C$ 182,999.62) * 15% 16/12/17(ver anexo 5): 30.7292
CTP (Dólares) = $ 6,848.52

CTP = CD + CI
Anexo 2. Factibilidad Financiera
Tabla 37.
Flujo de efectivo con financiamiento.
Periodos. 0 1 2 3 4 5
Flujo de caja -7,580.69 14,841.18 15,659.62 16,407.03 17,305.68 18,246.37
Flujo
-7,580.69 7,260.49 22,920.11 39,327.14 56,632.82 74,879.19
acumulado
Nota. fuente: elaboración propia.
𝑉𝑡
VAN = ∑𝑛1 (1+𝑖)𝑛 – io.
14,841.18 15,659.62 16,407.03 17,305.68 18,246.37
VAN = (1+0.15)1
+ (1+0.15)2 + (1+0.15)3 + (1+0.15)4 + (1+0.15)5 − 7,580.69.
14,841.18 15,659.62 16,407.03 17,305.68 18,246.37
VAN = + + + + − 7,580.69.
1.15 1.3225 1.5208 1.7490 2.0114
VAN = 12,905.37 + 11,840.92 + 10,788.42 + 9,894.61 + 9,071.48 − 7,580.69.

VAN = $ 46,920.11
𝑉𝐴𝑁 46,920.11
VAN relativo = %= = 618.9%.
𝐼𝑁𝑉𝐸𝑅𝑆𝐼𝑂𝑁 𝐼𝑁𝐼𝐶𝐼𝐴𝐿 7,580.69
Tabla 38.
TIR del flujo con financiamiento.
Datos
Costo Inicial $ -7,584.69
1er año 14841.18
2do año 15659.62
3er año 16407.03
4to año 17305.68
5to año 18246.37
TIR(5 Años) 200%
Tabla 39.
Flujo de efectivo sin financiamiento.
Períodos. 0 1 2 3 4 5
Flujo de caja. -7580.69 16050.05 16902.82 17690.74 18637.20 19634.28
Flujo
-7580.69 8469.36 25372.18 43062.92 61700.12 81334.40
acumulado.
𝑉𝑡
VAN = ∑𝑛1 (1+𝑖)𝑛 – io.
16,050.05 16,902.82 17,690.74 18637.20 19634.28
VAN = (1+0.15)1
+ (1+0.15)2 + (1+0.15)3 + (1+0.15)4 + (1+0.15)5 − 7,580.69.
16,050.05 16,902.82 17,690.74 18,637.20 19634.28
VAN = + + + + − 7,580.69.
1.15 1.3225 1.5208 1.7490 2.0114
VAN = 13,956.57 + 12,780.96 + 11,632.52 + 10,655.92 + 9,761.50 − 7,580.69.

VAN = $ 51,206.78
𝑉𝐴𝑁 51,206.78
VAN relativo = %= = 675.5 %.
𝐼𝑁𝑉𝐸𝑅𝑆𝐼𝑂𝑁 𝐼𝑁𝐼𝐶𝐼𝐴𝐿 7,580.69
Tabla 40.
TIR del flujo sin financiamiento.
Datos
Costo Inicial $ -7,580.69
1er año 16,050.05
2do año 16,902.82
3er año 17,690.74
4to año 18,637.20
5to año 19,634.28
TIR(5 Años) 216%
Anexo 3. Plantillas REM
Usuarios.
Tabla 41.
Coordinador del TSIS.

Tabla 42.
Asistente del TSIS.
Tabla 43.
Estudiante del TSIS.
Organización.
Tabla 44.
Organización TSIS.

Tabla 45.
Organización uni-rupap.
Desarrolladores.
Tabla 46.
Desarrollador de la aplicación.
Tabla 47.

Tabla 48.
Requerimientos funcionales
Son declaraciones de los servicios que debe proporcionar el sistema, de la

manera en que éste debe reaccionar a entradas particulares y de cómo se
debe comportar en situaciones particulares. En algunos casos, los
requerimientos funcionales de los sistemas también pueden declarar
explícitamente lo que el sistema no debe hacer.
Creación de usuario.
Tabla 49.
Creación de usuario.

Creación de carga académica.

Tabla 50.
Creación de carga académica.
Creación de matrícula.
Tabla 51.
Creación de matrícula.

Creación de régimen.
Tabla 52.
Creación de régimen.
Creación de horario.
Tabla 53.
Creación de horario.

Creación de docente.
Tabla 54.
Registro de docente.
Creación de estudiante.
Tabla 55.
Registro de estudiante.

Creación de grupo.
Tabla 56.
Creación de grupo.
Creación de cursos.
Tabla 57.
Creación de cursos.

Registro de asignatura.
Tabla 58.
Creación de asignatura.
Registro de notas.
Tabla 59.
Registro de notas.

Registro de pagos.
Tabla 60.
Registro de pagos.
Registro de monografía.
Tabla 61.
Registro monografía.

Reporte de matrícula.
Tabla 62.
Reporte de matrícula.
Reporte de esquela de pago.

Tabla 63.
Reporte de esquela de pago.

Reporte de datos generales de estudiante.

Tabla 64.
Reporte de datos generales de estudiante.
Reporte de datos generales de docente.

Tabla 65.
Reporte de datos generales de docente.

Reporte de historial académico.

Tabla 66.
Reporte de historial académico.
Reporte de horario académico.

Tabla 67.
Reporte de horario académico.

Requerimientos no funcionales.
Son restricciones de los servicios o funciones ofrecidos por el sistema.

Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares.
Los requerimientos no funcionales a menudo se aplican al sistema en su
totalidad. Normalmente apenas se aplican a características o servicios
individuales del sistema.
a) Requerimientos del producto.
Estos requerimientos especifican el comportamiento del producto. Algunos

ejemplos son los requerimientos de rendimiento en la rapidez de ejecución del
sistema y cuánta memoria se requiere; los requerimientos de fiabilidad que
fijan la tasa de fallos para que el sistema sea aceptable.
Requerimiento de usabilidad.
Tabla 68.
Requerimiento de usabilidad.

Requerimiento de rendimiento.
Tabla 69.
Requerimiento de rendimiento.
Requerimiento de espacio.
Tabla 70.
Requerimiento de espacio.

Requerimiento de fiabilidad.
Tabla 71.
Requerimiento de fiabilidad.
Requerimiento de portabilidad.
Tabla 72.
Requerimiento de portabilidad.

Requerimientos externos.
Este gran apartado incluye todos los requerimientos que se derivan de los
factores externos al sistema y de su proceso de desarrollo. Éstos pueden
incluir los requerimientos de interoperabilidad que definen la manera en que el
sistema interactúa con sistemas de otras organizaciones; los requerimientos
legislativos que deben seguirse para asegurar que el sistema funcione dentro
de la ley y los requerimientos éticos. Estos últimos son puestos en un sistema
para asegurar que será aceptado por sus usuarios y por el público en general.
Requerimiento de privacidad.
Tabla 73.
Requerimiento de privacidad.

Requerimiento de seguridad.
Tabla 74.
Requerimiento de seguridad.
Requerimientos de software.
Son las aplicaciones o programas que la aplicación requiere para poder

ejecutarse en un ordenador.
Tabla 75.
Requerimiento de software.

Requerimientos de hardware.
Los requerimientos de hardware son las características que debe tener el

hardware de una computadora para poder soportar o ejecutar una aplicación
o un dispositivo específicos.
Tabla 76.
Requerimiento de hardware.
Requerimientos de red.
Son todos los requerimientos que necesita la aplicación para poder trabajar en
un entorno cliente/servidor.
Tabla 77.
Requerimiento de red.

Anexo 4. Diseño UWE.
Caso de uso gestionar arancel.
Figura 29. Caso de uso gestionar arancel.
Tabla 78.
Gestionar arancel.
Caso de Uso Gestionar arancel
Definición El sistema permitirá gestionar los aranceles desde un sistema web,

validando que se llenen correcta y completamente los datos.
ACTORES
Nombre Actor: Definición
Coordinador Es quién se encargará de manipular el sistema web y digitar los

aranceles dependiendo de los pagos que se realicen.
Asistente
ESCENARIO
Nombre Aranceles
Precondiciones
Iniciado Por Coordinador
Finalizado Por Sistema
Post- Se digiten correctamente los datos.

Condiciones
Excepciones Información incompleta: Falta llenar datos en el arancel.
Caso de uso gestionar asignatura.
Figura 30. Caso de uso gestionar asignatura.
Tabla 79.
Gestionar asignatura.
Caso de Uso Gestionar asignatura
Definición El sistema permitirá digitar las asignaturas desde un sistema web,


ACTORES
Coordinador Es quién se encargará de manipular el sistema web y digitar las

asignaturas dependiendo del plan de estudio.
Asistente
ESCENARIO
Nombre Asignatura
Precondiciones Que la asignatura se registre por orden de dependencia y pre-

requisito.
Iniciado por Coordinador
Finalizado por Sistema
post- Se digiten correctamente los datos.

condiciones
Excepciones Información incompleta: Falta llenar datos en la Asignatura.
Caso de uso gestionar carga académica.
Figura 31. Caso de uso gestionar carga académica.

Tabla 80.
Gestionar carga académica.
Caso de Uso Gestionar carga académica
Definición El sistema permitirá digitar la carga académica desde un sistema web,

ACTORES
Coordinador Es quién se encargará de manipular el sistema web y digitar la carga

académica dependiendo del ciclo.
ESCENARIO
Nombre Carga académica
Precondiciones Que tenga disponible un catálogo de régimen.

condiciones
Excepciones Información incompleta: Falta llenar datos en la carga académica.

Caso de uso gestionar curso.
Figura 32. Caso de uso gestionar curso.
Tabla 81.
Gestionar cursos.
Caso de Uso Gestionar cursos
Definición El sistema permitirá digitar los cursos desde un sistema web,

ACTORES

cursos dependiendo de la carga académica.
ESCENARIO
Nombre Curso
Precondiciones Que se encuentren disponible los catálogos de los docentes y de las

asignaturas.

condiciones
Excepciones Información incompleta: Falta llenar datos en los cursos.
Caso de uso gestionar docente.
Figura 33. Caso de uso gestionar docente.
Tabla 82.
Gestionar docente.
Caso de Uso Gestionar Docente
Definición El sistema permitirá digitar los docentes desde un sistema web,


ACTORES

docentes dependiendo de las solicitudes por las asignaturas.
Asistente
ESCENARIO
Nombre Docente
Precondiciones

condiciones
Excepciones Información incompleta: Falta llenar datos en el docente.
Nota. fuente: elaboración propia
Caso de gestionar esquela.
Figura 34. Caso de uso gestionar esquela.

Tabla 83.
Gestionar esquela.
Caso de Uso Gestionar esquela
Definición El sistema permitirá digitar las esquelas desde un sistema web,

ACTORES

esquelas dependiendo de las solicitudes.
Asistente
ESCENARIO
Nombre Esquela
Precondiciones Que tenga disponible el catálogo de aranceles y de estudiantes.

condiciones
Excepciones Información incompleta: Falta llenar datos en la esquela.

Caso de uso gestionar estudiante.
Figura 35. Caso de uso gestionar estudiante.
Tabla 84.
Gestionar estudiante.
Caso de Uso Gestionar estudiante
Definición El sistema permitirá digitar los estudiantes desde un sistema web,

ACTORES

estudiantes dependiendo de la solicitud.
Asistente
ESCENARIO
Nombre Estudiante
Precondiciones

condiciones
Excepciones Información incompleta: Falta llenar datos en el estudiante.
Nota. fuente: elaboración propia
Caso de uso gestionar grupo.
Figura 36. Caso de uso gestionar grupo.
Tabla 85.
Gestionar grupo.
Caso de Uso Gestionar grupo
Definición El sistema permitirá digitar los grupos desde un sistema web,


ACTORES

grupos dependiendo del plan de estudio.
ESCENARIO
Nombre Grupo
Precondiciones Que exista carga del ciclo actual.

condiciones
Excepciones Información incompleta: Falta llenar datos en el grupo.
Caso de uso gestionar horario.
Figura 37. Caso de uso gestionar horario.

Tabla 86.
Gestionar horario.
Caso de Uso Gestionar horario
Definición El sistema permitirá digitar el horario desde un sistema web, validando

que se llenen correcta y completamente los datos.
ACTORES
Coordinador Es quién se encargará de manipular el sistema web y digitar el horario

dependiendo de la cantidad de grupos creados para el nuevo ciclo.
ESCENARIO
Nombre Horario
Precondiciones Que exista curso y grupo

condiciones
Excepciones Información incompleta: Falta llenar datos en el horario.

Caso de uso gestionar inscripción especial.
Figura 38. Caso de uso gestionar inscripción especial.
Tabla 87.
Gestionar inscripción especial.
Caso de Uso Gestionar inscripción especial
Definición El sistema permitirá digitar las inscripciones especiales desde un

sistema web, validando que se llenen correcta y completamente los
datos.
ACTORES

inscripciones especiales dependiendo de las solicitudes.
Asistente
ESCENARIO
Nombre Inscripción especial
Precondiciones Tiene que existir catálogo de estudiante con notas reprobadas y que
exista un pago realizado.

condiciones
Excepciones Información incompleta: Falta llenar datos en la inscripción especial.
Caso de uso gestionar monografía.
Figura 39. Caso de uso gestionar monografía.

Tabla 88.
Gestionar monografía.
Caso de Uso Gestionar monografía
Definición El sistema permitirá digitar la monografía desde un sistema web,

ACTORES
Coordinador Es quién se encargará de manipular el sistema web y digitar la

monografía dependiendo de las solicitudes.
Asistente
ESCENARIO
Nombre Monografía
Precondiciones Que el grupo como máximo de 3 estudiantes, se encuentre

matriculado y haya aprobado al menos un 90% de sus asignaturas y
exista un pago realizado por la gestión.

condiciones
Excepciones Información incompleta: Falta llenar datos en la monografía.

Caso de uso gestionar nota.
Figura 40. Caso de uso gestionar nota.
Tabla 89.
Gestionar nota.
Caso de Uso Gestionar nota
Definición El sistema permitirá digitar las notas desde un sistema web, validando
que se llenen correcta y completamente los datos.
ACTORES
Docente Es quién se encargará de manipular el sistema web y digitar las notas

de los cursos inscritos por los estudiantes.
ESCENARIO
Nombre Nota
Precondiciones Que la carga tenga un estado pre-finalizado.


condiciones
Excepciones Información incompleta: Falta llenar datos en la nota
Caso de uso gestionar nota especial (suficiencia.)
Figura 41. Caso de uso gestionar nota especial.
Tabla 90.
Gestionar nota especial.
Caso de Uso Gestionar nota especial
Definición El sistema permitirá digitar las notas especiales desde un sistema

web, validando que se llenen correcta y completamente los datos.

ACTORES
Docente Es quién se encargará de manipular el sistema web y digitar las notas

de los cursos inscritos por los estudiantes.
ESCENARIO
Nombre Nota especial
Precondiciones Que la carga tenga un estado pre-finalizado.

condiciones
Excepciones Información incompleta: Falta llenar datos en nota especial.
Figura 42. Relación de actores.

DIAGRAMAS DE ACTIVIDADES DEL NEGOCIO.
Ciclo académico.
Figura 43. Diagrama de actividad del negocio ciclo académico.

Registro de docente.
Figura 44. Diagrama de actividad del negocio docente.

Registro de nota.
Figura 45. Diagrama de actividad del negocio nota.

DIAGRAMAS DE SECUENCIA.
Guardar docente.
Figura 46. Diagrama de secuencia guardar docente.

Modificar docente.
Figura 47. Diagrama de secuencia modificar docente.

Inactivar docente.
Figura 48. Diagrama de secuencia inactivar docente.

Guardar estudiante.
Figura 49. Diagrama de secuencia guardar estudiante.

Modificar estudiante.
Figura 50. Diagrama de secuencia modificar estudiante.

Inactivar estudiante.
Figura 51. Diagrama de secuencia inactivar estudiante.

Guardar carga académica.
Figura 52. Diagrama de secuencia guardar carga académica.

Actualizar carga académica.
Figura 53. Diagrama de secuencia actualizar carga académica.

Prefinalizar carga académica.
Figura 54. Diagrama de secuencia prefinalizar carga académica.

Finalizar carga académica.
Figura 55. Diagrama de secuencia finalizar carga académica.

Guardar nota.
Figura 56. Diagrama de secuencia guardar nota.

Modificar nota.
Figura 57. Diagrama de secuencia modificar nota.

DIAGRAMAS DE ESTADO.
Carga académica.
Figura 58. Diagrama de estado carga académica.

Docente.
Figura 59. Diagrama de estado docente.

Estudiante.
Figura 60. Diagrama de estado estudiante.

Grupo.
Figura 61. Diagrama de estado grupo.

Nota.
Figura 62. Diagrama de estado nota.

DIAGRAMAS DE COLABORACIÓN.
Nueva carga académica.
Figura 63. Diagrama de colaboración nueva carga académica.
Modificar carga académica.
Figura 64. Diagrama de colaboración modificar carga académica.

Pre finalizar carga académica.
Figura 65. Diagrama de colaboración pre finalizar carga académica.
Modificar carga académica.
Figura 66. Diagrama de colaboración modificar carga académica.

Nuevo docente.
Figura 67. Diagrama de colaboración nuevo docente.
Modificar docente.
Figura 68. Diagrama de colaboración modificar docente.

Activar/desactivar docente.
Figura 69. Diagrama de colaboración activar/desactivar docente.
Finalizar docente.
Figura 70. Diagrama de colaboración finalizar docente.

Nuevo estudiante.
Figura 71. Diagrama de colaboración nuevo estudiante.
Modificar estudiante.
Figura 72. Diagrama de colaboración modificar estudiante.

Activar/desactivar estudiante.
Figura 73. Diagrama de colaboración activar/desactivar estudiante.
Finalizar estudiante.
Figura 74. Diagrama de colaboración finalizar estudiante.

Nueva nota.
Figura 75. Diagrama de colaboración nueva nota.
Modificar nota.
Figura 76. Diagrama de colaboración modificar nota.

Activar/desactivar nota.
Figura 77. Diagrama de colaboración activar/desactivar nota.
Finalizar nota.
Figura 78. Diagrama de colaboración finalizar nota.

DIAGRAMAS DE NAVEGACIÓN.
Diagrama navegacional asistente.
Figura 79. Diagrama navegacional asistente.

Diagrama navegacional coordinador.
Figura 80. Diagrama navegacional coordinador.

Diagrama navegacional docente.
Figura 81. Diagrama navegacional docente.

Diagrama navegacional estudiante.
Figura 82. Diagrama navegacional estudiante.

DIAGRAMAS DE PRESENTACIÓN.
Menú inicio del SISTSIS.
Figura 83. Diagrama de presentación menú inicio del SISTSIS.

Menú coordinador del SISTSIS.
Figura 84. Diagrama de presentación menú coordinador del SISTSIS.

Menú inscripción especial.
Figura 85. Diagrama de presentación menú inscripción especial.

Menú arancel.
Figura 86. Diagrama de presentación menú arancel.

Menú curso.
Figura 87. Diagrama de presentación menú curso.

Menú esquela.
Figura 88. Diagrama de presentación menú esquela.

Menú grupo.
Figura 89. Diagrama de presentación menú grupo.

Menú matrícula.
Figura 90. Diagrama de presentación menú matrícula.

Menú monografía.
Figura 91. Diagrama de presentación menú monografía.

Menú reporte de grupo.
Figura 92. Diagrama de presentación menú reporte de grupo.

Menú estudiante.
Figura 93. Diagrama de presentación menú estudiante.

Menús de carga académica, horario y docente.
Figura 94. Diagrama de presentación menús de carga académica, horario y docente.

Menú asignatura.
Figura 95. Diagrama de presentación menú asignatura.

DIAGRAMAS DE PROCESO Y DE ACTIVIDAD DEL SISTEMA.
Diagrama de proceso: gestionar carga académica.
Figura 96. Diagrama de proceso carga académica.

Diagrama de actividad: creación de carga.
Figura 97. Diagrama de actividad creación de carga.

Diagrama de actividad: activar/desactivar carga académica.
Figura 98. Diagrama de actividad activar/desactivar carga académica.

Diagrama de actividad: modificar carga académica.
Figura 99. Diagrama de actividad modificar carga académica.

Diagrama de proceso: gestionar estudiante.
Figura 100. Diagrama de proceso gestionar docente.

Diagrama de actividad: crear estudiante.
Figura 101. Diagrama de actividad crear estudiante.

Diagrama de actividad: modificar estudiante.
Figura 102. Diagrama de actividad modificar estudiante.

Diagrama de proceso: gestionar matrícula.
Figura 103. Diagrama de proceso gestionar matrícula.

Diagrama de actividad: crear matrícula.
Figura 104. Diagrama de actividad crear matrícula.

Diagrama de actividad: modificar matrícula.
Figura 105. Diagrama de actividad modificar matrícula.

Diagrama de proceso: gestionar nota.
Figura 106. Diagrama de proceso gestionar nota.

Diagrama de actividad: creación de nota.
Figura 107. Diagrama de actividad creación de nota.

Diagrama de actividad: modificar nota.
Figura 108. Diagrama de actividad modificar nota.

Anexo 5. Tasas de cambio.
Figura 109. Tipo de cambio oficial de 12-2017.

Anexo 6. Inflación.
Figura 110. Inflación nacional acumulada 2015-2017.

Anexo 7. Carta de aprobación DTIC.

Figura 105. Carta de aprobación DTIC.

Anexo 8. Proformas.
Figura 106. Proforma CONICO.

Anexo 9. Entrevista DTIC.
Entrevista DTIC
Nombre: _________________________________________________________________
Cargo: _______________
Fecha: ____/_____/_____
1- ¿En qué lenguaje de Programación desarrollan?
2- ¿Cuáles son los gestores de base de datos que son utilizados?
3- ¿Cuál es el sistema operativo en los servidores
4- ¿Cuál es la versión del Gestor de Base de Datos?
5- ¿Cuál es la versión del IIES?
6- ¿Los sistemas actuales poseen Certificados digitales de conexión?
7- ¿Cuantos servidores son dedicados al alojamiento de sistemas web?
8- ¿De cuánto es el ancho de banda del internet asignado al UNI-RUPAP?
9- ¿De cuánto es la capacidad de los servidores web?
10- ¿De cuánto es la capacidad de los servidores de Base de Datos?
11- ¿Con el fin de mejorar los procesos del TSIS en el UNI-RUPAP, estarían de acuerdo
en proporcionar alojamiento al sistema web y a la base de Datos?
ANEXO 10. Encuestas estudiantes TSIS. Fecha: ___/___/_____
Universidad Nacional de Ingeniería
Encuesta
Permítame saludarle muy cordialmente, esta encuesta está dirigida a los estudiantes del
Técnico Superior de Sistemas (TSIS), con el objetivo de conocer su opinión acerca de la
aceptación de una mejora en la gestión mediante la implementación de una aplicación web,
Información que servirá para un trabajo de investigación monográfica, por lo que se requiere
su colaboración al responder las siguientes preguntas:
1. ¿Cómo considera usted la gestión de matrícula, pagos e inscripción de asignaturas del

TSIS?
Muy buena
Buena
Regular
Mala
2. ¿Con qué nivel de eficacia cree usted que cumple el proceso actual de gestión del TSIS?
Muy eficaz
Eficaz
Ligeramente eficaz
Nada eficaz
3. ¿Con qué nivel de eficiencia cree usted que cumple el proceso actual de gestion del TSIS ?.
Muy eficiente
Eficiente
Poco eficiente
Nada eficiente
4. ¿Considera que realiza actividades repetitivas al momento de matricularse?
Si
No
5. Aproximadamente ¿cuánto tiempo espera en las filas para obtener la orden de matrícula?
De 1 min – 3 min
De 4 min – 8 min
De 9 min – 15 min
6. ¿Cuánto tiempo espera en las filas para inscripción de asignaturas?
De 1 min – 3 min
De 4 min – 8 min
De 9 min – 15 min
7. En general, ¿qué tan satisfecho está usted con la gestión de matrícula, pagos e inscripción de
asignaturas del TSIS?
Muy satisfecho
Moderadamente satisfecho
Poco satisfecho
Insatisfecho
8. ¿Considera muy tardía la respuesta de alguna consulta o informe incluyendo las notas?
Si
No
9. ¿Qué tan importante considera usted el uso de la tecnología en la gestión de los procesos TSIS?
Muy importante
Moderadamente importante
Poco importante
Sin importancia
10. ¿Qué tan útil consideraría usted un sistema que automatice la gestión de los procesos del
TSIS?
Muy útil
Moderadamente útil
Poco útil
Inútil
11. ¿Estaría de acuerdo en que se implemente un sistema automatizado para la gestión de los
procesos del TSIS?
Si
No
12. ¿Qué tanta influencia, cree usted que tiene la reputación de la Universidad Nacional de
Ingeniería al momento de implementar un Sistema automatizado?
Mucha influencia
Suficiente influencia
Poca influencia
Ninguna afluencia
13. En general, ¿qué tan importante cree usted que un Sistema sea de gran usabilidad?
Muy importante
Moderadamente importante
Poco importante
Sin importancia
14. ¿Qué tanta influencia tiene el diseño de interfaz, al momento de implementar un Sistema?
Mucha influencia
Suficiente influencia
Poca influencia
Ninguna influencia
15. ¿Le gustaría una plataforma en donde pueda consultar su información académica en línea?
Si
No
16. ¿Qué tipos de dispositivo utiliza usted para conectarse a internet?

Computadora escritorio
Laptop
Celular
Tablet
ANEXO 11. Entrevista coordinador y secretaria TSIS.
Fecha: ___/___/_____
Universidad Nacional de Ingeniería
Entrevista formal no estructurada para el Coordinador del TSIS

1. ¿Cuáles son las tecnologías en hardware y software que actualmente se usa para
la gestión de matrícula operaciones en el TSIS?
2. ¿Cuántas computadoras tienen disponibles para la gestión de los procesos?
3. ¿Poseen una infraestructura de red LAN y WAN?

4. ¿Cuentan con servicio de Internet para ayuda de la gestión del TSIS?
5. ¿Poseen un plan de mejora para los procesos de gestión del TSIS?
6. ¿Cómo considera usted la gestión de matrícula, pagos e inscripción de

asignaturas del TSIS?
7. ¿Es eficiente la gestión actual del TSIS?

8. ¿Cree usted que la gestión actual del TSIS es la adecuada? ¿Por qué?
9. ¿Usted se siente satisfecha con el proceso de gestión actual? ¿Por qué?
10. ¿Siente que se podrían mejorar los procesos del TSIS? ¿Por qué?
11. ¿Cuántas de las tareas están computarizadas, cuantas semi computarizado y

cuantas se realizan de manera manual en el TSIS?
12. ¿Cuáles son los procesos que se efectúan en la gestión académica del TSIS?
Explique cada uno.
13. ¿Quiénes son los que tienen permitidos realizar, inscripciones de alumnos,
maestros, entregas de notas y realización de pagos de matrículas y
mensualidades?
Técnico Superior de Sistemas (TSIS)
Fecha: ___/___/_____
Entrevista formal no estructurada para la secretaria TSIS.
14. ¿Cuáles son las tareas que realiza en el TSIS?
15. ¿Cuánto tiempo lleva la entrega de la orden de pago al estudiante?
16. ¿Cuánto tiempo lleva la inscripción de asignaturas por estudiantes?
17. ¿Cuántos estudiantes están matriculados actualmente en el TSIS?
18. ¿Cuánto tiempo se lleva en responder una consulta de notas de un estudiante?
19. ¿Cuántos docentes imparten clases actualmente en el TSIS?
20. ¿Cuántas asignaturas posee el currículo del TSIS?
21. ¿Cuáles son los reportes que se generan?
22. ¿Cree usted que la gestión actual del TSIS es la adecuada? ¿Por qué?
23. ¿Usted se siente satisfecha con el proceso de gestión actual? ¿Por qué?
24. ¿Siente que se podrían mejorar los procesos del TSIS? ¿Por qué?
ANEXO 12. Tabla de premio al riesgo.
Tabla 91
Premio al Riesgo.
Nota: fuente. http://www.applet-magic.com/countryrisksp.htm

ANEXO 13. Interés para el cálculo de la amortización.
Fuente: https://www.banprogrupopromerica.com.ni/banca-de-personas/cr%C3%A9ditos/calcula-la-
cuota-de-tu-prestamo-personal.
ANEXO 14. Esquela de pagos.

Universidad Nacional de Ingeniería Facultad de Ciencias Y Sistemas Ingeniería de Sistemas

Cargado por

Copyright:

Formatos disponibles

Universidad Nacional de Ingeniería Facultad de Ciencias Y Sistemas Ingeniería de Sistemas

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Universidad Nacional de Ingeniería Facultad de Ciencias Y Sistemas Ingeniería de Sistemas

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL DE INGENIERÍA

FACULTAD DE CIENCIAS Y SISTEMAS

MONOGRAFÍA PARA OPTAR AL TÍTULO DE INGENIERO DE SISTEMAS

DESARROLLO DE UNA APLICACIÓN WEB DE GESTIÓN ACADÉMICA Y

BR. GERALD DE JESÚS GONZÁLEZ ZELEDÓN 2010 – 33312

MSC. ING. YASSER MEMBREÑO GUDIEL

Managua, Septiembre del 2018

A Dios, porque siempre estuvo a nuestro lado en todo el transcurso de esta

A nuestros padres, por su apoyo en la elección de nuestra carrera universitaria,

A nuestros hermanos, parientes y amigos, por sus consejos, paciencia y toda

El presente documento, brinda al programa del Técnico Superior de

El objetivo es desarrollar un sistema que se ajuste a los procesos del TSIS y

Así mismo, se presenta un estudio de factibilidad para la aceptación que tiene

 Procesos académicos que engloba: el registro de docentes, estudiantes,

Entre los beneficios de este proyecto, podemos mencionar:

Finalmente, mediante los formatos de reportes propuestos, se presenta al

La Facultad de Ciencias y Sistemas del Recinto Universitario Pedro Arauz

En la actualidad la gestión académica de esta carrera se realiza de forma

La gestión se realiza a través de las herramientas: Microsoft Access, Excel,

Para ello se determinó la viabilidad del desarrollo de la aplicación Web

Finalmente se desarrolló la aplicación web de Gestión académica del TSIS

Desarrollar una aplicación web para la gestión académica y control de pagos

 Determinar la viabilidad del desarrollo de la aplicación Web mediante un

Los beneficios que se obtendrán con el desarrollo de la aplicación web serán

Así mismo el estudiante será beneficiado, ya que, con la creación de la

Esta aplicación permitirá al Técnico Superior en Informática y Sistemas

Entre otros beneficios se hace mención a la disminución sustantiva de los

El Programa Técnico Superior en Informática y Sistemas está ubicado en el

La gestión de los procesos que se incurren para dar el servicio a los

Desde la creación de la carrera técnica (2011) hasta la actualidad se ha hecho

Descripción del tipo de trabajo a realizar.

Se realiza una investigación proyectiva (La investigación proyectiva-

En esencia es lo que se hará, una propuesta de mejora mediante una

Así mismo el estudiante podrá tener disponible la información académica de

Descripción del universo e integrantes del estudio

Universo: La Facultad de Ciencias y Sistemas.

Se denomina la Facultad como el universo ya que es la que regula y controla

Sistema: Técnico Superior de Informática y Sistemas (TSIS).

Selección de la población y muestra.

 El cálculo de la muestra de estudiantes se estimó con una media

Integrante 2013 2014 2015 Promedio

Nota: fuente, TSIS.

Obteniendo una población de 64 estudiantes en promedio en los últimos 3

Para la selección de la muestra en estudio se utiliza la ecuación 1 (Aguilar-

Z: Valor correspondiente a la distribución de Gauss (Zúniga, 2016) según el

P=Proporción esperada (en este caso 0.5)

Q: 1-P (en este caso 0.5)

d: Error que se prevé cometer (en este caso 10%)

El tamaño de la muestra para la población estudiantil es:

64 ∗ 1.6452 ∗ 0.5 ∗ 0.5

En base a los resultados obtenidos se requiere realizar la encuesta a 33

Las fuentes de información son los instrumentos para el conocimiento,

1. Documentos y formatos que se generan al momento de la gestión de los

I. Estudios realizados anteriormente sobre la gestión de los procesos del

Tipo de información requerida de las fuentes

Coordinador 4. Tecnologías que usan.

Nota: fuente. TSIS.

Instrumentos para la recopilación de datos.

Se plantean los siguientes instrumentos de recopilación de datos para la