UNIVERSIDAD SIMÓN BOLÍVAR

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN DESARROLLO DEL MÓDULO DE GESTIÓN DEL SISTEMA DE CONTROL Y MONITOREO DE DISPOSITIVOS DE CAMPO Por: Juan Carlos Abreu Corrales INFORME DE PASANTÍA Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero en Computación Sartenejas, 10 de Enero de 2011

2 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE INGENIERÍA DE LA COMPUTACIÓN DESARROLLO DEL MÓDULO DE GESTIÓN DEL SISTEMA DE CONTROL Y MONITOREO DE DISPOSITIVOS DE CAMPO Por: Juan Carlos Abreu Corrales Realizado con la asesoría de: Tutor académico: Prof. Edumilis Mendez Tutor industrial: Ing. Efraín Cardona INFORME DE PASANTÍA Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero en Computación Sartenejas, 10 de Enero de 2011

3 Resumen Como parte del proyecto de pasantía larga, se planteó el diseño y desarrollo de un Módulo de Gestión del de Control y Monitoreo de Dispositivos de Campo de la Empresa Silocom. Para el desarrollo del sistema fue utilizada la metodología RUP, exceptuando su última fase. Debido a las particularidades del sistema, la plataforma de desarrollo a utilizar fue Java EE, debido a que posee librerías de mensajería entre los diferentes módulos desarrollados. Este sistema plantea solucionar el problema de gestión de los diferentes dispositivos de campo, incluyendo funcionalidades sobre los clientes que contratan los servicios de Silocom, así como de los diferentes usuarios asociados a los mismos. Además de control sobre los diferentes dispositivos de campo y las lecturas programadas que estos ejecutan. También se podrán supervisar el consumo de los clientes sobre los distintos planes de datos que estos mismos adquieren cuando contratan el servicio que ofrece Silocom C.A. iv

4 v

5 Índice general Índice general Índice de cuadros Índice de figuras VII X XI Introducción 1 1. Entorno empresarial Antecedentes de la empresa Misión Visión Ubicación del pasante Estructura Organizacional Marco teórico y tecnológico Aspectos del Negocio Gestión operativa de equipos de campo Aspectos tecnológicos Modelo Vista - Controlador (MCV) Modelo Cliente - Servidor Socket Protocolo J2EE Enterprise Java Bean Hibernate Struts

6 Swing XML Marco metodológico Estructura de RUP Fases de RUP Fase de inicio Fase de elaboración Fase de construcción Fase de transición Fases contempladas para este proyecto Desarrollo Primera Fase: Inicio Segunda Fase: Fase de Elaboración Plan de Proyecto Visión del sistema Lista Inicial de Requerimientos Lista inicial de Riesgos Herramientas de Desarrollo Infraestructura de Desarrollo Tercera Fase: Fase de Construcción Vista de Casos de Uso Vista lógica Módulo Cliente Administrador Módulo Silocom Administrador Vista de Datos Cuarta fase: fase de construcción Aspectos del Desarrollo Comunicación con XML Interfaces Pruebas realizadas Estado actual del Proyecto Conclusiones y recomendaciones 40 vii

7 Bibliografía 43 viii

8 Índice de cuadros 4.1. Actividades realizadas durante el proyecto de pasantías Lista Inicial de Requerimientos Lista inicial de Riesgos

9 Índice de figuras 1.1. Estructura organizacional de Silocom C.A Diagrama de flujo del Modelo Vista Controlador [5] Estructura del Proceso de Desarrollo RUP Casos de Uso Casos de Uso Casos de Uso Diagrama de Componentes Cliente Administrador Diagrama de Clases Cliente Administrador Estructura de mensajes en XML Ejemplo del mensaje XML enviado para agregar un Usuario Ejemplo del mensaje XML enviado para detener una lectura programada Solicitud de Credenciales al Usuario Menú principal del Módulo Cliente Administrador Lista de usuarios registrados Menú del super-usuario Formulario para agregar un usuario

10 1 Introducción La empresa Silocom C.A. mantiene varios proyectos con distintas empresas del sector eléctrico del país, entre las principales se encuentran la Electricidad de Valencia y la Electricidad de Caracas, y tiene como objetivo comunicar equipos situados en distintas zonas del país, que por su ubicación es inviable una comunicación de forma alámbrica. Justificación Debido a que la mayoría de las empresas están en búsqueda de ampliar sus redes y no siempre la solución garantiza medios alámbricos de comunicación, el mercado de Silocom C.A. está en pleno crecimiento. Con la idea de poder atender de manera efectiva la demanda de usuarios que requieren soluciones M2M 1, se determinó desarrollar un sistema de gestión sobre la plataforma tecnológica de Silocom C.A., para así poder automatizar todos los procesos de manejo de clientes y usuarios, como también procesos de facturación y manipulación de los distintos módulos del sistema. Planteamiento La empresa de s Integrados de Logística y Comunicaciones, SILOCOM, C.A., requería de un sistema de gestión sobre la plataforma M2M Engine. En producción se encuentra la versión 1.0 del sistema M2M Engine, por lo tanto se requiere 1 M2M (Machine to Machine o Máquina a Máquina) es un concepto genérico que indica el intercambio de información en formato de datos entre dos máquinas remotas.

11 2 un módulo con todas las funcionalidades de admistración para los clientes que contratan los servicios de la empresa (Módulo Cliente Administrador), tanto en la versión 1.0, como para la futura versión 2.0. Un segundo módulo a desarrollar, implementaría las funcionalidades de super-usuario (Módulo Silomom Administrador). Este último será incluido en la versión 2.0 del sistema anteriormente nombrado. Objetivo General El Objetivo General del proyecto desarrollar el módulo para la gestión operativa de equipos de campo. Objetivos específicos Los objetivos específicos del proyecto son: 1. Familiarización con el sistema desarrollado (M2M Engine 1.0) y las herramientas a utilizar. 2. Diseñar un sistema de gestión utilizando parte de la metodología RUP. 3. Estudiar y posiblemente mejorar de la base de datos del sistema desarrollado (M2M Engine 1.0). 4. Diseñar una interfaz web para el Módulo Cliente Administrador, y una interfaz en la plataforma Swing de Java para el Módulo Silocom Administrador.

12 3 5. Diseñar un protocolo de pruebas para la validación del sistema. 6. Realizar manuales para los usuarios finales. Alcance El alcance del proyecto es entregar un prototipo 100 % funcional que cumpla los siguientes aspectos: 1. Diseño y desarrollo de funcionalidad de gestión de los clientes: Información del cliente, planes disponibles con sus tarifas y asignación de estos a cada cliente, supervisión del consumo y facturación, configuración del parámetros del sistema por cliente y usuario, portal operativo y de consulta de información por cliente. 2. Diseño y desarrollo de la funcionalidad de gestión de sistemas: Administración, mantenimiento y diagnóstico del sistema; gestión de rendimiento y disponibilidad; seguridad, gestión de red. 3. Diseño y desarrollo de la funcionalidad de gestión de usuarios, lo cuál incluye el manejo de las sesiones y bitácoras de todas las actividades; y la permisología y perfiles de los usuarios.

13 Capítulo 1 Entorno empresarial En este capítulo se presenta una descripción del entorno en el cual se desarrolló el proyecto de pasantía en la empresa s Integrados de Logística y Comunicación SILOCOM, C. A. Comprende la composición corporativa, una breve reseña histórica de la empresa, su misión, visión, así como la estructura organizacional y el área a la cual el pasante estaba asignado. La información presentada fue suministrada por la Directiva Comercial de la empresa Antecedentes de la empresa Silocom, C. A. localizada en la ciudad de Caracas fue fundada en el año 2000 como una empresa proveedora e integradora de soluciones inalámbricas. Con el tiempo, y apoyados en la alta capacidad técnica de su personal, con una orientación a la calidad, la ética y el sentido de responsabilidad con sus compromisos, se han desarrollado como una de las empresas líderes en el segmento de datos inalámbricos, especializada en la comunicación entre máquinas (M2M) en el país.

14 5 Su mercado se enfoca en industrias e instituciones como la financiera, de servicios públicos, de transporte, de protección, seguridad y prevención, de ambiente y de petróleo y gas, entre otras dependen de dispositivos remotos o móviles para monitorear y controlar variables críticas para su operación. La supervisión y el control de éstas variables de forma inalámbrica y desde sus propias instalaciones incrementa la eficiencia, la velocidad de respuesta y en general la calidad de los servicios que prestan y contribuye también a la reducción de sus costos operativos. Entre las líneas de producto y principales soluciones provistas por Silocom, C. A. están: Gestión de Flotas: se basa en unidades de rastreo satelital de vehículos que permiten el monitoreo y adicionalmente controlarlos desde una aplicación central. Telemetría: se refiere al monitoreo y control centralizado de diversos dispositivos de campo, con aplicaciones en distribución de energía eléctrica, agua y gas, telemedición, pozos petroleros, hidrometereología, cajeros automáticos, máquinas dispensadoras, entre otros. Conectividad personal y corporativa: Silocom también dispone de otros dispositivos de comunicación inalámbrica como Terminales Fijos, Modems y Enrutadores que ponen a disposición de sus clientes la más avanzada tecnología en telecomunicaciones. Entre las aplicaciones que han manejado podemos mencionar proveer conectividad inalámbrica para Telecajeros y Puntos de ventas bien sea como respaldo a banda ancha o medio principal, televigilancia remota, todo esto utilizando la red de datos inalámbrica celular. Alarmas y seguridad electrónica: Mediante dispositivos inalámbricos basados en módulos de comunicación celular se puede monitorear remotamente el acceso y violación de agencias bancarias, establecimientos, fábricas, casas, entre otros con la ventaja y seguridad de disponer de una comunicación confiable e invulnerable por terceros.

15 Misión Nuestra misión es proveer productos y soluciones inalámbricas para el mercado M2M que aumenten la eficiencia, productividad e ingresos de nuestros clientes. Como parte fundamental de este esfuerzo está el involucrarnos con nuestro cliente para ser más que un proveedor su aliado, prestándole un apoyo técnico y comercial que le facilite el éxito en sus propios negocios Visión Nuestra visión es ser el proveedor líder en el país y fuera del mismo de dispositivos y soluciones inalámbricas que permitan que las máquinas puedan ser monitoreadas y controladas remotamente, ayudando a que esta región sea considerada a su vez líder en el mundo en la implementación de soluciones M2M Ubicación del pasante El proyecto de pasantía fue desarrollado en la Dirección de Ingeniría de Silocom C.A., con el apoyo del director de esta área y el ingeniero de desarrollo de software, adscrito tambíen a esta última. La Dirección de Ingeniería se ocupa de los procesos que permiten a Silocom C.A. estar al día y tomar posición de vanguardia en cuanto al desarrollo de software, como medida para mejorar la productividad y expansión del negocio Estructura Organizacional

16 Figura 1.1: Estructura organizacional de Silocom C.A. 7

17 Capítulo 2 Marco teórico y tecnológico En el presente capítulo se definen las bases teóricas que sustentan el proyecto, y se muestran las herramientas necesarias para la elaboración del mismo, de manera que el lector pueda conocer y entender los componentes, conceptos y tecnologías asociadas con la realización del proyecto Aspectos del Negocio M2M significa Machine to Machine refiriéndose a conexiones o comunicación sin (o con limitada) intervención humana. M2M combina la electrónica, telecomunicaciones y sistemas con el fin de interconectar dispositivos y sistemas remotos y ocasionalmente personas. Puede utilizar tanto comunicación alámbrica (PSTN, líneas eléctricas, entre otros) como inalámbrica (celular, radio, satélite, etc.). Las soluciones M2M están altamente fragmentadas y generalmente enfocadas a una sola aplicación como por ejemplo la Gestión de flotas o la telemedición. Además la variedad de soluciones técnicas y actividades de estandarización dispersas disminuyen el desarrollo del

18 9 mercado M2M, por lo que Silocom C.A. ha desarrollado soluciones que involucran: Dispositivos de comunicaciones en campo, arquitecturas de red y middlewares o Software del lado del usuario de forma que hayan sido seleccionados dispositivos de comunicaciones que cubren las diferentes interfaces y requerimientos de los diversos protocolos, además se soluciona la fragmentación de soluciones al ofrecer una plataforma de software genérica y flexible y los equipos y el software complementan y utilizan diferentes opciones en cuanto a las arquitecturas de red disponibles. La estrategia de negocio de Silocom C.A. es comenzar por las soluciones de telemetría para el sector eléctrico (justificado por el tamaño del mercado), pero crecer en nuevos segmentos según sea la demanda. Es clave que la aplicaciones permitam la flexibilidad para configurar de forma sencilla nuevos módulos y desarrollar nuevos protocolos. Se venderá bajo dos modalidades: venta bajo el esquema tradicional de venta de licencias y SaaS (Software as a Service) Gestión operativa de equipos de campo Entre los diferentes dispositivos de campo que utiliza Silocom C.A. para sus servicios, se encuentran: Módulos OEM. Modems. Terminales inalámbricos. Teléfonos vehiculares. Gestión vehicular. Colector de datos.

19 10 Estos diferentes dispositivos recolectan información, la cual es transmitida a los diferentes servidores de la empresa. Todo este contenido es procesado y presentado a los clientes por el M2M Engine. Para poder realizar sus operaciones de lectura, los diferentes dispositivos de comunicación necesitan un software particular para poder realizar estas acciones. Estos programas son conocidos como lecturas programadas, debido a que los equipos de campo las realizan automáticamente en un intervalo de tiempo definido. Las operaciones de gestión operativa de equipos de campo incluye la posibilidad de agregar, eliminar, habilitar y deshabilitar las lecturas programadas sobre los dispositivos de campo. También incluye funcionalidades de agregar, eliminar, habilitar y deshabilitar distintos equipos de campo, así como también poder generar reportes de funcionabilidad y conectividad de los diferentes equipos remotos Aspectos tecnológicos En las siguientes secciones se presentarán todos los diferentes conceptos con respecto a tecnologías que fueron requeridos para la realización de este proyecto de pasantías Modelo Vista - Controlador (MCV) Es un patrón de diseño para la arquitectura de aplicaciones Web, está basado en los beneficios de la modularidad de sus componentes. Esta modularidad ayuda tanto al desarrollo conceptual de la aplicación como al reuso de los artefactos y unidades de una aplicación en otra nueva aplicación. Este patrón establece la separación de la lógica del negocio de la interfaz del usuario. Esto permite que las modificaciones se den con mayor facilidad, tanto para la apariencia visual de la aplicación como para las reglas del negocio, sin afectar el funcionamiento del componente no modificado.

20 11 Figura 2.1: Diagrama de flujo del Modelo Vista Controlador [5] En la figura 2.1 se puede observar un diagrama que explica las principales funciones de cada componente del patrón MVC. En el Modelo Vista Controlador (MVC), el modelo representa la información, los datos de la aplicación; la vista corresponde a los elementos de las interfaz de usuario; y por último, el controlador gestiona la comunicación de los datos y la reglas del negocio que son utilizadas para manipular dichos datos desde y hacia el modelo. El patrón MVC fue descrito por primera vez en 1979 por Trygve Reenskaug, quien al momento estaba trabajando en Smalltalk-80. La interfaz de usuario de ambiente de programación de Smalltalk-80 fue desarrollada usando una estrategia particular de representación de la información, la presentación, y el control. Esta estrategia fue escogida para satisfacer dos objetivos: crear un conjunto especifico de componentes necesarios del sistema que apoyen procesos de desarrollo de software altamente interactivos; el segundo objetivo de dicha estrategia es proveer un conjunto general de componentes del sistema que hagan posible para

21 12 los programadores crear fácilmente aplicaciones gráficas interactivas portables. Al diseñar aplicaciones interactivas, así como otros programas, la modularidad de los componentes posee grandes beneficios. Al separar las unidades funcionales de la aplicación, los diseres tiene mayor facilidad para poder entender el concepto de cada unidad, así como poder realizar los cambios requeridos sin necesidad de conocer las otras unidades. Debido a todas las ventajas que presenta este modelo, se decidió utilizar en la interfaz del módulo de Cliente Administrador del M2M Engine 1.0, con ayuda del framework Struts que implementa el patrón Vista-Controlador Modelo Cliente - Servidor Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras [7]. En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema. La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un solo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma. Debido a que las aplicaciones de administración por parte de los clientes de Silocom C.A., estarán conectadas de forma remota, la comunicación se realizará bajo el modelo Cliente -

22 13 Servidor Socket Un socket es una abstracción por donde una aplicación puede enviar y recibir datos. Este permite que una aplicación se conecte a una red y se comunique con otra aplicación que se encuentra en la misma red. Los sockets pueden escribir información a través de una aplicación, y la información puede ser leída por una aplicación diferente [1]. Para establecer la comunicación a través de un socket se necesita de un puerto y una dirección IP. La aplicación cliente se conecta a través de un puerto en común con el servidor, indicando la dirección IP de la aplicación de dicho servidor. La aplicación servidor, acepta la conexión y a partir de ese momento se realizan las operaciones necesarias de escritura y lectura para lograr el intercambio de información. Los sockets son el mecanismo mediante el cual se implementará el modelo Cliente - Servidor en las aplicaciones Protocolo Tanembaum define el protocolo como un acuerdo entre las partes en comunicación sobre cómo debe llevarse a cabo la comunicación. Es importante conocer los lineamientos sobre los cuales se establece la comunicación, ya que sin el conocimiento de estos es prácticamente imposible establecer una comunicación exitosa [7] J2EE La plataforma Java 2, Enterprise Edition (J2EE) define el estándar para el desarrollo de aplicaciones empresariales multinivel. La J2EE simplifica las aplicaciones empresariales basándolas en componentes estandarizados, modulares, proporcionando un conjunto comple-

23 14 to de servicios a esos componentes, y manejando muchos detalles del comportamiento de la aplicación automáticamente, sin necesidad de programación compleja [2]. La arquitectura J2EE tiene varios beneficios entre los cuales destacan: Permite al desarrollador la creación de aplicaciones empresariales portátiles entre plataformas, fáciles de integrar con tecnologías anteriores. Permite una mayor concentración en la lógica del negocio por parte del programador. Define tres componentes a desarrollar por el programador: Java Server Pages, servlets o Enterprise Java Beans. Gracias a las ventajas que presenta Java EE sobre sus otras versiones, fue seleccionado como plataforma de desarrollo del proyecto de pasantía. Especialmente por sus funcionalidades de mensajería Enterprise Java Bean El Enterprise Java Bean (EJB) es una arquitectura que permite a los desarrolladores crear de forma rápida y sencilla aplicaciones de negocio. Permite un desarrollo rápido y simplificado de aplicaciones distribuidas con la tecnología Java. Con EJB, el desarrollador se preocupa solamente por resolver los problemas que vienen con el desarrollo del proceso de negocio de la empresa, sin importar el procesamiento de estos datos de forma interna, esto es, preocuparse por los problemas generales que conllevan una aplicación empresarial (concurrencia, seguridad, transacción, entre otros) [3] Hibernate Hibernate es una herramienta de mapeo objeto-relacional para la plataforma Java que facilita el mapeo de atributos entre una base de datos relacional tradicional y el modelo de

24 15 objetos de una aplicación, mediante archivos declarativos (XML) o anotaciones en los beans de las entidades que permiten establecer estas relaciones. Como todas las herramientas de su tipo, Hibernate busca solucionar el problema de la diferencia entre los dos modelos de datos coexistentes en una aplicación: el usado en la memoria de la computadora (orientación a objetos) y el usado en las bases de datos (modelo relacional). Para lograr esto permite al desarrollador detallar cómo es su modelo de datos, qué relaciones existen y qué forma tienen. Con esta información Hibernate le permite a la aplicación manipular los datos de la base operando sobre objetos, con todas las características de la programación orientada a objetos. Hibernate convertirá los datos entre los tipos utilizados por Java y los definidos por SQL. Hibernate genera las sentencias SQL y libera al desarrollador del manejo manual de los datos que resultan de la ejecución de dichas sentencias, manteniendo la portabilidad entre todos los motores de bases de datos con un ligero incremento en el tiempo de ejecución. Hibernate fue seleccionado como el framework a utilizar para manejar todas las conexiones y consultas a la base de datos, debido a que facilita estos procesos y garantiza seguridad sobre los datos manipulados Struts Struts es una herramienta de soporte para el desarrollo de aplicaciones Web bajo el patrón MVC bajo la plataforma Java EE (Java Enterprise Edition) [4]. Evidentemente, como todo framework intenta, simplifica notablemente la implementación de una arquitectura según el patrón MVC. El mismo separa muy bien lo que es la gestión del flujo de trabajo de la aplicación, del modelo de objetos de negocio y de la generación de interfaz. El controlador ya se encuentra implementado por Struts, aunque si fuera necesario se

25 16 puede heredar y ampliar o modificar, y el flujo de trabajo de la aplicación se puede programar desde un archivo XML. Las acciones que se ejecutarán sobre el modelo de objetos de negocio, se implementan basándose en clases predefinidas por el framework y siguiendo el patrón Facade. Y la generación de interfaz se soporta mediante un conjunto de Tags predefinidos por Struts cuyo objetivo es evitar el uso de Scriplets (los trozos de código Java entre < % y % >, lo cual genera ventajas de mantenibilidad y de rendimiento. Logísticamente, separa claramente el desarrollo de interfaz del sistema y lógica de negocio permitiendo desarrollar ambas en paralelo o con personal especializado. También potencia la reutilización, soporte de múltiples interfaces de usuario (html, shtml, wml, Desktop applications, etc.) y múltiples idiomas Swing Swing es una biblioteca gráfica para Java. Incluye widgets para interfaz gráfica de usuario tales como cajas de texto, botones, desplegables y tablas. El paquete Swing es parte de la JFC (Java Foundation Classes) en la plataforma Java. La JFC provee facilidades para ayudar a la gente a construir GUIs (GUI por su nombre en inglés Graphical User Interface - Interfaces Gráficas de Usuarios -). Swing existe desde la JDK 1.1 (como un agregado). Antes de la existencia de Swing, las interfaces gráficas con el usuario se realizaban a través de AWT (Abstract Window Toolkit), de quien Swing hereda todo el manejo de eventos. Usualmente, para toda componente AWT existe una componente Swing que la reemplaza, por ejemplo, la clase Button de AWT es reemplazada por la clase JButton de Swing (el nombre de todas las componentes Swing comienza con J ). Las componentes de Swing utilizan la infraestructura de AWT, incluyendo el modelo de eventos AWT, el cual rige como una componente reacciona a eventos tales como, eventos de

26 17 teclado, mouse, etc. Es por esto, que la mayoría de los programas Swing necesitan importar dos paquetes AWT: java.awt.* y java.awt.event.* XML XML, siglas en inglés de extensible Markup Language (lenguaje de marcas extensible), es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). Es una simplificación y adaptación del SGML y permite definir la gramática de lenguajes específicos (de la misma manera que HTML es a su vez un lenguaje definido por SGML). Por lo tanto XML no es realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades. XML es una tecnología sencilla que tiene a su alrededor otras que la complementan y la hacen mucho más grande y con unas posibilidades mucho mayores. Tiene un papel muy importante en la actualidad ya que permite la compatibilidad entre sistemas para compartir la información de una manera segura, fiable y fácil.

