Embed Size (px)
Citation preview
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS
COMPUTACIONALES
DESARROLLO DE UN SISTEMA DE GESTIÓN DE
REQUERIMIENTOS INFORMÁTICOS PARA LA
FACULTAD DE CIENCIAS MATEMÁTICAS
Y FÍSICAS DE LA UNIVERSIDAD
DE GUAYAQUIL
PROYECTO DE TITULACIÓN
Previa a la obtención del Título de:
INGENIERO EN SISTEMAS COMPUTACIONALES
AUTOR:
Jorge Andrés Martínez Álvarez
TUTOR: Ing. Darwin Cercado Barragán, Mgs.
GUAYAQUIL – ECUADOR 2017
II
REPOSITORIO NACIONAL EN CIENCIAS Y TECNOLOGÍA
FICHA DE REGISTRO DE TESIS
TÍTULO “DESARROLLO DE UN SISTEMA DE GESTIÓN DE REQUERIMIENTOS
INFORMÁTICOS PARA LA FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
DE LA UNIVERSIDAD DE GUAYAQUIL”
REVISORES:
INSTITUCIÓN: Universidad de Guayaquil FACULTAD:
Ciencias Matemáticas y Físicas
CARRERA: Ingeniería en Sistemas Computacionales
FECHA DE PUBLICACIÓN: Septiembre
del 2017 N° DE PÁGS.:
ÁREA TEMÁTICA: Desarrollo de aplicación web
PALABRAS CLAVES: Automatización, Requerimiento, Gestión, Scrum
RESUMEN: Desarrollo de un sistema web para gestionar los requerimientos
informáticos de los Departamentos de Hardware y Software de las Carreras de la
Facultad de Ciencias Matemáticas y Físicas de La Universidad de Guayaquil.
N° DE REGISTRO (en base de datos): N° DE CLASIFICACIÓN:
Nº
DIRECCIÓN URL (tesis en la web):
ADJUNTO PDF
SI
X
NO
CONTACTO CON AUTORES:
Jorge Andrés Martínez Álvarez
Teléfono:
0994962790
E-mail:
CONTACTO DE LA INSTITUCIÓN
Universidad de Guayaquil
Nombre: Ab. Juan Chávez Atocha
Teléfono: 2307729
III
CERTIFICADO DE ACEPTACIÓN DEL TUTOR
En mi calidad de Tutor del trabajo de titulación, “DESARROLLO DE UN SISTEMA
DE GESTIÓN DE REQUERIMIENTOS INFORMÁTICOS PARA LA FACULTAD
DE CIENCIAS MATEMÁTICAS Y FÍSICAS DE LA UNIVERSIDAD DE
GUAYAQUIL, elaborado por el señor Jorge Andrés Martínez Alvarez, alumno
no titulado de la Carrera de Ingeniería en Sistemas Computacionales, Facultad
de Ciencias Matemáticas y Físicas de la Universidad de Guayaquil, previo a la
obtención del Título de Ingeniero en Sistemas, me permito declarar que luego de
haber orientado, estudiado y revisado, la Apruebo en todas sus partes.
Atentamente
ING. DARWIN CERCADO BARRAGÁN, MGS.
TUTOR
IV
DEDICATORIA
Dedico este trabajo de titulación a todas
esas personas que me brindaron su
apoyo a lo largo de este proceso.
Hago una mención especial a Andrea
Carvajal Escobar, mi novia la cual
estuvo siempre apoyándome.
Jorge A. Martínez Álvarez
V
AGRADECIMIENTO
Agradezco a mi novia Andrea Carvajal
Escobar, mi familia quienes estuvieron
presentes dándome fuerzas para poder
culminar este proyecto.
De igual manera debo decir que sin el
apoyo del Abg, Juan Chávez Atocha y
el Ing. Harry Luna Aveiga MSc. no
hubiera podido alcanzar esta meta, por
este motivo les agradezco
infinitamente.
Jorge A. Martínez Álvarez
VI
TRIBUNAL PROYECTO DE TITULACIÓN
Ing. Eduardo Santos Baquerizo, M.Sc.
DECANO DE LA FACULTAD CIENCIAS MATEMATICAS Y
FISICAS
Ing. Abel Alarcón Salvatierra, Mgs.
DIRECTOR DE LA CARRERA DE INGENIERIA EN SISTEMAS
COMPUTACIONALES
Lcda. Viviana Pinos Medrano, Mgs.
PROFESOR REVISOR DEL ÁREA TRIBUNAL
Ing. Oscar Benavides Burgos M.Sc. PROFESOR REVISOR DEL ÁREA
TRIBUNAL
Ing. Darwin Cercado Barragán, Mgs.
PROFESOR TUTOR DEL PROYECTO DE TITULACION
Ab. Juan Chávez Atocha, Esp. SECRETARIO
VII
DECLARACIÓN EXPRESA
“La responsabilidad del contenido de este
Proyecto de Titulación, me corresponden
exclusivamente; y el patrimonio intelectual de
la misma a la UNIVERSIDAD DE
GUAYAQUIL”
Jorge Andrés Martínez Álvarez
VIII
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
DESARROLLO DE UN SISTEMA DE GESTIÓN DE
REQUERIMIENTOS INFORMÁTICOS PARA LA
FACULTAD DE CIENCIAS MATEMÁTICAS
Y FÍSICAS DE LA UNIVERSIDAD
DE GUAYAQUIL
Proyecto de Titulación que se presenta como requisito para optar por el
título de INGENIERO EN SISTEMAS COMPUTACIONALES
Autor: Jorge Andrés Martínez Álvarez
C.I. 1204897886
Tutor: Ing. Darwin Cercado Barragán, Mgs.
Guayaquil, Diciembre del 2017
IX
CERTIFICADO DE ACEPTACIÓN DEL TUTOR
En mi calidad de Tutor del proyecto de titulación, nombrado por el Consejo
Directivo de la Facultad de Ciencias Matemáticas y Físicas de la
Universidad de Guayaquil.
CERTIFICO:
Que he analizado el Proyecto de Titulación presentado por el
estudiante Jorge Andrés Martínez Álvarez, como requisito previo para optar
por el título de Ingeniero en Sistemas Computacionales cuyo problema es:
DESARROLLO DE UN SISTEMA DE GESTIÓN DE REQUERIMIENTOS
INFORMÁTICOS PARA LA FACULTAD DE CIENCIAS MATEMÁTICAS Y
FÍSICAS DE LA UNIVERSIDAD DE GUAYAQUIL.
Considero aprobado el trabajo en su totalidad.
Presentado por:
Jorge Andrés Martínez Álvarez C.I. 1204897886
Tutor: Ing. Darwin Cercado Barragán, Mgs.
Guayaquil, Diciembre del 2017
X
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
Autorización para Publicación de Proyecto de Titulación en
Formato Digital
1. Identificación del Proyecto de Titulación
Nombre Alumno: Jorge Andrés Martínez Álvarez
Dirección: Cdla. Alborada 13ava etapa Mz. 27 V. 13
Teléfono: 0994962790 E-mail: [email protected]
Facultad: Ciencias Matemáticas y Físicas
Carrera: Ingeniería en Sistemas Computacionales
Proyecto de titulación al que opta: Ingeniero en Sistemas Computacionales Profesor tutor: Ing. Darwin Cercado Barragán Mgs.
Título del Proyecto de titulación: Desarrollo de un sistema de gestión de requerimientos informáticos para la Facultad de Ciencias Matemáticas y Físicas de la Universidad de Guayaquil
Tema del Proyecto de Titulación: Automatización, Requerimiento, Gestión, Scrum, Hardware, Software
2. Autorización de Publicación de Versión Electrónica del Proyecto de Titulación
A través de este medio autorizo a la Biblioteca de la Universidad de Guayaquil y a la Facultad de Ciencias Matemáticas y Físicas a publicar la versión electrónica de este Proyecto de titulación.
XI
Publicación electrónica:
Inmediata X Después de 1 año
Firma Alumno:
3. Forma de envío:
El texto del proyecto de titulación debe ser enviado en formato Word, como archivo .Doc. O .RTF y .Puf para PC. Las imágenes que la acompañen pueden ser: .gif, .jpg o .TIFF.
DVDROM X CDROM
XII
ÍNDICE GENERAL
CERTIFICADO DE ACEPTACIÓN DEL TUTOR .................................................. III
DEDICATORIA ....................................................................................................... IV
AGRADECIMIENTO ............................................................................................... V
ÍNDICE GENERAL ................................................................................................ XII
ÍNDICE DE TABLAS ...........................................................................................XVII
ÍNDICE DE GRÁFICOS .....................................................................................XVIII
RESUMEN ............................................................................................................ XX
ABSTRACT ..........................................................................................................XXI
INTRODUCCIÓN .................................................................................................. 22
CAPÍTULO I .......................................................................................................... 25
EL PROBLEMA ..................................................................................................... 25
PLANTEAMIENTO DEL PROBLEMA .................................................................. 25
Ubicación del Problema en un Contexto .............................................................. 25
Situación Conflicto Nudos Críticos ....................................................................... 26
Causas y Consecuencias del Problema ............................................................... 26
Delimitación del Problema .................................................................................... 27
Formulación del Problema .................................................................................... 27
Evaluación del Problema ...................................................................................... 28
OBJETIVOS .......................................................................................................... 30
OBJETIVO GENERAL ...................................................................................... 30
OBJETIVOS ESPECÍFICOS ............................................................................. 30
ALCANCES DEL PROBLEMA ............................................................................. 32
XIII
METODOLOGÍA ................................................................................................... 32
JUSTIFICACIÓN E IMPORTANCIA .................................................................... 34
CAPITULO II ......................................................................................................... 36
MARCO TEÓRICO ............................................................................................... 36
ANTECEDENTES DEL ESTUDIO........................................................................ 36
Caso de estudio para la automatización de la gestión de solicitudes de
servicios y mantenimiento de equipos en La Universidad Agraria de La Habana
........................................................................................................................... 37
Caso de estudio acerca de la implementación de un sistema de mesa de
ayuda informático en el gobierno autónomo descentralizado de la provincia de
Esmeraldas ........................................................................................................ 39
Caso de estudio de Propuesta de un Service Desk para mejorar los procesos
de resolución de incidencias a través de ITIL................................................... 40
Caso de estudio ITAKA: Gestión Interactiva del Conocimiento en
Organizaciones de Desarrollo de Software ...................................................... 40
Caso de estudio desarrollo e implantación de sistema de control de inventarios
para la Facultad de Ciencias de La Escuela Politécnica Nacional .................. 41
FUNDAMENTACIÓN TEÓRICA ........................................................................... 42
Sistemas de gestión .......................................................................................... 42
Sistemas de gestión de requerimientos ............................................................ 44
Automatización de Procesos ............................................................................. 45
Tecnologías de la Información .......................................................................... 48
Mesa de ayuda .................................................................................................. 50
Gestión de Inventario ........................................................................................ 62
Herramientas para construcción de software ................................................... 65
XIV
FUNDAMENTACIÓN LEGAL ............................................................................... 82
PREGUNTA CIENTÍFICA A CONTESTARSE ..................................................... 84
DEFINICIONES CONCEPTUALES ...................................................................... 84
CAPÍTULO III ........................................................................................................ 87
PROPUESTA TECNOLÓGICA ............................................................................ 87
Análisis de factibilidad ........................................................................................... 87
Factibilidad Operacional .................................................................................... 88
Factibilidad técnica ............................................................................................ 89
Factibilidad Legal............................................................................................... 94
Factibilidad Económica ..................................................................................... 94
Etapas de la metodología del proyecto ................................................................ 97
1. Definición de roles ...................................................................................... 97
2. Pila del Producto (Product Backlog) .......................................................... 98
3. Planificación de Sprints ............................................................................ 101
4. Sprint 1 ..................................................................................................... 103
5. Sprint 2 ..................................................................................................... 112
6. Sprint 3 ..................................................................................................... 121
Entregables del proyecto .................................................................................... 129
Criterios de Validación de la Propuesta ............................................................. 129
CAPÍTULO IV ...................................................................................................... 130
CRITERIOS DE ACEPTACIÓN DEL PRODUCTO O SERVICIO ..................... 130
INFORME DE PRUEBAS ................................................................................... 132
RESULTADOS .................................................................................................... 132
CONCLUSIONES ............................................................................................... 133
RECOMENDACIONES ....................................................................................... 134
XV
ANEXOS ............................................................................................................. 135
ANEXO #1: GUIÓN DE LA ENTREVISTA REALIZADA A LOS ENCARGADOS
DE LOS DEPARTAMENTOS DE HARDWARE Y SOFTWARE DE LAS
CARRERAS DE LA FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS .. 136
ANEXO #2: ACTAS DE ENTREVISTAS ............................................................ 139
ANEXO #3: MODELO ENTIDAD RELACION DE LA BASE DE DATOS DEL
SISTEMAS DE GESTION DE REQUERIMIENTOS INFORMATICOS ............. 142
ANEXO #4: INFORME DE PRUEBAS ............................................................... 144
BIBLIOGRAFÍA ................................................................................................... 150
XVI
ABREVIATURAS
UG Universidad de Guayaquil
FCMF Facultad de Ciencias Matemáticas y Físicas
CISC Carrera de Ingeniería en Sistemas Computacionales
ITIL Information Technology Infrastructure Library
TI Tecnología de la información
ASP Active Server Pages
HU Historia de Usuario
BD Base de Datos
SGRI Sistema de Gestión de Requerimientos Informáticos
XVII
ÍNDICE DE TABLAS
TABLA N°. 1: Requisitos para desarrollo del sistema ......................................... 91
TABLA N°. 2: Requisitos de servidor donde se alojará la aplicación ................. 91
TABLA N°. 3: Requisitos de servidor donde se alojará la aplicación ................. 93
TABLA N°. 4: Matriz de análisis de recursos económicos .................................. 94
TABLA N°. 5: Pila del producto del Sistema de Gestión de requerimientos ...... 98
TABLA N°. 6: Pila del Sprint 1 ........................................................................... 103
TABLA N°. 7: Lista de tareas del Sprint 1 ......................................................... 105
TABLA N°. 8: Pila del Sprint 2 ........................................................................... 112
TABLA N°. 9: Lista de tareas del Sprint 2 ......................................................... 113
TABLA N°. 10: Pila del Sprint 3 ......................................................................... 121
TABLA N°. 11: Lista de tareas del Sprint 3 ....................................................... 123
TABLA N°. 12: Criterios de aceptación del producto ........................................ 130
XVIII
ÍNDICE DE GRÁFICOS
GRÁFICO N°. 1: Árbol de Problemas.................................................................. 28
GRÁFICO N°. 2: Módulos del software SGMANTE ............................................ 38
GRÁFICO N°. 3: Gestión de cambios de requerimientos ................................... 45
GRÁFICO N°. 4: Nivel de automatización de la maquinaria y equipo de producción
de las PYMIS de la ciudad de Cuenca ................................................................. 47
GRÁFICO N°. 5: Diagrama del soporte al servicio TI basado en ITIL ................ 53
GRÁFICO N°. 6: Flujo de escalado de niveles.................................................... 56
GRÁFICO N°. 7: Flujo básico del proceso de gestión de incidencias ................ 58
GRÁFICO N°. 8: Desarrollo de la Gestión de Conocimiento basado en ITIL® V3
............................................................................................................................... 60
GRÁFICO N°. 9: Interacción de la gestión del inventario de IT .......................... 63
GRÁFICO N°. 10: Esquema básico de una aplicación web ............................... 66
GRÁFICO N°. 11: Arquitectura tres capas .......................................................... 70
GRÁFICO N°. 12: Funcionamiento de las páginas ASP ..................................... 76
GRÁFICO N°. 13: Funcionamiento de las páginas ASP.NET ............................ 77
GRÁFICO N°. 14: Estructura de un documento HTML con CSS ....................... 78
GRÁFICO N°. 15: Componentes de SQL Server ................................................ 80
GRÁFICO N°. 16: Visualización de organización del proyecto en el Trello ..... 103
GRÁFICO N°. 17: Estado inicial del Sprint 1 en el Trello ................................. 108
GRÁFICO N°. 18: Estado del tablero al finalizar semana 1 del Sprint 1 en el Trello
............................................................................................................................. 108
GRÁFICO N°. 19: Estado del tablero al finalizar semana 2 del Sprint 1 en el Trel
............................................................................................................................. 109
GRÁFICO N°. 20: Control de usuarios del sistema .......................................... 110
GRÁFICO N°. 21: Control de permisos del sistema ......................................... 110
GRÁFICO N°. 22: Control de tipos de requerimientos ...................................... 111
GRÁFICO N°. 23: Ingreso de equipos informáticos (Hardware y Software) .... 111
GRÁFICO N°. 24: Estado inicial del Sprint 2 en el Trello ................................. 115
GRÁFICO N°. 25: Estado del tablero al finalizar semana 1 del Sprint 2 en el Trello
............................................................................................................................. 116
XIX
GRÁFICO N°. 26: Estado del tablero al finalizar semana 1 del Sprint 2 en el Trello
............................................................................................................................. 116
GRÁFICO N°. 27: Bandeja de requerimientos Administrador .......................... 117
GRÁFICO N°. 28: Asignación de Técnico ......................................................... 117
GRÁFICO N°. 29: Bandeja de requerimientos Técnico .................................... 118
GRÁFICO N°. 30: Atención de requerimiento Técnico ..................................... 119
GRÁFICO N°. 31: Bandeja de requerimientos Usuario solicitante ................... 119
GRÁFICO N°. 32: Estado requerimiento Usuario solicitante ............................ 120
GRÁFICO N°. 33: Consulta base de conocimientos ......................................... 120
GRÁFICO N°. 34: Ingreso de conocimiento ...................................................... 121
GRÁFICO N°. 35: Estado inicial del Sprint 3 en el Trello ................................. 125
GRÁFICO N°. 36: Estado del tablero al finalizar semana 1 del Sprint 3 en el Trello
............................................................................................................................. 126
GRÁFICO N°. 37: Estado del tablero al finalizar semana 2 del Sprint 3 en el Trello
............................................................................................................................. 127
GRÁFICO N°. 38: Control de herramientas ...................................................... 128
GRÁFICO N°. 39: Reporte de requerimientos .................................................. 128
XX
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
DESARROLLO DE UN SISTEMA DE GESTIÓN DE
REQUERIMIENTOS INFORMÁTICOS PARA LA FACULTAD DE CIENCIAS MATEMÁTICAS
Y FÍSICAS DE LA UNIVERSIDAD DE GUAYAQUIL
Resumen
El presente proyecto se origina como una propuesta para automatizar los
procesos de atención y gestión de solicitudes de requerimientos informáticos del
Departamento de Hardware y Software de las Carreras de La Facultad de Ciencias
Matemáticas y Físicas de La Universidad de Guayaquil. A través de la información
recolectada por medio de las entrevistas a los encargados de los departamentos,
se logró identificar procedimientos manuales que provocan atrasos e
inconvenientes en la atención de solicitudes realizadas por las áreas de las
carreras involucradas. Debido a que este proyecto pertenece a la rama de la
informática de desarrollo de software y gracias al valor que aporta su flexibilidad
en la adaptación de cambios emergentes, se adoptó la metodología SCRUM para
la elaboración de esta propuesta. La solución planteada consiste en un sistema
web que permite ingresar las solicitudes de requerimientos por parte de las áreas
solicitantes, registrarlas en la base de datos y que sean atendidas por los
departamentos de Hardware y Software de cada carrera respectivamente. Como
un valor agregado al proyecto, se ha incorporado una base de conocimientos y
una opción para registrar los recursos de hardware y software, de los cuales son
responsables de administrar el mismo departamento.
Autor: Jorge Andrés Martínez Álvarez
Tutor: Ing. Darwin Cercado Barragán
XXI
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
DEVELOPMENT OF A COMPUTER REQUIREMENTS
MANAGEMENT SYSTEM FOR THE FACULTY OF MATHEMATICAL AND PHYSICAL SCIENCES
OF THE UNIVERSITY OF GUAYAQUIL
Abstract
The project arises as a proposal to automate the attention and management
processes of computer requirements requests, belonging to the Department of
Hardware and Software at the Faculty of Mathematical and Physical Sciences
Careers to the Guayaquil University. The information collected through the
interviews with the department heads, was possible to identify manual procedures
that cause delays and inconveniences in the attention of requests made by the
areas of the careers involved. For the reason that this project belongs to the branch
of computer software development and thanks to the value of its flexibility in
adapting to emerging changes, the SCRUM methodology was adopted for the
elaboration of this proposal. The proposed solution consists of a web system that
allows to enter the requests of requirements by the applicant areas, register them
in the database and that are attended by the departments of Hardware and
Software of each race respectively. As a value added to the project has been
incorporated a knowledge base and an option to record the hardware and software
resources, which are responsible for managing the same department.
Author: Jorge Andrés Martínez Álvarez
Tutor: Ing. Darwin Cercado Barragán
22
INTRODUCCIÓN
En pleno año 2017, la utilización de dispositivos y aplicaciones informáticas, se han
convertido en la principal herramienta de trabajo para las distintas áreas de las
instituciones educativas, debido al proceso de innovación que se ha venido realizando
en el transcurso de los años en el país. En este tiempo, la información es receptada
a través páginas web informativas, los alumnos se matriculan, revisan sus
calificaciones y realizan otros procesos a través del Internet. Debido a la relevancia e
importancia de esta situación, es de vital importancia mantener operativos todos los
elementos informáticos que involucran estos procesos para no detener las actividades
del sistema educativo. Esta responsabilidad, recae en los Departamentos de
Hardware y Software de las Carreras de la Facultad de Matemáticas y Físicas de La
Universidad de Guayaquil, los cuales requieren la automatización de procesos dentro
del flujo de trabajo actual para la atención de requerimientos solicitados desde las
diferentes áreas de las carreras de la FCMF.
Esta propuesta tecnológica, plantea la creación de un sistema web que permita
registrar las solicitudes de requerimientos, para que sean gestionadas de forma
eficiente por el personal del Departamento de Hardware y Software. De esta manera,
se logrará optimizar los tiempos de atención y resolución de requerimientos
informáticos.
De igual manera se plantea la integración de una base de conocimientos, como una
ayuda para la centralización de las experiencias en la resolución de los requerimientos
por parte de los técnicos; el objetivo es facilitar la capacitación del personal en las
labores diarias que se le podrían asignar a los técnicos, agilizando la implementación
de soluciones basadas en registros pasados.
Adicionalmente el control de los recursos de hardware y software de las carreras,
representa una responsabilidad netamente de este mismo departamento, por lo que
23
la presente herramienta contempla una ayuda para administrar desde esta misma
aplicación, estos recursos.
A continuación se presenta la estructura general de los cuatro capítulos que abarca
el presente proyecto:
Capítulo I. Aborda principalmente el planteamiento del problema; en el que se
identifica la ubicación del problema, los motivos que lo originan, determinando
sus causas y consecuencias. Asimismo, se establecen los objetivos, alcances
e importancia del proyecto junto con la metodología que se va a emplear.
Capítulo II. Mencionan los estudios previos que se han realizado acerca de
los sistemas de gestión de requerimientos y las teorías en las cuales nos
hemos basado para el desarrollo de la propuesta. De igual modo, dentro de
este apartado se revisa las normas legales que fundamentan este proyecto.
Capítulo III. Evalúa la factibilidad de la presente propuesta, basada en cuatro
aspectos: Operativo, Técnico, Legal y Económico. Se describe las etapas de
la metodología seleccionada y se especifican los entregables que generará el
proyecto planteado.
Capítulo IV. Finalmente se establecen los criterios de aceptación del
producto, así como las conclusiones y recomendaciones que se han obtenido
con el desarrollo de la propuesta.
24
25
CAPÍTULO I
EL PROBLEMA
PLANTEAMIENTO DEL PROBLEMA
Ubicación del Problema en un Contexto
A nivel mundial la tecnología se ha convertido en un recurso indispensable en todas
las áreas de una institución, en nuestro país Ecuador, la situación no es indiferente.
Es así que esta condición, ha generado que diariamente los distintos departamentos
administrativos de las Carreras de la Facultad de Ciencias Matemáticas y Físicas de
la Universidad de Guayaquil, generen solicitudes de atención de requerimientos
informáticos vinculados a distintos tipos de requerimientos solicitados, tales como,
desarrollo, soporte técnico, gestión de proyectos o infraestructura.
La gestión y atención de los requerimientos ingresados competen específicamente al
Departamento de Hardware y Software de cada carrera, los cuales mantienen este
control en archivos de Excel. Este mecanismo de administración, evidentemente no
es eficiente, debido a que vuelve los procesos de gestión de requerimientos más
lentos y la mayoría de las veces no son atendidas de forma oportuna.
Esta problemática, produce malestar para el personal y alumnado de la carreras que
conforman la Facultad de Ciencias Matemáticas y Físicas de La Universidad de
Guayaquil, los cuales concuerdan que los recursos informáticos constituyen una parte
esencial y crítica dentro de todos los procesos que actualmente se llevan en la entidad
educativa, ya que si se avería un equipo del departamento de Contabilidad, produce
la demora en la elaboración de los estados financieros para la toma de decisiones o
si se requiere una actualización del sitio web por parte del departamento informático
y no se realiza a tiempo, ocasiona la desinformación de los usuarios.
26
Situación Conflicto Nudos Críticos
La Facultad de Matemáticas y Físicas realiza la captación de requerimientos y el
registro de los equipos informáticos de manera manual, almacenados en hojas de
cálculo.
Al realizar estos procesos de manera rudimentaria, la resolución de los mismos puede
tomar más tiempo de lo esperado, lo cual se torna un proceso molesto tanto para el
departamento de informática de las carreras involucradas, así como para los usuarios
solicitantes.
Causas y Consecuencias del Problema
Causas
Falta de gestión de los requerimientos informáticos
Registro del recurso informático de manera manual
Postergación de la atención de requerimientos prioritarios
Falta de bitácora de resolución de requerimiento
Consecuencias
Tiempo de respuesta a requerimientos ineficientes
Inconsistencia en el control de equipos informáticos
Malestar y quejas de parte del usuario
Lentitud de resolución de requerimientos
27
Delimitación del Problema
Campo: Apoyo Universitario
Área: Desarrollo de Software
Aspecto: Sistema Informático para apoyo Universitario
Tema: Desarrollo de un sistema de gestión de requerimientos informáticos para la
facultad de ciencias matemáticas y físicas de la universidad de Guayaquil
Formulación del Problema
Dado que la resolución de requerimientos informáticos es de suma importancia; y la
Facultad de Matemáticas y Físicas de la Universidad de Guayaquil carece de una
herramienta de apoyo para la atención de los mismos, ¿Es posible optimizar los
tiempos y la gestión de los requerimientos informáticos, con el desarrollo de un
sistema informático para la gestión de requerimientos informáticos?
En el caso hipotético que no se adopte las metodologías (desarrollo del sistema
informático), la respuesta de la gestión de los requerimientos antes los casos
presentados serán pocos eficientes y causarían inconvenientes en la efectividad de
la atención de los requerimientos en la Facultad de Ciencias Físicas y Matemáticas.
28
GRÁFICO N°. 1: Árbol de Problemas
Sistema actual no amigable con el
usuario
Tiempo de respuesta a requerimientos no
optimizados
Inconsistencia en el control de equipos
informáticos
Registro del recurso informático de manera
manual
Postergación de la atención de
requerimientos prioritarios
Malestar y quejas de parte del usuario
bitácora inexistente de resolución de requerimiento
CAUSAS
EFECTOS
Ineficiencia en la gestión de los requerimientos informáticos
Sistema informático inexistente
Lentitud de resolución de requerimientos
Retraso en solucionesTrabajo reiterativo
innecesarioPoco entendimiento
del sistema actual
Retraso en entrega de requerimientos
solucionados
Merma de equipos informáticos
Insatisfacción del proceso actual de
gestión de requerimientos
Retraso en entrega de requerimientos
solucionados
Autor: Jorge Martínez Álvarez
Fuente: Datos Recolectados
Evaluación del Problema
Delimitado: El departamento encargado de atender y resolver los requerimientos
informáticos de las carreras de Ingeniería en Sistemas Computacionales, Carrera de
Ingeniería en Networking y Carrera de Ingeniería Civil de La Universidad de
Guayaquil, son sus Departamentos de Hardware y Software respectivamente.
Actualmente existe ineficiencia en la gestión de los mismos, puesto que para receptar
un requerimiento desde cualquiera de las áreas solicitantes, asignarle un responsable
29
y aplicar una solución, los jefes de los departamentos utilizan instrumentos manuales
como archivos de Excel, correos o llamadas telefónicas, provocando desde lentitud
en el proceso hasta la atención no oportuna de requerimientos prioritarios.
Claro: La manera en que se gestionan los requerimientos informáticos es
manualmente, lo cual no es óptimo. A través de la automatización de este proceso,
se logrará resolver los tiempos de atención y gestión de requerimientos en los
departamentos de hardware y software.
Evidente: Es indudable la problemática expuesta, puesto que es palpable por el
personal encargado en los departamentos de hardware y software, el hecho de que
siendo un área tecnológica, se deba de gestionar la atención de un requerimiento
informático manualmente, cuando en la actualidad existen los medios para
automatizar estos procedimientos.
Relevante: Es de suma importancia la identificación y elaboración de una propuesta
con el fin de mitigar este problema, debido a que se requiere mejorar la calidad de la
atención y gestión de requerimientos en el área informática, ya que no solo beneficiará
al área en sí para la ejecución de sus labores de una forma más organizada, sino al
personal universitario los cuales diariamente generan solicitudes y se encuentran a la
espera de una pronta resolución de los mismos.
Factible: De acuerdo a los recursos de hardware y software disponibles, la
colaboración y amplia apertura que han brindado los interesados, se proyecta que la
propuesta tiene una alta probabilidad de ser culminada exitosamente.
Identifica los productos esperados: Con este estudio se desarrollará un sistema de
gestión de requerimientos informáticos para la Facultad de Ciencias Matemáticas y
Físicas de la Universidad de Guayaquil. El mismo dejará establecido una base donde
se encontrarán centralizados los procesos del departamento de hardware y software
para que en un futuro se evalúe la incorporación nuevos procedimientos.
30
OBJETIVOS
OBJETIVO GENERAL
Desarrollar un sistema de atención de requerimientos informáticos, gestión del
conocimiento y gestión de inventario, mediante el uso de la metodología ágil, para la
optimización de los procesos de gestión de requerimientos en La Facultad de Ciencias
Matemáticas y Físicas de la Universidad de Guayaquil.
OBJETIVOS ESPECÍFICOS
Realizar entrevistas a los encargados de los Departamentos de Hardware y
Software de las Carreras de la Facultad de Ciencias Matemáticas y Físicas de
la Universidad de Guayaquil, para identificar los procesos que son factibles
para automatizar.
Desarrollar un sistema web con una arquitectura de tres capas, aplicando los
lineamientos establecidos en la metodología SCRUM, que permita gestionar
los requerimientos informáticos.
Incorporar en el sistema web una base de conocimientos que permita registrar
y recuperar las experiencias que han sido aplicadas en la solución de un
requerimiento, a través de entradas de información, ingresadas por los
técnicos en el sistema.
Elaborar las pruebas del sistema web, para certificar las funcionalidades
desarrolladas al final de cada iteración.
31
32
ALCANCES DEL PROBLEMA
En el planteamiento de la propuesta es de vital importancia establecer la limitación a
la que se rige el proyecto para tener un panorama acertado del producto que se va a
entregar, por lo que a continuación se indican los alcances.
Generación de Modelo entidad relación de la base de datos del sistema de
gestión de requerimientos informáticos.
La presente propuesta respecta netamente a un desarrollo de software web
con los módulos de mantenimiento, reportes y el flujo de gestión de los
requerimientos.
El software contará con un mecanismo para almacenar los conocimientos
aplicados por los técnicos del departamento de hardware y software.
Las validaciones de las pruebas serán ejecutadas por el jefe del departamento
de informática de la Carrera de Ingeniería Civil Ing. Dennis Merchán y el jefe
del departamento de la Carrera de Ingeniería en Sistemas incluyendo la
Carrera de Networking Ing. Jorge Enrique Alvarado Chang. Dichas pruebas
serán realizadas en las instalaciones de cada carrera respectivamente.
METODOLOGÍA
Como paso previo al desarrollo del proyecto se adopta como metodología principal
de indagación, el tipo de investigación descriptiva, puesto que permite profundizar
acerca de los procesos actuales y detectar los causales de la demora en la atención
de requerimientos informáticos de las carreras de Ingeniería Civil, Sistemas
Computacionales y Networking, de la Facultad de Matemáticas y Físicas de la
Universidad de Guayaquil.
33
De acuerdo a la naturaleza de la investigación, el enfoque cualitativo es el idóneo
para este tipo de problema, ya que la interacción directa con los sujetos de estudio,
representa el instrumento de medición para analizar y comprender los hechos a
explorar. Este enfoque permite utilizar las técnicas de recolección de datos tales como
el diálogo, el cual permitió establecer una conversación abierta con los encargados
de los departamentos de informática, en la que manifestaron sus experiencias en el
tema; la observación como la técnica inicial y básica para el análisis de la información
y finalmente la entrevista como un medio de comunicación más específico, el cual
tiene como objetivo, conseguir respuestas a las dudas e interrogantes de la situación,
objeto del estudio.
Luego de realizar una investigación acerca de las diferentes metodologías para el
desarrollo de un proyecto de software y examinar con cada una de ellas las
características que mayormente se acoplan de acuerdo al tipo de proyecto, tiempos
de entrega y recursos que se presenta en esta propuesta, se decide aplicar una
metodología ágil; específicamente por los lineamientos, instrumentos y múltiples
herramientas que proporciona hoy en día la metodología SCRUM.
De acuerdo a las entrevistas realizadas a los jefes de los departamentos de
informática de las carreras respectivas, la automatización del registro de solicitudes
constituye una ayuda evidente para el departamento, por lo que la participación de
parte de los interesados establece una ventaja para realizar la planificación,
interacción y desarrollo del proyecto. A continuación se mencionan los principales
puntos que hacen que la metodología SCRUM, de acuerdo a esta ventaja sea la ideal
para desarrollar el presente proyecto:
Planificación de sprints. Para este tema existen herramientas muy buenas y
gratuitas en las que los participantes pueden interactuar durante el ciclo de
vida del proyecto.
34
Duración del proyecto. Una metodología ágil, ayuda a que un proyecto en
lugar de priorizar documentación y procesos burocráticos donde se genera un
desgaste de tiempo, se centre mucho más en el desarrollo de entregables del
producto, ocupando esta holgura para el cumplimiento de lo planificado
Entregables. Lo que más se destaca en esta metodología es la producción
de entregables tangibles para el usuario a nivel de software, en períodos
cortos y no al final del proyecto. Este elemento concede al cliente un producto
con más valor.
Flexibilidad. Como consecuencia del punto anterior, se genera una brecha al
final de cada sprint, que permite validar con el cliente el entregable y detectar
a tiempo problemas o cambios emergentes que pueden ser solucionados en
la planificación del siguiente sprint.
De esta manera, todos los puntos mencionados anteriormente consolidan la
utilización de esta metodología para ir construyendo un producto de calidad, que
satisfaga las necesidades de los departamentos de hardware y software
pertenecientes a las Carreras de la Facultad de Ciencias Matemáticas y Físicas de la
Universidad de Guayaquil.
JUSTIFICACIÓN E IMPORTANCIA
Debido a la problemática previamente expuesta, es fundamental la automatización de
estos procesos con la creación de un sistema de gestión de requerimientos, debido a
que esta mejora permitirá que los tiempos de atención sean más rápidos y
organizados.
Esta solución tecnológica aportará una mejor administración, control y referencia
acerca del inventario de los equipos informáticos.
35
Al contar con este sistema se registrará en una bitácora todas las soluciones que
permitieron resolver cada requerimiento, de esta manera el sistema ofrecerá esta
información para el conocimiento del personal. Guardar este historial, es una gran
ayuda para el departamento de hardware y software, ya que logrará reducir los
tiempos de resolución de los mismos independientemente si la persona asignada a
un requerimiento es un trabajador reciente o antiguo.
Es relevante recalcar que con el desarrollo de este sistema informático, se notarán
cambios en la gestión de admisión de los requerimientos; además con un inventario
automatizado se logrará conocer con certeza el estado y la ubicación de los equipos
informáticos también contará con una base de conocimientos que permitiría la
retroalimentación al sistema para la resolución de futuros incidentes y gestión de
requerimientos de las carreras que conforman la Facultad de Matemáticas y Físicas
de La Universidad de Guayaquil.
36
CAPITULO II
MARCO TEÓRICO
ANTECEDENTES DEL ESTUDIO
Desde el año 2013, La Universidad de Guayaquil ingresó en un período de
transformación en el sistema educativo aplicando mejoras en los procedimientos
administrativos, formación académica e infraestructura física. Muchos de los cambios
que se han implementado incluyen la automatización de procesos y adquisición de
equipos de alta tecnología con el propósito de mejorar la calidad educativa que brinda
la institución. Y es que definitivamente la tecnología se ha convertido en un recurso
fundamental para el progreso de la sociedad, visto desde cualquier ángulo. En un
trabajo publicado por la UNESCO, afirma que en el contexto de que el desarrollo
profesional es una práctica que se adquiere a través de la experiencia, es de suma
importancia que sean facilitadas las herramientas necesarias, en vista de la evolución
acelerada de la tecnología que representan (UNESCO, 2004)
Basándonos en esta teoría, a medida que ha evolucionado la tecnología, son grandes
los avances que la Universidad de Guayaquil ha incorporado dentro de las áreas
administrativas que conforman las carreras de la facultad de Matemáticas y Físicas
para que el personal mejore sus procesos y logre realizar su trabajo de una manera
mucho más eficiente, esto trae consigo que a su vez se desarrollen sus habilidades
y acojan esta experiencia como un desarrollo profesional, sin embargo existe un
sector clave lo cual es irónico que a pesar de que representa en sí el núcleo del
concepto de tecnología, aún cuenta con procesos no automatizados; los registros de
inventario, los recursos para el autoaprendizaje que deben de tener disponible los
nuevos trabajadores, la gestión y control de requerimientos, así como actividades del
personal técnico del departamento informático, se realizan manualmente registrados
en archivos de Word o Excel. Por lo tanto, cuando se requiere de algún reporte en
específico, solicitado por el área gerencial de la institución, el jefe de sistemas invierte
tiempo buscando en estos registros y armando los informes para ser entregados en
37
la brevedad del caso. Es totalmente evidente que todos estos procesos podrían ser
automatizados con una solución tecnológica a la medida. Como base de la presente
propuesta, se realizó una investigación acerca de problemáticas semejantes a las que
se evidencian en los departamentos de sistemas de la Facultad de Matemáticas y
Físicas de La Universidad de Guayaquil.
Caso de estudio para la automatización de la gestión de
solicitudes de servicios y mantenimiento de equipos en La
Universidad Agraria de La Habana
En un estudio publicado en la Revista de Ciencias Técnicas Agropecuarias sus
autores realizaron un análisis de los procesos de gestión y mantenimiento de equipos
en La Universidad Agraria de La Habana, donde claramente identificaron aquellas
tareas que podían ser automatizadas haciendo el uso de las herramientas
tecnológicas para la construcción de un sistema informático. En la UNAH la gestión
de mantenimiento de equipos se realizaba de forma poco eficiente debido a que las
solicitudes de servicios o mantenimientos se realizaban de forma manual. Este
proceso causaba que la generación de reportes sea lento y la información o control
de los equipos sea pobre. La situación generaba un ambiente de poca fiabilidad y
carencia de transparencia en el momento de presentar los informes de la entidad.
Dada estas circunstancias deciden proponer el sistema SGMANTE; un software
compuesto básicamente por cuatro módulos encargados de apoyar en la gestión de
requerimientos y mantenimiento de equipos, como se logra observar en el gráfico 2
(Suárez Fragas, Medina Peña, & Hernández Alfonso, 2015).
38
GRÁFICO N°. 2: Módulos del software SGMANTE
Autor: (Suárez Fragas, Medina Peña, & Hernández Alfonso, 2015)
Fuente: (Suárez Fragas, Medina Peña, & Hernández Alfonso, 2015)
Basados en esta investigación, se comprueba como la automatización de procesos,
particularmente las solicitudes de servicios generadas por los usuarios, aumenta la
eficiencia de la gestión de mantenimiento en la UNAH.
En sí este escenario en comparación con la situación de los Departamentos de
Informática de la FCMF, presentan necesidades similares respecto a la forma en que
se administran las solicitudes de los usuarios, por lo que, al igual que la UNAH es
sumamente importante realizar un análisis del flujo actual de la gestión de
requerimientos para identificar las falencias y desarrollar un sistema capaz de guardar
un registro común de toda la información que se maneja en la gestión de
requerimientos para que posteriormente sea administrada de manera eficiente y
oportuna.
39
Caso de estudio acerca de la implementación de un sistema
de mesa de ayuda informático en el gobierno autónomo
descentralizado de la provincia de Esmeraldas
Para el Gobierno Autónomo Descentralizado de la Provincia de Esmeraldas la
implementación de esta mesa de ayuda cooperó para que el 99% de los usuarios
sean atendidos de forma oportuna, mejorando los tiempos de respuesta y la
generación de estadísticas a través de información confiable. Un punto relevante de
este estudio es la utilización de fechas límites a los requerimientos ingresados en el
sistema, puesto que el administrador tiene la potestad de configurar los días de
resolución de la solicitud ingresada. Este parámetro permite que el recurso humano
responsable de la atención del mismo, se encuentre atento al plazo establecido para
la pronta resolución de la incidencia, a través de notificaciones que permiten estar
pendientes de la petición (López Vera, 2014).
Gracias a las bases de este factor, se tiene información valiosa para manejar mejor
aún las visualizaciones en el sistema, ya que un aplicativo no solo debe de servir para
resolver un problema en específico, sino que debe de ser una ayuda para el usuario.
Esto se puede lograr gracias a la creación de interfaces intuitivas. De esta manera,
se empieza a idear la organización del ingreso de solicitudes a manera de una
bandeja de correo electrónico, donde se encuentren organizadas por estados de los
requerimientos, con priorizaciones y donde claramente se logren identificar con
colores en el diseño del API, aquellos que están próximos a cumplir la fecha límite.
Este elemento representará una interfaz amigable para los usuarios del sistema a
construir.
40
Caso de estudio de Propuesta de un Service Desk para
mejorar los procesos de resolución de incidencias a través
de ITIL
Por otro lado en La Universidad Privada Norbert Wiener de Lima, para la elaboración
de una propuesta de Service Desk a través de las buenas prácticas ITIL, asegura que
el 90% de las empresas peruanas dependen de las Tecnologías de la Información
para sus labores diarias. Esta investigación se realizó en la empresa COGESA, una
prestigiosa constructora de edificios y construcciones viales, donde la aplicación de
un diagnóstico orientado a las cuatro categorías establecidas por el autor: capacidad
de respuesta del servicio, manejo de información, rendimiento del personal e
infraestructura tecnológica, permitió el desarrollo de esta propuesta. Baygorrea
plantea la aplicación de ITIL en el modelo de mesa de ayuda, puesto que afirma que
representan un conjunto de pautas para controlar las incidencias y administrar de
forma correcta los problemas de la empresa, manteniendo por encima, la calidad del
servicio. (Baygorrea Berrocal, 2016)
Lo destacado de este estudio es la implementacion de ITIL; este conjunto de buenas
prácticas se encuentra basado en la ISO 20000, la cual hace referencia a la calidad
del servicio respecto a las tecnologia de la informacion. Estas pautas permitirán
implementar en el sistema, normas para la gestion y administracion de requermientos
de forma organizada sin restar la calidad de los procesos a utilizar.
Caso de estudio ITAKA: Gestión Interactiva del Conocimiento
en Organizaciones de Desarrollo de Software
Esta investigación se centra específicamente en la creación de un repositorio de
conocimiento para su adquisición, organización, distribución, utilización, preservación
y medición en el contexto de las organizaciones de software. Según Heredia,
41
manifiesta que el modelo de gestión de conocimiento ITAKA posibilita el intercambio
de experiencias entre los participantes de la organización, independientemente de la
localización, equipos a los que pertenecen o medios para acceder a este único
repositorio de conocimiento. Este proyecto plantea realizar la gestión del
conocimiento a través de tecnologías Web 2.0 por medio de un sistema Wiki (Heredia
García, 2012).
Este concepto acerca de la centralización de los conocimientos del personal,
representa un factor válido para ser plasmado dentro de la automatización de la
gestión de requerimientos informáticos, debido a que si se almacena las experiencias
utilizadas en la resolución de los incidentes, los técnicos tendrán una base donde
consultar respuestas que se asemejen a la solicitud ingresada. Esto mejorará los
tiempos de resolución, ya que al tener una bitacorización de las respuestas el
personal, se estaría auto capacitando en futuras soluciones. De igual modo se evita
la pérdida de conocimientos, dado a que el personal técnico suele retirarse, con esto
no se perderá las instrucciones a seguir para solucionar las peticiones asignadas, por
lo tanto, la curva de aprendizaje nunca decaerá sino seguirá un ascenso estable .
.
Caso de estudio desarrollo e implantación de sistema de
control de inventarios para la Facultad de Ciencias de La
Escuela Politécnica Nacional
En este estudio se planteó la implementación de una herramienta de software para el
registro del inventario de la organización con el uso de metodologías ágiles. De esta
manera, se logra centralizar la información para que sea accedida de manera rápida
por los involucrados y organizar la búsqueda de la información de los activos que
pertenecen a la Facultad de Ciencias de La Escuela Politécnica Nacional (Chiluisa
Pallo & Loarte Cajamarca, 2014).
42
Una situación parecida se refleja en el almacenamiento y manejo de los equipos de
los Departamentos de Informática de la FCMF de la UG, puesto a que el registro de
los activos se realiza de forma manual, es decir es hojas de Excel. Este proyecto
destaca la importancia de automatizar el inventario ya que con esto se podrá controlar
el uso, el mantenimiento y la ubicación de los mismos. De igual forma al utilizar como
desarrollo las metodologías agiles los entregables son generados en plazos cortos.
Este nuevo enfoque, además de generar un producto de alta calidad debido a la
interacción constante con los usuarios finales, brinda flexibilidad para realizar cambios
emergentes en los tiempos adecuados y no al final de todo el proyecto, cuando
muchas veces ya suele ser demasiado tarde. La experiencia demostrada en este
trabajo permite entender que las metodologías ágiles, son una opción factible a utilizar
en proyectos de desarrollo de software.
FUNDAMENTACIÓN TEÓRICA
Sistemas de gestión
Los sistemas de gestión, están ligados a las organizaciones en distintos aspectos
como: la calidad, área comercial, área financiera, gestión de riesgos, entre otros. En
un artículo publicado en la Revista de Dirección y Administración de Empresas, por el
Profesor Iñaki Heras Saizarbitoria sostiene que un sistema de gestión, representa un
conjunto de elementos relacionados entre sí, a través de los cuales se rige una
institución para planear, cumplir e inspeccionar aquellas tareas ligadas al
cumplimiento de los objetivos que se desea alcanzar una organización.
Con esta teoría planteada por Iñaki, denotamos la importancia que representan los
sistemas de gestión en una institución, puesto que permite establecer los
procedimientos a seguir para trabajar de forma ordenada y lo que es más importante,
lograr asegurar el cumplimiento de objetivos.
43
Es por este motivo que en una publicación expuesta en el 2008 por el Dr. Martí
Casadesús Fa, asegura que como una evolución de los sistemas de gestión, se
introdujo a inicios del siglo XX el término “normalización”; se refiere a nivel general
como la práctica orientada a ordenar los procesos repetitivos que se ejecutan dentro
de una organización aplicados en diferentes ámbitos de la industria, la economía, las
ciencias y las tecnologías (Heras, 2006).
Dentro de esta publicación Heras asegura que con este término aparecieron los
sistemas de gestión normalizados como producto de la necesidad de formalizar y
estructurar procedimientos. Estos sistemas de gestión normalizados son ya
establecidos por entes reguladores independientes, encargados de auditar su
aplicación en las organizaciones. Según la evaluación de este proceso se otorga una
certificación. Dicha certificación, asegura que la entidad cumple con las normas
establecidas en el estándar.
Es así que dentro de este contexto, en la Revista Europea de Dirección y Economía
de la Empresa, Casadesús menciona que entre los principales entes de
estandarización o normalización se encuentra la prestigiosa Organización
Internacional de Estandarización o mejor conocida con las siglas “ISO”.
En el sitio web oficial de la ISO, menciona que cuentan con expertos de 163 países
alrededor del mundo para el desarrollo y establecimiento de una normativa a nivel
Internacional (ISO, 2017).
Dentro del portal web de esta organización, indica que se han desarrollado acerca de
21723 estándares internacionales, sin embargo consideramos relevante mencionar
únicamente aquellos relacionados a las TI, ya que es el núcleo de la propuesta
presentada. Es así, que según un estudio realizado en el sector de las TI publicado
en la Revista Española de Innovación, Calidad e Ingeniería del Software (Asociación
de Técnicos de Informática de Madrid, 2010), indica que dentro de los estándares de
sistemas de gestión más demandados por el sector de las TI se encuentran:
ISO 9001:2008 Sistemas de gestión de la calidad
ISO/IEC 20000-1:2005 Tecnología de la información - Gestión del servicio
44
ISO/IEC 27001:2005 Tecnología de la información - Técnicas de seguridad -
Sistemas de Gestión de la Seguridad de la Información (SGSI)
Sistemas de gestión de requerimientos
En la sección anterior, revisamos que los sistemas de gestión van orientados al
establecimiento y cumplimiento de objetivos relacionados a procesos específicos. En
esta oportunidad, nos referimos al proceso de gestión de requerimientos. Dentro del
campo de la Ingeniería de Software (Gelmer, 2009) define el término requerimiento,
como una necesidad la cual tiene que estar documentada y su contenido respecta a
la forma o funcionalidad de un producto o servicio tomando en cuenta las peticiones
y definiciones de los clientes.
De acuerdo a la definición de Gelmer, se deduce que los sistemas de gestión de
requerimientos, consisten en el proceso de interpretar y brindar seguimiento continuo
a las peticiones realizadas por parte de los usuarios.
Por su parte, el desatacado investigador en el campo de la Ingeniería de Sistemas,
Ian F. Sommerville, asegura y enfatiza que para la gestión de requerimientos, se
precisa asistencia automatizada, con el fin de agilizar y controlar de manera eficiente
las siguientes tareas propias de este proceso (Sommerville, 2005):
Registro de requerimientos. En la gestión de requerimientos, es
imprescindible el almacenamiento de los mismos, para que se encuentren
centralizados en un solo sitio y de esta manera puedan ser accedidos por los
involucrados o participantes del proceso.
Gestión de cambios. El flujo graficado en la figura N. 3, se resume y facilita,
con la implementación de una herramienta automatizada a través de la cual
se pueda llevar estos procedimientos propios de la gestión de cambios de los
requerimientos.
45
Control y seguimiento. Para lograr mantener un buen control y seguimiento
de los requerimientos, es necesario adoptar herramientas de ayuda que
permitan consultar el estado que se encuentra un requerimiento y en base a
esta información tomar decisiones de forma organizada y rápida.
GRÁFICO N°. 3: Gestión de cambios de requerimientos
Autor: (Sommerville, 2005)
Fuente: (Sommerville, 2005)
De acuerdo a la teoría planteada por Sommerville, demuestra la importancia que
representa la automatización en los procesos de gestión de requerimientos, para
aportar en las actividades que conllevan el proceso de gestión de peticiones.
Automatización de Procesos
Según el Licenciado en Informática por la Universidad Politécnica de Cataluña, Rafael
Macau, se refiere que el campo de la informática se introduce en las organizaciones
a partir del año 1960, con la finalidad de automatizar los procesos que se consideran
como repetitivos en las diferentes áreas de una organización, tales como contabilidad,
facturación y nómina. (Macau, 2004)
Macau relaciona el término proceso industrial clásico, con el concepto de tecnologías;
esta teoría indica que la tendencia para la automatización de procesos, con la
aparición de las herramientas informáticas, se realiza a través de estas nuevas
tecnologías.
46
Es así que de las teorías anteriores, logramos concluir que la automatización de
procesos dentro de una organización, libera al hombre de trabajos manuales y aporta
a la reducción de los márgenes de errores en el cumplimiento de tareas específicas;
es por este motivo que cada día las empresas optan por buscar soluciones o
herramientas tecnológicas que permitan reemplazar la mano de obra en los procesos
donde intervienen el ser humano.
Tipos de Automatización
En forma general, en el proyecto de investigación de la línea de trabajo en
aplicaciones de sistemas distribuidos en el Grupo de Investigación en Sistemas de
Información (GISI) del Departamento de Desarrollo Productivo y Tecnológico de la
Universidad Nacional de Lanús, se menciona que existen básicamente 3 tipos de
automatización:
Automatización Fija. Este tipo de automatización, se emplea cuando el
volumen de la producción es enorme. Por lo tanto el presupuesto de inversión
es justificable debido a la magnitud de la automatización. (Azcurra, y otros,
2011)
Automatización Programable. Este tipo de automatización, se emplea
cuando el volumen de la producción es regularmente bajo, es decir es variable.
Por este motivo tiene la capacidad de adaptarse generalmente esta
automatización se realiza utilizando software. (Azcurra, y otros, 2011)
Automatización Flexible. Este tipo de automatización, se emplea cuando el
volumen de la producción se clasifica en un término medio. Fusiona los dos
anteriores tipos de automatización mencionados. (Azcurra, y otros, 2011)
Por otra parte, en una investigación realizada en la ciudad de Cuenca por (Sánchez
& Pizarro, 2010) identifican cuatro niveles de automatización. Se reconoce en la
47
lectura de esta investigación que Sánchez realiza esta clasificación basada en el tipo
de tecnologías que se emplean para proceder a implementar la automatización de
algún proceso específico. A continuación se nombran dichos niveles reconocidos en
la investigación:
Manual. En este nivel interviene únicamente el operador y la máquina para
ejecutar tareas. Esto quiere decir que la producción depende de la fuerza de
la persona, ya que en caso de no existir, no habría quien manipule la maquina
por lo tanto, se detiene la producción.
Semiautomática. Este nivel se realiza en base a tareas manuales con ayuda
de herramientas oleo hidráulicas, electromecánica, neumáticas, contactores,
temporizadores etc.
Automática. Este nivel efectúa las tareas a través de secuencias dirigidas por
un sistema de control.
Computarizada. Este nivel, ejecuta las tareas con la implementación de un
computador, el cual es el encargado de dominar y controlar los procesos.
GRÁFICO N°. 4: Nivel de automatización de la maquinaria y equipo de producción de las
PYMIS de la ciudad de Cuenca
48
Autor: (Sánchez & Pizarro, 2010)
Fuente: (Sánchez & Pizarro, 2010)
Según las teorías expuestas acerca de los tipos de automatización, se expone que
en la presente propuesta el tipo de automatización que se utilizará será la
automatización programable, puesto que el proyecto propone como una solución el
desarrollo de un sistema informático. Adicionalmente según la investigación de
(Sánchez & Pizarro, 2010) al utilizar en el proyecto, un ordenador el cual tendrá un
sistema informático para la ayuda en la gestión de requerimientos, se posiciona a la
propuesta en el nivel de una automatización computarizada. En este punto,
coincidimos con una afirmación de Vilaboa, relacionada con la automatización
computarizada, en la cual sostiene que gracias al desarrollo de las tecnologías de la
computación, se facilita el desarrollo de aplicaciones innovadoras, con un costo de
inversión, menor al de una tecnología tradicional (Vilaboa B., 2006)
Tecnologías de la Información
Según (Chandler & Munday, 2011), las tecnologías de la información comprenden el
conjunto de ordenadores y redes informáticas, pero más ampliamente relacionados a
cualquier tecnología que se utiliza para generar, almacenar, procesar y distribuir
información electrónicamente.
Este concepto, se maneja generalmente a nivel de empresas y negocios, los cuales
conviven con el uso de estas herramientas como parte de su día a día;
específicamente por el hecho de que las mismas manejan información a través de
estos medios, se determina que emplean tecnologías de información. Estas
herramientas pueden ser tangibles o intangibles. Por ejemplo un motor de base de
datos, el cual es un elemento intangible constituye una tecnología de la información;
de igual manera, un dispositivo tangible como una Tablet forma parte de una TI.
49
El rol de las TI en las empresas
En pleno año 2017, las empresas diariamente dependen de las TI para la
productividad y operación de sus actividades; por ejemplo nombran en su publicación
(Powell & Dent-Micallef, 1997):
En el área farmacéutica, McKesson una importante empresa a nivel mundial
que distribuye medicamentos, proporciona a sus farmacéuticos terminales de
computadoras que les permiten ingresar pedidos directamente, mejorando al
mismo tiempo el servicio al cliente y aumentando los costos de cambio.
Los conductores de Federal Express utilizan ordenadores portátiles con un
sofisticado sistema de gestión de datos que mejoran el servicio y reducen los
costos haciendo que los servicios de entrega de sobremesa sean rentables y
asequibles para los clientes.
Merrill Lynch introdujo la cuenta de gestión de tesorería, basada en un sistema
de información que permite a los clientes combinar la comprobación en línea,
el ahorro de tarjetas de crédito y las cuentas de valores en una sola
declaración, invirtiendo automáticamente fondos no utilizados en fundadores
del mercado monetario con intereses.
Xerox ofrece horarios de producción en línea a los proveedores para facilitar
entregas a tiempo, reducir los costos de inventario y mejorar las relaciones
con los proveedores.
Los grandes minoristas como Toys R Us y Wall-Mart utilizan sofisticadas
tecnologías de gestión de inventario, incluyendo el intercambio electrónico de
datos con los proveedores, para aumentar la eficiencia operativa y mejorar los
servicios.
En el marco de los ejemplos referenciados, ¿Podemos imaginar qué pasaría si alguno
de los componentes de las TI se detiene o se ven afectados? Pues las consecuencias
serían enormes, empezando por las pérdidas económicas que esta afectación
generaría para la empresa, entre otros. Es por este motivo, que nace la necesidad de
50
crear un servicio propio de la empresa, dedicado a velar la continuidad de las
operaciones en la entidad; un ente que se dedique a la atención y resolución de
cualquier eventualidad que pueda desencadenar algún desastre o malestar para la
institución.
Mesa de ayuda
Como se menciona en el tópico anterior, el rol de las tecnologías de la información
desde hace mucho tiempo atrás juegan un papel importante en las empresas; incluso
desde antes que existiera el término tecnológico “software”, la empresas que se
dedicaban a la prestación de un servicio, tenían un canal de comunicación con sus
clientes para el reporte de alguna incidencia y resolver la misma en el menor tiempo
posible.
Con la aparición del teléfono, el cual representa para esta época un nuevo canal de
comunicación entre las empresas y sus clientes, se crearon los “centros de llamadas”
o “call center” con el fin de ayudar a sus clientes de manera más rápida.
La invención de los computadores y las tecnologías que estas acarrean consigo,
generan un nuevo canal de comunicación para la interacción entre las empresas y
estos usuarios tecnológicos, a través de soluciones de software de ayuda para la
recepción y atención de requerimientos.
En una publicación presentada en la Revista Tecnológica ESPOL, sus autores
mencionan que con el uso de las TI, la organización y procesamiento de la
información es mucho más integra y accesible; por lo que el uso de help desk es un
elemento adecuado para la gestión de servicios de TI. (Jaramillo Castro & Morocho
Puchaicela, 2016)
El concepto de mesa de ayuda se conoce también por el término inglés “Help Desk”.
Según Bravo, una mesa de ayuda representa un grupo de técnicos con conocimientos
51
de hardware y software, definidos por la organización para mantener operativos los
computadores de un modo eficiente. (Bravo, 2016)
Por otro lado, en la guía para el soporte de usuarios de computadoras para
especialistas en soporte técnico y de asistencia publicada por Fred Bessie, asegura
que dentro del contexto de las TI:
“Un help desk proporciona un punto de contacto único para los usuarios
que necesitan soporte técnico, ya sean internos o externos. Tener un
único punto o contacto agiliza el proceso tanto para el usuario como para
los encargados del área de soporte” (Beisse, 2014)
En relación a lo citado en los párrafos anteriores, se concluye que la inclusión de una
mesa de ayuda dentro de una organización, facilita a la rápida resolución de
requerimientos acortando los plazos de entrega, además permiten una comunicación
fluida entre los encargados de la parte técnica y los usuarios solicitantes mediante
uno o varios canales de comunicación.
Funciones de una mesa de ayuda
Dentro de las teorías consultadas acerca de las responsabilidades que tiene asignado
dentro de una empresa, el departamento que cumple el rol de brindar los servicios de
una mesa de ayuda. Según (Desongles Corrales, 2005) se encuentran las siguientes:
Atender las solicitudes de requerimientos por parte de los usuarios.
Evaluar el requerimiento enviado.
Analizar la solicitud de los requerimientos de los usuarios
Según el análisis del requerimiento recibido, priorizar cada requerimiento.
Asignar, una persona o técnico responsable para solucionar la solicitud
enviada.
Brindar al usuario, un servicio de atención de alta calidad.
52
Seguimiento de cierre de solicitudes ingresadas.
Mantener la operatividad de las TI asignadas al departamento de mesa de
ayuda.
Proporcionar un soporte proactivo. Es decir trabajar en un plan de
contingencia con el fin de prevenir cualquier desastre que podría afectar a los
procesos operativos de la empresa. Dentro de este punto se encuentran
también las rutinas de mantenimiento programadas.
Proporcionar soporte reactivo. Un help desk debe de tener la capacidad de
solucionar problemas reportados por los usuarios en el menor tiempo posible,
puesto que esta afectación puede detener las actividades de una entidad.
ITIL en la aplicación de una mesa de ayuda
Primero debemos de responder a la pregunta ¿Qué es ITIL? Este término se conoce
también como Biblioteca de Infraestructura de Tecnologías de la Información. Pues
bien, la siguiente definición recogida desde AXELOS Global Best Practice, la empresa
propietaria de ITIL la describe como un enfoque ampliamente aceptado en la Gestión
de Servicios TI; ha sido acogido por varias organizaciones alrededor del mundo. ITIL
concede un conjunto de buenas prácticas extraídas de sectores públicos y privados
a nivel internacional (AXELOS, 2017)
Es importante mencionar que en el sitio web oficial de ITIL, se menciona que este
conjunto de buenas prácticas se encuentra certificada bajo los estándares de la ISO
20000, que tal como revisamos anteriormente, es una norma ISO encargada de la
gestión del servicio de las Tecnologías de la Información.
Esto permite que los profesionales adopten y apliquen los procesos de la ITIL para
mejorar la gestión de servicios de las tecnologías de la Información. Además se
menciona de que tiene compatibilidad con las metodologías ágiles, las cuales
benefician a la propuesta que estamos presentando, ya que su desarrollo se realiza
bajo el marco de este tipo de metodología (AXELOS, 2017).
53
GRÁFICO N°. 5: Diagrama del soporte al servicio TI basado en ITIL
Autor: (Pirchado Veloz, y otros, 2015)
Fuente: (Pirchado Veloz, y otros, 2015)
De acuerdo a los beneficios que representa los estándares ITIL, para el desarrollo de
la propuesta nos hemos basado en la aplicación de estas buenas practicas. En el
gráfico N. 5 realizado por (Pirchado Veloz, y otros, 2015) se establecen los diferentes
tipos de gestiones de la ITIL.
54
Gestión de incidencias. Es necesario contar con este tipo de gestión dentro
de una mesa de ayuda, ya que su oportuna atención, garantiza la prevención
o restablecimiento del servicio en un tiempo razonable.
Gestión de problemas. Ofrece un diagnóstico acerca de las incidencias
reportadas. Suministra un marco para el restablecimiento de servicios de
forma ágil.
Gestión de configuraciones. Mantener identificados y registrados los activos
utilizados en el proceso de gestión.
Gestión de cambios. Implementar el control y auditorias de los cambios que
se generen durante el proceso de soporte.
Gestión de versiones. Asegurar que las nuevas versiones tanto en hardware
como en software están aprobadas y funcionen correctamente para garantizar
la operatividad. Igualmente llevar un control de las mismas.
Es importante recalcar que dentro de la versión V3, los estándares ITIL incluyen que
toda interacción con la base de datos de la gestión del cambio, gestión de incidentes
y gestión de problemas, abarca el registro del conocimiento como una estrategia para
mantener centralizado el conocimiento que se ha adquirido a través de los integrantes
durante sus interacciones. Más adelante, revisaremos un poco más las teorías acerca
de la base de conocimientos.
Gestión de incidencias según ITIL
Desde la perspectiva de ITIL, se define como una incidencia:
“Cualquier evento que no forma parte del desarrollo habitual del servicio
y que causa, o puede causar una interrupción del mismo o una reducción
de la calidad de dicho servicio” (Itlibrary, 2017)
55
El propósito principal de esta gestión radica en resolver y restaurar en el menor tiempo
posible este tipo de eventualidades, que paran la continuidad del negocio. Según el
alcance definido por la organización, una incidencia puede ser de diferentes índoles.
Por ejemplo dentro del contexto de un departamento informático pueden ser:
Fallo en hardware
Fallo en software
Solicitud de servicios informáticos
Consultas relacionadas al negocio
Una buena gestión de incidencias beneficia a la organización en varios aspectos entre
los cuales se mencionan:
Aumenta el rendimiento de las actividades de los usuarios.
Se obtiene un mayor dominio de los servicios del área TI.
Mejoras en el manejo de recursos.
A nivel general, se mejora significativamente el servicio tanto de los usuarios
como los administradores de la gestión de requerimientos.
En el grafico N. 7 se grafica el flujo básico del proceso de gestión de incidencias según
ITIL. A continuación la explicación:
Identificación. El flujo inicia con la identificación de la afectación en el
servicio.
Recepción. Posteriormente, se envía y recibe la incidencia por cualquiera de
los canales establecidos por la organización; aunque lo ideal es desde el inicio
automatizar todo el flujo.
56
Registro. En este paso, se procede a analizar la solicitud y determinar si
realmente se trata de una incidencia para proceder a su registro. En caso de
que no sea catalogada como incidencia, se procede a seguir un flujo alterno
acerca del proceso de peticiones. Al registrar una incidencia se almacenan
con ella, datos informativos que aporten a su identificación y resolución.
Comparación. En esta instancia se procede a emplear alguna base donde se
encuentre una solución acerca del tema (Base de conocimientos).
Priorización. Realizado el previo análisis con la ayuda de la base de
conocimientos, en caso de que se pueda resolver la incidencia en este nivel
se procede a la solución. Caso contrario se procede a priorizar la incidencia.
Escalado. Una vez priorizada la incidencia, se proceder a escalar la atención
al siguiente nivel.
GRÁFICO N°. 6: Flujo de escalado de niveles
Autor:
(Guzmán,
2014)
Fuente:
(Guzmán,
2014)
En sí, en
este
contexto,
el término
escalar,
se refiere al
proceso
de
asignación de un responsable para la resolución de una incidencia en cada nivel.
57
En el grafico N. 6 se puede observar una gráfica acerca del escalado en diferentes
niveles de una organización. Para este ejemplo, tal como se logra visualizar, la
primera línea de comunicación o reporte se realiza a través del nivel 1 de atención. Si
en esta instancia la incidencia representa un mayor impacto, entonces se procede a
escalar o asignar la incidencia al nivel 2, la cual en el ejemplo representa al área de
administración. Si en este nivel no se ha logrado llegar a la solución, el nivel 2 procede
a realizar un nuevo escalado a la siguiente línea que es el nivel 3, que en este caso
representa a los especialistas o desarrolladores. Por ultimo si el nivel 3 detecta que
no se logra resolver la incidencia, debido a que representa un impacto de competencia
que se relaciona al proveedor, procede a escalarlo al último nivel, que es el proveedor.
El número de niveles y las áreas en brindar el soporte para la atención de las
incidencias, depende de la dimensión de la organización y forma parte de la
planificación y establecimiento de definiciones de los procesos iniciales para la
gestión de atención de incidencias del negocio.
Resolución. En este paso el nuevo nivel podrá hacer uso de igual forma de
la base de conocimientos para llegar a una resolución y mitigar la incidencia.
Seguimiento. En esta fase, el responsable de mantener un control del estado
de la incidencia, es la persona del nivel que ha procedido con la solución de
la incidencia.
Cierre. Finalmente luego de que la incidencia ha sido resuelta, el responsable,
debe notificar a los involucrados del proceso, que ha sido restablecido los
servicios relacionados a la incidencia.
En esta etapa se recomienda registrar la solución aplicada, para la resolución
de la incidencia. De esta manera la organización, constará con una gestión del
conocimiento valiosa, actualizada y al alcance de cualquier miembro del
equipo, en todo momento.
58
GRÁFICO N°. 7: Flujo básico del proceso de gestión de incidencias
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
59
Rol de una base de conocimientos en los procesos de una
mesa de ayuda
En el anterior apartado, mencionamos el término conocimiento dentro del estándar
ITIL; por este motivo es necesario partir desde la definición del término en particular,
para luego comprender el término general. De esta manera empezaremos con el
concepto de la palabra conocimiento. Según Pérez Porto, el conocimiento es un
conjunto de información la cual se encuentra guardada y que se obtiene a través de
la experiencia o en el proceso de aprendizaje. (Pérez Porto, 2008)
Para entender la importancia del conocimiento dentro de una organización, hacemos
referencia a un ejemplo expresado por la Dra. Maritza Osorio, donde indica que
diariamente existen casos en que los trabajadores abandonan la compañía,
llevándose consigo la riqueza del conocimiento adquirido a través del tiempo, con la
práctica y experiencia en las actividades de la institución. (Osorio Núñez, 2003)
En este punto se realiza una reflexión; ¿Qué sucedería el día que este recurso
humano, el cual únicamente él, posee todo este conocimiento, deje de pertenecer a
la empresa? Pues bien, la respuesta de esta interrogante no es alentadora ante los
ojos de un jefe de sistemas encargado del departamento, para el cual, la situación
que se mencionó, se torna un proceso difícil de manejar, más que nada por la curva
de aprendizaje que le tomará al nuevo recurso técnico en capacitarse para el
entendimiento del negocio.
Este es uno de los principales motivos por lo que es de gran importancia almacenar
todo este conocimiento en un medio a través del cual el personal involucrado pueda
acceder con el fin de desempeñar de manera más acelerada y eficiente sus funciones
en el cargo asignado. Basados en este antecedente, es que la ITIL incorpora en su
guía de buenas prácticas la gestión del conocimiento.
Según el consultor Sergio Ríos, la gestión del conocimiento forma parte de los
procesos de prestación de servicios y su almacenamiento ayuda a que las
capacitaciones del nuevo personal sean más eficaces. (Ríos Huércano, 2011)
60
GRÁFICO N°. 8: Desarrollo de la Gestión de Conocimiento basado en ITIL® V3
Autor: (Quintana Solórzano, 2013)
Fuente: (Quintana Solórzano, 2013)
A través del gráfico N. 8, se representa la gestión del conocimiento según la ITIL,
como un proceso central, encargado de disponer todo el conocimiento aplicado
durante las etapas de:
Gestión de incidentes.
Gestión de problemas.
Gestión de configuraciones.
Gestión de cambios.
Gestión de versiones.
61
Basados en las sugerencias de la ITIL, para la gestión del conocimiento, se han
investigado herramientas que permitan la administración de este importante
elemento. Según Moreno, afirma que el concepto de base de conocimientos aparece
en una etapa posterior a la aparición del concepto de base de datos y la inteligencia
artificial:
“Las bases de conocimiento son la evolución lógica de los sistemas de
bases de datos tradicionales, en un intento de plasmar no ya cantidades
ingentes de datos, sino elementos de conocimiento (normalmente en
forma de hechos y reglas) así como la manera en que éste ha de ser
utilizado. También se les trata de dotar de conocimiento sobre sí mismas,
es decir, una KB ha de "saber lo que sabe"” (Moreno Ortiz, 2000)
Con estas teorías, nace la idea de la integración de una base de conocimientos en
una mesa de ayuda. A continuación se nombran algunas definiciones investigadas.
En una publicación realizada por Rouse, asegura que de manera general, una base
de conocimiento constituye un repositorio de información centralizado, semejante a
una biblioteca pública donde se puede consultar información relacionada a un tema
particular. (Rouse & May, 2007)
Una base de conocimientos representa un recurso entendible por la máquina para
optimizar la recopilación, organización y la recuperación de la información relacionada
a la experiencia del personal en una organización.
Beneficios de una base de conocimientos en una mesa de
ayuda
Entre los principales beneficios que aporta la integración de una base de
conocimientos en el proceso de gestión del conocimiento en una mesa de ayuda se
encuentran:
Facilita la gestión del conocimiento.
62
Acelera el acceso del conocimiento de la solución de incidencias o problemas
que previamente ya se han suscitado en el negocio.
Mejora la toma de decisiones en procesos que ya se han implementado
previamente.
El conocimiento del personal, permanece registrado en la base de datos de la
mesa de ayuda, de esta manera este valioso activo permanece dentro de la
empresa.
Facilita la capacitación del personal nuevo de la empresa.
Brinda información precisa.
Promueve la colaboración e integración de los miembros del equipo.
El conocimiento del negocio se centraliza en un solo lugar, para que cualquier
miembro de equipo logre acceder.
Una base mantiene un proceso de constante transferencia del conocimiento
entre cada uno de los miembros del equipo.
La investigación realizada expone que existe más de un motivo, de por qué se debe
de implementar una base de conocimientos dentro de un sistema de gestión de
requerimientos.
Gestión de Inventario
Como parte de las recomendaciones que abarca las prácticas de ITIL, se tiene el
registro del inventario de las tecnologías de la información.
“Se define un inventario como la acumulación de materiales que
posteriormente serán usados para satisfacer una demanda futura” (Moya
Navarro, 1999).
63
Enfocados en el área de sistemas, un inventario representa la cantidad de equipos o
hardware, el número de licencias o cualquier bien informático que requiera ser
controlado, como parte de las responsabilidad del departamento informático.
Según el sitio web oficial de la prestigiosa empresa Aranda Software, la gestión de
inventario forma parte de la gestión de configuración de la ITIL; el objetivo en sí
consiste en la administración de los datos de inventario en una CMBD. (Aranda
Software, 2017)
Una CMDB se refiere a una base de datos en la cual se encuentran registrados los
equipos y las interacciones con los incidentes o problemas que se manejan en las TI
de un negocio. El término se conoce mejor como base de datos de la gestión de la
configuración.
GRÁFICO N°. 9: Interacción de la gestión del inventario de IT
Autor: (Techedge, 2015)
Fuente: (Techedge, 2015)
64
En el gráfico N. 9 se representa la interacción entre los elementos generales que
intervienen dentro del servicio y negocio de las TI, los cuales establecen una
comunicación con la CMDB. La implementación de un registro de inventario dentro
de una mesa de ayuda, facilita considerablemente la administración, control y
actividad de los activos de un departamento de sistemas; además de la generación
de reportes de forma instantánea.
Consideraciones al realizar un inventario informático
En el libro Análisis y Diseño de Sistemas escrito por Kenneth y Julie Kendall,
mencionan siete puntos a considerar para la elaboración de un inventario informático:
(Kendall & Kendall, 2011)
1. Reconocimiento de bienes. En primer lugar, se debe de identificar el alcance
del inventario a realizar, es decir, como departamento informático cuáles son
los tipos de recursos que gestiono y de los cuáles como departamento, soy
responsable administrar.
2. Definición de espacios. Como segundo punto tenemos el análisis y definición
de los sitios o lugares, donde se encuentran o se ubicarán posteriormente
estos bienes, todo esto con el fin de tener claro el espacio donde están
ubicados los activos y llevar una administración efectiva.
3. Establecimiento de propiedades. Una vez realizados los anteriores puntos,
definiremos los atributos o propiedades que necesitamos almacenar o
registrar de cada tipo de activo identificado. Ejemplo: Para el tipo de activo
“Licencias”, se requiere guardar el nombre, versión, fecha de ingreso, fecha
de instalación, equipo donde se encuentra, etc.
4. Etiquetas en bienes. Para llevar un mejor control y una buena coordinación,
se recomienda adherir una etiqueta en el bien, con el mismo número de
identificación con el que se encuentra registrado en la bitácora del inventario.
65
5. Asignar un responsable. Cada vez que se despache un bien del
departamento, registrar el espacio donde ha sido ubicado y el nombre de la
persona que se le ha asignado el bien.
6. Control por estados. Los bienes de un departamento informático, se
aconseja que sean controlados por estados.
Herramientas para construcción de software
En los anteriores apartados, se ha realizado una investigación acerca de la
fundamentación teórica relacionada a la lógica del negocio que se maneja en la
presente propuesta. Los siguientes temas a tratar conciernen netamente a la parte
técnica del proyecto, es decir, la exploración de los instrumentos informáticos y la
arquitectura que van a permitir la construcción del sistema de requerimientos.
Aplicaciones basadas en web
En pleno 2017, las aplicaciones web han desplazado a las antiguas aplicaciones de
escritorio. Y es que existe una clara diferencia entre estas dos clases de aplicaciones,
que a la vez representa la ventaja más grande que una aplicación basada en
tecnología web posee, y es el acceso al sitio a través del Internet.
Desde cualquier lugar, desde cualquier dispositivo con conexión a internet y a
cualquier hora, a través de una aplicación web los usuarios pueden ingresar. Esta
demanda se ha incrementado alrededor del mundo, gracias a que la población
mundial, cada día tiene mayor acceso al servicio de internet; al contar con más gente
dirigiendo su atención a este medio, ha provocado la apertura de otro canal de
intercambio de información. Por lo que el mercado del desarrollo de software ha
66
posicionado a las aplicaciones web en las favoritas a la hora de realizar la
construcción de una solución tecnológica para cualquier tipo de negocio.
Por otra parte, el Profesor Titular de Universidad del Departamento de Lenguajes y
Sistemas Informáticos de la Universidad de Alicante Sergio Lujan Mora manifiesta
que una aplicación web es un tipo de aplicación cliente-servidor donde el navegador,
el servidor web y el protocolo http se encuentran homologados. Esta característica
representa una ventaja para las aplicaciones web, puesto que el desarrollador o el
programador, no deberá preocuparse en crear esta comunicación, puesto que ya
existe. (Luján Mora, 2002)
GRÁFICO N°. 10: Esquema básico de una aplicación web
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
En el gráfico N. 10, se puede observar una clara interacción entre un cliente y una
aplicación web. Podemos notar como el cliente se conecta al sitio a través de la web,
específicamente por el protocolo http y contacta con el servidor web, donde se
encuentra alojada la aplicación en sí. A su vez cuando el servidor ejecuta la
transacción enviada en la solicitud, devuelve al cliente la respuesta a través de este
mismo protocolo. Esta configuración es conocida como arquitectura cliente/servidor y
es la estructura básica de la que está conformada una aplicación web.
67
Ventajas de construir una aplicación web
Según el autor Cardador Cabello, existen varias ventajas para elegir el desarrollo de
un software, con las tecnologías que ofrece una aplicación web, por lo que a
continuación mencionamos algunas de ellas (Cardador Cabello, 2015) :
Multiplataforma. Una aplicación web no depende del sistema operativo que
el cliente posea en su máquina, puesto que el cliente se comunica a través de
una URL que es donde podrá acceder al sistema, el cual está alojado en un
servidor independiente de la máquina cliente.
Actualización en línea. Atrás quedaron los largos procesos de
actualizaciones en cada máquina del cliente. Las aplicaciones web al tener
sus fuentes centralizados en un servidor web, administrado mayormente por
técnicos informáticos, basta actualizar los nuevos features en el servidor para
que todos los clientes automáticamente puedan acceder a la aplicación web
actualizada. Sin duda esta ventaja beneficio tanto al técnico por el ahorro de
tiempo, así como al cliente que máximo en un par de horas programadas,
logrará visualizar las nuevas funcionalidades del software.
Ahorro de espacio en máquinas clientes. Tal como se ha mencionado, las
aplicaciones web operan sobre un computador distinto al del cliente, por lo que
respecta al compartimiento de archivos o fuentes, se encuentran en el servidor
y no ocupa espacio en el disco duro de los clientes.
Facilidad en compartición y acceso a la información. Tener una
plataforma donde se pueda subir información a un solo sitio, ya sea por el
administrador del sitio o por parte de los usuarios, garantiza que la información
sea más fácil y por ende más rápida de ser transmitida a los clientes.
Amplia compatibilidad con dispositivos. Una aplicación web puede ser
accedida desde cualquier dispositivo que tengan un browser o un navegador
web.
68
Alta disponibilidad. Como parte de las estrategias en la implementación de
un sistema web, con el fin de garantizar la disponibilidad de una aplicación, se
encuentra la elaboración de un plan de contingencia, el cual contiene las
medidas que se deben de ejecutar para restaurar el servicio en el menor
tiempo posible. Un entorno web, facilita y acelera el restablecimiento del
servicio, puesto que las tareas a ejecutarse se realizan únicamente sobre el
hardware y software del servidor.
Arquitectura de software
Para desarrollar la propuesta se investigan modelos de arquitectura de software para
la estructuración del proyecto. Para comprender mejor este tema, primero citaremos
una definición en sí del término arquitectura de software. Según Ramos Salavert y
Lozano Pérez:
“Se entiende por Arquitectura de Software a la representación de alto
nivel de la estructura de un sistema o aplicación, que describe las partes
que la integran , las interacciones entre ellas, los patrones que
supervisan su composición, y las restricciones a la hora de aplicar los
patrones” (Ramos Salavert & Lozano Pérez, 2000)
Existen múltiples modelos de arquitecturas de software; la selección para trabajar
con alguna de ellas se realiza dependiendo del tipo de proyecto, las funcionalidades
esperadas, ubicación física y nivel de seguridad requerido.
De acuerdo al análisis y evaluación de estos aspectos, para la presente propuesta se
ha seleccionado la arquitectura de tres capas, de la cual detallaremos un poco más
en la siguiente sección.
69
Modelo tres capas
Partiendo que las aplicaciones web, se basan en el modelo de arquitectura
cliente/servidor, este mismo modelo, permite identificar y separar claramente las
responsabilidades de una aplicación web en un modelo mucho más desacoplado, es
así, que bajo estas premisas se desarrolla el modelo tres capas.
Según Flórez Fernández, cada capa se debe centralizar en un servicio o característica
de la aplicación. Por ejemplo si se desarrolla una capa de presentación, las clases
que se relacionen con esta primera capa, deberán desarrollarse en otra capa
independiente; por lo general esta nueva capa representa la capa de transacciones
con datos. (Flórez Fernández, 2012)
De acuerdo al enfoque de los componentes propios de esta arquitectura, se identifican
tres tipos de capas y cada una de ellas cumple con una función específica:
Capa de presentación. Esta capa representa las interfaces o pantallas con
las que interacciona directamente el usuario desde un navegador web. A
través de ella, se envía y recibe la información para que logre ser visualizada
por el cliente.
Por este motivo se afirma que esta capa debe ser cuidadosamente diseñada,
es decir, la interfaz tiene que ser clara, amigable y sencilla de manejar, ya que
es el contacto directo con el usuario. Esta capa interacciona directamente con
la capa de lógica de negocio.
Capa de lógica del negocio. Esta capa abarca todas las reglas que se deben
cumplir, relacionadas al negocio que está dirigida la aplicación.
Es el núcleo de la aplicación y se encarga de gestionar las solicitudes entre la
capa de presentación y la capa de datos.
Capa de datos. Esta capa contiene todas las transacciones de la base de
datos de la aplicación, incluso de existir interacciones con otros sistemas, en
esta capa se desarrollan los procesos de conexiones a las bases de datos
externas al sitio.
70
A través de esta capa se logra consultar, ingresar, actualizar y eliminar de las
estructuras de las bases de datos.
A continuación, en el gráfico 11 se encuentran graficadas las capas que intervienen
en esta arquitectura.
GRÁFICO N°. 11: Arquitectura tres capas
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
Ventajas del modelos tres capas
Con este modelo, las capas de una aplicación pueden estar distribuidas de varias
formas, es decir, la capa de negocio y la capa de datos en un solo servidor o bien la
capa de negocio y la capa de datos en servidores distintos, siendo esta última la
distribución más óptima ya que de esta manera se alcanza un mayor rendimiento del
sitio; esta característica se llama escalabilidad.
El desacoplamiento entre cada capa, convierte este tipo de arquitecturas en el modelo
ideal para realizar tareas de mantenimiento en alguna capa en específico, puesto que
cada una cumple con una función única. De esta forma si se desea incorporar algún
71
procedimiento de base de datos, bastará con realizar los cambios en la capa de datos
y este cambio no afectará a las demás capas.
A nivel de programación, para el modelo de tres capas, existe una amplia gama de
patrones de desarrollo de software y frameworks, por lo que facilita la implementación
de este tipo de arquitectura.
Visual Studio 2015
Visual Studio es un entorno para el desarrollo de código de aplicaciones perteneciente
a la compañía Microsoft. Este IDE (Integrated Development Enviroment) tiene
incorporado herramientas para armar interfaces gráficas, ejecutar tareas de
compilación y depuración del código.
En el sitio oficial de Microsoft, indica que esta herramienta:
“Permite escribir código de manera precisa y eficiente sin perder el
contexto del archivo actual. Puede acercar fácilmente los detalles, como
la estructura de llamadas, las funciones relacionadas, las inserciones en
el repositorio y el estado de las pruebas” (Microsoft, 2017)
Con Visual Studio, se puede construir distintos tipos de aplicaciones y en varios
lenguajes como C# .NET, VB .NET, C++, PHP, Python, HTML, CSS, JavaScript,
JSON, Bootstrap, JQuery, Angular entre otros.
Lenguaje de Programación C SHARP
Un lenguaje de programación es una secuencia de órdenes escritas en código, el
cual, al ser compilado se vuelve en un lenguaje entendible para la máquina. Podemos
decir que es un conjunto de secuencias programadas por un humano, a través de las
cuales, logramos comunicarnos con una computadora, para que cumpla tareas
específicas.
72
Tal como se mencionó anteriormente, existen múltiples de lenguajes de
programación, sin embargo, en este apartado nos enfocaremos en el lenguaje de
programación C SHARP, el cual corresponde a esta propuesta.
Entre los artículos de Microsoft expuesto por Bill Wagner, uno de los desarrolladores
C # más destacados del mundo y miembro del Comité de Normas CMA de ECMA,
indica que es un lenguaje simple, seguro y orientado a objetos. Compila aplicaciones
ejecutables en .NET Framework. Además de tener ciertas características en sintaxis
con el conocido lenguaje C. (Wagner, 2017)
Entre las características que se destacan en el uso de C SHARP como lenguaje de
programación en el desarrollo de proyectos se encuentran:
Sencillo. Es un lenguaje sencillo ya que consta de elementos claros y fáciles
de ser manipulados en la programación.
Lenguaje orientado a objetos. Con este lenguaje se logra desarrollar código
de acuerdo a las características propias del paradigma de la programación
orientada a objetos tales como: herencia, polimorfismo y encapsulación.
Amplia compatibilidad. Al ser un lenguaje muy similar a Java, C y C++ torna
la migración de código mucho más sencilla.
Estructuración por componentes. C SHARP es un lenguaje orientado a
componentes, por lo que dentro de sus librerías ya incluye objetos que cumple
funciones específicas, los cuales a diferencia de otros lenguajes de
programación, no es necesario construirlos, puesto que ya se encuentran a
disposición de los desarrolladores para que sean utilizados, volviendo la
programación con este lenguaje mucho más fluida.
Excepciones detalladas. A nivel de programación, el tratamiento de
excepciones que incluye C#, es más rico que otros lenguajes. Esta
característica es muy útil para los desarrolladores, ya que permite tener un
panorama mucho más amplio de errores, para que el manejo de excepciones
sea más eficaz y las soluciones sean eficaces.
73
Seguridad integrada. En este aspecto CSHARP posee un nivel de seguridad
avanzado para las aplicaciones. Funciona a través de permisos, es así, que
únicamente se ejecuta el código propio de la aplicación; si algún otro código
perteneciente a otro fabricante pide ejecutarse, la seguridad de CSHARP, no
lo permite, al menos que previamente el administrador, le haya otorgado los
permisos necesarios.
Framework 4.5.2
Framework es un marco de trabajo que contiene un conjunto de herramientas, guías,
funciones, componentes y bibliotecas, que se encuentran disponibles para que el
desarrollador de aplicaciones las utilice según sus necesidades, con el fin de construir
una aplicación informática de una manera sencilla.
La elección de un marco de trabajo se realiza de acuerdo al lenguaje de
programación, las seguridades, las funciones que incluyen las librerías del framework
y que sirven para el tipo de proyecto que se va a desarrollar.
En este caso, al utilizar el lenguaje de programación C#, se ha seleccionado el
framework 4.5.2. Esta versión incluye mejoras en cuánto a las interfaces gráficas, en
depuración del código y perfiles de seguridad.
Servidor web IIS (Internet Information Service)
Para Villada Romero un servidor web es un sistema que recepta peticiones, llamadas
técnicamente como requests, enviadas desde un browser instalado en varias
máquinas clientes. El servidor web es el encargado de gestionar estas peticiones
sirviendo o entregando información para que sea visualizada por el usuario solicitante.
(Villada Romero, 2014)
El IIS o bien conocido en el idioma español como el Servicio de Información de
Internet, es el servidor web que gestiona las páginas de las aplicaciones creadas bajo
74
los entornos de desarrollo de Microsoft. Entre las principales configuraciones que se
pueden realizar a través del IIS se encuentran:
Configuración de puerto TCP. A través de este puerto, se comunica el IIS
con las máquinas clientes. Por defecto utiliza el puerto 80, sin embargo, en
ocasiones se necesita cambiar el número de puerto por el que se requiere que
nuestra aplicación salga. La interfaz gráfica del IIS, permite realizar esta tarea
de forma sencilla.
Habilitar funciones SSL. SSL es un protocolo criptográfico que permite
intercambiar información sensible a través de un canal seguro. Cuando se
manejan ciertos datos delicados, la habilitación de este protocolo es sustancial
para que ningún intruso pueda interrumpir o adulterar los mensajes.
Configuración de página por defecto. Al ser el IIS un gestionador de las
páginas de web de los aplicativos que residen en él, a través del mismo se
puede configurar la página de inicio que deseamos que cargue en el aplicativo
cada vez que se acceda a él.
Número máximo de conexiones. Se refiere que a través del IIS, se puede
configurar el número de clientes que se desea limitar para el acceso a la
aplicación de manera simultánea.
Log de aplicaciones. Dentro del IIS existe la opción para habilitar el registro
de las solicitudes http y errores que se pueden presentar en la aplicación. Por
lo general, este registro ayuda al administrador del sitio desde realizar un
análisis de estadísticas basadas en este registro, hasta el análisis de los
errores de la aplicación, para proceder a mitigar los mismos, por lo que
representa una gran ayuda para monitorear cualquier comportamiento
anormal que se pueda estar presentando en el aplicativo.
Configuración de timeout. Este servidor de aplicaciones permite configurar
el tiempo determinado en segundos, que se desea cerrar la conexión por
inactividad del cliente.
75
Configuración de CPU. Esta funcionalidad del IIS, permite limitar el ancho de
banda, la memoria RAM y la CPU, creando una regla en servidor.
Seguridad en FTP. Dentro del ISS, podemos configurar el número de
ingresos según los intentos fallidos, permitidos durante un lapso de tiempo.
Esta función permite mantener el acceso a los archivos que se manejan en
una aplicación mucho más seguros.
ASP.NET (Active Server Pages)
Previamente a la presentación de ASP.NET, existía la tecnología ASP o conocida es
castellano como Páginas de Servidor Activas, la cual fue lanzada en el año 1996 por
la compañía Microsoft. Está tecnología se ejecutaba del lado del servidor y lo hacía a
través de fragmentos de código insertados dentro del código HTML, lo cual tornaba a
las aplicaciones que estaban desarrolladas en esta tecnología, inseguras. Este tipo
de práctica, funcionaba, pero no era distributiva ni desacoplada en absoluto, ya que
combinaba la interfaz gráfica y la lógica de negocio del aplicativo; este detalle volvía
las aplicaciones desarrolladas bajo este framework en una aplicación más tediosa de
mantener.
Es relevante mencionar, que esta solución era un tanto limitada, ya que los scripts
podían ser codificados únicamente en código Visual Basic y Java; por lo que eran
conocidos como lenguaje VBScript y JScript respectivamente.
76
GRÁFICO N°. 12: Funcionamiento de las páginas ASP
Autor: (Berzal, Cortijo, & Cubero , 2005)
Fuente: (Berzal, Cortijo, & Cubero , 2005)
En el gráfico N. 12, se muestra como el HTML es enviado con producto de la ejecución
del código servidor.
A mediados del año 2000, durante el evento Microsoft's Professional Developers
Conference se lanza oficialmente el framework .NET y consigo la aparición del nuevo
lenguaje C#.NET y Visual Basic.NET (su nomenclatura hace alusión al framework
sobre el que trabajan). (Anders, 2000)
Con la aparición de .NET, ASP evoluciona a ASP .NET oficialmente lanzado a inicios
del año 2002; y si bien sus nombres son similares, las diferencias en tecnologías son
totalmente distintas.
La característica más sobresaliente de ASP .NET es la estructuración del código, ya
que esta versión permite separar la interfaz gráfica, de la lógica de negocio de la
aplicación, logrando separar las responsabilidades en capas y desarrollando el
concepto de aplicaciones distribuidas.
77
Según Duthie, G. Andrew y MacDonald, Matthew, ASP.NET en comparación al ASP
clásico muestra enormes diferencias, como los controles de servidor, un modelo de
programación más potente y soporte para web services XML. (Duthie & MacDonald,
2003)
Por otra parte, al no exponer el código dentro de los formularios web que se ejecutan
en el navegador del cliente, se mejora enormemente la seguridad dentro de las
aplicaciones.
GRÁFICO N°. 13: Funcionamiento de las páginas ASP.NET
Autor: (Berzal, Cortijo, & Cubero , 2005)
Fuente: (Berzal, Cortijo, & Cubero , 2005)
En el gráfico N. 13 se puede observar cómo interactúan los controles en una interfaz
gráfica de una página ASP.NET, con los manejadores de eventos propios de esta
versión y que se encuentran en el servidor web.
CSS
En su obra literaria Durango, indica que CSS se rige bajo los estándares de
Cascading Style Sheets, mejor conocido en español como Hojas de estilo en cascada,
78
representa el formato a seguir para las páginas escritas en formato HTML. (Durango,
2015)
El concepto de CSS (Cascading Style Sheet) va de la mano con el origen de HTML
(HyperText Markup Language), el lenguaje de marcado que se utiliza para construir
páginas web. Como bien lo mencionamos, HTML corresponde únicamente a la
estructura en sí de la página de Internet; en sus inicios este lenguaje de marcado no
poseía un formato en lo que respecta a diseño, con esta premisa es como nace el
concepto de CSS.
GRÁFICO N°. 14: Estructura de un documento HTML con CSS
Autor: (Sconce & Hewitt, 2010)
Fuente: (Sconce & Hewitt, 2010)
De esta manera, con la creación de CCS se logra separar la estructura del
documento, de la parte que respecta al diseño, volviendo mucho más organizado el
tratamiento del documento web.
79
Estas prácticas permiten que el mantenimiento de las páginas sea más sencillo,
puesto que en lugar de actualizar los estilos página por página, al encontrarse
centralizados en un solo archivo CSS, totalmente independiente del HTML, se
procede a actualizar únicamente el CSS del archivo, a diferencia que si no existiera y
tuviéramos que modificar cada una de ellas.
Base de datos
Según Nevado Cabello, una base de datos es una colección de datos relacionados
entre sí, almacenados en un repositorio; dota de información de manera eficiente a
cualquier aplicación que se conecte a ella. (Nevado Cabello, 2010)
Previamente al ingreso de la era tecnológica, las empresas manejaban y guardaban
la información a través de ficheros, portafolios y enormes archivadores. El desarrollo
tecnológico por el que ha atravesado la sociedad, ha hecho que prácticamente todas
las empresas enfocadas en los diferentes tipos de negocio como educación, salud,
economía, transporte y ente otros, involucren en sus procesos, la integración de
programas informáticos, para facilitar estos procesos que antes eran manuales. A
través de estos programas, se manejan datos de entrada que son procesados y
finalmente como salida ofrecen resultados. Es de vital importancia que estos datos se
encuentren almacenados y centralizados en un solo sitio, para que puedan ser
administrados de forma correcta, se maneje de forma eficiente y se reduzca el margen
de error en las consultas de los mismos. Como respuesta a esta necesidad, las
empresas involucradas en el negocio informático empiezan a crear los primeros
programas para manejo de datos y hasta la actualidad, en pleno 2017, podemos decir
que la demanda para el desarrollo y manejo de datos se ha disparado, debido a la
relevancia que representa en esta época el Internet y la utilización de varios
dispositivos diariamente por la sociedad. De este modo se desarrolla el concepto de
base de datos.
El desarrollo de este tema en esta propuesta, es importante tratarlo debido a que está
ligado a la aparición de las bases de conocimiento como recurso de gestión y
aprendizaje de los procesos de una empresa. Personalmente, se eligió este medio
80
para la gestión de conocimiento ya que consideramos importante el hecho de tener
todos los conocimientos centralizados en un solo sitio, administrado por el personal
propiamente del negocio, donde a lo largo del tiempo se logre actualizar esta
información y consultarla, para tener datos reales y actuales al alcance de todos los
miembros de una empresa.
SQL Server 2014 Express
En el presente año 2017, podemos manifestar que existen en el mercado múltiples
sistemas de bases de datos, cada uno con características propias, sin embargo en
esta sección nos dedicaremos a una sola BD, la cual es la que utilizaremos en el
desarrollo de este trabajo y es SQL Server 2014.
Desde el punto de vista de Pérez Marqués, SQL Server contiene una amplia gama de
herramientas para el desarrollo y administración de bases de datos, ideales para
implementar cualquier solución. (Pérez Marqués, 2011)
GRÁFICO N°. 15: Componentes de SQL Server
Autor: (TechNet, 2017)
81
Fuente: (TechNet, 2017)
Tal como lo indica Pérez Marqués, SQL Server en un sistema, es decir, está integrado
por un conjunto de servicios, los cuales se encuentran relacionados entre sí con el fin
de tratar en su totalidad todo lo relacionado a las bases de datos. En el gráfico N. 15,
podemos observar los componentes que incluye SQL Server. A continuación
explicaremos de forma breve la función de cada uno de ellos.
Motor de base de datos. Este servicio es el encargado principalmente de
guardar la información, la procesa y es el responsable de la protección de los
mismos.
Service Broker. Este servicio se encarga de controlar las comunicaciones y
mensajerías del motor de base de datos.
Replicación. Este servicio ofrece sincronizar la información almacenada de
una base a otra, independientemente de la ubicación que se encuentra esta
otra BD. De esta manera con este servicio, se asegura la disponibilidad de los
datos, ya que se respalda la información para no depender únicamente de un
almacén, sino tener siempre un plan de contingencia ante cualquier
eventualidad.
Reporting services. Como su nombre lo indica su nombre, este servicio
facilita la generación de informes para la organización.
Analysis services. En grafico 13 se logra observar dos elementos que forman
parte de este servicio: la minería de datos y los datos multidimensionales. Este
servicio se encuentra enfocado en proporcionar las herramientas necesarias
para trabajar en soluciones complejas que involucran estos dos campos.
Integration services. Este servicio proporciona servicios de integración de
información para soluciones de empresas.
Para el desarrollo de esta propuesta se va a utilizar SQL Server 2014, versión
Express, el cual ofrece una versión de almacén de datos confiable y potente. De esta
82
manera en el libro Microsoft SQL Server 2014 Unleashed se manifiesta que esta
versión es gratuita, ligera, incorporable y redistribuible de. Incluye una versión
reducida de SQL Server Management Studio, llamada SQL Server Management
Studio Express, para administrar fácilmente una instancia de SQL Server Express y
su Bases de datos (Rankins, Bertucci, Gallelli, & Silverstein, 2015)
FUNDAMENTACIÓN LEGAL
El desarrollo de esta propuesta se fundamenta en las siguientes bases legales
jurídicas que expide la Asamblea Nacional del Ecuador:
Sección Octava Ciencia, tecnología, innovación y saberes ancestrales
Art. 385.- El sistema nacional de ciencia, tecnología, Innovación y saberes
ancestrales, en el marco del respeto al ambiente, la naturaleza, la vida, las culturas y
la soberanía, tendrá como finalidad:
1. Generar, adaptar y difundir conocimientos científicos y tecnológicos.
2. Desarrollar tecnologías e innovaciones que impulsen la producción
nacional, eleven la eficiencia y productividad, mejoren la calidad de vida y
contribuyan a la realización del buen vivir.
3. Desarrollar tecnologías e innovaciones que impulsen la producción
nacional, leven la eficiencia y productividad, mejoren la calidad de vida y
contribuyan a la realización del buen vivir.
Art. 386.- El sistema comprenderá programas, políticas, recursos, acciones, e
incorporará a instituciones del Estado, universidades y escuelas politécnicas,
institutos de investigación públicos y privados, empresas públicas y privadas,
83
organismos no gubernamentales y personas naturales o jurídicas, en tanto realizan
actividades de investigación, desarrollo tecnológico, innovación…
El Estado, a través del organismo competente, coordinará el sistema, establecerá los
objetivos y políticas, de conformidad con el Plan Nacional de Desarrollo, con la
participación de los actores que lo conforman.
Art. 387.- Será responsabilidad del Estado:
1. Facilitar e impulsar la incorporación a la sociedad del conocimiento para
alcanzar los objetivos del régimen de desarrollo.
2. Promover la generación y producción de conocimiento, fomentar la
investigación científica y tecnológica, y potenciar los saberes ancestrales, para
así contribuir a la realización del buen vivir, al sumak kawsay.
3. Asegurar la difusión y el acceso a los conocimientos científicos y
tecnológicos, el usufructo de sus descubrimientos y hallazgos en el marco de
lo establecido en la Constitución y la Ley.
4. Garantizar la libertad de creación e investigación en el marco del respeto a
la ética, la naturaleza, el ambiente, y el rescate de los conocimientos
ancestrales.
5. Reconocer la condición de investigador de acuerdo con la Ley.
Adicionalmente se realizó una inspección en el Código de Ética de la Universidad de
Guayaquil, donde en el Artículo 18, se refiere de las actividades de orientación al
usuario:
Art. 18.- La Universidad de Guayaquil, centra su atención y su estrategia en la
satisfacción de las necesidades y expectativas de los usuarios y usuarias. Es la
sociedad, la que demanda una garantía de la calidad de la educación superior,
incluyendo la docencia, la investigación, la transferencia de conocimiento y la gestión.
84
Por tanto, las actividades y servicios realizados por la Institución están enfocados en
satisfacer esta demanda.
PREGUNTA CIENTÍFICA A CONTESTARSE
Con el desarrollo del sistema de gestión de requerimientos informáticos ¿Se aportará
con un modelo de optimización para la gestión y el control de requerimientos del
departamento de sistemas de las Carreras de la Facultad de Ciencias Matemáticas y
Físicas de la Universidad de Guayaquil?
La integración de una base de conocimientos en el sistema de gestión de
requerimientos informáticos ¿Logrará establecer un modelo para centralizar,
compartir y acceder a la información del conocimiento del personal del departamento
de sistemas de las Carreras de la Facultad de Ciencias Matemáticas y Físicas de la
Universidad de Guayaquil, a través del tiempo?
DEFINICIONES CONCEPTUALES
Tecnología: Conjunto de teorías y de técnicas que permiten el aprovechamiento
practico del conocimiento científico. (RAE, 2017)
Información:
Elemento de conocimiento susceptible de ser representado mediante signos conven
cionales osímbolos, y conservado, tratado o comunicado por medios informáticos.
(Farlex, 2017)
Gestión: El término gestión es utilizado para referirse al conjunto de acciones,
o diligencias que permiten la realización de cualquier actividad o deseo. Dicho de otra
manera, una gestión se refiere a todos aquellos trámites que se realizan con la
85
finalidad de resolver una situación o materializar un proyecto. En el entorno
empresarial o comercial, la gestión es asociada con la administración de un negocio.
(Venemedia, 2017)
Incidente: Un incidente es aquello que acontece en el curso de un asunto y que
cambia su devenir. (Definicion.de, 2017)
Problema: Un problema es un asunto o cuestión que se debe solucionar o aclarar,
una contradicción o un conflicto entre lo que es y lo que debe ser, una dificultad o un
inconveniente para la consecución de un fin o un disgusto, una molestia o una
preocupación. (7Graus, 2017)
Metodología: El término metodología se define como el grupo de mecanismos o
procedimientos racionales, empleados para el logro de un objetivo, o serie de
objetivos que dirige una investigación científica. (Venemedia, 2017)
Lenguaje de programación: En informática, cualquier lenguaje artificial que puede
utilizarse para definir una secuencia de instrucciones para su procesamiento por un
ordenador o computadora. (EcuRed, 2017)
ISO 20000: ISO 20000 es la norma internacional sobre Gestión de servicios de TI
(ITSM), publicada por ISO (Organización Internacional de Normalización) e ICE
(Comisión Electrotécnica Internacional). La norma describe un conjunto de procesos
de gestión diseñados para ayudarle a brindar servicios de TI más eficaces (tanto
dentro de su empresa como para sus clientes). (AdviseraExpertSolutions, 2017)
Herencia: La herencia es específica de la programación orientada a objetos, donde
una clase nueva se crea a partir de una clase existente. La herencia (a la que
habitualmente se denomina subclase) proviene del hecho de que la subclase (la
nueva clase creada) contiene los atributos y métodos de la clase primaria.
Polimorfismo: Esta característica permite definir distintos comportamientos para un
método dependiendo de la clase sobre la que se realice la implementación. En todo
momento tenemos un único medio de acceso, sin embargo se podrá acceder a
métodos distintos. (Ciberaula, 2017)
86
Encapsulación: Es el proceso de almacenar en una misma sección los elementos
de una abstracción que constituyen su estructura y su comportamiento; sirve para
separar el interfaz contractual de una abstracción y su implantación. (Styde, 2017)
Requerimiento: Un requerimiento puede definirse como un atributo necesario dentro
de un sistema, que puede representar una capacidad, una característica o un factor
de calidad del sistema de tal manera que le sea útil a los clientes o a los usuarios
finales. (Wikiteka, 2011)
87
CAPÍTULO III
PROPUESTA TECNOLÓGICA
La presente propuesta tecnológica comprende el desarrollo de una aplicación web
para la automatización de los procesos de captación de requerimientos, organización
en el registro de los equipos computacionales y la elaboración de un sistema para
almacenar las experiencias de los técnicos, con el fin de obtener un mayor control
sobre la gestión y administración del Departamento Informático para las tres carreras
que abarcan la Facultad de Ciencias Matemáticas y Físicas de La Universidad de
Guayaquil. Este proyecto será desarrollado empleando la metodología a ágil SCRUM.
Análisis de factibilidad
Durante la elaboración de la propuesta se analizan varios factores para determinar
las oportunidades de éxito que concibe el desarrollo de un sistema de gestión de
requerimientos para los departamentos de hardware y software de las carreras en
mención. Los cuatro aspectos que permitirán diagnosticar esta situación son:
El análisis de factibilidad operacional.
El análisis de factibilidad técnico.
El análisis de factibilidad Legal.
El análisis de factibilidad económico.
A partir de la siguiente sección se desarrolla cada uno de estos temas, los cuales
representan un punto de vista diferente para evaluar la viabilidad del proyecto
planteado.
88
Factibilidad Operacional
Previo al desarrollo de la propuesta, el instrumento que ayudó a conocer que tan
necesario es la automatización de los procesos de gestión de requerimientos para los
departamentos de hardware y software de la Facultad de Matemáticas y Físicas de la
UG, fue la entrevista realizada a los jefes de los departamentos.
Entre los principales malestares que comentaban los entrevistados fueron:
No existe un repositorio centralizado para registrar los requerimientos que
diariamente se gestionan en el departamento.
Al no contar con una gestión eficiente, se tiende a olvidar atender ciertos casos que
han sido reportados a última hora y ante cualquier eventualidad, al día siguiente, al
no encontrarse registrado, no existe una comunicación efectiva entre los miembros
del departamento, a través de la cual se logren enterar que un requerimiento se
encuentra pendiente de atender.
El inventario de los equipos de hardware y software de la carrera, respecta como una
responsabilidad que debe ser llevada por el departamento. Esta tarea se realiza en
archivos de Excel, de modo que cuando la administración solicita algún reporte, el
mismo es generado en base a este fichero. La inversión de tiempo en este proceso,
es superior al que se emplearía si toda la información se encontraría integrada en una
base de datos y disponibilizada a través de una interfaz gráfica.
El conocimiento que les brinda la experiencia, que adquieren los miembros del
departamento en la solución de requerimientos, no se registra en ninguna bitácora,
por lo que cada vez que estos recursos abandonan su cargo, existe una curva de
aprendizaje grande para la capacitación de nuevos técnicos.
En una ocasión surgió la propuesta de un sistema que permita gestionar estos
elementos. Según el Ing. Jorge Enrique Alvarado Chang, Coordinador de Software de
la CISC y la Carrera de Ingeniería en Networking y Telecomunicaciones, reconoce
89
que dicha herramienta no era amigable y más bien obstaculizaría las tareas diarias
del departamento.
Toda esta información, permitió proponer a los jefes de cada departamento una
propuesta informática, que sea totalmente útil para administrar y controlar la gestión
requerimientos. En el Anexo N. 1 se encuentra el guion de la entrevista realizada a
los encargados del área de sistemas de cada carrera de la FCMF.
De tal manera al plantear esta ayuda, es necesario manifestar que el presente
proyecto cuenta con el total apoyo de los beneficiarios, ya que para su elaboración se
ha recogido la información necesaria y funcionalidades deseadas para que el sistema
les contribuya de manera positiva en sus labores diarias y se convierta en la principal
herramienta que les permita gestionar, agilizar e incrementar la productividad del
departamento, mitigando los procesos manuales.
Adicionalmente, cabe mencionar que las interfaces gráficas de la propuesta han sido
cuidadosamente diseñadas, con el propósito de brindar a los usuarios una interacción
sencilla, cómoda e intuitiva con el software, de tal manera que los incentive a usar
nuevamente el sistema.
Dadas las consideraciones anteriores, se determina que gracias a los beneficios que
representa el proyecto y la validación realizada con los entrevistados, es una
propuesta factible desde el punto de vista operacional.
Factibilidad técnica
Debido a que la propuesta planteada es un proyecto de desarrollo tecnológico,
intervienen elementos de hardware y software, por lo cual es necesario especificar
las características necesarias, para que el sistema de gestión de requerimientos se
desempeñe de manera correcta.
90
En la tabla N. 1 se detallan los requisitos mínimos de hardware y software que se
requieren para el desarrollo de la aplicación web.
91
TABLA N°. 1: Requisitos para desarrollo del sistema
Tipo de elemento Características mínimas
Hardware
Procesador Core i3, 2.60 GHz
Memoria RAM 4 GB
Disco duro 250 GB
Software
IDE Visual Studio 2015 (LP C#.NET)
Framework 4.5.2
SQL Server 2014 Express
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
En la tabla N. 2 se especifican los requisitos mínimos de hardware y software que
debe poseer el servidor donde se alojará el sistema web.
TABLA N°. 2: Requisitos de servidor donde se alojará la aplicación
Tipo de elemento Características mínimas
Hardware
Procesador Core i5, 2.60 GHz
Memoria RAM 8 GB
Disco duro 500 GB
Software
Sistema Operativo Windows Server 2008 R2
Framework 4.5.2
Servidor web IIS 7.5
SQL Server 2014 Express
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
92
93
Cabe recalcar que en la presentación de la propuesta la capa de base de datos y la
capa de negocio, se encuentran alojadas en un solo servidor como se evidencia en
la tabla N. 2. Sin embargo la arquitectura de tres capas en la que está desarrollada la
aplicación es flexible y permitirá considerar en alguna instancia la separación de estas
dos capas, en dos servidores independientes, para mejorar aún más el rendimiento y
escalabilidad del sistema.
En la tabla N. 3 se especifican los requisitos mínimos de hardware y software que
deben poseer las estaciones de trabajo o máquinas clientes para que logren
interactuar de manera óptima con el sistema web de gestión de requerimientos.
TABLA N°. 3: Requisitos de servidor donde se alojará la aplicación
Tipo de elemento Características mínimas
Hardware
Procesador Core 2 dúo o superior, 1.60 GHz
Memoria RAM 1 GB
Disco duro mínimo 80 GB
Software Navegador web (Mozilla/Chrome)
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
Como se logra contemplar, los requisitos para el desarrollo, implementación y
utilización del sistema web son mínimos y más que nada representan recursos que
ya poseen los departamentos de hardware y software de las carreras beneficiarias de
la FCMF de la Universidad de Guayaquil. Por lo tanto, se determina que en el aspecto
técnico la propuesta es totalmente viable.
94
Factibilidad Legal
De acuerdo a las leyes y artículos revisados en el Capítulo II donde tanto la
Constitución de la República del Ecuador y el Código de Ética de la Universidad de
Guayaquil respaldan los proyectos tecnológicos, se logra determinar que la presente
propuesta, además de no infringir las leyes vigentes, en los reglamentos
mencionados, contribuye en el desarrollo de la produccion nacional y mejora los
servicios proporcionados por la Universidad de Guayaquil.
Por lo tanto, el proyecto se considera oportunamente viable, dado a que cumple con
las normas establecidas en el ámbito legal para su correcta operación.
Factibilidad Económica
Como parte del análisis de factibilidad se realiza la evaluación del aspecto económico
de los recursos de hardware y software mencionados en el análisis técnico. Por lo
que a continuación se detallan los costos asociados a la propuesta tecnológica
presentada:
TABLA N°. 4: Matriz de análisis de recursos económicos
Recurso Humano $0
Número Detalle Horas Costo/Hora Total
1 Desarrollador 1 1625 $5 $0
Recursos de hardware $0
Número Detalle Cantidad Costo Total
95
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
Como se logra visualizar en la tabla N. 4 en el análisis económico, respecto al recurso
humano empleado para desarrollar el proyecto, no se ha incurrido en gastos, puesto
que el desarrollo es de autoría propia.
En lo concerniente a los recursos de hardware, se identifica el equipo que utiliza el
desarrollador para codificar la aplicación, el mismo no genera ningún gasto. Luego se
considera el equipo que se requiere para instalar el sistema de gestión de
requerimientos; tal como se aprecia en el cuadro, no representa ningún costo, puesto
que los departamentos de hardware y software cuentan ya con estos equipos, los
cuales cumplen con las características mínimas para alojar la aplicación web.
Por último se encuentran los recursos de software, donde cabe recalcar que gracias
al convenio de licenciamiento pactado entre la empresa Microsoft y la Universidad de
Guayaquil se dispone de estas herramientas sin ningún costo.
De esta forma de acuerdo al análisis económico realizado se evidencia que al ser
costos mínimos los que se invierten en el proyecto, tanto por los recursos que ya se
disponen y los acuerdos de licencias existentes a la fecha con la UG, se describe
1 Equipo para desarrollo
1 $1000 $0
2 Equipo servidor de
aplicación y BD 1 $3000 $0
Recursos de Software $0
Número Detalle Cantidad Costo Total
1 Visual Studio 2015
1 $0 $0
2 SQL Server 2014
Express 1 $0 $0
3 Windows Server
2008 R2 1 $0 $0
96
como una propuesta viable desde el aspecto económico, considerando que los
beneficios son superiores.
97
Etapas de la metodología del proyecto
La metodología a utilizar para el desarrollo de la propuesta es la metodología ágil
SCRUM. Esta metodología, permitió desarrollar el proyecto de manera veloz y
flexible, dando apertura a la adaptación de las funcionalidades a través de su
desarrollo iterativo, con el objetivo de entregar un producto con más valor y calidad
para el usuario final. Tal como lo manifiesta en su obra literaria (Menzinsky, López, &
Palacio, 2016), la metodología SCRUM valora mucho más un software funcionando,
en lugar de la extensa documentación. En consecuencia, a continuación se detallan
los documentos únicamente necesarios, del manifiesto ágil generados en las etapas
de desarrollo de la propuesta.
1. Definición de roles
Para arrancar con el proyecto se especifican los roles que desempeñan los
interesados dentro de la propuesta.
Propietario del producto. Esta persona está encargada de proporcionar las
funcionalidades que se requieren para el desarrollo del sistema. En este caso
los dueños del proyecto son el Ing. Jorge Enrique Alvarado Chang,
Coordinador de Software de la Carrera Ingeniería en Sistemas
Computacionales e Ingeniería en Networking y telecomunicaciones y el Ing.
Denis Merchán Reyes, Coordinador de Software del Departamento de
Informática de la Carrera de Ingeniería Civil.
Scrum Master. El representante de este rol cumplirá la función de dar el
respectivo seguimiento al proyecto, generar observaciones y guiar al autor del
98
proyecto, con el objetivo de que se cumplan adecuadamente los objetivos de
la propuesta. El Ing. Darwin Cercado Barragán, tutor principal del proyecto de
titulación es el encargado de desempañar estas funciones dentro del
desarrollo del trabajo.
Equipo de desarrollo. Representa el elemento humano encargado de
desarrollar la propuesta. En este caso, la persona encargada de ejercer estas
funciones será el autor del presente trabajo de titulación el Sr. Jorge Andrés
Martínez Álvarez.
2. Pila del Producto (Product Backlog)
Durante esta etapa se documentan en una pila o lista ordenada, todas las
funcionalidades acordadas con el usuario y que necesita para interactuar en el
sistema de gestión de requerimientos. Dichas funcionalidades, se encuentran
transcritas en lenguaje de usuario, tal y como lo indica el formato de la
metodología Scrum. En la siguiente tabla se asigna un identificador de la
funcionalidad, la prioridad con la que se necesita que sea desarrollada, el título
de la HU y descripción de la misma.
TABLA N°. 5: Pila del producto del Sistema de Gestión de requerimientos
Id Prioridad Título Descripción
001 Alta Interfaces
deben de ser amigables
Como Coordinador de Software del Departamento de Informática, necesito que las interfaces del nuevo sistema sean amigables e intuitivas, para que el manejo del sistema sea una
99
verdadera ayuda para las personas que van a interactuar con el sistema.
002 Alta Control de
usuarios del sistema
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema para gestionar los usuarios, para ingresar, modificar o eliminar los registros según mi criterio.
003 Alta Control de los permisos del
sistema
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que me permita asignar los permisos a los usuarios en el sistema, para facilitar el acceso al sistema según mi criterio.
004 Alta Control de tipos de
requerimientos
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que me permita gestionar los tipos de requerimientos que se presentan en el departamento, para ingresar, modificar o eliminar los registros según mi criterio.
005 Alta Control de inventario
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que me permita gestionar el inventario a cargo del departamento, para llevar estos registros en el sistema de manera centralizada.
006 Alta Bandeja de
requerimientos Administrador
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que permita registrar y gestionar las solicitudes de requerimientos, para administrar estos registros en el sistema de manera eficiente y centralizada.
100
007 Alta Bandeja de
requerimientos Técnico
Como Técnico, necesito una opción en el sistema que permita visualizar las solicitudes de requerimientos que se me han sido asignadas, para proceder a atenderlas de manera oportuna.
008 Alta
Bandeja de requerimientos
Usuario solicitante
Como usuario solicitante, necesito una opción en el sistema que permita generar una solicitud de requerimientos, para notificar al departamento informática alguna novedad de software o hardware.
009 Media Control de
conocimientos
Como Coordinador de Software del Departamento de Informática, necesito que se cree en el sistema una base de conocimientos, para que el conocimiento se guarde en el sistema y pueda ser accedido en cualquier momento por alguno de los integrantes del departamento, sin importar la fecha.
010 Alta Control de
herramientas
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que me permita gestionar las herramientas que se utilizan en el departamento para resolver un requerimiento, para visualizar estos registros desde el mecanismo de la base de conocimientos.
011 Baja Generación de
reportes requerimientos
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que me permita generar reportes de los requerimientos, para llevar un mejor control y acelerar la entrega de esta información cuando la parte administrativa lo solicite.
101
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
3. Planificación de Sprints
Posteriormente a las definiciones generadas en la pila general del producto, se
procede a definir el tiempo de duración de cada Sprint. Para este caso se resolvió que
cada Sprint tendrá una duración 3 semanas, dando como resultado un número de 3
Sprints.
Así mismo, para organizar mejor el proyecto, de acuerdo a la metodología ágil
SCRUM, se va a emplear una herramienta de uso libre conocida como Trello. Esta
012 Baja
Generación de reportes de hardware y
software
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que me permita generar reportes de hardware y software ingresado, para llevar un mejor control del inventario.
013 Baja Generación de
reportes de herramientas
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que me permita generar reportes de las herramientas disponibles, para llevar un mejor control de las herramientas ingresadas.
014 Baja Generación de
reportes de conocimientos
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que me permita generar reportes de las entradas de conocimientos ingresados, para llevar un mejor control de las entradas ingresadas.
102
aplicación, permitirá gestionar y organizar las tareas del proyecto gestión de
requerimientos de acuerdo a los artefactos utilizados en esta metodología.
En el grafico N. 16 se visualiza la organización del proyecto; el product backlog
general, los sprints backlogs correspondientes a cada iteración y el estado de las
actividades organizadas en tres columnas: las tareas en estado “Pendiente”, las
cuales están por hacer, las tareas en estado “En curso” son aquellas que se están
ejecutando y las tareas en estado “Finalizado” las cuales se encuentran desarrolladas
al cien por ciento.
103
GRÁFICO N°. 16: Visualización de organización del proyecto en el Trello
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
4. Sprint 1
4.1. Pila del Sprint 1 (Sprint Backlog 1)
En la tabla N. 6 se especifica la pila con las historias de usuario que abarca el Sprint
1, acorde a las prioridades convenidas con los dueños del producto.
TABLA N°. 6: Pila del Sprint 1
Id Prioridad Título Descripción
001 Alta Interfaces
deben de ser amigables
Como Coordinador de Software del Departamento de Informática, necesito que las interfaces del nuevo sistema sean
104
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
amigables e intuitivas, para que el manejo del sistema sea una verdadera ayuda para las personas que van a interactuar con el sistema.
002 Alta Control de
usuarios del sistema
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema para gestionar los usuarios, para ingresar, modificar o eliminar los registros según mi criterio.
003 Alta Control de los permisos del
sistema
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que me permita asignar los permisos a los usuarios en el sistema, para facilitar el acceso al sistema según mi criterio.
004 Alta Control de tipos de
requerimientos
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que me permita gestionar los tipos de requerimientos que se presentan en el departamento, para ingresar, modificar o eliminar los registros según mi criterio.
005 Alta Control de inventario
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que me permita gestionar el inventario a cargo del departamento, para llevar estos registros en el sistema de manera centralizada.
105
Una vez establecida la pila del Sprint 1 (Sprint Backlog del Sprint 1), se analizan las
tareas a realizar para cumplir con la entrega del Sprint. En la siguiente tabla se detalla
el Id del requerimiento, la secuencia de la tarea con su descripción y la estimación en
horas que conlleva cada una de ellas.
TABLA N°. 7: Lista de tareas del Sprint 1
IdR IdT Responsable Tarea Estimación
(horas)
001 1 Andrés
Martínez Investigación y análisis de interfaces para diseño
5
001 2 Andrés
Martínez Diseño de modelo de interfaces
6
002 3 Andrés
Martínez
Diseño de estructuras en base de datos para administración de usuarios
6
002 4 Andrés
Martínez Diseño de interfaz gráfica para el login del sistema
5
002 5 Andrés
Martínez
Diseño de interfaz gráfica para la opción de administración de usuarios
4
002 6 Andrés
Martínez
Programación del acople ente base de datos e interfaces
6
002 7 Andrés
Martínez Pruebas Unitarias 2
003 8 Andrés
Martínez
Diseño de estructuras en base de datos para administración de permisos
5
106
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
003 9 Andrés
Martínez
Diseño de interfaz gráfica para administración de permisos
4
003 10 Andrés
Martínez
Programación del acople ente base de datos e interfaces
6
003 11 Andrés
Martínez Pruebas Unitarias 2
004 12 Andrés
Martínez
Diseño de estructuras en base de datos para administración de tipos de requerimientos
5
004 13 Andrés
Martínez
Diseño de interfaz gráfica para administración de tipos de requerimientos
5
004 14 Andrés
Martínez
Programación del acople ente base de datos e interfaces
6
004 15 Andrés
Martínez Pruebas Unitarias 2
005 16 Andrés
Martínez
Diseño de estructuras en base de datos para administración de inventario
5
005 17 Andrés
Martínez
Diseño de interfaz gráfica para administración de inventario
5
005 18 Andrés
Martínez
Programación del acople ente base de datos e interfaces
6
005 19 Andrés
Martínez Pruebas Unitarias 3
107
4.2. Desarrollo Sprint 1
Inicialmente en el tablero se refleja las tareas a desarrollar para este Sprint 1; en el
gráfico N. 17 se grafica el estado de los requerimientos a desarrollar en la fase inicial
del proyecto.
108
GRÁFICO N°. 17: Estado inicial del Sprint 1 en el Trello
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
Al finalizar la primera semana de desarrollo del sistema, observamos en la aplicación
Trello que las actividades correspondientes a los dos primeros requerimientos se
encuentran totalmente terminadas. El requerimiento con el identificador 003 se
encuentra aún en desarrollo y próximas a realizar, se encuentran las tareas de las
dos últimas funcionalidades del Sprint 1.
GRÁFICO N°. 18: Estado del tablero al finalizar semana 1 del Sprint 1 en el Trello
109
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
Al culminar la semana 2 del Sprint, se visualiza como todas las tareas del Sprint han
sido concluidas, por lo tanto todos los requerimientos destinados para este Sprint 1
se encuentran en la columna con estado “Realizado”; su representación en el gráfico
N. 19.
GRÁFICO N°. 19: Estado del tablero al finalizar semana 2 del Sprint 1 en el Trel
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
4.3. Entregable Sprint 1
Como resultado de este Sprint, se obtienen los requerimientos totalmente funcionales
del Sprint 1. A continuación se exponen las interfaces de los mismos:
110
GRÁFICO N°. 20: Control de usuarios del sistema
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
GRÁFICO N°. 21: Control de permisos del sistema
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
111
GRÁFICO N°. 22: Control de tipos de requerimientos
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
GRÁFICO N°. 23: Ingreso de equipos informáticos (Hardware y Software)
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
112
5. Sprint 2
5.1. Pila del Sprint 2 (Sprint backlog 2)
Para el Sprint 2 la lista de requerimientos a desarrollar en estas tres semanas
corresponden a las siguientes historias de usuario.
TABLA N°. 8: Pila del Sprint 2
Id Prioridad Título Descripción
006 Alta Bandeja de
requerimientos Administrador
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que permita registrar y gestionar las solicitudes de requerimientos, para administrar estos registros en el sistema de manera eficiente y centralizada.
007 Alta Bandeja de
requerimientos Técnico
Como Técnico, necesito una opción en el sistema que permita visualizar las solicitudes de requerimientos que se me han sido asignadas, para proceder a atenderlas de manera oportuna.
008 Alta
Bandeja de requerimientos
Usuario solicitante
Como usuario solicitante, necesito una opción en el sistema que permita generar una solicitud de requerimientos, para notificar al departamento informática alguna novedad de software o hardware.
009 Media Control de
conocimientos
Como Coordinador de Software del Departamento de Informática, necesito que se cree en el sistema una base de
113
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
Este Sprint principalmente está conformado por las funcionalidades del flujo de trabajo
para la gestión de requerimientos y la gestión de conocimientos. Seguidamente, se
muestra las tareas involucradas para el desarrollo de este Sprint.
TABLA N°. 9: Lista de tareas del Sprint 2
conocimientos, para que el conocimiento se guarde en el sistema y pueda ser accedido en cualquier momento por alguno de los integrantes del departamento, sin importar la fecha.
IdR IdT Responsable Tarea Estimación
(Horas)
006 1 Andrés
Martínez
Diseño de estructuras en base de datos para administración de requerimientos para el administrador
6
006 2 Andrés
Martínez
Diseño de interfaz gráfica para bandeja de administración de requerimientos para el administrador
5
006 4 Andrés
Martínez
Programación del acople ente base de datos e interfaces
7
006 5 Andrés
Martínez Pruebas Unitarias 5
007 6 Andrés
Martínez
Diseño de interfaz gráfica para bandeja de administración de
6
114
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
requerimientos para el técnico
007 7 Andrés
Martínez Programación de reglas para rol técnico
6
007 8 Andrés
Martínez Pruebas Unitarias 2
008 9 Andrés
Martínez
Diseño de interfaz gráfica para bandeja de administración de requerimientos para el usuario solicitante
6
008 10 Andrés
Martínez Programación de reglas para rol usuario solicitante
6
008 11 Andrés
Martínez Pruebas Unitarias 2
009 12 Andrés
Martínez
Diseño de estructuras en base de datos para administración de la base de conocimientos
5
009 13 Andrés
Martínez
Diseño de interfaz gráfica para incorporar la base de conocimientos en el sistema
5
009 14 Andrés
Martínez
Programación del acople ente base de datos e interfaces
6
009 15 Andrés
Martínez Pruebas Unitarias 2
115
5.2. Desarrollo Sprint 2
Para el Sprint 2, en el tablero se expone en la columna “Spring Backlog 2” las historias
de usuario a desarrollar en esta iteración. A continuación su representación en el
gráfico N.24.
GRÁFICO N°. 24: Estado inicial del Sprint 2 en el Trello
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
En el gráfico N. 25, se visualiza que al término de la semana 1 del Sprint, dos
requerimientos han sido cumplidos, ninguno se encuentra en curso y dos se
encuentran en estado pendiente de desarrollar.
116
GRÁFICO N°. 25: Estado del tablero al finalizar semana 1 del Sprint 2 en el Trello
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
A fines de la semana 2, todas las historias de usuario del segundo Sprint se visualizan
que han sido completadas, tal y como se expone en el gráfico N. 26.
GRÁFICO N°. 26: Estado del tablero al finalizar semana 1 del Sprint 2 en el Trello
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
117
5.3. Entregable Sprint 2
Como entregables del Sprint 2 se encuentran las funcionalidades presentadas a
continuación:
GRÁFICO N°. 27: Bandeja de requerimientos Administrador
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
GRÁFICO N°. 28: Asignación de Técnico
118
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
GRÁFICO N°. 29: Bandeja de requerimientos Técnico
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
119
GRÁFICO N°. 30: Atención de requerimiento Técnico
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
GRÁFICO N°. 31: Bandeja de requerimientos Usuario solicitante
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
120
GRÁFICO N°. 32: Estado requerimiento Usuario solicitante
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
GRÁFICO N°. 33: Consulta base de conocimientos
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
121
GRÁFICO N°. 34: Ingreso de conocimiento
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
6. Sprint 3
6.1. Pila del Sprint 3 (Sprint backlog 3)
El Sprint 3 está compuesto por las historias menos prioritarias del proyecto,
esencialmente los reportes del sistema. En la siguiente tabla se muestra la pila de
requerimientos a desarrollar en este Sprint.
TABLA N°. 10: Pila del Sprint 3
Id Prioridad Título Descripción
010 Alta Control de
herramientas
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que me permita gestionar
122
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
las herramientas que se utilizan en el departamento para resolver un requerimiento, para visualizar estos registros desde el mecanismo de la base de conocimientos.
011 Baja Generación de
reportes requerimientos
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que me permita generar reportes de los requerimientos, para llevar un mejor control y acelerar la entrega de esta información cuando la parte administrativa lo solicite.
012 Baja
Generación de reportes de hardware y
software
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que me permita generar reportes de hardware y software ingresado, para llevar un mejor control del inventario.
013 Baja Generación de
reportes de herramientas
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que me permita generar reportes de las herramientas disponibles, para llevar un mejor control de las herramientas ingresadas.
014 Baja Generación de
reportes de conocimientos
Como Coordinador de Software del Departamento de Informática, necesito una opción en el sistema que me permita generar reportes de las entradas de conocimientos ingresados, para llevar un mejor control de las entradas ingresadas.
123
La especificación de las tareas a cumplir, para generar el entregable correspondiente
al Sprint 3, se detallan en la tabla N. 11.
TABLA N°. 11: Lista de tareas del Sprint 3
IdR IdT Responsable Tarea Estimación
(Horas)
010 1 Andrés
Martínez
Diseño de estructuras en base de datos para administración de las herramientas a utilizar en el módulo de gestión de conocimiento
5
010 2 Andrés
Martínez
Diseño de interfaz gráfica para administración de las herramientas a utilizar en el módulo de gestión de conocimiento
5
010 3 Andrés
Martínez
Programación del acople ente base de datos e interfaces
6
010 4 Andrés
Martínez Pruebas Unitarias 2
011 5 Andrés
Martínez
Diseño de interfaz gráfica para la generación de reportes requerimientos
5
011 6 Andrés
Martínez Programación de la consulta en base de datos
6
011 7 Andrés
Martínez Pruebas Unitarias 2
012 8 Andrés
Martínez Diseño de interfaz gráfica para la generación de
5
124
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
reportes de hardware y software
012 9 Andrés
Martínez Programación de la consulta en base de datos
6
012 10 Andrés
Martínez Pruebas Unitarias 2
013 11 Andrés
Martínez
Diseño de interfaz gráfica para la generación de reportes de hardware y software
5
013 12 Andrés
Martínez Programación de la consulta en base de datos
6
013 13 Andrés
Martínez Pruebas Unitarias 2
014 14 Andrés
Martínez
Diseño de interfaz gráfica para la generación de reportes de herramientas
5
014 15 Andrés
Martínez Programación de la consulta en base de datos
6
014 16 Andrés
Martínez Pruebas Unitarias 2
015 17 Andrés
Martínez
Diseño de interfaz gráfica para la generación de reportes de conocimientos
5
015 18 Andrés
Martínez Programación de la consulta en base de datos
6
015 19 Andrés
Martínez Pruebas Unitarias 2
125
6.2. Desarrollo Sprint 3
Para el último Sprint del Proyecto, el estado inicial del tablero, se encuentra
conformado por las tareas establecidas en el Sprint Backlog 3, en el gráfico N. 35 se
representa las mismas.
GRÁFICO N°. 35: Estado inicial del Sprint 3 en el Trello
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
Culminando la semana 1 del Sprint 3 en el gráfico N. 36, se observa que las dos
primeras funcionalidades de este Sprint han sido terminadas. El requerimiento con Id
012 se encuentra en curso y los dos últimos requerimientos de este Sprint se
encuentran pendientes de desarrollar.
126
GRÁFICO N°. 36: Estado del tablero al finalizar semana 1 del Sprint 3 en el Trello
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
Finalmente en la segunda semana, se concluyen totalmente los últimos
requerimientos del Sprint y del proyecto. Tal y como se visualiza en el gráfico N.37,
ninguna funcionalidad se encuentra en el backlog general del producto, ni en los
backlogs de los Sprints o en estado pendiente; por lo que en esta etapa, se da por
concluido el desarrollo del proyecto.
127
GRÁFICO N°. 37: Estado del tablero al finalizar semana 2 del Sprint 3 en el Trello
Autor: Jorge Andrés Martínez Álvarez
Fuente: Jorge Andrés Martínez Álvarez
6.3. Entregable Sprint 3
En la presente sección se muestran los entregables generados como producto del
desarrollo de este último Sprint.
128
GRÁFICO N°. 38: Control de herramientas
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
GRÁFICO N°. 39: Reporte de requerimientos
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
129
Entregables del proyecto
El desarrollo de esta propuesta tecnológica generará los siguientes entregables:
Documentación completa del desarrollo del proyecto.
Código fuente del sistema.
Scripts de base de datos del sistema.
Modelo entidad relación del sistema (Anexo N. 3).
Manual de Usuario del sistema.
Manual Técnico del sistema.
Criterios de Validación de la Propuesta
De acuerdo a la metodología SCRUM, la cual hemos empleado para la ejecución del
proyecto, la validación del producto se realiza en la finalización de cada iteración, para
según los resultados obtenidos ajustar el entregable y finalmente certificar que los
requerimientos desarrollados en el Sprint se encuentran acorde con lo solicitado.
Para cumplir con este punto, los criterios utilizados para validar la propuesta fueron
las especificaciones de las historias de usuarios de cada Sprint, revisadas con el
Scrum Master, el cual ha colaborado con la validación de las funcionalidades del
sistema descritas en las HU y de las cuales han surgido ciertos cambios en la
aplicación con el propósito de mejorar la solución.
130
CAPÍTULO IV
CRITERIOS DE ACEPTACIÓN DEL PRODUCTO O SERVICIO
Con la finalidad de medir la calidad y aprobación del producto que se va a entregar,
a continuación se especifica una matriz con el porcentaje de cumplimiento de los
requerimientos establecidos en la historias de usuario de los tres sprints para la
presente propuesta tecnológica.
TABLA N°. 12: Criterios de aceptación del producto
Sprint 1 Porcentaje cumplimiento
Interfaces deben de ser amigables
100%
Control de usuarios del sistema 100%
Control de los permisos del sistema
100%
Control de tipos de requerimientos
100%
Control de inventario 100%
Sprint 2 Porcentaje cumplimiento
Bandeja de requerimientos Administrador
100%
Bandeja de requerimientos Técnico
100%
131
Bandeja de requerimientos Usuario solicitante
100%
Control de conocimientos 100%
Sprint 3 Porcentaje cumplimiento
Control de herramientas 100%
Generación de reportes requerimientos
100%
Generación de reportes de hardware y software
100%
Generación de reportes de herramientas
100%
Generación de reportes de conocimientos
100%
Autor: Jorge Andrés Martínez Álvarez Fuente: Jorge Andrés Martínez Álvarez
132
INFORME DE PRUEBAS
Dado que el presente proyecto es de carácter tecnológico, se adjunta como un anexo
el respectivo informe de revisión del software (Anexo N. 4). Dichas pruebas fueron
realizadas por los encargados de los departamentos de informática de las carreras
Sistemas Computacionales, Networking e Ingeniería Civil de la Facultad de
Matemáticas y Físicas de la U.G. los cuales son:
Ing. Jorge Enrique Alvarado Chang, Coordinador de Software de la Carrera
Ingeniería en Sistemas Computacionales
Ing. Denis Merchán Reyes, Coordinador de Software del Departamento de
Informática de la Carrera de Ingeniería Civil
RESULTADOS
Como producto de la investigación tipo descriptiva realizada, permitió obtener la
información necesaria para identificar aquellos procesos que podían ser
automatizados en los departamentos de informática de la FCMF de la UG.
Consecuentemente, se procedió al desarrollo del software siguiendo los lineamientos
de la metodología ágil scrum, en la que la participación de los interesados representó
un rol importante, para que el software resultante sea un producto de alta calidad,
debido a la gran flexibilidad y a la capacidad de adaptación continua para el desarrollo
del sistema. Esta característica, propia de esta metodología, permitió generar
entregables en las que los interesados, obtuvieron un nivel de satisfacción alto, de
acuerdo a sus expectativas al inicio del proyecto.
133
CONCLUSIONES
Las entrevistas realizadas a los jefes de los Departamentos de Hardware y
Software de las carreras pertenecientes a la Facultad de Matemáticas y
Físicas de La Universidad de Guayaquil, permitieron conocer a profundidad la
problemática e identificar los procesos que deben ser automatizados para
mejorar la gestión de requerimientos informáticos.
La metodología SCRUM permitió desarrollar el proyecto propuesto de manera
flexible. Surgieron algunas sugerencias en los entregables generados al final
de los Sprints, las cuales fueron solventadas en la brevedad del caso, gracias
a los principios de la metodología empleada.
La decisión acertada de trabajar el desarrollo del proyecto en una arquitectura
de tres capas, proporcionará un fácil mantenimiento del código en caso de
requerir incorporar alguna funcionalidad adicional en el software.
Las interfaces desarrolladas, no representan una obstaculización en el manejo
del sistema para los usuarios, ya que son sencillas e intuitivas.
La incorporación de una base de conocimientos en el software, resulta un
elemento interesante y útil, puesto que ahora se registrarán los mismos en el
sistema y estarán disponibilizados para los miembros del departamento, para
que se auto capaciten respecto a las tareas cotidianas que se les podría
asignar en un futuro.
Finalmente se concluye que según las revisiones del sistema realizadas con
los dueños del producto y el Scrum Master, la herramienta desarrollada resulta
útil para el registro y gestión eficiente de los requerimientos informáticos en el
Departamento de Hardware y Software, quienes desean que próximamente el
sistema sea implementado en el área para empezar a administrar las
solicitudes realizadas al departamento desde esta plataforma.
134
RECOMENDACIONES
Previamente a utilizar el software desarrollado se recomienda configurar los
parámetros básicos de la aplicación, desde el módulo de mantenimientos,
para que el sistema funcione correctamente.
El manual de usuario entregado como parte de la presente propuesta, incluye
una guía completa acerca del funcionamiento del sistema, se recomienda la
lectura detenida por parte de todos los miembros que conforman el flujo de
manejo del sistema de gestión de requerimientos informáticos para
aprovechar al máximo la herramienta.
Para futuros desarrollos, se recomienda seguir la arquitectura de tres capas
aplicada en el proyecto, de esta manera se garantizará la limpieza del código
y el rendimiento en el performance de la aplicación.
A través de la experiencia obtenida en el desarrollo de la propuesta, se sugiere
que para las próximas versiones o cambios de esta versión, se utilice la
metodología SCRUM, para mantener la calidad del software y lograr cumplir
las expectativas de los dueños del producto.
Culturizar a los técnicos para que el ingreso de conocimientos se registre en
el sistema cada vez que actualice como solucionado un requerimiento. Esta
disposición ayudará a que la base de conocimientos del departamento se
encuentre siempre actualizada con información adecuada para que el
personal disponga de la misma en cualquier momento y no se desaproveche
el conocimiento técnico adquirido por cada uno de los miembros.
135
ANEXOS
136
ANEXO #1: GUIÓN DE LA ENTREVISTA REALIZADA A LOS
ENCARGADOS DE LOS DEPARTAMENTOS DE HARDWARE Y
SOFTWARE DE LAS CARRERAS DE LA FACULTAD DE CIENCIAS
MATEMÁTICAS Y FÍSICAS
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
FORMATO DE ENTREVISTA
Nombre:
Cargo:
Fecha:
Formulación de preguntas
1) ¿Cuenta el departamento de hardware y software a su cargo, con algún
sistema de gestión de requerimientos informáticos?
Sí
No
2) ¿Cuántas personas conforman el área informática de la carrera?
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………
3) En caso de no contar con un sistema de gestión de requerimientos
informáticos ¿Cómo se realiza el proceso de asignación y atención de
requerimientos?
137
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………
4) ¿Cuál es el promedio de tiempo que demora en gestionar un requerimiento,
desde la solicitud hasta el cierre del mismo?
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………
5) ¿Posee el departamento, procesos con rutinas de mantenimientos
programadas?
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………
6) ¿Cuenta con algún control (inventario) para el hardware y software de los
recursos a cargo del departamento?
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………
7) ¿Cuáles son los cinco requerimientos más comunes que se presentan en el
departamento?
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………
8) ¿Considera conveniente que los requerimientos posean una clasificación de
prioridad de atención?
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………
138
9) ¿Considera usted importante que los sistemas de helpdesk deban poseer una
interfaz amigable e intuitiva para el manejo del usuario?
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………
10) Según su criterio, ¿Cree usted qué es necesario mejorar el actual proceso de
asignación y atención de requerimiento informáticos del departamento?
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………
11) De acuerdo a su opinión, ¿Cree usted qué las mejoras de los procesos de
asignación y atención de los requerimientos, deberían de verse reflejados en
un nuevo software?
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………
12) ¿Existe en el departamento un repositorio donde se almacenen, consulten y
gestionen los conocimientos adquiridos a través del tiempo, por los
trabajadores?
…………………………………………………………………………………………
…………………………………………………………………………………………
…………………………………………………………………………
139
ANEXO #2: ACTAS DE ENTREVISTAS
140
141
142
ANEXO #3: MODELO ENTIDAD RELACION DE LA BASE DE DATOS DEL
143
SISTEMAS DE GESTION DE REQUERIMIENTOS INFORMATICOS
144
ANEXO #4: INFORME DE PRUEBAS
145
146
147
148
149
150
BIBLIOGRAFÍA
7Graus. (23 de Julio de 2017). Significados. Obtenido de
https://www.significados.com/problema/
AdviseraExpertSolutions. (23 de Julio de 2017). 20000 Academy. Obtenido de https://advisera.com/20000academy/es/que-es-iso-20000/
Anders, M. (2000). The MSDN Show.
Aranda Software. (30 de Julio de 2017). Aranda Software. Obtenido de http://arandasoft.com/gestion-de-activos-e-inventario-cmdb-alineada-con-itil/
Asociación de Técnicos de Informática de Madrid. (Noviembre de 2010). Revista Española de Innovación, Calidad e Ingeniería del Software. Sistema de Gestión Integrado según las normas ISO. Madrid.
AXELOS. (2017). AXELOS Global Best Practice. Obtenido de https://www.axelos.com/best-practice-solutions/itil
Azcurra, D., Rodriguez, D., Pytel, P., Santos, D., Giordano, V., Arboleya, H., & García-Martínez, R. (2011). ARQUITECTURAS DE SISTEMAS EMBEBIDOS. Argentina.
Baygorrea Berrocal, D. B. (2016). Propuesta de un Service Desk para mejorar los procesos de resolución de incidencias a través de ITIL, empresa COGESA. Lima, Perú.
Beisse, F. (2014). A Guide to Computer User Support for Help Desk and Support Specialists. Boston: Cengage Learning.
Berzal, F., Cortijo, F., & Cubero , J. C. (2005). Desarrollo profesional de aplicaciones web con ASP.NET. ISBN 84-609-4245-7. Obtenido de ftp://listas.debiancolombia.org/ingenieria_web/web-book-a4-ASPNET.pdf
Bravo, R. (Febrero de 2016). Aula Virtual. Obtenido de Manual para soporte tecnico: https://fricardoac.files.wordpress.com/2016/02/01-curso_basico_de_soporte_tecnico.pdf
Cardador Cabello, A. L. (2015). Implantación de aplicaciones web en entornos internet, intranet y extranet. Málaga: IC Editorial.
Chandler, D., & Munday, R. (2011). A Dictionary of Media and Communication.
Oxford: Oxford University Press.
Chiluisa Pallo, A. P., & Loarte Cajamarca, B. G. (Mayo de 2014). Desarrollo e Implantacion del sistema de control de inventarios y gestion de laboratorios para La Facultad de Ciencias de La Escuela Politecnica Nacional. Quito.
151
Ciberaula. (23 de Julio de 2017). Ciberaula. Obtenido de http://www.ciberaula.com/articulo/polimorfismo
Código de Ética de la Universidad de Guayaquil. (2016).
Constitucion de la Republica del Ecuador. (2008). Ecuador.
Definicion.de. (23 de Julio de 2017). Definición.de. Obtenido de http://definicion.de/incidente/
Desongles Corrales, J. (2005). Ayudantes Tecnicos. Opcion Informatica. Junta de Andalucia. Temario Volumen Ii.e-book. España: Editorial MAD.
Durango, A. (2015). En Diseño Web con CSS (pág. 11). IT Campus Academy.
Duthie, G., & MacDonald, M. (2003). En ASP.NET in a Nutshell (pág. 11). Sebastopol: O'Reilly Media, Inc.
EcuRed. (23 de Julio de 2017). EcuRed. Obtenido de https://www.ecured.cu/
Farlex. (23 de Julio de 2017). The Free Dictionary. Obtenido de http://es.thefreedictionary.com/informaci%C3%B3n
Flórez Fernández, H. A. (2012). Programación orientada a objetos con Java. En H. A. Flórez Fernández, Programación orientada a objetos con Java (pág. 151). Bogotá D.C.: Ecoe Ediciones.
Gelmer. (5 de Junio de 2009). Analisis y desarrollo de sistemas de informacion. Obtenido de http://desasof2004.blogspot.com/2009/06/definicion-de-requerimientos.html
Guzmán, E. (20 de Noviembre de 2014). GESTIÓN DE INCIDENCIAS. Obtenido de https://eualblog.wordpress.com/2014/11/20/gestion-de-incidencias/
Heredia García, A. (Junio de 2012). ITAKA: Gestión Interactiva del Conocimiento en Organizaciones de Desarrollo de Software. Leganés.
ISO. (29 de Julio de 2017). International Organization for Standardization. Obtenido de International Organization for Standardization
Itlibrary. (24 de Julio de 2017). itlibrary. Obtenido de
http://www.itlibrary.org/index.php?page=Incident_Management
Jaramillo Castro, C. M., & Morocho Puchaicela, D. A. (Julio de 2016). Revista Tecnológica-ESPOL. Sistema Help Desk, utilizando ITIL para la provisión del Servicio en el departamento de mantenimiento y soporte técnico de la Universidad Nacional de Loja.
Kendall, K., & Kendall, J. (2011). Analisis y Diseno de Sistemas - 8 Edición. Mexico: Pearson Educación de México, S.A.
López Vera, F. F. (Mayo de 2014). Implementación de un sistema de mesa de ayuda informático (help desk) para el control de incidencias que se presentan en el gobierno autónomo descentralizado de la provincia de Esmeraldas. Ecuador.
152
Luján Mora, S. (2002). Programación de aplicaciones web: historia, principios básicos y clientes web. España: Editorial Club Universitario.
Macau, R. (2004). Revista de Universidad y Sociedad del Conocimiento. Obtenido de
TIC: ¿para qué? (Funciones de las tecnologías de la información y la comunicación en lasorganizaciones): http://www.uoc.edu/rusc/dt/esp/macau0704.pdf
Menzinsky, A., López, G., & Palacio, J. (2016). Guía de Scrum Manager.
Microsoft. (21 de 07 de 2017). Microsoft 2017. Obtenido de https://www.visualstudio.com/es/vs/
Moreno Ortiz, A. (2000). Estudios de Lingüística del Español. Obtenido de http://elies.rediris.es/elies9/4-1.htm
Moya Navarro, M. (1999). Investigación de Operaciones. En Investigación de Operaciones (pág. 19). San José: EUNED.
Nevado Cabello, M. V. (2010). En Introduccion a Las Bases de Datos Relacionales (pág. 22). Madrid: Editorial Visión Libros.
Osorio Núñez, M. (Diciembre de 2003). ACIMED. Obtenido de El capital intelectual en la gestión del conocimiento. Acimed: http://scielo.sld.cu/scielo.php?pid=S1024-94352003000600008&script=sci_arttext&tlng=en
Pérez Marqués, M. (2011). En SQL Server 2008 R2 : motor de base de datos y administración (pág. 13). Madrid: RC Libros.
Pérez Porto, J. (2008). Definicion.de. Obtenido de http://definicion.de/conocimiento/
Pirchado Veloz, J., González, S., Hernandez, A., Hidalgo, D., Almonte, J., Diaz, E., . . . Torres, O. (14 de Agosto de 2015). auditoriaensistemasblog. Obtenido de https://auditoriaensistemasblog.wordpress.com/2015/08/14/itil-y-cobit-213/
Powell, T., & Dent-Micallef, A. (1997). Information technology as competitive advantage: The role of human, business, and technology resources. Strategic management journal.
Quintana Solórzano, I. (21 de Noviembre de 2013). Prezi. Obtenido de https://prezi.com/dumspfsspman/desarrollo-de-la-gestion-de-conocimiento-basado-en-itil-v3/
RAE, A. d. (23 de Julio de 2017). Diccionario de la lengua española. Obtenido de http://dle.rae.es/?id=ZJ2KRZZ
Ramos Salavert, I., & Lozano Pérez, M. (2000). Ingeniería del software y bases de datos: tendencias actuales. En I. Ramos Salavert, & M. D. Lozano Pérez, Ingeniería del software y bases de datos: tendencias actuales (pág. 62). Cuenca: Ediciones de la Universidad de Castilla-La Mancha.
Rankins, R., Bertucci, P., Gallelli, C., & Silverstein, A. (2015). En Microsoft SQL Server 2014 Unleashed. United States: Sams Publishing.
153
Ríos Huércano, S. (18 de Julio de 2011). Biable driving innovation. Obtenido de http://www.biable.es/wp-content/uploads/2014/ManualITIL.pdf
Rouse, M., & May, J. (Marzo de 2007). Searchcrm. Obtenido de
http://searchcrm.techtarget.com/definition/knowledge-base
Sánchez, V., & Pizarro, D. (2010). Ingenius. Diagnóstico del nivel de automatización en las pequeñas y medianas industrias de la ciudad de cuenca. Cuenca.
Sconce, B., & Hewitt, A. (Febrero de 2010). TR&A: Whitepapers & Presentations.
Obtenido de https://www.tedroche.com/Present/2010/css/css.html
Sommerville, I. (2005). Ingeniería del Software. Madrid: PEARSON EDUCACIÓN, S.A.
Styde. (23 de Julio de 2017). Styde Limited. Obtenido de
https://styde.net/encapsulamiento-en-la-programacion-orientada-a-objetos/
Suárez Fragas, Y., Medina Peña, D., & Hernández Alfonso, P. M. (2015). Revista Ciencias Técnicas Agropecuarias. Sistema automatizado para la gestión del mantenimiento de equipos (módulos administración y solicitud de servicio). La
Habana, Cuba.
Techedge. (2015). Techedge España & LATAM. Obtenido de http://www.techedgegroup.es/areas-de-negocio/the-guard/soluciones/gestion-de-la-configuracion/gestion-de-activos-e-inventario/
TechNet, M. (23 de Julio de 2017). Microsoft TechNet. Obtenido de https://technet.microsoft.com/es-es/library/ms187875(v=sql.105).aspx
UNESCO. (2004). Las tecnologías de la información y la comunicación en la formación docente. Mariana Patru.
Venemedia. (23 de Julio de 2017). CONCEPTODEFINICION.DE. Obtenido de http://conceptodefinicion.de
Vilaboa B., J. (13 de Abril de 2006). Gestión de la automatización de plantas industriales en Chile. Red Revista de Facultad de Ingeniería. Obtenido de http://www.scielo.cl/pdf/rfacing/v12n1/art05.pdf
Villada Romero, J. L. (2014). Instalación y configuración del software de servidor Web. IFCT0509. Málaga: IC Editorial.
Wagner, B. (03 de Abril de 2017). docs.microsoft.com. Obtenido de
https://docs.microsoft.com/es-es/dotnet/csharp/csharp
Wikiteka. (8 de Junio de 2011). Wikiteka. Obtenido de https://www.wikiteka.com/apuntes/que-es-un-requerimiento/
154
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
DESARROLLO DE UN SISTEMA DE GESTIÓN DE
REQUERIMIENTOS INFORMÁTICOS PARA LA
FACULTAD DE CIENCIAS MATEMÁTICAS
Y FÍSICAS DE LA UNIVERSIDAD
DE GUAYAQUIL
MANUAL DE USUARIO
PROYECTO DE TITULACIÓN
Previa a la obtención del Título de:
INGENIERO EN SISTEMAS COMPUTACIONALES
155
AUTOR: Jorge Andrés Martínez Álvarez
TUTOR:
Ing. Darwin Cercado Barragán
GUAYAQUIL – ECUADOR 2017
156
ÍNDICE GENERAL
ÍNDICE GENERAL ........................................................................................................ 156
ÍNDICE DE GRÁFICOS .................................................................................................. 157
1. INTRODUCCIÓN AL USUARIO .............................................................................. 160
2. ORGANIZACIÓN DE LOS MÓDULOS ..................................................................... 160
2.1. Módulo de mantenimiento ............................................................................................ 160
2.1.1. Opción Usuarios ..................................................................................................... 161
2.1.2. Opción Tipos Requerimientos ................................................................................ 164
2.1.3. Opción Hardware y Software.................................................................................. 167
2.1.4. Opción Herramientas ............................................................................................. 170
2.1.5. Opción Permisos .................................................................................................... 173
2.1.6. Opción Parámetros del Sistema.............................................................................. 175
2.2. Módulo de Requerimientos ........................................................................................... 188
2.2.1. Opción Requerimientos – Usuario Solicitante ......................................................... 188
2.2.2. Opción Requerimientos – Usuario Solicitante Creación del Requerimiento ............ 189
2.2.3 Opción Requerimientos – Técnico .......................................................................... 191
2.2.4 Opción de Requerimiento – Técnico – Base de Conocimiento ................................ 193
2.3. Módulo de Reporte ........................................................................................................ 196
2.3.1. Reportes de Requerimientos .................................................................................. 196
2.3.2. Reportes de Hardware y Software .......................................................................... 198
157
ÍNDICE DE GRÁFICOS
GRÁFICO N°. 1: Módulo de Mantenimiento............................................................ 161
GRÁFICO N°. 2: Pantalla de la opción “Usuarios” .................................................. 162
GRÁFICO N°. 3: Pantalla del modal para modificar un usuario ............................. 163
GRÁFICO N°. 4: Pantalla de confirmación de eliminación de usuario ................... 164
GRÁFICO N°. 5: Pantalla de la opción “Tipos Requerimientos” ............................. 165
GRÁFICO N°. 6: Pantalla del modal para modificar los datos de asociación de una
subcategoría a un tipo de requerimiento .................................................................. 166
GRÁFICO N°. 7: Pantalla de confirmación de asociación de una subcategoría a un
tipo de requerimiento ................................................................................................ 167
GRÁFICO N°. 8: Pantalla de la opción “Hardware y Software” .............................. 168
GRÁFICO N°. 9: Pantalla del modal para modificar un hardware o software ........ 169
GRÁFICO N°. 10: Pantalla de confirmación de eliminación de un registro de Hardware
o Software ................................................................................................................. 170
GRÁFICO N°. 11: Pantalla de la opción “Herramientas” ........................................ 171
GRÁFICO N°. 12: Pantalla del modal para modificar una herramienta .................. 172
GRÁFICO N°. 13: Pantalla de confirmación de eliminación de un registro de una
herramienta ............................................................................................................... 173
GRÁFICO N°. 14: Pantalla de asignación de accesos a las páginas del sistema . 174
GRÁFICO N°. 15: Pantalla de la opción “Parámetros del Sistema” ....................... 175
GRÁFICO N°. 16: Pantalla de la sección “Parámetros del Sistema” ..................... 176
GRÁFICO N°. 17: Pantalla del modal para modificar un parámetro del sistema ... 177
GRÁFICO N°. 18: Pantalla de confirmación de eliminación de un registro de un
parámetro del sistema .............................................................................................. 178
GRÁFICO N°. 19: Pantalla de la sección “Equipo Hardware” ................................ 179
GRÁFICO N°. 20: Pantalla del modal para modificar un equipo hardware ............ 180
GRÁFICO N°. 21: Pantalla de confirmación de eliminación de un registro de un equipo
hardware del sistema ................................................................................................ 181
GRÁFICO N°. 22: Pantalla de la sección “Equipo Software” .................................. 182
158
GRÁFICO N°. 23: Pantalla del modal para modificar un software ......................... 183
GRÁFICO N°. 24: Pantalla de confirmación de eliminación de un registro de un equipo
software del sistema ................................................................................................. 184
GRÁFICO N°. 25: Pantalla de la sección “Aulas y Laboratorios” ........................... 185
GRÁFICO N°. 26: Pantalla del modal para modificar un registro de aula o laboratorio
................................................................................................................................... 186
GRÁFICO N°. 27: Pantalla de confirmación de eliminación de un registro de aula o
laboratorio del sistema .............................................................................................. 187
GRÁFICO N°. 28: Módulo de Requerimientos ........................................................ 188
GRÁFICO N°. 29: Módulo de Requerimientos – Pantalla de Inicio del Usuario
Solicitante .................................................................................................................. 189
GRÁFICO N°. 30: Módulo de Requerimientos – Pantalla de Creación de
Requerimientos ......................................................................................................... 190
GRÁFICO N°. 31: Módulo de Requerimientos – Pantalla de Solución de
Requerimientos ......................................................................................................... 191
GRÁFICO N°. 32: Módulo de Requerimientos – Pantalla de Requerimientos - Técnico
................................................................................................................................... 192
GRÁFICO N°. 33: Módulo de Requerimientos – Pantalla de Base de Conocimiento
................................................................................................................................... 192
GRÁFICO N°. 34: Módulo de Requerimientos – Pantalla de Base de Conocimiento -
Ingreso....................................................................................................................... 193
GRÁFICO N°. 35: Módulo de Requerimientos – Pantalla de Base de Conocimiento
................................................................................................................................... 194
GRÁFICO N°. 36: Módulo de Requerimientos – Administrador ............................. 194
GRÁFICO N°. 37: Módulo de Requerimientos – Pantalla de Asignación de Técnico
................................................................................................................................... 195
GRÁFICO N°. 38: Módulo de Requerimientos – Pantalla de Reportes de
Requerimientos ......................................................................................................... 196
GRÁFICO N°. 39: Módulo de Requerimientos – Reporte Exportado en formato PDF
................................................................................................................................... 197
159
GRÁFICO N°. 40: Módulo de Requerimientos – Pantalla de Reportes de Equipo
(Hardware) ................................................................................................................ 198
GRÁFICO N°. 41: Módulo de Requerimientos – Pantalla de Reportes de Equipo
(Software) .................................................................................................................. 199
160
1. INTRODUCCIÓN AL USUARIO
En el siguiente documento se describen las funcionalidades del sistema de gestión
de requerimientos informáticos, cuyo objetivo es ayudar a administrar de forma
adecuada y oportuna las solicitudes que los usuarios realizan diariamente a los
encargados del Departamento de Informática.
Este manual está dirigido a los usuarios de las carreras de la Facultad de Ciencias
Matemáticas y Físicas de La Universidad de Guayaquil. En el transcurso de la guía
del software, nos referiremos a tres tipos de usuarios o roles que maneja el sistema:
Usuario Administrador
Usuario Solicitante
Técnico
2. ORGANIZACIÓN DE LOS MÓDULOS
El sistema de gestión de requerimientos informáticos se encuentra conformado por
tres módulos:
Módulo de mantenimientos
Módulo de requerimientos
Módulo de reportes
2.1. Módulo de mantenimiento
En este módulo únicamente, el usuario administrador logrará ubicar todas las
configuraciones básicas, para que el sistema funcione correctamente. A continuación
en el gráfico N. 1 se visualiza las opciones de este módulo.
161
GRÁFICO N°. 40: Módulo de Mantenimiento
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
2.1.1. Opción Usuarios
Esta opción permite al usuario con rol administrador, consultar, ingresar y modificar
los usuarios del sistema de gestión de requerimientos informáticos.
Para consultar los usuarios del sistema, ingrese a la opción del módulo de
mantenimientos “Usuarios”. En esta pantalla usted podrá visualizar tabla con los
registros de los usuarios disponibles en el sistema.
162
Ingresar un usuario en el sistema:
1. Ingrese a la opción del módulo de mantenimientos “Usuarios”.
2. Digite los datos del usuario.
3. Presione el botón “Ingresar”.
GRÁFICO N°. 41: Pantalla de la opción “Usuarios”
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
Actualizar los datos de un usuario en el sistema:
1. Ingrese a la opción del módulo de mantenimientos “Usuarios”.
2. Clic en el icono modificar de la tabla de usuarios.
3. Se levantará un modal en el que podrá modificar los datos que usted desee
actualizar.
4. Finalmente, presione el botón “Modificar”.
163
GRÁFICO N°. 42: Pantalla del modal para modificar un usuario
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
Eliminar un usuario en el sistema:
1. Ingrese a la opción del módulo de mantenimientos “Usuarios”.
2. Clic en el icono eliminar de la tabla de usuarios.
3. A continuación, le aparecerá una confirmación para eliminar el usuario.
4. Finalmente, presione el botón “Sí”.
164
GRÁFICO N°. 43: Pantalla de confirmación de eliminación de usuario
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
2.1.2. Opción Tipos Requerimientos
Esta opción permite al usuario con rol administrador, consultar, ingresar y modificar
las asociaciones de las subcategorías a los tipos de requerimientos del sistema de
gestión de requerimientos informáticos.
Para consultar los tipos de requerimientos con las subcategorías asociadas, ingrese
a la opción del módulo de mantenimientos “Tipos Requerimientos”. En esta pantalla
usted podrá visualizar tabla con los registros de los tipos de requerimientos asociados
a una o varias subcategorías en el sistema.
165
Ingresar una asociación de una subcategoría a un tipo de requerimiento:
1. Ingrese a la opción del módulo de mantenimientos “Tipos Requerimientos”.
2. Seleccione el tipo de requerimiento al que desee asociarle una subcategoría.
3. Digite la subcategoría.
4. Presione el botón “Ingresar”.
GRÁFICO N°. 44: Pantalla de la opción “Tipos Requerimientos”
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
Actualizar los datos de asociación de una subcategoría a un tipo de
requerimiento:
1. Ingrese a la opción del módulo de mantenimientos “Tipos Requerimientos”,
2. Clic en el icono modificar de la tabla de los tipos de requerimientos.
3. Se levantará un modal en el que podrá modificar los datos que usted desee
actualizar.
4. Finalmente, presione el botón “Modificar”.
166
GRÁFICO N°. 45: Pantalla del modal para modificar los datos de asociación de una subcategoría a un tipo de requerimiento
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
Eliminar la asociación de una subcategoría a un tipo de requerimiento:
1. Ingrese a la opción del módulo de mantenimientos “Tipos Requerimientos”.
2. Clic en el icono eliminar de la tabla de los tipos de requerimientos.
3. A continuación, le aparecerá una confirmación para eliminar la asociación.
4. Finalmente, presione el botón “Sí”.
167
GRÁFICO N°. 46: Pantalla de confirmación de asociación de una subcategoría a un tipo de requerimiento
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
2.1.3. Opción Hardware y Software
Esta opción permite al usuario con rol administrador, consultar, ingresar y modificar
los equipos de hardware y software, de los cuales son responsabilidad de administrar
por el departamento de informática perteneciente a cada carrera.
Para consultar el inventario ingresado previamente, tanto de hardware como de
software, ingrese a la opción del módulo de mantenimientos “Hardware y Software”.
En esta pantalla usted podrá visualizar tabla con los registros del hardware y software
disponibles en el sistema. Cada vez que usted cambia el control de selección “Tipo
de equipo” le aparecerán en la tabla, los registros pertenecientes a la selección que
usted eligió, es decir registros de hardware o registros de software.
Ingresar un registro de hardware o software:
168
1. Ingrese a la opción del módulo de mantenimientos “Hardware y Software”.
2. Elija desde el control de selección “Tipo de equipo” el dato que desee ingresar
(Hardware o Software).
3. Complete los demás datos que el formulario le solicita. Los formularios de
ingreso de datos dependen de la selección que usted haya escogido desde el
control de selección “Tipo de equipo”.
4. Finalmente, presione el botón “Ingresar”.
GRÁFICO N°. 47: Pantalla de la opción “Hardware y Software”
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
Actualizar los datos de un hardware o software en el sistema:
169
1. Ingrese a la opción del módulo de mantenimientos “Hardware y Software”.
2. Clic en el icono modificar de la tabla de Hardware y Software.
3. Se levantará un modal en el que podrá modificar los datos que usted desee
actualizar.
4. Finalmente, presione el botón “Modificar”.
GRÁFICO N°. 48: Pantalla del modal para modificar un hardware o software
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
Eliminar un registro de Hardware o Software:
170
1. Ingrese a la opción del módulo de mantenimientos “Hardware y Software”.
2. Clic en el icono eliminar de la tabla de Hardware y Software.
3. A continuación, le aparecerá una confirmación para eliminar el registro.
4. Finalmente, presione el botón “Sí”.
GRÁFICO N°. 49: Pantalla de confirmación de eliminación de un registro de Hardware o Software
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
2.1.4. Opción Herramientas
Esta opción permite al usuario con rol administrador, consultar, ingresar y modificar
las herramientas que generalmente emplea un técnico de sistemas durante su trabajo.
Este mantenimiento, se lo emplea en la base de conocimientos por lo que importante
que el administrador complete esta información en el sistema, de acuerdo al negocio,
para garantizar una mejor experiencia al usuario del sistema de gestión de
requerimientos informáticos.
171
Para consultar las herramientas del sistema, ingrese a la opción del módulo de
mantenimientos “Herramientas”. En esta pantalla usted podrá visualizar tabla con los
registros de las herramientas disponibles en el sistema.
Ingresar un registro de herramienta en el sistema:
1. Ingrese a la opción del módulo de mantenimientos “Herramientas”.
2. Digite los datos de la herramienta a ingresar.
3. Presione el botón “Ingresar”.
GRÁFICO N°. 50: Pantalla de la opción “Herramientas”
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
172
Actualizar los datos de una herramienta en el sistema:
1. Ingrese a la opción del módulo de mantenimientos “Herramientas”.
2. Clic en el icono modificar de la tabla de herramientas.
3. Se levantará un modal en el que podrá modificar los datos que usted desee
actualizar.
4. Finalmente, presione el botón “Modificar”.
GRÁFICO N°. 51: Pantalla del modal para modificar una herramienta
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
Eliminar un registro de una herramienta:
1. Ingrese a la opción del módulo de mantenimientos “Herramientas”.
2. Clic en el icono eliminar de la tabla de Herramientas.
3. A continuación, le aparecerá una confirmación para eliminar el registro.
4. Finalmente, presione el botón “Sí”.
173
GRÁFICO N°. 52: Pantalla de confirmación de eliminación de un registro de una herramienta
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
2.1.5. Opción Permisos
Esta opción permite al usuario con rol administrador, otorgar los accesos a las páginas
del sistema para los roles de administrador, técnico y usuario solicitante del sistema
de gestión de requerimientos informáticos.
Para consultar los accesos a las páginas del sistema por rol, ingrese a la opción del
módulo de mantenimientos “Permisos”. En esta pantalla usted elegir desde el control
de selección “Rol”, el perfil y según su elección usted podrá visualizar las páginas a
las que tiene acceso ese rol específico.
174
Asignar o quitar el acceso a una página del sistema, a un rol específico:
1. Ingrese a la opción del módulo de mantenimientos “Permisos”.
2. Elija desde el control de selección “Rol”, el perfil al que desea asignar o quitar
un acceso.
3. Según su elección usted podrá visualizar las páginas a las que tiene acceso
ese rol específico.
4. Proceda a chequear o des chequear la página a la que desee asignar o quitar
el permiso, para el rol seleccionado.
5. Presione el botón “Ingresar”.
GRÁFICO N°. 53: Pantalla de asignación de accesos a las páginas del sistema
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
175
2.1.6. Opción Parámetros del Sistema
Esta opción permite al usuario con rol administrador, configurar la información básica
de las que se alimentan controles de selección u otros campos, en los distintos
formularios del sistema de gestión de requerimientos informáticos.
Estos parámetros básicos son:
Parámetros del sistema
Equipo Hardware
Equipo Software
Aulas y Laboratorios
GRÁFICO N°. 54: Pantalla de la opción “Parámetros del Sistema”
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
En los siguientes puntos re realizará la explicación de cada una de las secciones de
esta opción.
176
Sección Parámetros del sistema
En esta sección se encuentran parámetros básicos de la aplicación, tales como la
configuración del correo. Es necesario antes de empezar a utilizar el sistema
configurar esta sección, de lo contrario las notificaciones no se enviarán al correo de
los usuarios.
Ingresar un parámetro en el sistema:
1. Ingrese a la opción del módulo de mantenimientos “Parámetros del Sistema”.
2. Despliegue la sección, “Parámetros del Sistema”.
3. Digite los datos del parámetro.
4. Presione el botón “Ingresar”.
GRÁFICO N°. 55: Pantalla de la sección “Parámetros del Sistema”
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
177
Actualizar los datos de la sección parámetros del sistema:
1. Ingrese a la opción del módulo de mantenimientos “Parámetros del Sistema”.
2. Despliegue la sección, “Parámetros del Sistema”.
3. Clic en el icono modificar de la tabla de parámetros del sistema.
4. Se levantará un modal en el que podrá modificar los datos que usted desee
actualizar.
5. Finalmente, presione el botón “Modificar”.
GRÁFICO N°. 56: Pantalla del modal para modificar un parámetro del sistema
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
Eliminar un parámetro en el sistema:
1. Ingrese a la opción del módulo de mantenimientos “Parámetros del Sistema”.
2. Despliegue la sección, “Parámetros del Sistema”.
3. Clic en el icono eliminar de la tabla de parámetros del sistema.
4. A continuación, le aparecerá una confirmación para eliminar el parámetro.
5. Finalmente, presione el botón “Sí”.
178
GRÁFICO N°. 57: Pantalla de confirmación de eliminación de un registro de un parámetro del sistema
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
¡Nota Importante!: Dentro de esta sección se encuentran como parámetros iniciales
básicos, el usuario, la contraseña y el servidor de correo. Estos parámetros lanzan
las notificaciones a los usuarios, por lo que se cebe tener mucho cuidado con estos
datos; no se deben de eliminar, únicamente configurar o editar la información de estos
registros con el fin de garantizar la operatividad de la aplicación.
179
Sección Equipo Hardware
En esta sección se encuentran las configuraciones para ingresar la información del
hardware en el sistema. Es necesario antes de empezar a utilizar el sistema configurar
esta sección.
Ingresar un equipo hardware en el sistema:
1. Ingrese a la opción del módulo de mantenimientos “Parámetros del Sistema”.
2. Despliegue la sección, “Equipo Hardware”.
3. Digite los datos del hardware.
4. Presione el botón “Ingresar”.
GRÁFICO N°. 58: Pantalla de la sección “Equipo Hardware”
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
180
Actualizar los datos de la sección equipo hardware:
1. Ingrese a la opción del módulo de mantenimientos “Parámetros del Sistema”.
2. Despliegue la sección, “Equipo Hardware”.
3. Clic en el icono modificar de la tabla de equipo hardware.
4. Se levantará un modal en el que podrá modificar los datos que usted desee
actualizar.
5. Finalmente, presione el botón “Modificar”.
GRÁFICO N°. 59: Pantalla del modal para modificar un equipo hardware
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
181
Eliminar un registro de equipo hardware:
1. Ingrese a la opción del módulo de mantenimientos “Parámetros del Sistema”.
2. Despliegue la sección, “Equipo Hardware”.
3. Clic en el icono eliminar de la tabla equipo hardware.
4. A continuación, le aparecerá una confirmación para eliminar el hardware.
5. Finalmente, presione el botón “Sí”.
GRÁFICO N°. 60: Pantalla de confirmación de eliminación de un registro de un equipo hardware del sistema
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
182
Sección Equipo Software
En esta sección se encuentran las configuraciones para ingresar la información del
software en el sistema. Es necesario antes de empezar a utilizar el sistema configurar
esta sección.
Ingresar un equipo software en el sistema:
1. Ingrese a la opción del módulo de mantenimientos “Parámetros del Sistema”.
2. Despliegue la sección, “Equipo Software”.
3. Digite los datos del software.
4. Presione el botón “Ingresar”.
GRÁFICO N°. 61: Pantalla de la sección “Equipo Software”
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
183
Actualizar los datos de la sección equipo software:
1. Ingrese a la opción del módulo de mantenimientos “Parámetros del Sistema”.
2. Despliegue la sección, “Equipo Software”.
3. Clic en el icono modificar de la tabla de equipo software.
4. Se levantará un modal en el que podrá modificar los datos que usted desee
actualizar.
5. Finalmente, presione el botón “Modificar”.
GRÁFICO N°. 62: Pantalla del modal para modificar un software
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
184
Eliminar un registro de equipo software:
1. Ingrese a la opción del módulo de mantenimientos “Parámetros del Sistema”.
2. Despliegue la sección, “Equipo Software”.
3. Clic en el icono eliminar de la tabla equipo software.
4. A continuación, le aparecerá una confirmación para eliminar el software.
5. Finalmente, presione el botón “Sí”.
GRÁFICO N°. 63: Pantalla de confirmación de eliminación de un registro de un equipo software del sistema
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
185
Sección Aulas y Laboratorios
En esta sección se encuentran las configuraciones para ingresar la información de las
instalaciones donde se ubican el hardware y software, que se debe de administrar por
el departamento de informática. Es necesario antes de empezar a utilizar el sistema
configurar esta sección.
Ingresar un equipo software en el sistema:
1. Ingrese a la opción del módulo de mantenimientos “Parámetros del Sistema”.
2. Despliegue la sección, “Aulas y Laboratorios”.
3. Digite los datos de la ubicación.
4. Presione el botón “Ingresar”.
GRÁFICO N°. 64: Pantalla de la sección “Aulas y Laboratorios”
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
186
Actualizar los datos de la sección aulas y laboratorios:
1. Ingrese a la opción del módulo de mantenimientos “Parámetros del Sistema”.
2. Despliegue la sección, “Aulas y Laboratorios”.
3. Clic en el icono modificar de la tabla de aulas y laboratorios.
4. Se levantará un modal en el que podrá modificar los datos que usted desee
actualizar.
5. Finalmente, presione el botón “Modificar”.
GRÁFICO N°. 65: Pantalla del modal para modificar un registro de aula o laboratorio
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
187
Eliminar un registro de un aula o laboratorio:
1. Ingrese a la opción del módulo de mantenimientos “Parámetros del Sistema”.
2. Despliegue la sección, “Aulas y Laboratorios”.
3. Clic en el icono eliminar de la tabla aulas y laboratorios.
4. A continuación, le aparecerá una confirmación para eliminar el registro de aula
o laboratorio.
5. Finalmente, presione el botón “Sí”.
GRÁFICO N°. 66: Pantalla de confirmación de eliminación de un registro de aula o laboratorio del sistema
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
188
2.2. Módulo de Requerimientos
Con este módulo inicia el flujo de solicitudes de requerimientos en el sistema de
gestión de requerimientos informáticos. Los roles que tienen acceso a este módulo
son el Usuario Administrador, el Usuario Solicitante y el Técnico.
GRÁFICO N°. 67: Módulo de Requerimientos
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
2.2.1. Opción Requerimientos – Usuario Solicitante
Esta opción le permite al usuario solicitante crear, verificar su estado y finalizar el
requerimiento.
189
GRÁFICO N°. 68: Módulo de Requerimientos – Pantalla de Inicio del Usuario Solicitante
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
2.2.2. Opción Requerimientos – Usuario Solicitante Creación
del Requerimiento
En esta sección el usuario solicitante podrá crear el requerimiento.
Ingresar un requerimiento:
1. Ingrese a la opción del módulo “Requerimientos”.
2. Dar clic en el botón.
3. Seleccione el tipo y sub-tipo de requerimiento.
4. Describa el requerimiento en el cuadro de texto.
5. Luego dar clic en el botón ingresar.
190
GRÁFICO N°. 69: Módulo de Requerimientos – Pantalla de Creación de Requerimientos
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
Marcar como solucionado o no solucionado un requerimiento:
1. Ingrese a la opción del módulo “Requerimientos”.
2. Dar clic en la opción Solucionados.
3. Dar clic en el icono en el requerimiento seleccionado.
4. En la ventana emergente seleccionar si el requerimiento fue solucionado o no
detallando el porqué.
5. Luego dar clic en el botón ingresar.
191
GRÁFICO N°. 70: Módulo de Requerimientos – Pantalla de Solución de Requerimientos
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
2.2.3 Opción Requerimientos – Técnico
En esta sección el técnico podrá visualizar los requerimientos asignados. Para esto
esté modulo está divido en 3 secciones “nuevos”, “solucionados” y “no solucionados”.
Requerimientos Asignados
Aquí podemos ver que requerimientos fueron asignados al técnico, dando clic en la
imagen la cual desplegará una ventana en la cual se podrá atender el
requerimiento.
192
GRÁFICO N°. 71: Módulo de Requerimientos – Pantalla de Requerimientos - Técnico
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
En el grafico N° 33 se puede apreciar la ventana donde se podrá atender el
requerimiento, también se podrá acceder a la base de conocimientos del sistema de
requerimiento.
GRÁFICO N°. 72: Módulo de Requerimientos – Pantalla de Base de Conocimiento
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
193
2.2.4 Opción de Requerimiento – Técnico – Base de
Conocimiento
Esta opción permitirá almacenar todos los eventos para la solución de algún
requerimiento que pueda presentarse a futuro
Ingreso de información en la base de conocimiento
1. Acceder la página de búsqueda de base de conocimiento
2. Luego dar clic en el botón
3. Luego llenar los campos requeridos y después dar clic en ingresar.
GRÁFICO N°. 73: Módulo de Requerimientos – Pantalla de Base de Conocimiento - Ingreso
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
194
Selección de Soluciones de la Base de Conocimientos
Una vez que se localizó la solución adecuada al requerimiento, se lo selecciona dando
clic en el botón circular, para luego dar clic en el botón regresar requerimiento.
GRÁFICO N°. 74: Módulo de Requerimientos – Pantalla de Base de Conocimiento
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
2.2.5 Opción de Requerimiento – Administrador
Esta opción permite al administrador asignar técnicos a los requerimientos solicitados
por el usuario y revisar el estado de los mismos.
GRÁFICO N°. 75: Módulo de Requerimientos – Administrador
195
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
Asignación de Técnico
1. Seleccionar el requerimiento
2. Dar clic en el botón
3. Luego asignar el técnico y guardar
GRÁFICO N°. 76: Módulo de Requerimientos – Pantalla de Asignación de Técnico
196
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
2.3. Módulo de Reportes
Este módulo detallara la información almacenada del sistema, esta se puede
visualizar en pantalla y exportarlo a pdf.
2.3.1. Reportes de Requerimientos
Es reporte muestra todos los requerimientos almacenados por el sistema, los cuales
se los puede buscar ya sea por fecha de creación del requerimiento, tipo, sub-tipo,
estado, usuario que solicito el mismo o técnico que atendió el requerimiento.
GRÁFICO N°. 77: Módulo de Requerimientos – Pantalla de Reportes de Requerimientos
197
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
GRÁFICO N°. 78: Módulo de Requerimientos – Reporte Exportado en formato PDF
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
198
2.3.2. Reportes de Hardware y Software
Este reporte mostrará el estado de los equipos informáticos y el software utilizado.
Estos equipos pueden visualizarse por fecha de creación y estado, para hardware se
los puede ver también por tipo de equipo y ubicación.
GRÁFICO N°. 79: Módulo de Requerimientos – Pantalla de Reportes de Equipo (Hardware)
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
199
Por otro lado, para el reporte de software se los puede encontrar por tipo de software
y licencia, tal y como se muestra en el gráfico N. 41.
GRÁFICO N°. 80: Módulo de Requerimientos – Pantalla de Reportes de Equipo (Software)
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
200
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
DESARROLLO DE UN SISTEMA DE GESTIÓN DE
REQUERIMIENTOS INFORMÁTICOS PARA LA
FACULTAD DE CIENCIAS MATEMÁTICAS
Y FÍSICAS DE LA UNIVERSIDAD
DE GUAYAQUIL
MANUAL TÉCNICO
PROYECTO DE TITULACIÓN
Previa a la obtención del Título de:
INGENIERO EN SISTEMAS COMPUTACIONALES
AUTOR:
Jorge Andrés Martínez Álvarez
TUTOR: Ing. Darwin Cercado Barragán
201
GUAYAQUIL – ECUADOR
2017
1
ÍNDICE GENERAL
ÍNDICE GENERAL ....................................................................................................... 1
ÍNDICE DE GRAFICOS ................................................................................................. 2
1. PRESENTACION .................................................................................................. 3
2. ASPECTO TÉCNICO DE DESARROLLO DEL SISTEMA ............................................ 3
2.1. Capa de presentación................................................................................................... 3
2.1.1. Descripción de páginas ......................................................................................... 4
2.1.2. Archivos de configuración .................................................................................... 5
2.2. Base de datos ............................................................................................................... 6
2.2.1. Detalle de las tablas del sistema ........................................................................... 7
2.3. Instalación del sistema ............................................................................................... 16
2.3.1. Instalación del aplicativo web ............................................................................ 16
3. REQUERIMIENTOS DEL SISTEMA ...................................................................... 18
3.1.1. Requerimientos de hardware mínimos para la instalación de Visual Studio
2015 19
3.1.2. Requerimientos de hardware mínimos para la instalación de SQL Server 2014 .. 19
2
ÍNDICE DE GRAFICOS
GRÁFICO N°. 1: Diagrama entidad-relación del sistema ......................................6
GRÁFICO N°. 2: Ruta del aplicativo web .............................................................16
GRÁFICO N°. 3: Creación del aplicativo en el IIS ...............................................17
GRÁFICO N°. 4: Configuración de versión del framework ..................................18
3
3. PRESENTACION
Este manual técnico ha sido desarrollado en el marco del proyecto DESARROLLO
DE UN SISTEMA DE GESTIÓN DE REQUERIMIENTOS INFORMÁTICOS PARA
LA
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS DE LA UNIVERSIDAD DE
GUAYAQUIL con el propósito de proveer la información necesaria para dar
mantenimiento, revisar e instalar el sistema de requerimientos informáticos para
la facultad de Ciencias Matemáticas y Físicas de la Universidad de Guayaquil, el
cual fue conceptualizado para una actividad académica.
El manual técnico hace referencia a información necesaria con el fin de orientar al
personal encargado en la concepción, planeamiento, análisis, programación e
instalación del sistema. Cabe recalcar que este manual técnico está dirigido a
personal con conocimientos en sistemas informáticos, tecnología de la
información, conocimientos de programación avanzada, sobre entornos web y
bases de datos.
El sistema de requerimientos funciona bajo la modalidad de 3 capas: la capa de
presentación, la capa de negocio y la capa lógica; el cual se muestra una
descripción técnica de cada una de las capas, además de describir las funciones
que cumplen dentro del sistema.
4. ASPECTO TÉCNICO DE DESARROLLO DEL SISTEMA
4.1. Capa de presentación
Esta capa proporcionara la interfaz necesaria para la presentación de datos. Por
medio de ella se hacen uso de los servicios de negocios necesarios para ofrecer
las capacidades de transacciones requeridas e integrar al usuario con la
aplicación.
4
4.1.1. Descripción de páginas
login.aspx: Página de inicio de la aplicación, también es utilizada para la
autenticación de usuarios para acceder al sistema.
index.aspx: Página de presentación del sistema, contiene el menú del
sistema.
manusuarios.aspx: Página que permite el ingreso, modificación y
eliminación lógica de los usuarios del sistema.
mantiporeq.aspx: Página que permite el ingreso, modificación y
eliminación de los tipos de requerimientos del sistema.
maninvetaerio.aspx: Página que permite el ingreso, modificación y
eliminación de los equipos informáticos y software que utilizaran la
facultad.
manteherrramienta.aspx: Página que permite el ingreso, modificación y
eliminación de las herramientas utilizadas por los técnicos.
manteroles.aspx: Página que permite el acceso o no a las distintas
páginas del sistema, estos permisos se lo da al rol del sistema.
manparametros.aspx: Página que permite el ingreso de los parámetros
que utilizara el sistema para su funcionamiento óptimo.
requeadmin.aspx: Página donde se encuentran los requerimientos, el
administrador puede visualizar los nuevos y asignarlos a los técnicos de
turno.
5
pooltecnico.aspx: Página donde se visualiza los requerimientos
asignados a los técnicos.
baseconocimiento.aspx: Página donde se ingresa las soluciones o
experiencias de los técnicos para futuros usos.
pooluser.aspx: Página donde se muestran los requerimientos que el
usuario crea, monitorea y da de alta.
reprequeriadmin.aspx: Página donde se mostrar un reporte con los
estados de los requerimientos y puede ser exportado a formato pdf.
repinventaadmin.aspx: Página donde se mostrar un reporte con los
equipos informáticos y programas de computadoras que son utilizados por
la facultad y puede ser exportado a formato pdf.
4.1.2. Archivos de configuración
El sistema de requerimientos informáticos se apoya con un archivo de
configuración llamado “web.config”. Para su comprensión se detallaran los
parámetros en el archivo de configuración:
<customErrors mode="Off" defaultRedirect="/Error.aspx"/>, Esta
línea permite controlar los errores con una pantalla de aviso especificando
el tipo de error.
<connectionStrings>, Aquí se especificará la conexión a la base de datos
del sistema.
6
4.2. Base de datos
GRÁFICO N°. 81: Diagrama entidad-relación del sistema
7
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
4.2.1. Detalle de las tablas del sistema
Nombre de la tabla: tbl_Usuario
Descripción: Contiene los usuarios que usaran el sistema
Nombre del Campo Tipo de
Dato Integridad Longitud Descripción
id int PK Identificador de usuario
cedula varchar 15 Cedula del usuario y nombre del usuario para ingresar al sistema
nombre varchar 150 Nombre del usuario
tipo_usuario int FK Identificador de la tabla tipo de usuarios
8
fecha_creacion datetime Fecha de creación del registro
estado varchar 1 Estado del usuario A = activo I = Inactivo
clave varchar 200 Clave que se utilizara para el ingreso al sistema
mail varchar 150 Correo electrónico del usuario
imagen varchar 100 Ruta donde se guardara la foto del usuario
9
Nombre de la tabla: tbl_Tipo_Usuario
Descripción: Contiene los tipos de usuarios del sistema
Nombre del Campo Tipo de
Dato Integridad Longitud Descripción
id int PK Identificador de los tipos de usuarios
descripcion varchar 350 Descripción de los tipos de usuarios
fecha_creacion datetime Fecha de creación del registro
estado varchar 2 Estado del usuario A = activo I = Inactivo
Nombre de la tabla: tbl_Equipo_Hardware
Descripción: Contiene el hardware utilizado en la facultad
Nombre del Campo Tipo de
Dato Integridad Longitud Descripción
id int PK Identificador de equipo de hardware
nombre varchar 100 Nombre del equipo
nroSerie varchar 150 Número de serie del equipo informático
marca varchar 150 Marca del equipo informático
modelo varchar 150 Modelo del equipo informático
caracteristicas varchar 350 Característica del equipo informático
fkTipoEquiHardware int FK Id de la tabla tipo de hardware
fkEstado int FK Id de la tabla estado
fkAula int FK Id de la tabla Ubicación
fecha_creacion datetime Fecha de creación del registro
estado varchar 2 Estado del usuario A = activo I = Inactivo
Nombre de la tabla: tbl_Equipo_Hardware_Tipo
Descripción: Contiene los estados de los equipos informáticos
10
Nombre del Campo
Tipo de Dato
Integridad Longitud Descripción
id int PK Identificador de tipo de hardware
descripcion varchar 100 Descripción del estado del equipo informático
fecha_creacion datetime Fecha de creación del registro
estado varchar 2 Estado del usuario A = activo I = Inactivo
Nombre de la tabla: tbl_Equipo_Software
Descripción: Contiene los software que se utilizaran en la facultad
Nombre del Campo Tipo de
Dato Integridad Longitud Descripción
id int PK Identificador de equipo de software
nombre varchar 100 Nombre del software
compania varchar 100 Nombre de la compañía que creo el software
carateristicas varchar 350 Descripción del software y características principales
fkTipoEquiSoftware int FK Clave externa proveniente de la tabla tipo software
fkLicencias int FK Clave externa proveniente de la tabla licencias
fkEstado int FK Clave externa proveniente de la tabla Estados de Software
fecha_creacion datetime Fecha de creación del registro
estado varchar 2 Estado del usuario A = activo I = Inactivo
Nombre de la tabla: tbl_Equipo_Software_Tipo
Descripción: Contiene los tipo de software
11
Nombre del Campo Tipo de
Dato Integridad Longitud Descripción
id int PK Identificador de Equipo de Software
descripcion varchar 50 Nombre del Tipo de software
fecha_creacion datetime Fecha de creación del registro
estado varchar 2 Estado del usuario A = activo I = Inactivo
Nombre de la tabla: tbl_Equipo_Software_Tipo_Licencias
Descripción:
Contiene los tipo de licencias que se utilizaran en el software
Nombre del Campo Tipo de
Dato Integridad Longitud Descripción
id int PK Identificador de las licencias de software
descripcion varchar 50 Nombre de las licencias
fecha_creacion datetime Fecha de creación del registro
estado varchar 2 Estado del usuario A = activo I = Inactivo
12
Nombre de la tabla: tbl_Estado_Equipo
Descripción: Contiene los estados de los equipos
Nombre del Campo Tipo de
Dato Integridad Longitud Descripción
id int PK Identificador de los estados
descripcion varchar 50 Nombre de los estados
fecha_creacion datetime Fecha de creación del registro
estado varchar 2 Estado del usuario A = activo I = Inactivo
Nombre de la tabla: tbl_Herramientas
Descripción:
Contiene las herramientas que serán utilizadas por los técnicos
Nombre del Campo Tipo de
Dato Integridad Longitud Descripción
id int PK Identificador de los estados
herramienta varchar 50 Nombre de la herramienta
descripcion varchar 350 Descripción de la herramienta
fecha_creacion datetime Fecha de creación del registro
estado varchar 2 Estado del usuario A = activo I = Inactivo
Nombre de la tabla: tbl_Tipo_Requerimientos
Descripción:
Contiene los tipo de requerimientos que van a ser usados por el sistema
Nombre del Campo Tipo de
Dato Integridad Longitud Descripción
id int PK Identificador de los tipos de requerimientos
descripcion varchar 350 Descripción del tipo de requerimientos
fecha_creacion datetime Fecha de creación del registro
estado varchar 2 Estado del usuario A = activo I = Inactivo
13
Nombre de la tabla: tbl_Subtipo_Requerimientos
Descripción: Contiene la sub-clasificación de los tipos de requerimientos
Nombre del Campo Tipo de
Dato Integridad Longitud Descripción
id int PK Identificador de la sub-clasificación de los tipos de requerimientos
descripcion varchar 350 Descripción de la sub-clasificación de los tipo de requerimientos
fkTipoReq int FK Identificador de la tabla tipos de requerimientos
fecha_creacion datetime Fecha de creación del registro
estado varchar 2 Estado del usuario A = activo I = Inactivo
Nombre de la tabla: tbl_Ubicaciones
Descripción: Contiene las ubicaciones físicas de los equipos informáticos
Nombre del Campo Tipo de
Dato Integridad Longitud Descripción
id int PK Identificador de las ubicaciones de los equipos informáticos
descripcion varchar 350 Descripción de las ubicaciones
fecha_creacion datetime Fecha de creación del registro
estado varchar 2 Estado del usuario A = activo I = Inactivo
Nombre de la tabla: tbl_parametros
Descripción:
Contiene las parámetros para el funcionamiento del sistema
14
Nombre del Campo Tipo de
Dato Integridad Longitud Descripción
id int PK Identificador de los parámetros
parametro varchar 150 Se describe los parámetros
descripcion varchar 150 Descripción del parámetro
fecha_creacion datetime Fecha de creación del registro
estado varchar 2 Estado del usuario A = activo I = Inactivo
Nombre de la tabla: tbl_requerimiento
Descripción: Contiene las requerimientos generados por el sistema
Nombre del Campo Tipo de
Dato Integridad Longitud Descripción
id int PK Identificador de los requerimientos
comentario varchar 500 Se describe el requerimiento creado por el usuario
fecha_creacion datetime Fecha de creación del registro
fkTipoReq int FK Identificador de la tabla tipo de requerimiento
fkSubTpReq int FK Identificador de la tabla sub-tipo de requerimiento
fkEstado int FK Identificador de la tabla estados de requerimientos
fkTecnico int FK Identificador de la tabla técnicos
fecha_asignacion datetime fecha de asignación de técnico al requerimiento
comentarioTec varchar 500 Se describe la solución aplicada por el técnico
fecha_solucinado datetime fecha de solución del requerimiento
comentarioTermi varchar 500 Se describe el requerimiento terminado
fecha_terminado datetime fecha de finalización del requerimiento
fkUsuarioCrea int FK Identificador de la tabla usuario
fkPrioridad int FK Identificador de la tabla prioridad
dias_solucion int
Días de posible solución del requerimiento
fecha_posi_solu datetime fecha de entrega de la solución
15
Nombre de la tabla: tbl_base_conocimiento
Descripción:
Contiene las soluciones implementadas por los técnicos para poder ser utilizadas
Nombre del Campo
Tipo de Dato
Integridad Longitud Descripción
id int PK Identificador de la base de conocimiento
solucion varchar 1500 Solución detallada ingresada por el técnico
fkRequermiento int FK Identificador de la tabla requerimientos
fkTipoReq int FK Identificador de la tabla tipo de requerimiento
fkHerramienta int FK Identificador de la tabla herramientas
fktecnico int FK Identificador de la tabla técnico
fecha_ingreso datetime fecha de creación del registro de la base conocimiento
Adicionalmente, La base de datos cuenta con un procedimiento almacenado
llamado “SP_CORE_HELPDESK” el cual contiene los procesos que el sistema
utiliza para el mantenimiento del sistema.
16
4.3. Instalación del sistema
4.3.1. Instalación del aplicativo web
Copiar los ficheros del sistema en la ruta c:\inetpub\wwwroot
GRÁFICO N°. 82: Ruta del aplicativo web
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
17
Luego crear en el Internet Information Service el aplicativo apuntando a la carpeta
donde se encuentra alojado el sistema.
GRÁFICO N°. 83: Creación del aplicativo en el IIS
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
Luego de crear el aplicativo web en el IIS se debe establecer el tipo de net
framework con el que trabaja la aplicación. Se recomienda que se configure con
la versión 4, esto se lo debe hacer en el pool de grupo de aplicaciones.
18
GRÁFICO N°. 84: Configuración de versión del framework
Autor: Jorge Martínez Álvarez
Fuente: Jorge Martínez Álvarez
5. REQUERIMIENTOS DEL SISTEMA
A continuación se detallan los requerimientos necesarios para la puesta en
marcha del sistema de gestión de requerimientos informáticos.
19
5.1.1. Requerimientos de hardware mínimos para la
instalación de Visual Studio 2015
Procesador Computadora personal (PC) con procesador core I3 de 1,28
Mghz
Sistema Operativo
Microsoft Windows 8 o Windows Server 2008
Memoria 8 Gigabytes
Disco Duro 320 Gigabytes
Unidades CD-ROM o DVD-ROM
5.1.2. Requerimientos de hardware mínimos para la
instalación de SQL Server 2014
Procesador Computadora personal (PC) con procesador core I3 de 1,28
Mghz
Sistema Operativo
Microsoft Windows 8 o Windows Server 2008
Memoria 8 Gigabytes
Disco Duro 320 Gigabytes
Unidades CD-ROM o DVD-ROM
