Download desarrollos en java

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