UNIVERSIDAD SIMÓN BOLÍVAR Ingeniería de la Computación

SISTEMA DE INFORMACIÓN PARA LA ACTIVACIÓN, CONTROL Y SEGUIMIENTO DE PLANES DE CONTINGENCIA EN LA C.A. METRO DE CARACAS

Por Argenis Enrique Rodríguez Rondón

INFORME FINAL DE CURSOS EN COOPERACIÓN Presentado ante la Ilustre Universidad Simón Bolívar como Requisito Parcial para Optar el Título de Ingeniero en Computación

Sartenejas, Marzo de 2006

UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE COMPUTACIÓN

ACTA FINAL DE CURSOS EN COOPERACIÓN

SISTEMA DE INFORMACIÓN PARA LA ACTIVACIÓN, CONTROL Y SEGUIMIENTO DE PLANES DE CONTINGENCIA EN LA C.A. METRO DE CARACAS

Presentado por: Argenis Enrique Rodríguez Rondón

Este trabajo de cursos en cooperación ha sido aprobado en nombre de la Universidad Simón Bolívar por el siguiente jurado examinador:

____________________________ Profesora Maruja Ortega. Jurado ____________________________

____________________________

Profesora Anna Cecilia Grimán.

Lic. Gregorio Morales.

Tutor Académico

Tutor Industrial i

SISTEMA DE INFORMACIÓN PARA LA ACTIVACIÓN, CONTROL Y SEGUIMIENTO DE PLANES DE CONTINGENCIA EN LA C.A. METRO DE CARACAS

Por Argenis Enrique Rodríguez Rondón

RESUMEN

Desde su fundación la C.A. Metro de Caracas ha partido de la premisa de brindar un servicio de calidad a la colectividad caraqueña, donde la seguridad y la necesidad del usuario son lo primordial. Bajo este enfoque, y entendiendo al sistema Metro como un sistema estratégico y neurálgico para la ciudad en condiciones normales y en condiciones de irregularidad, el desarrollo de Planes de Contingencia se aborda con la orientación de enfatizar la reducción de la vulnerabilidad que se puede presentar en situaciones de emergencia originadas por fenómenos tecnológicos, sociales o naturales a los que es susceptible el Metro de Caracas. Sin embargo, la empresa no cuenta con la ayuda de alguna herramienta de software que le permita agilizar el proceso de información de la emergencia a todo el personal requerido para asistir al plan de contingencia. Este proyecto surge con el objetivo de proveer a la C.A. Metro de Caracas de una herramienta para el apoyo de este proceso de información, que del mismo modo le simplifique las tareas de planificación, gestión y control del personal participante, que además brinde el soporte informativo con el fin de trazar las mejores estrategias para prestar un mejor servicio al público usuario del sistema ferroviario y superficial en momentos de emergencia. La metodología de desarrollo seleccionada fue Rational Unified Process. La aplicación tiene una arquitectura de tres capas. Fue creado bajo el lenguaje PHP y utiliza los manejadores de Base de Datos Informix y MySQL. Además del desarrollo del sistema como tal, este proyecto también incluyo el estudio de la tecnología de telecomunicaciones a utilizar, al igual que un estudio de las herramientas de software libre más populares que existen en la actualidad, ya que fue un requisito de la empresa que la aplicación se desarrollaría con la utilización de software libre.

ii

AGRADECIMIENTOS En primer lugar, a Dios, por darme las fuerzas necesarias para lograr los objetivos de mi vida. A la labor realizada por mis padres en todos estos años de estudio, los cuales me demostraron que con esfuerzo, amor y pasión se puede llegar muy lejos. A mi hermana Patricia, por servirme de guía y de ejemplo para lograr las mismas metas que con mucho esfuerzo también consiguió. A la profesora Anna Cecilia Grimán, ya que logró que me exigiera al máximo para cumplir exitosamente las metas de mi proyecto. A todas las personas que me acompañaron en el Metro de Caracas durante la pasantía, en especial al Lic. Gregorio Morales, el cual no solo me brindó su ayuda y apoyo como Tutor Industrial, sino que también hizo que me sintiera en familia ante un grupo de personas excepcionales y de una gran calidad humana. ¡¡¡Muchas gracias a todos!!!! A mi querida Universidad Simón Bolívar, que a pesar de las dificultades y del exigente camino al título, me llenó de tantos logros y satisfacciones en el ámbito académico, deportivo y cultural. A mi bella novia Waika, por llegar a mi vida y servirme de apoyo en un momento tan importante, sólo yo sé todo el amor, la paciencia y la comprensión que me dio en tantas semanas de trasnocho por el estudio. A mi queridísima amiga Thais, por su compañía y el apoyo que me brindó durante el desarrollo de la pasantía. A todos los amigos que conocí durante la carrera, en especial a Alejandro, Mafher, Nicola y Joel, ¡¡por ser mucho más!! ¡¡por ser los mejores amigos de la Simón!! Y finalmente, a todas aquellas personas que estuvieron junto a mí y que de una u otra forma me ayudaron a cumplir mis objetivos, ¡¡¡GRACIAS A TODOS!!!

iii

DEDICATORIA Le dedico este trabajo y mi carrera en la Universidad Simón Bolívar a mis padres, por creer en mí y apoyarme en las decisiones que he tomado a lo largo de mi vida. Para Ustedes aquí esta el fruto de mi esfuerzo…

iv

ÍNDICE GENERAL pp. RESUMEN………………………………………………………………………....

ii

AGRADECIMIENTOS…………………………………………………………….

iii

DEDICATORIA…………………………………………………………………....

iv

ÍNDICE GENERAL………………………………………………………………..

v

ÍNDICE DE FIGURAS……………………………………………………………..

vii

ÍNDICE DE TABLAS……………………………………………………………...

viii

ABREVIATURAS………………………………………………………………….

ix

CAPÍTULO I

INTRODUCCIÓN…………………………………………………..

1

II

ENTORNO EMPRESARIAL……………………………………....

4

2.1 Entorno Empresarial………………………………….....

4

2.2 Estructura Organizacional de la Empresa……………….

5

MARCO TEÓRICO………………………………………………...

7

3.1 Contingencia…………………………………………….

7

3.2 Plan de Operaciones Especiales Arco Iris………………

8

3.3 Descripción del Contenedor Web Apache………………

10

3.4 Descripción de Sistemas de Gestión de Base de Datos…

10

3.5 Tecnología SMS………………………………………...

12

MARCO METODOLÓGICO………………………………………

13

4.1 Rational Unified Process (RUP)………………………...

13

FASE DE INICIO…………………………………………………...

15

5.1 Plan del Proyecto………………………………………..

15

5.2 Lista Inicial de Riesgos………………………………….

17

III

IV

V

v

VI

VII

5.3 Caso del Negocio………………………………………..

19

5.4 Visión del Proyecto……………………………………...

21

5.5 Especificación de Requerimientos del Software………..

23

5.6 Plan Creativo……………………………………………

29

FASE DE ELABORACIÓN………………………………………..

32

6.1 Lista Revisada de Riesgos………………………………

32

6.2 Arquitectura de Software………………………………..

34

FASE DE CONSTRUCCIÓN……………………………………....

52

7.1 Evaluación de la Tecnología le Telecomunicaciones…...

53

7.2 Evaluación de la Tecnología de Desarrollo……………..

53

7.3 Diseño y Funcionalidad de la Interfaz de la Aplicación...

55

7.4 Descripción de las Técnicas de Seguridad utilizadas en el Sistema…………………………………………….

59

7.5 Descripción de la Versión Actual……………………….

60

7.6 Problemas Enfrentados………………………………….

61

VIII

CONCLUSIONES…………………………………………………..

62

IX

RECOMENDACIONES…………………………………………….

65

REFERENCIAS BIBLIOGRÁFICAS……………………………...........................

67

BIBLIOGRAGÍA CONSULTADA………………………………...........................

68

REFERENCIAS ELECTRÓNICAS………………………………………………..

69

APÉNDICES……………………………………………………………………….

72

vi

ÍNDICE DE FIGURAS FIGURA

pp.

2.1

Organigrama Estructural de la C.A. Metro de Caracas………………………..

6

5.1

Modelo de Casos de Uso del Negocio………………………………………...

21

5.2

Modelo Inicial de Casos de Uso: SISCON……………………………………

27

5.3

Ventana Principal……………………………………………………………...

30

5.4

Ventana de Opciones de la Aplicación………………………………………..

30

5.5

Ventana de Opciones de Búsqueda……………………………………………

30

5.6

Ventana de Listado de Datos………………………………………………….

30

5.7

Ventana de Listado de Datos………………………………………………….

30

5.8

Color de las Interfaces………………………………………………………...

31

5.9

Diseño de los Botones…………………………………………………………

31

6.1

Modelo Refinado de Casos de Uso: SISCON…………………………………

36

6.2

Diagrama de Secuencia: “Activar Contingencia” …………………………….

40

6.3

Modelo Conceptual……………………………………………………………

41

6.4

Diagrama de Clases……………………………………………………………

44

6.5

Modelo Entidad – Relación de SISCON……………………………………...

46

6.6

Arquitectura de tres Capas…………………………………………………….

48

6.7

Modelo de Red de SISCON…………………………………………………...

50

7.1

Ventana Inicial de la aplicación……………………………………………….

55

7.2

Ventana Principal de la aplicación para el perfil “Administrador”…………...

55

7.3

Ventana Principal de la aplicación para el perfil “Personal”………………….

56

7.4

Ventana de “Activar Contingencia” para el perfil “Administrador”………….

56

7.5

Ventana de “Confirmar activación” para el perfil “Administrador” durante la activación de un Plan de Contingencia……………………………………….. Ventana de “Administración de Características de los Planes de Contingencia” para el perfil “Administrador” ……………………………….. Ventana de “Administración de Contingencia en Proceso” para el perfil “Administrador” ……………………………………………………………… Ventana de “Administración de Personal” (Listado de Asignaciones) para el perfil “Administrador” ……………………………………………………….. Ventana de “Reporte de Contingencia” para el perfil “Administrador”……....

57

7.6 7.7 7.8 7.9

vii

57 58 58 59

ÍNDICE DE TABLAS TABLA 3.1

pp. Resumen de Características de las herramientas PostgreSQL, MySQL e Informix………………………………………………………………. 11

5.1

Plan de Proyecto: Fase de Inicio………………………………………………… 15

5.2

Plan de Proyecto: Fase de Elaboración………………………………………….. 16

5.3

Plan de Proyecto: Fase de Construcción………………………………………… 16

5.4

Plan de Proyecto: Actividades Finales…………………………………………... 16

5.5

Número de Iteraciones para los diferentes proyectos…………………………… 17

5.6

Riesgo: Falta de Información sobre los Planes de Contingencia a Implementar……………………………………………………………………... 18

5.7

Resumen de Características……………………………………………………... 23

5.8

Requerimiento “Perfiles de Usuario” …………………………………………… 24

5.9

Usuarios de SISCON……………………………………………………………. 25

5.10

Casos de Uso de SISCON……………………………………………………….. 25

5.11

Descripción de los casos de uso…………………………………………………. 26

5.12

Requerimientos complementarios……………………………………………….. 28

5.13

Requerimiento Complementario: Facilidad de Uso……………………………... 29

6.1

Caso de Uso: Activar Contingencia……………………………………………... 38

6.2

Descripción de Conceptos del Modelo Conceptual……………………………... 43

6.3

Distribución de Clases en las diferentes capas…………………………………... 49

7.1

Evaluación de la Tecnología de Desarrollo: Herramientas Propuestas…………. 54

viii

ABREVIATURAS API

Application Programming Interface

ASP

Active Server Pages

BSD

Berkeley Software Distribution

DBMS

DataBase Management System

EIT

Empresa Integradora de Telecomunicaciones

ER

Entidad Relación

GIN

Gerencia de Sistemas de Información

GNU

GNU's Not UNIX

HTML

HyperText Markup Language

HTTP

HyperText Transfer Protocol

MADSI

Metodología de trabajo para la ejecución de proyectos de sistemas

MT

Mobile Terminated

PHP

PHP: Hypertext Preprocessor

RUP

Rational Unified Process

SAP

Systeme, Anwendungen und Produkte

SGBD

Sistemas Gestores de Bases de Datos

SISCON Sistema de Gestión de Contingencia SMS

Short Message Service

SQL

Structured Query Language

UML

Unified Modelling Language

XML

eXtensible Markup Language

ix

CAPITULO I. INTRODUCCIÓN La misión de la C.A. Metro de Caracas es la de contribuir al desarrollo del transporte colectivo en el área metropolitana de Caracas, mediante la planificación, construcción, explotación comercial y operación de un sistema integrado de transporte, conformado por una red ferroviaria metropolitana (Metro) y una red alimentadora de transporte superficial (Metrobús), que presta el servicio público de transporte minimizando las dificultades, los riesgos e inconvenientes que conllevan el movimiento de grandes masas de personas. En tal sentido, aunque las posibilidades de ocurrencia de una situación de contingencia en el Metro son muy remotas, la C.A. Metro de Caracas, consciente de su responsabilidad de preservar la seguridad de sus usuarios y de los recursos humanos y materiales, así como garantizar la operatividad del sistema, dirige su atención al desarrollo de Planes de Contingencia para la red Metro y Metrobús. Estos planes constan de varias fases como lo son: activación, ejecución y desactivación. La fase de activación resulta la más crítica ya que el coordinador del plan debe informar al personal requerido de la situación mediante llamadas telefónicas, lo cual representa un proceso largo y engorroso para ser realizado por una sola persona. En la fase de ejecución no se cuenta fácilmente con información en tiempo real de los problemas que se puedan presentar para una toma de decisiones acertada. En la desactivación se tiene la misma problemática que en la activación pero sin el factor crítico del tiempo. Un problema adicional se presenta por la falta de información histórica sobre activaciones anteriores de los planes, las cuales podrían solventar situaciones recurrentes de forma rápida y además ayudar a rediseñar procesos de los planes en función de fallas observadas. Tomando en cuenta los problemas actuales, el desarrollo de Planes de Contingencia se aborda con un enfoque que enfatiza la reducción de la vulnerabilidad que se puede presentar en situaciones de emergencia originadas por fenómenos operativos, sociales o naturales a los que es susceptible el Metro de Caracas. El aporte fundamental de la puesta en marcha de estos planes es la mitigación del impacto que generaría sobre la ciudad de Caracas cualquier evento o fenómeno que afecte al sistema Metro o viceversa.

1

Se considera que para la empresa es de gran importancia disponer de un sistema automatizado que le simplifique las tareas de planificación, gestión y control del personal operativo y de confianza, y que además brinde el soporte informativo con el fin de trazar las mejores estrategias para prestar un mejor servicio al público usuario del sistema ferroviario y superficial en momentos de emergencia. En tal sentido, se pretende ofrecer una manera rápida y eficaz de realizar la fase de activación de estos planes, dado que en determinadas contingencias la rapidez con la que se realice este proceso puede ser vital si se presenta una situación que pongan en riesgo la vida de los pasajeros, por lo cual el tiempo es un factor crítico para el desenvolvimiento del plan. Y por supuesto, se le facilita esta tarea al coordinador del plan. Además se busca proporcionar la información necesaria para la toma de decisiones tanto en el transcurso de la ejecución del plan como en la evaluación del desempeño del mismo. La comunicación de la Aplicación Web que se desarrollaría con el sistema SAP, proporcionaría información actualizada del personal disponible para el momento de la activación de un Plan de Contingencia, permitiendo la planificación y reorganización del personal. La emisión de reportes automáticamente sobre el desenvolvimiento del Plan, le ahorra al coordinador tiempo y trabajo, además de brindar información veraz y confiable al momento de ser solicitada. De manera general, con la realización de este Proyecto se pretende facilitar la aplicación y operación de Planes de Contingencia con el fin de ayudar a agilizar los procesos de activación y desactivación, así como también ayudar en la toma de decisiones en momentos de emergencia. En lo que concierne a la metodología de desarrollo seleccionada, se estudiaron las similitudes de la Metodología de Desarrollo de Sistemas de Información de la empresa (MADSI) con respecto a Rational Unified Process (RUP), con el objetivo de mantener los estándares de desarrollo establecidos por la Gerencia de Sistemas de Información, aunque permitiendo el avance y la actualización de su metodología actual debido a que no está enfocada al desarrollo de Aplicaciones Web y no contempla un proceso iterativo de refinamiento del sistema como lo tiene la metodología RUP.

2

Este tomo se encuentra organizado en nueve (9) capítulos, compuestos de la introducción, descripción del entorno empresarial, marco teórico y metodológico, los artefactos entregables y resultados para cada fase de la metodología utilizada, conclusiones y recomendaciones. A continuación se presenta el Capítulo II – Entorno Empresarial, el cual muestra brevemente los detalles más importantes de la empresa en la cual se realizó el proyecto de pasantía.

3

CAPITULO II. ENTORNO EMPRESARIAL 2.1. ENTORNO EMPRESARIAL La Compañía Anónima Metro de Caracas fue fundada el 8 de agosto de 1977, como una empresa adscrita al Ministerio de Transporte y Comunicaciones. El objetivo principal de la compañía es “la construcción e instalación de las obras y equipos, tanto de infraestructura como de superestructura del Metro de Caracas, el mantenimiento de sus equipos, instalaciones y la operación, administración y explotación de dicho sistema de transporte, así como la construcción, dotación, operación y explotación de otras instalaciones y sistemas complementarios y auxiliares del subterráneo, tales como estacionamientos, sistemas superficiales, elevados, subterráneos de transporte urbano y suburbano” (Registro Mercantil, 1977). Según la Reseña Histórica del Sistema Metro (2006), la empresa inicia la operación comercial, el 2 de enero de 1983, de la primera etapa de la Línea 1 desde Propatria hasta La Hoyada, con ocho estaciones. En octubre de 1987 inicio operaciones el sistema de Transporte Superficial (Metrobús). Un año después, el 6 de noviembre de 1988 arranca el tramo La Paz – El Silencio de la Línea 2 e inicia su operación. En los años siguientes el Metro continuó su expansión hasta finalizar completamente los 20,36 Kilómetros de la Línea 1, con el tramo Los Dos Caminos – Palo Verde, inaugurado el 19 de noviembre de 1989. El avance no se detuvo y el Metro se expandió hacia la parte sur de la ciudad; el 18 de diciembre de 1994 entró en funcionamiento el tramo Plaza Venezuela – El Valle, de la Línea 3. Actualmente la red de subterráneo cuenta con 42,5 Kilómetros de extensión y 39 estaciones, que movilizan diariamente cerca de un millón de usuarios. Con la firme determinación de dotar a la capital de una infraestructura de transporte público que satisfaga las necesidades de la población, el Metro de Caracas trabaja en nuevos planes y proyectos de expansión. En este sentido, tiene concluidos los estudios previos de nuevos ramales que aliviarán el problema de transporte en densos sectores de la ciudad.

4

2.2. ESTRUCTURA ORGANIZACIONAL DE LA EMPRESA La C.A. Metro de Caracas, como empresa moderna y dinámica, ha mantenido un proceso de evolución constante adaptando su organización a las distintas etapas que han caracterizado su desarrollo. La Empresa inició sus actividades con una organización sencilla, orientada básicamente al diseño de los proyectos técnicos de construcción de obras civiles y equipos, así como el desarrollo de estudios socioeconómicos dirigidos a cuantificar y obtener los recursos financieros necesarios para la construcción del Sistema Metro. Posteriormente, y en forma paralela al diseño de sus proyectos a mediano plazo, la Empresa adoptó una organización más compleja y situación que ha conllevado a contratar diversas empresas que se han encargado de la ejecución de los proyectos e igualmente ir capacitando los recursos humanos responsables de la operación y mantenimiento del Sistema. Al finalizarse la construcción de la primera etapa de la línea 1, la empresa transformó su organización nuevamente con el fin de acondicionarla a la operación y mantenimiento de los equipos e instalaciones en general, así como atender al gran número de usuarios que diariamente utiliza el servicio ofrecido. Igualmente se ajustó su organización para asumir la administración y control de un sistema de transporte distinto al que hasta ahora se había manejado, como lo es el transporte superficial, concebido este último como una red alimentadora del sistema subterráneo. En este mismo orden de ideas, para el año 2000 se presenta la estructura organizativa que se encuentra vigente en los actuales momentos, estructurada por cinco sectores; dirección superior, asesoría, control, ejecutivo y corporativo. En el sector de dirección superior se encuentra la Presidencia de la Empresa, así como la Gerencia Corporativa de Protección Integral y la Gerencia Corporativa de Planificación y Mercadeo; En el sector de Asesoría se ubican la Consultoría Jurídica y la Gerencia de Relaciones Públicas. El Sector de Control lo conforma la Contraloría Interna. Bajando a los siguientes niveles de la empresa, se encuentran el Sector Corporativo con las Gerencias Corporativas de: Recursos Humanos, Administración y Finanzas, Logística y Tecnología de la Información y las Gerencias Ejecutivas de: Construcción, Transporte Metro Ingeniería y Transporte Superficial. En la figura 2.1 se presenta el organigrama estructural de la empresa, el cual refleja la estructura organizativa vigente.

5

Figura 2.1. Organigrama Estructural de la C.A. Metro de Caracas Fuente: (Intranet Corporativa, 2005) Es necesario destacar que la pasantía se desarrolló dentro de la Gerencia de Sistemas de Información (GIN), la cual esta adscrita a la Gerencia Corporativa de Tecnología de la Información. El objetivo principal de dicha gerencia es la de garantizar el desarrollo e implantación de los sistemas de información requeridos por las unidades para obtener una mayor eficiencia en su funcionamiento en pro del logro de los objetivos de la empresa. En todo desarrollo de software se encuentran conceptos teóricos muy relacionados al mismo y que de alguna manera ayudan a un mejor entendimiento de la situación. El siguiente capítulo presenta todos los conceptos y aspectos concernientes al desarrollo del Sistema de Activación, Control y Seguimiento de Planes de Contingencia. 6

CAPITULO III. MARCO TEÓRICO En este capítulo se presentan todos los aspectos teóricos que fundamentan el desarrollo de este proyecto, involucrándose tanto los aspectos relacionados con el dominio, como aquellos relacionados con la tecnología utilizada. Este proyecto involucra el desarrollo de una Aplicación Web que apoye el proceso de activación, control, seguimiento y desactivación de una contingencia, que de la misma forma permita registrar y analizar los reportes e historiales de contingencias ejecutadas para evaluar los procedimientos a seguir para futuros eventos que requieran nuevamente de la utilización del sistema. Por lo tanto, se hace necesario conocer aquellos conceptos y aspectos más importantes relacionados con planes de contingencia. 3.1. CONTINGENCIA El Ministerio de Economía (2000) expone: Un plan de contingencia es un conjunto de procedimientos alternativos a la operación normal, que le permitirá a su Organización seguir operando, aún cuando alguna de sus funciones deje de hacerlo por una falla. El hecho de que una Organización tenga un plan de contingencia no implica que se trabaje inadecuadamente. Por el contrario indica que la Organización es previsora y que está cubriendo las eventualidades tanto internas como externas. Un plan de contingencia ayuda a la organización a tener respuestas ante emergencias. Un plan de contingencia es un mecanismo esencial de gestión basado en la evaluación de los problemas, necesidades y recursos. Para dicho plan se deberá determinar las prioridades, establecer objetivos y especificar las acciones que deben emprender los agentes responsables de los distintos sectores de una operación. Será preciso identificar claramente las tareas específicas de una emergencia y las partes responsables de la ejecución de dichas tareas, y formular un plan lo más claro y conciso posible. Según Wall (1997) los planes de contingencia deberán identificar cuestiones clave tales como: La naturaleza de la contingencia Las repercusiones operativas de la contingencia 7

Las respuestas viables Las implicaciones financieras de las respuestas “La orientación principal de un plan de contingencia es la continuidad de operaciones de la Organización. El plan debe constar de las etapas de evaluación, planificación, pruebas, ejecución y recuperación” (Ministerio de Economía, 2000). 3.2. PLAN DE OPERACIONES ESPECIALES ARCO IRIS “El Metro de Caracas se ha convertido en un sistema neurálgico para la ciudad, ya que diariamente transporta un millón de pasajeros a sus destinos. Si el Metro de Caracas se paraliza, no sólo se paraliza un sistema de transporte urbano, sino que se paraliza gran parte de la fuerza laboral y estudiantil de la ciudad, ya que el transporte público en general colapsa por el aumento en la demanda” (Gerencia Ejecutiva de Transporte Metro, 2003). A continuación se presenta un extracto del documento Plan de Operación Especial Arcoiris, el cual fue elaborado por la Gerencia Ejecutiva de Transporte Metro en el año 2003. 3.2.1. OBJETIVO DEL PLAN DE OPERACIONES ESPECIALES ARCO IRIS Garantizar la operación del sistema Metro y Metrobús, aunque disminuyendo la calidad del servicio prestado y la cantidad de unidades disponibles, pero manteniendo la efectividad y los niveles mínimos de seguridad. 3.2.2. CARACTERÍSTICAS DEL PLAN DE OPERACIONES ESPECIALES ARCO IRIS El origen de una emergencia es la naturaleza de la misma, es decir, el principio de la emergencia. Los diferentes orígenes que puede tener una situación de contingencia o emergencia son los siguientes: Natural: sismos, deslizamientos e inundaciones. Social: atentados, motines, sabotaje, asaltos, detonación de artefactos explosivos, paros. Operacional: fallas técnicas en el funcionamiento operativo. Otros: aquellas que son de alto impacto o no califican entre las anteriores. 8

Para cada origen de contingencia se pueden presentar diferentes escenarios. Los escenarios son los ambientes o situaciones que se presentan, es decir, la situación de emergencia en sí. Para ver los diferentes escenarios ver Apéndice XIII y Apéndice XIV. Según el escenario que se presente se llaman a diferentes grupos de personas para atender la contingencia. Los grupos son los diversos equipos de trabajo que son solicitados para cumplir labores para las cuales han sido entrenados anteriormente. Los diferentes grupos se pueden observar en el Apéndice XV. Dependiendo del escenario presentado se puede requerir diferentes grupos. Es por ello que cada escenario tiene asociado un conjunto de grupos que poseen las características para atender la emergencia. Para ver las asignaciones de grupos según los escenarios presentados se puede revisar el Apéndice XVI. 3.2.3. CADENA DEL PERSONAL RESPONSABLE DE LA ACTIVACIÓN DEL PLAN DE OPERACIONES ESPECIALES ARCO IRIS Para activar el Plan de Operaciones Especiales Arco Iris, es necesaria la autorización desde los niveles más altos de la Estructura Organizativa de la C.A. Metro de Caracas, comenzando, por supuesto, desde el puesto de Presidencia. Debido a la importancia de activar el plan lo antes posible cuando ocurre un suceso o evento anormal que lo requiera, es indispensable que ante la ausencia del Presidente o Vicepresidente, la responsabilidad de ejecutar la activación pueda ser relevada siguiendo un orden estricto dentro de una cadena de personas que tienen distintos cargos dentro de la empresa, de tal manera, que siempre sea posible que alguien active el plan en un momento determinado. Para la elaboración de dicha cadena, es preciso tomar en cuenta las funciones que cada gerencia cumple con la empresa a la hora de una contingencia. De tal forma, se propone básicamente el inicio de esta cadena de personal de la siguiente manera: PRESIDENTE

VICEPRESIDENTE

GTE. DE CONTROL OPERATIVO

GTE. CORPORATIVO DE PROTECCIÓN INTEGRAL

GTE. DE SEGURIDAD INDUSTRIAL GTE. EJEC. DE MANTENIMIENTO

GTE. EJEC. DE TRANSPORTE METRO GTE. DE PROTECCIÓN Y SEGURIDAD

... 9

Una vez presentados los aspectos teóricos relacionados con el dominio del problema, es conveniente entrar a detallar aquellos puntos relevantes sobre las tecnologías evaluadas y posteriormente utilizadas para el desarrollo de este proyecto. 3.3. DESCRIPCIÓN DEL CONTENEDOR WEB APACHE Escriben colaboradores de Wikipedia (2006a): El servidor HTTP Apache es un servidor HTTP de código abierto para plataformas Unix (BSD, GNU/Linux, etcétera), Windows y otras, que implementa el protocolo HTTP/1.1 (RFC 2616) y la noción de sitio virtual. Cuando comenzó su desarrollo en 1995 se basó inicialmente en código del popular NCSA HTTPd 1.3, pero más tarde fue reescrito por completo. Su nombre se debe a que originalmente Apache consistía solamente en un conjunto de parches a aplicar al servidor de NCSA. Era, en inglés, a patchy server (un servidor parcheado). El servidor Apache se desarrolla dentro del proyecto HTTP Server (httpd) de la Apache Software Foundation. Apache presenta entre otras características mensajes de error altamente configurables, bases de datos de autenticación y negociado de contenido, pero fue criticado por la falta de una interfaz gráfica que ayude en su configuración. En la actualidad, Apache es el servidor HTTP más usado, siendo el servidor HTTP del 68% de los sitios Web en el mundo y creciendo aún su cuota de mercado. 3.4. DESCRIPCIÓN DE SISTEMAS DE GESTIÓN DE BASE DE DATOS Según Hernández (2003), entre los Sistemas de Gestión de Base de Datos (SGBD) libres más populares que se disponen actualmente tenemos PostgreSQL y MySQL, es por ello que se considera necesario destacar algunas características de estos sistemas, tomando en cuenta a que es un requisito de la empresa desarrollar el presente proyecto en Software Libre. Junto a la presentación de las características de estos sistemas también se incluirá las del SGBD Informix, debido a que ha sido el más usado dentro de la Gerencia de Sistemas de Información y se evalúa actualmente mantener su utilización en los próximos proyectos.

10

A continuación se presenta la tabla 3.1 con el resumen de las características de los SGBD señalados anteriormente:

-

-

-

POSTGRESQL Claves ajenas. Disparadores (triggers). Vistas. Integridad transaccional. Acceso concurrente multiversión (no se bloquean las tablas, ni siquiera las filas, cuando un proceso escribe). Capacidad de albergar programas en el servidor en varios lenguajes. Herencia de tablas. Tipos de datos y operaciones geométricas.

-

-

-

MYSQL Amplio subconjunto del lenguaje SQL. Algunas extensiones son incluidas igualmente. Disponibilidad en gran cantidad de plataformas y sistemas. Diferentes opciones de almacenamiento según si se desea velocidad en las operaciones o el mayor número de operaciones disponibles. Transacciones y claves foráneas. Conectividad segura. Replicación. Búsqueda e indexación de campos de texto.

-

-

-

INFORMIX Utiliza plataforma NT y UNIX. Se especializa en aplicaciones tipos GIS (datos geográficos). Proporciona tablas que forma el SMI (interfaz de monitorización del sistema). Gestiona múltiples base de datos remotas de una única y centralizada cónsola donde se muestran gráficamente tanto la base de datos, como los objetos que contiene (tablas, índices, procedimientos). Tiene la capacidad de relación de datos en múltiples lugares físicos. Ofrece varias opciones para conectar datos relacionales en páginas web. Es costoso. Se integra con Linux y Oracle. Ofrece herramientas para crear menús, formularios de entrada de datos y generadores de listados. Datawarehouse y Datamining, software que permite manipular información de varias empresas (Ej.: data crédito).

Tabla 3.1. Resumen de Características de las herramientas PostgreSQL, MySQL e Informix Fuente: (Colaboradores de Wikipedia, 2006b, 2006c y 2006d) Otra de las tecnologías a evaluar en el presente proyecto es la relacionada con el envío de mensajes de texto a teléfonos móviles. A continuación se presenta el concepto y los beneficios de dicha tecnología.

11

