Términos de Referencia Plataforma de Interoperabilidad Libre Orientada a Servicios para el Estado Venezolano

Transcripción

1 Ministerio del Poder Popular para las Telecomunicaciones y la Informática Centro Nacional de Tecnologías de Información Términos de Referencia Plataforma de Interoperabilidad Libre Orientada a Servicios para el Estado Venezolano Validado por: Aprobado por : Francelis Konrad Gerente de Ingeniería de Software Ivonne Antón Gerente de Atención al Estado Oficina de Gestión de Requerimientos de Sistemas Gerencia de Ingeniería de Software 1 de 31

2 Historial de Revisiones Versión Fecha Autor Descripción /04/2008 Willie Nieto Versión Inicial /04/2008 Willie Nieto Correcciones versión inicial /05/2008 Willie Nieto Correcciones, recomendaciones de CANTV /05/2008 Willie Nieto Recomendaciones GPT, CANTV /06/2008 Willie Nieto Corrección /07/2008 Willie Nieto Corrección /07/2008 Willie Nieto Correcciones GAE, GNC /07/2008 Willie Nieto Correcciones GAE /08/2008 Willie Nieto / Yasibit Revisión 2 de 31

3 Índice de contenido 1 Información General Gerencias Solicitantes Nombre del Proyecto Beneficiario Introducción Antecedentes Justificación Objetivos Principal Secundarios Alcance Definiciones, Acrónimos y Abreviaturas Referencias Metodología Requerimientos Funcionales No Funcionales Seguridad Soportabilidad y Operabilidad Restricción de Diseño Requerimientos de Documentación en Línea y de Sistemas de Ayuda Interfaces Aspectos Legales Estándares Aplicables Requerimientos de transferencia tecnológica Descripciones de los Involucrados y Usuarios Perfil de Involucrados Perfil de Usuario Alternativas y Sistemas Similares Rangos de Calidad Calidad en el Producto de 31

4 7.2 Calidad en el cumplimiento de los Términos de Referencia Elementos Entregables de 31

5 Términos de Referencia 1 Información General 1.1 Gerencias Solicitantes Gerencia de Atención al Estado 1.2 Nombre del Proyecto Plataforma de Interoperabilidad Libre Orientada a Servicios para el Estado Venezolano 1.3 Beneficiario Administración Pública Nacional. 2 Introducción 2.1 Antecedentes En la actualidad, diversas instituciones de la Administración Pública han implantado, en los últimos años, sistemas internos automatizados en las áreas de estadísticas, finanzas, salud, transporte, defensa, planificación, recursos humanos, entre otros, que les ha permitido la prestación de servicios posteriormente en línea con el ciudadano. Sin embargo, la mayoría de estos organismos públicos (Ministerios e Instituciones Adscritas, Gobernaciones y Alcaldías) presentan desarticulación entre ellos, en materia de plataformas y tecnologías, que dificulta la interoperabilidad, así como la poca seguridad en las redes y servicios prestados, aunado a los elevados costos de conectividad que impiden el desarrollo de los servicios asociados a gobierno electrónico. Esta desarticulación, entre los organismos públicos y sus procesos de prestación de servicios, trae como consecuencia, desde el punto de vista de la información: duplicidad, falta de integridad, poca claridad frente a la responsabilidad de los datos y la no disponibilidad en el momento oportuno. Desde 5 de 31

6 el punto de vista institucional, se presenta una duplicidad de esfuerzos y se muestra una administración menos eficiente y poco transparente. En virtud de lo expuesto, se ha definido un modelo de interoperabilidad para el Estado venezolano, que debe permitir la incorporación de sistemas, trámites y servicios institucionales, a través de una plataforma orientada a servicios en software libre y estándares abiertos, con el objetivo de contribuir a la modernización tecnológica de la Administración Pública Nacional en todos sus niveles, a su vez que promueva una gestión eficaz y eficiente para la optimización de las relaciones entre el gobierno y el público (ciudadano, empresario, etc). El CNTI, está trabajando tanto en la definición de estándares de interoperabilidad como en la migración de aplicaciones de software propietario a software libre, implantación e integración de soluciones para conformar una plataforma robusta y escalable de prestación de servicios. 2.2 Justificación El presente proyecto busca proveer una plataforma de interoperabilidad libre que permita la publicación y uso de servicios por parte de las Instituciones del Estado para propiciar su interrelación efectiva y apoyar la optimización de la gestión pública de cara al ciudadano. En este sentido, el proyecto contempla crear los componentes tecnológicos que faciliten la automatización y unificación de la gestión de los trámites y servicios públicos prestados por los organismos de la AP, a fin de profundizar en la implementación del Gobierno Electrónico, todo ello contemplando una arquitectura para el despliegue e integración de aplicaciones y servicios que permita separar el nivel de interacción con el usuario final (aplicaciones de cara al ciudadano, Portal Web), las interfaces de comunicación (servicios institucionales, servicios transversales a la plataforma) y los sistemas de gestión o administración presentes en las instituciones (Sistemas CADIVI, SENIAT, ONIDEX, entre otros), y permita establecer estándares para la escalabilidad de la plataforma (nuevas aplicaciones, nuevos servicios), garantizando la prestación de los servicios con alta disponibilidad y 6 de 31

