Desarrollo de un sistema informático para la automatización del control de inventario by Pontificia Universidad Católica del Ecuador sede Santo Domingo PUCE SD

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica - Escuela de Sistemas

DESARROLLO DE UN SISTEMA INFORMÁTICO PARA LA AUTOMATIZACIÓN DEL CONTROL DE INVENTARIO DE ACTIVOS FIJOS Y BIENES, UTILIZANDO SOFTWARE LIBRE, PARA LA UNIDAD EDUCATIVA DEL “MILENIO MI INUN YA” EN EL CANTÓN SANTO DOMINGO DE LOS COLORADOS. AÑO 2014.

Disertación de Grado previa a la obtención del título de Ingeniero de Sistemas y Computación

Línea de Investigación: Estudio, Diseño e Implementación de Software

Autores: CÉSAR MAURICIO TAMAYO LÓPEZ JADIRA JOHANNA BARRIGA VALLEJO

Director: ING. MARGOTH ELISA GUARACA MOYOTA

Santo Domingo – Ecuador Febrero, 2015

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO Dirección Académica - Escuela de Sistemas

HOJA DE APROBACIÓN DESARROLLO DE UN SISTEMA INFORMÁTICO PARA LA AUTOMATIZACIÓN DEL CONTROL DE INVENTARIO DE ACTIVOS FIJOS Y BIENES, UTILIZANDO SOFTWARE LIBRE, PARA LA UNIDAD EDUCATIVA DEL MILENIO “MI INUN YA” EN EL CANTÓN SANTO DOMINGO DE LOS COLORADOS. AÑO 2014. Línea de Investigación: Estudio, Diseño e Implementación de Software

Autores: CÉSAR MAURICIO TAMAYO LÓPEZ JADIRA JOHANNA BARRIGA VALLEJO

Ing. Margoth Elisa Guaraca Moyota DIRECTOR DE LA DISERTACIÓN DE GRADO Msc. Diego Ricardo Salazar Armijos CALIFICADOR Msc. Rodolfo Sirilo Córdova Gálvez CALIFICADOR Msc. Rodolfo Sirilo Córdova Gálvez DIRECTOR DE LA ESCUELA DE SISTEMAS

Santo Domingo – Ecuador Febrero, 2015

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Nosotros, Jadira Johanna Barriga Vallejo portadora de la cédula de ciudadanía Nº. 171616142-5 y César Mauricio Tamayo López portador de la cédula de ciudadanía Nº. 172490944-3, declaramos que los resultados obtenidos en la investigación que presentamos como informe final, previo la obtención del Grado de Ingenieros de Sistemas y Computación son absolutamente originales, auténticos y personales. En tal virtud, declaramos que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de nuestra sola y exclusiva responsabilidad legal y académica.

Jadira Johanna Barriga Vallejo C.C. 171616142-5

César Mauricio Tamayo López C.C. 172490944-3

AGRADECIMIENTO Agradecemos a Dios por ser nuestra guía espiritual en cada momento de nuestras vidas y gracias a él hemos llegado alcanzar nuestras metas. A nuestros padres quienes con su amor han estado en las buenas y en las malas, brindándonos todo su apoyo y comprensión. Agradecemos a las autoridades de la Unidad Educativa del Milenio “MI INUN YA” por brindarnos todo el apoyo necesario para realizar este proyecto. A la Pontificia Universidad Católica del Ecuador Sede Santo Domingo por habernos enseñado los valores y virtudes para poder convertirnos en unos profesionales de éxito.

JADIRA JOHANNA BARRIGA VALLEJO CÉSAR MAURICIO TAMAYO LÓPEZ

DEDICATORIA Dedicamos el presente proyecto a nuestros padres y demás familia quienes son nuestra guía en la vida diaria. A dios quien es el que nos da la fortaleza para cumplir nuestras metas y culminarlas de la mejor manera.

JADIRA JOHANNA BARRIGA VALLEJO CÉSAR MAURICIO TAMAYO LÓPEZ

RESUMEN La presente disertación tiene como objetivo el diseño y desarrollo de un sistema informático para la automatización del control de inventario de activos fijos y bienes de la Unidad Educativa del Milenio “MI INUN YA”, con la implementación de este sistema se pretende optimizar el tiempo y mejorar el control de inventario, de esta forma la calidad del servicio que brinda el área de inventario mejorará.

Los beneficiarios directos serán el

personal docente, administrativo y autoridades de la institución así como la comunidad en general ya que parte del inventario es donado en ocasiones. Para poder cumplir con los objetivos de este proyecto se utilizó herramientas de software libre como lo son Java para la codificación del sistema, PostgreSQL como motor de base de datos y PgModeler como diseñador de la base de datos, además se usó la metodología de desarrollo XP llamada también programación extrema. La importancia que tiene el desarrollo de este proyecto, nos demuestra que será de gran ayuda en la comunidad, permitiendo sustentar y demostrar la necesidad de implementar este tipo de tecnologías en la actualidad. Esto y mucho más es lo que ofrece el presente proyecto en el cual las tecnologías de la información permitirán brindar respuestas eficientes para cada uno de los problemas en cuestión.

vii

ABSTRACT The present research Project has as objective the design and development of a computer program for the automation of the inventory control of fixed assets and goods from the Unidad Educativa del Milenio â&#x20AC;&#x153;MI INUN YAâ&#x20AC;?, with the implementation of this system the time optimization and improvement of the inventory control is tried, this way the quality of the service given by the inventory will improve. The direct beneficiaries will be teachers` staff, administrative staff and the authorities of the institution as well as the community in general since part of inventory is used for contributions. To archive the planning objectives in this project free software tools were used such as Java for system codification, PostgreSQL as the generator of database and PgModeler as designer of the database, besides the methodology of XP development was used to extreme programming. The importance of this project, shows it will be quite useful in the community allowing supporting and showing the need of implementing this kind of technology nowadays. This is some of the aspects that this project provides, in which information technologies will give efficient answers for each of the issues mentioned.

viii

ÍNDICE DE CONTENIDOS

HOJA DE APROBACIÓN ........................................................................................................ii DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD ...................................... iii AGRADECIMIENTO .............................................................................................................. iv DEDICATORIA ........................................................................................................................ v RESUMEN ............................................................................................................................... vi ABSTRACT.............................................................................................................................vii 1.

INTRODUCCIÓN ..................................................................................................... 14

PLANTEAMIENTO DEL PROBLEMA .................................................................. 16

2.1.

Antecedentes......................................................................................................................... 16

2.2.

Problema de investigación .................................................................................................... 16

2.3.

Justificación de la investigación............................................................................................. 17

2.3.1.

Impactos ................................................................................................................................ 19

2.4.

Objetivos de investigación..................................................................................................... 19

2.4.1.

Objetivo General.................................................................................................................... 19

2.4.2.

Objetivos Específicos ............................................................................................................. 20

MARCO REFERENCIAL......................................................................................... 21

3.1.

Revisión de la literatura o fundamentos teóricos ................................................................. 21

3.1.1.

Inventario .............................................................................................................................. 21

3.1.2.

Ingeniera de Software ........................................................................................................... 21

3.1.3.

Ciclo de vida del Software ..................................................................................................... 21

ix 3.1.4.

Metodología para el Desarrollo de Sistemas de Información ............................................... 21

3.1.5.

Software ................................................................................................................................ 22

3.1.6.

Modelos del proceso descriptivo .......................................................................................... 23

3.1.7.

Base de Datos ........................................................................................................................ 24

3.1.8.

Lenguajes de Programación .................................................................................................. 26

3.1.9.

Forma de ejecución ............................................................................................................... 27

3.1.10.

Tecnología ............................................................................................................................. 27

3.1.11.

Programación Extrema .......................................................................................................... 28

3.1.12.

Valores en XP ......................................................................................................................... 28

3.1.13.

Fases de la Programación Extrema........................................................................................ 29

3.1.13.1. Planificación........................................................................................................................... 29 3.1.13.2. Diseño .................................................................................................................................... 30 3.1.13.3. Pruebas .................................................................................................................................. 32 3.2.

Investigaciones o experiencias empíricas vinculadas con el problema de investigación..... 33

METODOLOGÍA DE LA INVESTIGACIÓN ......................................................... 35

4.1.

Diseño / Tipo de investigación .............................................................................................. 35

4.1.1.

Diseño de Investigación ......................................................................................................... 35

4.1.2.

Tipo de Investigación ............................................................................................................. 35

4.2.

Población / Universo ............................................................................................................. 35

4.3.

Muestra ................................................................................................................................. 35

4.4.

Instrumentos de recogida de datos....................................................................................... 36

4.4.1.

Entrevista ............................................................................................................................... 36

x 4.4.2.

Encuesta ................................................................................................................................ 36

4.4.3.

Observación ........................................................................................................................... 36

4.5.

Técnicas de Análisis de Datos ................................................................................................ 37

4.5.1.

Análisis Estadístico................................................................................................................. 37

4.6.

Metodología de Desarrollo .................................................................................................... 37

4.6.1.

Programación Extrema XP ..................................................................................................... 37

4.6.1.2. Diseño .................................................................................................................................... 40 4.6.1.3. Codificación ........................................................................................................................... 41 4.6.1.4. Pruebas .................................................................................................................................. 43

RESULTADOS ......................................................................................................... 45

5.1.

Análisis y Discusión de los resultados.................................................................................... 45

5.1.1.

Encuesta aplicada al personal docente y administrativo de la Unidad Educativa del Milenio “MI INUN YA”......................................................................................................................... 45

5.1.2.

Entrevista ............................................................................................................................... 56

5.1.3.

Observación ........................................................................................................................... 57

5.1.4.

Metodología de desarrollo Programación Extrema en la elaboración del Sistemas de control de Inventario de activos fijos y bienes. ..................................................................... 57

5.1.5.

Proceso de Desarrollo de la Metodología XP ........................................................................ 57

5.1.6.

Planificación........................................................................................................................... 57

5.1.7.

Diseño .................................................................................................................................... 61

5.1.7.1. Modelado de la base de datos SICIAF ................................................................................... 64 5.1.8.

Codificación ........................................................................................................................... 65

xi 5.1.9.

Pruebas .................................................................................................................................. 65

5.1.10.

Entrega del Sistema ............................................................................................................... 65

5.1.11.

An谩lisis y discusi贸n de los resultados .................................................................................... 66

5.2.

Conclusiones .......................................................................................................................... 67

5.3.

Recomendaciones ................................................................................................................. 68

xii

ÍNDICE DE TABLAS

Tabla 1: Investigaciones o experiencias Empíricas ................................................................. 33 Tabla 2: Información previa de la encuesta aplicada ............................................................... 45 Tabla 3: Uso del inventario de activos fijos y bienes. ............................................................. 46 Tabla 4: Frecuencia en el uso del inventario de activos fijos y bienes. ................................... 47 Tabla 5: Proceso de control y actualización del inventario de activos fijos y bienes. ............. 48 Tabla 6: Tiempo empleado en el control del inventario de activos fijos y bienes. .................. 49 Tabla 7: Cambio del proceso actual de control de inventario de activos fijos y bienes. ......... 50 Tabla 8: Optimización de procesos en el control de inventario de activos fijos y bienes. ...... 51 Tabla 9: Reacción por la implementación de un sistema informático para el control de inventario de activos fijos y bienes. ......................................................................................... 52 Tabla 10: Proceso de transición de control manual a control automático de inventario de activos fijos y bienes. ............................................................................................................... 53 Tabla 11: Procesos del inventario de activos fijos y bienes deben ser auditables. .................. 54 Tabla 12: Implementación de una aplicación para el control del inventario de activos fijos y bienes. ...................................................................................................................................... 55 Tabla 13: Especificación de Requerimientos de Software SICIAF ......................................... 58 Tabla 14: Historias de Usuarios SICIAF ................................................................................. 59 Tabla 15: Iteraciones ................................................................................................................ 60

xiii

ร NDICE DE FIGURAS

Figura 1: Uso del inventario de activos fijos y bienes. ............................................................ 46 Figura 2: Frecuencia en el uso del inventario de activos fijos y bienes. .................................. 47 Figura 3: Proceso de control y actualizaciรณn del inventario de activos fijos y bienes............. 48 Figura 4: Proceso de control y actualizaciรณn del inventario de activos fijos y bienes............. 49 Figura 5: Cambio del proceso actual de control de inventario de activos fijos y bienes. ........ 50 Figura 6: Optimizaciรณn de procesos en el control de inventario de activos fijos y bienes. ..... 51 Figura 7: Reacciรณn por la implementaciรณn de un sistema informรกtico para el control de inventario. ................................................................................................................................ 52 Figura 8: Proceso de transiciรณn de control manual a automรกtico de inventario de activos fijos y bienes. ................................................................................................................................... 53 Figura 9: Procesos del inventario de activos fijos y bienes deben ser auditables. ................... 54 Figura 10: Implementaciรณn de una aplicaciรณn para el control del inventario de activos fijos y bienes. ...................................................................................................................................... 55 Figura 11: Login de Usuario. ................................................................................................... 61 Figura 12: Interfaz Principal. ................................................................................................... 61 Figura 13: Interfaz del Mรณdulo de Productos. ........................................................................ 62 Figura 14: Interfaz de Orden de Ingreso. ................................................................................. 62 Figura 15: Interfaz de Orden de Pedido. .................................................................................. 63 Figura 16: Interfaz del Mรณdulo de Proveedores. .................................................................... 63 Figura 17: Interfaz del Mรณdulo de Personal. .......................................................................... 64 Figura 18: Modelo Entidad โ Relaciรณn de la base de datos. .................................................... 64 Figura 19: Codificaciรณn de la conexiรณn a la base de datos en la herramienta Netbeans. ........ 65

INTRODUCCIÓN

En la actualidad la educación en el Ecuador ha sufrido cambios significativos, uno de estos cambios es el mejoramiento de la calidad de estudio y para esto un factor importante es la creación de Unidades Educativas del Milenio, esto permitirá que muchas familias de escasos recursos económicos puedan tener una educación gratuita y de calidad. Hoy en día la tecnología es algo común para el buen vivir ya que nos facilita muchas tareas por ello el uso de aplicaciones informáticas harán que la calidad en el servicio mejore significativamente. El presente proyecto hace referencia al desarrollo de una solución informática para automatizar el control de inventario de activos fijos y bienes de la Unidad Educativa del Milenio “MI INUN YA” la cual no cuenta con un sistema informático que facilite su proceso. Para su mayor comprensión la disertación se encuentra estructurada de la siguiente manera: En la II sección contiene el Planteamiento del Problema en el que se da a conocer los servicios que presta la Unidad Educativa y los inconvenientes del problema, que conlleva al proyecto de investigación, incluyendo la delimitación del problema y se especificó lo que se va a solucionar por medio de la investigación. Se detalla la justificación del proyecto, beneficiarios y los impactos que conllevan el desarrollo del sistema. Se planteó el objetivo general y los objetivos específicos que detallaron los procedimientos para cumplir el objetivo principal. En la III sección contiene el marco referencial o estado del arte en el que se detalló los fundamentos teóricos utilizados en el proyecto de investigación, los cuales fueron un respaldo para orientar nuestra búsqueda mediante una conceptualización adecuada de los términos que utilizaremos. También se detalló las experiencias empíricas vinculadas con el problema de investigación. En la sección IV contiene la metodología de desarrollo en la cual se detalla el tipo y diseño de investigación utilizada para el desarrollo del proyecto, así también se definió la población o universo para cual se realizó la investigación, especificando la muestra tomada para la utilización de la encuesta, también contiene los instrumentos de recogida de datos los

cuales apoyaron al desarrollo del proyecto. Y para finalizar esta sección se define la metodología de desarrollo XP, detallando cada una de sus fases. En la IV sección, se da a conocer la interpretación y análisis de los resultados obtenidos en la investigación incluyendo los resultados de la metodología de desarrollo de software en algunas de sus fases, finalizando con las conclusiones pertinentes basándonos en los resultados obtenidos en la investigación y las recomendaciones en base a el desarrollo del proyecto.

2. 2.1.

PLANTEAMIENTO DEL PROBLEMA

Antecedentes La Unidad Educativa del Milenio “MI INUN YA”, se encuentra ubicada en la ciudad

de Santo Domingo de los Tsáchilas, es una institución pública que ofrece a la comunidad los servicios de jardín, escuela y colegio para las familias de escasos recursos económicos. Una entidad la cual tiene como objetivo formar a niños y jóvenes con valores humanos y un alto conocimiento que les permita sobresalir en las diferentes actividades de la vida cotidiana. Al contar con una cantidad significativa de activos fijos y bienes conlleva a que el plantel deba administrar dicha información por medio de un sistema informático, es por ello que si no se cuenta con dicho sistema, la información puede a llegar a perderse o ser manipulada fácilmente por propios y extraños del plantel. En la actualidad la unidad educativa realiza cada uno de los procesos de inventario manualmente con ayuda de una herramienta conocida como Excel, pero no llevan un control automatizado es decir cuando ingresa o sale inventario se debe descontar de forma manual, es por tal motivo que en muchas ocasiones existe inconsistencia de la información. Cada vez que ingresan nuevos activos fijos y bienes a la Unidad Educativa se vuelve un caos ya que todo el proceso de inventario se lleva acabo manualmente y algunas veces se producen errores de existencia e inconsistencia de la información. Por este motivo se desarrollará un sistema para el control de activos fijos y bienes ya que dicho sistema agilizará el proceso de inventariado y automatizará algunos subprocesos, esto permitirá que el encargado pueda realizar y brinda un mejor servicio.

2.2.

Problema de investigación El problema de investigación surge debido a que el proceso de control y manejo de

inventario tanto de activos fijos y bienes es realizado de forma manual y llevado a cabo en hojas de Excel. A consecuencia de este proceso manual y poco adecuado la integridad, confiabilidad y consistencia de la información se ven afectadas, debido que al comparar la información en físico y digital no concuerdan en ocasiones, lo que causa problemas al

momento de presentar informes a las autoridades que corresponden, además al momento de realizar una adquisición, registro o entrega de inventario no se conoce en tiempo real si existen o no. La constante demanda de inventario por parte del personal docente y administrativo y el no contar con un sistema de control que automatice el proceso de ingreso, registro y préstamo de inventario hace que presenten los problemas descritos anteriormente. Por todo lo antes mencionado es necesario desarrollar un sistema de control de inventario ajustado a las necesidades de la institución educativa que permita mejorar el tiempo y la calidad del servicio en el control de inventario, el mismo que también ayudará a mejorar la calidad de servicio que se brinda al personal docente y administrativo de la institución. 2.2.1

Preguntas Básicas

¿Mejorará el desempeño laboral del encargado del control de inventarios con la implementación del sistema informático? ¿Mejorará el proceso del control de inventario de activos fijos y bienes en la Unidad Educativa? ¿Cuál es el grado de aceptación del sistema por parte del personal y autoridades de la Unidad Educativa?

2.3.

Justificación de la investigación Actualmente la Unidad Educativa por ser una entidad pública, está obligada a llevar

un control de inventarios, conforme lo que establece la norma de control de bienes de la Contraloría General del Estado (Anexo 1), la institución no tiene a su disposición un sistema de software para el control de inventario de activos fijos y bienes, por eso se considera factible el desarrollo de una aplicación informática para el proceso de control de inventarios, porque esto agilitará los procesos que se realizan manualmente hoy en día en la Unidad Educativa del Milenio “MI INUN YA”. El uso de una aplicación informática hoy en día es de gran utilidad en un mundo que cada vez se vuelve más digital y de a poco se está dejando la utilización de información

física. Las Tecnologías de la Información harán que este proceso se lleve a cabo de la mejor manera. Debido a la necesidad por parte de las autoridades de la Unidad Educativa del Milenio “MI INUN YA” de llevar un control de inventario de sus activos fijos y bienes, actualmente se utiliza la herramienta Excel para poder realizar el proceso, sin embargo no ha sido de gran utilidad debido que la forma en la que llevan los procesos no es la mejor y la herramienta no ayuda a cubrir todas las necesidades (Anexo 2), en vista de eso se justifica la implementación de un sistema informático para la automatización de los procesos en el control de activos fijos y bienes. El sistema se basara únicamente en la automatización del control inventarios de activos fijos y bienes de la misma manera que es llevado el proceso actualmente en la Unidad Educativa del Milenio “MI INUN YA”, en el cantón santo domingo de los colorados en el año 2014, desligándose de cualquier posibilidad de acoplarse algún otro sistema como sistemas de facturación o contabilidad. El desarrollo del sistema es factible ya que se utilizará software libre lo cual no implicará un costo en licencias para su desarrollo tanto para el diseño de la base de datos como para la codificación del sistema. La utilización de software libre reducirá el factor económico y estará acorde con la normativa del Ministerio de Educación ya que por disposiciones del gobierno, las instituciones públicas deberán trabajar con software libre. El desarrollo de la disertación es viable ya que cuenta con la autorización de las autoridades de la Unidad Educativa del Milenio “MI INUN YA” y con la experiencia necesaria en el desarrollo del sistema por parte de los disertantes. Beneficiarios Directos del Sistema: Unidad Educativa del Milenio “MI INUN YA”. •

Rector de la Unidad Educativa

•

Secretaria encargada de llevar el control de inventarios y activos fijos.

Beneficiarios Indirectos del Sistema: •

Personal Administrativo y de Servicios de la Instituciones

•

La sociedad en general

Además ayudará a que dicha institución pueda ser vista y reconocida por más instituciones en sus alrededores y convertirlos en un ejemplo de desarrollo y de opción de estudio para la comunidad. 2.3.1. •

Impactos Impacto económico Generará un ahorro para la Unidad Educativa pues evitará perdida de bienes puesto

que al estar en un sistema tendrá una mayor seguridad y respaldo. •

Impacto social Brindará a la Unidad Educativa mayor eficiencia y organización al manejarse de

manera más rápida y segura, dando a los usuarios beneficiarios mayor seguridad y confiabilidad al interactuar con el sistema. •

Impacto tecnológico El efecto generado por el uso del Sistema de Inventarios en la Unidad Educativa será

en gran parte sobre la información, la cual se almacenará de una forma más segura y confiable en una base de datos, esto permitirá contar con los datos de una manera ágil al momento de consultarlos, además de ello se reducirá la creación de distintos archivos de Excel ya que toda la información se generará a partir del uso del software.

2.4.

Objetivos de investigación

2.4.1.

Objetivo General Desarrollar un sistema informático para la automatización del control de inventario de

activos fijos y bienes, utilizando software libre, el mismo que permitirá mejorar el proceso de control de inventario de la Unidad Educativa del Milenio “MI INUN YA”.

2.4.2. •

Objetivos Específicos Analizar los recursos y requerimientos funcionales para el desarrollo del sistema de Control de Inventarios.

•

Modelar la base de datos y los respectivos módulos que conformarán el sistema.

•

Codificar los diferentes módulos que intervienen en el desarrollo del sistema de control de inventario de activos fijos y bienes

basados en el análisis de los

requerimientos previamente obtenidos. •

Realizar las pruebas para verificar el correcto funcionamiento del sistema.

•

Entregar el sistema informático de control de inventario de activos fijos y bienes a la unidad educativa.

MARCO REFERENCIAL

3.1.

Revisión de la literatura o fundamentos teóricos

3.1.1.

Inventario Un inventario son objetos tangibles almacenados en un determinado lugar para su

posterior uso. (Ormeño, Valverde, 2009) afirma que: “Inventario de materiales para (inventario parcial): cantidad y valor de los artículos almacenados para incorporarse al proceso productivo o venderlos; se obtiene una vez recontadas las existencias físicas del almacén” (p. 128). 3.1.1.1. Activos Fijos Los activos fijos son caracterizados por su larga duración y según (Vidauirrì, González, 2012): “Activos fijos son los bienes sujetos al desgaste, a las descomposturas y a los cambios en la tecnología. Ejemplos de activos fijos son: edificios, maquinaria, equipo de cómputo, mobiliario de oficina, etcétera.”(p.574). 3.1.2.

Ingeniera de Software Según Pressman (2010): La ingeniería de software es una tecnología con varias capas. Cualquier enfoque de ingeniería (incluso la de software) debe basarse en un compromiso organizacional con la calidad. La administración total de la calidad, Six Sigma y otras filosofías similares alimentan la cultura de mejora continua, y es esta cultura la que lleva en última instancia al desarrollo de enfoques cada vez más eficaces de la ingeniería de software. El fundamento en el que se apoya la ingeniería de software es el compromiso con la calidad. (p.12)

3.1.3.

Ciclo de vida del Software El ciclo de vida del software esta descrito por las fases que conlleva su desarrollo

desde la fase de inicio hasta su fase final, aquí intervienen un conjunto de procedimientos que ayudaran a que el software sea de calidad. 3.1.4.

Metodología para el Desarrollo de Sistemas de Información Una Metodología para el Desarrollo de Sistemas de Información es un conjunto de

actividades llevadas a cabo para desarrollar y poner en marcha un Sistema de Información.

(Castellanos, 2009) “Los Objetivos de las Metodologías de Desarrollo de Sistemas de Información son:

3.1.5.

•

Definir actividades a llevarse a cabo en un Proyecto de S.I.

•

Unificar criterios en la organización para el desarrollo de S.I.

•

Proporcionar puntos de control y revisión. Software

Son instrucciones (programas de cómputo) que cuando se ejecutan proporcionan las características, función y desempeño buscados; estructuras de datos que permiten que los programas manipulen en forma adecuada la información e información descriptiva tanto en papel como en formas virtuales que describen la operación y uso de los programas. (Pressman, 2010, p.12)

3.1.5.1. Software Libre Es aquel que puede ser distribuido, modificado, copiado y usado; por lo tanto, debe venir acompañado del código fuente para hacer efectivas las libertades que lo caracterizan. Dentro de software libre hay, a su vez, matices que es necesario tener en cuenta. Por ejemplo, el software de dominio público significa que no está protegido por el copyright, por lo tanto, podrían generarse versiones no libres del mismo, en cambio el software protegido con copyleft impide a los redistribuidores incluir algún tipo de restricción a las libertades propias del software así concebido, es decir, garantizan que las modificaciones seguirán siendo software libre. También es conveniente no confundir el software libre con el software gratuito, este no cuesta nada, hecho que no lo convierte en software libre, porque no es una cuestión de precio, sino de libertad. (Molina, Baena, 2007, p.134)

Es un sistema o programa que tiene una licencia libre ósea que su distribución no es pagada por lo tanto el software puede ser utilizado de varias maneras exceptuando su comercialización. 3.1.5.2. Software de sistemas Pressman (2010) afirma: “Es conjunto de programas escritos para dar servicio a otros programas” (p.6). 3.1.5.3. Software de aplicación Pressman (2010) afirma: “Son programas aislados que resuelven una necesidad específica de negocios” (p.6).

3.1.5.3.1 Software de Ingeniera y ciencias Pressman (2010) afirma: Se ha caracterizado por algoritmos “devoradores de números” (p.6). 3.1.5.4. Software incrustado Pressman (2010) afirma: “Reside dentro de un producto o sistema y se usa para implementar y controlar características y funciones para el usuario final y para el sistema en sí” (p.6). 3.1.5.5. Aplicaciones de Escritorio Las aplicaciones de escritorio están limitadas al ordenador y a la red en la se ejecuten, hoy en día se están dejando de lado este tipo de aplicaciones debido a la necesidad de portabilidad entre aplicaciones. Rocca (2013) afirma: Son aplicaciones creadas para ejecutarse en un ordenador de escritorio, sobre un sistema operativo de interfaz visual como Windows o Linux. - Programa que permite a un usuario utilizar una computadora con un fin específico. Las aplicaciones son parte del software de una computadora, y suelen ejecutarse sobre el sistema operativo.

3.1.6.

Modelos del proceso descriptivo Son modelos que permiten desarrollar software a través de procesos que van

evolucionando entre modelos. 3.1.6.1. Modelo en Cascada Es un modelo secuencial utilizado para el desarrollo de software, el primer paso es recolectar la información más importante por parte del cliente llamada especificación de requerimientos “y avanza a través de planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado.” (Pressman, 2010, 34). 3.1.6.2. Modelo Incremental Este modelo se caracteriza por contener fases del modelo en cascada Pressman (2010) refiere que combina procesos lineal y paralelo. El modelo incremental intercala secuencias lineales mientras el transcurre el desarrollo. “Cada secuencia lineal produce “incrementos” de software susceptibles de entregarse [McD93] de manera parecida a los incrementos producidos en un flujo de proceso evolutivo”.

3.1.6.3. Modelo de procesos evolutivos “Se caracterizan por la manera en la que permiten desarrollar versiones cada vez más completas del software. En los párrafos que siguen se presentan dos modelos comunes de proceso evolutivo.” (Pressman, 2010, 36). 3.1.7.

Base de Datos Es un conjunto organizado que puede estar en formato digital o físico además permite

almacenar información a gran escala siendo de gran utilidad al momento de su consulta Aizaga (2005) afirma: en informática existen los sistemas gestores de bases de datos (SGBD), que permiten almacenar y posteriormente acceder a los datos de forma rápida y estructurada. Las propiedades de los sistemas gestores de bases de datos se estudian en informática. 3.1.7.1. Arquitectura de una Base de Datos La arquitectura de una base de datos está conformada por tres niveles, desde el punto de vista de los usuarios: Nivel externo: Es el nivel de abstracción más alto conocido también como nivel de vistas, en donde cada usuario percibe solo una parte de la información, ya que no necesita conocer la base de datos completa para llevar a cabo su función. Nivel lógico: En este nivel se hace referencia a que datos se almacenan y a las relaciones que hay entre ellos, para el uso de éste se manejan distintos elementos como son entidades atributos y relaciones. Entidad es todo aquello a lo que se le da un concepto para poder distinguirlo de otros objetos, y son descritos por un conjunto de propiedades y atributos que son las características de una entidad y las relaciones son los enlaces que existen entre distintas entidades. El usuario que manipula este nivel de abstracción suele ser el administrador. Nivel físico: Es el nivel más bajo de una base de datos, en el cual se van almacenando los datos que existen de manera física en las unidades de almacenamiento del equipo, discos duros, cintas magnéticas, entre otros, donde reside la base de datos.(Ángel Cobo, 2010).

3.1.7.2. Variabilidad de la base de datos Las bases de datos pueden variar en su contenido y en cómo se maneja la información, considerando la importancia de este para la realización de los objetivos que se tienen planteados en su instanciación, presentando los siguientes tipos:

