- La investigación tiene como objetivo desarrollar un sistema informático para mejorar los procesos de facturación, cobro de pensiones y servicios en la Comunidad Educativa Bilingüe Cristiana Israel "CEBCI". - Actualmente estos procesos se realizan de forma manual, lo que causa inconvenientes. El nuevo sistema se desarrollará usando RUP y arquitectura "4+1", y permitirá optimizar los servicios de la institución.

1. SISTEMA INFORMÁTICO DE
FACTURACIÓN, COBRO DE
PENSIONES Y SERVICIOS

2. R E S U M E N
 La presente investigación tiene como finalidad desarrollar un sistema
informático para mejorar los procesos educativos de la Comunidad
Educativa Bilingüe Cristiana Israel “CEBCI”.
 Para lo cual se realizó una investigación preliminar en donde se
determinó los requerimientos de la institución para el desarrollo de la
aplicación. Además el levantamiento de la información preliminar ayudo
a definir la metodología para el desarrollo del sistema.
 Razón por la cual se utiliza la metodología RUP (Proceso Racional
Unificado), de Kruchten, gracias a sus fases del ciclo de vida que
contiene este modelo.

3. R E S U M E N
 De igual manera se aplicó la arquitectura “4+1” (Kruchten) para
elaborar la construcción de casos de uso y diagramas de clases, los
mismos que permitieron el diseño de la base de datos y las relaciones
de cada una de sus entidades.
 La construcción del software se realizó en Visual Studio 2010 .Net, y
su Base de Datos en SQL Server2008 y en una plataforma web.

4. P L A N T E A M I E N T O D E L P R O B L E M A
 La Comunidad Educativa Bilingüe Cristiana Israel “CEBCI” viene
funcionando en la ciudad de Cuenca hace más de una década, en
sus inicios como Centro de cuidado Infantil, teniendo mucho orden y
cuidado en sus labores profesionales.
 Fue justamente la excelencia en este servicio que, a pedido de
muchos padres de familia, emprendieran con la formación
académica, constituyéndose en un Centro Educativo; es así que el
“CEBCI” fue creado mediante acuerdo Nº 20 emitido por La
Dirección Provincial de Educación del Azuay el 10 de mayo de 1995.

5. P L A N T E A M I E N T O D E L P R O B L E M A
 A medida que la tecnología avanza la institución desea innovar en el manejo de la
documentación de los padres de familia y estudiantes.
 En el departamento de colecturía la documentación se la lleva de forma manual y él
problema inicia cuando los estudiantes deben pagar las pensiones o realizar el
contrato de algún servicio que preste la institución.
 La persona encargada de colecturía debe hacer grandes esfuerzos, para buscar los
registros de los estudiantes. Ya que todos los registros se encuentran en un
archivero, se pudo igualmente observar que los documentos de los estudiantes
estaban expuestos para cualquier usuario.
 Además el registro de control de pagos de los estudiantes se los lleva en formatos
preestablecidos y en algunos casos en archivos de Excel. Todo esto ha generado
algunos inconvenientes y molestias a los padres de familia quienes han
demostrado su descontento, especialmente en la elaboración y entrega de facturas,
recibos de cancelación de pensiones y pagos de servicios.

6.  Recolectar información para realizar el análisis de especificaciones y
requerimientos para el Sistema de Facturación, Cobro de Pensiones y
Servicios.
 Clasificar y analizar la información recolectada.
 Diseñar la base de datos en SQL Server 2008 para el Sistema de
Facturación, Cobro de Pensiones y Servicios.
 Desarrollar el Sistema de Facturación, Cobro de Pensiones y Servicios en
Visual Studio .Net 2010.
 Implementar y Probar el funcionamiento del Sistema de Facturación,
Cobro de Pensiones y Servicios.
 Elaborar un manual de usuario del Sistema de Facturación, Cobro de
Pensiones y Servicios.
 Capacitar al personal administrativo de la Institución.
