Uladech Biblioteca Virtual PDF

118
Universidad Los Angeles de Chimbote

Facultad de Ingeniería
Escuela Profesional de Ingeniería de Sistemas
SISTEMA DE INFORMACION WEB PARA EL

DEPARTAMENTO DE COBRANZAS DE LA UNIVERSIDAD
LOS ANGELES DE CHIMBOTE
TESIS PARA OPTAR EL TITULO DE

INGENIERO DE SISTEMAS
Autores:
Bach. Carlos Alberto Coronado Cuma
Bach. Gilmer Velásquez Soto
Asesor:
Ing. Gianncarlo Gomez Morales
Chimbote - Perú
2007
PRESENTACION
La meta de todo estudiante universitario es obtener el titulo profesional, esta

meta se materializa con el desarrollo de la tesis, cuya importancia radica en
explotar la creatividad e impulsar el interés por la investigación científica.
La tesis que se presenta en este trabajo se fundamenta en la situación

problemática que se viene dando dentro del ámbito del Departamento de
Cobranzas de la Universidad Los Angeles de Chimbote.
La presente tesis titulada: “SISTEMA DE INFORMACION WEB PARA EL

DEPARTAMENTO DE COBRANZAS DE LA UNIVERSIDAD LOS ANGELES DE
CHIMBOTE”, contempla los aspectos relacionados con el análisis, diseño e
implementación de un sistema de información basado en la tecnología web; para
ello se realiza una serie de tareas propuestas por la metodología de desarrollo
UWE; el objetivo es dar solución a estos problemas que se originan por la falta de
centralización de la información relacionada con los ingresos de la institución.
Con el debido respeto presento señores miembros del jurado la presente

tesis.
Los Autores
AGRADECIMIENTOS
Ante todo, mi agradecimiento a Adiós por permitirme concluir mi carrera

profesional y por todos los objetivos realizados en mi vida profesional.
Quiero expresar mi agradecimiento a las personas que han participado de

alguna forma en el desarrollo de este proyecto.
A mi asesor por guiarme en el desarrollo de la tesis y compartir sus

conocimientos profesionales conmigo.
Al director y docentes de la Escuela Profesional de Ingeniería de Sistemas

por brindarme la formación profesional durante los cinco años en ésta casa de
estudios.
A mis padres, por el apoyo invalorable hacia mi desarrollo personal y

profesional.
A mis amigos y compañeros de trabajo, por el animo recibido.
¡Gracias a todos!
Universidad los Angeles de Chimbote
Facultad de Ingeniería
Escuela Profesional de Ingeniería de Sistemas
SISTEMA DE INFORMACION WEB PARA EL

DEPARTAMENTO DE COBRANZAS DE LA UNIVERSIDAD
LOS ANGELES DE CHIMBOTE
TESIS PARA OPTAR EL TITULO DE

INGENIERO DE SISTEMAS
APROBADA
Ing. Jorge Gutiérrez Gutiérrez
Ing. José Saldaña Tirado
Ing. Bogar Mantilla Gordillo

RESUMEN
La elaboración de la presente tesis tiene como objetivo el desarrollo de un

Sistema de Información basado en tecnología web que constituya una importante
herramienta de apoyo para mejorar la gestión en el Departamento de Cobranzas de
la Universidad Los Ángeles de Chimbote.
Dicho sistema de información permitirá gestionar los pagos en línea de las

filiales con las que cuenta la universidad, centralizar la información en tiempo real
facilitando de manera indirecta el desempeño de otras áreas de la institución.
El sistema estará dotado de funcionalidades que permita obtener

información en línea sobre los ingresos e historiales de pagos de los alumnos.
ABSTRACT
The elaboration of the present work has as objective the development of the
information system based on web technology that constitutes an important tool of
help to improve the administration in the treasure Department of the “Los Angeles
de Chimbote” University.
That information system will allow to negotiate the on-line payments of all
branches of the University, to centralize the information in real time performing
indirectly the work of other administrative areas.
The System will be equipped with features that will allow to obtain relevant
information on line about the payment and histories of the students payments.
INDICE
Pág.
INTRODUCCCION ……………………………………………………………….. 15
I. ASPECTOS GENERALES ……………………………………………………….. 16
1.1. Descripción de la organización ……………………………………………… 17
1.1.1. Razón social …………………………………………………………… 17
1.1.2. Ubicación geográfica …………………………………………………. 17
1.1.3. Fines de la universidad ………………………………………………. 17
1.1.4. Visión …………………………………………………………………… 18
1.1.5. Misión …………………………………………………………………... 18
1.1.6. Organigrama …………………………………………………………... 18
1.2. Ámbito y alcance del proyecto ………………………………………………. 19
1.2.1. Definición del proyecto ………………………………………………. 19
1.2.2. Alcance del proyecto …………………………………………………. 19
1.2.3. Áreas y/o dependencias afectadas …………………………………. 19
1.3. Funciones y procedimientos ………………………………………………… 20
1.3.1. Departamento de Cobranzas ………………………..……………… 20
1.3.1.1. Funciones ……………………………………………………….. 20
1.3.1.2. Gestión y procedimientos ……………………………………... 20
1.3.2. Analista de ingresos ………………………………………………….. 28
1.3.2.1. Funciones ……………………………………………………….. 28
1.3.2.2. Gestión y procedimientos ……………………………………... 29
1.3.3. Unidades recaudadoras (cajas) …………………………………….. 30
1.3.3.1. Funciones ……………………………………………………….. 30
II. PLAN DE INVESTIGACION ……………………………………………………… 31
2.1. Planteamiento del problema ………………………………………………… 32
2.2. Enunciado del problema ……………………………………………………... 33
2.3. Hipótesis ………………………………………………………………………. 33
2.4. Objetivos del proyecto ……………………………………………………...... 34
2.4.1. Objetivo general ………………………………………………………. 34
2.4.2. Objetivos específicos …………………………………………………. 34
2.5. Justificación …………………………………………………………………… 35
2.5.1. Justificación económica ……………………………………………… 35
2.5.2. Justificación tecnológica ……………………………………………... 36
2.5.3. Justificación social ……………………………………………………. 36
2.6. Costo del proyecto ……………………………………………………………. 36
2.7. Beneficios del proyecto ………………………………………………………. 40
2.8. Recursos del proyecto ……………………………………………………….. 40
2.8.1. Recursos humanos …………………………………………………… 40
2.8.2. Recursos de software ………………………………………………… 41
2.8.3. Recursos de hardware ……………………………………………….. 41
2.8.4. Recursos de materiales ……………………………………………… 42
2.9. Marco teórico ………………………………………………………………….. 43
2.9.1. Gestión ..………………………………………………………………. 43
2.9.2. Gestión de cobranzas ...……………………………………………… 43
2.9.3. Sistema de información ...……………………………………………. 43
2.9.4. Sistema cliente – servidor ...…………………………………………. 45
2.9.4.1. Ventajas ......…………………………………………………….. 46
2.9.5. Internet ..……………………………………………………………….. 46
2.9.6. Wide World Web ..….…………………………………………………. 47
2.9.6.1. Funcionamiento de la web .…......…………………………….. 47
2.9.7. Navegador de Internet………………………………………………… 49
2.9.8. Servidor Web…………………………………………………………... 49
2.9.9. Aplicación Web………………………………………………………… 52
2.9.9.1. Características de desarrollo de una aplicación web ………. 54
2.9.9.2. Requisitos de desarrollo de una aplicación web ...…...…….. 54
2.9.9.3. Requisitos para la aplicación de una aplicación web .…..…. 55
2.9.10. Ingeniería Web ……...………………………………………………… 57
2.9.11. Lenguaje Unificado de Modelado …..………………………………. 58
2.9.12. Servidor HTTP Apache ….…..……………………………………….. 60
2.9.13. Sistema operativo Linux ….….………………………………………. 62
2.9.14. Gestor de base de datos MySQL ...…………………………………. 63
2.9.15. PHP ...……...…………………………………………………………... 64
2.9.16. XAJAX ….….….……………………………………………………….. 64
2.10. Metodología de desarrollo UWE …..….…………………………………… 65
2.10.1. Relaciones con otras metodologías ……...…………………………. 68
2.10.2. Criterios de selección de la metodología UWE ……………………. 69
III. DESARROLLO ....…..…………………………………..…………………………. 70
3.1. Captura de requisitos .…..……………………………………………………. 72
3.1.1. Identificación de participantes ...…………………………………….. 72
3.1.2. Objetivos del sistema …...……………………………………………. 73
3.1.3. Identificación de actores ……………………………………………... 74
3.1.4. Definición de requisitos ...…...……………………………………….. 76
3.1.4.1. Requisitos de almacenamiento de información …………….. 76
3.1.4.2. Requisitos de interfaz .…...…...……………………………….. 81
3.1.4.3. Requisitos transaccionales o funcionales ..….………………. 81
3.1.4.4. Requisitos no funcionales .…...……..………………………… 97
3.1.4.4.1. Seguridad ...………………………………………………. 97
3.1.4.4.2. Usabilidad .….……………………………………………. 98
3.1.4.4.3. Rendimiento ..……………………………………………. 98
3.1.4.4.4. Mantenimiento ...…………………………………………. 98
3.1.4.4.5. Entorno de desarrollo ...…………………………………. 98
3.2. Análisis y Diseño .….…………………………………………………………. 99
3.2.1. Diseño conceptual ..………………………………………………….. 99
3.2.2. Diseño navegacional …..…………………………………………….. 103
3.2.2.1. Modelo del espacio navegacional .….……………………….. 103
3.2.2.2. Modelo de la estructura de navegación .…..………………… 108
3.2.3. Diseño de presentación …………..…………………………………. 110
3.2.4. Diseño lógico de la base de datos ……..………………………….. 118
3.3. Implementación .….…………………………………………………………... 120
3.3.1. Implementación de la base de datos ………………..……………... 120
3.3.1.1. Objetivos y servicios de la base de datos ..…………………. 120
3.3.1.2. Gestor de base de datos ..…………………………………….. 121
3.3.1.3. Estructura de la base de datos ….….………………………... 122
3.3.1.3.1. Convenciones de estructura de la base de datos ..….. 122
3.3.1.3.2. Descripción de tablas ...…………………………………. 123
3.3.1.3.3. Estructura de tablas …………………….…….…….…… 127
3.3.2. Implementación de la interfaz de usuario .….……………………… 141
3.3.2.1. Características de diseño …………….….….………………… 141
3.3.2.2. Pantallas .….……………………………………………………. 142
3.3.3. Implementación de la arquitectura .….……………………………… 150
3.3.3.1. Arquitectura lógica …….….….………………………………… 150
3.3.3.2. Arquitectura física .….…………………………………………. 152
IV. DISCUSIÓN DEL PROYECTO ….….…………………………………………… 155
4.1. Contrastación de hipótesis ………….….…………………………………… 156
4.1.1. Población ………..……………………………………………………. 156
4.1.2. Muestra .….……………………………………………………………. 156
4.1.3. Validación de contrastación de hipótesis ….…..…………………… 158
4.2. Verificación de la calidad del software .…..………………………………… 161
V. CONCLUSIONES Y RECOMENDACIONES ..….……………………………… 164
5.1. Conclusiones ..………………………………………………………………... 165
5.2. Recomendaciones .…..………………………………………………………. 166
VI. REFERENCIAS BIBLIOGRAFICAS .…..……………………………………….. 167
VII. GLOSARIO .…...……...……………………………………………………………. 169
VIII. ANEXOS …..…………………………………………………..…………………… 172
ANEXO Nº 01: Tablas y valores para COCOMO .….……………………… 172
ANEXO Nº 02: Organigrama de la Universidad Los Angeles de
Chimbote ……………..………………………………………. 174
ANEXO Nº 03: Tabla estadística T-Student ….......………………………… 175
ANEXO Nº 04: Recopilación de datos y sugerencias de usuario ………... 176
INDICE DE GRAFICOS
Pág.
Gráfico Nº 1: Organigrama del Departamento de Cobranzas .……………….. 19
Gráfico Nº 2: Objetivos del proyecto …………………………………………….. 35
Gráfico Nº 3: Flujo de datos ………………………………………………………. 37
Gráfico Nº 4: Funcionamiento general de la web ………………………………. 48
Gráfico Nº 5: Funcionamiento básico de servidor web ………………………... 50
Gráfico Nº 6: Arquitectura básica de una aplicación web ……………………... 52
Gráfico Nº 7: Jerarquía de los diagramas UML 2.0 ……………………………. 59
Gráfico Nº 8: Proceso de desarrollo de la metodología UWE ………………… 65
Gráfico Nº 9: UWE y otras metodologías de desarrollo web …………………. 68
Gráfico Nº 10: Diagrama de casos de uso ……………………………………… 82
Gráfico Nº 11: Vista de compromisos …………………………………………… 100
Gráfico Nº 12: Vista de ingresos …………………………………………………. 101
Gráfico Nº 13: Vista de usuarios …………………………………………………. 102
Gráfico Nº 14: Usuarios del sistema …………………………………………….. 103
Gráfico Nº 15: Espacio de navegación del usuario Cajera …………………… 105
Gráfico Nº 16: Espacio de navegación del usuario Jefe de Área …………….. 106
Gráfico Nº 17: Espacio de navegación del usuario Administrador …………… 107
Gráfico Nº 18: Estructura de navegación ……………………………………….. 109
Gráfico Nº 19: Boceto Registrar comprobante pago …………………………... 111
Gráfico Nº 20: Boceto Ingresar cronograma de pago …………………………. 112
Gráfico Nº 21: Boceto Mantenimiento plan de costos …………………………. 113
Gráfico Nº 22: Boceto Liquidación diaria ………………………………………... 114
Gráfico Nº 23: Boceto Emitir reporte de pensiones por cobrar ……………….. 115
Gráfico Nº 24: Boceto Consultar compromisos del alumno …………………... 115
Gráfico Nº 25: Boceto Fraccionamiento de deuda …………………………….. 116
Gráfico Nº 26: Boceto Anular comprobante pago ……………………………… 116
Gráfico Nº 27: Boceto Consultar kardex de pagos del alumno ………………. 117
Gráfico Nº 28: Modelo Entidad-Relación ………………………………………... 119
Gráfico Nº 29: Estructura de la tabla alumnos …………………………………. 127
Gráfico Nº 30: Estructura de la tabla alumno_categoria ………………………. 128
Gráfico Nº 31: Estructura de la tabla alumno_escuela ………………………… 128
Gráfico Nº 32: Estructura de la tabla caja ………………………………………. 129
Gráfico Nº 33: Estructura de la tabla compromiso ……………………………... 129
Gráfico Nº 34: Estructura de la tabla comprobante_pago …………………….. 130
Gráfico Nº 35: Estructura de la tabla config_system …………………………... 131
Gráfico Nº 36: Estructura de la tabla correlativo ……………………………….. 131
Gráfico Nº 37: Estructura de la tabla cronograma_pagos …………………….. 132
Gráfico Nº 38: Estructura de la tabla escuela …………………………………... 132
Gráfico Nº 39: Estructura de la tabla filial ……………………………………….. 133
Gráfico Nº 40: Estructura de la tabla fraccionamiento_cab …………………… 133
Gráfico Nº 41: Estructura de la tabla fraccionamiento_detalle ……………….. 134
Gráfico Nº 42: Estructura de la tabla historial_constancia ……………………. 134
Gráfico Nº 43: Estructura de la tabla historial_nota_credito ………………….. 135
Gráfico Nº 44: Estructura de la tabla historial_resolucion …………………….. 135
Gráfico Nº 45: Estructura de la tabla maestro_categoria ……………………… 135
Gráfico Nº 46: Estructura de la tabla maestro_estado ………………………… 136
Gráfico Nº 47: Estructura de la tabla maestro_grupo_tasa …………………… 136
Gráfico Nº 48: Estructura de la tabla maestro_modalidad ……………………. 136
Gráfico Nº 49: Estructura de la tabla maestro_modalidad_pension …………. 136
Gráfico Nº 50: Estructura de la tabla maestro_resolucion_tipo ………………. 137
Gráfico Nº 51: Estructura de la tabla maestro_semestre ……………………… 137
Gráfico Nº 52: Estructura de la tabla maestro_tasa …………………………… 137
Gráfico Nº 53: Estructura de la tabla maestro_tasa_escuela ………………… 138
Gráfico Nº 54: Estructura de la tabla maestro_turno_alumno ………………… 138
Gráfico Nº 55: Estructura de la tabla maestro_turno_cajas …………………... 138
Gráfico Nº 56: Estructura de la tabla maestro_usuario_tipo ………………….. 139
Gráfico Nº 57: Estructura de la tabla plan_costo ………………………………. 139
Gráfico Nº 58: Estructura de la tabla planes ……………………………………. 139
Gráfico Nº 59: Estructura de la tabla sede ……………………………………… 140
Gráfico Nº 60: Estructura de la tabla usuarios …………………………………. 140
Gráfico Nº 61: Pantalla Inicio de sesión ………………………………………… 142
Gráfico Nº 62: Pantalla Menú principal ………………………………………….. 143
Gráfico Nº 63: Pantalla Registrar comprobante de pago ……………………… 143
Gráfico Nº 64: Pantalla Ingresar cronograma de pagos ………………………. 144
Gráfico Nº 65: Pantalla Mantenimiento plan de costos ………………………... 144
Gráfico Nº 66: Pantalla Liquidación diaria ………………………………………. 145
Gráfico Nº 67: Pantalla Pensiones por cobrar …………………………………. 146
Gráfico Nº 68: Pantalla Consular compromisos del alumno ………………….. 147
Gráfico Nº 69: Pantalla Anular comprobante pago …………………………….. 147
Gráfico Nº 70: Pantalla Generar fraccionamiento de deuda ………………….. 148
Gráfico Nº 71: Pantalla Consultar kardex de pagos del alumno …………….. 149
Gráfico Nº 72: Arquitectura lógica del sistema …………………………………. 150
Gráfico Nº 73: Esquema de conexión de las filiales …………………………… 154
Gráfico Nº 74: Cuadro comparativo del nivel de aceptación de los usuarios .. 158
Gráfico Nº 75: Factores de calidad de software ………………………………... 161
Gráfico Nº 76: Organigrama de la ULADECH ………………………………….. 174
INDICE DE TABLAS
Pág.
Tabla Nº 1: Recursos humanos ………………………………………………….. 40
Tabla Nº 2: Recursos de software ……………………………………………….. 41
Tabla Nº 3: Recursos de hardware ………………………………………………. 41
Tabla Nº 4: Recursos de materiales ……………………………………………... 42
Tabla Nº 5: Distribución de recursos …………………………………………….. 42
Tabla Nº 6: Patrón del participante PA-01 ……………………………………… 72
Tabla Nº 7: Patrón del participante PA-03 ……………………………………… 72
Tabla Nº 8: Patrón del participante PA-03 ……………………………………... 72
Tabla Nº 9: Patrón del participante PA-04 ……………………………………... 72
Tabla Nº 10: Patrón del participante PA-05 …………………………………….. 73
Tabla Nº 11: Patrón del objetivo OBJ-01 ……………………………………….. 73
Tabla Nº 16: Patrón del Actor AC-01 ……………………………………………. 74
Tabla Nº 20: Patrón del requisito RA-01 ………………………………………… 76
Tabla Nº 27: Patrón del la naturaleza NA-01 …………………………………… 80
Tabla Nº 28: Patrón de requisito RF-01 …………………………………………. 83
Tabla Nº 35: Patrón de requisito RF-08 ………………………………………… 88
Tabla Nº 54: Descripción de tablas de la base de datos ……………………… 127
Tabla Nº 55: Líneas de conexión a Internet …………………………………….. 153
Tabla Nº 56: Factores de ponderación de la muestra …………………………. 156
Tabla Nº 57: Resultado de aceptación de usuario del sistema anterior …….. 157
Tabla Nº 58: Resultado de aceptación de usuario del sistema actual ………. 157
Tabla Nº 59: Factor de ponderación - Calidad de Software ….………..……… 162
Tabla Nº 60: Plantilla de ponderación - Calidad de Software ……………...… 162
Tabla Nº 61: Ponderación de métricas - Calidad de Software …..…………… 163
Tabla Nº 62: Esfuerzo y tiempo de desarrollo – Nivel Intermedio ……………. 172
Tabla Nº 63: Factores que afectan al esfuerzo ………………………………… 172
Tabla Nº 64: Calculo del valor de complejidad del proyecto ………………….. 173
Tabla Nº 65: Tabla estadística T-Student ………………………………………. 175
INTRODUCCION
La Universidad Los Angeles de Chimbote, es una institución que ha crecido

considerablemente en estos últimos años, y uno de los aspectos relacionados con
ello, a sido la descentralización de oficinas de recaudación; sin embargo esto
también a originando una serie de problemas en el Departamento de Cobranzas y a
otras áreas de la institución debido a la incapacidad del sistema actual para brindar
el soporte necesario.
En esta tesis se presenta una solución haciendo uso de tecnologías web;

para ello es necesario emplear una metodología de desarrollo adecuada; para ello
se ha realizado el análisis de las metodologías existentes del cual se ha elegido a la
metodología UWE (UML-Based Web Engineering) como la más acertada y que
contempla una serie de tareas que se adecuan a nuestras necesidades de
desarrollo.
La presente tesis esta estructurado de la siguiente manera:

En el capitulo I, se presenta a la institución y el ámbito en la cual tendrá
efecto el proyecto.
En el capitulo II, referido a los aspectos del análisis de la problemática y las

justificaciones para llevar acabo el proyecto, se incluye el marco conceptual donde
se definen los conceptos teóricos para comprender el desarrollo de esta tesis.
En el capitulo III, se desarrolla cada una de las etapas de la metodología

UWE, la misma que esta divida en tres etapas principales de las cuales se
subdividen en un conjunto de tareas que deben realizarse a lo largo del desarrollo
del proyecto.
En el capitulo IV, se somete el proyecto a un análisis para determinar la

validación de la hipótesis planteada mediante herramientas estadísticas aceptadas.
En el capitulo V, se plantean las conclusiones del proyecto y algunas

recomendaciones que deben considerarse en futuras ampliaciones del proyecto.
En el capitulo VI, las referencias bibliográficas y otras fuentes de ayuda que

se emplearon durante el desarrollo de la tesis.
En el capitulo VII, se describe un conjunto de términos empleados en el

presente documento.
En el capitulo VIII, se incluye el anexo del documento, que consiste en

información adicional y formatos que se utilizaron para desarrollar el proyecto.
Capitulo I
ASPECTOS GENERALES
Sistema de Información de Cobranzas Web ULADECH
1.1. Descripción de la organización
1.1.1. Razón social.
Universidad Los Angeles de Chimbote
1.1.2. Ubicación geográfica
La Universidad Los Angeles de Chimbote, tiene como Sede

Central la ciudad de Chimbote, Distrito Chimbote, Provincia del Santa,
Departamento de Ancash, cuya dirección es: Av. Bolognesi Nº 835 –
Telefax: 043-343444.
1.1.3. Fines de la universidad
La ULADECH es una universidad autónoma. Son fines de la

universidad:
• Contribuir a la formación integral del hombre, la transformación y

el desarrollo del país y la región, y el logro de una sociedad justa.
• Conservar, acrecentar y transmitir con sentido crítico y creativo,
"la cultura nacional y la cultura universal.
• Realizar investigación en humanidades, ciencia, tecnología, y
arte; adecuándolos a los requerimientos nacionales y regionales
con el objeto de ofrecer alternativas eficaces y viables para su
propio desarrollo y la transformación socio-económica del país y
fomentar la creación intelectual, artística y deportiva,
promoviendo su difusión.
• Formar profesionales humanistas, científicos e investigadores de
alta calidad académica, según las necesidades de la región y el
país.
• Vincularse a la comunidad por medio de mecanismos de
interacción dinámica, destinados a recoger la experiencia y
conocimiento que se produce fuera del claustro ya extender su
acción y servicio hacia ella.
• Promover la capacitación y el perfeccionamiento de sus
docentes, así como la permanente actualización de sus
graduados
Escuela de Ingeniería de Sistemas 17