3.1.7.2.1 Bases de datos estáticas Estas son bases de datos de consulta, almacenan por lo general datos históricos que pueden ser de utilidad en lo posterior para un análisis de conjunto en función del tiempo, para así poder realizar proyecciones que podrán servir en la toma de decisiones. 3.1.7.2.2 Bases de datos dinámicas Éstas son en las que la información almacenada se modifica a través del tiempo, permitiendo operaciones como consulta, inserción, actualización y eliminación de datos. Como ejemplo de esto tenemos las bases de datos utilizadas en empresas para el manejo de su información, que por el mismo hecho de que las diferentes dependencias o departamentos intercambian datos, estos se verán alterados en el transcurso del tiempo. 3.1.7.2.3 Sistema Gestor de Base de Datos Es un sistema informático que permite la manipulación o manejo de la información que se encuentran almacenada en una Base de datos además de permitir tener integridad entre los datos y sus relaciones. 3.1.7.2.3.1 MySQL Es un sistema gestor de base de datos relacional, ya que permite la administración de la misma, de fácil y rápido uso, bajo licencia GPL. Se encuentra establecido en la arquitectura de cliente/servidor esto quiere decir que cada vez que se realice una conexión con el servidor este a su vez creerá un subproceso para establecer la comunicación con el cliente estableciendo un control de las solicitudes realizas por el mismo. (MySQL fourth edition, Paul DuBois, página 2)

3.1.7.2.3.2 PostgreSQL Como una opción de base de datos de software libre, se ha pensado en la alternativa de utilizar PostgreSQL, el cual ofrece una gran capacidad y disponibilidad de recursos y utilidades que van a ser de mucha utilidad durante el desarrollo. PostgreSQL es una base de datos transaccional, orientada a objetos de software libre con licencia libre BSD. Entre las características que lo hacen un SGBD de gran calidad, está su amplio conjunto de tipos de datos, la gran disponibilidad de API’s para adaptarlo a sistemas de distintos lenguajes, tales como: C, C++, Java, Perl, PHP, Python y TCL, entre otros. (Postgres succinctly, Peter Shaw, página 18)

3.1.8.

Lenguajes de Programación Naturalmente, un programa que se escribe en un lenguaje de alto nivel también tiene

que traducirse a un código que pueda utilizar la máquina. Si un programa se escribe en un lenguaje de alto nivel es necesario que se traduzca a un código que pueda utilizar la máquina. Los programas intérpretes que tienen la capacidad de realizar esta operación se denominan compiladores. En los lenguajes compilados, Se requiere sea realizada la compilación antes de que los datos de un problema sean procesados. Otra característica de estos lenguajes es que el programa desarrollado no se ejecuta mientras haya errores, debe ser compilado una vez que no aparecen errores en el código. 3.1.8.1.1 Nivel de abstracción Se clasifican en: lenguajes de máquina, lenguajes de bajo, medio y alto nivel. 3.1.8.1.2 Lenguajes máquina Son lenguajes que están escritos en lenguajes inteligibles por la máquina directamente, basándose en datos simples como instrucciones con cadenas binarias (0 y 1). 3.1.8.1.3 Lenguajes de bajo nivel Son lenguajes específicos de la arquitectura, es decir, los programas escritos en lenguajes de bajo nivel no son portables, por lo que solo se pueden ejecutar en el computador para el cual fueron diseñados. Se incluyen en esta categoría el lenguaje máquina y el lenguaje ensamblador. (Marta Jiménez Castells, 2013)

3.1.8.1.4 Lenguajes de medio nivel Estos son regularmente fáciles de aprender porque están formados usando los elementos de lenguajes naturales, como el idioma inglés. Estos son intermediarios entre los lenguajes de bajo y alto nivel, pues tienen algunas características que les permiten interactuar con ellos. Son adecuados para ciertas aplicaciones como es el caso de la creación de sistemas operativos, debido a que permite un manejo abstracto independiente de la máquina, pero sin perder mucho el poder y eficiencia que brindan los lenguajes de bajo nivel.

3.1.8.1.5 Lenguajes de alto nivel Estos pueden ser expresados en algoritmos de fácil entendimiento en lugar de ir dirigido a lo que puede interpretar la máquina. La razón de ser de los lenguajes de alto nivel es que han sido creados para que el usuario pudiera solucionar problemas de procesamiento de datos de manera más fácil y rápida. 3.1.8.1.5.1 Java Java es un Lenguaje de Programación de Programación orientado a objetos y, sin embargo, no todo lo que se utiliza es un objeto. En Java existen los tipos bases (como int, por ejemplo) que no son objetos y no hacen parte del árbol de las clases, a la raíz del cual está las clases Object. (Valeri, Naccarato, 2006, p. 6).

3.1.9.

Forma de ejecución

3.1.9.1.1 Lenguajes compilados “Los lenguajes de programación compilados tienen la ventaja de producir archivos ejecutables que puedan abrirse en cualquier ordenador personal, pero, a cambio, el programa debe ser compilados antes de ser probado.” (Curiel, 2014) Si un programa se escribe en un lenguaje de alto nivel es necesario que se traduzca a un código que pueda utilizar la máquina. Los programas intérpretes que tienen la capacidad de realizar esta operación se denominan compiladores. En los lenguajes compilados, Se requiere sea realizada la compilación antes de que los datos de un problema sean procesados. Otra característica de estos lenguajes es que el programa desarrollado no se ejecuta mientras haya errores, debe ser compilado una vez que no aparecen errores en el código. 3.1.10. Tecnología “La tecnología –saber cómo y por qué hacer--, persigue desarrollar soluciones prácticas a problemas y necesidades existentes, de un modo sistemático y ordenado”. (Cubino, R. 2001).

3.1.11. Programación Extrema La programación extrema es otro de los enfoques de la ingeniería de software. Es una metodología ágil y se diferencia de las tradicionales al intentar adaptarse a los cambio durante el desarrollo del proyecto en cualquiera de sus puntos, encuentran una gran ventaja al poder hacer cambios de los requerimientos en cualquier etapa puesto que si seguimos la rigidez de las metodologías tradicionales al definir requisitos al inicio del proyecto y controlar los cambios que se podrían producirse cambios en los requisitos. La programación tiene su prioridad en aumentar las relaciones interpersonales como base del éxito del proyecto intentando enfocarse en el trabajo en equipo para obtener un buen ambiente de trabajo incluso preocupándose por el aprendizaje continuo de los desarrolladores y la retroalimentación constante con el cliente. 3.1.12. Valores en XP Se basa en cuatro valores para obtener el éxito del Proyecto. Comunicación Muchos de los problemas que existen en proyectos de software (así como en muchos otros ámbitos) se deben a problemas de comunicación entre las personas. La comunicación permanente es fundamental en XP. Dado que la documentación es escasa, el diálogo frontal, cara a cara, entre desarrolladores, gerentes y el cliente es el medio básico de comunicación. Una buena comunicación tiene que estar presente durante todo el proyecto. (Mamani Quisbert Celia, 2012)

Simplicidad XP, como metodología ágil, apuesta a la sencillez, en su máxima expresión. Sencillez en el diseño, en el código, en los procesos, etc. La sencillez es esencial para que todos puedan entender el código, y se trata de mejorar mediante recodificaciones continuas. (Mamani Quisbert Celia, 2012)

Retroalimentación La retroalimentación debe funcionar en forma permanente. El cliente debe brindar retroalimentación de las funciones desarrolladas, de manera de poder tomar sus comentarios para la próxima iteración, y para comprender, cada vez más, sus necesidades. Los resultados de las pruebas unitarias son también una retroalimentación permanente que tienen los desarrolladores acerca de la calidad de su trabajo. (Mamani Quisbert Celia, 2012)

Coraje Cuando se encuentran problemas serios en el diseño, o en cualquier otro aspecto, se debe tener el coraje suficiente como para encarar su solución, sin importar que tan difícil sea. Si es necesario cambiar completamente parte del código, hay que hacerlo, sin importar cuanto tiempo se ha invertido previamente en el mismo. (Joskowicz. J, 2008, 16).

3.1.13. Fases de la Programación Extrema 3.1.13.1. Planificación La metodología XP usa la planificación como una comunicación constante y prolongada entre las personas implicadas en dicho proyecto. 3.1.13.1.1 Roles en XP En XP se definen roles los cuales son Programador, Cliente, Encargado de Pruebas, Tracker, Entrenador, Consultor, Jefe de Proyecto. Estos serán utilizados a lo largo del desarrollo del sistema. 3.1.13.1.2 Historia de Usuarios Las Historias de Usuarios son “historias” escritas por los usuarios en su lenguaje natural los cuales sustituyen a los Documentos de especificación funcional y nos ayudan a estimar los tiempos requeridos durante el proceso de implementación. 3.1.13.1.3 División de las Iteraciones El proyecto se divide en etapas lo cual facilita la realización del mismo, estas etapas pueden durar de una a tres semanas y son llamadas iteraciones. 3.1.13.1.4 Velocidad del proyecto Es la medida que tiene el equipo de desarrollo para realizar un número de historias de usuario en una iteración. 3.1.13.1.5 Entregas Pequeñas Después de cada iteración se realizara una entrega del avance del producto las cuales serán funcionales

3.1.13.1.6 Plan de Entregas Es el cronograma que establece las fechas de entregas de las historias de usuario las cuales se agrupan de acuerdo a la importancia que proporcione el cliente, son establecidas en las reuniones con el cliente y con este se estima el tiempo que tomará desarrollar el proyecto. 3.1.13.1.7 Traslado de Personal Al tener una rotación del equipo de desarrollo en el proyecto se puede lograr que todos los involucrados en el proyecto conozcan todas las fases del mismo y de esta manera el equipo podrá ayudarse unos a otros en cualquier momento. Hacer que los programadores conozcan el código es conveniente para poder realizar un trabajo en equipo correcto. 3.1.13.2. Diseño En la metodología XP se trata de no desperdiciar tiempo por lo que el diseño del sistema se lo realiza durante todo el desarrollo del proyecto, durante el diseño se cometan errores o modificaciones debido a cambios en algunos procesos o falta de información de los mismos. 3.1.13.2.1 Simplicidad Los diseños serán simples y claros pues serán mucho más fáciles de implementar. 3.1.13.2.2 Tarjetas CRC Las tarjetas CRC tienen como funcionalidad dejar a un lado el pensamiento procedimental e incluir el enfoque orientado a objetos. 3.1.13.2.3 Refactorización La refactorización o recodificación nos impulsa a intentar que el código sea lo más sencillo posible pues por lo común después de codificar se encontró una manera más sencilla de hacerlo y a la misma vez existen cambios en los procesos ya sea por información incompleta o mal interpretado.

3.1.13.2.4 Codificación En la metodología XP la codificación se le realiza desde el inicio del proyecto a diferencia de las otras metodologías que lo realizan después del Diseño. 3.1.13.2.5 Cliente siempre presente Uno de los requerimientos en esta metodología es que el cliente este siempre presente incluso hacerlo parte del grupo para poder despejar las dudas en el momento oportuno. 3.1.13.2.6 Utilización de Estándares en el código La metodología XP promueve el uso de estándares de manera que sea lo mayor comprensible y facilite la recodificación de código. 3.1.13.2.7 Codificar primero la prueba Codificar primero la prueba nos ayuda a identificar los requerimientos que necesita dicho código. 3.1.13.2.8 Programación en Parejas Todo el código debería ser creado en pareja, programando los dos juntos en un mismo computador, así se obtiene un diseño de mejor calidad, un código más organizado y minimiza los errores. 3.1.13.2.9 Integración Secuencial XP promueve publicar las versiones actuales o últimas versiones funcionales de código, las mismas que tendrán que estar bien probadas para que los desarrolladores puedan trabajan sobre esta versión. 3.1.13.2.10 Integraciones Frecuentes La metodología XP sugiere que se realicen las integraciones lo más frecuente posible para que no transcurra más de un día pues esto evitará que existan errores al trabajar con versiones obsoletas de alguna clase.

3.1.13.2.11 Propiedad colectiva del código En XP se fomenta la recodificación por la cual, cualquier pareja de programadores podría tomar la responsabilidad de generar nuevo código ya sea para corregirlo u optimizarlo. 3.1.13.2.12 Evitar Horas Extras de trabajo Planificar un trabajo constante pero no sobrecargado para el equipo de trabajo así se evitara el cansancio, la falta interés y la pérdida de tiempo de parte de los programadores llegando a lograr una mayor productividad para el proyecto. 3.1.13.3. Pruebas XP destaca la realización pruebas contantes y correctamente realizadas para garantizar el correcto funcionamiento y la calidad del software, procurando ayudar al equipo a realizar su correcto trabajo, evitando la pérdida de tiempo al suscitarse errores difíciles de resolver, esta metodología enfatiza que solo se debe liberar una versión si esta ha pasado el cien por ciento de las pruebas. 3.1.13.3.1 Pruebas Unitarias XP enfatiza la realización de pruebas unitarias para cada uno de los módulos, así pueden ser liberados y publicados las mismas que deben ser definidas antes de realizar el código. 3.1.13.3.2 Pruebas de Aceptación Son creadas en base a las historias de usuarios, los clientes deben especificar escenarios para comprobar si cada historia de usuario ha sido correctamente implementada, los clientes son los responsables de verificar que los resultados de las pruebas sean adecuados a lo requerido.

3.2.

Investigaciones o experiencias empíricas vinculadas con el problema de investigación

Tabla 1: Investigaciones o experiencias Empíricas Tema

Autores

Institución

Desarrollo e implementación de Silva Pérez, Galo PUCESA un sistema de facturación y Francisco control de inventario utilizando la librería ExtJS para la intranet de la librería Rincón Andino

URL repositorio.pucesa.edu.ec/jspui/bits tream/123456789/957/1/75597.pdf

Resumen La presente tesis muestra el desarrollo de un sistema para la librería rincón Andino en la ciudad de Ambato, utilizando la librería ExtJs el cual ha permitido la facturas, compras, control de inventario, control de cuentas por pagar y cuentas vencidas, clientes y proveedores, las cuales se realizaban de manera manual en la librería Rincón Andino

Tema

Autores

Institución

Desarrollo del Sistema de Jiménez Toscano, Escuela Control de Inventarios para las Jaime Darío Politécnica Nacional Instituciones Públicas del Ecuador

URL http://bibdigital.epn.edu.ec/bitstrea m/15000/7089/1/CD-5267.pdf

Resumen El presente proyecto describe el proceso de la implementación de un sistema de inventario para Entidades Públicas del Ecuador , el cual fue desarrollado con la metodología de Programación Extrema, el problema de las instituciones Públicas del Ecuador es la demora en los procesos de Inventario pues estos se realizan de manera manual.

Tema

Autores

Desarrollo de una base de datos Plata Barros Kelly de inventario para activos fijos integrada a una interfaz gráfica de usuario (GUI), implementando el lector de código de barras con bluetooth MS-9535 Voyaguer BT

Institución Pontificia Bolivariana

URL http://repository.upb.edu.co:8080/js pui/bitstream/123456789/596/1/dig ital_18222.pdf

Resumen El presente proyecto describe el desarrollo de una Base de Datos integrada a una Interfaz Gráfica de Usuario (GUI), la cual permite la consultar, generar reportes y almacenar los inventarios de la Pontificia Universidad Bolivariana mediante un dispositivo electrónico para la entrada de Datos. El mismo que permitirá la sistematización y organización de los productos con la información detalla de sus características. Fuente: Los Disertantes - 2014

METODOLOGÍA DE LA INVESTIGACIÓN

4.1.

Diseño / Tipo de investigación

4.1.1.

Diseño de Investigación El tipo de diseño escogido fue el diseño no experimental el cual se basa en la

observación, este permite observar los fenómenos tal y como se da en su ambiente natural para después ser analizados. El mismo que fue aplicado en la parte de la entrevista y la observación de campo de esta manera permitió conocer el problema del Proceso de control de inventario de activos fijos y bienes de la Unidad Educativa y el entorno de trabajo donde se realiza este proceso. 4.1.2.

Tipo de Investigación La investigación en la que se basará fundamentalmente la presente Disertación de

Grado es la Investigación Aplicada, este tipo de investigación ayudará

a recopilar

información más veraz y palpable de las características importantes y fundamentales del problema a investigar y de esta forma se alcanzarán los objetivos del proyecto llegando a una solución factible y viable para la automatización del control de inventario de activos fijos y bienes de la Unidad Educativa del Milenio “MI INUN YA”.

4.2.

Población / Universo Benavente (2007) dice que una población o universo es el conjunto formado por

elementos que hacen referencia a un conjunto de personas, animales o cosas, además de poseer características en común, La población que se tomará en cuenta para el desarrollo del proyecto son el personal docente, administrativo de la Unidad Educativa del Milenio “MI INUN YA”, esta institución cuenta con alrededor 50 personas en total, esta población se considera finita , por lo tanto se tomará el total de la población para realizar su respectivo análisis.

4.3.

Muestra Se refiere a una parte de la población o universo, de donde podemos recolectar

información partiendo del uso de algún instrumento de recolección de datos.

Para nuestro caso no se tomará una muestra ya que la población es finita y cuenta con muy pocos individuos, por tal motivo la muestra sería igual a la población.

4.4.

Instrumentos de recogida de datos Para el desarrollo del proyecto se utilizará como instrumentos de recogida de datos la

entrevista que estará dirigida al encargado del inventario y al rector de la Unidad Educativa del Mileno MI INUN YA, encuesta que será realizada al personal docente y administrativo de la institución y por último la observación que nos permitirá obtener información de primera mano. 4.4.1.

Entrevista La entrevista es un acto de comunicación oral que se establece entre dos o más

personas con el fin de obtener una información o una opinión, o bien para conocer la personalidad de alguien por medio de una serie de preguntas planteadas y organizadas. Esta ayudará para obtener información de todos los requisitos y procesos que requiere el sistema de control de inventarios de activos fijos y bienes. Esta entrevista se realizó a la señorita encargada del manejo de inventario en la Unidad Educativa la cual ayudó proporcionando la información acerca del proceso de inventario. 4.4.2.

Encuesta Es una técnica investigativa, en donde el investigador busca recolectar información,

de un grupo de individuos en particular mediante el uso de un cuestionario de preguntas previamente elaborado, en donde se intenta reflejar las necesidades, deseos o pensamientos de los encuestados en base al tópico de las preguntas formuladas. La encuesta permitió conocer el grado de aceptación que tendría el sistema que se pretende implementar en la Unidad Educativa. 4.4.3.

Observación Es un instrumento investigativo que consiste en la visualización y análisis directo de

los procesos que un sistema organizacional emplea para desarrollar sus funciones.

Es de gran utilidad aplicar esta técnica de recolección de datos durante el proceso de investigación, ya que algunos sistemas organizacionales no poseen sus respectivos manuales de procedimientos sobre las operaciones que realizan, y si los poseen, pueden no reflejar la realidad de la situación que internamente se manejan.

4.5.

Técnicas de Análisis de Datos Para realizar el proceso de la información y análisis de los datos, se utilizará la técnica

investigativa cualitativa, en los cuales los datos presentados de manera verbal a través de las entrevistas y revisión documental nos darán un enfoque claro del problema. 4.5.1.

Análisis Estadístico Es la aplicación de técnicas estadísticas para el procesamiento de información surgida

durante un proceso de investigación. Su aplicación permite tener una visión amplia, o detallada de los datos recolectados y de los patrones de comportamiento de los individuos involucrados en el proceso de investigación.

4.6.

Metodología de Desarrollo Para el Desarrollo de este proyecto se usó como guía la metodología de desarrollo

software, Programación Extrema (XP), debido a que su uso en el mundo del desarrollo es de gran aporte y excelentes resultados. A continuación se realizará una descripción de lo que es XP y de las fases que se usaron dentro del ciclo de vida del proyecto y de los valores principales que esta metodología aplica para que el producto final sea de alta calidad. 4.6.1.

Programación Extrema XP La Programación extrema también conocida con sus siglas en ingles XP (extreme

programming) es una metodología ágil, la cual promueve el desarrollo iterativo y la participación continua del cliente, lo cual ayudará a que todos los requerimientos que se obtuvieron por parte del cliente consten en el programa, permitiendo que estos se ejecuten correctamente sin lanzar ningún error al momento de usar el software.

4.6.1.1. Planificación La metodología XP usa la planificación como una comunicación constante y prolongada entre las personas implicadas en dicho proyecto los cuales en este caso fueron el rector de la Unidad Educativa, la secretaria encargada de bodega y los programadores. 4.6.1.1.1 Roles en XP En XP se definen roles los cuales son Programador, Cliente, Encargado de Pruebas, Jefe de Proyecto. Estos serán utilizados a lo largo del desarrollo del sistema. Los roles que se utilizaron y definieron en el desarrollo del Sistema de Inventarios fue el de Jefe de proyectos, Programador y Encargado de Pruebas tomados por Mauricio Tamayo y Jadira Barriga y en el rol de Cliente a el Rector de la Unidad Educativa del Milenio “MI INUN YA”. 4.6.1.1.2 Historia de Usuarios Las Historias de Usuarios son historias escritas por los usuarios en su lenguaje natural los cuales sustituyen al documento de especificación funcional y ayudará a estimar los tiempos requeridos durante el proceso de implementación. Debido al escaso tiempo y poco conocimiento para realizar las historias de usuario requeridas por parte de la señorita encargada del proceso de inventario, se procedió a realizarlas con su respectiva colaboración y dirección en la redacción de cada una, con la mayor simplicidad posible las cuales fueron en total 24. 4.6.1.1.3 División de las Iteraciones El proyecto se divide en etapas lo cual facilita la realización del mismo, estas etapas pueden durar de una a tres semanas y son llamadas iteraciones. El proyecto se lo tuvo que dividir en 3 iteraciones, es decir se realizaron 3 entregas del mismo, donde se fueron corrigiendo los errores presentados en cada iteración esto permitió mejorar la calidad del software haciendo que se ajustara en mayor medida a las necesidades principales de la Unidad Educativa.

4.6.1.1.4 Velocidad del proyecto Es la medida que tiene el equipo de desarrollo para realizar un número de historias de usuario en una iteración. Para las 24 historias de usuario se utilizaron 10 semanas. 4.6.1.1.5 Entregas Pequeñas A continuación de cada iteración se realizará una entrega del avance del producto las cuales serán funcionales Como el proyecto se dividió en 3 iteraciones se hicieron 3 entregas las cuales se las hizo en la fecha respectiva según la disponibilidad del cliente. 4.6.1.1.6 Plan de Entregas Es el cronograma que establece las fechas de entregas de las historias de usuario las cuales se agrupan de acuerdo a la importancia que proporcione el cliente, son establecidas en las reuniones con el cliente y con este se estima el tiempo que tomará desarrollar el proyecto. Las historias de usuarios fueron agrupadas según la importancia que el cliente le dio a cada una de ellas con el asesoramiento de los desarrolladores, sin embargo los tiempos establecidos tuvieron que ser modificados debido a factores externos al proyecto, los cuales fueron, el cambio de rector de la Unidad Educativa del Milenio “MI INUN YA” y cambios en los procesos en el control de inventario. 4.6.1.1.7 Traslado de Personal Al tener una rotación del equipo de desarrollo en el proyecto se puede lograr que todos los involucrados en el proyecto conozcan todas las fases del mismo y de esta manera el equipo podrá ayudarse unos a otros en cualquier momento. Hacer que los programadores conozcan todo el código es conveniente para poder realizar un trabajo en equipo correcto. Los 2 integrantes del proyecto trabajaron en conjunto rotando los roles de jefes de proyecto, programador y encargado de pruebas. Se dio a conocer las tareas que cada uno realizó para ponerse al tanto y poder colaborar al progreso del proyecto.

4.6.1.2. Diseño En la metodología XP se trata de no desperdiciar tiempo por lo que el diseño del sistema se lo realiza durante todo el desarrollo del proyecto, durante el diseño se cometen errores o modificaciones debido a cambios en procesos o falta de información de los mismos. En esta fase se procedió a realizar el diseño de la base de datos así como de las interfaces gráficas, tratando de realizar estas últimas de la manera más sencilla y amigable posible para que el usuario final pueda utilizar sin mayor problema. 4.6.1.2.1 Simplicidad Los diseños serán simples y claros pues serán mucho más fáciles de implementar de esta manera se garantiza el uso por parte de los usuarios. En el proyecto se utilizó interfaces intuitivas y amigables para el usuario, lo cual hace fácil de manipular y mantener el sistema por parte de los usuarios finales, haciendo que el sistema pueda ser de calidad. 4.6.1.2.2 Tarjetas CRC Las tarjetas CRC tienen como funcionalidad dejar a un lado el pensamiento procedimental e incluir el enfoque orientado a objetos. Las tarjetas CRC sirvieron como base y de gran ayuda para poder hacer el modelo entidad relación pues se conocieron las clases y relaciones que se iban a utilizar en el sistema. Las mismas incluyeron en la creación de base de datos. 4.6.1.2.3 Refactorización La refactorización o recodificación se impulsa a intentar que el código sea lo más sencillo posible pues por lo común después de codificar se encuentra una manera más sencilla de hacerlo y a la misma vez existen cambios en los procesos ya sea por información incompleta o mal interpretada. En la fase de diseño del sistema se tuvo que hacer algunas refactorizaciones debido a cambios externos e internos en el proceso de control de inventario, por ejemplo se tuvo que incluir algunos reporte los cuales no estaban como requerimiento al principio del proyecto.

4.6.1.3. Codificación En la metodología XP la codificación se le realiza desde el inicio del proyecto a diferencia de las otras metodologías que lo realizan después del diseño. 4.6.1.3.1 Cliente siempre presente Uno de los requerimientos en esta metodología es que el cliente este siempre presente incluso hacerlo parte del grupo para poder despejar las dudas en el momento oportuno. Este requerimiento en el proyecto no fue totalmente cumplido porque el cliente en este caso el Rector de la Unidad Educativa y la secretaria encargada del proceso de inventario son personas con escasa disponibilidad de tiempo, por lo que se tomó como opción tratar de despejar las dudas mediante llamadas telefónicas y visitas a la institución. 4.6.1.3.2 Codificar primero la prueba Codificar primero la prueba nos ayuda a identificar los requerimientos que necesita dicho código. En la fase de codificación por el corto tiempo y basados en la experiencia como programadores se codificó primero la prueba para poder tener una mayor visión de lo que el cliente realmente necesitaba. 4.6.1.3.3 Programación en Parejas Todo el código debería ser creado en pareja, programando los dos juntos en un mismo computador, así se obtiene un diseño de calidad, más organizado y minimiza los errores. Este principio fue aplicado en el proyecto ya que contaba con dos programadores, pero no se pudo trabajar en un solo ordenador como la metodología sugería pues ambos programadores disponían de poco tiempo para poder reunirse, por lo tanto cada uno realizó diferentes módulos pero siempre tratando de tener el conocimiento entre ambos de toda la aplicación para que posteriormente sea más fácil corregir errores, de esta manera se logró un mayor control sobre la codificación y desarrollo del sistema.

4.6.1.3.4 Integración Secuencial XP promueve publicar las versiones actuales o últimas versiones funcionales de código, las mismas que tendrán que estar bien probadas para que los desarrolladores puedan trabajar sobre esta versión. En nuestra aplicación lo que se hizo es reunir lo que cada integrante iba haciendo para hacer las pruebas necesarias, así ambos corregían y solucionaban los errores que se presentaban, quienes al hacer las observaciones y pruebas guardaban una copia para poder trabajar sobre ella, lo que permitía regresar a la versión funcional si no se podía realizar la integración deseada. 4.6.1.3.5 Integraciones Frecuentes La metodología XP sugiere que se realicen las integraciones

lo más frecuentes

posibles que no transcurra más de un día pues esto evitará que existan errores al trabajar con versiones obsoletas de alguna clase. Se realizaron por lo general integraciones diarias de lunes a sábados mientras que en las ocasiones en las que no se podían realizar por situaciones externas al proyecto, se realizaban integraciones cada 2 días, siempre tratando de mantener la aplicación funcionando y tratando de solucionar en equipo los errores que se presentaron. 4.6.1.3.6 Propiedad colectiva del código En XP se fomenta la recodificación por lo cual, cualquier pareja de programadores podría tomar la responsabilidad de generar nuevo código ya sea para corregirlo u optimizarlo. En nuestro proyecto no se utilizó este principio ya que como se separó los módulos a desarrollarse y se prefirió no tocar el código del otro desarrollador para no causar errores, si el código necesitaba alguna corrección u optimización se le comunicaba al desarrollador del módulo para que lo corrigiera. 4.6.1.3.7 Evitar Horas Extras de trabajo Planificar un trabajo constante pero no sobrecargado para el equipo de trabajo así se evitará el cansancio, la falta interés y la pérdida de tiempo de parte de los programadores llegando a lograr una mayor productividad para el proyecto.

La planificación en el proyecto se trató de realizarla lo más liviana posible pero siempre tratando ir a la par con los tiempos estimados para la entrega del proyecto tomando en cuenta los factores internos y externos que podrían afectar el desarrollo, en la cual cada integrante tomaba la responsabilidad de hacer lo solicitado. 4.6.1.4. Pruebas XP destaca la realización pruebas contantes y correctamente realizadas para garantizar el correcto funcionamiento y la calidad del software, procurando ayudar al equipo a realizar su correcto trabajo, evitando la pérdida de tiempo al suscitarse errores difíciles de resolver, esta metodología enfatiza, que se podrá liberar una nueva versión si esta ha pasado el cien por ciento de las pruebas. 4.6.1.4.1 Pruebas Unitarias XP enfatiza la realización de pruebas unitarias para cada uno de los módulos, así pueden ser liberados y publicados, las mismas que deben ser definidas antes de realizar el código. Se realizaron las pruebas unitarias de Orden de Ingreso en las que se verificaba que tanto el Proveedor como el Producto que se va adquirir existan, caso contrario la prueba fallaba ya que dichas entidades son requisitos fundamentales para que se efectúe la orden de ingreso. También se realizaron las pruebas unitarias de Orden de Pedido en las se verificaba que tanto el Cliente como el Producto existan, caso contrario la prueba fallaba ya que dichas entidades son requisitos fundamentales para que se efectúe la orden de pedido. 4.6.1.4.2 Pruebas de Aceptación Son creadas en base a las historias de usuarios, los clientes deben especificar escenarios para comprobar si cada historia de usuario ha sido correctamente implementada, los clientes son los responsables de verificar que los resultados de las pruebas sean adecuados a lo requerido. Se realizaron tres pruebas de aceptación basándose en cada iteración realizada las mismas que fueron de responsabilidad del cliente, tratando de ajustarnos a la disponibilidad

