UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE … · BOMBEROS DEL DISTRITO METROPOLITANO DE QUITO,...
Transcript of UNIVERSIDAD CENTRAL DEL ECUADOR FACULTAD DE … · BOMBEROS DEL DISTRITO METROPOLITANO DE QUITO,...
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:
IMPLEMENTACIÓN DE UN SISTEMA DE INVENTARIO DE EQUIPOS
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
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 6 Historia de usuario 3 ..................................................................................................... 31
Tabla 7 Historia de usuario 4 ..................................................................................................... 31
Tabla 8 Historia de usuario 5 ..................................................................................................... 31
Tabla 9 Historia de usuario 6 ..................................................................................................... 31
Tabla 10 Historia de usuario 7 ................................................................................................... 32
Tabla 11 Historia de usuario 8 ................................................................................................... 32
Tabla 12 Historia de usuario 9 ................................................................................................... 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 26 Historia de usuario- 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 30 Historia de usuario- 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
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
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
HISTORIAS DE USUARIOS
Número: 2 Usuario: Administrador de la aplicación
Nombre Historia: Registro de especialistas
Descripción: Permitirá el registro, modificación y deshabilitación de especialistas en la aplicación web.
31
Tabla 6 Historia de usuario 3
HISTORIAS DE USUARIOS
Número: 3 Usuario: Administrador de la aplicación
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.
Tabla 7 Historia de usuario 4
HISTORIAS DE USUARIOS
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.
Tabla 8 Historia de usuario 5
HISTORIAS DE USUARIOS
Número: 5 Usuario: Especialistas
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.
Tabla 9 Historia de usuario 6
HISTORIAS DE USUARIOS
Número: 6 Usuario: Especialistas
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.
Tabla 10 Historia de usuario 7
HISTORIAS DE USUARIOS
Número: 7 Usuario: Especialistas
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.
Tabla 11 Historia de usuario 8
HISTORIAS DE USUARIOS
Número: 8 Usuario: Especialistas
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.
Tabla 12 Historia de usuario 9
HISTORIAS DE USUARIOS
33
Número: 9 Usuario: Especialistas
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.
Tabla 13 Historia de usuario 10
HISTORIAS DE USUARIOS
Número: 10 Usuario: Especialistas
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.
Tabla 14 Historia de usuario 11
HISTORIAS DE USUARIOS
Número: 11 Usuario: Especialistas
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
Se realizó un análisis de las funcionalidades y procesos que serán implementados.
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.
A continuación identificamos las historias de usuarios.
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
A continuación se diagrama los casos de uso con sus principales actores
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
El Backlog del sprint se muestra en la siguiente tabla:
Tabla 24 Backlog Sprint Modulo de Autenticación
Id Historia Número
Tarea
Nombre de la
tarea
Asignado Estimado(horas)
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
Se realizó un análisis de las funcionalidades y procesos que serán implementados.
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.
A continuación identificamos las historias de usuarios.
Tabla 26 Historia de usuario- sprint 3
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
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
A continuación se diagrama los casos de uso con sus principales actores
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
Usuarios de la aplicación
Objetivo Permitir crear, modificar, y asignar
equipos informáticos.
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 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
El Backlog del sprint se muestra en la siguiente tabla:
Tabla 28 Backlog Sprint Modulo de Gestión
Id Historia Número
Tarea
Nombre de la
tarea
Asignado Estimado(horas)
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
Se realizó un análisis de las funcionalidades y procesos que serán implementados.
Tabla 29 Requerimientos Funcionales/No Funcionales del Sprint 4
A continuación identificamos las historias de usuario.
Tabla 30 Historia de usuario- sprint 4
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
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
2 Gestión de reporte 800 La aplicación
permitirá realizar
consultas y reportes
de los equipos que
se encuentran
registrados.
Análisis
A continuación se diagrama los casos de uso con sus principales actores
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
Usuarios de la aplicación
Objetivo Permitir gestionar diferentes reportes
de la aplicación.
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 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
El Backlog del sprint se muestra en la siguiente tabla:
Tabla 32 Backlog Sprint Modulo de Autenticación
Id Historia Número
Tarea
Nombre de la
tarea
Asignado Estimado(horas)
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
campo Tipo de dato Tamaño Llave Descripción
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
campo Tipo de dato Tamaño Llave Descripción
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.-
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
2015 -10 de septiembre de 2016.-
https://es.wikipedia.org/wiki/Programaci%C3%B3n_por_capas
17. Wikipedia, Colaboradores de Wikipedia [En línea].- 31 de diciembre del
2015 -10 de septiembre de 2016.-
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 -
10 de septiembre de 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 -
10 de septiembre de 2016.-
https://es.wikipedia.org/wiki/Historias_de_usuario
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
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/
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