Servicios Informáticos Homero

La empresa de servicios informáticos “Homero”, líder en Proyectos TI, lleva cerca de 50 años en el mercado, ubicada
en la V región sector de Villa Alemana. Tiene a cargo el desarrollo, mantención, infraestructura y seguridad de
varias organizaciones. Los usuarios de sus sistemas son cerca de 15.000 y, en algunos sistemas, cerca de 500
transacciones por minuto. Toda esa carga de usuarios, sistemas y bases de datos la tienen distribuida en diferentes
servidores en un sitio certificado lo que con lleva una gran carga en la administración de este.

Problema

En la actualidad no existe una herramienta que registre la información completa de todos los sistemas que se
administran en “Homero”, con sus Bases de Datos correspondientes, los servidores donde se alojan con sus IP
asignadas, los servicios que deben estar operativos para su funcionamiento, las personas que los administran, las
claves de seguridad para acceder a ellos, etc.

Para obtener información de un servidor determinado, base de datos o Sistema en el caso de una contingencia, se
debe recurrir al conocimiento de los funcionarios que los administran y, además, se ha detectado que en algunos
casos se desconoce quién o quiénes lo administran, generando una pérdida de tiempo importante para reaccionar
en caso de emergencia.

Solución

Disponer de una herramienta Web para la gestión de todas las aplicaciones de “Homero”: Sistemas, Bases de Datos,
Servidores, Servicios, Funcionarios Encargados, Ubicación Física, Dirección IP, Documentación, etc.

Mantener una BD. actualizada con toda la información de las aplicaciones administradas con el fin de obtener
respuestas rápidas y oportunas sobre cualquier dato que se quiera obtener, como por ejemplo:

a) Dónde se encuentra físicamente el Servidor X y cuál es su IP

b) Quién administra el Sistema X
c) Qué Software de base de datos ocupa el Sistema X y en qué Servidor se encuentra
d) Qué servicios necesita el Sistema X para funcionar
e) El Sistema operativo de un servidor X.

Además, el proyecto debe contemplar generar un registro, en caso de contingencia de cualquier aplicación,
documentando cuál fue el problema y cómo se solucionó. Generando con esto una bitácora que permita a la
Empresa reaccionar de forma rápida, oportuna y eficiente en problemas conocidos.
Funcionalidades del Producto

Como propuesta de solución se debe desarrollar un sistema, amigable y usable de acuerdo a los estándares de
usabilidad impuestos actualmente por la industria.

La solución debe ser realizada para ser utilizada desde un navegador web, o cualquier dispositivo móvil que tenga
acceso a la intranet de la empresa.

La vista de usuario del producto debe ser intuitiva y con distribuciones de menú con colores, tamaño y distribución
muy parecido al Sistema operativo Windows 10.

Hay que considerar que la aplicación va a ser utilizada por usuarios relacionados con las tecnologías de información,
por lo mismo la empresa necesita que la aplicación no requiera una capacitación en su uso y que las etiquetas de
campos y botones sean con nombres técnicos propios del área.

Lógica del Negocio

De acuerdo a lo expresado por el Gerente de TI Sr Juan Planos, lo primero y elemental es almacenar la información
que se requiere de los servidores, como cuál sala de servidores, rack o ubicación física, qué sistema operativo tiene
instalado, capacidad de disco y memoria, si tiene o no tiene garantía y si es así, los contactos de mantención,
dirección IP, nombre del servidor, debe estar identificado si es servidor de aplicaciones o base de datos, contraseña
de administración, si es servidor de base de datos, indicar el usuario y password de administración de la base de
datos. Esas contraseñas deben estar encriptadas y solamente pueden ser vistas a través de la aplicación por quien
tenga los permisos.
Con la información base de los servidores, se debe comenzar a ingresar los sistemas y servicios que pertenecen a
cada uno de esos servidores, de los sistemas se requiere el nombre del sistema, lenguaje en que fue desarrollado,
proveedor del sistema y encargado del sistema, con sus respectivos datos de contacto. Con respecto a los servicios
o procesos batch que están siendo ejecutados en los equipos servidores, se requiere saber el nombre y los sistemas
que utilizan dichos servicios. Para cada Sistema o servicio se requiere tener acceso a la documentación del sistema,
por lo tanto, se debe considerar implementar un servidor documental u otra estrategia en la cual se pueda acceder
de manera rápida y segura a todos los artefactos asociados al sistema.
El registro de los incidentes es otra parte que el Gerente de TI necesita tener controlado, de estos incidentes se
requiere la fecha, hora, el sistema o servidor afectado, el detalle del problema, el detalle de la solución, quienes
participaron en la solución y el tiempo que se estuvo fuera de servicio. Es importante que los problemas y
soluciones estén parametrizados, de manera de poder generar futuros reportes o estadísticas de funcionamiento.
Como requerimiento a nivel Sistema, el Gerente de TI necesita que se implementen medidas de seguridad
adicionales tanto en la autenticación, transferencia de información, acceso a los datos y perimetrales, ya que la
información que va a manejar el sistema es sensible para la organización. Por lo tanto, también se requieren
generar auditorías de acceso, ingreso o modificación de la información.
Finalmente, y que fue solicitado por el Sr Planos, es que todos los datos deben estar parametrizados, de manera
de poder generar estadísticas o reportes eficientes y estandarizar los datos que va a mantener el sistema.
Requerimientos Funcionales Principales