de tiempo del cliente, en una de ellas se mostró al cliente la manera de realizar órdenes de ingreso, donde al realizarla no se permitía guardar la orden si no existía un proveedor y producto asignado, validando así dicho proceso. 4.6.1.4.3 Entrega del Sistema Una vez que la fase de Aceptación fue concluida satisfactoriamente se procedió a la entrega formal del Sistema del control de inventarios de bienes y activos fijos, a la Unidad Educativa del Milenio “MI INUN YA”, la cual conto con la implementación del sistema, la entrega de un CD que contiene los manual de usuario, manual técnico, script de la base de datos, diccionario de datos y el código fuente, los cuales le permitirán a la institución darle mantenimiento o en un futuro caso actualizar la aplicación a una versión con funciones extras.

5. 5.1.

RESULTADOS

Análisis y Discusión de los resultados Presentación de los resultados alcanzados en el proyecto de disertación y discusión.

5.1.1.

Encuesta aplicada al personal docente y administrativo de la Unidad Educativa del Milenio “MI INUN YA”.

5.1.1.1.1 Introducción. Se realizó una encuesta al personal administrativo y docente (Anexo 3), para poder conocer el grado de aceptación y factibilidad al implementar el sistema para el control de inventario de activos fijos y bienes. 5.1.1.1.2 Metodología Para la realización de la encuesta se tomaron en cuenta los siguientes parámetros y datos. Tabla 2: Información previa de la encuesta aplicada Datos de la encuesta

Descripción

Entidad

Unidad Educativa del Milenio “MI INUN YA”

Actividad

Servicio de educación pública

Ubicación

Ecuador, Santo Domingo de los Tsáchilas

Área

Administrativo, Docente

Tipo de preguntas

10 Preguntas de selección múltiple

Tipo de encuesta

Impreso

Trabajo de campo

23, 24 y 25 de julio 2014

Población

Personal administrativo y docente (50 personas) La población es finita por lo que se procedió a

Muestra encuestar a toda la población. Realizado por Fuente: Los Disertantes – 2014

Mauricio Tamayo y Jadira Barriga

5.1.1.1.3 Tabulación y análisis de la información Se presentarán los datos tabulados de las encuestas realizadas. Primera Pregunta: ¿Dentro de las funciones que desempeña, hace uso del inventario de activos fijos y bienes de la Unidad Educativa? Tabla 3: Uso del inventario de activos fijos y bienes. Selección

N° de Personas

Porcentaje (%)

97%

Total

100.0 %

Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Uso del inventario de activos fijos y bienes de la Unidad Educativa

SI NO

97%

Figura 1: Uso del inventario de activos fijos y bienes. Fuente: Los Disertantes Unidad Educativa del Milenio “MI INUN YA” – 2014.

Análisis 1: El 97% de las personas encuestada afirma que hace uso del inventario de activos fijos y bienes de la Unidad Educativa del Milenio “MI INUN YA”, lo cual indica que el número de usuarios potenciales a utilizar una aplicación informática para el control de inventario es la mayor parte. Esta información debe ser considerada al momento de realizar el

desarrollo y la implementación de la aplicación, ya que se debe tomar en cuenta estos parámetros de rendimiento y uso de recursos. Segunda Pregunta: ¿Con que frecuencia usted hace uso del inventario de activos fijos y bienes de la institución? Tabla 4: Frecuencia en el uso del inventario de activos fijos y bienes. Selección

N° de Personas

Porcentaje (%)

Diariamente

80%

Semanalmente

12%

Mensualmente

Anualmente

Nunca

Total

100.0 %

Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Uso del inventario de activos fijos y bienes de la institución 0% 0% 8% 12%

Diariamente Semanalmente Mensualmente Anualmente 80%

Figura 2: Frecuencia en el uso del inventario de activos fijos y bienes. Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Nunca

Análisis 2: La mayoría del personal docente, administrativo y de servicio que labora en la Institución afirman que hacen uso del inventario de activos fijos y bienes, esto refuerza el resultado obtenido en la pregunta realizada anteriormente, y ayudará en un futuro a la implementación del sistema en la designación de recursos para el uso del mismo. Tercera Pregunta: ¿Cómo considera que es el proceso de control y actualización del inventario de activos fijos y bienes? Tabla 5: Proceso de control y actualización del inventario de activos fijos y bienes. Selección

N° de Personas

Porcentaje (%)

Bueno

Agradable

Tedioso

70%

Complicado

30%

Fácil

Total

100.0 %

Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Proceso de control y actualización del inventario de activos fijos y bienes 0% Bueno

30%

Agradable Tedioso 70%

Figura 3: Proceso de control y actualización del inventario de activos fijos y bienes. Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Complicado Facil

Análisis 3: La mayoría del personal docente, administrativo y de servicio que labora en la Unidad Educativa del Milenio “MI INUN YA” afirma que la manera en la que se controla y se maneja el inventario de activos fijos y bienes de la Institución es tediosa, compleja y se requiere de bastante tiempo para realizarlo, lo cual demuestra que el desarrollo y la implementación de una aplicación informática debe brindar todas las facilidades para que dicho proceso se lleve a cabo de una manera sencilla, óptima y amigable con el usuario. Cuarta Pregunta: ¿Cree usted que el tiempo empleado para realizar el control y/o actualización de los activos fijos y bienes es? Tabla 6: Tiempo empleado en el control del inventario de activos fijos y bienes. Selección

N° de Personas

Porcentaje (%)

Optimo

Moderado

20%

Regular

32%

Largo

44%

Total

100.0 %

Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Tiempo empleado para realizar el control y/o actualización de los activos fijos y bienes 4% 30%

20%

Optimo Moderado Regular Largo

32%

Figura 4: Proceso de control y actualización del inventario de activos fijos y bienes. Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Análisis 4: La mayoría del personal docente, administrativo y de servicio que labora en la Unidad Educativa del Milenio “MI INUN YA” afirma que el tiempo empleado en el control de inventario de activos fijos y bienes de la Institución es regular y largo, lo que indica que el proceso que actualmente se lleva a cabo la persona encargada del inventario no es muy eficaz. Quinta Pregunta: ¿Considera que se deba cambiar el proceso actual de control de inventario de activos fijos y bienes de la institución? Tabla 7: Cambio del proceso actual de control de inventario de activos fijos y bienes. Selección

N° de Personas

Porcentaje (%)

Muy Necesario

60%

Necesario

40%

No Necesario

Total

100.0 %

Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Proceso actual de control de inventario de activos fijos y bienes de la institución 0%

40%

Muy Necesario Necesario 60%

No Necesario

Figura 5: Cambio del proceso actual de control de inventario de activos fijos y bienes. Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Análisis 5: El 60% del personal docente, administrativo y de servicio que labora en la Unidad Educativa Milenio “MI INUN YA”, afirman que es necesario realizar un cambio en el proceso de manejo y control de inventario de activos fijos y bienes que posee la Institución, y que en la actualidad se realiza manualmente y se pretende cambiar por un método automatizado, lo cual soporta todo el contenido que se tiene de este proyecto, ya que esto permitiría optimizar en tiempo y recursos los procesos del inventario. Sexta Pregunta: ¿En qué medida cree usted que una aplicación informática optimizaría los procesos del control de inventario de activos fijos y bienes? Tabla 8: Optimización de procesos en el control de inventario de activos fijos y bienes. Selección

N° de Personas

Porcentaje (%)

Mucha

70%

Poca

30%

Ninguna

Total

100.0 %

Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Procesos del control de inventario de activos fijos y bienes,mediante una aplicación informatica 0%

30% Mucha Poca Ninguna 70%

Figura 6: Optimización de procesos en el control de inventario de activos fijos y bienes. Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Análisis 6: La mayoría del personal docente, administrativo y de servicio que labora en la Unidad Educativa del Milenio “MI INUN YA” creen que una aplicación informática permitiría optimizar tiempo y recursos los procesos en el manejo y control de inventario de activos fijos y bienes que posee la Institución, por lo que es necesario hacer hincapié en cubrir esa expectativa que se tiene del sistema informático, ya que un objetivo implícito en este proyecto es lograr la satisfacción de todos los usuarios. Séptima Pregunta: ¿Cuál cree usted que sería la reacción del personal que actualmente lleva el control de inventario de activos fijos y bienes tras la implementación de un sistema informático para llevar a cabo esta tarea? Tabla 9: Reacción por la implementación de un sistema informático para el control de inventario de activos fijos y bienes. Selección

N° de Personas

Porcentaje (%)

Agrado

60%

Rechazo

30%

Indiferencia

10%

Total

100.0 %

Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Reacción del personal que actualmente lleva el control de inventario de activos fijos y bienes tras la implementación de un sistema informático 10% Agrado Rechazo

30% 60%

Indiferencia

Figura 7: Reacción por la implementación de un sistema informático para el control de inventario. Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Análisis 7: En base a la encuesta realizada se puede concluir que las opiniones entre el personal docente, administrativo y de servicio que labora en la Unidad Educativa del Milenio “MI INUN YA” estarían un poco divididas en cuanto a realizar o no la implementación de un sistema informático para la optimización en el control de inventario de activos fijos y bienes que posee la Institución, más aun, existe una mayoría que respalda la implantación del mismo. Octava Pregunta: Si se implementara una aplicación de software para el control del inventario de activos fijos y bienes, ¿Cómo cree usted que sería el proceso de transición entre el sistema actual y el nuevo? Tabla 10: Proceso de transición de control manual a control automático de inventario de activos fijos y bienes. Selección

N° de Personas

Porcentaje (%)

Optimo

40%

Moderado

30%

Regular

20%

Largo

10%

Total

100.0 %

Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Proceso de transición entre el sistema manual y el sistema automático

10% 40%

20%

Optimo Moderado Regular Largo

30%

Figura 8: Proceso de transición de control manual a automático de inventario de activos fijos y bienes. Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Análisis 8: La mayoría del personal docente, administrativo y de servicio que labora en la Unidad Educativa del Milenio “MI INUN YA” cree que el periodo de transición entre el proceso tradicional de manejo y control de inventario de activos fijos y el sistema informático que se desea aplicar sería óptimo, ya que esta transición beneficiaría a todo el personal y a la propia Institución, esto debido a la que se pretende perfeccionar el proceso actual, por tal razón es necesario considerar esto para cumplir las expectativas del personal durante la implementación. Novena Pregunta: ¿Qué tan necesario cree usted que el control de inventario de activos fijos y bienes sea manejado con la ayuda de una aplicación informática? Tabla 11: Procesos del inventario de activos fijos y bienes deben ser auditables. Selección

N° de Personas

Porcentaje (%)

Muy Necesario

60%

Necesario

30%

No Necesario

10%

Total

100.0 %

Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Necesidad del control de inventario de activos fijos y bienes se maneje con la ayuda de una aplicación informática

10%

Muy Necesario Necesario

30% 60%

Figura 9: Procesos del inventario de activos fijos y bienes deben ser auditables. Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

No Necesario

Análisis 9: En base a la encuesta realizada se puede concluir que el personal docente, administrativo y de servicio que labora en la Unidad Educativa del Milenio “MI INUN YA” encuestado afirman que es necesario el control de inventario de activos fijos y bienes que posee la Institución sea manejado por una aplicación informática, por lo que se deben incorporar todas las características necesarias en el sistema informático para suplir esta fundamental necesidad y que en un futuro sirva para probar la coherencia entre los valores iniciales y finales del inventario. Décima Pregunta: ¿Está de acuerdo con que se implemente una aplicación informática para el control del inventario de los activos fijos y bienes que posee la institución? Tabla 12: Implementación de una aplicación para el control del inventario de activos fijos y bienes. Selección Si

N° de Personas 44

Porcentaje (%) 88%

12%

Total

100.0 %

Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

Implementación de una aplicación informática para el control del inventario de los activos fijos y bienes que posee la institución

12%

SI NO

88%

Figura 10: Implementación de una aplicación para el control del inventario de activos fijos y bienes. Fuente: Los Disertantes Unidad Educativa del Milenio “MI INUN YA” – 2014.

Análisis 10: En base a la encuesta realizada se puede concluir que el personal docente, administrativo y de servicio que labora en la Unidad Educativa del Milenio “MI INUN YA” encuestado afirman que están de acuerdo con que se realice el desarrollo y la implementación de un sistema informático para el manejo y el control de los activos fijos y bienes que posee la Institución, ya que una aplicación como esta brindaría una gran beneficio por la optimización de tiempo y recursos que aportaría, para lo cual es necesario considerar todos los aspectos recopilados en esta encuesta y del que se plantea realizar proyecto como tal. 5.1.2.

Entrevista La entrevista se la realizó a la señorita encarda del proceso de Inventario en la Unidad

Educativa del Milenio “MI INUN YA” en la cual se realizaron las siguientes preguntas: ¿Quién o quienes hacen uso del Inventario? ¿Quién o quienes están encargados del proceso de inventario? ¿Cómo es el proceso para la adquisición y préstamo de inventario? ¿Con que tipo de inventarios cuenta la institución? Análisis: Se concluyó con los resultados obtenidos en la entrevista que en el proceso de inventario intervienen todo el personal de la Institución, Docentes, Administrativo y de Servicios. En lo que respecta al proceso de adquisición se pudo conocer que se deben hacer de dos a tres cotizaciones de lo que se necesite comprar, las cuales son enviadas al distrito correspondiente, quienes son los encargados de aprobar una de las cotizaciones, la cotización aprobada será registrada en la orden de ingreso y por consiguiente al haber realizado la compra se actualiza el inventario, otra manera para la actualización del inventario es cuando algún bien sea donado a la institución. En el proceso de préstamo se pudo conocer que se registra la orden de pedido con los datos de la persona que solicite algún bien, una vez realizada la entrega se realiza la actualización de inventario, otra manera de que el inventario disminuya será cuando se da de baja algún bien o cuando sea donado.

Concluyendo que los procesos de orden de ingreso, orden de pedido y actualización de inventario, se realizan con ayuda de la herramienta Excel no hace posible tener un control total del inventario, ya que la herramienta antes mencionada no es utilizada de la manera correcta lo cual crea inconsistencias en el inventario. 5.1.3.

Observación Por medio de la Observación se pudo conocer la manera en que se lleva a cabo el

registro de los activos fijos y bienes, tanto las entradas como las salidas de los mismos. Se pudo conocer el manejo de la herramienta Excel por parte de la persona encargada del proceso de inventario y constatar el tiempo que se demoraba la persona encargada del proceso de inventario al realizar el registro de los bienes. De la misma manera observamos la tecnología con la que cuenta la Unidad Educativa 5.1.4.

Metodología de desarrollo Programación Extrema en la elaboración del Sistemas de control de Inventario de activos fijos y bienes.

5.1.5.

Proceso de Desarrollo de la Metodología XP Para el Sistema de Control de Inventarios de Activos fijos y Bienes de la Unidad

Educativa del Milenio “MI INUN YA”, la cual se desarrolló usando la metodología de Programación Extrema (XP), se explicará su desarrollo a continuación: 5.1.6.

Planificación En esta fase que es la de inicio se definieron los roles de los integrantes del proyecto

los cuales fueron jefe de proyecto, programador y encargado de pruebas, se desarrolló las historias de usuarios con la aprobación del cliente, en la misma se definieron tres iteraciones, se planificaron las fechas de entrega y las tareas para cada integrante. Se definieron las herramientas de desarrollo a utilizar las cuales fueron: La herramienta de entorno de desarrollo integrado Netbeans en su versión 7.4 la cual se encontró propicia por ser gratuita y enfocada al lenguaje Java en la cual se desarrollaría el software.

Como Sistema gestor de Base de Datos a PostgreSQL versión 9.3 por que como se la conoce es una base de datos relacional orientada a objetos bajo licencia libre. Para el diseño del modelo de la base de datos se utilizó la herramienta gratuita PgModeler versión 1.7 ya que es propia de PostgreSQL. 5.1.6.1.1 Especificación de Requerimientos Basándonos en las continuas visitas donde se trató de cubrir el mayor conocimiento sobre los requerimientos de la unidad educativa por parte del Rector y la secretaria encargada del proceso de inventario, se realizó el SRS el cual contiene los siguientes requerimientos: Tabla 13: Especificación de Requerimientos de Software SICIAF Nº

Requerimiento Funcional

Ingreso al Sistema

Registro de Usuarios

Eliminación de Usuarios

Consulta de Usuarios

Registro de Activos Fijos y Bienes

Modificación Activos Fijos y Bienes

Baja de Activos Fijos y Bienes

Consulta y Reporte de Activos Fijos y bienes

Registro de Orden de Ingreso de Activos Fijos y Bines

Modificación de Orden de Ingreso de Activos Fijos y Bines

Eliminación de Orden de Ingreso de Activos Fijos y Bines

Consulta y Reportes de Ordenes de Ingreso de Activos Fijos y Bienes

Registro de Orden de Pedido de Activos Fijos y Bines

Modificación de Orden de Pedido de Activos Fijos y Bines

Eliminación de Orden de Pedido de Activos Fijos y Bines

Consulta y Reporte de Ordenes de Pedido de Activos Fijos y Bines

Registro de Clientes

Modificación de Clientes

59 19

Eliminación de Clientes

Consulta y Reporte de Clientes

Registro de Proveedores

Modificación de Proveedores

Eliminación de Proveedores

Consulta y Reporte de Proveedores

Fuente: Los Disertantes - 2014

Para su mayor análisis de la realización del SRS revise (Anexo 4). 5.1.6.1.2 Historias de Usuarios SICIAF Las Historias de usuarios las mismas que fueron dirigidas en su realización por parte del cliente, para conocer los pasos o actividades para llevar a cabo los procesos y conociendo los actores o participantes del mismo, con las historias de usuarios nos ayudaran a estimar los tiempos de implementación. Tabla 14: Historias de Usuarios SICIAF Nº

Historia de Usuario

Iteración

Tiempo de desarrollo

Ingreso al Sistema

6 horas

Registro de Usuarios

6 horas

Eliminación de Usuarios

6 horas

Consulta de Usuarios

4 horas

Registro de Activos Fijos y Bienes

15 horas

Modificación Activos Fijos y Bienes

12 horas

Baja de Activos Fijos y Bienes

16 horas

Consulta y Reporte de Activos Fijos y bienes

8 horas

Registro de Orden de Ingreso de Activos Fijos y Bines

15 horas

Modificación de Orden de Ingreso de Activos Fijos y Bines

12 horas

Eliminación de Orden de Ingreso de Activos Fijos y Bines

16 horas

Consulta y Reportes de Ordenes de Ingreso de Activos Fijos y

60 Bienes 13

Registro de Orden de Pedido de Activos Fijos y Bines

15 horas

Modificación de Orden de Pedido de Activos Fijos y Bines

12 horas

Eliminación de Orden de Pedido de Activos Fijos y Bines

12 horas

Consulta y Reporte de Ordenes de Pedido de Activos y Bines

4 horas

Registro de Clientes

4 horas

Modificación de Clientes

2 horas

Eliminación de Clientes

1 hora

Consulta y Reporte de Clientes

2 horas

Registro de Proveedores

4 horas

Modificación de Proveedores

2 horas

Eliminación de Proveedores

1 hora

Consulta y Reporte de Proveedores

2 horas

Fuente: Los Disertantes -2014

Para su mayor análisis y verificación revisar (Anexo 5). 5.1.6.1.3 Velocidad del Proyecto SICIAF El tiempo empleado en el desarrollo del proyecto está basado en tareas las cuales se realizaron en cada iteración. Tabla 15: Iteraciones Iteración 1

Iteración 2

Iteración 3

Horas

Horas Semanales

Semanas

Historias de Usuario

Fuente: Los Disertantes -2014

5.1.7.

Diseño El diseño en XP se lo realiza a lo largo de todo el proyecto ya que continuamente se

está evaluando y cualquier fallo o desperfecto tocará realizar cambios.

Figura 11: Login de Usuario. Fuente: Los Disertantes.

Figura 12: Interfaz Principal. Fuente: Los Disertantes.

Figura 13: Interfaz del M贸dulo de Productos. Fuente: Los Disertantes.

Figura 14: Interfaz de Orden de Ingreso. Fuente: Los Disertantes.

Figura 15: Interfaz de Orden de Pedido. Fuente: Los Disertantes.

Figura 16: Interfaz del M贸dulo de Proveedores. Fuente: Los Disertantes.

Figura 17: Interfaz del Módulo de Personal. Fuente: Los Disertantes.

5.1.7.1. Modelado de la base de datos SICIAF La base de datos fue modelada con PgModeler versión 1.7, herramienta de código libre la cual es fue diseñada para el modelamiento de base de datos con características específicas que solo PostgreSQL implementa.

Figura 18: Modelo Entidad – Relación de la base de datos. Fuente: Los Disertantes y Unidad Educativa del Milenio “MI INUN YA” – 2014.

5.1.8.

Codificación La codificación se realizó en el lenguaje Java utilizando la herramienta gratuita de

desarrollo Netbeans versión 7.4, incluyendo la biblioteca grafica Swing, con la cual se diseñó las interfaces.

Figura 19: Codificación de la conexión a la base de datos en la herramienta Netbeans. Fuente: Los Disertantes.

5.1.9.

Pruebas Las pruebas realizadas a cada módulo fueron exitosas al constatar que tenían el

funcionamiento que se esperaba el mismo que fue verificado por la señorita encargada de inventarios en la Unidad Educativa del Milenio “MI INUN YA”, dando así por concluidas todas las pruebas realizadas al Sistema de Inventarios SICIAF. 5.1.10. Entrega del Sistema Para finalizar, se procedió a la respectiva entrega del sistema, primero realizando la implantación del mismo en la Unidad Educativa del Milenio “MI INUN YA”, en una de las computadoras de escritorio correspondiente a la señorita Shirley Ortega Andrade quien ocupa el puesto de Guarda Almacén también se le entrego un CD donde se encuentra un manual de usuario e instalación y los fuentes del sistema para su correspondiente uso.

5.1.11. Análisis y discusión de los resultados Análisis El análisis de los recursos y requerimientos funcionales se lo realizó mediante la entrevista obtenida con la persona encargada del inventario y la observación directa del proceso, de esta manera se logró obtener todos los requerimientos que constan en el documento SRS. El modelado de la base de datos se lo realizó utilizando la herramienta pgModelerer, lo cual permitió visualizar de forma clara y precisa las entidades y relaciones que formaron parte de los diferentes módulos del sistema. La codificación de los distintos módulos del sistema de inventarios se lo realizó en el lenguaje de programación Java y se utilizó el entorno de desarrollo Netbeans, incluyendo la biblioteca grafica de Java, Swing. Las pruebas fueron realizadas una vez que se concluyó el desarrollo del sistema, permitiendo encontrar fallas las cuales fueron corregidas para su implementación. El sistema de control de inventario de activos fijos y bienes fue entregado al rector de la institución, donde se dio a conocer el funcionamiento del mismo, cumpliendo con los requerimientos planteados en los objetivos y las necesidades correspondientes al control de inventario. Discusión La entrevista que se tuvo con la persona encargada así como la observación directa del proceso de inventario, permitieron conocer de manera más profunda las falencias y virtudes de dicho proceso, lo cual ayudó a tener una idea más clara y precisa de los requerimientos funcionales del sistema sin embargo dichos requerimientos fueron evolucionando en el transcurso del proyecto. El utilizar la herramienta pgModelerer y no otras herramientas similares, hizo que la transición entre el modelo lógico y el modelo físico sea exitosa ya que al ser propia de PostgreSQL no dio ningún problema al momento de generar el script de la base de datos.

La razón de haber escogido Java para la codificación de los diferentes módulos fue porque es un lenguaje orientado a objetos lo que ayuda en la reusabilidad, mantenibilidad, modificabilidad y fiabilidad del sistema, tomando en cuenta que los desarrolladores tienen un conocimiento más amplio, en este lenguaje que en otros, además de ello Java cuenta con una biblioteca grafica la cual ayudó que el desarrollo de las interfaces se lo realizara de una manera más ágil, permitiendo concentrase en el desarrollo de los procesos internos. Por otro lado se utilizó el entorno de desarrollo Netbeans el cual es un complemento ideal para Java debido a su compatibilidad al momento de desarrollar. Las pruebas realizadas en el transcurso del desarrollo del sistema fueron una ventaja porque permitieron corregir los errores que se fueron generando, lo cual hizo que el sistema sea más robusto y confiable al momento de implementarlo. El proceso de la entrega del sistema tuvo algunas complicaciones siendo la más relevante la del Rector de la Institución quien por motivo de enfermedad no se encontraba laborando el día de la entrega, lo cual fue una pérdida de tiempo para los disertantes al tener que realizar continuos viajes hasta la institución, sin embargo el sistema fue aprobado con satisfacción por parte de las autoridades y de la persona encargada del control de inventario.

5.2.

Conclusiones De acuerdo a los requerimientos obtenidos al usar la metodología XP, se concluye

que: •

Con la información recabada se hizo posible determinar los requerimientos funcionales y no funcionales de la lógica de negocios del sistema, los cuales se encuentran reflejados en el documento SRS, adicionalmente se pudieron establecer los recursos con los que cuenta la institución como son: una red LAN que proporciona intranet, la cual fue aprovechada para permitir el acceso al servidor en donde se aloja la base de datos, además un ordenador en el cual se instaló el sistema.

•

El modelado de la base de datos y los módulos correspondientes al sistema fueron evolucionando en el transcurso del desarrollo del proyecto debido a la utilización de la metodología aplicada.

•

Al utilizar la metodología ágil de desarrollo XP ayudó a mejorar con cada iteración el modelado de la base de datos y de los módulos logrando así obtener un sistema robusto y confiable.

•

En todo el proceso de desarrollo del sistema se utilizó herramientas de software libre las cuales fueron: Java para la codificación, PostgreSQL como gestor de base de datos y PgModelerer como diseñador la base de datos. Además la utilización de las mismas facilito el desarrollo tanto en el aspecto económico como técnico.

•

La ejecución de pruebas en el desarrollo del sistema permitió verificar y corregir el funcionamiento del sistema y de esta manera poder mejorar la calidad del mismo.

•

La instalación del sistema en el área de trabajo antes de su entrega final permitió corregir los últimos problemas presentados como conexiones a la base de datos y pequeñas funcionalidades que no se tenía previsto como ciertos tipos de reportes.

5.3.

Recomendaciones  Documentar los procesos del control de inventario de activos fijos y bienes porque de esta manera resultaría mucho más fácil la obtención de información.  Se recomienda a la persona encargada del Sistema de Inventario ingresar la información correcta de los datos de acuerdo con el manual de usuario del sistema.  Para mantener segura la información de activos fijos y bienes se debe instalar el sistema SICIAF solo en máquinas autorizadas por las autoridades y que cumplan con los requisitos mínimos para su instalación.  Verificar el correcto funcionamiento de la red para que el acceso a la información este siempre disponible.  Utilizar el sistema de manera responsable basándose en las indicaciones establecidas en el manual de usuario, para que pueda funcionar sin problemas.

Lista de Referencias Bibliográficas •

Curiel, R. L. (2014). Las TIC en el aula de Tecnología. Guía para su aplicación a la metodología de proyectos. Lulu.com.

•

Marta Jiménez Castells, B. O. (2013). Fundamentos de ordenadores. Universitat Politècnica de Catalunya.

•

Pressman, R. S. (2010). Software Engineering A Practitioner's Approach. New York: McGraw-Hill.

•

Rodríguez, R., Encarna, S., & Prieto, Á. (2011). Programación Orientada a Objetos. México D.F.

•

Rodríguez, R., Encarna, S., & Prieto, Á. (2011). Programación Orientada a Objetos. México D.F.

•

Sommerville.

(2009).

Software

Engineering.

Madrid:

PEARSON

EDUCACIÓN. Lincográficas •

Jiménez, Jaime (2012). Desarrollo del Sistema de Control de Inventarios para las

Instituciones

Públicas

del

Ecuador.

Recuperado

de http://bibdigital.epn.edu.ec/bitstream/15000/7089/1/CD-5267.pdf •

Mamani Quisbert Celia, C. B. (2012). Sistema Académico escolar Avemaría.

Recuperado

de https://sistemacademicoescolaravemaria.wordpress.com/about/pagina-3/ •

Pérez, Silvia (2012). Desarrollo e implementación de un sistema de facturación y control de inventario utilizando la librería ExtJS para la intranet de

librería

Rincón

Andino.

Recuperado

http://repositorio.pucesa.edu.ec/jspui/bitstream/123456789/957/1/75597.pdf

•

Plata, Kelly (2012). Desarrollo de una base de datos de inventario para activos fijos integrada a una interfaz gráfica de usuario (GUI). Recuperado de http://repository.upb.edu.co:8080/jspui/bitstream/123456789/596/1/digital_18

•

Rocca,

(2013).

Slideshare.

Obtenido

http://es.slideshare.net/PaulaRocc/aplicaciones-de-escritorio-y-web-25219707

ANEXOS

ANEXO 1 MANUAL GENERAL DE ADMINISTRACIÓN Y CONTROL DE LOS ACTIVOS FIJOS DEL SECTOR PÚBLICO

MANUAL GENERAL DE ADMINISTRACIÓN Y CONTROL DE LOS ACTIVOS FIJOS DEL SECTOR PÚBLICO (Acuerdo No. 012 CG) CONTRALORÍA GENERAL DEL ESTADO: Considerando: Que, mediante Acuerdo 918, publicado en el Registro Oficial No. 258 de agosto 27 de 1985, se expidió el Reglamento General de Bienes del Sector Público; Que, el Manual General de Contabilidad Gubernamental promulgado en el Suplemento del Registro Oficial No. 594 de diciembre 21 de 1994, contiene normas relacionadas con el registro y control de los bienes del Estado; Que, es necesario dotar a los responsables de la administración de los recursos materiales del sector público, de un documento en el que se sistematicen los procedimientos administrativos, para la correcta aplicación de las disposiciones vigentes sobre esta materia; En ejercicio de las facultades que le confiere el numeral 8 del Art. 303 de la Ley Orgánica de Administración Financiera y Control, Acuerda: Art. 1.- Expedir el Manual General de Administración y Control de los Activos Fijos del Sector Público. Art. 2.- La Dirección de Normas Sistemas y Gestión de la Contraloría General del Estado, actualizará periódicamente este Manual, a base de las necesidades que se detecten en forma directa o por sugerencias de los usuarios. Art. 3.- Las normas y procedimientos específicos que sobre esta materia formulen las entidades y organismos del sector público, previo a su aplicación, requerirán de la aprobación de la Contraloría General del Estado. Art. 4.- El presente Manual entrará en vigencia desde la fecha de su publicación en el Registro Oficial. Dado en la ciudad de San Francisco de Quito, Distrito Metropolitano, 26 de Marzo de 1997.