1.1.4. Visión
La ULADECH, se visualiza como una comunidad universitaria, de

docentes, estudiantes y trabajadores, como un equipo que centra su
accionar en el servicio de calidad al estudiante, desarrollando sus fines
de enseñanza, investigación y proyección social, en continuo proceso de
innovación, crecimiento y mejora permanente, como una organización de
aprendizaje con responsabilidad social universitaria.
1.1.5. Misión
La ULADECH , es una institución privada sin fines de lucro que

tiene por misión principal ofrecer oportunidades de profesionalización de
calidad en entornos abiertos a nivel nacional adecuándose a la
capacidad económica de un creciente numero de estudiantes y
graduados, ofreciéndoles además una formación en desarrollo humano
de alto nivel.
1.1.6. Organigrama
La ULADECH cuenta y hace de su autonomía, a través de sus

Órganos competentes que le permite ejercer las siguientes Atribuciones:
• Aprobar su Estatuto, sus Reglamentos y gobernarse de acuerdo a

ellos.
• Organizar sus sistemas académico, administrativo y económico.
• Administrar sus bienes y rentas, elaborar su presupuesto y aplicar
sus fondos dentro de las responsabilidades que impone la Ley.
El organigrama estructural de la ULADECH se incluye en el capitulo

Anexos, página 174, Grafico Nº 76.

1.2. Ambito y alcance del proyecto
1.2.1. Definición del proyecto
Desarrollo de un Sistema de Información Web para el Departamento

de Cobranzas de la Universidad Los Angeles de Chimbote, mediante el uso
de herramientas libres.
1.2.2. Alcance del proyecto
Para desarrollar el proyecto se ha establecido una serie de

actividades programadas. Desde reuniones, entrevistas, cuestionarios y
otras técnicas de recolección de datos que nos permitirán entender la
problemática actual en el Departamento de Cobranzas y dependencias
afectadas; esto también comprende identificar el ámbito en las que el
proyecto tendrá incidencia.
Realizado el estudio preliminar, haremos un análisis para identificar

los requerimientos y características que deben considerarse antes, durante y
después del desarrollo del proyecto.
Así mismo se diseñará toda la arquitectura necesaria para poner en

funcionamiento el proyecto; se tocaran aspectos como el modelado de la
aplicación y arquitectura de soporte.
1.2.3. Áreas y/o dependencias afectadas

• Departamento de Cobranzas
• Analista de Ingresos
• Unidades Recaudadoras (Cajas)
Departamento de
Cobranzas
Analista de Ingresos
Unidades
Recaudadoras (Cajas)
Gráfico Nº 1: Organigrama del Departamento de Cobranzas

Fuente: Elaboración Propia

1.3. Funciones y procedimientos
1.3.1. Departamento de Cobranzas
El Departamento de Cobranzas es un órgano que depende

jerárquicamente de la Jefatura de la Oficina de Economía, ejerce autoridad
sobre el Analista de Ingresos y las Unidades Recaudadoras o Cajas.
1.3.1.1. Funciones
• Verificar los vouchers de pagos por conceptos de tasas y

académicas (matrículas, pensiones, grados, títulos,
categorizaciones, matrícula por creditaje, pagos de internos,
PATROS, seminarios, etc.) de toda las SEDES.
• Supervisar, verificar y reportar las morosidades.
• Recepcionar y controlar los pagos de acuerdo a las
resoluciones, solicitudes de cambio de escuela,
condonaciones de deudas etc.
• Recepcionar, evaluar y tramitar las solicitudes de
transferencias y devolución de pagos.
• Verificar y realizar los documentos de planilla del convenio
con la UGEL.
• Coordinar y supervisar los pagos por conceptos de
implementación de la clínica con el visto bueno del director.
• Realizar el seguimiento del servicio recaudador telemático
Teletransfer y controlar el envió a las diferentes SEDES los
respectivos comprobantes de pagos.
• Otros que le sean asignadas por la Jefatura de Economía.
1.3.1.2. Gestión y procedimientos
• Apertura de semestre académico
a) Los Decanos de las Facultades de Escuela, Directores de

Escuelas y Coordinadores de Sede deberán enviar al
Departamento de Cobranzas:
• Fecha de inicio y termino de matricula regular y
extemporánea.
• Especificar el semestre de apertura.

• Fecha de inicio y termino de cada ciclo Académico por

cada escuela.
b) A partir del segundo ciclo de estudio, los alumnos deberán
cancelar respectivamente boleta de notas de manera
obligatoria; antes de su matricula del nuevo ciclo académico.
c) Los pagos de matricula tendrán como plazo máximo de
recepción, 30 días hábiles de iniciada la matricula regular.
d) Los costos de pensiones según matricula es como sigue:
• Matriculado de 01 a 08 créditos: el costo de las
pensiones se generan de acuerdo al costo por crédito
según la especialidad.
• Matriculado de 09 a 11 créditos: el costo de las
pensiones serán el 50% del monto total de un semestre
regular según la especialidad.
• Matriculado de 12 a 22 créditos el costo de las
pensiones serán completas.
Para dicho efecto, el Departamento de Cobranzas tendrá que
obtener la información correspondiente por parte de las
escuelas; quienes expedirán las respectivas fichas de
matriculas a los alumnos.
• Fraccionamiento de Deudas
a) El alumno deberá cancelar el derecho de solicitud.
b) Según la deuda que presenta el alumno amortizará entre
el 30% y 50% del total de la deuda. Y el saldo se le
fraccionara en un número determinado de cuotas (entre 2
y 6) según acuerdo, para ser canceladas al vencimiento
de sus pensiones del semestre en curso.
c) El alumno no podrá ejecutar su matrícula correspondiente
en caso presente deuda pendiente de pago, salvo realice
el financiamiento en el Departamento de Cobranzas.

• Pago de Pensiones (Ciclo Completo)

a) Para este trámite solo están sujetos los alumnos que no
presenten ningún tipo de descuento en sus pensiones.
b) Procede el descuento del 10% cuando cancelan sus
cuatro pensiones juntas, pero antes de la fecha de
vencimiento de la 1° cuota o hasta el mismo día.
• Prorrogas
a) En este tramite se evalúa la deuda del alumno y de
acuerdo al estado de cuenta del semestre actual se emite
la prorroga.
b) Son emitidas después del vencimiento de cada pensión,
según cronograma de pagos, el trámite es personal;
evaluando la situación económica del usuario, pueden ser
desde 1 día hasta 15 días como máximo.
• Tramite de Carné Universitario

a) Es el único documento de identificación del alumno para
realizar cualquier trámite dentro de las jurisdicciones de la
Universidad, incluido para el control de pagos.
b) Deberá realizar el pago correspondiente según la tasa
vigente en cualquiera de las Unidades Recaudadoras o
mediante el Servicio Telemático de Recaudación.
c) Deberá presentar su comprobante de pago en la Unidad
de Carnés Universitarios para su trámite respectivo.
• Tramite de Carné de Biblioteca

a) Es el único documento de identificación que le permite al
alumno hacer uso del material bibliográfico de la
Universidad en las diferentes bibliotecas de la
Universidad.
b) Deberá realizar el pago correspondiente según la tasa
vigente en cualquiera de las Unidades Recaudadoras o
mediante el Servicio Telemático de Recaudación.
c) Deberá presentar su comprobante de pago en la oficina
administrativa de la Biblioteca, mas una fotografía tamaño
carné para su trámite respectivo.

• Tramite de Condonación de Deuda

a) Deberá realizar el pago por derecho de solicitud.
b) Deberá iniciar su tramite presentado la solicitud a en su
respectiva Escuela.
c) Dirección de Escuela deberá emitir una Resolución
Directoral, haciendo de conocimiento a Cobranza para su
respectivo ingreso al sistema.
d) El alumno culminará su trámite con la cancelación del
importe por derecho de condonación de deuda según la
tasa vigente.
• Tramite de Recategorización
a) La Oficina de Bienestar Universitario enviará al
Departamento de Cobranzas la programación de las
fechas para recepción de pagos por concepto de
recategorizaciónes.
b) Deberá cancelar el costo por derecho de solicitud de
trámite de recategorización.
c) Deberá cancelar el importe por derecho de Constancia de
no Adeudo y presentarla al Departamento de Cobranzas
para emitir la Constancia de No Adeudo.
d) Todos los documentos solicitados son adjuntados y
presentados a la oficina de Bienestar Universitario para su
evaluación y aprobación por Consejo Universitario.
e) Consejo Universitario emite una Resolución Directoral de
aprobación que es enviada al Departamento de
Cobranzas quien se encargará de ingresar las categorías
de los alumnos al sistema.
• Traslado de Especialidad (Escuela) y Sede

a) Se solicitará a Dirección de Escuela, el retiro de sus
expedientes; a la vez ésta deberá requerir a cobranzas
mediante un documento (Constancia de no Adeudo) el
estado de cuenta de cada alumno.
b) En el caso que Dirección de Escuela, apruebe o
desapruebe el traslado, deberá informar al Departamento
de Cobranzas, mediante una Resolución Directoral.

c) Si el alumno se traslada de una especialidad o sedes a

otra, a partir del II ciclo, deberá realizar el pago
correspondiente según tasa activa, si fuere alumno del I
ciclo no concluido, solo presenta una solicitud.
d) Luego puede proceder con la cancelación de la matrícula.
• Ingresos por Convalidación

a) El alumno deberá cancelar el derecho de ingreso con su
solicitud de trámite por convalidación.
b) Las Direcciones de Escuela deberán informar la relación
de alumnos que ingresan por esta modalidad al
Departamento de Cobranzas, en un plazo máximo de 30
días hábiles; especificando el total de créditos
convalidados.
c) El alumno deberá cancelar el importe por el total de
créditos convalidados, según la tasa vigente.
• Reservas de Matricula
a) La reserva será realizada dentro de los 30 días hábiles de
culminada y antes de vencimiento de la primera cuota.
b) El alumno deberá cancelar la tasa por derecho de de
solicitud de trámite, la misma que deberá presentar a la
Dirección de Escuela respectiva.
c) La Escuela, deberá evaluar y emitir la Resolución
Directoral de Reserva y hacer de conocimiento al
Departamento de Cobranzas para su ingreso respectivo.
d) Expedida la Resolución, el alumno terminará el
procedimiento con la cancelación de la tasa vigente por
derecho de Reserva de Matricula.
e) La reserva tendrá como máximo 01 ciclo académico para
que el alumno realice su incorporación; en el caso que el
alumno no desee incorporarse; deberá realizar
nuevamente el trámite, hasta antes de la culminación del
semestre. De lo contrario procederá a realizar la
condonación de deuda.

• Reserva de Vacante
a) Pueden realizar este trámite los alumnos que habiendo
ingresado a la Universidad y no desean iniciar su ciclo
académico en el Semestre de ingreso.
b) El tiempo máximo para realizar este proceso es de 30
días, concluida la matrícula regular.
c) Deberá realizar el pago por derecho de solicitud de tramite
de reserva de matricula.
d) El alumno tiene un plazo de 02 ciclo académicos para
realizar la incorporación, caso contrario, antes de la
culminación de la fecha deberá realizar nuevamente el
trámite.
e) En caso que el estudiante pase la fecha límite de reserva
de vacante, éste deberá cancelar nuevamente su
ingreso, teniendo en cuenta que tendrá el mismo código
de matricula.
• Anulación de Matriculas
a) Para realizar el trámite el alumno no tiene que registrar
matricula en la escuela.
b) Deberá cancelar el derecho de solicitud, luego presentarla
en la escuela respectiva; la escuela emitirá una resolución
donde especifica la anulación de la matricula y es remitida
al Departamento de Cobranzas para ser ingresada al
sistema (se detalla el tipo de tramite y número de
resolución).
• Cambio de Modalidad de Estudio (Presencial o S.U.A)

a) Para realizar el tramite el alumno deberá ser alumno
activo (registrar matricula u otro pago).
b) El alumno, deberá cancelar por derecho de solicitud y
presentarla a la escuela respectiva.
c) La escuela emite una resolución donde especifica el
cambio de modalidad, puede ser del S.U.A al
Presencial o viceversa.

d) La resolución es enviada al Departamento de Cobranzas

para realizar el ingreso al sistema (Detalle de trámite,
fecha y número de resolución).
• Reincorporación de Estudios
a) Todo alumno que deja de estudiar más de tres años y
desea reincorporarse, tiene que efectuar el pago de
solicitud y derecho de reincorporación.
b) La solicitud es presentada a la escuela, donde se emite
una Resolución aceptando su reincorporación y es
enviada al Departamento de Cobranzas para ser
ingresada al sistema
• Derechos para tramite del Grado de Bachiller

a) Los alumnos que se encuentran aptos para realizar el
tramite, son aquellos que han culminado sus X o XII ciclos
académicos de pendiendo de los planes curriculares que
tienen las escuelas y no tiene deuda pendiente.
b) Deberán efectuar el pago de los siguientes requisitos:
Solicitud
Inicio de tramite
Constancia de no adeudo
Tramite de grado de bachiller
Certificado de estudios x ciclo
Solicitud de tramite de certificados
Constancia de no adeudo de biblioteca
Solicitud (const. de no adeudo de biblioteca)
Fotografías
c) Realizados los pagos, son presentados a sus escuelas
para iniciar el trámite.
d) Las escuelas remiten los expedientes al Departamento de
Cobranzas para expedir la constancia de no adeudo, una
vez expedida la constancia el expediente se devuelve a la
escuela.

• Derechos del Tramite de Titulo

a) Los alumnos que se encuentran aptos para realizar el
Tramite de Titulo Profesional, aquellos que han obtenido
el Grado de Bachiller.
b) Deberán efectuar el pago de los siguientes requisitos:
Solicitud
Inicio de tramite
Constancia de no adeudo
Tramite de Titulo
Solicitud de tramite de certificados
Constancia de no adeudo de biblioteca
Solicitud (const. de no adeudo de biblioteca)
Fotografías
c) Realizados los pagos, son presentados a sus escuelas
para iniciar el trámite correspondiente.
d) Las Escuelas remiten los expedientes al Departamento de
Cobranzas para expedir la constancia de no adeudo, una
vez expedida la constancia el expediente se devuelve a la
escuela.
• Canjes de Depósitos
a) Los alumnos de los diferentes Centros Académicos
realizan el pago de sus matriculas, pensiones, solicitudes,
Constancias de Estudios y demás tasas en las entidades
bancarias
b) Después presentan el voucher de deposito original y una
fotostática en su Centro Académico, para ser remitidos a
la Sede Principal (Chimbote)
c) Los voucher son canjeados por sus respectivas boletas de
venta, que son remitidas a las sedes que corresponden.
• Pagos por el Sistema de Recaudación Telemática Teletransfer

a) Este sistema de pago se realiza en el Banco de Crédito.
b) Es solo para pagos de matriculas, pensiones y algunas
tasas (Apertura de file, carné universitario, carné de
biblioteca, segunda matricula y matricula por tercera, etc.).

c) Los alumnos se tienen que apersonar al Banco de Crédito

con su respectivo código de matricula e indicar al cajero el
pago a realizar, recibirá un voucher de deposito donde
figura el nombre del alumno y pago realizado.
d) Todos los días el banco emite un archivo de los pagos
realizados en su entidad al Departamento de Cobranzas y
viceversa.
• Tramite por Devoluciones o Transferencias de Pago

a) Procede cuando no se ha llevado a cabo el concepto
cancelado.
b) Se cancelará primero la solicitud de trámite y adjuntar a la
misma originales de boletas de pago (escuela y alumno e
ingresada en al Departamento de Cobranzas, la misma
que dará la certificación si procede dicha transferencia o
devolución).
c) El trámite tendrá como máximo 20 días, para que el
alumno puede recoger su transferencia o devolución.
d) En caso que el servicio educativo no se llegó a aperturar,
las devoluciones serán integras.
Por otro lado, el pago errado al momento de ser
boleteado, la transferencia será de manera integra a
pensiones y/o otros conceptos.
1.3.2. Analista de Ingresos
El analista de ingresos, depende Jerárquicamente de la jefatura de

cobranzas, no ejerce autoridad sobre ningún personal y entre sus función
esta la de coordinar con los responsables de los Departamentos de
Economía, Cobranzas, Contabilidad y las Unidades de Recaudación sobre
los ingresos de la Universidad.
1.3.2.1. Funciones
• Coordinar, realizar y revisar la liquidación de los ingresos (Efectivo y

canje con voucher de depósito) de las unidades recaudadoras.
• Coordinar y realizar los depósitos de ingreso en efectivo en las
cuentas corrientes de la Universidad en los diferentes turnos.

• Coordinar y verificar los ingresos (ventas, pagos, canje de voucher)

depósitos realizados en las cuentas corrientes tanto en la sede
principal como de las SEDES.
• Coordinar con el Departamento de Cobranzas sobre las prorrogas,
compromisos de pagos y procedimientos de las deudas de los
alumnos.
• Controlar e ingresar las recategorizaciones en el sistema de acuerdo
a las Resoluciones Rectorales.
• Controlar, registrar e informar sobre las morosidades de pago.
• Coordinar y supervisar las actividades realizadas por las unidades
recaudadoras.
• Emitir constancia de no adeudo de acuerdo al visto bueno del
Departamento de Cobranzas.
• Otros que le sea asignado por la Jefatura de Cobranzas.
1.3.2.2. Gestión y procedimientos

• Es de responsabilidad del Analista de ingresos, realizar el depósito
del efectivo recaudado durante el día en la sede central para ello
solicita la documentación referente a liquidaciones y comprobantes
de pago a la Unidad de Caja.
• De las liquidaciones
a) Las unidades de recaudación deberá remitir la documentación de
ingresos considerando lo siguiente:
Los reportes de liquidación se presentan por turnos.
Los reportes de liquidación se presentan separado por

modalidades; es decir los ingresos de la modalidad
presencial separado de los ingresos del S.U.A1 y
separado de los ingresos por modalidad Post-Grado.
Se debe adjuntar los voucher de los depósitos

efectuados por concepto de las ventas en efectivo.
b) A excepción de la sede central, las unidades de recaudación
deberán enviar el archivo de texto plano conteniendo las ventas
del día, mediante la página web de envió de archivos para la
contrastación y revisión de las ventas.
1
S.U.A : Es un sistema de estudios universitarios que utiliza la modalidad a Distancia.

c) Se revisará las liquidaciones diarias de cada Unidad de

Recaudación por separado para identificar cualquier anomalía en
los ingresos y los comprobantes de pagos.
d) Luego de realizada la verificación de las liquidaciones, la
documentación (reportes de liquidaciones, comprobantes de
pagos, voucher de depósitos, etc.) son remitidos a la Unidad de
Archivos para su respectivo archivo.
• Apoya en algunos procedimientos realizados por la Jefatura de
Cobranzas.
1.3.3. Unidades recaudadoras (Cajas)
1.3.3.1. Funciones
• Ejecutar y coordinar las cobranzas de las tasas administrativas y
académicas (Matriculas, Pensiones, grados, títulos, maestrías, SUA,
etc.) con el Departamento de Cobranzas y con las diferentes
escuelas de la universidad.
• Realizar las transferencias de pagos con el visto bueno del
• Realizar el descargo de depósitos efectuados mediante el servicio de
recaudación telemática Teletransfer (pagos efectuados en el banco)
de los diferentes centros académicos.
• Ejecutar y remitir los reportes de los alumnos matriculados a las
diferentes escuelas
• Otras que sean asignados por la Jefatura de Cobranzas.

Capitulo II
PLAN DE INVESTIGACION
2.1. Planteamiento del problema
La Universidad Los Angeles de Chimbote, actualmente cuenta con siete

unidades de recaudación en el interior del país (Trujillo, Huaraz, Piura,
Sullana, Talara, Casma y Huarmey) y tres unidades de recaudación en la
sede Central; uno en local Admisión y dos en local Rectorado.
Cada una de ellas realiza sus actividades apoyados de un sistema

transaccional (Módulo de Cobranzas), éste funciona de manera independiente
y con su propia base de datos; este programa genera un archivo de texto
plano el cual contiene el detalle de las ventas del día, este archivo es enviado
todos los días a la sede central al termino de cada jornada mediante la página
web de envió de archivos alojada en el servidor web de la institución.
Mediante este esquema de funcionamiento se logró identificar lo

siguiente:
Los usuarios (cajeras) no envían los archivos conteniendo las

ventas diariamente debido a olvidos u otros motivos. Ocasionando
reprogramaciones en las actividades del analista de ingresos y
además en el área de Tesorería; estas actividades retrasadas son
efectuadas en horarios fuera del horario normal de labores (horas
extras) originando sobre costos en salarios.
Para la actualización de versión del módulo de cobranzas, es
necesario que la unidad recaudadora envié la base de datos para
realizar la comparación de estructuras e identificar las
modificaciones o alteraciones en la estructura de la base de datos.
Originando costos por concepto de envió mediante encomiendas del
CD de la copia de la base de datos hacia la sede central. Se pudo
determinar que el tiempo que toma realizar esta actualización es
hasta en 5 días.
Cada unidad recaudadora realiza copias backup de la base de
datos en un CD una sola vez diariamente al terminar cada jornada.
Se determino que este proceso es realizado por las propias cajeras;
sin embargo ellas no tienen conocimientos suficientes para realizar
este proceso; no identifican si se ha tenido éxito en la copia backup.
Además de esto; obviamente se emplean suministros como CD y
otros dispositivos originando costos a la institución.

Al tener base de datos descentralizadas (en las filiales), estas están

expuestas a manipulaciones y/o intromisiones por los mismos
usuarios o por terceros.
Ocasionalmente, ocurren inconsistencias en la base de datos
provocados por problemas de hardware o sistema operativo. Para
resolver estos inconvenientes es necesario la ayuda de personal
experimentado en la filial que muchas veces no se dispone en el
momento requerido. Muchas veces es necesario la visita de
personal desde la sede central el cual origina costos en viáticos.
El problema principal radica en la falta de centralización de la

información referente a los ingresos de la institución.
Por ello, en el presente proyecto se plantea realizar un Sistema de

Información de Cobranzas basado en Tecnología Web con el objetivo de dar
solución a los problemas descritos anteriormente.
Esta tecnología permitirá tener centralizada la información y mejorar el

control y seguimiento de las unidades recaudadoras; facilitar la disponibilidad
de la información, entre otras funcionalidades será posible realizar consultas
en línea como estados de cuenta, reportes estadísticos, cronogramas de
pagos, planes de costos, constancias emitidas, liquidaciones de caja, entre
otra información relacionada con los ingresos de la institución.
2.2. Enunciado del problema
Realizado el análisis de la situación problemática, consideramos lo

siguiente:
¿Cómo mejorar la gestión administrativa en el Departamento de

Cobranzas de la Universidad Los Angeles de Chimbote?
2.3. Hipótesis
El Sistema de Información de Cobranzas Web, permitirá mejorar la

gestión administrativa en el Departamento de Cobranzas de la Universidad
Los Angeles de Chimbote.

2.4. Objetivos del proyecto
2.4.1. Objetivo general
Incrementar la eficiencia en la gestión administrativa del

Departamento de Cobranzas de la Universidad Los Angeles de
Chimbote mediante el Sistema de Información de Cobranzas Web.
2.4.2. Objetivos específicos
El sistema de información, permitirá cumplir con los siguientes

objetivos:
• Centralizar la información de los ingresos de las unidades

recaudadoras de la institución en la sede principal.
• Mejorar la planificación y ejecución de los procesos de control
para la reducción en los índices de morosidad.
• Mejorar el servicio de consultas en línea sobre estados de
cuentas, fechas de vencimientos, plan de costos y otra
información relevante para los alumnos.
• Mejorar los procesos de seguimiento y control de los ingresos
en las unidades recaudadoras de la institución.
• Apoyar los procesos de auto evaluación institucional a través de
la generación de reportes estadísticos.
• Facilitar el desempeño de otras soluciones gerenciales y
estratégicas de la institución.

Centralizar la información Mejorar la planificación Mejorar el servicio de