3.5. TECNOLOGÍA SMS “El servicio de mensajes cortos o SMS (Short Message Service) es un servicio disponible en los teléfonos móviles que permite el envío de mensajes cortos (también conocidos como mensajes de texto, o más coloquialmente, textos o incluso txts o msjs) entre teléfonos móviles, teléfonos fijos y otros dispositivos de mano.” (Colaboradores de Wikipedia, 2006e). Escribe Alsina (2003): Gracias al uso tan extendido de la telefonía móvil en los países occidentales, ésta puede ser empleada para avisar a un gran grupo de población sobre determinados eventos. Hasta ahora se tienen ejemplos de servicios que, ya sea pagando o de forma gratuita, hacen llegar a nuestro teléfono móvil mediante mensajes de texto cortos (SMS) informaciones sobre cotizaciones bursátiles, noticias de interés general o resultados deportivos. Esta misma tecnología puede también utilizarse para finalidades de protección civil o alertas diversas en casos de emergencias. La gran ventaja de este sistema es, tal y cómo se ha comentado, el uso masivo de la telefonía móvil, además de que los usuarios llevan con ellos los terminales prácticamente a todas horas, factor que lo convierte en un sistema muy eficiente. Según la empresa Tango/04 (2006) los beneficios para el usuario de SMS son: Mensajería instantánea: Las redes de telecomunicaciones entregan los mensajes más rápidamente que los servidores de e-mail. Fiable y segura: Los mensajes siempre llegan, las funcionalidades de la tecnología SMS incluyen la confirmación de entrega en el dispositivo que envía el mensaje. Barato: Tanto el hardware como el envío en sí son de bajo costo. Dispositivos ligeros: Los teléfonos móviles son altamente portables. Cobertura: SMS está soportado en todo el mundo, representa la última tecnología de comunicaciones. Estándar de la industria: SMS ha sido adoptado como el estándar de servicio de mensajería por todas las industrias. Con esto concluye la presentación de los aspectos teóricos involucrados con este proyecto. El siguiente capítulo se refiere a la descripción de los detalles metodológicos. 12

CAPITULO IV. MARCO METODOLÓGICO En el presente capítulo se presenta brevemente los detalles de la metodología escogida para el desarrollo del proyecto, así como la justificación de esta elección. Sin embargo, como fue destacado en capítulos anteriores, la Gerencia de Sistemas de Información, que es la unidad donde se desarrolló el presente proyecto, ya cuenta con una metodología para el desarrollo de sistemas informáticos, aunque dicha metodología no está enfocada a la construcción de aplicaciones Web. En vista de esto último, se propuso la utilización (dentro de los límites de la pasantía) de Rational Unified Process (RUP), proceso que captura varias de las mejores prácticas en el desarrollo moderno de software en una forma que es aplicable para un amplio rango de proyectos y organizaciones, que también tiene mucha similitud con la metodología actual de la Gerencia pero que además contempla métodos y procedimientos para el desarrollo de aplicaciones Web. 4.1. RATIONAL UNIFIED PROCESS (RUP) Según Kruchten (2003), la metodología RUP, llamada así por sus siglas en inglés Rational Unified Process, divide en 4 fases el desarrollo del software: Inicio, El Objetivo en esta etapa es determinar la visión del proyecto. Elaboración, En esta etapa el objetivo es determinar la arquitectura óptima. Construcción, En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial. Transición, El objetivo es llegar a obtener el “release” del proyecto. Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes. Kruchten (2003), también expone que es recomendable que a cada una de estas iteraciones se les clasifique y ordene según su prioridad, y que cada una se convierte luego en un entregable al cliente. Esto trae como beneficio la retroalimentación que se tendría en cada entregable o en cada iteración. 13

Los elementos del RUP son: Actividades, Son los procesos que se llegan a determinar en cada iteración. Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso. Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de modelo. Según Mendoza (2004), una particularidad de esta metodología es que, en cada ciclo de iteración, se hace exigente el uso de artefactos, siendo por este motivo, una de las metodologías más importantes para alcanzar un grado de certificación en el desarrollo del software. Debido a restricciones de tiempo, este proyecto sólo cubrirá las tres primeras fases del proceso, a saber: Inicio, Elaboración y Construcción. Por lo que se obtendrá solamente una versión inicial para este proyecto en particular, que aporte los recursos y herramientas necesarias para la iniciación de la Gerencia en el desarrollo de aplicaciones Web sobre software libre. El entrenamiento a los usuarios y la puesta en marcha del sistema en los diferentes servidores queda, entonces, a cuenta de la empresa. A continuación se muestra la lista de los artefactos a entregar por cada fase: Fase de Inicio: Plan del Proyecto. Lista Inicial de Riesgos. Caso del Negocio. Visión del Proyecto. Especificación de Requerimientos de Software. Glosario Inicial del Proyecto. Plan Creativo. Fase de Elaboración: Lista Revisada de Riesgos. Documento de Arquitectura del Software. Fase de Construcción: Versión Inicial del Sistema. En los próximos capítulos se presentará cada uno de los artefactos entregables en cada fase del proceso seguido y su respectiva explicación. 14

CAPITULO V. FASE DE INICIO La fase de Inicio es la primera de las cuatro fases que establece Rational Unified Process. Esta fase tiene por objetivos la obtención de un mejor entendimiento sobre el producto que se quiere construir, identificar las principales funcionalidades que se requieren, determinar al menos una posible solución y establecer los riesgos y costos asociados y el plan de trabajo a seguir. A continuación se presenta los principales entregables de esta fase, a saber: Plan de Proyecto, Lista de Riesgos, Caso del Negocio, Visión, Especificación de Requerimientos del Software y Plan Creativo. 5.1. PLAN DEL PROYECTO Según Booch (1999), este documento es un plan que proporciona un “mapa de trayectoria” para un proyecto. A continuación se presenta un extracto del documento Plan del Proyecto, los detalles completos se encuentran en el Apéndice I – Plan del Proyecto. Plan de actividades de la Fase de Inicio Actividad Definición de los objetivos del proyecto Definición del alcance detallado del proyecto Diagnóstico de la situación actual y propuesta de la solución del problema Definición de indicadores de éxito del proyecto, creación de un documento inicial de riesgos Redacción del documento “Visión” del proyecto Creación de un modelo inicial de Casos de Uso Redacción de un glosario inicial del proyecto Creación de un diagrama del Proceso Global Actual vs. Esperado Evaluación de los objetivos de la organización Evaluación de la factibilidad técnica, operacional y económica del proyecto Creación del documento “Caso del Negocio” Análisis y propuesta de la tecnología y el lenguaje de desarrollo de Software Libre a utilizar para definir la Arquitectura Candidata Definir y construir el Plan de Implantación del Proyecto Creación de un Plan de Proyecto

Tabla 5.1. Plan de Proyecto: Fase de Inicio Fuente: Elaboración Propia 15

Semana 1 1,2 2 2 2 2 2 2 2 3 3 3 3 3

Plan de actividades de la Fase de Elaboración Actividad Re-evaluar los requerimientos iniciales Diseño de las interfaces Actualización del modelo de Casos de Uso Diseño de Procesos Propuestos y Base de Datos, creación del Documento de Arquitectura del Software Creación de diagramas de clases, de casos de uso, de colaboración, de estados y de secuencia Elaboración del cronograma detallado del proyecto para la revisión del Plan de Proyecto

Semana 4 4,5 5 5,6 6,7 7

Tabla 5.2. Plan de Proyecto: Fase de Elaboración Fuente: Elaboración Propia Plan de actividades de la Fase de Construcción Actividad Creación de la Base de Datos de la aplicación Desarrollo e Implementación del Sistema para la activación de los diversos planes de contingencia de la C.A. Metro de Caracas, según el tipo de usuario Creación de la Capa de Interfaz Creación de la Capa Lógica Ejecución de pruebas del sistema y preparación de los datos para la carga inicial del sistema Ajuste y correcciones hechas a la aplicación

Semana 8 9 a la 15 11,12 12 a la 16 17,18 18

Tabla 5.3. Plan de Proyecto: Fase de Construcción Fuente: Elaboración Propia En vista de que el alcance del proyecto no contempla la fase de transición, no se presenta el plan de actividades para la misma, sin embargo, durante las 2 últimas semanas de la pasantía se planificaron el comienzo de algunas actividades que se deben destacar. Actividad Implantar el sistema en los distintos servidores y ejecutar las distintas pruebas finales Elaboración del Informe de la Pasantía

Tabla 5.4. Plan de Proyecto: Actividades Finales. Fuente: Elaboración Propia 16

Semana 19, 20 19, 20

El número de iteraciones definido para cada una de las fases de RUP depende en gran medida del tamaño del proyecto. Kruchten (2003) propone un número determinado de iteraciones en función del tamaño del proyecto en cuanto a meses y a la cantidad de personas involucradas. La tabla 5.5 muestra la sugerencia expuesta por Kruchten (2003). NÚMERO DE PERSONAS 3 10 80

NÚMERO DE MESES 4 8 20

CONCEPCIÓN 1 1 2

NÚMERO DE ITERACIONES POR FASE ELABORACIÓN CONSTRUCCIÓN TRANSICIÓN 1 3 1 2 3 2 3 4 2

Tabla 5.5. Número de Iteraciones para los diferentes proyectos Fuente: (Kruchten, 2003) Este proyecto tuvo una duración de 20 semanas (5 meses aproximadamente) y fue desarrollado por una sola persona, por lo cual es comparable con un proyecto de 4 meses, desarrollado por 3 personas. El número de iteraciones definido para cada fase, se obtuvo en función de esto, y siguiendo la sugerencia de Kruchten (2003). El siguiente paso, una vez definido el Plan del Proyecto, es determinar los principales riesgos asociados a este desarrollo. En la sección siguiente se presenta la Lista inicial de riesgos. 5.2. LISTA INICIAL DE RIESGOS Según Jacobson et al. (1999), un riesgo es la probabilidad de que un proyecto experimente eventos indeseables, tales como retrasos en la planificación, costos de más, o su cancelación. Estos autores exponen que la manera en la cual se planea el desarrollo de un nuevo sistema es considerablemente influenciada por los riesgos que se perciben. Por lo tanto, uno de los primeros pasos, en la fase de concepción es crear una lista de riesgos. En lo que sigue se presentará una lista de los riesgos que se pueden presentar durante el desarrollo del proyecto. Los riesgos del proyecto son presentados en forma decreciente de importancia. La tabla 5.6 muestra la descripción de uno de estos riesgos, el detalle de todos los riesgos se encuentra en el Apéndice IV – Lista de Riesgos. 17

Requerimientos pocos claros. Falta de información sobre los planes de contingencia a implementar. Recursos limitados e inestables. Disponibilidad de tiempo de los usuarios y administradores. Estimaciones de tiempo no realistas. Tecnología nueva o poco probada. Falta de experiencia de los desarrolladores. Integración de datos. FALTA DE INFORMACIÓN SOBRE LOS PLANES DE CONTINGENCIA A IMPLEMENTAR MAGNITUD DESCRIPCIÓN IMPACTO INDICADORES ESTRATEGIA DE MITIGACIÓN PLAN DE CONTINGENCIA

Alta Disponibilidad de la información sobre los planes de contingencia a implementar y que pueden ser asistidos por un sistema de información. Dificultad en el planteamiento de la solución a desarrollar. Falta de asesoría técnica y especializada acerca de los planes de emergencia o contingencia de la C.A. Metro de Caracas. Estudiar y analizar los manuales de procedimientos e informes de simulacros obtenidos en la búsqueda de documentación oficial del Metro de Caracas, para conseguir los puntos clave en donde el sistema podría asistir automatizando los procesos. Utilizar los planes más sencillos, pero que cubran las necesidades mínimas del negocio genérico planteado.

Tabla 5.6. Riesgo: Falta de Información sobre los Planes de Contingencia a Implementar Fuente: Elaboración Propia Una vez definido el alcance y los riesgos del proyecto se procede a presentar el Caso del Negocio, el cual presenta la descripción del producto, el contexto del negocio, los criterios de éxito, la planificación financiera y las restricciones del desarrollo.

18

5.3. CASO DEL NEGOCIO En esta sección se presenta un extracto del documento Caso del Negocio, para ver el documento completo dirigirse al Apéndice VII – Caso del Negocio. Probasco (2000) expone que el caso del negocio provee la información necesaria, desde el punto de vista del negocio, para determinar si vale la pena o no invertir en el proyecto. Éste provee la justificación del proyecto y establece sus restricciones económicas. 5.3.1. DESCRIPCIÓN Y OBJETIVOS DEL PRODUCTO Al finalizar este proyecto la C.A. Metro de Caracas debía contar con una herramienta que le permita automatizar todas las tareas relacionadas con la activación, control y seguimiento de los planes de contingencia que se originen, lo cual agilizará el tiempo de respuesta y disminuirá el impacto negativo que ocasione el retraso de las actividades a realizar durante una determinada emergencia. La aplicación Web proveerá las herramientas necesarias para que el administrador del sistema o los coordinadores de la contingencia puedan realizar la activación de la misma, que permitiría que todas las personas encargadas o responsables de llevar a cabo una labor sean informadas al instante y se reporten rápidamente a su área de trabajo. A pesar que la funcionalidad principal para agilizar los procesos sea la comunicación rápida y efectiva, también hay que agregar que la aplicación ofrecerá toda la información necesaria para que se puedan configurar las características relacionadas con el escenario que se presente durante una contingencia, lo que automatizará la elección inmediata del personal que asistirá a la operación especial con sus respectivas asignaciones, en lo que respecta al área de trabajo al que van asistir y los procedimientos que en ella deban seguir. De la misma forma, también la empresa contará con una herramienta que le provea los reportes de las contingencias ejecutadas, lo que será de gran ayuda cuando se estudien los resultados de la operación y se tomen medidas para mejorar la toma de decisiones cuando se presenten nuevas emergencias con las mismas características y dentro del mismo escenario.

19

Gracias a todo esto, la C.A. Metro de Caracas contará con un sistema de información que le ayudará a mantener el servicio comercial bajo situaciones de emergencia, lo cual es vital ya que la detención de dicho servicio es causal de una emergencia más grande que es la cancelación del 30% del transporte urbano durante un tiempo que mientras mas largo sea, más tráfico y caos originará en la ciudad. Para entender todavía más la importancia de este desarrollo dentro del marco de la organización, en la siguiente sección se presenta el Contexto del Negocio. 5.3.2. CONTEXTO DEL NEGOCIO La C.A. Metro de Caracas es una empresa del estado cuyo negocio se basa en el transporte de usuarios en el Área Metropolitana a través de un sistema ferroviario subterráneo y un sistema de transporte terrestre. El Sistema de Activación, Control y Seguimiento de Planes de Contingencia se desarrolló para lograr la automatización de todos aquellos procesos que son críticos a la hora de una emergencia, como lo son: la comunicación rápida y efectiva del suceso y los procedimientos a seguir por las personas involucradas, la administración confiable de todos los recursos humanos y la puesta en marcha de planes de seguridad y de logística que sean requeridos. Además de ayudar a evaluar el histórico de las contingencias ejecutadas que sirvan de soporte para el desarrollo de nuevas estrategias de acción y de planificación. Por otra parte, el sistema es pionero en la empresa en lo que respecta a la utilización de un componente tecnológico dentro del área de las comunicaciones inalámbricas como lo son los teléfonos celulares, cuya utilización ha aumentado vertiginosamente en Venezuela con el apoyo del servicio de mensajes cortos (SMS). El Modelo de Casos de Uso del Negocio es el artefacto a entregar en el Contexto del Negocio, en la figura 5.1 se presenta el respectivo modelo.

20

Figura 5.1. Modelo de Casos de Uso del Negocio Fuente: Elaboración Propia La siguiente sección presenta un extracto del documento Visión del Proyecto. Los detalles completos se encuentran en el Apéndice II. Visión del Proyecto. 5.4. VISIÓN DEL PROYECTO La C.A. Metro de Caracas, como empresa dedicada al transporte masivo de personas dentro de la región capital, es un sistema neurálgico de suma importancia, el cual debe mantener la operación comercial incluso bajo escenarios de emergencia. Conscientes de la problemática que implica detener el servicio de trenes durante una emergencia, se requiere de un sistema de información que tenga como funcionalidad principal apoyar al plan de contingencia que se lleve a cabo en un determinado escenario. Esta funcionalidad se basa principalmente en la gestión del proceso de activación de un Plan de Contingencia cuando se presenta un evento, suceso o emergencia que requiera la ejecución de una actividad de operación especial. También, se fundamenta en la acción a seguir

21

para lograr difundir el mensaje de activación al personal requerido para asistir las operaciones especiales. El proyecto en sí, tiene como alcance la construcción de un sistema que permita al administrador la activación del Plan de Operaciones Especiales Arco Iris, que de la misma forma también le sea posible configurar y describir todas las características del evento que originó la activación, la administración de la lista del personal de confianza, la elección de las personas o grupos de personas que serán notificadas y el manejo de los reportes generados tanto por la asistencia del personal como por el resultado general de la operación especial en los distintos puestos de trabajo. También incluye el estudio de toda la plataforma tecnológica para la elaboración del sistema, en lo que concierne al estudio del software (lenguajes, base de datos, etc.), hardware (tarjetas de interfaz telefónica, servidores, etc.), el servicio de mensajería de texto y de voz y de cualquier tecnología que se considere necesaria para que el sistema cumpla con los requerimientos de la empresa. En la tabla 5.7 se muestra un listado con los beneficios que obtendrá el cliente a partir del producto: Beneficio del cliente Mayor velocidad en el flujo de información al realizar la activación o desactivación de un Plan de Contingencia. Reportes automáticos de la asistencia del personal a sus puestos de trabajo. Mayor facilidad para administrar los eventos que puedan ocurrir en una contingencia.

Características que lo apoyan Servicio Web que ejecutará el envío de correos electrónicos y mensajes de texto de celular al personal requerido. Utilizando igualmente la Aplicación Web, el personal podrá reportar su asistencia. La Aplicación Web permitirá a los usuarios autorizados para tal fin, incluir, eliminar y modificar los eventos que sean necesarios manejar y que generen la activación de un Plan de Contingencia. Mayor facilidad para administrar el La Aplicación Web permitirá a los personal requerido según el tipo de evento, usuarios autorizados para tal fin, distribuir suceso o emergencia que origine la a cada uno de los trabajadores que integran activación de un Plan de Contingencia. el Personal de Confianza y Operativo de la C.A. Metro de Caracas, en las áreas de trabajo pertinentes para la asistencia de la operación especial. 22

Mayor facilidad para el control de los reportes de resultados generales de los Planes de Contingencia ejecutados.

La Aplicación Web generará reportes de diferentes actividades y asuntos pertinentes al desenvolvimiento de la contingencia, el cual podrá ser manejado por los usuarios autorizados. Adicionalmente, se tiene planteado que estos reportes puedan ser generados en formato de la herramienta Microsoft Excel, la cual en los últimos años ha servido para manejar y plasmar los reportes de diferentes procesos de la empresa.

Tabla 5.7. Resumen de Características Fuente: Elaboración Propia A continuación se presenta la especificación de requerimientos del software, el cual esta dividido en la presentación de los Requerimientos Funcionales, el Modelo Inicial de Casos de Uso y los Requerimientos Complementarios. 5.5. ESPECIFICACIÓN DE REQUERIMIENTOS DEL SOFTWARE Según Kruchten (2003), la especificación de requerimientos del software trata de especificar las funciones que debe desempeñar el software, las exigencias que debe satisfacer en el desempeño de esas funciones y las que deben cumplir el proceso de producción. Para comenzar, se presenta la descripción de los requerimientos funcionales de la aplicación. 5.5.1. REQUERIMIENTOS FUNCIONALES DEL SISTEMA “Los requerimientos son una descripción de las necesidades o deseos de un producto. La meta primaria de la fase de requerimientos es identificar y documentar lo que en realidad se necesita, en una forma que claramente se lo comunique al cliente y a los miembros del equipo de desarrollo” (Larman, 1999). El documento de requerimientos define los servicios que serán proporcionados por el sistema. Es la declaración oficial de lo que es requerido al sistema. A continuación se presentará 23

la lista de los requerimientos funcionales del sistema y la descripción de uno de ellos en la tabla 5.8. Las descripciones de los demás requerimientos se encuentran en el Apéndice III – Requerimientos Funcionales. R.1. Perfiles de usuario. R.2. Actualización de datos. R.3. Configuración de las características de las contingencias. R.4. Activación de un plan de contingencia. R.4.1. Configuración de la activación de un plan de contingencia. R.4.2. Configuración del personal participante. R.4.3. Comunicar la activación del plan de contingencia al personal participante. R.5. Confirmación de recepción de los mensajes del sistema. R.6. Reporte de asistencia del personal solicitado. R.7. Consulta de asignaciones de trabajo del personal. R.8. Consulta de la asistencia del personal solicitado. R.9. Ingreso de planes de seguridad. R.10. Desactivación de un plan de contingencia. R.10.1. Comunicar la desactivación del plan de contingencia. R.11. Mantener el historial de los planes ejecutados. Número Nombre Tipo Detalles y Restricciones Versión Condición

R.1 Perfiles de Usuario Control y Seguridad Permitir el acceso al personal requerido para la activación, control y mantenimiento del sistema definiendo y restringiendo el alcance de los usuarios. 1.0 Obligatorio Tabla 5.8. Requerimiento “Perfiles de Usuario” Fuente: Elaboración Propia

Una vez definidos los requerimientos, se debe describir qué es lo que es sistema debe hacer. En lo que sigue se presenta la versión inicial del Modelo de Casos de Uso. 24

5.5.2. MODELO INICIAL DE CASOS DE USO Según Kruchten (2003), este documento permite definir el funcionamiento y satisfacer los requerimientos de sistema a desarrollar. La tabla 5.9 muestra los actores que interactúan con la aplicación y su respectiva descripción. ACTOR DESCRIPCIÓN Administrador Encargado de la administración de la aplicación específicamente en lo que concierne a la configuración, activación, control y seguimiento de los planes de contingencia, así como también del análisis de los reportes originados de los planes ejecutados. Personal Son las personas que integran todo el personal de confianza y operativo de la C.A. Metro de Caracas, facultado para la utilización del sistema y que podría recurrir a el para realizar el reporte de asistencia de una contingencia, repasar el área de trabajo al que fue asignado, actualizar ciertos datos personales (números telefónicos, dirección, etc.) y revisar su participación en contingencias pasadas. Tabla 5.9. Usuarios de SISCON Fuente: Elaboración Propia Los casos de uso en los que actúan cada uno de estos actores se presentan en la tabla 5.10. ACTOR

CASO DE USO Activar Contingencia Consultar Contingencia en Proceso Configurar Características de las Contingencias Administrador Administrar Usuarios Administrar Personal Administrar Cuerpos de Seguridad Consultar Reportes de Contingencias Anteriores Reportar Asistencia Consultar Reportes de Asistencia de Contingencias Anteriores Personal Modificar Datos de Usuario Modificar Datos Personales Consultar Asignaciones de Trabajo Tabla 5.10. Casos de Uso de SISCON Fuente: Elaboración Propia

25

La tabla 5.11 muestra una pequeña descripción de estos casos de uso. El modelo inicial de casos de uso de la aplicación SISCON se muestra en la figura 5.2. CASO DE USO Activar Contingencia Consultar Contingencia en Proceso Configurar Características de las Contingencias Administrar Usuarios

Administrar Personal

Administrar Cuerpos de Seguridad Consultar Reportes de Contingencias Anteriores Reportar Asistencia Consultar Reportes de Asistencia de Contingencias Anteriores Modificar Datos de Usuario Modificar Datos Personales Consultar Asignaciones de Trabajo

DESCRIPCIÓN Se refiere a la introducción de las características de la contingencia presentada, para ejecutar la activación en el sistema de la misma. Concierne al control de la contingencia, en específico, el chequeo de la asistencia del personal, el manejo de las asignaciones de trabajo y las áreas de trabajo, el manejo de la logística y los insumos, etcétera. El administrador puede introducir, identificar y editar características como los orígenes y escenarios de las contingencias, así como definir los nombres de los grupos del personal de la empresa y las áreas de trabajo. Con este caso de uso se le permite al administrador ingresar nuevos usuarios y asociarlos con un integrante del personal de la empresa (obligatorio), también puede definir el perfil de cada uno y realizar el cambio de contraseña. Se podrá consultar con búsquedas específicas, los datos personales de cualquier integrante del personal de la C.A. Metro de Caracas, además de servir para asignar las labores y las áreas de trabajo a cada integrante según los escenarios propuestos para las contingencias. El sistema permitirá introducir y consultar los datos de los cuerpos de seguridad que asisten y apoyan a la empresa durante una contingencia. Se refiere a la consulta de todos los reportes generados luego de la conclusión de una contingencia, como por ejemplo, la asistencia del personal, las observaciones del plan, el desarrollo de los planes de logísticas y seguridad, entre otros. Un usuario con perfil “personal”, podrá acceder al sistema a través de intranet en el área de trabajo al que fue asignado en la activación de una contingencia, para reportar su asistencia en el sitio. Un usuario con perfil “personal”, podrá revisar su participación en contingencias ejecutadas, así como también consultar las áreas de trabajo al que fue asignado en esas oportunidades. Un usuario con perfil “personal” podrá modificar su contraseña. si lo desea. Un usuario con perfil “personal” podrá actualizar ciertos datos como números telefónicos, correo electrónico personal, dirección, etcétera. Un usuario con perfil “personal”, podrá consultar las asignaciones y las áreas de trabajo que le han sido predefinidas según los escenarios posibles de contingencias futuras. Tabla 5.11. Descripción de los casos de uso Fuente: Elaboración Propia 26

Figura 5.2. Modelo Inicial de Casos de Uso: SISCON Fuente: Elaboración Propia

27

Algunos requerimientos exigidos a la aplicación no pueden ser representados mediante los casos de uso, es por ello que debe elaborarse la Lista de Requerimientos Complementarios. Seguidamente se presenta dicha lista. 5.5.3. REQUERIMIENTOS COMPLEMENTARIOS Según Leffingwell (2000), adicional a los requerimientos funcionales, muchos sistemas también requieren de la definición de un conjunto de requerimientos complementarios enfocada en la especificación de atributos adicionales del sistema, tales como usabilidad, mantenibilidad, confiabilidad y rendimiento. La tabla 5.12 muestra los requerimientos no funcionales de la aplicación a desarrollar. REQUERIMIENTO DESCRIPCIÓN Facilidad de Uso El uso de la aplicación debe ser sencillo para los usuarios. Debe presentar una interfaz amigable e intuitiva. Tiempos de Es de suma importancia que la notificación de la emergencia utilizando Respuesta los mensajes de texto no se demore más de 30 segundos, de igual forma se requiere que los reportes de asistencia del personal se actualicen fielmente (con la fecha y hora del servidor) cuando un usuario utilice el sistema para llevar a cabo esta labor. Portabilidad A pesar de que es un requisito que la aplicación sea desarrollada bajo software libre, es importante que se pueda instalar en servidores con sistemas operativos comerciales como Windows. Modificabilidad La inclusión de nuevas funcionalidades e incluso la modificación en la estructura de las Bases de Datos, debe ser una tarea sencilla. Tabla 5.12. Requerimientos complementarios Fuente: Elaboración Propia La tabla 5.13 muestra la descripción de uno de los requerimientos, el resto de las descripciones se encuentra en el Apéndice V – Requerimientos Complementarios. Para cuantificar la relevancia de cada requerimiento se utilizó una escala de 1 a 3, en donde 1 es deseable, 2 es muy deseable y 3 es imprescindible.

28

IDENTIFICADOR C.1 Facilidad de Uso NOMBRE El uso de la aplicación debe ser sencillo para los usuarios. Debe presentar DESCRIPCIÓN una interfaz amigable e intuitiva. Usabilidad CATEGORÍA PONDERACIÓN 3 Tabla 5.13. Requerimiento Complementario: Facilidad de Uso Fuente: Elaboración Propia También es importante definir el diseño de la interfaz de la aplicación. La siguiente sección presenta las decisiones de diseño tomadas. 5.6. PLAN CREATIVO Esta sección tiene por finalidad proveer toda la información referente al diseño de las interfaces de la aplicación. Se toman en cuenta aspectos como atributos de la interfaz (colores, formas y botones), idioma requerido y distribución de los elementos. 5.6.1. DISTRIBUCIÓN DE LA INTERFAZ Las ventanas de la aplicación estarán divididas en: Ventana Principal, Ventana de Opciones de la Aplicación, Ventanas de Opciones de Búsqueda, Ventana de Listado de Datos y Ventana de Introducción de Datos. Para cada una de estas ventanas, se muestra entonces su respectivo diseño en las figuras 5.3, 5.4, 5.5, 5.6 y 5.7. La explicación de la distribución de la interfaz y la descripción del diseño de las ventanas se encuentra en el Apéndice VIII – Plan Creativo.

29

Figura 5.3. Ventana Principal

Figura 5.4. Ventana de Opciones de la

Fuente: Elaboración Propia

Aplicación Fuente: Elaboración Propia

Figura 5.5. Ventana de Opciones de

Figura 5.6. Ventana de Listado de Datos

Búsqueda

Fuente: Elaboración Propia

Fuente: Elaboración Propia

Figura 5.7. Ventana de Listado de Datos Fuente: Elaboración Propia

30

5.6.2. ATRIBUTOS DE LA INTERFAZ Los principales aspectos a considerar en este punto son el color, el diseño de los botones y las fuentes utilizadas en la interfaz del sistema.

Figura 5.8. Color de las Interfaces

Figura 5.9. Diseño de los Botones

Fuente: Elaboración Propia

Fuente: Elaboración Propia

En el siguiente capítulo se presenta la Fase de Elaboración, en la cual se planifican las actividades necesarias y los recursos requeridos, además se especifican el diseño de la arquitectura y sus características.

31

CAPITULO VI. FASE DE ELABORACIÓN En el presente capítulo se presentarán los artefactos elaborados durante la Fase de Elaboración, establecidos por RUP. Como se dijo anteriormente, esta fase tiene como meta principal la especificación de las características y el diseño de la arquitectura del sistema a desarrollar. A continuación se presenta la lista revisada de riesgos. 6.1. LISTA REVISADA DE RIESGOS A medida que avanza el desarrollo del proyecto algunos de los riesgos planteados originalmente (la lista de riesgos se encuentra en el Apéndice IV – Lista de Riesgos) tienden a disminuir su impacto y magnitud, mientras que algunos otros pueden aumentar. En lo que sigue se presenta los riesgos que aumentaron o disminuyeron. 6.1.1. RIESGOS QUE AUMENTAN Recursos limitados e inestables: los recursos tanto económicos como tecnológicos que ofreció la empresa al principio del proyecto se retrasaron, sobretodo el de la contratación de una Empresa Integradora de Telecomunicaciones, que era necesario para cumplir con uno de los requerimientos funcionales del sistema más importantes como lo es el envío de mensajes de texto. También hay que agregar que a pesar de que se logró la conexión del lenguaje PHP con el nuevo Sistema de Gestión de Base de Datos (Informix 9) que adquirió la empresa, no se planteó con exactitud el proyecto para actualizar dicha base de datos con el sistema SAP Recursos Humanos, el cual tiene la información oficial de todo el personal de la C.A. Metro de Caracas. Requerimientos pocos claros: al principio se tenía planteado que el alcance del sistema lograra abarcar todas las funcionalidades necesarias para la gestión de una contingencia bajo los lineamientos del Plan de Operaciones Especiales Arcoiris, el cual es activado por la empresa cuando ocurren paros laborales. Sin embargo, a medida que avanza el proyecto, se fueron incluyendo nuevos requerimientos para que el sistema también sea útil 32