O B J E T I V O G E N E R A L
 Desarrollar e implementar el sistema informático de Facturación, Cobro de
Pensiones y Servicios en el colegio particular mixto “CEBCI” de la parroquia Monay,
ciudad de Cuenca
O B J E T I V O S E S P E C I F I C O S
O B J E T I V O S D E L A I N V E S T I G A C I Ó N

7. J U S T I F I C A C I Ó N
 Después de haber realizado una
investigación preliminar se determina
que en la actualidad existe la necesidad
de crear un sistema informático para el
proceso de Facturación, Cobro de
Pensiones y Servicios dentro de la
Comunidad Educativa Bilingüe
Cristiana Israel “CEBCI”, en vista que
no cuenta con un Sistema Informático.
 Todos estos procesos se realizan en
secretaría conjunto con colecturía, en
formatos desarrollados en archivos de
Excel, sin mecanismos adecuados que
agilicen y garanticen la seguridad de la
información.
 Además no existe registros de los
pagos de servicios y pensiones, en
forma digital sino de forma manual en
carpetas, sin tener un respaldo de
datos que garantice sus registros.
 Razón por la cual el diseño de
este Software permitirá a la
institución brindar y optimizar sus
servicios con calidad y eficiencia.
Así mismo podemos llevar un
control de los valores cancelados
por los estudiantes.
 Los beneficiarios de este
proyecto serán la Comunidad
Educativa Bilingüe Cristiana
Israel “CEBCI”, los padres de
familia, estudiantes y la sociedad
en general.

8. A L C A N C E
 Se desarrollara e implementará el Sistema Informático de Facturación,
Cobro de Pensiones y Servicios, en la institución educativa “CEBCI”. El
software está desarrollado en Visual Studio .Net2010 y con una Base de
Datos en SQL Server 2008 en ambiente web.
 Desarrollar la metodología de producción de software por medio de la
metodología RUP (Proceso Racional Unificado) hasta la tercera etapa de
desarrollo de software según el modelo de Racional. La etapa faltante
no estará presente por motivo de tiempo.

9. A N Á L I S I S

10. A R Q U I T E C T U R A D E L D E S A R R O L L O
 Las vistas del software no se
requieren siempre, es decir no se
aplica las “4+1 vistas”.
 Las vistas que no son de ayuda
para la realización del software,
pueden excluir de la construcción
de dicho software; como puede
ser la vista física y la vista de
procesos.
 En sistemas de menor desarrollo,
la vista lógica y la de desarrollo
son casi iguales que no necesitan
descripciones de cada una de
ellas. Y los escenarios sirven de
ayuda en todas estas
circunstancias.

11. L A A R Q U I T E C T U R A “4 + 1”
 LA VISTA LÓGICA: lo que el sistema debería proporcionar en términos
de servicios a sus usuarios. En esta vista se usan comúnmente los
diagramas de clases, los de interacción y objetos.
 LA VISTA DE PROCESOS: Se tratan algunos requisitos no funcionales.
Ejecución, disponibilidad, tolerancia a fallos, integridad, etc. La notación
más usada es UML, y dentro de esta diagramas estados, actividad.
 LA VISTA DE DESARROLLO (Despliegue):La vista de desarrollo o
despliegue se enfoca en la organización de los módulos software en el
entorno de desarrollo. La notación más usada es UML.
 LA VISTA FÍSICA: La vista física se centra en los requisitos no
funcionales, tales como la disponibilidad del sistema, la fiabilidad
(tolerancia a fallos), ejecución y escalabilidad.
CONCEPTO: el modelo 4+1 describe la arquitectura del
software usando cinco vistas concurrentes; y cada vista se
refiere a un conjunto de intereses de diferentes participantes
del sistema.

12. M O D E L O D E D E S A R R O L L O
 En el desarrollo de este sistema informático, se decide escoger el