de los ingresos de las y ejecución de los consultas en línea sobre
filiales de la institución en procesos de control estados de cuentas,
la sede principal. para la reducción en los fechas de vencimientos,
índices de morosidad. plan de costos y otra
información relevante para
los alumnos.
Incrementar la eficiencia en la gestión administrativa

del Departamento de Cobranzas de la
Universidad Los Ángeles de Chimbote mediante la
implementación de un Sistema de Información
basado en tecnología Web.
Mejorar los procesos de Apoyar los procesos Facilitar el desempeño

seguimiento y control de de auto evaluación de otras soluciones
los ingresos en las institucional a través gerenciales y
unidades recaudadoras de de la generación de estratégicas de la
reportes estadísticos.
la institución. institución.
Gráfico Nº 2: Objetivos del proyecto

2.5. Justificación
2.5.1. Justificación económica
El Sistema de Información de Cobranzas Web permitirá reducir

considerablemente los costos para la ejecución de las actividades del
Departamento de Cobranzas y las unidades recaudadoras.
• Disminuirá sustancialmente los sobre costos generados por las

remuneraciones por horas extras debido a la reducción
considerable de sobre tiempo empleado para realizar el control,
revisión y análisis de las ventas.
• Se reducirán los gastos en insumos y materiales necesarios
para los procesos de backup y generación de informes para
revisión y control enviada por las unidades recaudadoras.

• Se eliminarán los costos originados por el mantenimiento y

corrección in situ de la base de datos en cada filial debido a que
se centralizará la base de datos en la sede central.
• El uso de herramientas de software libre permitirá reducir
significativamente los costos de inversión en licencias.
2.5.2. Justificación tecnológica
La Universidad Los Angeles de Chimbote logrará un gran

avance tecnológico con la implementación del proyecto; permitirá
integrar la información de manera centralizada usando la
infraestructura instalada actualmente.
2.5.3. Justificación social
La implementación del proyecto permitirá mejorar el servicio de

atención a los alumnos y en consecuencia la imagen institucional.
2.6. Costo del proyecto
Para realizar la estimación del proyecto emplearemos el modelo

COCOMO2 por ser el más adecuado para desarrollo de proyectos de sistemas
de información.
En el procedimiento para realizar el análisis de la estimación se realizan

los siguientes cálculos:
Definir el flujo de datos

Calculo de instrucciones fuentes (KLCD)
Calcular las miles de Instrucciones fuentes (MF)
Calcular el esfuerzo (ESF)
Calcular el tiempo de desarrollo (TDES)
Calcular el número de trabajadores (NT)
Calcular la productividad (P)
Calcular el costo total de proyecto (CT)
Beneficios tangibles
Beneficios intangibles
Resultado del estudio
2
Vea Glosario, Página 169

Gráfico Nº 3: Flujo de Datos



F= LDC x E/S
F= 420 x 14 =5880 Instrucciones fuente
Donde:
E/S =Flujo de entrada y salida
LDC = (líneas de código promedio de la programación)
420 = Vea Anexos, página 172

MF = F/1000
MF = 5880/1000
MF = 5.88
Calcular el esfuerzo (ESF)

1.12
ESF = 3.0 *(5.88)
ESF = 21.81 Nominal
ESF real = 21.81 * FC
ESF real = 21.81 * 0.52
ESF real = 11.34 hombres mes
Donde:
1.12 = (Vea Anexos, Tabla Nº 62)
FC = Factor de Complejidad
0.52 = (Vea Anexos, pág. 173)
Calcular el tiempo de desarrollo (TDES)

0.35
TDES = 2.5 (ESF)
0.35
TDES = 2.5 (11.34)
TDES = 5.85 meses = (6 meses)
Donde:
Calcular el número de trabajadores (NT)

NT = ESF / TDES
NT =11.34 / 6
NT = 1.89 = (2 hombres)

Calcular la productividad (P)

P = F / ESF
P = 5880 / 11.34
P = 518.52
Costo Total de Proyecto.

CTP = CD + CI
Calculando costo directo (CD)
CD = CFT + CMT + CMAT
- Costo Fuerza Trabajo (CFT)
CFT = SP x ESF Real
CFT= 1000 * 11.34 = S/. 11,340.00
Donde:
SP = Salario Promedio
- Costo Medios Técnicos (CMT)
CMT = HTM * CPH
CMT = 240 horas/mensual *
4.16 Costo Promedio horas
CMT = S/. 998.40
- Costo de materiales (CMAT)
CMAT = CMT x K (K= 1% a 3%)
CMAT = 998.40 * 0.02
CMAT = S/. 19.97
CD = CFT + CMT + CMAT
CD = 11,340.00 + 998.40 + 19.97
CD = S/. 12,358.37
Calculando costo indirecto (CI)
CI = CD x K (K = 5%)
CI = S/. 12,358.37 * 0.05
CI = S/. 617.92
Costo Total del Proyecto
CTP = CD + CI
CTP = 12,358.37 + 617.92
CTP = S/. 12,976.29

2.7. Beneficios del proyecto
Beneficios tangibles
• Disminución en los tiempos de espera en la atención al alumno.

• Reducción sustancial en el número de horas extras en el
Departamento de Cobranzas y otras áreas afectadas indirectamente.
• Disminución en costos producidos por envío de documentación de
liquidaciones mediante encomiendas.
• Disminución en costos por uso de suministros en realización de
copias backup de base de datos.
• Cero costos en licenciamiento de software.
Beneficios intangibles
• Mejora en la atención al alumno.

• Disponibilidad de información en el tiempo requerido.
• Estandarización de los proceso de cobranzas.
• Apoyar en la toma de decisiones a la jefatura del departamento de
Cobranzas.
• Apoya al incremento de la imagen de la institución.
Resultados del estudio
Tanto los beneficios tangibles e intangibles, demuestran que la

implementación de este proyecto es necesario, por tener un impacto
social y económico, para la mejora de la gestión en el Departamento de
Cobranzas y dependencias afectadas.
2.8. Recursos del proyecto
En esta parte se hace una estimación de la distribución del costo del

proyecto para el Sistema de Información de Cobranzas Web.
2.8.1. Recursos humanos
Personal Cantidad Sueldo Costo Total

Mensual
Autores 2 800.00 1,600.00 9,600.00
Asesor 1 0.00 0.00 0.00
TOTAL S/. 9,600.00
Tabla Nº 1: Recursos humanos


2.8.2. Recursos de software
Descripción Cantidad Costo (S/.)

Sistema Operativo Fedora 1 0
7.0
Gestor de Base de Datos 1 0
MySQL 5.0
Herramienta de Desarrollo 1 0
Web Quanta Plus
Servidor Web Apache 2 1 0
Herramienta de modelado 1 0
StarUML 5.0
Lenguaje de Programación 1 0
PHP
Herramienta de Oficina 1 0
OpenOffice 2.2
Total S/. 0.00
Tabla Nº 2: Recursos de software

2.8.3. Recursos de hardware
Descripción Cantidad Costo (S/.)
Equipamiento y materiales duraderos
Computadora y 2 2,500.00
accesorios
Impresora 1 226.00
Mobiliario 1 350.00
Total S/. 3,076.00
Tabla Nº 3: Recursos de hardware


2.8.4. Recursos de materiales
Detalle Cantidad Costo (S/.)

Materiales de Escritorio
Papel A4 de 80 gramos 1,000 30,00
Bolígrafos 10 15,00
Materiales de Impresión
Tinta de Impresora 1 50,00
CD-RW 1 20,00
Total S/. 115.00
Tabla Nº 4: Recursos de materiales

El siguiente cuadro muestra el resumen de la distribución de los recursos

empleados para en el Sistema de Información de Cobranzas Web.
Recurso Total
Recursos humanos 9,600.00
Recurso de software 0.00
Recurso de hardware 3,076.00
Recursos materiales 115.00
Total S/. 12,791.00
Tabla Nº 5: Distribución de recursos


2.9. Marco teórico
2.9.1. Gestión
Proceso que desarrolla actividades productivas con el fin de

generar rendimientos de los factores que en él intervienen. Diligencia
que conduce al logro de un negocio o satisfacción de un deseo.
[URL01]
2.9.2. Gestión de cobranzas
Proceso que sirve para canalizar el servicio de cobranzas a

todos los alumnos de esta casa de estudios, así como asegurar la
coordinación y cooperación de caja en todas la sedes a nivel nacional.
[URL02]
2.9.3. Sistema de información
Se define como un conjunto de procedimientos

interrelacionados que forman un todo, es decir, obtiene, procesa,
almacena y distribuye información (datos manipulados) para apoyar la
toma de decisiones y el control en una organización. Igualmente apoya
la coordinación, análisis de problemas, visualización de aspectos
complejos, entre otros aspectos.
Componentes de un sistema de información:
• Herramientas tecnológicas (hardware, software).

• El equipo computacional: el hardware necesario para que el
sistema de información pueda operar.
• El recurso humano que interactúa con el Sistema de
Información, el cual está formado por las personas que utilizan
el sistema, también conocidos como usuarios.
• Un sistema de información realiza cuatro actividades básicas:
entrada, almacenamiento, procesamiento y salida de
información.
• Los Sistemas de Información que logran la automatización de
procesos operativos dentro de una organización, son llamados
frecuentemente Sistemas Transaccionales, ya que su función
primordial consiste en procesar transacciones tales como
pagos, cobros, pólizas, entradas, salidas, etc. Por otra parte,

los sistemas de Información que apoyan el proceso de toma de

decisiones son los sistemas de Soporte a la Toma de
Decisiones, sistemas para la Toma de Decisión de Grupo,
sistemas Expertos de Soporte a la Toma de Decisiones y
Sistemas de Información para Ejecutivos. El tercer tipo de
sistema, de acuerdo con el uso u objetivos que cumple, es el
de los sistemas Estratégicos, los cuales se desarrollan en las
organizaciones con el fin de lograr ventajas competitivas, a
través del uso de la tecnología de información. [URL03]
Actividades Básicas de un Sistema de Información:
• Entrada de Información: Es el proceso mediante el cual el

Sistema de Información toma los datos que requiere para
procesar la información. Las entradas pueden ser manuales o
automáticas. Las manuales son aquellas que se proporcionan
en forma directa por el usuario, mientras que las automáticas
son datos o información que provienen o son tomados de otros
sistemas o módulos. Esto último se denomina interfases
automáticas.
Las unidades típicas de entrada de datos a las computadoras

son las terminales, las cintas magnéticas, las unidades de
diskette, los códigos de barras, los escáner, la voz, los
monitores sensibles al tacto, el teclado y el mouse, entre otras.
• Almacenamiento de información: El almacenamiento es una de
las actividades o capacidades más importantes que tiene una
computadora, ya que a través de esta propiedad el sistema
puede recordar la información guardada en la sección o
proceso anterior. Esta información suele ser almacenada en
estructuras de información denominadas archivos. La unidad
típica de almacenamiento son los discos magnéticos o discos
duros, los discos flexibles o diskettes y los discos compactos
(CD-ROM).
• Procesamiento de Información: Es la capacidad del Sistema de
Información para efectuar cálculos de acuerdo con una
secuencia de operaciones preestablecida. Estos cálculos
pueden efectuarse con datos introducidos recientemente en el

sistema o bien con datos que están almacenados. Esta

característica de los sistemas permite la transformación de
datos fuente en información que puede ser utilizada para la
toma de decisiones, lo que hace posible, entre otras cosas, que
un tomador de decisiones genere una proyección financiera a
partir de los datos que contiene un estado de resultados o un
balance general de un año base.
• Salida de Información: La salida es la capacidad de un sistema
de información para sacar la información procesada o bien
datos de entrada al exterior. Las unidades típicas de salida son
las impresoras, terminales, diskettes, cintas magnéticas, la voz,
los graficadores y los plotters, entre otros. Es importante aclarar
que la salida de un Sistema de Información puede constituir la
entrada a otro Sistema de Información o módulo. En este caso,
también existe una interfase automática de salida. Por ejemplo,
el Sistema de Control de Clientes tiene una interfase
automática de salida con el Sistema de Contabilidad, ya que
genera las pólizas contables de los movimientos procesales de
los clientes.
2.9.4. Sistema cliente - servidor
Esta arquitectura consiste básicamente en que un programa el

cliente informático realiza peticiones a otro programa, el servidor, que
les da respuesta.
Aunque esta idea se puede aplicar a programas que se

ejecutan sobre una sola computadora es más ventajosa en un sistema
operativo multiusuario distribuido a través de una red de
computadoras.
En esta arquitectura la capacidad de proceso está repartida

entre los clientes y los servidores, aunque son más importantes las
ventajas de tipo organizativo debidas a la centralización de la gestión
de la información y la separación de responsabilidades, lo que facilita y
clarifica el diseño del sistema.

La separación entre cliente y servidor es una separación de tipo

lógico, donde el servidor no se ejecuta necesariamente sobre una sola
máquina ni es necesariamente un sólo programa.
Una disposición muy común son los sistemas multicapa en los

que el servidor se descompone en diferentes programas que pueden
ser ejecutados por diferentes computadoras aumentando así el grado
de distribución del sistema.
La arquitectura cliente-servidor sustituye a la arquitectura

monolítica en la que no hay distribución, tanto a nivel físico como a
nivel lógico.
2.9.4.1. Ventajas
Centralización del control: los accesos, recursos y la

integridad de los datos son controlados por el servidor
de forma que un programa cliente defectuoso o no
autorizado no pueda dañar el sistema.
Escalabilidad: se puede aumentar la capacidad de
clientes y servidores por separado.
El servidor de cliente es la arquitectura de red que

separa al cliente (a menudo un uso que utiliza un interfaz
utilizador gráfico) de un servidor. Cada caso del software del
cliente puede enviar peticiones a un servidor. Los tipos
específicos de servidores incluyen los servidores web, los
servidores del uso, los servidores de archivo, los servidores
terminales, y los servidores del correo. Mientras que sus
propósitos varían algo, la arquitectura básica sigue siendo igual.
[URL13]
2.9.5. Internet
Internet es un método de interconexión descentralizada de

redes de computadoras implementado en un conjunto de protocolos
denominado TCP/IP y garantiza que redes físicas heterogéneas
funcionen como una red lógica única, de alcance mundial. Sus
orígenes se remontan a 1969, cuando se estableció la primera
conexión de computadoras, conocida como ARPANET, entre tres
universidades en California y una en Utah.

Al contrario de lo que se piensa comúnmente, Internet no es

sinónimo de World Wide Web (WWW, o "la Web"). Ésta es parte de
Internet, siendo uno de los muchos servicios ofertados en la red
Internet. La web es un sistema de información mucho más reciente,
desarrollado inicialmente por Tim Berners Lee en 1989. El WWW
utiliza Internet como medio de transmisión.
Algunos de los servicios disponibles en Internet, aparte de la

web, son el acceso remoto a otras máquinas (SSH y telnet), la
transferencia de archivos (FTP), el correo electrónico (SMTP y POP),
los boletines electrónicos (news o grupos de noticias), las
conversaciones en línea (IRC y chats), la mensajería instantánea y la
transmisión de archivos (P2P, P2M, Descarga Directa). [URL14]
2.9.6. Wide World Web
World Wide Web (o la "Web") es un sistema de documentos de

hipertexto enlazados y accesibles a través de Internet. Con un
navegador web, un usuario visualiza sitios web, forjados de páginas
web que pueden contener texto, imágenes u otros contenidos
multimedia, y navega a través de ellas usando hiperenlaces.
La web fue creada alrededor de 1990 por el inglés Tim Berners-

Lee y el belga Robert Cailliau mientras trabajaban en el CERN en
Ginebra, Suiza. Desde entonces, Berners-Lee ha jugado un papel
activo guiando el desarrollo de estándares web (como los lenguajes de
marcado con los que se crean las páginas web), y en los últimos años
ha abogado por su visión de una web semántica. [URL06]
2.9.6.1. Funcionamiento de la web
La visualización de una página web, u otro recurso, de la

World Wide Web comienza normalmente tecleando la URL de la
página en el navegador web, o siguiendo un enlace de hipertexto a
esa página o recurso. El primer paso, entre bastidores, consiste en
traducir la parte del nombre del servidor de la URL en una dirección
IP usando la base de datos distribuida de Internet conocida como
DNS. Entonces el navegador establece una conexión TCP con el
servidor en esa dirección IP.

El siguiente paso es enviar una petición HTTP al servidor

web solicitando el recurso. En el caso de una página web típica,
primero se solicita el texto HTML y luego es analizado por el
navegador, el cual, después, hace peticiones adicionales para los
gráficos y otros ficheros que formen parte de la página, en una
rápida sucesión. Cuando se examinan las estadísticas de
popularidad de un sitio web, las peticiones adicionales para estos
ficheros proporcionan un aumento de las diferencias entre las
simples 'páginas vistas' y un número asociado de 'peticiones' de
servidor.
Entonces el navegador web renderiza la página tal y como

se describe en el código HTML, el CSS y otros ficheros recibidos,
incorporando las imágenes y otros recursos si es necesario. Esto
produce la página que ve el usuario en su pantalla.
La mayoría de las páginas web contienen hiperenlaces

a otras páginas relacionadas y tal vez descargas, documentos
fuente, definiciones y otros recursos web.
Esta colección de recursos útiles y relacionados,

interconectados a través de enlaces de hipertexto, es lo que ha
sido denominado como 'red' (web, en inglés) de información.
Teniéndola disponible en Internet, se creó lo que Tim Berners-Lee
llamó primero WorldWideWeb (indicar que el uso del nombre
CamelCase, fue posteriormente desechado) en 1990. [URL07]
Gráfico Nº 4: Funcionamiento general de la web


2.9.7. Navegador de Internet
Un navegador web o explorador web (del inglés, navigator o

browser) es una aplicación software que permite al usuario recuperar y
visualizar documentos de hipertexto, comúnmente descritos en HTML,
desde servidores web de todo el mundo a través de Internet. Esta red
de documentos es denominada World Wide Web (WWW). Cualquier
navegador actual permite mostrar o ejecutar gráficos, secuencias de
vídeo, sonido, animaciones y programas diversos además del texto y
los hipervínculos o enlaces.
La funcionalidad básica de un navegador web es permitir la

visualización de documentos de texto, posiblemente con recursos
multimedia incrustados. Los documentos pueden estar ubicados en la
computadora en donde está el usuario, pero también pueden estar en
cualquier otro dispositivo que este conectado a la computadora del
usuario o a través de Internet, y que tenga los recursos necesarios
para la transmisión de los documentos (un software servidor web).
Tales documentos, comúnmente denominados páginas web, poseen
hipervínculos que enlazan una porción de texto o una imagen a otro
documento, normalmente relacionado con el texto o la imagen.
El seguimiento de enlaces de una página a otra, ubicada en

cualquier computadora conectada a la Internet, se llama navegación;
que es de donde se origina el nombre de navegador. Por otro lado,
hojeador es una traducción literal del original en inglés, browser,
aunque su uso es minoritario. [URL15]
2.9.8. Servidor Web
Un servidor web es un programa que implementa el protocolo

HTTP (hypertext transfer protocol). Este protocolo está diseñado para
transferir lo que llamamos hipertextos, páginas web o páginas HTML
(hypertext markup language): textos complejos con enlaces, figuras,
formularios, botones y objetos incrustados como animaciones o
reproductores de música.

Gráfico Nº 5: Funcionamiento básico de servidor web

Fuente: Google Images
Sin embargo, el hecho de que HTTP y HTML estén

íntimamente ligados no debe dar lugar a confundir ambos términos.
HTML es un lenguaje de programación y un formato de archivo y
HTTP es un protocolo.
Cabe destacar el hecho de que la palabra servidor identifica

tanto al programa como a la máquina en la que dicho programa se
ejecuta. Existe, por tanto, cierta ambigüedad en el término, aunque no
será difícil diferenciar a cuál de los dos nos referimos en cada caso.
Un servidor web se encarga de mantenerse a la espera de

peticiones HTTP llevada a cabo por un cliente HTTP que solemos
conocer como navegador. El navegador realiza una petición al servidor
y éste le responde con el contenido que el cliente solicita. A modo de
ejemplo, al teclear www.wikipedia.org en nuestro navegador, éste
realiza una petición HTTP al servidor de dicha dirección. El servidor
responde al cliente enviando el código HTML de la página; el cliente,
una vez recibido el código, lo interpreta y lo muestra en pantalla. Como
vemos con este ejemplo, el cliente es el encargado de interpretar el
código HTML, es decir, de mostrar las fuentes, los colores y la
disposición de los textos y objetos de la página; el servidor tan sólo se
limita a transferir el código de la página sin llevar a cabo ninguna
interpretación de la misma.

Sobre el servicio web clásico podemos disponer de

aplicaciones web. Estas son fragmentos de código que se ejecutan
cuando se realizan ciertas peticiones o respuestas HTTP. Hay que
distinguir entre:
Aplicaciones en el lado del cliente: el cliente web es el encargado

de ejecutarlas en la máquina del usuario. Son las aplicaciones
tipo Java o JavaScript: el servidor proporciona el código de las
aplicaciones al cliente y éste, mediante el navegador, las ejecuta.
Es necesario, por tanto, que el cliente disponga de un navegador
con capacidad para ejecutar aplicaciones (también llamadas
scripts). Normalmente, los navegadores permiten ejecutar
aplicaciones escritas en lenguaje javascript y java, aunque
pueden añadirse más lenguajes mediante el uso de plugins
Aplicaciones en el lado del servidor: el servidor web ejecuta la
aplicación; ésta, una vez ejecutada, genera cierto código HTML;
el servidor toma este código recién creado y lo envía al cliente
por medio del protocolo HTTP.
Las aplicaciones de servidor suelen ser la opción por la que se

opta en la mayoría de las ocasiones para realizar aplicaciones web. La
razón es que, al ejecutarse ésta en el servidor y no en la máquina del
cliente, éste no necesita ninguna capacidad adicional, como sí ocurre
en el caso de querer ejecutar aplicaciones javascript o java. Así pues,
cualquier cliente dotado de un navegador web básico puede utilizar
este tipo de aplicaciones. Algunos conceptos relacionados con las
aplicaciones web son PHP, ASP, Perl, CGI, NET, JSP (Tecnología
Java). Algunos servidores web importantes son Apache, IIS, Cherokee.
Otros servidores, más simples pero más rápidos, son lighttpd, thttpd.
[URL08]

2.9.9. Aplicación Web
Una aplicación web es un sitio web donde la navegación a

través del sitio, y la entrada de datos por parte de un usuario, afectan
el estado de la lógica del negocio. En esencia, una aplicación web usa
un sitio web como entrada (front-end) a una aplicación típica. Si no
existe lógica del negocio en el servidor, el sistema no puede ser
llamado aplicación web.3
Una aplicación web es un sistema informático que los usuarios

utilizan accediendo a un servidor web a través de Internet o de una
intranet. Las aplicaciones web son populares debido a la practicidad
del navegador web como cliente ligero. La facilidad para actualizar y
mantener aplicaciones web sin distribuir e instalar software en miles de
potenciales clientes es otra razón de su popularidad. Aplicaciones
como los webmails, wikis, weblogs, tiendas en línea y la Wikipedia
misma son ejemplos bien conocidos de aplicaciones web.
Gráfico Nº 6: Arquitectura básica de una aplicación web

Fuente: Google Images
En los primeros tiempos de la computación cliente-servidor,

cada aplicación tenía su propio programa cliente y su interfaz de
usuario, estos tenían que ser instalados separadamente en cada
estación de trabajo de los usuarios. Una mejora al servidor, como parte
de la aplicación, requería típicamente una mejora de los clientes
instalados en cada una de las estaciones de trabajo, añadiendo un
costo de soporte técnico y disminuyendo la eficiencia del personal.
3
Jim Conallen, Modeling Web Application Architectures with UML, Junio 1999.

En contraste, las aplicaciones web generan dinámicamente una

