UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE INGENIERÍA, CIENCIAS FÍSICAS Y MATEMÁTICA CARRERA DE INGENIERIA INFORMÁTICA

Transcripción

1 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

2 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. ii

3 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. iii

4 iv

5 CERTIFICACION v

6 APROBACION DEL JURADO vi

7 RESULTADO DEL TRABAJO DE GRADUACION vii

8 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 PRESENTACIÓN DEL PROBLEMA PLANTEAMIENTO DEL PROBLEMA FORMULACIÓN DEL PROBLEMA INTERROGANTES DE LA INVESTIGACIÓN OBJETIVO DE LA INVESTIGACIÓN JUSTIFICACIÓN CONTENIDO DEL PROYECTO... 7 CAPITULO ANTECEDENTES MARCO TEÓRICO IDENTIFICACIÓN DE VARIABLES VARIABLES INDEPENDIENTES VARIABLES DEPENDIENTES HIPÓTESIS CAPITULO ANÁLISIS DEL SISTEMA ESPECIFICACIÓN DE REQUERIMIENTOS CONTEXTO DEL SISTEMA RESTRICCIONES Y SUPOSICIONES RESTRICCIONES EN EL DESARROLLO DEL PROYECTO RESTRICCIONES EN LAS HERRAMIENTAS DE DESARROLLO DE SOFTWARE RESTRICCIONES DEL HARDWARE DEL SERVIDOR RIESGOS TECNOLÓGICOS DE RECURSOS DE MÓDULO viii

9 DE HABILIDADES DE REQUERIMIENTOS REQUERIMIENTOS FUNCIONALES DESCRIPCIÓN DE LOS ACTORES REQUERIMIENTOS TÉCNICOS REQUERIMIENTO DE SOFTWARE REQUERIMIENTOS DE HARDWARE LENGUAJE DE MODELAMIENTO UNIFICADO (UML) DIAGRAMA DE CLASES DIAGRAMA DE CASOS DE USO DIAGRAMAS DE SECUENCIA INGRESO DEL BIEN TRASLADO CUSTODIO INGRESO MASIVO INVENTARIO BAJAS DEVOLUCIÓN ARQUITECTURA MODELO-VISTA-CONTROLADOR CAPITULO MARCO ADMINISTRATIVO RECURSOS RECURSOS INSTITUCIONALES RECURSOS DEL AUTOR COSTOS CRONOGRAMA CAPITULO CONCLUSIONES Y RECOMENDACIONES CONCLUSIONES RECOMENDACIONES BIBLIOGRAFIA ANEXOS ix

10 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 x

11 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 xi

12 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 xii

13 xiii

14 xiv

15 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, 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 1

16 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. 2

17 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. 3

18 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. 4

19 Mejora en los procesos de las instituciones. Mejora de los servicios institucionales 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 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 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 5

20 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 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. 6