modelo de RUP (Proceso Racional Unificado), para producir software
de alta calidad que cumpla con los requerimientos, planificación y
presupuesto establecido, ya que es un modelo que involucra un análisis
de riesgo, y cubre todo el ciclo de vida del producto, soporta un enfoque
de desarrollo iterativo e incremental, las iteraciones tempranas se
enfocan en validar y producir una arquitectura de software.
 Se realizará una adaptación del modelo RUP al desarrollo de
software informático orientado a los servicios. Este modelo se
explicará en detalle a continuación. En primer lugar se dará una
descripción del modelo RUP, para luego establecer las diferentes fases
de la metodología para el desarrollo del prototipo.

13. M O D E L O D E D E S A R R O L L O
 (RUP) Proceso Racional
Unificado: es un proceso de
Ingeniería de Software
planteado por Philippe
Kruchten (2000) cuyo
objetivo es producir software
de alta calidad, que cumpla
con los requerimientos de los
usuarios dentro de una
planificación y presupuesto
establecidos.

14. E L E M E N T O S D E L M O D E L O R U P
 Trabajadores: este término se
refiere a los roles que definen cómo
deberían trabajar los individuos.
 Actividades: una actividad de un
trabajador específico es una unidad
de trabajo que un individuo en ese
rol puede realizar.
 Artefactos: un artefacto es una
pieza de información que es
producida, modificada o usada por
un proceso. Son productos tangibles
del sistema informático; las cosas
que el sistema usa mientras se
trabaja hacia el producto final. Los
artefactos se usan como entradas
para los trabajadores para realizar
una actividad y son el resultado o la
salida de esas actividades

15. R E V I S I Ó N D E L A S F A S E S
 Concepción o Inicio: la visión del producto, cómo se enmarca en el negocio, el
alcance del sistema informático de calidad. Esta fase se culmina con los objetivos
del ciclo de vida.
 Elaboración: Planificar las actividades necesarias y los recursos requeridos,
especificando las características y el diseño de la arquitectura. Esta fase culmina
con la arquitectura del ciclo de vida.
 Construcción: Desarrollar el producto y evolucionar la visión; la arquitectura y los
planes hasta que el producto en una primera versión esté listo para ser enviado a
la comunidad de usuarios. Esta fase culmina con la capacidad inicial de
operación.
 Transición: Realizar la transición del producto a los usuarios, lo cual incluye:
manufactura, envío, entrenamiento, soporte y mantenimiento del producto hasta
que el cliente esté satisfecho. Esta fase culmina con la Versión de Producto, la
cual a su vez concluye el ciclo.

16. A D M I N I S T R A C I Ó N “T R A D I C I O N A L”
E S T A D O S D E C U E N T A D E L
E S T U D I A N T E
 Funcionamiento que anteriormente la administración del colegio
particular mixto “CEBCI”, utilizaba para llevar los registros de cada
estudiante del plantel.
 Referente a los Estados de Cuenta del Estudiante: las facturas y
reportes, que registra y emite la institución lo realizaba de forma manual;
llegando al punto de llamarlo “tradicional” (lápiz y papel).
 Las diferentes actividades que realizaba el estudiante se las anotaba en
hojas prediseñadas de Excel; y eran colocadas en un archivero que
contenía toda la información de todos los estudiantes.
I D E N T I F I C A C I Ó N D E R E Q U E R I M I E N T O S

17. H O J A P R E E D I S E Ñ A D A D E L E S T A D O
D E C U E N T A D E U N E S T U D I A N T E D E L
“CEBCI”

18. A D M I N I S T R A C I Ó N “T R A D I C I O N A L”
A S I G N A C I Ó N D E S E R V I C I O S Y
F A C T U R A C I Ó N
 De la misma manera se realizaba el llenado de los datos del alumno
y los valores que cancela, correspondientes a los servicios que
adquirió en un determinado mes del año electivo; todo esto se haría
de forma manual.

