UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE … · BOMBEROS DEL DISTRITO METROPOLITANO DE QUITO, autorizo a la Universidad Central del Ecuador hacer uso de todos los contenidos que

UNIVERSIDAD CENTRAL DEL ECUADOR

FACULTAD DE INGIENIERÍA CIENCIAS FÍSICAS Y MATEMÁTICA

CARRERA DE INGENIERÍA INFORMÁTICA

IMPLEMENTACIÓN DE UN SISTEMA DE INVENTARIO DE EQUIPOS

TECNOLÓGICOS PARA LA DIRECCIÓN DE TECNOLOGÍA DEL CUERPO DE

BOMBEROS DEL DISTRITO METROPOLITANO DE QUITO

TRABAJO DE GRADUACIÓN PREVIO A LA OBTENCIÓN DEL TÍTULO DE

INGENIERO INFORMÁTICO

AUTOR: MARTHA VIVIANA VISCARRA PÁEZ

TUTOR: ING. RENÉ ALFONSO CARRILLO FLORES

QUITO, 14 Septiembre

2016

ii

DEDICATORIA

Al creador de todas las cosas, el que me ha dado la fortaleza para continuar cuando a

punto de caer he estado, por ello, con toda la humildad que de mi corazón puede

emanar, dedico primeramente mi trabajo a Dios.

A mis padres, porque ellos siempre estuvieron a mi lado brindándome su apoyo y sus

consejos para hacer de mí una mejor persona.

A mis hermanos, cuñada y sobrinas por el apoyo que siempre me brindaron día a día en

el transcurso de cada año de mi carrera universitaria.

A mi esposo por sus palabras, su apoyo y su confianza, por su amor y por brindarme el

tiempo necesario para realizarme profesionalmente.

A mis amigos, compañeros, y todas aquellas personas que de una u otra manera han

contribuido para el logro de mis objetivos.

iii

AGRADECIMIENTOS

A Dios, por permitirme llegar a este momento tan especial en mi vida, por protegerme

durante todo mi camino y darme fuerzas para superar los obstáculos y dificultades a lo

largo de toda mi vida. Por los triunfos y los momentos difíciles que me han enseñado a

valorarlo cada día más.

A mis padres por su lucha constante y su amor latente todo el tiempo, por cada palabra

y cada gesto de cariño y orgullo que han guiado los pasos a lo largo de mi vida, por

impulsarme con valor y amor para tomar decisiones, por los sacrificios que juntos

hemos pasado y por ser los mejores padres del mundo.

A mis hermanos, cuñada y sobrinas quienes con sus palabras de aliento no me dejaban

decaer para que siguiera adelante y siempre fuera perseverante y cumpliera mis metas.

A mi amado esposo quien me brindó su amor, su cariño, su estímulo y su apoyo

constante. Su cariño, comprensión y paciente espera para que pudiera terminar el

presente trabajo son evidencia de su gran amor.

A mis compañeros y amigos presentes y pasados, quienes sin esperar nada a cambio

compartieron su conocimiento, alegrías y tristezas y a todas aquellas personas que

durante este tiempo estuvieron a mi lado apoyándome y lograron que este sueño se haga

realidad.

iv

AUTORIZACIÓN DE LA AUTORIA INTELECTUAL

Yo, Martha Viviana Viscarra Páez en calidad de autor del trabajo de integración:


TECNOLOGICOS PARA LA DIRECCIÓN DE TECNOLOGIA EL CUERPO DE

BOMBEROS DEL DISTRITO METROPOLITANO DE QUITO, autorizo a la

Universidad Central del Ecuador hacer uso de todos los contenidos que me pertenecen o

parte de los que contiene esta obra, con fines estrictamente académicos o de

investigación.

Los derechos que como autor me corresponden, con excepción de la presente

autorización, seguirán vigentes a mi favor, de conformidad con lo establecido en los

artículos 5, 6, 8; 19 y demás pertinentes de la Ley de Propiedad Intelectual y su

Reglamento.

Asimismo, autorizo a la Universidad Central del Ecuador para que realice la

digitalización y publicación de este trabajo de investigación en el repositorio virtual,

de conformidad a lo dispuesto en el Art. 144 de la Ley Orgánica de Educación

Superior.

Quito, 28/Abril/2016

v

CERTIFICACIÓN DEL TUTOR

Yo, CARRILLO FLORES RENÉ ALFONSO en calidad de tutor del trabajo de

titulación IMPLEMENTACIÓN DE UN SISTEMA DE INVENTARIO DE

EQUIPOS TECNOLÓGICOS PARA LA DIRECCIÓN DE TECNOLOGÍA DEL

CUERPO DE BOMBEROS DEL DISTRITO METROPOLITANO DE QUITO,

elaborado por el estudiante VISCARRA PAÉZ MARTHA VIVIANA, de la Carrera

de Ingeniería Informática, Facultad de Ingeniería, Ciencias Físicas y Matemáticas de la

Universidad Central del Ecuador, considero que el mismo reúne los requisitos y méritos

necesarios en el campo metodológico y en el campo epistemológico, para ser sometido a

la evaluación por parte del jurado examinador que se designe, por lo que lo APRUEBO,

a fin de que el trabajo investigativo sea habilitado para continuar con el proceso de

titulación determinado por la Universidad Central del Ecuador.

En la ciudad de Quito, a los 12 días del mes de abril del 2016

vi

APROBACIÓN DE REVISORES

vii

viii

CONTENIDO

………………………………………………………………………………………pág.

DEDICATORIA ............................................................................................................................... ii

AGRADECIMIENTOS .................................................................................................................... iii

AUTORIZACIÓN DE LA AUTORIA INTELECTUAL ........................................................................... iv

APROBACIÓN DEL TUTOR DEL TRABAJO DE TITULACIÓN ............................................................. v

APROBACIÓN DE REVISORES ....................................................................................................... vi

LISTA DE FIGURAS ........................................................................................................................ x

LISTA DE TABLAS ......................................................................................................................... xi

RESÚMEN .................................................................................................................................. xiii

ABSTRACT.................................................................................................................................. xiv

1. MARCO TEORÍCO ...................................................................................................................... 3

1.1 Antecedentes ............................................................................................................... 3

1.2 Marco Teórico ............................................................................................................ 3

1.3 Metodologías Tradicionales ............................................................................................... 4

1.3.1 Principales Metodologías Tradicionales ...................................................................... 5

1.3.2 Principales metodologías ágiles................................................................................... 7

1.4 Diferencia entre metodologías tradicionales y agiles ......................................................... 9

2. METODOLOGÍA .................................................................................................................. 11

2.1 Metodología para el desarrollo del Proyecto ............................................................... 11

2.1.1 Elementos de Scrum ............................................................................................... 11

2.1.2 Aspectos interesantes de Scrum ............................................................................... 15

2.1.3 Fases de la Metodología Scrum ................................................................................ 16

2.2 Herramientas ................................................................................................................... 17

2.2.1 Recopilación de la información ................................................................................. 17

2.2.2 Entrevistas ................................................................................................................. 17

2.2.3 Documentos de registros de equipos que utiliza la unidad de informática ............... 17

2.2.4 Casos de Uso ............................................................................................................. 17

ix

2.2.5 Diagrama de Entidad Relación ................................................................................... 18

2.2.6 Plataforma JEE ........................................................................................................... 19

2.2.7 Java Server Faces (JSF) ............................................................................................... 20

2.2.8 JSF - Managed Beans ................................................................................................. 22

2.2.9 GlassFish .................................................................................................................... 23

2.2.10 Postgres .................................................................................................................. 24

3. DESARROLLO DE LA PROPUESTA .......................................................................................... 26

3.1Planificación .................................................................................................................... 26

3.1.1 Análisis de procesos .................................................................................................. 26

3.1.2 Modalidad de la investigación ................................................................................... 26

3.1.3 Recolección de la información................................................................................... 26

3.1.4 Procesamiento y análisis de la información............................................................... 26

3.1.5 Alcance del Software ............................................................................................... 29

3.1.6 Generación del Product Backlog................................................................................ 30

3.1.7 Historias de usuarios ............................................................................................... 30

3.1.8 Definición del Backlog del producto .......................................................................... 34

3.1.9 Diseño ....................................................................................................................... 35

3.1.10 Sprint 1 “Módulo de administración de usuarios”.............................................. 36

3.1.11 Sprint 2 “Modulo de autenticación” ........................................................................ 40

3.1.12 Sprint 3 “Módulo de Gestión” ................................................................................. 45

3.1.13 Sprint 4 “Módulo de Reportes” ............................................................................... 49

3.2 Diseño de la base de datos ............................................................................................... 53

3.2.1 Diseño Físico .............................................................................................................. 53

3.3 Diccionario de datos ......................................................................................................... 53

3.3.1 Perfil del usuario ....................................................................................................... 54

3.3.2 Usuario ...................................................................................................................... 54

3.3.3 Item ........................................................................................................................... 55

3.3.4 Tipo Ítem ................................................................................................................... 55

3.3.5 Marcas ...................................................................................................................... 55

3.3.6 Estado ........................................................................................................................ 56

3.3.7 Auditoría.................................................................................................................... 56

5. RECOMENDACIONES .............................................................................................................. 58

6. BIBLIOGRAFIA ......................................................................................................................... 59

x

LISTA DE FIGURAS

……………………………………………………………………………………………

………………………………………………………………………………………..pág.

Figura 1 Esquema general de las tecnologías web........................................................................ 4

Figura 2 Rational Unified Process ................................................................................................ 6

Figura 3 Microsoft Solution Framework ...................................................................................... 7

Figura 4 Scrum ............................................................................................................................. 8

Figura 5 Extreme Programming ................................................................................................... 9

Figura 6 Elementos de Scrum .................................................................................................... 11

Figura 7 Roles de Scrum ............................................................................................................ 13