7 calidad. 2.3 Objetivos Principal El objetivo del presente proyecto es desarrollar e implantar, en software libre y estándares abiertos, una Plataforma de Interoperabilidad Libre Orientada a Servicios para el Estado Venezolano Secundarios Desarrollar e implantar un Sistema de Gestión de Trámites y Servicios que permita unificar el mecanismo de acceso, reduzca o simplifique la actuación del ciudadano en el proceso de gestión de trámites, mantenga el historial de solicitudes realizadas por un ciudadano, permita conocer el estado de una solicitud en particular, y ofrezca otras funcionalidades descritas en mayor detalle en este documento. Implementar una plataforma de interoperabilidad basada en estándares y servicios para el intercambio de información entre las aplicaciones de las instituciones participantes, escalable y de alta disponibilidad, con posibilidades de replicación a través del estado venezolano. Integrar los sistemas de los organismos de la AP participantes en el proyecto. Establecer el concepto de Gobierno Electrónico mediante la implementación de servicios. Crear una visión unificada para la prestación de los servicios por parte del estado venezolano, a través de un portal de acceso para la gestión de trámites y servicios. 2.4 Alcance En este documento se especifican los involucrados y los usuarios principales del sistema, las necesidades de cada uno de ellos y las razones que justifican dichas necesidades. Se plantean las funcionalidades principales que debe cumplir la Plataforma de Interoperabilidad Libre Orientada a Servicios para el Estado Venezolano, en su implementación piloto, la cual consiste en la implantación de un Sistema de Gestión de Trámites y Servicios ante los organismos de la AP. Estos organismos serán seleccionadas a través de una serie de criterios que incluyen grado de automatización, grado de importancia del trámite o servicio, nivel de complejidad del trámite, entre otros. El piloto antes mencionado estará delimitado por los siguientes requerimientos claves: 7 de 31

8 Implantación de un bus de servicios. Desarrollo de una aplicación Web para la interacción entre el público general y los trámites o servicios a ser implementados por las instituciones. Desarrollo de un repositorio de datos del público general (identificación, historial de solicitudes, entre otros). Desarrollo e implantación de los servicios Web que deben proveer los organismos (participantes) asociados a la gestión de los trámites a ser desplegados. Desarrollo e implantación de los servicios Web transversales a la plataforma (autenticación, registro del público en general, consulta de trámites disponibles, servicios de monitoreo e indicadores, etc) Transferencia tecnológica de todos los puntos anteriores. Los puntos antes mencionados serán desarrollados en una visión global del proyecto, el cual tiene como objetivo final la integración de la Administración Pública y la automatización en mayor medida posible de los trámites administrativos de los organismos, siguiendo los estándares de desarrollo e implementación correspondientes para una arquitectura orientada a servicios y proveer una solución escalable que permita la incorporación paulatina de nuevos trámites y servicios. 2.5 Definiciones, Acrónimos y Abreviaturas Todas las definiciones, acrónimos y abreviaturas necesarias para entender este documento están especificadas en el Glosario del Sistema. 2.6 Referencias Título Fecha Organización Identificador del documento GLOSARIO 18/06/2008 GIS GAE-MPPTI-INTGOBE-GLOS 8 de 31

9 3 Metodología Se recomienda una metodología de tipo iterativa e incremental de forma que se contemplen los riesgos en tiempos tempranos del proyecto, se tenga visión del avance en el desarrollo desde las etapas iniciales, se obtenga retroalimentación del usuario lo antes posible, para orientar el desarrollo al cumplimiento de sus necesidades y realizar las adaptaciones identificadas. 4 Requerimientos 4.1 Funcionales ID del Requerimiento: Nombre del Requerimiento: Características: INT-01 Implementar un repositorio de datos (Base de Datos) para la información y transacciones del sistema. El repositorio de datos debe permitir el almacenamiento de: La información personal de los ciudadanos y funcionarios, La información básica de las transacciones realizadas en el bus de servicio, La información de los trámites, Los recaudos de cada trámite, Las fases de cada trámite, Los estados respectivos, Los trámites realizados, Los trámites en curso, Los trámites denegados. El sistema debe poseer un repositorio de datos, en el cual se almacenen todas las transacciones realizadas por el sistema. La prioridad es: Alta ID del Requerimiento: INT-02 9 de 31

10 Nombre del Requerimiento: Características: Crear un Portal de Acceso al Sistema de Gestión de Trámites. El portal debe contemplar lo siguiente: Validar la utilización de un certificado digital por parte del navegador para poder realizar cualquier tipo de trámite, Ofrecer el envío de los certificados digitales por correo al usuario, como a su vez mediante una descarga directa del portal, de manera que éste pueda ser obtenido fácilmente por el ciudadano, Permitir el registro de usuarios, Validar la información del usuario en el repositorio (INT- 01), Validar la información del usuario con el organismo responsable de la información de dicho usuario, Permitir al usuario iniciar sesión una única vez, y poder acceder a los servicios proporcionados. Acceder a la información acerca de los trámites, recaudos asociados,pasos para su realización, flujo de ejecución del trámite, información que se encontrará almacenada en el repositorio (INT-01). Permitir al usuario iniciar el proceso de un trámite desde el portal, Acceder al registro de todos los trámites realizados por los ciudadanos, información que se encontrará almacenada en el repositorio (INT-01), Las operaciones del portal deben estar soportadas por una plataforma de integración con otros sistemas mediante la implementación de servicios Web, Estar desarrollado en función a la integración con otros sistemas, Permitir al usuario el cambio de contraseña, Ofrecer la opción de recordar contraseña. El sistema debe estar representado como un servicio para el Estado, el cual se verá reflejado por un portal en el cual se le permita al usuario registrarse y realizar las diferentes solicitudes de trámites disponibles. Todas las operaciones o funcionalidades disponibles en el portal deberán ser implementadas en forma de servicios (transversales o institucionales), que serán desplegados en el Bus de Servicios (INT-03). La prioridad es: Alta ID del Requerimiento: Nombre del Requerimiento: INT-03 Implementar un Bus de Servicios 10 de 31

