Guía de Estándares. Informática del Ayuntamiento de Madrid

Tamaño: px
Comenzar la demostración a partir de la página:

Download "Guía de Estándares. Informática del Ayuntamiento de Madrid"

Transcripción

1 Guía de Estándares Informática del Ayuntamiento de Madrid 1

2 Contenido 1 Introducción Entornos Entorno de Servidores Entorno estándar Otros entornos Entorno de Puesto de Trabajo Herramientas de Soporte Entorno Metodológico Actividades comunes a todos los proyectos Pasos previos Reunión de inicio Identificación de Proyectos y Subsistemas Documentación de Gestión Planificación Elaborar plan de proyecto Creación de la Línea Base del proyecto estándar Solicitud de la Auditoría de planificación Ejecución y Seguimiento del Proyecto Actualización del Progreso de las Actividades Criterios de Entrega Entregables Criterios generales de Entregas al IAM Entregas Informales Estructura genérica Generación de etiquetas Política de Versionado Política de certificados Certificados admitidos Organización de los certificados 21 2

3 3.7.3 Obtención de Certificados Especificidades para las aplicaciones web Especificidades para Servicios Web 24 4 Proyectos de Desarrollo Estructura Carpeta Fuentes Carpeta Documentación Carpeta Despliegues Fase ASI Maqueta Interfaz de Servicios Web Documento / Modelo de Requisitos Planes de Pruebas Opcionales Fase DSI Diseño Arquitectura Lógica Modelo de Diseño Modelo de Datos Fase CSI Estrategia de Desarrollo Normas de codificación Construcción del Proyecto Casos de Prueba (fase de Construcción) Manual de Usuario Fase IAS Entornos Peticiones de despliegue Verificación de la instalación 64 5 Proyectos de Mantenimiento de Aplicaciones Introducción

4 5.1.1 Estructura y versionado Fases de los proyectos de Mantenimiento Gestión de Peticiones e Incidencias Documentación de Cambios y Requisitos de Calidad Proyectos de Prestación de Servicio Introducción Estructura y versionado Diseño del Servicio Descripción del servicio Formulario del servicio Procedimiento interno del Servicio Prestación del servicio Gestión de incidencias Informe de seguimiento 73 7 Proyectos no tipificados Solicitud de Cierre Plantillas Anexos

5 Tablas e Ilustraciones Ilustración 1. Ejemplo etiquetas incrementales Ilustración 2. Descripción almacenes de certificados por entorno Ilustración 3. Estructura de Carpetas con Subsistemas Ilustración 4. Estructura de la Carpeta Despliegues Ilustración 5. Modelo RSA de Análisis Ilustración 6. Arquitectura Lógica Corporativa Ilustración 7. Plantilla de diagrama de arquitectura Ilustración 8. Integración entre Aplicaciones y Componentes Comunes Ilustración 9. Estructura RSA de diseño Ilustración 10. Peticiones de Despliegue Ilustración 11. Estructura de Subversion Proyecto Servicios Tabla 1. Plantillas Genéricas Tabla 2. Nomenclatura de versionado Tabla 3. Localización de los módulos Tabla 4. Estructura interna de los módulos Tabla 5. Localización de los fuentes dentro de cada módulo Tabla 6. Plantillas de Entregables de Desarrollo de Software Tabla 7. Plantillas de Entregables de Despliegue Tabla 8. Plantilla Casos de Uso Tabla 9. Arquitectura en alta disponibilidad Tabla 10. Componentes Comunes Tabla 11. Caso de prueba en fase de construcción Tabla 12. Plantillas de Gestión de Servicios Tabla 13. Plantillas

6 Tabla 14. Anexos

7 1 Introducción El presente documento tiene por objeto describir los estándares, herramientas y metodologías que rigen los servicios y desarrollos TIC prestados por las empresas adjudicatarias de contratos en el Organismo Autónomo Informática del Ayuntamiento de Madrid (en adelante, IAM). Esta guía y todos sus anexos se encuentran publicados en en la sección Perfil del contratante El responsable del contenido de este documento es el Comité de Estándares del IAM. Cualquier sugerencia o duda, petición de reunión, reporte de incompatibilidad del proyecto con las directrices corporativas, o petición de adaptación a casos concretos de los estándares definidos en este documento podrá dirigirse al buzón corporativo XXXXX El presente documento establece unos entregables mínimos y uso común de herramientas, estando permitidos cuantos entregables y actividades adicionales se consideren oportunos desde la jefatura de cada proyecto. 7

8 2 Entornos A continuación se describe la infraestructura tecnológica y metodológica sobre la que se construyen los Servicios TIC del Organismo. 2.1 Entorno de Servidores Entorno estándar La plataforma tecnológica estándar para el desarrollo de sistemas de información para el Ayuntamiento de Madrid es la siguiente: Sistema Operativo Windows Server 2003 R2 SP2 Red Hat Enterprise Linux V5.4 Las plataformas hardware están basadas en tecnología Intel x Servidores Sistemas Abiertos Servidor Web (entorno Linux): o IBM IHS (S.O. Red Hat Enterprise Linux V5.4) Servidor de Aplicaciones (entorno Windows): o IBM Websphere Application Server Network Deployment V en un entorno cluster JRE IBM en Windows Server 2003 J2EE 1.4 o IBM Websphere Application Server Network Deployment V en un entorno cluster. JRE IBM en Windows Server 2003 Java EE 6 En la reunión de inicio indicada en el punto 3.2, y dependiendo del tipo de proyecto se decidirá si el proyecto se desarrolla en una versión u otra. Gestor de Bases de Datos: 8

9 o Microsoft SQL Server 2005 SP2 (Excepcionalmente, previa autorización del comité de estándares, y en caso de necesitar usarse Oracle, se utilizará la versión ) Gestor de contenidos y portal: o Vignette V7 Archivo electrónico y documental: o Documentum. 6.5 SP2 (incluyendo Content Server, Index Server y ADTS y Captiva). El acceso a esta plataforma por parte de los proyectos de desarrollo se realizará a través del Componente Común de Archivo Electrónico. Gestor de Procesos de Negocio (BPM): o TIBCO iprocess Engine Workflow: creación, orquestación e integración de servicios o TIBCO. BussinessWorks Securización: o TIBCO Bussiness Works / Policy Manager Firma y validación. o SIAVAL El acceso a esta plataforma por parte de los proyectos de desarrollo se realizará a través del Componente Común de Firma. Entorno SIG o Servidor de servicios de mapas: ArcIMS y ArcGis Server de ESRI o Servidor de geodatabases: ArcSDE o Servidor de ortofotos: ERDAS v10 o Para el uso de esta plataforma se tendrá en cuenta el uso de los servicios ya publicados en el SIG corporativo SIGMA. Entorno Formularios o Adobe LiveCycle v8 9

10 2.1.2 Otros entornos Los desarrollos realizados sobre entornos distintos al descrito en el punto anterior deberán ser presentados al Comité de Estándares para su autorización. Ejemplos de esta casuística son las aplicaciones desarrolladas sobre iseries, zseries, o cualquier aplicación que sea necesario mantener y haya sido ya desarrollada con otras directrices distintas a las estándar. 2.2 Entorno de Puesto de Trabajo Los desarrollos, servicios o herramientas realizados en el IAM, deberán tener en cuenta las limitaciones impuestas en los puestos clientes, y en el software (por ejemplo, los navegadores autorizados, versiones de productos de ofimática, etcétera) estandarizados para los mismos. El detalle del software y las características técnicas del puesto pueden consultarse en el Anexo 1. Puesto de trabajo a este documento. Para el caso de proyectos de desarrollo, el citado anexo describe tipo de puesto de trabajo mínimo requerido para utilizar las herramientas de desarrollo. Se utiliza Microsoft System Center Configuration Manager (SCCM) como solución de administración de equipos en red, incluyendo el inventario, despliegue automático y control remoto de equipos. 2.3 Herramientas de Soporte Se definen las siguientes herramientas para apoyar las distintas actividades llevadas a cabo en IAM, incluyendo proyectos ejecutados en las instalaciones de adjudicatarios de proyectos TIC del Ayuntamiento de Madrid: Se utiliza la herramienta de gestión de proyectos CA Clarity para realizar las tareas relacionadas con la gestión de proyectos (planificación, seguimientos, gestión de riesgos, etc.). Se define Remedy 7 como herramienta de soporte a la Gestión de servicios, que incluye incidencias, peticiones de servicio, y demás aspectos de gestión de servicios. Rational Software Architect (de IBM) v8 soporta la realización de modelados UML de despliegues, casos de uso, análisis, y diseños, así como la codificación y el empaquetado de aplicaciones. Será necesario tener incluido en el RSA de forma local las versiones corporativas del servidor de aplicaciones WAS indicadas anteriormente. Herramientas de pruebas de HP Mercury: o LoadRunner 9.51 o Quality Center 10 o WebInspect 8.10 o QAInspect

11 Familia de herramientas TAW3 para comprobar accesibilidad de la interfaz de usuario. Herramientas de validación de (X) HTML de W3C (Markup Validation Service). Gestor de Reporting (generación de PDFs, documentos Word, informes, etcétera) o Se usarán las librerías (no se usará la versión de servidor) que proporciona JasperReports para impresión de documentos online, en su versión o Isis Papyrus 6.20 cuando el volumen de impresión dentro del aplicativo es elevado o el número de plantillas aconseja un gestor de otro tipo, así como para el tratamiento off-line (batch). En este caso, su utilización ser validada previamente por el Comité de Estándares. Maven 3.0.4, para la construcción de aplicaciones. Subversion como gestor de versiones. o TortoiseSVN como software de acceso al repositorio desde el explorador de archivos. 2.4 Entorno Metodológico Para los aspectos no definidos en el presente documento, en lo referente a metodología, se tomarán como referencia los siguientes marcos de trabajo: Prácticas y recomendaciones de Project Management Body of Knowledge (PMBOK). En el ámbito de la gestión de proyectos IAM, se ha realizado una personalización de dichas prácticas, y se han definido roles y procesos específicos para IAM. METRICA3 y Rational Unified Process (RUP), para los aspectos o entregables adicionales a los señalados en la presente guía. Mejores prácticas ITIL, para las actividades de gestión de servicio y puesta en marcha de nuevos servicios. A nivel metodológico, los equipos de desarrollo podrán añadir cualquier práctica o técnica contemplada en cualquiera de estos marcos de trabajo, siempre y cuando no entre en conflicto con los mínimos establecidos en la presente guía. 11

12 3 Actividades comunes a todos los proyectos La gestión de proyectos se apoya en la herramienta corporativa Clarity. Como complemento a este documento se proporciona en el Anexo 2. Manual de Usuario del Gestor de proyectos para la Gestión en Clarity, que describe en detalle cómo realizar las distintas tareas descritas en las siguientes secciones. 3.1 Pasos previos Todo Proyecto IAM debe seguir una fase previa de propuesta y autorización, que realizará el responsable IAM del mismo. Las tareas a realizar se describen en el documento (sólo accesible para personal interno del IAM) Coordinación Interna. El personal subcontratado deberá contactar con el Responsable de Proyecto IAM para consultar las fechas estimadas de inicio de proyecto. Una vez finalizados los pasos previos, el proyecto quedará habilitado en Clarity, disponible para el equipo de trabajo, y se seguirán las fases descritas a continuación 3.2 Reunión de inicio Independientemente del tipo de servicio o proyecto a llevar a cabo, el primer paso es la reunión de inicio del proyecto, que deberá solicitar el Jefe de Proyecto del IAM y que requerirá la asistencia mínima de: - Jefe de Proyecto IAM - Representante de la Unidad de Calidad del IAM - Representante de Sistemas IAM - Jefe de Proyecto de la Empresa adjudicataria (en caso de que sea un proyecto subcontratado) - Colaboradores otras Subdirecciones (en caso de ser necesarios) - Recomendado un representante del peticionario (en caso de ser proyectos demandados por Unidades de Negocio del Ayuntamiento: coordinador, usuario final ) En esta reunión se acordará qué tipo de proyecto es el que corresponde al proyecto que arranca. Los proyectos se clasificarán en una de las siguientes categorías: 12