27 Capítulo 3 Marco metodológico Para cumplir los objetivos del proyecto fue necesario recurrir a una metodología de desarrollo de software, por lo tanto fue elegido el proceso de desarrollo RUP (Rational Unified Process). En este capítulo se presentarán las estructuras de este proceso desarrollo, explicando fases y actividades del mismos Estructura de RUP El Proceso Unificado de Rational (RUP, por sus siglas en inglés), es un proceso de la ingeniería del software. Provee de un enfoque disciplinado para la asignación de tareas y responsabilidades dentro de una organización de desarrollo. Su meta es el aseguramiento de la calidad de la producción de software [6]. La estructura de RUP está compuesta por dos dimensiones, una dinámica y otra estáica. La primera dimensión representa el aspecto dinámico del proceso y está constituido por fases, iteraciones e hitos [6]. La segunda dimensión representa el aspecto estático del proceso y está constituido por actividades, disciplinas, artefactos y roles. La figura 3.1 muestra la

28 19 Figura 3.1: Estructura del Proceso de Desarrollo RUP arquitectura global de RUP. El eje horizontal representa la organización a lo largo del tiempo, la dimensión dinámica, mientras que el eje vertical representa la organización en términos de contenido, la dimensión estática Fases de RUP RUP está compuesto por cuatro fases. Estas fases poseen un objetivo clave y una serie de hitos que deben ser cumplidos, los cuales representan que el objetivo de la fase fue alcanzado Fase de inicio Es la primera fase del proceso de desarrollo, tiene un conjunto de objetivos bien definidos y se considera concluido con el hito: Objetivo del ciclo de Vida. El objetivo principal de esta fase es entender el alcance y objetivos del proyecto. En esta fase se identifica la funcionalidad

29 20 clave del sistema, a través de la identificación de los casos de uso más críticos. A su vez se plantea una solución para el problema presentado, para ello se crean artefactos como un plan de proyecto, una lista de posibles riesgos, y una visión del proyecto, la cual presentará los actores, los costos y las características del proyecto [6]. Al final de esta fase se comprueba si se ha alcanzado el hito correspondiente, en caso de que no haya sido completado, el proyecto puede ser cancelado o se puede repetir la fase, a través de un nuevo diseño que se adecúe mejor a los criterios establecidos Fase de elaboración En esta fase se provee dirección a los principales riesgos, se diseña la arquitectura del sistema de software que satisfaga los requerimientos, y se da refinamiento al plan de proyecto [6]. Los objetivos específicos de esta fase son: Obtener un entendimiento más detallado de los requerimientos. Diseñar, implementar, validar y generar una línea base para la arquitectura. Mitigar los riesgos esenciales y producir un plan y costos más precisos. Al finalizar esta fase se debe haber alcanzado el hito correspondiente, el cual es llamado Objetivo de la Arquitectura del ciclo de vida, que debe cumplir con los siguientes criterios: Un modelo de casos de uso que identifique actores y casos de uso, y en el cual la mayoría de los casos de uso posean una descripción. Una descripción de la arquitectura de software. Una arquitectura factible que estructure arquitectónicamente los casos de uso más significativos.

30 21 Una revisión del caso de negocio y de la listas de riesgos. Un plan de desarrollo para el proyecto en general. En caso de que el proyecto no alcance los criterios propuesto por el hito, todavía se dispone de tiempo para poderlo cancelar o rediseñar. A partir de esta fase, el proyecto entra en una transición hacia operaciones de alto riesgo, en las cuales los cambios serán mucho más difíciles Fase de construcción En esta fase el objetivo principal es la construcción del sistema. El enfoque principal se da al desarrollo de los componentes y características del sistema que se ha diseñado. Se caracteriza por una gran actividad de codificación. En proyectos de gran escala esta fase se caracteriza por tener varias iteraciones que dividen el conjunto de casos de uso con el fin de producir varios prototipos [6]. Esta fase se considera finalizada cuando se han desarrollado todas las funcionalidades y se produce un primer release del software. Su conclusión está marcada por el hito de Capacidad Inicial de Operaciones Fase de transición El objetivo principal es la transición del sistema del ambiente de desarrollo al ambiente de producción, haciendo que el sistema esté disponible para el usuario, dotándole de charlas de inducción, entrenamientos y manuales de usuario. Además se caracteriza por la ejecución de pruebas beta por parte de los usuarios, lo que permitirá validar las expectativas de los usuarios en relación con el producto implementado. Si todos los objetivos son alcanzados, el hito Release de Producto se considera alcanzado y por tanto el ciclo de desarrollo finaliza [6].

31 Fases contempladas para este proyecto En la primera fase de la metodología se identificaron las necesidades del cliente, se definió el alcance de los módulos del sistema a ser desarrollados. Luego de esta fase, se obtuvo el Documentos Visión del. Acá fue contemplada una sola iteración. En la segunda fase de la metodología RUP, etapa de elaboración, se realizaron actividades de análisis y diseño del sistema. Al finalizar ésta, se obtuvieron los siguientes artefactos: Modelo de Casos de Uso, Diagrama Entidad Relación y Glosario de Datos usados. Especificación de Requerimientos de Software. Diseño de la Arquitectura de Software. Para completar esta segunda fase fueron contemplatas 2 iteraciones. En la fase de elaboración se refinó el modelo de casos de uso, y de igual manera, los documentos y planes elaborados previamente. También se definió una arquitectura factible que soluciona el problema planteado. La fase de construcción estuvo marcada por dos iteraciones. Con un total de 39 casos de uso y debido a la naturaleza de la aplicación, fueron divididos en dos segmentos. La primera iteración tenía con 19 casos de uso, correspondientes al primer módulo del sistema y la segunda iteración el resto de los casos. La fase de transición no fue incluida, debido a que su implantación está fuera del alcance del proyecto.

32 Capítulo 4 Desarrollo En el siguiente capítulo se describen las actividades realizadas en el proyecto, de acuerdo a los objetivos planteados y a la metodología establecida para su desarrollo Primera Fase: Inicio Durante esta fase se revisó la documentación existente, además se realizaron reuniones con la Dirección de Ingeniería y el Ingeniero de Desarrollo de Software, actividades que tenían como objetivo obtener información del negocio, así como de las necesidades del cliente, conocer sus expectativas y actualizar la información en cuanto a requerimientos del sistema. La documentación existente consta de un modelo Entidad-Relación de la primera versión del M2M Engine 1.0 y un material que presenta los actores del sistema, las funcionalidades implementadas. También se revisaron y analizaron diferentes documentaciones sobre librerías que se iban a utilizar en el desarrollo del proyecto.

33 Segunda Fase: Fase de Elaboración Como en la primera etapa se realizó el levantamiento de información para todo el proyecto, el análisis y diseño de dichos módulos fue contemplado dentro de esa etapa. Sin embargo se presentará toda la información relativa a la visión del proyecto dentro de este apartado Plan de Proyecto En el cuadro 4.1 se presentan las actividades de mayor relevancia para el desarrollo del proyecto, en cada fase se expondrán con mayor detalle las actividades realizadas de ser necesario. Actividades Familiarización con el sistema desarrollado, las herramientas a utilizar y levantamiento de información (visión, misión, requerimientos y casos de uso) Diseño de las funcionalidades, basado en UML que incluye la visión, misión, los diagramas de estructura, comportamiento e interacción pertinentes, y el diagrama E-R de la base de datos Desarrollo del diseño elaborado Desarrollo de la interfaz para el super-usuario y los clientes Desarrollo de un protocolo de pruebas, pruebas, validación de las funcionalidades y ajustes finales. Cuadro 4.1: Actividades realizadas durante el proyecto de pasantías Visión del sistema La visión del proyecto está definida por medio del Documento de Visión del (ver Apéndice A). Dicho documento tiene como objetivo principal coleccionar, analizar y definir requerimientos, necesidades de usuario y caracteísticas del Módulo de Gestión del de Control y Monitoreo de Dispositivos de Campo de Silocom C.A. El Documento de Visión

34 25 permite la comprensión general del producto y establece alcance y prioridades sobre las características de alto nivel Lista Inicial de Requerimientos Se realizaron reuniones con el director de Ingeniería y el Ingeniero de Desarrollo de Software para establecer los requerimientos iniciales del sistema. En el cuadro 4.2 se presenta el nombre de los requerimientos del sistema. El detalle de los mismos se encuenta en el Documento Visión del (ver Apéndice A). Nombre de los requerimientos Gestión de clientes Gestión de usuarios Supervisión de consumo de clientes según su plan Gestión de usuarios Reporte de factura Reporte de actividades de usuario Reporte de actividades de remota Reportes de disponibilidad y diagnóstico de módulos Reportes de rendimiento Gestión de lecturas programadas Gestión de módulos Gestión de dispositivos de comunicación Supervisión sobre la capa física Cuadro 4.2: Lista Inicial de Requerimientos Lista inicial de Riesgos En el cuadro 4.3 se presenta la lista de riesgos analizados para este proyecto. La lista de riesgos es un mecanismo que permite el control y mitigación de riesgos que se pueden presentar durante el desarrollo del software.

35 26 Nombre del riesgo Escala Impacto Conflicto de Requerimientos Baja Aumento considerable del tiempo y costos planificados Diseño implementado no satisface el alcance del sistema Media Se retrasa el desarrollo del sistema. La funcionalidad del sistema puede ser ineficiente Estimación de tiempos Media Se retrasa el desarrollo del sistema. La funcionalidad del sistema puede estar incompleta Interfaz no agradable al cliente Media Aumento del tiempo de desarrollo, para hacer las modificaciones necesarias Cuadro 4.3: Lista inicial de Riesgos Herramientas de Desarrollo Para el desarrollo de este proyecto, se utilizaron las siguientes herramientas: Lenguajes de programación: El Módulo del Cliente Administrador para la versión 1.0 del M2M Engine fue desarrollado en Java Standard Edition. El resto del proyecto fue desarrollado en Java Enterprise Edition, por requerimientos del mismo. Específicamente por la necesidad de comunicación entre los distintos módulos del sustema, para lo cual esta herramienta presenta librerias de mensajería que lo permiten. Frameworks: Para la implementación del proyecto, fueron utilizado dos frameworks: struts y hibernate. El primero diseñado para crear aplicaciones web bajo el patrón MVC. El segundo es una herramienta para realizar mapeos entre el modelo objetorelacional de base de datos, con el modelo orientado a objetos de la plataforma Java. Servidor: El servidor utilizado para todo el proyecto fue glassfish. Este es un servidor de aplicaciones de software libre desarrollado por Sun Microsystems. Manejador de base de datos: El manejador de base de datos relacionales utilizado fue MySQL 5.5.

36 27 Navegadores web: Debido a requerimientos de compatibilidad, fueron utilizados Google Chrome 8.0, Mozilla FireFox e Internet Explorer Infraestructura de Desarrollo La infraestructura de desarrollo consta de un computador que cuenta con los programas y herramientas necesarias para el desarrollo del software, estas herramientas son las nombradas anteriormente, así como acceso a Internet y conexión remota y local al servidor de desarrollo Tercera Fase: Fase de Construcción Durante la fase de elaboración se definieron los casos de uso correspondientes a los módulos a desarrollar, esto con la finalidad de poder diseñar una arquitectura factible y efectiva. Cabe destacar que durante el desarrollo de la primera etapa del proyecto, se definió una arquitectura que representaba los componentes previamente desarrollados, así como los módulos a ser implementados durante este proyecto. En esta sección se presentarán los detalles de la arquitectura definida Vista de Casos de Uso En esta vista de la arquitectura se incluyen los casos de uso, tanto el o los diagramas, las narrativas descriptivas asociadas a cada caso de uso. Esta vista tiene como objetivo el entendimiento de la funcionalidad del sistema. Las figuras 4.1, 4.2 y 4.3, representan gráficamente los casos de usos y los actores que intervienen en el sistema. Este diagrama de casos de uso también se puede encontrar dentro del Documento de Arquitectura de Software (ver Apéndice C) y en el Documento de Especificaciones de Requerimientos del Software (ver Apéndice B) donde además se presentan las

37 28 narrativas descriptivas asociadas cada caso de uso. Los requerimientos funcionales y no funcionales pueden ser encontrados dentro del Documento de Especificaciones de Requerimientos del Software (ver Apéndice B). Figura 4.1: Casos de Uso Vista lógica La vista lógica comprende las abstracciones fundamentales del sistema a partir del dominio del problema. Comprende las clases y subsistemas para aportar soporte a los requerimientos funcionales. Para describir esta vista se utiliza el método de diseño orientado a objetos, a través del uso del diagrama de componentes, y el modelo de clases. Todos estos modelos se encuentran presentados dentro del Documento de Arquitectura de Software (ver Apéndice

38 29 Figura 4.2: Casos de Uso Figura 4.3: Casos de Uso

39 30 C) Módulo Cliente Administrador La figura 4.4 representa el diagrama de componentes del módulo del cliente administrador del sistema. Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos los mismos. Figura 4.4: Diagrama de Componentes Cliente Administrador Se toma como base el modelo conceptual, se identifican aquellos conceptos sobre los cuales se requiere hacer algún tipo de procesamiento sobre la información que representan, en el contexto de la aplicación a ser desarrollada. A través del diagrama de clases se describe la estructura del sistema. Un sistema orientado a objetos se construye definiendo clases. Los objetos identificados en el dominio de la aplicación son agrupados en clases, cada una de las cuales representa un categoría de objetos que tienen atributos y mdos similares. En la figura 4.5 se presenta el diagrama de clases para el módulo Cliente Administrador.

40 Figura 4.5: Diagrama de Clases Cliente Administrador 31

41 Módulo Silocom Administrador Tanto el diagrama de componentes, como el diagrama de clases del Módulo Silocom Administrador se pueden encontrar dentro del Documento de Arquitectura del Software (Ver Apéndice C) Vista de Datos Es una representación del almacenamiento de la información y los datos. Esta representada por el diagrama Entidad Relación y el glosario de datos asociado. Este puede se pueden encontrar dentro del Documento de Arquitectura del Software (Ver Apéndice C) Cuarta fase: fase de construcción En la fase de construcción se realizaron todas las actividades que contemplan la implementación de todos los casos de uso Aspectos del Desarrollo Debido a que el proyecto fue dividido en dos módulos, en la primera iteración del desarrollo se implementaron 19 casos de uso correspondiente al Módulo Cliente Administrador. La versión de este módulo desarrollada para el M2M Engine 1.0 fue implementada en Java Standard Edition y la correspondiente al M2M Engine 2.0 fue desarrollada en Java Enterprise Edition. La diferencia entre las dos versiones reside en detalles de implementación. En las dos era necesario que el servidor fuese de tipo concurrente 1, en la versión 1.0 esto se logra a través de los Threads o hilos de Java, y en la segunda versión fue implementado con la plataforma Beans. 1 Un servidor concurrente es el tipo de servidor que crea un hilo de ejecución distinto por cada usuario que haga una solicitud de conexión.

42 33 En la segunda iteración se implementó las funcionalidades del Módulo Silocom Administrador o super-usuario. Con un total de 20 casos de uso, fueron implementados sobre la plataforma Java Enterprise Edition, debido a que este módulo debía comunicarse con el resto de la aplicación que se encuenta en el Core de M2M Engine Comunicación con XML En el módulo Cliente Administrador, la comunicación se implementó con el Modelo Cliente Servidor. Los datos transmitidos entre estos fueron estructurados como mensajes XML. La figura 4.6 muestra la estructura de los mensajes enviados entre las dos entidades. Figura 4.6: Estructura de mensajes en XML La figura 4.7 muestra un ejemplo del mensaje que es enviado cuando se desea agregar un cliente. Así mismo la figura 4.8 muestra como sería el mensaje enviado cuando se desea detener la ejecución de una lectura programada que esté funcionando en un equipo remoto de campo. Es importante resaltar que en estos mensajes se agrega toda la información necesaria para que el core del M2M Engine pueda ejecutar la acción descrita en el XML de forma normal.

43 34 Figura 4.7: Ejemplo del mensaje XML enviado para agregar un Usuario Figura 4.8: Ejemplo del mensaje XML enviado para detener una lectura programada

44 Interfaces La interfaz del Módulo Cliente Administrador fue diseñada como una página web. La figura 4.9 muestra el inicio del sistema, donde se le solicitan al usuario las credenciales para la autenticación. Figura 4.9: Solicitud de Credenciales al Usuario En este módulo, se le presentan al usuario las diferentes funcionales a través de un menu horizontal, con un menú despegable con las diferentes opciones que posee, tal y como se puede observar en la figura 4.10.

45 36 Figura 4.10: Menú principal del Módulo Cliente Administrador La figura 4.11 muestra la salida de consultar los usuarios registrados en el sistema. Figura 4.11: Lista de usuarios registrados La interfaz del Módulo Silocom Administrador, fue diseñada con la librería gráfica Swing de Java. En la figura 4.12 se observa el menú principal donde se presentan las funcionalidades

46 37 al super-usuario. Figura 4.12: Menú del super-usuario En la figura 4.13 se presenta el formulario que el super-usuario debe completar, para agregar un usuario asociado a un cliente. Figura 4.13: Formulario para agregar un usuario

47 Pruebas realizadas Se diseñó un protocolo de pruebas para realizar la validación del sistema. Los tres tipos de pruebas realizadas, fueron las siguientes: 1. Pruebas de Funcionalidad. Estas pruebas se realizaron teniendo como entradas el flujo de actividades definido para cada módulo, siguiendo las funcionalidades sin ningún tipo de error. Esto para verificar que las implementaciones funcionaban. Luego se incluyeron pruebas destructivas y negativas, así como de volumen y pruebas de seguridad, por ejemplo: URL mal formados, campos vacíos en los formularios, campos con contenido no válido, entre otros. El sistema respondió de la manera esperada en el 100 % de las pruebas. 2. Pruebas de Confiabilidad. Estas comprobaciones consistieron en probar con conexiones concurrentes (usuarios múltiples), integridad de la información (referente a los datos que son almacenados en la base de datos) y pruebas de estrés (que incluyen falta de recursos y condiciones extremas). De todas las pruebas realizadas, el sistema respondió de manera correcta ante éstas, manteniendo en un 100 % todos los aspectos de confiabilidad considerados. a) Pruebas de Stress: este tipo de pruebas nacen con la idea de saber cómo reacciona el sistema ante una gran carga, y en caso de que los resultados no sean satisfactorios, se querrá mejorar el rendimiento del sistema. En nuestro caso, se creó un programa que simulaba 100 remotas en funcionamiento. Desde las dos aplicaciones (Cliente Administrador y Silocom Administrador) fueron creadas y habilitadas distintas lecturas programadas asociadas al grupo de remotas creadas por el simulador. Inmediatamente las remotas empezaron a realizar las diferentes lecturas

48 39 programadas que le fueron asignadas, demostrando que el sistema realizaba de manera correcta esta operación. Luego se procedió a detener las lecturas programadas asociadas al grupo de remotas simuladas, causando una detención de las operaciones de las mismas. EL sistema respondió exactamente como se esperaba, por lo tanto un 100 % de las pruebas resultaron exitosas. 3. Pruebas de Soportabilidad. Para el Módulo Cliente Administrador, se incluyeron pruebas de las funcionalidades del sistema sobre los distintos Navegadores Web, para así corroborar la compatibilidad de la aplicación con los mismos. El resto de las pruebas, consistían en verificar el correcto comportamiento de los módulos tanto en el sistema operativo Windows XP, como en la distribución Ubuntu 10.0 de Linux. EL sistema pudo ejecutarse de manera correcta en las diferentes plataformas en la que fue probada, por lo tanto puede decirse que las pruebas fueron superadas en un 100 % Estado actual del Proyecto El Módulo Cliente Administrador desarrollado para el M2M Engine 1.0 se encuentra actualmente en producción. Tanto la versión de este módulo implementada para el M2M Engine 2.0 y el Módulo Silocom Administrador se encuentran en desarrollo, debido a que hay módulos de esta versión que no han sido desarrollados.

49 Capítulo 5 Conclusiones y recomendaciones Como resultado de este proyecto se logró implementar un módulo de gestión para el sistema de control y monitoreo de dispositivos de campo. El proyecto contempló el diseño y desarrollo de las diferentes funcionalidades que contemplaban: 1. Definir los planes de producto disponibles, los cuáles se basan en la cantidad de disco asignado a la información que debe guardarse para cada cliente, la cantidad de ancho de banda que consumen y la capacidad de microprocesador consumida. 2. Gestionar los diferentes aspectos de los clientes, como el aprovisionamiento de sus planes, control sobre sus actividades y consumo, y la facturación. 3. Administrar el sistema y un seguimiento de su rendimiento, con el objetivo de mantener altos niveles de calidad de servicio, de identificar fallas de forma inmediata, y de responder a estas rápidamente. Esto incluye la generación de reportes de disponibilidad, rendimiento y diagnóstico. 4. Administrar todo lo referente a las lecturas programadas que se realizan sobre los diferentes dispositivos de campo.

50 41 5. Ofrecer herramientas flexibles para que el cliente pueda definir e implementar las funciones operativas de sus empleados y realizarle un seguimiento y auditorías. En este proyecto se investigaron las herramientas a utilizar, se aprendieron las tecnologías necesarias, se analizaron los requerimientos del cliente y se diseñaron interfaces de forma que pudiesen ser portátiles, usables y eficientes. En base a la metodología aplicada y al aprendizaje obtenido, se puede afirmar que los objetivos de esta pasantía se llevaron a cabo en su totalidad, a pesar de los atrasos generados por problemas usando los diferentes frameworks para poder implementar los casos de usos definidos. A nivel de desarrollo, se alcanzó y superó el objetivo de implementación, ya que inicialmente se consideraba la implementación del Módulo Cliente Administrador para la versión 1.0 del M2M Engine, pero pudo implementarse el mismo módulo para la versión 2.0 del sistema anteriormente nombrado. Uno de los procesos mas importantes para esta pasantías, fue el aprendizaje del manejo del metalenguaje XML, debido a que la comunicación entre módulos del sistema seguía este patrón. El levantamiento de la información de forma adecuada, así como el análisis y diseño especificando con detalle los requerimientos establecidos, permitió realizar con mayor fluidez la implementación de los casos de uso, pudiendo entregarlas a tiempo para las pruebas sin encontrar problemas mayores. Todas las aplicaciones desarrolladas son de alta importancia para la empresa Silocom C.A. debido a que les agrega un conjunto muy importante de funcionalidades a los clientes que contratan su servicio, permitiéndoles tener un mejor manejo de los distintos dispositivos de campo, así como de sus usuarios y los planes a los cuales están adscritos. Con respecto a las funcionalidades del super-usuario, el empleado de Silocom podrá tener control de los clientes y usuarios del sistema a tiempo real, además que podrá atender de forma eficiente