19. H O J A P R E E D I S E Ñ A D A D E U N A
F A C T U R A D E U N E S T U D I A N T E
D E L « C E B C I »

20. A N Á L I S I S D E L A S O L U C I Ó N
P O R E L M O D E L O R U P
 ANÁLISIS:
 En esta etapa se necesita realizar un análisis de las necesidades de la
Comunidad Educativa Bilingüe Cristiana Israel “CEBCI” y del entorno
educativo de la población a la que va dirigido este sistema.
 En la primera iteración de la concepción del sistema se ha logrado tener
una concepción clara de la funcionalidad del sistema, de acuerdo a ello
podemos determinar la arquitectura del software.

21.  En el caso de la elaboración del sistema informático, se realizaron
cada uno de estos análisis y se llegó a la conclusión que se
ameritaba el desarrollo del software de forma inmediata.

22. ACTIVIDADES DEL ANÁLISIS DEL ENTORNO
ACTIVIDADES PROPÓSITO
1. Análisis de audiencia Conocer que área dentro de la Comunidad Educativa Bilingüe Cristiana Israel “CEBCI” se ve afectada
en el manejo de los registros, específicamente al control de pago de servicios que presta la institución,
y que son utilizados por parte del estudiante.
1. Análisis de equipo y soporte
técnico
Identificar las capacidades tecnológicas existentes en el área de administración del plantel educativo
“CEBCI”.
1. Análisis de área de
Contenido
Conocer en el área de administración los registros de datos: como son creados desde su “nacimiento”
hasta llegar a ser archivados, qué medidas se llevan a cabo para salvaguardar esta información, el
tiempo que se lleva a cabo para realizar un solo proceso de crear, modificar y archivar datos. Que
materiales utilizan para crear un registro. Conocer en qué parte del proceso de registro los problemas
se convierten más en un cuello de botella.
1. Análisis de las limitaciones y
recursos para el usuarios
Determinar quién tendrá acceso a estos datos, si hay una o varias personas encargadas. Si se utilizará
ayudas adicionales de apuntes, calculadoras o fórmulas.
1. Análisis de productos
comerciales
Investigar si la solución ya existe en el mercado, lo cual evitaría los costos de desarrollo.
1. Análisis de Costos Identificar los costos y los beneficios y el retorno a la inversión.
 Una vez que el análisis de las necesidades determina que se requiere
del desarrollo de un software, el próximo objetivo es más información
detallada acerca de qué es lo que se quiere desarrollar.

23. En esta propuesta:
ANÁLISIS DEL ENTORNO EDUCATIVO CON EL SIFCPS
ACTIVIDADES PROPÓSITO
1. Análisis de audiencia
El destinatario que utilizará el software se encuentran en colecturía; área de
administración. La persona encargada en el área de administración tiene
interés en que los procesos de los registros se lleven de manera más
eficiente. Ya que como saben que los procesos que se llevan a cabo en
computadoras y con software desarrollado según las necesidades del
usuario, son más fáciles de entender y procesar. Es decir que cuando se
creen los registros sean fáciles de encontrar, y modificar. Sabe que se
ahorrará tiempo y dará un mejor trato para los usuarios indirectos que
genera este software como lo son los estudiantes.
1. Análisis de equipo y
soporte técnico
El departamento de administración cuenta con al menos una computadora
con un procesador core i3como mínimo, lector de CD ROM. Pero no tiene
acceso a internet, ya que no tiene las instalaciones de cableado o zona de
wifi.
1. Análisis de área de
Contenido
Se decidió realizar un software de servicios, debido a las grandes
necesidades que tenía la institución. Ya que las diferentes actividades que se
realizan en la administración del plantel educativo, se las realizaba en
algunos casos en hojas preestablecidas en formato de Excel. Para esto se
centra la atención en el tema de los requerimientos que tiene y necesita el
plantel. Se trabajará en el área de administración de las actividades que
realiza el estudiante como: pagos de servicios que presta la institución
(transporte, natación, alimentación) y el de las pensiones.
1.
Análisis de las
limitaciones y recursos
para el o los usuarios
El software desarrollado será utilizado en forma individual por la persona
encargada en el área de administración.
1.
Análisis de productos
comerciales
A nivel comercial no existe un software que abarque el tema de control de
registros de servicios, desarrollados para instituciones educativas.
1. Análisis de Costos El análisis de costos no se realiza debido a que se trata de un desarrollo a
nivel de prototipo, producto del a elaboración del sistema informático especial
de grado, con tiempo y recursos limitados.