INTRODUCCIÓN De conformidad con lo que establece el Art. 303 numeral 8 literal e) de la Ley Orgánica de Administración Financiera y Control, la Contraloría General del Estado expide el presente Manual General de Administración y Control de los Activos Fijos para el Sector Público, documento que aspira constituir una importante herramienta de trabajo aplicable a una de las áreas consideradas generalmente como crítica en la administración pública. El volumen de las operaciones, el monto significativo de los recursos financieros invertidos por el Estado en bienes de naturaleza relativamente permanente, que se utilizan para el desarrollo de las actividades administrativas, técnicas y financieras y la ausencia de un instrumento normativo general, determinó la necesidad de elaborar este documento. En él se establecen guías y procedimientos, cuyo propósito principal es velar por la óptima administración y control de los recursos materiales de manera que se posibilite, la localización de las unidades administrativas donde están ubicados, la identificación de los custodios y usuarios de los bienes, la apropiada interrelación entre el control contable y físico mediante la aplicación de códigos preestablecidos y el uso de registros, formularios y reportes uniformes. Los criterios para la administración y el control de los Activos Fijos que comprende este Manual, se derivan del sistema general de contabilidad del sector público. Su estructura y contenido permiten la aplicación tanto en forma manual como automatizada; para este último caso cada entidad adoptará los mecanismos apropiados para la captura de la información pertinente y la producción de los reportes necesarios para los distintos propósitos. El Manual incorpora además los procedimientos que deben aplicarse para los ingresos y egresos de bienes originados en la compraventa, fabricación, remate, transferencias gratuitas (donación), traspasos internos, así como para el mantenimiento, entrega-recepciones, constataciones físicas de los bienes. Complementariamente, trata de los aspectos vinculados con los diferentes niveles de autoridad y responsabilidad, relacionados con la custodia y manejo de los bienes, con lo cual se propende al robustecimiento de los controles internos establecidos.

OBJETIVOS Objetivo General.- Definir un conjunto de criterios técnicos normativos de carácter práctico, que permitan una eficiente administración y control de los activos fijos, apoyado en medidas orientadas a salvaguardar los diversos recursos materiales. Objetivos específicos.- Proporcionar una guía que permita la implantación de una adecuada organización, segregación de funciones y delimitación de responsabilidades en el área de administración de los activos fijos. - Establecer registros, formularios y procedimientos tendientes a mejorar la administración de los bienes en lo que respecta al ingreso, egreso, traspaso, toma física, entrega-recepción, mantenimiento y protección de los mismos. - Determinar mecanismos de coordinación entre el control contable y el físico, a fin de facilitar el registro e identificación de los bienes y disponer de información útil y oportuna para la toma de decisiones y la adopción de acciones correctivas cuando fuere necesario.

ANEXO 2 Proceso Manual del Control de Inventario

PROCESO MANUAL LLEVADO EN LA HERRAMIENTA EXCEL EN LA UNIDAD EDUCATIVA DEL MILENIO “MI INUN YA”

ORDEN DE PEDIDO

ORDEN DE INGRESO

ANEXO 3 Encuesta realizada al personal docente, administrativo y autoridades de la Unidad Educativa del Milenio MI INUN YA

ENCUESTA La presente investigación tiene como objetivo recabar información para conocer el grado de aceptación que tendría la implementación de una aplicación informática para el control de inventario de los activos fijos y bienes que posee la Unidad Educativa del Milenio “MI INUN YA”. La información recopilada es para fines académicos: 1. ¿Dentro de las funciones que desempeña, hace uso del inventario de activos fijos y bienes de la Unidad Educativa?: a) Si b) No

( (

) )

2. ¿Con que frecuencia usted hace uso del inventario de activos fijos y bienes de la institución?: a) b) c) d) e)

Diariamente Semanalmente Mensualmente Anualmente Nunca

( ( ( ( (

) ) ) ) )

3. ¿Cómo considera que es el proceso de control y actualización del inventario de activos fijos y bienes?: a) b) c) d) e)

Bueno Agradable Tedioso Complicado Fácil

( ( ( ( (

) ) ) ) )

4. ¿Cree usted que el tiempo empleado para realizar el control y/o actualización de los activos fijos y bienes es?: a) b) c) d)

Optimo Moderado Regular Largo

( ( ( (

) ) ) )

5. ¿Considera que se deba cambiar el proceso actual de control de inventario de activos fijos y bienes de la institución?: a) Muy necesario b) Necesario c) No necesario

( ( (

) ) )

6. ¿En qué medida cree usted que una aplicación informática optimizaría los procesos del control de inventario de activos fijos y bienes?: a) Mucha b) Poca c) Ninguna

( ( (

) ) )

7. ¿Cuál cree usted que sería la reacción del personal que actualmente lleva el control de inventario de activos fijos y bienes tras la implementación de un sistema informático para llevar a cabo esta tarea?: a) Agrado b) Rechazo c) Indiferencia

( ( (

) ) )

8. Si se implementara una aplicación de software para el control del inventario de activos fijos y bienes, ¿Cómo cree usted que sería el proceso de transición entre el sistema actual y el nuevo?: a) b) c) d)

Optimo Moderado Regular Largo

( ( ( (

) ) ) )

9. ¿Qué tan necesario cree usted que el control de inventario de activos fijos y bienes sean manejados con la ayuda de una aplicación informática? a) Muy necesario b) Necesario c) No necesario

( ( (

) ) )

10. ¿Está de acuerdo con que se implemente una aplicación informática para el control del inventario de los activos fijos y bienes que posee la institución?: a) Si b) No

( (

) )

Cargo: ________________________________________

Nombre: ______________________________________

Firma: ________________________________________

ANEXO 4 Especificaci贸n de Requerimientos de Software

Especificaciones de Requerimiento de Software Proyecto: “DESARROLLO

SISTEMA

INFORMÁTICO PARA LA AUTOMATIZACIÓN DEL CONTROL DE INVENTARIO DE ACTIVOS FIJOS Y BIENES, UTILIZANDO SOFTWARE LIBRE, PARA LA UNIDAD EDUCATIVA DEL “MILENIO MI INUN YA” EN EL CANTÓN SANTO DOMINGO DE LOS COLORADOS. AÑO 2014.”

ÍNDICE DE CONTENIDOS

Especificaciones de requerimiento de software .............................................................................. 6 1.

INTRODUCCIÓN ............................................................................................................ 6

1.1.

Propósito de Especificación de Requerimiento de Software ............................................ 6

1.2.

Alcance del Producto ........................................................................................................ 6

1.3.

Resumen Ejecutivo ......................................................................................................... 10

Descripción General ....................................................................................................... 10

2.1.

Perspectiva ...................................................................................................................... 10

2.2.

Restricciones ................................................................................................................... 11

REQUERIMIENTOS FUNCIONALES ........................................................................ 12

3.1.

Requerimientos Funcionales ........................................................................................... 12

REQUERIMIENTOS NO FUNCIONALES .................................................................. 29

Requerimientos de la Interfaz Externa ........................................................................... 32

5.1.1.

Usuarios .......................................................................................................................... 32

5.1.2.

Hardware......................................................................................................................... 32

5.1.3.

Software .......................................................................................................................... 33

5.1.4.

Comunicaciones .............................................................................................................. 33

5.1.5.

Requerimientos de Rendimiento..................................................................................... 33

5.1.6.

Restricciones de Diseño .................................................................................................. 33

3 5.1.6.1. EstĂĄndares a Seguir ......................................................................................................... 33 5.1.6.2. Limitaciones de hardware ............................................................................................... 33 5.1.6.3. Limitaciones de software ................................................................................................ 33 5.1.7.

Atributos ......................................................................................................................... 34

5.1.7.1. Confiabilidad .................................................................................................................. 34 5.1.7.2. Mantenibilidad ................................................................................................................ 34 5.1.7.3. Portabilidad ..................................................................................................................... 34 5.1.7.4. Escalabilidad ................................................................................................................... 34 5.1.7.5. DesempeĂąo ..................................................................................................................... 34 5.1.7.6. Usabilidad ....................................................................................................................... 34

ÍNDICE TABLAS Tabla 1: Módulos del sistema ................................................................................................... 7 Tabla 2: Limitaciones del proyecto............................................................................................ 8 Tabla 3: Definiciones, Acrónimos y Abreviaturas .................................................................... 9 Tabla 4: Referencias .................................................................................................................. 9 Tabla 5: Características de los usuarios ................................................................................... 10 Tabla 6: Asunciones................................................................................................................. 11 Tabla 7: Ingreso al sistema ...................................................................................................... 12 Tabla 8: Registro de Usuarios .................................................................................................. 12 Tabla 9: Modificación de la información personal de cada usuario ........................................ 13 Tabla 10: Eliminar un usuario.................................................................................................. 14 Tabla 11: Consultas de usuarios ............................................................................................. 14 Tabla 12: Modificación de la información de activo fijo y bienes .......................................... 16 Tabla 13: Dar baja activos fijos y bienes ................................................................................ 17 Tabla 14: Consultar y Generar reportes de activos fijos y bienes............................................ 17 Tabla 15: Registro de Orden de ingreso de activos fijos y bienes ........................................... 18 Tabla 16: Modificación de orden de activos fijos y bienes ..................................................... 18 Tabla 17: Cancelación de orden de ingreso de activos fijos y bienes ...................................... 19 Tabla 18: Consulta y Generar reportes de orden de ingreso de activos fijos y bienes ............ 20 Tabla 19: Registro de orden de pedido de activos fijos y bienes ............................................. 21 Tabla 20: Modificación de orden de pedido de activos fijos y bienes ..................................... 21 Tabla 21: Cancelación de orden de pedido de activos fijos y bienes....................................... 22 Tabla 22: Consulta y Generar reportes de orden de pedido de activos fijos y bienes ............. 23 Tabla 23: Registros de Clientes ............................................................................................... 24 Tabla 24: Modificación de información personal de cada cliente ........................................... 24

5 Tabla 25: Eliminar un cliente................................................................................................... 25 Tabla 26: Consulta de clientes ................................................................................................. 26 Tabla 27: Registro de proveedores .......................................................................................... 26 Tabla 28: Modificaci贸n de la informaci贸n personal de cada proveedor .................................. 27 Tabla 29: Eliminar proveedor .................................................................................................. 28 Tabla 30: Consulta de proveedores .......................................................................................... 28 Tabla 31: Interfaz de usuario ................................................................................................... 29 Tabla 32: Asistencia en el manejo del sistema ........................................................................ 29 Tabla 33: Mantenimiento del sistema ...................................................................................... 30 Tabla 34: Desempe帽o del sistema............................................................................................ 30 Tabla 35: Perfil de Usuario ...................................................................................................... 31 Tabla 36: Seguridad del sistema .............................................................................................. 31

ESPECIFICACIONES DE REQUERIMIENTO DE SOFTWARE 1.

INTRODUCCIÓN

Es una descripción específica del funcionamiento del software a desarrollarse, esto permite una mejor comprensión del sistema ya que aquí se establecen los parámetros, requerimientos funcionales y no funcionales. 1.1.

Propósito de Especificación de Requerimiento de Software

El propósito de las Especificaciones de Requerimientos de Software para la elaboración del sistema de control de inventario de activos fijos y bienes de la Unidad Educativa del Milenio MI INUN YA es dar a conocer los requerimientos funcionales y no funcionales del sistema. Los beneficiarios directos serán las autoridades de la institución, así como también personal administrativo y docente. 1.2.

Alcance del Producto Este sistema a desarrollar se identificara con el nombre “Sistema Informático para el Control de Inventario de Activos Fijos y Bienes” SICIAF. El sistema será desarrollado para mejorar la administración y control de activos fijos y bienes de la Unidad Educativa del Milenio MI INUN YA. Los cuales son:  Ingreso de Bienes y Activos Fijos.  Préstamo de Bienes Activos Fijos.  Baja de Bienes y Activos Fijos.  Registro de Compras de los Activos Fijos y Bienes Este software debe ser capaz de permitir el ingreso de activos fijos y bienes y el control de los mismos dentro del inventario, el cual se debe aplicar de manera confiable y exacta de acuerdo con los requerimientos determinados en las visitas realizas al personal encargado del control de inventario. Con la implementación de SICIAF la Unidad Educativa del Milenio MI INUN YA se beneficiará en los siguientes aspectos:

7  Agilización en el control de inventario.  Optimización de tiempo.  Obtención de reportes. Se espera con este proyecto contribuir a:  Reducir el tiempo de respuesta en el ingreso y control de activos fijos y bienes.  Almacenamientos de datos centralizados.  Generación de reportes.  Agilización en el control del estado de los bienes a lo largo de todo el periodo académico. Tabla 1: Módulos del sistema

EL PROYECTO INCLUYE

Administración

Ingreso de usuarios al sistema de Control de inventario de

de Usuarios

Activos Fijos y Bienes.

Modificación de usuarios del sistema de Control de inventario de Activos Fijos y Bienes

Eliminación de usuarios del sistema de Control de inventario de Activos Fijos y Bienes

Consulta de usuarios del sistema de Control de inventario de Activos Fijos y Bienes

Asignación de Perfiles a los usuarios del sistema.

Asignación de un usuario y contraseña.

Control de

Ingreso de Activos Fijos y Bienes

8 Inventario de Activos Fijos y

Modificación de Activos Fijos y Bienes

Bienes Eliminación de Activos Fijos y Bienes

Consulta de Activos Fijos y Bienes

Reporte de Activos Fijos y Bienes

Creación de

Ingreso de órdenes de ingreso y pedido

Ordenes de Ingreso y Pedido Modificación de órdenes de ingreso y pedido

Eliminación de órdenes de ingreso y pedido

Consulta de órdenes de ingreso y pedido

Reporte de órdenes de ingreso y pedido Fuente: Los Disertantes – 2014

Tabla 2: Limitaciones del proyecto EL PROYECTO NO INCLUYE

Administración de Usuarios

Asignación de un usuario y contraseña para los estudiantes, docentes ni personal administrativo excepto encargada de inventario.

Asignación de un usuario contraseña para los Padres de Familia y o Representantes.

Control de Inventario de

9 Activos Fijos y Bienes

Generales

Equipamiento físico para la implantación del software

Logística de entrega del software Fuente: Los Disertantes – 2014

Tabla 3: Definiciones, Acrónimos y Abreviaturas Nombre

Descripción

IEEE

Instituto de Ingenieros Eléctricos y Electrónicos

Nombre de usuario con que ingresa al sistema

Hardware

JAVA

Lenguaje de Programación multiplataforma.

PostgreSQL

Gestor de base de datos

SICIAF

Sistema Informático para el Control de Inventario de Activos Fijos y Bienes

Software

Windows

Sistema operativo

Fuente: Los Disertantes – 2014

Tabla 4: Referencias Título del Documento

Referencia IEEE para la Especificación de Requerimientos

830-1984

Fuente: Los Disertantes – 2014

Software.

10 1.3.

Resumen Ejecutivo La intención del sistema es la de permitir un eficaz control del inventario, brindando mayor agilidad y seguridad al momento de dar uso al sistema. La creación de este software permitirá optimizar tiempo y facilitar el trabajo del usuario, también será elaborado con software interactivo con el usuario bajo la plataforma JAVA. Mediante una base de datos desarrollada en PostgreSQL permitirá almacenar toda la información necesaria y usuarios que intervendrán en el proceso. SICIAF se caracteriza por optimizar y agilizar el control del inventario y las operaciones que intervienen en el mismo dentro de la Unidad Educativa.

2. 2.1.

Descripción General

Perspectiva SICIAF se desarrollará con software libre como en el lenguaje de programación JAVA JEE y como motor de base de datos

en PostgreSQL, se acoplará a las

necesidades que la institución solicitó en los análisis de parámetros y requerimientos. Lo cual permitirá mejorar la calidad de servicio hacia el cliente. Se realizaran manuales de usuario y técnicos además de un diccionario de datos. Tabla 5: Características de los usuarios Usuario

ADMINISTRADOR

Persona que tiene acceso a:

Ingreso de Usuarios Modificación de Usuarios Eliminación de Usuarios Consulta de Usuarios Asignación de Permisos al resto de usuarios

SECRETARIA

Ingreso de Activos Fijos y Bienes

11 Modificación de Activos Fijos y Bienes Eliminación de Activos Fijos y Bienes Consulta de Activos Fijos y Bienes Registro de órdenes en ingreso.

Registro de órdenes de pedido. Fuente: Los Disertantes – 2014

2.2.

Restricciones Está prohibido el uso y reproducción del software sin autorización, la cual está protegido por la Ley de Propiedad Intelectual y por Régimen Común sobre Derechos de Autor y Derechos Conexos. Además queda prohibida la manipulación directa o indirecta del código fuente por parte de la Institución o terceros, sin previo consentimiento y supervisión de los autores del sistema SICIAF, bajo cualquier circunstancia a fin de garantizar la óptima funcionalidad del sistema. Este sistema se utilizará solo en la Unidad Educativa del Milenio “MI INUN YA” ubicada en la Cooperativa Los Unificados en la calle Biblian y Catacocha, cantón Santo Domingo de los Colorados, Provincia de los Tsáchilas; y será instalado en 3 ordenadores.

Tabla 6: Asunciones TIPO HW

RECURSO • • • • • • • • • • • • •

Servidor: Procesador: 2GHz en adelante 2GB de Memoria RAM 250 GB Disco Duro Tarjeta de Red Cliente: Impresora PCs Servidor: Windows Motor de Base de Datos: PostgreSQL 9.3 Java Runtime Environment 1.6.0 Cliente:

12 • Windows, Linux, ente otros • Java Runtime Environment Fuente: Los Disertantes – 2014

3. 3.1.

REQUERIMIENTOS FUNCIONALES

Requerimientos Funcionales

Tabla 7: Ingreso al sistema Identificación del requerimiento

RF-001

Nombre del requerimiento

Ingreso al sistema

Características

Los usuarios deberán identificarse con un nombre de usuario y contraseña para de esta manera poder acceder al sistema SICIAF, todo esto en la ventana de acceso al sistema.

Actores Involucrados

Todos los usuarios del sistema.

Descripción del requerimiento

Todos

los

usuarios

deberán

identificarse con su respectivo nombre de usuario y contraseña para poder acceder a sus funciones que le corresponden de acuerdo a su perfil de usuario. RNF-001, Requerimiento no funcional asociado

RNF-004,

RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 8: Registro de Usuarios Identificación del requerimiento

RF-002

Nombre del requerimiento

Creación de usuarios.

RNF-005,

13 Características

El administrador de usuarios será el

único

encargado

para

creación de nuevos usuarios que serán registrados en la base de datos. Actores Involucrados

Todos los usuarios del sistema.

Descripción del requerimiento

El usuario administrador será el encargado de crear más usuarios con sus respectivos perfiles los cuales se almacenaran en la base de datos del sistema SICIAF para su posterior acceso.

Requerimiento no funcional asociado

RNF-001,

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Prioridad del requerimiento

Alta

Fuente: Los Disertantes – 2014

Tabla 9: Modificación de la información personal de cada usuario Identificación del requerimiento

RF-003

Nombre del requerimiento

Modificación de usuarios.

Características

El administrador de usuarios será el

único

encargado

para

modificación de los usuarios ya registrados en la base de datos. Actores Involucrados

Todos los usuarios del sistema.

Descripción del requerimiento

El usuario administrador será el encargado

modificar

información de los usuarios que se encuentran registrados en la base de datos del sistema SICIAF. Dicha

información

será

actualizada en la base de datos del

14 sistema SICIAF. Requerimiento no funcional asociado

RNF-001,

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Prioridad del requerimiento

Alta

Fuente: Los Disertantes – 2014

Tabla 10: Eliminar un usuario RF-004 Identificación del requerimiento Eliminación de usuarios. Nombre del requerimiento El administrador de usuarios será Características

único

encargado

para

eliminación de usuarios

que se

encuentran registrados en la base de datos del sistema SICIAF. Todos los usuarios del sistema. Actores Involucrados El usuario administrador será el Descripción del requerimiento

encargado

eliminar

los

usuarios registrados en el sistema. Dicha

información

será

actualizada en la base de datos del sistema SICIAF. RNF-001, Requerimiento no funcional asociado

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 11: Consultas de usuarios RF-005 Identificación del requerimiento

RNF-002,

15 Búsqueda de usuarios. Nombre del requerimiento El administrador de usuarios será Características

único

encargado

para

búsqueda de los usuarios que se encuentran registrados en la base de datos del sistema SICIAF. Todos los usuarios del sistema. Actores Involucrados El usuario administrador será el Descripción del requerimiento

encargado

información

buscar los

usuarios

registrados en el sistema. Dicha información será de utilidad para poder modificar o eliminar a dicho usuario buscado en la base de datos del sistema SICIAF. RNF-001, Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 9: Registro de Activos fijos y bienes RF-006 Identificación del requerimiento Creación de Activos Fijos y Nombre del requerimiento

Bienes. La secretaria

Características

será la única

encargada para la creación de nuevos activos fijos y bienes que serán registrados en la base de

16 datos del sistema SICIAF. Secretaria. Actores Involucrados La secretaria será la encargada de Descripción del requerimiento

ingresar la información de los activos fijos y bienes, los cuales se almacenaran en la base de datos del

sistema

SICIAF

para

posterior consulta. RNF-001, Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 12: Modificación de la información de activo fijo y bienes RF-007 Identificación del requerimiento Modificación de Activos Fijos y Nombre del requerimiento

Bienes. La secretaria

Características

será la única

encargada para la modificación de activos fijos y bienes que se encuentran registrados en la base de datos del sistema SICIAF. Secretaria.

Actores Involucrados La secretaria será la encargada de Descripción del requerimiento

modificar la información de los activos fijos y bienes, los cuales se almacenaran en la base de datos del

sistema

SICIAF

para

posterior consulta. RNF-001, Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006

17 Alta Prioridad del requerimiento Fuente: Los Disertantes – 2014 Tabla 13: Dar baja activos fijos y bienes RF-008 Identificación del requerimiento Dar de baja a los Activos Fijos y Nombre del requerimiento

Bienes. La secretaria

Características

será la única

encargada para dar de baja a los activos fijos y bienes que se encuentran registrados en la base de datos del sistema SICIAF. Secretaria.

Actores Involucrados La secretaria será la encargada de Descripción del requerimiento

dar de baja a los activos fijos y bienes, los cuales se almacenaran en la base de datos del sistema con un estado diferente al resto en la base de datos del sistema SICIAF. RNF-001,

Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014 Tabla 14: Consultar y Generar reportes de activos fijos y bienes RF-009 Identificación del requerimiento Reporte de Activos Fijos y Bienes. Nombre del requerimiento La secretaria Características

será la única

encargada para dar reportes de activos fijos y bienes que se encuentran registrados en la base de datos del sistema SICIAF.

18 Secretaria. Actores Involucrados La secretaria será la encargada de Descripción del requerimiento

generar los reportes sobre la información de los activos fijos y bienes, los cuales se almacenaran en la base de datos del sistema SICIAF. RNF-001,

Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 15: Registro de Orden de ingreso de activos fijos y bienes RF-010 Identificación del requerimiento Creación de orden de ingreso de Nombre del requerimiento

Activos Fijos y Bienes. La secretaria

Características

será la única

encargada para la creación de la orden de ingreso de activos fijos y bienes. Secretaria.

Actores Involucrados La secretaria será la encargada de Descripción del requerimiento

Fuente: Los Disertantes – 2014

crear las órdenes de ingreso de los activos fijos y bienes, las cuales se almacenaran en la base de datos

Tabla 16: Modificación de

del

orden de activos fijos y bienes

sistema

SICIAF

para

posterior consulta. RNF-001, Requerimiento no funcional asociado

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento

RNF-002,

19 RF-011 Identificación del requerimiento Modificación de orden de ingreso Nombre del requerimiento

de Activos Fijos y Bienes. La secretaria

Características

será la única

encargada para la modificación de las órdenes de ingreso de los activos fijos y bienes que se encuentran registrados en la base de datos del sistema SICIAF. Secretaria.

Actores Involucrados La secretaria será la encargada de Descripción del requerimiento

modificar la información de las órdenes de activos fijos y bienes, los cuales se almacenaran en la base de datos del sistema SICIAF para su posterior consulta. RNF-001,

Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014 Tabla 17: Cancelación de orden de ingreso de activos fijos y bienes RF-012 Identificación del requerimiento Cancelar las órdenes de ingreso de Nombre del requerimiento

Activos Fijos y Bienes. La secretaria

Características

encargada

para

será la única cancelar

las

órdenes de ingreso de los activos fijos y bienes que se encuentran registrados en la base de datos del sistema SICIAF.

20 Secretaria. Actores Involucrados La secretaria será la encargada de Descripción del requerimiento

cancelar las órdenes de ingreso de los activos fijos y bienes, los cuales se almacenaran en la base de datos del sistema con un estado diferente al resto en la base de datos del sistema SICIAF. RNF-001,

Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 18: Consulta y Generar reportes de orden de ingreso de activos fijos y bienes RF-013 Identificación del requerimiento Reporte de órdenes de ingreso Nombre del requerimiento

Activos Fijos y Bienes. La secretaria

Características

será la única

encargada para dar reportes de órdenes de ingreso de activos fijos y

bienes

que

encuentran

registrados en la base de datos del sistema SICIAF. Secretaria. Actores Involucrados La secretaria será la encargada de Descripción del requerimiento

generar los reportes sobre la información de las ordenes de ingreso de los activos fijos y bienes, los cuales se almacenaran en la base de datos del sistema SICIAF.

21 RNF-001, Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 19: Registro de orden de pedido de activos fijos y bienes RF-014 Identificación del requerimiento Creación de orden pedido de Nombre del requerimiento

Activos Fijos y Bienes. La secretaria

Características

será la única

encargada para la creación de la orden de pedido de activos fijos y bienes. Secretaria.

Actores Involucrados La secretaria será la encargada de Descripción del requerimiento

crear las órdenes de pedido de los activos fijos y bienes, las cuales se almacenaran en la base de datos del

sistema

SICIAF

para

posterior consulta. RNF-001, Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 20: Modificación de orden de pedido de activos fijos y bienes RF-015 Identificación del requerimiento Modificación de orden de pedido Nombre del requerimiento

de Activos Fijos y Bienes.

22 La secretaria Características

será la única

encargada para la modificación de orden de pedido de activos fijos y bienes

que

encuentran

registrados en la base de datos del sistema SICIAF. Secretaria. Actores Involucrados La secretaria será la encargada de Descripción del requerimiento

modificar la información de las órdenes de los activos fijos y bienes, los cuales se almacenaran en la base de datos del sistema SICIAF para su posterior consulta. RNF-001,

Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 21: Cancelación de orden de pedido de activos fijos y bienes RF-016 Identificación del requerimiento Cancelación de orden de pedido de Nombre del requerimiento

activos fijos y bienes La secretaria

Características

será la única

encargada para cancelar la orden de pedido de los activos fijos y bienes

que

encuentran

registrados en la base de datos del sistema SICIAF. Secretaria. Actores Involucrados La secretaria será la encargada de Descripción del requerimiento

cancelar la orden de pedido de los activos fijos y bienes, los cuales se

23 almacenaran en la base de datos del sistema con un estado diferente al resto en la base de datos del sistema SICIAF. RNF-001, Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 22: Consulta y Generar reportes de orden de pedido de activos fijos y bienes RF-017 Identificación del requerimiento Reporte de orden de pedido de Nombre del requerimiento

Activos Fijos y Bienes. La secretaria

Características

será la única

encargada para dar reportes de orden de pedido de los activos fijos y bienes que se encuentran registrados en la base de datos del sistema SICIAF. Secretaria.

Actores Involucrados La secretaria será la encargada de Descripción del requerimiento

generar los reportes sobre la información de las ordenes de pedido de ingreso activos fijos y bienes, los cuales se almacenaran en la base de datos del sistema SICIAF. RNF-001,

Requerimiento no funcional asociado

Fuente: Los Disertantes – 2014

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006

24 Tabla 23: Registros de Clientes RF-018 Identificación del requerimiento Creación de clientes. Nombre del requerimiento El usuario secretaria será el único Características

encargado para la creación de nuevos

clientes

que

serán

registrados en la base de datos. Todos los usuarios del sistema. Actores Involucrados El Descripción del requerimiento

usuario

secretaria

será

encargado de crear más clientes los cuales se almacenarán en la base de datos del sistema SICIAF para su posterior acceso. RNF-001,

Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 24: Modificación de información personal de cada cliente RF-019 Identificación del requerimiento Modificación de clientes. Nombre del requerimiento El usuario secretaria será el único Características

encargado para la modificación de los clientes ya registrados en la base de datos.

25 Todos los usuarios del sistema. Actores Involucrados El Descripción del requerimiento

usuario

encargado

secretaria de

será

modificar

el la

información de los clientes que se encuentran registrados en la base de datos del sistema SICIAF. Dicha

información

será

actualizada en la base de datos del sistema SICIAF. RNF-001, Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 25: Eliminar un cliente RF-020 Identificación del requerimiento Eliminación de clientes. Nombre del requerimiento El usuario secretaria será el único Características

encargado para la eliminación de clientes

que

encuentran

registrados en la base de datos del sistema SICIAF. Todos los usuarios del sistema. Actores Involucrados El Descripción del requerimiento

usuario

encargado

secretaria de

eliminar

será

los

clientes registrados en el sistema. Dicha

información

será

actualizada en la base de datos del sistema SICIAF. RNF-001, Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006

26 Alta Prioridad del requerimiento Fuente: Los Disertantes – 2014 Tabla 26: Consulta de clientes RF-021 Identificación del requerimiento Búsqueda de clientes. Nombre del requerimiento El usuario secretaria será el único Características

encargado para la búsqueda de los clientes

que

encuentran

registrados en la base de datos del sistema SICIAF. Todos los usuarios del sistema. Actores Involucrados El Descripción del requerimiento

usuario

secretaria

encargado

información

será

buscar los

el la

clientes

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014 Tabla 27: Registro de proveedores RF-022 Identificación del requerimiento Creación de proveedores. Nombre del requerimiento El usuario secretaria será el único Características

encargado para la creación de nuevos proveedores que serán registrados en la base de datos.

27 Todos los usuarios del sistema. Actores Involucrados El Descripción del requerimiento

usuario

secretaria

encargado

proveedores

será

crear

los

el más

cuales

almacenaran en la base de datos del

sistema

SICIAF

para

posterior uso. RNF-001, Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 28: Modificación de la información personal de cada proveedor RF-023 Identificación del requerimiento Modificación de proveedores. Nombre del requerimiento El usuario secretaria será el único Características

encargado para la modificación de los proveedores ya registrados en la base de datos. Todos los usuarios del sistema.

Actores Involucrados El Descripción del requerimiento

usuario

encargado

secretaria de

será

modificar

el la

información de los proveedores que se encuentran registrados en la base de datos del sistema SICIAF. Dicha

información

será

actualizada en la base de datos del sistema SICIAF. RNF-001, Requerimiento no funcional asociado

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento

RNF-002,

28 Fuente: Los Disertantes – 2014