51 42 cualquier detalle que ocurra con algún módulo del sistema o algún dispositivo de campo. Como recomendaciones se sugiere tener unas futuras entrevistas con los usuarios, para conocer que otras necesidades particulares del negocio poseen, y así poder extender este módulo administrador y brindarle al usuario un sistema más adaptado a sus necesidades. También se propone hacer varias sesiones de inducción y entrenamiento a los usuarios finales. También se sugiere analizar el posible cambio de la interfaz del módulo del Administrador Silocom, de la plataforma Swing a una interfaz en cónsola en donde es posible aumentar aun mas la seguridad del sistema. Con respecto al Módulo Silocom Admistrador, se sugiere hacer constantes revisiones sobre el diseño de la base de datos, para buscar formas de acelerar las consultas a la misma aprovechando un buen diseño del almacenamiento de datos.

52 Bibliografía [1] K. L. Calvert. TCP/IP Socket in Java, practical guide for programmers. Morgan Kaufhank, [2] O. Corporation. Java 2 platform, enterprise edition (j2ee) overview [3] R. Ed. Mastering Enterprise JavaBeans. John Wiley Sons Inc. [4] J. Holmes. Struts: The Complete Reference. McGraw-Hill, [5] S. M. Inc. Java blueprints j2ee patterns [6] P. Krutchen. The Rational Unified Process: An Introduction. Adisson-Wesley, [7] T. A. S. Redes de computadoras. Prentice Hall, 2003.

53 Apéndice A

54 SILOCOM, C.A. Visión del M2M Engine 2.0 Versión 1.02

55 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision Historia de Revisiones Fecha Versión Descripción Autor 03/08/ Versión inicial del documento. Elaborados los capítulos /08/ Elaborados los capítulos /08/ Elaborados los capítulos 5-10 Efraín Cardona, Nicolás Cova Juan Carlos Abreu, Efraín Cardona, Nicolás Cova Juan Carlos Abreu, Efraín Cardona, Nicolás Cova Confidencial SILOCOM, C.A., 2010 Pág. 2 de 27

56 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision Tabla de Contenidos Visión del 5 1. Introducción Propósito Alcance Definiciones, Siglas y Abreviaciones Referencias Descripción General Posicionamiento Oportunidades de Negocio Declaración del Problema Declaración del Posicionamiento del 8 3. Descripciones de los Stakeholders y Usuarios Demografía del Mercado Resumen de Stakeholders Resumen de los Usuarios Ambiente Usuario Perfil del Stakeholder Fabricantes de equipos de campo Fabricantes de equipos de comunicaciones Operadores de Telecomunicaciones Clientes de SILOCOM, C.A Proveedores de Infraestructura SILOCOM, C.A Perfil del Usuario Operador Supervisor Gerente Superusuario Administrador Necesidades de los Stakeholder o Usuarios Fabricantes de Equipos de Comunicación y Clientes de SILOCOM, C.A Operadores de Telecomunicaciones SILOCOM, C.A Alternativas y Competencias AXEDA Platform Primestone Aplicaciones Verticales de Vendedores de Equipos Descripción del Perspectiva del Resumen de Capacidades Aspectos asumidos y Dependencias Costos y Precios Licencias e Instalación Características del 20 Confidencial SILOCOM, C.A., 2010 Pág. 3 de 27

57 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision 6. Restricciones Rangos de Calidad Desempeño Tolerancia a fallas Seguridad Robustez Usabilidad Interoperabilidad Precedencia y Prioridad Otros Requerimientos del Estándares Aplicables Requerimientos del Requerimientos de Desempeño Requerimientos del Ambiente Requerimientos de Documentación Manual de Usuario Ayuda en Línea Guías de Instalación, Configuración y archivos Read Me Etiquetas y Paquetes 27 A. Atributos de las Características Error! Marcador no definido. A.1 Estatus. Error! Marcador no definido. A.2 Beneficio. Error! Marcador no definido. A.3 Esfuerzo. Error! Marcador no definido. A.4 Riesgo. Error! Marcador no definido. A.5 Estabilidad. Error! Marcador no definido. A.6 Asignado a. Error! Marcador no definido. A.7 Razón Error! Marcador no definido. Confidencial SILOCOM, C.A., 2010 Pág. 4 de 27

58 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision 1. Introducción 1.1 Propósito Visión del El propósito de este documento es generar una perspectiva única, clara y generalizada del problema que el sistema M2M Engine pretende resolver, además de identificar las prioridades del cliente y el alcance del producto. El documento está dirigido a todos los stakeholders (descritos más adelante) involucrados en el proyecto. 1.2 Alcance Este documento presenta los stakeholders y usuarios principales del sistema en desarrollo. Adicionalmente, se muestra el alcance delimitado por la comprensión del problema por parte de los stakeholders, además establece la influencia que el sistema pueda generar en el medio y mercado donde opere, tomando en cuenta: los objetivos, paradigmas y propósitos de la parte interesada. Por último, se presentan las características que debe presentar el sistema, incluyendo sus restricciones y criterios de aceptación. 1.3 Definiciones, Siglas y Abreviaciones A continuación se muestran las Definiciones, Siglas y Abreviaciones de mayor importantcia utilizadas en este documento. Para mayor información, o si desea conocer los demás términos asociados al proyecto, consulte el Glosario del proyecto. ATM: Automated Teller Machine, también conocido como Cajero Automático. Máquina expendedora utilizada para extraer dinero sin la necesidad de personal bancario. Gateway: convertidor de protocolo, encargado de transformar un stack de protocolo en otro. Feedback: Retroalimentación. Referente a la reacción con opinión (o percepción) de un stakeholder o usuario sobre el desempeño de una tarea o gestión realizada, indicando su grado de acierto. Java EE: Java Enterprise Edition. Plataforma para el desarrollo de aplicaciones empresariales, exclusivo para el lenguaje de programación Java. M2M: Machine to Machine (Máquina a Máquina). Referente a la comunicación y transferencia de datos bidireccional entre distintas máquinas. Multivendor: Referente a la interoperabilidad entre dispositivos de varios fabricantes. Remotas: Referente a las fuentes de datos, variables o procesos de una compañía que no se encuentran ubicados en la sede principal o no se encuentran al alcance de la red local de la misma. SAAS: Software As A Service (Software como un Servicio). Referente al modelo de distribución de software en línea (a través de Internet o una red privada) en donde la Confidencial SILOCOM, C.A., 2010 Pág. 5 de 27

59 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision compañía que vende el software provee el servicio de mantenimiento, operación diaria, y soporte del software usado por el cliente. SCADA: Supervisory Control And Data Acquisition (Control de Supervisión y Adquisición de Datos). Software diseñado específicamente para realizar labores de control de producción, proporcionando comunicación con dispositivos de campo y controlando procesos de forma automática desde un computador. Legacy: También conocido como Heredado. Referente a sistemas de software anticuados pero que siguen estando en uso (por parte de una empresa u organización), el cual no se puede o no se quiere reemplazar. SMS: Short Message Service (Servicio de Mensajes Cortos). Servicio de mensajería para teléfonos móviles disponible en redes digitales de telefonía. Permite el envió y recibo de mensajes de texto de hasta 160 caracteres a teléfonos móviles mediante un centro de mensajes de un operador de red telefónica. Stack: Referente a las cuatro (4) primeras capas del Modelo OSI (Nivel Físico, Nivel de Enlace de Datos, Nivel de Red y Nivel de Transporte). TPV: Terminal de Punto de Venta. Dispositivos y tecnologías que ayudan en las actividades de gestión de un establecimiento comercial de venta al público. WAP: Wireless Application Protocol (Protocolo para Aplicaciones Inalámbricas). Colección de estándares para el desarrollo de aplicaciones orientadas al entorno de comunicaciones inalámbricas. 1.4 Referencias - Glosario M2M Engine. Versión: 1.0. Código del documento: SILOCOM_M2ME_Glosario. Fecha: 03/08/10. Ubicación electrónica: \\ \Company Shared Folders\Desarrollo \Documentacion M2M\Documentos M2M Engine\ 1.5 Descripción General. El documento se encuentra formado por 10 secciones, a través de las cuales se discuten temas como el posicionamiento del negocio, los stakeholders y usuarios del sistema, descripciones y características del sistema, sus restricciones y requerimientos, entre otros. 2. Posicionamiento 2.1 Oportunidades de Negocio Estudios realizados por prestigiosas consultoras y analistas de mercado han predicho un aumento sustancial en la producción de soluciones M2M utilizando redes GPRS y GSM como medio de comunicación. Según Berg Insight, para finales del año 2009, el 1,4% de las conexiones de telefonía celular a nivel mundial pertenecieron a comunicaciones M2M. Sus predicciones indican que para los Confidencial SILOCOM, C.A., 2010 Pág. 6 de 27

60 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision próximos 5 años se estima un crecimiento interanual del 25,6% en las conexiones M2M, lo cual se traduce a un total de 187,1 millones de conexiones para al año 2014 (representando un 3,1% de las conexiones de telefonía celular a nivel mundial). La consultora ABI Research estima que en el lapso entre septiembre del 2009 a octubre del 2014, las conexiones de celular para uso de soluciones M2M se triplicaran, alcanzando un total de 36,9 millardos de dólares. Por último, la consultora IDATE estima que el valor del mercador de soluciones M2M por telefonía celular aumentara de 15,1 millardos de dólares en el 2009 a 36,9 millardos de dólares para el año Por otra parte, el mercado de soluciones M2M utilizando conexiones celulares en Venezuela todavía se encuentra en sus inicios. Son muy pocos los esfuerzos realizados para ofrecer este tipo de soluciones y existe una amplia gama de negocios en el país que necesitan, o sacarían provecho, de tal tecnología. Con el desarrollo del sistema M2M Engine se busca ofrecer una aplicación robusta y de producción nacional, que compita con las actuales soluciones M2M extranjeras disponibles en el mercado y que sea acomode a las necesidades de las empresas nacionales. El desarrollo satisfactorio del sistema M2M Engine establecerá a SILOCOM, C.A. en la posición de líder de mercado de soluciones M2M mediante telefonía celular en territorio venezolano, con expectativas de expandir la distribución de la aplicación hacia el resto de América Latina. 2.2 Declaración del Problema El problema de Afecta a Cuyo impacto es La alta fragmentación de soluciones M2M, las cuales están generalmente enfocadas a una sola aplicación. Tal variedad de soluciones y actividades de estandarización disminuyen el desarrollo del mercado M2M. Empresas de distintos sectores, entre ellos: - Servicios Públicos (gas, agua, electricidad) - Petróleo - Seguridad - Banca (ATM s, TPV s) - Tele medición - Flotas de Vehículos y Transporte Público - Servicios (Operadoras de Dispensadores, Servicios de Ascensores, Fotocopiadoras, etc.) La fragmentación en las soluciones M2M dificulta las labores de masificación en las empresas. Se gasta mucho tiempo y recursos en replicar actividades para Confidencial SILOCOM, C.A., 2010 Pág. 7 de 27

61 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision Una solución exitosa sería cada solución M2M distinta. Poder unir en una plataforma única todos los aspectos comunes de las soluciones que tienen que ver con la obtención y almacenamiento de los datos de los dispositivos de campo. Dicha plataforma debe contar con una interfaz abierta para desarrollar a nivel de aplicación las funcionalidades específicas de cada solución M2M. 2.3 Declaración del Posicionamiento del Para Quién El M2M Engine Integradores y compañías de servicios públicos, petróleo y banca. Les interesa la monitorización y control en tiempo real de sus activos y procesos remotos. Es un de Control distribuido en tiempo real. Qué Simplifica las complejidades de los protocolos y comunicaciones con los activos y procesos de campo, de tal forma que se facilite y acelere la implementación de soluciones M2M. Se diferencia de 1. La obtención manual de los datos, lo cual incluye visitas de campo para la obtención de los datos de los equipos de campo y la descarga y procesamiento de datos en casa. 2. Aplicaciones especializadas (verticales) de alto costo que carecen de opciones de monitorización y control mediante dispositivos como celulares e Internet (ej. Efacec ACS Prism 1 y PRIMESTONE 2 ). 3. Soluciones similares que llevan poco tiempo en el mercado o que se encuentran en desarrollo en los mercadores europeos y norteamericanos (ej. AXEDA Platform 3 ) Confidencial SILOCOM, C.A., 2010 Pág. 8 de 27

62 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision Nuestro Debe cumplir con ser multivendor con respecto a los dispositivos de campo con los cuales se integrará. Ofrecerá múltiples interfaces de usuario: Internet, s Legacy, correo electrónico, consolas locales de los dispositivos, teléfonos móviles (vía WAP y SMS). También ofrecerá flexibilidad en la manipulación de la data y para la personalización de la aplicación. 3. Descripciones de los Stakeholders y Usuarios 3.1 Demografía del Mercado Las soluciones M2M son percibidas como soluciones complejas y a su vez corresponden a la operación medular de las empresas. Con el transcurso del tiempo y los avances tecnológicos, las soluciones M2M se han tornando indispensables para todo tipo de compañías a nivel mundial. En la actualidad, existe una gran cantidad de sectores en el mercado que hacen uso de dichas soluciones, entre ellos: Servicios Públicos, Petrolero, Seguridad, Bancario, Servicios de Flotas de Vehículos y Transporte Público, etc. El sistema M2M Engine tendrá un alcance inicial limitado a Latinoamérica, apoyando el negocio de integración de SILOCOM C.A. en las locaciones en donde tiene presencia (Venezuela y México). A medida que madure la aplicación, su distribución se expandirá a través de Latinoamérica como un negocio independiente al actual de la empresa. 3.2 Resumen de Stakeholders Nombre Descripción Responsabilidades Fabricantes de equipos de campo Fabricantes de equipos de comunicaciones Operadores de Telecomunicaciones Gran cantidad de empresas que fabrican equipos que el usuario final desea monitorizar y controlar. Son fabricantes de equipos que permiten la comunicación entre los equipos ubicados en campo y el sitio en donde se encuentra la plataforma a partir de donde se distribuye la información al usuario final. Son aquellas operadoras de telefonía celular o telefonía alámbrica por cuyas redes será Facilitar información sobre sus equipos y los protocolos de comunicación utilizados por los mismos. Ofrecer las funcionalidades requeridas para poder transmitir los diferentes tipos de tráfico. Proveer las arquitecturas de red adecuadas para la implementación de las soluciones M2M. Confidencial SILOCOM, C.A., 2010 Pág. 9 de 27

63 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision Clientes de SILOCOM, C.A. Proveedores de Infraestructura SILOCOM, C.A. transmitida la información de los dispositivos de campo. Diversas empresas que implementan soluciones M2M para su operación. Empresas que prestan servicios de hospedaje y alquiler de servidores dedicados. Compañía integradora de los diferentes componentes de una solución M2M y desarrolladora de la aplicación M2M Engine. Facilitar los recursos internos para la implementación, prueba y puesta en producción del sistema M2M Engine. Prestar las herramientas y calidad de servicio (velocidad de transmisión, disponibilidad, etc.) necesarias para tener un ambiente de ejecución optimo para el sistema M2M Engine. SILOCOM, C.A. se encargará de: Proveer el financiamiento para el desarrollo del sistema M2M Engine. Proveer los recursos necesarios para las labores de diseño y desarrollo de la aplicación. Búsqueda de clientes para la aplicación en desarrollo. Supervisar y evaluar el progreso del proyecto. 3.3 Resumen de los Usuarios Nombre Descripción Responsabilidades Stakeholder Operador Supervisor Gerente Superusuario Realiza la monitorización continua de los dispositivos de campo, a través de las interfaces desarrolladas con la aplicación. Persona responsable directa de la operación de los dispositivos de campo. Persona que utiliza el sistema para identificar el rendimiento de los equipos de campo. También lo utiliza como fuente de datos para apoyar la toma de decisiones del negocio. Persona que administra el sistema M2M Engine. - Atender las situaciones anormales presentadas por los dispositivos - Administrar los equipos de campo en cuanto a su operación diaria. - Responsabilidades gerenciales relacionadas con la operación del sistema. - Arrancar el sistema. - Llevar a cabo la gestión de usuarios. - Mantener disponible el sistema y su Clientes de SILOCOM, C.A. Clientes de SILOCOM, C.A. Clientes de SILOCOM, C.A. SILOCOM, C.A. Confidencial SILOCOM, C.A., 2010 Pág. 10 de 27

64 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision rendimiento. Administrador Persona designada dentro del personal de la empresa cliente encargada de la gestión de usuarios de la empresa y de la configuración de dispositivos de campo. - Gestionar los usuarios del sistema, otorgando los privilegios de acceso al mismo de acuerdo a la política de la empresa cliente. - Configurar los dispositivos de campo de la empresa a través del sistema. Clientes de SILOCOM, C.A. 3.4 Ambiente Usuario En la actualidad, existen dos tipos de ambientes de usuario en el mercado. El primero se caracteriza por tener una obtención de datos de los dispositivos de campo totalmente manual. Las empresas deben contar con flotillas de técnicos que se dirijan al campo para realizar la obtención de los datos de los dispositivos en sitio. La duración de esta actividad varía dependiendo del segmento de negocio de la empresa, pero usualmente se trata de una actividad sumamente lenta. Identificar una falla en un dispositivo y solucionarla implica un gasto de tiempo enorme debido a que se hace necesaria la visita de campo para identificar la falla (sin saber de forma previa cuales herramientas o repuestos llevar para la resolución de la misma). Las visitas de campo de inspección, con el fin de determinar el estado de los equipos de campo, se vuelven rutinarias y generan costos elevados de personal de campo. Por otro lado, existe un segundo tipo de ambiente en donde las empresas realizan una monitorización parcial de sus equipos de campo, mediante alguna aplicación de monitorización ya existente en el mercado. Esto se debe, en mayor parte, a las limitaciones en la cobertura de los medios de comunicación contratados por las empresas (las cuales, generalmente, no incluyen la telefonía celular). Por lo tanto, existe un porcentaje de la operación que las empresas no pueden monitorizar o controlar a distancia. 3.5 Perfil del Stakeholder Fabricantes de equipos de campo Representatividad Descripción Tipo Responsabilidad Elster, Actaris, Cewe, Canon, Racom Colaborador del Proyecto. Formado por una cantidad de empresas que fabrican equipos que el usuario final desea monitorizar y controlar. Gurú del Negocio Facilitar información sobre sus equipos y los protocolos de comunicación utilizados por los mismos. Confidencial SILOCOM, C.A., 2010 Pág. 11 de 27

65 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision Criterios de Éxito Nivel de participación Entregables Que las variables manejadas por sus equipos sean las mismas que se manejen en el sistema. Además, que sea posible realizar operación de control exitosamente. Proveer equipos de campo y la información necesaria relacionada a ellos. El stakeholder debe proveer los documentos de implementación de protocolos de comunicación de sus equipos Fabricantes de equipos de comunicaciones Representatividad Hongdian, Java Box, Motorola Descripción Proveedor. Empresas fabricantes de equipos que permiten la comunicación entre los equipos ubicados en campo y el sitio en donde se encuentra la plataforma a partir de donde se distribuye la información al usuario final. Tipo Gurú de Negocio Responsabilidad Ofrecer las funcionalidades requeridas para poder transmitir los diferentes tipos de tráfico. Criterios de Éxito No aplica. Nivel de Proveedor de equipos de comunicación. participación Entregables Manuales técnicos de configuración y operación del hardware Operadores de Telecomunicaciones Representatividad Descripción Tipo Responsabilidad Criterios de Éxito Nivel de participación Entregables Movistar, Digitel, Movilnet, CANTV Proveedor de Servicio y/o Cliente. Empresas operadoras de telefonía celular o telefonía alámbrica por cuyas redes será transmitida la información de los dispositivos de campo. Gurú de Negocio y/o Usuario Experto. Proveer las arquitecturas de red adecuadas para la implementación de las soluciones M2M. El M2M Engine se mantenga en línea permanentemente (con un 99% de disponibilidad). Prestan servicio para uno de los componentes de la solución y se consideran como clientes potenciales. Proveer líneas telefónicas y canales satelitales. El stakeholder recibirá manuales de usuario de software y dispositivos de comunicación Clientes de SILOCOM, C.A. Representatividad Descripción Tipo Responsabilidad Criterios de Éxito Electricidad de Caracas, ELEVAL, Racom, Contino, Movistar, Digitel Cliente. Diversas empresas que implementan soluciones M2M para su operación. Usuario Experto. Facilitar los recursos internos para la implementación, prueba y puesta en producción del sistema M2M Engine. Que el sistema M2M Engine cuente con un nivel de disponibilidad del 99%, la confiabilidad de los datos sea del 99,9% y que el sistema se Confidencial SILOCOM, C.A., 2010 Pág. 12 de 27