bajo otros escenarios como: incendios, inundaciones, paro del servicio por mantenimiento en la vía férrea, etc. Dichos requerimientos no fueron parte del estudio inicial del proyecto en la fase de concepción. Estimaciones de tiempo no realistas: los riesgos que aumentan, como los requerimientos pocos claros y los recursos limitados e inestables, ocasionan que los tiempos propuestos para la finalización de las fases del proyecto, sean afectados negativamente. 6.1.2. RIESGOS QUE DISMINUYEN Tecnología nueva o poco probada: el aprendizaje de los desarrolladores con las nuevas tecnologías de software libre ha utilizar en este proyecto y a futuro por la misma empresa, fue rápido, debido a que con anterioridad se había estipulado la realización de un curso exclusivo del lenguaje PHP para algunas de las personas involucradas con el proyecto. Dicho curso fue llevado a cabo en una semana con resultados bastante favorables. Falta de información sobre los planes de contingencia a implementar: a pesar de que no se sabía con exactitud para qué tipo de escenarios debían ser enfocadas las funcionalidades del sistema, por lo menos sí se tenían claros algunos de los procedimientos que la empresa ejecutaba cuando se presentaban estos escenarios. Disponibilidad de tiempo de los usuarios y administradores: durante las primeras semanas del proyecto, se contó ampliamente con la disposición y el apoyo del usuario principal del sistema, el cual es el Sr. Henry Abdelnour, coordinador principal de las últimas contingencias ejecutadas en la empresa. Por lo tanto, se lograron definir muchas de las características esenciales para que el sistema logre seguir los lineamentos y procedimientos de trabajo durante la ejecución de un Plan de Contingencia. Ya descrita la lista revisada de riesgos, el siguiente paso fue definir la arquitectura de software a desarrollar. La sección siguiente muestra una breve descripción sobre la definición y principales aspectos de la Arquitectura de Software.

33

6.2. ARQUITECTURA DE SOFTWARE Según Probasco (2000) en el Rational Unified Process, la arquitectura de un sistema de software es la organización o estructura de los componentes significativos del sistema que interactúan a través de interfaces, con componentes integrados por componentes e interfaces sucesivamente más pequeños. RUP provee una forma metódica y sistemática para diseñar, desarrollar y validar una arquitectura de software. Ésta es la esencia del Análisis y Diseño en RUP: definir una arquitectura candidata, refinar la arquitectura, analizar su comportamiento y diseñar componentes del sistema. Por su parte Kruchten (1999) expone que la arquitectura del software se ocupa del diseño y de la puesta en práctica de la estructura a alto nivel del software. Esta es el resultado del ensamblaje de cierto número de elementos arquitecturales, para satisfacer los principales requerimientos de funcionalidad y funcionamiento del sistema, así como otros requerimientos no funcionales tales como confiabilidad, escalabilidad, portabilidad y disponibilidad. Quatrani (1998) dice que establecer una base arquitectural consistente es absolutamente esencial para el éxito de un proyecto orientado a objetos. El desarrollo de la arquitectura de un sistema es un asunto bastante complicado y además, es desarrollada iterativamente en la Fase de Elaboración del proceso. Según Kruchten (1999), una vista arquitectónica es una descripción simplificada, una abstracción, del sistema desde una perspectiva o punto de vista particular, cubriendo aspectos particulares y omitiendo aspectos que no son relevantes para esa perspectiva. La arquitectura escogida para este desarrollo es la de 4 + 1 vistas, la cual según explica Kruchten (1999), usa un modelo que organiza la descripción de la arquitectura de un software usando cinco vistas concurrentes, cada una de las cuales está dirigida a un conjunto específico de conceptos. Los arquitectos exponen sus decisiones de diseño en cuatro vistas y usan la quinta vista para ilustrar y validar dichas decisiones. Estas vistas según Kruchten (1999) son: Vista Lógica, Vista de Procesos, Vista de Implementación y Vista de Implantación, y la quinta que es la Vista de Casos de Uso. Además Booch (1999), expone que también se pueden utilizar vistas adicionales como la Vista de Datos. La descripción de cada una de estas vistas y los respectivos artefactos correspondientes a este proyecto se presentará en las siguientes secciones. 34

6.2.1. VISTA DE CASOS DE USO Kruchten (1999) plantea que la vista de casos de uso es en cierto sentido una abstracción de los requerimientos más importantes. Para cada caso de uso, se describe la secuencia de interacciones entre los objetos y entre los procesos. Por otra parte, Kruchten (1999) expone que esta vista es redundante con respecto a las otras (por eso el “+1”), pero juega dos roles críticos, a saber: Actúa como un manejador para ayudar a los diseñadores a descubrir elementos de la arquitectura durante el diseño de la misma. Valida e ilustra el diseño de la arquitectura en papel; así como también permite determinar el punto de partida de las pruebas del prototipo arquitectural. En la figura 6.1 se presenta el modelo refinado de Casos de Uso de la Aplicación Web SISCON. La descripción de los casos de uso del sistema muestra detalladamente las interacciones entre el actor y el sistema. En esta sección se presentará únicamente la descripción de uno de los casos de uso del sistema. Las descripciones de los demás casos de uso se encuentran en el Apéndice IX – Documento de Arquitectura del Software. El caso de uso a describir es “Activar Contingencia”, ya que es uno de los más representativos y que inicia la ejecución de todos los procedimientos de trabajo que la empresa activa a la hora de una emergencia

35

Figura 6.1. Modelo Refinado de Casos de Uso: SISCON Fuente: Elaboración Propia

36

El formato usado para esta descripción es el propuesto por Larman (1999) y esta presentado en la tabla 6.1. Autor: Argenis Rodríguez CASO DE USO Actor(es) Tipo Descripción

Fecha: Octubre 2005

Activar Contingencia

Administrador Primario - Esencial Configura las características de la contingencia presentada e inicia el proceso de información a todo el personal requerido para asistir a la operación especial. Referencia Requerimiento Funcional 4: Activación de un Plan de Contingencia Requerimiento Funcional 4.1: Configuración de la activación de un Plan de Contingencia Requerimiento Funcional 4.2: Configuración del personal participante Precondición El actor es un usuario válido Curso Normal de los Eventos Acciones del Actor Respuesta del Sistema 1. El caso de uso se inicia cuando el actor hace clic en el enlace “Activar Contingencia. 2. Muestra un formulario para ingresar el nombre, el origen, el escenario y la descripción de la contingencia a activar. 3. Presenta los botones de acceso para configurar o editar otras opciones de la activación como: activación de grupos, activación de personal, ingresar un plan de seguridad o asignar coordinadores de la contingencia. 4. Para cada uno de los campos presentados en el formulario, llena o selecciona los datos correspondientes. 5. Presiona el botón “ACTIVAR”.

37

6. Presenta una nueva ventana con los datos de la contingencia ingresados y con los botones de acceso para consultar las opciones de la

activación que estaban preconfiguradas o modificadas por el usuario según haya sido el caso. 7. Habilita nuevamente el botón “ACTIVAR” para que el usuario confirme la activación de la contingencia. 8. Presiona nuevamente el botón “ACTIVAR” para confirmar la activación de la contingencia. 9. El caso de uso finaliza cuando la aplicación muestra una ventana con los datos ingresados de la contingencia y el resultado exitoso de la activación del plan. Curso Alterno En el paso 4, el usuario puede decidir editar algunas de las opciones preconfiguradas de la activación, como por ejemplo: la activación de grupos, la activación de personal, ingresar un plan de seguridad, consultar un plan de seguridad ingresado o asignar los coordinadores de la contingencia. Para cada una de estas opciones, en su ventana correspondiente el usuario puede hacer clic en el botón “GUARDAR” o en el caso de los planes de seguridad en el botón “INGRESAR”, de modo tal que el usuario pueda regresar a la página inicial y mantener todas las modificaciones hechas por el al momento de la activación. En el paso 8, el usuario puede cancelar la activación y eliminar todas las configuraciones hechas si presiona el botón “CANCELAR”. Postcondiciones: • La contingencia activada se encuentra en la lista de contingencias en proceso. Casos de Uso Relacionados: • Consultar Contingencia en Proceso. • Consultar Reportes de Contingencias Anteriores. Tabla 6.1. Caso de Uso: Activar Contingencia Fuente: Elaboración Propia En lo que sigue se presenta todos los aspectos relacionados a otra de las vistas que propone el Modelo de 4 + 1 vistas, la vista Lógica.

38

6.2.2. LA VISTA LÓGICA Según Kruchten (1999), la vista lógica principalmente soporta los requerimientos funcionales, los servicios que el sistema debería proveer a sus usuarios finales. Los diseñadores descomponen el sistema en un conjunto de abstracciones claves, tomadas del dominio del problema. Estas abstracciones son objetos o clases de objetos que utilizan los principios de abstracción, encapsulación y herencia. En esta vista se presenta el Diagrama de Clases, la Realización de los Casos de Uso y el Modelo Conceptual propuesto por Larman (1999). La descripción de cada uno de estos artefactos se presentará en la sección siguiente. 6.2.2.1. REALIZACIÓN DE LOS CASOS DE USO Una vez descritos los casos de uso es conveniente determinar las relaciones e interacciones entre cada uno de los componentes de la aplicación a desarrollar. Para ello UML ofrece los diagramas de interacción que explican gráficamente cómo los objetos interactúan a través de mensajes para realizar los casos de uso (Larman, 1999). Larman (1999) también expone que UML define dos tipos de estos diagramas; ambos sirven para expresar interacciones semejantes o idénticas de mensaje. Estos diagramas son los diagramas de colaboración y los diagramas de secuencia, este último expresa las mismas interacciones entre los objetos del sistema, pero de formas un poco diferentes. Por lo tanto, no se hace necesario hacer uso de los dos tipos de diagramas simultáneamente. Queda entonces decidir cuál de estos diagramas expresa estas interacciones de mejor forma. Por otra parte, según Jacobson et al. (2000), en la fase de diseño es más conveniente representar las interacciones y pase de mensajes entre objetos por medio de los diagramas de secuencia, ya que se centran en encontrar las secuencias de interacciones detalladas y ordenadas en el tiempo. Por lo expuesto anteriormente se decide expresar los diagramas de interacción requeridos en la vista de casos de uso, en términos de diagramas de secuencia. La figura 6.2 muestra el diagrama de secuencia que corresponde al caso de uso “Activar Contingencia”. El resto de los diagramas de secuencia diseñados para la aplicación se presentan en el Apéndice IX – Documento de Arquitectura del Software. 39

Figura 6.2. Diagrama de Secuencia: “Activar Contingencia” Fuente: Elaboración Propia

40

6.2.2.2 MODELO CONCEPTUAL Según Larman (1999) un modelo conceptual explica (a sus creadores) los conceptos significativos en un dominio del problema; es el artefacto más importante a crear durante el análisis orientado a objetos (los caso de uso son un artefacto importante del análisis de requerimientos, pero realmente no están orientados a objetos). Larman (1999) expone que un modelo conceptual ofrece la ventaja de subrayar fuertemente una concentración en los conceptos del dominio, no en las entidades de software. El Modelo Conceptual puede mostrarnos: Conceptos Asociaciones entre conceptos Atributos de conceptos La figura 6.3 muestra el Modelo Conceptual donde se presentan los conceptos asociados al dominio del problema.

Figura 6.3. Modelo Conceptual Fuente: Elaboración Propia 41

La tabla 6.2 presenta una pequeña descripción de cada uno de los conceptos del Modelo Conceptual. CONCEPTO Administrador Área de Trabajo Comida Coordinador de Contingencia Cuerpo de Seguridad Escenario Estación Gerencia Grupo Insumo Logística Observación Origen Perfil

Personal Plan Plan de Seguridad Tipo de

DESCRIPCIÓN Usuario que tiene acceso y control total del sistema, incluida la administración de cualquier contingencia en proceso. Sitio o lugar de la empresa para la cual se asignan labores específicas a un grupo determinado de personas. Orden de distribución de algún alimento a los trabajadores que asisten a la operación del Plan de Contingencia. Usuario que tiene acceso en el sistema para llevar a cabo la administración y el control de los planes de contingencia que le han sido asignados. Organismo del estado que apoya a la C.A. Metro de Caracas en un Plan de Contingencia, en donde su participación queda determinada dentro de un Plan de Seguridad. Situación que se presenta dentro o fuera de la empresa que origina que se requiera la activación de un Plan de Contingencia. Áreas destinadas por la empresa para el acceso de pasajeros a los ándenes del Metro de Caracas. Unidad de la empresa determinada para llevar a cabo diferentes procesos de la organización. Definición por parte del Administrador de un conjunto de trabajadores de la empresa con una característica o fin en común. Orden de distribución de algún elemento, herramienta, material o transporte que se requiera durante la ejecución de un Plan de Contingencia. Agrupación de todas las labores que se requieran para el mantenimiento de las asignaciones principales en la ejecución de un Plan de Contingencia, por ejemplo: las órdenes de repartición de comida o de insumo. Suceso o característica que valga la pena resaltar en un área de trabajo o en general dentro de un Plan de Contingencia. Característica general que agrupa a ciertos escenarios por la relación que tienen los sucesos que ellos definen y que ocasionan la activación de un Plan de Contingencia. Rasgo que define a un usuario y le permite al sistema determinar el tipo de control y acceso que este tiene en la aplicación. Los perfiles manejados son: Administrador y Personal, pero también se puede presentar provisionalmente a un usuario el perfil Coordinador para que controle un Plan de Contingencia que le haya sido asignado como si fuera Administrador. Se refiere a todos los trabajadores de cualquier tipo que laboran para la C.A. Metro de Caracas. Agrupación de asignaciones y de labores específicas para el mantenimiento o la recuperación de la operación normal de la C.A. Metro de Caracas, cuando se presentan escenarios que ocasionan un estado de contingencia. Asignación específica que se designa a un cuerpo de seguridad del estado para apoyar a la empresa durante la ejecución de un Plan de Contingencia. Definición de una clasificación específica para un grupo de observaciones de 42

Observación Tramo Ubicación Usuario

un Plan de Contingencia. Sector que agrupa un conjunto de estaciones dentro de una línea del Metro de Caracas. Lugar definido en donde se encuentran físicamente las áreas de trabajo, gerencias o demás unidades de la empresa. Persona registrada por el sistema y que tiene un perfil determinado que le permite consultar o ejecutar diferentes funcionalidades de la aplicación. Tabla 6.2. Descripción de Conceptos del Modelo Conceptual Fuente: Elaboración Propia

Una vez definidos y establecidos los conceptos del dominio del problema, se puede construir el diagrama de clases. Seguidamente se presenta el Diagrama de Clases de SISCON. 6.2.2.3 DIAGRAMA DE CLASES Según Kruchten (1995) un diagrama de clases muestra un conjunto de clases y sus relaciones lógicas, uso de las asociaciones, composición, herencia, entre otros. Por su parte Larman (1999) expone que el diagrama de clases describe gráficamente las especificaciones de software en una aplicación. Normalmente, contiene la siguiente información: Clases, asociaciones y atributos Métodos Interfaces, con sus operaciones y constantes Información sobre los tipos de los atributos Dependencias Además Larman (1999) explica que a diferencia del modelo conceptual, un diagrama de este tipo contiene las definiciones de las entidades del software en vez de conceptos del mundo real. La figura 6.4 muestra el diagrama de clases diseñado.

43

Figura 6.4. Diagrama de Clases Fuente: Elaboración Propia 44

En cuanto a los conceptos del mundo real, muchos de ellos requieren de su almacenamiento permanente. De ahí la importancia de las Bases de Datos. Para la construcción de estas es necesaria la elaboración de los Diagramas Entidad – Relación. La siguiente sección presenta la descripción de los diagramas realizados para el desarrollo de este proyecto en la Vista de Datos. 6.2.3. VISTA DE DATOS Según Navathe et al. (1997), el modelo Entidad – Relación describe los datos como entidades, vínculos y atributos. La entidad es el objeto básico de ER y representa a un objeto del mundo real que tiene existencia independiente, bien sea físico o conceptual. Los atributos son las propiedades particulares que describen a las entidades. Finalmente estas entidades con sus diferentes atributos tienen asociaciones entre sí las cuales son representadas a través de relaciones. Según Navathe et al. (1997), el Diagrama Entidad – Relación conocido como Diagrama ER, es una notación gráfica para representar el esquema lógico de una base de datos relacional. A pesar de que SISCON depende de la alimentación de datos provenientes de SAP Recursos Humanos, se decidió crear otra base de datos no sólo para reguardar la información del personal de la empresa obtenida en la última actualización, sino también para hacer el repositorio de datos referentes a los nuevos planes de contingencia que se vayan ejecutando y para mantener la configuración de las asignaciones de trabajo dependiendo por supuesto de los grupos de personal y los escenarios propuestos. Sin embargo, también fue necesario mantener datos que son redundantes debido a que se pueden obtener de otras bases de datos de la empresa como por ejemplo: información de las gerencias y demás unidades administrativas, datos de las estaciones y líneas del metro, ubicaciones físicas, datos de los cuerpos de seguridad del estado, etc. La decisión de mantener esta redundancia de datos es porque esta aplicación es un sistema crítico para la empresa durante el desarrollo de una contingencia, la cual también se puede presentar por una falla en los servidores centrales. Por lo tanto, la aplicación debe mantener y guardar algunos datos esenciales (por lo menos localmente) que le permitan operar a pesar de estas condiciones. 45

El diccionario de Datos de la Base de Datos se encuentra en la Vista de Datos del Apéndice IX – Documento de Arquitectura del Software. Para Navathe (1997), el Diccionario de Datos contiene la descripción de la Base de Datos, se encuentra conformado por la identificación de todas las tablas y sus atributos, además contiene la especificación del tipo de datos de los atributos e identifica cuáles son los campos claves. Las figuras 6.5 muestra el diagrama Entidad – Relación de la aplicación.

Figura 6.5. Modelo Entidad – Relación de SISCON Fuente: Elaboración Propia Con esto se presentan todos los artefactos requeridos en la Vista de Datos, la siguiente vista del Modelo de las 4 + 1 Vistas Arquitectónicas, es la de Procesos. La siguiente sección muestra el detalle de la misma.

46

6.2.4. VISTA DE PROCESOS Para Kruchten (1995) la vista de procesos toma en cuenta algunos requerimientos no funcionales, tales como funcionamiento y disponibilidad del sistema. Esta maneja la concurrencia y distribución, integridad del sistema, y tolerancia a fallas. También especifica cuál hilo de control ejecuta cada operación de cada clase identificada en la vista lógica. Booch (1999), sugiere que en algunos proyectos no es necesario establecer las cinco vistas y además propone ciertas recomendaciones para poder establecer cuáles vistas se deben especificar en el diseño de la arquitectura. La aplicación a desarrollar es una herramienta instalada en un servidor central que accede a otro servidor en el cual se tiene la Base de Datos que alimenta a dicha aplicación. Los clientes a su vez acceden “simultáneamente” al sistema a través de un navegador de páginas web y la concurrencia en este caso es manejada por el DBMS instalado en uno de los servidores y no por la aplicación en sí. Por lo cual la herramienta a desarrollar no posee más de un proceso. Por esta razón, y siguiendo los lineamientos expuestos por Booch en cuanto a la vista de procesos, la misma no será tomada en cuenta en la descripción de la arquitectura, ya que no representa ningún aporte para el desarrollo. Para continuar con la descripción de la arquitectura, en lo que sigue se presentará la Vista Implementación. 6.2.5. VISTA DE IMPLEMENTACIÓN Según Kruchten (1995) la vista de implementación se enfoca en la organización de los módulos reales del software en el ambiente de desarrollo del mismo. El software es empaquetado en pequeños pedazos (librerías o subsistemas) que pueden ser desarrollados por uno o más desarrolladores. Los subsistemas son organizados en jerarquía de capas, en donde cada capa provee una interfaz estrecha y bien definida para las capas superiores. En esta vista es recomendable definir la arquitectura del software y la distribución de los distintos elementos en las distintas capas que conforman la arquitectura.

47

La arquitectura seleccionada para el desarrollo de este proyecto es la de Cliente/Servidor en su forma avanzada de tres capas que son: la Capa de Presentación, la Capa Lógica y la Capa de Datos. Stevens (1996), propone que existen tres razones primordiales para la selección de las arquitecturas Cliente/Servidor de tres capas, a saber: Las aplicaciones pueden ser particionadas de una manera que se ajuste a las necesidades computacionales de la organización. En vista de que la mayor parte de la lógica está contenida en el servidor de aplicaciones, realzar cambios globales, o personalizar procesos para usuarios individuales, es relativamente fácil. Al tener la lógica separada de la interfaz del usuario, es sumamente fácil cambiar uno, o ambos, sin generar mayores esfuerzos en mantenimiento. La figura 6.6 muestra el modelo de arquitectura de tres capas

Figura 6.6. Arquitectura de tres Capas Fuente: Elaboración Propia

48

La tabla 6.3 muestra la distribución de los componentes de la aplicación entre las tres capas que componen la arquitectura y las diferentes interfaces de interacción entre las mismas. Capa de Presentación Mediador con Interfaz Páginas Web Formularios Enlaces Interfaz en general

Capa de Lógica Capa de Datos Mediador con Base de Datos Clases Plan Configuración de la Origen Base de Datos Escenario Configuración del estilo Personal Web (XML) Grupo Configuración de la Área de Trabajo seguridad del sistema Gerencia Ubicación Cuerpo de Seguridad Plan de Seguridad Efectivo Insumo Comida Asignación de Personal Observación Tipo de Observación Asistencia de Personal Usuario Perfil Cargo Movimiento de Personal

Tabla 6.3. Distribución de Clases en las diferentes capas Fuente: Elaboración Propia En la siguiente sección se presenta la descripción de la vista de Implantación. 6.2.6. VISTA DE IMPLANTACIÓN Para Kruchten (1995) la vista de Implantación toma en cuenta los requerimientos no funcionales del sistema tales como disponibilidad del sistema, confiabilidad (tolerancia de fallas), eficiencia (productividad) y escalabilidad.

49

Como el software se ejecuta en un servidor central y múltiples clientes tendrán acceso a él es muy importante que el sistema sea altamente confiable y como se ha dicho anteriormente, no puede presentar fallas a la hora de una emergencia porque justamente su función es apoyar a la empresa durante la contingencia que busca normalizar la operación. Igualmente se destacan otros aspectos como la eficiencia y la rapidez, dado que otro de los objetivos del proyecto es aumentar y agilizar el flujo de información entre las personas involucradas en la ejecución de un Plan de Contingencia. Se recomienda que los equipos involucrados presenten las siguientes características: •

Servidores El sistema y una base de datos de respaldo se encontrarán en un servidor y la base de

datos principal se encontrará en otro servidor, por lo tanto no solo se recomienda un alto desempeño de procesamiento al servidor que contendrá el sistema y una suficiente capacidad de almacenamiento al que tendrá a la base de datos, sino también que cuenten con una rápida conexión en función de mantener los datos en línea el mayor tiempo posible y por supuesto para poder manejar la gran cantidad de conexiones simultáneas que pueden surgir.

Figura 6.7. Modelo de Red de SISCON Fuente: Elaboración Propia 50

Los requerimientos mínimos de hardware serían: Memoria RAM de 512 MB 2 GB de espacio libre en disco duro (para el almacenamiento de la data) Procesador Pentium IV de 2.2 GHz En cuanto al software, la empresa ya tiene instalado en sus servidores centrales el Sistema de Gestión de Base de Datos Informix 9 y para la Base de Datos de respaldo se requiere MySQL Server 4.1. Todavía la empresa tiene en estudio (dentro del Proyecto de Utilización de Software Libre) el contenedor de páginas Web a utilizar, por los momentos se han hecho pruebas bastante satisfactorias con Apache HTTP Server el cual está disponible para servidores con sistemas Windows y Linux. •

Cliente Como la aplicación y la base de datos están instaladas en los servidores centrales, la

máquina del cliente no requiere de un software o un hardware especial, solo debe poseer un navegador de páginas Web el cual ha estado disponible en los sistemas Windows y Linux en los últimos años. Sin embargo, se requiere en algunos casos que estos navegadores tengan instalado y habilitado la ejecución de código JavaScript y de un interpretador de formularios y de archivos de estilos Web en formato XML. En resumen los requisitos mínimos de software para la máquina cliente son: Windows 98 o XP. Internet Explorer 5.0 o superior. En cuanto al hardware se requiere lo siguiente: Procesador Pentium III de 500 MHz Memoria RAM de 128 MB Con esta vista culmina la Fase de Elaboración. El siguiente capítulo presenta los detalles de la Fase de Construcción. 51

CAPITULO VII. FASE DE CONSTRUCCIÓN Kruchten (1995) expone que la Fase de Construcción, tal como su nombre lo indica, se refiere a la construcción del producto en sí hasta que el mismo está listo para ser entregado a los usuarios finales. Este capítulo muestra los detalles referentes a la Fase de Construcción de la aplicación. Se contempla la evaluación de las distintas soluciones de implementación propuestas, el Diseño y Funcionalidad de la interfaz de la herramienta, la Descripción de la versión actual de la misma y un breve resumen de los problemas encontrados durante este desarrollo. La principal restricción de este proyecto es que para cumplir uno de sus requerimientos más importantes depende de la contratación de los servicios de un Empresa Integradora de Telecomunicaciones. Aunque ya se realizaron varias reuniones con estas empresas, todavía no se ha logrado la autorización para llevar a cabo algunas pruebas concretas del funcionamiento del envío de los mensajes de texto con nuestro sistema. Sin embargo, se han estudiado algunas soluciones momentáneas para que se pueda ver como después de realizada la activación de un Plan de Contingencia algunas personas puedan ser informadas del hecho, por ejemplo, la utilización del servicio SMS Mail de la empresa Telemo, el cual permite el envío y recepción de correos electrónicos como mensajes de texto al celular, por lo tanto, ya que el sistema también ha desarrollado una interfaz para informar al personal mediante el envío de correos electrónicos, también se puede añadir el envío de correos electrónicos al celular, pero para lograr esto primero se necesita que las personas que deseen ser informados por el sistema envíen un correo electrónico con un mensaje de texto (SMS) utilizando el referido servicio, luego cuando el sistema realice la activación de un Plan de Contingencia enviará un correo electrónico a las direcciones “número de celular de la persona”@smsmail.com.ve. Por supuesto, los mensajes de texto que las personas envían utilizando SMS Mail tiene un costo y el sistema solo puede enviar un mensaje de vuelta por cada mensaje que reciban. A continuación se presenta la evaluación de la tecnología de telecomunicaciones desarrollada en el presente proyecto.

52

7.1. EVALUACIÓN DE LA TECNOLOGÍA DE TELECOMUNICACIONES Como se mencionó anteriormente la principal restricción de este proyecto es la necesidad de contratar los servicios de una Empresa Integradora de Telecomunicaciones para realizar las pruebas del envío de mensajes de texto (SMS). Tomando en cuenta esta restricción se procedió a realizar un estudio exhaustivo con diversas empresas del ramo, de modo tal que la C.A. Metro de Caracas no solo pueda contar de una vez con una versión del sistema que le permita tomar el control y la administración de un Plan de Contingencia, sino que también pueda contar con una propuesta detallada de los requisitos necesarios para llevar a cabo la conexión de la aplicación con un Servicio Web que realice este requerimiento tan importante, que a su vez sea el punto de partida para el inicio del trámite que tendrá como objetivo la contratación de los servicios con alguna de las empresas presentadas. Una vez finalizada la evaluación de los servicios ofrecidos por las Empresas Integradoras de Telecomunicaciones, se elaboraron tres (3) propuestas que fueron presentadas el día 27 de septiembre de 2005 en la Gerencia Corporativa de Protección Integral, en donde se sugirió la aprobación de la propuesta #2. Los detalles de los resultados de las reuniones con las empresas contactadas y la especificación de las propuestas se encuentran en el Apéndice X – Evaluación de la tecnología de telecomunicaciones 7.2. EVALUACIÓN DE LA TECNOLOGÍA DE DESARROLLO Uno de los objetivos del proyecto es la evaluación y propuesta de la mejor solución tecnológica (dentro del Proyecto de Utilización de Software Libre) para la implementación de la aplicación a desarrollar. Sin embargo, dicha evaluación sólo se enfocó en buscar un lenguaje de programación para aplicaciones Web dinámicas y por supuesto de software libre, que permitiera desarrollar rápidamente una versión inicial del sistema requerido y que pudiera ser implementado por la Gerencia de Sistemas de Información en el año 2006. Debido a la magnitud del proyecto, no se contaba con mucho tiempo para realizar una evaluación exhaustiva de los diferentes lenguajes de programación que existen en la actualidad, de hecho, la elección de PHP fue promovida principalmente porque algunos desarrolladores en la 53

Gerencia iban a tomar en poco tiempo un curso básico del lenguaje, y además se requería con prontitud tener un contacto inicial con software libre. Todavía la elección del lenguaje de programación a utilizar en futuros proyectos dentro de la gerencia esta siendo evaluada, un grupo de analistas de sistemas y de desarrolladores que trabajan dentro del Proyecto de Software Libre deberán concluir con dicha evaluación a mediados del 2006, pero podrán contar hasta ese entonces, con una evaluación inicial que se hizo en el presente proyecto y por supuesto con un sistema hecho en software libre, que además cubre una de las necesidades primordiales de la empresa como lo es la gestión de planes de contingencia. A continuación se presenta la lista de las herramientas propuestas en la tabla 7.1. El resumen completo de las propuestas y su justificación se encuentra en el Apéndice XI – Evaluación de la Tecnología de Desarrollo. Herramientas Propuestas Propuesta #1 Propuesta #2 SuSE Linux Red Hat Enterprise Linux Sistema Operativo PHP C# Lenguaje de Programación Eclipse SharpDevelop Entorno Integrado de Desarrollo Informix Informix Sistema de Gestión de Base de Datos Tabla 7.1. Evaluación de la Tecnología de Desarrollo: Herramientas Propuestas Fuente: Elaboración Propia Como se expuso anteriormente, la elección de PHP como Lenguaje de Programación fue promovida directamente por la Gerencia de Sistemas de Información, pero además en esta evaluación también influyó que el lenguaje C# todavía no está orientado al desarrollo de aplicaciones Web, aunque se tomo en cuenta para la propuesta #2 porque es un lenguaje libre basado en la plataforma .NET, la cual se ha venido utilizando en los últimos proyectos de la gerencia. Una vez descritas las propuestas y las razones de la escogencia de PHP, es relevante comentar las diferentes funcionalidades de la interfaz de la aplicación. A continuación se presenta esta descripción.

54

7.3. DISEÑO Y FUNCIONALIDAD DE LA INTERFAZ DE LA APLICACIÓN En esta sección se mostrarán las ventanas más representativas de la aplicación. La especificación del diseño y la funcionalidad de las interfaces, así como la presentación del resto de las ventanas se encuentra en el Apéndice XII – Diseño y Funcionalidad de la Interfaz de la Aplicación.

Figura 7.1. Ventana Inicial de la aplicación

Figura 7.2. Ventana Principal de la aplicación para el perfil “Administrador” 55

Figura 7.3. Ventana Principal de la aplicación para el perfil “Personal”

Figura 7.4. Ventana de “Activar Contingencia” para el perfil “Administrador”

56

Figura 7.5. Ventana de “Confirmar activación” para el perfil “Administrador” durante la activación de un Plan de Contingencia

Figura 7.6. Ventana de “Administración de Características de los Planes de Contingencia” para el perfil “Administrador” 57

Figura 7.7. Ventana de “Administración de Contingencia en Proceso” para el perfil “Administrador”

Figura 7.8. Ventana de “Administración de Personal” (Listado de Asignaciones) para el perfil “Administrador” 58

Figura 7.9. Ventana de “Reporte de Contingencia” para el perfil “Administrador” Una vez concluida la presentación del diseño y las funcionalidades de la interfaz de la aplicación, se considera importante comentar a continuación, algunas técnicas de seguridad utilizadas en el sistema. 7.4. DESCRIPCIÓN DE LAS TÉCNICAS DE SEGURIDAD UTILIZADAS EN EL SISTEMA Por razones de seguridad no se explicara con detalle las técnicas utilizadas, sin embargo, se muestran las características más importantes y las razones de la implementación de cada una. 1) Utilización de las funciones para el manejo de sesiones en PHP, las cuales permiten por cada conexión hecha en el sistema abrir un identificador único para el usuario, el cual es destruido cuando se cierra la sesión o esta permanece inactiva durante 10 minutos (este tiempo podrá ser modificado en futuras evaluaciones de seguridad). Entre las funciones más utilizadas se encuentran: session_start(), session_unset(), session_destroy() y session_id(). 2) Bloqueo de la navegación a través de la barra de direcciones, es decir, no se puede acceder directamente a las carpetas del sistema en donde se alojan las clases y las páginas web. Esta técnica fue configurada en el Servidor Web Apache. 3) La dirección web de la aplicación es única y no cambia durante la navegación a través del sistema. 59