13 - Proyectos de Desarrollo: Son los proyectos en los que se realizan todas las fases del ciclo de vida del software desde cero. Tienen por objeto crear aplicaciones nuevas o realizar modificaciones mayores de las existentes. - Proyectos de Mantenimiento de Aplicaciones: Son los proyectos que tienen por objeto gestionar las peticiones de cambio e incidencias, así como planificar las nuevas versiones menores de los aplicativos que ya se encuentren en producción. - Proyectos de Prestación de Servicio: Son los proyectos en los que se contrata a una empresa para que preste un servicio periódico al IAM. - Proyectos no tipificados: Cualquier tipo de proyecto que no cumpla ninguno de los criterios anteriores. En esta reunión, se definirá: - Criterios de calidad a aplicar: Entregables mínimos a realizar, dependientes del tipo de proyecto y descritos en la presente guía. - Características del proyecto: Servidor de aplicaciones, uso de componentes comunes, necesidad de pruebas, - Acrónimo del proyecto: Combinación de cinco letras que servirá para la identificación del proyecto dentro del IAM. - Otras consideraciones. Otras características especificas por proyecto. Al finalizar la reunión la Unidad de Calidad proporcionará a los asistentes a la reunión la documentación con los criterios definidos para el proyecto. La documentación aportada por la Unidad de Calidad comprende: - Acta de reunión: donde se indicará la fecha de inicio, los asistentes, los temas tratados, - Informe de la Unidad de Calidad: documento personalizado para el proyecto en cuestión donde se resumen los chequeos que se realizarán sobre cada uno de los entregables del proyecto. Estos chequeos serán de obligado cumplimiento. - Acuerdos: documento con la descripción de entregables que aplican al proyecto, componentes comunes que serán utilizados, etcétera Identificación de Proyectos y Subsistemas En algunos casos, se deberá realizar un análisis del proyecto para determinar si éste contendrá subsistemas. Podrán existir subsistemas en un proyecto cuando se prevean partes independientes desde el punto de vista de su despliegue 13

14 (generarán más de un ear en el aplicativo, un ear y un jar, ), pero que compartan código: permite organizar proyectos, de cierta complejidad, en módulos, entregables en forma individualizada, lo que permite avanzar a diferente ritmo las partes de un proyecto y que estas partes sigan el ciclo de vida a distinto ritmo. Un ejemplo de subsistemas son aplicaciones que desarrollan una parte Internet y otra Intranet. Normalmente, este tipo de proyectos tienen una o varias partes de negocio común, y parte de presentación diferente. Esto en código se traduce como una capa de presentación diferenciada (dos módulos WEB uno para la parte Internet y otro para la parte Intranet), uno o varios módulos de Negocio (NEG, EJb, ) que pueden o no estar incluidos en ambos, y uno o varios módulos de acceso a Datos (DAO, ) que pueden o no estar incluidos en ambos productos finales. La característica más importante que hace que Internet sea un subsistema, e Intranet sea otro subsistema es que tienen ciclos de vida diferenciados. Podemos desplegar y evolucionar la parte Intranet, sin tocar la parte Internet y viceversa. Este es un ejemplo, pero se nos pueden dar más casos de este tipo con otro tipo de aplicaciones, Web services, batch, 3.3 Documentación de Gestión La lista de entregables que muestra la siguiente tabla se deben almacenar en el gestor documental de Clarity de cada proyecto. Las plantillas están disponibles en el repositorio de publicación, en la carpeta Plantillas, junto con este documento. FASE Entregable Localización (En cualquier fase) Plantilla 1.Plantilla Genérica Repositorio Clarity. Carpeta raíz. (En cualquier fase) Plantilla 2. Acta de Reunión Repositorio de proyecto Clarity. Ruta: /actas Tabla 1. Plantillas Genéricas No deberá almacenarse información de gestión de proyectos fuera del gestor documental de Clarity, entendiendo como información de gestión aquella que no debe ser actualizada una vez que termine el proyecto en las sucesivas iteraciones, como por ejemplo un plan de proyecto, o un pliego ya finalizado. Dado que los seguimientos, gestión de riesgos y planificaciones se realizan directamente sobre la herramienta, no es necesario ubicar documentación de este tipo en Clarity. No obstante, a criterio del jefe de proyecto, se podrá ubicar en Clarity cualquier documentación adicional de gestión, como informes adicionales de seguimiento, acuerdos, etcétera. 14

15 3.4 Planificación Elaborar plan de proyecto Dependiendo del nivel de intervención del adjudicatario, el responsable IAM asignará al mismo, a través de la herramienta Clarity, los proyectos completos o fases de proyectos necesarios. Los adjudicatarios serán los encargados de crear y actualizar las planificaciones que les atañen en dicha herramienta. Para ello, el adjudicatario deberá elaborar un plan de trabajo que incluya la descomposición en tareas del proyecto, su secuencia y programación en el tiempo, así como los recursos asignados a cada una de ellas. Como elemento de ayuda, los proyectos en Clarity son creados utilizando una de las plantillas existentes que aportan al proyecto una serie de tareas predefinidas para cada tipo de proyecto definido en el punto 3.2 de la presente guía. Si el proyecto no se corresponde con ninguna tipología definida, no se usará este elemento de ayuda. El plan de trabajo puede ser creado utilizando el propio planificador de Clarity o bien utilizando un planificador externo (Ms Project) integrado con Clarity. Ambos métodos se describen en detalle en los documentos Anexo 2. Manual de Usuario del Gestor de proyectos para la Gestión en Clarity y Anexo 13. Uso Ms Project en planificación del gestor de proyecto.doc Creación de la Línea Base del proyecto estándar La línea base activa es la foto del cronograma inicial que se utiliza como referencia para evaluar el progreso del proyecto y para poder detectar desviaciones en plazo con respecto a lo inicialmente previsto. Se deberá crear una línea base una vez aprobada la planificación, antes de comenzar la ejecución. Para más información consultar el Anexo 2. Manual de Usuario del Gestor de proyectos para la Gestión en Clarity Solicitud de la Auditoría de planificación La auditoría de planificación se solicita cuando se ha lanzado la línea base y antes de empezar a ejecutar el proyecto. La auditoría de planificación se realiza sobre el proyecto estándar. En caso de que sea un proyecto estándar coordinador que contiene subproyecto, la auditoría de planificación se realizará sobre el proyecto coordinador sólo si tiene tareas propias y siempre sobre cada subproyecto asociado. 15

16 Esta auditoría debe ser solicitada por el Gestor interno o por los gestores de los subproyectos con copia del gestor coordinador por correo al departamento de Calidad XXXXX. 3.5 Ejecución y Seguimiento del Proyecto Cualquiera que sea el tipo de proyecto, se deberá actualizar su progreso en Clarity. El seguimiento del proyecto deberá realizarse con la periodicidad que especifique el responsable IAM del proyecto 1 o bajo demanda del Comité de Dirección. En este último caso, la Unidad de Apoyo enviará una notificación solicitando la actualización del estado de los proyecto. La unidad de Calidad realizará una revisión de que se está actualizando el seguimiento del proyecto cada vez que se realice una entrega de cualquier otra documentación y haya pasado más de un mes desde la última auditoría de seguimiento realizada Actualización del Progreso de las Actividades Para actualizar el estado del proyecto, el Gestor del proyecto debe actualizar su proyecto marcando el %Completado de cada tarea, Clarity permite también realizar el seguimiento de los proyectos desde la propia herramienta o utilizar Ms Project como planificador externo, es importante destacar que el seguimiento se debe realizar en Clarity o en MS Project, ya que la combinación de ambos métodos puede generar incongruencias en el sistema. Para conocer en detalle los métodos de seguimiento y cómo actualizar la situación del proyecto consultar el Anexo 2. Manual de Usuario del Gestor de proyectos para la Gestión en Clarity. 3.6 Criterios de Entrega Entregables Un entregable es un producto de trabajo que culmina la realización de una actividad o fase de un proyecto. Por entregable, dentro de la metodología definida en la presente guía, se entiende: - Para proyectos de Desarrollo 1 Normalmente se realiza quincenalmente o mensualmente. 16

17 o Cada uno de los documentos definidos en la Tabla 6. Plantillas de Entregables de Desarrollo de Software. - Para proyectos de Prestación de Servicio: o Los definidos en la Tabla 12. Plantillas de Gestión de Servicios - Para Otros tipos de Proyecto, incluidos los de Mantenimiento: o Los definidos en la reunión de inicio Criterios generales de Entregas al IAM Para considerarse finalizado un entregable (sea cual sea el tipo de proyecto), es necesario no sólo que el adjudicatario lo sitúe en la herramienta corporativa de gestión de configuración Subversion, sino que la Unidad de Calidad verifique el cumplimiento de los estándares. Para este último paso, el responsable IAM comunicará a la Unidad de Calidad (notificándolo con un correo a XXXXX ) la ruta del entregable en SubVersion y el nombre de la etiqueta ( Tag del SubVersion) bajo la que se ha introducido. Una vez que se realice la petición de entrega, la Unidad de Calidad revisará que el entregable cumple con los estándares establecidos y remitirá un informe al solicitante de la petición con el estado en el que se encuentra el entregable. La auditoría asignará un porcentaje de cumplimiento de los estándares corporativos, y el estado del entregable será correcto (y se dará por terminado) si se alcanzan los objetivos de cumplimiento de estándares fijados en la reunión de inicio. Nótese que ninguna de las auditorías de Calidad son bloqueantes para realizar subidas de aplicaciones entre entornos. El responsable IAM siempre podrá solicitar las subidas que considere oportunas sin que los entregables hayan sido terminados, salvo que se trate de incidencias de carácter grave que puedan impedir el despliegue o arranque de las aplicaciones entregadas. El conjunto de checks a comprobar por el equipo de auditoría se encuentra en el Informe de la Unidad de Calidad, proporcionada junto con este documento. Este documento es sólo para uso de la Unidad de Calidad. Se proporciona sólo a efectos informativos. Cada uno de los entregables se validará por la Unidad de Calidad en un tiempo Máximo de 8 horas laborables, teniendo en cuenta que en la planificación no se podrán solapar las entregas de varios entregables. Si las entregas se realizan de forma conjunta, se sumarán 8 horas por cada uno de los entregables. Se deberán hacer entregas a la Unidad de Calidad hasta que cada uno de los entregables alcance el nivel de cumplimiento acordado en la reunión de inicio. 17

18 Los estados posibles de los entregables incluidos en el Informe de la Unidad de Calidad son: - PENDIENTE: El entregable no ha sido revisado por la Unidad de Calidad. - NO APLICA: El entregable no aplica para el proyecto en cuestión. - NAACORD: (NO APLICA ACORDADO) El entregable sí que debería realizarse, pero se acuerda no realizarlo con la jefatura de Proyecto del IAM - Valor numérico: Porcentaje de cumplimiento del entregable respecto a la metodología definida en la presente Guía. Además de la verificación de los entregables que se solicite revisar en cada una de las entregas, la unidad de Calidad validará por cada entrega: - Gestión de la Configuración: verificar el acrónimo, la estructura estándar del repositorio, ubicación de entregables, despliegues y documentación - Seguimiento del proyecto: Grado de actualización de la planificación Entregas Informales Con objeto de tener una orientación del posible resultado de una auditoría para un entregable concreto, el adjudicatario podrá solicitar una auditoría informal por entregable, que consiste en una auditoría de una parte reducida de un entregable. Por ejemplo un grupo funcional, o un conjunto pequeño de clases de código. La Unidad de Calidad realizará una auditoría (sin acuerdo de nivel de servicio) que podrá servir para orientar al equipo sobre la construcción del resto del sistema Estructura genérica Para cada nuevo proyecto se deberá generar un acrónimo de máximo 5 letras (XXXXX). Este acrónimo deberá ser aprobado previamente por la Unidad de Calidad, para evitar duplicidades. El proyecto se añadirá dentro de la estructura de la Organización disponible para el Jefe de Proyecto en la herramienta de gestión de proyectos Clarity. Dentro de cada proyecto de desarrollo se establece la siguiente estructura normalizada para el repositorio de control de versiones subversion: [XXXXX] o Trunk 18

19 Donde: - Fuentes - Documentación - Despliegues o Tags o Branches 2 Trunk:(tronco) se utiliza para alojar la línea principal del desarrollo. Es la carpeta en la que normalmente se actualizarán los cambios. Branches: (ramas) para que contenga las copias/ramas. En el caso en que se deban mantener varias versiones en paralelo, se utilizarán las ramas para gestionar las distintas líneas de desarrollo concurrentes. Tags:(etiquetas) para contener las etiquetas, versiones de entrega al IAM, tanto parciales como totales. Como elemento de ayuda, se proporciona en la documentación adjunta un archivo (Plantilla Estructura de Carpetas.rar), con la estructura indicada. Cada entregable se almacenará en una ruta predeterminada del repositorio corporativo Subversion. Para más información acerca del uso y la estructura de SubVersion consultar el Anexo 10. Uso de SVN Generación de etiquetas Todas las entregas que se realicen a la Unidad de Calidad, deberán llevarse a cabo utilizando etiquetas. Todas las etiquetas se deberán generar en Subversion en la carpeta tags con la nomenclatura que se define en el punto Para etiquetar se debe tener en cuenta, que solo es necesario incluir en la etiqueta los entregables que se quieran entregar, más los entregables que ya se encuentren validados (100% de cumplimiento), realizando así etiquetas incrementales. Por ejemplo, si tenemos un tipo de proyecto de desarrollo y nos encontramos en la fase de diseño, cuando terminemos el entregable Diseño de arquitectura, la etiqueta deberá contener: carpeta trunk. 2 Las carpetas tags y branches contendrán la misma estructura interna que la 19