66 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision Nivel de participación Entregables integre exitosamente con sus actives. Clientes y Promotores. Proveer los formatos necesarios para el levantamiento de información de sus equipos, configuración y arquitectura de red Proveedores de Infraestructura Representatividad Descripción Tipo Responsabilidad Criterios de Éxito Nivel de participación Entregables HostICan, Daycohost, The Planet Proveedor. Empresas que prestan servicios de hospedaje y alquiler de servidores dedicados. Gurú de Negocio. Prestar las herramientas y calidad de servicio (velocidad de transmisión, disponibilidad, etc.) necesarias para tener un ambiente de ejecución optimo para el sistema M2M Engine. No aplica. Proveedor de servidores dedicados. El stakeholder está encargado de brindar ayuda en línea sobre configuración de servidores dedicados SILOCOM, C.A. Representatividad Efraín Cardona, Henry Varona, Luis Salazar, Javier Isern, Nicolás Cova, Juan Carlos Abreu Descripción Desarrollador. Compañía integradora de los diferentes componentes de una solución M2M y desarrolladora de la aplicación M2M Engine. Tipo Gurú de Negocio y Usuario Experto. Responsabilidad SILOCOM, C.A. cumplirá con las responsabilidades de: proveer el financiamiento para el desarrollo del sistema, proveer los recursos necesarios para las labores de diseño y desarrollo de la aplicación y supervisar y evaluar el progreso del proyecto. Criterios de Éxito Que el sistema M2M Engine cuente con un nivel de disponibilidad de 99% y un nivel de confiabilidad de datos de 99,9%. Nivel de Ejecutor, Promotor, Financiamiento del desarrollo. participación Entregables El stakeholder estará encargado de la redacción de los documentos de Visión, Especificación de Requerimientos del, Manual de Usuario, Documento de Pruebas y material de mercadeo. 3.6 Perfil del Usuario Operador Representatividad Clientes de SILOCOM, C.A. Descripción Realiza la monitorización continua de los dispositivos de campo, a través de las interfaces desarrolladas con la aplicación. Tipo Usuario Experto. Responsabilidad Atender las situaciones anormales presentadas por los dispositivos. Criterios de Éxito El sistema M2M Engine debe contar con una interfaz grafica con el Confidencial SILOCOM, C.A., 2010 Pág. 13 de 27

67 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision Nivel de participación Entregables usuario amigable y contar con un nivel alto de disponibilidad. Ofrece feedback sobre los requerimientos implementados en el sistema M2M Engine. Ninguno Supervisor Representatividad Descripción Tipo Responsabilidad Criterios de Éxito Nivel de participación Entregables Clientes de SILOCOM, C.A. Persona responsable directa de la operación de los dispositivos de campo. Usuario Experto. Administrar los equipos de campo en cuanto a su operación diaria. El sistema M2M Engine debe contar con una interfaz grafica con el usuario amigable y contar con un nivel alto de disponibilidad. Ofrece feedback sobre los requerimientos implementados en el sistema M2M Engine. Ninguno Gerente Representatividad Descripción Tipo Responsabilidad Criterios de Éxito Nivel de participación Entregables Clientes de SILOCOM, C.A. Persona que utiliza el sistema para identificar el rendimiento de los equipos de campo. También lo utiliza como fuente de datos para apoyar la toma de decisiones del negocio. Usuario Experto o Casual. Responsabilidades gerenciales relacionadas con la operación del sistema. El sistema M2M Engine debe contar con una interfaz grafica con el usuario amigable y contar con un nivel alto de disponibilidad. Adicionalmente, el sistema debe contar con facilidades para la generación de reportes y manipulación de datos. Ofrece feedback sobre los requerimientos implementados en el sistema M2M Engine. Debe proveer los documentos de levantamiento de requerimientos para el sistema Superusuario Representatividad Descripción Tipo Responsabilidad Criterios de Éxito Nivel de participación SILOCOM, C.A. Persona que administra el sistema M2M Engine. Usuario Experto. El Superusuario tiene como responsabilidades: arrancar el sistema, llevar a cabo la gestión de usuarios y mantener disponible el sistema y su rendimiento. Tener acceso total a todas las funcionalidades del sistema. Contar con herramientas de administración del sistema de fácil uso. Que el sistema tenga un alto rendimiento. Definir y evaluar requerimientos. Confidencial SILOCOM, C.A., 2010 Pág. 14 de 27

68 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision Entregables Debe proveer los documentos de levantamiento de requerimientos para el sistema Administrador Representatividad Descripción Tipo Responsabilidad Criterios de Éxito Nivel de participación Entregables Clientes de SILOCOM, C.A. Persona designada dentro del personal de la empresa cliente encargada de la gestión de usuarios de la empresa y de la configuración de dispositivos de campo. Usuario Experto. El Administrador tiene como responsabilidades: Gestionar los usuarios del sistema, otorgando los privilegios de acceso al mismo de acuerdo a la política de la empresa cliente y configurar los dispositivos de campo de la empresa a través del sistema. Contar con herramientas de administración y configuración del sistema de fácil uso. Que el sistema tenga un alto rendimiento. Definir y evaluar requerimientos. Debe proveer los documentos de levantamiento de requerimientos para el sistema. 3.7 Necesidades de los Stakeholder o Usuarios Fabricantes de Equipos de Comunicación y Clientes de SILOCOM, C.A. Necesidad Prioridad Problema que origina la necesidad Solución Actual Soluciones Propuestas (Características Preliminares) Realizar servicio en tiempo real a sus equipos de campo. Alta - Media Las visitas de campo para el mantenimiento de dispositivos en ubicaciones remotas implican una operación costosa y compleja. Cuadrillas de Soporte Técnico que realizan las visitas de campo. La monitorización en línea de los equipos de campo a través de redes de comunicación. Disminuir los tiempos de respuesta para fallas en los equipos. Alta Media Al no haber una monitorización en tiempo real de los equipos, los tiempos de respuesta para atender fallas en los equipos son muy largos. Esperar a recibir una llamada de una cuadrilla de Soporte Técnico o de un usuario final reportando la falla. Identificar y resolver las fallas de los equipos en tiempo real, mediante la monitorización y control de los equipos en línea. Confidencial SILOCOM, C.A., 2010 Pág. 15 de 27

69 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision Operadores de Telecomunicaciones Necesidad Prioridad Problema que origina la necesidad Solución Actual Soluciones Propuestas (Características Preliminares) Venta de líneas celulares de datos. Alta El negocio de un operador de telecomunicaciones es la venta de líneas celulares. En la actualidad, las líneas celulares de voz tienen un alto nivel de penetración en el mercado, lo cual genera un crecimiento bajo en las ventas. Los operadores deben enfocarse en la venta de servicios y líneas celulares de datos para aumentar sus ingresos. Los operadores de telecomunicaciones intentan aumentar sus ingresos ofreciendo los siguientes servicios: Servicios de Mensajería (SMS, MMS). Tonos de repique. Banda ancha inalámbrica. Ofrecer líneas celulares de datos que puedan ser utilizadas con aplicaciones M2M SILOCOM, C.A. Necesidad Prioridad Problema que origina la necesidad Solución Actual Soluciones Propuestas (Características Preliminares) Atender las necesidades de sus clientes en cuanto a soluciones M2M. Alta La diversidad de las aplicaciones M2M disponibles en el mercado dificultan la implantación rápida y personalizada de las soluciones M2M basadas en las necesidades de los clientes. La utilización de aplicaciones verticales orientadas a la satisfacción de necesidades especificas. Tener una plataforma M2M que permita la implantación rápida y costo-efectiva de distintas soluciones M2M. Estar abierto a la posibilidad de integrarse con otras aplicaciones M2M. Alta Existen clientes que tienen soluciones parciales M2M asociadas a sus aplicaciones de monitorización que no desean desechar. Al tener una aplicación de monitorización vertical, los clientes deben depender de reportes vía telefónica Tener una solución M2M vía telefonía celular o comunicación satelital para la monitorización del 100% de los Confidencial SILOCOM, C.A., 2010 Pág. 16 de 27

70 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision generados por sus equipos de campo para cubrir las carencias de la solución. dispositivos de campo del cliente y que se pueda integrar con la aplicación previamente utilizada por el cliente. Monitorización en tiempo real y de alta disponibilidad. Alta La aplicación utilizada por el cliente es medular para su negocio y necesita estar siempre en línea. Uso de cuadrillas de campo o soluciones parciales en los casos en que la conectividad lo permite. Una aplicación que permita mantener constantemente en línea los equipos de campo. Tener una solución M2M con diseño modular y distribuido de forma que sea escalable, facilite el mantenimiento, permita adaptarse a una configuración de red y funcional a las necesidades del cliente. Alta Prototipo actual del M2M Engine tiene un diseño monolítico, lo cual dificulta la inclusión de nuevas funcionalidades e impide el crecimiento de la aplicación a medida que crece el mercado y la cantidad de usuarios y dispositivos conectados al sistema. En la actualidad, para que la aplicación crezca se debe incrementar la capacidad del hardware que lo contiene. Tener una aplicación empresarial distribuida, que permita la inclusión de nuevas funcionalidades y módulos, de alto rendimiento y disponibilidad. 3.8 Alternativas y Competencias AXEDA Platform Fortalezas Alianza con fabricantes e integradores capaces de personalizar la aplicación de acuerdo a las necesidades del cliente. Producto en etapas avanzadas de desarrollo. Empresa desarrolladora con rápido crecimiento y desarrollo motivado por alta inversión privada. Debilidades Presencia exclusiva en el territorio estadounidense y europeo Primestone Fortalezas Debilidades Aplicación muy completa para el sector Aplicación exclusiva para negocios del eléctrico. sector eléctrico. Confidencial SILOCOM, C.A., 2010 Pág. 17 de 27

71 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision Presencia fuerte en varios países latinoamericanos Aplicaciones Verticales de Vendedores de Equipos Fortalezas Aplicaciones hechas a la medida para los equipos manufacturados por el vendedor. Debilidades Incompatibles con dispositivos manufacturados por otras compañías. 4. Descripción del 4.1 Perspectiva del El sistema M2M Engine 2.0 estará diseñado para ser una aplicación completamente independiente. Podrá coexistir con otras aplicaciones desplegadas tanto en el servidor web de SILOCOM, C.A. como en los servidores web de los clientes. El bloque central del sistema, denominado el core del M2M Engine 2.0, contará con un conjunto de interfaces para distintos tipos de conexiones. Entre las interfaces más importantes destacan la interfaz con el usuario de la aplicación a través de internet, una interfaz de comunicación con las aplicaciones existentes de los clientes para el intercambio de información y una interfaz de comunicación para el intercambio de información con los dispositivos de campo. 4.2 Resumen de Capacidades Tabla 4-1 Soporte de al Cliente Necesidades del Cliente Características del Monitorizar el estado y controlar remotamente los equipos de campo en tiempo real. Recibir alertas de condiciones, eventos y fallas de los dispositivos de campo que requieran atención. Poder integrar equipos de cualquier fabricante. Realizar el control y monitorización de los equipos a través de cualquier interfaz de usuario, tales como: El sistema se comunicara con los equipos de campo mediante stacks de protocolo que pueden ser personalizados según las características de un equipo y orientados a realizar una gestión de red diseñada para mantener los equipos en línea permanentemente. El sistema recibirá y procesara en tiempo real la información proveniente de los equipos de campo, dirigiéndola a la interfaz de usuario correspondiente según la configuración establecida. Manejar diversos stacks de protocolos, con la opción de agregar stacks nuevos en el futuro para integrarse con protocolos nuevos. Utilizar un formato en XML que permita la supervisión de los datos por parte del usuario a través de cualquier dispositivo (ej. Celular, Confidencial SILOCOM, C.A., 2010 Pág. 18 de 27

72 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision Aquella a la cual está acostumbrado el cliente (aplicación existente en la empresa). Teléfono celular (ej. SMS). Aplicación Web. Otro (depende de los requerimientos del cliente). Manipular y procesar datos obtenidos de los dispositivos de campo para su análisis. Administrar los usuarios del sistema de forma que realicen solo aquellas funciones que les sean asociadas. Tener un sistema seguro, escalable, confiable y disponible. computador) e interfaz grafica (ej. Web, SMS, aplicación). Los datos podrán ser procesados y manipulados en tiempo real, con la opción de crear nuevas variables, condiciones, eventos o acciones. De la misma forma, el sistema debe disponer de herramientas para el análisis de la información almacenada en la base de datos. El sistema contara con herramientas de configuración y gestión para la creación y administración de usuarios. Sera posible asignarle privilegios y permisos a cada usuario en base a las actividades que deben realizar dentro del sistema. La implementación del sistema M2M Engine se realizara con un lenguaje diseñado para el desarrollo de aplicaciones empresariales distribuidas, con el fin de desarrollar una aplicación ligera, distribuida y segura (Java EE). 4.3 Aspectos asumidos y Dependencias El sistema M2M Engine debe cumplir con las pautas establecidas por SILOCOM, C.A. Por lo tanto, el sistema debe cumplir con los siguientes aspectos: Debe tener una interfaz de cara a los protocolos de comunicación que independice la adquisición de datos y ejecución de comandos de los detalles de implementación de cada protocolo. Debe existir una interfaz que permita el intercambio de información entre el sistema y múltiples interfaces graficas con el usuario. Dicha interfaz debe ser independiente del lenguaje de implementación, dispositivo de visualización o ubicación del usuario. El sistema debe desarrollarse utilizando Java EE (versión 6) como lenguaje de implementación, MySQL para la base de datos del sistema y Hibernate como herramienta de mapeo objeto-relacional. El sistema debe ser portable y ejecutable en cualquier sistema operativo. 4.4 Costos y Precios Los costos asociados en el desarrollo del sistema M2M Engine se consideran confidenciales para el momento de redacción del documento presente. No obstante, es necesario mencionar que en el desarrollo de la aplicación se incurren gastos en los siguientes recursos: ingenieros de desarrollo, Confidencial SILOCOM, C.A., 2010 Pág. 19 de 27

73 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision pasantes (2), servidores dedicados, servidores de desarrollo y pruebas, routers, firewalls y material de mercadeo. Por otro lado, el precio de venta de la aplicación se ve afectado por la forma que se distribuya el software: bajo el modelo SAAS o bajo modalidad de instalación en sitio. Bajo la modalidad de SAAS, el precio del software se ve afectado por las siguientes variables: Número de usuarios conectados concurrentes conectados al sistema. Frecuencia de actualizaciones de datos. Numero de comandos a ejecutar en los dispositivos de campo. Funcionalidades del sistema a contratar. En la modalidad de instalación en sitio, el precio del software se ve sujeto a las siguientes variables: Licencia base del software. Licencia por modulo adicional. Licencia por dispositivo de campo. Soporte y mantenimiento anual del sistema. Configuración e instalación del sistema. Es importante destacar que para el momento de redacción del documento presente no se ha establecido el precio base para cada modalidad ni como las variables afectaran el precio final. 4.5 Licencias e Instalación Para el desarrollo del sistema M2M Engine 2.0 no es necesaria la adquisición de licencias dado que el lenguaje utilizado para la implementación, Java EE, pertenece al ámbito del software libre (se distribuye bajo la licencia GNU GPL a partir del año 2007). No obstante, el sistema será distribuido como software propietario (también conocido como software no libre o de código cerrado). SILOCOM, C.A. distribuirá cada copia del sistema (en su modalidad de instalación en sitio) con un conjunto de licencias de uso únicas para cada cliente. El conjunto de licencias estará formado por una licencia base para el modulo principal del sistema y una licencia aparte para cada modulo adicional que solicite el cliente. Tales licencias vendrán acompañadas con un número de serial único y verificable, con el fin de evitar el uso indebido del sistema. La distribución del sistema bajo el modelo SAAS carecerá de licencias, debido a que los clientes realizaran contratos con SILOCOM, C.A. para hacer uso del sistema, quienes lo presentaran como un servicio web. 5. Características del ID Característica Característica Descripción Prioridad M2M_CT_1 Realizar consultas periódicas a los dispositivos de campo. El sistema debe realizar consultas periódicos a los dispositivos de campo con el Confidencial SILOCOM, C.A., 2010 Pág. 20 de 27 Alta

74 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision M2M_CT_2 M2M_CT_3 M2M_CT_4 M2M_CT_5 M2M_CT_6 M2M_CT_7 M2M_CT_8 Mantener una base de datos con la información de los dispositivos. Realizar gestión de usuarios. Realizar gestión del sistema. Interfaz grafica amigable para la monitorización y control de dispositivo. Generar reportes de datos. Alertar a los usuarios cuando se generan alarmas en los equipos. Permitir acceso a la información a través de distintos medios y aplicaciones. fin de actualizar el estado del equipo y recopilar información de interés para el cliente. El sistema debe alimentar una base de datos con la información recopilada de los equipos de campo y permitir que los usuarios puedan consultar la información. Herramienta para la gestión de usuarios que cuente con comandos básicos como crear, modificar y eliminar usuarios, asignar permisos, etc. Herramienta para la gestión del sistema, en el cual se tenga acceso fácil a la configuración de la aplicación. El sistema debe contar con una interfaz grafica que facilite la lectura de los datos y que le permita al usuario tener acceso fácil a las funcionalidades del sistema. El sistema debe contar con una herramienta que genere reportes basados en los datos de los dispositivos almacenados en la base de datos. La interfaz grafica debe presentar un mecanismo de notificaciones que pueda alertarle al usuario cuando se genere alguna falla o evento en un equipo de campo. La interfaz grafica del sistema debe ser accesible desde distintos dispositivos, tales como computadoras y teléfonos celulares. En caso de no poder tener acceso a la interfaz grafica, debe ser posible el envío de la información por otros medios, como SMS. Confidencial SILOCOM, C.A., 2010 Pág. 21 de 27 Alta Media-Baja Media-Baja Media Alta-Media Baja Alta-Media M2M_CT_9 Configurar dispositivos de El sistema debe contar con Media

75 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision M2M_CT_10 M2M_CT_11 M2M_CT_12 campo. una herramienta para la configuración de los dispositivos de campo. Interfaz grafica intuitiva para la configuración de equipos. Servir como Gateway entre diferentes protocolos de comunicación. Permitir organizar los datos de acuerdo a distintos parámetros (ej. tipo de cliente, por región, por volumen, por nivel, etc.). La herramienta de configuración de equipos e campo debe contar con una interfaz grafica intuitiva que facilite las labores de configuración. El sistema debe contar con una herramienta que tome la información correspondiente a un stack de protocolo y lo convierta en otro. La interfaz grafica del sistema debe ser capaz de mostrar la información almacenada en la base de datos a través de distintas visualizaciones, dependiendo de la configuración que tenga el sistema. Alta Baja Baja 6. Restricciones Las actividades de desarrollo del sistema M2M Engine 2.0 se ven sujetas a las siguientes restricciones: Implementación de stacks de protocolos depende de que los fabricantes de dispositivos faciliten la información relacionada sus equipos y como trabajan con los protocolos de comunicación. Acomodarse a las facilidades prestadas por el sistema operativo, CentOS, instalado en los servidores dedicados durante la etapa de desarrollo del sistema. La fase de pruebas de las diferentes soluciones M2M a través del sistema está sujeta a la disponibilidad de los clientes de SILOCOM, C.A. Utilizar OpenVPN para la creación de redes virtuales privadas. Presupuesto para el desarrollo del sistema pre-establecido y no variable por el resto del año Las actividades de la fase de pruebas se ven sujetas a la disponibilidad de las redes en los clientes que se presten para las pruebas y de los tiempos de respuesta que permitan dichas redes. Confidencial SILOCOM, C.A., 2010 Pág. 22 de 27

76 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision 7. Rangos de Calidad 7.1 Desempeño Dado que la comunicación con los equipos de campo debe ser en tiempo real, los tiempos de respuesta del sistema deben ser lo más cortos dentro de lo posible (es necesario recalcar que las redes GPRS y satelitales agregan un grado de latencia). Del mismo modo, la adquisición de datos almacenados en la base de datos debe realizarse en el menor tiempo posible. 7.2 Tolerancia a fallas El sistema debe contar con un nivel alto de tolerancia de fallas. Entre sus rasgos más importantes se destacan la posibilidad de recuperarse de una falla por su cuenta y preservar la integridad de la información de la base de datos al ocurrir una falla. Adicionalmente, el sistema debe contar con una codificación para los errores del sistema y una bitácora de fallas que facilite las labores de debugging por el personal de mantenimiento. Por último, las fallas generadas en un modulo no deberían afectar los demás módulos del sistema o detener la operación del sistema completo. 7.3 Seguridad El sistema debe implementar un sistema de permisología que limite las funciones de los usuarios en el sistema y su acceso a la información almacenada en la base de datos. Adicionalmente, el sistema debe contar con mecanismos de seguridad que protejan la transmisión de datos entre los dispositivos de campo y la aplicación. 7.4 Robustez El sistema debe soportar un alto nivel de concurrencia de conexiones con dispositivos de campo y usuarios. La arquitectura del sistema debe estar basado en un diseño escalable, el cual pueda soportar el crecimiento masivo de conexiones (tanto de maquinas como de usuarios). El sistema debe mantener la integridad de la información en la base de datos en una tasa de 99,9% y tener una disponibilidad con una tasa de 99,9%. 7.5 Usabilidad El sistema contará con una interfaz gráfica clara, sencilla e intuitiva, que refleje las funcionalidades del sistema y permita al usuario ubicarlas de forma rápida. El sistema debe presentar una curva de aprendizaje baja, que facilite y agilice el proceso de asimilación de la aplicación dentro de las empresas clientes. El sistema debe contar con una herramienta de configuración que permita personalizar la interfaz grafica del sistema de acorde a la solución M2M y necesidades del cliente. 7.6 Interoperabilidad El sistema debe ser capaz de compartir información con aplicaciones verticales y sistemas CRM ya existentes en las infraestructuras de los clientes. Además, el sistema debe ser capaz de operar en conjunto con un sistema de facturación (aun no establecido) para poder ofrecer el sistema bajo el modelo SAAS. Confidencial SILOCOM, C.A., 2010 Pág. 23 de 27

77 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision 8. Precedencia y Prioridad En la etapa actual de desarrollo del sistema, las actividades del equipo desarrollador se encuentran orientadas a la implementación de las siguientes características (enumeradas en orden descendente de prioridad): Realizar consultas periódicas a los dispositivos de campo [M2M_CT_1]. Mantener una base de datos con la información de los dispositivos [M2M_CT_2]. Configurar dispositivos de campo [M2M_CT_9]. Generar reportes de datos [M2M_CT_6]. Permitir acceso a la información a través de distintos medios y aplicaciones [M2M_CT_8]. Realizar gestión de usuarios [M2M_CT_3]. Realizar gestión de sistema [M2M_CT_4]. Las características mencionadas anteriormente están pautadas para ser desarrolladas en el periodo de tiempo comprendido entre los meses de julio y diciembre del año 2010 y formaran el grueso de las actividades de los dos pasantes de la compañía (Juan Carlos Abreu y Nicolás Cova). La implementación de las siguientes características está pautada para etapas más tardías de desarrollo (en orden descendiente de importancia): Interfaz grafica amigable para la monitorización y control de dispositivo [M2M_CT_5]. Interfaz grafica intuitiva para la configuración de equipos [M2M_CT_10]. Alertar a los usuarios cuando se generan alarmas en los equipos [M2M_CT_7]. Servir como Gateway entre diferentes protocolos de comunicación [M2M_CT_11]. Permitir organizar los datos de acuerdo a distintos parámetros (ej. tipo de cliente, por región, por volumen, por nivel, etc.) [M2M_CT_12]. 9. Otros Requerimientos del 9.1 Estándares Aplicables El sistema M2M Engine 2.0 debe cumplir con los siguientes estándares: Comunicación o o o o o o o o o Modbus DNP3 IEC61107 ANSI C12 OPC TCP/IP UDP GPRS EDGE Confidencial SILOCOM, C.A., 2010 Pág. 24 de 27