4) Creación de un generador aleatorio de identificadores, de tal forma que cuando un usuario hace clic en un enlace o botón, el servidor no descarga directamente la página web, sino que lee el identificador y busca en una tabla creada en la sesión la dirección física de la página, para luego adjuntar el código html en la página actual. Como se menciono anteriormente, la sesión es destruida posteriormente, por lo tanto la tabla con los identificadores es eliminada y las direcciones de los enlaces que podrían quedar guardados en el historial del navegador serán inválidos. 5) Se utilizo el método de encriptación para leer y guardar las contraseñas de los usuarios, por lo tanto, las contraseñas que son leídas directamente de las tablas de la Base de Datos no corresponden a ningún usuario si el sistema no lo desencripta. 6) También se utilizó el método de encriptación de contraseñas en la conexión del sistema con la Base de Datos. 7.5. DESCRIPCIÓN DE LA VERSIÓN ACTUAL La versión actual de la aplicación se presenta como una versión inicial y oficial de un sistema que se requería desde hace varios años por la empresa, pero que tras varios desarrollos de prototipos que no se terminaron de implantar, por fin quedo listo uno que contiene todas las funcionalidades requeridas para llevar a cabo la gestión de un plan de contingencia. Lamentablemente, no se pudo llevar a cabo la contratación de los servicios de una Empresa Integradora de Telecomunicaciones, que nos hubiese permitido realizar la conexión con una interfaz que ejecutaría el envío de los mensajes de texto, lo cual es muy importante para comprobar si la utilización en conjunto de la tecnología informática y la de telecomunicaciones, lograría agilizar el proceso de activación, ejecución y desactivación de un Plan de Contingencia. Sin embargo, el estudio de la tecnología que permitió desarrollar algunas propuestas, quedo plasmado en el diseño lógico del sistema, de modo tal, que si se logra la contratación de la Empresa Integradora de Telecomunicaciones, solo sería necesario configurar la conexión de un Servicio Web en una nueva clase que se denominaría mediadorSms, la cual será referida en los métodos que llevan a cabo la activación, movimientos de personal, reportes de personal y desactivación.

60

También es importante destacar, que al finalizar la pasantía la empresa decidió continuar el desarrollo del sistema, tomando en cuenta que fue el primer contacto de la organización con un producto desarrollado en Software Libre, y además, ya se pueden efectuar pruebas de esta primera versión en los próximos Planes de Contingencia de la C.A. Metro de Caracas. 7.6. PROBLEMAS ENFRENTADOS El principal problema encontrado durante este desarrollo y que hasta el momento, como se dijo anteriormente, no se ha podido solucionar del todo, es la contratación de la Empresa Integradora de Telecomunicaciones que es la encargada de realizar el envío de los mensajes de texto (SMS). Todavía no se tiene claro si la empresa autorizará la contratación de estos servicios para este año, ya que actualmente la C.A. Metro de Caracas no ha incluido esta inversión dentro del presupuesto, aunque si ha valorado la importancia y la necesidad del sistema, por lo que probablemente durante la puesta en marcha de la Fase de Transición del Proyecto, se autorice por lo menos la contratación de un servicio de prueba que demuestre la gran utilidad que tendrá la aplicación si cuenta con este recurso. Otro inconveniente que afectó un poco los tiempos de programación fue la deserción de otro pasante de la universidad involucrado al principio del proyecto, que sumado al tiempo que requería el estudio inicial que tenía que hacerse para decidir el lenguaje de programación a utilizar, no permitió que el proyecto avanzara con rapidez cuando comenzó la Fase de Construcción. Sin embargo, afortunadamente durante la pasantía se involucraron algunos desarrolladores de la gerencia que habían tomado el curso básico del lenguaje PHP, lo que permitió que se avanzara bastante en lo que respecta al diseño creativo de las interfaces y las pruebas de conexión con la nueva versión de Informix que fue adquirida por la empresa a finales de Noviembre, la cual seguramente será el Sistema de Gestión de Base de Datos que utilice el sistema cuando se implante. De esta forma finaliza la Fase de Construcción y así el desarrollo del proyecto. A continuación se presentan las conclusiones y las recomendaciones que se derivan del proceso realizado. 61

CONCLUSIONES En este capítulo se presentan todos aquellos aspectos importantes y conclusiones que dejó el desarrollo de este proyecto. •

La C.A. Metro de Caracas, como empresa dedicada al transporte de grandes masas de personas, esta consciente de la responsabilidad de preservar la seguridad de sus usuarios y de los recursos humanos y materiales, así como garantizar la operatividad del sistema. Por lo tanto, la empresa dirige su atención al desarrollo de Planes de Contingencia para la red Metro y Metrobús.

•

El aporte fundamental de los Planes de Contingencia es la mitigación del impacto que generaría sobre la ciudad de Caracas cualquier evento o fenómeno que afecte al sistema Metro o viceversa, por lo que se considera que para la empresa es de gran importancia disponer de un sistema automatizado que le simplifique las tareas de planificación, gestión y control del personal operativo y de confianza, que además brinde el soporte informativo con el fin de trazar las mejores estrategias para prestar un mejor servicio al público usuario del sistema ferroviario y superficial en momentos de emergencia.

•

Rational Unified Process es una metodología muy completa que logra abarcar todos los aspectos del desarrollo de software.

•

Es importante evaluar muy bien las características del proyecto en desarrollo a fin de determinar cuáles artefactos de la metodología son realmente necesarios, así se evita la pérdida de tiempo en actividades que no dan ningún tipo de valor o aporte al desarrollo.

•

El Sistema de Activación, Control y Seguimiento de Planes de Contingencia se desarrolló para lograr la automatización de todos aquellos procesos que son críticos a la hora de una emergencia, por ejemplo: la comunicación rápida y efectiva del suceso, la administración confiable de todos los recursos humanos, entre otros.

62

•

La definición de la arquitectura del software es una actividad de suma importancia y se debe tomar el tiempo adecuado en el análisis de cuál arquitectura se adapta mejor a las características del producto a desarrollar.

•

Antes de escoger algún tipo de tecnología de implementación, resulta de vital importancia estudiar detalladamente las características de las tecnologías disponibles para luego ver cuál de estas se adapta mejor al producto a desarrollar y a las necesidades y requerimientos de la organización.

•

La arquitectura seleccionada para el desarrollo de este proyecto es la de Cliente/Servidor en su forma avanzada de tres capas.

•

La evaluación de la tecnología de telecomunicaciones permitió proponer ante una comisión de seguridad de la empresa la contratación de los servicios de una Empresa Integradora de Telecomunicaciones, la cual solo funcionaría como “puente” para la transmisión de mensajes entre el sistema y el personal requerido para la contingencia.

•

La evaluación de la tecnología de desarrollo se enfocó en buscar un lenguaje de programación para aplicaciones Web dinámicas y por supuesto de software libre, que permitiera desarrollar rápidamente una versión inicial del sistema requerido y que pudiera ser implementado por la Gerencia de Sistemas de Información en el año 2006.

•

El lenguaje de programación escogido en la evaluación de la tecnología de desarrollo fue PHP, el cual también había sido el sugerido directamente por la Gerencia de Sistemas de Información.

•

Un estudio muy importante que fue llevado a cabo en el presente proyecto y que era altamente requerido por la organización fue las técnicas de seguridad a utilizar en el sistema. Era fundamental mantener altos niveles de seguridad tomando en cuenta que la aplicación maneja información personal y en ciertos puntos confidencial de los trabajadores y de los planes que ejecuta la empresa. 63

•

La versión actual de la aplicación se presenta como una versión inicial y oficial de un sistema que se requería desde hace varios años por la empresa, pero que tras varios desarrollos de prototipos que no se terminaron de implantar, por fin quedo listo uno que contiene todas las funcionalidades requeridas para llevar a cabo la gestión de un plan de contingencia.

•

Aunque durante el transcurso de la pasantía no se logró la contratación formal de los servicios de una Empresa Integradora de Telecomunicaciones, por lo menos se pudo adecuar el diseño lógico del sistema para que solamente sea necesario configurar los datos de conexión con los sistemas de dichas empresas en un servicio Web en PHP.

64

RECOMENDACIONES Ya concluido el desarrollo del proyecto y documentadas las conclusiones a las que se ha llegado, se proponen las siguientes recomendaciones para ser consideradas tanto para el mantenimiento del producto, como para futuros desarrollos: •

Establecer dentro de la organización una metodología de desarrollo de software que este enfocada en la construcción de aplicaciones Web, tomando en cuenta que la metodología actual de la empresa solo cubre el desarrollo de sistemas Stand Alone y no ha sido actualizada en años recientes a pesar de que ya se han desarrollado en la gerencia sistemas bajo la plataforma .NET.

•

Establecer estándares claros de documentación, codificación, nomenclaturas de diagramas y base de datos, en el momento no se encuentra ningún manual oficial y aprobado por la gerencia que defina este tipo de estándares, los cuales facilitarían enormemente el mantenimiento a futuro del producto desarrollado.

•

Realizar una evaluación formal de los manejadores de Base de Datos que dispone la empresa, debido a que la utilización de Informix rompería el requerimiento inicial de la organización de desarrollar aplicaciones utilizando únicamente Software Libre.

•

Describir el procedimiento a seguir para realizar la actualización de la Base de Datos principal con la información proveniente de SAP Recursos Humanos. De igual forma, también es necesario definir como se llevará a cabo la actualización de la Base de Datos de respaldo en MySQL, de modo tal que se mantenga una consistencia entre todas las Bases de Datos.

•

Definir un poco más los procesos que se llevan a cabo en diferentes planes de contingencia que la empresa puede ejecutar, ya que por los momentos el único plan documentado y estructurado claramente y que se ha activado en diferentes ocasiones con

65

las mismas características es el Plan de Operaciones Especiales Arcoiris, que solo esta planteado bajo el escenario de paros laborales. •

Realizar un chequeo completo de los datos del personal de la empresa, tomando en cuenta las sugerencias dadas en la reunión con un comité de seguridad, el cual explicaba los problemas que se presentaban durante la activación de Plan Arcoiris cuando se les notificaba a personas que ya no eran trabajadores de la empresa o cuando no se podía localizar una parte del personal porque no tenían el mismo número telefónico.

•

Tomar en cuenta la contratación de un servicio de prueba con una Empresa Integradora de Telecomunicaciones durante los primeros meses del año 2006, de modo tal que sumado a las funcionalidades de administración y control que ya fueron comprobadas al finalizar el sistema, se puedan llevar a cabo las pruebas de comunicación directamente con los teléfonos móviles del personal de la empresa. Para estas pruebas se sugiere la planificación del simulacro de una contingencia.

•

Crear un grupo piloto que interactúe con la aplicación, que esté capacitado para encontrar posibles errores o para proponer algunas mejoras a la misma.

66

REFERENCIAS BIBLIOGRAFICAS (Jacobson et al., 1999)

Jacobson, Booch y Rumbaugh. “The Unified Software Development Process”. Addison-Wesley. EE.UU. 1999.

(Gerencia Ejecutiva de

“Plan de Operación Especial (Arcoiris)”. Gerencia Ejecutiva de

Transporte Metro,

Transporte Metro. C.A. Metro de Caracas. 2003.

2003). (Kruchten, 1999)

Kruchten, Phillipe. “The Rational Unified Process”. AddisonWesley. EE.UU. 1999.

(Kruchten, 2003)

Kruchten y Kroll. “The Rational Unified Process made easy. A practitioner’s guide to the RUP”. Adisson-Wesley. 2003

(Larman, 1999)

Larman, Craig. “UML y patrones. Introducción al análisis y diseño orientado a objetos”. Prentice Hall. Primera Edición. México. 1999.

(Navathe et al., 1997)

Elmarsi, R y Navathe, S. “Sistemas de Bases de Datos” AddisonWesley Iberoamericana. Segunda Edición. México. 1997.

(Registro Mercantil,

Registro Mercantil de la Circunscripción Judicial del Distrito

1977)

Federal y Estado Miranda, Nº 18, Tomo 110-A. 1977.

(Quatrani, 1998)

Quatrani, T. “Visual Modeling with Rational Rose and UML”. Addison-Wesley Longman, Inc. EE.UU. 1998.

67

BIBLIOGRAFIA CONSULTADA •

Booch, Rumbaugh y Jacobson. “The Unified Modeling Language User Guide”. Addison-Wesley. Novena Edición. EE.UU. 2001.

•

Kendall, Kenneth y Kendall, Julie. “Análisis y Diseños de Sistemas”. Prentice Hall Hispanoamericana. México. 1997.

•

Mendoza. L. “Sistemas de Información I,II,III. Teoría.”. Universidad Simón Bolívar. 2001.

68

REFERENCIAS ELECTRÓNICAS (Alsina, 2003)

Alsina, Guillem. (2003). “La tecnología SMS puede utilizarse para avisos masivos”. DiarioRed.Com. Recuperado el 19 de marzo de 2006, de http://diariored.com/blog/000184.php.

(Booch, 1999)

Booch, Grady. (1999). “Software Architecture and the UML”. Recuperado el 19 de marzo de 2006, de http://www.jeckle.de/files/arch.pdf.

(Colaboradores de

“Servidor HTTP Apache”. (2006). Wikipedia, La enciclopedia libre.

Wikipedia, 2006a)

Recuperado el 19 de marzo de 2006, de http://es.wikipedia.org/w/index.php?title=Servidor_HTTP_Apache&old id=2613068.

(Colaboradores de

“PostgreSQL”. (2006). Wikipedia, La enciclopedia libre. Recuperado el

Wikipedia, 2006b)

19 de marzo de 2006, de http://es.wikipedia.org/w/index.php?title=PostgreSQL&oldid=2520189.

(Colaboradores de

“MySQL”. (2006). Wikipedia, La enciclopedia libre. Recuperado el 19

Wikipedia, 2006c)

de marzo de 2006, de http://es.wikipedia.org/w/index.php?title=MySQL&oldid=2576267.

(Colaboradores de

“Informix”. (2006). Wikipedia, La enciclopedia libre. Recuperado el 19

Wikipedia, 2006d)

de marzo de 2006, de http://es.wikipedia.org/w/index.php?title=Informix&oldid=2583969.

(Colaboradores de

“Servicio de mensajes cortos”. (2006). Wikipedia, La enciclopedia libre.

Wikipedia, 2006e)

Recuperado el 19 de marzo de 2006, de http://es.wikipedia.org/w/index.php?title=Servicio_de_mensajes_cortos &oldid=2415284. 69

(Hernández, 2003)

Hernández, José. (2003). “Arquitecturas de Sistemas de Bases de Datos (ABD), 3B, ETSIAP”. Universitat Politècnica de València. Recuperado el 19 de marzo de 2006, de https://www.upv.es/bin2/caches/miw/visfit?id=378873&idioma=C.

(Kruchten, 1995)

Kruchten, Phillipe. (1995). “Architectural Blueprints—The “4+1” View Model of Software Architecture”. Recuperado el 17 de marzo de 2006, de http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitep apers/2003/Pbk4p1.pdf.

(Leffingwell,

Leffingwell, Dean. (2000). “Features, Use Cases, Requirements, Oh

2000)

My!”. Recuperado el 17 de marzo de 2006, de http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitep apers/2003/featucreqom.pdf.

(Mendoza, 2004)

Mendoza, María. (2004). “Metodologías De Desarrollo De Software”. Recuperado el 17 de marzo de 2006, de http://www.informatizate.net/articulos/metodologias_de_desarrollo_de_ software_07062004.html.

(Ministerio de

“Plan de contingencias”. (2000). Ministerio de Economía y Obras y

Economía, 2000)

Servicios Públicos de Argentina. Recuperado el 17 de marzo de 2006, de http://www.mecon.gov.ar/download/dirinf/cont.pdf.

(Probasco, 2000)

Probasco, Leslee. (2000). “The ten essentials of RUP. The essence of an effective development process”. Recuperado el 17 de marzo de 2006, de http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitep apers/2003/TP177.pdf.

70

(Reseña Histórica

“Reseña Histórica del Sistema Metro”. (2006). Recuperado el 17 de

del Sistema Metro,

marzo de 2006, de

2006)

http://www.metrodecaracas.com.ve/institucion/rese.htm#.

(Tango/04, 2006)

“DirectSMS. Mensajería bidirecional para iSeries”. (2006). Recuperado el 17 de marzo de 2006, de http://www.tango04.es/tecnologia/directsms.php.

(Wall, 1997)

Wall, Alan. (1997). “Planes de Contingencia”. Recuperado el 17 de marzo de 2006, de http://www.aceproject.org/main/espanol/po/poh01d.htm.

71

ÍNDICE GENERAL DE APÉNDICES APÉNDICE I II III IV V VI VII VIII IX X XI XII XIII XIV XV XVI

PLAN DEL PROYECTO………………………………………………….. VISIÓN DEL PROYECTO………………………………………………... REQUERIMIENTOS FUNCIONALES DEL SISTEMA………………… LISTA DE RIESGOS……………………………………………………… REQUERIMIENTOS COMPLEMENTARIOS…………………………… GLOSARIO DEL SISTEMA……………………………………………… CASO DEL NEGOCIO……………………………………………………. PLAN CREATIVO………………………………………………………… DOCUMENTO DE ARQUITECTURA DEL SOFTWARE……………… EVALUACIÓN DE LA TECNOLOGÍA DE TELECOMUNICACIONES EVALUACIÓN DE LA TECNOLOGÍA DE DESARROLLO…………… DISEÑO Y FUNCIONALIDAD DE LA INTERFAZ DE LA APLICACIÓN……………………………………………………………... ESCENARIOS PARA EL PLAN DE OPERACIONES ESPECIALES ARCOIRIS…………………………………………………………………. ESCENARIOS PARA EL PLAN DE OPERACIONES ESPECIALES ARCOIRIS ESPECIALES ARCOIRIS POR ORIGEN GRUPOS PARA EL PLAN DE OPERACIONES ESPECIALES ARCOIRIS…………………………………………………………………. ASIGNACIONES DE GRUPOS PARA LOS DIFERENTES ESCENARIOS DEL PLAN DE OPERACIONES ESPECIALES ARCOIRIS………………………………………………………………….

72

pp. 73 76 83 88 92 94 98 101 104 149 159 162 181 182 183 184

APÉNDICE I. PLAN DEL PROYECTO AI.1. PLAN DE LAS FASES El desarrollo se llevara a cabo en base a fases con una o más iteraciones en cada una de ellas. La tabla AI.1 muestra la distribución de tiempos y el número de iteraciones de cada fase. Fase Fase de Inicio Fase de Elaboración Fase de Construcción

Nro. Iteraciones Duración 1 3 1 4 2 11

Tabla AI.1. Número de Iteraciones por Fases RUP Fuente: Elaboración Propia AI.2. PLAN DE ACTIVIDADES Plan de actividades de la Fase de Inicio Actividad Definición de los objetivos del proyecto Definición del alcance detallado del proyecto Diagnóstico de la situación actual y propuesta de la solución del problema Definición de indicadores de éxito del proyecto, creación de un documento inicial de riesgos Redacción del documento “Visión” del proyecto Creación de un modelo inicial de Casos de Uso Redacción de un glosario inicial del proyecto Creación de un diagrama del Proceso Global Actual vs. Esperado Evaluación de los objetivos de la organización Evaluación de la factibilidad técnica, operacional y económica del proyecto Creación del documento “Caso del Negocio” Análisis y propuesta de la tecnología y el lenguaje de desarrollo de Software Libre a utilizar para definir la Arquitectura Candidata Definir y construir el Plan de Implantación del Proyecto Creación de un Plan de Proyecto

Tabla AI.2. Plan de Proyecto: Fase de Inicio Fuente: Elaboración Propia

73

Semana 1 1,2 2 2 2 2 2 2 2 3 3 3 3 3

Plan de actividades de la Fase de Elaboración Actividad Re-evaluar los requerimientos iniciales Diseño de las interfaces Actualización del modelo de Casos de Uso Diseño de Procesos Propuestos y Base de Datos, creación del Documento de Arquitectura del Software Creación de diagramas de clases, de casos de uso, de colaboración, de estados y de secuencia Elaboración del cronograma detallado del proyecto para la revisión del Plan de Proyecto

Semana 4 4,5 5 5,6 6,7 7

Tabla AI.3. Plan de Proyecto: Fase de Elaboración Fuente: Elaboración Propia Plan de actividades de la Fase de Construcción Actividad Creación de la Base de Datos de la aplicación Desarrollo e Implementación del Sistema para la activación de los diversos planes de contingencia de la C.A. Metro de Caracas, según el tipo de usuario Creación de la Capa de Interfaz Creación de la Capa Lógica Ejecución de pruebas del sistema y preparación de los datos para la carga inicial del sistema Ajuste y correcciones hechas a la aplicación

Semana 8 9 a la 15 11,12 12 a la 16 17,18 18

Tabla AI.4. Plan de Proyecto: Fase de Construcción Fuente: Elaboración Propia En vista de que el alcance del proyecto no contempla la fase de transición, no se presenta el plan de actividades para la misma, sin embargo, durante las 2 últimas semanas de la pasantía se planificaron el comienzo de algunas actividades que se deben destacar. Actividad Implantar el sistema en los distintos servidores y ejecutar las distintas pruebas finales Elaboración del Informe de la Pasantía

Tabla AI.5. Plan de Proyecto: Actividades Finales. Fuente: Elaboración Propia 74

Semana 19, 20 19, 20

El número de iteraciones definido para cada una de las fases de RUP depende en gran medida del tamaño del proyecto. Kruchten (2003) propone un número determinado de iteraciones en función del tamaño del proyecto en cuanto a meses y a la cantidad de personas involucradas. La tabla AI.6 muestra la sugerencia expuesta por Kruchten (2003). NÚMERO DE PERSONAS 3 10 80

NÚMERO DE MESES 4 8 20

CONCEPCIÓN 1 1 2

NÚMERO DE ITERACIONES POR FASE ELABORACIÓN CONSTRUCCIÓN TRANSICIÓN 1 3 1 2 3 2 3 4 2

Tabla AI.6. Número de Iteraciones para los diferentes proyectos Fuente: (Kruchten, 2003) Este proyecto tuvo una duración de 20 semanas (5 meses aproximadamente) y fue desarrollado por una sola persona, por lo cual es comparable con un proyecto de 4 meses, desarrollado por 3 personas. El número de iteraciones definido para cada fase, se obtuvo en función de esto, y siguiendo la sugerencia de Kruchten (2003).

75

APÉNDICE II. VISIÓN DEL PROYECTO La visión captura la esencia de los requerimientos en RUP: analizando el problema, entendiendo las necesidades de los usuarios, definiendo el sistema y gerenciando los requerimientos a medida que estos vayan cambiando. La visión captura a un muy alto nivel los requerimientos y las restricciones de diseño, en función de ofrecer un entendimiento del sistema a ser desarrollado. (Probasco, 2000) 1. Posicionamiento 1.1. Oportunidad de Negocio Se considera que para la empresa es de gran importancia disponer de un sistema automatizado que le simplifique las tareas de planificación, gestión y control del personal operativo y de confianza, que además brinde el soporte informativo con el fin de trazar las mejores estrategias para prestar un mejor servicio al público usuario del sistema ferroviario y superficial en momentos de emergencia. En tal sentido, se pretende ofrecer una manera rápida y eficaz de realizar la fase de activación de los Planes de Contingencia, dado que en determinadas emergencias o sucesos la rapidez con la que se realice este proceso puede ser vital si se presenta una situación que pongan en riesgo la vida de los pasajeros, por lo cual el tiempo es un factor crítico para el desenvolvimiento del plan. Y por supuesto, se le facilita esta tarea al coordinador del plan. Además se busca proporcionar la información necesaria para la toma de decisiones tanto en el transcurso de la ejecución del plan como en la evaluación del desempeño del mismo. La comunicación de la Aplicación Web que se desarrollaría con el sistema SAP, proporcionaría información actualizada del personal disponible para el momento de la activación de un Plan de Contingencia, permitiendo la planificación y reorganización del personal. La emisión de reportes automáticamente sobre el desenvolvimiento del Plan le ahorra al coordinador tiempo y trabajo, además de brindar información veraz y confiable al momento de ser solicitada. De manera general, con la realización de este Proyecto se pretende facilitar la aplicación y operación de Planes de Contingencia con el fin de ayudar a agilizar los procesos de activación y desactivación, así como también ayudar en la toma de decisiones en momentos de emergencia. 76

1.2. Sentencia que define el problema El problema de

Informar al personal requerido la activación o desactivación de un Plan de Contingencia específico. Gestionar el reporte de las asistencias del personal a sus puestos de trabajo respectivo. Gestionar la elección del personal requerido según el evento que se presente. Gestionar la administración del personal con respecto a los puestos de trabajo o asistencia de la operación especial. Gestionar el reporte de los resultados generales de los Planes de Contingencia llevados a cabo.

afecta a

Presidente. Vicepresidente. Gerencia Ejecutiva de Transporte Metro. Gerencia de Seguridad e Higiene Industrial. Gerencia Corporativa de Protección Integral. Gerencias Ejecutivas y Corporativas en general. Centro de Control y Operaciones. Sala de Contingencia. Personal Operativo. Personal de Confianza.

El impacto asociado es

La automatización del proceso de activación de un Plan de Contingencia en específico, el cual se llevará a cabo en pocos minutos utilizando tecnologías de comunicación existentes, y que mediante el proceso actual (llevado a cabo manualmente) duraba varias horas en muchos casos. También el manejo de los reportes será ejecutado automáticamente debido a que el sistema registrará de inmediato la asistencia del personal que pueda reportarse a través del sistema de información.

una adecuada solución sería

Automatizar el proceso, utilizando un Servicio Web que permita al Presidente, Vicepresidente, Administrador o cualquier persona autorizada, realizar la activación de un Plan de Contingencia, en donde de inmediato se les notificará al personal requerido la activación del Plan mediante el envío de mensajes de texto a sus celulares y correos electrónicos. La búsqueda de los números telefónicos y direcciones de correo electrónico será mediante el uso de una base de datos integrada con el Sistema SAP de la empresa.

Tabla AII.1. Sentencia que define el problema

77

1.3. Sentencia que define la posición del Producto Para

Presidente. Vicepresidente. Administrador del Sistema a definir por la empresa (Persona(s) autorizada(s) para administrar los eventos y el personal requerido según el tipo de Plan; también esta facultado para ejecutar la activación o desactivación) Gerente Ejecutivo de Transporte Metro. Coordinador de la Sala de Contingencia (a definir durante una contingencia). Personal Operativo. Personal de Confianza.

Quienes

Ejecutan la activación, asisten a sus puestos de trabajo asignados durante la contingencia y administran las configuraciones, para finalmente manejar los reportes de asistencia y resultados originados al finalizar un plan en específico.

El nombre del producto

Es una aplicación Web.

Que

Maneja la información y los recursos necesarios para gestionar la activación, control y seguimiento de un Plan de Contingencia.

No como

El proceso actual llevado a cabo manualmente.

Nuestro producto

Permite gestionar las distintas actividades de activación, desactivación, administración y reportes durante una contingencia, mediante una interfaz gráfica sencilla y amigable. Además proporciona un acceso rápido y actualizado a la información desde cualquier punto que tenga acceso a Intranet de la empresa o a Internet.

Tabla AII.2. Sentencia que define la posición del Producto

2. Descripción de Stakeholders (Participantes en el Proyecto) y Usuarios Para proveer de una forma efectiva productos y servicios que se ajusten a las necesidades de los usuarios, es necesario identificar e involucrar a todos los participantes en el proyecto como parte del proceso de modelado de requerimientos. También es necesario identificar a los usuarios del sistema y asegurarse de que el conjunto de participantes en el proyecto los representa adecuadamente. Esta sección muestra un perfil de los participantes y de los usuarios involucrados en el proyecto, así como los problemas más importantes que éstos perciben para enfocar la 78

solución propuesta hacia ellos. No describe sus requisitos específicos ya que éstos se capturan mediante otro artefacto. En lugar de esto proporciona la justificación de por qué estos requisitos son necesarios.

2.1. Resumen de Stakeholders Nombre

Descripción

Responsabilidades

Maria Di Sabatino

Gerente de Sistemas de Información.

Representa a todos los usuarios posibles del sistema.

Dennis Naranjo

Representante de la Gerencia de Telecomunicaciones.

Seguimiento del desarrollo del proyecto.

Aurelio Pestana

Representante de la Oficina de Seguridad Ambiental dentro de la Gerencia de Seguridad e Higiene Industrial.

Aprueba requisitos y funcionalidades

Henry Abdelnour

Representante de la Gerencia Ejecutiva de Transporte Metro.

A definir

Representante de la Gerencia de Desarrollo Institucional.

Tabla AII.3. Resumen de Stakeholders

2.2. Resumen de Usuarios Nombre

Descripción

Stakeholder

Administrador

Encargado de la administración de la aplicación específicamente en lo que concierne a la configuración, activación, control y seguimiento de los planes de contingencia, así como también del análisis de los reportes originados de los planes ejecutados.

Henry Abdelnour

Personal

Son las personas que integran todo el personal de confianza y operativo de la C.A. Metro de Caracas, facultado para la utilización del sistema y que podría recurrir a el para realizar el reporte de asistencia de una contingencia, repasar el área de trabajo al que fue asignado, actualizar ciertos datos personales (números telefónicos, dirección, etc.) y revisar su participación en contingencias pasadas.

No Asociado

Tabla AII.4. Resumen de Usuarios

79

2.3. Entorno de usuario Los usuarios entrarán al sistema ingresando la dirección Web que se le asigne a la aplicación, dicho acceso podrá ser efectuado a través de Internet o Intranet. Cabe destacar, que no es necesario que el usuario disponga de una computadora con características especiales más allá de un navegador Web y por supuesto acceso a Internet o a la red interna de la C.A. Metro de Caracas. Luego, una vez dentro de la aplicación tendrán que identificarse utilizando su nombre de usuario y contraseña respectiva, para así poder acceder a los recursos y herramientas permitidas según el tipo de usuario o nivel de acceso que tenga.

3. Descripción Global del Producto 3.1. Perspectiva del producto El producto a desarrollar es una Aplicación Web que asista la Activación, Control y Seguimiento de Planes de Contingencia de la C.A. Metro de Caracas. Los objetivos fundamentales a cumplir son la automatización de la activación, la administración y configuración de los eventos y el reporte de asistencia del personal solicitado. 3.2. Resumen de características A continuación se mostrará un listado con los beneficios que obtendrá el cliente a partir del producto: Beneficio del cliente Mayor velocidad en el flujo de información al realizar la activación o desactivación de un Plan de Contingencia. Reportes automáticos de la asistencia del personal a sus puestos de trabajo. Mayor facilidad para administrar los eventos que puedan ocurrir en una contingencia.

Características que lo apoyan Servicio Web que ejecutará el envío de correos electrónicos y mensajes de texto de celular al personal requerido. Utilizando igualmente la Aplicación Web, el personal podrá reportar su asistencia. La Aplicación Web permitirá a los usuarios autorizados para tal fin, incluir, eliminar y modificar los eventos que sean necesario manejar y que generen la activación de un Plan de Contingencia. Mayor facilidad para administrar el La Aplicación Web permitirá a los personal requerido según el tipo de evento, usuarios autorizados para tal fin, distribuir suceso o emergencia que origine la a cada uno de los trabajadores que integran activación de un Plan de Contingencia. el Personal de Confianza y Operativo de la C.A. Metro de Caracas, en las áreas de 80

Mayor facilidad para el control de los reportes de resultados generales de los Planes de Contingencia ejecutados.

trabajo pertinentes para la asistencia de la operación especial. La Aplicación Web generará reportes de diferentes actividades y asuntos pertinentes al desenvolvimiento de la contingencia, el cual podrá ser manejado por los usuarios autorizados. Adicionalmente, se tiene planteado que estos reportes puedan ser generados en formato de la herramienta Microsoft Excel, la cual en los últimos años ha servido para manejar y plasmar los reportes de diferentes procesos de la empresa.