21 (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 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. 7

22 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. 8

23 CAPITULO 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 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 , 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 habitantes. 9

24 (4) Población de Tumbaco Consultado el día 4 de Agosto de 2013 desde 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 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 10

25 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 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 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. 11

26 Análisis y diseño Análisis Teórico 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 12

27 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 13

28 Modelo en V Consultado el día 16 de Noviembre de 2013 desde prezi.com/ryyutemqk5go/ingeniería-de-software-modelo-en-v Ilustración 2: MODELO NIVELES LOGICOS En los 4 niveles lógicos comenzando desde el 1, para cada fase del desarrollo, existe una fase correspondiente o paralela de verificación o validación. Esta estructura obedece que desde el principio para cada fase del desarrollo debe existir un resultado verificable. En la misma estructura se advierte también que la proximidad entre una fase del desarrollo y su fase de verificación correspondiente va decreciendo a medida que aumenta el nivel dentro de la V, es decir de arriba hacia abajo en donde se localiza la punta. La longitud de esta separación intenta ser proporcional a la distancia en el tiempo entre una fase y su homóloga de verificación. 14

29 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 15

30 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 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 16

31 El proceso de ciclo de vida de RUP se divide en cuatro fases: Inicio: El objetivo en esta etapa es delimitar la visión del proyecto. Mayor énfasis en modelamiento del proyecto: objetivos, alcance, limitaciones y requerimientos. Elaboración: En esta fase el objetivo es delimitar la arquitectura óptima. Se define la infraestructura y ambiente de desarrollo. Construcción: En esta etapa se lleva a cabo la construcción del producto por medio de una serie de iteraciones obteniendo la capacidad operativa inicial. Transición: se pretende obtener el producto preparado para la entrega. Pruebas de aceptación y capacitación a usuarios. Estas fases se dividen en iteraciones, cada una de las cuales produce una pieza de software demostrable. (12) Kruchten, P (1996). A rational Development Process. Consultado el día 15 de Diciembre de 2013 desde 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. 17

32 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 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 18

33 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 DISEÑO Para el diseño de la reingeniería del sistema Erp-Social se utilizan las siguientes herramientas tecnológicas 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 19

34 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 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 20

35 Características de PostgreSQL. A continuación se enumeran las principales características de este gestor de bases de datos: Implementación del estándar SQL92/SQL99. Soporta distintos tipos de datos: además del soporte para los tipos base, también soporta datos de tipo fecha, monetarios, elementos gráficos, datos sobre redes (MAC, IP), cadenas de bits, etc. También permite la creación de tipos propios. Incorpora una estructura de datos array. Incorpora funciones de diversa índole: manejo de fechas, geométricas, orientada las operaciones con redes. Permite la declaración de funciones propias, así como la definición dedisparadores Soporta el uso de índices, reglas y vistas. Incluye herencia entre tablas (aunque no entre objetos, ya que no existen), por a este gestor de bases de datos se le incluye entre los gestores objeto-relacionales. Permite la gestión de diferentes usuarios, como también los permisos asignados a cada uno de ellos (18) Postgress Consultado el día 14 de Enero de 2014 desde es.wikipedia.org/wiki/postgresql Ventajas de PostgreSQL Instalación ilimitada Es frecuente que las bases de datos comerciales sean instaladas en más servidores de lo que permite la licencia. Algunos proveedores comerciales consideran a esto la principal fuente de incumplimiento de licencia. Con PostgreSQL, nadie puede demandarlo por violar acuerdos de licencia, puesto que no hay costo asociado a la licencia del software. Esto tiene varias ventajas adicionales: 21

36 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. 22

37 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 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. 23

38 (20) Servidor de aplicaciones JBoss Consultado el día 14 de Enero de 2014 desde Componentes de JBOSS Hibernate Hibernate es un servicio de persistencia objeto/relaciones y consultas para Java. Hibernate facilita a los desarrolladores crear las clases de persistencia utilizando el lenguaje Java - incluyendo la asociación, herencia, polimorfismo y composición y el entorno de colecciones Java. (21) Servidor de aplicaciones JBoss Consultado el día 14 de Enero de 2014 desde 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 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. 24

39 Conocer la cantidad en existencia de los bienes que poseen cada una de las instituciones educativas 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 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 25

40 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 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: 26

41 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 27

42 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. 28

43 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 29

44 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 30

45 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. 31

46 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 Restricciones y suposiciones 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. 32

47 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) Restricciones del hardware del servidor Servidor Centos 6.0 Servidor de aplicaciones: JBoss 3.3. Riesgos 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. 33

48 De recursos El desarrollo se realizara en computadoras personales basadas en Windows 7 (cualquier versión) 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. 34

49 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 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 Requerimientos funcionales Se hace referencia al Anexo 1 donde se evidencia los requerimientos funcionales originales obtenidos para iniciar con el desarrollo 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 35

50 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. 36

51 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. 37

52 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 Requerimiento de software Equipo Tipo de Aplicación Nombre Sistema Operativo Centos 6.0 Servidor de Aplicaciones JBOSS Servidor Base de datos Postgress Sistema Operativo Cualquiera Cliente Navegador Web Firefox, Google Chrome Tabla 1: REQUERIMIENTO DE SOFTWARE FUENTE: Elaboración propia 3.8. Requerimientos de hardware Equipo Elemento Valor Procesador 2 GHz o superior Memoria 1 GB o mayor Servidor de Aplicaciones Sistema Operativo Base de datos Cliente Disco Duro 1GB disponible Tarjeta de Red 10/100 Mbps Disco Duro 10 GB disponibles Memoria 2 GB o mayor Disco Duro 4 GB Memoria 1GB mínimo Procesador 800 MHz o superior Memoria 512 MB o mayor Tarjeta de Red 10/100 Mbps Tabla 2 REQUERIMIENTO DE HADWARE FUENTE: Elaboración propia 38