78 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision o HDPA o SCPC Base de datos o ODBC Programación o HTML 2.0 o XML o Java EE Metodología de proyecto o RUP 9.2 Requerimientos del Para la ejecución del sistema es necesario que este desplegado en un servidor que tenga instalado el servidor de aplicaciones Glassfish V3 de Oracle. Por otra parte, para que los clientes (o usuarios finales) tengan acceso al sistema basta tener una computadora con un navegador Web (con soporte HTML 2.0) y conexión a internet o enlace dedicado a una operadora de telecomunicaciones. Se podrá tener acceso al sistema a través de la mayoría de los navegadores web disponibles en el mercado. No obstante, se recomiendan los navegadores Mozilla Firefox, Microsoft Internet Explorer y Google Chrome para el funcionamiento optimo del sistema. Por último, al tener acceso al sistema mediante un navegador Web, se vuelve irrelevante el tipo de sistema operativo que este instalado en las computadoras del cliente. 9.3 Requerimientos de Desempeño El desempeño del sistema M2M Engine 2.0, dada su naturaleza Web, se ve ligado estrechamente con la arquitectura de red que posea el cliente. Las medidas de volumen de carga de datos, ancho de banda y capacidad de conexión dependerán de las capacidades del servicio de red que tengan contratado con su operadora de telecomunicaciones (si se utiliza el sistema bajo el modelo SAAS) o de la estructura de la red interna del cliente (si se utiliza el sistema bajo la modalidad de instalación en sitio). Tomando en cuenta los datos del sistema M2M Engine 1.0, se espera que los tiempos de respuesta del sistema M2M Engine 2.0 sean menores a los 10 segundos (teniendo una conexión a internet o dedicada al operador optima). Confidencial SILOCOM, C.A., 2010 Pág. 25 de 27

79 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision 9.4 Requerimientos del Ambiente Los requerimientos de ambiente varían con la modalidad de uso del sistema M2M Engine2.0. Bajo la modalidad SAAS, el cliente no existen requerimientos de ambiente dado que el sistema se estaría ejecutando desde un servidor ubicado en un datacenter, controlado por SILOCOM C.A., en donde se asegura la infraestructura y ambiente optimo para los servidores. Para la modalidad de instalación en sitio, es necesaria la instalación en un servidor Web y su despliegue a través de un servidor de aplicaciones que soporte Java EE. Dado que el acceso a la aplicación se realiza a través de navegadores Web, no es necesaria la instalación de software adicional en las maquinas que se vayan a conectar al sistema. Se recomienda que la habitación en donde su ubique el servidor de instalación cumpla con los requerimientos estándar para el ambiente favorable para el servidor: utilizar aire acondicionado para el control de la temperatura en la habitación, temperatura promedio entre C, nivel de humedad del 40 55%, dispositivos de energía de respaldo (baterías, generadores de diesel) y suelo alzado. 10. Requerimientos de Documentación 10.1 Manual de Usuario El sistema M2M Engine 2.0 contará con un Manual de Usuario que indicara las funcionalidades del sistema y orientara a los usuarios finales en el uso correcto del mismo. En aquellos casos que sean necesarios, las explicaciones podrán estar acompañadas con capturas de pantalla para asegurar un mejor nivel de comprensión por parte del lector. Deberá contar con un capitulo de introducción en donde se elaboren los objetivos y usos del manual y una breve introducción general al sistema. Es indispensable el uso de una índice de contenidos, figuras y tablas para agilizar el acceso a la información que pueda solicitar el usuario. De ser requerido, el manual contara con un glosario de términos para ayudar en la comprensión de usuarios casuales (o no expertos). Para el momento de redacción de este documento, no se han establecido las pautas de formato, diseño grafico e impresión del manual Ayuda en Línea El sistema contara con ayuda en línea en la forma de una copia digital del manual de usuario, hecha en formato HTML 2.0. Adicionalmente, el sistema debe permitir el acceso a la ayuda según el contexto y contar con un conjunto de tooltips de brinden ayuda al usuario en ciertas posiciones en donde se coloque el cursor del ratón de la maquina. La ayuda en línea, al igual que el sistema, debe estar disponible para el usuario en todo momento Guías de Instalación, Configuración y archivos Read Me El sistema contara con dos guías y un archivo Read Me para la modalidad de instalación en sitio. El primer documento será un manual de instalación y configuración del sistema, el cual tenga las explicaciones necesarias para la instalación, configuración y despliegue de la aplicación en el servidor del cliente. El segundo documento será un manual de configuración del sistema orientado para el usuario Confidencial SILOCOM, C.A., 2010 Pág. 26 de 27

80 M2M Engine 2.0 Versión: 1.02 Visión del Fecha: 11/08/10 SILOCOM_M2ME_Vision administrador. Los contenidos de este documento desarrollaran los siguientes temas: como configurar los dispositivos de comunicación, como configurar los dispositivos de campo, cuales son las operaciones relacionadas con la gestión de usuarios, configuración de eventos y alarmas, entre otros. Por último, el archivo Read Me indicara el número de versión de la aplicación, sus novedades y mejoras con respecto a la versión anterior e información de contacto de SILOCOM, C.A Etiquetas y Paquetes La modalidad del sistema de instalación en sitio contara con una presentación empaquetada cuyos contenidos son: un (1) CD con la aplicación en un estuche con la caratula de la aplicación y su número de serie, un (1) contrato de licencia y tres (3) manuales (Manual de Usuario, Manual de Instalación y Configuración del y Manual de Configuración del Administrador). El arte grafico del empaque no se encuentra disponible para el momento de redacción del documento. Por otra parte, la interfaz grafica debe contar con el logotipo de SILOCOM, C.A. y el logotipo de la empresa cliente (siempre y cuando sea requerido por la empresa cliente). Del mismo modo, se puede realizar una mayor personalización de la interfaz grafica a petición del cliente. Confidencial SILOCOM, C.A., 2010 Pág. 27 de 27

81 Apéndice B

82 SILOCOM, C.A. Especificaciones de Requerimientos del Software Para M2M Engine 2.0 (Administrador) Versión 1.02

83 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS Historia de Revisiones Fecha Versión Descripción Autor Redacción inicial del documento. 16/08/ Elaborados los capítulos 1, 2 y 4. 18/08/ Elaborado el capítulo 3. Efraín Cardona Juan Carlos Abreu Henry Varona Efraín Cardona Juan Carlos Abreu 23/08/ Insertado diagramas de casos de uso. Juan Carlos Abreu Confidencial SILOCOM, C.A., 2010 Pág. 2 de 42

84 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS Tabla de Contenido 1. Introducción Alcance Definiciones, Acrónimos y Abreviaturas Referencias Descripción General 5 2. Especificaciones Funcionales 6 3. Casos de Uso Resumen de Casos de Uso y es Especificaciones de Casos de Uso Diagrama de Casos de uso Especificaciones Suplementarias (Requerimientos no funcionales) Usabilidad Tiempo de Adiestramiento de los usuarios Tiempos para tareas típicas Confiabilidad Disponibilidad Tiempo de Recuperación Desempeño Tiempos de respuesta para transacciones Capacidad Inicial Mantenibilidad de Control de Versiones (CVS) Diseño Modular Estandarización de variables Servidor de Respaldo Estándares de Programación de Java EE Utilización de bibliotecas de soporte de Java EE Seguridad Redes Virtuales Privadas (VPN) Protocolo HTTPS y Conexiones TCP Conexión con la base de datos restringida al modulocore Restricciones de Diseño Lenguaje de Programación Software de Desarrollo Software de Servidor de Aplicaciones de Gestión de Bases de Datos Relacional Navegadores Web Formato XML para la comunicación Requerimientos de Documentación en Línea y de s de Ayuda Componentes Comprados Interfaces Interfaz de Usuario Requerimientos de Licenciamiento Aspectos Legales, Derecho de Autor y otros Avisos Estándares Aplicables 41 Confidencial SILOCOM, C.A., 2010 Pág. 3 de 42

85 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS Especificaciones de Requerimientos del Software 1. Introducción Este documento tiene como propósito describir el funcionamiento del sistema de gestión del sistema de control y monitoreo de dispositivos de campo inalámbricos a través de la especificación de los requerimientos de funcionalidad, usabilidad, confiabilidad, desempeño y soporte que fueron elicitados, con la intención de dar una especificación sencilla de su comportamiento. 1.1 Alcance El alcance de esta especificación comprende la definición de los requerimientos que debe satisfacer el módulo de gestión del sistema de control y monitoreo de dispositivos de campo inalámbricos. Las funcionalidades principales del sistema incluyen el manejo y control de sesiones de usuarios, control de los planes disponibles a los clientes con sus respectivas tarifas, supervisión del consumo de recursos y facturación, manejo de bitácoras de todas las actividades de los usuarios y la permisología y perfiles de los mismos. Este documento está muy relacionado con el planteamiento de los casos de uso y es importante no sólo durante la fase de inicio, sino durante todo el desarrollo, pues permite mantenerse claro en los objetivos del sistema. Cabe destacar que la información contenida en este documento esta relacionadas a las actividades de pasantía del bachiller Juan Carlos Abreu 1.2 Definiciones, Acrónimos y Abreviaturas presente: A continuación se reseñan las definiciones, siglas y abreviacionesmencionadas en el documento CVS: ConcurrentVersionSystem ( de Versiones Concurrentes). de arquitectura cliente-servidor para el control de versiones, el cual mantiene un registro sobre el trabajo y los cambios realizados sobre un conjunto de archivos pertenecientes a un proyecto. MTBF: Mean Time Between Failures. Referente al promedio de tiempo entre fallas ocurridas en un sistema. Confidencial SILOCOM, C.A., 2010 Pág. 4 de 42

86 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS SAAS:Software As A Service(Software como un Servicio). Referente al modelo de distribución de software en línea (a través de Internet o una red privada) en donde la compañía que vende el software provee el servicio de mantenimiento, operación diaria, y soporte del software usado por el cliente. Para mayor información sobre todas las definiciones, siglas y abreviaciones asociadas a este proyecto, por favor consulte el documento de Glosario del sistema M2M Engine Referencias - Visión Del M2M Engine 2.0. Versión: Código del documento: SILOCOM_M2ME_Vision. Fecha: 11/08/10. Ubicación electrónica: \\ \Company SharedFolders\Desarrollo \Documentacion M2M\Documentos M2M Engine\ - Glosario M2M Engine 2.0. Versión: Código del documento: SILOCOM_M2ME_Glosario. Fecha: 17/08/10. Ubicación electrónica: \\ \Company SharedFolders\Desarrollo \Documentacion M2M\Documentos M2M Engine\ 1.4 Descripción General El documento se encuentra formado por un total de cuatro (4) capítulos, en donde se discuten los detalles sobre las especificaciones funcionales, los casos de uso (incluyendo sus especificaciones y sus diagramas) y las especificaciones suplementarias (ej. usabilidad, seguridad, desempeño, restricciones de diseño, aspectos legales, etc.) asociadas al proyecto M2M Engine 2.0, mencionadas previamente en el documento de Visión del sistema (código del documento: M2ME_Vision). Confidencial SILOCOM, C.A., 2010 Pág. 5 de 42

87 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS 2. Especificaciones Funcionales Nota: si desea saber más sobre las características asociadas a los requerimientos, consulte el capítulo cinco (5) del documento de Visión del sistema M2M Engine 2.0 (código de documento: SILOCOM_M2ME_Vision). Nombre del Requerimiento: ID requerimiento: M2ME_Admin_1 Gestión de clientes. Descripción del Requerimiento: El sistema debe permitir gestionar a los clientes. Específicamente se debe permitir agregar, modificar, eliminar clientes, suspenderle los servicios y realizar cambios de planes. Atributo: Prioridad ( ) Alta (X) Media-Alta ( ) Media ( ) Media-Baja ( ) Baja Característica Asociada: (M2M_CT_3) Realizar gestión de usuarios. Nombre del Requerimiento: Gestión de usuarios. ID requerimiento: M2ME_Admin_2 Descripción del Requerimiento: El sistema debe permitir manejar la permisología de los distintos usuarios de un cliente, mostrar la información de cuando el usuario configurador está conectado. También debe permitir desconectar usuarios a tiempo real y limitar el rango de direcciones IP por las cuales los mismos pueden conectarse. Atributo: Prioridad ( ) Alta ( ) Media-Alta ( X ) Media ( ) Media-Baja ( ) Baja Característica Asociada: (M2M_CT_3) Realizar gestión de usuarios. Confidencial SILOCOM, C.A., 2010 Pág. 6 de 42

88 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS Nombre del Requerimiento: Supervisión de consumo de clientes según su plan. Descripción del Requerimiento: ID requerimiento: M2ME_Admin_3 El sistema debe supervisar el consumo de la cuota que posee cada cliente dependiendo del plan que posea, para tomar decisiones en el caso de excesos sobre el mismo. Los recursos que el sistema debe verificar son: - Cantidad de usuarios a conectarse. - Espacio o tamaño de la base de datos. - Ancho de banda. Atributo: Prioridad () Alta ( ) Media-Alta ( X ) Media ( ) Media-Baja ( ) Baja Característica Asociada: (M2M_CT_4) Realizar gestión del sistema. Nombre del Requerimiento: Reporte de factura. ID requerimiento: M2ME_Admin_4 Descripción del Requerimiento: El sistema debe colectar y presentar toda la información con respecto al pago que realizarán los clientes por el plan escogido por los mismos, exportándolo a un formato de facturación conocido. Debe presentarse la información si hubo cargos extras por consumos mayores a los del plan suscrito. Atributo: Prioridad ( ) Alta ( ) Media-Alta ( ) Media ( ) Media-Baja ( X ) Baja Característica Asociada: (M2M_CT_6) Generar reportes de datos. Confidencial SILOCOM, C.A., 2010 Pág. 7 de 42

89 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS Nombre del Requerimiento: Reporte de actividades de usuario. ID requerimiento: M2ME_Admin_5 Descripción del Requerimiento: El sistema debe creas logs con la información de cual usuario está conectado y cuál es su ubicación. Se diferenciaran dos tipos de logs: el estático que es una bitácora detallada de todas las lecturas y comandos realizados por el usuario y el log a tiempo real, que informará cuales usuarios están conectados y desde donde, al momento de realizarse la consulta. Atributo: Prioridad ( ) Alta ( ) Media-Alta ( X ) Media ( ) Media-Baja ( ) Baja Característica Asociada: (M2M_CT_6) Generar reportes de datos. Nombre del Requerimiento: ID requerimiento: M2ME_Admin_6 Reporte de actividades de remota. Descripción del Requerimiento: El sistema debe reportar el porcentaje de efectividad de las remotas en un intervalo de tiempo considerado. Atributo: Prioridad ( ) Alta () Media-Alta ( X ) Media ( ) Media-Baja ( ) Baja Característica Asociada: (M2M_CT_6) Generar reportes de datos. Confidencial SILOCOM, C.A., 2010 Pág. 8 de 42

90 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS ID requerimiento: M2ME_Admin_7 Nombre del Requerimiento: Reportes de disponibilidad y diagnóstico de módulos. Descripción del Requerimiento: El sistema debe presentar información sobre los módulos que están en funcionamiento, es decir, cuales están corriendo También deberá presentarse un historial del estado de los módulos desde el inicio del sistema Atributo: Prioridad ( ) Alta ( X ) Media-Alta ( ) Media ( ) Media-Baja ( ) Baja Característica Asociada: (M2M_CT_6) Generar reportes de datos. Nombre del Requerimiento: Reportes de rendimiento. ID requerimiento: M2ME_Admin_8 Descripción del Requerimiento: El sistema debe presentar un reporte sobre el rendimiento del sistema, con respecto a memoria RAM, base de datos y ancho de banda, midiendo número de transacciones, total de usuarios conectados, total de clientes y total de dispositivos de campo. Esta información se debe presentar por cliente, por grupo de clientes y por el sistema en total. Atributo: Prioridad ( ) Alta ( X ) Media-Alta ( ) Media ( ) Media-Baja ( ) Baja Característica Asociada: (M2M_CT_6) Generar reportes de datos. Confidencial SILOCOM, C.A., 2010 Pág. 9 de 42

91 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS Nombre del Requerimiento: Gestión de lecturas programadas. ID requerimiento: M2ME_Admin_9 Descripción del Requerimiento: El sistema debe poder manejar las diferentes lecturas programadas por cliente, en particular de deben poder iniciar, detener, agregar y eliminar lecturas sobre los diferentes dispositivos remotos. Es necesario que el sistema calcule el ancho de banda consumida por cada una de las lecturas realizadas. Atributo: Prioridad ( ) Alta ( X ) Media-Alta ( ) Media ( ) Media-Baja ( ) Baja Característica Asociada: (M2M_CT_4) Realizar gestión del sistema. Nombre del Requerimiento: ID requerimiento: M2ME_Admin_10 Gestión de módulos. Descripción del Requerimiento: Debido a que todo el sistema está implementado de forma modular, el módulo de gestión debe permitir iniciar, detener y reiniciar las distintas funcionalidades del sistema. Atributo: Prioridad ( ) Alta ( ) Media-Alta ( X ) Media ( ) Media-Baja ( X ) Baja Característica Asociada: (M2M_CT_4) Realizar gestión del sistema. Confidencial SILOCOM, C.A., 2010 Pág. 10 de 42

92 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS Nombre del Requerimiento: ID requerimiento: M2ME_Admin_11 Gestión de dispositivos de comunicación. Descripción del Requerimiento: El módulo de gestión debe permitir asignar y remover dispositivos de comunicación a los clientes. Atributo: Prioridad ( ) Alta ( ) Media-Alta ( X ) Media ( ) Media-Baja ( ) Baja Característica Asociada: (M2M_CT_4) Realizar gestión del sistema. Nombre del Requerimiento: ID requerimiento: M2ME_Admin_12 Supervisión sobre la capa física. Descripción del Requerimiento: El sistema debe permitir deshabilitar, habilitar y reiniciar sockets utilizados para las conexiones. Atributo: Prioridad ( X ) Alta ( ) Media-Alta ( ) Media ( ) Media-Baja ( ) Baja Característica Asociada: (M2M_CT_4) Realizar gestión del sistema. Confidencial SILOCOM, C.A., 2010 Pág. 11 de 42

93 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS 3. Casos de Uso 3.1 Resumen de Casos de Uso y es ID Caso de Uso Caso de Uso CU_ADMIN_01 Agregar cliente Superusuario. CU_ADMIN_02 Eliminar cliente Superusuario. CU_ADMIN_03 Modificar cliente Superusuario. CU_ADMIN_04 Habilitar servicios a un cliente Superusuario. CU_ADMIN_05 Deshabilitar servicios a un cliente Superusuario. CU_ADMIN_06 Agregar usuario Administrador, superusuario. CU_ADMIN_07 Eliminar usuario Administrador, superusuario. CU_ADMIN_08 Modificar usuario Administrador, superusuario. CU_ADMIN_9 Listar usuarios Administrador, superusuario. CU_ADMIN_10 Desconectar usuario Superusuario. CU_ADMIN_11 Agregar rol Administrador, superusuario. CU_ADMIN_12 Modificar rol Administrador, superusuario. CU_ADMIN_13 Eliminar rol Administrador, superusuario. CU_ADMIN_14 Listar roles Administrador, superusuario. CU_ADMIN_15 Limitar direcciones IP de un usuario Superusuario. Confidencial SILOCOM, C.A., 2010 Pág. 12 de 42

94 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS (Continuación) ID Caso de Uso Caso de Uso CU_ADMIN_16 Mostrar usuarios conectados Superusuario. CU_ADMIN_17 Mostrar espacio libre en la base de datos Administrador, superusuario. CU_ADMIN_18 Mostrar historial de conexiones del usuario configurador Administrador, superusuario. CU_ADMIN_19 Mostrar consumo en ancho de banda Administrador, superusuario. CU_ADMIN_20 Generar factura. Superusuario. CU_ADMIN_21 Iniciar registro de eventos estáticos Superusuario. CU_ADMIN_22 Detener registro de eventos estáticos Superusuario. CU_ADMIN_23 Generar reporte de diagnóstico de remotas Superusuario. CU_ADMIN_24 Generar reporte de disponibilidad y diagnóstico de módulos Superusuario. CU_ADMIN_25 Generar reporte de rendimiento Superusuario. CU_ADMIN_26 Agregar lectura programada Administrador, superusuario. CU_ADMIN_27 Eliminar lectura programada Administrador, superusuario. Confidencial SILOCOM, C.A., 2010 Pág. 13 de 42

95 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS (Continuación) ID Caso de Uso Caso de Uso CU_ADMIN_28 Iniciar lectura programada Administrador, superusuario. CU_ADMIN_29 Detener lectura programada Administrador, superusuario. CU_ADMIN_30 Iniciar un módulo Superusuario. CU_ADMIN_31 Detener módulo Superusuario. CU_ADMIN_32 Reiniciar módulo Superusuario. CU_ADMIN_33 Agregar dispositivo de comunicación Administrador, superusuario, configurador. CU_ADMIN_34 Eliminar dispositivo de comunicación Administrador, superusuario, configurador. CU_ADMIN_35 Habilitar dispositivo de comunicación Administrador, superusuario, configurador. CU_ADMIN_36 Deshabilitar dispositivo de comunicación Administrador, superusuario, configurador. CU_ADMIN_37 Habilitar socket Superusuario. CU_ADMIN_38 Deshabilitar socket Superusuario. CU_ADMIN_39 Reiniciar socket Superusuario. Confidencial SILOCOM, C.A., 2010 Pág. 14 de 42