Tabla 29: Eliminar proveedor RF-024 Identificación del requerimiento Eliminación de proveedores. Nombre del requerimiento El usuario secretaria será el único Características

encargado para la eliminación de que se encuentran

proveedores

registrados en la base de datos del sistema SICIAF. Todos los usuarios del sistema. Actores Involucrados El Descripción del requerimiento

usuario

encargado proveedores

secretaria de

eliminar

registrados

será

los

sistema. Dicha información será actualizada en la base de datos del sistema SICIAF. RNF-001, Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 30: Consulta de proveedores RF-025 Identificación del requerimiento Consulta de proveedores. Nombre del requerimiento El usuario secretaria será el único Características

encargado para la consulta de los proveedores que se encuentran registrados en la base de datos del

29 sistema SICIAF. Todos los usuarios del sistema. Actores Involucrados El Descripción del requerimiento

usuario

encargado

secretaria de

será

buscar

el la

información de los proveedores registrados en el sistema. Dicha información será de utilidad para poder modificar o eliminar a dicho usuario buscado en la base de datos del sistema SICIAF. RNF-001, Requerimiento no funcional asociado

RNF-002,

RNF-003,

RNF-004, RNF-005, RNF-006 Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

4. REQUERIMIENTOS NO FUNCIONALES Tabla 31: Interfaz de usuario RNF-001 Identificación del requerimiento Interfaz de Usuario Nombre del requerimiento El sistema contara con una interfaz Características

amigable e intuitiva. Todos los usuarios.

Actores Involucrados El sistema presentara una interfaz Descripción del requerimiento

de fácil uso para los usuarios del sistema. Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 32: Asistencia en el manejo del sistema

30 RNF-002 Identificación del requerimiento Asistencia para el uso del sistema Nombre del requerimiento El sistema contara con ayuda para Características

el uso del sistema. Todos los usuarios.

Actores Involucrados El sistema contara con ayuda Descripción del requerimiento

complementaria que facilite el manejo del sistema. Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 33: Mantenimiento del sistema RNF-003 Identificación del requerimiento Mantenimiento del sistema. Nombre del requerimiento El sistema tendrá a disposición de Características

los usuarios tanto manual técnico como de usuario. Todos los usuarios.

Actores Involucrados El sistema dispondrá de manual de Descripción del requerimiento

usuario y de instalación para ayudar al mantenimiento fácil y eficaz del sistema Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 34: Desempeño del sistema RNF-004 Identificación del requerimiento

31 Desempeño del sistema. Nombre del requerimiento El sistema se desempeñará de la Características

mejor

manera

con

respuestas

óptimas a las peticiones de los usuarios. Todos los usuarios. Actores Involucrados El desempeño del sistema se verá Descripción del requerimiento

reflejado tanto en las consultas como en la administración de la información

dando

respuestas

rápidas y en corto tiempo. Alta Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 35: Perfil de Usuario RNF-005 Identificación del requerimiento Perfil de Usuario. Nombre del requerimiento El sistema garantizara el acceso a Características

los módulos correspondientes al perfil de usuario. Todos los usuarios.

Actores Involucrados El sistema autorizara el ingreso Descripción del requerimiento

correspondiente al perfil de cada usuario para una mayor seguridad en el manejo de la información. Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

Tabla 36: Seguridad del sistema

32 RNF-006 Identificación del requerimiento Seguridad del sistema. Nombre del requerimiento El sistema contara con seguridades Características

tanto a nivel de base de datos como de la aplicación. Todos los usuarios.

Actores Involucrados El Descripción del requerimiento

sistema

dispondrá

seguridades por medio de usuario y contraseña lo cual permitirá el acceso solo a usuarios registrados. Alta

Prioridad del requerimiento Fuente: Los Disertantes – 2014

5. 5.1.1.

Requerimientos de la Interfaz Externa

Usuarios El usuario podrá ser visualizar la aplicación por medio de una pantalla de tipo grafica en donde tendrá a su disposición menús para obtener información del sistema, según al perfil de usuario con la que ingrese.

5.1.2.

Hardware Impresoras matriciales (reportes) Mouse óptico USB Teclado estándar español Monitor resolución de 1024 x 728

33 5.1.3.

Software Sistema Operativo Windows o Linux. Java Runtime Eviroment

5.1.4.

Comunicaciones Con la ayuda de la red que dispone la Unidad Educativa del Milenio MI INUN YA realizaremos las conexiones que nos permita tener un control seguro y eficiente en las distintas máquinas que usarán el sistema.

5.1.5.

Requerimientos de Rendimiento Hemos previsto un tiempo de respuesta del sistema desde 1 a 2 segundos, velocidad tomada en cuenta a partir de los requerimientos solicitados tanto para hardware como para software.

5.1.6.

Restricciones de Diseño

5.1.6.1. Estándares a Seguir Como es un sistema de práctica no será muy extenso, puede que no se utilice ningún estándar, pero en caso de ser necesario podría ser el IEEE. 5.1.6.2. Limitaciones de hardware  Memoria RAM mínimo de 2GB  Disco duro mínimo 250GB  Procesador mínimo de 1.33 GHz

En lo posterior si se necesita más recursos de hardware, se modificaran los datos según las necesidades que surjan en el desarrollo del proyecto. 5.1.6.3. Limitaciones de software  Sistema Operativo Windows XP, Windows vista, windows7  Gestor de bases de datos PostgreSQL  Java Runtime Enviroment

34 5.1.7.

Atributos

5.1.7.1. Confiabilidad La seguridad del sistema será muy estricta donde podrán ingresar las personas autorizadas con sus respectivos usuarios y contraseñas, los usuarios podrán ingresar a los distintos módulos del sistema según la actividad o el cargo que desempeñe. 5.1.7.2. Mantenibilidad  Cualquier servicio de mantenimiento como: actualizaciones o reparos del software fuera del año de garantía tendrán un costo adicional. 5.1.7.3. Portabilidad  El Sistema podrá ser instalado en una plataforma de la familia de Windows o plataforma libre, según las preferencias que tenga el cliente. 5.1.7.4. Escalabilidad  El sistema será capaz de crecer (aumentar módulos) dependiendo de las necesidades. 5.1.7.5. Desempeño  El sistema será capaz de adaptarse a todos los requerimientos que fueron formulados por el cliente, llevándoles a cabo de manera eficiente tanto en tiempo como en recursos. 5.1.7.6. Usabilidad  El sistema será accesible a los usuarios a través de su interfaz gráfica, la cual se manejará por medio de perfiles dándole a cada tipo de usuario su funcionalidad correspondiente.

ANEXO 5 Historias de Usuario

Historias de Usuario Proyecto: “DESARROLLO

SISTEMA

Historia de Usuario Número: 1

Usuario: Administrador, Secretaria

Nombre de Historia: Ingreso al Sistema Prioridad en Negocio: Alta

Riesgo en Desarrollo: Baja

Puntos Estimados: 3

Iteración asignada: 1

Programador Responsable: Jadira Barriga Descripción: El ingreso al sistema estará gestionado por roles asignados a los usuarios, según el rol que se haya asignado el sistema habilitara las opciones que le corresponde y deshabilitará otras, el usuario administrador tendrá solo acceso a la administración de usuarios, y el usuario secretaria tendrá acceso solo a sus módulos correspondientes. Observaciones:

Historia de Usuario Número: 2

Usuario: Administrador

Nombre de Historia: Registro de Usuarios Prioridad en Negocio: Alta

Riesgo en Desarrollo: Baja

Puntos Estimados: 4

Iteración asignada: 1

Programador Responsable: Mauricio Tamayo Descripción: Los usuarios que interactúen en el sistema deberán estar registrados en la base de datos, por ello el registro de usuarios permitirá registrar y dar los permisos de acuerdo a los roles asignados. Observaciones: Los datos que el usuario deberá ingresar para su registro en el sistema serán: Nombre de usuario, Contraseña, Nombre de la persona, Correo electrónico y el rol de usuario.

Historia de Usuario Número: 3

Usuario: Administrador

Nombre de Historia: Eliminación de Usuario Prioridad en Negocio: Media

Riesgo en Desarrollo: Baja

Puntos Estimados: 3

Iteración asignada: 1

Programador Responsable: Mauricio Tamayo Descripción: El usuario con el rol de administrador puede eliminar a otro usuario para que dicho usuario ya no pueda ingresar al sistema. Observaciones: La eliminación de usuarios permite denegar el acceso a usuarios que hayan hecho mal uso del sistema y como control de seguridad, además el usuario será borrado de la base de datos solo cambiara de estado.

Historia de Usuario Número: 4

Usuario: Administrador

Nombre de Historia: Consulta de Usuarios Prioridad en Negocio: Media

Riesgo en Desarrollo: Media

Puntos Estimados: 1

Iteración asignada: 1

Programador Responsable: Mauricio Tamayo Descripción: El usuario administrador podrá visualizar los usuarios registrados en el sistema además. Observaciones: El usuario administrador no podrá visualizarse en la consulta de usuarios ya que no podrá auto eliminarse.

Historia de Usuario Número: 5

Usuario: Secretaria

Nombre de Historia: Registro de Activos Fijos y Bienes Prioridad en Negocio: Alta

Riesgo en Desarrollo: Media

Puntos Estimados: 4

Iteración asignada: 5

Programador Responsable: Jadira Barriga Descripción: El usuario con el rol de secretaria podrá registrar los activos fijos y bienes. Observaciones: Los campos deben estar correctamente ingresados y el código del activo fijo o bien no podrá repetirse.

Historia de Usuario Número: 6

Usuario: Secretaria

Nombre de Historia: Modificación de Activos Fijos y Bienes Prioridad en Negocio: Alta

Riesgo en Desarrollo: Media

Puntos Estimados: 2

Iteración asignada: 4

Programador Responsable: Jadira Barriga Descripción: El usuario con el rol de secretaria podrá modificar la información de los activos fijos y bienes, previa a la respectiva consulta. Observaciones: El activo fijo o bien deberá existir para poder ser modificado.

Historia de Usuario Número: 7

Usuario: Secretaria

Nombre de Historia: Baja de Activos Fijos y Bienes Prioridad en Negocio: Alta

Riesgo en Desarrollo: Media

Puntos Estimados: 2

Iteración asignada: 5

Programador Responsable: Jadira Barriga Descripción: El usuario con el rol de secretaria podrá dar de baja los activos fijos y bienes ya sea porque ha cumplido su vida útil o por donación. Observaciones: El activo fijo o bien deberá existir en para poder ser dado de baja.

Historia de Usuario Número: 8

Usuario: Secretaria

Nombre de Historia: Consulta y Reporte de Activos Fijos y Bienes Prioridad en Negocio: Alta

Riesgo en Desarrollo: Media

Puntos Estimados: 1

Iteración asignada: 3

Programador Responsable: Mauricio Tamayo Descripción: El usuario con el rol de secretaria podrá visualizar las los activos fijos y bienes, además podrá generar un reporte ya sea guardándolo en una unidad de almacenamiento o impreso. Observaciones: La información no podrá ser modificada ni eliminada solo visualizada.

Historia de Usuario Número: 9

Usuario: Secretaria

Nombre de Historia: Registro de Orden de Ingreso de Activos Fijos y Bienes Prioridad en Negocio: Alta

Riesgo en Desarrollo: Alta

Puntos Estimados: 3

Iteración asignada: 5

Programador Responsable: Mauricio Tamayo Descripción: El usuario con el rol de secretaria podrá registrar la orden de ingreso de los activos fijos y bienes que sean adquiridos, ya sea por compra o donaciones. Observaciones:

Historia de Usuario Número: 10

Usuario: Secretaria

Nombre de Historia: Modificación de la Orden de Ingreso de Activos Fijos y Bienes Prioridad en Negocio: Alta

Riesgo en Desarrollo: Media

Puntos Estimados: 3

Iteración asignada: 4

Programador Responsable: Mauricio Tamayo Descripción: El usuario con el rol de secretaria podrá modificar la información de la orden de ingreso de los activos fijos y bienes previa a la consulta de la respectiva orden de ingreso. Observaciones: La orden de ingreso deberá existir para poder ser modificada.

Historia de Usuario Número: 11

Usuario: Secretaria

Nombre de Historia: Eliminación de Orden de Ingreso de Activos Fijos y Bienes Prioridad en Negocio: Alta

Riesgo en Desarrollo: Media

Puntos Estimados: 2

Iteración asignada: 3

Programador Responsable: Mauricio Tamayo Descripción: El usuario con el rol de secretaria podrá eliminar la orden de ingreso de los activos fijos y bienes previa a la consulta de la respectiva orden de ingreso. Observaciones: La orden de ingreso deberá existir para poder ser eliminada.

Historia de Usuario Número: 12

Usuario: Secretaria

Nombre de Historia: Consulta y Reporte de las Ordenes de Ingreso de Activos Fijos y Bienes Prioridad en Negocio: Alta

Riesgo en Desarrollo: Media

Puntos Estimados: 1

Iteración asignada: 2

Programador Responsable: Mauricio Tamayo Descripción: El usuario con el rol de secretaria podrá visualizar las ordenes de ingreso los activos fijos y bienes, además podrá generar un reporte ya sea guardándolo en una unidad de almacenamiento o impreso. Observaciones: La información no podrá ser modificada ni eliminada solo visualizada, solo cambiara el estado mas no será borrado del sistema.

Historia de Usuario Número: 13

Usuario: Secretaria

Nombre de Historia: Registro de Orden de Pedido de Activos Fijos y Bienes Prioridad en Negocio: Alta

Riesgo en Desarrollo: Alta

Puntos Estimados: 3

Iteración asignada: 5

Programador Responsable: Mauricio Tamayo Descripción: El usuario con el rol de secretaria podrá registrar la orden de pedido de los activos fijos y bienes que estén registrados en la base de datos, dichas ordenes serán impresas y con firmas de responsabilidad para la posterior entrega de los activos fijos o bienes según sea el caso. Observaciones:

Historia de Usuario Número: 14

Usuario: Secretaria

Nombre de Historia: Modificación de la Orden de Pedido de Activos Fijos y Bienes Prioridad en Negocio: Alta

Riesgo en Desarrollo: Media

Puntos Estimados: 3

Iteración asignada: 4

Programador Responsable: Mauricio Tamayo Descripción: El usuario con el rol de secretaria podrá modificar la información de la orden de pedido de los activos fijos y bienes previa a la consulta de la respectiva orden de ingreso. Observaciones: La orden de pedido deberá existir para poder ser modificada.

Historia de Usuario Número: 15

Usuario: Secretaria

Nombre de Historia: Eliminación de Orden de Pedido de Activos Fijos y Bienes Prioridad en Negocio: Alta

Riesgo en Desarrollo: Media

Puntos Estimados: 2

Iteración asignada: 3

Programador Responsable: Mauricio Tamayo Descripción: El usuario con el rol de secretaria podrá eliminar la orden de pedido de los activos fijos y bienes previa a la consulta de la respectiva orden de ingreso. Observaciones: La orden de ingreso deberá existir para poder ser eliminada, solo cambiara el estado mas no será borrado del sistema.

Historia de Usuario Número: 16

Usuario: Secretaria

Nombre de Historia: Consulta y Reporte de las Ordenes de Pedido de Activos Fijos y Bienes Prioridad en Negocio: Alta

Riesgo en Desarrollo: Media

Puntos Estimados: 1

Iteración asignada: 2

Programador Responsable: Mauricio Tamayo Descripción: El usuario con el rol de secretaria podrá visualizar las ordenes de pedido los activos fijos y bienes, además podrá generar un reporte ya sea guardándolo en una unidad de almacenamiento o impreso. Observaciones: La información no podrá ser modificada ni eliminada solo visualizada.

Historia de Usuario Número: 17

Usuario: Secretaria

Nombre de Historia: Registro de Clientes Prioridad en Negocio: Alta

Riesgo en Desarrollo: Media

Puntos Estimados: 1

Iteración asignada: 2

Programador Responsable: Jadira Barriga Descripción: El usuario con el rol de secretaria podrá registrar a los clientes que harán uso de los activos fijos y bienes, los cuales podrán ser solicitados con su respectiva orden de pedido. Observaciones:

Historia de Usuario Número: 18

Usuario: Secretaria

Nombre de Historia: Modificación de Clientes Prioridad en Negocio: Alta

Riesgo en Desarrollo: Media

Puntos Estimados: 1

Iteración asignada: 1

Programador Responsable: Jadira Barriga Descripción: El usuario con el rol de secretaria podrá modificar la información de los clientes que harán uso de los activos fijos y bienes, previa a la consulta respectiva de dicho cliente. Observaciones: El cliente deberá estar registrado en la base de datos para poder ser modificado.

Historia de Usuario Número: 19

Usuario: Secretaria

Nombre de Historia: Eliminación de Clientes Prioridad en Negocio: Alta

Riesgo en Desarrollo: Media

Puntos Estimados: 1

Iteración asignada: 1

Programador Responsable: Jadira Barriga Descripción: El usuario con el rol de secretaria podrá eliminar a los clientes que ya no hagan uso de los activos fijos y bienes, previa a la consulta respectiva de dicho cliente. Observaciones: El cliente deberá estar registrado en la base de datos para poder ser eliminado, solo cambiara el estado mas no será borrado del sistema.

Historia de Usuario Número: 20

Usuario: Secretaria

Nombre de Historia: Consulta y Reporte de Clientes Prioridad en Negocio: Alta

Riesgo en Desarrollo: Media

Puntos Estimados: 1

Iteración asignada: 1

Programador Responsable: Jadira Barriga Descripción: El usuario con el rol de secretaria podrá visualizar a los clientes que estén registrados en el sistema, además tendrá la posibilidad de generar un reporte y este podrá ser guardado en una unidad de almacenamiento o impreso. Observaciones: La información no podrá ser modificada ni eliminada solo visualizada.

Historia de Usuario Número: 21

Usuario: Secretaria

Nombre de Historia: Registro de Proveedores Prioridad en Negocio: Alta

Riesgo en Desarrollo: Media

Puntos Estimados: 1

Iteración asignada: 2

Programador Responsable: Jadira Barriga Descripción: El usuario con el rol de secretaria podrá registrar a los proveedores que de los activos fijos y bienes, los cuales serán registrados con su respectiva orden de ingreso. Observaciones:

Historia de Usuario Número: 22

Usuario: Secretaria

Nombre de Historia: Modificación de Proveedores Prioridad en Negocio: Media

Riesgo en Desarrollo: Media

Puntos Estimados: 1

Iteración asignada: 1

Programador Responsable: Jadira Barriga Descripción: El usuario con el rol de secretaria podrá modificar la información de los proveedores, previa a la consulta respectiva de dicho proveedor. Observaciones: El proveedor deberá estar registrado en la base de datos para poder ser modificado.

Historia de Usuario Número: 23

Usuario: Secretaria

Nombre de Historia: Eliminación de Proveedores Prioridad en Negocio: Media

Riesgo en Desarrollo: Media

Puntos Estimados: 1

Iteración asignada: 1

Programador Responsable: Jadira Barriga Descripción: El usuario con el rol de secretaria podrá eliminar a los proveedores que ya no sean necesarios, previa a la consulta respectiva de dicho proveedor. Observaciones: El proveedor deberá estar registrado en la base de datos para poder ser eliminado, solo cambiara el estado mas no será borrado del sistema.

Historia de Usuario Número: 24

Usuario: Secretaria

Nombre de Historia: Consulta y Reporte de Proveedores Prioridad en Negocio: Alta

Riesgo en Desarrollo: Media

Puntos Estimados: 1

Iteración asignada: 1

Programador Responsable: Jadira Barriga Descripción: El usuario con el rol de secretaria podrá visualizar a los proveedores que estén registrados en el sistema, además tendrá la posibilidad de generar un reporte y este podrá ser guardado en una unidad de almacenamiento o impreso. Observaciones: La información no podrá ser modificada ni eliminada solo visualizada.

ANEXO 6 Diccionario de Datos

Diccionario de Datos Proyecto: “DESARROLLO

SISTEMA

INFORMÁTICO PARA LA AUTOMATIZACIÓN DEL

CONTROL

INVENTARIO

ACTIVOS FIJOS Y BIENES, UTILIZANDO SOFTWARE

LIBRE,

PARA

UNIDAD

EDUCATIVA DEL “MILENIO MI INUN YA” EN EL CANTÓN SANTO DOMINGO DE LOS COLORADOS. AÑO 2014.”

ÍNDICE DE CONTENIDOS 1.

INTRODUCCIÓN

TABLAS

2.1

Parametrización

2.2

Lista de Tablas

2.2.1

Tabla categorías_productos

2.2.2

Tabla clientes

2.2.3

Tabla departamentos

2.2.4

Tabla ingresos_productos

2.2.5

Tabla movientos_productos

2.2.6

Tabla ordenes_ingreso

2.2.7

Tabla ordenes_pedido

2.2.8

Tabla pedidos_productos

2.2.9

Tabla productos

2.2.10 Tabla proveedores

2.2.11 Tabla usuarios

FUNCIONES

3.1

Parametrización

3.2

Lista de Funciones

3.2.1

Función sp_eliminar

3.2.2

Función sp_guardar_categoria

3.2.3

Función sp_guardar_cliente

3.2.4

Función sp_guardar_departamento

3.2.5

Función sp_guardar_orden_ingreso

3.2.6

Función sp_guardar_orden_pedido

3.2.7

Función sp_guardar_producto

3.2.8

Función sp_guardar_proveedor

3.2.9

Función sp_guardar_usuario

LISTA DE TABLAS Tabla 1: Lista de Tablas ...................................................................................................................... 6 Tabla 2: Tabla categorias_productos................................................................................................... 7 Tabla 3: Restricciones Tabla categorías_productos ............................................................................ 7 Tabla 4: Tabla de clientes.................................................................................................................... 7 Tabla 5: Restricciones Tabla clientes ................................................................................................... 8 Tabla 6: Tabla departamentos ............................................................................................................ 8 Tabla 7: Restricciones Tabla departamentos ...................................................................................... 8 Tabla 8: Tabla de ingresos_productos ................................................................................................ 9 Tabla 9: Restricciones Tabla ingresos_productos ............................................................................... 9 Tabla 10: Tabla de movimientos_productos ....................................................................................... 9 Tabla 11: Restricciones de la Tabla movimientos_productos ........................................................... 10 Tabla 12: Tabla de ordenes_ingreso ................................................................................................. 10 Tabla 13: Restricciones Tabla proveedores....................................................................................... 10 Tabla 14: Tabla de ordenes_pedido .................................................................................................. 11 Tabla 15: Restricciones Tabla proveedores....................................................................................... 11 Tabla 16: Tabla de pedidos_productos ............................................................................................. 11 Tabla 17: Restricciones Tabla pedidos_productos ............................................................................ 12 Tabla 18: Tabla de productos ............................................................................................................ 12 Tabla 19: Restricciones Tabla productos........................................................................................... 13 Tabla 20: Tabla de proveedores ........................................................................................................ 13 Tabla 21: Restricciones Tabla proveedores....................................................................................... 13 Tabla 22: Tabla de usuarios ............................................................................................................... 14 Tabla 23: Restricciones Tabla usuarios ............................................................................................. 14 Tabla 24: Lista de Funciones ............................................................................................................. 15 Tabla 25: Función sp_eliminar .......................................................................................................... 16 Tabla 26: Función sp_guardar_categoria .......................................................................................... 16 Tabla 27: Función sp_guardar_cliente .............................................................................................. 17 Tabla 28: Función sp_guardar_departamento .................................................................................. 18 Tabla 29: Función sp_guardar_orden_ingreso ................................................................................. 18 Tabla 30: Función sp_guardar_orden_pedido .................................................................................. 19

5 Tabla 31: Funci贸n sp_guardar_producto .......................................................................................... 20 Tabla 32: Funci贸n sp_guardar_proveedor ........................................................................................ 21 Tabla 33: Funci贸n sp_guardar_usuario ............................................................................................. 22

1. INTRODUCCIÓN El presente documento contiene el diccionario de datos, donde se describen las características lógicas utilizadas en el sistema para el control de inventario de activos fijos y bienes.

2. TABLAS 2.1

Parametrización

Cada tabla del Sistema de control de inventario de activos fijos y bienes inicia con el nombre propio que se le ha designado a la tabla en el cual define su contenido.

2.2

Lista de Tablas

Lista de las tablas utilizadas en el desarrollo del modelo de la base de datos para el sistema de control de inventario de activos fijos y bienes.

N.-

Nombre de la Tabla

Descripción

CATEGORIAS_PRODUCTOS

CLIENTES

DEPARTAMENTOS

INGRESOS_PRODUCOS

MOVIMIENTOS_PRODUCTOS

ORDENES_INGRESO

ORDENES_PEDIDO

PEDIDOS_PRODUCTOS

PRODUCTOS

PROVEEDORES

USUARIOS

Tabla que contiene las categorías de los activos fijos y bienes. Tabla que contiene a las personas u entidades que harán uso del inventario. Tabla que contiene los departamentos a los cuales pertenecen los clientes. Tabla que almacena el detalle de las ordenes de ingreso Tabla que contiene el movimiento de stock de los productos. Tabla que contiene las ordenes de ingreso de los activos fijos y bienes. Tabla que contiene las ordenes de pedido de los activos fijos y bienes. Tabla que almacena el detalle de las ordenes de pedido Tabla que contiene los activos fijos y bienes de la unidad educativa. Tabla que contiene la información de los proveedores de los activos fijos y bienes. Tabla que contiene a los usuarios del sistema.

Tabla 1: Lista de Tablas Fuente: Los autores

2.2.1 N.-

Tabla categorías_productos Nombre de Columna

Tipo de Datos

Null

Comentarios Código secuencial de

cpro_id

Integer

cpro_nombre

character varying(100)

Nombre de la categoría

cpro_estado

Smallint

Estado de la categoría

categorias_productos

Tabla 2: Tabla categorias_productos Fuente: Los autores

•

Restricciones Nombre

Tipo

pk_categorias_producto

PRIMARY KEY

Columna Local

Tabla Ref.

Columna de Ref.

cpro_id

Tabla 3: Restricciones Tabla categorías_productos Fuente: Los autores

2.2.2 N.-

Tabla clientes Nombre de Columna

Tipo de Datos

Null

Comentarios

cli_id

integer

Código secuencial de clientes

cli_identificacion

character varying(13)

Cedula del cliente

cli_nombres

character varying(50)

Nombres del cliente

cli_apellidos

character varying(50)

Apellidos del cliente

cli_telefono

character varying(20)

Teléfono del cliente

cli_correo

character varying(100)

Correo electrónico del cliente

cli_estado

smallint

Estado del cliente

depa_id

integer

Código secuencial de departamentos

Tabla 4: Tabla de clientes Fuente: Los autores

•

Restricciones Columna

Nombre

Tipo

pk_clientes

PRIMARY KEY

cli_id

fk_departamentos_id

FOREIGN KEY

depa_id

Tabla Ref.

Local

Departamentos

Columna de Ref.

depa_id

Tabla 5: Restricciones Tabla clientes Fuente: Los autores

2.2.3

Tabla departamentos

N.-

Nombre de Columna

Tipo de Datos

Null

Comentarios

depa_id

integer

Código secuencial de departamentos

depa_nombre

character varying(100)

Nombre del departamento

depa_descripcion

character varying(100)

Descripción del departamento

depa_estado

smallint

Estado del departamento

Tabla 6: Tabla departamentos Fuente: Los autores

•

Restricciones Nombre

Tipo

pk_departamentos

PRIMARY KEY

Columna Local

Tabla Ref.

depa_id

Tabla 7: Restricciones Tabla departamentos Fuente: Los autores

Columna de Ref.

2.2.4 N.-

Tabla ingresos_productos Nombre de Columna

Tipo de Datos

Null

Comentarios Código secuencial de ingresos_productos

ingrpro_id

integer

ingrpro_cantidad

integer

ingrpro_precio

double precisión

Precio del producto

ingr_id

integer

Código de orden de ingreso

prod_id

integer

Código secuencial de los productos

Cantidad del producto para la orden de ingreso

Tabla 8: Tabla de ingresos_productos Fuente: Los autores

•

Restricciones Tabla Ref.

Columna

Nombre

Tipo

Columna Local

pk_ingresos_productos

PRIMARY KEY

ingrpor_id

fk_ordenes_ingreso

FOREIGN KEY

ingr_id

Ordenes_ingreso

ingr_id

fk_productos

FOREIGN KEY

prod_id

productos

prod_id

de Ref.

Tabla 9: Restricciones Tabla ingresos_productos Fuente: Los autores

2.2.5 N.-

Tabla movientos_productos Nombre de Columna

Tipo de Datos

Null

Comentarios Código secuencial de los movimientos de

pmov_id

integer

prod_id

integer

Código secuencial de productos

pmov_fecha

character varying (10)

Fecha del movimiento

pmov_cantidad

integer

Cantidad del movimiento de producto

pmov_tipo

integer

Tipo de movimiento

pmov_estado

smallint

Estado del movimiento de producto

stock de productos

Tabla 10: Tabla de movimientos_productos Fuente: Los autores

•

Restricciones Nombre

Tipo

Columna Local

pk_movimientos_productos

PRIMARY KEY

pmov_id

fk_productos

FOREIGN KEY

prod_id

Columna de

Tabla Ref.

Ref.

productos

prod_id

Tabla 11: Restricciones de la Tabla movimientos_productos Fuente: Los autores

2.2.6 N.-

Tabla ordenes_ingreso Nombre de Columna

Tipo de Datos

Null

Comentarios

ingr_id

integer

Código secuencial de los ordenes_ingreso

usua_id

integer

Código secuencial de usuarios

prov_id

integer

Código secuencial de proveedores

ingr_factura

character varying(20)

Numero de factura

ingr_cur

character varying(20)

CUR

ingr_tipo

smallint

Tipo de ingreso

ingr_acta

character varying(20)

Acta asociado al ingreso

ingr_estado

smallint

Estado de las ordenes de ingreso

Tabla 12: Tabla de ordenes_ingreso Fuente: Los autores

•

Restricciones Columna

Nombre

Tipo

pk_ordenes_ingreso

PRIMARY KEY

ingr_id

fk_proveedores

FOREIGN KEY

prov_id

Local

Tabla Ref.

Columna de Ref.

Proveedores

prov_id

Tabla 13: Restricciones Tabla proveedores Fuente: Los autores

2.2.7 N.-

Tabla ordenes_pedido Nombre de Columna

Tipo de Datos

Null

Comentarios

pedi_id

integer

Cรณdigo secuencial de las ordenes de pedido

pedi_cliente

integer

Cรณdigo secuencial de clientes

usua_id

integer

Cรณdigo secuencial de usuarios

pedi_fecha

character varying(20)

Numero de factura

pedi_observaciones

character varying(20)

Observaciones del pedido