53 3.9. Lenguaje de Modelamiento Unificado (UML) 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 39

54 Relación de la transacción con el detalle del bien Ilustración 5 BD RELACION TRANSACCION 40

55 Relación detalle-cabecera del bien Ilustración 6 DB RELACION CABECERA BIEN 41

56 3.11. Diagrama de Casos de Uso Asignación del bien Ingresa sistema Bodeguero Autentica Usuario Sistema selecciona Opcion asignar bien Llenar campos asignacion asignacion Valida asignacion Notificar asignacion funcionario Grabar salir del sistema Ilustración 7 DCU ASIGNACION DEL BIEN 42

57 Generación de Reportes Ingresa sistema Bodeguero Autentica Usuario Sistema selecciona Opcion reportes Llenar criterios Genera reporte imprime salir del sistema Ilustración 8 DCUSISTEMA 43

58 Validación del bien Ingresa sistema Funcionario Autentica Usuario Sistema Escoja el bien Valida bienes a cargo Genera reporte imprime salir del sistema Ilustración 9 DCUVALIDACION BIEN 44

59 Ingreso del bien Ingresa sistema Bodeguero Autentica Usuario Sistema selecciona Opcion Ingresar Bien Ingresa datos del bien Grabar salir del sistema Ilustración 10DCU INGRESO BIEN 45

60 IngresoBien Diagramas de secuencia Ingreso del bien Sistema Usuario Ingreso del Bien Categoria Linea Bien Color Marca Codigo del Bien Asignacion Custodio Autentificacion Usuario Usuario Registrado Ingreso Bien Ingresar Datos Seleccionar Categoria Categoria Ingresada Seleccionar Linea Bien Linea del Bien Ingresada Ingresar Color Color Registrado Seleccionar Marca Marca Registrada Ingresar Codigo Codigo Asignado Asignación del Custodio Custodio remplazado exitosamente Ilustración 11 DS INGRESO BIEN 46

61 Traslado Custodio Transaccion Sistema Usuario Bien Alta Bien Transaccion Custodio Asignado Custodio Remplazar Consulta Autentificacion Usuario() Usuario Registrado Consultar Bien () Presenta el Bien Consultar bien Asignado Bien Asignado Seleccionar Transacción Traslado de Custodio Consultar Custodio () Presenta Custodio Consulta Custodios() Lista Custodios Cosulta Nuevo Custodio Custodio Registrado Ilustración 12 DS TRASLADO CUSTODIO 47

62 Ingreso Masivo CATEGORIA LINEA BIENES CUSTODIO UBICACIÓN CODIGO Seleccionar Categoria() Lista las Categorias Selccionar Linea() Lista Lineas Listan los bienes() Bienes Asignar Buscar custodio() Custodio Asignado Seleccionar la Ubicación Física() Presenta la area fisica Generación del Código() Ilustración 13 DS INGRESO MASIVA 48

63 Inventario TIPO DE TRANSACCION ESTADO DE CONSERVACION CATEGORIA LINEA BIENES SELECCIÓN TRANSACCION() Presenta Transacciones Seleccionar Categoria() Lista las Categorias Selccionar Linea() Lista Lineas Selccionar Bienes() Lista Bienes Ilustración 14 DS INVENTARIO 49

64 Bajas CODIGO TIPO TRANSACCION CATEGORIA LINEA BIENES MOTIVO BAJA BUSQUEDA CODIGO PRESENTA BIEN Seleccionar Transaccion Presenta Transacciones Seleccionar Categoria() Lista las Categorias Selccionar Linea() Lista Lineas Consulta Bienes() BIENES A SER DADOS DE BAJA SELECCIONAR MOTIVO() MOTIVO EXITOSO INGRESO NOTA() BIEN DADO DE BAJA Ilustración 15 DS BAJAS 50