96 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS 3.2 Especificaciones de Casos de Uso ID: CU_ADMIN_01 Caso de uso: Agregar cliente Descripción:Permite agregar un cliente a la base de datos. Requerimiento: (M2ME_Admin_1) Gestión de clientes. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Agregar cliente. 3- Llena la información necesaria y presiona el botón agregar cliente. 2- Muestra un formulario con toda la información que es necesaria para agregar un cliente. 4- Valida la información y se muestra un mensaje con el resultado de la operación. FlujoAlterno I 4.1- Si algún campo del formulario es inválido, se pide al usuario que corrija el mismo. Poscondición: El cliente queda agregado en la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_02 Caso de uso: Eliminar cliente Descripción:Permite eliminar un cliente de la base de datos. Requerimiento: (M2ME_Admin_1) Gestión de clientes. Precondición: El actor debe estar autenticado en el sistema. El cliente a eliminar debe estar registrado en el sistema. Flujo Básico 1- Selecciona la opción Eliminar cliente. 3- Selecciona el cliente que se desea eliminar y presiona el botón eliminar cliente. 5- Confirma la operación. --- FlujoAlterno I 2- Muestra una lista ordenada de los clientes registrados en el sistema. 4- Pide confirmación de la operación de eliminación. 6- Muestra un mensaje con el resultado de la operación. Confidencial SILOCOM, C.A., 2010 Pág. 15 de 42

97 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS Poscondición: El cliente queda eliminado de la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_03 Caso de uso: Modificar cliente Descripción:Permite modificar los datos un cliente en la base de datos. Requerimiento: (M2ME_Admin_1) Gestión de clientes. Precondición: El actor debe estar autenticado en el sistema. El cliente a modificar debe estar registrado en el sistema. Flujo Básico 1- Selecciona la opción Modificar cliente. 3- Modifica los campos deseados y selecciona el botón Guardar información. 5- Confirma la operación Muestra todos los atributos de un cliente, permitiendo modificar los mismos. 4- Pide confirmación de la operación de modificación. 6- Muestra un mensaje con el resultado de la operación. FlujoAlterno I 6.1- Si algún campo del formulario es inválido, se pide al usuario que corrija el mismo. Poscondición: El cliente queda modificado de la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_04 Caso de uso: Habilitar servicios cliente Descripción:Permite habilitar los servicios que un cliente adquirió a través de un plan. Requerimiento: (M2ME_Admin_1) Gestión de clientes. Precondición: El actor debe estar autenticado en el sistema. El cliente al que se le van a habilitar los servicios, debe estar registrado en el sistema. Flujo Básico 1- Selecciona la opción Habilitar servicios El sistema muestra una lista ordenada de los usuarios a los cuales se les puede habilitar los servicios. Confidencial SILOCOM, C.A., 2010 Pág. 16 de 42

98 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS 3- Selecciona el cliente al cual se desea habilitar los servicios. 5- Confirma la operación. 4- Pide confirmación a la operación. 6- Muestra un mensaje con el resultado de la operación. FlujoAlterno I Poscondición: Al cliente le quedan activos los servicios adquiridos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_05 Caso de uso: Deshabilitar servicios cliente Descripción:Permite deshabilitar los servicios que un cliente. Requerimiento: (M2ME_Admin_1) Gestión de clientes. Precondición: El actor debe estar autenticado en el sistema. Los servicios han debido ser habilitados previo a la deshabilitación. Flujo Básico 1- Selecciona la opción Detener servicios 3- Selecciona el cliente al cual desea deshabilitarte los servicios. 5- Confirma la operación de deshabilitación. --- FlujoAlterno I Poscondición: Al cliente le quedan desactivados los servicios. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra una lista de todos los clientes registrados en el sistema, los cuales tienen los servicios habilitados. 4- Pide confirmar la operación. 6- Muestra un mensaje con el resultado de la operación. ID: CU_ADMIN_06 Caso de uso: Agregar usuario Descripción:Permite agregar un usuario a la base de datos. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. Confidencial SILOCOM, C.A., 2010 Pág. 17 de 42

99 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS 1- Selecciona la opción Agregar usuario. 3- Llena la información necesaria y presiona el botón agregar usuario. Flujo Básico 2- Muestra un formulario con toda la información que es necesaria para agregar un usuario (incluyendo al cliente al cual se va a asociar). 4- Valida la información y muestra un mensaje con el resultado de la operación al usuario. FlujoAlterno I 4.1- Si algún campo del formulario es inválido, se pide al usuario que corrija el mismo. Poscondición: El usuario queda agregado a la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_07 Caso de uso: Eliminar usuario Descripción:Permite eliminar un usuario de la base de datos. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. El usuario a eliminar debe estar registrado en el sistema. Flujo Básico 1- Selecciona la opción Eliminar usuario. 3- Selecciona el cliente al cual está asociado el usuario a eliminar. 5- Selecciona el usuario que desea eliminar. 7- Confirma la operación. --- FlujoAlterno I 2- Muestra una lista ordenada de los clientes registrados en el sistema. 4- Muestra una lista de los usuarios registrados. 6- Pide confirmación de la operación de eliminación. 8- Muestra un mensaje con el resultado de la operación. Poscondición: El usuario queda eliminado de la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. Confidencial SILOCOM, C.A., 2010 Pág. 18 de 42

100 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS ID: CU_ADMIN_08 Caso de uso: Modificar usuario Descripción:Permite modificar los datos un usuario en la base de datos. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. El usuario a editar debe estar registrado en el sistema. Flujo Básico 1- Selecciona la opción Modificar usuario. 3- Modifica los campos deseados y selecciona el botón Guardar información. 5- Confirma la operación. 2- Muestra todos los atributos de un usuario, permitiendo modificar los mismos. 4- Pide confirmación de la operación de modificación. 6- Valida la información y muestra un mensaje con el resultado de la operación. FlujoAlterno I 6.1- Si algún campo del formulario es inválido, se pide al usuario que corrija el mismo. Poscondición: El usuario queda modificado en la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_09 Caso de uso:listar usuarios Descripción:Permite mostrar los usuariosen la base de datos. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Listar usuario. --- FlujoAlterno I 2- Muestra una lista ordenada con los usuarios registrados en el sistema. Poscondición: Queda impreso en pantalla una lista con los usuarios registrados. Requerimientos especiales: N/A. Puntos de extensión:n/a. Confidencial SILOCOM, C.A., 2010 Pág. 19 de 42

101 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS ID: CU_ADMIN_10 Caso de uso:desconectar usuario Descripción:Permite desconectar un usuario del sistema. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Desconectar usuario. 3- Selecciona el cliente al cual está asociado el usuario a desconectar. 5- Selecciona el usuario se desea desconectar. 7- Confirma la operación. FlujoAlterno I Poscondición: El usuario queda desconectado del sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra una lista ordenada de los clientes registrados en el sistema. 4- Muestra una lista de los usuarios asociados al cliente seleccionado, que están conectados. 6- Pide confirmación de la operación de desconexión. 8- Muestra un mensaje con el resultado de la operación. ID: CU_ADMIN_11 Caso de uso:agregar rol Descripción:Permite desconectar un usuario del sistema. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Agregar rol. 3- Llena la información necesaria y presiona el botón agregar rol. 2- Muestra un formulario con toda la información que es necesaria para agregar un rol. 4- Valida la información y muestra un mensaje con el resultado de la operación al usuario. FlujoAlterno I 4.1- Si algún campo del formulario es inválido, se Confidencial SILOCOM, C.A., 2010 Pág. 20 de 42

102 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS pide al usuario que corrija el mismo. Poscondición: El rol queda agregado a la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_12 Caso de uso:modificar rol Descripción:Permite modificar un rol registrado en el sistema. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Agregar rol. 3- Llena la información necesaria y presiona el botón agregar rol Muestra un formulario con toda la información que es necesaria para agregar un rol. 4- Valida la información y muestra un mensaje con el resultado de la operación al usuario. FlujoAlterno I 4.1- Si algún campo del formulario es inválido, se pide al usuario que corrija el mismo. Poscondición: El rol queda modificado en la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_13 Caso de uso:eliminar rol Descripción:Permite modificar un rol eliminado del sistema. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. El rol a eliminar debe estar registrado en el sistema. Flujo Básico 1- Selecciona la opción Eliminar rol. 5- Selecciona el rol que desea eliminar. 7- Confirma la operación Muestra una lista ordenada de los roles registrados en el sistema. 6- Pide confirmación de la operación de eliminación. 8- Muestra un mensaje con el resultado de la Confidencial SILOCOM, C.A., 2010 Pág. 21 de 42

103 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS operación. FlujoAlterno I Poscondición: El rol queda eliminado de la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_14 Caso de uso:listar roles Descripción:Permite listar los roles registrado en el sistema. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Listar roles. --- FlujoAlterno I Poscondición: El rol queda eliminado de la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra una lista ordenada de los roles registrados en el sistema. ID: CU_ADMIN_15 Caso de uso:limitar direcciones IP de un usuario Descripción:Permite crear una lista de direcciones IP de las cuales los usuarios no van a poder conectarse. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Bloquear dirección IP. 3- Ingresa toda la información necesaria solicitada por el sistema y selecciona el botón agregar. FlujoAlterno I 2- Muestra un formulario, con toda la información necesaria para agregar un IP a la lista de direcciones bloqueadas. 4- Muestra un mensaje con la operación Poscondición: La dirección IP queda agregada en la lista de direcciones bloqueadas. Confidencial SILOCOM, C.A., 2010 Pág. 22 de 42

104 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_16 Caso de uso:mostrar usuarios conectados Descripción:Muestra una lista ordenada de los usuarios conectados en el sistema. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Mostrar usuarios conectados. --- FlujoAlterno I 2- Muestra una lista ordenada por clientes, de todos los usuarios conectados al sistema. Poscondición: Queda impreso en pantalla todos los usuarios conectados en el sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a. --- ID: CU_ADMIN_17 Caso de uso: Mostrar espacio libre en la base de datos Descripción:Muestra un informe sobre el espacio disponible en la base de datos. Requerimiento: (M2ME_Admin_3) Supervisión de consumo de clientes según plan. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Mostrar espacio libre en la base de datos. FlujoAlterno I 2- Muestra la información sobre el espacio disponible en la base de datos. Poscondición: Queda impreso en pantalla la información sobre el uso de la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. --- ID: CU_ADMIN_18 Caso de uso: Mostrar historial de conexiones del usuario configurador. Descripción:Muestra una lista de conexiones del usuario configurador. Confidencial SILOCOM, C.A., 2010 Pág. 23 de 42

105 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS Requerimiento: (M2ME_Admin_3) Supervisión de consumo de clientes según plan. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Mostrar espacio libre en la base de datos. FlujoAlterno I 2- Muestra la información sobre el espacio disponible en la base de datos. Poscondición: Queda impreso en pantalla la información sobre las conexiones del usuario configurador. Requerimientos especiales: N/A. Puntos de extensión:n/a. --- ID: CU_ADMIN_19 Caso de uso: Mostrar consumo en ancho de banda Descripción:Muestra un informe con el consumo de ancho de banda hasta la fecha de la consulta. Requerimiento: (M2ME_Admin_3) Supervisión de consumo de clientes según plan. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Mostrar consumo de ancho de banda. FlujoAlterno I 2- Muestra la información del consumo de ancho de banda, realizado hasta la fecha. Poscondición: Queda impreso en pantalla la información sobre el consumo en ancho de banda hasta la fecha de la consulta. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_20 Caso de uso: Generar factura Descripción:Permite generar una factura que resume todos los consumos de un cliente. Requerimiento: (M2ME_Admin_4) Reporte de factura. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Generar factura. --- Confidencial SILOCOM, C.A., 2010 Pág. 24 de 42

106 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS 3- Selecciona las opciones deseadas y luego Generar factura 2- Muestra un formulario con las diferentes opciones de formato a exportar (xls, pdf, web). 4- Muestra un mensaje con el resultado de la operación. FlujoAlterno I Poscondición: Queda generado una factura con todos los consumos del cliente seleccionado. Requerimientos especiales: N/A. Puntos de extensión:n/a. --- ID: CU_ADMIN_21 Caso de uso: Iniciar registro de eventos estáticos. Descripción:Crea un archivo en el que se registrarán las actividades de los usuarios conectados Requerimiento: (M2ME_Admin_5) Reporte de actividades de usuario. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Iniciar log. FlujoAlterno I Poscondición:Queda iniciado el registro de eventos estáticos. Requerimientos especiales: N/A. Puntos de extensión:n/a Crea un archivo e inicia el registro de las actividades de los usuarios que están conectados. ID: CU_ADMIN_22 Caso de uso: Detener registro de eventos estáticos. Descripción:Detiene el registro las actividades de los usuarios conectados Requerimiento: (M2ME_Admin_5) Reporte de actividades de usuario. Precondición: El actor debe estar autenticado en el sistema. Debió haber sido iniciado el registro de eventos estáticos. Flujo Básico 1- Selecciona la opción Detener log. FlujoAlterno I 2- Detiene el registro de las actividades de los usuarios que están conectados. Confidencial SILOCOM, C.A., 2010 Pág. 25 de 42

107 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS Poscondición:Queda detenido el registro de eventos estáticos. Requerimientos especiales: N/A. Puntos de extensión:n/a. --- ID: CU_ADMIN_23 Caso de uso: Generar reporte de diagnóstico de remotas. Descripción:Detiene el registro las actividades de los usuarios conectados Requerimiento: (M2ME_Admin_6) Reporte de actividades de remotas. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Generar reporte de remotas. FlujoAlterno I Poscondición:Queda impreso en pantalla el reporte de las remotas. Requerimientos especiales: N/A. Puntos de extensión:n/a Genera un reporte con la información de diagnóstico de las remotas. ID: CU_ADMIN_24 Caso de uso: Generar reporte de disponibilidad y diagnóstico de módulos. Descripción:El sistema genera un reporte con la información de los módulos del mismo Requerimiento: (M2ME_Admin_7) Reporte de disponibilidad y diagnóstico de módulos Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Generar reporte de módulos. FlujoAlterno I Poscondición:Queda impreso en pantalla el reporte de las módulos. Requerimientos especiales: N/A. Puntos de extensión:n/a. 2- Genera un reporte con la información de diagnóstico y disponibilidad de los módulos del sistema. Confidencial SILOCOM, C.A., 2010 Pág. 26 de 42

108 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS ID: CU_ADMIN_25 Caso de uso: Generar reporte de rendimiento Descripción:El sistema genera un reporte con la información del rendimiento del mismo. Requerimiento: (M2ME_Admin_8) Reporte de rendimiento Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Generar reporte de rendimiento. FlujoAlterno I Poscondición:Queda impreso en pantalla el reporte de rendimiento. Requerimientos especiales: N/A. Puntos de extensión:n/a Genera un reporte con la información del rendimiento del sistema, entre consumo de memoria ram, uso del CPU y consumo de la base de datos. ID: CU_ADMIN_26 Caso de uso: Agregar lectura programada. Descripción:El sistema agrega una lectura programada para una remota Requerimiento: (M2ME_Admin_9) Gestión de lecturas programadas Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Agregar lecturas programadas. 3- Ingresa la información requerida y selecciona la opción agregar 2- Muestra un formulario con toda la información asociada a una lectura programada. 4- Muestra un mensaje con el resultado de la operación. FlujoAlterno I 4.1 Si algún campo es invalido, se le pide al usuario que sea corregido. Poscondición:Queda registrada la lecturaprogramada en el sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a. Confidencial SILOCOM, C.A., 2010 Pág. 27 de 42

109 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS ID: CU_ADMIN_27 Caso de uso: Eliminar lectura programada. Descripción:El sistema elimina una lectura programada. Requerimiento: (M2ME_Admin_9) Gestión de lecturas programadas Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Eliminar lectura programada. 3- Selecciona la lectura programada que se desea 5- Confirma la operación de eliminación. FlujoAlterno I 2- Muestra una lista de las lecturas agregadas al sistema. 4- Pide confirmar la operación. Poscondición:Queda eliminada la lectura programada en el sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra un mensaje con el resultado de la operación. ID: CU_ADMIN_28 Caso de uso: Iniciar lectura programada. Descripción:El sistema inicia una lectura programada. Requerimiento: (M2ME_Admin_9) Gestión de lecturas programadas Precondición: El actor debe estar autenticado en el sistema. La lectura programada a iniciar, debe estar registrada en el sistema. Flujo Básico 1- Selecciona la opción Iniciar lectura programada. 3- Selecciona la lectura programada que se desea iniciar. 5- Confirma la operación de iniciación. FlujoAlterno I 2- Muestra una lista de las lecturas agregadas al sistema y disponibles para ese usuario. 4- Pide confirmación de la operación 6- Muestra un mensaje con el resultado de la operación. Confidencial SILOCOM, C.A., 2010 Pág. 28 de 42

110 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS Poscondición:Queda iniciada la lectura programada en el sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_29 Caso de uso: Detener lectura programada. Descripción:El sistema detiene una lectura programada. Requerimiento: (M2ME_Admin_9) Gestión de lecturas programadas Precondición: El actor debe estar autenticado en el sistema. La lectura programada a detener, debe haber sido inicia anteriormente. Flujo Básico 1- Selecciona la opción Finalizar lectura programada. 3- Selecciona la lectura programada que se desea finalizar. 5- Confirma la operación. --- FlujoAlterno I Poscondición:Queda detenida la lectura programada en el sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra una lista de las lecturas programadas iniciadas por el usuario. 4- Pide confirmación de la operación de finalización. 6- Muestra un mensaje con el resultado de la operación. ID: CU_ADMIN_30 Caso de uso: Iniciar un módulo. Descripción:El sistema iniciaun módulo del M2M. Requerimiento: (M2ME_Admin_10) Gestión de módulos Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Iniciar módulo. 3- Selecciona el módulo del sistema que desea ser iniciado. 2- Muestra una lista de los módulos que pueden ser iniciados. 4- Muestra un mensaje con el resultado de la Confidencial SILOCOM, C.A., 2010 Pág. 29 de 42

111 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS operación. FlujoAlterno I Poscondición:Queda iniciado el módulo seleccionado. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_31 Caso de uso: Detener un módulo. Descripción:El sistema detieneun módulo del M2M. Requerimiento: (M2ME_Admin_10) Gestión de módulos Precondición: El actor debe estar autenticado en el sistema. El módulo a detener, debió haber sido iniciado previamente. Flujo Básico 1- Selecciona la opción Detener módulo. 3- Selecciona el módulo del sistema que desea ser detenido. 5- Confirma la operación. --- FlujoAlterno I Poscondición:Queda detenido el módulo seleccionado. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra una lista de los módulos que están activos y pueden ser detenidos. 4- Pide confirmación de la operación. 6- Muestra un mensaje con el resultado de la operación. ID: CU_ADMIN_32 Caso de uso: Reiniciar un módulo. Descripción:El sistema reiniciaun módulo del M2M. Requerimiento: (M2ME_Admin_10) Gestión de módulos Precondición: El actor debe estar autenticado en el sistema. El módulo a reiniciar, debió haber sido iniciado previamente. Flujo Básico 1- Selecciona la opción Reiniciar módulo. 2- Muestra una lista de los módulos que están activos y pueden ser reiniciados. Confidencial SILOCOM, C.A., 2010 Pág. 30 de 42

112 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS 3- Selecciona el módulo del sistema que desea ser reiniciado. 5- Confirma la operación. 4- Pide confirmación de la operación. 6- Muestra un mensaje con el resultado de la operación. FlujoAlterno I Poscondición:Queda reiniciado el módulo seleccionado. Requerimientos especiales: N/A. Puntos de extensión:n/a. --- ID: CU_ADMIN_33 Caso de uso: Agregar dispositivo de comunicación Descripción:El sistema agrega un dispositivo de comunicación. Requerimiento: (M2ME_Admin_11) Gestión de dispositivos de comunicación. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Agregar dispositivo de comunicación. 3- Ingresa toda la información necesaria y selecciona la opción Agregar. 2- Muestra un formulario con toda la información asociada a un dispositivo de comunicación. 4- Valida la información y muestra un mensaje con el resultado de la operación. FlujoAlterno I 4.1- Si uno de los datos es el inválido, se le pide al usuario que lo corrija. Poscondición:Queda agregado el dispositivo de comunicación al sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a. --- ID: CU_ADMIN_34 Caso de uso: Eliminar dispositivo de comunicación Descripción:El sistema elimina un dispositivo de comunicación. Requerimiento: (M2ME_Admin_11) Gestión de dispositivos de comunicación. Precondición: El actor debe estar autenticado en el sistema. El dispositivo de comunicación a eliminar, debe estar agregado en el sistema Flujo Básico Confidencial SILOCOM, C.A., 2010 Pág. 31 de 42

113 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS 1- Selecciona la opción Eliminar dispositivo de comunicación. 3- Selecciona el dispositivo que se desea eliminar. 5- Confirma la operación. FlujoAlterno I 2- Muestra una lista de los dispositivos de comunicación agregados en el sistema. 4- Pide confirmación de la operación. Poscondición:Queda eliminado el dispositivo de comunicación al sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra un mensaje con el resultado de la operación. ID: CU_ADMIN_35 Caso de uso: Habilitar dispositivo de comunicación Descripción:El sistema habilita un dispositivo de comunicación. Requerimiento: (M2ME_Admin_11) Gestión de dispositivos de comunicación. Precondición: El actor debe estar autenticado en el sistema. El dispositivo de comunicación a habilitar, debe estar agregado en el sistema Flujo Básico 1- Selecciona la opción Habilitar dispositivo de comunicación. 3- Selecciona el dispositivo que se desea habilitar. FlujoAlterno I Poscondición:Queda habilitado el dispositivo de comunicación al sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a. 2- Muestra una lista de los dispositivos de comunicación agregados en el sistema. 4- Muestra un mensaje con el resultado de la operación. Confidencial SILOCOM, C.A., 2010 Pág. 32 de 42

114 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS ID: CU_ADMIN_36 Caso de uso: deshabilitar dispositivo de comunicación Descripción:El sistema deshabilita un dispositivo de comunicación. Requerimiento: (M2ME_Admin_11) Gestión de dispositivos de comunicación. Precondición: El actor debe estar autenticado en el sistema. El dispositivo de comunicación a deshabilitar, debe haber sido habilitado anteriormente Flujo Básico 1- Selecciona la opción Deshabilitar dispositivo de comunicación. 3- Selecciona el dispositivo que se desea deshabilitar. 5- Confirma la operación. FlujoAlterno I 2- Muestra una lista de los dispositivos de comunicación habilitados en el sistema. 4- Pide confirmación de la operación. Poscondición:Queda deshabilitado el dispositivo de comunicación al sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra un mensaje con el resultado de la operación. ID: CU_ADMIN_37 Caso de uso: Habilitar socket Descripción:El sistema habilita un socket. Requerimiento: (M2ME_Admin_12) Supervisión de la capa física. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Habilitar socket 3- Selecciona el socket que desea habilitarse. FlujoAlterno I Poscondición:Queda habilitado el socket, en la capa física. Requerimientos especiales: N/A. Puntos de extensión:n/a. 2- Muestra una lista de los sockets creados. 4- Muestra un mensaje con el resultado de la operación. Confidencial SILOCOM, C.A., 2010 Pág. 33 de 42