pedi_tipo

smallint

Tipo de pedido

pedi_acta

character varying(20)

Acta asociado al pedido

pedi_estado

smallint

Estado de las ordenes de pedido

Tabla 14: Tabla de ordenes_pedido Fuente: Los autores

โ ข

Restricciones Columna

Nombre

Tipo

Tabla Ref.

Columna de Ref.

pk_ordenes_pedido

PRIMARY KEY

pedi_id

fk_clientes

FOREIGN KEY

cli_id

Clientes

cli_id

fk_usuarios

FOREIGN KEY

usua_id

Usuarios

usua_id

Local

Tabla 15: Restricciones Tabla proveedores Fuente: Los autores

2.2.8 N.-

Tabla pedidos_productos Nombre de Columna

Tipo de Datos

Null

Comentarios

pedipro_id

Integer

Cรณdigo secuencial de los clientes

pedipro _cantidad

Character varying(13)

Cedula del cliente

Prod_id

Character varying(50)

Nombres del cliente

Pedi_id

Character varying(50)

Apellidos del cliente

Tabla 16: Tabla de pedidos_productos Fuente: Los autores

•

Restricciones Columna

Nombre

Tipo

Tabla Ref.

Columna de Ref.

pk_pedidos_productos

PRIMARY KEY

cli_id

fk_productos

FOREIGN KEY

prod_id

productos

prod_id

fk_ordenes_pedido

FOREIGN KEY

pedi_id

Ordenes_pedido

pedi_id

Local

Tabla 17: Restricciones Tabla pedidos_productos Fuente: Los autores

2.2.9 N.-

Tabla productos Nombre de Columna

Tipo de Datos

Null

Comentarios

prod_id

integer

Código secuencial de los productos

prod_categoria

smallint

prod_codigo

character varying(50)

Código del producto

prod_descripcion

character varying(500)

Nombre descriptivo del producto

prod_pcp

double precisión

Precio del producto

prod_vidautil

smallint

Vida útil del producto

prod_custodio

character varying(50)

Custodio del producto

prod_tipo

smallint

Tipo de producto

prod_serie

character varying(50)

Serie del producto

prod_marca

character varying(100)

Marca del producto

prod_modelo

character varying(100)

Modelo del producto

prod_esctructura

character varying(100)

Estructura del producto

prod_color

character varying(50)

Color del producto

prod_condicion

character varying(50)

Condición del producto

prod_estado

smallint

Estado del producto

prod_ubicacion

character varying(100)

Ubicación del producto

Código secuencial de categoría de productos

Tabla 18: Tabla de productos Fuente: Los autores

•

Restricciones Nombre

Tipo

pk_productos

PRIMARY KEY

fk_caracteristicas_producto

FOREIGN KEY

Columna

Columna de

Tabla Ref.

Local

Ref.

cli_id prod_categoria Categorias_productos

cpro_id

Tabla 19: Restricciones Tabla productos Fuente: Los autores

2.2.10 Tabla proveedores N.-

Nombre de Columna

Tipo de Datos

Null

Comentarios

prov_id

Integer

Código secuencial de los proveedores

prov_identificacion

character varying(13)

Cedula o ruc del proveedor

prov_nombre

character varying(80)

Nombre del proveedor

prov_direccion

character varying(80)

Dirección del proveedor

prov_telefono1

character varying(12)

Teléfono del proveedor

prov_correo1

character varying(40)

Correo electrónico del proveedor

prov_tipo

integer

Tipo de proveedor

prov_estado

smallint

Estado del proveedor

Tabla 20: Tabla de proveedores Fuente: Los autores

•

Restricciones Nombre

Tipo

pk_proveedores

PRIMARY KEY

Columna Local

Tabla Ref.

prov_id

Tabla 21: Restricciones Tabla proveedores Fuente: Los autores

Columna de Ref.

2.2.11 Tabla usuarios N.-

Nombre de Columna

Tipo de Datos

Null

Comentarios

usua_id

integer

Código secuencial de los usuarios

usua_login

character varying(15)

usua_password

character varying(15)

Contraseña del usuario

usua_nombre

character varying(60)

Nombres del usuario

usua_correo

character varying(100)

Correo electrónico del cliente

usua_tipo

integer

Perfil del usuario

usua_estado

smallint

Estado del usuario

depa_id

integer

Código secuencial de departamentos

Tabla 22: Tabla de usuarios Fuente: Los autores

•

Restricciones Nombre

Tipo

pk_usuarios

PRIMARY KEY

Columna Local usua_id

Tabla 23: Restricciones Tabla usuarios Fuente: Los autores

Tabla Ref.

Columna de Ref.

3. FUNCIONES

3.1 Parametrización Cada función del sistema de control de inventario de activos fijos y bienes comienzan con el prefijo “sp” seguido de un nombre el cual define su funcionamiento.

3.2 Lista de Funciones Lista de las funciones del sistema de control de inventario de activos fijos con su respectiva descripción. N.-

Nombre de la Función

Descripción

sp_eliminar

sp_guardar_categoria

sp_guardar_cliente

sp_guardar_departamento

sp_guardar_orden_ingreso

Funcion que permite guardar ordenes de ingreso.

sp_guardar_orden_pedido

Funcion que permite guardar ordenes de pedido.

sp_guardar_producto

sp_guardar_proveedor

sp_guardar_usuario

Funcion que permite eliminar los registros de las tablas que se puedan eliminar sus datos. Funcion que permite guardar y modificar las categorías de productos Funcion que permite guardar y modificar los registros de los clientes Funcion que permite guardar y modificar los registros de departamentos.

Funcion que permite guardar o modificar los registros de los productos. Funcion que permite guardar y modificar los proveedores.

Funcion que permite guardar y modificar los registros de usuarios. Tabla 24: Lista de Funciones Fuente: Los autores

3.2.1 Función sp_eliminar CÓDIGO CREATE FUNCTION sp_eliminar(tabla character varying, id integer) RETURNS integer AS $BODY$ begin if(tabla = 'clientes')then update clientes set cli_estado=2 where cli_id=id; return 1; end if; if(tabla = 'productos')then update productos set prod_estado=2 where prod_id=id; return 1; end if; if(tabla = 'proveedores')then update proveedores set prov_estado=2 where prov_id=id; return 1; end if; if(tabla = 'usuarios')then update usuarios set usua_estado=2 where usua_id=id; return 1; end if; end; $BODY$

Tabla 25: Función sp_eliminar Fuente: Los autores

3.2.2 Función sp_guardar_categoria CÓDIGO CREATE FUNCTION sp_guardar_categoria(opcion boolean, id integer, nombre character varying) RETURNS integer AS $BODY$ begin if(opcion = '0')then INSERT INTO categorias_producto(cpro_nombre, cpro_estado) VALUES (nombre, 1); return 1; end if; if(opcion = '1')then UPDATE categorias_producto SET cpro_nombre=nombre WHERE cpro_id=id ; return 1; end if; end; $BODY$

Tabla 26: Función sp_guardar_categoria Fuente: Los autores

3.2.3 Función sp_guardar_cliente CÓDIGO CREATE FUNCTION sp_guardar_cliente(opcion boolean, id integer, ruc character varying, nombres character varying, apellidos character varying, telefono1 character varying, correo1 character varying, departamento integer) RETURNS integer AS $BODY$ begin if(opcion = '0')then INSERT INTO clientes(cli_identificacion, cli_nombres, cli_apellidos, cli_telefono, cli_correo, depa_id, cli_estado) VALUES (ruc,nombres,apellidos,telefono1,correo1,departamento,1); return 1; end if; if(opcion = '1')then UPDATE clientes SET cli_identificacion=ruc, cli_nombres=nombres, cli_apellidos=apellidos, cli_telefono=telefono1, cli_correo=correo1, depa_id=departamento WHERE cli_id=id ; return 1; end if; end; $BODY$

Tabla 27: Función sp_guardar_cliente Fuente: Los autores

3.2.4 Función sp_guardar_departamento CÓDIGO CREATE FUNCTION sp_guardar_departamento(opcion boolean, id integer, nombre character varying, descripcion character varying) RETURNS integer AS $BODY$ begin if(opcion = '0')then INSERT INTO departamentos(depa_nombre, depa_descripcion, depa_estado) VALUES (nombre, descripcion, 1); return 1; end if; if(opcion = '1')then UPDATE departamentos SET depa_nombre=nombre, depa_descripcion=descripcion WHERE depa_id=id; return 1; end if; end; $BODY$

Tabla 28: Función sp_guardar_departamento Fuente: Los autores

3.2.5 Función sp_guardar_orden_ingreso CÓDIGO CREATE FUNCTION sp_guardar_orden_ingreso(opcion boolean, idingreso integer, idusuario integer, idproveedor integer, factura character varying, fecha character varying, cur character varying, tipo integer, acta character varying, producto integer[], cantidad integer[], precio double precision[]) RETURNS integer AS $BODY$ DECLARE id_ingreso int; begin if opcion = '0' THEN id_ingreso=nextval('ordenes_ingreso_ingr_id_seq'::regclass); INSERT INTO ordenes_ingreso(ingr_id, usua_id, prov_id, ingr_factura, ingr_fecha, ingr_cur, ingr_tipo,ingr_acta,ingr_estado) VALUES (id_ingreso, idusuario, idproveedor, factura, fecha,cur, tipo,acta, 1); FOR i IN 1..(ARRAY_LENGTH(producto,1)) loop INSERT INTO ingresos_productos(ingrpro_cantidad, prod_id, ingr_id,ingrpro_precio) VALUES (cantidad[i],producto[i], id_ingreso,precio[i]); UPDATE productos set prod_pcp = precio[i] where prod_id = producto[i]; INSERT INTO movimientos_productos(prod_id, pmov_fecha, pmov_cantidad, pmov_tipo, pmov_estado) VALUES (producto[i], current_date, cantidad[i],1,1); end loop; return id_ingreso; END IF; end; $BODY$

Tabla 29: Función sp_guardar_orden_ingreso Fuente: Los autores

3.2.6 Función sp_guardar_orden_pedido CÓDIGO CREATE OR REPLACE FUNCTION sp_guardar_orden_pedido(opcion boolean, idpedido integer, idcliente integer, idusuario integer, fecha_pedido character varying, observaciones character varying, tipopedido integer, acta character varying, producto integer[], cantidad integer[]) RETURNS integer AS $BODY$ DECLARE id_pedido int; begin IF opcion = '0' THEN id_pedido=nextval('pedidos_pedi_id_seq'::regclass); INSERT INTO ordenes_pedido(pedi_id, pedi_cliente, usua_id, pedi_fecha, pedi_observaciones, pedi_tipo,pedi_acta, pedi_estado) VALUES (id_pedido, idcliente, idusuario, fecha_pedido, observaciones, tipopedido,acta, 1); if(array_length(producto, 1)>0)then FOR i IN 1..(ARRAY_LENGTH(producto,1)) loop INSERT INTO pedidos_productos(pedipro_cantidad, prod_id, pedi_id) VALUES (cantidad[i],producto[i], id_pedido ); INSERT INTO movimientos_productos(prod_id, pmov_fecha, pmov_cantidad, pmov_tipo, pmov_estado) VALUES (producto[i], current_date, -cantidad[i],2,1);

end loop; end if; return id_pedido; END IF; IF opcion = '1' THEN update ordenes_pedido set pedi_observaciones=observaciones, pedi_estado=2 where pedi_id=idpedido; if(array_length(producto, 1)>0)then FOR i IN 1..(ARRAY_LENGTH(producto,1)) loop INSERT INTO movimientos_productos(prod_id, pmov_fecha, pmov_cantidad, pmov_tipo, pmov_estado) VALUES (producto[i], current_date, cantidad[i],2,1); end loop; end if; return 1; END IF; end; $BODY$

Tabla 30: Función sp_guardar_orden_pedido Fuente: Los autores

3.2.7 Función sp_guardar_producto CÓDIGO CREATE OR REPLACE FUNCTION sp_guardar_producto(opcion boolean, id_producto integer, id_categoria integer, codigo_pro character varying, nombre_pro character varying, precioc double precision, vidautil integer, custodio character varying, tipo_pro integer, serie character varying, marca character varying, modelo character varying, estructura character varying, color character varying, condicion character varying, ubicacion_pro character varying, cantidad_pro integer) RETURNS integer AS $BODY$ DECLARE id_pro int; begin IF opcion = '0' THEN id_pro=nextval('productos_prod_id_seq'::regclass); INSERT INTO productos(prod_id,prod_categoria, prod_codigo, prod_descripcion, prod_pcp, prod_vidautil, prod_custodio, prod_tipo, prod_serie, prod_marca, prod_modelo, prod_estructura, prod_color, prod_condicion, prod_estado,prod_ubicacion) VALUES (id_pro,id_categoria, codigo_pro, nombre_pro, precioc, vidautil, custodio, tipo_pro, serie, marca, modelo, estructura, color, condicion, 1,ubicacion_pro); INSERT INTO movimientos_productos(prod_id, pmov_fecha, pmov_cantidad, pmov_tipo, pmov_estado) VALUES (id_pro, current_date, cantidad_pro, tipo_pro, 1);

Tabla 31: Función sp_guardar_producto Fuente: Los autores

3.2.8 Función sp_guardar_proveedor CÓDIGO CREATE OR REPLACE FUNCTION sp_guardar_proveedor(opcion boolean, id integer, ruc character varying, nombre character varying, direccion character varying, telefono1 character varying, correo1 character varying, tipo integer) RETURNS integer AS $BODY$ begin if(opcion = '0')then INSERT INTO proveedores(prov_identificacion, prov_nombre, prov_direccion, prov_telefono1, prov_correo1, prov_tipo, prov_estado) VALUES ( ruc, nombre, direccion, telefono1, correo1,tipo, 1); return 1; end if; if(opcion = '1')then UPDATE proveedores SET prov_identificacion=ruc, prov_nombre=nombre, prov_direccion=direccion, prov_telefono1=telefono1, prov_correo1=correo1, prov_tipo = tipo WHERE prov_id=id ; return 1; end if; end; $BODY$

Tabla 32: Función sp_guardar_proveedor Fuente: Los autores

3.2.9 Función sp_guardar_usuario CÓDIGO CREATE OR REPLACE FUNCTION sp_guardar_usuario(opcion boolean, id integer, login character varying, pass character varying, nombres character varying, correo character varying, tipo integer) RETURNS character varying AS $BODY$ begin if(opcion = '0')then INSERT INTO usuarios(usua_login, usua_password, usua_nombre, usua_correo, usua_tipo, usua_estado) VALUES (login,pass,nombres,correo,tipo,1); return 'Datos Ingresados Correctamente'; end if; if(opcion = '1')then UPDATE usuarios SET usua_login=login, usua_password=pass, usua_nombre=nombres, usua_correo=correo, usua_tipo=tipo WHERE usua_id=id;

return 'Datos Modificados Correctamente'; end if;

end; $BODY$

Tabla 33: Funci贸n sp_guardar_usuario Fuente: Los autores

ANEXO 7 Script de la Base de Datos

Script de la Base de Datos

Proyecto: “DESARROLLO

SISTEMA

INFORMÁTICO PARA LA AUTOMATIZACIÓN DEL

CONTROL

INVENTARIO

ACTIVOS FIJOS Y BIENES, UTILIZANDO SOFTWARE

LIBRE,

PARA

UNIDAD

EDUCATIVA DEL “MILENIO MI INUN YA” EN EL CANTÓN SANTO DOMINGO DE LOS COLORADOS. AÑO 2014.”

Script de la Base de Datos -- Database generated with pgModeler (PostgreSQL Database Modeler). -- pgModeler version: 0.7.0 -- PostgreSQL version: 9.3 -- Project Site: pgmodeler.com.br -- Model Author: --SET check_function_bodies = false; -- ddl-end --

-- Database creation must be done outside an multicommand file. -- These commands were put in this file only for convenience. -- -- object: bdd_siciaf | type: DATABASE --- -- DROP DATABASE bdd_siciaf; -- CREATE DATABASE bdd_siciaf -ENCODING = 'UTF8' -LC_COLLATE = 'Spanish_Spain.UTF8' -LC_CTYPE = 'Spanish_Spain.UTF8' -TABLESPACE = pg_default -OWNER = postgres -- ; -- -- ddl-end ---- object: public.sp_consultar | type: FUNCTION --- DROP FUNCTION public.sp_consultar(IN character varying,IN character varying,IN character varying); CREATE FUNCTION public.sp_consultar (IN opcion character varying, IN tipo character varying, IN busqueda character varying) RETURNS SETOF record LANGUAGE plpgsql VOLATILE CALLED ON NULL INPUT SECURITY INVOKER COST 100 ROWS 1000 AS $$ DECLARE tabla record; begin IF opcion = 'guardar' THEN alter sequence orden_tabla restart 1; for tabla in select nextval('orden_tabla') ,prod_codi ,prod_nomb ,prod_cant ,prod_pvp1 ,prod_fela ,prod_fcad ,prod_ubic from productos loop return next tabla; end loop;

END IF; return ; end; $$;

3 ALTER FUNCTION public.sp_consultar(IN character varying,IN character varying,IN character varying) OWNER TO postgres; -- ddl-end --- object: public.sp_guardar_compra | type: FUNCTION --- DROP FUNCTION public.sp_guardar_compra(IN character varying,IN character varying,IN integer,IN integer,IN character varying,IN character varying,IN integer,IN integer,IN integer,IN integer,IN integer); CREATE FUNCTION public.sp_guardar_compra (IN tabla character varying, IN opcion character varying, IN id_compra integer, IN num_factura integer, IN fecha_elab character varying, IN fecha_pago character varying, IN estado_comp integer, IN usuario integer, IN proveedor integer, IN producto integer, IN cantidad integer) RETURNS void LANGUAGE plpgsql VOLATILE CALLED ON NULL INPUT SECURITY INVOKER COST 100 AS $$ DECLARE num numeric; id_compra int; id_bodega int; begin IF tabla = 'productos' THEN IF opcion = 'guardar' THEN id_compra=nextval('compras_comp_codi_seq'::regclass); INSERT INTO compras(comp_codi,comp_nfac, comp_fech, comp_fpag, comp_esta, usua_codi, prov_codi) VALUES (id_compra,num_factura, fecha_elab, fecha_pago,estado_comp, usuario, proveedor); INSERT INTO comproductos(cpro_cant, prod_codi, comp_codi) VALUES (cantidad, producto, id_compra); UPDATE productos SET prod_cant=(prod_cant+cantidad) where prod_codi=producto;

END IF; END IF; IF tabla = 'servicios' THEN IF opcion = 'guardar' THEN id_compra=nextval('compras_comp_codi_seq'::regclass); INSERT INTO compras(comp_codi,comp_nfac, comp_fech, comp_fpag, comp_esta, usua_codi, prov_codi) VALUES (id_compra,num_factura, fecha_elab, fecha_pago,estado_comp, usuario, proveedor); INSERT INTO comservicios(cser_cant, serv_codi, comp_codi) VALUES (cantidad, producto, id_compra); END IF; END IF; return ; end; $$;

4 ALTER FUNCTION public.sp_guardar_compra(IN character varying,IN character varying,IN integer,IN integer,IN character varying,IN character varying,IN integer,IN integer,IN integer,IN integer,IN integer) OWNER TO postgres; -- ddl-end --- object: public.sp_guardar_venta | type: FUNCTION --- DROP FUNCTION public.sp_guardar_venta(IN character varying,IN integer,IN integer,IN integer,IN integer,IN double precision); CREATE FUNCTION public.sp_guardar_venta (IN opcion character varying, IN id_ventaserv integer, IN id_servicio integer, IN id_venta integer, IN cantidad integer, IN precio double precision) RETURNS void LANGUAGE plpgsql VOLATILE CALLED ON NULL INPUT SECURITY INVOKER COST 100 AS $$ DECLARE num numeric; id_pro int; id_bodega int; begin IF opcion = 'guardarServ' THEN INSERT INTO venservicios(serv_codi, vent_codi, vser_cant, vser_prec) VALUES (id_servicio, id_venta, cantidad, precio); END IF; IF opcion = 'guardarProd' THEN INSERT INTO venproductos(prod_codi, vent_codi, vpro_cant, vpro_prec) VALUES (id_servicio, id_venta, cantidad, precio);

UPDATE productos SET prod_cant=prod_cant-cantidad WHERE prod_codi=id_servicio;

END IF; return ; end; $$; ALTER FUNCTION public.sp_guardar_venta(IN character varying,IN integer,IN integer,IN integer,IN integer,IN double precision) OWNER TO postgres; -- ddl-end --- object: public.clientes_cli_id_seq | type: SEQUENCE --- DROP SEQUENCE public.clientes_cli_id_seq; CREATE SEQUENCE public.clientes_cli_id_seq INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START WITH 1 CACHE 1 NO CYCLE OWNED BY NONE; ALTER SEQUENCE public.clientes_cli_id_seq OWNER TO postgres; -- ddl-end --

5 -- object: public.clientes | type: TABLE --- DROP TABLE public.clientes; CREATE TABLE public.clientes( cli_id integer NOT NULL DEFAULT nextval('clientes_cli_id_seq'::regclass), cli_identificacion character varying(13), cli_nombres character varying(50), cli_apellidos character varying(50), cli_telefono character varying(20), cli_correo character varying(100), depa_id integer, cli_estado smallint, CONSTRAINT pk_cli_codi PRIMARY KEY (cli_id) ); -- ddl-end -ALTER TABLE public.clientes OWNER TO postgres; -- ddl-end --- object: public.ordenes_ingreso_ingr_id_seq | type: SEQUENCE --- DROP SEQUENCE public.ordenes_ingreso_ingr_id_seq; CREATE SEQUENCE public.ordenes_ingreso_ingr_id_seq INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START WITH 1 CACHE 1 NO CYCLE OWNED BY NONE; ALTER SEQUENCE public.ordenes_ingreso_ingr_id_seq OWNER TO postgres; -- ddl-end --- object: public.ordenes_ingreso | type: TABLE --- DROP TABLE public.ordenes_ingreso; CREATE TABLE public.ordenes_ingreso( ingr_id integer NOT NULL DEFAULT nextval('ordenes_ingreso_ingr_id_seq'::regclass), usua_id integer NOT NULL, prov_id integer NOT NULL, ingr_factura character varying(20) NOT NULL, ingr_fecha character varying(20) NOT NULL, ingr_cur character varying(20), ingr_tipo smallint, ingr_acta character varying(20), ingr_estado smallint NOT NULL, CONSTRAINT pk_ordenes_ingreso PRIMARY KEY (ingr_id) ); -- ddl-end -COMMENT ON COLUMN public.ordenes_ingreso.ingr_tipo IS 'pueden ser 1:compra, 2:donaciones'; COMMENT ON COLUMN public.ordenes_ingreso.ingr_acta IS 'acta interna para ingreso de bienes y activos'; ALTER TABLE public.ordenes_ingreso OWNER TO postgres; -- ddl-end --- object: public.ingresos_productos_ingrpro_id_seq | type: SEQUENCE --- DROP SEQUENCE public.ingresos_productos_ingrpro_id_seq; CREATE SEQUENCE public.ingresos_productos_ingrpro_id_seq INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START WITH 1 CACHE 1 NO CYCLE OWNED BY NONE;

6 ALTER SEQUENCE public.ingresos_productos_ingrpro_id_seq OWNER TO postgres; -- ddl-end --- object: public.ingresos_productos | type: TABLE --- DROP TABLE public.ingresos_productos; CREATE TABLE public.ingresos_productos( ingrpro_id integer NOT NULL DEFAULT nextval('ingresos_productos_ingrpro_id_seq'::regclass), ingrpro_cantidad integer NOT NULL, prod_id integer NOT NULL, ingr_id integer NOT NULL, ingrpro_precio double precision, CONSTRAINT pk_cpro_codi PRIMARY KEY (ingrpro_id) ); -- ddl-end -COMMENT ON COLUMN public.ingresos_productos.ingrpro_cantidad IS 'cantidad del producto en la orden de ingreso '; COMMENT ON COLUMN public.ingresos_productos.prod_id IS 'id del producto'; COMMENT ON COLUMN public.ingresos_productos.ingr_id IS 'id de la orden de ingreso'; ALTER TABLE public.ingresos_productos OWNER TO postgres; -- ddl-end --- object: public.productos_prod_id_seq | type: SEQUENCE --- DROP SEQUENCE public.productos_prod_id_seq; CREATE SEQUENCE public.productos_prod_id_seq INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START WITH 1 CACHE 1 NO CYCLE OWNED BY NONE; ALTER SEQUENCE public.productos_prod_id_seq OWNER TO postgres; -- ddl-end --- object: public.productos | type: TABLE --- DROP TABLE public.productos; CREATE TABLE public.productos( prod_id integer NOT NULL DEFAULT nextval('productos_prod_id_seq'::regclass), prod_categoria smallint NOT NULL, prod_codigo character varying(50), prod_descripcion character varying(500), prod_pcp numeric(10,2), prod_vidautil smallint, prod_custodio character varying(50), prod_tipo smallint, prod_serie character varying(50), prod_marca character varying(100), prod_modelo character varying(100), prod_estructura character varying(100), prod_color character varying(50), prod_condicion character varying(50), prod_estado smallint NOT NULL, prod_ubicacion character varying(20), CONSTRAINT pk_prod_codi PRIMARY KEY (prod_id) ); -- ddl-end -COMMENT ON COLUMN public.productos.prod_id IS 'id de producto'; COMMENT ON COLUMN public.productos.prod_categoria IS 'categoria a la que pertenece un producto'; COMMENT ON COLUMN public.productos.prod_pcp IS 'precio de compra'; COMMENT ON COLUMN public.productos.prod_vidautil IS 'vida util del producto en a単os';

7 COMMENT ON COLUMN public.productos.prod_custodio IS 'departamento o persona que estara a cargo del bien o acitvo'; COMMENT ON COLUMN public.productos.prod_tipo IS 'Puede ser activo fijo o bien'; COMMENT ON COLUMN public.productos.prod_serie IS 'serie del producto '; COMMENT ON COLUMN public.productos.prod_marca IS 'marca del producto'; COMMENT ON COLUMN public.productos.prod_modelo IS 'model del producto'; COMMENT ON COLUMN public.productos.prod_estructura IS 'Estructura del producto'; COMMENT ON COLUMN public.productos.prod_condicion IS 'condicion en la que se encuentra bueno, malo etc.'; ALTER TABLE public.productos OWNER TO postgres; -- ddl-end --- object: public.proveedores_prov_id_seq | type: SEQUENCE --- DROP SEQUENCE public.proveedores_prov_id_seq; CREATE SEQUENCE public.proveedores_prov_id_seq INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START WITH 1 CACHE 1 NO CYCLE OWNED BY NONE; ALTER SEQUENCE public.proveedores_prov_id_seq OWNER TO postgres; -- ddl-end --- object: public.proveedores | type: TABLE --- DROP TABLE public.proveedores; CREATE TABLE public.proveedores( prov_id integer NOT NULL DEFAULT nextval('proveedores_prov_id_seq'::regclass), prov_identificacion character varying(13), prov_nombre character varying(80), prov_direccion character varying(80), prov_telefono1 character varying(12), prov_correo1 character varying(40), prov_tipo integer, prov_estado smallint, CONSTRAINT pk_prov_codi PRIMARY KEY (prov_id) ); -- ddl-end -ALTER TABLE public.proveedores OWNER TO postgres; -- ddl-end --- object: public.usuarios_usua_id_seq | type: SEQUENCE --- DROP SEQUENCE public.usuarios_usua_id_seq; CREATE SEQUENCE public.usuarios_usua_id_seq INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START WITH 1 CACHE 1 NO CYCLE OWNED BY NONE; ALTER SEQUENCE public.usuarios_usua_id_seq OWNER TO postgres; -- ddl-end --- object: public.usuarios | type: TABLE --- DROP TABLE public.usuarios; CREATE TABLE public.usuarios( usua_id integer NOT NULL DEFAULT nextval('usuarios_usua_id_seq'::regclass), usua_login character varying(15) NOT NULL, usua_password character varying(15) NOT NULL, usua_nombre character varying(60) NOT NULL,

8 usua_correo character varying(100), usua_tipo integer NOT NULL, usua_estado smallint NOT NULL, CONSTRAINT pk_usua_codi PRIMARY KEY (usua_id) ); -- ddl-end -COMMENT ON COLUMN public.usuarios.usua_tipo IS 'Es el perfil de usuario para acceder al sistema'; ALTER TABLE public.usuarios OWNER TO postgres; -- ddl-end --- object: public.pedidos_productos_pedipro_id_seq | type: SEQUENCE --- DROP SEQUENCE public.pedidos_productos_pedipro_id_seq; CREATE SEQUENCE public.pedidos_productos_pedipro_id_seq INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START WITH 1 CACHE 1 NO CYCLE OWNED BY NONE; ALTER SEQUENCE public.pedidos_productos_pedipro_id_seq OWNER TO postgres; -- ddl-end --- object: public.pedidos_productos | type: TABLE --- DROP TABLE public.pedidos_productos; CREATE TABLE public.pedidos_productos( pedipro_id integer NOT NULL DEFAULT nextval('pedidos_productos_pedipro_id_seq'::regclass), pedipro_cantidad integer NOT NULL, prod_id integer NOT NULL, pedi_id integer NOT NULL, pedipro_imagen bytea, CONSTRAINT pk_vpro_codi PRIMARY KEY (pedipro_id) ); -- ddl-end -COMMENT ON COLUMN public.pedidos_productos.pedipro_imagen IS 'Imagen solo para los productos que se dan de baja'; ALTER TABLE public.pedidos_productos OWNER TO postgres; -- ddl-end --- object: public.pedidos_pedi_id_seq | type: SEQUENCE --- DROP SEQUENCE public.pedidos_pedi_id_seq; CREATE SEQUENCE public.pedidos_pedi_id_seq INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START WITH 1 CACHE 1 NO CYCLE OWNED BY NONE; ALTER SEQUENCE public.pedidos_pedi_id_seq OWNER TO postgres; -- ddl-end --- object: public.ordenes_pedido | type: TABLE --- DROP TABLE public.ordenes_pedido; CREATE TABLE public.ordenes_pedido( pedi_id integer NOT NULL DEFAULT nextval('pedidos_pedi_id_seq'::regclass), pedi_cliente integer NOT NULL, usua_id integer NOT NULL, pedi_fecha character varying(20), pedi_observaciones character varying(200),

9 pedi_tipo smallint, pedi_acta character varying(20), pedi_estado smallint NOT NULL, CONSTRAINT pk_vent_codi PRIMARY KEY (pedi_id) ); -- ddl-end -COMMENT ON COLUMN public.ordenes_pedido.pedi_fecha IS 'fecha de entrega del bien'; COMMENT ON COLUMN public.ordenes_pedido.pedi_tipo IS 'tipo de pedido '; COMMENT ON COLUMN public.ordenes_pedido.pedi_acta IS 'acta de salida del pedido'; ALTER TABLE public.ordenes_pedido OWNER TO postgres; -- ddl-end --- object: public.sp_eliminar | type: FUNCTION --- DROP FUNCTION public.sp_eliminar(IN character varying,IN integer); CREATE FUNCTION public.sp_eliminar (IN tabla character varying, IN id integer) RETURNS integer LANGUAGE plpgsql VOLATILE CALLED ON NULL INPUT SECURITY INVOKER COST 100 AS $$ begin if(tabla = 'clientes')then update clientes set cli_estado=2 where cli_id=id; return 1; end if; if(tabla = 'productos')then update productos set prod_estado=2 where prod_id=id; return 1; end if; if(tabla = 'proveedores')then update proveedores set prov_estado=2 where prov_id=id; return 1; end if; if(tabla = 'usuarios')then update usuarios set usua_estado=2 where usua_id=id; return 1; end if; end; $$; ALTER FUNCTION public.sp_eliminar(IN character varying,IN integer) OWNER TO postgres; -- ddl-end --- object: public.movimientos_productos_pmov_id_seq | type: SEQUENCE --- DROP SEQUENCE public.movimientos_productos_pmov_id_seq; CREATE SEQUENCE public.movimientos_productos_pmov_id_seq INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START WITH 1 CACHE 1 NO CYCLE OWNED BY NONE; ALTER SEQUENCE public.movimientos_productos_pmov_id_seq OWNER TO postgres;