65 Devolución CUSTODIO CODIGO TIPO DE TRANSACCION CATEGORIA LINEA BIENES BUSQUEDA CUSTODIO() CUSTODIO SELECCIONADO INGRESAR CODIGO() CODIGO BIEN SELECCIONA TRANSACCION() TRANSACCION CONSULTADA SELECCIONAR CATEGORIA() CATEGORIA SELECCIONADA SELCCIONAR LINEA LINEA SELECCIONADA BUSCAR BIENES() LISTA BIENES NOTA DE DEVOLUCION DEVOLUCION EXITOSA Ilustración 16 DS DEVOLVER 51

66 3.13. Arquitectura Modelo-Vista-Controlador CLIENTE NAVEGADOR WEB LOGICA DE PRESENTACION SERVIDOR WEB LOGICA DE NEGOCIO ERP SOCIAL MODULO INVENTARIO ALTA MASIVA TRASLADO BAJAS REPORTES ACCESO BASE DATOS SERVIDOR BDD POSGRESS Ilustración 17 ARQUITECTURA VCC 52

67 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: 53

68 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. 54

69 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. 55

70 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 Ingeniero Informático, (Tutor). Director de la Escuela Manuel Quiroga Conocimientos relacionados con el proyecto. 1 Debe estar en capacidad de tomar decisiones para la institución a cargo. Dueño del producto final. 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 56

71 aplicación. Ingeniero Informático o relacionado, (Revisores). Tesista (Desarrollado r) Conocimientos relacionados con el proyecto. Análisis, diseño y desarrollo de aplicaciones web. 2 Debe pertenecer a la institución y se encargará de la revisión del documento y cumplimiento del plan de tesis. 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. Tabla 3 FORMACION DEL EQUIPO FUENTE: Elaboración propia 4.2. Recursos Institucionales En reuniones previas con la autoridad de la institución se definieron los requerimientos y soluciones tecnológicas a los mismos, para que el sistema supla las necesidades de la institución. La escuela Unidad Educativa San José de Collaqui, se compromete a dar las facilidades necesarias para la vialidad de este proyecto y el personal de la institución serán los encargados del uso del mismo. 57

72 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 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 Derecho universitario Hoja universitaria Talento Humano 365 horas 16/hora Borrador trabajo de grado Empastado Impresión de hojas

73 Servicios varios (agua, luz, Internet, alimentación, transporte,etc) 7 meses Imprevistos Total Tabla 4 COSTOS FUENTE: Elaboración propia 4.5. Cronograma ANEXO2 DETALLE DEL CRONOGRAMA 59

74 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 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. 60

75 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. 61

