Download desarrollos en java
Document related concepts
no text concepts found
Transcript
Información general Java DESARROLLOS EN JAVA INFORMACION GENERAL Versión 1.3 Septiembre 2009 Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 1 Información general Java CONTROL DE CAMBIOS Fecha Versión Cambios 10/03/2008 1.0 Primera versión del documento 29/04/2008 1.1 Modificado: 6.2 Uso de convenciones en los proyectos Anexo 1: Referencias Anexo 2: Documentación relacionada 15/01/2009 1.2 Modificado: 4 Base de datos 6.11 Otras cuestiones a tener en cuenta 09/09/2009 1.3 Se incluye información sobre las variables de configuración propias de la aplicación Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 2 Información general Java INDICE 1 2 3 INTRODUCCION................................................................................................ 4 PROYECTOS Y MODULOS .............................................................................. 5 ARQUITECTURA DE SISTEMAS .................................................................... 6 3.1 APLICACIONES WEB Y SERVICIOS WEB ................................................ 6 3.2 PROCESOS BATCH ....................................................................................... 7 3.3 LIBRERIAS ..................................................................................................... 8 4 BASE DE DATOS ............................................................................................... 8 5 NAVEGADORES Y POB ................................................................................. 10 6 CARACTERISTICAS DE DESARROLLO DE LOS MÓDULOS .................. 11 6.1 DOCUMENTACION..................................................................................... 11 6.2 USO DE CONVENCIONES EN LOS PROYECTOS .................................. 12 6.3 ESTRUCTURA DE DIRECTORIOS ............................................................ 12 6.4 PAQUETES JAVA ........................................................................................ 13 6.5 CONFIGURACION ....................................................................................... 13 6.6 TRAZABILIDAD .......................................................................................... 14 6.7 AUDITORÍA DE SEGURIDAD ................................................................... 14 6.8 GESTION DE EXCEPCIONES..................................................................... 15 6.9 CERTIFICADOS DIGITALES – PLATAFORMA MULTI PKI ASF ......... 15 6.10 LIBRERIAS HOMOLOGADAS ................................................................... 16 6.11 OTRAS CUESTIONES A TENER EN CUENTA ........................................ 17 6.12 PLAN DE PRUEBAS .................................................................................... 18 7 PLANTILLAS .................................................................................................... 18 8 ENTREGAS ....................................................................................................... 19 9 ANEXO 1: REFERENCIAS .............................................................................. 20 10 ANEXO 2: DOCUMENTACION RELACIONADA........................................ 20 Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 3 Información general Java 1 INTRODUCCION Este documento presenta la información general necesaria para la implementación de componentes software que se desarrollen para la Comunidad de Madrid. REQUISITOS Los componentes software que se pueden desarrollar en Java son: • Aplicaciones web • Servicios web • Procesos batch • Librerías Toda la documentación relacionada con los desarrollos se encuentra accesible en la web de la Unidad de Arquitectura de Aplicaciones en la url: https://gestiona.madrid.org/soja_int. Esta web es el canal de comunicación de la Unidad de Arquitectura de Aplicaciones hacia los proveedores. Aparte de documentación también se pueden encontrar las ultimas versiones de las librerías, plantillas, etc. Cada vez que se publica algo en la web se incluye una noticia indicando la actualización que se ha realizado. El proveedor por lo tanto tiene la responsabilidad de conectarse asiduamente a esta web para estar al corriente de las modificaciones. Esta web es de acceso restringido a los proveedores que colaboran con ICM. El acceso a esta web debe ser solicitado por el proveedor al jefe de proyecto. Las consultas relacionadas con el desarrollo de aplicaciones se deben dirigir a la Unidad de Arquitectura de Aplicaciones a través de la web en el apartado Contactar/Mensaje a Arquitectura. Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 4 Información general Java 2 PROYECTOS Y MODULOS Cada desarrollo debe estar comprendido dentro de un proyecto identificado por cuatro letras, dicho proyecto a su vez estará organizado en uno o más módulos. Al principio de cada desarrollo tanto el proyecto como sus módulos deben de estar dados de alta en Midax (herramienta interna para la gestión del conocimiento) Dependiendo del tipo de módulo se debe seguir la siguiente nomenclatura: Modelo de datos: xxxx_modd xxxx se corresponde con el código de proyecto Ejemplo: ejpl_modd Aplicación web: xxxx_yyyy xxxx se corresponde con el código de proyecto yyyy es un sufijo que identifica lo más claramente posible al módulo REQUISITOS Ejemplo: ejpl_pub Webservice: xxxx_ws_[yyyy] xxxx se corresponde con el código de proyecto yyyy es un sufijo que identifica lo más claramente posible al módulo Ejemplo: ejpl_ws; ejpl_ws_envio; ejpl_ws_recep Procesos batch: xxxx_batch_[yyyy] xxxx se corresponde con el código de proyecto yyyy es un sufijo que identifica lo más claramente posible al módulo Ejemplo: ejpl_batch; ejpl_batch_envio Librerías de clases: xxxx_lib_[yyyy] xxxx se corresponde con el código de proyecto yyyy es un sufijo que identifica lo más claramente posible al módulo Ejemplo: ejpl_lib; ejpl_lib_util Nota: La nomenclatura del proyecto debe ser establecida al comienzo del mismo ya que determina tanto la nomenclatura de los módulos como de las tablas del esquema de base de datos que va a utilizar. Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 5 Información general Java ARQUITECTURA DE SISTEMAS REQUISITOS 3 Los módulos no deben usar funcionalidades o tecnologías dependientes del sistema operativo sin la previa aprobación de ICM. En concreto, los módulos deberán soportar los sistemas operativos Linux (RedHat 3.0), Solaris y Windows2000, aunque en producción las aplicaciones se ejecutarán sobre Linux (RedHat 3.0). Dependiendo del tipo de módulo que se vaya a desarrollar se deben tener las siguientes consideraciones con respecto a la arquitectura de sistemas: 3.1 APLICACIONES WEB Y SERVICIOS WEB Las aplicaciones web y los servicios web deberán desarrollarse teniendo en cuenta que en el entorno de producción podrán ser desplegadas en modo cluster, tanto en varias instancias de un mismo o diferentes servidores de aplicaciones. De esta arquitectura se desprenden los siguientes requisitos a tener en cuenta en el desarrollo de las aplicaciones: REQUISITOS • Minimizar el uso de la sesión. o No incluir en sesión colecciones de objetos. o El tamaño de la sesión nunca podrá exceder los límites que ICM defina en base a la arquitectura de sistemas. • Los ficheros generados por las aplicaciones y que se necesiten dejar en disco se ubicarán según se indique en un parámetro del fichero de configuración. Esta ubicación corresponderá con un directorio compartido por las distintas maquinas que compongan el cluster. • Las aplicaciones se van a ejecutar en varias maquinas virtuales por lo tanto los objetos que se dejen en la memoria de la maquina virtual no estarán replicados en las diferentes instancias. • En este tipo de aplicaciones no está permitida la creación de nuevos hilos o threads. Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 6 Información general Java 3.2 PROCESOS BATCH REQUISITOS Vamos a distinguir entre dos tipos de procesos batch: • Jobs de Oracle: Cuando el código de ejecución en batch se puede implementar en plsql. • Procesos batch en Java: Los procesos batch en Java se van a ejecutar desde el planificador Control M y no se va a ejecutar bajo demanda del usuario sino mediante una planificación. Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 7 Información general Java 3.3 LIBRERIAS REQUISITOS Cuando dos módulos comparten algunas clases (código java) es necesario crear un nuevo módulo que es una librería de clases que se incluirá en cada uno de los módulos que se requiera. Las librerías que se desarrollen para un proyecto deben cumplir los requisitos del tipo de módulo donde se van a ejecutar. Siempre se deberán entregar como un módulo con su código fuente. En los módulos que utilicen una librería desarrollada se debe indicar que usa dicha librería en la ficha de entrega. 4 BASE DE DATOS Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 8 Información general Java REQUISITOS Las aplicaciones utilizarán Oracle 9i como repositorio de información teniendo en cuenta los siguientes requisitos: • La base de datos funcionará en modo costes. • La definición del acceso a base de datos se realizará en el fichero de configuración de la aplicación. En el caso de aplicaciones web y servicios web se utilizará el datasource del servidor de aplicaciones. • Las sentencias SQL de las aplicaciones estarán escritas en SQL estándar para evitar al máximo las dependencias con el gestor de base de datos. No obstante, si por razones de rendimiento o funcionalidad fuera necesario utilizar sintaxis propia de Oracle, su uso deberá ser consultado previamente a ICM. • El modelo de datos deberá ser entregado mediante la herramienta Erwin y seguir los requisitos de diseño y nomenclatura de ICM. • Para optimizar las sentencias SQL es imprescindible que se utilice el mecanismo de PreparedStatement de JDBC y se realice correctamente el binding de las variables de la sentencia. • Las llamadas a los métodos de la clase CallableStatement deben hacerse sin parámetros, para evitar problemas de cursores abiertos. • En el caso de módulos de procesos batch en java hay que utilizar directamente la librería de JDBC en su versión 1.4. Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 9 • Siempre se deben cerrar los cursores abiertos. • Solamente se podrán utilizar sentencias sql o código de acceso a datos en las clases DAO (Data Access Object) • No se podrán utilizar sentencias SQL- DML ni SQL- DDL desde el código. • No se permiten realizar actualizaciones en tablas de catálogos generales de ICM (Por ejemplo: SUCA, CATA, etc) • El acceso a tablas remotas se debe hacer mediante sinonimos remotos y no por database link. • En el caso de utilizar una sentencia SELECT FOR UPDATE se hará con la clausula NO WAIT. • No se deben utilizar las sentencias SELECT * en su lugar se incluirán los nombre de los campos que en realidad se van a consultar. 5 NAVEGADORES Y POB REQUISITOS REQUISITOS Información general Java Los módulos de aplicaciones web deben de ser compatibles con la versiones de Navegador Internet Explorer 6.0 o superior y Mozilla Firefox 1.4 o superior. Los módulos que se desarrollen para los usuarios de la Intranet deben funcionar correctamente con el POB (Puesto ofimático básico) que tienen instalado en su PC . Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 10 Información general Java 6 CARACTERISTICAS DE DESARROLLO DE LOS MÓDULOS 6.1 DOCUMENTACION Todas las clases Java de las aplicaciones deberán incluir tanto en sus métodos como en sus propiedades las correspondientes etiquetas de Javadoc que permitan generar la documentación correspondiente. El porcentaje de javadoc que se debe incluir es del 100%. Además se deberán entregar los correspondientes documentos de análisis que el Área de Proyectos de Desarrollo requiera. REQUISITOS Por otra parte se deben incluir los siguientes documentos: • Informe de accesos: Este informe debe describir las estimaciones de ancho de banda por puesto y globales de la aplicación en función de uso de la misma a lo largo del día. ICM revisará este documento a fin de ajustar dichas estimaciones a la arquitectura de comunicaciones en la que se desplegarán las aplicaciones. • Informe de uso de sesión y contexto: Este informe debe contener la descripción de los datos incluidos en sesión y en contexto y su tamaño. También se indicara el número máximo de usuarios concurrentes en la aplicación. • Plan de pruebas: Se deberá elaborar un documento de pruebas que deberá reflejar tipos de pruebas a realizar: • Pruebas unitarias • Pruebas de integración • Pruebas funcionales y de aceptación • Pruebas de carga y stress Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 11 Información general Java 6.2 USO DE CONVENCIONES EN LOS PROYECTOS Un estándar de codificación adecuado y buen diseño orientado a objetos son prácticas que deben estar presentes en todos los proyectos. Es necesario imponer una normalización a la hora de desarrollar código debido a diferentes factores que nos van a influir en nuestra facilidad de mantenimiento posterior y costes económicos derivados de tal actividad. • Un porcentaje elevado del coste del software va asociado a su mantenimiento. • Las aplicaciones son dinámicas, crecen y se modifican, requieren de mantenimiento y evolución. • Las convenciones de código nos facilitarán la interpretación fácil de nuestro código, más rápida y más clara. • Debemos pues garantizar el cumplimiento con estas convenciones. Se deben utilizar las convenciones de código para el lenguaje de programación Java de SUN Microsystems. REQUISITOS Estas convenciones están disponibles en la url: http://java.sun.com/docs/codeconv/ Para el chequeo de estas convenciones se utilizaran los siguientes plugins de Eclipse: - Checkstyle - PMD En la web de soja en el apartado Area de Aseguramiento de la Calidad/ Recursos adicionales se incluyen los ficheros de reglas para estos plugins. El documento Validación de normas de codificación de código java explica como incorporar estos ficheros de reglas a estos plugins. 6.3 ESTRUCTURA DE DIRECTORIOS Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 12 REQUISITOS Información general Java REQUISITOS 6.4 REQUISITOS 6.5 La estructura de directorios es la definida en la plantillas de cada uno de los tipos de módulos. Por lo tanto el proveedor debe asegurarse que antes de realizar una entrega dispone de la ultima versión de la plantilla correspondiente. Alguna de las plantillas incorporan páginas html e imágenes que son ejemplos de aplicación y por lo tanto no se deben dejar en la aplicación que se entregue. Se deben eliminar aquellos ficheros que no son necesarios para la aplicación. PAQUETES JAVA Dependiendo del tipo de módulo que se vaya a desarrollar la estructura de los paquetes va a ser distinta por lo tanto se debe utilizar la estructura de paquetes indicada en cada uno de los documentos de arquitectura de cada tipo de módulos. CONFIGURACION • Las aplicaciones tendrán un único fichero de configuración. Este fichero se debe llamar igual que el nombre de la aplicación. • La ubicación del fichero de configuración dependerá del tipo de módulo que estemos desarrollando. • El fichero de configuración no contendrá información que suponga riesgo de seguridad como por ejemplo claves no cifradas. • En este fichero de configuración habrá propiedades comunes a todas las aplicaciones y propiedades propias de la aplicación. En este ultimo caso las variables del fichero de configuración deben comenzar con el nombre de la aplicación. Las variables propias de la aplicación deberán venir con un comentario descriptivo. Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 13 Información general Java 6.6 TRAZABILIDAD Las aplicaciones deberán tener presente el cumplimiento de los siguientes requisitos de trazabilidad: Existirá un archivo log por aplicación, especificándose el nombre de dicho archivo en el fichero de configuración. • Las trazas no podrán mostrar cierto tipo de información como: REQUISITOS • 6.7 o Información que suponga un riesgo de seguridad como claves utilizadas por los usuarios, claves de acceso a otros sistemas como bases de datos, etc. o Información que viole la Ley Orgánica de Protección de Datos (LOPD) como datos que identifiquen menores, intervinientes, etc. • Mediante parámetros de configuración las aplicaciones podrán activar un nivel de trazado y un tipo de trazas. • Cuando se produzca una excepción se deberá dejar una traza extendida de la excepción en el fichero de log. • Nunca se dejarán trazas en la salida estándar. AUDITORÍA DE SEGURIDAD Las aplicaciones que accedan a datos de alto nivel de seguridad deberán implementar los mecanismos necesarios para que se registren los distintos accesos de los usuarios. REQUISITOS El modelo de datos donde se registran los accesos ya existe. En el documento de Trazabilidad de Alto Nivel de Seguridad se explica en detalle este modelo. Para el acceso a este modelo de datos se han predefinido una serie de paquetes y triggers que son invocados cuando se realiza alguna operación de INSERT, UPDATE o DELETE en la base de datos de la aplicación. En el caso de consultas de tipo SELECT es necesario llamar directamente a los paquetes preparados para dejar este tipo de trazas. Este tipo de aplicaciones deberán utilizar el protocolo https. Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 14 Información general Java 6.8 GESTION DE EXCEPCIONES REQUISITOS En todo momento las excepciones deben ser capturas y tratadas. Cuando una excepción es capturada y se trata de una excepción que no está controlada se deberá dejar en el fichero de log la traza extendida de la excepción para que sea mas fácil la identificación del error que ha provocado que se lance la excepción. La aplicación no debe devolver por pantalla directamente mensajes de excepciones que no están controladas, por ejemplo SQLException, NullPointerException, etc. En su lugar debe recibir un mensaje que le avise de que se ha producido un error. Se deben evitar bloques try/catch muy grandes ya que en caso de producirse una excepción va a ser mas difícil identificarla. 6.9 CERTIFICADOS DIGITALES – PLATAFORMA MULTI PKI ASF REQUISITOS Las aplicaciones que requieran el uso de certificados digitales utilizaran la plataforma ASF. Esta plataforma nos ofrece las operaciones de: • Consulta de datos del certificado • Validación • Firma digital en cliente • Firma digital en servidor • Cifrado en cliente • Cifrado en servidor Para que las aplicaciones puedan hacer uso de esta librería es necesario solicitar el alta de la aplicación en la plataforma. Para ello se enviará un mensaje a través de la web de soja a la Unidad de Arquitectura de Aplicaciones, indicando el código de la aplicación y las operaciones que va a realizar. Las aplicaciones deberán incluir una serie de librerías cliente para que la aplicación pueda interactuar con la plataforma ASF. Estas librerías se encuentran especificadas en el documento Librerías Homologadas para el framework correspondiente. Las plantillas de aplicaciones que lo necesiten ya llevan incorporadas estas librerías. Por otra parte existen unos ficheros de configuración propios de ASF que se deben incluir en la carpeta propertyFiles dentro del directorio classes de las aplicaciones. Igualmente en el Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 15 Información general Java documento Librerías Homologadas existe más información sobre estos ficheros de configuración. Cuando el proveedor trabaja en sus instalaciones no dispone de esta plataforma y entonces se puede actuar de dos formas: • • Solicitar acceso a la maquina icmifirma01, esta maquina es una maquina de ICM de desarrollo que se encuentra en Internet y a la que solamente pueden acceder la ip’s autorizadas. El acceso a esta maquina se hace a través de la web de soja indicando en el correo la ip y nombre de la empresa que solicita el acceso. Esta ip debe ser la ip desde la que sale a Internet, esto hay que tenerlo en cuenta si se tiene un Proxy. Dejar las pruebas de integración con la plataforma ASF para cuando se realice la entrega a nuestro entorno de desarrollo. REQUISITOS 6.10 LIBRERIAS HOMOLOGADAS Solo se podrán utilizar aquellas librerías homologadas por ICM para un determinado framework. Para cada framework se incluye un documento llamado Librerías homologadas que incluye la lista de librerías y su forma de utilización. El uso de cualquier nueva tecnología, producto, librería o componente, no homologado y que se desee incorporar a un módulo deberá ser autorizado previamente por ICM. Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 16 Información general Java 6.11 OTRAS CUESTIONES A TENER EN CUENTA REQUISITOS A continuación se incluyen algunas cuestiones a tener en cuenta a la hora de realizar los desarrollos: • Nunca se debe invocar directamente la Garbage Collector de la maquina virtual java. • Las páginas html, jsp, etc no deben incluir enlaces rotos o erróneos. • No deben existir URLs absolutas en el código y páginas. • No deben existir direcciones de correo en el código y páginas. • No deben existir valores estáticos en el código: cadenas, DNIs, nombres… • No debe existir un retardo explicito en el código (sleep). Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 17 Información general Java 6.12 PLAN DE PRUEBAS El proveedor deberá elaborar un plan de pruebas. Este plan de pruebas deberá ejecutarlo en sus instalaciones antes de realizar la entrega del proyecto. REQUISITOS A continuación se describen los principales tipos de pruebas que deberán ser realizados y ejecutados, a saber: • Pruebas unitarias: El objetivo de estas pruebas es asegurar que cada componente software se ejecuta bajo las precondiciones y post-condiciones esperadas. Para realizar este tipo de pruebas se utilizará JUnit. Las clases de testeo de la aplicación se encontrarán en un directorio distinto a de los fuentes de la aplicación. • Pruebas funcionales: El objetivo de este tipo de pruebas es asegurar que cada elemento de la aplicación concuerda con los requisitos de negocio detallados. Para automatizar este tipo de pruebas se utilizará la herramienta Selenium. El proveedor deberá proporcionar los scripts de Selenium que permitan realizar estas pruebas. • Pruebas de carga y rendimiento: Estas pruebas aseguran que el sistema proporciona tiempos de respuesta adecuados y que se comporte de forma adecuada en momentos pico de trabajo. Este tipo de pruebas se realizarán mediante JMeter. El proveedor deberá entregar los scripts de JMeter necesarios para realizar las pruebas. En la entrega se deberá incluir un documento que explique cuales son las pruebas y como ejecutarlas y el resultado de la ejecución de las mismas en el entorno del proveedor. PLANTILLAS REQUISITOS 7 Todo desarrollo se debe comenzar a partir de las plantillas existentes dependiendo del tipo de framework y del tipo de módulo a desarrollar. En el caso de que ICM actualice las plantillas durante el desarrollo de un módulo y sean publicadas en la web el proveedor deberá actualizar su módulo a la nueva plantilla. Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 18 Información general Java 8 ENTREGAS El proveedor desarrollará los distintos módulos en sus instalaciones y posteriormente realizará la entrega del software desarrollado a la Unidad de Integración de Aplicaciones a través del Jefe de Proyecto. Para realizar una entrega el jefe de proyecto de ICM deberá solicitar a la Unidad de Integración de Aplicaciones una planificación para la instalación. La Unidad de Integración de Aplicaciones dispone de un servidor SFTP para que los proveedores puedan realizar las entregas. REQUISITOS La entrega deberá efectuarse mediante alguno de los siguientes mecanismos: • Entrega de un CD/DVD al jefe de proyecto • Entrega en el directorio del proveedor en el SFTP destinado a tal efecto En cada entrega el proveedor deberá cumplimentar una ficha de instalación (disponible en la web) que deberá enviar al jefe de proyecto para que la revise antes de efectuar la entrega propiamente dicha. La Unidad de Integración de Aplicaciones se encargará de la compilación y despliegue de los distintos módulos entregados sin la asistencia del proveedor, por lo tanto la entrega deberá tener la estructura de directorios exigida y todo el código fuente, librerias, etc necesarios para la compilación del proyecto. Pudiendo desestimarse la instalación si no se cumple lo anterior. A lo largo del ciclo de vida del desarrollo del proyecto es recomendable realizar al menos dos entregas intermedias a ICM, al 30% y 70% del desarrollo. La Unidad de Integración de Aplicaciones emitirá un resumen de la realización de la instalación al jefe de proyecto. Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 19 Información general Java 9 ANEXO 1: REFERENCIAS PRODUCTO 10 URL Ant http://ant.apache.org/ Eclipse http://www.eclipse.org/ MyEclipse http://www.myeclipseide.com/ JMeter http://jakarta.apache.org/jmeter/ Checkstyle http://eclipse-cs.sourceforge.net/ PMD http://pmd.sourceforge.net/ JUnit http://junit.sourceforge.net/ Selenium http://www.openqa.org/selenium/ Erwin Herramienta para el modelado de base de datos ANEXO 2: DOCUMENTACION RELACIONADA Documento Desarrollos general Nombre del fichero java – Información aiaa_java.pdf Validación de normas de codificación de código java aiaa_java_validacion.pdf Framework 2 – Información general aiaa_fw2.pdf Framework 2 – Arquitectura de Aplicaciones web aiaa_fw2_web.pdf Framework 2 – Arquitectura de procesos batch aiaa_fw2_batch.pdf Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 20 Información general Java Documento Framework Justicia - Arquitectura de Aplicaciones web Nombre del fichero aiaa_fjus_web.pdf Subdirección General de Desarrollo, Tecnología e Infraestructuras. Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Área de Integración y Arquitectura de Aplicaciones. Página: 21