serie de páginas en un formato estándar, soportado por navegadores
web comunes como HTML o XHTML. Se utilizan lenguajes
interpretados del lado del cliente, tales como JavaScript, para añadir
elementos dinámicos a la interfaz de usuario. Generalmente cada
página web individual es enviada al cliente como un documento
estático, pero la secuencia de páginas provee de una experiencia
interactiva.
Las interfaces web tienen ciertas limitaciones en la

funcionalidad del cliente. Métodos comunes en las aplicaciones de
escritorio como dibujar en la pantalla o arrastrar-y-soltar no están
soportadas por las tecnologías web estándar. Los desarrolladores web
comúnmente utilizan lenguajes interpretados del lado del cliente para
añadir más funcionalidad, especialmente para crear una experiencia
interactiva que no requiera recargar la página cada vez (cosa que
suele molestar a los usuarios). Recientemente se han desarrollado
tecnologías para coordinar estos lenguajes con tecnologías del lado
del servidor, como por ejemplo PHP. AJAX, es una técnica de
desarrollo web que usa una combinación de varias tecnologías.
Aunque muchas variaciones son posibles, una aplicación web

está comúnmente estructurada como una aplicación de tres-capas. En
su forma más común, el navegador web es la primera capa, un motor
usando alguna tecnología web dinámica (ejemplo: CGI, PHP, Java
Servlets o ASP) es la capa de en medio, y una base de datos como
última capa. El navegador web manda peticiones a la capa media, que
la entrega valiéndose de consultas y actualizaciones a la base de
datos generando una interfaz de usuario.
Existen numerosos lenguajes de programación empleados

para el desarrollo de aplicaciones web, entre los que destacan PHP,
ASP/ASP.NET, Java, con sus tecnologías Java Servlets y JavaServer
Pages (JSP), Perl, Ruby, Pitón. [URL09]

2.9.9.1. Características de una aplicación web
Las aplicaciones web tienen una serie de rasgos comunes que

diferencia a unos tipos de aplicaciones software de otros, y que son:
Desde el punto de vista del usuario, se ha universalizado

su accesibilidad: Actualmente un usuario experto y un
usuario con habilidad limitada en el uso de aplicaciones
informáticas acceden al mismo tipo de aplicación. Aún
más, el número y tipo de usuario de las aplicaciones web
no siempre es predecible, lo que obliga a tener el
concepto de facilidad de uso aún más presente que en
otros tipos de aplicaciones.
Desde el punto de vista de la plataforma se realiza un uso
intensivo de la red y la conexión se establece desde
distintos tipos de dispositivo de acceso.
Desde el punto de vista de la información, asistimos en la
actualidad a una disponibilidad global de fuentes
heterogéneas de información, estructurada y no
estructurada, pertenecientes a distintos dominios y que
colaboran en el cumplimiento de los objetivos de la
aplicación.
2.9.9.2. Requisitos de desarrollo de una aplicación web
Cada una de estas perspectivas introduce una serie de

requisitos que deben ser tenidos en cuenta durante el proceso de
desarrollo de cualquier tipo de aplicación web con el fin de
incrementar su probabilidad de éxito de implantación y que pueden
ser estructuradas como sigue:
Portabilidad.- Debido a la dinamicidad del entorno

tecnológico, a menudo es necesario implantar una misma
aplicación en distintas plataformas, con distintas
arquitecturas, con distintas tecnologías y/o atendiendo a
distintos dispositivos de acceso, lo que obliga a
desarrollar técnicas, modelos y herramientas que faciliten
la reutilización e independiza hasta donde sea posible en
el desarrollo de la aplicación.

Inmediatez (Rapidez de Implantación).- El desarrollo de

aplicaciones web requiere un período de implantación
mucho más reducido, que influye en todo su ciclo de
desarrollo.
Creación de contenidos como parte integrante de la fase
de ingeniería de la aplicación. Aunque en este trabajo nos
centramos en la especificación de aplicaciones orientadas
a ofrecer funcionalidad compleja, más allá de la mera
diseminación de información, el diseño y producción de
textos, gráficos, vídeos etc. que conforman la estructura
informacional de la aplicación es una tarea que debería
ser realizada en paralelo al diseño de la propia aplicación.
Integración (disponibilidad global), de fuentes
heterogéneas de información. La posible necesidad de
manejo integrado de contenido estructurado y no
estructurado, almacenado en distintos formatos (bases de
datos, sistemas de ficheros, dispositivos multimedia) y
accesibles de forma distribuida mediante múltiples
aplicaciones es otro de los factores que condiciona el
proceso de diseño de este tipo de aplicaciones.
2.9.9.3. Requisitos para la aplicación de una aplicación web
Los requisitos que vamos a destacar en una aplicación web,

son los siguientes:
Evolución orgánica. Es un aspecto fundamental en el

ámbito de la web, donde tanto el contenido como los
requisitos de las aplicaciones evolucionan a una velocidad
vertiginosa. Esto es en parte debido a que los clientes de
este tipo de aplicaciones suelen tener un conocimiento
muy pobre de sus necesidades y de las posibilidades del
sistema.
Seguridad en la comunicación. Debido a que las
aplicaciones web se encuentran disponibles a través de
una red, es difícil limitar el grupo de usuarios finales que
pueden acceder a ella. Es por ello que se hacen
necesarios mecanismos para proteger información

sensible y proporcionar modos seguros de transmisión de

datos.
Calidad (margen de error cero). La permisividad mostrada
por los usuarios ante los errores en aplicaciones web
(robustez, facilidad de uso o rendimiento) es muy limitada:
enlaces erróneos o información desactualizada provocan
la pérdida de usuarios de la aplicación. Es por ello que en
el desarrollo de este tipo de aplicaciones es primordial
disponer de mecanismos exhaustivos de control de
calidad que minimicen las posibilidades de fracaso de la
aplicación.
Velocidad. El uso intensivo de la red provoca que la
elección de protocolos de comunicación y el
mantenimiento de una velocidad de acceso adecuada
sean una parte clave de diseño de dichas aplicaciones.
Importancia de la interfaz. La necesidad de implementar
interfaces de usuario más intuitivas, capaces de capturar
la atención del usuario y facilitar el acceso a la información
a aquéllos que poseen una habilidad limitada en el uso de
aplicaciones informáticas.
Necesidad de personalización. Debido, a la facilidad de
migración del usuario a otras aplicaciones y la variedad de
este tipo de aplicaciones, la personalización es un
elemento significativo del diseño, y da valor añadido a un
contenido que debe además ser accesible y estar
actualizado.
A estos requisitos debemos añadirles seguridad de la
propia aplicación, escalabilidad, disponibilidad,
interoperabilidad con sistemas propietarios, etc.

2.9.10. 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.
En este sentido, la Ingeniería de la web hace referencia a las

metodologías, técnicas y herramientas que se utilizan en el desarrollo
de aplicaciones web complejas y de gran dimensión en las que se
apoya la evaluación, diseño, desarrollo, implementación y evolución de
dichas aplicaciones.
El desarrollo de aplicaciones web posee determinadas

características que lo hacen diferente del desarrollo de aplicaciones o
software tradicional y sistemas de información.
La ingeniería de la web es multidisciplinar y aglutina

contribuciones de diferentes áreas: arquitectura de la información,
ingeniería de hipermedia/hipertexto, ingeniería de requisitos, diseño de
interfaz de usuario, usabilidad, diseño gráfico y de presentación,
diseño y análisis de sistemas, ingeniería de software, ingeniería de
datos, indexado y recuperación de información, testeo, modelado y
simulación, despliegue de aplicaciones, operación de sistemas y
gestión de proyectos.
La ingeniería de la web no es un clon o subconjunto de la

ingeniería de software aunque ambas incluyen desarrollo de software y
programación, pues a pesar de que la ingeniería de la web utiliza
principios de ingeniería de software, incluye nuevos enfoques,
metodologías, herramientas, técnicas, guías y patrones para cubrir los
requisitos únicos de las aplicaciones web.
Los principales aspectos de la ingeniería de la web incluyen,

entre otros, los siguientes temas:
Diseño de procesos de negocio para aplicaciones web.

Herramientas CASE para aplicaciones web
Generación de código para aplicaciones web
Desarrollo web colaborativo

Modelado conceptual de aplicaciones web

Diseñó de Modelos de datos para sistemas de información
web
Ingeniería web empírica
Entornos de desarrollo de aplicaciones web integrados
Herramientas de autor para contenido multimedia
Pruebas de rendimiento de aplicaciones basadas en web
Personalización y adaptación de aplicaciones web
Modelado de procesos para aplicaciones web
Herramientas y métodos de prototipazo
Control de calidad y pruebas de sistemas
Ingeniería de requisitos para aplicaciones web
Aplicaciones para la web semántica
Factorías de software para la web
Métodos, herramientas y automatización de pruebas para
aplicaciones web
Aplicaciones web móviles y ubicuas
Usabilidad de aplicaciones web
Accesibilidad para la web
Metodologías de diseño web
Formación en ingeniería de la web
Diseño de interfaces de usuario
Métricas para la web, estimación de costes y medición
Gestión de proyectos web y gestión de riesgos
Desarrollo y despliegue de servicios web
[URL12]
2.9.11. Lenguaje Unificado de Modelado
Lenguaje Unificado de Modelado (UML, por sus siglas en

inglés, Unified Modeling Language) es el lenguaje de modelado de
sistemas de software más conocido y utilizado en la actualidad; aún
cuando todavía no es un estándar oficial, está respaldado por el OMG
(Object Management Group). Es un lenguaje gráfico para visualizar,
especificar, construir y documentar un sistema de software. UML
ofrece un estándar para describir un "plano" del sistema (modelo),
incluyendo aspectos conceptuales tales como procesos de negocios y

funciones del sistema, y aspectos concretos como expresiones de

lenguajes de programación, esquemas de bases de datos y
componentes de software reutilizables.
Es importante resaltar que UML es un "lenguaje" para

especificar y no para describir métodos o procesos. Se utiliza para
definir un sistema de software, para detallar los artefactos en el
sistema y para documentar y construir. En otras palabras, es el
lenguaje en el que está descrito el modelo. Se puede aplicar en una
gran variedad de formas para dar soporte a una metodología de
desarrollo de software (tal como el Proceso Unificado de Rational) -
pero no especifica en sí mismo qué metodología o proceso usar.
UML cuenta con varios tipos de diagramas, los cuales muestran

diferentes aspectos de las entidades representadas
En UML 2.0 hay 13 tipos diferentes de diagramas. Para

comprenderlos de manera concreta, a veces es útil categorizarlos
jerárquicamente, como se muestra en el siguiente gráfico.
Gráfico Nº 7: Jerarquía de los diagramas UML 2.0

Fuente: Wikipedia

Diagramas de estructura.- Enfatizan en los elementos que deben

existir en el sistema modelado:
Diagrama de clases
Diagrama de componentes
Diagrama de objetos
Diagrama de estructura compuesta (UML 2.0)
Diagrama de despliegue
Diagrama de paquetes
Diagramas de comportamiento.- Enfatizan en lo que debe suceder en

el sistema modelado:
Diagrama de actividades
Diagrama de casos de uso
Diagrama de estados
Diagramas de Interacción.- Un subtipo de diagramas de

comportamiento, que enfatiza sobre el flujo de control y de datos entre
los elementos del sistema modelado:
Diagrama de secuencia
Diagrama de comunicación
Diagrama de tiempos (UML 2.0)
Diagrama de vista de interacción (UML 2.0)
[URL11]
2.9.12. Servidor HTTP Apache
El servidor HTTP Apache es un software (libre) servidor HTTP

de código abierto para plataformas Unix (BSD, GNU/Linux, etc.),
Windows, Macintosh y otras, que implementa el protocolo HTTP/1.1 [1]
y la noción de sitio virtual. Cuando comenzó su desarrollo en 1995 se
basó inicialmente en código del popular NCSA HTTPd 1.3, pero más
tarde fue reescrito por completo. Su nombre se debe a que
originalmente Apache consistía solamente en un conjunto de parches
a aplicar al servidor de NCSA. Era, en inglés, a patchy server (un
servidor "parcheado").
El servidor Apache se desarrolla dentro del proyecto HTTP

Server (httpd) de la Apache Software Foundation.

Apache presenta entre otras características mensajes de error

altamente configurables, bases de datos de autenticación y negociado
de contenido, pero fue criticado por la falta de una interfaz gráfica que
ayude en su configuración.
Apache tiene amplia aceptación en la red: en el 2005, Apache

es el servidor HTTP más usado, siendo el servidor HTTP del 48% de
los sitios Web en el mundo y decreciendo su cuota de mercado
(estadísticas históricas y de uso diario proporcionadas por Netcraft [2]).
La mayoría de las vulnerabilidades de la seguridad

descubiertas y resueltas puede en la mayoría de los casos ser
abusada solamente por los usuarios locales y no puede ser accionada
remotamente. Sin embargo, algunas de las ediciones antedichas se
pueden accionar remotamente en ciertas situaciones, o explotar por
los usuarios locales malévolos en las disposiciones de recibimiento
compartidas que utilizan PHP como módulo de Apache.
Ventajas:
Modular
Open source
Multi-plataforma
Extensible
Popular (fácil conseguir ayuda/soporte)
Gratuito
Módulos:
La arquitectura del servidor Apache es muy modular. El

servidor consta de una sección core y mucha de la funcionalidad que
podría considerarse básica para un servidor web es provista por
módulos. Algunos de estos son:
mod_ssl - Comunicaciones Seguras vía TLS.

mod_rewrite - reescritura de direcciones servidas
(generalmente utilizado para transformar páginas dinámicas
como php en páginas estáticas html para así engañar a los
navegantes o a los motores de búsqueda en cuanto a como
fueron desarrolladas estas páginas).
mod_dav - Soporte del protocolo WebDAV (RFC 2518).

mod_deflate - Compresión transparente con el algoritmo

deflate del contenido enviado al cliente.
mod_auth_ldap - Permite autentificar usuarios contra un
servidor LDAP.
mod_proxy_ajp - Conector para enlazar con el servidor
Jakarta Tomcat de páginas dinámicas en Java (servlets y
JSP).
El servidor de base puede ser extendido con la inclusión de

módulos externos entre los cuales se encuentran:
mod_perl - Páginas dinámicas en Perl.

mod_php - Páginas dinámicas en PHP.
mod_python - Páginas dinámicas en Python.
mod_rexx - Páginas dinámicas en REXX y Object REXX.
mod_ruby - Páginas dinámicas en Ruby.
mod_aspdotnet - Páginas dinámicas en .NET_de_Microsoft
(Módulo retirado).
mod_mono - Páginas dinámicas en Mono
mod_security - Filtrado a nivel de aplicación, para seguridad.
[URL10]
2.9.13. Sistema operativo Linux
Linux (pronunciación Iinuks) es la denominación de un sistema

operativo tipo-Unix y el nombre de un núcleo. Es uno de los
paradigmas más prominentes del software libre y del desarrollo del
código abierto, cuyo código fuente está disponible públicamente, para
que cualquier persona pueda libremente usarlo, estudiarlo,
redistribuirlo y, con los conocimientos informáticos adecuados,
modificarlo.
Los primeros sistemas Linux se originaron en 1992, al combinar

utilidades de sistema y librerías del proyecto GNU con el núcleo Linux,
completando un sistema también conocido como GNU/Linux. Desde
fines de 2000 Linux ha obtenido un aumento en el apoyo de diversas
empresas multinacionales del mundo de la informática, tales como
IBM, Sun Microsystems, Hewlett-Packard y Novell. Actualmente Linux
es comercializado en computadores de escritorio y portátiles por Dell y

Lenovo, además hay un grupo numeroso de compañías establecidas

en Taiwan que planean hacer lo propio.
Si bien Linux es usado como sistema operativo en

computadores de escritorio (PCs x86 y x86-64 así como Macintosh y
PowerPC), computadores de bolsillo, teléfonos celulares, dispositivos
empotrados y otros, su mayor desarrollo se ha llevado a cabo en el
mundo de los servidores y supercomputadores.
La marca Linux (Número de serie: 1916230) pertenece a Linus

Torvalds y se define como "un sistema operativo para computadoras
que facilita su uso y operación".
Existen numerosas distribuciones Linux (también conocidas

como "distros"), ensambladas por individuos, empresas y otros
organismos. Cada distribución puede incluir cualquier número de
software adicional, incluyendo software que facilite la instalación del
sistema. La base del software incluido con cada distribución incluye el
núcleo Linux y las herramientas GNU, al que suelen adicionarse
también varios paquetes de software.
Algunas distribuciones muy utilizadas son Fedora, Debian,

SuSE, Ubuntu o YellowDog (esta última es la más común en la
plataforma PlayStation 3). La mayoría de las distribuciones son
gratuitas y pueden conseguirse fácilmente a través de las páginas web
de los fabricantes. [URL16]
2.9.14. Gestor de base de datos MySQL
MySQL es un sistema de gestión de base de datos relacional,

multihilo y multiusuario con más de seis millones de instalaciones.
MySQL AB desarrolla MySQL como software libre en un esquema de
licenciamiento dual. Por un lado lo ofrece bajo la GNU GPL, pero,
empresas que quieran incorporarlo en productos privativos pueden
comprar a la empresa una licencia que les permita ese uso. Está
desarrollado en su mayor parte en ANSI C.
Al contrario de proyectos como el Apache, donde el software

es desarrollado por una comunidad pública, y el copyright del código
está en poder del autor individual, MySQL es propiedad y está
patrocinado por una empresa privada, que posee el copyright de la

mayor parte del código. Esto es lo que posibilita el esquema de

licenciamiento anteriormente mencionado. Además de la venta de
licencias privativas, la compañía ofrece soporte y servicios. Para sus
operaciones contratan trabajadores alrededor del mundo que
colaboran vía Internet. MySQL AB fue fundado por David Axmark,
Allan Larsson, y Michael Widenius. [URL17]
2.9.15. PHP
PHP es un lenguaje de programación usado frecuentemente

para la creación de contenido para sitios Web con los cuales se puede
programar las páginas html y los códigos de fuente. PHP es un
acrónimo recursivo que significa "PHP Hypertext Pre-processor"
(inicialmente PHP Tools, o, Personal Home Page Tools), y se trata de
un lenguaje interpretado usado para la creación de aplicaciones para
servidores, o creación de contenido dinámico para sitios web.
Últimamente también para la creación de otro tipo de programas
incluyendo aplicaciones con interfaz gráfica usando las librerías Qt o
GTK+. [URL18]
2.9.16. XAJAX
Xajax es una biblioteca código abierto de PHP capaz de

generar aplicaciones Web con tecnología AJAX.
Xajax utiliza una forma de trabajo de funciones, designando

qué funciones de código PHP se convierten en funciones AJAX.
AJAX se ha convertido en una de las tecnologías más

populares para la creación de aplicaciones web dinámicas. Por tal
razón hay una gran cantidad de bibliotecas y frameworks que nos
permiten hacer uso de esta tecnología de una manera sencilla y
cómoda. Algunos de ellos son Prototype, ScriptAculous, Google web
Toolkit (GWT), Xajax entre otros. En este artículo se realizará una
comparación entre las web Tradicionales y la introducción de la
tecnología AJAX en las mismas, pero principalmente se centrará en la
implementación de AJAX utilizando la biblioteca Xajax. [URL19]

2.10. Metodología de desarrollo UWE
UWE (UML Based Web Engineering, Ingeniería Web basada en UML)

[Koch 2001], es una propuesta metodológica basada en el Proceso Unificado
[Jacobson et al. 1999] [Kruchten 1998] y UML para el desarrollo de
aplicaciones web. UWE cubre todo el ciclo de vida de este tipo de
aplicaciones centrando además su atención en aplicaciones personalizadas o
adaptativas. Su proceso de desarrollo se basa en tres fases principales: la
fase de captura de requisitos, la fase de análisis y diseño y la fase de
implementación.
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 adaptivas de la navegación en función de las
preferencias, conocimiento o tareas de usuario.
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 un 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 proceso de desarrollo de UWE se caracteriza por la importancia que

da a la segunda fase, la de análisis y diseño. Todo el proceso de desarrollo de
UWE se encuentra detallado y definido, así como la estructura de los modelos
que se van generando. Sin embargo es en el análisis y diseño donde se
enfoca más la propuesta. En el gráfico 8 se presenta un esquema general con
las fases que plantea esta metodología.
Gráfico Nº 8: Proceso de desarrollo de la metodología UWE

Fuente: Internet

UWE es una propuesta muy completa que concreta mucho las tareas a
realizar. De esta forma, y aunque no se ha concretado en la figura para no
complicarla demasiado UWE propone las siguientes etapas:
a. En la primera fase, propone comenzar con la identificación de los

usuarios y la elicitación de los requisitos. Trata de diferente forma las
necesidades de información, las necesidades de navegación, las
necesidades de adaptación y las de interfaz de usuario, así como
algunos requisitos adicionales relacionados, por ejemplo, con las
restricciones hardware o la seguridad. Tras esto, centra el trabajo en el
estudio de los casos de uso, la generación de los glosarios y el
prototipado de la interfaz de usuario. Las tareas que vamos a realizar
son las siguientes:
Identificación de participantes
Objetivos del sistema
Definición de requisitos
Requisitos de almacenamiento de información
Requisitos de interfaz
Requisitos no funcionales
b. En la fase de análisis y diseño, distingue entre diseño conceptual, de
modelo de usuario, de navegación, de presentación, de adaptación, de
la arquitectura, en el diseño detallado de las clases y en la definición
de los subsistemas e interfaces. Se consideran las siguientes tareas:
Diseño conceptual.- Se basa en el análisis de requisitos,

reflejados en los casos de uso del paso anterior, se materializa
en un modelo de dominio.
Diseño navegacional
Modelo del espacio navegacional.- Se determina las
clases para cada tipo de usuario que pueden visitar a
través de la aplicación web.
Modelo de la estructura de presentación.- Muestra la
forma de navegar ante el espacio de navegación.
Diseño de presentación.- Representa las vistas del interfaz del
usuario mediante modelos estándares de interacción UML.
Diseño lógico de la base de datos.- El objetivo del diseño lógico
es convertir los esquemas conceptuales en un esquema lógico

global que se ajuste al modelo de la base de datos sobre el que

se va a implementar el sistema.
c. Por último, en la fase de implementación, UWE incluye todas las
tareas que llevan a la implementación de los modelos aceptados:
implementación de la arquitectura, implementación de la estructura del
hiperespacio, implementación del modelo de usuario, implementación
de la interfaz de usuario, implementación de los mecanismos
adaptativos y las tareas referentes a la integración de todas estas
implementaciones. Las tareas que se han considerado son las
siguientes:
Implementación de la base de datos
Implementación de la interfaz de usuario
Implementación de la arquitectura.
Centrando el estudio de UWE en el tratamiento de la navegación,

comentar que UWE propone ya en su fase de requisitos una elicitación de los
requisitos de navegación. UWE considera los requisitos de navegación como
un tipo de requisito funcional y, aunque realmente no propone técnicas
específicas para este tratamiento, principalmente se basa en los casos de uso
[Jacobson 1995][Booch et al. 1999], los separa con idea de identificar mejor
los aspectos que influirán en el modelo navegacional que se realiza en la fase
de análisis y diseño.
Este modelo de navegación se construye en dos fases. En una primera

etapa se desarrolla un modelo de espacio de la navegación, construido como
vista del modelo conceptual y que indica cuáles son las clases y modelos
visitables. Se representa mediante un modelo de clases especiales
denominadas clases navegacionales que no son más que clases de UML
estereotipadas para indicar su semántica. Este modelo se enriquece en una
segunda etapa con el modelo de la estructura de la navegación. En él ya no
sólo se indica qué es visitable, sino también cómo estos objetos son visitados.
UWE es una propuesta que en los últimos años ha conseguido gran

aceptación en los foros de investigación. Sus modelos basados totalmente en
UML están siendo muy bien valorados. Además, es una propuesta viva.
Actualmente también se está trabajando en una herramienta que sea capaz
de soportar su ciclo de vida denominada ArgoUWE [ArgoUWE 2004].

2.10.1. Relaciones con otras metodologías
UWE es una metodología que ha surgido basándose en otras