76 BIBLIOGRAFIA WEB (1) Tesis de Grado ERP-Social 2012 Consultado el día 4 de marzo de 2013 desde (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 (4) Población de Tumbaco Consultado el día 4 de Agosto de 2013 desde (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 (7) Modelo en V Consultado el día 16 de Noviembre de 2013 desde prezi.com/ryyutemqk5go/ingeniería-de-software-modelo-en-v (8) Niveles lógicos del Modelo en V Consultado el día 16 de Noviembre de 2013 desde ingenieriadesoftware.mex.tl/61885_modelo-v.html (9) Ventajas absolutas y relativas del Modelo en V Consultado el día 25 de Noviembre de 2013 desde (10) Modelos de Proceso de software Consultado el día 25 de Noviembre de 2013 desde (11) Kruchten, P (1996). A rational Development Process.Consultado el día 15 de Diciembre de 2013 desde (12) Especificación de requerimientos, estándar IEEE830 Consultado el día 10 de Diciembre de 2013 desde 830/ 62

77 (13) Características de Especificación de requerimiento con estándar IEEE830 Consultado el día 10 de Diciembre de 2013 desde (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 (16) Postgress Consultado el día 14 de Enero de 2014 desde es.wikipedia.org/wiki/postgresql (17) Ventajas de Postgress Consultado el día 14 de Enero de 2014 desde es.slideshare.net/brobelo/postgresql. (18) Servidor de aplicaciones JBoss Consultado el día 14 de Enero de 2014 desde (19) Servidor de aplicaciones JBoss Consultado el día 14 de Enero de 2014 desde (20) Lenguaje de programación Java Consultado el día 14 de Enero de 2014 desde (21)Librería de componentes Primefaces Consultado el día 14 de Enero de 2014 desde (22) Pruebas de software Consultado el día 05 de Noviembre de 2014 desde 63

78 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: 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 Ninguno Afectados: 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 64

79 Teléfono: Estado del proveedor: Vigente o no vigente Cedula o Ruc Ciudad: Se seleccionaran de los campos creados que será tomado del catálogo de cuidad-país Notas. 2. En la opción de proveedores deberá existir la opción de buscar aquellos nombres que hayan sido registrados. Las consultas se podrán realizar a nivel de cedula o Ruc, nombres, estado. 3. Estos datos deberán ser guardados y estar disponibles para consultas. 4. Debe permitir realizar la actualización de los datos. 5. Enlistar de manera vertical las opciones que se despliegan. 6. No se podrá eliminar al proveedor registrado. Tabla 5 REQUERIMIENTO FUNCIONAL PROVEEDORES FUENTE: Elaboración propia 2. Ingreso de productos Cliente: Unidad Educativa Fecha: Módulo : Inventario Sub-módulo : Ingresar Productos Requerimiento: Información del bien Número: 2 Tipo de Requerimiento: Requerimiento Estado: Definido Categoría: Necesario Prioridad: Alta Complejidad: Media Tiemp Alcance 65

80 o (DH): Módulos Ninguno Afectados: 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. 66

81 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. 67

82 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. 68

83 4. En marca/material se deberá seleccionar la opción por cada una de las líneas creadas (Línea: Teléfonos, Marca: Nokia, LG etc.) EL botón INSERTAR deberá permitir almacenar la información ingresada. El botón cancelar deberá permitir regresar a la pantalla principal y no guardara ninguna información. El botón limpiar permitirá vaciar todos los campos para poder llenar la información necesaria. Cuando se presionen los botones GUARDAR, CANCELAR se deberá presentar mensajes de confirmación por parte del usuario para ejecutar las acciones especificadas. Tabla 6 REQUERIMIENTO FUNCIONAL INGRESO DE PRODUCTOS FUENTE: Elaboración propia 3. Consulta de bienes Cliente: Unidad Educativa Fecha: Módulo : Inventario Sub-módulo : Consulta de bienes según su estado Requerimiento: Inventario Número: 3 Tipo de Requerimiento Estado: Definido Requerimiento: Alcance 69

84 Categoría: Indispensable Prioridad: Alta Complejidad: Media Tiemp o (DH): Módulos Ninguno Afectados: 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 70

85 para la descarga. SOLUCIÓN FUNCIONAL: La opción de consulta deberá tener un control de los bienes que ingresan a diario a las Instituciones Educativas que usen el sistema. Vamos a seleccionar la opción mediante la cual deseamos que se nos genere la consulta de acuerdo a las siguientes opciones 1. Se deberá seleccionar la Categoría de los Bienes a Filtrar. 2. Selección de Línea. 3. Generación del Reporte en Excel, clic en el botón del icono de Excel, luego de haber realizado las elecciones necesarias para la generación del informe requerido. Tabla 7 REQUERIMIENTO FUNCIONAL CONSULTA BIENES FUENTE: Elaboración propia 71

86 4. Mantenimiento tabla de inventarios Cliente: Unidad Educativa Fecha: Módulo : Activo Fijo Sub-módulo : Mantenimiento tabla Activo Fijo Requerimiento: Verificación de Activo Fijo Número: 4 Tipo de Requerimiento: Requerimiento Estado: Definido Alcance Categoría: Indispensable Prioridad: Alta Complejidad: Media Tiemp o (DH): Módulos Ninguno Afectados: 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 72

87 Deberá contener los campos ID, NOMBRE, EDITAR, ELIMINAR, Por ejemplo es activo, inactivo. Tabla Estado de Bien Deberá contener los campos ID, NOMBRE, EDITAR, ELIMINAR, Por ejemplo será Activado, Desactivado Tabla Tipo de Bien Deberá contener los campos ID, NOMBRE, EDITAR, ELIMINAR, Por ejemplo será donación, Adjudicación. Tabla Estado de conservación del Bien Deberá contener los campos ID, NOMBRE, EDITAR, ELIMINAR, Por ejemplo será Bueno, Malo, Regular. Tabla Estado del Bien Deberá contener los campos ID, NOMBRE, EDITAR, ELIMINAR, Por ejemplo será asignado, reasignado, ingresado. Tabla de Categoría Debe contener los campos ID, NOMBRE, EDITAR, ELIMINAR. Por ejemplo Muebles, Equipos de oficina. Manejar la estructura para la creación del cualquier catalogo Tabla de enlace Línea Marca Deberá contener los campos ID, LINEA, EDITAR, ELIMINAR Cuando se realiza la selección de línea de producto se podrá ingresar una nueva marca 73

88 Tabla de Marca de Bien Deberá contener los campos ID, NOMBRE, EDITAR, ELIMINAR Tabla Tipo de Ingreso Deberá contener los campos ID, NOMBRE, EDITAR, ELIMINAR, Por ejemplo será Adquisición, donación. SOLUCIÓN FUNCIONAL: 74

89 Se desarrolla una pantalla en la cual se detalla las características del bien como nombre, ubicación, custodio fecha de ingreso el estado físico todo esto se registra en la tabla de transacción en la base de datos. CUADRO 1 REQUERIMIENTO FUNCIONAL MANTENIMIENTO INVENTARIO FUENTE: Elaboración propia 75

90 5. Reportes Cliente: Unidad Educativa Fecha: Módulo : Activo Fijo Sub-módulo : Reportes Requerimiento: Presentación de reportes Número 5 Tipo de Requerimiento: Requerimiento Estado: Definido Alcance Categoría: Indispensable Prioridad Alta Complejidad: Media Tiemp o (DH): Módulos Ninguno Afectados: 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 76

91 Actual, ubicación Anterior, ubicación Actual, Fecha de Transferencia, se lo manejara a través de la trazabilidad de cada bien donde se detalla el movimiento entre custodios, fechas y estados. SOLUCIÓN FUNCIONAL: 1. El Reporte deberá mostrar información con los siguientes datos: Código Categoría Líneas del bien Marca o material del cual se necesita saber la información. Tipo de bien Ubicación Estado Custodio Fecha de ingreso 2. Reporte que permita verificar los bienes según los siguientes detalles: Código Proveedor Línea de producto Modelo Color Fecha de asignación Custodio Estado Estado de conservación 3 Generar un reporte sobre los movimientos que tenido los bienes sea por motivo de alta, baja, por funcionarios, por fechas del movimiento, 77

92 activo, funcionario. 4 Reporte Altas de Activos Para generar este reporte se deberá poder filtrar por: activo), código del bien, categoría, línea, Fecha de Baja por rango de fechas ( Desde, Hasta ), ordenados por la fecha de baja., Condición del Bien ( Sin Uso, En Uso, Todos ), Por cada grupo adicional a la descripción del criterio de agrupación, deberá también mostrar el número de ítems, y por cada grupo y sub grupo En el cuerpo del reporte, los campos mínimos que deberá presentar son: Código del Bien, su Descripción, No. de Serie, Marca, Valor Adquisición, Fecha Adquisición, ubicación, Funcionario, Cantidad, Condición del Bien. 5 Reporte de baja de activos Para generar este reporte se deberá poder filtrar por: activo), código del bien, categoría, línea, Fecha de Baja por rango de fechas ( Desde, Hasta ), ordenados por la fecha de baja. Por cada grupo adicional a la descripción del criterio de agrupación, deberá también mostrar el número de ítems, y por cada grupo y sub grupo En el cuerpo del reporte, los campos mínimos que deberá presentar son: Código del Bien, su Descripción, No. de Serie, Marca, Fecha Adquisición, Fecha de Baja, ubicación, Funcionario, Cantidad. Cuando ya se realicen todas las selecciones deberá realizar un enlace a una página en Excel. En el caso de imprimir se deberá seleccionar el icono de imprimir y este será en formato pdf. Tabla 8 REQUERIMIENTO FUNCIONAL REPORTE FUENTE: Elaboración propia 78

93 6. Traslado y transacción Cliente: Unidad Educativa Fecha: Módulo : Activo Fijo Sub-módulo : Consulta de Ingreso y Salida Requerimiento: Traslado y transacción Número: 6 Tipo de Requerimiento: Requerimiento Estado: Definido Alcance Categoría: Indispensable Prioridad: Alta Complejidad: Media Tiemp o (DH): Módulos Ninguno Afectados: 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 79

94 empleado a la cual se encuentra registrado el bien Empleado reasignado: Este campo se encuentra registrado el empleado a la cual se realizara la nueva asignación registrado el bien. Fecha de transacción: Este campo se registra la fecha en la cual se realizó el movimiento de los bienes. Estado de la transacción: Este campo se encuentra si está activo, inactivo. Esta pantalla debe permitir realizar guardar, editar,eliminar La búsqueda puede realizarse por transacción, fecha de transacción, código de trasferencia. Alta del Bien Crear las pantalla para la creación de la alta en la cual se procederá a la asignación del bien a un funcionario de la institución realizando un traslado de los bienes del bodeguero a un nuevo funcionario en el cual se encuentra el código del bien, nombre del funcionario, fecha de asignación y una descripción en la cual se puede indicar un detalle del bien, Se genera un secuencial par ale ingreso de las altas del bien. Se llamara al catálogo de categoría y línea para definir los atributos del bien. Debe permitir guardar,editar, eliminar de forma lógica es decir un cambio de estado a inactivo no se debe afectar a la base de datos TRAZABILIDAD DEL BIEN.- Se solicita que en una pantalla se encuentre la historia del bien desde el ingreso a bodega, los cambios de custodia las reasignaciones. EL tipo de movimiento sea una Alta o baja. Fechas en las cuales se realizó los movimientos. Ubicación actual del bien. Detallar los funcionarios que se encontraban en custodia del bien. CUADRO 2 REQUERIMIENTO FUNCIONAL TRANSACCION Y TRAZABILIDAD FUENTE: Elaboración propia 80

95 7. Transferencia de bienes Cliente: Unidad Educativa Fecha: Módulo : Activo Fijo Sub-módulo : Consulta de Ingreso y Salida Requerimiento: Transferencia Número: 7 Tipo de Requerimiento: Requerimiento Estado: Definido Alcance Categoría: Indispensable Prioridad Alta Complejidad: Media Tiemp o (DH): Módulos Ninguno Afectados: Req. --- Asociados: Anexos: DESCRIPCIÓN DEL REQUERIMIENTO: TRASFERENCIA ENTRE CUSTODIOS Y TRANSACCIONES. TRASLADO ENTRE CUSTODIOS Dentro del proceso de transferencia de bienes entre Custodios buscar los activos por el código del bien e irlo agregando a la orden de transferencia ítem por ítem, este criterio de búsqueda será opcional por lo que si no es ingresado se desplegará en la grilla todos los bienes asignados al Custodio que va transferir. El botón Buscar que aplique la búsqueda en base a los criterios seleccionados ya que existe funcionarios como los de bodega que poseen gran cantidad de bienes asignados y la actual funcionalidad limitaría mucho el tema de la asignación de un bien. Tabla 9 REQUERIMIENTO FUNCIONAL TRASLADO ENTRE CUSTODIOS FUENTE: Elaboración propia 81

96 8. Baja de bienes Cliente: Unidad Educativa Fecha: Módulo : Activo Fijo Sub-módulo : Baja de Bienes Requerimiento: Activo Fijo Número: 8 Tipo de Requerimiento: Requerimiento Estado: Definido Alcance Categoría: Indispensable Prioridad Alta Complejidad: Media Tiemp o (DH): Módulos Ninguno Afectados: 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. 82

97 SOLUCIÓN FUNCIONAL: 1 Descripción de las Modificaciones 1.1Proceso de Bajas / Definición de catálogos Añadir los catálogos necesarios para el proceso de Bajas, los mismos que se detallan a continuación: CATALOGO DE ESTADO BAJAS ESTADOS Código Descripción 01 ASIGNADO 02 NO ASIGNADO CATALOGO DE TIPO DE BAJAS TIPO DE MOVIMIENTO Código Descripción TIPO 01 BAJAS POR PÉRDIDA BAJAS 02 BAJAS POR ROBO BAJAS 03 BAJAS TOTAL BAJAS 04 BAJAS POR DONACION BAJAS EJEMPLO DE UN CASO DE BAJA: CASO

98 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. 84

99 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 ESTADO BIEN BIEN PIZARRON S00001 SIN USO ESCRITORIO M00009 SIN USO COMPUTADOR E00099 EN USO Tabla 10 REQUERIMIENTO FUNCIONAL BAJA DE BIENES FUENTE: Elaboración propia 85

100 ANEXO 2 CRONOGRAMA - 1 -

101 - 2 -