115 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS ID: CU_ADMIN_38 Caso de uso: Deshabilitar socket Descripción:El sistema deshabilita un socket. Requerimiento: (M2ME_Admin_12) Supervisión de la capa física. Precondición: El actor debe estar autenticado en el sistema. El socket a deshabilitar, debió haber sido activado previamente. Flujo Básico 1- Selecciona la opción Habilitar socket 3- Selecciona el socket que desea habilitarse. FlujoAlterno I Poscondición:Queda deshabilitado el socket, en la capa física. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra una lista de los sockets creados. 4- Muestra un mensaje con el resultado de la operación. ID: CU_ADMIN_39 Caso de uso: Reiniciar socket Descripción:El sistema reinicia un socket. Requerimiento: (M2ME_Admin_12) Supervisión de la capa física. Precondición: El actor debe estar autenticado en el sistema. El socket a reiniciar, debió haber sido activado previamente. Flujo Básico 1- Selecciona la opción Reiniciar socket 3- Selecciona el socket que desea reiniciarse. 5- Confirma la operación de reinicio. FlujoAlterno I Poscondición:Queda reiniciado el socket, en la capa física. Requerimientos especiales: N/A. Puntos de extensión:n/a. 2- Muestra una lista de los sockets habilitados. 4- Pide confirmar la operación. 6- Muestra un mensaje con el resultado de la operación. Confidencial SILOCOM, C.A., 2010 Pág. 34 de 42

116 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS 3.3 Diagrama de Casos de uso Confidencial SILOCOM, C.A., 2010 Pág. 35 de 42

117 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS Confidencial SILOCOM, C.A., 2010 Pág. 36 de 42

118 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS 4. Especificaciones Suplementarias (Requerimientos no funcionales) 4.1 Usabilidad Tiempo de Adiestramiento de los usuarios El sistema M2M Engine 2.0 contara con una curva de aprendizaje baja que les permitirá a los usuarios adaptarse al sistema en un tiempo mínimo. Se estima que un usuario del sistema lo pueda dominar en un periodo de 4 horas y que un administrador de sistema lo domine en el transcurso de 2 días. Esto se debe a que el sistema tendrá un aspecto y funcionalidades parecidas a los sistemas de administración existentes en las instalaciones de los clientes, lo cual le brindará un ambiente familiar y fácil de asimilar a los usuarios del sistema. Adicionalmente, el sistema contará con un segmento de documentación en línea (para las modalidades SAAS y de instalación en sitio) y manuales impresos (exclusivo para la modalidad de instalación en sitio) para orientar a los usuarios en situaciones de duda Tiempos para tareas típicas El sistema M2M Engine 2.0 se desarrollara teniendo como meta realización de las operaciones en el menor tiempo posible. Confidencial SILOCOM, C.A., 2010 Pág. 37 de 42

119 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS 4.2 Confiabilidad Disponibilidad El sistema estará diseñado para tener un porcentaje de tiempo de disponibilidad del 99,5%. Se espera que se le dé uso al sistema por un periodo de 24 horas diarias, con un tiempo de acceso para mantenimiento de 8 horas por mes Tiempo de Recuperación El diseño del sistema M2M Engine 2.0 deberá proveer un tiempo de recuperación de 45 minutos a partir del momento de que se detenga a raíz de una falla o excepción del sistema. 4.3 Desempeño Tiempos de respuesta para transacciones Se espera que el sistema cuente con tiempos de respuesta para transacciones cortas. Se estima que el tiempo de respuesta para una transacción entre el sistema y un dispositivo de comunicación o remota tenga un promedio de 15 segundos y un máximo de 45 segundos. Por otra parte, se espera que el tiempo de respuesta de transacciones asociadas a actividades del usuario (navegación entre distintas secciones del sistema, generación de reportes, etc.) tenga un promedio de dos (2) segundos, con un máximo de un (1) minuto Capacidad Inicial Se espera que el sistema tenga una capacidad inicial que pueda soportar la conexión concurrente de doscientos (200) usuarios. La capacidad de almacenamiento de datos dependerá del servidor en donde se realice la instalación del sistema, bajo su presentación de instalación en sitio. Bajo la modalidad del SAAS, todavía no se ha determinado la capacidad de almacenamiento de datos (dependerá del plan de hospedaje que se contrate con el proveedor de hospedaje y servidores dedicados). 4.4 Mantenibilidad de Control de Versiones (CVS) Las actividades de desarrollo del sistema se realizaran con el apoyo de sistemas de control de versiones tanto para la implementación como para la documentación. El CVS para el código fuente del sistema estará instalado en el servidor de pruebas ubicado en las instalaciones de SILOCOM, C.A. El CVS para la documentación del proyecto se hará uso del servicio gratuito de repositorio de datos de Assembla Diseño Modular El sistema M2M Engine 2.0 debe contar con un diseño modular con la finalidad de facilitar las labores de mantenimiento. La razón detrás de tal decisión de diseño es que con un sistema modular se pueden realizar modificaciones a un modulo del sistema sin la necesidad de detener el funcionamiento 1- Confidencial SILOCOM, C.A., 2010 Pág. 38 de 42

120 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS del resto de la aplicación Estandarización de variables Con la finalidad de mejorar la legibilidad del código fuente del sistema, se creara un formato para el nombramiento de las variables del sistema, basado en el idioma inglés. El equipo desarrollador se verá comprometido a cumplir con las pautas del formato para mantener la uniformidad de los nombres de variable a través de los distintos módulos que serán desarrollados Servidor de Respaldo Para las actividades de desarrollo y pruebas del sistema se espera contar con un servidor de aplicación de respaldo. La finalidad de tal hardware será realizar pruebas sobre balanceo de cargas del sistema y pruebas sobre el funcionamiento de un servidor de respaldo en caso que el servidor de aplicación principal sufra alguna falla. En el momento de redacción del documento no se ha llegado a una decisión sobre cual plataforma se utilizara Estándares de Programación de Java EE El sistema debe cumplir con los estándares de programación propuestos por Java EE, con la finalidad de facilitar la lectura del código por parte de los desarrolladores y garantizar la ejecución correcta de los módulos del sistema Utilización de bibliotecas de soporte de Java EE Para asegurar el buen funcionamiento del sistema, el equipo desarrollador debe hacer uso de las versiones más recientes de las bibliotecas para Hibernate, Apache Struts y comunicación mediante puerto COMM para Java. Además, el sistema hará uso de las bibliotecas de Java desarrolladas por SILOCOM, C.A. para la construcción de mensajes XML. 4.5 Seguridad Redes Virtuales Privadas (VPN) Para garantizar la seguridad de los datos intercambiados entre el sistema M2M Engine 2.0 y los dispositivos de campo se establecerán redes virtuales privadas. Las redes virtuales privadas brindan facilidades de seguridad como cifrado de paquetes de datos transmitidos y mejores servicios de validación de usuarios Protocolo HTTPS y Conexiones TCP La interfazgrafica con el usuario a través de Internet deberá hacer uso del protocolo HTTPS para el cifrado de datos compartidos entre los navegadores web y el servidor de aplicación. Adicionalmente, para evitar la pérdida de datos o el recibo de paquetes en un orden distinto al de transmisión, el sistema deberá permitir el uso de conexiones TCP con dispositivos de comunicación y ciertos usuarios Conexión con la base de datos restringida al modulocore Para garantizar la seguridad e integridad de la información almacenada en las bases de datos se debe restringir el acceso a la base de datos al modulo central, también conocido como Core, del sistema. Confidencial SILOCOM, C.A., 2010 Pág. 39 de 42

121 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS Luego, el modulo central se encargara de transmitirle los datos a las interfaces de usuario mediante un objeto tipo XML. Así se tratan de evitar accesos indebidos a las bases de datos, como es en el caso de ataques de inyección SQL. 4.6 Restricciones de Diseño Lenguaje de Programación El lenguaje de programación elegido para el desarrollo del sistema M2M Engine 2.0 es Java EE versión 6. Java EE es un lenguaje de programación que permite el desarrollo de aplicaciones empresariales distribuidas, además de contar con todas las prestaciones de la versión estándar de Java Software de Desarrollo El software de desarrollo elegido para el proyecto es NetBeans IDE 6.9 de Oracle. Este entorno de desarrollo integrado es recomendado para el desarrollo de aplicaciones en el lenguaje Java y cuenta con el apoyo de varias comunidades a nivel internacional. Es de distribución libre bajo la licencia CDDL y viene empaquetado con el lenguaje de programación Java EE 6 y el software de servidor de aplicación Glassfish versión Software de Servidor de Aplicaciones El servidor en donde se despliegue el sistema M2M Engine 2.0 deberá tener instalado el servidor de aplicaciones Glassfish versión 3. Glassfish 3 es desarrollado por Oracle e implementa las tecnologías especificadas por Java EE. El software se distribuye bajo un licenciamiento dual a través de las licencias CDDL y la GNU GPL de Gestión de Bases de Datos Relacional El sistema de gestión de bases de datos relacional a ser utilizado para el desarrollo de la aplicación debe ser MySQL (versión ). MySQL de Oracle, al igual que las herramientas mencionadas anteriormente, es desarrollado como software libre y se distribuye bajo la licencia GNU GPL en su versión gratuita. Adicionalmente, es uno de los sistemas de gestión de bases de datos de mayor uso a nivel mundial y actualmente es el gestor de bases de datos del sistema M2M Engine Navegadores Web El sistema se diseñara para poder ser visualizado mediante la mayoría de los navegadores web disponibles en el mercado. No obstante, se el sistema debe estar diseñado para asegurar el mayor nivel de compatibilidad con los navegadores Mozilla Firefox y Microsoft Internet Explorer Formato XML para la comunicación El sistema debe hacer uso del formato XML implementado en el sistema M2M Engine 1.0 para la comunicación con los dispositivos de campo y las aplicaciones de terceros. El formato XML existente estará sujeto a revisión con el fin de estudiar la inclusión de nuevas variables o estructuras de datos. Confidencial SILOCOM, C.A., 2010 Pág. 40 de 42

122 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS 4.7 Requerimientos de Documentación en Línea y de s de Ayuda El sistema debe contar con una copia digital del manual de usuario. La documentación en línea debe implementarse en el formato HTML 2.0 y contar con los mismos recursos gráficos (capturas de pantalla, ilustraciones, etc.) que su contraparte en físico. El sistema debe contar con ayuda en base al contexto, utilizando recursos visuales como cuadros de mensajes, tooltips, etc. 4.8 Componentes Comprados Para el desarrollo del sistema no se incurrirán gastos en la adquisición de licencias, software o hardware. Cabe destacar que se están utilizando solo herramientas de software libre para el desarrollo de la aplicación. 4.9 Interfaces Interfaz de Usuario La interfaz de usuario web estará diseñada en formato HTML 2.0. Debe presentar un entorno amigable y que facilite la ubicación y utilización de las funcionalidades del sistema. En este momento no se cuentan con capturas de pantalla de la interfaz de usuario Requerimientos de Licenciamiento Debido a que el desarrollo del sistema M2M Engine 2.0 se realizara haciendo uso de tecnologías de software libre, no se generan requerimientos de licenciamiento. No obstante, el equipo desarrollador debe comprometerse a hacer uso de dichas herramientas según lo estipulado por las licencias GNU GPL y CDDL Aspectos Legales, Derecho de Autor y otros Avisos En estos momentos no se cuenta con la información sobre los aspectos legales y derechos de autor aplicables al sistema M2M Engine 2.0. SILOCOM, C.A. se compromete en realizar los trámites necesarios para establecer los aspectos legales del software antes de su distribución comercial Estándares Aplicables El sistema M2M Engine 2.0 tendrá un ciclo de desarrollo en donde deben cumplirse los siguientes estándares en las labores de implementación: HTML 2.0 (definido por la W3C) Especificaciones de Java EE (definidas por Oracle) Por otra parte, las labores de desarrollo de software de SILOCOM, C.A. se llevaran a cabo con la finalidad de cumplir (internamente y con miras a obtener una certificación a mediano o largo plazo) con los siguientes estándares de calidad y regulación internacionales: ISO 9001:2008 Confidencial SILOCOM, C.A., 2010 Pág. 41 de 42

123 M2M Engine 2.0 Core Versión: 1.02 Especificaciones de Requerimientos del Software Fecha: 23/08/10 SILOCOM_M2ME[ADMIN]_ERS ISO/IEC 12207:2008 CMMI (Nivel 2) Confidencial SILOCOM, C.A., 2010 Pág. 42 de 42

124 Apéndice C

125 SILOCOM, C.A. M2M Engine 2.0 (Administrador) Documento de la Arquitectura del Software Versión 1.1

126 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS Historia de Revisión Fecha Versión Descripción Autor 23/09/ Primera versión del documento de Arquitectura de Software 10/10/ Finalización del documento de Arquitectura de Software Juan Abreu Juan Abreu Confidencial Silocom C.A., 2010 Página2 de 33

127 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS Tabla de Contenidos 1. Introducción Propósito Alcance Definiciones, Siglas, y Abreviaciones Referencias Vista Global 5 2. Representación Arquitectónica 6 3. Metas y Restricciones Arquitectónicas 6 4. Vista de Casos de Uso es Casos de uso Diagramas de casos de uso Descripción de los casos de uso Vista Lógica Visión general Paquetes de Diseño Significativos Arquitectónicamente Diagrama de Componentes (Módulo Cliente Administrador) Diagrama de Clases (Módulo Cliente Administrador) Diagrama de Componentes (Módulo Silocom Administrador) Vista de Datos Entidad Relación Capa Física Entidad Relación M2M Engine Confidencial Silocom C.A., 2010 Página3 de 33

128 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS 33 Confidencial Silocom C.A., 2010 Página4 de 33

129 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS Documento de la Arquitectura del Software 1. Introducción 1.1 Propósito 1.2 Alcance El presente documento describe en detalle la representación arquitectónica del sistema sugerido para el desarrollo del de administración para el M2M Engine. Este documento será utilizado como guía para la construcción, con el objetivo de sentar bases para la estructuración lógica y física del sistema. El propósito de este documento es proveer un modelo para la estructura arquitectónica general del sistema usando un modelo donde se muestran las vistas de Casos de uso, lógica y de datos, que describen de forma detallada los fundamentos de la construcción. A través de estas vistas se busca reflejar las decisiones significativas de diseño que han sido tomadas en el desarrollo de esta propuesta que satisface los requerimientos del usuario. Eldocumento presentado a continuación persigue el objetivo el explicar de manera clara la estructura base sobre la cual se construirá el sistema en cuestión. De esta estructura, basada en las vistas de Casos de Uso, Lógica y de Datos, se describirán los modelos correspondientes a cada una para obteneruna mejor comprensión de la propuesta en general. 1.3 Definiciones, Siglas, y Abreviaciones 1.4 Referencias - Especificaciones de Requerimientos del Software M2M Engine 2.0 (Administrador). Versión: Código del documento: SILOCOM_M2ME[ADMIN]_ERS. Fecha: 23/08/10. Ubicación electrónica: \\ \Company Shared Folders\Desarrollo \Documentacion M2M\Documentos M2M Engine\ - Visión Del M2M Engine 2.0. Versión: Código del documento: SILOCOM_M2ME_Vision. Fecha: 11/08/10. Ubicación electrónica: \\ \Company SharedFolders\Desarrollo \Documentacion M2M\Documentos M2M Engine\ - Glosario M2M Engine 2.0. Versión: Código del documento: SILOCOM_M2ME_Glosario. Fecha: 17/08/10. Ubicación electrónica: \\ \Company SharedFolders\Desarrollo \Documentacion M2M\Documentos M2M Engine\ 1.5 Vista Global El presente documento muestra, de manera general, una descripción de la notación, modelos y estándares utilizados para la representación arquitectónica del sistema, indicando también la especificación de las restricciones a las cuales éstos se encuentran sujetos, mencionando también las metas que se alcanzar y que tienen gran significancia en el desarrollo de una arquitectura base del sistema. Confidencial Silocom C.A., 2010 Página5 de 33

130 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS Se incluye la Vista de Casos de Uso, con una descripción completa de cada uno de ellos y sus diagramas. Posteriormente se muestra la Vista Lógica, que muestra el conjunto principal de clases que modelan el sistema con las relaciones que existen entre ellas. También se encuentra la Vista de Datos, que consiste en el diagrama del modelo ERE propuesto para la base de datos del sistema acompañado de su diccionario de datos que lista y explica las entidades, interrelaciones y atributos de las mismas. 2. Representación Arquitectónica Representaremos las vistas en el documento utilizando los siguientes recursos: - Vista de casos de uso: se utilizará el diagrama de casos de usos, usando la notación UML. - Vista lógica: se usará el diagrama de clases y diagrama de componentes usando notación UML. - Vista de datos: se empleará el diagrama ER y el diccionario de datos para desarrollar esta vista. 3. Metas y Restricciones Arquitectónicas El desarrollo de este proyecto se encuentra orientado hacia un proceso que permita entregar un software que cumpla con ser mantenible, usable y de alta calidad. El software debe seguir las siguientes características: - Mantenibilidad El sistema de ser de fácil mantenimiento. Es decir, que los programadores y diseñadores realicen el mínimo esfuerzo necesario para localizar y arreglar un error del programa o hacerle una actualización al mismo. Además que el sistema esté diseñado de forma modular, esto es: que todas las funcionalidades estén encapsuladas y que sea fácil el proceso de agregar nuevas funcionalidades. - Practicidad El sistema debe seguir el principio de eficiencia (en tiempo y memoria). Abarcar los conceptos de usabilidad y portabilidad. - Usabilidad El sistema debe ser de fácil manejo. El esfuerzo que necesiten los usuarios para aprender, operar, preparar los datos de entrada e interpretar las salidas del sistema debe ser mínimo. Todo esto puede lograrse con una interfaz amigable, con elementos fáciles de usar y atractivos para el usuario. Las restricciones halladas hasta el momento son: - Restricciones de tiempo: existe una fecha de entrega, a la cual el proyecto debe estar finalizado. - Restricciones de seguridad y privacidad: es necesario prestarle a los usuarios toda la Confidencial Silocom C.A., 2010 Página6 de 33

131 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS seguridad con respecto a sus datos, información, etc. - Restricciones de tecnología: el software debe ser compatible con casi todos los navegadores existentes, para garantizarle a los usuarios el acceso al mismo. - Restricciones en el uso de herramientas de desarrollo: Los lenguajes a emplear para el desarrollo del sistema son limitados. Además, sólo se pueden utilizar la metodología RUP para el desarrollo de los documentos y diagramas. 4. Vista de Casos de Uso 4.1 es Administrador Configurador Superusuario Descripción Representación del cliente en el sistema. Representación de un usuario perteneciente al módulo configurador, que posee funcionalidades en común con este módulo Empleado de la empresa Silocom, con acceso a todas las funcionalidades del sistema. 4.2 Casos de uso A continuación se presentan los casos de uso que influyen en la arquitectura del sistema Diagramas de casos de uso Confidencial Silocom C.A., 2010 Página7 de 33

132 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS Confidencial Silocom C.A., 2010 Página8 de 33

133 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS Confidencial Silocom C.A., 2010 Página9 de 33

134 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS Descripción de los casos de uso ID: CU_ADMIN_01 Caso de uso: Agregar cliente Descripción:Permite agregar un cliente a la base de datos. Requerimiento: (M2ME_Admin_1) Gestión de clientes. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Agregar cliente. 3- Llena la información necesaria y presiona el botón agregar cliente. 2- Muestra un formulario con toda la información que es necesaria para agregar un cliente. 4- Valida la información y se muestra un mensaje con el resultado de la operación. FlujoAlterno I 4.1- Si algún campo del formulario es inválido, se pide al usuario que corrija el mismo. Poscondición: El cliente queda agregado en la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_02 Caso de uso: Eliminar cliente Descripción:Permite eliminar un cliente de la base de datos. Requerimiento: (M2ME_Admin_1) Gestión de clientes. Precondición: El actor debe estar autenticado en el sistema. El cliente a eliminar debe estar registrado en el sistema. Flujo Básico 1- Selecciona la opción Eliminar cliente. 3- Selecciona el cliente que se desea eliminar y presiona el botón eliminar cliente. 5- Confirma la operación. --- FlujoAlterno I 2- Muestra una lista ordenada de los clientes registrados en el sistema. 4- Pide confirmación de la operación de eliminación. 6- Muestra un mensaje con el resultado de la operación. Confidencial Silocom C.A., 2010 Página10 de 33

135 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS Poscondición: El cliente queda eliminado de la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_03 Caso de uso: Modificar cliente Descripción:Permite modificar los datos un cliente en la base de datos. Requerimiento: (M2ME_Admin_1) Gestión de clientes. Precondición: El actor debe estar autenticado en el sistema. El cliente a modificar debe estar registrado en el sistema. Flujo Básico 1- Selecciona la opción Modificar cliente. 3- Modifica los campos deseados y selecciona el botón Guardar información. 5- Confirma la operación Muestra todos los atributos de un cliente, permitiendo modificar los mismos. 4- Pide confirmación de la operación de modificación. 6- Muestra un mensaje con el resultado de la operación. FlujoAlterno I 6.1- Si algún campo del formulario es inválido, se pide al usuario que corrija el mismo. Poscondición: El cliente queda modificado de la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_04 Caso de uso: Habilitar servicios cliente Descripción:Permite habilitar los servicios que un cliente adquirió a través de un plan. Requerimiento: (M2ME_Admin_1) Gestión de clientes. Precondición: El actor debe estar autenticado en el sistema. El cliente al que se le van a habilitar los servicios, debe estar registrado en el sistema. Flujo Básico 1- Selecciona la opción Habilitar servicios El sistema muestra una lista ordenada de los usuarios a los cuales se les puede habilitar los Confidencial Silocom C.A., 2010 Página11 de 33

136 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS 3- Selecciona el cliente al cual se desea habilitar los servicios. 5- Confirma la operación. servicios. 4- Pide confirmación a la operación. 6- Muestra un mensaje con el resultado de la operación. FlujoAlterno I Poscondición: Al cliente le quedan activos los servicios adquiridos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_05 Caso de uso: Deshabilitar servicios cliente Descripción:Permite deshabilitar los servicios que un cliente. Requerimiento: (M2ME_Admin_1) Gestión de clientes. Precondición: El actor debe estar autenticado en el sistema. Los servicios han debido ser habilitados previo a la deshabilitación. Flujo Básico 1- Selecciona la opción Detener servicios 3- Selecciona el cliente al cual desea deshabilitarte los servicios. 5- Confirma la operación de deshabilitación. --- FlujoAlterno I Poscondición: Al cliente le quedan desactivados los servicios. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra una lista de todos los clientes registrados en el sistema, los cuales tienen los servicios habilitados. 4- Pide confirmar la operación. 6- Muestra un mensaje con el resultado de la operación. ID: CU_ADMIN_06 Caso de uso: Agregar usuario Descripción:Permite agregar un usuario a la base de datos. Confidencial Silocom C.A., 2010 Página12 de 33