Tabla AII.5. Resumen de características 3.3. Costo y precio Como se tiene planteado la utilización de Software Libre, el costo asociado a la adquisición de estos recursos sería mínimo, sin embargo en lo que concierne a la tecnología y los servicios necesarios para el envío de los mensajes de texto, se mantiene en estudio el costo de las propuestas debido a que actualmente esta en curso reuniones y negociaciones con Empresas Integradoras de Telecomunicaciones (EIT). Hay que destacar que el estudio de las soluciones ofrecidas en las reuniones con las EIT’s al igual que el estudio de la herramienta de software y tecnologías a utilizar, son parte de los objetivos del presente proyecto. Ambos estudios se deben efectuar en paralelo para que sean compatibles la herramienta a utilizar y el servicio que se contrate.

4. Otros Requisitos del Producto 4.1. Estándares Aplicables Es necesario cumplir con la Metodología de Trabajo para la Ejecución de Proyectos de Sistemas (No Sap), con la cual la Gerencia de Sistemas de Información lleva a cabo sus proyectos. De la misma forma, también es necesario cumplir con los procesos establecidos por la Gerencia de Desarrollo Institucional, la cual actuará como enlace entre los stakeholders y usuarios principales del sistema. 81

4.2. Requisitos de Desempeño Fundamentalmente, es necesario que se cumplan altos niveles de seguridad, tanto en la transacción de datos y mensajes entre el sistema y el Servicio Web de la Empresa Integradora de Telecomunicaciones, así como en el acceso de los usuarios, debido a que el presente sistema se convertiría en una herramienta vital para que una empresa de transporte de tanta importancia como lo es la C.A. Metro de Caracas, pueda cumplir con una operación especial que se ejecute durante una contingencia, y justamente debido a que en ella pueden ocurrir emergencias en donde esten en riesgo vidas humanas, no cabe espacio a que se pueda violar el sistema por usuarios no autorizados o que no pueda cumplir a cabalidad con la transmisión de los mensajes de activación de los planes.

82

APÉNDICE III. REQUERIMIENTOS FUNCIONALES DEL SISTEMA Los requerimientos son una descripción de las necesidades o deseos de un producto. La meta primaria de la fase de requerimientos es identificar y documentar lo que en realidad se necesita, en una forma que claramente se lo comunique al cliente y a los miembros del equipo de desarrollo. (Larman, 1999) El documento de requerimientos define los servicios que serán proporcionados por el sistema. Es la declaración oficial de lo que es requerido al sistema. Número Nombre Tipo Detalles y Restricciones Versión Condición

R.1 Perfiles de Usuario Control y Seguridad Permitir el acceso al personal requerido para la activación, control y mantenimiento del sistema definiendo y restringiendo el alcance de los usuarios. 1.0 Obligatorio Tabla AIII.1. Requerimiento “Perfiles de Usuario”

Número Nombre Tipo Detalles y Restricciones Versión Condición

R.2 Actualización de Datos Funcional Permitir a los administradores del sistema actualizar la información concerniente a los datos del personal de la C.A. Metro de Caracas (número de teléfono, e-mail, dirección física, etc.), necesarios para ubicar al personal que es requerido en una contingencia. 1.0 Deseable Tabla AIII.2. Requerimiento “Actualización de Datos”

83

Número Nombre Tipo Detalles y Restricciones Versión Condición

R.3 Configuración de las Características de las Contingencias Funcional Permitir a los administradores del sistema configurar las características (orígenes, escenarios, grupos de personal, áreas de trabajo, etc.) de las contingencias que se puedan presentar. 1.0 Obligatorio

Tabla AIII.3. Requerimiento “Configuración de las Características de las Contingencias” Número Nombre Tipo Detalles y Restricciones Versión Condición

R.4 Activación de un Plan de Contingencia Funcional Permitir a los administradores del sistema realizar la activación y desactivación oficial de un Plan de Contingencia. 1.0 Obligatorio

Tabla AIII.4. Requerimiento “Activación y desactivación de un Plan de Contingencia” Número Nombre Tipo Detalles y Restricciones Versión Condición

R.4.1 Configuración de la activación de un Plan de Contingencia Funcional Permitir la configuración de la activación según el evento o suceso que este ocurriendo. 1.0 Obligatorio

Tabla AIII.5. Requerimiento “Configuración de la activación de un Plan de Contingencia” Número Nombre Tipo Detalles y Restricciones Versión Condición

R.4.2 Configuración del personal participante Funcional Indicar los grupos de trabajadores que estarán operativos durante la ejecución del plan y que deberán ser notificados. 1.0 Obligatorio

Tabla AIII.6. Requerimiento “Configuración del personal participante” 84

Número Nombre Tipo Detalles y Restricciones Versión Condición

R.4.3 Comunicar la activación del plan de contingencia al personal participante Funcional Informar automáticamente de la activación del plan al personal de confianza activo, utilizando diferentes sistemas de comunicación personal como: e-mail, envío de mensajes de texto al celular, envío de mensajes de voz por teléfono (móvil y/o fijo), etc. 1.0 Deseable

Tabla AIII.7. Requerimiento “Configuración del personal participante” Número Nombre Tipo Detalles y Restricciones

Versión Condición

R.5 Confirmación de recepción de los mensajes del sistema Control Notificación automática al sistema de la recepción de los mensajes al personal de confianza solicitado, esto incluye por ejemplo, la respuesta de los sistemas de telefonía móvil cuando el usuario abre un mensaje de texto, chequea su buzón de voz, recibe una llamada telefónica o revisa su buzón de correo (e-mail). 1.0 Deseable

Tabla AIII.8. Requerimiento “Configuración del personal participante” Número Nombre Tipo Detalles y Restricciones Versión Condición

R.6 Reporte de asistencia del personal solicitado Funcional Permitir al personal notificar su asistencia a su puesto de trabajo asignado para la ejecución del plan. 1.0 Obligatorio

Tabla AIII.9. Requerimiento “Reporte de asistencia del personal solicitado”

85

Número Nombre Tipo Detalles y Restricciones Versión Condición

R.7 Consulta de asignaciones de trabajo del personal Funcional Permitir al personal de la empresa consultar sus asignaciones de trabajo según el tipo de contingencia que pueda participar o este participando. 1.0 Obligatorio

Tabla AIII.10. Requerimiento “Consulta de asignaciones de trabajo del personal” Número Nombre Tipo Detalles y Restricciones Versión Condición

R.8 Consulta de la asistencia del personal solicitado Funcional Permitir al administrador consultar el estado de la asistencia del personal solicitado. 1.0 Obligatorio

Tabla AIII.11. Requerimiento “Consulta de la asistencia del personal solicitado” Número Nombre Tipo Detalles y Restricciones Versión Condición

R.9 Ingreso de planes de seguridad Funcional Permitir al administrador ingresar planes de seguridad que se llevarán a cabo con el Plan de Contingencia activado. 1.0 Deseable

Tabla AIII.12. Requerimiento “Ingreso de planes de seguridad” Número Nombre Tipo Detalles y Restricciones Versión Condición

R.10 Desactivación de un Plan de Contingencia Funcional Permitir al administrador concluir las operaciones especiales ejecutando la desactivación del Plan de Contingencia 1.0 Obligatorio

Tabla AIII.13. Requerimiento “Mantener el historial de los planes ejecutados”

86

Número Nombre Tipo Detalles y Restricciones Versión Condición

R.10.1 Comunicar la desactivación del plan de contingencia Funcional Informar al personal que se mantiene trabajando en el Plan de Contingencia, la desactivación y finalización de las operaciones del mismo. 1.0 Deseable

Tabla AIII.14. Requerimiento “Comunicar la desactivación del plan de contingencia” Número Nombre Tipo Detalles y Restricciones Versión Condición

R.11 Mantener el historial de los planes ejecutados Funcional Permitir al administrador consultar los resultados de los planes de contingencia ejecutados y desactivados 1.0 Obligatorio

Tabla AIII.15. Requerimiento “Mantener el historial de los planes ejecutados”

87

APÉNDICE IV. LISTA DE RIESGOS Un precepto esencial de RUP es identificar y atacar los más altos riesgos en una etapa temprana del proyecto. La lista de riesgos se hace con la intención de capturar los riesgos que pueden ocurrir en el proyecto. Esta los identifica en orden decreciente de prioridad. Para cada riesgo, debe haber un plan de mitigación. (Probasco, 2000) Lo que sigue es la lista de riesgos identificados para este proyecto, tal como expone Probasco (2000), se presentan en orden decreciente de importancia. 1. REQUERIMIENTOS POCOS CLAROS MAGNITUD Alta DESCRIPCIÓN Falta de claridad en la información requerida para el desarrollo e implementación de los sistemas y proyectos en la C.A. Metro de Caracas. IMPACTO Dificultad en el planteamiento de la solución a desarrollar. INDICADORES Falta de información teórica y oficial acerca de los métodos que son usados en la realización de proyectos y análisis de propuestas. ESTRATEGIA DE Investigar en diversas fuentes oficiales de la C.A. Metro de Caracas MITIGACIÓN acerca de los procedimientos correctos para la realización de proyectos y que sean adecuados para el negocio genérico planteado. PLAN DE Buscar asesoría fuera de la organización, es decir, entrevistarse con CONTINGENCIA especialistas en el área de tecnología de la información que tengan experiencia en el desarrollo de sistemas de emergencia o contingencia. Tabla AIV.1. Riesgo: Requerimientos pocos claros 2. FALTA DE INFORMACIÓN SOBRE LOS PLANES DE CONTINGENCIA A IMPLEMENTAR MAGNITUD Alta DESCRIPCIÓN Disponibilidad de la información sobre los planes de contingencia a implementar y que pueden ser asistidos por un sistema de información. IMPACTO Dificultad en el planteamiento de la solución a desarrollar. INDICADORES Falta de asesoría técnica y especializada acerca de los planes de emergencia o contingencia de la C.A. Metro de Caracas. ESTRATEGIA DE Estudiar y analizar los manuales de procedimientos e informes de MITIGACIÓN simulacros obtenidos en la búsqueda de documentación oficial del Metro de Caracas, para conseguir los puntos clave en donde el sistema podría asistir automatizando los procesos. PLAN DE Utilizar los planes más sencillos, pero que cubran las necesidades 88

CONTINGENCIA

mínimas del negocio genérico planteado.

Tabla AIV.2. Riesgo: Falta de información sobre los planes de contingencia a implantar 3. RECURSOS LIMITADOS E INESTABLES MAGNITUD Alta DESCRIPCIÓN Recursos económicos limitados y poco definidos. IMPACTO Ajustes en el cronograma de actividades. Retrasos a la hora de iniciar la construcción de la plataforma de comunicaciones. INDICADORES Pérdida de tiempo en la fase de construcción. Carencia temporal de algunos recursos (software y hardware). ESTRATEGIA DE Solicitud de algunos recursos necesarios para llevar a cabo algunas MITIGACIÓN propuestas planteadas. PLAN DE Ninguno. CONTINGENCIA Tabla AIV.3. Riesgo: Recursos limitados e inestables 4. DISPONIBILIDAD DE TIEMPO DE LOS USUARIOS Y ADMINISTRADORES MAGNITUD Alta DESCRIPCIÓN Disponibilidad de los usuarios y administradores para entrevistarse con los analistas. IMPACTO Pérdida de tiempo y ajustes constantes en el cronograma de actividades. INDICADORES Falta de información crítica para la determinación de los requerimientos. ESTRATEGIA DE Buscar otras formas de establecer requerimientos como: observación de MITIGACIÓN los procesos involucrados y necesidades de la empresa, además de las entrevistas. PLAN DE Realizar reuniones fuera del horario de oficina, utilizar técnicas como CONTINGENCIA “StoryBoards” que permitan recolectar opiniones acerca de lo que el sistema permitirá hacer.

Tabla AIV.4. Riesgo: Disponibilidad de tiempo de los usuarios y administradores

89

5. ESTIMACIONES DE TIEMPO NO REALISTAS MAGNITUD Significativa DESCRIPCIÓN Debido a los riesgos anteriores y más aún por aquellos que no están, se pueden presentar inconvenientes que retrasen las fases del desarrollo. IMPACTO Ajustes o ampliaciones en el Plan de desarrollo del sistema. INDICADORES Retrasos constantes en la entrega de proyectos o componentes relativos al sistema. ESTRATEGIA DE Dejar un espacio de holgura entre las fases del desarrollo. MITIGACIÓN PLAN DE Realizar un análisis de los tiempos reales de entrega y basar la nueva CONTINGENCIA planificación en base a estos tiempos. Tabla AIV.5. Riesgo: Estimaciones de tiempo no realistas 6. TECNOLOGÍA NUEVA O POCO PROBADA MAGNITUD Significativa DESCRIPCIÓN La C.A. Metro de Caracas ha desarrollado en los últimos años con PowerBuilder y últimamente en .NET. Para poder llevar a cabo este proyecto se exige la utilización de software libre, algo que no se ha probado antes en la organización.. IMPACTO Retraso en el desarrollo de los componentes principales e incompatibilidades con sistemas existentes. INDICADORES Las soluciones siempre serán dependientes a la forma en como podemos hacerlas posibles utilizando una tecnología desconocida o poco estudiada.. ESTRATEGIA DE Dejar un margen de tiempo para analizar y probar el software libre MITIGACIÓN elegido para desarrollar el sistema. PLAN DE Elegir una herramienta alterna a la escogida, que luego del aprendizaje CONTINGENCIA y la experiencia tomada durante el levantamiento de información, se ajuste mucho más a la solución planteada ó regresar al uso de la tecnología ya probada, es decir, trabajar en Visual .NET. Tabla AIV.6. Riesgo: Tecnología nueva o poco probada

90

7. FALTA DE EXPERIENCIA DE LOS DESARROLLADORES MAGNITUD Moderada DESCRIPCIÓN Falta de experiencia del personal de desarrollo del sistema (pasantes) con respecto a las herramientas a utilizar. IMPACTO Ajustar el cronograma de actividades. INDICADORES Pérdida de tiempo de los programadores en la fase de construcción. ESTRATEGIA DE Exigir a la empresa que se designe con anticipación la tecnología y MITIGACIÓN software a utilizar, para que los desarrolladores que a pesar de no contar con la experiencia necesaria para el manejo de estas herramientas, por lo menos si tenga el tiempo suficiente para adecuarse a ellas. PLAN DE Exigir la adquisición de manuales o cambiar las herramientas a utilizar CONTINGENCIA para el desarrollo. Tabla AIV.7. Riesgo: Falta de experiencia de los desarrolladores 8. INTEGRACIÓN DE DATOS MAGNITUD Moderada DESCRIPCIÓN Modelos incompatibles para hacer la importación de datos de SAP a la Base de Datos que se desea implementar. IMPACTO Retraso en la ejecución de las pruebas con datos reales. INDICADORES El módulo encargado de realizar las actualizaciones periódicas con la Base de Datos de SAP podría no estar completo a la hora de realizar las pruebas generales del sistema. ESTRATEGIA DE Analizar la implementación de una aplicación de Import / Export que MITIGACIÓN actualice la base de datos en períodos cortos. Cargar la base de datos mediante un archivo importado con los datos de PLAN DE CONTINGENCIA SAP o parcialmente mediante llenado manual. Tabla AIV.8. Riesgo: Integración de datos

91

APÉNDICE V. REQUERIMIENTOS COMPLEMENTARIOS En adición a los requerimientos funcionales tales como entradas traducidas en salidas, muchos sistemas también requieren la definición de un conjunto de requerimientos no funcionales enfocados en aquellos atributos adicionales del sistema, tales como requerimientos de usabilidad, mantenibilidad, rendimiento, entre otros. (Leffingwell, 2000) Los requerimientos no funcionales de SISCON son: Facilidad de Uso Tiempos de Respuesta Plataformas de Software Modificabilidad A continuación se presentan los detalles de cada uno de estos requerimientos. Para cuantificar la relevancia de cada requerimiento se utilizó una escala de 1 a 3, en donde 1 es deseable, 2 es muy deseable y 3 es imprescindible. IDENTIFICADOR C.1 Facilidad de Uso NOMBRE El uso de la aplicación debe ser sencillo para los usuarios. Debe presentar DESCRIPCIÓN una interfaz amigable e intuitiva. Usabilidad CATEGORÍA PONDERACIÓN 3 Tabla AV.1. Requerimiento Complementario: Facilidad de Uso IDENTIFICADOR C.2 Tiempos de Respuesta NOMBRE Es de suma importancia que la notificación de la emergencia utilizando los DESCRIPCIÓN mensajes de texto no se demore más de 30 segundos, de igual forma se requiere que los reportes de asistencia del personal se actualicen fielmente (con la fecha y hora del servidor) cuando un usuario utilice el sistema para llevar a cabo esta labor. Eficiencia CATEGORÍA 2 PONDERACIÓN Tabla AV.2. Requerimiento Complementario: Tiempos de Respuesta 92

IDENTIFICADOR C.3 Plataformas de Software NOMBRE A pesar de que es un requisito que la aplicación sea desarrollada bajo DESCRIPCIÓN software libre, es importante que se pueda instalar en servidores con sistemas operativos comerciales como Windows. Portabilidad CATEGORÍA PONDERACIÓN 3 Tabla AV.3. Requerimiento Complementario: Plataformas de Software IDENTIFICADOR C.4 Modificabilidad NOMBRE La inclusión de nuevas funcionalidades e incluso la modificación en la DESCRIPCIÓN estructura de las Bases de Datos, debe ser una tarea sencilla. Mantenibilidad CATEGORÍA PONDERACIÓN 3 Tabla AV.4. Requerimiento Complementario: Modificabilidad

93

APÉNDICE VI. GLOSARIO DEL SISTEMA El glosario o diccionario modelo incluye y define todos los términos que requieren explicación para mejorar la comunicación y aminorar riesgos de malos entendidos. (Larman, 1999) A continuación se presenta la lista de términos, ordenada alfabéticamente, asociados a la aplicación desarrollada.

C CCO Centro de Control y Operaciones. Lugar en el cual se monitorea todo el sistema Metro, de la red Metro de Caracas. Contingencia Se define como todo evento que de acuerdo a su magnitud no puede ser controlado por los recursos disponibles de la C.A. Metro de Caracas, por lo que es necesaria la intervención de organismos externos (Cuerpo de Bomberos, Policía Metropolitana, Policía Técnica Judicial, Guardia Nacional, DISIP, etc.). El evento será declarado como contingencia cuando el CCO lo determine.

E Emergencia Un acontecimiento que puede ser controlado localmente sin necesidad de añadir medidas o cambios en el proceder. Estación Infraestructura donde ingresa el público usuario para utilizar el sistema ferroviario (trenes). Escenario Son los ambientes o situaciones que se presentan, es decir la situación de emergencia en sí, los cuales son clasificados según su origen y que dependiendo del tipo que se presente, son llamados diferentes grupos o equipos de trabajo que participaran en el Plan de 94

Contingencia que pretende mitigar la emergencia. Evento Suceso o fenómeno natural, tecnológico o provocado por el hombre que se describe en términos de sus características, su severidad, ubicación y área de influencia. Es el registro en el tiempo y el espacio de un fenómeno que caracteriza una amenaza. Es importante diferenciar entre un evento potencial y el evento mismo, una vez éste se presenta.

G GDI Gerencia de Desarrollo Institucional de la C.A. Metro de Caracas. GEM Gerencia Ejecutiva de Transporte Metro de la C.A. Metro de Caracas. GIN Gerencia de Sistemas de Información de la C.A. Metro de Caracas. GNU Es un proyecto que tiene como objetivo crear un sistema operativo completo libre: el sistema GNU. GPL General Public License. Es una licencia creada por la Free Software Foundation y orientada principalmente a los términos de distribución, modificación y uso de software. Su propósito es declarar que el software cubierto por esta licencia es software libre. Grupo de Trabajo Es la clasificación específica que se le da a un conjunto de trabajadores de la empresa, los cuales pueden ser llamados para asistir a la ejecución de un Plan de Contingencia. GSI Gerencia de Seguridad e Higiene Industrial de la C.A. Metro de Caracas.

M Metro Unidades ferroviarias de transporte subterráneo para el transporte de usuarios. Metrobús 95

Unidades automotores de transporte superficial para el transporte de usuarios. MMS Multimedia Messaging System. Es una versión mejorada de SMS, ya que SMS es sólo para texto. Con MMS se pueden enviar y recibir datos multimedia (como fotos digitales, video, etc...).

O Operadoras de Telefonía Celular Empresas dedicadas a ofrecer servicios dentro del área de las telecomunicaciones entre dispositivos móviles como lo son los teléfonos celulares. Entre los servicios innovadores ofrecidos con más fuerza en la última década se encuentran la Mensajería de Texto (SMS) y la Mensajería Multimedia (MMS). Origen Es la naturaleza de la emergencia, es decir, el principio de la emergencia, la cual generalmente es denominada como de tipo natural, social, operacional, entre otros.

P PBX Private Branch eXchange. Red de telefonía privada que se usa dentro de una empresa, con el objetivo de compartir, administrar y controlar un conjunto de líneas externas. Personal de confianza Personal Administrativo de la C.A. Metro de Caracas adscrito a las diferentes gerencias, entrenados para cumplir las labores del personal operativo en situaciones de emergencia. Personal operativo Personal de la C.A. Metro de Caracas adscrito a la gerencia de estaciones y trenes, los cuáles cumplen su función de velar por los usuarios en las estaciones y trenes. Plan de Contingencia Procedimientos operativos específicos y preestablecidos de coordinación, alerta, movilización y respuesta ante la manifestación o la inminencia de un fenómeno peligroso particular para el cual se tienen escenarios definidos. Plan de Operaciones Especiales Arco Iris 96

Es un plan diseñado por la C.A. Metro de Caracas, en donde se establecen las acciones a seguir en caso de situaciones de orden interno que puedan afectar el normal desenvolvimiento de la operación comercial de los sistemas Metro y Metrobús. Plan de Seguridad Es un plan que consiste en definir algunas áreas dentro o fuera de las instalaciones de la C.A. Metro de Caracas, en donde se requiere que intervengan distintos organismos públicos que ayuden a mantener el control, la seguridad y el orden durante la ejecución de un Plan de Contingencia.

S Sala de Contingencia Es el centro operativo para coordinar todas las labores organizativas y de logística en el momento en que se activa el Plan de Operaciones Especiales Arco Iris. SMS Short Message Service. Es un protocolo estándar para el envío de mensajes cortos, que permite la transmisión de mensajes de texto, generalmente con un máximo de 140 ó 160 caracteres de longitud, desde un teléfono móvil. Software Libre Es el software que, una vez obtenido, puede ser usado, copiado, estudiado, modificado y redistribuido libremente.

97

APÉNDICE VII. CASO DEL NEGOCIO El caso del negocio provee la información necesaria, desde el punto de vista del negocio, para determinar si vale la pena o no invertir en el proyecto. Este provee la justificación del proyecto y establece sus restricciones económicas. (Probasco, 2000) En lo que sigue se presenta el Caso del Negocio para este proyecto. AVII.1. DESCRIPCIÓN Y OBJETIVOS DEL PRODUCTO Al finalizar este proyecto la C.A. Metro de Caracas debía contar con una herramienta que le permita automatizar todas las tareas relacionadas con la activación, control y seguimiento de los planes de contingencia que se originen, lo cual agilizará el tiempo de respuesta y disminuirá el impacto negativo que ocasione el retraso de las actividades a realizar durante una determinada emergencia. La aplicación Web proveerá las herramientas necesarias para que el administrador del sistema o los coordinadores de la contingencia puedan realizar la activación de la misma, que permitiría que todas las personas encargadas o responsables de llevar a cabo una labor sean informadas al instante y se reporten rápidamente a su área de trabajo. A pesar que la funcionalidad principal para agilizar los procesos sea la comunicación rápida y efectiva, también hay que agregar que la aplicación ofrecerá toda la información necesaria para que se puedan configurar las características relacionadas con el escenario que se presente durante una contingencia, lo que automatizará la elección inmediata del personal que asistirá a la operación especial con sus respectivas asignaciones, en lo que respecta al área de trabajo al que van asistir y los procedimientos que en ella deban seguir. De la misma forma, también la empresa contará con una herramienta que le provea los reportes de las contingencias ejecutadas, lo que será de gran ayuda cuando se estudien los resultados de la operación y se tomen medidas para mejorar la toma de decisiones cuando se presenten nuevas emergencias con las mismas características y dentro del mismo escenario. Gracias a todo esto, la C.A. Metro de Caracas contará con un sistema de información que le ayudará a mantener el servicio comercial bajo situaciones de emergencia, lo cual es vital ya 98

que la detención de dicho servicio es causal de una emergencia más grande que es la cancelación del 30% del transporte urbano durante un tiempo que mientras mas largo sea, más tráfico y caos originará en la ciudad. AVII.2. CONTEXTO DEL NEGOCIO La C.A. Metro de Caracas es una empresa del estado cuyo negocio se basa en el transporte de usuarios en el Área Metropolitana a través de un sistema ferroviario subterráneo y un sistema de transporte terrestre. El Sistema de Activación, Control y Seguimiento de Planes de Contingencia se desarrolló para lograr la automatización de todos aquellos procesos que son críticos a la hora de una emergencia, como lo son: la comunicación rápida y efectiva del suceso y los procedimientos a seguir por las personas involucradas, la administración confiable de todos los recursos humanos y la puesta en marcha de planes de seguridad y de logística que sean requeridos. Además de ayudar a evaluar el histórico de las contingencias ejecutadas que sirvan de soporte para el desarrollo de nuevas estrategias de acción y de planificación. Por otra parte, el sistema es pionero en la empresa en lo que respecta a la utilización de un componente tecnológico dentro del área de las comunicaciones inalámbricas como lo son los teléfonos celulares, cuya utilización ha aumentado vertiginosamente en Venezuela con el apoyo del servicio de mensajes cortos (SMS). El artefacto a entregar en el Contexto del Negocio es el Modelo de Casos de Uso del Negocio, el cual permite definir los principales entes que intervienen en los procesos del negocio. La figura AVII.1 muestra dicho modelo.

99

Figura AVII.1. Modelo de Casos de Uso del Negocio AVII.3. RESTRICCIONES DEL DESARROLLO Este proyecto presenta como principal restricción la lentitud con que se realiza el proceso para la contratación de los servicios de una Empresa Integradora de Telecomunicaciones, la cual será la encargada de establecer un “puente” para que el sistema ejecute el envío de mensajes de texto (SMS) al personal requerido en una contingencia. A pesar de que durante la pasantía se concretaron reuniones con 5 empresas que actualmente ofrecen el servicio de mensajería de texto ya sea para uso comercial o empresarial, además de haber recogido diferentes propuestas para la construcción de la capa de comunicaciones requerida para ejecutar el servicio, no se logro por lo menos la autorización para realizar pruebas con estas empresas, que era fundamental para evaluar la eficiencia de los mensajes de texto cuando se activa un plan específico.

100

APÉNDICE VIII. PLAN CREATIVO Esta sección tiene por finalidad proveer toda la información referente al diseño de las interfaces de la aplicación. Se toman en cuenta aspectos como atributos de la interfaz (colores, formas y botones), idioma requerido y distribución de los elementos. Uno de los requerimientos complementarios de la aplicación es la facilidad de uso, por lo cual el diseño de la interfaz debe resultar lo más amigable posible para el usuario. En la siguiente sección se presentan las decisiones de diseño tomadas para garantizar que la aplicación cumpla con este requerimiento y con los estándares definidos por la organización. AVIII.1. DISTRIBUCIÓN DE LA INTERFAZ A pesar de que las opciones de uso brindadas por la aplicación son notablemente diferentes entre sí, se aplico un estilo prediseñado por la Gerencia de Sistemas de Información para las aplicaciones web que tengan relación con la página principal de la Intranet, de hecho, parte de la visión del sistema es que su acceso sea a través de dicha página. Por lo tanto, es importante que, en búsqueda de la comodidad del usuario con la interfaz de la aplicación, sea conveniente que la misma sea lo más parecida a las interfaces ya diseñadas para las aplicaciones web desarrolladas en la C.A. Metro de Caracas. Las ventanas de la aplicación podrían dividirse entonces en: Ventana Principal, Ventana de Opciones de la Aplicación, Ventanas de Opciones de Búsqueda, Ventana de Listado de Datos y Ventana de Introducción de Datos. Ventana Principal Para la interfaz de esta ventana, se aplica un diseño que plantea mantener el logo e imagen que representa al sistema en la parte superior central, y en la parte inferior el formulario para la introducción del nombre de usuario y la contraseña con sus respectivos botones para ejecutar o cancelar el acceso a la aplicación.

101

Ventana de Opciones de la Aplicación Según el tipo de ingreso (Administrador o Personal) esta ventana tendrá un número determinado de opciones, aunque siempre estas estarán ubicadas en el marco vertical izquierdo de la interfaz, dejando el marco central para presentar la imagen representativa del sistema (presentada cuando se accede desde la Ventana Principal) o para la presentación del resto de las ventanas en donde se manejan las funcionalidades de la aplicación. Ventanas de Opciones de Búsqueda Estás ventanas son presentadas para los casos de búsqueda de personal, búsqueda de usuarios y búsqueda de asistencia del personal, dado que representan el conjunto de datos más numerosos y a los que se les puede aplicar más patrones de búsqueda. El diseño de este tipo de ventanas comprende la división en marcos horizontales de las características que representarán los filtros de búsqueda, comenzando siempre desde arriba con la característica más general hacia la más específica, para finalizar en la parte inferior con los correspondientes botones para ejecutar la búsqueda o regresar a la ventana anterior según sea el caso. Ventana de Listado de Datos Luego de definir los filtros y ejecutar la búsqueda se presentan la ventana de listado de datos, en donde se puede visualizar en la parte superior el nombre que representa el conjunto de datos, por ejemplo: asistencia del personal, usuarios, etc., para luego presentar en un marco central los nombres de las características (por ejemplo: cédula, nombres, apellidos, área de trabajo, etc.) y línea por línea los datos encontrados. En el caso de que una de las características sea posible editarla, como ocurre en la presentación de la asistencia del personal en donde una de ellas es la característica “liberado”, esta será representada por una casilla de verificación y si el usuario decide activar una o varias de estas casillas podrá guardar estos cambios luego de hacer clic al botón “guardar”, el cual será mostrado en la parte inferior de la interfaz al final del listado de datos. Otro botón que también será presentado en el mismo lugar, es el botón “regresar”, que permite al usuario devolverse a la ventana de opciones de búsqueda.

102

Ventana de Introducción de Datos Esta ventana contempla una de las funcionalidades más importantes del sistema la cual es la carga de datos por parte del usuario. Estas ventanas deben presentar algunos atributos para, por ejemplo, asegurar la comodidad visual al usuario, o cumplir con estándares de la organización, entre otros. En lo que sigue se presentan las decisiones tomadas para estos atributos. AVIII.2. ATRIBUTOS DE LA INTERFAZ Los principales aspectos a considerar en este punto son: Color: se plantea el uso de los colores del estilo prediseñado por la Gerencia de Sistemas de Información para el desarrollo de Aplicaciones Web que tendrán acceso a través de la Intranet. Entre estos colores se destaca el naranja para los enlaces, el azul marino para el texto y el gris claro para los fondos de los recuadros. Botones: por las mismas razones expuestas anteriormente, los botones propuestos son los predeterminados por el estilo de la empresa para estas aplicaciones. Fuentes: los tipos de letra que se encuentran predeterminados en el estilo son Arial y Sans-serif, en tamaños 10, 11 ó 12, dependiendo del tipo de interfaz que se presente.

103