10 -- ddl-end --- object: public.movimientos_productos | type: TABLE --- DROP TABLE public.movimientos_productos; CREATE TABLE public.movimientos_productos( pmov_id integer NOT NULL DEFAULT nextval('movimientos_productos_pmov_id_seq'::regclass), prod_id integer, pmov_fecha character varying(10), pmov_cantidad integer, pmov_tipo integer DEFAULT (-1), pmov_estado smallint, CONSTRAINT pk_movimientos PRIMARY KEY (pmov_id) ); -- ddl-end -ALTER TABLE public.movimientos_productos OWNER TO postgres; -- ddl-end --- object: public.categorias_producto_cpro_id_seq | type: SEQUENCE --- DROP SEQUENCE public.categorias_producto_cpro_id_seq; CREATE SEQUENCE public.categorias_producto_cpro_id_seq INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START WITH 1 CACHE 1 NO CYCLE OWNED BY NONE; ALTER SEQUENCE public.categorias_producto_cpro_id_seq OWNER TO postgres; -- ddl-end --- object: public.categorias_producto | type: TABLE --- DROP TABLE public.categorias_producto; CREATE TABLE public.categorias_producto( cpro_id integer NOT NULL DEFAULT nextval('categorias_producto_cpro_id_seq'::regclass), cpro_nombre character varying(100), cpro_estado smallint, CONSTRAINT pk_caracteristicas_producto PRIMARY KEY (cpro_id) ); -- ddl-end -COMMENT ON COLUMN public.categorias_producto.cpro_id IS 'id categoria'; COMMENT ON COLUMN public.categorias_producto.cpro_nombre IS 'nombre de la categoria'; COMMENT ON COLUMN public.categorias_producto.cpro_estado IS 'estado de la categoria'; ALTER TABLE public.categorias_producto OWNER TO postgres; -- ddl-end --- object: public.v_usuarios_todo | type: VIEW --- DROP VIEW public.v_usuarios_todo; CREATE VIEW public.v_usuarios_todo AS SELECT usuarios.usua_id AS id, usuarios.usua_login, usuarios.usua_password, usuarios.usua_nombre, usuarios.usua_correo, usuarios.usua_tipo, usuarios.usua_estado FROM usuarios WHERE (usuarios.usua_estado = 1);; -- ddl-end -ALTER VIEW public.v_usuarios_todo OWNER TO postgres;

11 -- ddl-end --- object: public.v_proveedores_public | type: VIEW --- DROP VIEW public.v_proveedores_public; CREATE VIEW public.v_proveedores_public AS SELECT proveedores.prov_id AS id, proveedores.prov_identificacion AS identificacion, proveedores.prov_nombre AS proveedor, proveedores.prov_direccion AS direccion, proveedores.prov_telefono1 AS telefono FROM proveedores WHERE (proveedores.prov_estado = 1);; -- ddl-end -ALTER VIEW public.v_proveedores_public OWNER TO postgres; -- ddl-end --- object: public.v_proveedores_todo | type: VIEW --- DROP VIEW public.v_proveedores_todo; CREATE VIEW public.v_proveedores_todo AS SELECT proveedores.prov_id AS id, proveedores.prov_identificacion, proveedores.prov_nombre, proveedores.prov_direccion, proveedores.prov_telefono1, proveedores.prov_correo1, proveedores.prov_tipo, proveedores.prov_estado FROM proveedores WHERE (proveedores.prov_estado = 1);; -- ddl-end -ALTER VIEW public.v_proveedores_todo OWNER TO postgres; -- ddl-end --- object: public.departamentos_depa_id_seq | type: SEQUENCE --- DROP SEQUENCE public.departamentos_depa_id_seq; CREATE SEQUENCE public.departamentos_depa_id_seq INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START WITH 1 CACHE 1 NO CYCLE OWNED BY NONE; ALTER SEQUENCE public.departamentos_depa_id_seq OWNER TO postgres; -- ddl-end --- object: public.departamentos | type: TABLE --- DROP TABLE public.departamentos; CREATE TABLE public.departamentos( depa_id integer NOT NULL DEFAULT nextval('departamentos_depa_id_seq'::regclass), depa_nombre character varying(50), depa_descripcion character varying(150), depa_estado smallint, CONSTRAINT pk_depa_id PRIMARY KEY (depa_id) ); -- ddl-end -ALTER TABLE public.departamentos OWNER TO postgres; -- ddl-end --

12 -- object: public.sp_guardar_usuario | type: FUNCTION --- DROP FUNCTION public.sp_guardar_usuario(IN boolean,IN integer,IN character varying,IN character varying,IN character varying,IN character varying,IN integer); CREATE FUNCTION public.sp_guardar_usuario (IN opcion boolean, IN id integer, IN login character varying, IN pass character varying, IN nombres character varying, IN correo character varying, IN tipo integer) RETURNS character varying LANGUAGE plpgsql VOLATILE CALLED ON NULL INPUT SECURITY INVOKER COST 100 AS $$ begin if(opcion = '0')then INSERT INTO usuarios(usua_login, usua_password, usua_nombre, usua_correo, usua_tipo, usua_estado) VALUES (login,pass,nombres,correo,tipo,1); return 'Datos Ingresados Correctamente'; end if; if(opcion = '1')then UPDATE usuarios SET usua_login=login, usua_password=pass, usua_nombre=nombres, usua_correo=correo, usua_tipo=tipo WHERE usua_id=id; return 'Datos Modificados Correctamente'; end if;

end; $$; ALTER FUNCTION public.sp_guardar_usuario(IN boolean,IN integer,IN character varying,IN character varying,IN character varying,IN character varying,IN integer) OWNER TO postgres; -- ddl-end --- object: public.v_usuarios_public | type: VIEW --- DROP VIEW public.v_usuarios_public; CREATE VIEW public.v_usuarios_public AS SELECT usuarios.usua_id AS id, usuarios.usua_login AS "Login", usuarios.usua_nombre AS "Nombres", usuarios.usua_correo AS "Correo" FROM usuarios WHERE (usuarios.usua_estado = 1);; -- ddl-end -ALTER VIEW public.v_usuarios_public OWNER TO postgres; -- ddl-end --- object: public.v_clientes_public | type: VIEW --- DROP VIEW public.v_clientes_public; CREATE VIEW public.v_clientes_public AS SELECT clientes.cli_id AS id,

13 clientes.cli_identificacion AS "Identificaci贸n", clientes.cli_nombres AS "Nombres", clientes.cli_apellidos AS "Apellidos", clientes.cli_telefono AS "Tel茅fono" FROM clientes WHERE (clientes.cli_estado = 1);; -- ddl-end -ALTER VIEW public.v_clientes_public OWNER TO postgres; -- ddl-end --- object: public.v_departamentos_todo | type: VIEW --- DROP VIEW public.v_departamentos_todo; CREATE VIEW public.v_departamentos_todo AS SELECT departamentos.depa_id AS id, departamentos.depa_nombre, departamentos.depa_descripcion, departamentos.depa_estado FROM departamentos;; -- ddl-end -ALTER VIEW public.v_departamentos_todo OWNER TO postgres; -- ddl-end --- object: public.v_departamentos_public | type: VIEW --- DROP VIEW public.v_departamentos_public; CREATE VIEW public.v_departamentos_public AS SELECT departamentos.depa_id AS id, departamentos.depa_nombre AS "Departamento", departamentos.depa_descripcion AS "Descripci贸n" FROM departamentos;; -- ddl-end -ALTER VIEW public.v_departamentos_public OWNER TO postgres; -- ddl-end --- object: public.sp_guardar_cliente | type: FUNCTION --- DROP FUNCTION public.sp_guardar_cliente(IN boolean,IN integer,IN character varying,IN character varying,IN character varying,IN character varying,IN character varying,IN integer); CREATE FUNCTION public.sp_guardar_cliente (IN opcion boolean, IN id integer, IN ruc character varying, IN nombres character varying, IN apellidos character varying, IN telefono1 character varying, IN correo1 character varying, IN departamento integer) RETURNS integer LANGUAGE plpgsql VOLATILE CALLED ON NULL INPUT SECURITY INVOKER COST 100 AS $$ begin if(opcion = '0')then INSERT INTO clientes(cli_identificacion, cli_nombres, cli_apellidos, cli_telefono, cli_correo, depa_id, cli_estado) VALUES (ruc,nombres,apellidos,telefono1,correo1,departamento,1); return 1; end if; if(opcion = '1')then

UPDATE clientes SET cli_identificacion=ruc, cli_nombres=nombres, cli_apellidos=apellidos, cli_telefono=telefono1, cli_correo=correo1, depa_id=departamento WHERE cli_id=id ;

return 1; end if;

end; $$; ALTER FUNCTION public.sp_guardar_cliente(IN boolean,IN integer,IN character varying,IN character varying,IN character varying,IN character varying,IN character varying,IN integer) OWNER TO postgres; -- ddl-end --- object: public.v_clientes_todo | type: VIEW --- DROP VIEW public.v_clientes_todo; CREATE VIEW public.v_clientes_todo AS SELECT clientes.cli_id AS id, clientes.cli_identificacion, clientes.cli_nombres, clientes.cli_apellidos, clientes.depa_id, departamentos.depa_nombre, clientes.cli_correo, clientes.cli_telefono, clientes.cli_estado FROM clientes, departamentos WHERE ((clientes.cli_estado = 1) AND (clientes.depa_id = departamentos.depa_id));; -- ddl-end -ALTER VIEW public.v_clientes_todo OWNER TO postgres; -- ddl-end --- object: public.sp_guardar_proveedor | type: FUNCTION --- DROP FUNCTION public.sp_guardar_proveedor(IN boolean,IN integer,IN character varying,IN character varying,IN character varying,IN character varying,IN character varying,IN integer); CREATE FUNCTION public.sp_guardar_proveedor (IN opcion boolean, IN id integer, IN ruc character varying, IN nombre character varying, IN direccion character varying, IN telefono1 character varying, IN correo1 character varying, IN tipo integer) RETURNS integer LANGUAGE plpgsql VOLATILE CALLED ON NULL INPUT SECURITY INVOKER COST 100 AS $$ begin if(opcion = '0')then INSERT INTO proveedores(prov_identificacion, prov_nombre, prov_direccion, prov_telefono1, prov_correo1, prov_tipo, prov_estado)

15 VALUES ( ruc, nombre, direccion, telefono1, correo1,tipo, 1); return 1; end if; if(opcion = '1')then UPDATE proveedores SET prov_identificacion=ruc, prov_nombre=nombre, prov_direccion=direccion, prov_telefono1=telefono1, prov_correo1=correo1, prov_tipo = tipo WHERE prov_id=id ; return 1; end if; end; $$; ALTER FUNCTION public.sp_guardar_proveedor(IN boolean,IN integer,IN character varying,IN character varying,IN character varying,IN character varying,IN character varying,IN integer) OWNER TO postgres; -- ddl-end --- object: public.sp_guardar_departamento | type: FUNCTION --- DROP FUNCTION public.sp_guardar_departamento(IN boolean,IN integer,IN character varying,IN character varying); CREATE FUNCTION public.sp_guardar_departamento (IN opcion boolean, IN id integer, IN nombre character varying, IN descripcion character varying) RETURNS integer LANGUAGE plpgsql VOLATILE CALLED ON NULL INPUT SECURITY INVOKER COST 100 AS $$ begin if(opcion = '0')then INSERT INTO departamentos(depa_nombre, depa_descripcion, depa_estado) VALUES (nombre, descripcion, 1);

return 1; end if; if(opcion = '1')then UPDATE departamentos SET depa_nombre=nombre, depa_descripcion=descripcion WHERE depa_id=id;

return 1; end if;

end;

16 $$; ALTER FUNCTION public.sp_guardar_departamento(IN boolean,IN integer,IN character varying,IN character varying) OWNER TO postgres; -- ddl-end --- object: public.v_categorias_producto_public | type: VIEW --- DROP VIEW public.v_categorias_producto_public; CREATE VIEW public.v_categorias_producto_public AS SELECT categorias_producto.cpro_id, categorias_producto.cpro_nombre AS "Categoria" FROM categorias_producto;; -- ddl-end -ALTER VIEW public.v_categorias_producto_public OWNER TO postgres; -- ddl-end --- object: public.sp_guardar_categoria | type: FUNCTION --- DROP FUNCTION public.sp_guardar_categoria(IN boolean,IN integer,IN character varying); CREATE FUNCTION public.sp_guardar_categoria (IN opcion boolean, IN id integer, IN nombre character varying) RETURNS integer LANGUAGE plpgsql VOLATILE CALLED ON NULL INPUT SECURITY INVOKER COST 100 AS $$ begin if(opcion = '0')then INSERT INTO categorias_producto(cpro_nombre, cpro_estado) VALUES (nombre, 1);

return 1; end if; if(opcion = '1')then UPDATE categorias_producto SET cpro_nombre=nombre WHERE cpro_id=id ;

return 1; end if;

end; $$; ALTER FUNCTION public.sp_guardar_categoria(IN boolean,IN integer,IN character varying) OWNER TO postgres; -- ddl-end --- object: public.v_categorias_producto_todo | type: VIEW --- DROP VIEW public.v_categorias_producto_todo; CREATE VIEW public.v_categorias_producto_todo AS SELECT categorias_producto.cpro_id AS id, categorias_producto.cpro_nombre, categorias_producto.cpro_estado

17 FROM categorias_producto;; -- ddl-end -ALTER VIEW public.v_categorias_producto_todo OWNER TO postgres; -- ddl-end --- object: public.v_productos_public | type: VIEW --- DROP VIEW public.v_productos_public; CREATE VIEW public.v_productos_public AS SELECT productos.prod_id AS id, productos.prod_descripcion AS "Producto" FROM productos WHERE (productos.prod_estado = 1);; -- ddl-end -ALTER VIEW public.v_productos_public OWNER TO postgres; -- ddl-end --- object: public.v_productos_todo | type: VIEW --- DROP VIEW public.v_productos_todo; CREATE VIEW public.v_productos_todo AS SELECT productos.prod_id AS id, productos.prod_categoria, categorias_producto.cpro_nombre, productos.prod_codigo, productos.prod_descripcion, productos.prod_pcp, productos.prod_vidautil, productos.prod_custodio, productos.prod_tipo, productos.prod_serie, productos.prod_marca, productos.prod_modelo, productos.prod_estructura, productos.prod_color, productos.prod_condicion, ( SELECT sum(movimientos_productos.pmov_cantidad) AS sum FROM movimientos_productos WHERE (movimientos_productos.prod_id = productos.prod_id)) AS sum, productos.prod_ubicacion, productos.prod_estado FROM productos, categorias_producto WHERE ((productos.prod_estado = 1) AND (categorias_producto.cpro_id = productos.prod_categoria));; -- ddl-end -ALTER VIEW public.v_productos_todo OWNER TO postgres; -- ddl-end --- object: public.sp_guardar_producto | type: FUNCTION --- DROP FUNCTION public.sp_guardar_producto(IN boolean,IN integer,IN integer,IN character varying,IN character varying,IN double precision,IN integer,IN character varying,IN integer,IN character varying,IN character varying,IN character varying,IN character varying,IN character varying,IN character varying,IN character varying,IN integer); CREATE FUNCTION public.sp_guardar_producto (IN opcion boolean, IN id_producto integer, IN id_categoria integer, IN codigo_pro character varying, IN nombre_pro character varying, IN precioc double precision, IN vidautil integer, IN custodio character varying, IN tipo_pro integer, IN serie character varying, IN marca character varying, IN modelo character varying, IN estructura character varying, IN color character varying, IN condicion character varying, IN ubicacion_pro character varying, IN cantidad_pro integer) RETURNS integer LANGUAGE plpgsql VOLATILE CALLED ON NULL INPUT

18 SECURITY INVOKER COST 100 AS $$ DECLARE id_pro int; begin IF opcion = '0' THEN id_pro=nextval('productos_prod_id_seq'::regclass); INSERT INTO productos(prod_id,prod_categoria, prod_codigo, prod_descripcion, prod_pcp, prod_vidautil, prod_custodio, prod_tipo, prod_serie, prod_marca, prod_modelo, prod_estructura, prod_color, prod_condicion, prod_estado,prod_ubicacion) VALUES (id_pro,id_categoria, codigo_pro, nombre_pro, precioc, vidautil, custodio, tipo_pro, serie, marca, modelo, estructura, color, condicion, 1,ubicacion_pro); INSERT INTO movimientos_productos(prod_id, pmov_fecha, pmov_cantidad, pmov_tipo, pmov_estado) VALUES (id_pro, current_date, cantidad_pro, tipo_pro, 1);

END IF; IF opcion = '1' THEN UPDATE productos SET prod_categoria=id_categoria, prod_codigo=codigo_pro, prod_descripcion=nombre_pro, prod_pcp=precioc, prod_vidautil=vidautil, prod_custodio=custodio, prod_tipo=tipo_pro, prod_serie=serie, prod_marca=marca, prod_modelo=modelo, prod_estructura=estructura, prod_color=color, prod_condicion=condicion,prod_ubicacion=ubicacion_pro WHERE prod_id=id_producto ; END IF; return 1; end; $$; ALTER FUNCTION public.sp_guardar_producto(IN boolean,IN integer,IN integer,IN character varying,IN character varying,IN double precision,IN integer,IN character varying,IN integer,IN character varying,IN character varying,IN character varying,IN character varying,IN character varying,IN character varying,IN character varying,IN integer) OWNER TO postgres; -- ddl-end --- object: public.sp_guardar_orden_pedido | type: FUNCTION --- DROP FUNCTION public.sp_guardar_orden_pedido(IN boolean,IN integer,IN integer,IN integer,IN character varying,IN character varying,IN integer,IN character varying,IN integer[],IN integer[]); CREATE FUNCTION public.sp_guardar_orden_pedido (IN opcion boolean, IN idpedido integer, IN idcliente integer, IN idusuario integer, IN fecha_pedido character varying, IN observaciones character varying, IN tipopedido integer, IN acta character varying, IN producto integer[], IN cantidad integer[]) RETURNS integer LANGUAGE plpgsql VOLATILE CALLED ON NULL INPUT SECURITY INVOKER COST 100 AS $$ DECLARE id_pedido int; begin IF opcion = '0' THEN

id_pedido=nextval('pedidos_pedi_id_seq'::regclass); INSERT INTO ordenes_pedido(pedi_id, pedi_cliente, usua_id, pedi_fecha, pedi_observaciones, pedi_tipo,pedi_acta, pedi_estado) VALUES (id_pedido, idcliente, idusuario, fecha_pedido, observaciones, tipopedido,acta, 1); if(array_length(producto, 1)>0)then FOR i IN 1..(ARRAY_LENGTH(producto,1)) loop INSERT INTO pedidos_productos(pedipro_cantidad, prod_id, pedi_id) VALUES (cantidad[i],producto[i], id_pedido ); INSERT INTO movimientos_productos(prod_id, pmov_fecha, pmov_cantidad, pmov_tipo, pmov_estado) VALUES (producto[i], current_date, -cantidad[i],2,1);

INSERT INTO movimientos_productos(prod_id, pmov_fecha, pmov_cantidad, pmov_tipo, pmov_estado) VALUES (producto[i], current_date, cantidad[i],2,1); end loop; end if; return 1; END IF;

end; $$; ALTER FUNCTION public.sp_guardar_orden_pedido(IN boolean,IN integer,IN integer,IN integer,IN character varying,IN character varying,IN integer,IN character varying,IN integer[],IN integer[]) OWNER TO postgres; -- ddl-end --- object: public.v_pedidos_public | type: VIEW --- DROP VIEW public.v_pedidos_public; CREATE VIEW public.v_pedidos_public AS SELECT ordenes_pedido.pedi_cliente, ordenes_pedido.pedi_id AS "Pedido", (((clientes.cli_nombres)::text || ' '::text) || (clientes.cli_apellidos)::text) AS "Nombres", ordenes_pedido.pedi_fecha AS "Fecha" FROM (ordenes_pedido JOIN clientes ON ((ordenes_pedido.pedi_cliente = clientes.cli_id))) WHERE ((ordenes_pedido.pedi_tipo = 1) AND (ordenes_pedido.pedi_estado = 1));; -- ddl-end --

20 ALTER VIEW public.v_pedidos_public OWNER TO postgres; -- ddl-end --- object: public.sp_guardar_orden_ingreso | type: FUNCTION --- DROP FUNCTION public.sp_guardar_orden_ingreso(IN boolean,IN integer,IN integer,IN integer,IN character varying,IN character varying,IN character varying,IN integer,IN character varying,IN integer[],IN integer[],IN double precision[]); CREATE FUNCTION public.sp_guardar_orden_ingreso (IN opcion boolean, IN idingreso integer, IN idusuario integer, IN idproveedor integer, IN factura character varying, IN fecha character varying, IN cur character varying, IN tipo integer, IN acta character varying, IN producto integer[], IN cantidad integer[], IN precio double precision[]) RETURNS integer LANGUAGE plpgsql VOLATILE CALLED ON NULL INPUT SECURITY INVOKER COST 100 AS $$ DECLARE id_ingreso int; begin IF opcion = '0' THEN id_ingreso=nextval('ordenes_ingreso_ingr_id_seq'::regclass); INSERT INTO ordenes_ingreso(ingr_id, usua_id, prov_id, ingr_factura, ingr_fecha, ingr_cur, ingr_tipo,ingr_acta,ingr_estado) VALUES (id_ingreso, idusuario, idproveedor, factura, fecha,cur, tipo,acta, 1); FOR i IN 1..(ARRAY_LENGTH(producto,1)) loop INSERT INTO ingresos_productos(ingrpro_cantidad, prod_id, ingr_id,ingrpro_precio) VALUES (cantidad[i],producto[i], id_ingreso,precio[i]); UPDATE productos set prod_pcp = precio[i] where prod_id = producto[i]; INSERT INTO movimientos_productos(prod_id, pmov_fecha, pmov_cantidad, pmov_tipo, pmov_estado) VALUES (producto[i], current_date, cantidad[i],1,1);

end loop; return id_ingreso; END IF;

end; $$; ALTER FUNCTION public.sp_guardar_orden_ingreso(IN boolean,IN integer,IN integer,IN integer,IN character varying,IN character varying,IN character varying,IN integer,IN character varying,IN integer[],IN integer[],IN double precision[]) OWNER TO postgres; -- ddl-end --- object: fk_departamentos_id | type: CONSTRAINT --- ALTER TABLE public.clientes DROP CONSTRAINT fk_departamentos_id; ALTER TABLE public.clientes ADD CONSTRAINT fk_departamentos_id FOREIGN KEY (depa_id) REFERENCES public.departamentos (depa_id) MATCH FULL ON DELETE NO ACTION ON UPDATE NO ACTION; -- ddl-end --

21 -- object: fk_proveedores | type: CONSTRAINT --- ALTER TABLE public.ordenes_ingreso DROP CONSTRAINT fk_proveedores; ALTER TABLE public.ordenes_ingreso ADD CONSTRAINT fk_proveedores FOREIGN KEY (prov_id) REFERENCES public.proveedores (prov_id) MATCH SIMPLE ON DELETE NO ACTION ON UPDATE NO ACTION; -- ddl-end --

-- object: fk_usuarios | type: CONSTRAINT --- ALTER TABLE public.ordenes_ingreso DROP CONSTRAINT fk_usuarios; ALTER TABLE public.ordenes_ingreso ADD CONSTRAINT fk_usuarios FOREIGN KEY (usua_id) REFERENCES public.usuarios (usua_id) MATCH FULL ON DELETE NO ACTION ON UPDATE NO ACTION; -- ddl-end --

-- object: fk_ordenes_ingreso | type: CONSTRAINT --- ALTER TABLE public.ingresos_productos DROP CONSTRAINT fk_ordenes_ingreso; ALTER TABLE public.ingresos_productos ADD CONSTRAINT fk_ordenes_ingreso FOREIGN KEY (ingr_id) REFERENCES public.ordenes_ingreso (ingr_id) MATCH SIMPLE ON DELETE NO ACTION ON UPDATE NO ACTION; -- ddl-end --

-- object: fk_productos | type: CONSTRAINT --- ALTER TABLE public.ingresos_productos DROP CONSTRAINT fk_productos; ALTER TABLE public.ingresos_productos ADD CONSTRAINT fk_productos FOREIGN KEY (prod_id) REFERENCES public.productos (prod_id) MATCH SIMPLE ON DELETE NO ACTION ON UPDATE NO ACTION; -- ddl-end --

-- object: fk_caracteristicas_producto | type: CONSTRAINT --- ALTER TABLE public.productos DROP CONSTRAINT fk_caracteristicas_producto; ALTER TABLE public.productos ADD CONSTRAINT fk_caracteristicas_producto FOREIGN KEY (prod_categoria) REFERENCES public.categorias_producto (cpro_id) MATCH FULL ON DELETE NO ACTION ON UPDATE NO ACTION; -- ddl-end --

-- object: producto_venprod_fk | type: CONSTRAINT --- ALTER TABLE public.pedidos_productos DROP CONSTRAINT producto_venprod_fk; ALTER TABLE public.pedidos_productos ADD CONSTRAINT producto_venprod_fk FOREIGN KEY (prod_id) REFERENCES public.productos (prod_id) MATCH SIMPLE ON DELETE NO ACTION ON UPDATE NO ACTION; -- ddl-end --

-- object: venta_venprod_fk | type: CONSTRAINT --- ALTER TABLE public.pedidos_productos DROP CONSTRAINT venta_venprod_fk; ALTER TABLE public.pedidos_productos ADD CONSTRAINT venta_venprod_fk FOREIGN KEY (pedi_id) REFERENCES public.ordenes_pedido (pedi_id) MATCH SIMPLE ON DELETE NO ACTION ON UPDATE NO ACTION; -- ddl-end --

-- object: fk_clientes | type: CONSTRAINT --- ALTER TABLE public.ordenes_pedido DROP CONSTRAINT fk_clientes; ALTER TABLE public.ordenes_pedido ADD CONSTRAINT fk_clientes FOREIGN KEY (pedi_cliente) REFERENCES public.clientes (cli_id) MATCH FULL ON DELETE NO ACTION ON UPDATE NO ACTION; -- ddl-end --

-- object: fk_usuarios | type: CONSTRAINT --- ALTER TABLE public.ordenes_pedido DROP CONSTRAINT fk_usuarios; ALTER TABLE public.ordenes_pedido ADD CONSTRAINT fk_usuarios FOREIGN KEY (usua_id) REFERENCES public.usuarios (usua_id) MATCH FULL ON DELETE NO ACTION ON UPDATE NO ACTION; -- ddl-end --

-- object: fk_productos_movientos | type: CONSTRAINT --- ALTER TABLE public.movimientos_productos DROP CONSTRAINT fk_productos_movientos; ALTER TABLE public.movimientos_productos ADD CONSTRAINT fk_productos_movientos FOREIGN KEY (prod_id) REFERENCES public.productos (prod_id) MATCH FULL ON DELETE NO ACTION ON UPDATE NO ACTION; -- ddl-end --

ANEXO 8 Manual TĂŠcnico

Manual Técnico del Sistema Proyecto: “DESARROLLO DE UN SISTEMA INFORMÁTICO PARA LA AUTOMATIZACIÓN DEL CONTROL DE INVENTARIO DE ACTIVOS FIJOS Y BIENES, UTILIZANDO SOFTWARE LIBRE, PARA LA UNIDAD EDUCATIVA DEL “MILENIO MI INUN YA” EN EL CANTÓN SANTO DOMINGO DE LOS COLORADOS. AÑO 2014.”

ÍNDICE DE CONTENIDOS

INTRODUCCIÓN ................................................................................................................ 4

REQUERIMIENTOS DEL SISTEMA ................................................................................. 5

2.1 Requisitos para el servidor .................................................................................................... 5 2.2 Requisitos para el cliente ....................................................................................................... 6 3.

INSTALACION DE LA MAQUINA VIRTUAL DE JAVA (JRE) ..................................... 6

INSTALACION DE POSTGRESQL ................................................................................... 9

CONFIGURACIÓN DEL SISTEMA ................................................................................. 15

5.1 CONFIGURACION PARA RESTAURAR LA BASE DE DATOS. ................................ 15 5.2 CONFIGURACIÓN PARA INSTALAR LA APLICACIÓN. ........................................... 19

LISTA DE TABLAS

Tabla 1: Requisitos del servidor .................................................................................................... 5 Tabla 2: Requisitos del cliente ...................................................................................................... 6

MANUAL TÉCNICO DEL SISTEMA 1. INTRODUCCIÓN El presente manual tiene como finalidad servir de guía para conocer la correcta instalación y configuración del Sistema de Control de Inventario de Activos Fijos y Bienes.

Este documento está dirigido al personal técnico de la Unidad Educativa, contiene la instalación y configuración inicial del sistema de control de inventario de activos fijos y bienes, se asume que la persona que lea este manual dispone cumple con los conocimientos necesarios para utilizar el sistema.

Este manual está dividido en 4 secciones principales: •

Requerimientos del sistema: aquí se dan a conocer los requisitos mínimos para la instalación y configuración del sistema respecto a hardware y software.