24. D I S E Ñ O

25. A R Q U I T E C T U R A D E L A
S O L U C I Ó N (M O D E L O R U P)
 FASE DE CONCEPCIÓN:
Objetivos
-Establecer el alcance del sistema informático, las condiciones y límites que se plantearon para
la realización del mismo.
- Cuáles son los casos de uso del sistema, como se enlazan unos con otros.
- Valorar los costos, tiempos y viáticos sobre el desarrollo del sistema informático.
Artefactos
- Un documento con la guía necesaria para ayudar al usuario.
- El modelo de casos de uso con los actores que intervienen y que puedan ser identificados en la
realización del sistema.
-Un caso inicial del negocio el cual incluye: contexto del negocio.
- Requerimientos complementarios.
- Un plan del proyecto el cual muestre las fases y las iteraciones, más concretamente un
cronograma de actividades que especifiquen u tiempo desde su iniciación hasta la culminación
del sistema informático.
- Un análisis del diseño del sistema que se va a desarrollar.
Criterios de
Evaluación
- Fidelidad en los casos de uso primarios.
- Alcance de un prototipo del desarrollo del sistema informático.
- Gastos reales contra gastos planificados.

26. A R Q U I T E C T U R A D E L A
S O L U C I Ó N (M O D E L O R U P)
Objetivos - Definir, validad y delinear la arquitectura tan rápido como sea posible.
- Delinear un plan de alta fidelidad para la fase de construcción.
Actividades
Esenciales
- Establecer un sólido entendimiento de los casos de uso más críticos que conducen las decisiones de
arquitectura y planificación.
- Elaborar la arquitectura y seleccionar los componentes.
Artefactos
- Un modelo de casos de uso (completo en al menos un 70%) con todos los actores identificados y la mayor
parte de las descripciones de casos de uso.
- Requerimientos complementarios.
- Descripción de la arquitectura de software.
- Plan de sistema informático incluyendo iteraciones.
Criterios de
Evaluación
- Estabilidad de la arquitectura.
- Nivel de detalle y exactitud del plan de la fase de construcción.
- Acuerdos de las partes interesadas acerca de que el plan logre que se pueda alcanzar desarrollar el sistema
con la arquitectura seleccionada.
 FASE DE ELABORACIÓN:

27. A R Q U I T E C T U R A D E L A
S O L U C I Ó N (M O D E L O R U P)
 FASE DE CONSTRUCCIÓN:
Objetivos - Minimizar los costos de desarrollo.
- Lograr la calidad adecuada.
- Lograr una versión que pueda ser usada.
Actividades Esenciales - Gerencia de recursos, control de recursos y optimización de procesos.
- Manual preliminar del usuario.
Artefactos
- El producto de software Integrado sobre plataforma adecuada y el funcionamiento adecuado.
- Una descripción de la versión actual.
Piedra de Milla: Capacidad Operativa inicial
Criterios de Evaluación - Estabilidad y madurez de versión del producto, capacidad para ser manipulada.
- Los gastos reales de recursos comparados con los gastos planificados.

28. A R Q U I T E C T U R A D E L A
S O L U C I Ó N (M O D E L O R U P)
 FASE DE TRANSICIÓN:
Objetivos - Lograr que el usuario manipule con facilidad el software.
- Lograr un producto final tan rápidamente y costo efectivo como sea posible.
Actividades Esenciales - Ajustes, incluyendo corrección de errores y mejoramiento para el desempeño y usabilidad
del software.
Artefactos
- El producto de software Integrado sobre plataforma adecuada y el funcionamiento
adecuado.
- Una descripción de la versión actual.
Piedra de Milla: Versión del producto
Criterios Evaluación - Usuario satisfecho.
- Gastos de recursos actuales contra gastos planificados.

29. M O D E L O D E L A I N T E R F A Z
 Cinco (5) pasos importantes en el diseño: análisis, diseño, desarrollo,
implementación y evaluación. En este sistema informático, no se incluye la etapa
de prueba piloto y prueba de campo, ya que el modelo RUP incluye una constante
vigilancia de los productos y subproductos del proceso de desarrollo del software.
Se explican las estas etapas; para el desarrollo de sistema informático, se
abarcará hasta la etapa de inicial de diseño.

30. C R O N O G R A M A D E
A C T I V I D A D E S
N° Actividad Fecha inicio Fecha fin
1 Investigación y evaluación (métodos y actividades que usan) de
la existencia de nuevos métodos para el desarrollo del software.
24-09-2012 24-10-2012
2 Entrevistas, en el plantel acerca de la deficiencia en el proceso y
manejo de la información.
25-10-2012 31-10-2012
3 Recolección, Análisis y Plan Estratégico envase a la información
en Unidad Educativa Bilingüe Cristiana Israel “CEBCI”, de
acuerdo con los requerimientos de la misma. 05-11-2012 05-12-2012
4 Desarrollo de la aplicación en C # .Net 06-12-2012 07-02-2013
5 Pruebas de Depuración de la Aplicación 11-02-2013 01-03-2013
6 Implementación de la aplicación desarrollada 02-03-2013 11- 03-2013
7 Demostración final de la Aplicación 12-03-2013 15-03-2013

31. D I A G R A M A D E C L A S E S

32. C A S O S D E U S O
CASO DE USO 1: ASIGNAR SERVICIO
Actividades Esenciales “Servicio - estudiante” Muestra los servicios de los estudiantes que utilizarán a lo largo del año
electivo, teniendo como variable la del transporte, natación y alimentación, pero siendo fijo el
servicio de pensiones.
Condiciones Previas Toda la información pertinente al software deberá existir.
Condiciones Resultantes Los módulos del sistema interactuar con esta información.
Pasos -Ingresar como administrador del sistema.
- La interfaz muestra toda la información concerniente.
Actores beneficiados Administrador
Usuario (estudiante).
CASOS DE USO DESCRIPCIÓN
Validar Usuario Se encarga de validar la identidad del usuario que accede al software, así como identificar su rol.
Registrar Usuario Su propósito es registrar al estudiante o docente que no haya sido registrado para poder usar este
portal.
Mostrar contenido
Este proceso se encarga de mostrar el contenido que corresponde cada usuario de acuerdo a su
login y contraseña. Si es estudiante tendrá derecho a cierta información, si es docente a otra.
También muestra la información que es común a ambos.

33. C A S O S D E U S O
CASO DE USO 2: REALIZAR PAGOS
Actividades Esenciales “Realizar Pagos” Muestra la información de la interfaz de “Asignar Servicios”; para poder obtener
interactividad con esta interfaz.
Condiciones Previas
Establecer las condiciones de asignar los servicios a ser utilizados de manera anticipada.
Condiciones Resultantes Los demás módulos del sistema pueden interactuar con esta información.
Pasos - Genera resultados.
- La interfaz del software muestra toda la información concerniente.
Actores Beneficiados Usuario (estudiante).
Administrador.
CASO DE USO 3: FACTURA
Actividades Esenciales “Emitir - Factura” Muestra los servicios y el valor de cada uno de los servicios que el estudiante o
representante ha cancelado con anterioridad; Los servicios que han sido cancelados durante
diferentes meses a lo largo de año electivo, se entregarán al estudiante o representante como
constancia del pago que ya ha realizado.
Condiciones Previas Establecer las condiciones de cancelar los servicios que han sido utilizados, y se debe hacerlo de
manera anticipada.
Condiciones Resultantes Los demás módulos del sistema pueden interactuar con esta información.
Pasos - Genera resultados.
- La interfaz del software muestra toda la información concerniente.
Actores Beneficiados Administrador
Usuario(estudiante)

