Post on 01-Nov-2018
UNIVERSIDAD CENTRAL DEL ECUADOR
FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA
CARRERA DE INGENIERIA INFORMÁTICA
IMPLEMENTACIÓN Y REINGENIERÍA DEL SISTEMA “ERP SOCIAL”, EN
LA ESCUELA FISCAL MIXTA MANUEL QUIROGA DE LA PARROQUIA
TUMBACO DEL DISTRITO METROPOLITANO DE QUITO
TRABAJO DE GRADUACIÓN
PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO INFORMÁTICO
AUTOR: Irma Guadalupe Pérez Reina
TUTOR: Ing. César Augusto Morales Mejía
QUITO – ECUADOR
2015
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
ii
DEDICATORIA
Mi mayor gratitud a Dios por su bondad de concederme la vida, y de guiarme
en cada paso, por alcanzar una meta, siendo mi aliento y realización.
A la Virgen del Perpetuo Socorro que siempre me brindo su protección y me
guio por el camino correcto.
A mis padres por participar con Dios en esta etapa de vida, por sus consejos
y los valores que han inculcado en mi persona y me enseñaron que se
puede superar cualquier adversidad.
A mis hermanos quienes con sus palabras de aliento no me dejaban decaer
para que siguiera adelante y siempre sea perseverante y cumpla con mis
ideales.
A mi gran amiga de la infancia que con sus consejos y vivencias siempre me
dio una palabra de aliento y confió en mi potencial.
Y a todas aquellas personas que durante este tiempo de carrera estuvieron a
mi lado apoyándome y lograron que este sueño se haga realidad.
Gracias a Todos.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
iii
AGRADECIMIENTOS
Mi agradecimiento a la Universidad Central del Ecuador, a la facultad de
Ingeniería Ciencias Físicas y Matemática ya que fue un excelente espacio de
formación y estudio, y en especial por todo lo que me ha brindado personal y
profesionalmente.
La realización de esta tesis fue posible gracias al apoyo del Ing. Cesar
Morales, quien ha sido mi tutor y se ha preocupado de una manera especial
del avance de este módulo permitiendo desarrollarlo y estructurarlo de
manera adecuada en base a su guía y conocimiento adquirido.
Un agradecimiento al Director Dr. Rubén García de la Escuela Manuel
Quiroga quien me brindó su colaboración y apoyo para implementar el
sistema.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
iv
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
v
CERTIFICACION
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
vi
APROBACION DEL JURADO
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
vii
RESULTADO DEL TRABAJO DE GRADUACION
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
viii
CONTENIDO
UNIVERSIDAD CENTRAL DEL ECUADOR ............................................................................... I
DEDICATORIA .............................................................................................................................. II
AGRADECIMIENTOS .................................................................................................................. III
CERTIFICACION ........................................................................................................................... V
APROBACION DEL JURADO .................................................................................................... VI
RESULTADO DEL TRABAJO DE GRADUACION .................................................................. VII
CONTENIDO ............................................................................................................................... VIII
LISTA DE ANEXOS ...................................................................................................................... X
LISTA DE TABLAS ....................................................................................................................... X
LISTA DE ILUSTRACIONES ....................................................................................................... X
INTRODUCCIÓN ........................................................................................................................... 1
CAPITULO 1 .................................................................................................................................. 2
1. PRESENTACIÓN DEL PROBLEMA ...................................................................... 2
1.1. PLANTEAMIENTO DEL PROBLEMA .................................................................................... 2
1.2. FORMULACIÓN DEL PROBLEMA ....................................................................................... 4
1.3. INTERROGANTES DE LA INVESTIGACIÓN ......................................................................... 5
1.4. OBJETIVO DE LA INVESTIGACIÓN ..................................................................................... 5
1.5. JUSTIFICACIÓN ................................................................................................................. 6
1.6. CONTENIDO DEL PROYECTO ........................................................................................... 7
CAPITULO 2 .................................................................................................................................. 9
2.1. ANTECEDENTES ............................................................................................................... 9
2.2. MARCO TEÓRICO ........................................................................................................... 10
2.3. IDENTIFICACIÓN DE VARIABLES ..................................................................................... 24
2.3.1. VARIABLES INDEPENDIENTES ........................................................................................ 24
2.3.2. VARIABLES DEPENDIENTES ........................................................................................... 25
2.4. HIPÓTESIS...................................................................................................................... 25
CAPITULO 3 ................................................................................................................................ 26
3. ANÁLISIS DEL SISTEMA .................................................................................................. 26
3.1. ESPECIFICACIÓN DE REQUERIMIENTOS ......................................................................... 26
3.1.1. CONTEXTO DEL SISTEMA ............................................................................................... 26
3.2. RESTRICCIONES Y SUPOSICIONES ................................................................................ 32
3.2.1. RESTRICCIONES EN EL DESARROLLO DEL PROYECTO .................................................. 32
3.2.2. RESTRICCIONES EN LAS HERRAMIENTAS DE DESARROLLO DE SOFTWARE .................. 33
3.2.3. RESTRICCIONES DEL HARDWARE DEL SERVIDOR ......................................................... 33
3.3. RIESGOS ........................................................................................................................ 33
3.3.1. TECNOLÓGICOS ............................................................................................................. 33
3.3.2. DE RECURSOS ............................................................................................................... 34
3.3.3. DE MÓDULO ................................................................................................................... 34
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
ix
3.3.4. DE HABILIDADES ............................................................................................................ 35
3.3.5. DE REQUERIMIENTOS .................................................................................................... 35
3.4. REQUERIMIENTOS FUNCIONALES .................................................................................. 35
3.5. DESCRIPCIÓN DE LOS ACTORES .................................................................................... 35
3.6. REQUERIMIENTOS TÉCNICOS ........................................................................................ 38
3.7. REQUERIMIENTO DE SOFTWARE ................................................................................... 38
3.8. REQUERIMIENTOS DE HARDWARE ................................................................................. 38
3.9. LENGUAJE DE MODELAMIENTO UNIFICADO (UML) ...................................................... 39
3.10. DIAGRAMA DE CLASES .................................................................................................. 39
3.11. DIAGRAMA DE CASOS DE USO ...................................................................................... 42
3.12. DIAGRAMAS DE SECUENCIA ........................................................................................... 46
3.12.1. INGRESO DEL BIEN ......................................................................................................... 46
3.12.2. TRASLADO CUSTODIO ................................................................................................... 47
3.12.3. INGRESO MASIVO .......................................................................................................... 48
3.12.4. INVENTARIO ................................................................................................................... 49
3.12.5. BAJAS ............................................................................................................................ 50
3.12.6. DEVOLUCIÓN ................................................................................................................. 51
3.13. ARQUITECTURA MODELO-VISTA-CONTROLADOR......................................................... 52
CAPITULO 4 ................................................................................................................................ 56
4. MARCO ADMINISTRATIVO ...................................................................................... 56
4.1. RECURSOS .................................................................................................................... 56
4.2. RECURSOS INSTITUCIONALES ....................................................................................... 57
4.3. RECURSOS DEL AUTOR ................................................................................................. 58
4.4. COSTOS ......................................................................................................................... 58
4.5. CRONOGRAMA ............................................................................................................... 59
CAPITULO 5 ................................................................................................................................ 60
5. CONCLUSIONES Y RECOMENDACIONES .......................................................... 60
5.1. CONCLUSIONES ............................................................................................................. 60
5.2. RECOMENDACIONES ...................................................................................................... 61
BIBLIOGRAFIA ........................................................................................................................... 62
ANEXOS ....................................................................................................................................... 64
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
x
LISTA DE ANEXOS
ESPECIFICACIONES FUNCIONALES…………….………………………..66
CRONOGRAMA……………………………………………………………….102
LISTA DE TABLAS
Tabla 1: REQUERIMIENTO DE SOFTWARE .........................................................38
Tabla 2 REQUERIMIENTO DE HADWARE ............................................................38
Tabla 3 FORMACION DEL EQUIPO ......................................................................57
Tabla 4 COSTOS ....................................................................................................59
Tabla 5 REQUERIMIENTO FUNCIONAL PROVEEDORES ...................................65
Tabla 6 REQUERIMIENTO FUNCIONAL INGRESO DE PRODUCTOS .................69
Tabla 7 REQUERIMIENTO FUNCIONAL CONSULTA BIENES .............................71
Tabla 8 REQUERIMIENTO FUNCIONAL REPORTE .............................................78
Tabla 9 REQUERIMIENTO FUNCIONAL TRASLADO ENTRE CUSTODIOS ........81
Tabla 10 REQUERIMIENTO FUNCIONAL BAJA DE BIENES ................................85
LISTA DE ILUSTRACIONES
Ilustración 1 : MODELO EN V .................................................................................13
Ilustración 2: MODELO NIVELES LOGICOS ..........................................................14
Ilustración 3 BDLINEAS DE BIEN ...........................................................................39
Ilustración 4 BD RELACION BIEN INVENTARIO....................................................39
Ilustración 5 BD RELACION TRANSACCION .........................................................40
Ilustración 6 DB RELACION CABECERA BIEN ......................................................41
Ilustración 7 DCU ASIGNACION DEL BIEN ...........................................................42
Ilustración 8 DCUSISTEMA ....................................................................................43
Ilustración 9 DCUVALIDACION BIEN .....................................................................44
Ilustración 10DCU INGRESO BIEN ........................................................................45
Ilustración 11 DS INGRESO BIEN ..........................................................................46
Ilustración 12 DS TRASLADO CUSTODIO .............................................................47
Ilustración 13 DS INGRESO MASIVA .....................................................................48
Ilustración 14 DS INVENTARIO ..............................................................................49
Ilustración 15 DS BAJAS ........................................................................................50
Ilustración 16 DS DEVOLVER ................................................................................51
Ilustración 17 ARQUITECTURA VCC .....................................................................52
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
xi
RESUMEN
IMPLEMENTACION Y REINGENIERIA DEL SISTEMA ERP SOCIAL EN LA
ESCUELA FISCAL MIXTA MANUEL QUIROGA DE LA PARROQUIA DE
TUMBACO DEL DISTRITO METROPOLITANO DE QUITO.
El sistema de "Erp social" es un proyecto para la sociedad y se ocupa de
diferentes módulos entre estos activos fijos utilizados para registrar los
bienes que están en la escuela, que permiten generar informes sobre el
movimiento de cada activo.
La herramienta desarrollada es simple e intuitiva, por lo que es fácil de
manejar para cualquier persona. También se desarrolla bajo un entorno web
que le permite ser accedido desde cualquier lugar donde usted tiene una
conexión a Internet.
Este sistema abarca varios niveles de seguridad para asignar perfiles a los
que participan en cada proceso de usuario desarrollado, algunos de los
cuales son transaccionales.
DESCRIPTORES:
SISTEMA DE IMPLEMENTACION / REINGENIERIA "SOCIAL ERP"/
ESCUELA FISCAL "MANUEL QUIROGA"/ PARROQUIA TUMBACO/
DISTRITO METROPOLITANO DE QUITO / UML/ SOFTWARE LIBRE
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
xii
SUMMARY
SYSTEM IMPLEMENTATION AND RE-ENGINEERING "SOCIAL ERP" IN
FISCAL SCHOOL "MANUEL QUIROGA", OF THE PARISH TUMBACO OF
THE METROPOLITAN DISTRICT OF QUITO.
The "Erp-social" system is a project for society and deals with different
modules between these fixed assets used to record goods that are in school
that allow generate reports on the movement of each asset.
The tool developed is simple and intuitive, so that it is easy to handle for
anyone. It is also developed under a web environment allowing it to be
accessed from anywhere where you have an internet connection.
This system covers several levels of security to assign profiles to user
involved in each process developed, some of which are transactional.
DESCRIPTORS:
SYSTEM IMPLEMENTATION / RE-ENGINEERING "SOCIAL ERP"/
FISCAL SCHOOL "MANUEL QUIROGA"/ PARISH TUMBACO/
METROPOLITAN DISTRICT OF QUITO / UML/ SOFTWARE FREE
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
xiii
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
xiv
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
1
INTRODUCCIÓN
En poco tiempo, las nuevas tecnologías de la información han llegado a ser
el centro y la base de importantes operaciones de gestión. Hoy en día no es
posible entender la vida social sin el servicio de estos equipos y los sistemas
informáticos que funcionan sobre ellos. La mayoría de las actividades
industriales, comerciales, militares, investigativas y de servicios tales como
transporte, salud, educación, entre otras, dejarían de funcionar sin el apoyo
que ahora reciben de los medios informáticos.
En los últimos años se ha podido observar una serie de avances en las
diferentes tecnologías de información, esto ha permitido crear sistemas de
información más sofisticados y por supuesto más integrados.
El ERP es uno de estos sistemas, que integra las grandes áreas de
información de una empresa en un solo sistema. Sus siglas provienen del
término en inglés ENTERPRISE RESOURCE PLANNING. Por lo general,
estos sistemas están compuesto de módulos como: Recursos Humanos,
Ventas, Contabilidad, Finanzas, Compras, Producción, entre otros;
brindando información cruzada e integrada de todos los procesos del
negocio.
Este software debe ser parametrizado y adaptado para responder a las
necesidades específicas de cada organización.
La implementación de esta herramienta en una empresa conlleva la
transformación y redefinición de sus procesos.
La Facultad de Ingeniería, Ciencias Físicas y Matemática, de la Universidad
Central del Ecuador, en vista de promover la automatización de procesos y
vinculación con la sociedad ha implementado en la parroquia San Pedro de
Amaguaña, del Distrito Metropolitano de Quito, el sistema “ERP Social”, que
administra los módulos relacionados a la gestión documental escolar y
eclesiástica.
(1)Tesis de Grado ERP-Social 2012 Consultado el día 4 de marzo de 2013
desde http://www.dspace.uce.edu.ec/bistream.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
2
CAPITULO 1
1. Presentación del problema
1.1. Planteamiento del Problema
En la actualidad surge la gran necesidad de hacer que los procesos que
se realizan tanto en las instituciones educativas como en los despachos
parroquiales se ejecuten de una manera automática, lo que dará como
resultado que las actividades a ser desarrolladas en estas instituciones
sean más eficientes y rápidas gracias al uso de la tecnología.
Existen instituciones que tienen varios años sirviendo a la comunidad,
manejándose sin ningún tipo de tecnología o la que tienen es básica
como la utilización de Word o Excel de Microsoft Office; a su vez, es
necesario imprimir los documentos generados con estas herramientas, lo
que conlleva al uso de un mayor espacio físico para su almacenamiento.
La educación en un país es el factor más importante para que éste se
pueda desarrollar por lo que es primordial apoyar a que tenga las mejores
herramientas, una de las acciones para promover esta mejora es el
enfoque respecto al manejo de los documentos que se generan, por tal
motivo se ha llegado a escuelas de diferentes parroquias, que tienen
como objetivo brindar una educación de calidad y prestar servicios de
forma eficiente lo cual se dificulta debido al número de estudiantes que
reciben en cada una de sus instituciones, y que, actualmente gestionan
de forma manual lo que se refiere al registro de asistencia de los
profesores, inscripciones, matrículas escolares, control académico,
gestión documental y activos fijos; lo que implica tiempo y consumo de
recursos en gran cantidad, tanto para el registro como para la búsqueda
de datos o información que se requiera al instante. Además, se infringen
las normativas de control ambiental, debido al papel impreso que se
almacena.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
3
Otra institución que es importante en una parroquia es el despacho
parroquial ya que allí se maneja documentos concernientes a las
actividades que tienen los feligreses tales como:
Certificados de bautizo
Certificados de matrimonio
Catequesis
Misas
En algunas parroquias el despacho parroquial también se encarga de la
administración del cementerio donde se manejan funciones como:
Administración de nichos
Alquiler y cobro de nichos
En la actualidad la mayoría de despachos realizan estas actividades
mediante herramientas de Office: el editor de texto (Word) y hojas de
cálculo (Excel) y almacenan los documentos en carpetas, utilizando
diferentes formas de organización documental, lo que ocasiona el uso de
diversos recursos al momento de realizar una consulta de los mismos.
En la actualidad con el avance de la tecnología la mayor parte de las
empresas están adoptando la automatización de sus procesos, y en este
aspecto las parroquias de Pintag, Tumbaco y La Magdalena del Distrito
Metropolitano de Quito, San Isidro de la provincia del Carchi, San Pablo
de la provincia de Bolívar, San Miguel Arcángel de la provincia de
Cotopaxi y Cacha de la provincia de Chimborazo no son la excepción, ya
que sus instituciones educativas y el despacho parroquial por falta de
recursos económicos no han logrado adquirir un sistema que gestione los
módulos mencionados anteriormente, por lo cual a la propuesta de
implementación del sistema ERP social, se tuvo una respuesta positiva de
dichas parroquias.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
4
1.2. Formulación del Problema
En la actualidad debido a la cantidad de habitantes se complica cada año
el trabajo de las personas que administran documentos, en este aspecto
se señala a las Instituciones Educativas, que tienen dificultades en cuanto
a la gestión de inscripciones, matriculas escolares, control académico,
control de asistencia y activos fijos, debido a que se lo hace en forma
manual y por otro lado la administración en los despachos parroquiales ya
que existe gran cantidad de documentación personal como certificados de
bautismo, comunión, confirmación, matrimonio, contratos y pagos de
nichos.
La solución brindada es algo novedoso ya que las instituciones siempre
buscan hacer su trabajo de manera ágil y más eficiente, el uso de nuevas
tecnologías mejora los tiempos de ejecución de procesos dentro de las
instituciones, además que la solución que se brinda a las diferentes
entidades es un sistema web, el cual optimiza y reduce el uso de recursos
físicos y costos operativos.
En base a las necesidades que presenta la comunidad, estudiantes de la
Facultad de Ingeniería Informática de la Universidad Central del Ecuador
plantean como proyecto la Implementación y reingeniería del Sistema
“ERP Social” en la Escuela Manuel Quiroga de la Parroquia Tumbaco y la
Reingeniería del sistema “ERP-SOCIAL” que actualmente se encuentra
en producción.
Con el sistema se desea que las instituciones obtengan beneficios como:
Ahorro de gastos en suministros de oficina.
Acceso on-line a los datos.
Seguridad en la custodia digital de documentos.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
5
Mejora en los procesos de las instituciones.
Mejora de los servicios institucionales.
1.3. Interrogantes de la Investigación
En el presente trabajo de graduación se plantea las siguientes
interrogantes:
¿Existe un sistema informático que permita la gestión de los
recursos de las diferentes unidades educativas?
¿Las herramientas elegidas para realizar la reingeniería son las
apropiadas para abarcar las necesidades que la aplicación
demanda?
¿El módulo de activos fijos permite realizar auditoria sobre los
procesos que se efectúan a los bienes?
1.4. Objetivo de la Investigación
1.4.1. Objetivo General
Brindar soluciones a la estructura de la información en las diferentes
instituciones, mediante el desarrollo de un sistema automatizado que
comprenda las necesidades y por ende sea la herramienta que mejore los
procesos en el manejo del flujo y procesamiento de los datos.
1.4.2. Objetivos Específicos
Realizar la investigación del Marco Legal Educativo para el
desarrollo del ERP, de acuerdo a las normas establecidas para
mejorar la productividad de los procesos orientados a inscripciones,
matrículas, asistencia, registro escolar y activos fijos utilizando
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
6
herramientas tecnológicas que permitan la automatización y
reducción de costos.
Definir procesos para el manejo de los bienes mediante los cuales
se pueda acceder a la información y comprobar, tanto cualitativo
como cuantitativo la existencia física de cada uno de ellos.
1.5. Justificación
El manejo adecuado de la información es de suma importancia para
cualquier organización y empresa en general tanto privada como pública.
Las diferentes parroquias; a nivel nacional tanto urbano como rural no
cuentan con un sistema informático de manejo de información, la mayoría
de sus procesos se realizan con herramientas que no satisfacen
completamente las necesidades de automatización, por lo que las
personas de las diferentes parroquias realizan los mismos procesos en
forma repetitiva y en consecuencia dando cabida a la generación de
procesos innecesarios.
Es necesario que la información sea procesada y almacenada de una
forma más efectiva para agilizar los procesos que realizan cada institución
(Unidad Educativa) de diferentes parroquias y así lograr un control integral
de las actividades que realizan dichas instituciones.
Es por esta razón que se propone a las diferentes parroquias, la solución
a este problema con la reingeniería del Sistema “ERP-SOCIAL”, la que
se basa en beneficiar a las instituciones de dichas parroquias,
aumentando la capacidad de competir en el mercado mediante reducción
de costos, incremento en la calidad y proporcionando una respuesta a la
demanda de información a través del uso de la tecnología.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
7
(2) Plan de tesis ERP-Social en la escuela fiscal mixta “Manuel Quiroga
Parroquia Tumbaco del Distrito Metropolitano de Quito Consultado el día
15 de Junio de 2013
Se resalta también, que esta propuesta constituye un punto de partida
para que las instituciones se introduzcan en un estándar de cambio
evolutivo constante para así estar a la vanguardia tecnológica aplicando
las mejores prácticas que les permitan ser competitivas dentro de su área.
Así, al implantar este sistema poseerá un impacto social positivo, lo cual
proporcionará a los usuarios, una información ágil, confiable y que podrá
ser consultada en línea.
1.6. Contenido del Proyecto
El sistema consta de los siguientes módulos:
Administración del Sistema: Este módulo se basa en la
administración de los perfiles de usuario y sus respectivos permisos.
Control Académico: Este módulo permite el registro de
calificaciones, asistencia y comportamiento de los estudiantes que
pertenecen a cada una de las instituciones y obtener reportes de los
mismos.
Gestión del talento humano y seguimiento de docentes: Permite
tener un control de asistencia de empleados y personal docente a
través de la justificación de faltas, cronogramas del año escolar y los
horarios de cada docente. En este módulo también es posible
obtener reportes de asistencias.
Despacho Parroquial: Este módulo se encarga de automatizar la
emisión de certificados de Bautizos, Confirmaciones, Matrimonios,
Defunciones (Cementerio) y su vez se puede obtener reportes de
los mismos.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
8
Control de Activos Fijos: Se basa en la administración de los
bienes que poseen cada una de las instituciones, de tal manera que
se pueda obtener reportes actualizados sobre el estado de los
bienes.
Gestión Documental: Este módulo permite administrar grandes
cantidades de documentos electrónicos de todo tipo en una
organización y la recuperación de los mismos de forma eficiente.
Auditoría del Sistema: Creado para llevar el registro de la
interacción entre el usuario y el sistema, de tal manera que se
garantice la integridad y confiabilidad de la información.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
9
CAPITULO 2
2.1. Antecedentes
La misión de la Facultad de Ingeniería Ciencias Físicas y Matemática, es
crear y difundir el conocimiento científico –tecnológico, formar
profesionales, investigadores y técnicos críticos de nivel superior y crear
espacios para el análisis y solución de los problemas nacionales.
(3) Universidad Central del Ecuador-Facultad de Ingeniería, Ciencias
Físicas y Matemáticas-Visión y Misión Consultado el día 4 de Agosto de
2013 desde http://www.uce.edu.ec/web/ingenieria-ciencias-fisicas-y-
matematica.
Basados en estas premisas fue desarrollado un sistema de gestión
orientado a la comunidad y las necesidades que conlleva la planificación y
manejo de los organismos principales de las parroquias rurales del cantón
Quito, este sistema llamado ERP social nace de la iniciativa del Director
de la Carrera de Ingeniería Informática periodo 2011-2012, de la Escuela
de Ciencias Físicas y Matemática de la Ilustre Universidad Central del
Ecuador, Ing. Santiago Morales Cardoso, cuyo objetivo principal es
brindar el apoyo a la comunidad considerando como materia prima los
recursos tecnológicos que se encuentran dentro de las parroquias, este
sistema fue implementado en su primera fase en la parroquia de
Amaguaña cubriendo las necesidades de la misma.
Como evolución y avance del sistema se plantea la expansión de
implementación del ERP en otras comunidades recogiendo nuevas
necesidades y planteando mejoras al sistema ya existente para lo cual se
ha definido como nueva comunidad la parroquia de Tumbaco la cual se
encuentra al oriente de la ciudad de Quito y cuenta con una población de
38.948 habitantes.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
10
(4) Población de Tumbaco Consultado el día 4 de Agosto de 2013 desde
http://www.eruditos.net/.
Se realizó la visita a la parroquia y se gestionó una reunión con la
Doctora Cecilia Coba presidenta de la junta parroquial a quien se le
planteó realizar una presentación general del funcionamiento del sistema,
que se planificó para el día lunes 21 de enero del 2013 y conto con la
presencia de los directores de escuelas, jardines (educación inicial),
iglesia de los cuales se obtuvo su aprobación preliminar para la
implementación del sistema ERP-Social.
El sistema Erp-Social abarca varios módulos que estarán desarrollados
por un grupo de tesistas de la facultad de ingeniería Ciencias Físicas y
Matemática de la Universidad Central del Ecuador, el tema mencionado
en esta tesina se enfocara específicamente en el desarrollo de la
reingeniería del módulo de activos fijos.
2.2. Marco Teórico
Esta forma parte de un ERPSOCIAL cuya definición en los sistemas
de Planificación de Recursos Empresariales, son Sistemas de Información
Gerenciales que integran y manejan negocios asociados con las
operaciones de producción y de los aspectos de distribución de una
compañía en la producción de bienes o servicios.
Los sistemas ERP normalmente manejan la producción, logística,
distribución, inventario, envíos, facturas y la contabilidad en una
organización. Puede intervenir en el control de muchas actividades de
negocios como ventas, entregas, pagos, producción, administración de
inventarios, calidad de administración y la administración de recursos
humanos. Este sistema trata directamente con los clientes, o con los
sistemas de negocios electrónicos tales como: comercio electrónico,
gobierno electrónico, telecomunicaciones electrónicas y finanzas
electrónicas; así mismo, es un sistema que trata directamente con los
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
11
proveedores, no estableciendo únicamente una relación administrativa
con ellos (SRM), en contraste con el sistema de apertura de datos (front
office), que crea una relación administrativa del consumidor o servicio al
consumidor
(5) Sistema Erp, Consultado el día 8 de Agosto de 2013 desde
http://es.wikipedia.org/wiki/Social_Networks_ERP
Beneficios del ERP
Optimización de los procesos de una organización.
Acceso a toda la información de forma confiable, precisa y
oportuna.
La posibilidad de compartir información entre todos los
componentes de la organización.
Eliminación de datos y operaciones innecesarias de reingeniería.
Otorgar apoyo a los usuarios, tiempos rápidos de respuesta a sus
problemas así como un eficiente manejo de información que
permita la toma oportuna de decisiones y disminución de los costos
totales de operación.
(6) Beneficios del sistema Erp Consultado el día 8 de Agosto de 2013
desde www.kepler.com.mx/Archivos/definicion_de_sistema_erp.pdf
2.2.1. Limitaciones
En el sistema ERP Social surgen las siguientes limitaciones para el
módulo de activos fijos debido a que no se encuentran definidos los
procesos para esta actividad.
No se incluirá el proceso contable sobre los bienes al realizar las
transacciones tales como Alta, Baja y traslado.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
12
2.2.2. Análisis y diseño
2.2.2.1. Análisis Teórico
2.2.2.1.1. Modelo de desarrollo.
El modelo en V se encarga de representar las relaciones temporalmente
entre las fases del ciclo de desarrollo del proyecto, en él se realizan dos
procesos al mismo tiempo hasta llegar a la punta de la V, conforme se
reduce el espacio esto se refiere a la reducción de tiempo de cada fase y
mientras más se reduce aumenta el nivel, esto puede
ser prácticamente una ventaja o desventaja dependiendo del modo de
trabajo de cada persona.
Fue desarrollado para regular el proceso de desarrollo de software.
Describe las actividades y los resultados que se producen durante
el desarrollo del software.
El modelo representa, en forma de V, las relaciones temporales entre las
distintas fases del ciclo de desarrollo de un proyecto.
Es una representación gráfica del ciclo de vida del desarrollo del sistema.
Resume los pasos principales que hay que tomar en conjunción con las
correspondientes entregas de los sistemas de validación.
(7) Modelo en V Consultado el día 16 de Noviembre de 2013 desde
prezi.com/ryyutemqk5go/ingeniería-de-software-modelo-en-v
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
13
Ilustración 1 : MODELO EN V
La parte izquierda de la V representa la corriente donde se definen
las especificaciones del sistema.
La parte derecha de la V representa la corriente donde se
comprueba el sistema (contra las especificaciones definidas en la
parte izquierda).
La parte de abajo, donde se encuentran ambas partes, representa
la corriente de desarrollo.
La corriente de especificación consiste principalmente de:
Especificaciones de requerimiento de usuario
Especificaciones funcionales
Especificaciones de diseño
La corriente de pruebas, por su parte, suele consistir de:
Calificación de instalación
Calificación operacional
Calificación de rendimiento
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
14
Modelo en V Consultado el día 16 de Noviembre de 2013 desde
prezi.com/ryyutemqk5go/ingeniería-de-software-modelo-en-v
Ilustración 2: MODELO NIVELES LOGICOS
En los 4 niveles lógicos comenzando desde el 1, para cada fase del
desarrollo, existe una fase correspondiente o paralela de verificación o
validación.
Esta estructura obedece que desde el principio para cada fase del
desarrollo debe existir un resultado verificable.
En la misma estructura se advierte también que la proximidad entre una
fase del desarrollo y su fase de verificación correspondiente va
decreciendo a medida que aumenta el nivel dentro de la V, es decir de
arriba hacia abajo en donde se localiza la punta. La longitud de esta
separación intenta ser proporcional a la distancia en el tiempo entre una
fase y su homóloga de verificación.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
15
Nivel 1 está orientado al cliente. El inicio del proyecto y el fin del
proyecto constituyen los dos extremos del ciclo. Se compone del
análisis de requisitos y especificaciones, se traduce en un documento
de requisitos y especificaciones.
Nivel 2 se dedica a las características funcionales del sistema
propuesto. Puede considerarse el sistema como una caja negra, y
caracterizarla únicamente con aquellas funciones que son directa o
indirectamente visibles por el usuario final, se traduce en un documento
de análisis funcional.
Nivel 3 define los componentes hardware y software del sistema final,
a cuyo conjunto se denomina arquitectura del sistema.
Nivel 4 es la fase de implementación, en la que se desarrollan los
elementos unitarios o módulos del programa.
(8) Niveles lógicos del Modelo en V Consultado el día 16 de Noviembre
de 2013 desde ingenieriadesoftware.mex.tl/61885_Modelo-V.html
Ventajas:
Específica bien los roles de los distintos tipos de pruebas a realizar.
Hace explícito parte de la iteración y trabajo que hay que realizar.
Este método involucra chequeos de cada una de las etapas del
método Cascada.
Es un método más robusto y completo que el método cascada y
produce software de mayor calidad que con el modelo cascada.
Es un modelo sencillo y de fácil aprendizaje.
Involucra al usuario en las pruebas.
(9) Ventajas absolutas y relativas del Modelo en V Consultado el día 25
de Noviembre de 2013 desde www.eumed.net/libros-
gratis/2005/jmfb/3a.htm
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
16
Desventajas:
Es difícil que el cliente exponga explícitamente todos los requisitos.
El cliente debe tener paciencia, ya que obtendrá el producto al final
del ciclo de vida.
El modelo no contempla la posibilidad de retornar etapas
inmediatamente anteriores, cosa que en la realidad puede ocurrir.
Se pierde dinero, ya que si algún proceso fue mal desarrollado,
este debe ser revisado de nuevo, lo que puede traer como
consecuencia un "RollBack" de todo un proceso.
Las pruebas pueden ser caras y a veces no lo suficientemente
efectivas.
(10) Modelos de Proceso de software Consultado el día 25 de
Noviembre de 2013 desde www.comusoft.com/.../Ciclos-de-vida-
proceso-de-desarrollo-del-software
2.2.2.1.2. Metodología de Desarrollo
La metodología empleada para el desarrollo del Sistema ERP (Módulo
Activo Fijo) es RUP (Rational Unified Process), definido como un conjunto
de metodologías adaptables al contexto y necesidades de cada
organización.
Se escogió esta metodología de desarrollo ya que cubre el ciclo de vida
completo del producto, soporta un enfoque de desarrollo iterativo e
incremental.
RUP se enfoca en el análisis, implementación y documentación del
sistema ya que es un modelo que cubre todo el ciclo de vida del producto.
(11) Kruchten, P (1996).”A rational Development Process”.Consultado el
día 15 de Diciembre de 2013 desde
www.rational.com/media/whitepappers/xtalk.pdf
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
17
El proceso de ciclo de vida de RUP se divide en cuatro fases:
Inicio: El objetivo en esta etapa es delimitar la visión del proyecto.
Mayor énfasis en modelamiento del proyecto: objetivos, alcance,
limitaciones y requerimientos.
Elaboración: En esta fase el objetivo es delimitar la arquitectura
óptima. Se define la infraestructura y ambiente de desarrollo.
Construcción: En esta etapa se lleva a cabo la construcción del
producto por medio de una serie de iteraciones obteniendo la
capacidad operativa inicial.
Transición: se pretende obtener el producto preparado para la
entrega. Pruebas de aceptación y capacitación a usuarios.
Estas fases se dividen en iteraciones, cada una de las cuales produce
una pieza de software demostrable.
(12) Kruchten, P (1996).”A rational Development Process”. Consultado el
día 15 de Diciembre de 2013 desde
www.rational.com/media/whitepappers/xtalk.pdf
2.2.2.1.3. Especificación de requisitos de software (ERS)
La ERS es una descripción completa del comportamiento del sistema que
se va a desarrollar. Incluye un conjunto de casos de uso que describe todas
las interacciones que tendrán los usuarios con el software.
Los casos de uso también son conocidos como requisitos funcionales.
Además de los casos de uso, la ERS también contiene requisitos no
funcionales (o complementarios). Los requisitos no funcionales son
requisitos que imponen restricciones en el diseño o la implementación,
como, por ejemplo, restricciones en el diseño o estándares de calidad.
Está dirigida tanto al cliente como al equipo de desarrollo. El lenguaje
utilizado para su redacción debe ser informal, de forma que sea fácilmente
comprensible para todas las partes involucradas en el desarrollo.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
18
IEEE830 se encarga de las especificaciones de requerimiento del sistema
de software su finalidad es la integración de los requerimiento del sistema
desde la perspectiva del usuario, cliente y desarrollador.
(13) Especificación de requerimientos, estándar IEEE830 Consultado el
día 10 de Diciembre de 2013 desde https://prezi.com/wribnzku2hre/ieee-
830/
Las características de una buena ERS son definidas por el estándar
IEEE830 son las siguientes:
Completa: Todos los requerimientos deben estar reflejados en ella
y todas las referencias deben estar definidas.
Consistente: Debe ser coherente con los propios requerimientos y
también con otros documentos de especificación.
Inequívoca: La redacción debe ser clara de modo que no se pueda
mal interpretar.
Correcta: El software debe cumplir con los requisitos de la
especificación.
Trazable: Se refiere a la posibilidad de verificar la historia,
ubicación o aplicación de un ítem a través de su identificación
almacenada y documentada.
Priorizable: Los requisitos deben poder organizarse
jerárquicamente según su relevancia para el negocio y
clasificándolos en esenciales, condicionales y opcionales.
Modificable: Aunque todo requerimiento es modificable, se refiere a
que debe ser fácilmente modificable.
Verificable: Debe existir un método finito sin costo para poder
probarlo.
(14) Características de Especificación de requerimiento con estándar
IEEE830 Consultado el día 10 de Diciembre de 2013 desde
https://prezi.com/wribnzku2hre/ieee-830/
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
19
2.2.2.1.3.1. Tipos de requisitos
Existen varios tipos de requisitos como son:
Requisitos de Usuarios: Necesidades que los usuarios expresan
verbalmente
Requisitos del Sistema: Son los componentes que el sistema debe
tener para realizar determinadas tareas
Requisitos Funcionales: Servicios que el sistema debe proporcionar
Requisitos no funcionales: Restricciones que afectan al sistema
(15) Tipos de requisitos Consultado el día 6 de Noviembre de 2014 desde
es.wikipedia.org/wiki/Especificación_de_requisitos_de_software
2.1.1.1. DISEÑO
Para el diseño de la reingeniería del sistema Erp-Social se utilizan las
siguientes herramientas tecnológicas.
2.1.1.1.1. Sistema Operativo del servidor
(Community ENTerprise Operating System) es una bifurcación a nivel
binario de la distribución Linux Red Hat Enterprise Linux RHEL, compilado
por voluntarios a partir del código fuente liberado por Red Hat. El
Community ENTerprise Operating System es un sistema operativo de
Linux distribuido por un vendedor de América del Norte. Es un programa
de fuente abierta, basado en la distribución Red Hat Enterprise Linux.
Destinado a ser un sistema de programa de "clase empresarial" gratuito,
Centos es robusto, estable y fácil de instalar y utilizar.
Sorprendentemente, Centos soporta cada edición, o lanzamiento, por
siete años. Luce y se opera de forma similar al RHEL (Red Hat Enterprise
Linux).
Red Hat Enterprise Linux se compone de software libre y código abierto,
pero se publica en formato binario usable (CD-ROM o DVD-ROM)
solamente a suscriptores pagados. Como es requerido, Red Hat libera
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
20
todo el código fuente del producto de forma pública bajo los términos de
la Licencia pública general de GNU y otras licencias. Los desarrolladores
de Centos usan ese código fuente para crear un producto final que es
muy similar al Red Hat Enterprise Linux y está libremente disponible para
ser bajado y usado por el público, pero no es mantenido ni asistido por
Red Hat. Existen algunos Clones de Red Hat Enterprise Linux .
Centos usa yum para bajar e instalar las actualizaciones, herramienta
también utilizada por Fedora.
(16) Community ENTerprise Operating System Consultado el día 14 de
Enero de 2014 desde http://es.wikipedia.org/wiki/CentOS
2.1.1.1.2. BASE DE DATOS
PostgreSQL
Es un sistema de gestión de base de datos relacional orientada a objetos
y libre, publicado bajo la licencia BSD. Es más completo que MySQL ya
que permite métodos almacenados, restricciones de integridad, vistas,
Como muchos otros proyectos de código abierto, el desarrollo de
PostgreSQL no es manejado por una sola empresa sino que es dirigido
por una comunidad de desarrolladores y organizaciones comerciales las
cuales trabajan en su desarrollo. Dicha comunidad es denominada PGDG
(PostgreSQL Global Development Group). Es el sistema de gestión de
bases de datos de código abierto más potente del mercado y en sus
últimas versiones no tiene nada que envidiarle a otras bases de datos
comerciales. Utiliza el lenguaje SQL para llevar a cabo sus búsquedas de
información, las bases de datos generadas dentro de servidores de SQL
son bases de datos relacionales. Utiliza un modelo cliente/servidor y usa
multiprocesos en vez de multihilos para garantizar la estabilidad del
sistema. Un fallo en uno de los procesos no afectará el resto y el sistema
continuará funcionando.
(17) Postgress Consultado el día 14 de Enero de 2014 desde
es.wikipedia.org/wiki/PostgreSQL
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
21
Características de PostgreSQL.
A continuación se enumeran las principales características de este gestor
de bases de datos:
Implementación del estándar SQL92/SQL99.
Soporta distintos tipos de datos: además del soporte para los tipos
base, también soporta datos de tipo fecha, monetarios, elementos
gráficos, datos sobre redes (MAC, IP), cadenas de bits, etc.
También permite la creación de tipos propios.
Incorpora una estructura de datos array.
Incorpora funciones de diversa índole: manejo de fechas,
geométricas, orientada las operaciones con redes.
Permite la declaración de funciones propias, así como la definición
dedisparadores
Soporta el uso de índices, reglas y vistas.
Incluye herencia entre tablas (aunque no entre objetos, ya que no
existen), por a este gestor de bases de datos se le incluye entre
los gestores objeto-relacionales. Permite la gestión de diferentes
usuarios, como también los permisos asignados a cada uno de
ellos
(18) Postgress Consultado el día 14 de Enero de 2014 desde
es.wikipedia.org/wiki/PostgreSQL
Ventajas de PostgreSQL
Instalación ilimitada
Es frecuente que las bases de datos comerciales sean instaladas en más
servidores de lo que permite la licencia. Algunos proveedores comerciales
consideran a esto la principal fuente de incumplimiento de licencia. Con
PostgreSQL, nadie puede demandarlo por violar acuerdos de licencia,
puesto que no hay costo asociado a la licencia del software.
Esto tiene varias ventajas adicionales:
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
22
Modelos de negocios más rentables con instalaciones a gran
escala.
No existe la posibilidad de ser auditado para verificar cumplimiento
de licencia en ningún momento.
Flexibilidad para hacer investigación y desarrollo sin necesidad de
incurrir en costos adicionales de licenciamiento.
Mejor soporte que los proveedores comerciales
Además de nuestras ofertas de soporte, tenemos una importante
comunidad de profesionales y entusiastas de PostgreSQL de los
que su compañía puede obtener beneficios y contribuir.
Ahorros considerables en costos de operación
Nuestro software ha sido diseñado y creado para tener un
mantenimiento y ajuste mucho menor que los productos de los
proveedores comerciales, conservando todas las características,
estabilidad y rendimiento. Además de esto, nuestros programas de
entrenamiento son reconocidamente mucho más costo-efectivos,
manejables y prácticos en el mundo real que aquellos de los
principales proveedores comerciales.
Estabilidad y con fiabilidad legendarias
En contraste a muchos sistemas de bases de datos comerciales,
es extremadamente común que compañías reporten que
PostgreSQL nunca ha presentado caídas en varios años de
operación de alta actividad. Ni una sola vez. Simplemente funciona.
Extensible
El código fuente está disponible para todos sin costo. Si su equipo
necesita extender o personalizar PostgreSQL de alguna manera,
pueden hacerlo con un mínimo esfuerzo, sin costos adicionales.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
23
Esto es complementado por la comunidad de profesionales y
entusiastas de PostgreSQL.
Multiplataforma
PostgreSQL está disponible en casi cualquier Unix (34 plataformas
en la última versión estable), y una versión nativa de Windows está
actualmente en estado beta de pruebas.
Diseñado para ambientes de alto volumen
PostgreSQL usa una estrategia de almacenamiento de filas llamada
MVCC para conseguir una mejor respuesta en ambientes de grandes
volúmenes. Los principales proveedores de sistemas de bases de datos
comerciales que usan también esta tecnología, por las mismas razones.
(19) Ventajas de Postgress Consultado el día 14 de Enero de 2014 desde
es.slideshare.net/brobelo/postgresql.
2.1.1.1.3. Servidor de aplicaciones (JBOSS)
JBoss AS es el primer servidor de aplicaciones de código abierto,
preparado para la producción y certificado J2EE 1.4, disponible en el
mercado, ofreciendo una plataforma de alto rendimiento para aplicaciones
de e-business. Combinando una arquitectura orientada a servicios SOA,
con una licencia GNU de código abierto, JBoss AS puede ser descargado,
utilizado, incrustado y distribuido sin restricciones por la licencia.
Las características destacadas de JBoss incluyen:
Producto de licencia de código abierto sin coste adicional.
Cumple los estándares.
Confiable a nivel de empresa
Incrustable, orientado a arquitectura de servicios.
Flexibilidad consistente
Servicios del middleware para cualquier objeto de Java.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
24
(20) Servidor de aplicaciones JBoss Consultado el día 14 de Enero de
2014 desde http://es.wikipedia.org/wiki/JBoss
Componentes de JBOSS
Hibernate
Hibernate es un servicio de persistencia objeto/relaciones y consultas
para Java. Hibernate facilita a los desarrolladores crear las clases de
persistencia utilizando el lenguaje Java - incluyendo la asociación,
herencia, polimorfismo y composición y el entorno de colecciones Java.
(21) Servidor de aplicaciones JBoss Consultado el día 14 de Enero de
2014 desde http://es.wikipedia.org/wiki/JBoss
2.3. Identificación de Variables
Después de realizar el levantamiento de requerimientos con las
responsables en las unidades educativas se identificó la variable
independiente que es la base estructural para el manejo del módulo de
activos fijos.
2.3.1. Variables Independientes
Dentro de este proyecto se ha determinado el ingreso de bienes como la
variable independiente.
El ingreso de bienes permite realizar los procesos tales como altas,
bajas, traslado y devolución que se registraran en transacciones para
poder realizar una auditoría sobre los activos fijos permitiendo que el
sistema realice:
Ingreso detallado de lo información de cada uno de los bienes.
Control adecuado del estado físico de los activos fijos.
Conocer los responsables que se encuentran a cargo de los bienes
para conocer el estado de transaccionalidad.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
25
Conocer la cantidad en existencia de los bienes que poseen cada
una de las instituciones educativas
2.3.2. Variables Dependientes
Se establece las variables dependientes a las altas, y traslado ya que son
el consecuente o efecto que cambia por influencia de la variable
Independiente que es el ingreso de bienes.
2.4. Hipótesis
El propósito de este estudio, es el control de activos fijos en un sistema
que abarca la totalidad de los bienes que se encuentran en la unidad
educativa, por lo tanto la hipótesis es:
“Los usuarios que manejan la información necesitan un sistema de control
de activos fijos que mejore los procesos y manejo de datos permitiendo
verificar la transaccionalidad de los bienes existentes en la unidad
educativa”
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
26
CAPITULO 3
3. Análisis del Sistema
3.1. Especificación de requerimientos
Conforme la información obtenida del proceso de activo fijo en las
diferentes unidades educativas, se ha podido identificar los procesos que
se ejecutan desde la llegada de los diferentes bienes a la unidad
educativa y los diferentes estados que se manejan. En base a todos los
procesos de los diferentes módulos se elaborara el presente proyecto de
tesis, con la finalidad de automatizar los procesos que en la actualidad se
ejecutan manualmente.
El sistema propuesto permite la creación y control de los recursos
destinados a las unidades educativas. Una de las ventajas adicionales es
contar con reportería gracias a la forma centralizada con que se manejara
la información.
El detalle de los anexos se encuentra en el anexo 1.
3.1.1. Contexto del sistema
Se llama módulo a una parte de un sistema ya que entiéndase como tal
un conjunto de subprogramas y estructuras de datos. Los módulos son
unidades que pueden ser compiladas por separado y los hace reusables y
permite que múltiples programadores trabajen en diferentes módulos en
forma simultánea, produciendo ahorro en los tiempos de desarrollo.
Los módulos promueven la modularidad y el encapsulamiento, pudiendo
generar programas complejos de fácil comprensión.
Análisis, diseño e implementación del módulo de inventario es en
términos generales, un conjunto de procedimientos y mecanismos de
recolección y análisis de información sobre:
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
27
Reducir el tiempo de respuesta.
Reducir errores y mejorar la entrada de datos.
Reducir costos mediante la eliminación de duplicados innecesarios.
Agilitar consultas sobre la base de reportes precisos.
Reducir el tiempo de procesamiento de datos.
Disponer de un único dispositivo capaz de localizar un determinado
El sistema permite contar con información relevante y oportuna para la
toma de decisiones en cuanto a las mejores estrategias posibles para
alcanzar lo que nos proponemos (la planificación), realizar los reajustes
y/o modificaciones necesarios considerándolos cambios que se van
dando en el contexto y en la situación de los grupos beneficiarios; y la
forma en que vamos avanzando hacia el logro de los resultados
esperados.
Características del módulo de activo fijo.
La función principal de la gestión de activo fijo es determinar la cantidad
suficiente y tipo de los insumos, productos en proceso y terminados o
acabados para satisfacer la demanda del producto, facilitando las
operaciones de producción y venta y minimizando los costos al
mantenerlos en un nivel óptimo.
Su importancia radica en el siguiente aspecto:
Optimización de los tiempos. La producción y la entrega por lo general no
ocurren de manera instantánea, por lo que se debe contar con existencias
El módulo de activos fijos se encuentra conformado por los siguientes
procesos:
Ingreso de Bienes el cual consiste en seleccionar información de algunos
catálogos tales como tipo de ingreso, estado de conservación, categoría,
línea, marca material se digita información como color, nombre del bien,
modelo, valor unitario cantidad y nota el sistema calcula automáticamente
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
28
el valor total este permite q se puede registra los bienes para ser
administrados en la instituciones educativas.
Tipo de ingreso Este catálogo contiene la información de compra o
donación de los bienes
Compra es cuando los bienes se han asignado a la unidad educativa por
parte del ministerio de educación.
Donación: este campo se refiere a los bienes entregados por parte de
padres de familia o personas naturales que colaboran con la institución
educativa.
Estado de Conservación: contiene la información referente al estado
físico del bien tal como: muy bueno, bueno, regular y malo.
Categoría: este catálogo contiene la información referente al tipo de bien
por ejemplo tecnología, suministro de oficina, material didáctico.
Línea: este catálogo contiene la información referente al subtipo del bien
por ejemplo perforadora grapadora el cual se relaciona con la categoría
de acuerdo a la naturaleza del bien.
Marca/Material.-este catálogo contiene la información referente al
material o proveedor del bien como por ejemplo LG, Sony, Toshiba,
plástico, metal.
Modelo.- este catálogo contiene la información del código cuando el bien
es fabricado aplica a la categoría tecnología este campo es opcional en
los demás.
Color.- Este catálogo contiene la información referente de los colores de
acuerdo a los bienes ingresados este campo es opcional.
Nombre del bien.- Se ingresa el título del bien de acuerdo a su categoría
y línea.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
29
Valor Unitario.-Se ingresa las unidades del bien.
Cantidad.-Se ingresa el número de bienes a registrar.
Valor Total.-se calcula mediante la fórmula calor unitario *cantidad.
Nota: se ingresa observación sobre del bien.
Tipo de transacción: este catálogo contiene la información de los
movimientos que se podrán realizar al bien tales como: ingreso,
asignación, reasignación, devolución y baja.
Trazabilidad del bien.- Se puede observar el movimiento inicial del bien
en cual se visualiza fecha de asignación, estado y custodio.
Estado. - permite observar si el bien se encuentra activo o inactivo para
poder realizar un determinado proceso.
En Uso.- Este campo nos indica si el bien se encuentra asignado a un
custodio.
Proceso transacciones de bienes
Transacciones Masivas.-En este proceso se agrupa los bienes que
serán asignados a un custodio.
El mismo que se maneja atreves de un check list en donde se ingresara
la ubicación y el custodio a cargo de los bienes. Los códigos se generan
automáticamente y de forma independiente para cada uno.
La estructura del código se conforma de acuerdo al tipo de categoría y
línea.
Código Al asignar un bien al custodio el sistema genera automáticamente
un código el cual permitirá identificar de forma única y facilita su
búsqueda
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
30
Esta opción nos permite realizar búsqueda por: custodio, código, tipo de
transacción, categoría y línea
Se podrá realizar la asignación del custodio una vez que el bien
seleccionado posea una ubicación física nos permite selecciono el
custodio.
Una vez asignado el custodio se genera el código y se muestra en
pantalla.
Traslado.- Este proceso se efectúa cuando el bien es reasignado a un
nuevo custodio o se cambia la ubicación física aquí se extrae la
información como nombre del bien, código.
La ubicación se debe registrar cada vez que se efectué el movimiento de
traslado.
El cambio de custodio se debe seleccionar de la lista de catálogos y no
se podrá realizar el cambio al mismo usuario, la fecha de reasignación se
tomara del sistema.
Devolver: Este proceso se realiza una vez que el custodio que se
encuentra responsable del bien termina su año lectivo y regresa los
bienes que fueron asignados a bodega, es obligatorio ingresar el motivo
de devolución.
El estado del bien se encuentra sin uso, el código es único y se mantiene
durante su vida útil.
Todos los procesos se encuentran respaldados por el acta que es un
documento físico que sirve como evidencia de los movimientos realizados
sobre el bien el cual tendrá firmas de responsabilidad.
Bajas.- La baja consiste en la extracción física de los bienes muebles del
patrimonio de las unidades educativas, la cual se autoriza mediante
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
31
resolución administrativa con indicación expresa de las causales que la
originaron.
La búsqueda se puede realizar por custodio, código, tipo de transacción
categoría y línea.
Se debe seleccionar el motivo de la baja el cual puede ser perdido, robo,
total o donación y se ingresa la nota por que se efectúa la devolución del
bien.
No se cuenta con un Inventario actualizado de las diferentes unidades
educativas de tal manera que no puede llevarse un control de asignación
de los bienes correspondientes y no se puede priorizar el abastecimiento
oportuno de mobiliario, pizarras, etc.
La falta de reporte no permite tomar decisiones en la asignación de
recursos en las diferentes unidades educativas, Los datos de inventarios
que se manejan son completamente manuales y esto provoca una
pérdida de información, la actualización de los datos de los diferentes
recursos no son inmediatos en cada unidad educativa.
Funcionalidades del Módulo de Activo Fijo
Conocer el número de bienes que tiene el establecimiento.
Conocer la ubicación de cada uno de los bienes.
Tener la información del responsable que está a cargo de los
bienes asignado a su custodia.
Poseer un detalle de cada uno de los bienes que posee la unidad
educativa.
Permitir realizar una auditoría cuando la institución lo considere
necesario.
Conocer el estado del bien por sus diferentes estados que se
encuentren definidos en un catálogo.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
32
La información de cada uno de los bienes se encuentre
almacenado en un repositorio al cual se puede acceder con
facilidad y evitar la pérdida de la información
Clasificación y catalogación: Es la identificación de los productos
por categoría, línea , clase, subclase, así como de las instalaciones
y áreas en cuestión, con fines de registro y sistema localizador.
Separar e identificar materiales dañados según su estado para
devolución y posterior proceso de bajas.
3.2. Restricciones y suposiciones
3.2.1. Restricciones en el desarrollo del proyecto
La aplicación web será compatible con las versiones actuales de los
principales browsers de internet, se incluye Internet Explorer 9.0, Mozilla
Firefox 19 o superiores.
La aplicación se desarrollara para trabajar sobre el internet ocupando una
arquitectura basada en servicios. La interfaz de usuario entregada en el
proyecto es un sitio web con el servidor proporcionado por la Universidad
Central del Ecuador.
Se contempla que el registro de información sensible como artículos,
usuarios finales, permisos se realizara únicamente por las personas
autorizadas de las instituciones educativas.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
33
3.2.2. Restricciones en las herramientas de desarrollo de software
Motor de base de datos: Postgress
Modelador de base de datos: PowerDesigner
Lenguaje: Java-Eclipse Indigo
Frameworks de desarrollo:JPA (Hibernate);EJB;JSF Primefaces)
3.2.3. Restricciones del hardware del servidor
Servidor Centos 6.0
Servidor de aplicaciones: JBoss
3.3. Riesgos
3.3.1. Tecnológicos
Al ser una aplicación basada en la web, se corre el riesgo que con
el tiempo los navegadores de internet dejen de soportar ciertas
características y sea necesario corregir el desarrollo de la interfaz.
Debido a que se emplean versiones gratuitas de los programas de
desarrollo y base de datos, se está sujeto a cualquier modificación
en la licencia de uso.
Se usa para los servicios estándares propuestos por lo que no se
garantiza la compatibilidad con otras plataformas de desarrollo de
software.
Posibles riesgos dentro de la configuración o actualización del
programa.
Analizar las posibles dificultades o limitantes ya que al haber
actualizaciones o modificaciones alteran partes del programa,
afectando los inventarios.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
34
3.3.2. De recursos
El desarrollo se realizara en computadoras personales basadas en
Windows 7 (cualquier versión).
3.3.3. De módulo
Creación, modificación y eliminación de usuarios del sistema: Solo
lo podrá hacer las personas administradoras del sistema.
Perfil del administrador y usuarios: Identificar las reglas de los
usuarios así como su acceso al programa.
Salida de información de inventarios
Generación de reportes o datos hacia los usuarios que necesitan
visualizar esta información.
Puertos de salida: Contar con varios puertos de salida para mitigar
las dificultades que se puedan presentar en caso de que se dañe
alguno y no estar limitado a un solo puerto de salida.
Bases de datos
Existencia de reglas donde se estipule la confidencialidad de la
información suministrada por el sistema, tomando las medidas
pertinentes para que se lleve a cabo.
Interfaz de usuario
Capacitación y entrenamiento de una manera eficaz al usuario o
usuarios de manera que maneje correctamente el programa y
pueda actuar en el momento de presentarse dificultades con el
mismo.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
35
3.3.4. De habilidades
Se corre el riesgo que los administradores o usuarios realicen una
configuración errónea causando funcionamientos no adecuados del
sistema. Para evitar esto se proporcionara capacitación a los
actuales usuarios así como también se entregara manuales de
usuario que puedan ser utilizados como referencia a futuro.
3.3.5. De requerimientos
Se ha hecho un levantamiento de los requerimientos de los
usuarios de manera que el sistema atienda las necesidades
funcionales de los mismos. Sin embargo, si a posterior se
presentan nuevas necesidades podrá realizarse modificaciones al
sistema atendiendo los nuevos requerimientos. Dichas
modificaciones no forman parte del presente proyecto.
3.4. Requerimientos funcionales
Se hace referencia al Anexo 1 donde se evidencia los requerimientos
funcionales originales obtenidos para iniciar con el desarrollo.
3.5. Descripción de los actores
Se definen los actores con el fin de controlar todos los procesos que
intervienen en el módulo de activos fijos.
Actor: Administrador
Caso de uso: Ingresar al módulo, verificar devoluciones de bienes,
aprobar devoluciones, aprobar traslados de custodio o bienes, verificar
altas masivas.
Actor: Analista de Inventarios
Caso de uso: Visualizar los bienes ingresados con el objetivo de verificar
existencias, ingresar pedidos de materiales al inventario, crear nuevos
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
36
códigos , realizar traslado, modificar material, generar inventarios, generar
informe e imprimir toda orden de movimiento de los bienes.
Actor: Bodeguero
Caso de uso Visualizar los bienes asignados a bodega, asignar bienes a
los custodios, verificar devoluciones, ingresar información de los bienes.
Requerimientos no Funcionales
Los principales atributos del módulo de Activo Fijo del sistema Erp-Social
se detallan a continuación:
Usabilidad
El sistema está diseñado de forma tal que la interacción de los
usuarios con el sistema sea lo más sencillo posible y ejecutando el
mínimo número de pasos en la ejecución de los procesos.
La estructura de las pantallas permite que los usuarios puedan
realizar sus tareas de una manera intuitiva y con capacitaciones
elementales.
El desarrollo basado en web descomplica el acceso al mismo, lo
que reduce la necesidad de conocimiento técnico al no requerir
descargar el software ni instalarlo. Las páginas web desarrolladas
cumplen con las características requeridas por los navegadores
web actuales.
Adicionalmente se provee un completo conjunto de manuales de
usuario en los que se detalla claramente los pasos a seguir en la
ejecución de los distintos procesos del sistema.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
37
Disponibilidad
El sistema es accesible desde cualquier lugar que cuente con
acceso a internet, por lo que todos los usuarios pueden acceder al
mismo independientemente de su ubicación geográfica. Los
procesos de los servidores web y bases de datos aseguran la
continuidad del servicio la mayor parte del tiempo.
Escalabilidad-Capacidad
El diseño cuenta con una plataforma de servicios lo que permite a
futuro integrar otros módulos con interfaces de usuario de diversa
índole manteniendo la lógica de negocio.
Se permitirá el crecimiento de la base de datos conforme el
volumen de transacciones realizadas lo demande. De ser el caso
que se sobrepase la limitación de la versión Postgress, se deberá
adquirir la licencia de uso que sea pertinente.
Seguridad
El módulo de inventarios implementa el esquema de seguridad de
ADP.NET, de manera que transcurridos 20 minutos de inactividad
del usuario provocan el cierre de la sesión del mismo. Esto evita
que otros usuarios hagan uso indebido de la sesión.
La contraseña de usuario es administrada únicamente por el
usuario, ningún administrador tiene atributos suficientes para
restablecer o modificar la contraseña del usuario.
La contraseña de usuario se almacena en la base de datos cifrada
imposibilitando que cualquier persona con acceso a la base de
datos pueda obtenerla y hacer uso indebido de la misma.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
38
3.6. Requerimientos Técnicos
Para el correcto funcionamiento del sistema Erp-Social se han
considerado los siguientes requerimientos mínimos de hardware y
software.
3.7. Requerimiento de software
Equipo Tipo de Aplicación Nombre
Servidor
Sistema Operativo Centos 6.0
Servidor de
Aplicaciones JBOSS
Base de datos Postgress
Cliente
Sistema Operativo Cualquiera
Navegador Web Firefox, Google Chrome
Tabla 1: REQUERIMIENTO DE SOFTWARE
FUENTE: Elaboración propia
3.8. Requerimientos de hardware
Equipo Elemento Valor
Servidor de
Aplicaciones
Procesador 2 GHz o superior
Memoria 1 GB o mayor
Disco Duro 1GB disponible
Tarjeta de Red 10/100 Mbps
Sistema
Operativo
Disco Duro 10 GB disponibles
Memoria 2 GB o mayor
Base de datos
Disco Duro 4 GB
Memoria 1GB mínimo
Cliente
Procesador 800 MHz o superior
Memoria 512 MB o mayor
Tarjeta de Red 10/100 Mbps
Tabla 2 REQUERIMIENTO DE HADWARE
FUENTE: Elaboración propia
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
39
3.9. Lenguaje de Modelamiento Unificado (UML)
3.10. Diagrama de Clases
Asignación de líneas para un bien.
Ilustración 3 BDLINEAS DE BIEN
Asignación de marca de un bien y relación con el inventario
Ilustración 4 BD RELACION BIEN INVENTARIO
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
40
Relación de la transacción con el detalle del bien
Ilustración 5 BD RELACION TRANSACCION
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
41
Relación detalle-cabecera del bien
Ilustración 6 DB RELACION CABECERA BIEN
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
42
3.11. Diagrama de Casos de Uso
Asignación del bien
Bodeguero
�
Ingresa sistema
Autentica Usuario
Sistema
selecciona Opcion asignar bien
Llenar campos asignacion asignacion
Valida asignacion
salir del sistema
Grabar
Notificar asignacion funcionario
Ilustración 7 DCU ASIGNACION DEL BIEN
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
43
Generación de Reportes
Bodeguero
�
Ingresa sistema
Autentica Usuario
Sistema
selecciona Opcion reportes
Llenar criterios
Genera reporte
salir del sistema
imprime
Ilustración 8 DCUSISTEMA
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
44
Validación del bien
Funcionario
�
Ingresa sistema
Autentica Usuario
Sistema
Escoja el bien
Valida bienes a cargo
Genera reporte
salir del sistema
imprime
Ilustración 9 DCUVALIDACION BIEN
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
45
Ingreso del bien
Bodeguero
�
Ingresa sistema
Autentica Usuario
Sistema
selecciona Opcion Ingresar Bien
Ingresa datos del bien
Grabar
salir del sistema
Ilustración 10DCU INGRESO BIEN
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
46
3.12. Diagramas de secuencia
3.12.1. Ingreso del bien
IngresoBien
Custodio remplazado exitosamente
Codigo Asignado
Marca Registrada
Color Registrado
Linea del Bien Ingresada
Categoria Ingresada
Ingresar Datos
Usuario Registrado
Asignación del Custodio
Ingresar Codigo
Seleccionar Marca
Ingresar Color
Seleccionar Linea Bien
Seleccionar Categoria
Ingreso Bien
Autentificacion Usuario
Sistema Usuario Ingreso del Bien Categoria Linea Bien Color Marca Codigo del Bien Asignacion Custodio
Custodio remplazado exitosamente
Codigo Asignado
Marca Registrada
Color Registrado
Linea del Bien Ingresada
Categoria Ingresada
Ingresar Datos
Usuario Registrado
Asignación del Custodio
Ingresar Codigo
Seleccionar Marca
Ingresar Color
Seleccionar Linea Bien
Seleccionar Categoria
Ingreso Bien
Autentificacion Usuario
Ilustración 11 DS INGRESO BIEN
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
47
3.12.2. Traslado Custodio
Transaccion
Custodio Registrado
Usuario Registrado
Presenta el Bien
Bien Asignado
Traslado de Custodio
Presenta Custodio
Lista Custodios
Cosulta Nuevo Custodio
Consulta Custodios()
Consultar Custodio ()
Seleccionar Transacción
Consultar bien Asignado
Consultar Bien ()
Autentificacion Usuario()
Bien Alta Bien Transaccion Custodio Asignado Custodio Remplazar ConsultaSistema Usuario
Custodio Registrado
Usuario Registrado
Presenta el Bien
Bien Asignado
Traslado de Custodio
Presenta Custodio
Lista Custodios
Cosulta Nuevo Custodio
Consulta Custodios()
Consultar Custodio ()
Seleccionar Transacción
Consultar bien Asignado
Consultar Bien ()
Autentificacion Usuario()
Ilustración 12 DS TRASLADO CUSTODIO
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
48
3.12.3. Ingreso Masivo
Seleccionar Categoria()
Selccionar Linea()
Listan los bienes()
Bienes Asignar
Seleccionar la Ubicación Física()
Presenta la area fisica
Buscar custodio()
Custodio Asignado
Generación del Código()
CATEGORIA LINEA BIENES CUSTODIO UBICACIÓN CODIGO
Lista Lineas
Lista las Categorias
Ilustración 13 DS INGRESO MASIVA
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
49
3.12.4. Inventario
TIPO DE TRANSACCION ESTADO DE CONSERVACION CATEGORIA LINEA BIENES
Selccionar Linea()
Lista Lineas
Seleccionar Categoria()
Lista las Categorias
SELECCIÓN TRANSACCION()
Presenta Transacciones
Selccionar Bienes()
Lista Bienes
Ilustración 14 DS INVENTARIO
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
50
3.12.5. Bajas
BUSQUEDA CODIGO
BIEN DADO DE BAJA
INGRESO NOTA()
Seleccionar Transaccion
BIENES A SER DADOS DE BAJA
SELECCIONAR MOTIVO()
CODIGO TIPO TRANSACCION CATEGORIA LINEA BIENES MOTIVO BAJA
PRESENTA BIEN
Presenta Transacciones
Seleccionar Categoria()
Lista las Categorias
Selccionar Linea()
Lista Lineas
Consulta Bienes()
MOTIVO EXITOSO
Ilustración 15 DS BAJAS
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
51
3.12.6. Devolución
INGRESAR CODIGO()
SELECCIONAR CATEGORIA()
SELCCIONAR LINEA
BUSCAR BIENES()
NOTA DE DEVOLUCION
DEVOLUCION EXITOSA
CUSTODIO SELECCIONADO
BUSQUEDA CUSTODIO()
CODIGO BIEN
SELECCIONA TRANSACCION()
TRANSACCION CONSULTADA
CATEGORIA SELECCIONADA
LINEA SELECCIONADA
LISTA BIENES
CUSTODIO CODIGO TIPO DE TRANSACCION CATEGORIA LINEA BIENES
Ilustración 16 DS DEVOLVER
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
52
3.13. Arquitectura Modelo-Vista-Controlador
CLIENTE
NAVEGADOR WEB LOGICA DE PRESENTACION
SERVIDOR WEB
LOGICA DE NEGOCIO
ACCESO BASE DATOS
MODULO INVENTARIO
SERVIDOR BDD
ERP SOCIAL
ALTA MASIVA TRASLADO BAJAS REPORTES
POSGRESS
Ilustración 17 ARQUITECTURA VCC
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
53
Arquitectura MVC
Esta arquitectura como describen sus siglas se basa en:
Modelo.- Básicamente clases orientadas a la interacción con la base de
datos.
Vista.- Todo lo que se mostrará, es decir la parte del diseño.
Controlador.- Es la parte donde se maneja el modelo y se invocan las
vistas, el que arma todo el asunto como diría.
Modelo.- Esta es la representación específica de la información con la
cual el sistema opera. En resumen, el modelo se limita a lo relativo de la
vista y su controlador facilitando las presentaciones visuales complejas. El
sistema también puede operar con más datos no relativos a la
presentación, haciendo uso integrado de otras lógicas de negocio y de
datos afines con el sistema modelado.
Vista.- Este presenta el modelo en un formato adecuado para interactuar,
usualmente la interfaz de usuario.
Controlador.- Este responde a eventos, usualmente acciones del usuario,
e invoca peticiones al modelo y, probablemente, a la vista.
La unión entre capa de presentación y capa de negocio conocido en el
paradigma de la Programación por capas representaría la integración
entre Vista y su correspondiente Controlador de eventos y acceso a datos,
MVC no pretende discriminar entre capa de negocio y capa de
presentación pero si pretende separar la capa visual gráfica de su
correspondiente programación y acceso a datos, algo que mejora el
desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que
ambos cumplen ciclos de vida muy distintos entre sí. De hecho, este
patrón separa el código en tres capas:
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
54
Capa Modelo
Esta capa se encarga de interactuar con la base de datos y también se
ejecuta las reglas de negocio.
Capa Controlador
El Controlador procesa las peticiones de la página web (vista), y envía
estos datos a la capa modelo, para que esta le devuelva la información
adecuada para mostrarla en la capa vista.
Capa Vista
La vista es el código HTML que se muestra al usuario, con la información
proveniente del controlador.
Tecnología Web.
Para el desarrollo de aplicaciones de negocio se utiliza frecuentemente el
patrón de diseño MVC Modelo Vista Controlador (Model View Controller)
que además es sencillo de implementar en las aplicaciones Web. En este
patrón el modelo es modificable por las funciones de negocio. Estas
funciones son solicitadas por el usuario mediante el uso de un conjunto de
vistas de la aplicación que solicitan dichas funciones de negocio a través
de un controlador, que es el módulo que recibe las peticiones de las vistas
y las procesa. Se suele clasificar en dos tipos a las aplicaciones basadas
en MVC:
Tipo 1.- Las vistas conocen la acción que se va a invocar en su petición,
normalmente la función esta cableada dentro de la vista.
Tipo 2.- El controlador introduce un conjunto de reglas que mapean a las
peticiones con las funciones, controlando además el flujo de navegación
por la aplicación.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
55
Por qué utilizar MVC
El fácil mantenimiento de código en un futuro, ya que al estar separadas
los distintos procesos según su tipo.
Si quisiéramos por ejemplo cambiar de tipo de base de datos, solo
tendremos que cambiar la capa modelo.
Ventajas de MVC
Las principales ventajas de la arquitectura MVC son:
La separación del Modelo de la Vista es decir, separar los datos
de la representación visual de los mismos.
Es mucho más sencillo agregar múltiples representaciones de los
mismos datos o información.
Facilita agregar menos tipos de datos según sea requerido por la
aplicación ya que son independientes del funcionamiento de las
otras capas.
Crea independencia de funcionamiento.
Facilita el mantenimiento en caso de errores.
Ofrece maneras más sencillas para probar el correcto
funcionamiento del sistema.
Permite el escalamiento de la aplicación en caso de ser requerido.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
56
CAPITULO 4
4. MARCO ADMINISTRATIVO
4.1. Recursos
La persona encargada de ejecutar este proyecto es un estudiante
egresado de la facultad de Ciencias Físicas y Matemáticas de la escuela
de Ciencias especialidad Informática de la Universidad Central del
Ecuador.
Este proyecto se va ejecutar en la escuela Manuel Quiroga de la
parroquia Tumbaco, se tiene la aprobación del director de la escuela y el
apoyo de la persona encargada del área, así como del personal
administrativo.
El equipo de personas que conformarán el proyecto estará constituido de
la siguiente manera:
RECURSO
HUMANO
COMPETENCIAS N° OBSERVACIÓN
Solicitante Director de la
Escuela Manuel
Quiroga
1 Debe estar en
capacidad de
tomar decisiones
para la institución
a cargo.
Dueño del
producto final.
Ingeniero
Informático,
(Tutor).
Conocimientos
relacionados con el
proyecto.
1 Debe pertenecer
a la institución y
será el
responsable de
guiar al
estudiante en la
gestión del
proyecto y
desarrollo de la
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
57
Tabla 3 FORMACION DEL EQUIPO
FUENTE: Elaboración propia
4.2. Recursos Institucionales
En reuniones previas con la autoridad de la institución se definieron los
requerimientos y soluciones tecnológicas a los mismos, para que el
sistema supla las necesidades de la institución.
La escuela Unidad Educativa San José de Collaqui, se compromete a dar
las facilidades necesarias para la vialidad de este proyecto y el personal
de la institución serán los encargados del uso del mismo.
aplicación.
Ingeniero
Informático o
relacionado,
(Revisores).
Conocimientos
relacionados con el
proyecto.
2 Debe pertenecer
a la institución y
se encargará de
la revisión del
documento y
cumplimiento del
plan de tesis.
Tesista
(Desarrollado
r)
Análisis, diseño y
desarrollo de
aplicaciones web.
1 Estudiante de
Ingeniería
Informática de la
Universidad
Central del
Ecuador que será
el gerente del
proyecto y
responsable del
desarrollo de la
aplicación.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
58
4.3. Recursos del autor
La persona que desarrolla el sistema Erp-Social cubrirá los gastos durante
todas las fases del proyecto:
Fase de análisis
Fase de diseño
Desarrollo
Pruebas
Capacitación
Implementación del Sistema.
4.4. Costos
El autor del trabajo de grado correrá con los costos directos e indirectos
que deriven por el desarrollo del sistema, para el desarrollo de este
proyecto se realizó un análisis de costos de lo cual se derivó la siguiente
tabla:
RECURSO CANTIDAD COSTO
UNITARIO
COSTO
TOTAL
Papel 11 resmas 5 55
Tinta 6 cargas 11 66
Derecho universitario 4 5.00 20.00
Hoja universitaria 30 1.00 30.00
Talento Humano 365 horas 16/hora 5840.00
Borrador trabajo de
grado
1 50.00 50.00
Empastado 6 50.00 300.00
Impresión de hojas 650 0.05 32.5
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
59
Servicios varios
(agua, luz, Internet,
alimentación,
transporte,etc)
7 meses 80.00 560.00
Imprevistos 1 110.00 110.00
Total 7063.50
Tabla 4 COSTOS
FUENTE: Elaboración propia
4.5. Cronograma
ANEXO2 DETALLE DEL CRONOGRAMA
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
60
CAPITULO 5
5. CONCLUSIONES Y RECOMENDACIONES
Al terminar el trabajo de graduación, en el que se ha cumplido con todos
los objetivos planteados para la reingeniería e implementación del
Sistema ERP-Social en la unidad educativa, se han generado las
siguientes conclusiones y recomendaciones.
5.1. Conclusiones
Una vez culminado el trabajo, en el que se ha cumplido con todas las
fases de desarrollo para la automatización de los procesos que se
generan para la Escuela Manuel Quiroga en la parroquia de Tumbaco, se
ha logrado establecer las siguientes conclusiones:
El análisis de los requerimientos, basados en el estándar IEEE830,
mediante el levantamiento de las especificaciones funcionales,
permitieron que el desarrollador obtenga un mejor entendimiento de
la lógica del negocio sobre el manejo de los bienes en la Escuela
Manuel Quiroga, mediante el cual se definieron los procesos que el
software debía ofrecer. Los cuales fueron aprobados por el director,
mostrando su satisfacción con el software implementado.
El sistema de control de activos se desarrolla por herramientas
robustas que permitan realizar el manejo de transacciones sobre los
bienes y ofrezcan un nivel de seguridad alto además de permitir
obtener un control en línea de la información.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
61
5.2. Recomendaciones
Las recomendaciones obtenidas al finalizar este trabajo de graduación
son las siguientes:
Tomar en cuenta todas las observaciones que haga el cliente a
cada avance presentado y encontrar verdaderas soluciones para
garantizar una total satisfacción del cliente con el producto final
entregado.
Todas las evaluaciones que el cliente realice a los prototipos
entregados, deben ser aprovechadas como capacitaciones del
funcionamiento del producto final, esto sirve para familiarizar a los
actores que interactuarán con el sistema y facilitará la aceptación y
comprensión del usuario sobre la herramienta desarrollada.
Realizar mantenimiento preventivo de los equipos donde será
implantado el nuevo sistema, para evitar posibles fallas durante el
funcionamiento de éste.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
62
BIBLIOGRAFIA
WEB
(1) Tesis de Grado ERP-Social 2012 Consultado el día 4 de marzo de
2013 desde http://www.dspace.uce.edu.ec/bistream.
(2) Plan de tesis ERP-Social en la escuela fiscal mixta “Manuel Quiroga”
Parroquia Tumbaco del Distrito Metropolitano de Quito Consultado el día
15 de Junio de 2013
(3) Universidad Central del Ecuador-Facultad de Ingeniería, Ciencias
Físicas y Matemáticas-Visión y Misión Consultado el día 4 de Agosto de
2013 desde http://www.uce.edu.ec/web/ingenieria-ciencias-fisicas-y-
matematica.
(4) Población de Tumbaco Consultado el día 4 de Agosto de 2013 desde
http://www.eruditos.net/.
(5) Sistema Erp, Consultado el día 8 de Agosto de 2013 desde
http://es.wikipedia.org/wiki/Social_Networks_ERP
(6) Beneficios del sistema Erp Consultado el día 8 de Agosto de 2013
desde www.kepler.com.mx/Archivos/definicion_de_sistema_erp.pdf
(7) Modelo en V Consultado el día 16 de Noviembre de 2013 desde
prezi.com/ryyutemqk5go/ingeniería-de-software-modelo-en-v
(8) Niveles lógicos del Modelo en V Consultado el día 16 de Noviembre
de 2013 desde ingenieriadesoftware.mex.tl/61885_Modelo-V.html
(9) Ventajas absolutas y relativas del Modelo en V Consultado el día 25
de Noviembre de 2013 desde www.eumed.net/libros-
gratis/2005/jmfb/3a.htm
(10) Modelos de Proceso de software Consultado el día 25 de Noviembre
de 2013 desde www.comusoft.com/.../Ciclos-de-vida-proceso-de-
desarrollo-del-software
(11) Kruchten, P (1996).”A rational Development Process”.Consultado el
día 15 de Diciembre de 2013 desde
www.rational.com/media/whitepappers/xtalk.pdf
(12) Especificación de requerimientos, estándar IEEE830 Consultado el
día 10 de Diciembre de 2013 desde https://prezi.com/wribnzku2hre/ieee-
830/
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
63
(13) Características de Especificación de requerimiento con estándar
IEEE830 Consultado el día 10 de Diciembre de 2013 desde
https://prezi.com/wribnzku2hre/ieee-830/
(14) Tipos de requisitos Consultado el día 6 de Noviembre de 2014 desde
es.wikipedia.org/wiki/Especificación_de_requisitos_de_software
(15) Community ENTerprise Operating System Consultado el día 14 de
Enero de 2014 desde http://es.wikipedia.org/wiki/CentOS
(16) Postgress Consultado el día 14 de Enero de 2014 desde
es.wikipedia.org/wiki/PostgreSQL
(17) Ventajas de Postgress Consultado el día 14 de Enero de 2014 desde
es.slideshare.net/brobelo/postgresql.
(18) Servidor de aplicaciones JBoss Consultado el día 14 de Enero de
2014 desde http://es.wikipedia.org/wiki/JBoss
(19) Servidor de aplicaciones JBoss Consultado el día 14 de Enero de
2014 desde http://es.wikipedia.org/wiki/JBoss
(20) Lenguaje de programación Java Consultado el día 14 de Enero de
2014 desde www.unav.es/SI/manuales/Java/indice.html
(21)Librería de componentes Primefaces Consultado el día 14 de Enero
de 2014 desde http://es.wikipedia.org/wiki/PrimeFaces.
(22) Pruebas de software Consultado el día 05 de Noviembre de 2014
desde http://pruebasdelsoftware.wordpress.com/
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
64
ANEXOS
Anexo 1 ESPECIFICACIONES FUNCIONALES
Se describen todas las especificaciones funcionales iníciales obtenidas
luego de las reuniones que se llevaron a cabo con los responsables de las
unidades educativas:
1. Ingreso de proveedor
Cliente: Unidad Educativa Fecha: 2013-10-
16
Módulo : Inventario
Sub-módulo : Entrada de Proveedores
Requerimiento: Ingreso de proveedor Número: 1
Tipo de
Requerimiento:
Requerimiento Estado: Definido
Alcance
Categoría: Necesario Prioridad: Alta
Complejidad: Media Tiemp
o (DH):
Módulos
Afectados:
Ninguno
Req.
Asociados:
---
Anexos:
DESCRIPCIÓN DEL REQUERIMIENTO: Proveedor
1. En la opción de proveedores deberá existir la opción de ingreso con
los campos que se detalla a continuación.
Todos los campos deberán ser obligatorios.
Los campos que se deben crear son:
Nombre:
Apellido:
Dirección
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
65
Teléfono:
Estado del proveedor: Vigente o no vigente
Cedula o Ruc
Ciudad: Se seleccionaran de los campos creados que será
tomado del catálogo de cuidad-País
Notas.
2. En la opción de proveedores deberá existir la opción de buscar
aquellos nombres que hayan sido registrados.
Las consultas se podrán realizar a nivel de cedula o Ruc, nombres,
estado.
3. Estos datos deberán ser guardados y estar disponibles para
consultas.
4. Debe permitir realizar la actualización de los datos.
5. Enlistar de manera vertical las opciones que se despliegan.
6. No se podrá eliminar al proveedor registrado.
Tabla 5 REQUERIMIENTO FUNCIONAL PROVEEDORES
FUENTE: Elaboración propia
2. Ingreso de productos
Cliente: Unidad Educativa Fecha: 2013-
10-16
Módulo : Inventario
Sub-módulo : Ingresar Productos
Requerimiento: Información del bien Número: 2
Tipo de
Requerimiento:
Requerimiento Estado: Definido
Alcance
Categoría: Necesario Prioridad: Alta
Complejidad: Media Tiemp
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
66
o (DH):
Módulos
Afectados:
Ninguno
Req. Asociados: ---
Anexos:
DESCRIPCIÓN DEL REQUERIMIENTO: Registro de producto
1. El sistema debe permitir ingresar y guardar la información del bien
tomando como datos:
Código.- Se genera un secuencial y automático en base a la
estructura definida por el ministerio de educación provincial, el
mismo que se definirá cuando se realice la asignación del bien.
Categoría.- Se manejara las clases de bienes como por ejemplo
Muebles, equipos de computación dentro de un catalogo
Línea.- Se manejara los subtipos como dentro de Equipos de
computación estará el subtipo monitor, pc, mouse teclado
Marca/Material.- Se deberá escoger del catálogo ingresado para
este caso.
Modelo.- Dependiendo del tipo de bien, el mismo no será
obligatorio
Color.- Dependiendo del tipo de bien, el mismo no será
obligatorio
Fecha de Asignación: se manejara según la fecha del sistema
Ubicación del bien: se establecerá cuando se realice la
asignación del bien al custodio responsable.
Estado del bien: Se definirá como activo, inactivo dentro de un
catálogo.
Tipo del bien: Ingresado, asignado, reasignado, devuelto se
manejar dentro de un catálogo.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
67
Estado de Conservación.- Se manejara dentro de una catalogo
bueno, malo, regular.
Cantidad: número de bienes ingresados
Ingreso del valor unitario.- Se procederá a digitar por el personal
a cargo del ingreso.
Valor Total.- Se calculara automáticamente entre la cantidad de
bienes ingresados y el ingreso del valor unitario.
2. Estos datos deberán ser guardados y estar disponibles para
consultas.
3. La búsqueda se realizara por los siguientes filtros Categoría, línea
,fecha de asignación, ubicación del bien, estado de conservación
4. Todos los datos deberán ser ingresados por el usuario como
campos obligatorios.
5. Parametrizar los campos de selección: línea del producto, marca,
modelo, color, estado del bien. Tipo del bien, estado de
conservación.
6. Al seleccionar la opción de “categoría”, deberá desplegar en la línea
del producto la información relacionado a este tipo de bien.
SOLUCIÓN FUNCIONAL:
Se deberá presentar el id del artículo, categoría, línea, marca, modelo,
color, fecha de asignación, ubicación del bien, estado del bien, tipo del
bien y estado de conservación.
Figura 1.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
68
Visualización de los campos que deben llenarse el momento de registro
del ingreso.
El Código deberá generarse de manera secuencial y automática cuando
se está creando un bien.
2. En la categoría se deberá seleccionar de la lista el bien del cual vamos
a realizar el ingreso.
3. En línea se deberá seleccionar de la lista el bien del cual vamos a
realizar el ingreso.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
69
4. En marca/material se deberá seleccionar la opción por cada una de las
líneas creadas (Línea: Teléfonos, Marca: Nokia, LG etc.)
EL botón INSERTAR deberá permitir almacenar la información ingresada.
El botón cancelar deberá permitir regresar a la pantalla principal y no
guardara ninguna información.
El botón limpiar permitirá vaciar todos los campos para poder llenar la
información necesaria.
Cuando se presionen los botones GUARDAR, CANCELAR se deberá
presentar mensajes de confirmación por parte del usuario para ejecutar
las acciones especificadas.
Tabla 6 REQUERIMIENTO FUNCIONAL INGRESO DE PRODUCTOS
FUENTE: Elaboración propia
3. Consulta de bienes
Cliente: Unidad Educativa Fecha: 2013-10-
16
Módulo : Inventario
Sub-módulo : Consulta de bienes según su estado
Requerimiento: Inventario Número: 3
Tipo de
Requerimiento:
Requerimiento Estado: Definido
Alcance
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
70
Categoría: Indispensable Prioridad: Alta
Complejidad: Media Tiemp
o (DH):
Módulos
Afectados:
Ninguno
Req.
Asociados:
--
Anexos:
DESCRIPCIÓN DEL REQUERIMIENTO: Consulta de bienes según su
estado.
1. Se deberá realizar un filtro por Tipo de transacción, Categoría, línea y
estado del bien, para generar el reporte correspondiente, el mismo
deberá presentar en pantalla los siguientes datos:
ID del artículo. Es el código único que se ingresa el momento que
se registra el bien, deberá tomar esta información desde el
ingreso de productos.
Categoría: cantidad de artículos ingresados por cada una de las
categorías de producto en las fechas correspondientes.
Líneas: cantidad de artículos ingresados por cada línea de
producto en base a la categoría generada
Modelo y color: en base a las características ingresadas según el
tipo de bien
Estado: Verificación del bien si se encuentra “activo” cuando se
pueda realizar la asignación del bien al custodio e inactivo
cuando el bien fue dado de baja en el proceso.
2. Permitir el control de bienes que ingresan a la institución educativa.
3. Llevar un manejo adecuado de los bienes según su estado para
poder realizar las asignaciones correspondientes.
4. Se deberá tener la posibilidad de exportar a formato Excel o pdf,
previamente con los mensajes correspondientes de autorización
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
71
para la descarga.
SOLUCIÓN
FUNCIONAL:
La opción de consulta deberá tener un control de los bienes que ingresan a
diario a las Instituciones Educativas que usen el sistema.
Vamos a seleccionar la opción mediante la cual deseamos que se nos
genere la consulta de acuerdo a las siguientes opciones
1. Se deberá seleccionar la Categoría de los Bienes a Filtrar.
2. Selección de Línea.
3. Generación del Reporte en Excel, clic en el botón del icono de Excel,
luego de haber realizado las elecciones necesarias para la generación del
informe requerido.
Tabla 7 REQUERIMIENTO FUNCIONAL CONSULTA BIENES
FUENTE: Elaboración propia
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
72
4. Mantenimiento tabla de inventarios
Cliente: Unidad Educativa Fecha: 2013-
10-16
Módulo : Activo Fijo
Sub-módulo : Mantenimiento tabla Activo Fijo
Requerimiento: Verificación de Activo Fijo Número: 4
Tipo de
Requerimiento:
Requerimiento Estado: Definido
Alcance
Categoría: Indispensable Prioridad: Alta
Complejidad: Media Tiemp
o (DH):
Módulos
Afectados:
Ninguno
Req. Asociados: ---
Anexos:
DESCRIPCIÓN DEL REQUERIMIENTO: Mantenimiento de tablas
En esta opción, lo que se va a visualizar los datos de todos los
catálogos del sistema de Activo Fijo.
Se deberá tener los campos que se indican a continuación :
Id, Código, Nombre
Que se permita la opción de crear, editar y eliminar nuevos registros.
Presentar mensajes cuando se eliminen o guarden productos.
Tabla de Transacciones
Deberá contener los campos ID, NOMBRE, EDITAR, ELIMINAR,
Por ejemplo es asignado, reasignado, traslado.
Tabla de Estado de transacciones
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
73
Deberá contener los campos ID, NOMBRE, EDITAR, ELIMINAR,
Por ejemplo es activo, inactivo.
Tabla Estado de Bien
Deberá contener los campos ID, NOMBRE, EDITAR,
ELIMINAR,
Por ejemplo será Activado, Desactivado
Tabla Tipo de Bien
Deberá contener los campos ID, NOMBRE, EDITAR,
ELIMINAR,
Por ejemplo será donación, Adjudicación.
Tabla Estado de conservación del Bien
Deberá contener los campos ID, NOMBRE, EDITAR,
ELIMINAR,
Por ejemplo será Bueno, Malo, Regular.
Tabla Estado del Bien
Deberá contener los campos ID, NOMBRE, EDITAR,
ELIMINAR,
Por ejemplo será asignado, reasignado, ingresado.
Tabla de Categoría
Debe contener los campos ID, NOMBRE, EDITAR, ELIMINAR.
Por ejemplo Muebles, Equipos de oficina.
Manejar la estructura para la creación del cualquier catalogo
Tabla de enlace Línea – Marca
Deberá contener los campos ID, LINEA, EDITAR, ELIMINAR
Cuando se realiza la selección de línea de producto se podrá
ingresar una nueva marca
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
74
Tabla de Marca de Bien
Deberá contener los campos ID, NOMBRE, EDITAR, ELIMINAR
Tabla Tipo de Ingreso
Deberá contener los campos ID, NOMBRE, EDITAR,
ELIMINAR,
Por ejemplo será Adquisición, donación.
SOLUCIÓN FUNCIONAL:
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
75
Se desarrolla una pantalla en la cual se detalla las características del bien
como nombre, ubicación, custodio fecha de ingreso el estado físico todo
esto se registra en la tabla de transacción en la base de datos.
CUADRO 1 REQUERIMIENTO FUNCIONAL MANTENIMIENTO INVENTARIO
FUENTE: Elaboración propia
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
76
5. Reportes
Cliente: Unidad Educativa Fecha: 2013-10-16
Módulo : Activo Fijo
Sub-módulo : Reportes
Requerimiento: Presentación de reportes Número 5
Tipo de
Requerimiento:
Requerimiento Estado: Definido
Alcance
Categoría: Indispensable Prioridad Alta
Complejidad: Media Tiemp
o (DH):
Módulos
Afectados:
Ninguno
Req.
Asociados:
---
Anexos:
DESCRIPCIÓN DEL REQUERIMIENTO: El sistema debe permitir reportes
de los bienes que están registrados para presentar un inventario según las
necesidades de los usuarios.
Características de los reportes
En la cabecera el reporte debe: Titulo del Reporte, logo de la Institución
educativa, el rango de las fechas de la búsqueda y la fecha de
generación del reporte.
El reporte deberá agrupar los bienes por Clasificación del Bien
categoría, línea; ordenados por la fecha de transferencia.
Mostrar la descripción del criterio de agrupación, deberá también
mostrar el número de ítems, y por cada grupo.
En el cuerpo del reporte, los campos mínimos que deberá presentar
son: Código del Bien, Descripción, Funcionario Anterior, Funcionario
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
77
Actual, ubicación Anterior, ubicación Actual, Fecha de Transferencia,
se lo manejara a través de la trazabilidad de cada bien donde se
detalla el movimiento entre custodios, fechas y estados.
SOLUCIÓN FUNCIONAL:
1. El Reporte deberá mostrar información con los siguientes datos:
Código
Categoría
Líneas del bien
Marca o material del cual se necesita saber la información.
Tipo de bien
Ubicación
Estado
Custodio
Fecha de ingreso
2. Reporte que permita verificar los bienes según los siguientes detalles:
Código
Proveedor
Línea de producto
Modelo
Color
Fecha de asignación
Custodio
Estado
Estado de conservación
3 Generar un reporte sobre los movimientos que tenido los bienes sea
por motivo de alta, baja, por funcionarios, por fechas del movimiento,
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
78
activo, funcionario.
4 Reporte Altas de Activos
Para generar este reporte se deberá poder filtrar por: activo), código
del bien, categoría, línea, Fecha de Baja por rango de fechas (“Desde”,
“Hasta”), ordenados por la fecha de baja., Condición del Bien (“Sin
Uso”, “En Uso”, “Todos”),
Por cada grupo adicional a la descripción del criterio de agrupación,
deberá también mostrar el número de ítems, y por cada grupo y sub
grupo
En el cuerpo del reporte, los campos mínimos que deberá presentar
son: Código del Bien, su Descripción, No. de Serie, Marca, Valor
Adquisición, Fecha Adquisición, ubicación, Funcionario, Cantidad,
Condición del Bien.
5 Reporte de baja de activos
Para generar este reporte se deberá poder filtrar por: activo), código
del bien, categoría, línea, Fecha de Baja por rango de fechas (“Desde”,
“Hasta”), ordenados por la fecha de baja.
Por cada grupo adicional a la descripción del criterio de agrupación,
deberá también mostrar el número de ítems, y por cada grupo y sub
grupo
En el cuerpo del reporte, los campos mínimos que deberá presentar
son: Código del Bien, su Descripción, No. de Serie, Marca, Fecha
Adquisición, Fecha de Baja, ubicación, Funcionario, Cantidad.
Cuando ya se realicen todas las selecciones deberá realizar un enlace
a una página en Excel. En el caso de imprimir se deberá seleccionar
el icono de imprimir y este será en formato pdf.
Tabla 8 REQUERIMIENTO FUNCIONAL REPORTE
FUENTE: Elaboración propia
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
79
6. Traslado y transacción
Cliente: Unidad Educativa Fecha: 2013-10-
16
Módulo : Activo Fijo
Sub-módulo : Consulta de Ingreso y Salida
Requerimiento: Traslado y transacción Número: 6
Tipo de
Requerimiento:
Requerimiento Estado: Definido
Alcance
Categoría: Indispensable Prioridad: Alta
Complejidad: Media Tiemp
o (DH):
Módulos
Afectados:
Ninguno
Req.
Asociados:
---
Anexos:
DESCRIPCIÓN DEL REQUERIMIENTO: TRASFERENCIA ENTRE
CUSTODIOS Y TRANSACCIONES
Manejo de Transacciones
Se debe crear una pantalla en la cual contenga los siguientes
campos tipo de transacción, empleado asignado, empleado
reasignado, fecha, estado.
Descripciones de los campos
Código de transacción .- Debe ser generada por un secuencial y
automáticamente
Transacción: Este campo se encuentra el catálogo de las
transacciones en las cuales se registra los estados asignado,
reasignado, traslado
Tipo de movimiento. Debe detallar si es alta, baja, traslado de
custodio.
Empleado asignado: Este campo se encuentra registrado el
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
80
empleado a la cual se encuentra registrado el bien
Empleado reasignado: Este campo se encuentra registrado el
empleado a la cual se realizara la nueva asignación registrado el
bien.
Fecha de transacción: Este campo se registra la fecha en la cual se
realizó el movimiento de los bienes.
Estado de la transacción: Este campo se encuentra si está activo,
inactivo.
Esta pantalla debe permitir realizar guardar, editar ,eliminar
La búsqueda puede realizarse por transacción, fecha de transacción,
código de trasferencia.
Alta del Bien
Crear las pantalla para la creación de la alta en la cual se procederá
a la asignación del bien a un funcionario de la institución realizando
un traslado de los bienes del bodeguero a un nuevo funcionario en el
cual se encuentra el código del bien, nombre del funcionario, fecha
de asignación y una descripción en la cual se puede indicar un
detalle del bien ,
Se genera un secuencial par ale ingreso de las altas del bien.
Se llamara al catálogo de categoría y línea para definir los atributos
del bien.
Debe permitir guardar ,editar, eliminar de forma lógica es decir un
cambio de estado a inactivo no se debe afectar a la base de datos
TRAZABILIDAD DEL BIEN.-
Se solicita que en una pantalla se encuentre la historia del bien desde
el ingreso a bodega, los cambios de custodia las reasignaciones.
EL tipo de movimiento sea una Alta o baja.
Fechas en las cuales se realizó los movimientos.
Ubicación actual del bien.
Detallar los funcionarios que se encontraban en custodia del bien.
CUADRO 2 REQUERIMIENTO FUNCIONAL TRANSACCION Y TRAZABILIDAD
FUENTE: Elaboración propia
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
81
7. Transferencia de bienes
Cliente: Unidad Educativa Fecha: 2013-10-16
Módulo : Activo Fijo
Sub-módulo : Consulta de Ingreso y Salida
Requerimiento: Transferencia Número: 7
Tipo de
Requerimiento:
Requerimiento Estado: Definido
Alcance
Categoría: Indispensable Prioridad Alta
Complejidad: Media Tiemp
o (DH):
Módulos
Afectados:
Ninguno
Req.
Asociados:
---
Anexos:
DESCRIPCIÓN DEL REQUERIMIENTO: TRASFERENCIA ENTRE
CUSTODIOS Y TRANSACCIONES.
TRASLADO ENTRE CUSTODIOS
Dentro del proceso de transferencia de bienes entre Custodios buscar
los activos por el código del bien e irlo agregando a la orden de
transferencia ítem por ítem, este criterio de búsqueda será opcional
por lo que si no es ingresado se desplegará en la grilla todos los
bienes asignados al Custodio que va transferir.
El botón Buscar que aplique la búsqueda en base a los criterios
seleccionados ya que existe funcionarios como los de bodega que
poseen gran cantidad de bienes asignados y la actual funcionalidad
limitaría mucho el tema de la asignación de un bien.
Tabla 9 REQUERIMIENTO FUNCIONAL TRASLADO ENTRE CUSTODIOS
FUENTE: Elaboración propia
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
82
8. Baja de bienes
Cliente: Unidad Educativa Fecha: 2013-10-16
Módulo : Activo Fijo
Sub-módulo : Baja de Bienes
Requerimiento: Activo Fijo Número: 8
Tipo de
Requerimiento:
Requerimiento Estado: Definido
Alcance
Categoría: Indispensable Prioridad Alta
Complejidad: Media Tiemp
o (DH):
Módulos
Afectados:
Ninguno
Req. Asociados: ---
Anexos:
DESCRIPCIÓN DEL REQUERIMIENTO: Proceso de bajas
Proceso de bajas
Crear las pantallas que permitan realizar el proceso de bajas de
bienes de forma parametrizada, evitando en lo posible errores
operativos.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
83
SOLUCIÓN FUNCIONAL:
1 Descripción de las Modificaciones
1.1Proceso de Bajas / Definición de catálogos
Añadir los catálogos necesarios para el proceso de Bajas, los
mismos que se detallan a continuación:
CATALOGO DE ESTADO BAJAS
ESTADOS
Código Descripción
01 ASIGNADO
02 NO ASIGNADO
CATALOGO DE TIPO DE BAJAS
TIPO DE MOVIMIENTO
Código Descripción TIPO
01 BAJAS POR PÉRDIDA BAJAS
02 BAJAS POR ROBO BAJAS
03 BAJAS TOTAL BAJAS
04 BAJAS POR DONACION BAJAS
EJEMPLO DE UN CASO DE BAJA:
CASO 00001
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
84
DESCRIP
CION
……………………
MOTIVO
DE LA
BAJA
ROBO
Los bienes para proceder a dar de baja se debe encontrar en
bodega es decir en custodia del bodeguero y en estado no utilizado.
El proceso para las bajas por pérdidas o robo no se debe considerar
el estado y custodio.
Al ingresar en el menú al proceso de bajas, existen las opciones de
buscar un caso de baja, se tendrá la opción de buscar un caso de
baja antes definida por el número de caso, por el motivo de la baja,
por la fecha de creación, por el usuario que crea la baja
Al ingresar en el menú al proceso de bajas, existe la opción de
ingresar un nuevo caso.
Al ingresar un nuevo caso, el sistema debe generar un código
secuencial y automático.
El usuario ingresa la descripción.
El usuario escoge el motivo de la Baja del catálogo antes definido
Debe presentar el nombre del funcionario que realizo el proceso de
la baja.
BIENES
Buscar los bienes por categoría, línea, funcionario, fecha de
adquisición, por estado del bien.
Se presenta un grid con los bienes y el usuario escoge los bienes
que va a dar de baja.
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
85
Puede realizar una nueva búsqueda sin que pierda el listado de
bienes escogidos.
Confirmar si está seguro de dar la baja.
Bajar el archivo de bienes a dar de baja a Excel.
LISTADO DE BIENES BUSCADOS
SUBTIPO USUARIO CODIGO
BIEN
ESTADO
BIEN
PIZARRON 000109 S00001 SIN USO
ESCRITORIO 000240 M00009 SIN USO
COMPUTADOR 000176 E00099 EN USO
Tabla 10 REQUERIMIENTO FUNCIONAL BAJA DE BIENES
FUENTE: Elaboración propia
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
- 1 -
ANEXO 2 CRONOGRAMA
Universidad Central del Ecuador
Facultad de Ingeniería, Ciencias Físicas y Matemática
- 2 -