11 Características: El bus debe proporcionar: Mecanismos de seguridad y autenticación de los servicios que se integren, Mecanismo para el despliegue, publicación o integración de nuevos servicios Mecanismos de asignación de prioridades o niveles de importancia a los servicios que se integren al bus, Fiabilidad del transporte del mensaje, Recepción y envío de diferentes formatos de mensaje, Transformación de formatos de mensaje entendibles a otros sistemas, Diversos esquemas de comunicación (síncrona, asíncrona) Gestionar un gran volumen de mensajes, Mecanismos para el monitoreo y auditoria del bus, Mecanismos para el monitoreo y auditoria de los servicios integrados al bus, Mecanismos para notificación de alertas, errores, posibles fallas y utilización de logs, Conectividad con otros bus de servicios, Conectividad con cualquier tipo de sistemas, propietarios, libres, sistemas legados, etc. El Bus de Servicios es la capa del sistema que debe manejar de manera eficiente y fiable la comunicación entre el resto de los componentes del sistema. En esta capa se desplegarán todos los servicios que implementarán las distintas funcionalidades del sistema. La prioridad es: Alta ID del Requerimiento: Nombre del Requerimiento: Características: INT-04 Implementar una aplicación que permita el registro y administración de todos los servicios Web, disponibles en el bus de servicios. La aplicación debe proporcionar: Una vista de interfaz gráfica en el cual se puedan visualizar los servicios disponibles. Una interfaz donde se muestre la descripción del servicio Web (Datos de entrada, descripción de la ejecución, datos de salida). Conceptos relaciondos con UDDI (Universal Description, Discovery, and Integration). Proporcionar mecanismos de búsquedas de servicios 11 de 31

12 disponibles. Administración de los servicios (registro, actualización, etc.). La aplicación debe permitir poder visualizar los servicios disponibles en la plataforma de interoperabilidad, a fin de integrar nuevos sistemas, esta información debe estar disponible mediante una aplicación Web para la administración de la plataforma. La prioridad es: Media Alta ID del Requerimiento: Nombre del Requerimiento: Características: INT-05 Implementar una aplicación que permita el seguimiento del comportamiento del servicio en tiempo de ejecución (Monitoreo de los servicios Web). La aplicación debe proporcionar: Que servicios son ejecutados, quién los invocó, datos intercambiados, frecuencia, Cantidad de mensajes, procesados por un servicio al mismo tiempo, Registro de Errores de comportamiento. Metadatos de apoyo, para controlar el ciclo de vida de un servicio. Suministrar información sobre el comportamiento transaccional, timeout, etc; el control de la semántica transaccional de la invocación del servicio. Evaluar el rendimiento. Mecanismos para consulta de los registros (históricos) del comportamiento de los servicios desplegados en la plataforma. De forma general, los requeridos en el INT-04 La aplicación debe permitir poder visualizar el rendimiento y la actividad de los servicios desplegados en la plataforma, esta información debe estar disponible mediante una aplicación Web de administración de la plataforma. La prioridad es: Media Alta ID del Requerimiento: Nombre del Requerimiento: INT-06 Desarrollar los servicios Web de los organismos participantes (específicos de los trámites a implementar) que serán integrados a través del bus de servicios 12 de 31

13 Características: Los servicios desarrollados deben: Ofrecer las funcionalidades correspondientes para proporcionar la información requerida del organismo, Corresponder con la especificación de los servicios Web que realizará para su construcción, Proporcionar mecanismos de alertas ante posibles fallas, y ser enviado mediante correos electrónicos, alertas en un sistemas de monitoreo, SMS, etc, Proporcionar mecanismos de autorecuperación ante una falla, Integrar los servicios a la plataforma. Los servicios Web son las interfaces que permitirán el acceso a los sistemas de los organismos involucrados, debido a esto y por ser el medio de enlace se deben proporcionar con un alto grado disponibilidad, seguridad, etc. El número contemplado de servicios Web a desarrollar es aproximadamente 50 servicios Web en una proporción de 60% complejos (30 servicios Web complejos) y 40% simples (20 servicios Web simples). La prioridad es: Media Alta ID del Requerimiento: Nombre del Requerimiento: Características: INT-07 Desarrollar los servicios Web de los transversales que serán dispuestos en el bus de servicios y permitirán la integración con los servicios Web foráneos pertenecientes a cada organismo participante. Los servicios desarrollados deben: Permitir la búsqueda de los servicios que están desplegados en la plataforma de integración. Permitir identificar los requerimientos(datos,campos requeridos) que posee un servicio específico de un organismo. Realizar las operaciones que sean comunes para todos los servicios que serán desplegados en la plataforma, a fin de reutilizar todas las operaciones. Proporcionar mecanismos de alertas ante posibles fallas, y ser enviado mediante correos electrónicos, alertas en un sistemas de monitoreo, SMS, etc, Proporcionar mecanismos para la auditoria de los servicios ejecutados en la plataforma. Proporcionar mecanismos de autorecuperación ante una falla. 13 de 31

14 Los Servicios Web Transversales son los servicios que deberán ejecutar las funciones que permitirán poder interactuar con los servicios que son desplegados en los organismos participantes en la plataforma, así como también serán los responsables de la auditoria del comportamiento de los servicios que son ejecutados en la plataforma. La prioridad es: Media Alta 4.2 No Funcionales Los requerimientos no funcionales para este proyecto, a fin de especificar más a profundidad van a estar divididos por los requerimientos funcionales mencionados en el apartado anterior: Requerimiento ID = INT-01 (repositorio de datos) Usabilidad: RNF-1.- Los errores de base de datos deben ser manejados por el sistema a fin de no llegar a la vista del usuario. RNF-2.- El nombramiento de los componentes de la base de datos debe corresponder con el estándar definido por el CNTI. RNF-3.- Debe usar palabras nemotécnicas. Confiablidad: RNF-4.- El tiempo máximo de reparación de una falla será de 20 minutos aproximadamente. RNF-5.- El sistema debe estar disponible 24X7X365. En caso de que se requiera mantenimiento, éste deberá ser planificado y se realizará durante las horas de poca concurrencia. RNF-6.- Contar con un sistema de repositorio respaldo, a fin de tener un resguardo de la información del ciudadano. Seguridad RNF-7.- RNF-8.- RNF-9.- El repositorio sólo debe ser accedido mediante el bus de servicios. Se deben especificar nombres de usuario (roles,grupos) de conexión por organismos. La conexión debe realizarse sobre SSL(Secure Sockets Layer-Capa de Conexión Segura). 14 de 31