34. D E S A R R O L L O

35. M E N U P R I N C I P A L

36. A S I G N A C I O N D E
S E R V I C I O S

37. P A G O S

38. F A C T U R A

39. R E P O R T E S

40. IMPLEMENTACIÓN Y CAPACITACIÓN

42. CONCLUSIONES Y
RECOMENDACIONES

43. CONCLUSIONES
 A pesar de que el software desarrollado se realizó exitosamente en las áreas
especificadas y según los requerimientos que el plantel solicitó; a la entrega del
mismo, se requirió que se continuara con el desarrollo del software, pero en otras
áreas. Cabe recalcar que es una INVESTIGACIÓN FORMATIVA PREVIA A LA
OBTENCIÓN DEL TÍTULO DE INGENIERO DE SISTEMAS, y no se podrá
extender el desarrollo del software en más módulos, por tener un tiempo y un
cronograma determinado de actividades.
 Se han observado ciertas dificultades en el manejo del software, a pesar de que
su manipulación es sencilla, las personas encargadas de su manipulación
demostraron cierto descontento o temor, al momento de “manejar” el software.
 En el desarrollo de este software queda una enseñanza de evitar cometer errores
al momento de desarrollar un software, o al momento de ponerlo en práctica, se
debe revisar y solucionar las dificultades que se presenten; ya que es una pérdida
de tiempo valiosa.
 Se puede decir que las herramientas utilizadas fueron las adecuadas, y se logró
desarrollar un software que cumpliera con lo que se planteó inicialmente.
Utilizando el método RUP, se puede utilizar como la primera parte del análisis de
cualquier sistema o proceso, y ser útil como referencia para las siguientes fases
del ciclo de desarrollo de software, aunque la siguiente etapa no se continué con
su desarrollo y siga un método estructurado.
 Mejorar las interfaces de presentación del software, es decir el inicio de la
presentación en general, necesita más información sobre el ingreso al sistema.

44. RECOMENDACIONES
 Se planteó continuar con el desarrollo del software, en los módulos que ellos
crean necesarios, pero se recalcó que tendría un costo por cada uno de los
diferentes módulos; a lo cual no se llegó a un acuerdo. Por lo que se recomienda
que se siga el mismo método de desarrollo con la que se realizó con este equipo
de investigación. Es decir que continúen más estudiantes egresados con el
desarrollo del software, si podríamos decirlo en una siguiente fase. Así no tendría
un costo para la unidad educativa, y los estudiantes tendrían un proyecto de
investigación.
 Para ello se adjunta un manual de usuario que ayudará a las personas
encargadas de su manipulación, en las áreas que correspondan. Y así tengan un
software amigable con el usuario y fácil de manipular.
 Tener una mejor planificación en el desarrollo de proyectos venideros, ya que
como fue un primer proyecto muy distante de lo universitario; convirtiéndose en un
caso profesional de la carrera de ingeniería de sistemas. Entonces se debe
mejorar la recolección de datos e información en las distintas empresas que
tengan sus necesidades y requerimientos informáticos, para evitar inconvenientes.
 Seguir con el mismo método de desarrollo, ya que son una gran ayuda en su
desarrollo, en recolección de datos y en la realización de un seguimiento y en
ejecución.
 Elaborar una interfaz inicial que incorpore más información del plantel; el acceso
al sistema, mejorar el diseño de la interfaz inicial, en cuanto a colores y cuadros
de dialogo informativos.

45. ¡ GRACIAS !