APÉNDICE IX. DOCUMENTO DE ARQUITECTURA DEL SOFTWARE Este documento provee una descripción arquitectural comprensible del sistema, usando un número de vistas arquitecturales diferentes para describir los diferentes aspectos del sistema. Es principalmente desarrollado durante la fase de elaboración, ya que uno de los propósitos de este documento es establecer una fundamentación arquitectural. (Kruchten, 2003). AIX.1. VISTA DE CASOS DE USO Técnicamente, un caso de uso describe una secuencia de acciones, llevadas a cabo por un sistema, que producen un resultado de valor al usuario. En otras palabras, los casos de uso describen una serie de interacciones entre un usuario y el sistema, que ayudan al usuario a llevar a cabo la tarea deseada. El caso de uso describe cómo usuario y sistema trabajan juntos para realizar una actividad. (Leffingwell, 2000) Antes de presentar los casos de uso de la aplicación desarrollada, es importante aclarar cuáles son los aspectos que interactuarán con esta aplicación. La tabla AIX.1 muestra esta información. ACTOR DESCRIPCIÓN Administrador Encargado de la administración de la aplicación específicamente en lo que concierne a la configuración, activación, control y seguimiento de los planes de contingencia, así como también del análisis de los reportes originados de los planes ejecutados. Personal Son las personas que integran todo el personal de confianza y operativo de la C.A. Metro de Caracas, facultado para la utilización del sistema y que podría recurrir a el para realizar el reporte de asistencia de una contingencia, repasar el área de trabajo al que fue asignado, actualizar ciertos datos personales (números telefónicos, dirección, etc.) y revisar su participación en contingencias pasadas. Tabla AIX.1. Actores de SISCON Estos actores activan distintos casos de uso, a continuación se presentan los casos de uso correspondientes para cada actor en la tabla AIX.2.

104

ACTOR

CASO DE USO Activar Contingencia Consultar Contingencia en Proceso Configurar Características de las Contingencias Administrador Administrar Usuarios Administrar Personal Administrar Cuerpos de Seguridad Consultar Reportes de Contingencias Anteriores Reportar Asistencia Consultar Reportes de Asistencia de Contingencias Anteriores Personal Modificar Datos de Usuario Modificar Datos Personales Consultar Asignaciones de Trabajo Tabla AIX.2. Casos de Uso de SISCON La tabla AIX.3 muestra una pequeña descripción de estos casos de uso. El modelo inicial de casos de uso de la aplicación SISCON se muestra en la figura AIX.1. CASO DE USO Activar Contingencia

DESCRIPCIÓN Se refiere a la introducción de todas las características de la contingencia presentada, para ejecutar la activación en el sistema de la misma. Consultar Contingencia Concierne al control de la contingencia, en específico, el chequeo de la en Proceso asistencia del personal, el manejo de las asignaciones de trabajo y las áreas de trabajo, el manejo de la logística y los insumos, entre otros. Configurar El administrador puede introducir, identificar y editar características Características de las como los orígenes y escenarios de las contingencias, así como definir Contingencias los nombres de los grupos del personal de la empresa y las áreas de trabajo. Administrar Usuarios Con este caso de uso se le permite al administrador ingresar nuevos usuarios y asociarlos con un integrante del personal de la empresa (obligatorio), también puede definir el perfil de cada uno y realizar el cambio de contraseña. Administrar Personal Se podrá consultar con búsquedas específicas, los datos personales de cualquier integrante del personal de confianza y operativo de la C.A. Metro de Caracas, además de servir para asignar las labores y las áreas de trabajo a cada integrante según los escenarios propuestos para las contingencias. Administrar Cuerpos de El sistema permitirá introducir y consultar los datos de los cuerpos de Seguridad seguridad que asisten y apoyan a la empresa durante una contingencia. 105

Consultar Reportes de Contingencias Anteriores Reportar Asistencia Consultar Reportes de Asistencia de Contingencias Anteriores Modificar Datos de Usuario Modificar Datos Personales Consultar Asignaciones de Trabajo

Se refiere a la consulta de todos los reportes generados luego de la conclusión de una contingencia, como por ejemplo, la asistencia del personal, las observaciones del plan, el desarrollo de los planes de logísticas y seguridad, entre otros. Un usuario con perfil “personal”, podrá acceder al sistema a través de intranet en el área de trabajo al que fue asignado en la activación de una contingencia, para reportar su asistencia en el sitio. Un usuario con perfil “personal”, podrá revisar su participación en contingencias ejecutadas, así como también consultar las áreas de trabajo al que fue asignado en esas oportunidades. Un usuario con perfil “personal” podrá modificar su contraseña si lo desea. Un usuario con perfil “personal” podrá actualizar ciertos datos como números telefónicos, correo electrónico personal, dirección de habitación, etcétera. Un usuario con perfil “personal”, podrá consultar las asignaciones y las áreas de trabajo que le han sido predefinidas según los escenarios posibles de contingencias futuras. Tabla AIX.3. Descripción de los casos de uso

106

Figura AIX.1. Modelo Inicial de Casos de Uso: SISCON

107

Estos Casos de Uso pasaron por un proceso de refinamiento, la tabla AIX.4 muestra el resultado de este refinamiento y la relación entre los casos de uso refinados. CASO DE USO Activar Contingencia Reportar Asistencia

Consultar Contingencia en Proceso

Configurar Reportes de Asistencia de Contingencias Anteriores Administrar Usuarios Modificar Datos de Usuario Administrar Personal Modificar Datos Personales Consultar Asignaciones de Trabajo Consultar Reportes de Contingencias Anteriores Administrar Cuerpos de Seguridad Consultar Asistencia de Personal

CASO DE USO Validar Usuario Configurar Características de Contingencia Editar Activación del Personal Configurar Planes de Seguridad Validar Usuario Validar Usuario Administrar Observaciones Desactivar Contingencia Configurar Planes de Seguridad Consultar Asistencia del Personal Configurar Logística Validar Usuario

RELACIÓN Includes Includes Extends Extends Includes Includes Extends Extends Extends Extends Extends Includes

Validar Usuario Validar Usuario Validar Usuario Validar Usuario Validar Usuario Validar Usuario

Includes Includes Includes Includes Includes Includes

Validar Usuario Reasignar Personal

Includes Extend

Tabla AIX.4. Casos de Uso Refinados de SISCON En la figura AIX.2 se presenta el modelo refinado de Casos de Uso de la Aplicación Web SISCON.

108

Figura AIX.2. Modelo Refinado de Casos de Uso: SISCON En lo que sigue se presenta la descripción de cada uno de estos Casos de Uso, siguiendo el formato propuesto por Larman (1999).

109

Autor: Argenis Rodríguez CASO DE USO Actor(es) Tipo Descripción

Fecha: Octubre 2005

Activar Contingencia

Administrador Primario – Esencial Configura las características de la contingencia presentada e inicia el proceso de información a todo el personal requerido para asistir a la operación especial. Referencia Requerimiento Funcional 4: Activación de un Plan de Contingencia Requerimiento Funcional 4.1: Configuración de la activación de un Plan de Contingencia Requerimiento Funcional 4.2: Configuración del personal participante Precondición El actor es un usuario válido Curso Normal de los Eventos Acciones del Actor Respuesta del Sistema 1. El caso de uso se inicia cuando el actor hace clic en el enlace “Activar Contingencia. 2. Muestra un formulario para ingresar el nombre, el origen, el escenario y la descripción de la contingencia a activar. 3. Presenta los botones de acceso para configurar o editar otras opciones de la activación como: activación de grupos, activación de personal, ingresar un plan de seguridad o asignar coordinadores de la contingencia. 4. Para cada uno de los campos presentados en el formulario, llena o selecciona los datos correspondientes. 5. Presiona el botón “ACTIVAR”.

110

6. Presenta una nueva ventana con los datos de la contingencia ingresados y con los botones de acceso para consultar las opciones de la activación que estaban preconfiguradas o modificadas por el usuario según haya sido el caso.

7. Habilita nuevamente el botón “ACTIVAR” para que el usuario confirme la activación de la contingencia. 8. Presiona nuevamente el botón “ACTIVAR” para confirmar la activación de la contingencia. 9. El caso de uso finaliza cuando la aplicación muestra una ventana con los datos ingresados de la contingencia y el resultado exitoso de la activación del plan. Curso Alterno En el paso 4, el usuario puede decidir editar algunas de las opciones preconfiguradas de la activación, como por ejemplo: la activación de grupos, la activación de personal, ingresar un plan de seguridad, consultar un plan de seguridad ingresado o asignar los coordinadores de la contingencia. Para cada una de estas opciones, en su ventana correspondiente el usuario puede hacer clic en el botón “GUARDAR” o en el caso de los planes de seguridad en el botón “INGRESAR”, de modo tal que el usuario pueda regresar a la página inicial y mantener todas las modificaciones hechas por el al momento de la activación. En el paso 8, el usuario puede cancelar la activación y eliminar todas las configuraciones hechas si presiona el botón “CANCELAR”. Postcondiciones: • La contingencia activada se encuentra en la lista de contingencias en proceso. Casos de Uso Relacionados: • Editar Activación del Personal. • Configurar Planes de Seguridad. Tabla AIX.5. Caso de Uso: Activar Contingencia Fuente: Elaboración Propia Autor: Argenis Rodríguez CASO DE USO Actor(es) Tipo Descripción Referencia

Fecha: Octubre 2005

Reportar Asistencia Personal Primario - Esencial Permite al usuario notificar su asistencia al área de trabajo asignada durante la ejecución de un Plan de Contingencia. Requerimiento Funcional 6: Reporte de asistencia del personal solicitado 111

Precondición El actor es un usuario válido Curso Normal de los Eventos Acciones del Actor 1. El caso de uso se inicia cuando el usuario selecciona una contingencia en proceso en la sección “Reportar Asistencia - Contingencia en Proceso”.

Respuesta del Sistema

2. Muestra una pantalla con los datos personales del trabajador y de su asignación en la contingencia actual, la cual define el área de trabajo, la dirección física y el nombre del Plan de Contingencia. 3. Presiona el botón “Actualizar Fecha / Hora”. 5. Presiona el botón “Modificar”.

4. Actualiza la Fecha/Hora de Llegada con la hora actual. 6. Muestra el mensaje “MODIFICACIÓN EXITOSA”.

7. El caso de uso finaliza cuando la aplicación realiza la operación solicitada por el usuario y muestra nuevamente la pantalla con los datos del trabajador y de su asignación. Curso Alterno En el paso 3, el usuario puede presionar el botón “Consultar movimientos”, para consultar la lista de asignaciones de trabajo que ha tenido durante la contingencia actual. Postcondiciones: • Los datos de la asistencia del personal, reflejan la fecha y hora de llegada a su área de trabajo. Casos de Uso Relacionados: Ninguno Tabla AIX.6. Caso de Uso: Reportar Asistencia Fuente: Elaboración Propia

112

Autor: Argenis Rodríguez CASO DE USO Actor(es) Tipo Descripción

Fecha: Octubre 2005

Consultar Contingencia en Proceso

Administrador Primario - Esencial Permite al Administrador del Sistema o Coordinador de una contingencia administrar y controlar la ejecución de un Plan de Contingencia. Referencia Requerimiento Funcional 8: Consulta de la asistencia del personal solicitado Requerimiento Funcional 9: Ingreso de Planes de Seguridad Requerimiento Funcional 10: Desactivación de un Plan de Contingencia Precondición El actor es un usuario válido Curso Normal de los Eventos Acciones del Actor Respuesta del Sistema 1. El caso de uso se inicia cuando el actor selecciona una contingencia en la sección “Contingencia en Proceso”. 2. Muestra los datos del Plan de Contingencia y las opciones: - Activar Plan de Seguridad. - Consultar Plan de Seguridad. - Consultar Asistencia de Personal. - Administrar Logística. - Administrar Observaciones. - Editar Configuración de la activación. - Desactivar Contingencia. 3. Selecciona la opción que desea utilizar. 4. Presenta una nueva ventana para ejecutar la opción seleccionada. 5. El caso de uso finaliza cuando la aplicación muestra una ventana para que el usuario lleve a cabo el control de la opción seleccionada. Curso Alterno Ninguno Postcondiciones: • El usuario elije una opción para llevar a cabo una tarea de administración en la contingencia actual. 113

Casos de Uso Relacionados: • Configurar Planes de Seguridad • Consultar Asistencia del Personal • Administrar Observaciones • Desactivar Contingencia Tabla AIX.7. Caso de Uso: Consultar Contingencia en Proceso Fuente: Elaboración Propia Autor: Argenis Rodríguez CASO DE USO Actor(es) Tipo Descripción

Fecha: Octubre 2005

Consultar Reportes de Asistencia de Contingencias Anteriores

Personal Primario - Esencial Permite a los trabajadores consultar los datos de sus participaciones en Planes de Contingencia ejecutados. Referencia Requerimiento Funcional 7: Consulta de asignaciones de trabajo del personal Precondición El actor es un usuario válido Curso Normal de los Eventos Acciones del Actor Respuesta del Sistema 1. El caso de uso se inicia cuando el usuario selecciona una contingencia ejecutada en la sección “Reportes de Asistencia de Contingencias Anteriores”. 2. Muestra una pantalla con los datos personales del trabajador y la asignación que tuvo en la contingencia ejecutada, la cual define el área de trabajo, la dirección física y el nombre del Plan de Contingencia. 3. El caso de uso finaliza cuando la aplicación muestra los datos de la asignación del trabajador en la contingencia ejecutada y también muestra la opción para consultar los movimientos de áreas de trabajo que tuvo. 114

Curso Alterno En el paso 3, el usuario puede hacer clic al botón “Consultar movimientos”, luego el sistema mostrará una lista con los datos de los movimientos que tuvo en la contingencia incluyendo las áreas de trabajo y la fecha y hora de los reportes. Postcondiciones: • El trabajador consulta su asistencia en un Plan de Contingencia ejecutado. Casos de Uso Relacionados: Ninguno Tabla AIX.8. Caso de Uso: Consultar Reportes de Asistencia de Contingencias Anteriores Fuente: Elaboración Propia Autor: Argenis Rodríguez CASO DE USO Actor(es) Tipo Descripción

Fecha: Octubre 2005

Administrar Usuarios

Administrador Primario - Esencial Permite a los administradores del sistema ingresar y consultar usuarios al sistema. Referencia Requerimiento Funcional 1: Perfiles de Usuario Precondición El actor es un usuario válido Curso Normal de los Eventos Acciones del Actor Respuesta del Sistema 1. El caso de uso se inicia cuando el usuario hace clic en el enlace “Administrar Usuarios”. 2. Muestra una pantalla con la opción “Ingresar Usuario” y con un buscador de usuarios para realizar la consulta de aquel que se requiera. 3. El usuario hace clic en la opción “Ingresar Usuario”.

115

4. Muestra un formulario para introducir los siguientes datos de un usuario: - Cédula - Nombre de usuario - Contraseña - Nombre - Apellido - Perfil

5. El usuario llena el formulario y hace clic en el botón “INGRESAR”.

6. Muestra el mensaje “INGRESO EXITOSO”.

7. El caso de uso finaliza cuando la aplicación ingresa correctamente los datos de un nuevo usuario. Curso Alterno En el paso 3, el usuario puede llenar los datos de los filtros del buscador, luego hacer clic en el botón “BUSCAR” y cuando la aplicación muestre la lista de los usuarios encontrados, hacer clic en el botón de consulta del usuario requerido para que el sistema le presente una pantalla con los datos del mismo. En esta pantalla, puede llevar a cabo tareas como modificación de la contraseña, modificación del perfil o eliminar al usuario. Postcondiciones: • El administrador ingresa, consulta o modifica los datos de un usuario. Casos de Uso Relacionados: Ninguno Tabla AIX.9. Caso de Uso: Administrar Usuarios Fuente: Elaboración Propia Autor: Argenis Rodríguez CASO DE USO Actor(es) Tipo Descripción

Fecha: Octubre 2005

Administrar Personal

Administrador Primario - Esencial Permite al administrador del sistema, ingresar y consultar los datos de los trabajadores de la empresa, al igual que ingresar y consultar las asignaciones de trabajo correspondientes a dichos trabajadores dependiendo de los tipos de contingencia (escenarios) en que puedan participar. Referencia Requerimiento Funcional 2: Actualización de Datos Precondición El actor es un usuario válido Curso Normal de los Eventos Acciones del Actor Respuesta del Sistema 1. El caso de uso se inicia cuando el usuario hace clic en el enlace “Administrar Usuarios”. 2. Muestra una pantalla con las opciones para consultar los 116

datos de un integrante del personal, además de una sección para buscar a los trabajadores que participarán en una contingencia dependiendo del escenario y el grupo que se escoja. 3. El usuario selecciona el escenario. 4. Llena la lista de los grupos de personal asociados al escenario elegido. 5. El usuario elige el grupo de personal. 6. Muestra una lista con el personal asociado al grupo elegido y con sus asignaciones respectivas a las contingencias que se presenten con el escenario elegido anteriormente. 7. El usuario selecciona al personal al cual desea consultar su asignación de trabajo. 8. Muestra una pantalla con los datos del trabajador elegido, además también muestra los datos de la asignación de trabajo, como: - Área de Trabajo - Activar (Si/No) - Turno - Descripción de Asignación de Personal. 9. Si el usuario lo desea, realiza las modificaciones correspondientes a la asignación del trabajador. 10. Hace clic al botón “Modificar” 11. Muestra el mensaje “MODIFICACIÓN EXITOSA”. 12. El caso de uso finaliza 117

cuando la aplicación realiza correctamente la modificación de la asignación del personal. Curso Alterno En el paso 3, el usuario puede hacer clic en el enlace “Ingresar personal – Metro”, luego la aplicación mostrará un formulario para que se ingresen los datos de un nuevo trabajador del metro o se consulte los datos uno de ellos si se introduce una cédula que ya exista en la base de datos. En el paso 10, el usuario puede hacer clic en el botón “Eliminar” para eliminar la asignación del personal de la contingencia que se presente con el escenario elegido anteriormente. Posteriormente la aplicación presentará el mensaje “ELIMINACIÓN EXITOSA”. Postcondiciones: • El administrador ingresa, consulta o modifica los datos de un usuario o de su asignación de trabajo respectiva a un escenario seleccionado. Casos de Uso Relacionados: Ninguno Tabla AIX.10. Caso de Uso: Administrar Personal Fuente: Elaboración Propia Autor: Argenis Rodríguez CASO DE USO Actor(es) Tipo Descripción

Fecha: Octubre 2005

Consultar Reportes de Contingencias Anteriores

Administrador Primario - Esencial Permite al administrador del sistema consultar los datos y los resultados de una contingencia ejecutada. Referencia Requerimiento Funcional 11: Mantener el historial de los planes ejecutados Precondición El actor es un usuario válido Curso Normal de los Eventos Acciones del Actor Respuesta del Sistema 1. El caso de uso se inicia cuando el usuario selecciona una contingencia ejecutada en la sección “Reportes de Contingencias Anteriores”. 2. La aplicación muestra una pantalla con los datos del Plan de Contingencia ejecutado y con 4 (cuatro) opciones de consulta, que son: - Consultar Plan de Seguridad - Consultar Asistencia de 118

Personal - Administrar Observaciones - Administrar Logística 3. Selecciona la opción que desea utilizar.

4. Presenta una ventana para ejecutar la opción seleccionada.

5. El caso de uso finaliza cuando la aplicación muestra una ventana para que el usuario lleve a cabo la consulta de la opción seleccionada. Curso Alterno Ninguno Postcondiciones: • El usuario elije una opción para llevar a cabo una consulta de la contingencia ejecutada. Casos de Uso Relacionados: Ninguno Tabla AIX.11. Caso de Uso: Consultar Reportes de Contingencias Anteriores Fuente: Elaboración Propia Autor: Argenis Rodríguez CASO DE USO Actor(es) Tipo Descripción

Fecha: Octubre 2005

Validar Usuario

Administrador, Personal Primario - Esencial Restringe el acceso a la aplicación. Sólo se permitirá el acceso a usuarios autorizados, además determina las funcionalidades a habilitarle al usuario, dependiendo de su perfil. Referencia Requerimiento Funcional 1: Perfiles de Usuario Precondición Ninguna Curso Normal de los Eventos Acciones del Actor Respuesta del Sistema 1. El caso de uso se inicia cuando actor ingresa a la aplicación e introduce su nombre de usuario y contraseña. 2. Verifica si los datos 119

3. Selecciona la opción que desea realizar.

introducidos son correctos. Si el usuario es válido se muestra la ventana de la aplicación en la cual estarán las funcionalidades a las cuales tiene acceso el usuario. 4. Procesa la opción seleccionada por el usuario.

5. El caso de uso finaliza cuando el sistema procesa la opción seleccionada. Curso Alterno En el paso 2, si el usuario no introduce datos válidos la aplicación desplegará un mensaje de error y le dará la opción al usuario de volver a introducir sus datos. Postcondiciones: • Se muestra la ventana inicial de la aplicación con las funcionalidades respectivas al perfil del usuario que esa ingresando. Casos de Uso Relacionados: • Activar Contingencia • Reportar Asistencia • Consultar Contingencia en Proceso • Consultar Reportes de Asistencia de Contingencias Anteriores • Administrar Usuarios • Administrar Personal • Consultar Reportes de Contingencias Anteriores Tabla AIX.12. Caso de Uso: Validar Usuario Fuente: Elaboración Propia Autor: Argenis Rodríguez CASO DE USO Actor(es) Tipo Descripción

Fecha: Octubre 2005

Configurar Características de Contingencias

Administrador Primario - Esencial Permite al administrador ingresar y consultar datos generales para configurar la activación de un Plan de Contingencia. Referencia Requerimiento Funcional 3: Configuración de las Características de las Contingencias Precondición El actor es un usuario válido Curso Normal de los Eventos Acciones del Actor Respuesta del Sistema 1. El caso de uso se inicia 120

cuando el usuario hace clic en el enlace “Configurar Características de la Contingencia”. 2. Muestra una pantalla con opciones para ingresar y consultar características como: - Origen de una contingencia. - Escenario que se presenta en una contingencia. - Grupos de personal. - Área de Trabajo. 3. Selecciona la opción que desea realizar.

4. Muestra la pantalla con el formulario que presenta los datos de la característica seleccionada.

5. El caso de uso finaliza cuando el sistema procesa la opción seleccionada. Curso Alterno Ninguno. Postcondiciones: • El usuario elije una opción para llevar a cabo un ingreso o consulta de característica de una contingencia. Casos de Uso Relacionados: • Activar Contingencia Tabla AIX.13. Caso de Uso: Configurar Características de Contingencias Fuente: Elaboración Propia Autor: Argenis Rodríguez CASO DE USO Actor(es) Tipo Descripción Referencia Precondición

Fecha: Octubre 2005

Administrar Observaciones Administrador Primario - Esencial Permite al administrador ingresar y consultar observaciones y tipos de observaciones. Ninguno El actor es un usuario válido y se encuentra consultando una contingencia en 121

proceso Curso Normal de los Eventos

Acciones del Actor 1. El caso de uso se inicia cuando el usuario hace clic en el enlace “Administrar Observaciones”. 3. Selecciona la opción que desea realizar.

Respuesta del Sistema

2. Muestra una pantalla con opciones para ingresar y consultar observaciones y tipos de observaciones. 4. Muestra la pantalla con el formulario para ingresar una observación o tipo de observación.

5. Llena el formulario. 6. Presiona el botón “INGRESAR”

7. Muestra el mensaje “INGRESO EXITOSO” 8. El caso de uso finaliza cuando la aplicación realiza correctamente el ingreso de la observación o el tipo de observación. Curso Alterno En el paso 3, el usuario aparte de elegir la opción de ingreso de observación o tipo de observación, también puede elegir la opción de consulta, la cual también le presentará una pantalla con un formulario pero esta vez ya esta completo con los datos de la observación o el tipo de observación según haya sido su elección. Si el usuario decide modificar algunos datos procederá a presionar el botón “MODIFICAR”, posteriormente el sistema le indicara el resultado exitoso o no de la modificación. Postcondiciones: • El usuario lleva a cabo la administración de las observaciones Casos de Uso Relacionados: • Consultar Contingencia en Proceso Tabla AIX.14. Caso de Uso: Administrar Observaciones Fuente: Elaboración Propia Autor: Argenis Rodríguez CASO DE USO Actor(es)

Fecha: Octubre 2005

Desactivar Contingencia Administrador 122

Tipo Descripción

Primario - Esencial Permite al administrador desactivar y finalizar la ejecución de una contingencia en Proceso. Referencia Requerimiento Funcional 10: Desactivación de un Plan de Contingencia Precondición El actor es un usuario válido y se encuentra consultando una contingencia en proceso Curso Normal de los Eventos Acciones del Actor Respuesta del Sistema 1. El caso de uso se inicia cuando el usuario hace clic en el enlace “Desactivar Contingencia”. 2. Muestra una pantalla con los datos de la contingencia y con la pregunta “¿Está seguro que desea desactivar la contingencia?”. También muestra los botones de confirmación “Desactivar” y “Cancelar”. 3. El usuario hace clic en el botón “Desactivar”. 4. Muestra el mensaje de notificación “Desactivación Exitosa”. 5. El caso de uso finaliza cuando la aplicación muestra una ventana con los datos de la contingencia y el resultado exitoso de la desactivación del plan. Curso Alterno En el paso 3, el usuario puede decidir cancelar la desactivación de la contingencia haciendo clic en el botón “Cancelar”, esta acción hace que el sistema se devuelva a la ventana de administración de la contingencia en proceso. Postcondiciones: • El plan de contingencia en ejecución es desactivado y entra en la lista de contingencias ejecutadas. Casos de Uso Relacionados: • Consultar Contingencia en Proceso Tabla AIX.15. Caso de Uso: Desactivar Contingencia Fuente: Elaboración Propia

123

Autor: Argenis Rodríguez CASO DE USO Actor(es) Tipo Descripción Referencia

Fecha: Octubre 2005

Editar Activación del Personal

Administrador Primario - Esencial Permite seleccionar al personal que será activado en un Plan de Contingencia. Requerimiento Funcional 4: Activación de un Plan de Contingencia Requerimiento Funcional 4.2: Configuración del personal participante Precondición El actor es un usuario válido y se encuentra activando un Plan de Contingencia Curso Normal de los Eventos Acciones del Actor Respuesta del Sistema 1. El caso de uso se inicia cuando el usuario hace clic en la opción “Editar activación del personal”. 2. Muestra una pantalla con la lista del personal a activar, la cual para cada uno muestra los siguientes datos: - Cédula - Nombre - Apellido - Disponible (Si/No) - Gerencia - Grupo - Área de Trabajo 3. En el dato “Área de Trabajo” de cada uno de los integrantes del personal a activar, se muestra una lista desplegable con las otras áreas de trabajo de la empresa 4. También para cada uno de los integrantes del personal listado, se muestra una casilla de verificación que indica si la persona será activada en esta contingencia. 5. El usuario hace las modificaciones respectivas, incluyendo el marcado o desmarcado de las casillas que indican la participación en la contingencia de cada uno de 124

los trabajadores, o también puede modificar las áreas de trabajo de cada uno de ellos seleccionando otra de sus respectivas listas desplegables. 6. Hace clic en el botón “Guardar”. 7. Guardar la configuración de la activación del personal en la sesión del usuario. 8. El caso de uso finaliza cuando la aplicación se regresa a la ventana con el menú principal para la activación de un Plan de Contingencia. Curso Alterno En el paso 6, el usuario puede decidir restaurar los cambios hechos haciendo clic al botón “Restaurar”, inmediatamente se mostrará nuevamente la pantalla actual pero devolviendo todos los cambios hechos por el usuario desde el momento que ingreso. De igual modo, en el paso el usuario también puede hacer clic en el botón “Regresar”, para retornar al menú principal de la activación sin tomar en cuenta alguna modificación hecha cuando se ingreso. Postcondiciones: • Se configura manualmente la participación y las asignaciones del personal que trabajará en el Plan de Contingencia. Casos de Uso Relacionados: • Activar Contingencia Tabla AIX.16. Caso de Uso: Editar Activación del Personal Fuente: Elaboración Propia

125

Autor: Argenis Rodríguez CASO DE USO Actor(es) Tipo Descripción

Fecha: Octubre 2005

Configurar Planes de Seguridad

Administrador Primario - Esencial Permite al administrador ingresar y consultar los Planes de Seguridad que se deseen activar en conjunto con el Plan de Contingencia. Referencia Requerimiento Funcional 9: Ingreso de planes de seguridad Precondición El actor es un usuario válido y se encuentra activando un Plan de Contingencia o consultando un plan en ejecución. Curso Normal de los Eventos Acciones del Actor Respuesta del Sistema 1. El caso de uso se inicia cuando el usuario hace clic en la opción “Ingresar Plan de Seguridad”. 2. Muestra una pantalla con el formulario correspondiente para hacer el ingreso de un plan de seguridad. Entre los datos a introducir tenemos: - Ubicación - Estación - Tramo - Dirección - Cuerpo de Seguridad - Responsable - Dirección de contacto - Teléfono de contacto - Cantidad de personas - Observaciones 3. El usuario llena el formulario. 4. Hace clic en el botón “INGRESAR”. 5. Muestra la ventana principal de activación o de consulta del Plan de Contingencia, con el plan de seguridad ingresado en la lista de planes de seguridad a consultar. 5. El caso de uso finaliza cuando la aplicación se regresa a la ventana principal de 126

activación o de consulta del Plan de Contingencia. Curso Alterno En el paso 1, el usuario puede decidir consultar un plan de seguridad que este en la lista de planes de seguridad ingresados. Para llevar a cabo esta tarea, el usuario seleccionará el plan de seguridad de la lista descrita y luego el sistema presentará una ventana con los datos del plan y con los botones “Modificar”, “Eliminar” y “Regresar”. Postcondiciones: • Se hará ingreso de un plan de seguridad a un Plan de Contingencia. Casos de Uso Relacionados: • Activar Contingencia • Consultar Contingencia en Proceso Tabla AIX.17. Caso de Uso: Configurar Planes de Seguridad Fuente: Elaboración Propia Autor: Argenis Rodríguez CASO DE USO Actor(es) Tipo Descripción

Fecha: Octubre 2005

Consultar Asistencia del Personal

Administrador Primario - Esencial Permite al administrador consultar el estado de la asistencia de cualquier integrante del personal que haya sido activado en una contingencia. Referencia Requerimiento Funcional 8: Consulta de la asistencia del personal solicitado Precondición El actor es un usuario válido y se encuentra consultando un Plan de Contingencia en proceso. Curso Normal de los Eventos Acciones del Actor Respuesta del Sistema 1. El caso de uso se inicia cuando el usuario hace clic en la opción “Consultar Asistencia del Personal”. 2. Muestra una pantalla con los filtros de un buscador de personal. Estos filtros son: - Nombre, Apellido, Cédula o Carnet. - Ubicación (correspondiente al área de trabajo asignada). - Área de trabajo. - Estado actual (cualquiera, reportado, no reportado) 3. Llena y selecciona los 127

filtros de búsqueda. 4. Presiona el botón “BUSCAR”. 4. Muestra la lista del personal encontrado, cada uno con los siguientes datos: - Cédula - Nombres - Apellidos - Área de Trabajo - Fecha/Hora Reporte - Ubicación - Liberado (casilla marcada o no marcada) 5. También presenta un botón para cada uno de los integrantes del personal encontrado, el cual representa un enlace para acceder a la consulta específica de la asistencia del personal. 6. Si lo desea el usuario puede marcar a los trabajadores que desee liberar. 7. Hace clic en el botón “GUARDAR”.

5. El caso de uso finaliza cuando la aplicación muestra una lista con el personal liberado exitosamente por el usuario.

7. Muestra una lista con el personal liberado exitosamente.

Curso Alterno En el paso 4 y 7, el usuario puede decidir regresar a la ventana anterior haciendo clic en el botón “REGRESAR”. En el caso del paso 7, no se guardarían los cambios realizados en la lista del personal encontrado. También en el paso 7, el usuario puede decidir consultar los detalles de la asistencia de uno de los integrantes del personal listado, de tal manera que pueda realizar las tareas de reporte del trabajador seleccionado o incluso consultar los movimientos que ha tenido durante la ejecución del plan. Postcondiciones: • Se habrán llevado a cabo tareas de consulta, reportes o liberación de la asistencia de uno o varios integrantes del personal buscado por el usuario. Casos de Uso Relacionados: 128

•

Consultar Contingencia en Proceso Tabla AIX.18. Caso de Uso: Consultar Asistencia del Personal Fuente: Elaboración Propia