15 RNF-10.- La información de alta criticidad debe almacenarse cifrada. Eficiencia RNF-11.- El número de conexiones que debe soportar de forma concurrente es de al menos RNF-12.- Poseer la capacidad de ser distribuido (Clustering), debido a la alta demanda. Mantenimiento y Actualización RNF-13.- Las actualizaciones al sistema que cambien el esquema de datos deberán ofrecer métodos de migración de los datos de versiones antiguas. RNF-14.- Las opciones de respaldo deben poder ser generadas automáticamente Requerimiento ID = INT-02 (Portal de Acceso) Usabilidad RNF-15.- El portal debe proporcionar una interfaz gráfica orientada al individuo, que permita al usuario utilizar la herramienta de manera fácil. RNF-16.- El portal debe ofrecer una baja curva de aprendizaje. RNF-17.- Uso de palabras nemotécnicas. RNF-18.- El sistema de poseer páginas preestablecidas para los errores más conocidos (RFC-2616). RNF-19.- El sistema no debe emitir mensajes de errores fatales poco entendibles para el Confiablidad: usuario. RNF-20.- De cada 100 peticiones (request) realizadas, máximo 1 de ellas pueden ser fallas. RNF-21.- El tiempo máximo de reparación de una falla será de 30 minutos aproximadamente. RNF-22.- El sistema debe estar disponible 24X7. En caso de que se requiera mantenimiento, este se realizará durante las horas de poca concurrencia para reducir al mínimo la falta de acceso por parte de usuarios. Seguridad RNF-23.- La clave de acceso al portal debe ser cifrada. RNF-24.- Aplicar SSL(Secure Sockets Layer-Capa de Conexión Segura) para el inicio de sesión. RNF-25.- El acceso a cada uno de los módulos del portal y recursos se debe realizar a través de un único método de ingreso, es decir, se deben resguardar los accesos directos a operaciones. 15 de 31

16 RNF-26.- Validaciones a los formularios del portal, a fin de evitar ataques de inyección SQL. RNF-27.- Utilización de imagen Captcha para la pueba de Turing pública y automática para diferenciar a máquinas y humanos Eficiencia RNF-28.- El número de conexiones que debe soportar de forma concurrente es de al menos RNF-29.- Poseer la capacidad de ser distribuido (Clustering), debido a la alta demanda. Mantenimiento y Actualización RNF-30.- Las actualizaciones al sistema deberán poder realizarse sin afectar los datos. RNF-31.- El mantenimiento y actualización del portal debe ser planificado y debe realizarse en las horas de poca concurrencia o poca demanda del servicio. RNF-32.- En el tiempo de mantenimiento y actualización de la aplicación, se debe proveer una interfaz de mantenimiento en el cual se observe el tiempo para la restauración del servicio Requerimiento ID = INT-03 (Bus de Servicios) Usabilidad RNF-33.- La aplicación Web poseer interfaces amigables para el despliegue de servicios Web. RNF-34.- Las interfaces de la aplicación deben ser intuitivas. RNF-35.- Debe poseer enlaces para la interfaz de monitoreo del estado de los servicios Web. Confiablidad: RNF-36.- El bus de servicios debe estar disponible 24X7. En caso de que se requiera mantenimiento, éste deberá ser planificado y se realizará durante las horas de poca concurrencia para reducir al mínimo la falta de acceso por parte de usuarios. RNF-37.- El bus de servicios debe asegurar la entrega de los mensajes a los servicios conectados al bus. Seguridad RNF-38.- Debe poseer mecanismos de seguridad en el envío de mensajes. RNF-39.- Debe poseer dispositivos físicos y lógicos (firewall, IDS) de red que filtren las conexiones realizadas al bus. RNF-40.- El acceso al bus de servicios debe ser realizado únicamente mediante un servicio Web. 16 de 31

17 RNF-41.- Se deben establecer políticas de seguridad para el despliegue de servicios en el bus. RNF-42.- El bus de servicio debe aplicar medidas de WS-Security para el despliegue de los servicios. RNF-43.- El bus de servicio debe contemplar las políticas definidas por la WS-I en el Basic Profile Security - Perfil de seguridad Básico, definido para la interoperabilidad de servicios Web seguros. Eficiencia RNF-44.- El número de conexiones que debe soportar de forma concurrente es de al menos RNF-45.- Poseer la capacidad de ser distribuido (Clustering), debido a la alta demanda. RNF-46.- El bus de servicios debe proveer mecanismos de conexión a diferentes medios de transporte de mensajería. Mantenimiento y Actualización RNF-47.- Las actualizaciones al bus deberán poder realizarse sin afectar los servicios. RNF-48.- Las opciones de respaldo deben poder ser generadas automáticamente Requerimiento ID = INT-04 (Aplicación del registro de los servicios desplegados en el Bus - Registro de Servicios) Usabilidad RNF-49.- La aplicación debe poder ser accedida vía Web, mediante un portal de administración de la plataforma. Confiabilidad RNF-50.- La información de los servicios debe proveerse desde el bus de servicios. RNF-51.- Fiabilidad de la información mostrada. Eficiencia RNF-52.- Cualquier consulta de servicios, ocurrirá en un tiempo menor de tres (3) milisegundos el 99% de las incidencias. Seguridad 17 de 31

18 RNF-53.- El acceso a la aplicación debe ser provisto por el bus de servicios. RNF-54.- Debe poseer mecanismos de autenticación para los usuarios permitidos. RNF-55.- Utilizar mecanismos de certificados digitales particulares para usuarios permitidos. RNF-56.- El tiempo de la sesión del usuario autenticado no debe ser mayor a 5 min de inactividad. RNF-57.- Todas los accesos realizados deben ser almacenarse para auditoria de lo mismos RNF-58.- Las conexiones a la aplicación deben estar soportadas por una capa SSL(Secure Sockets Layer-Capa de Conexión Segura). Mantenimiento y Actualización RNF-59.- El mantenimiento de la aplicación no debe afectar los registros históricos. RNF-60.- La actualización de la aplicación no debe afectar ningún elemento de la plataforma. RNF-61.- Se deben almacenar todas las transacciones realizadas en la aplicación. RNF-62.- El mantenimiento de la aplicación debe ser programado y proporcionar otros mecanismos de registros del comportamiento de la aplicación Requerimiento ID = INT-05 (Monitoreo de los servios Web) Usabilidad RNF-63.- Para el monitoreo de servicios debe existir una interfaz Web la cual debe ser accedida mediante un módulo de administración del portal. RNF-64.- La interfaz Web, poseer palabras nemotécnicas. RNF-65.- Iconografía adecuada. Eficiencia RNF-66.- Cualquier consulta ocurrirá en un tiempo menor de tres (3) segundos el 99% de las incidencias. RNF-67.- Todas las funcionalidades del monitor de servicios debe ser provistas mediante servicios Web. Seguridad RNF-68.- El acceso a la información de la aplicación debe ser provisto por el bus de servicios. RNF-69.- Debe poseer mecanismos de autenticación de usuarios permitidos. RNF-70.- Utilizar mecanismos de certificados digitales particulares para usuarios permitidos. RNF-71.- Se deben almacenar todas las transacciones realizadas en la aplicación. RNF-72.- El acceso debe realizarse solo por acceso la red interna donde se despliegue la aplicación. 18 de 31