Figura 8 Artefactos de Scrum ..................................................................................................... 13

Figura 9 Roles, artefactos y reuniones de Scrum ........................................................................ 15

Figura 10 Etapas de Scrum......................................................................................................... 16

Figura 11 Ejemplo de Diagrama Entidad Relación .................................................................... 19

Figura 12 Ciclo de vida de jsf .................................................................................................... 22

Figura 13 JSF - Managed Beans................................................................................................. 23

Figura 14 Arquitectura del servidor GlassFish ........................................................................... 24

Figura 15 Arquitectura de PostgreSQL ...................................................................................... 25

Figura 16 Escala importancia definida por Product Owner. ....................................................... 35

Figura 17 Arquitectura de la aplicación web del sistema de inventarios de equipos tecnológicos.

................................................................................................................................................... 35

Figura 18 Casos de uso- Modulo de administración de usuario ................................................. 38

Figura 19 Casos de uso- Módulo de autenticación ..................................................................... 42

Figura 20 Caso de uso –Modulo de gestión................................................................................ 46

Figura 21 Caso de uso –Modulo de reportes .............................................................................. 51

Figura 22 Base de datos que se utilizará en el desarrollo de la aplicación web .......................... 53

xi

LISTA DE TABLAS

……………………………………………………………………………………………

……………………………………………………………………………………….pág

Tabla 1 Diferencias entre metodologías tradicionales y ágiles ................................................... 10

Tabla 2 Formato de Casos de uso ............................................................................................... 18

Tabla 3 Requerimientos Funcionales/No funcionales ................................................................ 28

Tabla 4 Historia de usuario1 ...................................................................................................... 30

Tabla 5 Historia de usuario 2 ..................................................................................................... 30





Tabla 10 Historia de usuario 7 ................................................................................................... 32



Tabla 13 Historia de usuario 10.................................................................................................. 33

Tabla 14 Historia de usuario 11.................................................................................................. 33

Tabla 15 Backlog producto ........................................................................................................ 34

Tabla 16 Requerimientos Funcionales/No Funcionales del Sprint 1 .......................................... 36

Tabla 17 Historia de usuario – Sprint 1 ...................................................................................... 37

Tabla 18 Equipo de trabajo ........................................................................................................ 37

Tabla 19 Especificación del caso de uso: módulo de administración de usuario y perfiles ........ 38

Tabla 20 20 Backlog Sprint Modulo de Administración ............................................................ 39

Tabla 21 Requerimientos Funcionales/No Funcionales – Sprint 2 ............................................. 41

Tabla 22 Historia de usuario- sprint 2 ........................................................................................ 41

Tabla 23 Especificación del caso de uso: módulo de autenticación............................................ 42

Tabla 24 Backlog Sprint Modulo de Autenticación ................................................................... 43

Tabla 25 Requerimientos Funcionales/No Funcionales – Sprint 3 ............................................. 45


Tabla 27 Especificación del caso de uso: Módulo de gestión ..................................................... 47

Tabla 28 Backlog Sprint Modulo de Gestión ............................................................................. 48

xii

Tabla 29 Requerimientos Funcionales/No Funcionales del Sprint 4 .......................................... 49


Tabla 31 Especificación del caso de uso: Módulo de reportes ................................................... 51

Tabla 32 Backlog Sprint Modulo de Autenticación ................................................................... 52

Tabla 33 Diccionario de datos perfil del usuario ........................................................................ 54

Tabla 34 Diccionario de datos perfil del usuario ........................................................................ 54

Tabla 35 Diccionario de datos ítem ............................................................................................ 55

Tabla 36 Diccionario de datos tipo ítem ..................................................................................... 55

Tabla 37 Diccionario de datos marca ......................................................................................... 55

Tabla 38 Diccionario de datos estado ......................................................................................... 56

Tabla 39 Diccionario de datos auditoría ..................................................................................... 56

xiii

RESÚMEN


TECNOLÓGICOS PARA LA DIRECCIÓN DE TECNOLOGÍA DEL CUERPO DE

BOMBEROS DEL DISTRITO METROPOLITANO DE QUITO

Autor: Martha Viviana Viscarra Páez

Tutor: René Alfonso Carrillo Flores

La Dirección de Tecnología y Comunicaciones del Cuerpo de Bomberos del Distrito

Metropolitano de Quito con el afán de mejorar los procesos de administración

de inventarios, busca un soporte informático de calidad para el manejo ágil,

adecuado y sencillo de la información a través del desarrollo de soluciones tecnológicas

innovadoras. El desarrollo de software busca la rapidez, calidad y mejora continua;

estas características son el fundamento de las metodologías ágiles de desarrollo.

El diseño y desarrollo de software exige cumplir con los parámetros especificados en

los requerimientos, cumpliendo con los procesos de una metodología probada y

garantizada se puede tener un producto de calidad que satisfaga las necesidades del

cliente y cumpla con parámetros de calidad de software

El presente estudio está orientado en el análisis del método ágil Scrum para la

implementación de una aplicación web para el control de inventario.

El resultado es un producto de software funcional, en cuyo desarrollo se pudo demostrar

la validez de SCRUM aplicado a proyectos de software de mediano tamaño, en entornos

cambiantes con grupos de trabajo pequeños que involucran permanentemente al dueño

del producto.

PALABRAS CLAVES: APLICACIÓN WEB/JAVA PARA NETBEANS/GENERADOR DE

CODIGO WEB / METODOLOGIA SCRUM / BASE DE DATOS POSTGRES /SERVIDOR

GLASSFISH

xiv

ABSTRACT

IMPLEMENTATION OF AN INVENTORY SYSTEM OF TECHNOLOGICAL

EQUIPMENT FOR THE TECHNOLOGY DIRECTION OF THE FIRE

DEPARTAMENT OF THE METROPOLITAN DISTRICT OF QUITO.

Author: Martha Viviana Viscarra Páez

Tutor: René Alfonso Carrillo Flores

The Direction of Technology and Communications of the Fire Department of the

Metropolitan District of Quito in order improve the inventory management processes,

looking for a computer support of quality for agile, appropriate and simple management

of information through the development of innovative technological solutions. The

development of software search for the speed, quality and continuous improvement;

these characteristics are the basis of agile methodologies of development.

The design and development of software has to meet with the specified parameters in

the requirements, complying with a proven and guaranteed methodology processes it is

possible to have a quality product that satisfies the customer needs and meets with

parameters of software quality.

This study is guided to the analysis of the Scrum agile methodology for the

implementation of an application web for the inventory control.

The result is a product of functional software, in whose development the validity of

SCRUM applied to medium-sized software projects, in changing environments with

small working groups involving permanently to the owner of the product could be

demonstrated.

KEYWORDS: WEB APPLICATION / JAVA FOR NETBEANS / WEB CODE

GENERATOR / SCRUM METHODOLOGY / POSTGREST DATABASE / GLASSFISH

SERVER

1

INTRODUCCIÒN

Las aplicaciones informáticas presentes en las organizaciones evolucionan

incesantemente adaptándose a los nuevos requerimientos y a las tecnologías de la

información, estas implican la utilización de las actuales mejoras tecnológicas; el

manejo y control de la información ha permitido que los usuarios manifiesten un grado

de aceptación por estos sistemas de gestión, los cuales representan el medio eficaz para

agilizar los procedimientos desarrollando una mayor productividad en la empresa.

Actualmente existen empresas de desarrollo de software que ofrecen una gran cantidad

de programas en todos los ámbitos; debido a que no todos los negocios son iguales, las

empresas ven la necesidad de tener un software que se acople a sus necesidades.

La Dirección de Tecnología y Comunicaciones del Cuerpo de Bomberos del Distrito

Metropolitano de Quito no dispone de una aplicación web que automatice el control de

los equipos informáticos asignados a los diferentes funcionarios de la institución; con

esta información el personal de la unidad de informática realiza diariamente su trabajo

prestando soporte a las incidencias que se presentan diariamente.

Mensualmente se realiza un inventario manual de los equipos que se encuentran

asignados a los diferentes usuarios; esta información se la recopila en un archivo en

Excel. Se corre el riesgo de perder dicha información por varios factores, por ejemplo

cerrar el archivo sin guardar los cambios, el servidor donde se encuentra guardado el

archivo se dañe, se borre el archivo accidentalmente, etc., lo que puede provocar que la

información se pierda o se corrompa.

Con esta aplicación se pretende optimizar dicho proceso, permitiendo al personal de la

unidad de informática registrar de manera ágil y eficaz la información de equipos , los

usuarios asignados, la dirección a la que pertenecen, obtener informes parametrizables,

evitar pérdida y redundancia de la información.

En este sentido, el objetivo general es desarrollar e implementar un sistema de gestión

de manejo de inventario de equipos informáticos para el Cuerpo de Bomberos del

Distrito Metropolitano de Quito.

2

Los objetivos específicos son identificar el equipo informático para registrarlo, crear

una base de datos para registrar los equipos, definir la interface visual para el registro,

procesamiento y presentación de la información y determinar el administrador,

especialistas para la aplicación y realizar la inducción para el manejo del sistema de

gestión.

La creación de la aplicación implicara llevar a cabo las siguientes funciones: Respaldo

de información, ordenes de trabajo, validación y carga de datos. Se hará un proceso de

carga de los datos en la base que consultará la aplicación, este proceso se realizará

inicialmente de forma manual y luego será gestionado por la aplicación.

El acceso a la información estaría conformado por el análisis de datos mediante

funcionalidades específicas, realización de informes predefinidos o personalizados por

el usuario en función de diferentes parámetros, acceso a la información a través del

navegador web.

3

1. MARCO TEORÍCO

1.1 Antecedentes

El control del inventario se ha convertido en una actividad complicada de realizar

debido a la cantidad de equipos presentes en la institución y más aún con sistemas

manuales.