Autor: Argenis Rodríguez CASO DE USO Actor(es) Tipo Descripción

Fecha: Octubre 2005

Reasignar Personal

Administrador Primario - Esencial Permite al administrador cambiar la asignación de un integrante del personal que este laborando durante un Plan de Contingencia. Referencia Requerimiento Funcional 8: Consulta de la asistencia del personal solicitado Precondición El actor es un usuario válido y se encuentra consultando la asistencia de un trabajador en específico que se encuentre laborando en un Plan de Contingencia. Curso Normal de los Eventos Acciones del Actor Respuesta del Sistema 1. El caso de uso se inicia cuando el usuario hace clic en el botón que corresponde al trabajador del cual se desea consultar su asistencia. 2. Muestra una pantalla con los datos de la asistencia del trabajador seleccionado y con las opciones “Consultar Movimientos” y “Actualizar Fecha / Hora”. 3. El usuario si lo desea modificará la ubicación y el área de trabajo en que se encuentra asignado el trabajador. 4. Presiona el botón “Modificar” 5. Muestra un mensaje de “Modificación Exitosa”. 5. El caso de uso finaliza cuando la aplicación muestra un mensaje notificando al usuario del éxito de la reasignación. 129

Curso Alterno En el paso 3, el usuario puede hacer clic en el botón “Consultar Movimientos” para consultar las reasignaciones que ha tenido el trabajador en el Plan de Contingencia actual, posteriormente el sistema mostrará una lista de estas reasignaciones. También en el paso 3, el usuario puede hacer clic en el botón “Actualiza Fecha / Hora” para llevar a cabo el reporte del personal en la asignación actual. Para este caso el sistema colocará en la casilla “Fecha/hora llegada”, la fecha y hora actual del sistema. En el paso 4, el usuario puede hacer clic en el botón “Regresar” para retornar a la ventana anterior. Postcondiciones: • Se habrá modificado el área de trabajo del trabajador consultado. Casos de Uso Relacionados: • Consultar Asistencia del Personal Tabla AIX.19. Caso de Uso: Reasignar Personal Fuente: Elaboración Propia Autor: Argenis Rodríguez CASO DE USO Actor(es) Tipo Descripción

Fecha: Octubre 2005

Configurar Logística

Administrador Primario - Esencial Permite al administrador controlar y asignar labores de logística durante la ejecución de un Plan de Contingencia. Referencia Ninguno Precondición El actor es un usuario válido y se encuentra consultando un Plan de Contingencia en proceso. Curso Normal de los Eventos Acciones del Actor Respuesta del Sistema 1. El caso de uso se inicia cuando el usuario hace clic en el botón que corresponde a la opción “Administrar Logística”. 2. Muestra una pantalla con los datos del Plan de Contingencia y las opciones de ingreso y consulta de órdenes de distribución de comida e insumo. 3. El usuario presiona el botón de ingreso de distribución de orden de comida o insumo. 130

4. Muestra un formulario para introducir los datos de la orden de distribución de comida o insumo, según como haya sido la elección del usuario. 5. Llena el formulario 6. Presiona el botón “Ingresar”. 7. Muestra el mensaje “Ingreso Exitoso 8. El caso de uso finaliza cuando la aplicación muestra un mensaje notificando al usuario el éxito del ingreso de la orden de distribución de comida o insumo, según como haya sido su elección en el paso 3. Curso Alterno En el paso 3, el usuario puede consultar también una orden de distribución de comida o insumo, las cuales se muestran en unas listas desplegables para que puedan ser seleccionadas. En el paso 6, el usuario puede hacer clic en el botón “Regresar”, para cancelar el ingreso de la orden y retornar a la ventana anterior. Postcondiciones: • Se habrá llevado a cabo tareas de ingreso y consulta de órdenes de distribución de comida o insumo, la cuales son labores de administración y control de la logística del Plan de Contingencia. Casos de Uso Relacionados: • Consultar Contingencia en Proceso Tabla AIX.20. Caso de Uso: Configurar Logística Fuente: Elaboración Propia AIX.2. LA VISTA LÓGICA La vista lógica principalmente soporta los requerimientos funcionales, los servicios que el sistema debería proveer a sus usuarios finales. Los diseñadores descomponen el sistema en un conjunto de abstracciones claves, tomadas del dominio del problema. Estas abstracciones son objetos o clases de objetos que utilizan los principios de abstracción, encapsulación y herencia (Kruchten, 1999). 131

En esta vista se presenta el Diagrama de Clases, la Realización de los Casos de Uso y el Modelo Conceptual. AIX.2.1. REALIZACIÓN DE LOS CASOS DE USO Una vez descritos los casos de uso es conveniente determinar las relaciones e interacciones entre cada uno de los componentes de la aplicación a desarrollar. Para ello UML ofrece los diagramas de interacción que explican gráficamente cómo los objetos interactúan a través de mensajes para realizar los casos de uso (Larman, 1999). Larman (1999) también expone que UML define dos tipos de estos diagramas; ambos sirven para expresar interacciones semejantes o idénticas de mensaje. Estos diagramas son los diagramas de colaboración y los diagramas de secuencia, este último expresa las mismas interacciones entre los objetos del sistema, pero de formas un poco diferentes. Por lo tanto, no se hace necesario hacer uso de los dos tipos de diagramas simultáneamente. Queda entonces decidir cuál de estos diagramas expresa estas interacciones de mejor forma. Por otra parte, según Jacobson et al. (2000), en la fase de diseño es más conveniente representar las interacciones y pase de mensajes entre objetos por medio de los diagramas de secuencia, ya que se centran en encontrar las secuencias de interacciones detalladas y ordenadas en el tiempo. Por lo expuesto anteriormente se decide expresar los diagramas de interacción requeridos en la vista de casos de uso, en términos de diagramas de secuencia.

132

Figura AIX.3. Diagrama de Secuencia: “Activar Contingencia” Fuente: Elaboración Propia

133

AIX.2.2 MODELO CONCEPTUAL Un modelo conceptual explica (a sus creadores) los conceptos significativos en un dominio del problema; es el artefacto más importante a crear durante el análisis orientado a objetos (los caso de uso son un artefacto importante del análisis de requerimientos, pero realmente no están orientados a objetos) (Larman, 1999). La figura AIX.4 muestra el Modelo Conceptual donde se presentan los conceptos asociados al dominio del problema.

Figura AIX.4 Modelo Conceptual Fuente: Elaboración Propia

134

La tabla AIX.21 presenta una pequeña descripción de cada uno de los conceptos del Modelo Conceptual. CONCEPTO Administrador Área de Trabajo Comida Coordinador de Contingencia Cuerpo de Seguridad Escenario Estación Gerencia Grupo Insumo Logística Observación Origen Perfil

Personal Plan Plan de

DESCRIPCIÓN Usuario que tiene acceso y control total del sistema, incluida la administración de cualquier contingencia en proceso. Sitio o lugar de la empresa para la cual se asignan labores específicas a un grupo determinado de personas. Orden de distribución de algún alimento a los trabajadores que asisten a la operación del Plan de Contingencia. Usuario que tiene acceso en el sistema para llevar a cabo la administración y el control de los planes de contingencia que le han sido asignados. Organismo del estado que apoya a la C.A. Metro de Caracas en un Plan de Contingencia, en donde su participación queda determinada dentro de un Plan de Seguridad. Situación que se presenta dentro o fuera de la empresa que origina que se requiera la activación de un Plan de Contingencia. Áreas destinadas por la empresa para el acceso de pasajeros a los ándenes del Metro de Caracas. Unidad de la empresa determinada para llevar a cabo diferentes procesos de la organización. Definición por parte del Administrador de un conjunto de trabajadores de la empresa con una característica o fin en común. Orden de distribución de algún elemento, herramienta, material o transporte que se requiera durante la ejecución de un Plan de Contingencia. Agrupación de todas las labores que se requieran para el mantenimiento de las asignaciones principales en la ejecución de un Plan de Contingencia, por ejemplo: las órdenes de repartición de comida o de insumo. Suceso o característica que valga la pena resaltar en un área de trabajo o en general dentro de un Plan de Contingencia. Característica general que agrupa a ciertos escenarios por la relación que tienen los sucesos que ellos definen y que ocasionan la activación de un Plan de Contingencia. Rasgo que define a un usuario y le permite al sistema determinar el tipo de control y acceso que este tiene en la aplicación. Los perfiles manejados son: Administrador y Personal, pero también se puede presentar provisionalmente a un usuario el perfil Coordinador para que controle un Plan de Contingencia que le haya sido asignado como si fuera Administrador. Se refiere a todos los trabajadores de cualquier tipo que laboran para la C.A. Metro de Caracas. Agrupación de asignaciones y de labores específicas para el mantenimiento o la recuperación de la operación normal de la C.A. Metro de Caracas, cuando se presentan escenarios que ocasionan un estado de contingencia. Asignación específica que se designa a un cuerpo de seguridad del estado 135

Seguridad Tipo de Observación Tramo

para apoyar a la empresa durante la ejecución de un Plan de Contingencia. Definición de una clasificación específica para un grupo de observaciones de un Plan de Contingencia. Sector que agrupa un conjunto de estaciones dentro de una línea del Metro de Caracas. Lugar definido en donde se encuentran físicamente las áreas de trabajo, gerencias o demás unidades de la empresa. Persona registrada por el sistema y que tiene un perfil determinado que le permite consultar o ejecutar diferentes funcionalidades de la aplicación.

Ubicación Usuario

Tabla AIX.21. Descripción de Conceptos del Modelo Conceptual Fuente: Elaboración Propia Una vez definidos y establecidos los conceptos del dominio del problema, se puede construir el diagrama de clases. Seguidamente se presenta el Diagrama de Clases de SISCON. AIX.2.3 DIAGRAMA DE CLASES Un diagrama de clases muestra un conjunto de clases y sus relaciones lógicas, uso de las asociaciones, composición, herencia, entre otros (Kruchten, 2003). Por su parte Larman (1999) expone que el diagrama de clases describe gráficamente las especificaciones de software en una aplicación. Normalmente, contiene la siguiente información: Clases, asociaciones y atributos Métodos Interfaces, con sus operaciones y constantes Información sobre los tipos de los atributos Dependencias Además Larman (1999) explica que a diferencia del modelo conceptual, un diagrama de este tipo contiene las definiciones de las entidades del software en vez de conceptos del mundo real. La figura AIX.5 muestra el diagrama de clases diseñado.

136

Figura AIX.5. Diagrama de Clases Fuente: Elaboración Propia 137

A.IX.3. VISTA DE DATOS En esta sección se presentarán los artefactos elaborados para esta vista, los cuales son: Modelo Entidad – Relación, Diccionario de la Base de Datos y Modelo Relacional. AIX.3.1. MODELO ENTIDAD - RELACIÓN El modelo Entidad – Relación describe los datos como entidades, vínculos y atributos. La entidad es el objeto básico de ER y representa a un objeto del mundo real que tiene existencia independiente, bien sea físico o conceptual. Los atributos son las propiedades particulares que describen a las entidades. Finalmente estas entidades con sus diferentes atributos tienen asociaciones entre sí las cuales son representadas a través de relaciones (Navathe et al., 1997). Navathe et al. (1997) también expone que el Diagrama Entidad – Relación conocido como Diagrama ER, es una notación gráfica para representar el esquema lógico de una base de datos relacional. A pesar de que SISCON depende de la alimentación de datos provenientes de SAP Recursos Humanos, se decidió crear otra base de datos no sólo para reguardar la información del personal de la empresa obtenida en la última actualización, sino también para hacer el repositorio de datos referentes a los nuevos planes de contingencia que se vayan ejecutando y para mantener la configuración de las asignaciones de trabajo dependiendo por supuesto de los grupos de personal y los escenarios propuestos. Sin embargo, también fue necesario mantener datos que son redundantes debido a que se pueden obtener de otras bases de datos de la empresa como por ejemplo: información de las gerencias y demás unidades administrativas, datos de las estaciones y líneas del metro, ubicaciones físicas, datos de los cuerpos de seguridad del estado, etc. La decisión de mantener esta redundancia de datos es porque esta aplicación es un sistema crítico para la empresa durante el desarrollo de una contingencia, la cual también se puede presentar por una falla en los servidores centrales. Por lo tanto, la aplicación debe mantener y guardar algunos datos esenciales (por lo menos localmente) que le permitan operar a pesar de estas condiciones. 138

Las figuras AIX.6 muestra el diagrama Entidad – Relación de la aplicación.

Figura AIX.6. Modelo Entidad – Relación de SISCON Fuente: Elaboración Propia AIX.3.2. DICCIONARIO DE DATOS DE LA BASE DE DATOS Un diccionario de datos es un catálogo, un depósito, de los elementos en una base de datos. En un diccionario de datos se encuentra la lista de todos los elementos que forman parte de la misma junto con su definición, especificación de su tipo y principales características. (Castro, 1997) Esta aplicación es alimentada por una base de datos central y en caso de alguna emergencia que impida la conexión con esta podrá ser alimentada por una base de datos local (en el servidor). Ambas base de datos contendrán las mismas tablas y a su vez periódicamente se

139

actualizarán con los datos de la base de datos de SAP Recursos Humanos, que contiene toda la información referente al personal de la empresa. A continuación en la tabla AIX.22 se presentan todas las tablas que forman parte de la bases de datos de la aplicación, junto con la descripción de los atributos (columnas) de cada una. Nombre del Atributo CP_A_TRAB NOM_A_TRAB DESC_A_TRAB SIGLA_A_TRAB MIN_PERS_A_TRAB TEL_A_TRAB DESC_A_PER ACTIVAR_A_PER TURNO_A_PER FEC_LLEG_A_PER HOR_LLEG_A_PER FEC_NOTIF_A_PER HOR_NOTIF_A_PER LIBER_A_PER COD_CAR DESC_CAR NOM_CAR FEC_CAR_H CP_COM DESC_COM SITIO_CPR_COM CPR_NOM_COM CPR_CED_COM AUTORI_NOM_COM AUTORI_CED_COM REPAR_NOM_COM REPAR_CED_COM FEC_ENTREG_COM HOR_ENTREG_COM SITIO_ALM_COM CP_C_SEG SIGLAS_C_SEG DESC_C_SEG RESP_C_SEG TEL_CTC_C_SEG DIR_CTC_C_SEG CED_EFEC

Tabla area_trabajo area_trabajo area_trabajo area_trabajo area_trabajo area_trabajo asig_personal asig_personal asig_personal asist_per asist_per asist_per asist_per asist_per cargo cargo cargo car_hist comida comida comida comida comida comida comida comida comida comida comida comida cuerpo_seg cuerpo_seg cuerpo_seg cuerpo_seg cuerpo_seg cuerpo_seg efectivo

Tipo de Dato Tamaño Clave Primaria Nulo INTEGER 10 X VARCHAR 45 VARCHAR 100 X VARCHAR 5 INTEGER 10 DECIMAL 10,0 VARCHAR 45 X DECIMAL 1,0 CHAR 1 X DATE X TIME X DATE X TIME X DECIMAL 9,0 X INTEGER 6 X VARCHAR 100 X VARCHAR 45 DATETIME X INTEGER 10 X VARCHAR 45 VARCHAR 45 X VARCHAR 45 X VARCHAR 9 X VARCHAR 45 VARCHAR 9 VARCHAR 45 X VARCHAR 9 X DATE X TIME X VARCHAR 45 X INTEGER 10 X CHAR 3 VARCHAR 100 VARCHAR 45 DECIMAL 10,0 VARCHAR 45 VARCHAR 9 X 140

NOM_EFEC efectivo APELL_EFEC efectivo SEXO_EFEC efectivo DIRECC_EFEC efectivo TEL_HAB_EFEC efectivo TEL_CEL_EFEC efectivo RET_EFEC efectivo DISPO_EFEC efectivo CP_ESCEN escenario NOMBRE_ESCEN escenario DES_ESCEN escenario CP_EST estacion SIGLA_EST estacion NOMBRE_EST estacion COD_GER gerencia NOM_GER gerencia SIGLA_GER gerencia UBIC_GER gerencia DESC_GER gerencia CP_GRUPO grupo NOM_GRUPO grupo DESC_GRUPO grupo CP_HAB habilidad NOM_HAB habilidad DESC_HAB habilidad CP_INS insumo DESC_INS insumo CANT_INS insumo RESP_NOM_INS insumo RESP_CED_INS insumo CP_M_PERSONAL mov_personal FECHA_M_PERSONAL mov_personal HORA_M_PERSONAL mov_personal CP_O_PLAN obser_plan FECHA_O_PLAN obser_plan HOR_O_PLAN obser_plan DESC_O_PLAN obser_plan CP_ORIGEN origen NOM_ORIGEN origen DESC_ORIGEN origen PERFIL_PER perfil DESC_PER perfil CARNET_P personal NOMBRE_P personal APELLIDO_P personal

VARCHAR VARCHAR CHAR VARCHAR DECIMAL DECIMAL DECIMAL DECIMAL INTEGER VARCHAR VARCHAR INTEGER CHAR VARCHAR INTEGER VARCHAR CHAR VARCHAR VARCHAR INTEGER VARCHAR VARCHAR INTEGER VARCHAR VARCHAR INTEGER VARCHAR INTEGER VARCHAR VARCHAR INTEGER DATE TIME INTEGER DATE TIME VARCHAR INTEGER VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR 141

45 45 1 100 18,0 18,0 9,0 9,0 10 45 100 10 3 45 6 100 3 100 100 10 45 100 10 45 100 10 100 10 45 9 10 10 200 10 45 100 18 100 15 45 45

X X X X X X X X

X X X X X X X

X X

X X X

CEDULA_P FECHA_NAC_P SEXO_P DIRECCION_P TELF_HAB_P TELF_CEL_P SINDICAL_P TIPO_NOMINA_P DISPONIBLE_P EMAIL_OFIC_P EMAIL_OTRO_P RETIRADO_P CP_PLAN NOM_PLAN DESC_PLAN FEC_ACT_PLAN HOR_ACT_PLAN FEC_DES_PLAN HOR_DES_PLAN RESP_P_SEG CANT_PER_P_SEG TEL_CTC_P_SEG DIR_CTC_P_SEG OBS_P_SEG COD_T_HAB NOM_T_HAB DESC_T_HAB CP_T_OBSER NOM_T_OBSER DESC_T_OBSER CP_UBIC TRAMO_UBIC DIRECC_UBIC DESC_UBIC COD_U_TRAB DESC_U_TRAB TELEF_U_TRAB LOGIN_USU CONT_USU NOM_USU APELL_USU

personal personal personal personal personal personal personal personal personal personal personal personal plan plan plan plan plan plan plan plan_seg plan_seg plan_seg plan_seg plan_seg tipo_habilidad tipo_habilidad tipo_habilidad tipo_obser tipo_obser tipo_obser ubicacion ubicacion ubicacion ubicacion ubic_trabajo ubic_trabajo ubic_trabajo usuario usuario usuario usuario

VARCHAR DATE CHAR VARCHAR VARCHAR VARCHAR CHAR INTEGER CHAR VARCHAR VARCHAR CHAR INTEGER VARCHAR VARCHAR DATE TIME DATE TIME VARCHAR INTEGER VARCHAR VARCHAR VARCHAR INTEGER VARCHAR VARCHAR INTEGER VARCHAR VARCHAR INTEGER DECIMAL VARCHAR VARCHAR INTEGER VARCHAR DECIMAL VARCHAR VARCHAR VARCHAR VARCHAR

9 1 100 10 10 1 2 1 45 45 1 10 45 100 45 10 10 45 100 10 45 100 10 45 100 10 3,0 45 100 6 100 10,0 16 16 45 45

Tabla AIX.22. Atributos de la Base de Datos SISCON Fuente: Elaboración Propia 142

X

X X X X X X

X X

X X X X X X X X X

AIX.3.3. MODELO RELACIONAL El modelo relacional representa la base de datos como una colección de relaciones. En términos informales, cada relación semeja una tabla o, hasta cierto punto, un archivo simple. Si visualizamos una relación como una tabla de valores, cada fila de la tabla representa una colección de valores de datos relacionados entre sí. Dichos valores se pueden interpretar como hechos que describen una entidad o un vínculo entre entidades del mundo real (Navathe et al., 1997). En la figura AIX.7 se presenta el modelo relacional de la aplicación SISCON.

Figura AIX.7. Modelo Relacional SISCON Fuente: Elaboración Propia 143

AIX.4. VISTA DE PROCESOS La vista de procesos toma en cuenta algunos requerimientos no funcionales, tales como funcionamiento y disponibilidad del sistema. Esta maneja la concurrencia y distribución, integridad del sistema, y tolerancia a fallas. También especifica cuál hilo de control ejecuta cada operación de cada clase identificada en la vista lógica (Kruchten, 1995). Booch (1999), sugiere que en algunos proyectos no es necesario establecer las cinco vistas y además propone ciertas recomendaciones para poder establecer cuáles vistas se deben especificar en el diseño de la arquitectura. La aplicación a desarrollar es una herramienta instalada en un servidor central que accede a otro servidor en el cual se tiene la Base de Datos que alimenta a dicha aplicación. Los clientes a su vez acceden “simultáneamente” al sistema a través de un navegador de páginas web y la concurrencia en este caso es manejada por el DBMS instalado en uno de los servidores y no por la aplicación en sí. Por lo cual la herramienta a desarrollar no posee más de un proceso. Por esta razón, y siguiendo los lineamientos expuestos por Booch en cuanto a la vista de procesos, la misma no será tomada en cuenta en la descripción de la arquitectura, ya que no representa ningún aporte para el desarrollo. Para continuar con la descripción de la arquitectura, en lo que sigue se presentará la Vista Implementación. AIX.5. VISTA DE IMPLEMENTACIÓN La vista de implementación se enfoca en la organización de los módulos reales del software en el ambiente de desarrollo del mismo. El software es empaquetado en pequeños pedazos (librerías o subsistemas) que pueden ser desarrollados por uno o más desarrolladores. Los subsistemas son organizados en jerarquía de capas, en donde cada capa provee una interfaz estrecha y bien definida para las capas superiores (Kruchten, 1995).

144

En esta vista es recomendable definir la arquitectura del software y la distribución de los distintos elementos en las distintas capas que conforman la arquitectura. La arquitectura seleccionada para el desarrollo de este proyecto es la de Cliente/Servidor en su forma avanzada de tres capas. Stevens (1996), propone que existen tres razones primordiales para la selección de las arquitecturas Cliente/Servidor de tres capas, a saber: Las aplicaciones pueden ser particionadas de una manera que se ajuste a las necesidades computacionales de la organización. En vista de que la mayor parte de la lógica está contenida en el servidor de aplicaciones, realzar cambios globales, o personalizar procesos para usuarios individuales, es relativamente fácil. Al tener la lógica separada de la interfaz del usuario, es sumamente fácil cambiar uno, o ambos, sin generar mayores esfuerzos en mantenimiento. La figura AIX.8 muestra el modelo de arquitectura de tres capas.

Figura AIX.8. Arquitectura de tres Capas Fuente: Elaboración Propia

145

La tabla AIX.23 muestra la distribución de los componentes de la aplicación entre las tres capas que componen la arquitectura y las diferentes interfaces de interacción entre las mismas. Capa de Presentación Mediador con Interfaz Páginas Web Formularios Enlaces Interfaz en general

Capa de Lógica Capa de Datos Mediador con Base de Datos Clases Plan Configuración de la Origen Base de Datos Escenario Configuración del estilo Personal Web (XML) Grupo Configuración de la Área de Trabajo seguridad del sistema Gerencia Ubicación Cuerpo de Seguridad Plan de Seguridad Efectivo Insumo Comida Asignación de Personal Observación Tipo de Observación Asistencia de Personal Usuario Perfil Cargo Movimiento de Personal

Tabla AIX.23. Distribución de Clases en las diferentes capas Fuente: Elaboración Propia En la siguiente sección se presenta la descripción de la vista de Implantación. AIX.6. VISTA DE IMPLANTACIÓN La vista de Implantación toma en cuenta los requerimientos no funcionales del sistema tales como disponibilidad del sistema, confiabilidad (tolerancia de fallas), eficiencia (productividad) y escalabilidad (Kruchten, 1995).

146

Como el software se ejecuta en un servidor central y múltiples clientes tendrán acceso a él es muy importante que el sistema sea altamente confiable y como se ha dicho anteriormente, no puede presentar fallas a la hora de una emergencia porque justamente su función es apoyar a la empresa durante la contingencia que busca normalizar la operación. Igualmente se destacan otros aspectos como la eficiencia y la rapidez, dado que otro de los objetivos del proyecto es aumentar y agilizar el flujo de información entre las personas involucradas en la ejecución de un Plan de Contingencia. Se recomienda que los equipos involucrados presenten las siguientes características: •

Servidores El sistema y una base de datos de respaldo se encontrarán en un servidor y la base de

datos principal se encontrará en otro servidor, por lo tanto no solo se recomienda un alto desempeño de procesamiento al servidor que contendrá el sistema y una suficiente capacidad de almacenamiento al que tendrá a la base de datos, sino también que cuenten con una rápida conexión en función de mantener los datos en línea el mayor tiempo posible y por supuesto para poder manejar la gran cantidad de conexiones simultáneas que pueden surgir.

Figura AIX.9. Modelo de Red de SISCON Fuente: Elaboración Propia 147

Los requerimientos mínimos de hardware serían: Memoria RAM de 512 MB 2 GB de espacio libre en disco duro (para el almacenamiento de la data) Procesador Pentium IV de 2.2 GHz En cuanto al software, la empresa ya tiene instalado en sus servidores centrales el Sistema de Gestión de Base de Datos Informix 9 y para la Base de Datos de respaldo se requiere MySQL Server 4.1. Todavía la empresa tiene en estudio (dentro del Proyecto de Utilización de Software Libre) el contenedor de páginas Web a utilizar, por los momentos se han hecho pruebas bastante satisfactorias con Apache HTTP Server el cual está disponible para servidores con sistemas Windows y Linux. •

Cliente Como la aplicación y la base de datos están instaladas en los servidores centrales, la

máquina del cliente no requiere de un software o un hardware especial, solo debe poseer un navegador de páginas Web el cual ha estado disponible en los sistemas Windows y Linux en los últimos años. Sin embargo, se requiere en algunos casos que estos navegadores tengan instalado y habilitado la ejecución de código JavaScript y de un interpretador de formularios y de archivos de estilos Web en formato XML. En resumen los requisitos mínimos de software para la máquina cliente son: Windows 98 o XP. Internet Explorer 5.0 o superior. En cuanto al hardware se requiere lo siguiente: Procesador Pentium III de 500 MHz Memoria RAM de 128 MB

148

APENDICE X. EVALUACIÓN DE LA TECNOLOGÍA DE TELECOMUNICACIONES Como se mencionó en el documento Caso del Negocio, la principal restricción de este proyecto es la necesidad de contratar los servicios de una Empresa Integradora de Telecomunicaciones para realizar las pruebas del envío de mensajes de texto (SMS). Tomando en cuenta esta restricción se procedió a realizar un estudio exhaustivo con diversas empresas del ramo, de modo tal que la C.A. Metro de Caracas no solo pueda contar de una vez con una versión del sistema que le permita tomar el control y la administración de un Plan de Contingencia, sino que también pueda contar con una propuesta detallada de los requisitos necesarios para llevar a cabo la conexión de la aplicación con un Servicio Web que realice este requerimiento tan importante, que a su vez sea el punto de partida para el inicio del trámite que tendrá como objetivo la contratación de los servicios con alguna de las empresas presentadas. A continuación se presenta un resumen de las reuniones con las empresas contactadas y posteriormente las tres posibles alternativas de implementación. Investigación preliminar sobre proveedores y servicios Para la realización del levantamiento de información que permitió construir una serie de propuestas, fue indispensable ubicar a las empresas que ofrecen servicios de mensajería de texto en Venezuela. Una vez obtenida la lista de estas empresas, se analizó y estudió los servicios que ellas ofrecen, para luego concretar reuniones con las que tienen experiencia en proyectos similares con otras empresas en el ámbito nacional, las cuales, al igual que la C.A. Metro de Caracas, requirieron de una aplicación que permitiese comunicarle al personal alertas, noticias o informaciones especiales. Por los momentos, las reuniones que se han realizado fueron con las empresas: DINAMA, UNPLUGGED, IMOLKO y TELEMO, entre los días 23 y 31 de Agosto del 2005.

149