19 Mantenimiento y Actualización RNF-73.- La actualización de los servicios debe realizarse mediante una interfaz administrativa Requerimiento ID = INT-06 (Servicios Web de los organismos) Confiabilidad RNF-74.- Todos los servicios desarrollados deben ser expuesto mediante un bus de servicios propio por organismo, a fin de proveer mayor confiabilidad y eficiencia en el intercambio de mensajes. RNF-75.- Cada servicio debe proporcionar mecanismos de autorecuperación. RNF-76.- Cada servicio debe proporcionar mecanismos de alerta, ante una posible falla. Eficiencia RNF-77.- El tiempo de respuesta máximo por operación será menor a (0.005 seg) 5 milisegundos. RNF-78.- Cada servicio debe mantener sus operaciones por encima del SLA (service level agreement-acuerdo de nivel de servicio) establecido para cada organismo, a fin de garantizar la calidad. RNF-79.- El número de conexiones que debe soportar de forma concurrente es de al menos Seguridad RNF-80.- El acceso a la aplicación debe ser provisto por el bus de servicios RNF-81.- Los datos deben enviarse cifrados o poseer una capa de SSL(Secure Sockets Layer-Capa de Conexión Segura) a nivel físico. RNF-82.- Cada servicio debe proporcionar mecanismos de autenticación, con el bus de servicios Mantenimiento y Actualización RNF-83.- El mantenimiento del servicio debe ser programado. RNF-84.- Las actualizaciones no debe afectar la comunicación con el bus de servicios Requerimiento ID = INT-07 (Servicios Web Transversales) 19 de 31

20 Confiabilidad RNF-85.- Todos los servicios desarrollados deben ser expuesto mediante el bus de servicios descrito anteriormente (INT-003). RNF-86.- Cada servicio debe proporcionar mecanismos de autorecuperación. RNF-87.- Cada servicio debe proporcionar mecanismos de alerta, ante una posible falla. Eficiencia RNF-88.- El tiempo de respuesta máximo por operación será menor a (0.003 seg) 3 milisegundos. RNF-89.- Cada servicio debe mantener sus operaciones por encima del SLA (service level agreement-acuerdo de nivel de servicio) para servicios transversales. RNF-90.- Los servicios transversales que accedan a otros servicios Web, debe proveer mecanismos de cache para mantener la información de acceso y no sobrecargar los métodos de descubrimiento de servicios. RNF-91.- El número de conexiones que debe soportar de forma concurrente es de al menos Seguridad RNF-92.- El acceso a la aplicación debe ser provisto por el bus de servicios descrito anteriormente (INT-003) RNF-93.- Los datos deben enviarse cifrados o poseer una capa de SSL(Secure Sockets Layer-Capa de Conexión Segura) a nivel físico. RNF-94.- Cada servicio debe proporcionar mecanismos de autenticación, con el bus de servicios. Mantenimiento y Actualización RNF-95.- El mantenimiento del servicio debe ser programado. RNF-96.- Las actualizaciones no debe afectar la comunicación con el bus de servicios. RNF-97.- El mantenimiento no debe comprometer la operación de los demás servicios. A continuación se muestran algunos requerimientos no funcionales comunes para todos los requerimientos antes expuestos. 4.3 Seguridad RNF-98.- El sistema debe estar soportado sobre una infraestructura de intercambio de certificados digitales, a fin de aseverar que la información se envía y se recibe por actores autorizados. RNF-99.- La información debe ser enviada cifrada. 20 de 31

21 RNF-100.-Para la integración de nuevos organismos, deben pasar por un proceso de aceptación y acreditación de los permisos necesarios para su integración a la plataforma. 4.4 Soportabilidad y Operabilidad RNF-101.-Está por definirse el lugar de hospedaje del sistema. 4.5 Restricción de Diseño RNF-102.-Se tomará en cuenta que el manejador de base de datos tenga la posibilidad de ser distribuido. RNF-103.-Las aplicaciones Web debe tener una arquitectura de 4 o más capas (Acceso a datos, Modelo de Negocio, Servicios y Vista o más). RNF-104.-El sistema debe tener una Arquitectura Orientada a Servicios, con alta cohesión, bajo acoplamiento, y máxima reutilización. Todas las funcionalidades del sistema deberán ser implementadas en forma de servicios, los cuales serán consumidos desde las distintas capas de la arquitectura (interfaces de usuario, lógica del negocio, entre otras) RNF-105.-Para el desarrollo del sistema se deben seguir convenciones de código internacionalmente aceptadas. RNF-106.-Para el desarrollo de las interfaces del Portal Web se debe permitir, hojas de estilos basada en estándares RNF-107.-Para el desarrollo del sistema se debe maximizar el uso de patrones de diseño. RNF-108.-Para el desarrollo de servicios Web se debe hacer uso estándares definidos por WS-I (Web-Services Interoperability), Basic Profile, Basic Profile Security. RNF-109.-La arquitectura debe garantizar que el sistema sea modular y escalable. 4.6 Requerimientos de Documentación en Línea y de Sistemas de Ayuda RNF-110.-La ayuda en Línea debe ser dinámica y gráfica de modo que permita a todo tipo de usuarios comprender con la mayor facilidad las funciones del portal y de la plataforma. RNF-111.-En los casos de mayor complejidad debe ofrecer demos para la mejor visualización de las operaciones a realizar por el usuario. RNF-112.-Las operaciones criticas de la aplicación deben ofrecer mecanismos de ayuda a discapacitados. 4.7 Interfaces a) Interfaces de Usuario Iconografía adecuada a todos los usuarios. Mantener Imagen del Gobierno Bolivariano usada en los portales del Estado. Uso de pestañas para organizar la información. Usar menús contextuales. 21 de 31

