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