20 3.6.4 Política de Versionado Ilustración 1. Ejemplo etiquetas incrementales El patrón de nombrado de la versión es Vxx.yy.zzz Por ejemplo: V , (la tabla siguiente indica el valor de cada uno de ellos) donde: VARIABLE POSIBLES VALORES SIGNIFICADO xx yy zzz Entero positivo. [1..99] Entero positivo. [1..99] Enteros positivos. [0..999] Número de versión mayor. Aumenta cuando se añaden cambios significativos y/o nuevas funcionalidades. Fundamentalmente cuando se inicia un nuevo desarrollo (o pliego) Número de versión menor. Aumenta cuando se añaden pequeños cambios y/o funcionalidades poco importantes. A modo de ejemplo, una forma de identificar el cambio de funcionalidad si conlleva una generación de nuevos scripts de pruebas. Mantenimiento adaptativo de menor importancia. Número de revisión. Aumenta con cada una de las entregas de mantenimiento e incluyen resoluciones de errores. Tabla 2. Nomenclatura de versionado 20

21 3.7 Política de certificados. En este apartado se va a tratar todo lo relativo a la política de certificados digitales en el IAM Certificados admitidos Los certificados clientes deben ceñirse a una lista de autoridades emisoras de certificados digitales reconocidas en el ámbito del Ayuntamiento de Madrid, siendo la relación la siguiente: - FNMT. - DNIe. - Firma Profesinal. - Asociación Nacional de Fabricantes - ANF. - Agencia Notarial de Certificación ANCERT. - Camerfirma. - Agencia de Tecnología y Certificación Electrónica - ACCV. - Colegio de Registradores. - APE Organización de los certificados Tanto para el caso de Web Services, como en el caso de aplicaciones web, cuando se vea la necesidad de utilizar certificados digitales para autenticación o cifrado de los datos, se ha resuelto organizar la infraestructura necesaria de la siguiente manera: - Por cada uno de los aplicativos o servicios, se ha de crear un almacén de certificados para cada entorno. Estos almacenes contendrán: o Certificado servidor. o Certificados de la jerarquía de las Autoridades de Certificación de los distintos certificados cliente y servidor. o En el caso de Web Services, certificados con clave pública de cliente, enviados por las unidades, empresas, organizaciones, etc. consumidoras de la aplicación. 21

22 Almacenes de certificados para ENTORNO A Almacén Aplicativo 1 Almacén Aplicativo 2.. Almacén Aplicativo n Certificados de clientes y de servidor.. cliente-1 cliente-n SERVIDOR. cliente-2 cliente-p SERVIDOR. cliente-j cliente-2 SERVIDOR Certificados raíces de confianza CAs clientes raíz-ca-1 raíz-ca-n raíz-ca-1 raíz-ca-n raíz-ca-1 raíz-ca-n Ilustración 2. Descripción almacenes de certificados por entorno. A pesar de que en párrafo anterior se ha indicado que se ha de crear un almacén de certificados para cada aplicativo, se puede reutilizar un mismo almacén de certificados para dos o más aplicativos, teniendo en cuenta que éstos deben tener autorizados los mismos usuarios. El formato de almacenamiento de los certificados debe ser JKS. No es necesario proporcionar certificados para firma, ya que la firma se llevará a cabo a través del Componente Común de Firma Obtención de Certificados Sistemas dispone de certificados de pruebas para los distintos entornos, así como la posibilidad de crear certificados de servidor, que puede solicitarse por el responsable IAM del proyecto a través de IamPeticiones Entorno de Desarrollo Como norma general se utilizará un certificado cliente para acceder a cada aplicativo que necesite certificados para sus operaciones. Es decir, si un aplicativo es atacado por varios clientes, se utilizará el mismo certificado. Como certificado de servidor se dispone de un certificado para el entorno de desarrollo emitido por la PKI corporativa, según lo comentado en el punto anterior. 22

23 En el caso (generalmente para Web Services) de necesitar realizar un control por peticionario, el jefe de proyecto de IAM podrá solicitar la generación un certificado para cada cliente siguiendo también las instrucciones del punto anterior Entorno de Preproducción En el entorno de preproducción, y como norma general, no se generará ningún certificado, sino que deberán ser los clientes los que deban proporcionar la parte pública de sus certificados para que el intercambio de datos pueda ser llevado a cabo. Como certificado de servidor se dispone de un certificado para el entorno de Preproducción Entorno de Producción Cono norma general, se tendrá en cuenta lo indicado para el entorno de Preproducción. Como certificado servidor, se dispone en el almacén de certificados de un certificado de servidor emitido por la FNMT Especificidades para las aplicaciones web Algunas aplicaciones pueden requerir niveles de seguridad basados en certificados digitales. Esta seguridad es proporcionada en parte por los servidores web frontales IHS. Dependiendo del tipo de política de seguridad que se establezca establecer se requerirán las siguientes configuraciones: SSL: Se requiere una comunicación cifrada (se utiliza el certificado *.munimadrid.es en el servidor web). Existe una configuración a nivel de plataforma WAS en entorno INTRANET que determina la confianza en el certificado *.munimadrid.es, es decir, por defecto, los servidores confiarán en dicho certificado cuando desde una de las aplicaciones desplegadas se establezca una configuración SSL con otra aplicación en *.munimadrid.es. Por tanto, dichas aplicaciones no requerirán un almacén de certificados propio ni realizar configuración de la conexión SSL. Negociación de Certificado Cliente: se solicita al usuario que presente un certificado digital; la negociación la realiza el servidor frontal web y se envía al servidor WAS si es un certificado de alguna entidad autorizada. Para el resto de certificados en los que la aplicación deba confiar (por ejemplo, entidades bancarias) o para los certificados propios de autenticación, será responsabilidad del aplicativo: 23

24 o Incorporar entre sus ficheros de recursos (dependientes del entorno) el almacén con los certificados en que confía dicha aplicación, así como el certificado de autenticación o firma que debe utilizar. o Mantener actualizado dicho almacén de certificados ante caducidad o cambio de los mismos, así como solicitar su subida a los entornos de desarrollo, preproducción y producción con la suficiente antelación para minimizar las paradas de servicio. o Configurar adecuadamente la conexión SSL haciendo uso de JSSE. Las aplicaciones deben contemplar el tratamiento en caso de recibir cualquier tipo de estos certificados. En caso de no aceptar alguno de ellos, así como para cuando el usuario no dispone de certificado o cancela la negociación (error 403), se deberá redirigir al usuario a una página HTML de aviso donde se indique la necesidad de disponer de un certificado cliente y los tipos aceptados por el aplicativo. Por defecto, esta página ya existe para el error 403 a nivel de toda la plataforma WAS INTERNET., por lo que es opcional entregar una página personalizada, en cuyo caso dicha página debe estar diseñada para permitir su despliegue fuera del contexto de la aplicación (por defecto, se desplegará en el contexto general de mantenimiento). Es responsabilidad del aplicativo verificar si la petición llega con certificado cliente y enviar si la persona/entidad asociada a dicho certificado está autorizada o no para el acceso al aplicativo. El requisito de seguridad (comunicación SSL y certificado digital del usuario requerido) debe establecerse para toda la aplicación. La información necesaria para una correcta configuración deberá detallarse claramente en el Plantilla 13. Manual Técnico de Despliegue de Aplicación Web, incluyendo si requiere SSL, certificado cliente, página HTML personalizada, etcétera. No se permitirá una configuración de seguridad a nivel de servidor, sino que debe realizarse con JSSE de tal forma que permita la convivencia entre varios aplicativos con diferentes almacenes de certificados y evitando en todo momento la sobre-escritura de la configuración por defecto del servidor Especificidades para Servicios Web Respecto a los Web Services, éstos deben ser desarrollados sin hacer ningún tratamiento interno de seguridad (usuarios/contraseña, etc.). En su lugar se establecerá la política de seguridad con las herramientas corporativas para este fin. Consúltese el documento Anexo 11. Manual de Servicios Web. 24

25 4 Proyectos de Desarrollo Las fases y requisitos técnicos presentados en esta sección aplican tanto a nuevos proyectos como a evolutivos mayores (suficientemente grandes como para ser planificados 3 como una nueva versión) de proyectos ya en producción. En caso de tener varios bloques funcionales que se entreguen por separado, la planificación se dividirá en iteraciones, y para cada una de ellas se definirán las fases definidas en la metodología de desarrollo (ASI, DSI ). Las tareas de alto nivel de cada iteración de desarrollo serán las fases definidas en MÉTRICA, exceptuando las tareas de Planificación y Estudio de Viabilidad, realizadas anteriormente, es decir: Análisis del Sistema de Información (ASI), Diseño del Sistema de Información (DSI), Construcción del Sistema de Información (CSI), Implementación y Aceptación del Sistema (IAS). Se permite la utilización de metodologías tanto ágiles como planificadas, pero el resultado de cada iteración o sprint debe respetar la estructura de entregables que se describe en este apartado. En caso de usar metodologías ágiles, el proyecto debe ser el encargado de establecer los puntos en los que se auditarán los entregables, y será responsable de gestionar los posibles trabajos de corrección de incumplimientos de Calidad. 4.1 Estructura La estructura normalizada del repositorio se describe a continuación: Carpeta Fuentes A continuación describimos los distintos módulos que pueden formar parte de una aplicación. Nombre modulo será el acrónimo del proyecto y en caso de que esto produzca colisión de nombres (por ejemplo si existen dos módulos DAO) será <acronimoproyecto>_<nombredescriptivodelmodulu> por ejemplo (WEB_CURSO_INTERNET, WEB_CURSO_INTRANET) MÓDULO LOCALIZACIÓN DESCRIPCIÓN Módulos Client fuentes/client_<nombremodulo> Módulo que contiene los artefactos necesarios para construir la parte 3 Se recomienda planificar proyectos cuando superan los dos o tres meses de duración, y/o cuando el alcance del proyecto tenga uno o varios productos de entrega definidos. 25

26 cliente de un EJB. Módulos DAO fuentes/dao_<nombremodulo> Módulo que contiene los artefactos necesarios para construir el acceso a datos. Módulos EJB fuentes/ejb_<nombremodulo> Módulo que contiene los artefactos necesarios para construir la interfaz publica un EJB. Módulos de NEGOCIO Módulos Servicios Web fuentes/neg_<nombremodulo> fuentes/ws_<nombremodulo> Módulos que contienen únicamente los artefactos necesarios para construir el negocio. Módulo que contiene los artefactos necesarios para construir la parte Web Service. Módulos WEB fuentes/web_<nombremodulo> Módulo que contiene los artefactos necesarios para construir la parte WEB. Tabla 3. Localización de los módulos Para cada módulo, a partir de la ubicación raíz indicada en la tabla anterior, la estructura será la siguiente (no todos los elementos son obligatorios, pero de existir este elemento, debe ser localizado en la ruta indicada 4 ): ELEMENTO LOCALIZACIÓN DESCRIPCIÓN Script de construcción En la raíz del módulo. El pom.xml del módulo que será el encargado de construir el módulo. Código fuente src/main/java Fuentes del módulo que serán empaquetados dentro del artefacto generado por el módulo. Código fuente pruebas unitarias Ficheros de recursos. Fichero de recursos de pruebas src/test/java/ src/main/resources src/test/resources Fuentes de las pruebas unitarias que NO serán empaquetas dentro del artefacto generado por el módulo. Contendrá los archivos de recursos que serán empaquetados dentro del artefacto generado por el módulo. Estos archivos de recursos no se empaquetaran dentro del zip de recursos y no podrán ser modificados tras el despliegue. Esta carpeta contendrá también los almacenes de certificados, en formato JKS, de los certificados que se requieran instalar en el almacén de certificados asociado a la aplicación, tanto en el caso de Web Services (vía el producto Policy Manager) como en el caso de aplicaciones web (en el servidor de aplicaciones) Contendrá los archivos de recursos necesarios para las pruebas unitarias que NO serán empaquetados dentro del artefacto generado por el módulo 4 Por ejemplo, los ficheros de recursos de un módulo NEG se localizarían en Fuentes/NEG_NombreModulo/src/main/resources/ 26