•

Instalación de la máquina virtual de java (JRE): Se especifica el proceso de instalación para que pueda funcionar la aplicación del sistema.

•

Instalación del motor de base de datos: Se muestra el proceso de instalación del motor de base de datos.

•

Configuración del Sistema y Base de Datos: Se realizan las configuraciones necesarias para que el sistema y la base de datos funcionen correctamente.

2. REQUERIMIENTOS DEL SISTEMA A continuación se detallan los requisitos mínimos que se necesitan para el correcto funcionamiento del sistema.

2.1

Requisitos para el servidor HARDWARE

SOFTWARE

CPU 2Ghz, 2 núcleos Memoria RAM 2Gb Disco duro 80Gb Conexión de red Ethernet 10/100 Mbps 1 puerto USB ó lector de dvd.

Sistema operativo Windows, Centos o compatible PostgreSQL server 9.3 o superior

Tabla 1: Requisitos del servidor Fuente: Los autores

2.2

Requisitos para el cliente HARDWARE

SOFTWARE Máquina Virtual de Java (JRE) jre-7 o superior

CPU 1Ghz Memoria RAM 1GB

Sistema operativo indistinto, en el que se pueda instalar la máquina virtual de java (JRE)

Almacenamiento 100Mb Impresora (Opcional) Conexión de red WiFI 802.11b o Ethernet 10/100 Mbps

Tabla 2: Requisitos del cliente Fuente: Los autores

3. INSTALACION DE LA MAQUINA VIRTUAL DE JAVA (JRE) •

Acceder al Browser o a su navegador de preferencia e ingresar a la siguiente dirección: https://www.java.com/es/download/

•

Dar clic en Dowload para descargar el instalador de JRE.

•

Dar clic en Aceptar e iniciar Descarga.

• Ejecutar el aarchivo ejecutable en nuestro caso descargado a través del navegador.

jre-8u11-windows-i586.exe,

• Si aparece una advertencia de seguridad como la siguiente, se debera indicar que efectivamente se desea “Ejecutar” el archivo. xxxxxxx • Se iniciará el asistente de instalación de JRE: •

Dar clic en Instalar

Tras dar clic en instalar comenzarรก la instalaciรณn del software el cual tardarรก unos segundos.

โ ข

Al finalizar mostrara el siguiente mensaje:

4. INSTALACION DE POSTGRESQL •

Acceder al Browser o a su navegador de preferencia e ingresar a la siguiente dirección: http://www.postgresql.org/download/windows/

•

Dar clic en Dowload para descargar el instalador de PostgreSQL.

•

Escoger de Acuerdo al Sistema Operativo a instalarse el PostgreSQL.

• Ejecutar el fichero ejecutable por ejemplo postgresql-9.3.5-1-windows.exe, descargado a través del navegador.

• Es posible que aparezca una advertencia de seguridad, si aparece habrá que indicar que efectivamente se desea “Ejecutar” el fichero xxxxxxx • Aparecerá la siguiente ventana:

• •

Tras finalizar el proceso de la ventana anterior, aparecerá el asistente de PostgreSQL. Dar clic en Siguiente

Aparecerá una ventana se ingresará la dirección o el directorio de instalación en donde vamos a guardar PostgreSQL. Dar clic en Siguiente

Aparecerá una ventana se ingresará la dirección o el directorio donde se almacenará los datos. Dar clic en Siguiente.

• •

•

Aparecerá una ventana en la que pedirá una contraseña de usuario de PostgreSQL, ingresaremos nuestra contraseña. Dar clic en Siguiente

Aparecerá una ventana en la que pedirá el puerto por donde se comunicara el programa, este aparecerá por default, es el puerto 5432, dejamos el mismo número de puerto. Dar clic en Siguiente

• •

Pedirá cambiar la configuración regional, dejaremos la que da por default. Dar clic en Siguiente

•

Aparecerá una ventana la cual Software. Dar clic en Siguiente

•

indicara que está

listo para instalarse el

โ ข

Comenzarรก la instalaciรณn del software el cual tardarรก unos segundos.

•

aparecerá una venta que indicará que se ha terminado el proceso de instalación de PostgreSQL y dar clic en terminar.

5. CONFIGURACIÓN DEL SISTEMA Una vez instalados todos los programas necesarios se procederá a configurar el sistema y la base de datos.

5.1

CONFIGURACION PARA RESTAURAR LA BASE DE DATOS.

Abrir PostreSQL • • • •

Inicio. Todos los programas. PostgreSQL 9.3 o el que se haya instalado. pgAdmin III

16 Conectarse a las base de datos • •

Clic derecho sobre PostgreSQL 9.3(localhost:5432) Clic izquierdo en Connect

Crear Nueva base de datos en el caso que no exista si ya existe omitimos este paso. • •

Clic derecho sobre Databases Clic izquierdo New Database…

• •

Escribir el nombre de la base de datos siciaf. Clic izquierdo en OK

• •

Cargar la base de datos Clic derecho sobre la base de datos creada (siciaf) Clic izquierdo Restore.

•

Clic izquierdo en

• •

Buscar donde se encuentre el backup de la base de datos llamado bdd_siciaf.backup Clic izquierdo abrir.

•

Por ultimo clic izquierdo en Restore.

â&#x20AC;˘

Finalmente clic izquierdo en Done.

5.2 CONFIGURACIÓN PARA INSTALAR LA APLICACIÓN. •

Copiar la carpeta siciaf en la unidad c:/

Verificar que contenga los siguientes archivos y capetas. • • •

Lib. Reportes SICIAF

Crear acceso directo en el escritorio. • •

Clic derecho sobre SICIAF Enviar al escritorio

Finalmente ejecutamos la aplicación.

ANEXO 9 Manual de Usuario del Sistema

Manual de Usuario del Sistema Proyecto: “DESARROLLO DE UN SISTEMA INFORMÁTICO PARA LA AUTOMATIZACIÓN DEL CONTROL DE INVENTARIO DE ACTIVOS FIJOS Y BIENES, UTILIZANDO SOFTWARE LIBRE, PARA LA UNIDAD EDUCATIVA DEL “MILENIO MI INUN YA” EN EL CANTÓN SANTO DOMINGO DE LOS COLORADOS. AÑO 2014.”

ÍNDICE DE CONTENIDOS

INTRODUCCIÓN ....................................................................................................................... 6

COMPONENTES PRINCIPALES DEL FORMULARIO DEL SISTEMA .............................. 6

MÓDULO DE USUARIOS ...................................................................................................... 10

MÓDULO DE ORDEN DE PEDIDO....................................................................................... 13

5.1. GENERAR ORDEN DE PEDIDO............................................................................................ 15 5.2. DEVOLUCIÓN DEL PEDIDO ................................................................................................ 16 6.

MÓDULO DE ORDEN DE INGRESO .................................................................................... 18

6.1. GENERAR ORDEN DE INGRESO ......................................................................................... 20 7.

MÓDULO DE DEPARTAMENTOS ....................................................................................... 21

MÓDULO DE CATEGORIAS ACTIVOS FIJOS Y BIENES ................................................. 24

MÓDULO DE PERSONAL...................................................................................................... 26

10. MÓDULO DE ACTIVOS FIJOS Y BIENES ........................................................................... 29 11. MÓDULO DE PROVEEDORES .............................................................................................. 33 12. MÓDULO DE REPORTES ...................................................................................................... 36 13. REPORTE DE EXISTENCIA DE ACTIVOS .......................................................................... 38 14. REPORTE DE EXISTENCIA DE BIENES ............................................................................. 39 15. REPORTE DE COMPRAS DE ACTIVOS FIJOS Y BIENES ................................................ 40 16. REPORTE DE ORDENES PEDIDOS ...................................................................................... 41 17. REPORTE DE DONACIONES ................................................................................................ 42 18. REPORTE DE ACTIVOS O BIENES DADOS DE BAJA ...................................................... 43

ÍNDICE DE ILUSTRACIONES

Ilustración 1: Formulario Principal del Sistema .................................................................................. 7 Ilustración 2: Formulario de acceso al Sistema ................................................................................. 10 Ilustración 3: Acceso al Módulo de Usuarios ................................................................................... 11 Ilustración 4: Selección del perfil de Usuario .................................................................................... 11 Ilustración 5: Campos del formulario Usuario .................................................................................. 11 Ilustración 6: Lista de Usuarios ......................................................................................................... 12 Ilustración 7: Modificación de Usuarios ............................................................................................ 12 Ilustración 8: Acceso al Módulo de Orden de Pedido ....................................................................... 13 Ilustración 9: Selección del tipo de Pedido ....................................................................................... 13 Ilustración 10: Campos del formulario Orden de Pedido.................................................................. 14 Ilustración 11: Lista de activos fijos y bienes .................................................................................... 14 Ilustración 12: Lista de la Orden de Pedido ...................................................................................... 14 Ilustración 13: Acceso al Módulo de Orden de Ingreso .................................................................... 18 Ilustración 14: Selección del tipo de Ingreso .................................................................................... 18 Ilustración 15: Campos del formulario Orden de Ingreso ................................................................. 19 Ilustración 16: Lista de activos fijos y bienes .................................................................................... 19 Ilustración 17: Lista de la Orden de Ingreso ...................................................................................... 19 Ilustración 18: Acceso al módulo de Departamentos ....................................................................... 22 Ilustración 19: Módulo Departamentos ............................................................................................ 22 Ilustración 20: Campos del formulario Departamento ..................................................................... 23 Ilustración 21: Lista de Departamentos ............................................................................................ 23 Ilustración 22: Modificación de Departamento ................................................................................ 23

4 Ilustración 23: Acceso a Categorías de Activos Fijos y Bienes........................................................... 24 Ilustración 24: Módulo de Categorías de Activos Fijos y Bienes ....................................................... 24 Ilustración 25: Campos del formulario Categorías ............................................................................ 25 Ilustración 26: Lista de Categorías .................................................................................................... 25 Ilustración 27: Modificación de Categoría ........................................................................................ 26 Ilustración 28: Acceso a Módulo Personal ........................................................................................ 27 Ilustración 29: Selección de Departamento ...................................................................................... 27 Ilustración 30: Validación de Cédula ................................................................................................. 27 Ilustración 31: Campos del formulario Personal ............................................................................... 28 Ilustración 32: Lista del Personal....................................................................................................... 28 Ilustración 33: Modificación de Personal .......................................................................................... 29 Ilustración 34: Acceso al módulo de Activos Fijos y Bienes .............................................................. 30 Ilustración 35: Selección de Activo o Bien......................................................................................... 30 Ilustración 36: Selección de categoría de artículo ............................................................................ 31 Ilustración 37: Campos del formulario Activos Fijos y Bienes ........................................................... 31 Ilustración 38: Lista de activos y bienes ............................................................................................ 32 Ilustración 39: Modificación de activo fijo o bien ............................................................................. 32 Ilustración 40: Acceso al módulo de Proveedores ............................................................................ 33 Ilustración 41: Selección de proveedor público o privado ................................................................ 33 Ilustración 42: Validación de cédula ................................................................................................. 34 Ilustración 43: Campos del formulario Proveedor ............................................................................ 34 Ilustración 44: Lista de Proveedores ................................................................................................. 35 Ilustración 45: Modificación de Proveedor ....................................................................................... 35 Ilustración 46: Acceso al módulo de Reportes .................................................................................. 36

5 Ilustración 47: Selección tipo de Reporte ........................................................................................ 37 Ilustración 48: Fechas de corte ......................................................................................................... 37 Ilustración 49: Reporte de existencia de Activos Fijos ...................................................................... 38 Ilustración 50: Reporte de existencia de Bienes ............................................................................... 39 Ilustración 51: Reporte de compra de activos fijos y bienes ............................................................ 40 Ilustración 52: Reporte de Notas de Pedido pendientes de devolución........................................... 41 Ilustración 53: Reporte de Activos o Bienes Donados ...................................................................... 42 Ilustración 54: Reporte de Activos o Bienes dados de Baja .............................................................. 43

MANUAL DE USUARIO DEL SISTEMA 1. INTRODUCCIÓN El presente manual tiene como finalidad servir de guía para conocer el funcionamiento del sistema de control de inventario de activos fijos y bienes, además para describir las funciones principales de cada uno de sus módulos.

2. COMPONENTES PRINCIPALES DEL FORMULARIO DEL SISTEMA Formulario principal del sistema de donde se tendrá acceso a todas sus funcionalidades.

En la parte lateral izquierda se encuentra el menú principal y en la parte superior se puede observar la barra de menú. •

Orden de Pedido o Módulo de Orden de Pedido. o Módulo de Personal.

•

Inventario o Módulo de Orden de Ingreso. o Módulo de Activos Fijos y Bienes. o Módulo Proveedores.

•

Reportes o Existencia de Activos fijos. o Existencia Bienes. o Compras. o Pedidos. o Donaciones. o Activos Fijos y Bienes Dados de baja.

Ilustración 1: Formulario Principal del Sistema Fuente: Los autores

A CONTINUACIÓN SE DETALLAN LAS FUNCIONES PRINCIPALES DE CADA BOTÓN: Nuevo: Habilita y limpia los campos para el ingreso de nueva información correspondiente a cada módulo. F2 Guardar: Guarda la información ingresa en los campos respectivos de cada módulo o a su vez modifica los datos. F5 Eliminar: Elimina la información del registro seleccionado.

F7 Salir: Cierra el formulario activo o cancela alguna acción.

F12 Cerrar Sistema: Cierra el sistema.

CTRL + F12

8 Cerrar Sesión: Cierra la sesión actual.

CTRL+ L Imprimir: Imprime los reportes según el tipo que se haya elegido.

Acceder al sistema: Permite acceder al sistema.

A CONTINUACIÓN SE DETALLAN LOS MENSAJES PRINCIPALES DEL SISTEMA: Acceso al sistema: Cuando

usuario

pudo

acceder

satisfactoriamente al sistema por medio de su nombre de usuario y contraseña.

Acceso Incorrecto: Cuando el usuario ingresa incorrectamente su usuario o contraseña.

Completar campos obligatorios: Cuando se quiere guardar o modificar y no se ha ingresado toda la información requerida en el respectivo formulario. Ej. Formulario del proveedor.

Información Invalida: Cuando se quiere guardar o modificar y no se ha ingresado correctamente algunos campos como por ejemplo la cedula o el correo.

9 Guardado Correctamente: Cuando toda la información ingresada en los campos está completa y correcta los datos son almacenados.

Eliminado Correctamente: Cuando se ha eliminado algún registro correctamente.

Elegir antes de eliminar: Cuando no se elige algún registro para eliminar.

Stock Insuficiente: Cuando la cantidad del articulo seleccionado es mayor al stock disponible.

3. FORMULARIO DE ACCESO AL SISTEMA Este formulario permite el acceso al sistema SICIAF, solo podrán acceder los usuarios registrados en el sistema por medio de su nombre de usuario y contraseña, los cuales les fueron asignados por el administrador de usuarios.

Para acceder al sistema se debe realizar los siguientes pasos: 1. Ejecutar la aplicación. 2. Ingresar Usuario y Contraseña 3. Clic izquierdo en Acceder!

Ilustración 2: Formulario de acceso al Sistema Fuente: Los autores

4. MÓDULO DE USUARIOS Módulo que permite administrar la información de los usuarios que accederán al sistema.

Para acceder a este módulo se debe realizar los siguientes pasos: 1. Ingresar con un usuario que tenga perfil de Administrador. 2. Clic izquierdo sobre ADMINISTRACIÓN, que se encuentra en el módulo principal del sistema. 3. Dirigirse al submenú de USUARIOS.

Ilustración 3: Acceso al Módulo de Usuarios Fuente: Los autores

DETALLE DE LA FUNCIONALIDAD DEL MÓDULO DE USUARIOS: •

Sirve para asignar un perfil de usuario.

Ilustración 4: Selección del perfil de Usuario Fuente: Los autores

•

Son los campos necesarios para poder registrar un usuario, deben estar ingresados todos para poder almacenar, en caso que no se cuente con la información de algun campo se recomienda asignarle un nombre estandar por ejemplo “sn” que se podria tomar como sin nombre.

Ilustración 5: Campos del formulario Usuario Fuente: Los autores

12 •

Muestra la lista de todos los usuarios que se encuentran registrados en la base de datos del sistema.

Ilustración 6: Lista de Usuarios Fuente: Los autores

•

Haciendo clic izquierdo sobre cualquiera de ellos automáticamente se carga toda la información del registro seleccionado en los campos anteriormente descritos para su modificación correspondiente.

Ilustración 7: Modificación de Usuarios Fuente: Los autores

5. MÓDULO DE ORDEN DE PEDIDO Módulo que permite administrar las ordenes de pedido.

Para acceder a este módulo se debe realizar los siguientes pasos: 1. Ingresar con un usuario que tenga perfil de SECRETARIA. 2. Clic izquierdo sobre ORDEN DE PEDIDO, que se encuentra en el módulo principal del sistema. 3. Dirigirse a la pestaña ORDEN DE PEDIDO.

Ilustración 8: Acceso al Módulo de Orden de Pedido Fuente: Los autores

DETALLE DE LA FUNCIONALIDAD DEL MÓDULO DE ORDEN DE PEDIDO: •

Sirve para seleccionar el tipo de pedido.

Ilustración 9: Selección del tipo de Pedido Fuente: Los autores

14 •

Son los campos necesarios para poder registrar un pedido, deben estar ingresados todos para poder almacenar.

Ilustración 10: Campos del formulario Orden de Pedido Fuente: Los autores

•

Muestra la lista de todos los activos fijos y bienes que se encuentran registrados en la base de datos del sistema.

Ilustración 11: Lista de activos fijos y bienes Fuente: Los autores

•

Muestra la lista de los ítems seleccionados para la orden de pedido.

Ilustración 12: Lista de la Orden de Pedido Fuente: Los autores

15 5.1. GENERAR ORDEN DE PEDIDO El proceso para generar un pedido es el siguiente: 1. Seleccionar el tipo de pedido: a. Préstamo. b. Donación. c. De Baja.

2. Seleccionar la persona responsable haciendo clic izquierdo sobre *Seleccione Personal:

3. Escoja la fecha del pedido.

4. Si tiene alguna observación la escribimos en el campo correspondiente.

5. Ingresar el acta con la cual se registra la orden de pedido.

6. Seleccionar los artículos que se van prestar, donar o dar de baja según sea el caso.

16 7. Guardar.

8. Esperar a que se genere el reporte de la nota de pedido.

5.2. DEVOLUCIĂ&#x201C;N DEL PEDIDO El proceso para devolver un pedido es el siguiente: 1. Clic izquierdo sobre DEVOLUCIONES

2. Elegir la orden de pedido que se requiera devolver.

3. Eliminar los bienes o activos que no serán devueltos utilizando el botón eliminar.

4. Lista de pedido después de haber eliminado los activos o bienes que no se devolverán.

5. Guardar.

6. MÓDULO DE ORDEN DE INGRESO Módulo que permite administrar las ordenes de ingreso.

Para acceder a este módulo se debe realizar los siguientes pasos: 4. Ingresar con un usuario que tenga perfil de SECRETARIA. 5. Clic izquierdo sobre INVENTARIO, que se encuentra en el módulo principal del sistema. 6. Dirigirse a la pestaña ORDEN DE INGRESO.

Ilustración 13: Acceso al Módulo de Orden de Ingreso Fuente: Los autores

DETALLE DE LA FUNCIONALIDAD DEL MÓDULO DE ORDEN DE INGRESO: •

Sirve para seleccionar el tipo de ingreso.

Ilustración 14: Selección del tipo de Ingreso Fuente: Los autores

19 •

Son los campos necesarios para poder registrar un pedido, deben estar ingresados todos para poder almacenar.

Ilustración 15: Campos del formulario Orden de Ingreso Fuente: Los autores

•

Muestra la lista de todos los activos fijos y bienes que se encuentran registrados en la base de datos del sistema.

Ilustración 16: Lista de activos fijos y bienes Fuente: Los autores

•

Muestra la lista de los ítems seleccionados para la orden de pedido.

Ilustración 17: Lista de la Orden de Ingreso Fuente: Los autores

20 6.1. GENERAR ORDEN DE INGRESO El proceso para generar una orden de ingreso es el siguiente: 1. Seleccionar el tipo de ingreso: a. Compra. b. Donación.

2. Seleccionar el proveedor haciendo clic izquierdo sobre *Seleccione Proveedor:

3. Escoja la fecha del ingreso.

4. Ingresar el acta con la cual se registra la orden de ingreso.

5. Seleccionar los artículos que se van comprar o que serán donados según sea el caso.

6. Guardar.

21 7. Esperar a que se genere el reporte de la orden de ingreso.

7. MÓDULO DE DEPARTAMENTOS Módulo que permite administrar los diferentes departamentos a los cuales pertenece el personal.

Para acceder a este módulo se debe realizar los siguientes pasos: 1. Ingresar con un usuario que tenga perfil de Secretaria. 2. Clic izquierdo sobre MANTENIMIENTO, que se encuentra en el módulo principal del sistema. 3. Dirigirse al submenú de DEPARTAMENTOS.

Ilustración 18: Acceso al módulo de Departamentos Fuente: Los autores

Ilustración 19: Módulo Departamentos Fuente: Los autores

DETALLE DE LA FUNCIONALIDAD DEL MÓDULO DE DEPARTAMENTOS: •

Son los campos necesarios para poder registrar un departamento, deben estar ingresados todos los campos para poder almacenar, en caso que no se cuente con la

23 información de algun campo se recomienda asignarle un nombre estandar por ejemplo “sn” que se podria tomar como sin nombre.

Ilustración 20: Campos del formulario Departamento Fuente: Los autores

•

Muestra la lista de todos los departamentos que se encuentran registrados en la base de datos del sistema.

Ilustración 21: Lista de Departamentos Fuente: Los autores

•

Haciendo clic izquierdo sobre cualquiera de ellos automáticamente se carga toda la información del registro seleccionado en los campos anteriormente descritos para su modificación correspondiente.

Ilustración 22: Modificación de Departamento Fuente: Los autores

24 8. MÓDULO DE CATEGORIAS ACTIVOS FIJOS Y BIENES Módulo que permite administrar las diferentes categorías a las cuales pertenece los activos fijos y bienes.

Ilustración 23: Acceso a Categorías de Activos Fijos y Bienes Fuente: Los autores

Ilustración 24: Módulo de Categorías de Activos Fijos y Bienes Fuente: Los autores

25 DETALLE DE LA FUNCIONALIDAD DEL MÓDULO DE CATEGORÍAS: •

Son los campos necesarios para poder registrar una categoria, deben estar ingresados todos los campos para poder registrar.

Ilustración 25: Campos del formulario Categorías Fuente: Los autores

•

Muestra la lista de todas las categorías que se encuentran registrados en la base de datos del sistema.

Ilustración 26: Lista de Categorías Fuente: Los autores

26 •

Haciendo clic izquierdo sobre cualquiera de ellos automáticamente se carga toda la información del registro seleccionado en los campos anteriormente descritos para su modificación correspondiente.

Ilustración 27: Modificación de Categoría Fuente: Los autores

9. MÓDULO DE PERSONAL

Módulo que permite administrar la información del personal.

Para acceder a esta modulo se debe realizar los siguientes pasos: 1. Clic izquierdo sobre ORDEN PEDIDO que se encuentra en el módulo principal del sistema. 2. Dirigirse a la pestaña de PERSONAL.

Ilustración 28: Acceso a Módulo Personal Fuente: Los autores

DETALLE DE LA FUNCIONALIDAD DEL MÓDULO DE PERSONAL: •

Se hace clic izquierdo sobre este campo para poder seleccionar el departamento al cual pertenece el personal, por ejemplo pueden ser: docente, administrativo etc.

Ilustración 29: Selección de Departamento Fuente: Los autores

•

Se puede habilitar haciendo clic izquierdo en caso la cedula o ruc ingresado no sea validado por el sistema o en algún caso sea extranjero.

Ilustración 30: Validación de Cédula Fuente: Los autores

28 •

Son los campos necesarios para poder registrar un proveedor, deben estar ingresados todos para poder registrar, en caso que no se cuente con la información de algun campo se recomienda asignarle un nombre estandar por ejemplo “sn” que se podria tomar como sin nombre.

Ilustración 31: Campos del formulario Personal Fuente: Los autores

•

Muestra la lista de todo el personal que se encuentran registrados en la base de datos del sistema.

Ilustración 32: Lista del Personal Fuente: Los autores

29 •

Haciendo clic izquierdo sobre cualquiera de ellos automáticamente se carga toda la información del registro seleccionado en los campos anteriormente descritos para su modificación correspondiente.

Ilustración 33: Modificación de Personal Fuente: Los autores

10. MÓDULO DE ACTIVOS FIJOS Y BIENES

Módulo que permite administrar la información de los activos fijos y bienes.

Para acceder a esta modulo se debe realizar los siguientes pasos: 1. Clic izquierdo sobre INVENTARIO que se encuentra en el módulo principal del sistema. 2. Dirigirse a la pestaña de ACTIVOS FIJOS Y BIENES.

Ilustración 34: Acceso al módulo de Activos Fijos y Bienes Fuente: Los autores

DETALLE DE LA FUNCIONALIDAD DEL MÓDULO DE ACTIVOS FIJOS Y BIENES: •

Identifica si el artículo ingresado es un bien o un activo fijo, estoy ayuda para su posterior reporte.

Ilustración 35: Selección de Activo o Bien Fuente: Los autores

31 •

Se hace clic izquierdo sobre este campo para poder seleccionar la categoría a la que pertenece el artículo, por ejemplo pueden ser: suministros de oficina, de limpieza etc.

Ilustración 36: Selección de categoría de artículo Fuente: Los autores

•

Son los campos necesarios para poder registrar un articulo, deben estar ingresados todos para poder registrar, en caso que no se cuente con la información de algun campo se recomienda asignarle un nombre estandar por ejemplo “sn” que se podria tomar como sin nombre.

Ilustración 37: Campos del formulario Activos Fijos y Bienes Fuente: Los autores

32 •

Muestra la lista de todos los activos fijos y bienes que se encuentran registrados en la base de datos del sistema.

Ilustración 38: Lista de activos y bienes Fuente: Los autores

•

Haciendo clic izquierdo sobre cualquiera de ellos automáticamente se carga toda la información del artículo seleccionado en los campos anteriormente descritos para su modificación correspondiente.

Ilustración 39: Modificación de activo fijo o bien Fuente: Los autores

33 11. MÓDULO DE PROVEEDORES

Módulo que permite administrar la información de los proveedores.

Para acceder a esta modulo se debe realizar los siguientes pasos: 1. Clic izquierdo sobre INVENTARIO que se encuentra en el módulo principal del sistema. 2. Dirigirse a la pestaña de PROVEEDORES.

Ilustración 40: Acceso al módulo de Proveedores Fuente: Los autores

DETALLE DE LA FUNCIONALIDAD DEL MÓDULO DE PROVEEDORES: •

Identifica si el proveedor es público o privado.

Ilustración 41: Selección de proveedor público o privado Fuente: Los autores

34 •

Se puede habilitar haciendo clic izquierdo en caso la cedula o ruc ingresado no sea validado por el sistema o en algún caso se extranjero.

Ilustración 42: Validación de cédula Fuente: Los autores

•

Ilustración 43: Campos del formulario Proveedor Fuente: Los autores

•

Muestra la lista de todos los proveedores que se encuentran registrados en la base de datos del sistema.

Ilustración 44: Lista de Proveedores Fuente: Los autores

•

Haciendo clic izquierdo sobre cualquiera de ellos automáticamente se carga toda la información del registro seleccionado en los campos anteriormente descritos para su modificación correspondiente.

Ilustración 45: Modificación de Proveedor Fuente: Los autores

36 12. MÓDULO DE REPORTES

Módulo que permite generar los diferentes reportes.

Para acceder a esta modulo se debe realizar los siguientes pasos: 1. Clic izquierdo sobre REPORTES que se encuentra en el módulo principal del sistema.

Ilustración 46: Acceso al módulo de Reportes Fuente: Los autores

DETALLE DE LA FUNCIONALIDAD DEL MÓDULO DE REPORTES: •

Sirve para seleccionar el tipo de reporte, el cual pude ser: o

Existencia de Activos.

Existencia de Bienes.

Por fecha de Compra.

Por fecha de Pedido.

Donaciones.

Activos y Bienes dados de Baja.

Ilustraciรณn 47: Selecciรณn tipo de Reporte Fuente: Los autores

โ ข

Sirve para escoger la fecha de inicio y fecha corte para los reportes: o

Por fecha de Compra.

Por fecha de Pedido.

Donaciones.

De Baja.

Ilustraciรณn 48: Fechas de corte Fuente: Los autores

38 13. REPORTE DE EXISTENCIA DE ACTIVOS En el siguiente reporte se muestra la informaci贸n de la existencia de los activos fijos que se encuentran almacenados dentro de la base de datos, permitiendo saber el stock con el que cuenta actualmente el inventario.

Ilustraci贸n 49: Reporte de existencia de Activos Fijos Fuente: Los autores

39 14. REPORTE DE EXISTENCIA DE BIENES En el siguiente reporte se muestra la informaci贸n de la existencia de los bienes que se encuentran almacenados dentro de la base de datos, permitiendo saber el stock con el que cuenta actualmente el inventario.

Ilustraci贸n 50: Reporte de existencia de Bienes Fuente: Los autores

40 15. REPORTE DE COMPRAS DE ACTIVOS FIJOS Y BIENES En el siguiente reporte se muestra la informaci贸n de las compras de los activos fijos y bienes que se encuentran almacenados dentro de la base de datos, permitiendo saber qu茅 es lo que se ha comprado y en qu茅 fecha.

Ilustraci贸n 51: Reporte de compra de activos fijos y bienes Fuente: Los autores

41 16. REPORTE DE ORDENES PEDIDOS En el siguiente reporte se muestra la informaciรณn de la las ordenes de pedido que estรกn pendientes de devoluciรณn.

Ilustraciรณn 52: Reporte de Notas de Pedido pendientes de devoluciรณn Fuente: Los autores

42 17. REPORTE DE DONACIONES En el siguiente reporte se muestra la informaci贸n de las donaciones realizadas a diferentes instituciones u organismos.

Ilustraci贸n 53: Reporte de Activos o Bienes Donados Fuente: Los autores

43 18. REPORTE DE ACTIVOS O BIENES DADOS DE BAJA En el siguiente reporte se muestra la informaci贸n de los activos fijos o bienes dados de baja.

Ilustraci贸n 54: Reporte de Activos o Bienes dados de Baja Fuente: Los autores

ANEXO 10 Carta de Impacto

ANEXO 11 Acta de Entrega – Recepción