22 b) Interfaces de Software El componente principal del sistema se encuentra en la implementación de un bus de servicios integrador de sistemas, en el cual se desplieguen los servicios Web que interactuarán con los diferentes sistemas. Se requiere que toda operación del sistema sea ejecutado mediante Servicios Web. c) Interfaces de Hardware Se requiere la implantación de un dispositivos de balanceo de cargas para las conexiones con los servidores que soportan el bus de servicios. Se requiere de la implantación de un dispositivos de filtrado de paquetes para el acceso a las funcionalidades permitidas por los diferentes participantes. d) Interfaces de Comunicaciones Se requiere de la implementación de un sistema de comunicaciones que proporcione altos niveles de transacciones, que soporten anchos de banda superiores a 1Gbps para la integración de los sistemas, conexiones en fibra óptica, etc. 4.8 Aspectos Legales a) Políticas de la Organización Todos los productos de software deben dar cumplimiento a los postulados establecidos en el Decreto N 3.390, en el que se establece el uso prioritario de software libre y estándares abiertos en los organismos de la administración pública nacional. El CNTI realizará seguimiento del avance del proyecto. Los pagos se realizarán de acuerdo a la conformidad con los entregables del proyecto. El producto debe tener mínimo 120 días de garantía luego de su entrega final. Se debe garantizar las pruebas funcionales y técnicas del Sistema. Se debe garantizar el soporte post_instalación del sistema Se debe garantizar la correcta transferencia tecnológica a las unidades productivas venezolanas seleccionadas. Se debe garantizar los aspectos contenidos en este documento y el documento de especificación de requerimientos. b) Propiedad Intelectual La propiedad intelectual corresponde al CNTI. 4.9 Estándares Aplicables Accesibilidad: Web Content Accessibility Guidelines (WCAG). Contenido Web: XHTML Strict. Presentación Web: CSS Codificación de caracteres: Unicode (UTF-8). 22 de 31

23 Interoperabilidad de Servicios Web: Web Services Interoperability Organization (WS-I), WS- Stack de la W3C. Estándar para definir coreografías de servicios: WS-CDL Estandares basados en lenguajes XML (XSL, XFORM) Requerimientos de transferencia tecnológica La empresa contratista en su oferta debe presentar un plan para la transferencia tecnológica y capacitación al personal técnico que el CNTI designe que abarque todos los aspectos técnicos inherentes al desarrollo de Plataforma de Interoperabilidad Libre Orientada a Servicios para el Estado Venezolano, tomando en cuenta los siguientes elementos: 1.- Entregar el plan de capacitación, reflejando todos los cursos a efectuarse por el proveedor. 2.- Proporcionar el contenido programático de cada taller o curso, proporcionando los siguientes datos: índice del contenido por módulos, la duración de cada módulo, perfil del participante, objetivos a alcanzar, descripción, requerimiento técnico para su puesta en marcha y cualquier otro aspecto que incida en la ejecución óptima del proceso. (Debe entregarse al inicio de cada curso). 3.- Entregar los materiales didácticos a ser usados para impartir el conocimiento a los usuarios, bien sean manuales para instructores, contenidos digitales, guías rápidas de solución de problemas presentaciones usadas para la capacitación, videos tutoriales, entre otros (deben ser entregados antes de comenzar la capacitación a efecto de ser evaluados por el CNTI). 4.- Entregar los instrumentos de evaluación a ser usados para medir el conocimiento transferido por cada participante al final de cada curso (deben ser entregados antes de comenzar la capacitación a efecto de ser evaluados por el CNTI). 5.- Los materiales didácticos deben ser entregados de manera digital e impresa, luego de haber sido revisados y aprobados por la gerencia de capacitación tecnológica. 6.- Los contenidos que se encuentren en toda la documentación, deben ser desarrollado en la lengua nativa del país (español) y regionalizadas aquellas palabras que no formen parte del argot cotidiano utilizado en Venezuela. 23 de 31

24 7.- Deberán proveer el espacio con todas las condiciones propicias para ser usado como laboratorio de capacitación y transferencia tecnológica. 8.- El proveedor estará encargado de la logística de las salas para las distintas capacitaciones y transferencias tecnológicas que deben llevarse a cabo. 5 Descripciones de los Involucrados y Usuarios 5.1 Perfil de Involucrados Representantes de los distintos organismos de la APN. Rol o involucrado Analista del Organismo o Institución Descripción Tipo Responsabilidades quecriterio de Éxito Grado de participación Entregables Comentarios Representante del Organismo o Institución a interactuar Usuario interno del sistema. Encargado de interactuar con el sistema en términos funcionales específicos de cada organismo, que serán expuesto por medio de servicios Web que estarán publicados en la plataforma de servicios. Además, es responsable de dar seguimiento a las incidencias que pueda presentar el sistema en alguna eventualidad. Contar con un sistema que le permita integrarse con el resto de los organismos del estado a fin de poder intercambiar información entre los mismos. Formulación de requerimientos funcionales en detalle. Seguimiento del proyecto. Acta de conformidad de los entregables definidos para las instituciones, asignación de responsabilidades funcionales. Ninguno Representantes del CNTI Rol o involucrado Analista de Plataforma Tecnológica Descripción Representante de la Gerencia General de Plataforma Tecnológica Tipo Experto en determinar la plataforma tecnológica. Responsabilidades Debe realizar la evaluación de los aspectos técnicos de plataforma definidos para el proyecto, como a su vez en la norma técnica. Criterio de Éxito Que el proyecto sea llevado a feliz término, dando cumplimiento a los requerimientos técnicos exigidos para el proyecto. Grado de participación Participación en el seguimiento y control del proyecto. 24 de 31