27 unitarias. WSDL de servicios web 5 Hojas de estilo en cascada 6 src/main/wsdl/ Nota: Se admitirá la ubicación en src\main\webapp\w EB-INF\wsdl src/main/webapp/cs s Contendrá los WSDL necesarios para los módulos de servicios web. Contendrá las CSS que serán empaquetadas dentro del zip de ficheros estáticos. JavaScript 6 src/main/webapp/ js Contendrá los js que serán empaquetadas dentro del zip de ficheros estáticos. Imágenes 6 src/main/ / images Contendrá las imágenes que serán empaquetadas dentro del zip de ficheros estáticos. Páginas estáticas 6 Páginas dinámicas 6 Archivos de configuración 6 src/main/webapp src/main/webapp/ht ml src/main/webapp/w EB-INF/jsp src/main/webapp/w EB-INF Contendrá las páginas estáticas (html, htm) que serán empaquetadas dentro del zip de ficheros estáticos. Se recomienda alojar la mayoría de las páginas bajo src/main/webapp/html. Contendrá las páginas dinámicas que módulo que serán empaquetados dentro del artefacto generado por el módulo. Archivos de xml de configuración. Tabla 4. Estructura interna de los módulos Independientemente de los artefactos asociados a un módulo, otros artefactos no asociados directamente a ningún módulo en concreto deberán seguir la siguiente nomenclatura: ELEMENTO LOCALIZACIÓN DESCRIPCIÓN Ficheros de configuración del proyecto fuentes/config/conf/(*)/(**) fuentes/config/rec/(*)/(**) En la carpeta conf se incluirán los ficheros de configuración del proyecto (parámetros que puedan cambiar sin que requiera la generación del EAR) En la carpeta rec se incluirán los ficheros de recursos del proyecto. En sistemas para plataforma J2EE WASv8 se entregará un fichero serviciosiam.properties dónde se localizarán datos restringidos de máquinas y 5 Solo para módulos WS. 6 Solo para módulos WEB. 27

28 acceso según plantilla. Herramientas externas (en caso de existir) Scripts de construcción fuentes/herramientas fuentes/ (*) En caso de existir subsistemas se creará una carpeta para cada subsistema. (**) A este nivel se encuentra la definición de las propiedades para los distintos entornos (desa, pre, pro,..) Aquí se incluirán las herramientas externas al estándar del IAM que sean necesarias para construir el proyecto. POM padre de los distintos submódulos. Scripts de carga de base de datos (en caso de ser necesario) Scripts de instalación de base de datos. Scripts de Documentum Archivos de instalación de BPM Archivos de GIS Archivos de ERDAS Scripts de procesos batch (en caso de ser necesarios) Scripts de prueba y ficheros asociados fuentes/scripts/bbdd/actuali zación fuentes/scripts/bbdd/instala cion fuentes/scripts/documentu m/instalacion fuentes/scripts/bpm/instala cion fuentes/scripts/gis/instalac ion fuentes/scripts/erdas/inst alacion fuentes/scripts/batch fuentes/scripts/pruebas Sentencias SQL o PTF de actualización de datos, o de actualización de los mismos realizadas con posterioridad a la instalación Sentencias SQL o PTF de creación de la base de datos e inserción de datos iniciales. Sentencias DQL u otros componentes para creación o actualización de repositorio en Documentum Ficheros.ear u otros para creación o actualización de componentes en BPM o iprocess. Archivos ASX, MSD u otros para creación o actualización de servicios de mapas GIS. Archivos para creación o actualización de ortofotos ERDAS. En esta carpeta estarán los procesos batch de la aplicación. Nota: Esta ubicación contendrá normalmente un fichero.jar a ejecutar según la política definida en la Plantilla 12.Despliegue de procesos Batch. Scripts de Load Runner, datos de entrada de los scripts, y cuantos artefactos sean necesarios para su ejecución. En esta carpeta se situarán también los scripts de QuickTest, en caso de existir. Tabla 5. Localización de los fuentes dentro de cada módulo El código fuente deberá adaptarse además a una nomenclatura de paquetes, y cumplir las normas de código, según lo establecido en el Anexo 7.Normas de Código. 28

29 4.1.2 Carpeta Documentación La lista de entregables que muestra la siguiente tabla se debe almacenar en Subversion de cada proyecto. Las plantillas están disponibles en el repositorio de publicación, junto con la presente Guía. FASE Entregable Localización ASI Plantilla 3. Maqueta /Documentación/2.ASI/ ASI Plantilla 4.Interfaz de Servicio /Documentación/2.ASI/ ASI Plantilla 5.Requisitos /Documentación/2.ASI/ ASI Plantilla 9. Proyecto RSA de Modelado (XXXXX_Modelado) /Documentación/ModeloRSA/ DSI Plantilla 7. Diseño de Arquitectura /Documentación/3.DSI/ DSI Plantilla 9. Proyecto RSA de Modelado (XXXXX_Modelado) /Documentación/ModeloRSA/ DSI Plantilla 10.Proyecto RSA de Modelado de DATOS (XXXXX_DBD) /Documentación/ModeloRSA/ CSI Plantilla 8. Manual de Uso de Componentes_Servicios /Documentación/4.CSI/ CSI Plantilla 11. Manual de Usuario /Documentación/4.CSI/ CSI Plantilla 6. Casos de Prueba /Documentación/4.CSI/ IAS Plantilla 12.Despliegue de procesos Batch /Documentación/5.IAS/ IAS Plantilla 13. Manual Técnico de Despliegue de Aplicación Web /Documentación/5.IAS/ IAS Plantilla 14. Publicación de Servicios Web /Documentación/5.IAS/ IAS Plantilla 19. Gestión de incidencias /Documentación/5.IAS/ 29

30 IAS Plantilla 20. Plan de Implantación /Documentación/5.IAS/ IAS Plantilla 21. Creación de un Servicio ARcGIS /Documentación/5.IAS/ IAS Plantilla 22. Creación de un Servicio ARCIMS /Documentación/5.IAS/ IAS Plantilla 23. Plantilla Creación objetos documentales Documentum.dot /Documentación/5.IAS/ IAS Plantilla 24. Despliegue aplicaciones SOA- BPM.dot /Documentación/5.IAS/ IAS Plantilla 25. Actualización repositorio documental.dot /Documentación/5.IAS/ Tabla 6. Plantillas de Entregables de Desarrollo de Software Carpeta información adicional Existirá, además, dentro de Documentación la carpeta /Información adicional donde se podrá introducir cualquier otra documentación no mencionada en este documento y que se considere necesaria para el proyecto Proyectos con Subsistemas Si se han definido Subsistemas en el proyecto, podríamos tener 2 casos al incluir la documentación: 1. Que exista un documento, por ejemplo maqueta, por cada uno de los subsistemas. En este caso, se creará una carpeta, dentro del directorio 2.ASI, para cada subsistema y con el archivo con nombre Maqueta.ppt dentro de cada una 30

31 Ilustración 3. Estructura de Carpetas con Subsistemas 2. Que exista un sólo documento, con la especificación de todo el proyecto (para todos los subsistemas). En este caso se seguirán las directrices del apartado Carpeta Despliegues En la siguiente imagen se muestra el contenido de la carpeta despliegues de un modo grafico. Ilustración 4. Estructura de la Carpeta Despliegues Dependiendo de los elementos que contenga la aplicación podremos incluir en la carpeta Despliegues: FASE Entregable Localización 31

32 Para aplicaciones J2EE Aplicación <acrónimo de la aplicación>.ear (Aplicativo.EAR) trunk/despliegues/aplica ción Aplicación < acrónimo de la aplicación>_estaticos.zip (Archivo de ficheros estáticos) trunk/despliegues/aplica ción Aplicación < acrónimo de la aplicación>_recursos.zip (Archivo de ficheros de propiedades) trunk/despliegues/aplica ción/<entorno> (desa, pre, pro, forma) Para aplicaciones Con BPM BPM < acrónimo de la aplicación>.ear (Aplicativo.EAR) trunk/despliegues/bpm BPM Otros ficheros trunk/despliegues/bpm /<Entorno> (desa, pre, pro, forma) Para aplicaciones Con SOA SOA <nom_fichero>.ear trunk/despliegues/soa Otras actuaciones SOA + BPM Modificación fichero CDQP CDQP.txt Trunk Despliegues BPM + SOA Creación de Colas IPE-EMS Dentro de documentación indicar nombre de la cola a crear Para aplicaciones Con Mapas Mapas <Ficheros>.axl trunk/despliegues/mapas /<Entorno> (desa, pre, pro, forma) Mapas <Ficheros>.mxd trunk/despliegues/mapas /<Entorno> (desa, pre, pro, forma) Mapas <Ficheros>.sde trunk/despliegues/mapas /<Entorno> (desa, pre, pro, forma) Para aplicaciones Con Gestor Documental 32

33 Gestor Documental <Ficheros>.dql trunk/despliegues/gestor Documental Extensión de las DFCs <Ficheros>.tbo trunk/despliegues/gestor Documental Para aplicaciones con BBDD BBDD <Ficheros>.sql trunk/despliegues/bbdd Tabla 7. Plantillas de Entregables de Despliegue En el Anexo 8.Normas de empaquetado y entrega se detallan las directrices técnicas de los entregables de despliegue. En los siguientes apartados se describen con más detalle cada una de las fases y los entregables que le corresponden. 4.2 Fase ASI En esta fase, se definirán todos los entregables necesarios para la validación funcional del usuario (necesidades de alto nivel, maqueta e interfaz), y se almacenarán en SubVersion Maqueta Para poder proporcionar al usuario una visión más completa de la aplicación a desarrollar, se elaborará una maqueta que servirá de base para la captura de requisitos, y se almacenará en la ruta de SubVersion indicada en la Tabla 6. Plantillas de Entregables de Desarrollo de Software. La maqueta podrá realizarse en formato HTML (si se pretende reutilizar dicho código añadiendo la lógica de negocio en el futuro) o en formato PowerPoint siguiendo la Plantilla 3. Maqueta. En caso de codificarse el HTML de la maqueta, dicho código deberá alojarse en las carpetas definidas para la parte estática de un desarrollo normal, dentro de la carpeta Fuentes Imagen Corporativa Para el cumplimiento de la imagen corporativa del IAM, se encuentran a disposición de los proyectos en el directorio de distribución, en la carpeta Interfaz Gráfica, los manuales de estilo y hojas de estilos de las diferentes líneas de desarrollo de aplicaciones: AYRE, para el desarrollo de aplicaciones de Intranet. MuniMadrid, para el desarrollo de aplicaciones de Internet. 33

34 Sede, para el desarrollo de trámites electrónicos a publicar en la SEDE. Móvil, para el desarrollo de aplicaciones para dispositivos móviles. Se crearán tantas maquetas como sean necesarias para describir la imagen de la aplicación. Se debe tener en cuenta que en la imagen de la aplicación también se deberán describir los formularios de impresión si aplicasen. Todos los elementos de presentación comentados se encuentran disponibles junto al resto de elementos comunes descritos en la Tabla 10. Componentes Comunes Requisitos de Accesibilidad En los casos en que el acceso a la aplicación sea a través de Internet, aunque los usuarios sean controlados, ésta tendrá que ajustarse al nivel mínimo de accesibilidad exigido por la legislación española para las administraciones públicas, que corresponde a los niveles de Prioridad 1 y Prioridad 2 de la UNE:139803:2004, que a su vez se corresponde con los niveles A, doble-a y tres requisitos del nivel triple-a del W3C. Estos tres requisitos son: Identificar el lenguaje natural del documento. Proporcionar resúmenes de las tablas. Crear un orden lógico para navegar con el tabulador a través de vínculos, controles de formulario y objetos. Toda la normativa de accesibilidad se encuentra disponible en la carpeta Accesibilidad y Normativa publicada junto con la presente guía Interfaz de Servicios Web Para Servicios Web, deberá construirse una presentación PowerPoint siguiendo la Plantilla 4.Interfaz de Servicio y se almacenará también en el Subversion. Del mismo modo que con las maquetas, se crearán cuantos documentos de Interfaz sean necesarios. En el documento de Interfaz, se indicarán al menos los servicios disponibles, entradas y salidas (generales) de cada servicio, una breve descripción de cada uno y un diagrama que muestre la interacción de los servicios con usuarios y sistemas externos. Será este documento (en lugar del WSDL, que se generará en fase de Diseño) el que se utilice para que el usuario valide si los datos a intercambiar son los apropiados. 34