Actualmente existen soluciones de gestión del inventario que permiten la

automatización de la recopilación de datos para mantener un mejor control sobre ellos,

saber qué cantidad se dispone e identificar cada uno de los equipos informáticos.

El desarrollo de la aplicación para la Dirección de Tecnología y Comunicaciones del

Cuerpo de Bomberos del Distrito Metropolitano de Quito integra en el sistema el

proceso de negocio que se necesita para el control del inventario.

Se procura que todos los datos estén actualizados y disponibles en cualquier momento

para poder brindar un mejor servicio a todos los usuarios que utilicen la aplicación.

1.2 Marco Teórico

La implementación de aplicaciones informáticas como medio importante para la

publicación y administración de datos ha aumentado debido al desarrollo de las

tecnologías de la información.

Mediante una aplicación web el usuario por medio de un navegador realiza peticiones a

una aplicación remota obteniendo respuesta en el mismo navegador.

Características de las aplicaciones web:

Compatibilidad en diferentes plataformas.

Siempre se mantienen actualizadas.

4

Acceso inmediato.

Disminución en los requerimientos de hardware.

Datos alojados en servidores altamente fiables.

Reducción de errores debido a problemas de software y conflictos de

hardware.

Admite distintos tipos de usuarios

Servidores, para alojar la base de datos y la aplicación

La arquitectura de la aplicación web es por capas

Comunicación mediante protocolo HTTP sobre TCP/IP

Figura 1 Esquema general de las tecnologías web

Fuente:http://www.infor.uva.es/~jvegas/cursos/buendia/pordocente/node11.html

1.3 Metodologías Tradicionales

El desarrollo del software fue adaptado por metodologías existentes en otras áreas para

mejorar y cumplir la meta de los proyectos.

El uso de las metodologías tradicionales en los procesos de desarrollo de software

presentaba dificultades al equipo de desarrollo ya que en cada secuencia se necesitaba la

documentación completa para poder avanzar a la siguiente etapa.

5

Para solucionar estos inconvenientes se definieron los métodos iterativos los cuales

permiten guiar el proceso de desarrollo de software.

Entre las principales metodologías tradicionales podemos citar a RUP y MSF, que

durante todo el proyecto centran su atención en llevar una documentación exhaustiva y

en cumplir un plan definido en la fase inicial del desarrollo del proyecto.

1.3.1 Principales Metodologías Tradicionales

Rational Unified Process (RUP)1

Rup es una metodología que ordenadamente permite asignar tareas y responsabilidades

dentro de una organización de desarrollo de software, define claramente quien, cómo,

cuándo y qué debe hacerse en el proyecto.

Características:

Orienta el proyecto a la importancia para el usuario.

Relaciona la toma de decisiones las cuales indican como debe ser construido el

sistema y en qué orden.

El proyecto es dividido en mini proyectos donde los casos de uso y la

arquitectura cumplen sus objetivos de manera más depurada.

Fases

6

Figura 2 Rational Unified Process

Fuente: https://commons.wikimedia.org/wiki/File:Rup_espanol.gif

Microsoft Solution Framework (MSF)2

Es una metodología flexible y adaptable que permite entregar de forma rápida los

proyectos tecnológicos, reduciendo recursos humanos y riesgos, ofreciendo resultados

de calidad.

MSF se centra en el modelo de procesos y de equipo dejando los demás aspectos en

segundo plano.

Las cinco principales fases de MSF son:

Visión y alcances.

Planificación

Desarrollo

Estabilización

Implantación

2 Microsoft Solution Framework (MSF): es un conjunto de principios, modelos , disciplinas, conceptos y directrices para la entrega de tecnología de la información soluciones de Microsoft. MSF no se limita al desarrollo de aplicaciones de forma única, sino que también es aplicable a otros proyectos de TI como los proyectos de despliegue, o de redes de infraestructura, no obliga al desarrollador a utilizar un determinado método, pero permite decidir que metodología utilizar.

7

Figura 3 Microsoft Solution Framework

Fuente: https://technet.microsoft.com/es-es/library/bb490186.aspx

1.3.2 Principales metodologías ágiles

Scrum3

Es una metodología ágil, adaptable, iterativa, rápida, flexible y eficaz que sirve para

administrar y controlar el desarrollo de software, ofreciendo un valor significativo de

forma rápida en todo el proyecto.

Existe una responsabilidad en todos los integrantes del equipo de desarrollo para el

progreso continuo de diferentes productos dentro de los proyectos.

El equipo de desarrollo se reúne diariamente para revisar el progreso y ajustar los

siguientes pasos necesarios para completar el trabajo pendiente.

3 SCRUM: es un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto.

8

Figura 4 Scrum

Fuente: https://www.mountaingoatsoftware.com/agile/scrum/overview

Extreme Programming (XP)

9

Es una metodología ágil que centra su éxito en potenciar las relaciones personales para

el desarrollo de software, mejora la productividad de los proyectos basándose en la

realimentación permanente entre el cliente y los desarrolladores.

Figura 5 Extreme Programming

Fuente: http://slideplayer.es/slide/2273638/

1.4 Diferencia entre metodologías tradicionales y agiles

En la siguiente tabla se encuentra las principales diferencias entre las metodologìa

tradicionales y las metodologìas àgiles.

10

Tabla 1 Diferencias entre metodologías tradicionales y ágiles

Metodologías Ágiles Metodologías Tradicionales

Basadas en heurìticas provenientes de

pràcticas de producciòn de còdigo.

Basadas en normas provenientes de

estándares seguidos por el entorno de

desarrollo.

Especialmente preparados para cambios

durante el proyecto.

Cierta resistencia a los cambios.

Impuestas internamente por el equipo Impuestas externamente

Proceso menos controlado, con pocos

principios

Proceso mucho más controlado, con

numeras políticas/normas

No existe contrato tradicional o al menos

es bastante flexible

Existe un contrato prefijado

El cliente es parte del equipo de desarrollo El cliente interactua con el equipo de

desarrollo mediante reuniones

Grupos pequeños(< 10 integrantes) y

trabajando en el mismo sitio

Grupos grandes y posiblemente

distribuidos

Pocos artefactos Más artefactos

Pocos roles Màs roles

Menos enfasis en la arquitectura del

software

La arquitectura del software ws esencial y

se expresa mediante modelos

11

2. METODOLOGÍA

2.1 Metodología para el desarrollo del Proyecto

La metodología en la que se basará el desarrollo del software será Scrum.

Scrum es una metodología que permite al equipo desarrollar el software de una manera

ágil en una serie de interacciones, realizando entregas parciales obteniendo resultados

inmediatos.

Estas interacciones son los llamados Sprints que tienen una fecha de inicio y de fin y

que pueden durar entre una semana hasta un mes. Los miembros del equipo durante el

sprint deben cumplir y completar todas las tareas.

2.1.1 Elementos de Scrum

Figura 6 Elementos de Scrum

12

Fuente: http://www.palentino.es/blog/resumen-de-la-metodologia-scrum-para-el-

desarrollo-del-software-historia-caracteristicas-roles/

En Scrum existen tres actores o roles principales que intervienen de manera directa

o indirectamente en el proyecto.

o Product Owner: representa a las personas que requieren el software,

cuya responsabilidad es desarrollar, mantener y priorizar las ideas del

cliente.

o Scrum Master: es el responsable de eliminar las dificultades que se

presentan en el equipo durante el desarrollo del proyecto, verificando que

se realicen las reuniones y ayudando a tomar decisiones responsables

para lograr el éxito en el desarrollo ágil de los objetivos.

o Team Members: es el equipo que posee experiencia y conocimientos

necesarios para organizar, tomar decisiones durante el desarrollo del

software para que el producto sea un éxito.

13

Figura 7 Roles de Scrum

Fuente: http://agileatlas.org/articles/item/scrum-framework

Artefactos: herramientas utilizadas por Scrum

o Product Backlog: es una lista ordenada de todos los requerimientos

iniciales del proyecto elaborada por el dueño del producto.

o Sprint Backlog: son las actividades o lista de tareas asignadas a cada

persona que se van a realizar dentro de un sprint indicando el tiempo o

esfuerzo necesario para concluirlas.

o Sprint: son las iteraciones que pueden tener una duración entre una

semana a un mes, poseen las tareas que son identificadas en las reuniones

de planificación.

o Incremento: son los requisitos realizados dentro de un sprint, de acuerdo

a los resultados obtenidos el cliente puede realizar los cambios

necesarios al proyecto.

Figura 8 Artefactos de Scrum

Fuente: http://www.mikelnino.com/2014/08/fundamentos-metodologias-agiles-

scrum-training-series-Michael-James.html

14

Eventos: son las reuniones necesarias para aplicar la metodología Scrum.

o Reunión de planificación del sprint: se crea un documento con las lista

de tareas prioritarias que se deben realizar en cada sprint.

o Scrum diario: es una actividad diaria que tiene una duración máxima de

quince minutos, en la cual cada miembro del equipo comunica al resto lo

que se ha realizado, lo que se va a realizar y si existe dificultades para

desarrollar el trabajo. Esta reunión es importante ya que las personas

comparten información para encontrar la manera exitosa de cumplir las

tareas y metas del Sprint.

o Revisión del sprint: es la presentación de los resultados finales del

producto a los clientes y al dueño.

o Retrospectiva del sprint: reunión en la que el equipo crea un plan para

mejorar la forma de trabajo, reduciendo los errores para que el equipo de

desarrollo sea exitoso en el siguiente sprint.

15

Figura 9 Roles, artefactos y reuniones de Scrum

Fuente: http://www.islavisual.com/articulos/desarrollo_web/diferencias-entre-

scrum-y-xp.php

2.1.2 Aspectos interesantes de Scrum

Dentro del equipo que construye el producto que va a ser utilizado por el cliente

se encuentran los expertos necesarios para desarrollar el software ejecutable