metodologías, asumiendo algunas de sus ideas y experiencias de
grupos y metodologías anteriores para definir sus aproximaciones.
Esta relación se muestra en el siguiente gráfico mediante

líneas continuas dirigidas. En otros casos, la relación entre los
entornos metodológicos resulta más fuerte en el sentido de que
incluso parte del equipo de desarrollo de una propuesta forman parte
del equipo de desarrollo de otra, o incluso, hay propuestas como el
proyecto UWA que incorpora totalmente una o varias fases de otras
propuestas como W2000. Esta relación viene representada
mediante una línea discontinua.
Gráfico Nº 9. UWE y otras metodologías de desarrollo web


2.10.2. Criterios de selección de la metodología UWE
Se ha elegido UWE como la metodología de desarrollo por los

siguientes criterios:
Es una propuesta orientada a objetos, iterativa e incremental

basada en UML y en el proceso de desarrollo de software
unificado.
Mayor importancia en la fase de análisis y diseño.
Uso del paradigma orientado a objetos, su orientación al
usuario, la definición de un 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.
Definición de los pasos para la construcción de los diferentes
modelos.
Recomienda el uso de restricciones escritas (OCL: Lenguaje
de restricciones de objetos) para aumentar la exactitud de los
modelos.
Por tener gran aceptación por la comunidad de
desarrolladores en aplicaciones web.
Por ser una propuesta novedosa de los autores.

Capitulo III
DESARROLLO
En este capitulo se realizan todas las actividades para el desarrollo del

Sistema de Información. La metodología de desarrollo esta basada en la propuesta
UWE y las etapas que consideramos son las siguientes:
Fase I: Captura de requisitos

Identificación de participantes
Objetivos del sistema
Identificación de actores
Identificación de requisitos
• Requisitos de almacenamiento de información
• Requisitos de interfaz
• Requisitos transaccionales o funcionales
• Requisitos no funcionales
Fase II: Análisis y Diseño
Diseño conceptual
Diseño navegacional
• Modelo del espacio navegacional
• Modelo de la estructura de navegación
Diseño de presentación
Diseño lógico de la base de datos
Fase III: Implementación
Implementación de la base de datos
Implementación de la interfaz de usuario
Implementación de la arquitectura
En la fase de ingeniería de requisitos, se determina las necesidades que

debe cumplir el sistema. En este proceso, los usuarios involucrados asumen un
papel importante, se emplearon técnicas como entrevistas, cuestionarios y tormenta
de ideas. Se emplearon diagramas de casos de uso y patrones.
En la fase del análisis y diseño se definen los modelos mediante el uso de

metamodelos representados mediante la notación de diagramas UML. Se
representa la estructura estática del sistema. Se ofrece una vista de cómo se va a
presentar la información al usuario.
En la última fase, de implementación se incluyen todas las tareas que llevan

a la implementación de los modelos analizados en la fase anterior.

3.1. Captura de Requisitos
3.1.1. Identificación de participantes
PA-01
Participante Carlos A. Coronado C.
Gilmer Velásquez S.
Area Autor del proyecto
Rol Bachiller en Ingeniería de Sistemas
Desarrollador Si
Cliente No
Usuario No
Tabla Nº 6: Patrón del participante PA-01
PA02
Participante Karin Aldana Farias
Area Departamento de Cobranzas
Rol Fuente
Desarrollador No
Cliente Si
Usuario Si
PA03
Participante Mariela Medranda Vargas
Area Analista de Ventas
Rol Fuente
Desarrollador No
Cliente Si
Usuario Si
PA04
Participante Angélica Cruz Alarcón,
Sara Gutierrez Castañeda
Area Unidad de Caja
Rol Fuente
Desarrollador No
Cliente Si
Usuario Si

PA05
Participante Marilu Feijo Vilela
Area Contabilidad
Rol Fuente
Desarrollador No
Cliente Si
Usuario No
3.1.2. Objetivos del sistema
OBJ-01 Gestión y control del flujo de ingresos

Autor Carlos A. Coronado C.
Fuentes Karin Aldana Farias
Mariela Medranda Vargas
Descripción El sistema deberá ser capaz de facilitar
el seguimiento y control en los ingresos
de la Universidad.
Tabla Nº 11: Patrón del objetivo OBJ-01
OBJ-02 Emitir informes detallados y

consolidados de ingresos.
Descripción El sistema deberá proporcionar
información relevante y confiable de los
ingresos de la universidad según los
formatos establecidos por el
OBJ-03 Centralizar la información de ingresos.

Descripción El sistema deberá centralizar la
información de los ingresos y estar
disponible en tiempo real, considerando
las restricciones establecidas por el

OBJ-04 Posibilitar la ampliación del proyecto

Descripción El sistema debe ofrecer la posibilidad de
añadir nuevas funcionalidades a la
aplicación, de acuerdo a las nuevas
disposiciones del Departamento de
Cobranzas.
OBJ-05 Gestión de usuarios

Descripción El sistema debe gestionar el grupo de
usuarios que tendrá acceso a la
aplicación. Será el administrador del
sistema el encargado de gestionar el
grupo de usuarios que harán uso de la
aplicación.
3.1.3. Identificación de actores
AC-01 Jefe de Cobranza

Objetivos OBJ-01: Gestión y control del flujo de
ingresos.
OBJ-02: Emitir informes detallados y
Descripción Podrá introducir, modificar y borrar
datos en la base de datos.
Comentarios El usuario con este perfil, tendrá acceso
a todas las funcionalidades de
mantenimiento, control y seguimiento de
la aplicación.
Tabla Nº 16: Patrón del Actor AC-01

AC-02 Analista de Venta

Objetivos OBJ-01: Gestión y control del flujo de ingresos.
OBJ-02: Emitir informes detallados y
Descripción Podrá introducir, modificar y borrar datos en la base
de datos.
Comentarios El usuario con este perfil, tendrá acceso a todas las
funcionalidades de mantenimiento, control y
seguimiento de la aplicación.
AC-03 Cajera
Objetivos OBJ-02: Emitir informes detallados y
OBJ-03: Centralizar la información de los
ingresos.
Descripción Ingresará al sistema todos los pagos realizados por,
alumnos, clientes u otras fuentes según la plantilla
de costos vigentes.
Comentarios El usuario con este perfil, tendrá acceso a las
funcionalidades de registro y consultas de ingresos.
AC-04 Administrador
Objetivos OBJ-04: Posibilitar la ampliación del proyecto.
OBJ-05: Gestión de usuarios.
Descripción Establecerá los permisos de acceso a los usuarios a
la aplicación. Es el encargado del mantenimiento del
sistema y también del desarrollo de nuevas
funcionalidades.
Comentarios El usuario con este perfil, tendrá acceso exclusivo a
la gestión de usuarios y no a otras funcionalidades
del sistema.

3.1.4. Definición de requisitos
En esta parte se plantean las necesidades del sistema utilizando

patrones formales.
3.1.4.1. Requisitos de almacenamiento de información
Para definir estos requisitos se responde a la pregunta: ¿Qué

información debe almacenar y administrar el sistema?
RA-01 Comprobante de pago

Objetivos OBJ-01, OBJ02, OBJ03
asociados
Descripción El sistema deberá almacenar información
correspondiente a los comprobantes de pago (facturas
y boletas).
Datos Dato Descripción Naturaleza
específicos Serie Almacena el número de Cadena
serie del documento de
venta.
Numero Almacena el número del Cadena
comprobante de pago.
Fecha de Almacena la fecha de Fecha
emisión emisión del comprobante Formato:{dd-
de pago. mm-aaaa}
Nombre Almacena el nombre del Cadena
del alumno que realizo el
alumno pago.
Sede Almacena información Cadena
de la unidad
recaudadora que emite
el documento.
Escuela Almacena información Cadena
de la escuela del
alumno.
Concepto Almacena el detalle por Cadena
el cual se emite el
Cantidad Almacena el número de Numérico
unidades del concepto.
Importe Almacena el importe del Real
concepto.
Emisor Almacena el nombre de Cadena
la cajera que emitió el
Tabla Nº 20: Patrón del requisito RA-01

RA-02 Compromiso
asociados
Descripción El sistema deberá almacenar deberá almacenar los
compromisos de pago del alumno con la Universidad.
específicos Nombre del Almacena el propietario Cadena
alumno de la cuenta corriente.
Detalle Almacena la Cadena
descripción de la tasa
administrativa.
Semestre Almacena el semestre Cadena
académico.
Fecha de Almacena la fecha en Fecha
Pago que se realizo el pago. Formato:{dd-
mm-aaaa}
vencimiento vencimiento del Formato:{dd-
compromiso. mm-aaaa}
Numero de Almacena el número de Cadena
Operación operación del voucher.
Fecha de Almacena la fecha del Fecha
deposito depósito efectuado. Formato:{dd-
mm-aaaa}
Importe Almacena el importe Real
compromiso que debe pagar el
alumno
Importe Almacena el importe Real
pagado que paga el alumno.
RA-03 Cronograma de pago

asociados
Descripción El sistema deberá almacenar el cronograma de pago
de la escuela.
específicos Sede Almacena el nombre Cadena
de la sede.
Escuela Almacena el nombre Cadena
de la escuela.
académico.
Ciclo Almacena el ciclo. Cadena
Turno Almacena el turno. Cadena
Vencimiento Es la fecha de Fecha
de Matricula vencimiento de la Formato:{dd-
matricula. mm-aaaa}
Vencimiento Es la fecha de Fecha

de matricula vencimiento de la Formato:{dd-

extemporánea matricula mm-aaaa}
extemporánea.
Vencimiento Almacena una lista de Fecha
de pensiones fechas de Formato:{dd-
vencimientos por mm-aaaa}
cada pensión. Cardinalidad:
0..n
RA-04 Plan de Costos

asociados
Descripción El sistema deberá almacenar los costos de matriculas
y pensiones de cada escuela según las normas
establecidas.
específicos Sede Almacena el nombre Cadena
de la sede.
Escuela Almacena el nombre Cadena
de la escuela.
académico.
Costo de Almacena el costo de Double
matricula la matricula.
Costos de Almacena una lista de Double
Categorías costos de pensión por Cardinalidad:
cada categoría. 0..5
RA-05 Resoluciones y Oficios

asociados
Descripción El sistema deberá almacenar resoluciones, oficios u
otros documentos que permitirán sustentar asignación
de costos irregulares en pensiones de los alumnos.
específicos Numero de Almacena el número del Cadena
documento documento.
Fuente Almacena el remitente Cadena
del documento.
Fecha Almacena la fecha de Fecha
emisión del documento. Formato:{dd-
mm-aaaa}
Motivo Almacena el motivo de Cadena
la emisión del
documento.

RA-06 Ficha de Alumno

asociados
Descripción El sistema deberá almacenar la información
correspondiente a los datos del alumno.
específicos Código Almacena información NA-01
alumno que identifica de manera
univoca a cada alumno.
Nombres Almacena información Cadena
sobre los nombres del
alumno.
Sede Almacena la sede en la Cadena
que el alumno estudia.
Escuela Almacena la escuela en Cadena
la que el alumno estudia.
Modalidad Almacena la modalidad Cadena
de enseñanza en la que
esta matriculado.
actual en la que esta
matriculado el alumno.
Ciclo Almacena el ciclo actual Cadena
en la que esta
Turno de Almacena el turno actual Cadena
asistencia en la que esta
RA-07 Notas de Crédito

Objetivos OBJ-01, OBJ02
asociados
Descripción El sistema deberá almacenar las notas de crédito
emitidas.
específicos Serie Almacena la serie de la Cadena
nota de crédito.
Numero Almacena el número de Cadena
la nota de crédito.
emisión emisión de la nota de Formato:{dd-
crédito. mm-aaaa}
Nombre Almacena los nombres Cadena
del alumno del alumno al que se le
emite la nota de crédito.
Importe Almacena el importe de Double
Concepto Almacena el concepto Cadena
de la nota de crédito,

Documento Almacena serie y Cadena

origen número del documento
que origina la nota de
crédito.
Emisor Almacena el nombre del Cadena
usuario que emite la
nota de crédito.
Con este patrón se tienen definidos los requisitos de

almacenamiento. Sin embargo en el patrón RA-06 se detalla la
necesidad de definir una nueva naturaleza.
NA-01 Dato código de alumno

Objetivos OBJ-01, OBJ02, OBJ-03
asociados
Descripción Esta naturaleza representa la estructura que describe
el código univoco identificativo a cada alumno.
específicos Código de Almacena, mediante Cadena
Sede un código de 2 Tamaño:2
dígitos el código de
la sede.
Código de Almacena, mediante Cadena
escuela un código de 2 Tamaño:2
dígitos el código de
la escuela.
Código de Almacena, mediante Cadena
semestre un código de tres Tamaño:3
dígitos el semestre
de admisión.
Número Almacena, mediante Cadena
Correlativo un número de tres Tamaño:3
dígitos el número
correlativo del
código.
Tabla Nº 27: Patrón del la naturaleza NA-01

3.1.4.2. Requisitos de interfaz
Todas las salidas del sistema deber estar escrito en

español.
El diseño de la interfaz debe reconocer eventos de mouse
y/o teclado para la navegación del sistema.
El código HTML generado en el servidor mediante PHP
deberá cumplir con el estándar HTML, además de estar
escrito en forma estricta, de tal forma que sea
correctamente interpretado por los navegadores más
importantes (Internet Explorer, Mozilla Firefox).
Los colores de la interfaz de usuario deben cumplir con el
estándar de la Universidad de Los Angeles de Chimbote.
3.1.4.3. Requisitos transaccionales o funcionales
En esta parte se identifican los requisitos funcionales del

sistema; para ello se emplea el diagrama de casos de uso general
del cual nos permite hacer las especificaciones de caso para cada
requerimiento del sistema.
Las especificaciones de casos de uso están asociadas a

alternativas que son condiciones que reflejan restricciones que
deben cumplirse en el sistema antes o después, respectivamente,
de llevarse acabo la funcionalidad representada por el requisito
funcional.

Gráfico Nº 10: Diagrama de Casos de Uso


Mediante el diagrama de caso de uso, mostramos una vista

general de las relaciones que existen entre los procesos y los
actores del sistema, a continuación se hacen las especificaciones
de caso de uso con la finalidad de describir con mayor detalle
cada uno de los casos de uso.
RF01: Registrar comprobante de pago

Descripción: Se utiliza para registrar los pagos de alumnos por
conceptos de matriculas, pensiones y otras tasas.
Actor: Cajera
Precondiciones:
El alumno debe estar registrado.
Deben existir costos de tasas.
Curso Normal Alternativas
1. El usuario busca el alumno.
2. El sistema muestra los datos del alumno
(sede, escuela, modalidad de enseñanza,
costos de matricula, numero de cuotas y el
costo por pensión. También muestra los
compromisos pendientes de pago.
Muestra la lista de tasas con sus
respectivos costos.
3. El usuario selecciona el concepto a cobrar.
4. El usuario selecciona el tipo de documento
Si selecciona
(boleta o factura). factura, el
sistema solicita
el número de
RUC del cliente.
5. El usuario selecciona la forma de pago Si el usuario
(efectivo, depósito o nota de crédito). selecciona pago
con depósito o
nota de crédito,
el sistema
solicita el
ingreso del
número de
documento y
fecha de
emisión.
6. El sistema registra el pago e emite el
Poscondiciones
Comprobante de pago registrado.
Comprobante de pago impreso.
Tabla Nº 28: Patrón de requisito RF-01

RF02: Ingresar cronograma de pagos

Descripción: Se utiliza para ingresar o modificar las fecha de
vencimiento de compromisos obligatorios que son matricula, matricula
extemporánea, pensiones, admisión, apertura de file, etc. Estos
compromisos se establecen para un semestre, ciclo y turno
específico.
Actor: Jefe de Cobranzas, Cajera
Precondiciones:
Deben existir costos en las tasas que se emplearán en las
fechas de vencimiento.
1. El usuario selecciona la sede, escuela,
semestre, ciclo y turno.
2. El sistema muestra las fechas de
vencimiento definidas actualmente.
3. El usuario ingresa o modifica las fechas de Si la fecha de
vencimiento. vencimiento es
Ingresa: incorrecta, el
Selecciona la tasa a agregar. sistema solicita
Ingresa la fecha de vencimiento. la corrección.
El sistema, valida la fecha.
El sistema almacena temporalmente la
fecha.
Modifica
Selecciona la fecha a modificar
Ingresa la nueva fecha de vencimiento
El sistema, valida la fecha.
El sistema reemplaza temporalmente
la fecha.
Repetir los pasos hasta que no haya mas
cambios.
4. El usuario define el orden en que deben
generarse los compromisos en las cuentas
corrientes de los alumnos.
5. El usuario guarda el cronograma de pago.
Poscondiciones:
Ninguno.
RF03: Mantenimiento del Plan de Costos

Descripción: Se utiliza para establecer costos por concepto de
matriculas y pensiones; se define el número de cuotas que debe
pagar el alumno en el semestre. En la primera categoría se establece
el costo regular y a partir de la segunda categoría se consideran
costos irregulares.
Actor: Jefe de Cobranzas
Precondiciones:
Debe existir categorías.

1. El usuario selecciona la sede, escuela y el

plan de costos.
2. El sistema visualiza los costos actuales del
plan de costos.
3. El usuario ingresa o modifica los costos de
la categoría de pago.
Ingresa:
Ingresa el costo de matricula.
Ingresa el número de cuotas.
Ingresa el costo de pensión
4. El sistema valida que se ingresen
correctamente el costo de matricula, el
numero de cuotas y el costo por cuota de la
categoría predeterminada (A), y
opcionalmente los costos de la otras
categorías (B-E).
5. El sistema guarda los datos ingresados.
6. Se repite los pasos 3 al 6 mientras no haya
nuevos cambios.
7. El sistema verifica si existen compromisos
de pagos con costos que deben cambiarse
al nuevo costo y actualiza todos los
registros afectados.
Poscondiciones:
Ninguno.
RF04: Registrar documento aval

Descripción: Se utiliza para registrar las resoluciones, oficios y otros
documentos emitidos por el consejo universitario o las direcciones de
escuelas acerca del cambio de costos en las pensiones de los
alumnos como becas, medias becas, categorizaciones o descuentos
por convenios.
Todos estos documentos se registran para sustentar el cambio de
costos en las pensiones de los alumnos.
Actor: Cajera, Jefe de Cobranzas
Precondiciones:
Ninguno
1. El usuario ingresa Si la resolución
La fecha de emisión del documento. ya existe, se
Número de resolución (código de muestra
identificación). información del
Remitente. documento.
Breve descripción.
2. El sistema registra el documento.
Poscondiciones:
Documento aval registrado.

RF05: Emitir reporte de liquidación diaria

Descripción: Permite emitir el reporte de liquidación al cerrar el turno
y para la verificación de ventas.
Actor: Cajera, Jefe de Cobranzas, Analista de Ventas
Precondiciones:
Deben existir comprobantes de pago registrados.
1. El usuario:
Ingresa fecha a liquidar.
Selecciona turno a liquidar.
2. El sistema muestra todas las unidades El usuario
operativas en las que hubo ingresos. puede
seleccionar una
sola unidad
operativa o
considerar
todas.
3. El usuario selecciona el tipo de reporte
(detalle o consolidado).
4. El sistema visualiza el reporte.
Poscondiciones:
Ninguno.
RF06: Emitir constancia no adeudo

Descripción: Se utiliza para la emisión de constancias de no adeudo.
La emisión de una constancia de no adeudo asegura que el alumno
no tiene deudas pendientes con la Institución.
Actor: Jefe de Cobranzas, Analista de Ventas
Precondiciones:
El alumno no debe tener deudas pendientes de pago.
1. El usuario busca al alumno.
2. El sistema muestra los datos del alumno
(nombres, sede y escuela).
3. El sistema verifica si el alumno no tiene
deudas pendientes, para ello revisa el
estado de cuenta del alumno.
4. Si el alumno tiene deudas pendientes,
Termina el caso de uso.
5. El usuario selecciona el tramite (Grado de
bachiller, Titulo Profesional, Grado de
Magíster u otros.).
6. El sistema emite la constancia de no
adeudo.
Poscondiciones:
Emitida la constancia de no adeudo.
Constancia de no adeudo registrada en el historial de
constancias de no adeudo.

RF07: Emitir reporte de pensiones por cobrar

Descripción: Se utiliza para reportar los compromisos pendientes de
pago de los alumnos concernientes a pensiones.
Precondiciones:
Deben existir compromisos de pensiones.
1. El usuario selecciona: Si no selecciona
Sede ciclo y turno, el
Escuela sistema debe
Semestre emitir el reporte
Ciclo considerando
todos los ciclos
y turnos.
2. El sistema visualiza el reporte incluyendo: El sistema debe
Código incluir también
Nombres aquellos que
Importe por pagar de pensiones (1..n) han pagado
(n): Es el número de cuotas. todos sus
pensiones pero
con importes a
cero.
Poscondiciones:
Ninguno.
RF08: Emitir reporte de ingresos por tasa

Descripción: Se utiliza para reportar las ventas por tasa de un
semestre o en un rango de fechas.
Precondiciones:
Las tasas deben estar definidas.
1. El usuario:
Selecciona sede
Selecciona escuela
O selecciona semestre o ingresa rango
de fechas
2. El usuario selecciona la tasa. Opcionalmente
el usuario puede
ingresar una
observación
adicional del
comprobante de
pago.
3. El sistema visualiza el reporte incluyendo:
Código
Nombres

Comprobante de pago (serie y

número)
Importe
Poscondiciones:
Ninguno.
RF09: Emitir informe estadístico de matriculados

Descripción: Se utiliza para emitir reportes estadísticos del numero de
alumnos por escuelas que han cancelado el concepto de matricula
correspondiente a un semestre.
Precondiciones:
Deben existir comprobantes de pago registrados por
conceptos de matriculas.
1. El usuario selecciona:
Sede.
Semestre.
2. El sistema visualiza el reporte incluyendo: Opcionalmente
Escuela. incluye gráfico
Número de alumnos por ciclos (I..XII). de barras.
El informe
puede ser
guardado en
formato PDF.
Poscondiciones:
Ninguno.
RF10: Emitir informe estadístico de morosidad

Descripción: Se utiliza para emitir un informe estadístico de
morosidad en pensiones correspondientes a un semestre específico.
Precondiciones:
Deben existir compromisos por pagar.
Para considerarse morosidad, las fechas de los compromisos
deben haber vencido.
Sede
Escuela
Semestre.
2. El sistema visualiza el informe estadístico Opcionalmente
incluyendo: incluye gráfico
Escuela de barras.
Total por cobrar El informe
Total morosidad puede ser

Porcentaje de morosidad guardado en

formato PDF.
Poscondiciones:
Ninguno.
RF11: Asignar costo irregular

Descripción: Se utiliza para asignar costos irregulares en las
pensiones del alumno debido a categorizaciones, becas, medias
becas, descuentos por convenios, etc.
Precondiciones:
Debe existir el documento aval.
Deben existir la plantilla de descuentos (es el porcentaje de
descuento aplicado al costo regular).
2. El sistema muestra los datos del alumno:
Código
Nombres
Sede
Modalidad
Semestre matriculado
Ciclo matriculado
Turno de asistencia matriculado
Categoría de pago actual
Costo de matricula actual
Numero de cuotas actual
Costo de por pensión actual
3. El usuario selecciona el documento aval. Si el documento
aun no esta
registrado en el
sistema ir a
RF04.
Tipo de asignación: Categorización o
beca o media beca o descuento por
convenio.
Semestre desde el cual tendrá efecto
la asignación.
5. El sistema calcula el nuevo costo por
pensión:
Si es categorización, se asigna la
nueva categoría (B-E).
Si es beca, se eliminan los
compromisos pendientes de pago para
el semestre de asignación.
Si es media beca, se aplica 50% de
descuento sobre el costo regular.
Si por convenio, se aplica el descuento
por convenio sobre el costo regular.

6. El sistema:
Actualiza el costo de pensiones en los
compromisos pendientes de pago para
el semestre asignado.
Asigna el nuevo costo al alumno.
Poscondiciones:
Costo irregular asignado al alumno.
Registrado en el historial de asignaciones de costos
irregulares.
RF12: Emitir nota de crédito

Descripción: Se utiliza para emitir nota de crédito por transferencias o
devoluciones. Para las devoluciones están sujetas a un descuento
porcentual por concepto de gastos administrativos. Para las
transferencias, estos importes se destinan al pago de otros conceptos
a favor del alumno, no hay descuentos por gastos administrativos.
Actor: Jefe de Cobranza
Precondiciones:
El comprobante de pago motivo de la nota de crédito debe
estar activo.
Debe existir el pago por derecho de solicitud de transferencia.
1. El usuario consulta el comprobante de
pago.
2. El sistema muestra información del
comprobante de pago:
Código
Nombres
Sede
Escuela
Fecha de emisión
Concepto
Importe
3. El usuario selecciona el tipo de transacción:
transferencia o devolución.
4. Si la transacción es devolución, el sistema El porcentaje de
calcula el descuento por gastos descuento esta
administrativos a partir del importe total del definido en los
comprobante de pago. parámetros de
configuración
del sistema
5. El sistema muestra el importe para generar
6. El usuario emite la nota de crédito.
Poscondiciones:
Nota de crédito emitida.
Nota de crédito registrada en el historial de notas de
crédito.

RF13: Emitir reporte de pagos por alumnos

Descripción: Se utiliza para emitir el reporte de ventas de alumnos, de
tasas mas importantes como admisión, matricula, pensiones, grados,
etc.
Precondiciones:
Sede
Escuela
Ámbito: semestre o rango de fechas.
Código
Nombres
Monto por tasas: por admisión, por
matriculas, por pensiones, etc.
Poscondiciones:
Ninguno.
RF14: Emitir informe de ingresos por convenios con otras

instituciones
Descripción: Se utiliza para emitir el reporte de ingresos efectuados
mediante depósitos por alumnos en filiales donde la Universidad
mantiene convenio.
Precondiciones:
Deben existir comprobantes de pago.
1. El usuario:
Selecciona sede
Selecciona escuela
Ámbito: selecciona semestre o ingresa
rango de fechas
Ingresa el porcentaje de cálculo
Código
Nombres
Comprobante de pago
Concepto
Importe
Número de operación
Fecha de operación
Total de ingresos
Poscondiciones
Ninguno

RF15: Consultar compromisos del alumno

Descripción: Se utiliza para mostrar los compromisos de pagos del
alumno con la Universidad.
Actor: Cajera, Jefe de Cobranzas, Analista de Ventas
Precondiciones:
Compromisos existentes del alumno.
2. El sistema muestra los compromisos del
alumno: concepto, importe, semestre, ciclo,
fecha de vencimiento, fecha de adelanto e
importe de adelanto.
Poscondiciones:
Ninguno
RF16: Generar fraccionamiento de deuda

Descripción: Se utiliza para realizar fraccionamientos de deudas. Por
lo regular los fraccionamientos se hacen durante el periodo de
matriculas.
Precondiciones:
El alumno debe tener deudas vencidas

2. El sistema muestra las deudas del alumno:
el semestre, fecha de vencimiento, el
concepto y el importe.
3. El usuario selecciona los compromisos a
fraccionar.
4. El sistema muestra el importe total a
fraccionar.
5. El usuario selecciona el semestre en el que
el alumno pagará el fraccionamiento.
6. El usuario ingresa el importe a amortizar y
el número de cuotas en las que
fraccionaran la deuda.
7. El sistema; según el semestre Si los
seleccionado, muestra los compromisos en compromisos en
los que se distribuirán las cuotas de el semestre de
fraccionamiento incluyendo la amortización. fraccionamiento
no existen, el
usuario debe
generarlos. Ir a
RF21
8. El sistema genera el nuevo cronograma de
pagos en el semestre de pago.
9. El usuario emite el acta de compromiso.
El acta incluye el nuevo cronograma de

pago.
Poscondiciones:
Emisión de acta de compromiso.
RF17: Registrar tasa

Descripción: Permite registrar o actualizar la plantilla de las tasas.
Precondiciones:
Ninguno
1. El usuario ingresa.
Código de tasa.
Descripción completa.
Descripción abreviada.
Costo.
2. El sistema registra la nueva tasa.
Poscondiciones:
Ninguno.
RF18: Anular comprobante de pago

Descripción: Permite anular comprobantes de pago por motivos de
errores de impresión o de usuario. Los documentos son anulados
inmediatamente después de la detección del error o antes de emitir la
liquidación del turno.
Actor: Cajera
Precondiciones:
Que el comprobante de pago este observado por error de
usuario o por impresión incorrecta.
1. El sistema muestra todos los documentos
del turno actual para el usuario.
2. El usuario selecciona el documento para
anular.
3. El sistema solicita confirmación para
realizar la anulación del documento.
4. El sistema anula el documento.
Poscondiciones:
Ninguno
RF19: Emitir reporte de ingresos por unidad recaudadora

Descripción: Permite reportar ingresos por unidad recaudadora en
una fecha especifica.

1. El usuario ingresa la fecha.

2. El usuario selecciona la unidad
recaudadora.
3. El sistema muestra las ventas realizadas,
incluye, comprobante de pago, tipo de
comprobante, importe y estado.
Poscondiciones:
Ninguno.
RF20: Emitir reporte consolidado de ventas

Descripción: Permite reportar las ventas diferenciados por sedes y
por cada modalidad (PRESENCIAL, SUA, POSTGRADO Y
VIRTUAL). Para el caso de las modalidades SUA, POSTGRADO y
VIRTUAL las ventas se depositan en forma separada en una misma
cuenta. Este proceso se realiza antes de efectuar los depósitos en el
banco.
Actor: Analista de Ventas, Cajera
Precondiciones:
Asiento contable del sub-diario ventas para esa fecha.
1. El usuario ingresa la fecha.
2. El sistema muestra el consolidado de los
ingresos por sede y modalidad, incluyendo
la sede, número de cuenta bancaria,
importe acumulado, la modalidad y el
registro contable (banco, mes y voucher).
3. El usuario verifica el consolidado de ventas
con las liquidaciones del día.
Poscondiciones:
Asiento contable sub-diario caja.
RF21: Mantenimiento de compromisos

Descripción: Permite agregar, eliminar y modificar los compromisos
del alumno. Agregar solo es permitido cuando el alumno no tiene
deudas de semestres anteriores o tiene deudas fraccionadas o
refinanciadas. En ella se generan los compromisos que deberá pagar
el alumno obligatoriamente.
Actor: Cajera
Precondición:
Para alumnos nuevos, debe existir el pago por derecho de
admisión.
Para el resto de alumnos, no debe tener deudas en semestres
anteriores y haber pagado la boleta de notas del semestre
anterior.


2. El sistema muestra los compromisos
pendientes de pago.
3. Si, el alumno tiene deudas pendientes de
pago, el caso de uso termina.
4. Caso contrario, el usuario selecciona el
semestre, el ciclo, el turno, ingresa el
numero de créditos, ingresa el número de
cursos por segunda matricula, por tercera o
por cuarta y créditos adicionales.
5. El sistema genera los compromisos con las Si no existen
fechas de vencimiento establecidas. Los fecha de
compromisos incluyen: matricula, el vencimiento, el
numero de pensiones con el costo de usuario debe
acuerdo al numero de créditos ingresar el
matriculados, y además incluye el cronograma de
compromiso por matricula de segunda, pagos para la
tercera o matricula por cuarta y los créditos escuela,
adicionales). semestre, ciclo
y turno
requerido. RF02
Poscondición:
Cuenta corriente creada.
RF22: Consultar kardex de pagos del alumno