RF.1 El sistema debe permitir autenticar y validar el ingreso de sus usuarios.

RF. 2 El sistema debe permitir administrar los Usuarios en el Sistema y asignar perfiles, crear usuarios y cargar datos
personales. Permitir la alta y baja o modificación de datos.

RF. 3 El sistema debe tener un módulo que permita incorporar y modificar los datos de las salas de Servidores.

RF. 4 El sistema debe permitir ingresar los Rack con que se cuenta y asociarlos a una sala de servidores determinada.

RF. 5 Se debe tener un módulo que permita ingresar los servidores y asociarlos a algún Rack y el proveedor para su
mantención.

RF.6 El sistema debe permitir ingresar los niveles de seguridad que tiene asociado un Sistema, los niveles de
seguridad serán; alto en el cual solo puede ver los datos el administrador y encargado de dicho sistema, medio para
los sistemas que pueden ser vistos por los encargados de los sistemas relacionados y nivel bajo para aquellos
sistemas cuya información puede ser vista por todos los usuarios.

RF. 7 El sistema debe permitir ingresar niveles de sensibilidad a los sistemas, los cuales determinan el impacto que
tienen en la organización en caso de caída. Estos niveles aún no estaban definidos en la etapa inicial, pero el sistema
debe considerar estos niveles que van a ser ingresados al sistema.

RF. 8 El sistema debe tener un módulo que permita ingresar los diferentes lenguajes de programación que se han
utilizado para el desarrollo de Sistemas.

RF. 9 El sistema debe permitir ingresar los diferentes servicios que son claves para el funcionamiento de algunos
sistemas.

RF. 10 El sistema debe permitir el ingreso de todos los Software de base de datos que son utilizados asociándolos
al sistema que lo utiliza.

RF. 11 El sistema debe permitir configurar las alertas en caso de caída de un sistema, de manera que si el
responsable del sistema ingresa un incidente, se alerte a todos los involucrados con ese sistema mediante el envío
de un correo electrónico.

RF.12 Módulo que permita el ingreso de los Sistemas con los cuales cuenta la organización y asociarlos el servidor
de base de datos correspondiente, ingresar los datos necesarios del sistema, asociarle los Web Services que ocupa,
Servidores con los que se relaciona (indicando cuál de ellos es primario, secundario o de contingencia), la
organización que utiliza el Sistema, unidad interna responsable, equipo de trabajo interno y externo involucrado
en el sistema, Lenguaje de programación, grado de sensibilidad e incorporar la documentación del Proyecto.

RF.13 Módulo que permita el registro de los Incidentes, indicando todos los datos necesarios asociados al incidente,
servidor o sistema, problema, solución, tiempo de inactividad del sistema, equipo de trabajo asociado en la
solución.
Roles Identificados

a) Administrador: Encargado de mantener los usuarios, roles, sala de servidores, servidores, sistemas. Puede ver
las contraseñas de todos los servidores y base de datos.
b) Responsable: Encargado de mantener la información de los sistemas y servidores a su cargo, también puede
consultar sistemas o generar reportes. Puede ver contraseñas de servidores y base de datos asociadas a sus
sistemas.
c) Consultor: Usuario que puede consultar ubicación de sistemas o servidores y no puede ver contraseñas de los
servidores o base de datos.
d) Informante: Usuario responsable de ingresar algún incidente asociado a un sistema.