potencial

Al inicio del proyecto no es indispensable la documentación, Scrum se centra

en sacar los productos para que el cliente pueda observar los avances que se van

realizando durante el desarrollo

El dueño del producto es el responsable de crear una lista de requerimientos

ordenada por prioridades.

La experiencia de los administradores está a disposición del equipo el cual es

apoyado para eliminar las dificultades identificadas durante el desarrollo del

producto.

16

Scrum tiene como objetivo minimizar el esfuerzo y maximizar el rendimiento en

el desarrollo.

2.1.3 Fases de la Metodología Scrum

La metodología Scrum está formada por las fases de Concepto, Especulación,

Exploración, revisión, Cierre.

Figura 10 Etapas de Scrum

Fuente:

http://diariodeelisacom.weebly.com/uploads/2/6/5/9/26595837/4059542.jpg?336

Concepto: se definen las características del producto y el equipo que se

encargará de su desarrollo.

Especulación: Se establece los límites con una estimación de coste y agenda que

marcarán el desarrollo del producto.

Esta fase se repite en cada iteración y consiste:

o Desarrollar y revisar los requisitos generales.

o Mantener la lista de las funcionalidades que se esperan.

o Se establecen la fecha de las versiones, hitos e iteraciones.

17

Exploración: se incrementa el producto en el que se añaden las funcionalidades

de la fase de especulación.

Revisión: el equipo revisa todo lo que se ha construido y se compara con el

objetivo deseado.

Cierre: se entregará en la fecha acordada una versión del producto deseado. Al

tratarse de una versión, el cierre no indica que se ha finalizado el proyecto sino

que seguirá habiendo cambios, que hará que el producto se acerque al producto

final deseado

2.2 Herramientas

2.2.1 Recopilación de la información

El método de recolección de información y las herramientas utilizadas fueron las

siguientes:

2.2.2 Entrevistas

Se realizaron entrevistas para obtener la información detallada de las actividades y

manejo de los equipos en la Dirección de Tecnología y Comunicaciones del Cuerpo de

Bomberos del Distrito Metropolitano de Quito

2.2.3 Documentos de registros de equipos que utiliza la unidad de informática

La Unidad de informática proporcionó el documento digital en formato Excel con la

información necesaria para registrar los equipos, direcciones, ips asignadas.

2.2.4 Casos de Uso

Los casos de uso son una técnica que comprenden los pasos necesarios para alcanzar un

objetivo determinando las características necesarias que tendrá el sistema.

Los diagramas de casos de uso documentan el comportamiento de un sistema desde el

punto de vista del usuario

18

Tabla 2 Formato de Casos de uso

Id nombre

Actores

Objetivo

Precondiciones

Postcondiciones

Escenario básico

2.2.5 Diagrama de Entidad Relación

Es una herramienta que permite representar las entidades de un sistema de información.

Las entidades es un objeto real o abstracto del cual deseamos guardar información.

Las relaciones son los vínculos que permiten definir una dependencia entre entidades.

19

Figura 11 Ejemplo de Diagrama Entidad Relación

2.2.6 Plataforma JEE

Java Plataform, Enterprise Edition o Java EE es el estándar en software empresarial para

crear, desarrollar e implementar aplicaciones en línea basadas en la web, simplificando

el desarrollo de las aplicaciones a través de componentes modulares que son

reutilizables y se ejecutan sobre un servidor de aplicaciones.

La plataforma Java EE consta de API4, como JDBC5, servicios web, etc que

proporcionan la funcionalidad necesaria para desarrollar aplicaciones basadas en la web.

La identificación de los procesos y subprocesos que se realizan en la unidad de

Informática de la Dirección de Tecnología y comunicaciones serán representadas

mediante un conjunto de diagramas, utilizando el lenguaje de modelado UML

(Lenguaje Unificado de Modelado) que permite gráficamente visualizar, especificar,

construir y documentar un sistema.

4 API(Application Programming Interface)es una serie de servicios o funciones que ofrece una librería Java al programador 5 JDBC(Java Database Connectivity) es una interfaz que permite a un programa java ejecutar instrucciones SQL dentro de bases de datos

20

Se aplicará una arquitectura de tres capas ya que facilita la administración de los

procesos de manera sencilla proporcionando las modificaciones requeridas por el

sistema

Las aplicaciones Java EE están formadas de componentes, lo que permite crear una

aplicación empresarial portable capaz de ejecutar y desplegarse en cualquier servidor

web que cumpla con los requisitos.

2.2.7 Java Server Faces (JSF)

Es un framework que permite la construcción de aplicaciones java basadas en la web como interfaces de usuarios.

Para el despliegue de las páginas usa la tecnología JavaServerPages (JSP).

JavaServerFaces separa la lógica de presentación y de aplicación, facilitando la conexión entre las correspondientes capas.

Estos objetivos de diseño representan el foco de desarrollo de JSF:

Definir un conjunto simple de clases base de Java para componentes de la

interfaz de usuario, estado de los componentes y eventos de entrada. Estas clases

tratarán los aspectos del ciclo de vida de la interfaz de usuario, controlando el

estado de un componente durante el ciclo de vida de su página.

Proporcionar un conjunto de componentes para la interfaz de usuario,

incluyendo los elementos estándares de HTML para representar un formulario.

Estos componentes se obtendrán de un conjunto básico de clases base que se

pueden utilizar para definir componentes nuevos.

Proporcionar un modelo de JavaBeans para enviar eventos desde los controles

de la interfaz de usuario del lado del cliente a la aplicación del servidor.

Definir APIs para la validación de entrada, incluyendo soporte para la validación

en el lado del cliente.

Especificar un modelo para la internacionalización y localización de la interfaz

de usuario.

21

Automatizar la generación de salidas apropiadas para el objetivo del cliente,

teniendo en cuenta todos los datos de configuración disponibles del cliente,

como versión del navegador.

Fases del Java Server Faces

Restaurar la vista (restore view). En este paso se reconstruye el árbol de

componentes, si ya ha sido generado este se recupera caso contrario se genera a

partir de la descripción JSF.

Aplicar los valores de la petición (apply request values). Una vez obtenido el

árbol de componentes, se procesan todos los valores asociados a los mismos. Se

convierten todos los datos de la petición a tipos de datos Java y, para aquellos

que tienen la propiedad inmediata a cierta, se validan, adelantándose a la

siguiente fase.

Procesar las validaciones (process validations). Se validan todos los datos. Si

existe algún error, se encola un mensaje de error y se termina el ciclo de vida,

saltando al último paso (renderizar respuesta), mostrándole al usuario la página

actual para que pueda introducir los datos correctos.

Actualizar los valores del modelo (update model values). Cuando se llega a

esta fase, todos los valores se han procesado y se han validado. Se actualizan

entonces las propiedades de los beans gestionados asociados a los componentes.

Invocar a la aplicación (invoke application). Cuando se llega a esta fase, todas

las propiedades de los beans asociados a componentes de entrada (input) se han

actualizado. Se llama en este momento a la acción seleccionada por el usuario.

Renderizar la respuesta (render response). El servidor devuelve la página de

respuesta al navegador del usuario y guarda el estado actual de la vista para

poderla restaurar en una petición posterior. Si la petición es inicial, los

componentes en la página se cargarán en el árbol de componentes conforme JSF

ejecuta la página. Si surgieran errores, se mostrarán en la página. Una vez

renderizada la vista, la respuesta se guarda, para ser llamada.

22

Figura 12 Ciclo de vida de jsf

Fuente: http://www.jtech.ua.es/j2ee/publico/jsf-2012-13/sesion03-apuntes.html

2.2.8 JSF - Managed Beans

Controlar el estado de las páginas web es el objetivo de los Managed Beans. Un

Managed Beans es una clase JavaBean regularmente registrada con JSF, se crea

automáticamente y tiene un tiempo de vida que depende del alcance que tiene.

JSF Managed Beans es un modelo de programación Plain Old Java Object (POJO). El

Managed Bean contiene los métodos getter, setter y la lógica del negocio.

JSF administra automáticamente los Managed Beans:

Crea las instancias, por ello la necesidad de un constructor vacío.

Controla su ciclo de vida, JSF determina el alcance de cada Managed Bean.

Managed Beans cuenta con los siguientes alcances:

Application: el Bean está accesible para todos los usuarios y sesiones en la aplicación.

Session: el Bean está disponible en una única sesión HTTP de usuario.

Request: el Bean está disponible solo en una única petición HTTP.

None: el Bean no está almacenado en ningún alcance, pero puede ser creado en

demanda cuando sea necesario.

23

Figura 13 JSF - Managed Beans

Fuente: http://corejsf.com/refcard.html

2.2.9 GlassFish

Servidor de aplicaciones de software libre que implementa las tecnologías definidas en

la plataforma de Java Enterprise Edition, a su vez puede ejecutar otras aplicaciones que

cumplan las especificaciones. Cuenta con dos versiones GlassFish Enterprise Server y

Oracle GlassFish Enterprise Server.

GlassFish tiene las siguientes ventajas:

Compatible con lenguajes de scripts.

Ruta de migración sencilla.

Administración y supervisión sencilla y fácil de manipular.

Justificativo de utilizar GlassFish

GlassFish tiene la capacidad de retener sesiones entre distintos despliegues de

aplicaciones, ahorro de tiempo para desarrollo.

Facilita la reconfiguración dinámica de servidores virtuales.

24

Figura 14 Arquitectura del servidor GlassFish

Fuente: http://www.slideshare.net/brunoborges/glassfish-in-production-

environments

2.2.10 Postgres

Es un sistema gestor de bases de datos relacionales orientadas a objetos, está derivado

del paquete Postgres escrito en Berkeley.

PostgreSQL es el gestor de bases de datos de código abierto más avanzado hoy en día,

ofreciendo control de concurrencia multi-version.