137 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Agregar usuario. 3- Llena la información necesaria y presiona el botón agregar usuario. 2- Muestra un formulario con toda la información que es necesaria para agregar un usuario (incluyendo al cliente al cual se va a asociar). 4- Valida la información y muestra un mensaje con el resultado de la operación al usuario. FlujoAlterno I 4.1- Si algún campo del formulario es inválido, se pide al usuario que corrija el mismo. Poscondición: El usuario queda agregado a la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_07 Caso de uso: Eliminar usuario Descripción:Permite eliminar un usuario de la base de datos. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. El usuario a eliminar debe estar registrado en el sistema. Flujo Básico 1- Selecciona la opción Eliminar usuario. 3- Selecciona el cliente al cual está asociado el usuario a eliminar. 5- Selecciona el usuario que desea eliminar. 7- Confirma la operación. --- FlujoAlterno I 2- Muestra una lista ordenada de los clientes registrados en el sistema. 4- Muestra una lista de los usuarios registrados. 6- Pide confirmación de la operación de eliminación. 8- Muestra un mensaje con el resultado de la operación. Confidencial Silocom C.A., 2010 Página13 de 33

138 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS Poscondición: El usuario queda eliminado de la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_08 Caso de uso: Modificar usuario Descripción:Permite modificar los datos un usuario en la base de datos. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. El usuario a editar debe estar registrado en el sistema. Flujo Básico 1- Selecciona la opción Modificar usuario. 3- Modifica los campos deseados y selecciona el botón Guardar información. 5- Confirma la operación Muestra todos los atributos de un usuario, permitiendo modificar los mismos. 4- Pide confirmación de la operación de modificación. 6- Valida la información y muestra un mensaje con el resultado de la operación. FlujoAlterno I 6.1- Si algún campo del formulario es inválido, se pide al usuario que corrija el mismo. Poscondición: El usuario queda modificado en la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_09 Caso de uso:listar usuarios Descripción:Permite mostrar los usuariosen la base de datos. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Listar usuario. --- FlujoAlterno I 2- Muestra una lista ordenada con los usuarios registrados en el sistema. Confidencial Silocom C.A., 2010 Página14 de 33

139 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS Poscondición: Queda impreso en pantalla una lista con los usuarios registrados. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_10 Caso de uso:desconectar usuario Descripción:Permite desconectar un usuario del sistema. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Desconectar usuario. 3- Selecciona el cliente al cual está asociado el usuario a desconectar. 5- Selecciona el usuario se desea desconectar. 7- Confirma la operación. --- FlujoAlterno I Poscondición: El usuario queda desconectado del sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra una lista ordenada de los clientes registrados en el sistema. 4- Muestra una lista de los usuarios asociados al cliente seleccionado, que están conectados. 6- Pide confirmación de la operación de desconexión. 8- Muestra un mensaje con el resultado de la operación. ID: CU_ADMIN_11 Caso de uso:agregar rol Descripción:Permite desconectar un usuario del sistema. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Agregar rol. 2- Muestra un formulario con toda la información que es necesaria para agregar un rol. Confidencial Silocom C.A., 2010 Página15 de 33

140 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS 3- Llena la información necesaria y presiona el botón agregar rol. 4- Valida la información y muestra un mensaje con el resultado de la operación al usuario. FlujoAlterno I 4.1- Si algún campo del formulario es inválido, se pide al usuario que corrija el mismo. Poscondición: El rol queda agregado a la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_12 Caso de uso:modificar rol Descripción:Permite modificar un rol registrado en el sistema. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Agregar rol. 3- Llena la información necesaria y presiona el botón agregar rol Muestra un formulario con toda la información que es necesaria para agregar un rol. 4- Valida la información y muestra un mensaje con el resultado de la operación al usuario. FlujoAlterno I 4.1- Si algún campo del formulario es inválido, se pide al usuario que corrija el mismo. Poscondición: El rol queda modificado en la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_13 Caso de uso:eliminar rol Descripción:Permite modificar un rol eliminado del sistema. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. El rol a eliminar debe estar registrado en el sistema. Flujo Básico 1- Selecciona la opción Eliminar rol. --- Confidencial Silocom C.A., 2010 Página16 de 33

141 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS 5- Selecciona el rol que desea eliminar. 7- Confirma la operación. 2- Muestra una lista ordenada de los roles registrados en el sistema. 6- Pide confirmación de la operación de eliminación. 8- Muestra un mensaje con el resultado de la operación. FlujoAlterno I Poscondición: El rol queda eliminado de la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_14 Caso de uso:listar roles Descripción:Permite listar los roles registrado en el sistema. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Listar roles. --- FlujoAlterno I Poscondición: El rol queda eliminado de la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra una lista ordenada de los roles registrados en el sistema. ID: CU_ADMIN_15 Caso de uso:limitar direcciones IP de un usuario Descripción:Permite crear una lista de direcciones IP de las cuales los usuarios no van a poder conectarse. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Bloquear dirección IP. 2- Muestra un formulario, con toda la información necesaria para agregar un IP a la lista de Confidencial Silocom C.A., 2010 Página17 de 33

142 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS 3- Ingresa toda la información necesaria solicitada por el sistema y selecciona el botón agregar. direcciones bloqueadas. 4- Muestra un mensaje con la operación FlujoAlterno I Poscondición: La dirección IP queda agregada en la lista de direcciones bloqueadas. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_16 Caso de uso:mostrar usuarios conectados Descripción:Muestra una lista ordenada de los usuarios conectados en el sistema. Requerimiento: (M2ME_Admin_2) Gestión de usuarios. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Mostrar usuarios conectados. --- FlujoAlterno I 2- Muestra una lista ordenada por clientes, de todos los usuarios conectados al sistema. Poscondición: Queda impreso en pantalla todos los usuarios conectados en el sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a. --- ID: CU_ADMIN_17 Caso de uso: Mostrar espacio libre en la base de datos Descripción:Muestra un informe sobre el espacio disponible en la base de datos. Requerimiento: (M2ME_Admin_3) Supervisión de consumo de clientes según plan. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Mostrar espacio libre en la base de datos. FlujoAlterno I 2- Muestra la información sobre el espacio disponible en la base de datos. Confidencial Silocom C.A., 2010 Página18 de 33

143 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS Poscondición: Queda impreso en pantalla la información sobre el uso de la base de datos. Requerimientos especiales: N/A. Puntos de extensión:n/a. --- ID: CU_ADMIN_18 Caso de uso: Mostrar historial de conexiones del usuario configurador. Descripción:Muestra una lista de conexiones del usuario configurador. Requerimiento: (M2ME_Admin_3) Supervisión de consumo de clientes según plan. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Mostrar espacio libre en la base de datos. FlujoAlterno I 2- Muestra la información sobre el espacio disponible en la base de datos. Poscondición: Queda impreso en pantalla la información sobre las conexiones del usuario configurador. Requerimientos especiales: N/A. Puntos de extensión:n/a. --- ID: CU_ADMIN_19 Caso de uso: Mostrar consumo en ancho de banda Descripción:Muestra un informe con el consumo de ancho de banda hasta la fecha de la consulta. Requerimiento: (M2ME_Admin_3) Supervisión de consumo de clientes según plan. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Mostrar consumo de ancho de banda. FlujoAlterno I 2- Muestra la información del consumo de ancho de banda, realizado hasta la fecha. Poscondición: Queda impreso en pantalla la información sobre el consumo en ancho de banda hasta la fecha de la consulta. Requerimientos especiales: N/A. Puntos de extensión:n/a. Confidencial Silocom C.A., 2010 Página19 de 33

144 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS ID: CU_ADMIN_20 Caso de uso: Generar factura Descripción:Permite generar una factura que resume todos los consumos de un cliente. Requerimiento: (M2ME_Admin_4) Reporte de factura. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Generar factura. 3- Selecciona las opciones deseadas y luego Generar factura FlujoAlterno I 2- Muestra un formulario con las diferentes opciones de formato a exportar (xls, pdf, web). 4- Muestra un mensaje con el resultado de la operación. Poscondición: Queda generado una factura con todos los consumos del cliente seleccionado. Requerimientos especiales: N/A. Puntos de extensión:n/a. --- ID: CU_ADMIN_21 Caso de uso: Iniciar registro de eventos estáticos. Descripción:Crea un archivo en el que se registrarán las actividades de los usuarios conectados Requerimiento: (M2ME_Admin_5) Reporte de actividades de usuario. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Iniciar log. FlujoAlterno I Poscondición:Queda iniciado el registro de eventos estáticos. Requerimientos especiales: N/A. Puntos de extensión:n/a Crea un archivo e inicia el registro de las actividades de los usuarios que están conectados. ID: CU_ADMIN_22 Caso de uso: Detener registro de eventos estáticos. Descripción:Detiene el registro las actividades de los usuarios conectados Requerimiento: (M2ME_Admin_5) Reporte de actividades de usuario. Precondición: Confidencial Silocom C.A., 2010 Página20 de 33

145 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS El actor debe estar autenticado en el sistema. Debió haber sido iniciado el registro de eventos estáticos. Flujo Básico 1- Selecciona la opción Detener log. FlujoAlterno I Poscondición:Queda detenido el registro de eventos estáticos. Requerimientos especiales: N/A. Puntos de extensión:n/a Detiene el registro de las actividades de los usuarios que están conectados. ID: CU_ADMIN_23 Caso de uso: Generar reporte de diagnóstico de remotas. Descripción:Detiene el registro las actividades de los usuarios conectados Requerimiento: (M2ME_Admin_6) Reporte de actividades de remotas. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Generar reporte de remotas. FlujoAlterno I Poscondición:Queda impreso en pantalla el reporte de las remotas. Requerimientos especiales: N/A. Puntos de extensión:n/a Genera un reporte con la información de diagnóstico de las remotas. ID: CU_ADMIN_24 Caso de uso: Generar reporte de disponibilidad y diagnóstico de módulos. Descripción:El sistema genera un reporte con la información de los módulos del mismo Requerimiento: (M2ME_Admin_7) Reporte de disponibilidad y diagnóstico de módulos Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Generar reporte de módulos. 2- Genera un reporte con la información de Confidencial Silocom C.A., 2010 Página21 de 33

146 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS diagnóstico sistema. FlujoAlterno I y disponibilidad de los módulos del Poscondición:Queda impreso en pantalla el reporte de las módulos. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_25 Caso de uso: Generar reporte de rendimiento Descripción:El sistema genera un reporte con la información del rendimiento del mismo. Requerimiento: (M2ME_Admin_8) Reporte de rendimiento Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Generar reporte de rendimiento. --- FlujoAlterno I Poscondición:Queda impreso en pantalla el reporte de rendimiento. Requerimientos especiales: N/A. Puntos de extensión:n/a Genera un reporte con la información del rendimiento del sistema, entre consumo de memoria ram, uso del CPU y consumo de la base de datos. ID: CU_ADMIN_26 Caso de uso: Agregar lectura programada. Descripción:El sistema agrega una lectura programada para una remota Requerimiento: (M2ME_Admin_9) Gestión de lecturas programadas Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Agregar lecturas programadas. 3- Ingresa la información requerida y selecciona la opción agregar 2- Muestra un formulario con toda la información asociada a una lectura programada. 4- Muestra un mensaje con el resultado de la Confidencial Silocom C.A., 2010 Página22 de 33

147 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS operación. FlujoAlterno I 4.1 Si algún campo es invalido, se le pide al usuario que sea corregido. Poscondición:Queda registrada la lectura programada en el sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_27 Caso de uso: Eliminar lectura programada. Descripción:El sistema elimina una lectura programada. Requerimiento: (M2ME_Admin_9) Gestión de lecturas programadas Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Eliminar lectura programada. 3- Selecciona la lectura programada que se desea 5- Confirma la operación de eliminación. --- FlujoAlterno I 2- Muestra una lista de las lecturas agregadas al sistema. 4- Pide confirmar la operación. Poscondición:Queda eliminada la lectura programada en el sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra un mensaje con el resultado de la operación. ID: CU_ADMIN_28 Caso de uso: Iniciar lectura programada. Descripción:El sistema inicia una lectura programada. Requerimiento: (M2ME_Admin_9) Gestión de lecturas programadas Precondición: El actor debe estar autenticado en el sistema. La lectura programada a iniciar, debe estar registrada en el sistema. Flujo Básico 1- Selecciona la opción Iniciar lectura programada. Confidencial Silocom C.A., 2010 Página23 de 33

148 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS 3- Selecciona la lectura programada que se desea iniciar. 5- Confirma la operación de iniciación. 2- Muestra una lista de las lecturas agregadas al sistema y disponibles para ese usuario. 4- Pide confirmación de la operación 6- Muestra un mensaje con el resultado de la operación. FlujoAlterno I Poscondición:Queda iniciada la lectura programada en el sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_29 Caso de uso: Detener lectura programada. Descripción:El sistema detiene una lectura programada. Requerimiento: (M2ME_Admin_9) Gestión de lecturas programadas Precondición: El actor debe estar autenticado en el sistema. La lectura programada a detener, debe haber sido inicia anteriormente. Flujo Básico 1- Selecciona la opción Finalizar lectura programada. 3- Selecciona la lectura programada que se desea finalizar. 5- Confirma la operación. --- FlujoAlterno I Poscondición:Queda detenida la lectura programada en el sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a. 2- Muestra una lista de las lecturas programadas iniciadas por el usuario. 4- Pide confirmación de la operación de finalización. 6- Muestra un mensaje con el resultado de la operación. Confidencial Silocom C.A., 2010 Página24 de 33

149 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS ID: CU_ADMIN_30 Caso de uso: Iniciar un módulo. Descripción:El sistema iniciaun módulo del M2M. Requerimiento: (M2ME_Admin_10) Gestión de módulos Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Iniciar módulo. 3- Selecciona el módulo del sistema que desea ser iniciado. FlujoAlterno I Poscondición:Queda iniciado el módulo seleccionado. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra una lista de los módulos que pueden ser iniciados. 4- Muestra un mensaje con el resultado de la operación. ID: CU_ADMIN_31 Caso de uso: Detener un módulo. Descripción:El sistema detieneun módulo del M2M. Requerimiento: (M2ME_Admin_10) Gestión de módulos Precondición: El actor debe estar autenticado en el sistema. El módulo a detener, debió haber sido iniciado previamente. Flujo Básico 1- Selecciona la opción Detener módulo. 3- Selecciona el módulo del sistema que desea ser detenido. 5- Confirma la operación. FlujoAlterno I Poscondición:Queda detenido el módulo seleccionado. Requerimientos especiales: N/A. Puntos de extensión:n/a. 2- Muestra una lista de los módulos que están activos y pueden ser detenidos. 4- Pide confirmación de la operación. 6- Muestra un mensaje con el resultado de la operación. Confidencial Silocom C.A., 2010 Página25 de 33

150 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS ID: CU_ADMIN_32 Caso de uso: Reiniciar un módulo. Descripción:El sistema reiniciaun módulo del M2M. Requerimiento: (M2ME_Admin_10) Gestión de módulos Precondición: El actor debe estar autenticado en el sistema. El módulo a reiniciar, debió haber sido iniciado previamente. Flujo Básico 1- Selecciona la opción Reiniciar módulo. 3- Selecciona el módulo del sistema que desea ser reiniciado. 5- Confirma la operación. FlujoAlterno I Poscondición:Queda reiniciado el módulo seleccionado. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra una lista de los módulos que están activos y pueden ser reiniciados. 4- Pide confirmación de la operación. 6- Muestra un mensaje con el resultado de la operación. ID: CU_ADMIN_33 Caso de uso: Agregar dispositivo de comunicación Descripción:El sistema agrega un dispositivo de comunicación. Requerimiento: (M2ME_Admin_11) Gestión de dispositivos de comunicación. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Agregar dispositivo de comunicación. 3- Ingresa toda la información necesaria y selecciona la opción Agregar. 2- Muestra un formulario con toda la información asociada a un dispositivo de comunicación. 4- Valida la información y muestra un mensaje con el resultado de la operación. FlujoAlterno I 4.1- Si uno de los datos es el inválido, se le pide al usuario que lo corrija. Poscondición:Queda agregado el dispositivo de comunicación al sistema. Confidencial Silocom C.A., 2010 Página26 de 33

151 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS Requerimientos especiales: N/A. Puntos de extensión:n/a. --- ID: CU_ADMIN_34 Caso de uso: Eliminar dispositivo de comunicación Descripción:El sistema elimina un dispositivo de comunicación. Requerimiento: (M2ME_Admin_11) Gestión de dispositivos de comunicación. Precondición: El actor debe estar autenticado en el sistema. El dispositivo de comunicación a eliminar, debe estar agregado en el sistema Flujo Básico 1- Selecciona la opción Eliminar dispositivo de comunicación. 3- Selecciona el dispositivo que se desea eliminar. 5- Confirma la operación. FlujoAlterno I 2- Muestra una lista de los dispositivos de comunicación agregados en el sistema. 4- Pide confirmación de la operación. Poscondición:Queda eliminado el dispositivo de comunicación al sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra un mensaje con el resultado de la operación. ID: CU_ADMIN_35 Caso de uso: Habilitar dispositivo de comunicación Descripción:El sistema habilita un dispositivo de comunicación. Requerimiento: (M2ME_Admin_11) Gestión de dispositivos de comunicación. Precondición: El actor debe estar autenticado en el sistema. El dispositivo de comunicación a habilitar, debe estar agregado en el sistema Flujo Básico 1- Selecciona la opción Habilitar dispositivo de comunicación. 3- Selecciona el dispositivo que se desea habilitar. 2- Muestra una lista de los dispositivos de comunicación agregados en el sistema. Confidencial Silocom C.A., 2010 Página27 de 33

152 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS 4- Muestra un mensaje con el resultado de la operación. FlujoAlterno I Poscondición:Queda habilitado el dispositivo de comunicación al sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a. --- ID: CU_ADMIN_36 Caso de uso: deshabilitar dispositivo de comunicación Descripción:El sistema deshabilita un dispositivo de comunicación. Requerimiento: (M2ME_Admin_11) Gestión de dispositivos de comunicación. Precondición: El actor debe estar autenticado en el sistema. El dispositivo de comunicación a deshabilitar, debe haber sido habilitado anteriormente Flujo Básico 1- Selecciona la opción Deshabilitar dispositivo de comunicación. 3- Selecciona el dispositivo que se desea deshabilitar. 5- Confirma la operación. FlujoAlterno I 2- Muestra una lista de los dispositivos de comunicación habilitados en el sistema. 4- Pide confirmación de la operación. Poscondición:Queda deshabilitado el dispositivo de comunicación al sistema. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra un mensaje con el resultado de la operación. ID: CU_ADMIN_37 Caso de uso: Habilitar socket Descripción:El sistema habilita un socket. Requerimiento: (M2ME_Admin_12) Supervisión de la capa física. Precondición: El actor debe estar autenticado en el sistema. Flujo Básico 1- Selecciona la opción Habilitar socket Confidencial Silocom C.A., 2010 Página28 de 33

153 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS 3- Selecciona el socket que desea habilitarse. 2- Muestra una lista de los sockets creados. 4- Muestra un mensaje con el resultado de la operación. FlujoAlterno I Poscondición:Queda habilitado el socket, en la capa física. Requerimientos especiales: N/A. Puntos de extensión:n/a. ID: CU_ADMIN_38 Caso de uso: Deshabilitar socket Descripción:El sistema deshabilita un socket. Requerimiento: (M2ME_Admin_12) Supervisión de la capa física. Precondición: El actor debe estar autenticado en el sistema. El socket a deshabilitar, debió haber sido activado previamente. Flujo Básico 1- Selecciona la opción Habilitar socket 3- Selecciona el socket que desea habilitarse. --- FlujoAlterno I Poscondición:Queda deshabilitado el socket, en la capa física. Requerimientos especiales: N/A. Puntos de extensión:n/a Muestra una lista de los sockets creados. 4- Muestra un mensaje con el resultado de la operación. ID: CU_ADMIN_39 Caso de uso: Reiniciar socket Descripción:El sistema reinicia un socket. Requerimiento: (M2ME_Admin_12) Supervisión de la capa física. Precondición: El actor debe estar autenticado en el sistema. El socket a reiniciar, debió haber sido activado previamente. Flujo Básico 1- Selecciona la opción Reiniciar socket 2- Muestra una lista de los sockets habilitados. Confidencial Silocom C.A., 2010 Página29 de 33

154 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS 3- Selecciona el socket que desea reiniciarse. 5- Confirma la operación de reinicio. 4- Pide confirmar la operación. 6- Muestra un mensaje con el resultado de la operación. FlujoAlterno I Poscondición:Queda reiniciado el socket, en la capa física. Requerimientos especiales: N/A. Puntos de extensión:n/a. 5. Vista Lógica Debido a la naturaleza problema, el sistema se divide en dos grandes módulos: el módulo del cliente que contrata los servicios de la empresa Silocom C.A. (Módulo Cliente Administrador), y el módulo de los empleados de Silocom C.A., quienes tienen funciones de superusuarios en el sistema (Módulo Silocom Administrador). 5.1 Visión general Soporta los requerimientos funcionales y los servicios que el sistema debe proveer a sus usuarios finales. En esta vista se incluye el Diagrama de Componentes y el Diagrama de Clases, que abarca el espacio de la Solución del Problema 5.2 Paquetes de Diseño Significativos Arquitectónicamente Diagrama de Componentes (Módulo Cliente Administrador) Confidencial Silocom C.A., 2010 Página30 de 33

155 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS Diagrama de Clases (Módulo Cliente Administrador) Confidencial Silocom C.A., 2010 Página31 de 33

156 M2M Engine 2.0 Administrador Versión: 1.0 Documento de la Arquitectura de Software Fecha: 23/09/2010 SILOCOM_M2ME[ADMIN]_DAS Diagrama de Componentes (Módulo Silocom Administrador) 6. Vista de Datos La base de datos utilizada en el proyecto, fue una modificación de la base de datos que se encuentra actualmente en producción. Adicionalmente fue agregada una base de datos mas para el Módulo de la Capa Física. 6.1 Entidad Relación Capa Física Confidencial Silocom C.A., 2010 Página32 de 33