35 4.2.3 Documento / Modelo de Requisitos Este entregable va dirigido a usuarios del sistema, por lo que los requisitos que se describan deberán estar siempre enfocados desde el punto de vista de dichos usuarios, sin entrar en el funcionamiento interno de la aplicación. Por tanto, no se deberán hacer referencias a entidades, flujos internos, ni a elementos de arquitectura. Para la realización de este documento se podrá utilizar la Plantilla 5.Requisitos o si se prefiere realizar toda la documentación en un modelo la Plantilla 9. Proyecto RSA de Modelado (XXXXX_Modelado) (02.ASI.emx) ubicada en el directorio de distribución. Si se realiza el documento se deberán entregar los elementos de modelado en RSA. En cambio, si se utiliza la plantilla de Modelado para documentar toda la información (sin utilizar documento), solo será necesario el modelo. En esta plantilla se deberán especificar: - Los Actores que interactúan con el sistema. - Los Requisitos Funcionales que describan la funcionalidad o los servicios que se espera que el sistema provea en un lenguaje natural entendible por el usuario. - Los Requisitos No Funcionales que describan las propiedades transversales del sistema como la fiabilidad, disponibilidad, - Los Requisitos de Rendimiento asociados a un camino crítico de la aplicación Para una mejor comprensión de los requisitos funcionales, estos deberán agruparse en paquetes de Grupos Funcionales, siempre que dichos requisitos tengan una funcionalidad relacionada. Cada grupo funcional estará numerado con la notación GF-XX, donde XX no tiene porque ser necesariamente números consecutivos. Todos los elementos gráficos UML incluidos en el documento Word, deberán además ser proporcionados para su edición en la herramienta corporativa de modelado RSA, siguiendo la utilizando Plantilla 9. Proyecto RSA de Modelado (XXXXX_Modelado) 35

36 Ilustración 5. Modelo RSA de Análisis Para más información acerca del uso de la herramienta RSA y modelad de la fase de Análisis consultar el Anexo 4. Manual de Análisis y Diseño con RSA Los casos de uso de criticidad alta (considerados importantes por el responsable IAM), deberán ser descritos mediante la documentación de su escenario, bien como diagramas de actividad UML, bien de forma textual siguiendo la siguiente estructura: Datos Caso de Uso: Descripción El cliente solicita que Actores participantes Pre-condiciones Post-condiciones Actor Genérico Si el adeudo es para una tasa de ejecutiva, se debe haber realizado antes el Caso de Uso paso a ejecutiva. El estado queda registrado como En Ejecutiva en el sistema Flujo Principal: 1 El Actor solicita a.1 2.b.1 2.b.2 Flujo opcional A: Si se pulsa Flujo opcional B: Si por el contrario se pulsa Más pasos del flujo opcional B 36

37 Flujos de Excepción: E1. No existe la tasa solicitada E1.1 El sistema informa que no existe la tasa E1.2 Vuelve a iniciarse el subflujo 2.b.1 E2. Tamaño de adjunto excedido E2.1 El sistema informa de que se reduzca el tamaño del adjunto Tabla 8. Plantilla Casos de Uso La realización de la especificación de requisitos puede realizarse en documento Word o en modelado RSA, a criterio de la jefatura de proyecto IAM. Si se realiza en documento Word, los elementos de modelado deberán entregarse en RSA, si se realiza en modelo RSA solo será necesario el modelo Planes de Pruebas Opcionales Opcionalmente, de existir, se definirán del siguiente modo los distintos tipos de prueba: Pruebas Unitarias 7 (JUnit): se entregará directamente en el código fuente, en la localización indicada en la Tabla 5. Pruebas Funcionales (a realizar manualmente por el equipo de desarrollo o con Quick Test Profesional): Se documentarán en QualityCenter. Aquellas pruebas funcionales marcadas con severidad Crítica formarán parte del juego de pruebas de regresión, es decir, aquellas que es necesario ejecutar antes de cada subida de versión. Pruebas No Funcionales (como accesibilidad, navegabilidad, seguridad etcétera): Se documentarán en la Plantilla 6. Casos de Prueba, añadiendo cuantos párrafos se necesiten. 7 Clases Java cuya única finalidad es la prueba del código fuente del proyecto. El objetivo es probar de forma aislada una parte del código determinada para asegurar su correcto funcionamiento independientemente del resto del proyecto. 37

38 4.3 Fase DSI En la fase DSI, se establecen los siguientes entregables: Diseño Arquitectura Lógica En el documento de Arquitectura, que seguirá la Plantilla 7. Diseño de Arquitectura, se especificará la arquitectura lógica que sigue la aplicación que se está desarrollando. Dicha arquitectura deberá adaptarse a los criterios corporativos descritos en los siguientes apartados. Cualquier excepción respecto a la arquitectura corporativa, deberá describirse en este documento acompañado de una justificación, que deberá ser aprobada por el Comité de Estándares. También se indicarán los Componentes Comunes IAM que se utilizarán, así como los componentes que se desarrollarán para su uso por otras aplicaciones Arquitectura Lógica Corporativa Las aplicaciones deben seguir la siguiente arquitectura lógica de referencia cliente-servidor que se estructurará al menos en tres capas y seguirá el patrón de diseño MVC: Ilustración 6. Arquitectura Lógica Corporativa 38

39 Presentación: o Proporciona el interfaz de usuario (IU) y gestiona el flujo de navegación de la aplicación. o Gestiona los eventos y el intercambio de datos entre el usuario y la aplicación. Lógica de Negocio: o Proporciona la lógica de la aplicación y funciona como nexo entre las capas de presentación y persistencia. o En un servicio o componente de negocio distinguimos los siguientes elementos: Persistencia: Interface del servicio proporcionado a la capa de presentación. Estos elementos son el contrato de la capa de negocio, es decir, son los elementos que indican lo que va a hacer la capa. Implementación del servicio o componente de negocio que contiene la lógica de la aplicación. Deben implementar los elementos de la interfaz de negocio. o Incluye las entidades persistentes del dominio de la aplicación y los servicios de acceso a la base de datos. o En la capa de persistencia podemos distinguir los siguientes elementos: Interface de persistencia proporcionado a la capa de negocio. Estos elementos son el contrato de la capa de persistencia, es decir, son los elementos que indican lo que va a hacer la capa. Implementación de la persistencia. Estos elementos son los encargados reales de realizar la persistencia. Deben implementar los elementos de la interfaz de persistencia. Servicios transversales: o Los componentes comunes IAM proporcionan funcionalidades reutilizables por las diferentes aplicaciones. 39