25 Entregables Comentarios Diseño general de la plataforma, acta de conformidad sobre la plataforma instalada Ninguno Rol o involucrado Descripción Tipo Responsabilidades Criterio de Éxito Grado de participación Entregables Comentarios Analista de Atención al Estado Representante de la Gerencia General de Atención al Estado del CNTI Experto en la identificación de necesidades presentes en la AP. Debe realizar seguimiento del proyecto macro, de la ejecución del mismo y la elaboración de los términos de referencia.. Que el proyecto sea llevado a feliz término, siguiendo el plan de ejecución elaborado para el desarrollo. Participación en la formulación de los términos de referencia, identificación de requerimientos, en el seguimiento y control del proyecto Acta de conformidad sobre los entregables del proyecto. Cliente de cara al CNTI. Rol o involucrado Descripción Tipo Responsabilidades Criterio de Éxito Grado de participación Entregables Comentarios Especialista de Normalización y Certificación. Representante de la Gerencia General de Normalización y Certificación Experto en normalización y certificación de estándares. Debe realizar la verificación del cumplimiento de la norma técnica definida para el proyecto. Que el proyecto sea llevado a feliz término, dando cumplimiento a los criterios establecidos en la norma. Participación en el seguimiento y control del proyecto. Acta de conformidad sobre el cumplimiento de la norma técnica en el desarrollo plataforma. Ninguno Rol o involucrado Descripción Tipo Responsabilidades Criterio de Éxito Grado de participación Entregables Comentarios Especialista de Capacitación y transferencia tecnológica Representante de la Gerencia General de Capacitación Tecnológica Experto en Capacitación y transferencia tecnológica de proyectos. Debe verificar el cumplimiento de la transferencia tecnológica del proyecto Que el proyecto sea llevado a feliz término, realizando la transferencia tecnológica y capacitación. Participación en el seguimiento y control del proyecto. Acta de conformidad de los entregables de la transferencia. Ninguno 25 de 31

26 Rol o involucrado Descripción Tipo Responsabilidades Criterio de Éxito Grado de participación Entregables Comentarios Arquitecto de Software Representante de la Gerencia General de Ingeniería de Software del CNTI Experto en aplicación de metodologías de desarrollo, en particular en los aspectos asociados a la arquitectura del sistema. Se encarga de la definición de la arquitectura que guiará el desarrollo, y de la continua refinación de la misma en cada iteración; debe apoyar a la Gerencia del Proyecto en la identificación de aspectos riesgosos desde el punto de vista técnico del proyecto; definirá los lineamientos generales del diseño y la implementación. Contar con un sistema efectivo desarrollado de acuerdo con la metodología establecida, que se adapte a los requerimientos del ambiente de implementación. Conduce y coordina las actividades y los artefactos técnicos a través del proyecto, prioriza los casos de uso, identifica elementos y mecanismos de diseño. Documentos: Visión, Glosario, Modelados y Análisis de Casos de Usos, Documento de Arquitectura de Software, Modelado del Negocio, Modelo de Domino, Modelo de Implementación. Ninguno Rol o involucrado Descripción Tipo Responsabilidades Criterio de Éxito Grado de participación Entregables Comentarios Analista de Pruebas Representante de la Gerencia General de Ingeniería de Software del CNTI Experto en la aplicación de pruebas Identificar la implementación más apropiada para una prueba efectuada, formular casos de prueba de acuerdo a los casos de uso definidos, probar los componentes según los casos de prueba y los subsistemas correspondientes, implementar pruebas individuales. Análisis de los resultados. Retroalimentación hacia los desarrolladores a fin de corregir las fallas encontradas. Que el sistema desarrollado responda adecuadamente al plan de pruebas establecidos (calidad del sistema). Generación de los scripts de prueba, formulación de los casos de prueba. Informes. Plan de Pruebas, Casos de prueba, Scripts de Prueba, Suite de Prueba, Evaluación de los Resultados de las Pruebas. Ninguno 26 de 31

27 Rol o involucrado Descripción Tipo Responsabilidades Criterio de Éxito Grado de participación Entregables Comentarios Gerente de Proyecto Representante del CNTI. Experto en el seguimiento y control de Proyectos de Software. Encargado del proyecto y de la asignación de recursos, establece prioridades y los tiempos que tendrá cada actividad, coordina interacciones con los clientes y los usuarios, y generalmente mantiene al equipo de proyecto centrado en el objetivo correcto. Además, asegura la integridad y la calidad de los artefactos del proyecto. Que el sistema desarrollado cumpla los requerimientos funcionales y no funcionales definidos, desarrollado de acuerdo a la metodología establecida, cumpliendo los tiempos y el presupuesto establecido. Gerencia el plan de elicitación de requerimientos, de desarrollo, implementación, establece las métricas de calidad, coordina el plan de trabajo y el cumplimiento de los tiempos. Documentos: Visión, Glosario, Modelados y Análisis de Casos de Usos, Modelado del Negocio, Gestión de Requerimientos, Modelo de Domino, modelo de implementación, Lista de Riesgos, Plan de Administración de Riesgos, Plan de Aceptación de Productos, Plan para la Resolución de Problemas, Plan de Trabajo (Plan Director). Ninguno Representantes del Proveedor de la Solución (Requeridos) Rol o involucrado Descripción Tipo Responsabilidades Criterio de Éxito Grado de participación Entregables Arquitecto de Software Representante del Proveedor de la Solución. Experto en aplicación de metodologías de desarrollo, en particular en los aspectos asociados a la arquitectura del sistema. Se encarga de la definición de la arquitectura que guiará el desarrollo, y de la continua refinación de la misma en cada iteración; debe apoyar a la Gerencia del Proyecto en la identificación de aspectos riesgosos desde el punto de vista técnico del proyecto; definirá los lineamientos generales del diseño y la implementación. Contar con un sistema efectivo desarrollado de acuerdo con la metodología establecida, que se adapte a los requerimientos del ambiente de implementación. Conduce y coordina las actividades y los artefactos técnicos a través del proyecto, prioriza los casos de uso, identifica elementos y mecanismos de diseño. Documentos: Visión, Glosario, Modelados y Análisis de Casos de Usos, 27 de 31

