Implementación y Reingeniería del Sistema Erp Social · universidad central del ecuador facultad de ingenierÍa, ciencias fÍsicas y matemÁtica carrera de ingenieria informÁtica

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.



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.



iv



v

CERTIFICACION



vi

APROBACION DEL JURADO



vii

RESULTADO DEL TRABAJO DE GRADUACION



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



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



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



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



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



xiii



xiv



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.



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.



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.



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.



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



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.



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.



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.



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.

http://www.uce.edu.ec/web/ingenieria-ciencias-fisicas-y-matematica

http://www.uce.edu.ec/web/ingenieria-ciencias-fisicas-y-matematica



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

http://www.eruditos.net/



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.




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



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

http://3.bp.blogspot.com/-4lc4llomLRU/UE5yzbmRZXI/AAAAAAAAAis/xBV0JnJtwSg/s1600/V.jpg



14

Modelo en V Consultado el día 16 de Noviembre de 2013 desde


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.

http://2.bp.blogspot.com/-J26jOpOtYpw/UE5yvdouPII/AAAAAAAAAik/9thHIKU7IXA/s1600/v2.bmp



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



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



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



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.

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

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

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

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



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/



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

http://es.wikipedia.org/wiki/Bifurcaci%C3%B3n_(desarrollo_de_software)

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

http://es.wikipedia.org/wiki/C%C3%B3digo_fuente

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

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

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

http://es.wikipedia.org/wiki/C%C3%B3digo_abierto



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

http://es.wikipedia.org/wiki/C%C3%B3digo_fuente

http://es.wikipedia.org/wiki/Licencia_p%C3%BAblica_general_de_GNU

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

http://es.wikipedia.org/wiki/Yellow_dog_Updater,_Modified

http://es.wikipedia.org/wiki/Fedora_(distribuci%C3%B3n_Linux)

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



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



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:



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.



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.



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.



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.

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

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




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”



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:

http://www.alegsa.com.ar/Dic/compilar.php

http://www.alegsa.com.ar/Dic/programador.php

http://www.alegsa.com.ar/Dic/modulo.php

http://www.alegsa.com.ar/Dic/modularidad.php

http://www.alegsa.com.ar/Dic/programa.php



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



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.



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



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



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.



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.



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.



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.



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



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.



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.



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




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



40

Relación de la transacción con el detalle del bien

Ilustración 5 BD RELACION TRANSACCION



41

Relación detalle-cabecera del bien

Ilustración 6 DB RELACION CABECERA BIEN



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



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



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



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



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



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



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



49

3.12.4. Inventario

TIPO DE TRANSACCION ESTADO DE CONSERVACION CATEGORIA LINEA BIENES

Selccionar Linea()

Lista Lineas



SELECCIÓN TRANSACCION()

Presenta Transacciones

Selccionar Bienes()

Lista Bienes

Ilustración 14 DS INVENTARIO



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



Selccionar Linea()

Lista Lineas

Consulta Bienes()

MOTIVO EXITOSO

Ilustración 15 DS BAJAS



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



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



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:



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.



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.



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



57

Tabla 3 FORMACION DEL EQUIPO


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.



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



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


4.5. Cronograma

ANEXO2 DETALLE DEL CRONOGRAMA



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.



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.

http://www.monografias.com/trabajos11/mpt/mpt.shtml



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


(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


(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



(12) Especificación de requerimientos, estándar IEEE830 Consultado el

día 10 de Diciembre de 2013 desde https://prezi.com/wribnzku2hre/ieee-

830/



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



(17) Ventajas de Postgress Consultado el día 14 de Enero de 2014 desde

es.slideshare.net/brobelo/postgresql.





(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/




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



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

Email

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


2. Ingreso de productos

Cliente: Unidad Educativa Fecha: 2013-

10-16


Sub-módulo : Ingresar Productos

Requerimiento: Información del bien Número: 2

Tipo de

Requerimiento:


Alcance

Categoría: Necesario Prioridad: Alta




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.



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.



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.



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


3. Consulta de bienes


16


Sub-módulo : Consulta de bienes según su estado

Requerimiento: Inventario Número: 3

Tipo de

Requerimiento:


Alcance



70

Categoría: Indispensable Prioridad: Alta


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



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




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:


Alcance



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



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


ELIMINAR,

Por ejemplo será donación, Adjudicación.

Tabla Estado de conservación del Bien


ELIMINAR,

Por ejemplo será Bueno, Malo, Regular.

Tabla Estado del Bien


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



74

Tabla de Marca de Bien

Deberá contener los campos ID, NOMBRE, EDITAR, ELIMINAR

Tabla Tipo de Ingreso


ELIMINAR,

Por ejemplo será Adquisición, donación.




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




76

5. Reportes

Cliente: Unidad Educativa Fecha: 2013-10-16


Sub-módulo : Reportes

Requerimiento: Presentación de reportes Número 5

Tipo de

Requerimiento:


Alcance

Categoría: Indispensable Prioridad Alta


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



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.


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,



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


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


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




79

6. Traslado y transacción


16


Sub-módulo : Consulta de Ingreso y Salida

Requerimiento: Traslado y transacción Número: 6

Tipo de

Requerimiento:


Alcance



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



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




81

7. Transferencia de bienes



Sub-módulo : Consulta de Ingreso y Salida

Requerimiento: Transferencia Número: 7

Tipo de

Requerimiento:


Alcance



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




82

8. Baja de bienes



Sub-módulo : Baja de Bienes

Requerimiento: Activo Fijo Número: 8

Tipo de

Requerimiento:


Alcance



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.



83


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



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.



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




- 1 -

ANEXO 2 CRONOGRAMA



- 2 -

Documents

Implementación y Reingeniería del Sistema Erp Social · universidad central del ecuador facultad de ingenierÍa, ciencias fÍsicas y matemÁtica carrera de ingenieria informÁtica