Descripción: Permite mostrar el historial de pagos realizados por el
alumno.
Actor: Cajera, Jefe de Area.
Precondición:
Deben existir comprobantes de pagos emitidos para el
alumno.
2. El sistema muestra el kardex de pago del
alumno: semestre, número de comprobante de
pago, fecha de pago, ciclo, concepto, numero y
fecha de operación, importe y el tipo de
comprobante.
Poscondiciones:
Ninguno
RF23: Dar de alta a usuario

Descripción: Permite agregar a un usuario y habilitar el acceso al
sistema.
Actor: Administrador
Precondición:
Identificar el tipo de usuario.


1. El usuario ingresa el nombre de usuario.
2. El sistema verifica si ya existe un usuario con
ese nombre.
3. Si existe, el sistema pide que ingrese otro
nombre de usuario. Termina el caso de uso.
4. Caso contrario, el usuario ingresa sus apellidos
y nombres, selecciona la sede, selecciona el
nivel de acceso.
Poscondición:
Nuevo usuario creado.
RF24: Dar de baja a usuario

Descripción: Se usa para inhabilitar el acceso del usuario al sistema.
Precondición:
El usuario debe estar activo.
1. El sistema muestra todos los usuarios.
2. El usuario selecciona el usuario.
3. El usuario confirma la inhabilitación del
usuario.
4. Si confirma, el sistema inhabilita el
acceso al sistema.
5. Caso contrario, paso 6.
Poscondición:
Usuario dado de baja.
RF25: Establecer parámetros del sistema

Descripción: Se emplea para establecer parámetros de
funcionamiento interno del sistema. Por ejemplo formatos de fechas,
símbolo de moneda, tasas de compromisos, tasa de carné
universitario, tasa de matricula extemporánea, tasas de matriculas y
de pensiones, porcentajes de descuentos, frases de impresión, etc.
Precondición:
Ninguno.
1. El usuario establece los parámetros.
2. El sistema almacena los cambios.
Poscondición:
Ninguno.

RF26: Ingresar al sistema

Descripción: Se emplea para ingresar al sistema previa autenticación.
Precondición:
Debe haber usuarios registrados y activos.
1. El usuario proporciona datos de su
cuenta de usuario, introduce su nombre y
la clave de acceso.
2. El sistema, valida la cuenta. Si los datos no
son correctos, el
sistema avisa al
sistema que debe
ingresar
nuevamente los
datos.
3. Se repiten los pasos 1 y 2 hasta que la Si se cumplen el
cuenta sea valida. número de
intentos
establecidos, el
sistema bloquea
la cuenta.
4. El sistema permite el acceso y muestra
las opciones de acuerdo al nivel de
acceso.
Poscondición:
Usuario ingresado al sistema.
3.1.4.4. Requisitos no funcionales
3.1.4.4.1. Seguridad.
Confidenciabilidad.- La información no debe

estar asequible a nadie, excepto a usuarios
autorizados.
Disponibilidad.- A usuarios autorizados no se les
debe impedir el acceso a los datos. La seguridad
no dificultará o retrasará lo que necesitan
cuando lo necesitan.
Integridad.- Los datos que ofrece el sistema
deben ser los mismos que se han introducido
mediante las funciones de entrada de datos.

3.1.4.4.2. Usabilidad
El sistema deberá ser de fácil uso.

El sistema deberá tener el acceso a ayudas de
manera rápida y puntual.
El sistema deberá disponer de accesos directos
a las funciones más relevantes.
3.1.4.4.3. Rendimiento
El sistema deberá resolver consultas en tiempos

cortos.
El sistema deberá tener la capacidad de soportar
altos índices de transacciones en operaciones
de entrada de datos.
3.1.4.4.4. Mantenimiento
El sistema deberá permitir de manera sencilla la

dotación de nuevas funcionalidades.
Deberá contar con todas las herramientas
necesarias como manual de usuario, manual del
sistema, diccionario de datos, entre otros, que
permita facilitar su mantenimiento.
3.1.4.4.5. Entorno de desarrollo
Las herramientas empleadas para el desarrollo del

sistema no deberán ser propietarias. Se deberán
emplear herramientas gratuitas o libres.
El sistema debe estar desarrollado para funcionar
mediante la tecnología Web.
Las herramientas utilizadas no deberán ser versiones
testeadas o beta.

3.2. Análisis y Diseño
En esta fase se realiza el modelado del sistema de acuerdo a las

necesidades determinadas en la fase anterior; se emplean diagramas UML
estereotipadas para graficar los modelos.
3.2.1. Diseño conceptual
En esta parte se representa gráficamente el modelo conceptual

como visión estática que demuestre una colección de los elementos
estáticos del dominio. En esta parte no se hace análisis en cuestiones
de navegabilidad y de aspectos de interacción de la aplicación web,
esa parte se trata en el modelado de navegación.
Basándonos en la descripción textual y en los casos de uso

realizados en el análisis de requisitos del paso anterior, identificamos
los objetos, relaciones y operaciones necesarias para construir el
modelo conceptual del sistema. Diferenciamos tres vistas del
problema:
• La vista de compromisos: Representa el proceso que se va

a llevar a cabo sobre un compromiso de pago.
• La vista de ingresos: Representa el proceso que se va a
realizar a sobre un comprobante de pago.
• La vista de usuario: Representa las distintas formas de
acceso a la aplicación web que tienen cada usuario, ya sea
cajera, jefe de área o administrador.
A continuación, el modelo conceptual de la aplicación

representados mediante diagramas de clases UML.

Gráfico Nº 11: Vista de compromisos


Gráfico Nº 12: Vista de ingresos


Gráfico Nº 13: Vista de usuarios


3.2.2. Diseño navegacional
El modelado de la navegación, comprende la construcción de dos

modelos de navegación, es decir, el modelo de la navegación espacial y el
modelo de la estructura de navegación. El primero especifica qué objetos
pueden ser visitados por la navegación a través de la aplicación, es un
modelo en el análisis. El último define la forma en que estos objetos se
alcanzan, se trata de un modelo en el diseño.
La navegación están representada por los modelos estereotipados de

diagramas de clase.
Primeramente, se realiza un estudio para detectar interrelaciones entre

usuarios buscando propiedades comunes (acceso a funcionalidad común,
visibilidad de la misma información, etc.) creando una taxonomía de
usuarios que nos permitirá reutilizar especificaciones navegacionales.
De este modo se logró identificar que tanto el Jefe de Cobranzas como

el Analista de Ventas comparten roles y por tanto el mismo nivel de acceso,
por ello se cree conveniente unirlos en el usuario Jefe de Área. Por el modo
de acceso a las funcionalidades del sistema, se identifican tres usuarios:
Gráfico Nº 14: Usuarios del sistema

3.2.2.1. Modelo del espacio de navegación
El modelo del espacio navegacional se construye con las clases

de navegación y asociaciones entre las mismas y son
representadas por un diagrama de clase en UML.
Se usan dos elementos de modelado para la construcción del

modelo del espacio navegacional:

• Las clases de navegación: Es una clase cuyas instancias son

visitadas por los usuarios durante la navegación.
Los atributos derivados del modelo conceptual no son

incluidos en el modelo navegacional.
• La navegabilidad directa: Las asociaciones entre el espacio

navegacional representan la navegabilidad directa entre la
clase de navegación inicial y la clase de navegación final.
Para determinar las direcciones de la navegación usaremos

flechas, en la que se indica el rol y su multiplicidad. Si falta un
nombre por convenio se hace lo siguiente si la multiplicidad es
menor que uno o igual el nombre de la clase de destino se
usa como el nombre del rol; si es mayor que uno se usa el
plural del nombre de la clase destino.
Cada actor, Cajera, Jefe de Area, etc. tiene una vista diferente
del espacio de navegacion. Estas vistas se representan como un
modelo de clases UML construidos con las clases de navegación
y estereotipos de navegabilidad directa.
• Espacio de navegación del usuario Cajera.- Partiendo de la

página inicial (de autenticación), una cajera podrá registrar
ingresos, cuentas corrientes, cronogramas de pagos. Podrá
navegar por planes de costos, de pagos. Podrá anular
documentos solo en su turno activo.
• Espacio de navegación del usuario Jefe de Área.- Partiendo
de la página inicial, podrá revisar ingresos, cuentas
corrientes. Podrá ingresar costos, planes de costos,
cronogramas, fraccionamientos y resoluciones.
• Espacio de navegación del usuario Administrador.- Desde la
página inicial, el administrador solo podrá navegar por
usuarios y vistas de configuración del sistema.
En los siguientes gráficos se representan el espacio de

navegación y para cada usuario del sistema.

Gráfico Nº 15: Espacio de navegación del usuario Cajera


Gráfico Nº 16: Espacio de navegación del Jefe de Area


Escuela de Ingeniería de Sistemas
Sistema de Información de Cobranzas Web
Gráfico Nº 17: Espacio de navegación del usuario Administrador
107
ULADECH

3.2.2.2. Modelo de la estructura de navegación
El modelo de estructura de navegación explica la forma en

que se alcanzan cada objeto del sistema; los elementos de acceso
son los índices, consultas, menús y giras guiadas. Los estereotipos y
los iconos asociados son:
• Índices: Es un índice que permite el acceso directo a las

instancias de las clases navegacionales. Se modelan por un
objeto compuesto formado por un objeto, que qué tiene un
nombre que identifica cada instancia y posee un enlace a una
instancia de una clase de navegación. Se modelan en base a
los estereotipos UML.
• Vuelta Guiada: Proporciona el acceso secuencial a las
instancias de una clase de navegación. Estas deben ser
controladas por el usuario o por el sistema.
• Consultas: Se modelan mediante una clase con cadena de
consulta como un atributo. Esta puede ser por ejemplo una
operación de selección en OCL4.
• Menú: Es un índice de un conjunto de elementos, donde cada
elemento tiene un nombre y un enlace a las instancias de una
clase o a otros elementos de acceso, es decir, otro menú, una
consulta o un índice.
En el siguiente gráfico se aprecia como al modelo del espacio

navegacional, mediante índices, vueltas guiadas, consultas y menú
se construye el modelo de estructura de navegación.
4
OCL (Object Constraint Language, lenguaje de restricciones de objetos)

Gráfico Nº 18: Estructura de navegación


3.2.3. Diseño de presentación
El diseño de presentación soporta la construcción de un modelo de

presentación basado en el modelo de estructura de navegación y la
información adicional recogida durante el análisis de requisitos. El modelo
de la presentación plantea la construcción de bocetos de cada vista de
interfaz del usuario, es decir el plan de interfaces abstractas de usuario.
Para la construcción de los bocetos nosotros proponemos un conjunto

de elementos modelados algunos de los cuales son los siguientes:
• Vista de interfaz de usuario: Especifica que cada instancia de esta

clase es un contenedor de todos los elementos de interfaz de usuario
abstractos que se presentan simultáneamente al usuario.
• La clase presentación: Es una estructura única la cual permite la
división en vistas de interfaz de usuario, dentro de grupos de
elementos de interfaz de usuario.
• Elementos de interfaz de usuario: Es un una clase abstracta la cual
tiene elemento de interfaz de usuario describiendo los elementos
particulares de la interfaz. Los elementos que se pueden incluir en la
interfaz de usuario son: «text», «form», «button», «image», «audio»,
«anchor», «collection» y «anchored collection».
A continuación se ofrecen algunos de los bocetos de los principales

requisitos funcionales del sistema.

Gráfico Nº 19: Boceto Registrar comprobante pago


Gráfico Nº 20: Boceto Ingresar cronograma de pago


Gráfico Nº 21: Boceto Mantenimiento plan de costos


Gráfico Nº 22: Boceto Liquidación diaria


Gráfico Nº 23: Boceto Emitir reporte de pensiones por cobrar

Gráfico Nº 24: Boceto Consultar compromisos del alumno


Gráfico Nº 25: Boceto Fraccionamiento de deuda

Gráfico Nº 26: Boceto Anular comprobante pago


Gráfico Nº 27: Boceto Consultar kardex de pagos del Alumno
117
ULADECH

3.2.4. Diseño lógico de la base de datos
El análisis de los requisitos de almacenamiento y los modelos

propuestos anteriormente, nos ha permitido determinar las necesidades de
almacenamiento y de contenidos, detectando elementos de información
que podrían ser complementarios o posibles duplicaciones e
inconsistencias de información.
Para cada una de estas consideraciones fue necesario definir en

forma explicita el contenido, estructura, relaciones y las restricciones de
consistencia que deben regir para almacenar los datos.
En el gráfico 28, se plantea el modelo entidad-relación de la base

de datos, en el cual se han definido un conjunto de entidades y las
propiedades de cada una de estas, además de las interrelaciones
existentes.

Gráfico Nº 28: Modelo Entidad-Relación


3.3. Implementación
3.3.1. Implementación de la base de datos
En esta parte se plantean los aspectos referentes a la implementación

de la base de datos.
3.3.1.1. Objetivos y servicios de la base de datos
Flexibilidad e independencia.- Máxima independencia

posible entre datos y los procesos de usuarios para que
se pueda llevar a cabo todo tipo de cambios tecnológicos
y variaciones en la estructura de la base de datos, sin que
eso signifique la modificación de la aplicación ya
desarrollada ni cambiar la forma de escribir las consultas
(o actualizaciones) directas. De este modo, se pueden
hacer cambios de tecnología y cambios físicos para
mejorar el rendimiento sin afectar a nadie, este tipo de
independencia es lo que se denomina independencia
física de los datos.
Redundancia.- En lo posible se evitara la redundancia. En
principio, nos conviene hacer que un dato sólo figure una
vez en la base de datos. Sin embargo, esto no
necesariamente va a hacer así, por ejemplo, para
representar una interrelación entre las entidades alumno y
comprobante de pago se repetirá el atributo id_alumno
para que una haga referencia a la otra y poder obtener los
nombres del alumno.
Integridad de datos.- La base de datos deberán mantener
la calidad de los datos en cualquier circunstancia.
Sin embargo, se podría perder la corrección o la
consistencia de los datos por muchas otras razones:
errores de operación humana, avería de disco,
transacciones incompletas por corte de alimentación
eléctrica, etc.
Sin embargo para asegurar la integridad de datos
pondremos restricciones para asegurar que mediante la
aplicación y otras aplicaciones futuras las cumplan

cuando efectúen actualizaciones. Una parte de ello será

la integridad referencial existente entre entidades.
Del mismo modo se emplearán herramientas de
reconstrucción o restauración de los datos en caso estos
se estropeen, esta parte se trata con más detalle en la
sección Administración de la base de datos.
Concurrencia de usuarios.- El objetivo fundamental de
este proyecto es la centralización de la información por
ello la base de datos debe permitir que varios usuarios
puedan acceder concurrentemente a la misma base de
datos. Se empleará el concepto de transacciones para
asegurar que la ejecución de las instrucciones se hagan
correctamente ante cualquier eventualidad de interrupción
durante el proceso de ejecución.
Seguridad.- Los mecanismos de seguridad incluyen la
definición de autorizaciones o derechos de acceso
mediante diferentes niveles de acuerdo a los tipos de
usuarios identificados. Se crearán usuarios y contraseñas
de acceso para cada usuario que manejará el sistema.
3.3.1.2. Gestor de base de datos
Uno de los requisitos del proyecto es el uso de herramientas

libres o gratuitas, en ese sentido la ULADECH ha optado por usar
MySQL como gestor de base de datos.
Por ello, no hace el análisis de otras alternativas existentes

para seleccionar el gestor de base de datos a emplear en el
proyecto. Sin embargo podemos mencionar las características
principales del porque usamos MySQL como gestor de base de
datos.
Es un sistema de gestión de base de datos relacional,

multihilo y multiusuario.
Existen varias APIs que permiten, a aplicaciones escritas
en diversos lenguajes de programación, acceder a las
bases de datos MySQL Server.
Soporte a multiplataforma