28 Comentarios Documento de Arquitectura de Software, Modelado del Negocio, Modelo de Domino, Modelo de Implementación, etc. Vease punto 9 del presente documento. Ninguno Rol o involucrado Descripción Tipo Responsabilidades Criterio de Éxito Grado de participación Entregables Comentarios Desarrollador Representante del Proveedor de la Solución. Experto en desarrollo de soluciones de software. Tiene a su cargo el diseño y codificación de los componentes en código fuente en algún lenguaje de programación; debe elaborar y ejecutar las pruebas unitarias realizadas sobre el código desarrollado; es responsable de las clases que ha desarrollado debiendo documentarlas, actualizarlas ante cambios y mantenerlas bajo el control de configuración de las mismas mediante la herramienta utilizada. Desarrollo del sistema de acuerdo a la metodología establecida, con los criterios de calidad especificados y en los lapsos de tiempo establecidos. Generación del código fuente y casos de pruebas. Código del Sistema, Elementos de Implementación, Plan de Integración, Documento de Arquitectura del Software (Modelo de Implementación), Plan de Pruebas, Casos de prueba, Scripts de Prueba, Suite de Prueba, Evaluación de los Resultados de las Pruebas, Plan de Implantación, Documento del Arquitectura de Software (Modelo de Implantación), Material de Soporte al Usuario, Notas de Release, Unidad de Implantación, Material de Adiestramiento. Ninguno Rol o involucrado Descripción Tipo Responsabilidades Criterio de Éxito Integrador Representante del Proveedor de la Solución. Experto en el desarrollo de soluciones de software que es integrable con otros sistemas y orientado a servicios Se encarga de verificar que la arquitectura que guiará el desarrollo contemple características de integración y de ser orientada servicios, y de la continua refinación de la misma en cada iteración; debe apoyar a la Gerencia del Proyecto en la identificación de aspectos riesgosos desde el punto de vista técnico del proyecto en el ámbito de la integración de las soluciones; definirá los lineamientos generales del diseño y la implementación. Desarrollo del sistema de acuerdo a la metodología establecida, que garantize la interoperabilidad con otros sistemas, con los criterios de calidad especificados y en los lapsos de tiempo establecidos. 28 de 31

29 Grado de participación Entregables Comentarios Generación de las configuraciones del software para la integración y casos de pruebas, pruebas de carga y estrés de los servicios. Código del Sistema, Elementos de Implementación, Plan de Integración, Documento de Arquitectura del Software (Modelo de Implementación), Plan de Pruebas, Casos de prueba, Scripts de Prueba, Suite de Prueba, Evaluación de los Resultados de las Pruebas, Plan de Implantación, Documento del Arquitectura de Software (Modelo de Implantación), Material de Soporte al Usuario, Notas de Release, Unidad de Implantación, Material de Adiestramiento. Ninguno 5.2 Perfil de Usuario Administrador de Sistema Rol o involucrado Administrador del Sistema Descripción Administra la parametrización de los módulos, los servicios Web, Tipo Super usuario del sistema. Responsabilidades Persona que estará encargada de administrar, monitorear toda la aplicación. Criterio de Éxito Sistema que incluya uno o más módulos que permitan administrar en conjunto todas las funcionalidades solicitadas por los usuarios finales. Grado de participación Administración del sistema. Entregables Informes de conformidad o satisfacción. Comentarios Ninguno Administrador de Servicios por Organismo Rol o involucrado Descripción Tipo Responsabilidades Criterio de Éxito Grado de participación Entregables Administrador del Sistema del organismo participante. Administra la parametrización de los módulos, y los servicios Web que son desplegados en el organismo. Usuario administrador del sistema local Persona que estará encargada de administrar, monitorear los servicios de los organismo Sistema que incluya uno o más módulos que permitan administrar en conjunto todas las funcionalidades para poder realizar el despliegue de los servicios propios del organismo. Administración del sistema. Informes de conformidad o satisfacción. Comentarios Ninguno 29 de 31

30 5.2.3 Ciudadano/Empresario (Usuarios finales) Rol o involucrado Usuarios finales del sistema, que accederán a través de la interfaz Web las funcionalidades del sistema para la gestión de los tramites administrativos. Descripción Ciudadano o empresario que inicia la gestión de un trámite administrativo. Tipo Responsabilidades Criterio de Éxito Grado de participación Entregables Comentarios Usuario de la aplicación. Persona que estará encargada de almacenar, modificar, consultar la información referente a los trámites que se realizan en el organismo desde el cual se accede al sistema. Sistema que implemente de manera eficaz todas las funcionalidades o requerimientos solicitados de acuerdo a sus responsabilidades. Utiliza las funcionalidades del sistema y será capaz de realizar cambio a alto nivel en caso de ser necesario. Ninguno Ninguno 6 Alternativas y Sistemas Similares Actualmente en el mercado existen varias alternativas en el área de software para los componentes principales de la plataforma, entre las cuales tenemos: Bus de Servicios (MuleESB, OpenESB,ServiceMix, entre otros). Repositorio de datos (PostgreSQL,MySQL, entre otros). Portales Web, Manejadores de Contenidos (Alfresco, Liferay,etc) Mensajería de datos (JMS,SOAP,etc). 7 Rangos de Calidad 7.1 Calidad en el Producto La principal garantía de calidad exigida por el CNTI sobre el sistema a desarrollar es el cumplimiento de este documento, el mismo describe las prioridades del CNTI en cuanto a calidad; sin embargo, todos los entregables y el producto serán probados por la Oficina de Control y Calidad de Sistemas. Se validará que la plataforma opere eficientemente, que sea flexible e interoperable (el que sea 30 de 31