Resultados DINAMA En esta primera reunión, se logró obtener una visión más clara de los servicios ofrecidos por las Empresas Integradoras de Telecomunicaciones (EIT), del mismo modo se pudo conocer que ofrecen también la construcción de una aplicación que cumpla con las necesidades del presente proyecto. En su página Web (http://www.dinama.com), tienen también una aplicación que ofrece los servicios de manejo de grupos de números telefónicos, a los cuales se les desea enviar en masa un mensaje de texto en específico. Explicaron las limitaciones que tienen con diferentes operadoras de telefonía celular, en especial en el caso de DIGITEL que le ofrece a ellos contrataciones de servicio con un mínimo de 10.000 mensajes mensuales, además de que puntualizaron con importancia, que necesitan la lista de números telefónicos a los que se les va a enviar un mensaje, debido a la política en contra del SPAM implementada recientemente por todas las operadoras de telefonía celular. En lo que concierne a una conexión entre una Aplicación Web desarrollada por la C.A. Metro de Caracas y ellos, ofrecieron el API (Application Programming Interface) con el cual podemos configurar el sistema para que se conecte con los servicios de DINAMA, y estos a su vez puedan enviar los mensajes de texto que se requieren. Para que lográramos entender con exactitud esta posible comunicación, nos explicaron que enviando un paquete en formato XML o HTML a través de una conexión http, en donde especificáramos los números de teléfono con su mensaje de texto respectivo, ellos se encargarían luego de hacer el envío a las diferentes operadoras de telefonía celular. Sobre la confiabilidad de que los mensajes lleguen a su receptor, nos aseguraron que hasta la operadora de celular ellos se hacen responsables, debido a que solo sirven como puente entre nuestra aplicación y los servicios de estas operadoras. Tampoco ofrecen el acuse de recibo automático de los celulares, pero si es permitido el proceso de auditoria a través de ellos para averiguar si el mensaje de texto llega efectivamente al destinatario. Por supuesto, también ofrecen el envío de correos electrónicos en conjunto con los mensajes de texto e informaron que para poder instalar un demo requieren de una carta oficial de la empresa explicando con detalle los servicios requeridos.

150

Resultados UNPLUGGED Al igual que DINAMA, ofrecen la construcción de la aplicación, por lo que nos pudimos dar cuenta, que las Empresas Integradoras de Telecomunicaciones (EIT) están más enfocadas en realizar tanto el levantamiento de requerimientos como la construcción completa de la aplicación, en vez de integrar con su sistema aplicaciones ya existentes en las empresas, sin embargo, no quiere decir que no se adapten al objetivo de algunas empresas que prefieren solo contratarles el servicio de mensajería de texto. Explicaron la problemática que existe con algunas operadoras de telefonía celular, las cuales no les han informado concretamente sus políticas acerca del cobro de los mensajes MT (Mobile Terminated), sin embargo, MOVISTAR les asegura que tendrá informaciones claras a partir de Octubre. Requieren que le informemos con exactitud la cantidad de usuarios por operadoras y nos propusieron la coordinación entre ambas partes para realizar pruebas con una aplicación demo sin costo. Resultados IMOLKO En esta reunión, la empresa IMOLKO mantuvo la misma idea de construir la Aplicación Web, aunque establecieron criterios más claros sobre los protocolos de comunicación que se podrían configurar entre una posible conexión entre sistemas existentes en la C.A. Metro de Caracas y los sistemas de su empresa. Con respecto a esto último, propusieron el envío automático de correos electrónicos por parte de nuestra aplicación, el cual tuviese como contenido la lista de números telefónicos con su mensaje respectivo, en formato HTML o XML. Mostraron tener inconvenientes con alguna operadora en específico, es decir, no importa si la empresa que los contrate envíe solo mensajes a una operadora, a dos o a todas, ya que el cobro de los mensajes se hace preestableciendo un monto por número de mensajes a enviar, sin importar la operadora que los reciba. Explicaron un poco mejor la problemática que también nos informo la empresa UNPLUGGED, la cual a partir de Octubre requieren la autorización de los usuarios de telefonía celular para que el servicio les haga llegar los mensajes, aunque es posible que siendo la C.A. 151

Metro de Caracas una empresa de mucha importancia para la ciudad, la cual esta requiriendo de estos servicios para automatizar sistemas de seguridad, se puedan hacer convenios con las operadoras para confirmarles que todos los mensajes de texto son enviados a celulares del personal de la empresa, los cuales no tienen inconvenientes en recibir este tipo de notificaciones mientras estén activos dentro de la organización. También, hablaron sobre unas pruebas que están realizando con la tecnología Text-ToSpeech, la cual puede convertir un mensaje de texto en un mensaje de voz, el cual sería útil para enviar las notificaciones a teléfonos fijos o que no dispongan del servicio de recepción de mensajes de texto. Finalmente, del mismo modo como lo han hecho las compañías de las reuniones anteriores, ofrecen la coordinación para instalar un demo, la cual ya fue informada oficialmente luego de concluida la reunión y en estos momentos están efectuando la fase de análisis del procedimiento para ejecutar la conexión. Resultados TELEMO Las Empresas Integradoras de Telecomunicaciones (EIT) últimamente en nuestro país, han tenido bastante auge debido al éxito que han tenido los servicios interactivos como chat’s, trivias, concursos y juegos que son ofrecidos en la radio y televisión, de hecho, antes de la reunión con TELEMO, las otras EIT destacaron que trabajan más en este tipo de servicios que en servicios para empresas. Sin embargo, TELEMO mostró un enfoque diferente, ya que lo mejor que ofrecen son los servicios de comunicación SMS entre las empresas y su personal de calle, a través de una aplicación que ellos adaptarían según las necesidades de sus clientes. A diferencia de las otras EIT con las que se pudo contactar, TELEMO permite la contratación de un servicio por uso con una renta básica mensual por mantenimiento, es decir, solo cobrarían los mensajes que se envíen más una pequeña tarifa por mantenimiento de la plataforma. También mostraron algunas limitaciones, en específico con los mensajes MT (Mobile Terminated) en Movilnet, en donde todavía no tienen un contrato con los servicios de esta operadora.

152

Descripción de las Propuestas Propuesta #1 Se propone la elaboración de una aplicación Web, en la cual se administrarán todos los datos necesarios para ubicar a cada uno de los trabajadores que integran el personal de la C.A. Metro de Caracas. De igual forma permitirá al usuario configurar todas las características de los eventos que originan la activación de Planes de Operaciones Especiales durante una determinada contingencia y la configuración del procedimiento a seguir para comunicar la alerta al personal requerido para asistir al evento y a la normalización de la operación comercial del Transporte Metro y Metrobús. Esta aplicación obtendrá periódicamente los datos del personal a través del Sistema SAP, para luego facilitar todos los números de celular y las direcciones de correo electrónico de estos trabajadores a la Empresa Integradora de Telecomunicaciones (EIT), que construirá una aplicación Web la cual ejecutará el envío de mensajes de texto (SMS) y el envío de correos electrónicos (e-mail) al personal requerido. La actualización de la Base de Datos de la EIT que se contrate también será hecha periódicamente. En lo que concierne al procedimiento para ejecutar la activación, será imprescindible que previamente la EIT tenga configurado en su aplicación Web los grupos de teléfonos móviles y direcciones de correo electrónico que recibirán el mensaje de notificación según el tipo de evento que origina la activación del plan; esta configuración podrá ser hecha manualmente accediendo a la página Web de la aplicación o automáticamente como será mostrado posteriormente. El Presidente, Vicepresidente o cualquier usuario calificado y autorizado para ejecutar la administración, podrá acceder por Intranet a la aplicación Web del Metro de Caracas para configurar y especificar los datos señalados anteriormente, luego esta aplicación se conectará automáticamente mediante un Servicio Web con la EIT para que puedan actualizar su Base de Datos y configurar su aplicación. Cuando se presente un evento en la cual sea necesario la ejecución de un Plan de Contingencia, el Presidente, Vicepresidente o cualquier usuario calificado y autorizado para ejecutar la activación, ingresará a través de Internet a la aplicación Web de la EIT para ejecutar el envío de mensajes de notificación vía SMS o e-mail. 153

Seguidamente, el personal requerido recibirá en sus celulares y en sus cuentas de correo electrónico el mensaje de notificación informando la activación del plan, en donde también se requiere que confirmen la recepción de la notificación, utilizando de la misma forma el envío de un mensaje de texto o e-mail o a través de la aplicación Web del Metro de Caracas. Este personal al llegar al puesto de trabajo en donde ha sido solicitado, ingresará a la aplicación Web del Metro de Caracas utilizando intranet, en donde en caso de que sea necesario notificarlo a través de esta vía deberá reportar su asistencia, contando por supuesto en el lugar con la red y el equipo necesario para hacerlo. Cuando se ordene la desactivación del Plan, el Presidente, Vicepresidente o cualquier usuario calificado y autorizado para ejecutar la desactivación, ingresará a través de Internet a la aplicación Web de la EIT para ejecutar el envío de mensajes de texto y correos electrónicos que informarán al personal solicitado la finalización del Plan de Contingencia. Justamente en este proceso de desactivación, también queda abierto el estudio de automatizar la notificación de este mensaje a través de los altavoces de anuncios al público, para que el personal que cumple diferentes labores y que esta esparcido en diferentes áreas de trabajo (estaciones, túneles, patios, etc.), pueda enterarse de la desactivación aunque no cuente en ese momento con un celular o acceso a su correo electrónico. Es necesario acotar que la aplicación Web del Metro de Caracas también permitirá generar reportes de la asistencia del personal a sus puestos de trabajo, organizar los procedimientos que tienen que cumplirse para la ejecución de los planes e informar al personal el sitio de trabajo a donde debe dirigirse y las instrucciones necesarias según el tipo de actividad que tenga que llevar a cabo.

154

Figura AX.1. Propuesta #1 – Asistencia de un Sistema de Información en conjunto con una Empresa Integradora De Telecomunicaciones. Fuente: Elaboración Propia Propuesta #2 Esta propuesta se distingue de la anterior a que solo requiere la contratación de una Empresa Integradora de Telecomunicaciones (EIT) que establezca un puente para el envío de mensajes de texto (SMS) entre el Metro de Caracas y el personal solicitado durante una contingencia. Por lo tanto, la EIT ya no mantiene una Base de Datos con los grupos de número telefónicos y direcciones de correo electrónico del personal, al igual que tampoco tendrá guardado los eventos que originan la activación del plan, sino que utilizando un Servicio Web que puede ser establecido mediante el envío de un correo electrónico en formato XML, recibe desde la aplicación Web del Metro de Caracas, al momento de activarse el plan, la lista de

155

números telefónicos y direcciones de correo electrónico con el mensaje de notificación respectivo. De igual forma, cuando la EIT reciba las confirmaciones de la recepción de los mensajes por parte del personal solicitado, enviará a la aplicación Web del Metro dichas confirmaciones. Utilizando esta arquitectura, tampoco es necesario que la EIT disponga de una aplicación Web para ejecutar el envío de los mensajes, esta responsabilidad recaerá en la aplicación Web del Metro de Caracas, la cual para poder permitir la activación desde cualquier lugar podrá ser ingresada a través de Internet, sin embargo, el reporte de asistencia por parte del personal así como las opciones de administración seguirán siendo tocadas a través de intranet.

Figura AX.2. Propuesta #2 – Asistencia de un Sistema de Información en conjunto con una Empresa Integradora De Telecomunicaciones. Fuente: Elaboración Propia

156

Propuesta #3 En esta propuesta no es requerida la contratación de una Empresa Integradora de Telecomunicaciones (EIT), ya que promueve la adquisición de los equipos y de la infraestructura tecnológica necesaria para establecer una comunicación directa entre el Metro de Caracas y las operadoras comerciales de telefonía celular (Movistar, Movilnet, Digitel, etc.). Actualmente no se conoce con exactitud si esta solución es factible para empresas que no se dedican con exclusividad a las telecomunicaciones como el Metro de Caracas, sin embargo, en caso de que sea posible instalar todo lo necesario para que se pueda llevar a cabo, la aplicación Web a desarrollar mantendría conexiones más directas y rápidas, tomando en cuenta que todos los sistemas implicados estarán funcionando bajo la misma red interna establecida en la empresa, sin la necesidad de establecer conexiones externas a través de Internet.

Figura AX.3. Propuesta #3 – Asistencia de un Sistema de Información integrado a una Plataforma de Telecomunicaciones. Fuente: Elaboración Propia 157

Como se dijo al comienzo de la presentación de las propuestas y de los resultados de las reuniones, la C.A. Metro de Caracas ya cuenta con las herramientas necesarias para concretar una evaluación que permita definir la elección tecnológica más adecuada a las necesidades de la empresa y que se ajusten a la versión inicial del sistema. A medida que se continúa trabajando en el sistema durante el 2006, se deberá desarrollar la interfaz respectiva que permita realizar el envío de los mensajes de texto a través de los servicios que ofrezcan la Empresa Integradora de Telecomunicaciones que se contrate.

158

APÉNDICE XI. EVALUACIÓN DE LA TECNOLOGÍA DE DESARROLLO Uno de los objetivos del proyecto es la evaluación y propuesta de la mejor solución tecnológica (dentro del Proyecto de Utilización de Software Libre) para la implementación de la aplicación a desarrollar. Sin embargo, dicha evaluación sólo se enfocó en buscar un lenguaje de programación para aplicaciones Web dinámicas y por supuesto de software libre, que nos permitiera desarrollar rápidamente una versión inicial del sistema requerido y que pudiera ser implementado por la Gerencia de Sistemas de Información en el año 2006. Debido a la magnitud del proyecto, no se contaba con mucho tiempo para realizar una evaluación exhaustiva de los diferentes lenguajes de programación que existen en la actualidad, de hecho, la elección de PHP fue promovida principalmente porque algunos desarrolladores en la Gerencia iban a tomar en poco tiempo un curso básico del lenguaje, y además se requería con prontitud tener un contacto inicial con software libre. Todavía la elección del lenguaje de programación a utilizar en futuros proyectos dentro de la gerencia esta siendo evaluada, un grupo de analistas de sistemas y de desarrolladores que trabajan dentro del Proyecto de Software Libre deberán concluir con dicha evaluación a mediados del 2006, pero podrán contar hasta ese entonces, con una evaluación inicial que se hizo en el presente proyecto y por supuesto con un sistema hecho en software libre, que además cubre una de las necesidades primordiales de la empresa como lo es la gestión de planes de contingencia. A continuación se presenta un resumen de las propuestas luego de concluir la evaluación del software libre a utilizar en el presente proyecto Propuesta N°1: Se propone la elección del sistema operativo SuSE Linux, tomando en cuenta principalmente a que no sólo es una de las distribuciones Linux más populares que existen, sino que su presencia oficial en Venezuela permite tener un soporte de sus productos más estable, rápido y eficiente, características que para una empresa como la C.A. Metro de Caracas son altamente valoradas.

159

No se tomó en cuenta distribuciones gratuitas como Fedora y Knoppix fundamentalmente porque ambos son proyectos que todavía no están ampliamente sugeridos para su desarrollo empresarial sino más bien personal, a pesar de esto, se pueden utilizar para probar la migración a Linux antes de instalar la distribución final. Tampoco se tomó en cuenta el sistema operativo Solaris porque si al final se prefirió elegir una herramienta comercial, era mejor migrar a Linux que es más conocido que Solaris. En lo concerniente al lenguaje de programación, se prefirió para esta primera propuesta PHP, tomando en cuenta a que su sintaxis es bastante sencilla y manejable, a diferencia de la tecnología JSP, que aunque también se desarrolla embebida en el código HTML, es un poco más compleja y de todas maneras ambas tienen métodos para integrarse con clases de JAVA. Al mismo tiempo PHP es uno de los lenguajes más completos y populares para la creación de páginas Web dinámicas. Es también multiplataforma, lo que ya lo hace muy superior a otros lenguajes de programación comerciales como ASP que solo pueden ser desarrollados bajo Windows. Después de haber elegido PHP como el lenguaje de programación, sin duda alguna se eligió como contenedor Web al servidor http Apache, y basta decir que es el servidor más usado en el mundo y su integración con el interpretador PHP ya fue realizada con éxito dentro de la evaluación de estas herramientas. En lo que se refiere a la elección del entorno integrado de desarrollo, se tomaron en cuenta herramientas como Eclipse y muchos otros que desarrollan en PHP. Eclipse por los momentos es el más adecuado porque ya se probo un plugin para el desarrollo en PHP, sin embargo esta herramienta tiene que estar complementada con un diseñador de páginas Web gráfico el cual seguramente obtendremos dentro del paquete del sistema operativo. Finalmente, solo se pudieron hacer pruebas de conexión con una base de datos utilizando la herramienta de software libre MySQL, aunque ya en el Metro de Caracas se ha trabajado exitosamente utilizando Informix que también es multiplataforma y se conecta con PHP. Por lo tanto la elección de cualquiera de las 2 herramientas sería de mucha utilidad, aunque ligeramente Informix es preferida debido a que ya tiene un soporte oficial con la empresa y es más conocida por los desarrolladores de la Gerencia de Sistemas de Información.

160

Propuesta N°2: En esta propuesta sugerimos la utilización de herramientas que al igual que los sugeridos en la propuesta N°1 se ajustan muy bien a los requerimientos de este y de próximos proyectos a desarrollar dentro de la empresa. Como sistema operativo se propone la elección de Red Hat Enterprise Linux, debido a que se tiene conocimiento de que los próximos servidores a instalar en la empresa van a funcionar también bajo este sistema operativo, y al igual que SuSE Linux, es una de las distribuciones linux más populares del mundo. Lo único que lo debilita para que sea tomado en esta propuesta y no en la primera es su costo, el cual es muy superior a otras distribuciones comerciales de linux. Ahora bien, lo que diferencia a esta propuesta es la elección del lenguaje de programación C#, por razones más que todo internas que se basan en que los últimos proyectos elaborados en la gerencia están bajo la plataforma .NET de Microsoft que utiliza este mismo lenguaje, y sumado a que C# esta dentro de un proyecto para el desarrollo de software libre como lo es el Proyecto MONO, le permite mantenerse dentro de la visión de la empresa el cual tiene como objetivo migrar hacia aplicaciones que utilicen software libre y se desarrollen en linux. El entorno integrado de desarrollo tiene que ser por supuesto alguna que soporte C#, y aunque existen pocas, se pudo probar SharpDevelop que es libre y además multiplataforma. El único problema de la elección de C#, es que todavía no esta orientado al desarrollo de aplicaciones Web, lo que no lo hace idóneo para el desarrollo de este proyecto, por lo tanto, todavía se tiene que esperar por el avance del Proyecto MONO en lo que concierne a este punto.

161

APÉNDICE XII. DISEÑO Y FUNCIONALIDAD DE LA INTERFAZ DE LA APLICACIÓN Es importante aclarar que en vista de que el producto desarrollado se trata de una aplicación Cliente – Servidor, es mejor desarrollar una ventana inicial de acceso en donde solo se encuentre un formulario corto para que el personal se identifique introduciendo su nombre de usuario y su contraseña. Posteriormente, se presentará una ventana principal, y dependiendo del perfil del usuario se mostrarán las opciones correspondientes, de tal modo, que alguien que tenga el perfil personal no tenga en su interfaz de navegación opciones como: activar contingencia o administrar personal, sino que solo tenga las opciones necesarias para que pueda reportarse o consultar su asignación de trabajo. La figura AXII.1 muestra el diseño de la ventana inicial del sistema.

Figura AXII.1. Ventana Inicial de la aplicación Las figuras AXII.2 y AXII.3 muestran el diseño de la ventana principal de la aplicación para los usuarios con perfil administrador y personal. 162

En el marco central de ambos diseños se mostrarán las diferentes ventanas que se acceden a través de las opciones del usuario. Están opciones siempre se ubicarán en el marco vertical izquierdo de la interfaz, por lo que el diseño permite al usuario mantener siempre a la vista toda la funcionalidad del sistema, independientemente de lo que este haciendo, y a su vez, reserva el área central de la pantalla para enfocar con más claridad las utilidades y herramientas que se estén utilizando al momento.

Figura AXII.2. Ventana Principal de la aplicación para el perfil “Administrador”

163

Figura AXII.3. Ventana Principal de la aplicación para el perfil “Personal” Como se puede ver en las figuras AXII.2 y AXII.3, las ventanas muestran la lista de opciones disponibles (para mayor detalle ver el Apéndice VIII – Plan Creativo). En vista de esto el usuario accede a una funcionalidad del sistema haciendo clic a los botones y enlaces que representan las opciones, la ventana en el marco central se cargará nuevamente para mostrar las utilidades correspondientes a la opción elegida. La figura AXII.4, muestra la ventana presentada cuando el usuario con perfil “Administrador” decide activar un Plan de Contingencia. En ella se presenta el formulario respectivo para que el usuario introduzca los datos de la contingencia y además muestra las opciones correspondientes para configurar otras características del plan.

164

Figura AXII.4. Ventana de “Activar Contingencia” para el perfil “Administrador” En caso de que el usuario decida configurar otras características del Plan de Contingencia, seleccionará la opción correspondiente y el marco central de la interfaz se cargará nuevamente para mostrar la utilidad correspondiente. Todas estas ventanas contienen un botón para regresar a la ventana inicial de activación del Plan de Contingencia.

Figura AXII.5. Ventana de “Gestión de Grupos” para el perfil “Administrador” durante la activación de un Plan de Contingencia

165

Figura AXII.6. Ventana de “Gestión de Personal” para el perfil “Administrador” durante la activación de un Plan de Contingencia En la figura AXII.7 se puede observar el formulario para ingresar un Plan de Seguridad. Cada Plan de Seguridad que sea ingresado entrará en una lista dentro de la ventana inicial de la activación como se muestra en la figura 7.10, de tal modo que permita al usuario posteriormente consultarlo y efectuar tareas de modificación o eliminación del mismo.

Figura AXII.7. Ventana de “Ingresar Plan de Seguridad” para el perfil “Administrador” durante la activación de un Plan de Contingencia Cuando el usuario ya haya configurado todas las características correspondientes al Plan de Contingencia que se requiera activar, procederá a hacer clic en el botón “ACTIVAR”. Luego 166

la ventana se cargará nuevamente, esta vez mostrando solo los datos de la contingencia y las opciones para consultar las características que fueron configuradas. En la parte inferior de esta ventana, aparecerá una pregunta del sistema para que se confirme la activación del plan.

Figura AXII.8. Lista desplegable de Planes de Seguridad ingresados durante la activación de un Plan de Contingencia

Figura AXII.9. Ventana de “Asignación de Coordinadores” para el perfil “Administrador” durante la activación de un Plan de Contingencia

Figura AXII.10. Ventana de “Confirmar activación” para el perfil “Administrador” durante la activación de un Plan de Contingencia 167

Otra de las utilidades con las que cuenta el usuario “Administrador” es la Administración de las Características de los Planes de Contingencia, la figura AXII.11 muestra la ventana correspondiente a esta funcionalidad.

Figura AXII.11. Ventana de “Administración de Características de los Planes de Contingencia” para el perfil “Administrador”

Figura AXII.12. Ventana “Área de Trabajo” (Ingreso de Datos) para el perfil “Administrador” en la administración de características de los planes de contingencia

168

Figura AXII.13. Ventana “Escenario” (Consulta de Datos) para el perfil “Administrador” en la administración de características de los planes de contingencia Otro detalle importante es la confirmación por parte del sistema de las operaciones del usuario, por ejemplo, cuando se lleva a cabo la modificación de los datos de un Grupo de Personal, por lo que el sistema deberá notificar si se realizo correctamente el cambio en la Base de Datos. La figura AXII.14 muestra un ejemplo de estas notificaciones.

Figura AXII.14. Ventana “Grupo” (Consulta de Datos – Confirmación de la modificación) para el perfil “Administrador” en la administración de características de los planes de contingencia Posterior a la activación de un Plan de Contingencia, se requiere la administración del mismo hasta que ocurra la desactivación. Para llevar a cabo esto último, el usuario deberá buscar dicho plan en la lista desplegable ubicada en la sección “Contingencia en Proceso”, que se encuentra en las opciones para el usuario Administrador (Ver Figura AXII.2), luego el sistema le

169

presentará una ventana con las opciones correspondientes para la gestión del mismo. En la figura AXII.15 se muestra un ejemplo de esta ventana.

Figura AXII.15. Ventana de “Administración de Contingencia en Proceso” para el perfil “Administrador” La activación y consulta de planes de seguridad durante la administración de un Plan de Contingencia en proceso se realiza de la misma forma y utilizando las mismas ventanas que el sistema muestra durante la activación del plan (Ver Figura AXII.7). Para la opción “Consultar Asistencia del Personal”, el sistema primero mostrará una ventana con filtros de búsqueda para ingresar datos o características específicas del personal a consultar, esto es debido a que en una contingencia pueden llegar a estar activados alrededor de 170

600 personas, por lo que sería incomodo para el Administrador observar toda la lista de este personal. Es por ello, que el sistema le permite al usuario elegir solo una parte del personal que desea consultar. En la figura AXII.16 se muestra la ventana con el referido buscador.

Figura AXII.16. Ventana de “Asistencia del Personal” (Buscador) para el perfil “Administrador” Cuando el sistema realice la búsqueda requerida por el usuario, mostrará una nueva ventana con la lista del personal encontrado, en ella tendrá la posibilidad de marcar con una casilla de verificación al personal que desea liberar, del mismo modo que también podrá consultar los datos de la asistencia de cada uno de ellos, haciendo clic en su botón correspondiente ubicado a la derecha de cada fila. La figura AXII.17 muestra un ejemplo de este tipo de ventana.

Figura AXII.17. Ventana de “Asistencia del Personal” (Lista del Personal encontrado) para el perfil “Administrador” Cuando se accede a la consulta de la asistencia de una persona en específico, el Administrador podrá efectuar el reporte de la llegada del personal haciendo clic en el botón “Actualizar Fecha / Hora”, el sistema automáticamente colocará la fecha y hora actual en la casilla de reporte de la persona consultada. 171

Otra funcionalidad adicional de esta ventana, es que el Administrador podrá cambiar el área de trabajo de la persona, dicho cambio se denomina “Movimiento”. Para consultar los movimientos que puede haber tenido esta persona, el usuario debe hacer clic en el botón “Consultar Movimientos”. Las figuras AXII.18 y AXII.19 muestran ejemplos de estas ventanas, las cuales son las mismas que se presentan cuando un usuario con perfil “Personal” ingresa a las opciones “Reportar Asistencia - Contingencia en Proceso” y “Reportes de Asistencia de Contingencias Anteriores” (Ver Figura AXII.3).

Figura AXII.18. Ventana de “Asistencia del Personal” para el perfil “Administrador” y “Personal”

Figura AXII.19. Ventana de “Asistencia del Personal” (Consulta de Movimientos) para el perfil “Administrador” y “Personal” Otra funcionalidad del sistema como lo es la Administración de la Logística, es presentada en una nueva ventana al hacer clic en el botón “Administrar Logística”, el cual se 172

encuentra en la ventana inicial durante la gestión de un Plan de Contingencia en proceso (Ver Figura AXII.15). En esta ventana se mantiene en la parte superior los datos del plan, mientras que en la parte inferior muestra las opciones para ingresar y consultar órdenes de distribución de comida y de insumo. Al ingresar una orden está podrá ser consultada a través de una lista desplegable ubicada en la opción correspondiente dependiendo si es una orden de insumo o de comida. Las figuras AXII.20, AXII.21 y AXII.22, muestran las ventanas que permiten llevar a cabo la administración y el control de la logística de un Plan de Contingencia.

Figura AXII.20. Ventana de “Logística” para el perfil “Administrador”

Figura AXII.21. Ventana de “Logística – Orden de Distribución de Insumo” (Ingreso) para el perfil “Administrador”

173

Figura AXII.22. Ventana de “Logística – Orden de Distribución de Comida” (Notificación de Ingreso Exitoso) para el perfil “Administrador” Para que el usuario Administrador pueda ingresar observaciones y clasificarlas en diferentes tipos, tendrá que hacer clic a la opción “Administrar Observaciones” (ver Figura AXII.15). Una vez hecho esto, el sistema presentará una ventana que del mismo modo como se presento en “Administrar Logística”, mantendrá en la parte superior los datos del Plan de Contingencia en proceso, y en la parte central tendrá los botones de acceso a las ventanas para ingresar y consultar tanto observaciones como tipos de observaciones. Las Figuras AXII.23, AXII.24 y AXII.25 muestran ejemplos de estas ventanas.

174

Figura AXII.23. Ventana de “Observaciones” para el perfil “Administrador”

Figura AXII.24. Ventana de “Observaciones – Tipo de Observación” (Ingreso) para el perfil “Administrador”

175

Figura AXII.25. Ventana de “Observaciones” (Consulta) para el perfil “Administrador” La opción “Editar Configuración de la Activación”, que se presenta en la ventana inicial de Administración del Plan de Contingencia en Proceso (Ver Figura AXII.15), permite al usuario acceder a una ventana para consultar las mismas opciones observadas durante la activación (Ver Figura AXII.4). El proceso para realizar alguna modificación en los grupos o personal activados, entre otras opciones, se realiza de la misma forma expuesta durante la activación. La última opción presentada dentro de la Administración de la Contingencia en Proceso, es por supuesto la de desactivación de la contingencia. Cuando el usuario hace clic en el botón para realizar la desactivación, el sistema mostrará una ventana con los datos de la activación de la contingencia y una pregunta de confirmación de la desactivación (Ver Figura AXII.26).

Figura AXII.26. Ventana de “Desactivación” (Confirmación) para el perfil “Administrador”

176

En lo que se refiere a la administración de usuarios, el sistema cuenta con una interfaz que no solo le permitirá asignar nuevos nombres de usuario al personal, sino también consultar los datos de cualquiera de ellos, en caso de que requiera modificar por ejemplo; el perfil, el nombre de usuario o incluso la contraseña. Además, la ventana contiene un buscador para definir las características de los usuarios que se requieran consultar. Al realizar la búsqueda, el sistema mostrará una lista con los usuarios encontrados en la parte inferior de la ventana, contando cada uno de ellos con un botón para acceder a sus datos respectivos. Las Figuras AXII.27 y AXII.28 muestran ejemplos de estas ventanas.

Figura AXII.27. Ventana de “Administración Usuarios” (Resultados de Búsqueda) para el perfil “Administrador”

Figura AXII.28. Ventana de “Usuario” (Ingreso) para el perfil “Administrador”

177

Aunque las interfaces para la Administración de Personal no se requieren para la versión final del sistema, debido a que el ingreso y la actualización de los datos del personal de la empresa serán realizados automáticamente desde el Sistema SAP Recursos Humanos, fue preciso realizar una parte de esta funcionalidad para poder ingresar datos de prueba que nos permitieran comprobar el funcionamiento de la aplicación. Además, también se requiere, que el sistema permita al usuario asignar las áreas de trabajo a cada uno de los integrantes del personal de la C.A. Metro de Caracas, labor que solo puede ser realizada a través de este sistema. Las figuras AXII.29, AXII.30 y AXII.31 muestran las ventanas correspondientes a estas funcionalidades.

Figura AXII.29. Ventana de “Administración de Personal” (Listado de Asignaciones) para el perfil “Administrador”

178

Figura AXII.30. Ventana de “Registro Personal Metro” (Ingreso) para el perfil “Administrador”

Figura AXII.31. Ventana de “Asignación de Personal” (Consulta) para el perfil “Administrador” Luego de la desactivación de un plan de contingencia, este podrá ser consultado en la opción “Reporte de Contingencias Anteriores”, al ser seleccionado en la lista desplegable que muestra todos los planes que fueron ejecutados y desactivados con éxito (Ver Figura AXII.2). En la ventana de reporte (Ver Figura AXII.32), se mostrarán las mismas opciones presentadas durante la administración de la contingencia, pero en este caso, es solo para consultar las características y datos ingresados durante la ejecución del plan.

179

Figura AXII.32. Ventana de “Reporte de Contingencia” para el perfil “Administrador”

180

APÉNDICE XIII. ESCENARIOS PARA EL PLAN DE OPERACIONES ESPECIALES ARCOIRIS

En la tabla AXIII.1 se muestran los distintos escenarios contemplados actualmente por el plan. En ella se pueden observar la identificación y la descripción de cada uno de ellos.

ESCENARIO

DESCRIPCIÓN DEL ESCENARIO

Escenario 1

Sismo, deslizamiento o inundación afectando instalaciones o áreas de trabajo de la C.A. Metro de Caracas.

Escenario 2

Sismo, deslizamiento o inundación sin afectar las instalaciones o áreas de trabajo de la C.A. Metro de Caracas.

Escenario 3

Atentados y/o asaltos.

Escenario 4

Motines o saqueos.

Escenario 5

Paro parcial por convención colectiva.

Escenario 6

Paro parcial por convención colectiva y confianza sindicalizado.

Escenario 7

Paro total por convención colectiva.

Escenario 8

Paro total por convención colectiva y parcial de confianza.

Escenario 9

Paro total de la empresa.

Escenario 10

Falla en el funcionamiento operativo del metro.

Escenario 11

Evento de alto impacto.

Tabla AXIII.1. Escenarios para el Plan de Operaciones Especiales Arcoiris Fuente: Elaboración Propia

181

APÉNDICE XIV. ESCENARIOS PARA EL PLAN DE OPERACIONES ESPECIALES ARCOIRIS POR ORIGEN En esta tabla se puede observar los diferentes escenarios agrupados según el origen que poseen, Natural, Social Operacional u Otro. ORIGEN

ESCENARIOS Escenario 1

Natural

Escenario 2 Escenario 3 Escenario 4 Escenario 5

Social

Escenario 6 Escenario 7 Escenario 8 Escenario 9

Operacional

Escenario 10

Otro

Escenario 11

Tabla AXIV.1. Escenarios para el Plan de Operaciones Especiales Arcoiris por Origen Fuente: Elaboración Propia

182

APÉNDICE XV. GRUPOS PARA EL PLAN DE OPERACIONES ESPECIALES ARCOIRIS En la tabla AXV.1 se muestran los distintos grupos que prestarían apoyo al plan. En ella se pueden observar la identificación y la descripción de cada uno de ellos. GRUPO Grupo 1 Grupo 2 Grupo 3 Grupo 4 Grupo 5 Grupo 6 Grupo 7 Grupo 8 Grupo 9 Grupo 10 Grupo 11

DESCRIPCIÓN DEL EQUIPO Operación combinada, personal amparado por convención colectiva y personal de confianza. Operación combinada, personal amparado por convención colectiva y personal de confianza no sindicalizado. Solo personal de confianza. Solo personal operativo. Efectivos militares y personal de dirección. Todo el personal. Personal operativo voluntario. Personal de mantenimiento. Policías. Bomberos. Defensa Civil.

Tabla AXV.1. Grupos para el Plan de Operaciones Especiales Arcoiris Fuente: Elaboración Propia

183

APÉNDICE XVI. ASIGNACIONES DE GRUPOS PARA LOS DIFERENTES ESCENARIOS DEL PLAN DE OPERACIONES ESPECIALES ARCOIRIS En la tabla AXVI.1 se presenta la asignación de los grupos que prestarían apoyo al Plan de Operaciones Especiales Arcoiris según los diferentes escenarios:

1

2

3

4

1

ESCENARIOS 5 6 7 8

10 11

X

2

X

3

X

4

X

X X

X

X X

5 GRUPOS

9

X

X

X X

6

X

X

7

X X X X X X X X X

X

X

8

X X

X

X

9

X X X X

X

10 X X X X

X

X

11 X X X X

X

X

Tabla AXVI.1. Asignaciones de Grupos para los diferentes Escenarios del Plan de Operaciones Especiales Arcoiris Fuente: Elaboración Propia

184