Procedimientos almacenados
Soporte para SSL
Sub-SELECTs (o SELECTs anidados)
Uso de multihilos mediante hilos del kernel.
Soporta gran cantidad de datos. MySQL Server tiene
bases de datos de hasta 50 millones de registros.
Múltiples motores de almacenamiento (MyISAM, Merge,
InnoDB, BDB, Memory/heap, MySQL Cluster, Federated,
Archive, CSV, Blackhole y Example en 5.x
Altas velocidades en lectura de datos.
Es Open Source. El código fuente de MySQL Server se
puede descargar y está accesible a cualquiera, por otra
parte, usa la licencia GPL para aplicaciones no
comerciales.
3.3.1.3. Estructura de la base de datos
El nombre definido para la base de datos es cobranza.
3.3.1.3.1. Convenciones de estructura de la base de datos
Tanto para la estructura de la base de datos como para

los datos propiamente, existen una serie de reglas que se han
considerado, los mismos que deberían tomarse en cuenta en las
futuras ampliaciones, entre ellos:
Nombres de objetos.- Todos los nombres de las tablas y

de los campos deben estar escritos en minúsculas y sin
espacios en blanco.
Longitud de campos.- En lo posible, los tamaños de los
campos tipo cadenas de longitud exacta se han empleado
el tipo de datos CHAR.
De los Datos.- Todos los datos que signifiquen nombres
propios, pronombres o sustantivos se almacenarán en
mayúsculas y sin letras acentuadas.
Indexación de tablas.- Para las tablas más importantes se
han creado índices de los campos más significativos. Esto
permitirá mejorar de manera considerable los tiempos de
respuesta en las transacciones de consultas.

Las reglas que se han definido anteriormente permitirán

mejorar el desempeño de la base de datos; sin embargo a estas
existentes pueden agregarse otras según las necesidades en
ampliaciones futuras.
3.3.1.3.2. Descripción de tablas
En la tabla 54, se puede apreciar la descripción de cada

una de las tablas de la base de datos cobranza.
Tabla Descripción
alumno Almacena los datos personales de los
alumnos. El campo único de
identificación es el código del alumno.
alumno_categoria Almacena el historial de las categorías
asignadas a los alumnos.
alumno_escuela Almacena los datos referentes a las
escuelas en las que esta inscrito el
alumno. Todas las dependencias
académicas tienen el tratamiento como
escuelas, por ejemplo un alumno esta
matriculado en la escuela de Derecho
pero al mismo tiempo puede estar
llevando la especialización de
complementación académica en la
modalidad SUA.
caja Almacena los datos de todas las
unidades recaudadoras existente en la
Universidad. Cada una de ellas esta
identificada mediante el campo id_caja.
comprobante_pago Almacena todos los comprobantes
emitidos por conceptos de pagos
efectuados por los alumnos y clientes
externos. Existen dos tipos de
comprobantes: Boleta de Venta y
Factura.

Todas las consultas de ingresos se

obtienen desde esta única tabla; desde
liquidaciones hasta informes
estadísticos de ingresos.
compromiso Esta tabla almacena los datos de los
compromisos de pagos establecidos
entre el alumno y la universidad. Existen
compromisos obligatorios como
matriculas y pensiones; sin embargo
aquí también se almacenan todos los
compromisos de pago del alumno.
config_system Almacena los datos de configuración
para el funcionamiento del sistema,
como caracteres predeterminados para
las categorías, turnos de asistencia,
costos de descuentos, etc. Esto permite
tener separado una configuración para
cada filial.
correlativo Almacena los correlativos de los
comprobantes de pago por cada
usuario. Esto indica que a cada usuario
se le asigna un numero de serie; sin
embargo esto no significa que una serie
esta relacionada únicamente a un
usuario; varios usuarios pueden usar la
misma serie aunque no en la misma
fecha y turno.
cronograma _pago Almacena los datos referentes a los
cronogramas de pago para cada
escuela. Aquí se determinan que
compromisos son obligatorios para los
alumnos, por ejemplo para la mayoría
de las escuelas es obligatorio, matricula
y pensiones.
escuela Almacena los datos de todas las

carreras profesionales ofrecidas por la

Universidad.
filial Almacena los datos de filiales de la
universidad. Es preciso decir que una
filial es distinta de una sede; un conjunto
de sedes pueden pertenecer a una filial;
por ejemplo en la filial de Huaraz se
tiene identificado, Huaraz y Sihuas
como dos sedes distintas.
fraccionamiento_cab Almacena el historial de
fraccionamientos otorgados a los
alumnos.
fraccionamiento_detalle Almacena el historial de
fraccionamientos al detalle de otorgados
a los alumnos.
historial_constancia Almacena el historial de las constancias
de no adeudo emitidas.
historial_nota_credito Almacena el historial de las notas de
créditos emitidas.
historial_resolucion Almacena el historial de las
resoluciones emitidas.
maestro_categoria Almacena la plantilla de categorías para
la especificación de costos. Inicialmente
se identificaron las categorías A, B, C,
D, E.
maestro_estado Almacena los estados que se
manejarán en el sistema.
maestro_grupo_tasa Almacena la agrupación de tasas. La
agrupación de tasas permite separar las
tasas que cumplen ciertas
características comunes; por ejemplo
existen dos tipos de tasas para
pensiones: pensiones pre-grado y
pensiones post-grado.
maestro_modalidad Almacena las modalidades de

enseñanza ofrecidas por la Universidad.

maestro_resolucion_tipo Almacena los diferentes tipos de
resoluciones o documentos que
sustentan cambios en los costos de las
pensiones de los alumnos.
maestro_semestre Almacena los semestres académicos.
maestro_tasa Almacena la plantilla general de tasas.
maestro_tasa_escuela Almacena la plantilla de tasas por
escuela. Esto permite tener tasas con
costos distintos por cada escuela.
maestro_turno_alumno Almacena los turnos de asistencia a
clases de los alumnos.
maestro_turno_cajas Almacena los turnos de liquidación.
maestro_usuario_tipo Almacena los diferentes tipos de
usuarios en el sistema. Esto permite
clasificar a los usuarios y restringir el
acceso a algunas funcionalidades del
sistema.
plan_costo Almacena los costos de matriculas y
pensiones así como el número de
cuotas por semestres de cada escuela.
Los alumnos empiezan pagando según
un plan y esto se mantiene durante toda
su permanencia en la universidad. Si un
alumno empezó pagando 190.00 de
pensión y posteriormente las pensiones
suben a 120.00, este nuevo plan solo
afecta a los nuevos alumnos más los
anteriores conservan el plan con el que
empezaron.
planes Almacena los diferentes planes de pago
aperturados por las escuelas. Cada vez
que el costo regular de las pensiones
varía implica la creación de un nuevo
plan.

Sede Almacena todas las sedes de la

Universidad.
usuarios Almacena los usuarios del sistema.
Tabla Nº 54: Descripción de tablas de la base de datos

3.3.1.3.3. Estructura de tablas
Gráfico Nº 29: Estructura de la tabla alumnos


Gráfico Nº 30: Estructura de la tabla alumno_categoria

Gráfico Nº 31: Estructura de la tabla alumno_escuela


Gráfico Nº 32: Estructura de la tabla caja

Gráfico Nº 33: Estructura de la tabla compromiso


Gráfico Nº 34: Estructura de la tabla comprobante_pago


Gráfico Nº 35: Estructura de la tabla config_system

Gráfico Nº 36: Estructura de la tabla correlativo


Gráfico Nº 37: Estructura de la tabla cronograma_pagos

Gráfico Nº 38: Estructura de la tabla escuela


Gráfico Nº 39: Estructura de la tabla filial

Gráfico Nº 40: Estructura de la tabla fraccionamiento_cab


Gráfico Nº 41: Estructura de la tabla fraccionamiento_detalle

Gráfico Nº 42: Estructura de la tabla historial_constancia


Gráfico Nº 43: Estructura de la tabla historial_nota_credito

Gráfico Nº 44: Estructura de la tabla historial_resolucion

Gráfico Nº 45: Estructura de la tabla maestro_categoria


Gráfico Nº 46: Estructura de la tabla maestro_estado

Gráfico Nº 47: Estructura de la tabla maestro_grupo_tasa

Gráfico Nº 48: Estructura de la tabla maestro_modalidad

Gráfico Nº 49: Estructura de la tabla maestro_modalidad_pension


Gráfico Nº 50: Estructura de la tabla maestro_resolucion_tipo

Gráfico Nº 51: Estructura de la tabla maestro_semestre

Gráfico Nº 52: Estructura de la tabla maestro_tasa


Gráfico Nº 53: Estructura de la tabla maestro_tasa_escuela

Gráfico Nº 54: Estructura de la tabla maestro_turno_alumno

Gráfico Nº 55: Estructura de la tabla maestro_turno_cajas


Gráfico Nº 56: Estructura de la tabla maestro_usuario_tipo

Gráfico Nº 57: Estructura de la tabla plan_costo

Gráfico Nº 58: Estructura de la tabla planes


Gráfico Nº 59: Estructura de la tabla sede

Gráfico Nº 60: Estructura de la tabla usuarios


3.3.2. Implementación de la interfaz de usuario
El análisis de los diferentes requisitos y los modelos definidos en las

dos primeras etapas de la metodología, nos ha permitido desarrollar los
prototipos de bosquejos, los mismos que se han sido sometidos a
procesos de validación con los usuarios tratando de determinar la interfaz
del sistema.
A partir de estos resultados se empezó a desarrollar la interfaz de

usuario considerando los requerimientos funcionales y no funcionales
especificados en la primera fase de la metodología de desarrollo.
Para construir la aplicación web se ha empleado el lenguaje de

programación PHP; se han empleado tecnologías web como javascript y
hojas de estilo (css); así mismo hemos utilizado la técnica de
programación XAJAX la cual nos ha permitido reducir las recargas de las
páginas sustancialmente.
3.3.2.1. Características de diseño
Estándares internacionales.- Además de las buenas

prácticas basadas en la experiencia, se ha considerado
los estándares propuestos por la Word Wide Web
Consortium (http://www.w3c.org/) que se encarga de velar
por las mejoras en la tecnología web.
Patrón de diseño.- Se ha empleado un patrón estándar
para escribir cada página, desde el tipo de letra, tamaños
y formatos para cada sección de las páginas y se ha
empleado la paleta de colores estándar que identifica a la
institución.
Accesibilidad.- En cada página de interacción con el
usuario se han incluido accesos directos a las principales
funcionalidades del sistema.
Tiempos de recarga.- El uso de la técnica XAJAX nos ha
permitido reducir en gran manera la recarga de páginas.
Ventanas múltiples.- Las ventanas múltiples (ventanas
pop up) permite al usuario mayor libertad para acceder a
las funcionalidades del sistema y facilitar por ejemplo
comparaciones de resultados en pantalla.

Peso de las páginas.- En lo posible se ha optimizado el

tamaño de las páginas para acelerar la carga de las
mismas.
Browser.- Las páginas deben ser ejecutas con normalidad
tanto en Mozilla FireFox e Internet Explorer que son los
exploradores en los cuales se ha testeado la aplicación
web.
Imágenes.- Se ha evitado en lo posible utilizar imágenes
para reducir el tiempo de carga de las páginas.
Uso de Frames.- No se emplean frames.
Multimedia.- No se emplea objetos multimedia.
3.3.2.2. Pantallas
A partir de los bosquejos se han desarrollado las pantallas de

usuario tomando en cuenta las condiciones establecidas en el punto
anterior; a continuación se incluyen las principales pantallas del
sistema.
Gráfico Nº 61: Pantalla inicio de sesión


Gráfico Nº 62: Pantalla principal

Gráfico Nº 63: Pantalla Registrar comprobante de pago


Gráfico Nº 64: Pantalla Ingresar cronograma de pagos

Gráfico Nº 65: Pantalla Mantenimiento plan de costos


Gráfico Nº 66: Pantalla Liquidación diaria


Gráfico Nº 67: Pantalla Pensiones por cobrar


Gráfico Nº 68: Pantalla Consular compromisos del alumno

Gráfico Nº 69: Pantalla Anular comprobante pago


Gráfico Nº 70: Pantalla Generar fraccionamiento de deuda


Gráfico Nº 71: Pantalla Consultar kardex de pagos del alumno
149
ULADECH

3.3.3. Implementación de la arquitectura
La implementación de la arquitectura abarca los aspectos

relacionados con la identificación y la manera como están relacionados los
componentes necesarios para poner en marcha el proyecto; solo se
realiza una descripción general de estos componentes, bajo ningún
concepto se plantean estudios minuciosos para no extender más allá de lo
necesario el proyecto.
El primer paso en el desarrollo de la arquitectura es preparar un

escenario de implementación. En este caso el escenario de
implementación está formado por:
La arquitectura lógica, que identifica los componentes lógicos

necesarios para implementar el proyecto.
La arquitectura física, que identifica los componentes físicos
necesarios para implementar el proyecto.
3.3.3.1. Arquitectura lógica
Gráfico Nº 72: Arquitectura lógica del sistema

Los componentes del gráfico 72, están incluidos por las

siguientes razones:

En la capa de presentación, se muestra el sistema al

usuario, le comunica la información y captura la
información del usuario dando un mínimo de proceso
(realiza un filtrado previo para comprobar que no hay
errores de formato). Esta capa se comunica únicamente
con la capa de negocio. Aquí se ejecuta el explorador
web.
En la capa dos, la de negocio es donde estará instalado
la aplicación, se reciben las peticiones del usuario y se
envían las respuestas tras el proceso. Es aquí donde se
establecen todas las reglas que deben cumplirse. Esta
capa se comunica con la capa de presentación, para
recibir las solicitudes y presentar los resultados, y con la
capa de datos, para solicitar al gestor de base de datos
para almacenar o recuperar datos de él.
Aquí se aloja el servidor web y el interprete PHP.
En la capa de datos, es donde residen los datos. Está
formada por el gestor de bases de datos MySQL, recibe
solicitudes de almacenamiento o recuperación de
información desde la capa de negocio.
Las características de los componentes son las siguientes:
Clientes del La aplicación ha sido testeada tanto en

Explorador Internet Explorer 6.0 y Mozilla FireFox 2.0 por
Web lo que se recomienda usar cualquiera de
estos exploradores.
HTTP La versión instalada del HTTP Apache Server

Apache es la 2.2.2 instalado en el servidor web bajo
Server la plataforma Linux (Sistema Operativo
Fedora Core 6)
PHP La versión instalada del PHP es la versión 5.
Aplicación La aplicación esta desarrollada con el

Web lenguaje de programación PHP, así mismo
se han empleado tecnologías como

JavaScript, Hojas de estilos y XAJAX.
MySQL El servidor de base de datos, tiene instalado

Server la versión 5.0 bajo la plataforma Linux (
Sistema Operativo Fedora Core 6)
3.3.3.2. Arquitectura física
Se realiza una descripción de los componentes hardware

necesario para poner en marcha el proyecto.
La institución ya cuenta con los equipos servidores instalados

por lo que se usará estos recursos para instalar el proyecto.
Servidores.- Los servidores implementados tienen las

siguientes características:
Procesador Intel® Xeon® 5150

Dual-Core a 3,0 GHz 2,66 GHz, 8
MB (1 x 4 MB) de caché de nivel 2,
Servidor Web, Servidor
HP Proliant DL380 G5 Bus frontal a 1333 MHz, 2 GB
(ampliable a 4 GB) de memoria
RAM, Controlador HP Smart Array
P400/512 MB con caché de
escritura respaldada por batería
(RAID 0/1/1+0/5/6), Dos
adaptadores de servidor Gigabit
multifunción NC373i integrados
con TCP/IP Offload Engine.
Procesador Intel® Xeon® 5150

Dual-Core a 3,0 GHz 2,66 GHz, 8
MB (1 x 4 MB) de caché de nivel 2,
Servidor de Base de
Bus frontal a 1333 MHz, 2 GB
Datos, Servidor HP
(ampliable a 4 GB) de memoria
Proliant DL380 G5
RAM, Controlador HP Smart Array
P400/512 MB con caché de
escritura respaldada por batería
(RAID 0/1/1+0/5/6), Dos

adaptadores de servidor Gigabit

multifunción NC373i integrados
con TCP/IP Offload Engine.
Equipos clientes.- Los clientes cuentan con equipos

compatibles y básicamente con las siguientes especificaciones.
Placa Intel o msi segun modelo

tecnología, microprocesador Intel Pentium
D2 1.8 Ghz, Memoria 1 Gb. DDR RAM,
Dsco Duro SATA 80 Gb, Grabadora de
Equipos clientes CD-RW LG, tarjeta de red inalámbrica D-

Link.
Líneas de Internet.- La central cuenta con 1 línea dedica de

1024Kbs, empleada para la salida a Internet por el Servidor Web.
Las sedes cuentan con las siguientes líneas de Internet:
Sede Línea de conexión a Internet

CHIMBOTE Speedy Business 2000 (2048/512Kbps) al 10%
TRUJILLO Speedy 900 Business (900Kps) al 10%
HUARAZ Speedy Business 2000 (2048/512Kbps) al 10%
PIURA Speedy Business 2000 (2048/512Kbps) al 30%
SULLANA Speedy Business 2000 (2048/512Kbps) al 10%
TALARA Speedy 400 Convencional (400Kbps) al 10%
CASMA Speedy 600 Convencional (600Kbps) al 10%
HUARMEY Speedy 1200 Convencional (2048/512Kbps) al
10%
Tabla Nº 55: Líneas de conexión a Internet


En el siguiente gráfico se puede apreciar el esquema de

conexión entre la sede principal y las filiales.
Gráfico Nº 73: Esquema de conexión de las filiales


Capitulo IV
DISCUSION DEL PROYECTO
A lo largo del presente proyecto se han empleado una serie de tareas para
desarrollar cada una de las etapas que plantea la metodología UWE.
En esta parte se trata de demostrar la hipótesis planteada como respuesta

tentativa a esta investigación.
4.1. Contrastación de hipótesis
El análisis y contrastación de la variable independiente y la variable

dependiente nos permitirá determinar la veracidad o falsedad de la hipótesis.
• Planteamiento de la hipótesis
El Sistema de Información de Cobranzas Web, permitirá mejorar la
gestión administrativa en el Departamento de Cobranzas de la
Universidad los Angeles de Chimbote.
• Variable Independiente
• Variable Dependiente
La gestión administrativa en el Departamento de Cobranzas
• Variable Interviniente
Metodología de desarrollo UWE (UML - Web Engineering)
4.1.1. Población
La población objeto de estudio esta conformada por un total de

12 personas que laboran en las áreas afectadas.
4.1.2. Muestra
Se toma como muestra de estudio la población total debido a

que ésta es pequeña. Se plantearon 8 preguntas (P1-P8) de las
cuales se han obtenido los siguientes resultados.
Ponderación
Muy bueno (si) 3
Bueno 2
Regular
(regular) 1
Malo 0
Tabla Nº 56: Factores de ponderación de la muestra

User P1 P2 P3 P4 P5 P6 P7 P8 TOTAL
1 2 0 1 2 1 1 1 3 11
2 2 1 2 1 0 1 1 3 11
3 0 0 1 2 1 2 2 3 11
4 0 1 2 2 1 1 1 3 11
5 2 0 2 1 2 2 1 3 13
6 0 1 2 2 1 2 2 3 13
7 2 0 1 1 2 2 1 3 12
8 2 1 2 0 1 1 2 3 12
9 2 1 1 1 2 2 1 3 13
10 2 2 2 2 1 2 2 3 16
11 0 1 1 2 2 2 2 3 13
12 2 0 2 1 2 2 2 3 14
12.5
Tabla Nº 57: Resultado de aceptación de usuario del sistema anterior

User P1 P2 P3 P4 P5 P6 P7 P8 TOTAL
1 2 1 2 1 2 2 2 3 15
2 2 2 2 1 2 1 3 2 15
3 2 1 2 2 2 2 2 2 15
4 2 2 2 2 2 2 3 2 17
5 2 1 2 2 2 2 2 2 15
6 2 2 2 2 3 2 2 2 17
7 3 1 2 3 2 2 3 2 18
8 2 2 3 2 2 2 2 2 17
9 2 2 2 1 2 2 2 3 16
10 2 1 2 2 2 2 3 2 16
11 2 2 3 2 2 2 3 2 18
12 2 1 2 1 2 1 3 3 15
16.167
Tabla Nº 58: Resultado de aceptación de usuario del sistema actual

Se presentan los datos y se trata de demostrar estadísticamente la

hipótesis de investigación relativa a “EL SISTEMA DE COBRANZAS
WEB MEJORARA LA GESTIÓN EN EL DEPARTAMENTO DE
COBRANZAS”. Consecuentemente, con la información estadística
obtenida a partir de los cuestionarios aplicados a todo el personal del
Departamento de Cobranzas, se demuestra la hipótesis planteada al
inicio de la presente tesis como respuesta tentativa a esta investigación
si será aceptada o rechazada.
El cuestionario consta de 8 preguntas cerradas, estas mismas

preguntas fueron realizadas a todo el personal de dicho departamento

antes de la implementación del sistema web, y luego estas mismas

preguntas se realizaron después de la implementación del nuevo
sistema, obteniendo así los siguientes resultados.
CUADRO COMPARATIVO DEL NIVEL DE ACEPTACION DEL USUARIO

Sistema Anteriorl Vs. Nuevo Sistema Web
80
70
60
50
40
30
20
10
0
Muy bueno (si) Bueno Regular Malo
(regular)
Sistema Anterior Nuevo sistema
Gráfico Nº 74: Cuadro comparativo del nivel de aceptación de los usuarios

4.1.3. Validación de contrastación de hipótesis
Para evaluar los resultados obtenidos en ambas encuestas, se

utilizo el diseño de investigación pre – experimental al total de la
población antes y después, usando un test comparativo como es la
prueba t Student.
La prueba de t Student, es un método de análisis estadístico, que

compara las medias de dos categorías dentro de una variable
dependiente sin tener en cuenta que la muestra sea grande o pequeña.
Es una prueba paramétrica, o sea que solo sirve para comparar
variables numéricas de distribución normal.
Los resultados de los cuestionarios fueron analizados

estadísticamente con el propósito de medir el impacto de la variable
independiente sobre la variable dependiente en grado de aceptabilidad o
negatividad, teniendo como indicador el nivel de satisfacción del usuario.

La presente evaluación de la hipótesis esta basada en el

siguiente diseño estadístico.
La presente evaluación de la hipótesis esta basada en el

siguiente diseño estadístico.
• Población: Personal de cobranzas incluyendo el jefe del

departamento
• Muestra : La mismas personas que forman la población
En total fueron encuestadas 12 personas responsables de área

de caja, quienes conforman la muestra para realizar el planteamiento
estadístico.
Teniendo como planteamiento la siguiente hipótesis estadística:

Ho: µ1=µ2 La implementación del sistema de información de
cobranzas no permitirá mejorar la gestión dentro del
Ho: µ1>µ2 La implementación del sistema de información de
cobranzas permitirá mejorar la gestión dentro del
A un nivel de significancia:
α = 0.05
Por lo tanto estadísticamente el nivel de confianza es:
1 – α = 1- 0.05 = 0.95
Considerando estos resultados se realiza el cálculo de la prueba

de hipótesis.
Desviación estándar conjunta (S)
n1 = muestra primera encuesta.
n2 = muestra segunda encuesta.
S1= desviacion standar primera encuesta.
S2= desvicion standar segunda encuesta.
S2 = ((n1 - 1)* S12 ) + ((n2 + 1)* S22 )

n1 + n2 - 2
Sp2 = (12-1)2.27273 + (12-1)1.4242

12+12-2

Sp2 = 1.8485
Sp = 1.3596
Utilizando la Estadística T – Student
Tc = (x2 – x1) - µ tn-1

S .
√12
Donde:
• X1 = Promedio de la primera encuesta.
• X2 = Promedio de la segunda encuesta.
• µ = Media de la población muestral.
Tc = (16.167 – 12.5) – (0)

1.84848
3.4641
Tc = (16.167 – 12.5)-(0)
0.5336
Tc = 3.667
0.5336
Tc = 6.8722
Hallando los grados de libertad (gl) en la siguiente formula:
gl = (n1 + n2) - 2 = 12 + 12 - 2 => gl = 22
Estos grados de libertad permitirán comparar el valor de “t” con

respecto al valor que le corresponde en su tabla. Si el valor calculado de
Tc es mayor que el valor de la tabla se acepta la hipótesis de
investigación.
Para α = 0.05 (nivel de significancia), la región de rechazo para

Ho consiste en todos aquellos valores de tn-1 menores que -1.72 y
mayores que 1.72, se encuentra en la región de rechazo de H0, donde
podemos observar que el valor de Tc esta dentro del área de rechazo
para la hipótesis H0:µ1=µ2 y se acepta H1:µ1 > µ2 descartándose así la
hipótesis Nula y aceptando la hipótesis alterna.

4.2. Verificación de la calidad del software
Calidad en
Uso
Eficacia Productividad Satisfacción Seguridad
Gráfico Nº 75: Factores de calidad de software

• Eficacia: La capacidad del producto de software para permitir a los

usuarios lograr las metas especificadas con exactitud e integridad.
• Productividad: La capacidad del producto de software para permitir a los
usuarios emplear cantidades apropiadas de recursos, en relación a la
eficacia lograda en un contexto especificado de uso.
Los recursos relevantes pueden incluir: tiempo para completar la tarea,
esfuerzo del usuario, materiales o costo financiero.
• Satisfacción: La capacidad del producto de software para satisfacer a los
usuarios. La satisfacción es la respuesta del usuario a la interacción con
el producto, e incluye las actitudes hacia el uso del producto.
• Seguridad: La capacidad del producto de software para lograr niveles
aceptables de riesgo de daño a las personas, institución, software, en un
contexto especificado de uso.
Los riesgos son normalmente el resultado de deficiencias en la
funcionalidad (incluyendo seguridad), fiabilidad, usabilidad o facilidad de
mantenimiento.
Se consideran las siguientes métricas para evaluar la calidad del software:
• Facilidad de Auditoria: La facilidad con la que se puede comprobar la

conformidad con los estándares.
• Exactitud. La presión de los cálculos y control.
• Normalización de las comunicaciones: Es el grado con la que se usa el
ancho de banda.
• Consistencia: Es el uso de un diseño uniforme y de técnicas de
documentación a lo largo del proyecto de desarrollo de software.

• Concesión: Lo compacto que es el programa en términos de líneas de

código.
• Estandarización de los datos: El uso de estructura de datos y de tipos a
lo largo del programa.
• Tolerancia de errores: El daño que produce cuando el programa
encuentra errores.
• Eficiencia de ejecución: El rendimiento del tiempo de ejecución de un
programa.
• Generalidad: La amplitud de aplicación potencial en los programas.
• Independencia de hardware: El grado en que el software es
Independiente del hardware.
• Modularidad: La independencia funcional de los componentes del
programa.
• Facilidad de operaciones: La facilidad de operar el programa.
• Seguridad: Mecanismos de seguridad que protejan los datos.
• Auto documentación: Es el grado con el que puede ser entendido el
código fuente sin dificultad.
• Formación. Es el grado en que el software ayuda para permitir que
nuevos usuarios apliquen el sistema.
Los factores de ponderación:
Descripción Factor
Malo 1-5
Regular 6-7
Bueno 8 - 10
Tabla Nº 59: Factor de ponderación - Calidad de software

Plantilla de de ponderación:
Malo 15 * 5 75
Regular 15 * 7 105
Bueno 15 * 10 150
Tabla Nº 60: Plantilla de ponderación – Calidad de software


A continuación el cuadro de resultados:
Métricas de de calidad del Ponderación

software
Facilidad de Auditoria 8
Exactitud 10
Normalización de las 7
Comunicaciones
Consistencia 9
Concesión 8
Estandarización de los datos 10
Tolerancia de errores 7
Eficiencia de ejecución. 8
Generalidad 9
Independencia. de hardware 10
Modularidad 8
Facilidad de operaciones 10
Seguridad 10
Auto documentación 10
Formación 10
Total 134
Tabla Nº 61: Ponderación de métricas – Calidad de software

Mediante la tabla 62, realizamos la sumatoria de la ponderación y

encontramos que en este caso particular la calidad del sistema es buena.
Total = 134 / 15 = 8.93
Se considera la calidad del software en función a la sumatoria total por cada

factor de la ponderación.
Bueno 15 * 11.16 133.95

Capitulo V
CONCLUSIONES Y
RECOMENDACIONES
5.1. Conclusiones
En este documento se describen cada una de las actividades que se han

realizado para desarrollar la tesis, se lograron identificar los problemas que se
presentaban; así mismo se especifican las necesidades que debería contemplar
el nuevo sistema para dar solución a la problemática planteada.
El sistema propuesto reúne las características técnicas, filosóficas y

económicas impuestas por la institución. El Sistema de información que se ha
desarrollado esta basado en tecnología web, como metodología de desarrollo
se utilizo UWE y teniendo como herramientas aquellas que están orientadas al
uso del software libre.
Al inicio se plantearon una serie de objetivos que deberían cumplirse al

finalizar el proyecto, los mismos que podemos concluir en lo siguiente:
1. Mejorar los procesos de seguimiento y control de los ingresos en las

unidades recaudadoras de la institución.
El sistema facilita el control y seguimiento de los ingresos, dentro de
sus funcionalidades ofrece informes preparados para visualizar la
información en tiempo real, permitiendo a los usuarios tomar
decisiones rápidamente.
2. Mejorar la planificación y ejecución de los procesos de control para la
reducción en los índices de morosidad.
Con la implementación del proyecto, se tiene centralización de datos
y esto le permite al Departamento de Cobranzas planificar y controlar
los índices de morosidad por cada sede académica, esto no se
contaba con el sistema anterior y para realizarlo se debía coordinar
con las sedes académicas retrazando el tiempo.
3. Centralizar la información de los ingresos de las filiales de la
institución en la sede principal.
El sistema centraliza la información de todas las unidades
recaudadoras en una misma base de datos, se emplea el gestor de
base de datos MySQL Server por ser una herramienta libre, de buen
rendimiento y veloz en los tiempos de respuestas. Y lo mas
importante, la institución cuenta con servidores instalados y
configurados con esta tecnología.

4. Mejorar el servicio de consultas en línea sobre estados de cuentas,

fechas de vencimientos, plan de costos y otra información relevante
para los alumnos.
La implementación del proyecto cuenta con una base de datos
centralizada esto permitirá realizar consultas en línea sobre los
estados de cuenta de todos los alumnos a nivel nacional.
5. Apoyar los procesos de auto evaluación institucional a través de la
generación de reportes estadísticos.
En el sistema propuesto se han considerado mejoras considerables
en la disponibilidad de la información de tal manera que estos
puedan incrementar los procesos de auto evaluación de la situación
financiera de la institución.
6. Facilitar el desempeño de otras soluciones gerenciales y estratégicas
de la institución.
Con la implementación del proyecto se ha mejorado la integración
con otras soluciones, se podrá emitir reporte de los estados
financieros actuales de la universidad y en tiempo real, ya sea
globalizado o segmentado por cada sede o filial de tal manera que
mejora la toma de decisiones.
5.2. Recomendaciones
Ante el constante crecimiento de la institución, será necesario agregar

nuevas funcionalidades, o incluso módulos adicionales en el sistema de
cobranzas, por ello se recomienda emplear tecnologías mas recientes para
estar acorde con los cambios venideros.
En este proyecto se utiliza la metodología de desarrollo UWE; una

metodología que contempla una serie de tareas ideales para este tipo de
proyectos; por ello se recomienda emplear esta metodología para futuros
proyectos web dentro de la institución.
Ante la inestabilidad de las líneas de internet convencionales en nuestro

medio, se recomienda migrar a líneas dedicadas lo suficiente como para reducir
las constantes caídas de conexiones a internet; sin embargo esto amerita un
estudio de factibilidad para determinar el costo/beneficio de las inversiones que
esto demandaría.

VI. REFERENCIAS BIBLIOGRAFICAS
URL01 Comunidad andina. José A. Gómez Hernández

http://gti1.edu.um.es:8080/jgomez/bibgen/intranet/03gestiona.
pdf
URL02 Sistemas y redes de bibliotecas públicas en España

http://www.fundaciongsr.es/bp/bp03.htm
URL03 Portal: Wikipedia, Sistema de Información

http://es.wikipedia.org/wiki/Sistema_de_informaci%C3%B3n
URL04 Portal: Monografías, Sistemas de Información

http://www.monografias.com/trabajos7/sisinf/sisinf.shtml
URL05 Universidad de Murcia – Apuntes: Ingeniería del Software

http://www.um.es/docencia/barzana/IAGP/Iagp2.html
URL06 About The World Wide Web

http://www.w3.org/WWW/
URL07 WorldWideWeb: Proposal for a HiperText Project

http://www.w3.org/Proposal.html
URL08 Portal: Wikipedia, Servidor Web

http://es.wikipedia.org/wiki/Servidor_web
URL09 Portal: Wikipedia, Aplicación Web

http://es.wikipedia.org/wiki/Aplicacion_web
URL10 Portal: Wikipedia, Servidor HTTP Apache

http://es.wikipedia.org/wiki/Servidor_HTTP_Apache
URL11 Portal: Object Management - UML

http://www.uml.org/
URL12 Portal: The Web Engineering community site

http://www.webengineering.org/
URL13 Portal: Wikipedia, Cliente–Servidor

http://es.wikipedia.org/wiki/Cliente-servidor
URL14 Portal: Wikipedia, Internet

http://es.wikipedia.org/wiki/Internet
URL15 Portal: Wikipedia, Navegador Web

http://es.wikipedia.org/wiki/Navegador

URL16 Portal: Wikipedia, Sistema Operativo Linux

http://es.wikipedia.org/wiki/Linux
URL17 Portal: Wikipedia, MySQL

http://es.wikipedia.org/wiki/Mysql
URL18 Portal: PHP Hipertext Preprocessor

http://www.php.net/
URL19 Portal: XAXAJ PHP library

http://xajaxproject.org/
URL20 Portal: Project UWE

http://www.pst.ifi.lmu.de/projekte/uwe/

VII. GLOSARIO
Acta de compromiso Documento emitido por el Sistema de Cobranzas cada

vez que existe un fraccionamiento de deuda solicitado
por un alumno.
Este documento contempla el nuevo cronograma de
pago de los compromisos del alumno.
Canje por deposito Una forma de pago que consiste en la emisión de un
comprobante de pago por un depósito efectuado en las
cuentas corrientes de la Universidad. El documento que
valida esta transacción es el voucher de depósito.
Categorización Beneficio otorgado por primera vez a un alumno para el
cambio del costo de sus pensiones previa evaluación
del cumplimiento de las condiciones establecidas por la
Oficina de Bienestar Universitario.
COCOMO Es un modelo que permite estimar el coste, esfuerzo y
tiempo cuando se planifica una nueva actividad de
desarrollo software. Está asociado a los ciclos de vida
modernos.
Comprobante de pago Documento que sustenta el pago de una tasa
administrativa por parte del alumno o empresas.
Existen dos tipos de comprobantes de pago que son la
boleta de venta y la factura.
Compromiso de pago Es un compromiso que asume el alumno con la
Universidad referente al pago de una o varias tasas
administrativas (matricula, pensiones, boleta de notas,
etc.) durante un tiempo acordado (por ej. un semestre
académico). Sí el alumno no cumple con este acuerdo,
la universidad tiene la facultad de suspender cualquier
tramite del alumno dentro de la jurisdicción de la
Universidad.
Constancia de No Adeudo Documento emitido por el Departamento de Cobranzas
que garantiza que el alumno no tiene deudas
pendientes de pago de tal manera que el alumno pueda
iniciar cualquier trámite dentro de la Universidad.

Costo irregular Costo que no esta dentro de los estándares en las

pensiones. Por ejemplo los costos de medias becas,
descuentos por convenios, categorías y costos
individualizados. Para asignar un costo irregular es
necesario documentos sustentatorios como las
resoluciones emitidas por Consejo Universitario.
Costo regular Costo estándar de pensiones.
Documento aval Una resolución, oficio u otro documento emitido por
Consejo Universitario para otorgar un costo irregular en
pensiones a los alumnos.
Ficha de Alumno Documento que contiene los datos personales del
alumno, así mismo contiene mismo los datos referentes
a la inscripción del alumno a una escuela o
especialidad.
Liquidación diaria Proceso que se realiza diariamente al terminar el turno
de una caja. Para ello se constrasta el efectivo
recaudado con los reportes de liquidación emitidos por
el Sistema de Cobranzas.
Modalidad presencial Sistema de enseñanza en la que el alumno recibe la
cátedra dentro de las instalaciones de la Universidad.
Modalidad SUA Innovador sistema de formación profesional que ofrece
la ULADECH para estudiar a distancia una Carrera
Profesional Universitaria desde su centro de trabajo o
lugar donde se encuentre. Esta modalidad de estudios
no es presencial y las carreras profesionales que ofrece
la Universidad son las siguientes:
Derecho
Educación
Contabilidad
Administración
Administración de Empresas Turísticas
Ingeniería
Nota de crédito Documento emitido por el Departamento de Cobranzas
cada vez que existe una devolución o transferencia de
pago realizado por el alumno incorrectamente.
PATPRO Programa de AcTualización PROfesional, es una de las

modalidades para obtener el Titulo Profesional en las

diferentes carreras profesionales de la ULADECH.
Consiste en el asesoramiento al alumno en el
desarrollo de una tesis o proyecto durante un periodo
relativamente corto.
Plan de costo Conjunto de costos diferenciados por categorías.
Un plan de costo se crea cada vez que hay cambios en
los costos en matriculas y/o pensiones.
Por ejemplo para la escuela de Ingeniería de Sistemas,
los costos del PLAN2004 son A=170.00, B=150.00,
C=125.00. Y el PLAN2005 tiene los siguientes costos
A=190.00, B=170.00, C=150.00. Con esto se asume
que todos los alumnos ingresantes a partir del 2005
están dentro del PLAN2005.
Prorroga Ampliación de la fecha de vencimiento para pagar un
compromiso vencido solicitado por el alumno a la
Jefatura del Departamento de Cobranzas.
Esta solicitud es evaluada para determinar si procede o
no la prorroga, de no ser aceptada se procede a
recargar la mora correspondiente.
Recategorización Beneficio otorgado a un alumno para revalidar el
cambio del costo de sus pensiones previa evaluación
del cumplimiento de las condiciones establecidas por la
Oficina de Bienestar Universitario.
Resolución Documento emitido por Consejo Universitario que tiene
carácter general y obligatorio y se refiere a el
otorgamiento de costos irregulares en las pensiones de
los alumnos.
Unidad recaudadora También denominada Caja, es una dependencia del
Departamento de Cobranzas. En las filiales existe un
administrador que es el responsable del efectivo
recaudado diariamente, el mismo que debe ser
depositado en las cuentas de la Universidad cada vez
que termina un turno.

VIII. ANEXOS
ANEXO Nº 01: Tablas y valores para COCOMO
Modo Esfuerzo Tiempo Desarrollo

ORGANICO ESF = 3.2 (M.F.)1.05 TDES = 2.5 (ESF)0.35
SEMILIBRE ESF = 3.0 (M.F.)1.12 TDES = 2.5 (ESF)0.35
FUERTEMENTE ESF = 2.8 (M.F.)1.20 TDES = 2.5 (ESF)0.32
RESTRINGIDO
Tabla Nº 62: Esfuerzo y tiempo de desarrollo – Nivel Intermedio
Indicador Niveles
Muy Bajo Nominal Alto Muy Ext.
bajo Alto Alto
Producto RSS 0.75 0.88 1 1.15 1.40 -
TBD - 0.94 1 1.08 1.16 -
CPR 0.7 0.85 1 1.15 1.30 1.65
Computadora RTE - - 1 1.11 1.30 1.66
RMP - - 1 1.06 1.30 1.58
VMC - 0.87 1 1.15 1.30 -
TRC - 0.87 1 1.07 1.15 -
Persona CAN - - 1 0.86 0.71 -
EAN - - 1 0.91 0.82 -
CPRO - - 1 0.86 0.70 -
ESO - - 1 0.96 - -
ELP - - 1 0.95 - -
Proyecto UTP - - 1 0.91 0.82 -
UHS - - 1 0.91 0.83 -
RPL - - 1 1.04 1.10 -
Tabla Nº 63: Factores que afectan al esfuerzo

Factor Bases de Calculo Nivel Valor

Requerimiento de
Seguridad Software Perdida Moderada6 Nominal 1
(RSS)
Tamaño de Base de Tamaño BD= 1024kb / 5,88MF
Muy Alto 0.94
Datos (TBD) =174.15
Complejidad del
Nominal 1
Producto (CPR)
Restricciones Tiempo TD= 8 horas/día TE= 10 horas/día
de Ejecución (RTE) Nominal 1
RTE = 8 / 10 = 0.8
Restricción Memoria
Nominal 1
Principal (RMP)
Velocidad Cambio
No se da el efecto del tiempo de
Medios Cómputo Bajo 0.87
cambio
(VMC)
Tiempo Respuesta del
Tiempo de respuesta es interactivo Bajo 0.87
Computador (TRC)
Capacidad Analistas
Alto 0.86
(CAN)
Experiencia Analistas
3 años Nominal 1
(EAN)
Capacidad
Programadores Alto 0.86
(CPRO)
Experiencia en S.O.
1 año Nominal 1
(ESO)
Experiencia Lenguaje
de Programación 1 año Nominal 1
(ELP)
Uso Técnicas
Cambiantes a mayo r uso
Modernas de Alto 0.91
"Metodologías"
Programación (UTP)
Utilización de
Herramientas
Automatización de manera amplia Nominal 1
Moderna de Software
(UHS)
Restricción Tiempo a realizar el proyecto es de
Bajo 1.08
Planificación (RPL) 6 meses
Factor complejidad (FC) 52%
Tabla Nº 64: Calculo del valor de complejidad del proyecto
Factor esfuerzo Compuesto (FEC)= 52%
FEC= 0.94 *0.87 * 0.87 * 0,86 * 0.86 * 0.91 * 1.08 = 0.52

ANEXO Nº 02: Organigrama de La Universidad Los Angeles de Chimbote
Gráfico Nº 76: Organigrama de la ULADECH


ANEXO Nº 03: Tabla estadística T-Student
Tabla Nº 65: Tabla estadística T-Student


ANEXO Nº 04: Recopilación de datos y sugerencias de usuario
Esta encuesta se realizo antes de empezar el proyecto para tratar de

identificar las inquietudes y problemas de los usuarios; de la igual forma esta misma
encuesta se aplico al finalizar la implementación del proyecto con el objetivo de
determinar el grado de aceptación del proyecto.
ENCUESTA 01
RECOPILACION DE DATOS Y SUGERENCIAS DE USUARIO
Nombres: ……………………………………………………… Fecha:…./……/…………

Cargo:…………………………..………………………………………………………….…
Jefatura: …………………….…………………………………………………………….…
1. ¿Cuál es su función básica dentro del puesto que ud. esta ocupando?
2. ¿Qué funciones específicas realiza Ud, dentro de su puesto?, Describa
3. ¿Qué problemas identifica en el desarrollo de sus funciones?, Describa
4. ¿A quienes afecta directamente los problemas que tiene en su puesto?,
Mencione y describa.
5. ¿Describa brevemente el principal problema que afecta su puesto, qué
solución propone Ud.?
6. ¿Tiene alguna limitación con el sistema actual?, Describa.
7. ¿Conoce Ud. sus funciones y responsabilidades dentro de su puesto?,
mencione los más relevantes.
8. ¿Cómo califica Ud. al proceso de innovación y mejora continua que esta
implementando la universidad?
9. ¿Qué problemas identifica en relación a los pagos que realiza los alumnos
en el banco?, Mencione.
10. ¿A que áreas afecta directamente los problemas generados en su puesto?,
mencione.
11. ¿Existe alguna persona con quien coordina directamente, sobre cualquier
problema generado en su puesto?, Mencione.
12. ¿Desde el puesto que ocupa, coordina ud. con las demás sedes?, Mencione
los puntos relevantes a tratar.
13. ¿Qué información son de vital importancia para su área?, Mencione

14. ¿Mencione las causas que provocan el atraso de sus actividades en el

puesto que Ud. ocupa?
15. ¿Se siente capacitado para el cargo que desempeña?, o considera que
debe ser capacitado.
16. ¿El sistema actual cubre las necesidades de su puesto, si no es asi que
funcionalidades deberían considerarse en el nuevo sistema?
17. ¿Mencione que mejoras propone Ud. al desarrollo de sus actividades
diarias?
18. ¿Recurren a UD. otras áreas de la institución a solicitarle información
referente a los pagos de alumnos u otras consultas, especifique las áreas?

Uladech Biblioteca Virtual PDF

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

Uladech Biblioteca Virtual PDF

Cargado por

Copyright:

Formatos disponibles

118

Universidad Los Angeles de Chimbote

SISTEMA DE INFORMACION WEB PARA EL

TESIS PARA OPTAR EL TITULO DE

La meta de todo estudiante universitario es obtener el titulo profesional, esta

La tesis que se presenta en este trabajo se fundamenta en la situación

La presente tesis titulada: “SISTEMA DE INFORMACION WEB PARA EL

Con el debido respeto presento señores miembros del jurado la presente

Ante todo, mi agradecimiento a Adiós por permitirme concluir mi carrera

Quiero expresar mi agradecimiento a las personas que han participado de

A mi asesor por guiarme en el desarrollo de la tesis y compartir sus

Al director y docentes de la Escuela Profesional de Ingeniería de Sistemas

A mis padres, por el apoyo invalorable hacia mi desarrollo personal y

A mis amigos y compañeros de trabajo, por el animo recibido.

SISTEMA DE INFORMACION WEB PARA EL

TESIS PARA OPTAR EL TITULO DE

Ing. Jorge Gutiérrez Gutiérrez

Ing. José Saldaña Tirado

Ing. Bogar Mantilla Gordillo

La elaboración de la presente tesis tiene como objetivo el desarrollo de un

Dicho sistema de información permitirá gestionar los pagos en línea de las

El sistema estará dotado de funcionalidades que permita obtener

La Universidad Los Angeles de Chimbote, es una institución que ha crecido

En esta tesis se presenta una solución haciendo uso de tecnologías web;

La presente tesis esta estructurado de la siguiente manera:

En el capitulo II, referido a los aspectos del análisis de la problemática y las

En el capitulo III, se desarrolla cada una de las etapas de la metodología

En el capitulo IV, se somete el proyecto a un análisis para determinar la

En el capitulo V, se plantean las conclusiones del proyecto y algunas

En el capitulo VI, las referencias bibliográficas y otras fuentes de ayuda que

En el capitulo VII, se describe un conjunto de términos empleados en el

En el capitulo VIII, se incluye el anexo del documento, que consiste en

1.1. Descripción de la organización

1.1.1. Razón social.

Universidad Los Angeles de Chimbote

1.1.2. Ubicación geográfica

La Universidad Los Angeles de Chimbote, tiene como Sede

1.1.3. Fines de la universidad

La ULADECH es una universidad autónoma. Son fines de la

• Contribuir a la formación integral del hombre, la transformación y

Escuela de Ingeniería de Sistemas 17

La ULADECH, se visualiza como una comunidad universitaria, de

La ULADECH , es una institución privada sin fines de lucro que

La ULADECH cuenta y hace de su autonomía, a través de sus

• Aprobar su Estatuto, sus Reglamentos y gobernarse de acuerdo a

El organigrama estructural de la ULADECH se incluye en el capitulo

Escuela de Ingeniería de Sistemas 18

1.2. Ambito y alcance del proyecto

1.2.1. Definición del proyecto

Desarrollo de un Sistema de Información Web para el Departamento

1.2.2. Alcance del proyecto

Para desarrollar el proyecto se ha establecido una serie de

Realizado el estudio preliminar, haremos un análisis para identificar

Así mismo se diseñará toda la arquitectura necesaria para poner en

1.2.3. Áreas y/o dependencias afectadas

Gráfico Nº 1: Organigrama del Departamento de Cobranzas

Escuela de Ingeniería de Sistemas 19

1.3. Funciones y procedimientos

1.3.1. Departamento de Cobranzas

El Departamento de Cobranzas es un órgano que depende

• Verificar los vouchers de pagos por conceptos de tasas y

1.3.1.2. Gestión y procedimientos

• Apertura de semestre académico