40 o Se podrá utilizar el conjunto de servicios proporcionadas y soportados por el servidor de aplicaciones (JavaMail, JNDI, JMS, ) o Servicio de generación de documentos basado en Jasper Reports. Además debemos considerar los siguientes aspectos relevantes: La seguridad de la aplicación se realizará del siguiente modo: o Si se trata de una aplicación Intranet, deberá realizarse utilizando el componente UWEB de autenticación y control de acceso. La documentación de este componente se encuentra publicada junto a este documento (ver Tabla 10. Componentes Comunes). o Si se trata de una aplicación Internet, la seguridad se controlará usando certificado digital, utilizando de manera programática las funcionalidades del componente de Pasarela de Firma (ver Tabla 10. Componentes Comunes). En todo caso, todas las aplicaciones que se sitúen en la Sede Electrónica, deben configurarse para acceder por https. o Otra casuística de seguridad, deberá ser tratada en el Comité de Estándares. El nombre de la aplicación debe coincidir con el contexto de la misma, por ejemplo: o Proyecto: GITED_InspeccionTecnicaEdificios o Aplicación: GITED (URL: o Aplicación: GITED_INF (URL: La gestión de las transacciones debe considerarse en cada una de las capas. Será responsabilidad de cada aplicación realizar una adecuada gestión transaccional que evite las inconsistencias en los datos de la aplicación. Los procesos batch son ejecutados fuera del servidor WAS y su programación puede planificarse con la frecuencia que se determine o lanzarse de forma manual desde un equipo cliente. Para más información consultar el documento Anexo 8.Normas de empaquetado y entrega Las siguientes secciones definen las siguientes tecnologías y estándares según la versión del servidor de aplicaciones dónde se despliegue la aplicación. Nótese que la arquitectura estándar a fecha de la publicación de esta guía es WAS 6.1. En caso de tratarse de un proyecto a largo plazo, y siempre dependiendo 40

41 de la disponibilidad de los entornos, se podría plantear el desarrollo en WAS 8. La arquitectura concreta a seguir se establecerá en la reunión de inicio del proyecto Arquitectura WAS 6.1 (estándar) Los estándares a considerar están basados en los soportados por la especificación J2EE 1.4. Pese a eso no se permite de forma general usar: Enterprise Java Beans RMI-IIOP ORB JAVA-IDL JDBC JMX Uso programático del User Transaction Para las distintas capas que conforman una aplicación estándar en el IAM se deberán usar las siguientes tecnologías: Presentación. o Para aplicaciones web tradicionales se utilizará Spring 3 + Tiles. Excepcionalmente y bajo acuerdo explicito con el Comité de Estándares, se puede usar Servlets 2.4 para funcionalidades no soportadas por Spring. o Para aplicaciones web 2.0 con soporte AJAX se podrá usar jquery como solución centrada en el cliente. o En casos excepcionales y tras acuerdo explicito con el Comité de Estándares se podrá usar struts 1.0 o superior. Lógica de Negocio. o Se utilizará Spring como contenedor de beans. o Se usarán servicios web JAX- RPC Persistencia. o Se utilizará Hibernate 3 para la declaración de las entidades persistentes del dominio de la aplicación y el acceso a la base de datos. Se prohíbe el uso de cualquier tipo de anotaciones no incluidas en el estándar JPA. o Excepcionalmente y previa autorización por el Comité de Estándares, se podrá usar directamente JDBC 3.0 siguiendo el patrón de diseño DAO. 41

42 Se utilizará Spring IoC para la inyección de las referencias entre los objetos de las distintas capas. Pese a que la arquitectura de desarrollo hace uso de Spring queda prohibido el uso de las siguientes características de Spring: AspectJ Jax-WS Task shedulling JDO, Oracle TopLink Ibatis SQL Velocity JSF RMI EJB 2 Lenguajes dinámicos JMX JDBC JPA Arquitectura WAS 8 (sujeto a disponibilidad) Las tecnologías y estándares a considerar están basados en los soportados por la especificación Java EE 6: Presentación. o Para aplicaciones web tradicionales se utilizará MyFaces 2.0 como implementación de JSF 2.0 y Facelets, EL-Expression y JSTL para la definición del interface de usuario. Excepcionalmente se puede usar Servlets 3.0 para funcionalidades no soportadas por JSF 2.0 o Para aplicaciones web 2.0 con soporte AJAX se empleará la solución IceFaces siguiendo el patrón Single Page Interface (SPI) Lógica de Negocio. o Se usarán EJB 3.1 que exponen métodos de negocio para aplicaciones Intranet: EJB de sesión para llamadas síncronas en tiempo real y EJBs de mensaje para llamadas asíncronas. o Se usarán servicios web JAX-WS 2.2 para servicios comunes que deban publicarse en el ESB 42

43 Persistencia. o Se utilizará JPA 2.0. Excepcionalmente y previa autorización por el Comité de Estándares, se podrá usar directamente JDBC 4.0 siguiendo el patrón de diseño DAOs. Deberá usarse JEE CDI para inyectar las referencias entre objetos pertenecientes a distintas capas Arquitectura de despliegue La distribución en máquinas de los distintos componentes se realiza en IAM de acuerdo al siguiente esquema: Tabla 9. Arquitectura en alta disponibilidad Hay que tener en cuenta que el despliegue de las aplicaciones debe acomodarse a esta arquitectura y que las necesidades de alta disponibilidad van a incidir directamente en la forma de implementar los componentes java. En particular, se recomienda tener en cuenta que los servidores de aplicaciones WAS se encuentran en CLUSTER y por ello se debe seguir las recomendaciones de desarrollo en estos entornos, entre las que podemos destacar: Todo lo que esté incluido en la sesión debe ser serializable. El tamaño de la sesión debe reducirse al mínimo posible. No use el sistema de ficheros local de la máquina. Use un sistema centralizado como Base de Datos o NAS. En la fase de diseño de la aplicación se deben indicar los distintos dispositivos (servidores web, servidores de base de datos, servidores de aplicaciones, etc.) de los que va a hacer uso la aplicación. Para realizar esta tarea se proporciona en la plantilla de diseño RSA (03.DSI.emx). Dentro del apartado 43

44 diagrama de despliegue se ha incluido un diagrama ejemplo. En este diagrama se muestra toda la arquitectura física del IAM y un ejemplo de cómo indicar el uso de los distintos dispositivos. Del diagrama de ejemplo se deben eliminar los dispositivos de los que no haga uso la aplicación y usar los artefactos propios de la aplicación indicando donde son desplegados. A continuación se muestra el diagrama de la plantilla Aplicaciones móviles Ilustración 7. Plantilla de diagrama de arquitectura. Para el desarrollo de aplicaciones accedidas mediante dispositivos móviles tanto orientadas al ciudadano como al trabajador del Ayuntamiento de Madrid se contempla una serie de estándares de uso obligado. Los estándares específicos para aplicaciones móviles se encuentran en el Anexo 9. Normas de desarrollo de Aplicaciones Móviles Componentes Comunes IAM disponibles El IAM dispone de una serie de componentes comunes que permiten la reutilización de funcionalidades. El uso de estos componentes toma carácter 44

Guía de Estándares. Informática del Ayuntamiento de Madrid. 26/02/2015 V03.01.007 Página 1 de 71

Guía de Estándares. Informática del Ayuntamiento de Madrid. 26/02/2015 V03.01.007 Página 1 de 71 Guía de Estándares Informática del Ayuntamiento de Madrid 26/02/2015 V03.01.007 Página 1 de 71 Contenido 1 Introducción... 6 2 Infraestructura... 7 2.1 Infraestructura de Puesto de Trabajo... 7 2.2 Metodología...

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

PLIEGO DE PRESCRIPCIONES TÉCNICAS DEL PROCEDIMIENTO SIMPLIFICADO PARA LA CONTRATACIÓN DE LOS SERVICIOS DE UNA EMPRESA PARA la INTEGRACIÓN DE

PLIEGO DE PRESCRIPCIONES TÉCNICAS DEL PROCEDIMIENTO SIMPLIFICADO PARA LA CONTRATACIÓN DE LOS SERVICIOS DE UNA EMPRESA PARA la INTEGRACIÓN DE PLIEGO DE PRESCRIPCIONES TÉCNICAS DEL PROCEDIMIENTO SIMPLIFICADO PARA LA CONTRATACIÓN DE LOS SERVICIOS DE UNA EMPRESA PARA la INTEGRACIÓN DE CONTENIDOS DE LA WEB DEL INSTITUTO DE CRÉDITO OFICIAL EN UN

Más detalles

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARTICULARES CORRESPONDIENTE AL CONTRATO NRC 96/2006

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARTICULARES CORRESPONDIENTE AL CONTRATO NRC 96/2006 PLIEGO DE PRESCRIPCIONES TÉCNICAS PARTICULARES CORRESPONDIENTE AL CONTRATO NRC 96/2006 1. CARACTERÍSTICAS TÉCNICAS QUE HA DE REUNIR EL OBJETO DE CONTRATO 1.1. OBJETO Este contrato tiene por objeto el servicio

Más detalles

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com EMPRESAS TUXPAN www.tuxpan.com AÑO 2007 INDICE DE CONTENIDO 1 Software de Servicios y Orquestación de Procesos 2 1.1.1 Introducción 2 1.1.2 Software de Orquestación como Integrador 3 1.1.3 Automatización

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

Administración Local Soluciones

Administración Local Soluciones SISTEMA INTEGRADO DE GESTIÓN DE EXPEDIENTES MODULAR (SIGM) CONFIGURACIÓN PARA LA INTEGRACIÓN CON SISNOT Y CORREOS SIGM v3 Administración Local Soluciones Control de versiones Versión Fecha aprobación Cambio

Más detalles

Servicios de accesibilidad Web

Servicios de accesibilidad Web experiencias reales, soluciones reales Servicios de accesibilidad Web Ref.: SER_ACC_V3_julio_ 2009 w w w. o b s e r v a l i a. c o m Índice 1. Introducción a la accesibilidad [ 3] 2. Auditorías de accesibilidad

Más detalles

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 18 CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC297_2 Versión 5 Situación RD 1201/2007 Actualización

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

SERVICIOS PARA DEMANDANTES DE EMPLEO A TRAVÉS DE INTERNET: ÁREA PERSONAL PARA DEMANDANTES

SERVICIOS PARA DEMANDANTES DE EMPLEO A TRAVÉS DE INTERNET: ÁREA PERSONAL PARA DEMANDANTES SERVICIOS PARA DEMANDANTES DE EMPLEO A TRAVÉS DE INTERNET: ÁREA PERSONAL PARA DEMANDANTES Servicio de Intermediación Profesional Dirección General de Intermediación e Inserción Laboral Servicio Andaluz

Más detalles

Contratación de la migración de portales web estáticos a la plataforma de gestión de contenidos y portales OpenText del Banco de España

Contratación de la migración de portales web estáticos a la plataforma de gestión de contenidos y portales OpenText del Banco de España Dirección General de Servicios Abril 2015 Contratación de la migración de portales web estáticos a la plataforma de gestión de contenidos y portales OpenText del Banco de España Pliego de prescripciones

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

ESB NORMATIVA DE DESARROLLO DE PROYECTOS

ESB NORMATIVA DE DESARROLLO DE PROYECTOS ESB NORMATIVA DE DESARROLLO DE PROYECTOS Versión 1.0 Área de Integración y Arquitectura de Aplicaciones Versión 1.0 Área de Aplicaciones Especiales y Arquitectura de Software Hoja de Control Título Normativa

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB DENOMINACIÓN: CON TECNOLOGÍAS WEB Código: IFCD0210 Familia profesional: Informática y Comunicaciones Área profesional: Desarrollo Nivel de cualificación profesional: 3 Cualificación profesional de referencia:

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Modelar, documentar, discutir, versionar, difundir, capacitar DESCRIPCIÓN TÉCNICA

Modelar, documentar, discutir, versionar, difundir, capacitar DESCRIPCIÓN TÉCNICA Sistema para Gestión de Conocimiento Modelar, documentar, discutir, versionar, difundir, capacitar DESCRIPCIÓN TÉCNICA Contenido Introducción... 3 Antecedentes... 4 Ediciones... 4 Empresarial... 4 Personal...

Más detalles

PLIEGO DE PRESCRIPCIONES TECNICAS PARTICULARES PARA EL REDISEÑO DE LA WEB MUNICIPAL USANDO DISEÑO ADAPTATIVO

PLIEGO DE PRESCRIPCIONES TECNICAS PARTICULARES PARA EL REDISEÑO DE LA WEB MUNICIPAL USANDO DISEÑO ADAPTATIVO ASUNTO: PLIEGO DE PRESCRIPCIONES TECNICAS PARTICULARES PARA EL REDISEÑO DE LA WEB MUNICIPAL USANDO DISEÑO ADAPTATIVO Informazioaren Teknologien Saila Departamento de Tecnologías de la Información Herritarrentzako

Más detalles

Plataforma de expediente Electrónico @DOC

Plataforma de expediente Electrónico @DOC MINISTERIO DE LA PRESIDENCIA SUBSECRETARÍA SUBDIRECCIÓN GENERAL DE TECNOLOGÍAS Y SERVICIOS DE LA INFORMACIÓN Plataforma de expediente Electrónico @DOC Arquitectura de Sistemas Control de versiones Versión

Más detalles

Plataforma de Desarrollo de Software

Plataforma de Desarrollo de Software Plataforma de Software Guía de introducción a la Plataforma de Desarrollo de Software Versión 1.07 Basado en plantilla: xxxxx - Plantilla básica v2.01 2014-02-07 Página 1 de 9 Control de cambios Fecha

Más detalles

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA EL SERVICIO DE CREACIÓN DE MAPA DE CONOCIMIENTO DE LA UNIVERSIDAD DE GRANADA

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA EL SERVICIO DE CREACIÓN DE MAPA DE CONOCIMIENTO DE LA UNIVERSIDAD DE GRANADA PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA EL SERVICIO DE CREACIÓN DE MAPA DE CONOCIMIENTO DE LA UNIVERSIDAD DE GRANADA Expte. EXCEL. CEI 04/11 1. OBJETO DEL CONTRATO Actualmente, la información presentada

Más detalles

Collaborative Lifecycle Management

Collaborative Lifecycle Management Collaborative Lifecycle Management IBM Rational Software Portafolio.. Documentación Técnica... COLLABORATIVE LIFECYCLE MANAGEMENT La solución de IBM Rational para la Gestión del Ciclo de Vida Colaborativo

Más detalles

Anexo 1 CONDICIONES TÉCNICAS EXIGIDAS

Anexo 1 CONDICIONES TÉCNICAS EXIGIDAS Anexo 1 CONDICIONES TÉCNICAS EXIGIDAS El contrato del sistema para la gestión de peticiones, quejas, reclamos sugerencias y felicitaciones PQRSF comprende las siguientes especificaciones técnicas de la

Más detalles

Características de OpenCms

Características de OpenCms Características de OpenCms Se basa en Java y Xml OpenCms está totalmente desarrollado en java bajo el estándar servlet. Por lo tanto, se puede integrar fácilmente en entornos hardware y software existentes,

Más detalles

MADEJA. Organización Gestor Documental. Versión: 0100 Fecha: 11/04/2011

MADEJA. Organización Gestor Documental. Versión: 0100 Fecha: 11/04/2011 Versión: 0100 Fecha: 11/04/2011 Queda prohibido cualquier tipo de explotación y, en particular, la reproducción, distribución, comunicación pública y/o transformación, total o parcial, por cualquier medio,

Más detalles

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Plan de Desarrollo de Software Universidad

Más detalles

EL PORTAFIRMAS ELECTRÓNICO CORPORATIVO (DOCELWEB)

EL PORTAFIRMAS ELECTRÓNICO CORPORATIVO (DOCELWEB) EL PORTAFIRMAS ELECTRÓNICO CORPORATIVO (DOCELWEB) Gonzalo Fernández-Victorio Jefe de Proyecto de Sistemas Informáticos Intervención General de la Administración del Estado Palabras clave DocelWeb, Portafirmas

Más detalles

elastic PROJECTS INFORMACIÓN COMERCIAL PROJECTS

elastic PROJECTS INFORMACIÓN COMERCIAL PROJECTS PROJECTS elastic PROJECTS INFORMACIÓN COMERCIAL Inscripción Registro Mercantil de Pontevedra, Tomo 3116, Libro 3116, Folio 30, Hoja PO-38276 C.I.F.: B-36.499.960 contact@imatia.com 1 INTRODUCCIÓN Mediante

Más detalles

Cualificación Profesional ADMINISTRACIÓN DE SERVICIOS DE INTERNET. Nivel 3. Versión 5

Cualificación Profesional ADMINISTRACIÓN DE SERVICIOS DE INTERNET. Nivel 3. Versión 5 Página 1 de 23 Cualificación Profesional ADMINISTRACIÓN DE SERVICIOS DE INTERNET Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC156_3 Versión 5 Situación Publicada Competencia general

Más detalles

ACCIÓN FORMATIVA FINANCIADA POR EL SERVICIO PÚBLICO DE EMPLEO ESTATAL

ACCIÓN FORMATIVA FINANCIADA POR EL SERVICIO PÚBLICO DE EMPLEO ESTATAL MF0491_3: PROGRAMACIÓN WEB EN EL ENTORNO CLIENTE. (IFCD0210: DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB) 180 HORAS PRESENCIALES Nº DE EXPEDIENTE: FC/2013/0064 ACCION 141 GRUPO 1 ACCIÓN FORMATIVA FINANCIADA

Más detalles

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 6. Actualización

CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL. Nivel 2. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN CONFECCIÓN Y PUBLICACIÓN DE PÁGINAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 2 Código IFC297_2 Versión 6 Situación Contraste externo Actualización

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

ATLAS MANUAL DE USUARIO DEL ARQUETIPO WEBSERVICE

ATLAS MANUAL DE USUARIO DEL ARQUETIPO WEBSERVICE ATLAS MANUAL DE USUARIO DEL ARQUETIPO WEBSERVICE Versión 1.8 Área de Aplicaciones Especiales y Arquitectura de Software Hoja de Control Título Documento de Referencia Responsable Manual de usuario del

Más detalles

Gestión del Portfolio de Proyectos HP Portfolio & Project Management. Información de Producto. 2010 Dirección de Consultoría

Gestión del Portfolio de Proyectos HP Portfolio & Project Management. Información de Producto. 2010 Dirección de Consultoría Gestión del Portfolio de Proyectos HP Portfolio & Project Información de Producto 2010 Dirección de Consultoría 2 1. Introducción Actualmente las organizaciones necesitan hacer frente a la complejidad

Más detalles

Manual del Empleado Público. Plataforma de Administración Electrónica Open Cities Community

Manual del Empleado Público. Plataforma de Administración Electrónica Open Cities Community Manual del Empleado Público Plataforma de Administración Electrónica Open Cities Community Versión 1.0 Esta obra está distribuida bajo la licencia Reconocimiento 3.0 de España de Creative Commons Para

Más detalles

REQUISITOS TÉCNICOS Y GUÍA DE USUARIO

REQUISITOS TÉCNICOS Y GUÍA DE USUARIO REQUISITOS TÉCNICOS Y GUÍA DE USUARIO DIRECCIÓN GENERAL DE LA POLICÍA CUERPO NACIONAL DE LA POLICÍA www.policia.es ÍNDICE DE CONTENIDOS 1. REQUISITOS TÉCNICOS... 4 1.1 Certificados digitales... 4 1.2 Sistemas

Más detalles

PROCEDIMIENTO DE GESTIÓN DE ENTREGAS

PROCEDIMIENTO DE GESTIÓN DE ENTREGAS Página 1 de 16 PROCEDIMIENTO DE GESTIÓN DE ENTREGAS Rev. Fecha Descripción 01 09/03/2007 Primera versión del documento 02 22/09/2009 Actualización de logos y contenido en general 03 20/06/2010 Actualización

Más detalles

Pliego de prescripciones técnicas Servicios de gestión y control de alertas de la CMDB Pliego de prescripciones técnicas

Pliego de prescripciones técnicas Servicios de gestión y control de alertas de la CMDB Pliego de prescripciones técnicas Sistemas de Información Marzo de 2015 Pliego de prescripciones técnicas Servicios de gestión y control de alertas de la CMDB Pliego de prescripciones técnicas Sistemas de Información 1 Objeto de la contratación

Más detalles

Pliego de Prescripciones Técnicas Particulares

Pliego de Prescripciones Técnicas Particulares Página: 1 de 26 Pliego de Prescripciones Técnicas Particulares Servicio de soporte para la administración de sistemas de la plataforma de portales y gestión de contenidos Nº expediente 300/2013/00925 División

Más detalles

Proyecto de implantación de una oficina virtual de atención al ciudadano en el Ayuntamiento de Baza

Proyecto de implantación de una oficina virtual de atención al ciudadano en el Ayuntamiento de Baza Concurso abierto Marzo 2005 Contrato de Consultoría y Asistencia para el diseño del Servicio de Atención Ciudadana (SAC) del Ayuntamiento Proyecto de implantación de una oficina virtual de atención al

Más detalles

Contrato de Consultoría y Asistencia para el diseño del Servicio de Atención Ciudadana (SAC) del Ayuntamiento

Contrato de Consultoría y Asistencia para el diseño del Servicio de Atención Ciudadana (SAC) del Ayuntamiento Concurso abierto Marzo 2005 Contrato de Consultoría y Asistencia para el diseño del Servicio de Atención Ciudadana (SAC) del Ayuntamiento PROYECTO CONSULTORÍA Y ASISTENCIA TÉCNICA PARA LA CONEXIÓN DE LA

Más detalles

GMF Gestor de incidencias

GMF Gestor de incidencias GMF Gestor de incidencias Contenidos Contenidos... 1 Introducción... 2 El módulo de Gestión de Incidencias... 2 Vista del técnico... 2 Vista de usuario... 4 Workflow o flujo de trabajo... 5 Personalización

Más detalles

Con la interacción de tus empleados mejorará la productividad de tu negocio

Con la interacción de tus empleados mejorará la productividad de tu negocio 1. Introducción Con la interacción de tus empleados mejorará la productividad de tu negocio Los empleados de cualquier compañía precisan numerosos accesos en su trabajo diario, además de interaccionar

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

Aplicateca Certificados SMS

Aplicateca Certificados SMS Aplicateca Certificados SMS Manual de usuario Versión v-2 By DIDIMO Servicios Móviles INDICE INDICE...2 1 QUÉ ES CERTIFICADOS SMS?...3 2 MENÚ PRINCIPAL...5 2.1 GRUPOS...5 2.1.1 Crear Grupo...5 2.1.2 Gestión

Más detalles

Índice. » Qué es Platino» Qué ofrece Platino» Cómo es Platino. » Quién usa Platino» Recursos / documentación

Índice. » Qué es Platino» Qué ofrece Platino» Cómo es Platino. » Quién usa Platino» Recursos / documentación Índice» Qué es Platino» Qué ofrece Platino» Cómo es Platino Infraestructura técnica Bus de Servicios (ESB) Seguridad en Platino Servicios de Platino» Quién usa Platino» Recursos / documentación 2 Qué es

Más detalles

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA CONTRATACIÓN DE SERVICIOS INFORMÁTICOS PARA APOYO EN LA ADMINISTRACIÓN Y GESTIÓN DE LOS SISTEMAS DE

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA CONTRATACIÓN DE SERVICIOS INFORMÁTICOS PARA APOYO EN LA ADMINISTRACIÓN Y GESTIÓN DE LOS SISTEMAS DE PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA CONTRATACIÓN DE SERVICIOS INFORMÁTICOS PARA APOYO EN LA ADMINISTRACIÓN Y GESTIÓN DE LOS SISTEMAS DE INFORMACIÓN Y DE LAS PLATAFORMAS TECNOLÓGICAS DEL ÁREA DE INFORMÁTICA

Más detalles

ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES Y DE GESTIÓN DE RELACIONES CON CLIENTES CUALIFICACIÓN PROFESIONAL

ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS EMPRESARIALES Y DE GESTIÓN DE RELACIONES CON CLIENTES CUALIFICACIÓN PROFESIONAL Página 1 de 23 CUALIFICACIÓN PROFESIONAL Familia Profesional Nivel 3 Código IFC363_3 Versión 5 Situación RD 1701/2007 Actualización ADMINISTRACIÓN Y PROGRAMACIÓN EN SISTEMAS DE PLANIFICACIÓN DE RECURSOS

Más detalles

PLIEGO DE PRESCRIPCIONES TECNICAS

PLIEGO DE PRESCRIPCIONES TECNICAS PLIEGO DE PRESCRIPCIONES TECNICAS TITULO: SERVICIO DE SOPORTE A USUARIOS DEL SISTEMA BAS CLAVE: INF.05.020 Expediente nº INF.05.020 Página 1 de 10 1 INTRODUCCIÓN Y ANTECEDENTES La Empresa Pública de Puertos

Más detalles

Diseño e implementación de un sistema de información basado en Servicios Web para la gestión de ofertas de empleo y candidatos ANEXOS

Diseño e implementación de un sistema de información basado en Servicios Web para la gestión de ofertas de empleo y candidatos ANEXOS Proyecto Fin de Carrera Ingeniería Informática Diseño e implementación de un sistema de información basado en Servicios Web para la gestión de ofertas de empleo y candidatos ANEXOS Autor: Mariola Valiente

Más detalles

REQUISITOS PARA EL USO DEL REGISTRO ELECTRÓNICO

REQUISITOS PARA EL USO DEL REGISTRO ELECTRÓNICO REQUISITOS PARA EL USO DEL REGISTRO ELECTRÓNICO TABLA DE CONTENIDOS 1. N A V E G A D O R E S S O P O R T A D O S.................................. 3 2. S I S T E M A S O P E R A T I V O S........................................

Más detalles

Sistema de gestión de procesos institucionales y documental.

Sistema de gestión de procesos institucionales y documental. [Documento versión 1.7 del 10/10/2015] Sistema de gestión de procesos institucionales y documental. El sistema de gestión de procesos institucionales y documental, es una solución diseñada para mejorar

Más detalles

PERFIL TÉCNICO CONSULTOR SHAREPOINT PARA LA WEB

PERFIL TÉCNICO CONSULTOR SHAREPOINT PARA LA WEB PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA CONTRATACIÓN DE LA CONSULTORÍA Y ASISTENCIA PARA LOS PROYECTOS WEB EN EL TRIBUNAL CONSTITUCIONAL PERFIL TÉCNICO CONSULTOR SHAREPOINT PARA LA WEB 1 Índice Antecedentes...

Más detalles

SERVICIOS DE DESARROLLO SOFTWARE PARA APLICACIONES WEB DE INTECO

SERVICIOS DE DESARROLLO SOFTWARE PARA APLICACIONES WEB DE INTECO SERVICIOS DE DESARROLLO SOFTWARE PARA APLICACIONES WEB DE INTECO PLIEGO DE CARACTERÍSTICAS TÉCNICAS SEPTIEMBRE 2014 PCT. Expediente 076/14. Servicio de desarrollos de software para aplicaciones web de

Más detalles

PERFIL TÉCNICO ANALISTA-PROGRAMADOR

PERFIL TÉCNICO ANALISTA-PROGRAMADOR PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA CONTRATACIÓN DE LA CONSULTORÍA Y ASISTENCIA PARA LOS PROYECTOS WEB EN EL TRIBUNAL CONSTITUCIONAL PERFIL TÉCNICO ANALISTA-PROGRAMADOR 1 Índice Antecedentes... 3

Más detalles

Administración Local Soluciones

Administración Local Soluciones SISTEMA INTEGRADO DE GESTIÓN DE EXPEDIENTES MODULAR (SIGM) MANUAL INSTALACIÓN AL SIGM SIGM v3 Administración Local Soluciones Control de versiones Versión Fecha aprobación Cambio producido Autor 1.0 Octubre

Más detalles

CUALIFICACIÓN ADMINISTRACIÓN DE SERVICIOS DE INTERNET PROFESIONAL. Nivel 3. Versión 5 Situación RD 1087/2005 Actualización

CUALIFICACIÓN ADMINISTRACIÓN DE SERVICIOS DE INTERNET PROFESIONAL. Nivel 3. Versión 5 Situación RD 1087/2005 Actualización Página 1 de 23 CUALIFICACIÓN ADMINISTRACIÓN DE SERVICIOS DE INTERNET PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC156_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

Especificación de Requisitos del Sistema de Registro y Control de Bienes Muebles de la ULA (ULA_SRCBM, versión 1.0)

Especificación de Requisitos del Sistema de Registro y Control de Bienes Muebles de la ULA (ULA_SRCBM, versión 1.0) Proyecto: Actualización del Sistema de Información de Muebles Documento: Especificación de s del Sistema de Registro y Control de Muebles ULA (ULA_SRCBM, versión 1.0) Elaborado por: William J. Montilva

Más detalles

FOREST BPMS. Arquitectura Forest BPMS. Metodologia de implementación. Fase I Instalación

FOREST BPMS. Arquitectura Forest BPMS. Metodologia de implementación. Fase I Instalación FOREST BPMS Arquitectura Forest BPMS Metodologia de implementación Fase I Instalación 1. Instalación del sistema de información Forest en los servidores provistos por la entidad Entregable: Documento de

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

Tema 4: Diseño de flujos interaplicación

Tema 4: Diseño de flujos interaplicación Tema 4: Diseño de flujos interaplicación 4.1 Introducción a los Sistemas EAI Modelo de referencia (1) INTEGRACIÓN B2B INTEGRACIÓN DE APLICACIONES Y PROCESOS INTEGRACIÓN DE DATOS INTEGRACIÓN DE PLATAFORMA

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

COMUNICACIÓN TECNIMAP SEDE ELECTRÓNICA DEL MINISTERIO DE MEDIO AMBIENTE, Y MEDIO RURAL Y MARINO

COMUNICACIÓN TECNIMAP SEDE ELECTRÓNICA DEL MINISTERIO DE MEDIO AMBIENTE, Y MEDIO RURAL Y MARINO COMUNICACIÓN TECNIMAP SEDE ELECTRÓNICA DEL MINISTERIO DE MEDIO AMBIENTE, Y MEDIO RURAL Y MARINO ÍNDICE 1 INTRODUCCIÓN... 1 2 ARQUITECTURA TECNOLÓGICA DEL MARM... 2 2.1 ARQUITECTURA DE SEDE ELECTRÓNICA...3

Más detalles

CONSEJERÍA DE EMPLEO. Secretaría General Técnica

CONSEJERÍA DE EMPLEO. Secretaría General Técnica PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA EL APOYO A LA ADMINISTRACIÓN DE SERVIDORES DE BASE DE DATOS ORACLE Y MÁQUINAS SERVIDORAS CON SISTEMA OPERATIVO UNIX DE LA CONSEJERÍA DE EMPLEO DE LA JUNTA DE ANDALUCÍA

Más detalles

Proyecto Final de Carrera

Proyecto Final de Carrera Aplicación de gestión de proyectos informáticos Memoria del Proyecto Consultor: Jairo Sarrias Guzmán Ingeniería Técnica Informática de Gestión P á g i n a 2 CONTENIDO 1. Introducción... 6 1.1. Resumen...

Más detalles

1. ÁMBITO Y OBJETO DEL PLIEGO.

1. ÁMBITO Y OBJETO DEL PLIEGO. PLIEGO DE PRESCRIPCIONES TÉCNICAS PARTICULARES PARA LA CONTRATACIÓN DE SERVICIOS DE SOPORTE, MANTENIMIENTO Y NUEVOS DESARROLLOS DE LAS APLICACIONES DEL SISTEMA DE GESTIÓN DE PROGRAMAS Y PROYECTOS DEL CENTRO

Más detalles

Sage CRM. 7.2 Guía de autoservicio

Sage CRM. 7.2 Guía de autoservicio Sage CRM 7.2 Guía de autoservicio Copyright 2013 Sage Technologies Limited, editor de este trabajo. Todos los derechos reservados. Quedan prohibidos la copia, el fotocopiado, la reproducción, la traducción,

Más detalles

Implantación de Aplicaciones Web Fecha: 20-09-13

Implantación de Aplicaciones Web Fecha: 20-09-13 Página 1 de 24 RESUMEN DE LA PROGRAMACIÓN ADMINISTRACIÓN DE SISTEMAS INFORMÁTICOS EN RED CURSO AC. 2012 / 2013 ÁREA / MATERIA / MÓDULO PROFESIONAL Implantación de Aplicaciones Web (84 horas 4 horas semanales)

Más detalles

PROCEDIMIENTOS PARA LA INSTALACIÓN DEL SOFTWARE SISTEMA RED. Junio 2010 MINISTERIO DE TRABAJO E INMIGRACIÓN TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

PROCEDIMIENTOS PARA LA INSTALACIÓN DEL SOFTWARE SISTEMA RED. Junio 2010 MINISTERIO DE TRABAJO E INMIGRACIÓN TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL SUBDIRECCIÓN GENERAL DE RECAUDACIÓN PROCEDIMIENTOS PARA LA INSTALACIÓN DEL SOFTWARE SISTEMA RED Junio 2010 MINISTERIO DE TRABAJO E INMIGRACIÓN TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL INDICE 1 INTRODUCCIÓN...

Más detalles

Nº Pliego/Expte: TIC-0056/2013 Elemento PEP: G0000/001-2013

Nº Pliego/Expte: TIC-0056/2013 Elemento PEP: G0000/001-2013 PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA CONTRATACIÓN DEL SERVICIO DE IMPLANTACIÓN DE UN SISTEMA DE GESTIÓN INTEGRAL DE LA INFORMACIÓN EN CÁMARA VALENCIA. Nº Pliego/Expte: TIC-0056/2013 Elemento PEP:

Más detalles

SMS Marketing. Manual de usuario. By DIDIMO Servicios Móviles

SMS Marketing. Manual de usuario. By DIDIMO Servicios Móviles SMS Marketing Manual de usuario By DIDIMO Servicios Móviles Manual de usuario SMS Marketing Madrid Network Marketplace INDICE INDICE... 2 1 QUÉ ES SMS MARKETING?... 3 2 MENÚ PRINCIPAL... 4 2.1 CAMPAÑAS...4

Más detalles

MANUAL DE INSTALACIÓN DEL CLIENTE @FIRMA

MANUAL DE INSTALACIÓN DEL CLIENTE @FIRMA Instituto Andaluz de Administración Pública CONSEJERÍA DE HACIENDA Y ADMINISTRACIÓN PÚBLICA MANUAL DE INSTALACIÓN Fecha: 13/12/2011 Queda prohibido cualquier tipo de explotación y, en particular, la reproducción,

Más detalles

PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE REGIRÁ LA REALIZACIÓN DEL CONTRATO DE

PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE REGIRÁ LA REALIZACIÓN DEL CONTRATO DE PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE REGIRÁ LA REALIZACIÓN DEL CONTRATO DE SERVICIO DE DESARROLLO Y MANTENIMIENTO PARA LA EVOLUCIÓN DE PORTALES DE RED.ES PROCEDIMIENTO ABIERTO Observaciones Página 1/52

Más detalles

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1. Cliente: FCM-UNA Página 1 de 14 PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA Cliente: FCM-UNA Página 2 de 14 Tabla de contenido 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. ALCANCE 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

CONTRATACIÓN DEL DESARROLLO DE NUEVAS FUNCIONALIDADES PARA LA PLATAFORMA DE NOTIFICACIONES POSTALES Y ENVÍO DE SMS

CONTRATACIÓN DEL DESARROLLO DE NUEVAS FUNCIONALIDADES PARA LA PLATAFORMA DE NOTIFICACIONES POSTALES Y ENVÍO DE SMS CONTRATACIÓN DEL DESARROLLO DE NUEVAS FUNCIONALIDADES PARA LA PLATAFORMA DE NOTIFICACIONES POSTALES Y ENVÍO DE SMS PLIEGO DE CONDICIONES DE CONTRATACIÓN 1 1 Antecedentes Lanbide, Servicio Vasco de Empleo,

Más detalles

PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE HA DE SERVIR DE BASE PARA MODERNIZACIÓN WEB MUNICIPAL

PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE HA DE SERVIR DE BASE PARA MODERNIZACIÓN WEB MUNICIPAL PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE HA DE SERVIR DE BASE PARA MODERNIZACIÓN WEB MUNICIPAL 1 1.- OBJETO DEL CONTRATO Constituye objeto del presente pliego adjudicar la contratación de una inversión nueva

Más detalles

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software.

TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. . TEMA 37: Arquitecturas Cliente / Servidor. Tipos de cliente. Tipos de Servidor. Clasificación del software. Índice 1 INTRODUCCIÓN 2 2 CARACTERÍSTICAS 2 2.1 Características del cliente...2 2.2 Características

Más detalles

Centro de Interoperabilidad Semántica y Sistema de Gestión de Mensajes de Intercambio

Centro de Interoperabilidad Semántica y Sistema de Gestión de Mensajes de Intercambio Centro de Interoperabilidad Semántica y Sistema de Gestión de Mensajes de Intercambio Francisco José Martín Lázaro franciscojose.martin@map.es Consejero Tecnológico de Normas de Tecnología. Ministerio

Más detalles

Sistema de Creación de Trámites Web 2.0 del Consejo Superior de Investigaciones Científicas

Sistema de Creación de Trámites Web 2.0 del Consejo Superior de Investigaciones Científicas Sistema de Creación de Trámites Web 2.0 del Consejo Superior de Investigaciones Científicas Clara Cala Rivero Sistema de Creación de Trámites Web 2.0 del Consejo Superior de Investigaciones Científicas

Más detalles

Intranet Corporativa (SharePoint 2013)

Intranet Corporativa (SharePoint 2013) www.uoc.edu PFC- Memoria Proyecto final de carrera Intranet Corporativa (SharePoint 2013) Consultor: Juan Carlos González Martín Junio 2013 A todos los que confiaron en que llegaría hasta aquí Resumen

Más detalles

PLIEGO DE PRESCRIPCIONES TÉCNICAS ÍNDICE 1. OBJETO... 2 2. ANTECEDENTES Y SITUACIÓN ACTUAL... 2

PLIEGO DE PRESCRIPCIONES TÉCNICAS ÍNDICE 1. OBJETO... 2 2. ANTECEDENTES Y SITUACIÓN ACTUAL... 2 PROCEDIMIENTO NEGOCIADO SIN PUBLICIDAD PARA LA ADJUDICACIÓN DEL CONTRATO DE SERVICIOS PARA EL DESARROLLO DE COMPONENTES PARA LAS APLICACIONES DE ADMINISTRACIÓN ELECTRÓNICA DEL SENADO PLIEGO DE PRESCRIPCIONES

Más detalles

SIOM-Interfaz AM Manual de Usuario

SIOM-Interfaz AM Manual de Usuario SIOM-Interfaz AM Manual de Usuario Alfonso XI, 6 28014 Madrid F(+34) 91 524 03 96 www.omie.es Ref. MU_InterfazAM.doc Versión 5.0 Fecha: 2014-09-10 ÍNDICE 1 INTRODUCCIÓN 3 2 REQUISITOS PREVIOS 4 2.1 COMPONENTES

Más detalles

ASUNTO: PLIEGO DE PRESCRIPCIONES TECNICAS PARTICULARES PARA LA CONTRATACIÓN DEL DESARROLLO DE LA SOCIALIZACIÓN EN LA WEB MUNICIPAL

ASUNTO: PLIEGO DE PRESCRIPCIONES TECNICAS PARTICULARES PARA LA CONTRATACIÓN DEL DESARROLLO DE LA SOCIALIZACIÓN EN LA WEB MUNICIPAL ASUNTO: PLIEGO DE PRESCRIPCIONES TECNICAS PARTICULARES PARA LA CONTRATACIÓN DEL DESARROLLO DE LA SOCIALIZACIÓN EN LA WEB MUNICIPAL ÍNDICE ÍNDICE...2 OBJETO DEL CONTRATO...3 SITUACIÓN ACTUAL...3 DESCRIPCIÓN

Más detalles

Capítulo V. Implementación

Capítulo V. Implementación Capítulo V Implementación En este capítulo se especifican los recursos utilizados en la implementación de la interfaz, así como se describe su arquitectura funcional y las características principales.

Más detalles

Historia de revisiones

Historia de revisiones Binary Rain Glosario Versión 1.1 Historia de revisiones Fecha Versión Descripción Autor 17/08/2012 1.0 Creación del documento Carolina Trias 18/08/2012 1.1 Revisado y corregido por SQA Mercedes Marzoa

Más detalles

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

Más detalles

REQUISITOS PARA EL USO DEL REGISTRO ELECTRÓNICO

REQUISITOS PARA EL USO DEL REGISTRO ELECTRÓNICO REQUISITOS PARA EL USO DEL REGISTRO ELECTRÓNICO TABLA DE CONTENIDOS 1. N AVEGADORES SOPORTADOS... 2. R EQUISITOS GENERALES... 2.1 Certificado digital... 3 2.2 Acceso a los puertos 8443 y 8444... 3 2.3

Más detalles

Servicios informáticos para la instalación y adaptación del SDM a la versión R14.1 Pliego de prescripciones técnicas

Servicios informáticos para la instalación y adaptación del SDM a la versión R14.1 Pliego de prescripciones técnicas Dirección General de Servicios Septiembre de 2015 Servicios informáticos para la instalación y adaptación del SDM a la versión R14.1 Pliego de prescripciones técnicas Sistemas de Información Índice 1 Objeto

Más detalles

Máster en Instalación, Gestión y Mantenimiento de CRM: Gestión de Relaciones con Clientes

Máster en Instalación, Gestión y Mantenimiento de CRM: Gestión de Relaciones con Clientes Máster en Instalación, Gestión y Mantenimiento de CRM: Gestión de Relaciones con Clientes Titulación certificada por EUROINNOVA BUSINESS SCHOOL Máster en Instalación, Gestión y Mantenimiento de CRM: Gestión

Más detalles

Despliegue de plataforma Q-expeditive

Despliegue de plataforma Q-expeditive How to Despliegue de plataforma Q-expeditive Versión: 2.0 Fecha de publicación 08-04-2011 Aplica a: Q-expeditive 3.0 y Q-flow 3.1 Índice Requerimientos de Software... 4 Diagramas de arquitectura... 5 Componentes

Más detalles

El tramitador común. el Ministerio de Educación

El tramitador común. el Ministerio de Educación El tramitador común del Ministerio de Educación En el presente artículo se describe la plataforma tecnológica del Ministerio de Educación que ha sido desarrollada para ofrecer unos servicios comunes de

Más detalles

ATLAS MANUAL DE USUARIO DEL ARQUETIPO WEB PARA PROYECTOS NEXUS

ATLAS MANUAL DE USUARIO DEL ARQUETIPO WEB PARA PROYECTOS NEXUS ATLAS MANUAL DE USUARIO DEL ARQUETIPO WEB PARA PROYECTOS NEXUS Versión 1.1 Área de Aplicaciones Especiales y Arquitectura de Software Hoja de Control Título Documento de Referencia Responsable Manual de

Más detalles

Requerimientos Documentales. Sistemas de Información

Requerimientos Documentales. Sistemas de Información Requerimientos Documentales Sistemas de Información Índice de contenido Objetivo... 3 Alcance... 3 Recepción de Aplicaciones... 3 Tipos de documentación... 3 Documentación de soporte (DS)... 3 Documentación

Más detalles

Unicenter Asset Management versión 4.0

Unicenter Asset Management versión 4.0 D A T A S H E E T Unicenter Asset Management versión 4.0 Unicenter Asset Management es una completa solución para gestionar los activos TI de su entorno empresarial de forma activa. Proporciona funciones

Más detalles

Certificado de Profesionalidad DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB [Nivel 3]

Certificado de Profesionalidad DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB [Nivel 3] INFORMÁTICA Y COMUNICACIONES Certificado de Profesionalidad DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB [Nivel 3] Desarrollo de aplicaciones con tecnologías web Contenidos I IDENTIFICACIÓN DEL CERTIFICADO

Más detalles

Implantación y Aceptación del Sistema

Implantación y Aceptación del Sistema y Aceptación del Sistema 1 y Aceptación del Sistema ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN...5 Tarea IAS 1.1: De finición del Plan de... 5 Tarea IAS

Más detalles

Factura Electrónica. Un proyecto de facturación electrónica que integra empresas y administraciones

Factura Electrónica. Un proyecto de facturación electrónica que integra empresas y administraciones Factura Electrónica. Un proyecto de facturación electrónica que integra empresas y administraciones Resumen de la Comunicación El proyecto de Facturación electrónica forma parte de los planes del Gobierno

Más detalles

Centro de Excelencia Liferay. Presentación de servicios

Centro de Excelencia Liferay. Presentación de servicios Centro de Excelencia Liferay Presentación de servicios ÍNDICE 1. Alianza 2. Qué es el Centro de Excelencia Liferay? 3. Capacidades del CEL 4. Referencias 5. Catálogo de servicios Alianza Una alianza provechosa

Más detalles