PostgreSQL funciona bien con grandes cantidades de datos y una alta concurrencia de

usuarios accediendo a la vez al sistema.

Ventajas de Postgres

Ideal para tecnologías web.

Fácil de administrar.

Su sintaxis SQL es estándar y fácil de aprender.

Multiplataforma.

Capacidades de replicación de datos.

25

Figura 15 Arquitectura de PostgreSQL

Fuente: http://es.slideshare.net/cesmarmay1/documentacionpostgresql

26

3. DESARROLLO DE LA PROPUESTA

3.1Planificación

Es necesario realizar una planificación inicial que permita identificar el objetivo de cada

iteración y definir lo que se realizará en cada sprint.

3.1.1 Análisis de procesos

Para definir los alcances funcionales, se analizará el proceso ya definido internamente

por la Unidad de Informática del Cuerpo de Bomberos del Distrito Metropolitano de

Quito.

Actualmente la Dirección de Tecnología y Comunicaciones para realizar el proceso de

registro del inventario de equipos lo lleva manualmente a través de un archivo en Excel

con un determinado formato diseñado por la unidad de informática, en donde se insertan

datos de estos dispositivos de forma general.

Cabe destacar que las personas encargadas en realizar el respectivo levantamiento de la

información de los equipos, no recurren al inventario existente debido a la cantidad de

usuarios y a su rotación la información no se encuentra actualizada causando

inconvenientes al momento de resolver alguna incidencia presentada.

3.1.2 Modalidad de la investigación

Se empleó la investigación de campo ya que ha permitido recolectar la información del

personal que labora en la unidad de informática del Cuerpo de Bomberos del Distrito

Metropolitano de Quito.

3.1.3 Recolección de la información

La información se la recolectó de las personas que trabajan en la unidad de informática

del CB-DMQ las cuales están familiarizadas con el proceso que se utiliza en el control

del inventario, además obtendremos la documentación existente en la dirección.

Las entrevistas al personal de la unidad se las realizaron en varias ocasiones hasta

completar toda la información necesaria.

3.1.4 Procesamiento y análisis de la información

27

Una vez recolectada la información se procedió al análisis de los datos obtenidos los

cuales fueron de gran importancia para la formulación de la propuesta.

Como resultado de las entrevistas realizadas al personal de la unidad de informática se

ha recabado la siguiente información:

El personal que da soporte a los usuarios interviene en el inventario de equipos

informáticos actualizándolo de acuerdo a los cambios que se presenten.

Una vez realizadas las entrevistas al personal involucrado, se llegó a la conclusión que

la unidad de informática no cuenta con una aplicación para llevar a cabo el proceso de

control de inventario, es decir se lo realiza manualmente lo que conlleva a un sinnúmero

de contratiempos por tal motivo necesita un sistema informático que permita el control

adecuado y eficaz del inventario.

Proceso manual mediante el cual la unidad de informática del Cuerpo de

Bomberos del Distrito Metropolitano de Quito realiza el control de inventario de

equipos informáticos.

Subproceso 1: El especialista se dirige a las direcciones, distritos o estaciones, `para

constatar los equipos informáticos.

Subproceso 2: El especialista lleva a cabo el levantamiento físico de los equipos

utilizando el formato establecido.

Subproceso 3: Se encuentra registrado el bien la lista:

Si: se marca en el formato que el equipo se encuentra registrado

No: se activa el subproceso 4

Subproceso 4: El especialista ingresa los datos del usuario, la dirección a la que

pertenece y los datos relacionados de acuerdo al tipo de equipo informático.

Subproceso 5: Una vez realizado el levantamiento del inventario se lo consolida y se lo

tiene disponible para las actividades diarias de la unidad de informática.

De los subprocesos descritos anteriormente se han identificado los requisitos

funcionales y no funcionales.

28

Tabla 3 Requerimientos Funcionales/No funcionales

Módulo Requisitos funcionales Requisitos no funcionales

Administración El sistema brindara

seguridad para ser utilizado

por usuarios registrados,

con diferentes niveles de

acceso. Se crearán roles de

acuerdo a las necesidades,

en este caso se crearán tres

roles.

Autenticación El sistema pedirá el usuario

y contraseña, los cuales

serán validados en el active

directory, una vez

validados se redireccionará

al módulo asignado

dependiendo del rol, en

caso de que los datos sean

incorrectos volverá a la

página de autenticación

La aplicación funcionará

en navegador Mozilla

Firefox versión 26 o

superior

Gestión El sistema permitirá

registrar los equipos

Gestión El sistema permitirá

asignar los equipos al

usuario

29

Reportes o informes El sistema permitirá

realizar consultas e

informes co parámetros

establecidos o

parametrizables

Auditoria El sistema permitirá

identificar la realización de

los movimientos o cambios

3.1.5 Alcance del Software

De acuerdo al análisis de los subprocesos y las funcionalidades identificadas, el

software a desarrollarse tendrá los siguientes alcances

Módulo de administración de usuarios que permitirá:

Crear usuarios y asignar perfiles

Para este proyecto se creará roles de acuerdo a las necesidades. En este

caso se crearán solamente tres roles

o Rol administrador: tendrá todos los permisos para modificar

información de los usuarios y equipos tecnológicos, podrá

ingresar a todos los módulos

o Rol de especialista: manejará todo lo referente a los equipos

tecnológicos, tendrá todos los derechos para administrar los

equipos y podrá realizar y ver los diferentes reportes.

o Rol de reportes: solo tendrá acceso al módulo de reportes.

Módulo de ingreso que permitirá:

Ingreso del usuario a la aplicación de acuerdo al perfil asignado

Módulo de gestión que permitirá:

Crear, modificar equipos

Asignar equipos a usuarios

Módulo de Reportes que permitirá:

Realizar consultas

Realizar informes con parámetros establecidos o parametrizables.

30

3.1.6 Generación del Product Backlog

La Dirección de Tecnología y Comunicaciones no cuenta con una aplicación que

controle el inventario de equipos informáticos, esta labor se la realiza de forma manual

lo que provoca inconsistencias en la información.

Para la elaboración de la aplicación para el control del inventario se realizaron

reuniones con el personal de la unidad de informática. En estas reuniones se

establecieron los requerimientos con los que debe cumplir el sistema para solucionar los

problemas que se han venido presentando a lo largo de los años.

Con toda la información obtenida después de las entrevistas realizadas se procedió a

realizar las historias de usuario de acuerdo a la metodología Scrum.

3.1.7 Historias de usuarios

Son representaciones de requisitos de software escritas en una o dos frases utilizando el

lenguaje común del usuario.

Tabla 4 Historia de usuario1

HISTORIAS DE USUARIOS

Número: 1 Usuario: Administrador de la aplicación

Nombre Historia: Creación, modificación de usuarios, perfiles

Descripción: La aplicación web tendrá tres perfiles según las funciones, se necesita usuarios y contraseñas que permitan el ingreso al sitio web, y según el perfil a las

diferentes opciones.

Tabla 5 Historia de usuario 2



Nombre Historia: Registro de especialistas

Descripción: Permitirá el registro, modificación y deshabilitación de especialistas en la aplicación web.

31




Nombre Historia: Ingreso de usuarios que utilizan la aplicación

Descripción: Es necesario registrar los usuarios que utilizarán la aplicación para lo cual es necesario ingresar los siguientes datos: nombre, apellido, cédula, además debe

estar relacionado a un tipo de usuario.



Número: 4 Usuario: Especialistas

Nombre Historia: creación, modificación de cpu

Descripción: Permitirá el registro, modificación los cpu, es necesario registrar los cpu con los siguientes datos: marca, modelo, serie, ip además debe estar relacionado

con el usuario y la dirección, unidad o estación a la que pertenece.




Nombre Historia: creación, modificación de monitor

Descripción: Permitirá el registro, modificación de los monitores, es necesario registrar los monitores con los siguientes datos: marca, modelo, serie, además debe

estar relacionado con el cpu o portátil a la que pertenece.




Nombre Historia: creación, modificación de teclado

32

Descripción: Permitirá el registro, modificación de los teclados, es necesario

registrar los teclados con los siguientes datos: marca, modelo, serie, además debe estar relacionado con el cpu o a la portátil a la que pertenece.




Nombre Historia: creación, modificación de mouse

Descripción: Permitirá el registro, modificación de los mouses, es necesario registrar los mouse con los siguientes datos: marca, modelo, serie, además debe estar

relacionado con el cpu o portátil a la que pertenece.




Nombre Historia: creación, modificación de portátil

Descripción: Permitirá el registro, modificación de las portátiles, es necesario registrar las portátiles con los siguientes datos: marca, modelo, serie, ip además debe

estar relacionado con el usuario y la dirección, unidad o estación a la que pertenece.



33


Nombre Historia: creación, modificación de docking

Descripción: Permitirá el registro, modificación de los docking, es necesario registrar los docking con los siguientes datos: marca, modelo, serie, además debe

estar relacionado con la portátil a la que pertenece.




Nombre Historia: creación, modificación de impresoras

Descripción: Permitirá el registro, modificación de las impresoras, es necesario registrar las impresoras con los siguientes datos: marca, modelo, serie, ip además

debe estar relacionado con el usuario y la dirección, unidad o estación a la que pertenece.




Nombre Historia: creación, modificación de iPad

Descripción: Permitirá el registro, modificación de los iPad, es necesario registrar los iPad con los siguientes datos: marca, modelo, serie, imei además debe estar

relacionado con el usuario al que pertenece.

34

3.1.8 Definición del Backlog del producto

El Backlog del producto se encuentra definido en la siguiente tabla de acuerdo al

estudio de los subprocesos y los requerimientos identificados durante la etapa de

análisis

Tabla 15 Backlog producto

Id Nombre Importancia Tiempo

estimado(días)

Comentarios

1 Módulo de

administración

de usuarios

100 Funcionalidad

para la

administración

de usuarios

2 Módulo de

autenticación

200 Funcionalidad

para permitir a

los usuarios el

ingreso a los

diferentes

módulos en el

sistema de

acuerdo al

perfil asignado

3 Módulo de

gestión

300 Funcionalidad

para

administrar los

equipos

4 Módulo de

reportes

400 Funcionalidad

para gestionar

la información

La importancia está cuantificada con números enteros entre 0 y 1000, de acuerdo a la

figura siguiente

35

Figura 16 Escala importancia definida por Product Owner.

3.1.9 Diseño

Modelo de Datos

Se definirá en forma general, el modelo de datos que serán implementados en los

siguientes Sprints.

Arquitectura funcional de la aplicación

La arquitectura está definida por herramientas de código abierto disponibles para el

lenguaje java, las cuales utilizan el patrón MVC6, y se basan en una estructura de capas:

presentación, negocio y datos.

Figura 17 Arquitectura de la aplicación web del sistema de inventarios de equipos

tecnológicos.

6 MVC: Modelo, Vista, Controlador

Capa de datos Capa de Presentación Capa de negocio

BROWSER

MANAGED BEANS

JPA

BDD

36

o Capa de presentación: Esta capa se va a desarrollar con JEE y el framework JSF

que crea aplicaciones web rápidamente con Primefaces.

Además se utiliza el MVC que es un patrón de diseño de software que convierte

una aplicación en un paquete modular fácil de mantener y mejora la rapidez del

desarrollo.

o Capa de negocio: en esta capa se reciben las peticiones del usuario y se envían

las respuestas tras el proceso. Se denomina capa de negocio porque es aquí

donde se establecen las reglas que deben cumplirse.

o Capa de datos: esta capa se comunica con la capa de presentación, para recibir

las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al

gestor de datos almacenar o recuperar datos del sistema.

En la capa de datos se utiliza los JPA que es el lenguaje de programación java

que maneja datos relacionales. Para almacenar y manejar la información se

utiliza PostgreSQL que es el software de base de datos.

o También se utiliza GlassFish un servidor de aplicaciones que implementa las

tecnologías definidas en la plataforma Java EE y permite ejecutar aplicaciones

que siguen esta especificación.

3.1.10 Sprint 1 “Módulo de administración de usuarios”

El objetivo del sprint 1 es implementar las funcionalidades, como crear, modificar

usuarios y controlar el acceso a los diferentes módulos del sistema a través de los roles.

Planificación

Se realizó un análisis de las funcionalidades y procesos que serán implementados.

Tabla 16 Requerimientos Funcionales/No Funcionales del Sprint 1

REQUISITOS

FUNCIONALES

REQUISITOS NO FUNCIONALES

La aplicación permitirá registrar a

los usuarios.

Brindará seguridad para su ingreso

dependiendo de los roles asignados

37

A continuación identificamos las historias de usuarios.

Tabla 17 Historia de usuario – Sprint 1

ID Historia de

usuario

Importancia

Product

Owner

Descripción

1 Iniciar sesión

en el sistema

1000 Permitir el

acceso a

usuarios

registrados

2 Administración

de usuarios

800 Es necesario

administrar a

los usuarios

Definición del equipo de trabajo

Tabla 18 Equipo de trabajo

Responsabilidad Nombre

Product Owner Gabriel Ortega

Scrum Master Viviana Viscarra

No se podrán eliminar los

usuarios porque se necesita tener

un histórico de la información.

La aplicación funcionará en el

navegador Mozilla Firefox versión 26.

o superior

38

Desarrollador Viviana Viscarra

Pruebas Eduardo Moina

Análisis

A continuación se diagrama los casos de uso con sus principales actores

Diagramas de caso de uso del módulo de administración de usuarios

Figura 18 Casos de uso- Modulo de administración de usuario

Descripción de los casos de uso

Tabla 19 Especificación del caso de uso: módulo de administración de usuario y

perfiles

39

Id

CU-01

Nombre caso de uso

Módulo de administración de usuario

y perfiles

Actores

Administrador

Objetivo Permitir al administrador crear,

modificar y listar usuarios de la

aplicación

Precondiciones Acceder a la aplicación y

autenticarse

Postcondiciones N/A

Arquitectura

La codificación para el módulo de administración de usuario y perfiles se implementará

de la siguiente manera:

Pantallas para:

o Formularios para la administración de recursos

Administración de usuarios

Construcción

Backlog del Sprint

El Backlog del sprint se muestra en la siguiente tabla:

Tabla 20 20 Backlog Sprint Modulo de Administración

40

Id Historia Número

Tarea

Nombre de la

tarea

Asignado Estimado(horas)

1 Creación de

usuario

24

1 Listado de

usuarios

Viviana

Viscarra

4

2 Modificar usuario

Viviana

Viscarra

4

3 Asignación de

perfil por

usuario

Viviana

Viscarra

4

5 Pruebas de

desarrollo

Viviana

Viscarra

6 Pruebas

unitarias

Eduardo

Moina

1

2 Administración

de usuarios

1 Componentes

comunes

Viviana

Viscarra

2 Creación

objetos DB

Viviana

Viscarra

3 Desarrollo de

pantallas

Viviana

Viscarra

4 Pruebas de

desarrollo

Viviana

Viscarra

5 Pruebas

unitarias

Eduardo

Moina

3.1.11 Sprint 2 “Modulo de autenticación”

El objetivo del sprint 2 es implementar las funcionalidades, validar el ingreso de los

usuarios a la aplicación y controlar su acceso dependiendo del rol asignado.

41

Planificación


Tabla 21 Requerimientos Funcionales/No Funcionales – Sprint 2

REQUISITOS FUNCIONALES REQUISITOS NO FUNCIONALES

El sistema pedirá el usuario y contraseña,

los cuales serán validados en el active

directory, una vez validados se

redireccionará al módulo asignado

dependiendo del rol, en caso de que los

datos sean incorrectos volverá a la página

de autenticación.


Tabla 22 Historia de usuario- sprint 2

ID Historia de

usuario

Importancia

Product Owner

Descripción

1 Iniciar sesión en el

sistema

1000 El usuario ingresará

su usuario y

contraseña para

poder ejecutar las

operaciones que le

está permitido de

acuerdo al rol

asignado

Análisis

42


Diagramas de caso de uso del módulo de autenticación

Figura 19 Casos de uso- Módulo de autenticación

Descripción de los casos de uso

Tabla 23 Especificación del caso de uso: módulo de autenticación

Id

CU-02

Nombre caso de uso

Módulo de Autenticación

Actores

Usuarios de la aplicación

Objetivo Permitir acceder a la aplicación una

vez registrado correctamente.

Precondiciones El servicio de la aplicación debe

estar activo.

Postcondiciones N/A

Escenario básico 1. El usuario ingresa la url de la

aplicación en el navegador.

2. Muestra la pantalla de

autenticación del usuario.

3. Ingresa el usuario y la contraseña.

4. Accede a los módulos y opciones,

según el rol asignado

43

Arquitectura

La codificación para el módulo de autenticación se implementará de la siguiente

manera:

Internamente la aplicación tendrá los siguientes módulos:

Pantallas para:

o Módulo de autenticación

Validación de datos en el active directory

Asignación de formularios al perfil

Construcción

Backlog del Sprint


Tabla 24 Backlog Sprint Modulo de Autenticación

Id Historia Número

Tarea

Nombre de la

tarea


1 Iniciar sesión

en la

aplicación

1 Programación

de plantilla

Viviana

Viscarra

16

44

principal

2 Programación de casillero de

usuario y password

Viviana

Viscarra

16

3 Inserción de

información en

la base de

datos

Viviana

Viscarra

16

4 Verificación de

inserción en la

base de datos

Viviana

Viscarra

8

5 Programación

del estilo de la

plantilla

Viviana

Viscarra

8

6 Programación

del fondo de

pantalla

Viviana

Viscarra

5

7 Revisión de

transición a

siguiente tarea,

siendo

password

correcto

Eduardo

Moina

8

8 Validación

datos en el

active directory

Viviana

Viscarra

16

9 Extraer el

perfil al que

pertenece el

usuario

autentificado

Viviana

Viscarra

4

10 Desarrollo de

pantallas

Viviana

Viscarra

11 Pruebas de Viviana

45

desarrollo Viscarra

12 Pruebas

unitarias

Eduardo

Moina

Para llevar un control de los avances de las tareas se utiliza la herramienta.

3.1.12 Sprint 3 “Módulo de Gestión”

El tercer sprint tiene como objetivo implementar las funcionalidades requeridas para la

gestión de los equipos informáticos.

Planificación


Tabla 25 Requerimientos Funcionales/No Funcionales – Sprint 3

REQUISITOS FUNCIONALES REQUISITOS NO FUNCIONALES

La aplicación permitirá gestionar los

equipos informáticos y asignar a los

usuarios custodios.



ID Historia de

usuario

Importancia

Product Owner

Descripción


sistema


su usuario y

contraseña para

poder ejecutar las

operaciones que le

está permitido de

acuerdo al rol

asignado

46

2 Administración de

equipos

800 La aplicación debe

registrar los

equipos con los que

cuenta la institución

3 Asignación de

equipos

800 Cada usuario tiene

asignado un equipo

informático para

realizar sus

actividades diarias.

Análisis


Diagramas de caso de uso del módulo de gestión

Figura 20 Caso de uso –Modulo de gestión

47

Especificación de caso de uso

Tabla 27 Especificación del caso de uso: Módulo de gestión

Id

CU-03

Nombre caso de uso

Módulo de Gestión

Actores


Objetivo Permitir crear, modificar, y asignar

equipos informáticos.


estar activo.

Postcondiciones N/A






4. Accede al módulo de gestión y

gestiona el proceso de crear,

modificar,y asignar equipos a

usuarios.

Arquitectura

La codificación para el módulo de gestión se implementará de la siguiente manera:

Pantallas para:

o Formularios para la administración de equipos

Creación de ítems

Modificación de ítem

48

Asignar custodio

Modificar custodio

Listado de custodios

Cambio de estado de los ítems

Registro de auditoria

Construcción

Backlog del Sprint


Tabla 28 Backlog Sprint Modulo de Gestión

Id Historia Número

Tarea

Nombre de la

tarea


1 Iniciar sesión

en la

aplicación

1 Creación de

ítems

Viviana

Viscarra

24

4 Modificar

ítems

Viviana

Viscarra

4

5 Asignar

custodio

Viviana

Viscarra

4

6 Modificar Viviana 4

49

custodio Viscarra

7 Listado de

custodio

Eduardo

Moina

2

8 Cambiar de

estado a los

ítems

Viviana

Viscarra

4

9 Registro de

auditoria

Viviana

Viscarra

16

3.1.13 Sprint 4 “Módulo de Reportes”

Este módulo permitirá generar reportes

Planificación


Tabla 29 Requerimientos Funcionales/No Funcionales del Sprint 4

A continuación identificamos las historias de usuario.


REQUISITOS

FUNCIONALES

REQUISITOS NO FUNCIONALES

La aplicación permitirá realizar

consultas de acuerdo a los

parámetros establecidos por el

usuario

La aplicación permitirá extraer el

informe en formato

50

ID Historia de

usuario

Importancia

Product Owner

Descripción


sistema


su usuario y

contraseña para

poder ejecutar las

operaciones que le

está permitido de

acuerdo al rol

asignado

2 Gestión de reporte 800 La aplicación

permitirá realizar

consultas y reportes

de los equipos que

se encuentran

registrados.

Análisis


Diagramas de caso de uso del módulo de gestión

51

Figura 21 Caso de uso –Modulo de reportes

Especificación de caso de uso

Tabla 31 Especificación del caso de uso: Módulo de reportes

Id

CU-04

Nombre caso de uso

Módulo de Reportes

Actores


Objetivo Permitir gestionar diferentes reportes

de la aplicación.


estar activo.

Postcondiciones N/A






4. Accede al módulo de reportes y

gestiona el proceso.

52

Arquitectura

La codificación para el módulo de reporte se implementará de la siguiente manera:

Pantallas para:

o Formularios para la administración de reportes

Reportes de usuarios

Reporte de ítems

Reporte de custodio

Reporte de estado de ítems

Reporte por custodio

Reporte por dirección

Reporte de auditoria

Construcción

Backlog del Sprint


Tabla 32 Backlog Sprint Modulo de Autenticación

Id Historia Número

Tarea

Nombre de la

tarea


1 Iniciar sesión

en la

aplicación

1 Creación de

ítems

Viviana

Viscarra

24

4 Modificar

ítems

Viviana

Viscarra

4

5 Asignar

custodio

Viviana

Viscarra

4

6 Modificar Viviana 4

53

custodio Viscarra

7 Listado de

custodio

Eduardo

Moina

2

8 Cambiar de

estado a los

ítems

Viviana

Viscarra

4

9 Registro de

auditoria

Viviana

Viscarra

16

Para llevar un control de los avances de las tareas se utiliza la herramienta.

3.2 Diseño de la base de datos

3.2.1 Diseño Físico

Figura 22 Base de datos que se utilizará en el desarrollo de la aplicación web

3.3 Diccionario de datos

54

3.3.1 Perfil del usuario

Tabla 33 Diccionario de datos perfil del usuario

3.3.2 Usuario

Tabla 34 Diccionario de datos perfil del usuario

Usuario Contiene información de los usuarios de la aplicación

Nombre del

campo

Tipo de

dato

Tamañ

o

Llav

e Descripción

idusuario serial pk identificador único de usuario

idperfil int 4 fk clave foreana para relacionar un usuario con un perfil

cedula char 10 cédula del usuario con la que traeremos información del

distributivo para saber la dirección a la que pertenece

nombres varchar 50 nombre del usuario registrado en la aplicación

apellidos varchar 50 apellidos del usuario registrado en la aplicación

usuarioad varchar 25 usuario del active directory

fechacreacion timestap fecha cuando se creó el usuario

fechaultimoacceso

timestap fecha última de acceso

Perfil

Contiene información de los perfiles que pueden tener los

usuarios en la aplicación

Nombre del

campo

Tipo de

dato Tamaño Llave Descripción

idperfil serial pk identificador único del perfil

descripcion varchar 250 descripción del perfil de usuario

55

3.3.3 Item

Tabla 35 Diccionario de datos ítem

Item Contiene información de los equipos tecnológicos

Nombre del

campo

Tipo de

dato

Tamañ

o

Llav

e Descripción

iditem serial pk identificador único del ítem

idtipoitem int 4 fk1 clave foreana para relacionar un

ítem con el tipo de ítem

idusuario int 4 fk2

clave foreana para relacionar un

ítem con un usuario

idestado int 4 fk3

clave foreana para relacionar un

ítem con su estado

idmarcas int 4 fk4 clave foreana para relacionar un

ítem con su marca

custodio char 10 persona responsable del bien

fechaadquisicion date fecha en la que fue adquirido el bien

vidautilmeses int

tiempo de vida e un equipo

informático

observaciones text observaciones del ítem

3.3.4 Tipo Ítem

Tabla 36 Diccionario de datos tipo ítem

Tipo ítem Contiene información de los tipo de ítems

Nombre del

campo Tipo de dato Tamaño Llave Descripción

idtipoitem serial pk

identificador único del tipo del

ítem

descripción varchar 100 descripción del tipo del ítem

3.3.5 Marcas

Tabla 37 Diccionario de datos marca

Marcas Contiene información de las marcas de los ítems

Nombre del


idmarca serial pk identificador único de la marca

descrpcion varchar 250 descripción de la marca

56

3.3.6 Estado

Tabla 38 Diccionario de datos estado

Estado Contiene información del estado del ítem

Nombre del

campo Tipo de dato

Tamañ

o

Llav

e Descripción

idestado serial pk identificador único de estado

descripción varchar 250 descripción de estado

3.3.7 Auditoría

Tabla 39 Diccionario de datos auditoría

Auditoria Contiene información de los cambios realizados en la aplicación

Nombre del


idauditoria serial pk identificador único de auditoria

idusuario int 4 fk clave foreana para relacionar una auditoria al usuario

fecha date fecha del cambio realizado

tabla text

valoractual text

valoranterior text

57

4. CONCLUSIONES

El Cuerpo de Bomberos del Distrito Metropolitano de Quito, cuenta con

200 equipos informáticos entre computadoras de escritorio, portátiles e

impresoras.

La base de datos utilizada para el registro de los equipos informáticos de

acuerdo a los parámetros establecidos es Postgres.

El sistema de gestión lo utilizará los usuarios especialistas (ver Anexo 1)

y el usuario administrador (ver Anexo 2)

58

5. RECOMENDACIONES

Registrar el ingreso de los equipos informáticos al sistema

Para el uso adecuado del sistema de gestión el usuario debe contar con un

navegador Mozilla Firefox versión 26 o superior ya que esta optimizada para

este navegador.

Realizar reportes de los equipos informáticos

Elaborar periódicamente informes sobre el estado del funcionamiento de los

equipos

59

6. BIBLIOGRAFIA

1. ETHERIDGE, D. (2009). Classes in Java Applications- An Introduction to

Java Programming.

2. PALACIO, J., & RUATA, C. (2011). Scrum Manager Gestión de Proyectos

(7ma ed.). SafeCreative.

3. PARRA, A., & PARRA, E. (2010). Lenguaje de Programación Java. Sun

Microsystems.

4. QUESADA, J. (2009). Características de JSF . En J. Quesada, JAVA

SERVER FACES Y EL USO DE PATRONES DE DISEÑO (págs. 1-2).

5. SABANA, M. (2006). PostgreSQL. Megabyte S.A.C.

6. SPADA, D. (2006). Usabilidad en el proceso de desarrollo de SCRUM

7. OPTIMUS, S., & Consultoría. (2011). Roles en Scrum. Obtenido de

http://www.optimussoftware.com/noticias/2011/10/31/roles-en-el-scrum

8. CARMONA, J.(2013). Metodologías de Desarrollo de Software. Obtenido

de

https://prezi.com/shjepp4eurim/metodologias-de-desarrollo-de-software/

9. Wikipedia, Colaboradores de Wikipedia [En línea]. – 29 de agosto del

2016.- 10 de septiembre del 2016 .-

https://es.wikipedia.org/wiki/Proceso_Unificado_Racional

10. CORDOBA, S.(2012). Rup- Obtenido de

https://prezi.com/pqecnnwpicel/rup/

11. RIVERA, B.(2010). Metodología Msf. Obtenido de

http://es.slideshare.net/bebeyom/metodologia-msf-4861508

12. PELLICER,P.(2015)¿Qué es el método de Scrum y para qué se utiliza?.

Obtenido de

http://www.emagister.com/blog/que-es-el-metodo-scrum-y-para-que-se-utiliza/

13. Wikipedia, Colaboradores de Wikipedia [En línea].- 10 de agosto del 2016 -

10 de septiembre de 2016.-

http://www.optimussoftware.com/noticias/2011/10/31/roles-en-el-scrum

https://prezi.com/shjepp4eurim/metodologias-de-desarrollo-de-software/

https://es.wikipedia.org/wiki/Proceso_Unificado_Racional

https://prezi.com/pqecnnwpicel/rup/

http://es.slideshare.net/bebeyom/metodologia-msf-4861508

http://www.emagister.com/blog/que-es-el-metodo-scrum-y-para-que-se-utiliza/

60

https://es.wikipedia.org/wiki/Scrum_(desarrollo_de_software)

14. PATER,L. (2013). Métodos agiles Programación Xtrema. Obtenido de

http://es.slideshare.net/LisPater1/metodologias-agiles-xp

15. Wikipedia, Colaboradores de Wikipedia [En línea].- 2 de septiembre del

2016 -10 de septiembre de 2016.-

https://es.wikipedia.org/wiki/Modelo_entidad-relaci%C3%B3n

16. Wikipedia, Colaboradores de Wikipedia [En línea].- 22 de noviembre del


https://es.wikipedia.org/wiki/Programaci%C3%B3n_por_capas

17. Wikipedia, Colaboradores de Wikipedia [En línea].- 31 de diciembre del


https://es.wikipedia.org/wiki/JavaServer_Faces

18. JTECH.ua.es. (2016). El ciclo de vida de JSF. [En línea] Recuperado de:

http://www.jtech.ua.es/j2ee/publico/jsf-2012-13/sesion03-apuntes.html

19. Global Mentoring. (2011). JavaServer Faces. [En línea] Recuperado de:

http://www.globalmentoring.com.mx/curso-

jsf/leccion2/PDFs/Curso_JSF_Teoria%20-%20leccion2.pdf

20. Wikipedia, Colaboradores de Wikipedia [En línea].- 8 de febrero del 2016 -


https://es.wikipedia.org/wiki/GlassFish

21. LOCKHART.T.(1996). Tutorial de PostgreSQL. Obtenido de

http://palomo.usach.cl/Docs/postgres/Postgres-Tutorial.pdf

22. Wikipedia, Colaboradores de Wikipedia [En línea].- 27 de octubre del 2015 -


https://es.wikipedia.org/wiki/Historias_de_usuario

https://es.wikipedia.org/wiki/Scrum_(desarrollo_de_software)

http://es.slideshare.net/LisPater1/metodologias-agiles-xp

https://es.wikipedia.org/wiki/Modelo_entidad-relaci%C3%B3n

https://es.wikipedia.org/wiki/Programaci%C3%B3n_por_capas

https://es.wikipedia.org/wiki/JavaServer_Faces

http://www.jtech.ua.es/j2ee/publico/jsf-2012-13/sesion03-apuntes.html

http://www.globalmentoring.com.mx/curso-jsf/leccion2/PDFs/Curso_JSF_Teoria%20-%20leccion2.pdf

http://www.globalmentoring.com.mx/curso-jsf/leccion2/PDFs/Curso_JSF_Teoria%20-%20leccion2.pdf

https://es.wikipedia.org/wiki/GlassFish

http://palomo.usach.cl/Docs/postgres/Postgres-Tutorial.pdf

https://es.wikipedia.org/wiki/Historias_de_usuario

61

ANEXOS

62

7. Anexo A

Manual de Instalación de Postgres

Prerrequisitos

Comprobar que se tenga instalado el Java JDK 8

Figura A 1. Instalación de Java

Ambiente de instalación:

Memoria de 8gb

Disco duro de 50gb

CPU de 4 núcleos a 2.0GHz

Tarjeta de red

Conexión a la red de Bomberos para utilizar el Directorio Activo y la base de

datos

63

Instalación de Postgres 9.3

Acceder a un navegador e ingresar la siguiente url:

www.postgresql.org/download/windows

Figura A 2. Ingreso y descarga del instalador del programa Postgres

Seleccionamos el modo de instalación

Figura A 3. Modo de instalación

Ejecutamos el archivo descargado

Figura A 4. Ejecución de archivo descargado

http://www.postgresql.org/download/windows

64

Colocamos la dirección o el directorio de instalación en donde se va a guardar el

programa

Figura A 5. Directorio de instalación

Pulsamos siguiente e ingresamos la contraseña del usuario postgres

Figura A 6. Ingreso de la contraseña de postgres

65

Aparecerá una ventana en la que pedirá el puerto con el cual se comunicará el programa,

dejamos el mismo número de puerto que viene por defecto.

Figura A 7 Puerto por defecto para la comunicación del programa

Aplicación Postgres instalada

Figura A 8 Aplicación instalada

66

ANEXO B

Manual de configuración de Postgres

Para conectarnos con el servidor Postgres introducimos la contraseña que elegimos

durante el proceso de instalación

Figura B 1 Introducción de la contraseña

Procedemos a restaurar la base de datos inventario, ejecutando los scripts y cargamos

los registros de la configuración inicial

Figura B 2 Proceso de Restauración de la Base de Datos Inventario

67

Procedemos a restaurar la base de datos de personas, ejecutando los scripts y cargamos

los registros de la configuración inicial

Figura B 3 Proceso de restauración de la Base de Datos Interna Personas

68

ANEXO C

Manual de instalación de NetBeans IDE 8

Descargar netbeans de la página oficial https://netbeans.org/downloads/8.0/index.html

Figura C 1 Descarga del Instalador de Netbeans

Ejecutamos el archivo descargado, se abrirá la ventana en donde nos indicará que el instalador

se está configurando

Figura C 2 Configuración del instalador de netbeans ide 8

69

Aceptamos el acuerdo de licencia e instalamos JUNIT y presionamos siguiente

Figura C 3 Acuerdo de licencia e instalación de herramientas básicas

En la siguiente ventana aparece la ruta de instalación del Ide de Netbeans y el JDK que

utilizará.

Figura C 4 Ruta de instalación de netbeans por defecto

70

A continuación se instalará el servidor de aplicaciones GlassFish.

Figura C 5. Instalación del servidor de aplicaciones

Seguiremos con el proceso de instalación, desactivaremos la casilla de "Check for Updates"

Figura C 6. Proceso de Instalación de Netbeans

71

Finalmente la aplicación ha sido instalada

Figura C 7. Finalización de la instalación de Netbeans

72

ANEXO D

Conexión entre el servidor de aplicaciones web con el servidor de base de datos

Configuración de pools de la Base de datos en Glassfish 4.0

Figura D 1. Creación de jdbc y pools

Conexión a base de datos desde IDE desarrollo Netbeans 8.0

Figura D 2. Conexión con la base de datos

73

Agregar librerías necesarias al proyecto

Figura D 3. Agregar librerías en el proyecto

Configuración de jdbc y pools

Figura D 4. Configuración del pool de inventario

74

Verificamos la conexión con la Base de Datos de Postgres

Figura D 5. Prueba de conexión con la base de datos inventario

Creamos el jdbc para la base datos Distributivo

Figura D 6. Creación del jdbc para la base de datos Distributivo

75

Procedemos a cargar el ejecutable de la aplicación

Figura D 7. Ejecutable de la aplicación

Desplegamos la aplicación

Figura D 8. Aplicación desplegada correctamente en el navegador

76

ANEXO E

Manual de despliegue de la aplicación

El manual de inventario de equipos tecnológicos para la Dirección de Tecnología del Cuerpo de

Bomberos del Distrito Metropolitano de Quito, permite visualizar de manera perceptible su

entorno gráfico y su operatividad, ya que en el se explica detalladamente los pasos que deben

seguir para el manejo general de las estructuras de las pantallas.

El sistema de Gestión de Inventario de Equipos Tecnológicos fue creado con el objetivo de

brindar facilidades a los especialistas de la Dirección de Tecnología del Cuerpo de Bomberos

del Distrito Metropolitano de Quito para consultar la situación de los equipos informáticos, su

estado actual, su custodio, su tiempo de vida útil.

Es de mucha importancia consultar el manual antes y/o durante la visualización de las pantallas,

ya que lo guiará paso a paso en el manejo de las funciones.

Con el fin de facilitar la comprensión del manual, se incluye gráficos explicativos.

Uso del Sistema

Para ingresar al sistema de Gestión debemos tener en cuenta algunos aspectos que a

continuación se detalla:

1.- El usuario especialista debe estar creado dentro del sistema de acuerdo al perfil asignado, la

aplicación se integra con el active directory de la institución razón por la cual el técnico utilizará

el usuario y contraseña creados en el directorio activo.

Ingreso al Sistema

El acceso al sistema de Gestión de Inventarios se realizará en el navegador predeterminado

Mozilla Firefox cliqueando la siguiente url http://localhost:8080/inventarioCBDMQ-war/

http://localhost:8080/inventarioCBDMQ-war/

77

Figura E 1. Pantalla de Inicio de Sesión de la Aplicación

Se debe introducir el usuario y contraseña para luego presionar Iniciar sesión.

Como se puede observar al Iniciar la sesión se observa el perfil asociado al especialista y las

diferentes opciones dentro del Menú.

Figura E 2. Administración de Inventario

Menú

Permite al usuario ingresar a las diferentes opciones disponibles en la aplicación

78

Administración del sistema

Acceso a las diferentes funcionalidades de la aplicación

Figura E 3. Menú de Administración de la Aplicación

Gestión de usuarios

Es el módulo en donde se crea y modifica los usuarios asignandoles el perfil deacuerdo a sus

funciones.

Figura E 4. Registro de usuarios en el sistema deacuerdo al perfil asignado

79

Gestión de marcas

Es el módulo en donde se crea las marcas de los equipos informáticos existentes en la

Institución.

Figura E 5. Registro de marcas de equipos informáticos.

80

Gestión de ítems

Es el módulo en el cual se registra el ítem de acuerdo a los parámetros solicitados. Al

seleccionar el tipo de ítem observamos que se encuentra una lista previamente establecida de los

equipos informáticos, dependiendo del tipo se despliega diferentes parámetros para su ingreso y

asignación al custodio, la lista de los custodios es la información extraída de la Base de Datos

Distributivo en donde se obtiene su número de cédula y a que estación o distrito pertenece.

Figura E 6. Registro de Items

Documents

UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE … · BOMBEROS DEL DISTRITO METROPOLITANO DE QUITO, autorizo a la Universidad Central del Ecuador hacer uso de todos los contenidos que