Guia Estandares V02.01.005

Gua de Estndares
Informtica del Ayuntamiento de

Madrid
Contenido
1
Introduccin...........................................................................................7
Entornos.................................................................................................8
2.1 Entorno de Servidores...................................................................................8

2.1.1
Entorno estndar________________________________________________8
2.1.2
Otros entornos_________________________________________________10
2.2 Entorno de Puesto de Trabajo.....................................................................10

2.3 Herramientas de Soporte.............................................................................10
2.4 Entorno Metodolgico.................................................................................11
Actividades comunes a todos los proyectos...................................12
3.1 Pasos previos...............................................................................................12

3.2 Reunin de inicio.........................................................................................12
3.2.1
Identificacin de Proyectos y Subsistemas___________________________13
3.3 Documentacin de Gestin.........................................................................14

3.4 Planificacin.................................................................................................15
3.4.1
Elaborar plan de proyecto________________________________________15
3.4.2
Creacin de la Lnea Base del proyecto estndar______________________15
3.4.3
Solicitud de la Auditora de planificacin_____________________________15
3.5 Ejecucin y Seguimiento del Proyecto.......................................................16

3.5.1
Actualizacin del Progreso de las Actividades_________________________16
3.6 Criterios de Entrega.....................................................................................16

3.6.1
Entregables___________________________________________________16
3.6.2
Criterios generales de Entregas al IAM______________________________17
3.6.1
Entregas Informales_____________________________________________18
3.6.2
Estructura genrica_____________________________________________18
3.6.3
Generacin de etiquetas_________________________________________19
3.6.4
Poltica de Versionado___________________________________________20
3.7 Poltica de certificados................................................................................21

3.7.1
Certificados admitidos___________________________________________21
3.7.2
Organizacin de los certificados___________________________________21

2
3.7.3
Obtencin de Certificados________________________________________22
3.7.4
Especificidades para las aplicaciones web___________________________23
3.7.5
Especificidades para Servicios Web________________________________24
Proyectos de Desarrollo.....................................................................25
4.1 Estructura.....................................................................................................25
4.1.1
Carpeta Fuentes_______________________________________________25
4.1.2
Carpeta Documentacin_________________________________________29
4.1.3
Carpeta Despliegues____________________________________________31
4.2 Fase ASI........................................................................................................33

4.2.1
Maqueta______________________________________________________33
4.2.2
Interfaz de Servicios Web________________________________________34
4.2.3
Documento / Modelo de Requisitos_________________________________35
4.2.4
Planes de Pruebas Opcionales____________________________________37
4.3 Fase DSI........................................................................................................38

4.3.1
Diseo Arquitectura Lgica_______________________________________38
4.3.2
Modelo de Diseo______________________________________________51
4.3.3
Modelo de Datos_______________________________________________52
4.4 Fase CSI........................................................................................................52

4.4.1
Estrategia de Desarrollo_________________________________________52
4.4.2
Normas de codificacin__________________________________________53
4.4.3
Construccin del Proyecto________________________________________53
4.4.4
Casos de Prueba (fase de Construccin)____________________________54
4.4.5
Manual de Usuario______________________________________________55
4.5 Fase IAS........................................................................................................55
4.5.1
Entornos_____________________________________________________55
4.5.2
Peticiones de despliegue_________________________________________57
4.5.3
Verificacin de la instalacin______________________________________64
Proyectos de Mantenimiento de Aplicaciones.................................66
5.1 Introduccin.................................................................................................66
5.1.1
Estructura y versionado__________________________________________66
5.2 Fases de los proyectos de Mantenimiento................................................66

5.3 Gestin de Peticiones e Incidencias...........................................................67
5.4 Documentacin de Cambios y Requisitos de Calidad..............................67
Proyectos de Prestacin de Servicio................................................69
6.1 Introduccin.................................................................................................69
6.1.1
Estructura y versionado__________________________________________69
6.2 Diseo del Servicio......................................................................................71

6.2.1
Descripcin del servicio__________________________________________71
6.2.2
Formulario del servicio___________________________________________72
6.3 Procedimiento interno del Servicio............................................................72

6.4 Prestacin del servicio................................................................................73
6.4.1
Gestin de incidencias___________________________________________73
6.4.2
Informe de seguimiento__________________________________________73
Proyectos no tipificados.....................................................................74
Solicitud de Cierre...............................................................................75
Plantillas...............................................................................................76
10
Anexos..................................................................................................78
Tablas e Ilustraciones
Ilustracin 1. Ejemplo etiquetas incrementales............................................20
Ilustracin 2. Descripcin almacenes de certificados por entorno................22
Ilustracin 3. Estructura de Carpetas con Subsistemas...............................31
Ilustracin 4. Estructura de la Carpeta Despliegues....................................31
Ilustracin 5. Modelo RSA de Anlisis..........................................................36
Ilustracin 6. Arquitectura Lgica Corporativa..............................................38
Ilustracin 7. Plantilla de diagrama de arquitectura......................................44
Ilustracin 8. Integracin entre Aplicaciones y Componentes Comunes......47
Ilustracin 9. Estructura RSA de diseo.......................................................51
Ilustracin 10. Peticiones de Despliegue.....................................................57
Ilustracin 11. Estructura de Subversion Proyecto Servicios........................70
Tabla 1. Plantillas Genricas........................................................................14

Tabla 2. Nomenclatura de versionado..........................................................20
Tabla 3. Localizacin de los mdulos...........................................................26
Tabla 4. Estructura interna de los mdulos..................................................27
Tabla 5. Localizacin de los fuentes dentro de cada mdulo.......................28
Tabla 6. Plantillas de Entregables de Desarrollo de Software......................30
Tabla 7. Plantillas de Entregables de Despliegue........................................33
Tabla 8. Plantilla Casos de Uso...................................................................37
Tabla 9. Arquitectura en alta disponibilidad..................................................43
Tabla 10. Componentes Comunes...............................................................46
Tabla 11. Caso de prueba en fase de construccin......................................55
Tabla 12. Plantillas de Gestin de Servicios.................................................70
Tabla 13. Plantillas.......................................................................................77
Tabla 14. Anexos..........................................................................................78
5
1 Introduccin
El presente documento tiene por objeto describir los estndares,
herramientas y metodologas que rigen los servicios y desarrollos TIC prestados por
las empresas adjudicatarias de contratos en el Organismo Autnomo Informtica
del Ayuntamiento de Madrid (en adelante, IAM). Esta gua y todos sus anexos se
encuentran publicados en www.madrid.es en la seccin Perfil del contratante
El responsable del contenido de este documento es el Comit de
Estndares del IAM. Cualquier sugerencia o duda, peticin de reunin, reporte de
incompatibilidad del proyecto con las directrices corporativas, o peticin de
adaptacin a casos concretos de los estndares definidos en este documento podr
dirigirse al buzn corporativo iam-estndares@madrid.es.
El presente documento establece unos entregables mnimos y uso comn
de herramientas, estando permitidos cuantos entregables y actividades adicionales
se consideren oportunos desde la jefatura de cada proyecto.
2 Entornos
A continuacin se describe la infraestructura tecnolgica y metodolgica
sobre la que se construyen los Servicios TIC del Organismo.
2.1 Entorno de Servidores

2.1.1
Entorno estndar
La plataforma tecnolgica estndar para el desarrollo de sistemas de

informacin para el Ayuntamiento de Madrid es la siguiente:
2.1.1.1 Sistema Operativo
Windows Server 2003 R2 SP2

Red Hat Enterprise Linux V5.4
Las plataformas hardware estn basadas en tecnologa Intel x64.
2.1.1.2 Servidores Sistemas Abiertos
Servidor Web (entorno Linux):

o
IBM IHS 6.1.0.27 (S.O. Red Hat Enterprise Linux V5.4)
Servidor de Aplicaciones (entorno Windows):

o
IBM Websphere Application

V6.1.0.33 en un entorno cluster
Server
Network
JRE 1. 5. 0 IBM en Windows Server 2003
J2EE 1.4
Deployment
IBM Websphere Application Server Network Deployment V8.0.0.3

en un entorno cluster.
JRE 1.6.0 IBM en Windows Server 2003
Java EE 6
En la reunin de inicio indicada en el punto 3.2, y dependiendo del

tipo de proyecto se decidir si el proyecto se desarrolla en una
versin u otra.
Gestor de Bases de Datos:

8
Gestor de contenidos y portal:

o
TIBCO Bussiness Works 5.7.2 / Policy Manager 3.0.0
Firma y validacin.
o
TIBCO. BussinessWorks 5.7.2
Securizacin:
o
TIBCO iProcess Engine 11.0.2
Workflow: creacin, orquestacin e integracin de servicios

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 travs del Componente
Comn de Archivo Electrnico.
Gestor de Procesos de Negocio (BPM):

o
Vignette V7
Archivo electrnico y documental:

o
Microsoft SQL Server 2005 SP2 (Excepcionalmente, previa

autorizacin del comit de estndares, y en caso de necesitar
usarse Oracle, se utilizar la versin 10.2.0.4)
SIAVAL. 6.2.9 El acceso a esta plataforma por parte de los

proyectos de desarrollo se realizar a travs del Componente
Comn de Firma.
Entorno SIG
o
Servidor de servicios de mapas: ArcIMS 9.3.1 y ArcGis Server

9.3.1 de ESRI
Servidor de geodatabases: ArcSDE 9.3.1
Servidor de ortofotos: ERDAS v10
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
2.1.2
Otros entornos
Los desarrollos realizados sobre entornos distintos al descrito en el punto

anterior debern ser presentados al Comit de Estndares para su autorizacin.
Ejemplos de esta casustica son las aplicaciones desarrolladas sobre iSeries,
zSeries, o cualquier aplicacin que sea necesario mantener y haya sido ya
desarrollada con otras directrices distintas a las estndar.
2.2 Entorno de Puesto de Trabajo

Los desarrollos, servicios o herramientas realizados en el IAM, debern
tener en cuenta las limitaciones impuestas en los puestos clientes, y en el software
(por ejemplo, los navegadores autorizados, versiones de productos de ofimtica,
etctera) estandarizados para los mismos. El detalle del software y las
caractersticas tcnicas 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 mnimo requerido para utilizar las herramientas de desarrollo.
Se utiliza Microsoft System Center Configuration Manager (SCCM) como
solucin de administracin de equipos en red, incluyendo el inventario, despliegue
automtico 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 gestin de proyectos CA Clarity 12.0.6 para

realizar las tareas relacionadas con la gestin de proyectos
(planificacin, seguimientos, gestin de riesgos, etc.).
Se define Remedy 7 como herramienta de soporte a la Gestin de
servicios, que incluye incidencias, peticiones de servicio, y dems
aspectos de gestin de servicios.
Rational Software Architect (de IBM) v8 soporta la realizacin de
modelados UML de despliegues, casos de uso, anlisis, y diseos, as
como la codificacin 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 5.1
10
Familia de herramientas TAW3 para comprobar accesibilidad de la

interfaz de usuario.
Herramientas de validacin de (X) HTML de W3C (Markup Validation
Service).
Gestor de Reporting (generacin de PDFs, documentos Word, informes,
etctera)
o Se usarn las libreras (no se usar la versin de servidor) que
proporciona JasperReports para impresin de documentos online, en su versin 4.0.2.
o Isis Papyrus 6.20 cuando el volumen de impresin dentro del
aplicativo es elevado o el nmero de plantillas aconseja un gestor
de otro tipo, as como para el tratamiento off-line (batch). En este
caso, su utilizacin ser validada previamente por el Comit de
Estndares.
Maven 3.0.4, para la construccin de aplicaciones.
Subversion como gestor de versiones.
o TortoiseSVN como software de acceso al repositorio desde el
explorador de archivos.
2.4 Entorno Metodolgico

Para los aspectos no definidos en el presente documento, en lo referente a
metodologa, se tomarn como referencia los siguientes marcos de trabajo:
Prcticas y recomendaciones de Project Management Body of

Knowledge (PMBOK). En el mbito de la gestin de proyectos IAM, se
ha realizado una personalizacin de dichas prcticas, y se han definido
roles y procesos especficos para IAM.
METRICA3 y Rational Unified Process (RUP), para los aspectos o
entregables adicionales a los sealados en la presente gua.
Mejores prcticas ITIL, para las actividades de gestin de servicio y
puesta en marcha de nuevos servicios.
A nivel metodolgico, los equipos de desarrollo podrn aadir cualquier

prctica o tcnica contemplada en cualquiera de estos marcos de trabajo, siempre y
cuando no entre en conflicto con los mnimos establecidos en la presente gua.
11
3 Actividades
proyectos
comunes
todos
los
La gestin 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 Gestin en Clarity, que describe en detalle
cmo realizar las distintas tareas descritas en las siguientes secciones.
3.1 Pasos previos

Todo Proyecto IAM debe seguir una fase previa de propuesta y autorizacin,
que realizar el responsable IAM del mismo. Las tareas a realizar se describen en
el documento (slo accesible para personal interno del IAM) Coordinacin 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 seguirn las fases descritas a
continuacin
3.2 Reunin de inicio

Independientemente del tipo de servicio o proyecto a llevar a cabo, el primer
paso es la reunin de inicio del proyecto, que deber solicitar el Jefe de Proyecto
del IAM y que requerir la asistencia mnima 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 reunin se acordar qu tipo de proyecto es el que corresponde al

proyecto que arranca.
Los proyectos se clasificarn en una de las siguientes categoras:
12
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 produccin.
Proyectos de Prestacin de Servicio: Son los proyectos en los que se

contrata a una empresa para que preste un servicio peridico al IAM.
Proyectos no tipificados: Cualquier tipo de proyecto que no cumpla

ninguno de los criterios anteriores.
En esta reunin, se definir:

-
Criterios de calidad a aplicar: Entregables mnimos a realizar,

dependientes del tipo de proyecto y descritos en la presente gua.
Caractersticas del proyecto: Servidor de aplicaciones, uso de

componentes comunes, necesidad de pruebas,
Acrnimo del proyecto: Combinacin de cinco letras que servir para

la identificacin del proyecto dentro del IAM.
Otras consideraciones. Otras caractersticas especificas por proyecto.
Al finalizar la reunin la Unidad de Calidad proporcionar a los asistentes a la

reunin la documentacin con los criterios definidos para el proyecto. La
documentacin aportada por la Unidad de Calidad comprende:
-
Acta de reunin: donde se indicar la fecha de inicio, los asistentes, los

temas tratados,
Informe de la Unidad de Calidad: documento personalizado para el

proyecto en cuestin donde se resumen los chequeos que se realizarn
sobre cada uno de los entregables del proyecto. Estos chequeos sern
de obligado cumplimiento.
Acuerdos: documento con la descripcin de entregables que aplican al

proyecto, componentes comunes que sern utilizados, etctera.
3.2.1
Identificacin de Proyectos y Subsistemas
En algunos casos, se deber realizar un anlisis del proyecto para determinar

si ste contendr subsistemas. Podrn existir subsistemas en un proyecto cuando
se prevean partes independientes desde el punto de vista de su despliegue
13
(generarn ms de un ear en el aplicativo, un ear y un jar,), pero que compartan

cdigo: permite organizar proyectos, de cierta complejidad, en mdulos,
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 comn, y parte de presentacin diferente. Esto en cdigo se traduce como
una capa de presentacin diferenciada (dos mdulos WEB uno para la parte
Internet y otro para la parte Intranet), uno o varios mdulos de Negocio (NEG, EJb,
) que pueden o no estar incluidos en ambos, y uno o varios mdulos de acceso a
Datos (DAO,) que pueden o no estar incluidos en ambos productos finales.
La caracterstica ms 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 ms casos de este tipo con otro tipo de
aplicaciones, Web services, batch,
3.3 Documentacin de Gestin

La lista de entregables que muestra la siguiente tabla se deben almacenar
en el gestor documental de Clarity de cada proyecto. Las plantillas estn
disponibles en el repositorio de publicacin, en la carpeta Plantillas, junto con este
documento.
FASE
Entregable
Localizacin
(En cualquier fase)
Plantilla 1.Plantilla Genrica
Repositorio Clarity. Carpeta raz.
(En cualquier fase)
Plantilla 2. Acta de Reunin
Repositorio de proyecto Clarity.

Ruta: /actas
Tabla 1. Plantillas Genricas
No deber almacenarse informacin de gestin de proyectos fuera del

gestor documental de Clarity, entendiendo como informacin de gestin 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, gestin de riesgos y planificaciones se realizan
directamente sobre la herramienta, no es necesario ubicar documentacin de este
tipo en Clarity. No obstante, a criterio del jefe de proyecto, se podr ubicar en Clarity
cualquier documentacin adicional de gestin, como informes adicionales de
seguimiento, acuerdos, etctera.
14
3.4 Planificacin
3.4.1
Elaborar plan de proyecto
Dependiendo del nivel de intervencin del adjudicatario, el responsable IAM

asignar al mismo, a travs de la herramienta Clarity, los proyectos completos o
fases de proyectos necesarios. Los adjudicatarios sern los encargados de crear y
actualizar las planificaciones que les ataen en dicha herramienta.
Para ello, el adjudicatario deber elaborar un plan de trabajo que incluya la
descomposicin en tareas del proyecto, su secuencia y programacin 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 gua.
Si el proyecto no se corresponde con ninguna tipologa 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 mtodos se describen en detalle en los documentos Anexo 2. Manual de
Usuario del Gestor de proyectos para la Gestin en Clarity y Anexo 13. Uso Ms
Project en planificacin del gestor de proyecto.doc
3.4.2
Creacin de la Lnea Base del proyecto estndar
La lnea 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 lnea base una vez aprobada la planificacin, antes de
comenzar la ejecucin. Para ms informacin consultar el Anexo 2. Manual de
Usuario del Gestor de proyectos para la Gestin en Clarity.
3.4.3
Solicitud de la Auditora de planificacin
La auditora de planificacin se solicita cuando se ha lanzado la lnea base y

antes de empezar a ejecutar el proyecto.
La auditora de planificacin se realiza sobre el proyecto estndar. En caso
de que sea un proyecto estndar coordinador que contiene subproyecto, la
auditora de planificacin se realizar sobre el proyecto coordinador slo si tiene
tareas propias y siempre sobre cada subproyecto asociado.
15
Esta auditora 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 iamuacalidad@madrid.es.
3.5 Ejecucin 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 proyecto1 o bajo demanda del Comit de
Direccin. En este ltimo caso, la Unidad de Apoyo enviar una notificacin
solicitando la actualizacin del estado de los proyecto.
La unidad de Calidad realizar una revisin de que se est actualizando el
seguimiento del proyecto cada vez que se realice una entrega de cualquier otra
documentacin y haya pasado ms de un mes desde la ltima auditora de
seguimiento realizada.
3.5.1
Actualizacin 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 tambin
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 combinacin de ambos mtodos
puede generar incongruencias en el sistema.
Para conocer en detalle los mtodos de seguimiento y cmo actualizar la
situacin del proyecto consultar el Anexo 2. Manual de Usuario del Gestor de
proyectos para la Gestin en Clarity.
3.6 Criterios de Entrega

3.6.1
Entregables
Un entregable es un producto de trabajo que culmina la realizacin de una

actividad o fase de un proyecto.
Por entregable, dentro de la metodologa definida en la presente gua, se
entiende:
-
Para proyectos de Desarrollo
Normalmente se realiza quincenalmente o mensualmente.

16
o
-
Para proyectos de Prestacin de Servicio:

o
Los definidos en la Tabla 12. Plantillas de Gestin de Servicios
Para Otros tipos de Proyecto, incluidos los de Mantenimiento:

o
3.6.2
Cada uno de los documentos definidos en la Tabla 6. Plantillas de

Entregables de Desarrollo de Software .
Los definidos en la reunin de inicio.
Criterios generales de Entregas al IAM
Para considerarse finalizado un entregable (sea cual sea el tipo de

proyecto), es necesario no slo que el adjudicatario lo site en la herramienta
corporativa de gestin de configuracin Subversion, sino que la Unidad de Calidad
verifique el cumplimiento de los estndares. Para este ltimo paso, el responsable
IAM comunicar a la Unidad de Calidad (notificndolo con un correo a
iamuacalidad@madrid.es) 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 peticin de entrega, la Unidad de Calidad revisar
que el entregable cumple con los estndares establecidos y remitir un informe al
solicitante de la peticin con el estado en el que se encuentra el entregable. La
auditora asignar un porcentaje de cumplimiento de los estndares corporativos, y
el estado del entregable ser correcto (y se dar por terminado) si se alcanzan los
objetivos de cumplimiento de estndares fijados en la reunin de inicio.
Ntese que ninguna de las auditoras 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 carcter grave que puedan
impedir el despliegue o arranque de las aplicaciones entregadas.
El conjunto de checks a comprobar por el equipo de auditora se encuentra
en el Informe de la Unidad de Calidad, proporcionada junto con este documento.
Este documento es slo para uso de la Unidad de Calidad. Se proporciona slo a
efectos informativos.
Cada uno de los entregables se validar por la Unidad de Calidad en un
tiempo Mximo de 8 horas laborables, teniendo en cuenta que en la planificacin no
se podrn solapar las entregas de varios entregables. Si las entregas se realizan de
forma conjunta, se sumarn 8 horas por cada uno de los entregables.
Se debern hacer entregas a la Unidad de Calidad hasta que cada uno de
los entregables alcance el nivel de cumplimiento acordado en la reunin de inicio.
17
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 cuestin.
NAACORD: (NO APLICA ACORDADO) El entregable s que debera

realizarse, pero se acuerda no realizarlo con la jefatura de Proyecto del
IAM
Valor numrico: Porcentaje de cumplimiento del entregable respecto a la

metodologa definida en la presente Gua.
Adems de la verificacin de los entregables que se solicite revisar en cada una

de las entregas, la unidad de Calidad validar por cada entrega:
-
Gestin de la Configuracin: verificar el acrnimo, la estructura

estndar del repositorio, ubicacin de entregables, despliegues y
documentacin
Seguimiento del proyecto: Grado de actualizacin de la planificacin.
3.6.5928
Entregas Informales
Con objeto de tener una orientacin del posible resultado de una auditora
para un entregable concreto, el adjudicatario podr solicitar una auditora
informal por entregable, que consiste en una auditora de una parte reducida de un
entregable. Por ejemplo un grupo funcional, o un conjunto pequeo de clases de
cdigo. La Unidad de Calidad realizar una auditora (sin acuerdo de nivel de
servicio) que podr servir para orientar al equipo sobre la construccin del resto del
sistema.
3.6.5929
Estructura genrica
Para cada nuevo proyecto se deber generar un acrnimo de mximo 5

letras (XXXXX). Este acrnimo deber ser aprobado previamente por la Unidad de
Calidad, para evitar duplicidades.
El proyecto se aadir dentro de la estructura de la Organizacin disponible
para el Jefe de Proyecto en la herramienta de gestin 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
- Fuentes
18
o
o
- Documentacin
- Despliegues
Tags
Branches2
Donde:
Trunk:(tronco) se utiliza para alojar la lnea principal del desarrollo. Es la

carpeta en la que normalmente se actualizarn los cambios.
Branches: (ramas) para que contenga las copias/ramas. En el caso en

que se deban mantener varias versiones en paralelo, se utilizarn las
ramas para gestionar las distintas lneas 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 documentacin 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 ms informacin acerca del uso y la estructura de
SubVersion consultar el Anexo 10. Uso de SVN
3.6.5930
Generacin de etiquetas
Todas las entregas que se realicen a la Unidad de Calidad, debern llevarse

a cabo utilizando etiquetas. Todas las etiquetas se debern generar en Subversion
en la carpeta tags con la nomenclatura que se define en el punto 3.6.5931
Para etiquetar se debe tener en cuenta, que solo es necesario incluir en la
etiqueta los entregables que se quieran entregar, ms 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 diseo, cuando terminemos el entregable Diseo de
arquitectura, la etiqueta deber contener:
Las carpetas tags y branches contendrn la misma estructura interna que la

carpeta trunk.
19
Ilustracin 1. Ejemplo etiquetas incrementales
3.6.5931
Poltica de Versionado
El patrn de nombrado de la versin es Vxx.yy.zzz

Por ejemplo: V01.04.010, (la tabla siguiente indica el valor de cada uno de ellos)
donde:
VARIABLE
POSIBLES VALORES
SIGNIFICADO
xx
Entero positivo.
Nmero de versin mayor.
[1..99]
Aumenta cuando se aaden cambios significativos y/o

nuevas funcionalidades. Fundamentalmente cuando se
inicia un nuevo desarrollo (o pliego)
Entero positivo.
Nmero de versin menor.
[1..99]
Aumenta cuando se aaden pequeos cambios y/o

funcionalidades poco importantes. A modo de ejemplo,
una forma de identificar el cambio de funcionalidad si
conlleva una generacin de nuevos scripts de pruebas.
Mantenimiento adaptativo de menor importancia.
Enteros positivos.
Nmero de revisin.
[0..999]
Aumenta con cada una de las entregas de mantenimiento

e incluyen resoluciones de errores.
yy
zzz
Tabla 2. Nomenclatura de versionado
20
3.7 Poltica de certificados.

En este apartado se va a tratar todo lo relativo a la poltica de certificados
digitales en el IAM.
3.7.1
Certificados admitidos
Los certificados clientes deben ceirse a una lista de autoridades emisoras

de certificados digitales reconocidas en el mbito del Ayuntamiento de Madrid,
siendo la relacin la siguiente:
3.7.2
FNMT.
DNIe.
Firma Profesinal.
Asociacin Nacional de Fabricantes - ANF.
Agencia Notarial de Certificacin ANCERT.
Camerfirma.
Agencia de Tecnologa y Certificacin Electrnica - ACCV.
Colegio de Registradores.
APE
Organizacin 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 autenticacin 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 almacn
de certificados para cada entorno. Estos almacenes contendrn:
o
Certificado servidor.
Certificados de la jerarqua de las Autoridades de

Certificacin de los distintos certificados cliente y servidor.
En el caso de Web Services, certificados con clave pblica de

cliente, enviados por las unidades, empresas, organizaciones,
etc. consumidoras de la aplicacin.
21
Almacenes de certificados para ENTORNO A

Certificados de clientes y de
servidor.
Certificados races de
confianza CAs clientes
Almacn
Aplicativo
1
Almacn
Aplicativo
2
..
Almacn
Aplicativo
n
Ilustracin 2. Descripcin almacenes de certificados por entorno.
A pesar de que en prrafo anterior se ha indicado que se ha de crear un

almacn de certificados para cada aplicativo, se puede reutilizar un mismo almacn
de certificados para dos o ms 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 travs del Componente Comn de Firma.
3.7.3
Obtencin 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 travs de IamPeticiones.
3.7.3.1 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, segn lo comentado en el punto anterior.
22
En el caso (generalmente para Web Services) de necesitar realizar un

control por peticionario, el jefe de proyecto de IAM podr solicitar la generacin un
certificado para cada cliente siguiendo tambin las instrucciones del punto anterior.
3.7.3.2 Entorno de Preproduccin

En el entorno de preproduccin, y como norma general, no se generar
ningn certificado, sino que debern ser los clientes los que deban proporcionar la
parte pblica 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
Preproduccin.
3.7.3.3 Entorno de Produccin

Cono norma general, se tendr en cuenta lo indicado para el entorno de
Preproduccin.
Como certificado servidor, se dispone en el almacn de certificados de un
certificado de servidor emitido por la FNMT.
3.7.4
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 poltica de seguridad que se establezca
establecer se requerirn las siguientes configuraciones:
SSL: Se requiere una comunicacin cifrada (se utiliza el certificado

*.munimadrid.es en el servidor web). Existe una configuracin a nivel
de plataforma WAS en entorno INTRANET que determina la
confianza en el certificado *.munimadrid.es, es decir, por defecto, los
servidores confiarn en dicho certificado cuando desde una de las
aplicaciones desplegadas se establezca una configuracin SSL con
otra aplicacin en *.munimadrid.es. Por tanto, dichas aplicaciones
no requerirn un almacn de certificados propio ni realizar
configuracin de la conexin SSL.
Negociacin de Certificado Cliente: se solicita al usuario que

presente un certificado digital; la negociacin la realiza el servidor
frontal web y se enva al servidor WAS si es un certificado de alguna
entidad autorizada. Para el resto de certificados en los que la
aplicacin deba confiar (por ejemplo, entidades bancarias) o para los
certificados propios de autenticacin, ser responsabilidad del
aplicativo:
23
Incorporar entre sus ficheros de recursos (dependientes del

entorno) el almacn con los certificados en que confa dicha
aplicacin, as como el certificado de autenticacin o firma
que debe utilizar.
Mantener actualizado dicho almacn de certificados ante

caducidad o cambio de los mismos, as como solicitar su
subida a los entornos de desarrollo, preproduccin y
produccin con la suficiente antelacin para minimizar las
paradas de servicio.
Configurar adecuadamente la conexin 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 negociacin
(error 403), se deber redirigir al usuario a una pgina HTML de aviso donde se
indique la necesidad de disponer de un certificado cliente y los tipos aceptados por
el aplicativo. Por defecto, esta pgina ya existe para el error 403 a nivel de toda la
plataforma WAS INTERNET., por lo que es opcional entregar una pgina
personalizada, en cuyo caso dicha pgina debe estar diseada para permitir su
despliegue fuera del contexto de la aplicacin (por defecto, se desplegar en el
contexto general de mantenimiento).
Es responsabilidad del aplicativo verificar si la peticin 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 (comunicacin SSL y certificado digital del
usuario requerido) debe establecerse para toda la aplicacin. La informacin
necesaria para una correcta configuracin deber detallarse claramente en el
Plantilla 13. Manual Tcnico de Despliegue de Aplicacin Web, incluyendo si
requiere SSL, certificado cliente, pgina HTML personalizada, etctera.
No se permitir una configuracin 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 configuracin por defecto del servidor.
3.7.5
Especificidades para Servicios Web
Respecto a los Web Services, stos deben ser desarrollados sin hacer
ningn tratamiento interno de seguridad (usuarios/contrasea, etc.). En su lugar se
establecer la poltica de seguridad con las herramientas corporativas para este fin.
Consltese el documento Anexo 11. Manual de Servicios Web.
24
4 Proyectos de Desarrollo
Las fases y requisitos tcnicos presentados en esta seccin aplican tanto a
nuevos proyectos como a evolutivos mayores (suficientemente grandes como
para ser planificados3 como una nueva versin) de proyectos ya en produccin.
En caso de tener varios bloques funcionales que se entreguen por separado,
la planificacin se dividir en iteraciones, y para cada una de ellas se definirn las
fases definidas en la metodologa de desarrollo (ASI, DSI).
Las tareas de alto nivel de cada iteracin de desarrollo sern las fases
definidas en MTRICA, exceptuando las tareas de Planificacin y Estudio de
Viabilidad, realizadas anteriormente, es decir: Anlisis del Sistema de Informacin
(ASI), Diseo del Sistema de Informacin (DSI), Construccin del Sistema de
Informacin (CSI), Implementacin y Aceptacin del Sistema (IAS).
Se permite la utilizacin de metodologas tanto giles como planificadas,
pero el resultado de cada iteracin o sprint debe respetar la estructura de
entregables que se describe en este apartado. En caso de usar metodologas
giles, el proyecto debe ser el encargado de establecer los puntos en los que se
auditarn los entregables, y ser responsable de gestionar los posibles trabajos de
correccin de incumplimientos de Calidad.
4.1 Estructura
La estructura normalizada del repositorio se describe a continuacin:
4.1.1
Carpeta Fuentes
A continuacin describimos los distintos mdulos que pueden formar parte

de una aplicacin. Nombre modulo ser el acrnimo del proyecto y en caso de que
esto produzca colisin de nombres (por ejemplo si existen dos mdulos DAO) ser
<acronimoProyecto>_<nombreDescriptivoDelModulu>
por
ejemplo
(WEB_CURSO_INTERNET, WEB_CURSO_INTRANET)
MDULO
LOCALIZACIN
DESCRIPCIN
Mdulos Client
fuentes/Client_<NombreModulo>
Mdulo que contiene los artefactos

necesarios para construir la parte
3
Se recomienda planificar proyectos cuando superan los dos o tres meses de
duracin, y/o cuando el alcance del proyecto tenga uno o varios productos de entrega
definidos.
25
cliente de un EJB.
Mdulos DAO
fuentes/DAO_<NombreModulo>

necesarios para construir el acceso a
datos.
Mdulos EJB
fuentes/EJB_<NombreModulo>

necesarios para construir la interfaz
publica un EJB.
Mdulos de
NEGOCIO
fuentes/NEG_<NombreModulo>
Mdulos que contienen nicamente los

artefactos necesarios para construir el
negocio.
Mdulos Servicios
Web
fuentes/WS_<NombreModulo>

necesarios para construir la parte Web
Service.
Mdulos WEB
fuentes/WEB_<NombreModulo>

necesarios para construir la parte WEB.
Tabla 3. Localizacin de los mdulos
Para cada mdulo, a partir de la ubicacin raz 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 indicada4):
ELEMENTO
LOCALIZACIN
DESCRIPCIN
Script de
construccin
En la raz del
mdulo.
El pom.xml del mdulo que ser el encargado de construir el

mdulo.
Cdigo fuente
src/main/java
Fuentes del mdulo que sern empaquetados dentro del

artefacto generado por el mdulo.
Cdigo fuente
pruebas
unitarias
src/test/java/
Fuentes de las pruebas unitarias que NO sern empaquetas

dentro del artefacto generado por el mdulo.
Ficheros de
recursos.
src/main/resources
Contendr los archivos de recursos que sern empaquetados

dentro del artefacto generado por el mdulo. Estos archivos
de recursos no se empaquetaran dentro del zip de recursos y
no podrn ser modificados tras el despliegue.
Esta carpeta contendr tambin los almacenes de certificados,
en formato JKS, de los certificados que se requieran instalar
en el almacn de certificados asociado a la aplicacin, tanto
en el caso de Web Services (va el producto Policy Manager)
como en el caso de aplicaciones web (en el servidor de
aplicaciones)
Fichero de
recursos de
pruebas
unitarias.
src/test/resources
Contendr los archivos de recursos necesarios para las

pruebas unitarias que NO sern empaquetados dentro del
artefacto generado por el mdulo
Por ejemplo, los ficheros de recursos de un mdulo NEG se localizaran en

Fuentes/NEG_NombreModulo/src/main/resources/
26
WSDL de
servicios web5
src/main/wsdl/
Hojas de estilo
en cascada6
src/main/webapp/cs
s
Contendr las CSS que sern empaquetadas dentro del zip de

ficheros estticos.
JavaScriptError:
Reference
source not
found
src/main/webapp/ js
Contendr los js que sern empaquetadas dentro del zip de

ficheros estticos.
ImgenesError:
Reference
source not
found
src/main/ / images
Contendr las imgenes que sern empaquetadas dentro del

zip de ficheros estticos.
Pginas
estticasError:
Reference
source not
found
src/main/webapp
Contendr las pginas estticas (html, htm) que sern

empaquetadas dentro del zip de ficheros estticos.
Pginas
dinmicasError:
Reference
source not
found
src/main/webapp/W
EB-INF/jsp
Contendr las pginas dinmicas que mdulo que sern

empaquetados dentro del artefacto generado por el mdulo.
Archivos de
configuracinEr
ror: Reference
source not
found
src/main/webapp/W
EB-INF
Archivos de xml de configuracin.
Nota: Se admitir la
ubicacin en
src\main\webapp\W
EB-INF\wsdl
src/main/webapp/ht
ml
Contendr los WSDL necesarios para los mdulos de

servicios web.
Se recomienda alojar la mayora de las pginas bajo

src/main/webapp/html.
Tabla 4. Estructura interna de los mdulos
Independientemente de los artefactos asociados a un mdulo, otros

artefactos no asociados directamente a ningn mdulo en concreto debern seguir
la siguiente nomenclatura:
ELEMENTO
LOCALIZACIN
DESCRIPCIN
Ficheros de
configuracin del
proyecto
fuentes/config/conf/(*)/(**)
En la carpeta conf se incluirn los ficheros de

configuracin del proyecto (parmetros que puedan
cambiar sin que requiera la generacin del EAR)
fuentes/config/rec/(*)/(**)
En la carpeta rec se incluirn los ficheros de

recursos del proyecto.
En sistemas para plataforma J2EE WASv8 se
5
Solo para mdulos WS.
Solo para mdulos WEB.

27
entregar un fichero serviciosIAM.properties dnde

se localizarn datos restringidos de mquinas y
acceso segn plantilla.
(*) En caso de existir subsistemas se crear una

carpeta para cada subsistema.
(**) A este nivel se encuentra la definicin de las
propiedades para los distintos entornos (desa, pre,
pro,..)
Herramientas
externas (en caso
de existir)
fuentes/herramientas
Aqu se incluirn las herramientas externas al

estndar del IAM que sean necesarias para
construir el proyecto.
Scripts de
construccin
fuentes/
POM padre de los distintos submdulos.
Scripts de carga de
base de datos (en
caso de ser
necesario)
fuentes/scripts/bbdd/actuali
zacin
Sentencias SQL o PTF de actualizacin de datos, o

de actualizacin de los mismos realizadas con
posterioridad a la instalacin
Scripts de
instalacin de base
de datos.
fuentes/scripts/bbdd/instala
cion
Sentencias SQL o PTF de creacin de la base de

datos e insercin de datos iniciales.
Scripts de
Documentum
fuentes/scripts/documentu
m/instalacion
Sentencias DQL u otros componentes para

creacin o actualizacin de repositorio en
Documentum
Archivos de
instalacin de BPM
fuentes/scripts/BPM/instala
cion
Ficheros .ear u otros para creacin o actualizacin

de componentes en BPM o iProcess.
Archivos de GIS
fuentes/scripts/GIS/instalac
ion
Archivos ASX, MSD u otros para creacin o

actualizacin de servicios de mapas GIS.
Archivos de
ERDAS
fuentes/scripts/ERDAS/inst
alacion
Archivos para creacin o actualizacin de ortofotos

ERDAS.
Scripts de procesos
batch (en caso de
ser necesarios)
fuentes/scripts/batch
En esta carpeta estarn los procesos batch de la

aplicacin.
Scripts de prueba y
ficheros asociados
fuentes/scripts/pruebas
Nota: Esta ubicacin contendr normalmente un

fichero .JAR a ejecutar segn la poltica 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 ejecucin.
En esta carpeta se situarn tambin los scripts de
QuickTest, en caso de existir.
Tabla 5. Localizacin de los fuentes dentro de cada mdulo
28
El cdigo fuente deber adaptarse adems a una nomenclatura de

paquetes, y cumplir las normas de cdigo, segn lo establecido en el Anexo
7.Normas de Cdigo.
4.1.2
Carpeta Documentacin
La lista de entregables que muestra la siguiente tabla se debe almacenar en

Subversion de cada proyecto. Las plantillas estn disponibles en el repositorio de
publicacin, junto con la presente Gua.
FASE
Entregable
Localizacin
ASI
Plantilla 3. Maqueta
/Documentacin/2.ASI/
ASI
Plantilla 4.Interfaz de Servicio
ASI
Plantilla 5.Requisitos
ASI
Plantilla 9. Proyecto RSA de Modelado

(XXXXX_Modelado)
/Documentacin/ModeloRSA/
DSI
Plantilla 7. Diseo de Arquitectura
/Documentacin/3.DSI/
DSI

(XXXXX_Modelado)
DSI
Plantilla 10.Proyecto RSA de Modelado de

DATOS (XXXXX_DBD)
CSI
Plantilla 8. Manual de Uso de

Componentes_Servicios
/Documentacin/4.CSI/
CSI
Plantilla 11. Manual de Usuario
CSI
Plantilla 6. Casos de Prueba
IAS
Plantilla 12.Despliegue de procesos Batch
/Documentacin/5.IAS/
IAS
Plantilla 13. Manual Tcnico de Despliegue de

Aplicacin Web
IAS
Plantilla 14. Publicacin de Servicios Web
29
IAS
Plantilla 19. Gestin de incidencias
IAS
Plantilla 20. Plan de Implantacin
IAS
Plantilla 21. Creacin de un Servicio ARcGIS
IAS
Plantilla 22. Creacin de un Servicio ARCIMS
IAS
Plantilla 23. Plantilla Creacin objetos

documentales Documentum.dot
IAS
Plantilla 24. Despliegue aplicaciones SOABPM.dot
IAS
Plantilla 25. Actualizacin repositorio

documental.dot
Tabla 6. Plantillas de Entregables de Desarrollo de Software
4.1.2.1 Carpeta informacin adicional

Existir, adems, dentro de Documentacin la carpeta /Informacin
adicional donde se podr introducir cualquier otra documentacin no mencionada
en este documento y que se considere necesaria para el proyecto.
4.1.2.2 Proyectos con Subsistemas

Si se han definido Subsistemas en el proyecto, podramos tener 2 casos al
incluir la documentacin:
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
Ilustracin 3. Estructura de Carpetas con Subsistemas
2. Que exista un slo documento, con la especificacin de todo el

proyecto (para todos los subsistemas). En este caso se seguirn las
directrices del apartado 4.1.2
4.1.3
Carpeta Despliegues
En la siguiente imagen se muestra el contenido de la carpeta despliegues de

un modo grafico.
Ilustracin 4. Estructura de la Carpeta Despliegues
Dependiendo de los elementos que contenga la aplicacin podremos incluir

en la carpeta Despliegues:
FASE
Entregable
Localizacin
Para aplicaciones J2EE

31
Aplicacin
<acrnimo de la aplicacin>.ear
(Aplicativo .EAR)
trunk/Despliegues/Aplicac
in
Aplicacin
< acrnimo de la aplicacin>_estaticos.zip

(Archivo de ficheros estticos)
in
Aplicacin
< acrnimo de la aplicacin>_recursos.zip

(Archivo de ficheros de propiedades)
in/<Entorno> (desa,
pre, pro, forma)
Para aplicaciones Con BPM

BPM
< acrnimo de la aplicacin>.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

Modificacin fichero
CDQP
CDQP.txt
Creacin de Colas
IPE-EMS
Dentro de documentacin indicar nombre de la

cola a crear
Trunk Despliegues BPM

+ SOA
Para aplicaciones Con Mapas

Mapas
<Ficheros>.axl
trunk/Despliegues/Mapas
/<Entorno> (desa, pre,
pro, forma)
Mapas
<Ficheros>.mxd
pro, forma)
Mapas
<Ficheros>.sde
pro, forma)
Para aplicaciones Con Gestor Documental
32
Gestor Documental
<Ficheros>.dql
trunk/Despliegues/Gestor
Documental
Extensin 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 entregase detallan las directrices

tcnicas de los entregables de despliegue.
En los siguientes apartados se describen con ms detalle cada una de las
fases y los entregables que le corresponden.
4.2 Fase ASI

En esta fase, se definirn todos los entregables necesarios para la
validacin funcional del usuario (necesidades de alto nivel, maqueta e interfaz), y se
almacenarn en SubVersion.
4.2.1
Maqueta
Para poder proporcionar al usuario una visin ms completa de la aplicacin

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 cdigo aadiendo la lgica de
negocio en el futuro) o en formato PowerPoint siguiendo la Plantilla 3. Maqueta.
En caso de codificarse el HTML de la maqueta, dicho cdigo deber alojarse
en las carpetas definidas para la parte esttica de un desarrollo normal, dentro de la
carpeta Fuentes.
4.2.1.1 Imagen Corporativa

Para el cumplimiento de la imagen corporativa del IAM, se encuentran a
disposicin de los proyectos en el directorio de distribucin, en la carpeta Interfaz
Grfica, los manuales de estilo y hojas de estilos de las diferentes lneas de
desarrollo de aplicaciones:
AYRE, para el desarrollo de aplicaciones de Intranet.

MuniMadrid, para el desarrollo de aplicaciones de Internet.
Sede, para el desarrollo de trmites electrnicos a publicar en la SEDE.
33
Mvil, para el desarrollo de aplicaciones para dispositivos mviles.
Se crearn tantas maquetas como sean necesarias para describir la imagen

de la aplicacin. Se debe tener en cuenta que en la imagen de la aplicacin tambin
se debern describir los formularios de impresin si aplicasen.
Todos los elementos de presentacin comentados se encuentran disponibles
junto al resto de elementos comunes descritos en la Tabla 10. Componentes
Comunes.
4.2.1.2 Requisitos de Accesibilidad

En los casos en que el acceso a la aplicacin sea a travs de Internet,
aunque los usuarios sean controlados, sta tendr que ajustarse al nivel mnimo de
accesibilidad exigido por la legislacin espaola para las administraciones pblicas,
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 resmenes de las tablas.
Crear un orden lgico para navegar con el tabulador a travs de

vnculos, controles de formulario y objetos.
Toda la normativa de accesibilidad se encuentra disponible en la carpeta

Accesibilidad y Normativa publicada junto con la presente gua.
4.2.2
Interfaz de Servicios Web
Para Servicios Web, deber construirse una presentacin PowerPoint

siguiendo la Plantilla 4.Interfaz de Servicio y se almacenar tambin en el
Subversion. Del mismo modo que con las maquetas, se crearn cuantos
documentos de Interfaz sean necesarios.
En el documento de Interfaz, se indicarn al menos los servicios disponibles,
entradas y salidas (generales) de cada servicio, una breve descripcin de cada uno
y un diagrama que muestre la interaccin de los servicios con usuarios y sistemas
externos. Ser este documento (en lugar del WSDL, que se generar en fase de
Diseo) el que se utilice para que el usuario valide si los datos a intercambiar son
los apropiados.
4.2.3
Documento / Modelo de Requisitos
Este entregable va dirigido a usuarios del sistema, por lo que los requisitos
que se describan debern estar siempre enfocados desde el punto de vista de
34
dichos usuarios, sin entrar en el funcionamiento interno de la aplicacin. Por tanto,

no se debern hacer referencias a entidades, flujos internos, ni a elementos de
arquitectura.
Para la realizacin de este documento se podr utilizar la Plantilla
5.Requisitos o si se prefiere realizar toda la documentacin en un modelo la
Plantilla 9. Proyecto RSA de Modelado (XXXXX_Modelado) (02.ASI.emx) ubicada
en el directorio de distribucin. Si se realiza el documento se debern entregar los
elementos de modelado en RSA. En cambio, si se utiliza la plantilla de Modelado
para documentar toda la informacin (sin utilizar documento), solo ser necesario el
modelo.
En esta plantilla se debern especificar:
-
Los Actores que interactan 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 crtico de la

aplicacin
Para una mejor comprensin de los requisitos funcionales, estos debern

agruparse en paquetes de Grupos Funcionales, siempre que dichos requisitos
tengan una funcionalidad relacionada. Cada grupo funcional estar numerado con
la notacin GF-XX, donde XX no tiene porque ser necesariamente nmeros
consecutivos.
Todos los elementos grficos UML incluidos en el documento Word, debern
adems ser proporcionados para su edicin en la herramienta corporativa de
modelado RSA, siguiendo la utilizando Plantilla 9. Proyecto RSA de Modelado
(XXXXX_Modelado)
35
Ilustracin 5. Modelo RSA de Anlisis
Para ms informacin acerca del uso de la herramienta RSA y modelad de

la fase de Anlisis consultar el Anexo 4. Manual de Anlisis y Diseo con RSA
Los casos de uso de criticidad alta (considerados importantes por el
responsable IAM), debern ser descritos mediante la documentacin de su
escenario, bien como diagramas de actividad UML, bien de forma textual siguiendo
la siguiente estructura:
Datos Caso de Uso:
Descripcin
El cliente solicita que
Actores
participantes
Actor Genrico
Pre-condiciones
Si el adeudo es para una tasa de ejecutiva, se debe haber realizado antes el

Caso de Uso paso a ejecutiva.
Post-condiciones
El estado queda registrado como En Ejecutiva en el sistema
Flujo Principal:
1
El Actor solicita
2.1
2.a.1
Flujo opcional A: Si se pulsa
2.b.1
Flujo opcional B: Si por el contrario se pulsa
2.b.2
Ms pasos del flujo opcional B
36
Flujos de Excepcin:
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.
Tamao de adjunto excedido
E2.1
El sistema informa de que se reduzca el tamao del adjunto
Tabla 8. Plantilla Casos de Uso
La realizacin de la especificacin 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 debern entregarse en
RSA, si se realiza en modelo RSA solo ser necesario el modelo.
4.2.4
Planes de Pruebas Opcionales
Opcionalmente, de existir, se definirn del siguiente modo los distintos tipos

de prueba:
Pruebas Unitarias7 (JUnit): se entregar directamente en el cdigo

fuente, en la localizacin indicada en la Tabla 5.
Pruebas Funcionales (a realizar manualmente por el equipo de
desarrollo o con Quick Test Profesional): Se documentarn en
QualityCenter. Aquellas pruebas funcionales marcadas con severidad
Crtica formarn parte del juego de pruebas de regresin, es decir,
aquellas que es necesario ejecutar antes de cada subida de versin.
Pruebas No Funcionales (como accesibilidad, navegabilidad,
seguridad etctera): Se documentarn en la Plantilla 6. Casos de
Prueba, aadiendo cuantos prrafos se necesiten.
7
Clases Java cuya nica finalidad es la prueba del cdigo fuente del proyecto. El
objetivo es probar de forma aislada una parte del cdigo determinada para asegurar su
correcto funcionamiento independientemente del resto del proyecto.
37
4.3 Fase DSI

En la fase DSI, se establecen los siguientes entregables:
4.3.1
Diseo Arquitectura Lgica
En el documento de Arquitectura, que seguir la Plantilla 7. Diseo de

Arquitectura, se especificar la arquitectura lgica que sigue la aplicacin que se
est desarrollando. Dicha arquitectura deber adaptarse a los criterios corporativos
descritos en los siguientes apartados. Cualquier excepcin respecto a la
arquitectura corporativa, deber describirse en este documento acompaado de
una justificacin, que deber ser aprobada por el Comit de Estndares.
Tambin se indicarn los Componentes Comunes IAM que se utilizarn,
as como los componentes que se desarrollarn para su uso por otras aplicaciones.
4.3.1.1 Arquitectura Lgica Corporativa

Las aplicaciones deben seguir la siguiente arquitectura lgica de referencia
cliente-servidor que se estructurar al menos en tres capas y seguir el patrn de
diseo MVC:
Ilustracin 6. Arquitectura Lgica Corporativa
38
Presentacin:
o
Proporciona el interfaz de usuario (IU) y gestiona el flujo de

navegacin de la aplicacin.
Gestiona los eventos y el intercambio de datos entre el

usuario y la aplicacin.
Lgica de Negocio:
o
Proporciona la lgica de la aplicacin y funciona como nexo

entre las capas de presentacin y persistencia.
En un servicio o componente de negocio distinguimos los

siguientes elementos:
Interface del servicio proporcionado a la capa de

presentacin. Estos elementos son el contrato de la
capa de negocio, es decir, son los elementos que
indican lo que va a hacer la capa.
Implementacin del servicio o componente de negocio

que contiene la lgica de la aplicacin. Deben
implementar los elementos de la interfaz de negocio.
Persistencia:
o
Incluye las entidades persistentes del dominio de la aplicacin

y los servicios de acceso a la base de datos.
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.
Implementacin de la persistencia. Estos elementos

son los encargados reales de realizar la persistencia.
Deben implementar los elementos de la interfaz de
persistencia.
Servicios transversales:
39
o
o
Los
componentes
comunes
IAM
proporcionan
funcionalidades reutilizables por las diferentes aplicaciones.
Se podr utilizar el conjunto de servicios proporcionadas y
soportados por el servidor de aplicaciones (JavaMail, JNDI,
JMS, )
Servicio de generacin de documentos basado en Jasper
Reports.
Adems debemos considerar los siguientes aspectos relevantes:
La seguridad de la aplicacin se realizar del siguiente modo:

o Si se trata de una aplicacin Intranet, deber realizarse utilizando
el componente UWEB de autenticacin y control de acceso. La
documentacin de este componente se encuentra publicada junto
a este documento (ver Tabla 10. Componentes Comunes).
o Si se trata de una aplicacin Internet, la seguridad se controlar
usando certificado digital, utilizando de manera programtica las
funcionalidades del componente de Pasarela de Firma (ver Tabla
10. Componentes Comunes). En todo caso, todas las
aplicaciones que se siten en la Sede Electrnica, deben
configurarse para acceder por https.
o Otra casustica de seguridad, deber ser tratada en el Comit de
Estndares.
El nombre de la aplicacin debe coincidir con el contexto de la misma,

por ejemplo:
o
o
o
Proyecto: GITED_InspeccionTecnicaEdificios
Aplicacin: GITED (URL: http://dominio/GITED)
Aplicacin: GITED_INF (URL: http://dominio/GITED_INF)
La gestin de las transacciones debe considerarse en cada una de las

capas. Ser responsabilidad de cada aplicacin realizar una adecuada
gestin transaccional que evite las inconsistencias en los datos de la
aplicacin.
Los procesos batch son ejecutados fuera del servidor WAS y su

programacin puede planificarse con la frecuencia que se determine o
lanzarse de forma manual desde un equipo cliente. Para ms
informacin consultar el documento Anexo 8.Normas de empaquetado
y entrega
Las siguientes secciones definen las siguientes tecnologas y estndares

segn la versin del servidor de aplicaciones dnde se despliegue la aplicacin.
Ntese que la arquitectura estndar a fecha de la publicacin de esta gua es
WAS 6.1. En caso de tratarse de un proyecto a largo plazo, y siempre dependiendo
40
de la disponibilidad de los entornos, se podra plantear el desarrollo en WAS 8. La

arquitectura concreta a seguir se establecer en la reunin de inicio del proyecto.
4.3.1.2
Arquitectura WAS 6.1 (estndar)
Los estndares a considerar estn basados en los soportados por la

especificacin J2EE 1.4. Pese a eso no se permite de forma general usar:
Enterprise Java Beans
RMI-IIOP
ORB
JAVA-IDL
JDBC
JMX
Uso programtico del User Transaction
Para las distintas capas que conforman una aplicacin estndar en el IAM
se debern usar las siguientes tecnologas:
Presentacin.
o Para aplicaciones web tradicionales se utilizar Spring 3 + Tiles.
Excepcionalmente y bajo acuerdo explicito con el Comit de
Estndares, 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 solucin centrada en el cliente.
o En casos excepcionales y tras acuerdo explicito con el Comit de
Estndares se podr usar struts 1.0 o superior.
Lgica de Negocio.
o Se utilizar Spring como contenedor de beans.
o Se usarn servicios web JAX- RPC
Persistencia.
o Se utilizar Hibernate 3 para la declaracin de las entidades
persistentes del dominio de la aplicacin y el acceso a la base de
datos. Se prohbe el uso de cualquier tipo de anotaciones no
incluidas en el estndar JPA.
o Excepcionalmente y previa autorizacin por el Comit de
Estndares, se podr usar directamente JDBC 3.0 siguiendo el
patrn de diseo DAO.
41
Se utilizar Spring IoC para la inyeccin 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 caractersticas de Spring:
AspectJ
Jax-WS
Task shedulling
JDO, Oracle TopLink Ibatis SQL
Velocity
JSF
RMI
EJB 2
Lenguajes dinmicos
JMX
JDBC
JPA
4.3.1.3
Arquitectura WAS 8 (sujeto a disponibilidad)
Las tecnologas y estndares a considerar estn basados en los soportados

por la especificacin Java EE 6:
Presentacin.
o Para aplicaciones web tradicionales se utilizar MyFaces 2.0
como implementacin de JSF 2.0 y Facelets, EL-Expression y
JSTL para la definicin 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
solucin IceFaces siguiendo el patrn Single Page Interface (SPI)
Lgica de Negocio.
o Se usarn EJB 3.1 que exponen mtodos de negocio para
aplicaciones Intranet: EJB de sesin para llamadas sncronas en
tiempo real y EJBs de mensaje para llamadas asncronas.
o Se usarn servicios web JAX-WS 2.2 para servicios comunes
que deban publicarse en el ESB
42
Persistencia.
o Se utilizar JPA 2.0. Excepcionalmente y previa autorizacin por
el Comit de Estndares, se podr usar directamente JDBC 4.0
siguiendo el patrn de diseo DAOs.
Deber usarse JEE CDI para inyectar las referencias entre objetos
pertenecientes a distintas capas.
4.3.1.4
Arquitectura de despliegue
La distribucin en mquinas 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 sesin debe ser serializable.

El tamao de la sesin debe reducirse al mnimo posible.
No use el sistema de ficheros local de la mquina. Use un sistema
centralizado como Base de Datos o NAS.
En la fase de diseo de la aplicacin 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 aplicacin. Para realizar esta tarea
se proporciona en la plantilla de diseo RSA (03.DSI.emx). Dentro del apartado
diagrama de despliegue se ha incluido un diagrama ejemplo. En este diagrama se
43
muestra toda la arquitectura fsica del IAM y un ejemplo de cmo indicar el uso de
los distintos dispositivos. Del diagrama de ejemplo se deben eliminar los
dispositivos de los que no haga uso la aplicacin y usar los artefactos propios de la
aplicacin indicando donde son desplegados. A continuacin se muestra el
diagrama de la plantilla.
Ilustracin 7. Plantilla de diagrama de arquitectura.
4.3.1.5 Aplicaciones mviles

Para el desarrollo de aplicaciones accedidas mediante dispositivos mviles
tanto orientadas al ciudadano como al trabajador del Ayuntamiento de Madrid se
contempla una serie de estndares de uso obligado. Los estndares especficos
para aplicaciones mviles se encuentran en el Anexo 9. Normas de desarrollo de
Aplicaciones Mviles.
4.3.1.6 Componentes Comunes IAM disponibles

El IAM dispone de una serie de componentes comunes que permiten la
reutilizacin de funcionalidades. El uso de estos componentes toma carcter
obligatorio si los sistemas de informacin han de realizar alguna de las funciones
que dichos componentes exponen.
44
Tanto las funciones detalladas como los entregables de los diferentes

componentes relacionados se encuentran disponibles en la documentacin global
de desarrollo, accesibles desde el directorio de distribucin.
Si una aplicacin necesita el uso de cualquier componente comn debe
realizar una solicitud a iamuacalidad@madrid.es con copia a los responsables
indicados en la siguiente tabla. Esta solicitud tiene por objeto la preparacin del
entorno y la habilitacin de la seguridad necesaria.
Nombre
Funcin Global
Responsables
BDC
Gestin del Territorio (Calles, nmeros, cdigos

postales, coordenadas etc.)
Javier Delgado Bermejo

delgadobj@madrid.es
Enrique de Dios
diose@madrid.es
EPOB
Consulta Habitantes
Javier Delgado Bermejo

delgadobj@madrid.es
Javier Martnez Valdueza
martinezj@madrid.es
Registro
Gestin Registro de Entrada Ayuntamiento de Madrid
Guillermo Molina Herranz

molinag@madrid.es
Alberto Ibez
ibaneza@madrid.es
UWEB
Control Usuarios , Aplicaciones
Mercedes Lozano Quirce

lozanoqm@madrid.es
Pablo Belinchn Tens
belinchonp@madrid.es
Directorio
Consultas a Directorio de Personal Municipal
Leonor Torres Moreno

toresml@madrid.es
Paloma Hernndez
hernandezp@madrid.es
Archivo
Electrnico
Pasarela
Firma
Interoperabili
dad
Gestin Documental (Documentum)
Validacin Certificados, Firma y Validacin

Documentos
Interconexin entre aplicativos ( Control de Peticiones

Respuestas) internas y con otros Organismos
Julio Estela Gutirrez

estelagj@madrid.es
lozanoqm@madrid.es
Mariano Estevez Garca
estevezgm@madrid.es
lozanoqm@madrid.es
estevezgm@madrid.es
45
Nombre
Funcin Global
Registros
Electrnicos
Registro Telemtico, Registro Pleno.
Censo
Locales
Gestin Censo de Locales y Actividades
Responsables
lozanoqm@madrid.es
estevezgm@madrid.es
Guillermo Molina Herranz
molinag@madrid.es
Maite Muoz Gmez
munozm@madrid.es
GIIM
Gestin informacin Tributaria

(Carpeta del Ciudadano, Deudas IVTM, Gestores
Administrativos, Notarios)
Fernando Ruiz Contreras

feruiz@madrid.es
Enrique Romero Puertas
romeroe@madrid.es
SMS
Servicio de envo de mensajes SMS.
Ivan Ledesma Obelar

ledesmaoi@madrid.es
Estilos
Comunes
Hoja de estilos corporativos para aplicaciones

lozanoqm@madrid.es
Tabla 10. Componentes Comunes
4.3.1.7 Integracin entre aplicaciones

La Ilustracin 8. Integracin entre Aplicaciones y Componentes Comunes muestra
un diagrama con los distintos tipos de accesos entre aplicaciones, incluida la
funcionalidad proporcionada por los componentes Comunes IAM, descritos en el
apartado anterior. El acceso a estos componentes se puede realizar:
Desde un Sistema Externo, a travs de Internet u otra red externa a

IAM, se realizar a travs de un Servicio Web, con seguridad a nivel de
certificado. El BUS de servicios se encarga de autorizar, securizar y
enrutar la peticin a la URL adecuada.
Desde un sistema dentro del IAM, pero fuera del contexto JEE (por
ejemplo, desde SAP), se utilizar tambin el BUS de servicios a travs
del servicio web, pero con un nivel de seguridad de usuario y
contrasea.
Desde una aplicacin JEE IAM, la aplicacin cliente podr:
o incluir en el EAR la librera (JAR) proporcionada por el
Componente Comn
o utilizar la biblioteca compartida a nivel de servidor o aplicacin
proporcionada por el Componente Comn
Las clases proporcionadas pueden:
46
Invocar un servicio web mediante el BUS de Servicios (ESB), en

caso de tratarse de un servicio que no sea de libre acceso por
cualquier aplicacin.
Ejecutar la lgica de negocio contenida en la librera, que podra
acceder directamente a los datos del Componente Comn.
Para el acceso a un servicio se necesita especificar en la peticin los

siguientes datos:
o WSDL/JAR de acceso
o Nombre del aplicativo
o Motivo del uso del componente
o Credenciales para la autenticacin del aplicativo:
Usuario | Contrasea
Certificado electrnico
Ilustracin 8. Integracin entre Aplicaciones y Componentes Comunes
47
4.3.1.8 Desarrollo de nuevos Componentes Comunes

En caso de detectar la necesidad de interconectar aplicaciones o servicios
que se vayan a usar por varios Sistemas de Informacin se debern crear nuevos
componentes comunes.
Se establecen varias posibilidades a la hora de desarrollar estos
componentes comunes.
La primera posibilidad es empaquetar el nuevo componente comn en un jar
que se incluya dentro del classpath de las aplicaciones que deseen usarlo. De esta
forma el acceso al componente comn se realizara de una forma local a la
aplicacin. Estas libreras deben disearse para poder ser instaladas como
bibliotecas compartidas a nivel de servidor, minimizando as el uso de recursos y
optimizando los procesos de implantacin de las aplicaciones, y permitiendo la
compatibilidad entre versiones diferentes que sean utilizadas por aplicaciones
diferentes dentro de un mismo servidor.
La segunda posibilidad es crear un servicio que publique un Web Service.
De esta forma el componente ser accedido de forma remota por las aplicaciones
que deseen usarlo.
En cualquiera de los casos el nuevo desarrollo debe cumplir las siguientes
directrices:
Se deben cumplir, en general, todas las normativas vigentes a la fecha

de inicio del proyecto. Esas normativas se especifican en esta gua y en
los anexos a los que hace referencia.
Se elaborar un manual segn la plantilla Plantilla 8. Manual de Uso de
Componentes_Servicios, que contenga el objetivo funcional del
componente, ejemplos de uso, posibilidades de configuracin,
localizacin de descargas, datos de prueba, etctera.
Se proporcionarn los mecanismos necesarios para la realizacin de
pruebas del componente individualmente, ya sean scripts de pruebas en
caso de servicios web, o aplicaciones cliente en caso de componentes
jar.
Deber proporcionarse una versin mock (sin funcionalidad), que
devuelva siempre los mismos datos, de manera que sea posible
desarrollar usando el componente a equipos situados fuera del IAM.
En caso de entregarse como librera:
o
Permitir su despliegue como biblioteca compartida y posibilitar

la utilizacin de diferentes versiones por aplicaciones distintas en
un mismo servidor. Posibilitar a las aplicaciones que lo utilicen la
independencia del entorno de despliegue y la configuracin de
sus ficheros de trazas, siguiendo los estndares.
48
Utilizar las libreras estndar de la plataforma WAS, evitando el

uso de libreras de terceros sobre las que no puedan asegurar el
cumplimiento de estndares, su despliegue como biblioteca
compartida y la compatibilidad entre versiones de la misma.
Si el nuevo componente comn se empaqueta en un jar, adems de las

directrices propias de todo componente comn debe cumplir las siguientes:
Se debe solicitar la subida del nuevo componente al gestor de artefactos

corporativo. Para ello se debe solicitar a travs de la direccin
iamuacalidad@madrid.es
Si el nuevo componente comn se despliega como un servicio, adems de

las directrices propias de todo componente comn debe cumplir las siguientes:
Seguir la normativa de desarrollo descrita en el Anexo 11. Manual de

Servicios Web.
Para solicitar el despliegue del servicio web se debe aportar, a parte de
todos los documentos que se establecen en esta gua relativos a
despliegue de aplicaciones, la plantilla Plantilla 14. Despliegue de
Servicios Web
El servicio no debe implementar ninguna funcionalidad relativa a la
seguridad. Esa funcionalidad ser proporcionada por el bus corporativo,
siendo responsabilidad del grupo de desarrollo indicar que tipo de
seguridad desean (sin seguridad, usuario/contrasea, certificador
digital).El servicio ser registrado en el registro de servicios
corporativo.
Los Servicio WEB con clientes en internet o intranet, siempre que estos
ltimos requieran seguridad, sern desplegados en un servidor
dedicado. Este servidor solo ser accesible desde una maquina que
realizar las tareas de proxy de estos servicios. Esto implica que, en
caso de que los servicios se engloben en un aplicativo junto con otros
mdulos desplegables (WEB, EJB), los mdulos de Servicios WEB se
deben empaquetar, como mnimo, en un EAR distinto al resto de los
mdulos y por consiguiente este modulo se debe tratar como un
subsistema.
4.3.1.9 Procesos en batch y procesamiento asncrono

Los procesos batch se caracterizan por tener una elevada carga de
procesamiento mantenida durante un espacio de tiempo amplio, procesando
informacin que no precisa gestionarse en tiempo real. Los procesos batch deben
ser ejecutados fuera del servidor WAS y su programacin puede planificarse con la
frecuencia que se determine o lanzarse de forma manual desde un equipo cliente:
Procesos batch en base de datos: los que corresponden a

actualizaciones como reconstruccin de ndices de BBDD, carga de
49
tablas de estadsticas, etc. Dado que slo actan sobre los datos, se
recomienda el uso de lenguajes que permitan una rpida actualizacin
de los datos, como, por ejemplo, Transact-SQL, Pro-C, PL/SQL.
Procesos Batch manuales puntuales: por ejemplo, para una migracin

o sincronizacin de datos que se realiza de forma puntual y unitaria.
Procesos Batch automticos: en estos procesos se pueden delegar las

tareas diarias, semanales, mensuales, etc. como la generacin de
informes o el envo masivo de notificaciones. Estos procesos se
planificarn en la herramienta de planificacin de tareas de IAM.
Para proceder a la implantacin del proceso batch automtico, se debe
cumplimentar la Plantilla 12.Despliegue Procesos Batch y cursar una
solicitud mediante un correo a iamuacalidad@madrid.es. La Unidad de
Calidad realizar las peticiones de visto bueno del documento de
Despliegue Procesos Batch a los departamentos implicados en la
implantacin, y una vez obtenidos lo remitir al Departamento de
Explotacin para su ejecucin y notificar al responsable del proceso
batch su puesta en produccin.
Existe adems u caso intermedio entre las aplicaciones web y los procesos
batch, para tareas que no se realizan de forma masiva y surgen bajo peticin del
usuario. Por ejemplo, un usuario solicita a una aplicacin un informe estableciendo
filtros personalizados para el mismo y al requerir un tratamiento pesado no se
puede devolver la respuesta inmediatamente al usuario. La forma de implementar
este desacoplamiento sera mediante el uso de la API JMS:
1. El usuario accede a una pgina de la aplicacin para lanzar la tarea.
Esta pgina invocar la lgica de negocio que se encarga de lanzar
un mensaje JMS y responder al cliente con un aviso de que la tarea
est en curso, finalizando la peticin.
2. Este mensaje es recogido asincrnicamente por un EJB (messagedriven bean), el cual se encargar de procesar la peticin y realizar
los trabajos oportunos. De esta forma se desacopla el procesado del
mensaje de la respuesta al usuario (quien no tiene que esperar online la respuesta del proceso).
3. El EJB se encargara de actualizar la informacin acerca de las
tareas en curso y su estado, de forma que el usuario podr verificar
en qu estado se encuentra su proceso y si ha finalizado o no.
Opcionalmente podra tambin enviar la notificacin de finalizacin
de la tarea mediante correo electrnico.
Como comentario final al procesamiento asncrono, no est permitido el uso
del WorkManager de WAS salvo autorizacin expresa.
50
4.3.2
Modelo de Diseo
El diseo, si se realiza, deber realizarse en forma de modelado RSA.

No ser necesario entregar documentos Word con el diseo detallado,
siendo el formato RSA en el que debe etiquetarse y entregarse el diseo en
Subversion, con todos los elementos UML debidamente comentados.
Slo ser necesario modelar las clases de Diseo que intervengan en los
casos de uso de criticidad alta (el resto se podrn incluir de manera opcional, a
criterio de la jefatura del proyecto IAM). El fichero de modelado seguir la estructura
establecida en la Plantilla 9. Proyecto RSA de Modelado (XXXXX_Modelado)
(fichero 03.DSI)
El modelado se divide en dos partes, segn la estructura especificada en la
Plantilla 9. Proyecto RSA de Modelado (XXXXX_Modelado), que se muestra a
continuacin:
Ilustracin 9. Estructura RSA de diseo
Para ms informacin consultar el Anexo 4. Manual de Anlisis y Diseo con

RSA.
4.3.2.1 Realizacin del Caso de Uso en Diseo

Se generar una realizacin de caso de uso RSA por cada caso de uso que
se haya definido como crtico (el resto de realizaciones son a criterio del proyecto)
51
en la fase de Anlisis, y dentro de la misma, se aadir un diagrama de secuencia

de diseo, que especifique las clases del sistema por las que pasa la llamada.
4.3.2.2 Modelado esttico

Segn se vayan creando las distintas clases, necesarias para la ejecucin
(realizacin) de los casos de uso en RSA, stas se irn aadiendo a un modelo
esttico de diseo, incluyendo cada clase en la capa y el paquete que corresponda.
Adems del modelado de clases que intervengan en los diagramas de
secuencia, se debern modelar las excepciones, teniendo en cuenta que se deber
realizar un tratamiento de excepciones de forma jerrquica.
4.3.3
Modelo de Datos
El modelo fsico y lgico de datos se realizar en RSA, a travs de la

perspectiva de modelado de datos. Contendr la siguiente informacin:
Descripcin de Tablas y Campos.

Volumetra estimada de cada tabla
Archivos de creacin y carga, y eliminacin de tablas (scripts SQL
generados automticamente a travs de RSA)
Formato de ficheros de intercambio, si los hay.
La estructura de informacin seguir la Plantilla 10.Proyecto RSA de

Modelado de DATOS (XXXXX_DBD). Se adjunta un manual de uso de la parte de
datos de RSA en el Anexo 5. Manual de Modelado de datos RSA.
4.4 Fase CSI

4.4.1
Estrategia de Desarrollo
Durante la construccin, se crearn todos los artefactos de cdigo (ver

seccin 4.1 para ms detalle sobre la ubicacin de los mismos), incluido:
Cdigo Java, cuyo esqueleto podr ser creado

transformacin UML->Java de RSA.
Scripts SQL, tambin generados a travs de RSA
Ficheros de configuracin
Plantillas (por ejemplo, plantillas Jasper)
Libreras utilizadas
Scripts de compilacin y construccin
cualquier otro elemento necesario para la entrega
usando
la
52
4.4.2
Normas de codificacin
Se debe tener en cuenta una serie de normas de estilo, codificacin y

empaquetado durante la fase de construccin. Estas normas tienen dos objetivos,
estandarizar el nombrado y estilo de codificacin de los distintos elementos que
conforman un proyecto java (paquetes, clases, interfaces, etc.) y evitar el uso de
malas prcticas con el objetivo de evitar errores y mejorar el rendimiento.
Alguna de estas normas sern validadas de forma manual y otras usando
herramientas automticas de validacin de cdigo esttico. Para la validacin
automtica se usaran las herramientas PMD y CheckStyle. En el Anexo 7.Normas
de Cdigo se especifican estas normas estando divididas en tres grupos:
Normas de obligado cumplimiento: Estas normas deben cumplirse de forma

obligatoria. Cualquier incumplimiento de alguna de estas implicar que el
chequeo correspondiente del informe de auditora sea considerado
incorrecto.
Normas comprobadas por mtricas: Estas normas se comprobaran en base

a una ratio teniendo en cuenta el nmero de lneas de la aplicacin. Este
ratio nos indicar un tanto por ciento de cumplimiento que ser reflejado en
el informe de calidad.
Normas de obligado cumplimiento para el despliegue: En caso de solicitar

un despliegue se realzar un anlisis del cdigo desde la unidad de calidad
antes de pasar la solicitud a la unidad de Sistemas. En caso de detectarse
algn incumplimiento la unidad de calidad informar al equipo de desarrollo
y no se remitir la peticin de despliegue a la unidad de SIstemas.
Tanto PMD como CheckStyle se configuran mediante unos archivos creados

por la unidad de calidad y puestos a disposicin de todos los equipos junto con esta
gua. Estas herramientas pueden ser ejecutadas con RSA o Maven, lo que posibilita
que los distintos equipos de desarrollo realicen la validacin de estas reglas antes
de solicitar la auditora correspondiente.
4.4.3
Construccin del Proyecto
Realizando un checkout de todo el cdigo del proyecto (carpeta fuentes), y

ejecutando el script de maven, deber generarse por separado los entregables
especificados en la Tabla 7. Plantillas de Entregables de Despliegue.
Ser obligatorio el uso de maven para la construccin de proyectos de
desarrollo en el IAM. Los equipos de desarrollo deben generar los archivos de
configuracin necesarios para que el proyecto se pueda construir de forma correcta
independientemente del entorno donde se genere.
53
Para validar el correcto uso de la infraestructura tecnolgica la Unidad de

Calidad debe ser capaz de construir el proyecto con maven desde un entorno limpio
con el nico apoyo del gestor de artefactos corporativo del IAM. En caso de
producirse algn error durante la construccin del proyecto quedar reflejado en el
informe de la Unidad de Calidad.
Para ms informacin del uso de maven consulte el Anexo 15. Manual de
uso de maven.
La estructura interna de los ficheros, as como los aspectos relevantes en
cuanto al contenido de los ficheros de configuracin, para su adaptacin al entorno
de IAM se describe en el Anexo 8.Normas de empaquetado y entrega.
4.4.3.1 Libreras
Las distintas libreras de las que dependa la aplicacin para su construccin
deben recuperarse del gestor de artefactos corporativos del IAM estando prohibido
usar cualquier otro tipo de gestor de artefactos.
En caso de que una aplicacin necesite alguna librera que no est
disponible en el gestor de artefactos, su inclusin ser solicitada, mediante una
propuesta justificada de la misma a iamuacalidad@madrid.es , pudiendo sta ser
remitida al Comit de Estndares para su estudio. En caso de su aprobacin ser
incluida en el gestor de artefactos corporativo del IAM.
Consultar el Anexo 8.Normas de empaquetado y entrega, para ms
informacin sobre las libreras java a incluir dentro del EAR.
Todas las libreras utilizadas deben estar estandarizadas en la presente
Gua. Para el uso de libreras propietarias o de terceras partes no especificadas
debe consultarse con el Comit de Estndares para su aprobacin.
4.4.4
Casos de Prueba (fase de Construccin)
En este punto, se debern crear los Planes de pruebas siguiendo las

especificaciones de requisitos No funcionales y de rendimiento definidos en la fase
ASI,
En la Plantilla 6. Casos de Prueba para la especificacin de pruebas se
debern cumplimentar las siguientes tablas:
Condiciones especiales de Rendimiento:
Es necesario volcado de datos de

produccin?
S
/NO
El volumen/tipo de los datos a utilizar no permite su

creacin de forma manual. Se requiere permiso del
RESPONSABLE DEL FICHERO en caso de aplicarse
Proteccin de Datos.
Procesamiento Batch
Si /No
Hay procesos batch o la propia aplicacin web realiza

procesamiento de informes pesados. Horarios y
54
duracin estimada.
Procesamiento de archivos (descargas y
subida de ficheros on-line)
Si/No
Incluye webservices
Si/No
<URL de los wsdl>
Requiere autenticacin
Si
<sistema de autenticacin utilizado; admite un mimo

usuario con varias sesiones abiertas?>
Transacciones:
Nombre de la
Transaccin
Parmetro/s LR
Tipo
Descripcin de uso
Alta_00_Inicio
{p_Nombre}
UNICO/Secuencial/Ale
atorio
Restricciones,
ficheros de datos,
etc.
2
3
n
Tabla 11. Caso de prueba en fase de construccin

Importante: En la ruta especificada en la Tabla 5 deben situarse los scripts de Load
Runner, as como otros ficheros que sean necesarios para la ejecucin del
escenario (ficheros de entrada de datos, etctera)
4.4.5
Manual de Usuario
Al final de la fase de Construccin se deber entregar a la Unidad de

Calidad para su revisin, el documento de manual de usuario de la aplicacin, que
deber describir el funcionamiento de la aplicacin desde el punto de vista del
usuario y que se basar en la Plantilla 11. Manual de Usuario
4.5 Fase IAS

4.5.1
Entornos
Existen tres entornos de paso obligatorio para conseguir el despliegue en

produccin y dos opcionales
55
Los entornos obligatorios son:
Desarrollo
Preproduccin
Produccin
Los entornos opcionales son:
Pruebas de Sistemas
Formacin
A continuacin detallaremos cada entorno y como realizar el paso de uno a

otro.
4.5.1.1 Entorno de desarrollo

Este entorno est dedicado a realizar la integracin de la aplicacin en el
entorno IAM y a realizar las pruebas funcionales necesarias que garanticen el
correcto funcionamiento.
Para dar por concluido el paso por este entorno el grupo de desarrollo
deber realizar las pruebas funcionales necesarias que aseguren el correcto
funcionamiento de la aplicacin.
4.5.1.2 Entorno de preproduccin o Pruebas de Aceptacin

Estar dedicado a la realizacin de las pruebas de implantacin antes de su
paso a Produccin y a las pruebas funcionales de usuario, tambin llamadas
pruebas de aceptacin.
Estas pruebas comienzan una vez se ha concluido el desarrollo del
aplicativo y se han ejecutado todas las pruebas funcionales por parte de los equipos
de prueba de desarrollo.
Este entorno tambin es usado por Sistemas para realizar las pruebas de
despliegue, y simular el despliegue a Produccin. Los equipos de desarrollo no
cuentan con acceso a la configuracin de este entorno.
4.5.1.3 Entorno de produccin

Este es el entorno encargado de albergar las aplicaciones destinadas a su
uso en produccin
56
4.5.1.4 Entorno de pruebas de sistema

Tiene como finalidad ejecutar las pruebas de rendimiento y seguridad de
aplicacin, que comprueban tiempos de respuesta deseados, seguridad,
concurrencia y rendimiento. En algunas ocasiones podr requerirse la realizacin
de pruebas de stress. Para ms detalle acerca de las pruebas a pasar en este
entorno consultar el apartado Ejecucin de Pruebas funcionales y de rendimiento
de este mismo documento.
La especificacin tcnica del Plan de Pruebas y su planificacin se
comunica, de acuerdo con la metodologa vigente, en la fase de Construccin de la
aplicacin.
La realizacin de pruebas en este entorno se realizar bajo demanda del
jefe de proyecto IAM.
4.5.1.5 Entorno de Formacin

Este entorno est destinado a formar a los usuarios de la aplicacin, no es
un entorno de pruebas y se encuentra aislado de los servidores anteriores. Su uso
debe ser justificado y acotado en el tiempo, ya que su finalidad principal es albergar
las aplicaciones de las que se est realizando una formacin a usuarios. Una vez
finalizada la formacin, la aplicacin se podra desactivar de este entorno.
4.5.2
Peticiones de despliegue
A continuacin se muestra una grafica, con los diferentes flujos definidos en

IAM para el despliegue de las aplicaciones:
Ilustracin 10. Peticiones de Despliegue

57
4.5.2.1 Primer Despliegue en desarrollo

La peticin del primer despliegue en desarrollo se realizar la primera vez
que se quiera desplegar la aplicacin en dicho entorno. Se realizarn tantas
peticiones como sean necesarias para que la aplicacin funcione correctamente en
este entorno.
Una vez desplegado por primera vez en desarrollo, los siguientes
despliegues los realizar el equipo de desarrollo, mediante el procedimiento
automtico implantado en la plataforma WAS, incluyendo actualizacin de
componentes estticos y ficheros de recursos de la aplicacin.
En caso de cambio de parmetros del servidor, se deber realizar una
peticin a Sistemas por el mismo procedimiento que el descrito en el prrafo
anterior.
4.5.2.1.1
Procedimiento de Solicitud
Los pasos a realizar en la peticin de despliegue a desarrollo son:

1. El
jefe
de
proyecto
IAM
debe
iamuacalidad@madrid.es indicando :
realizar
una
solicitud
a. La etiqueta de SVN de la que se solicita el despliegue.

b. El Entorno de despliegue, en este caso DESARROLLO
2. La unidad de calidad validar que en la etiqueta se encuentra la
documentacin definida en el apartado Ficheros y documentacin
necesarios y realizar los chequeos indicados en la hoja Despliegues
apartado Despliegues en Desarrollo del documento Informe de la
Unidad de Calidad publicado junto con el presente documento.
3. Si se cumplen los chequeos marcados como obligatorios, la unidad de
calidad remitir la peticin a Sistemas, si no se cumplen se rechazar la
solicitud de despliegue y se volver a empezar el ciclo
4. Una vez que Sistemas recibe la solicitud de despliegue verificar la
entrega y planificar fecha y hora para el mismo. Remitirn el Informe de
la Unidad de Calidad con todas las incidencias detectadas en la entrega,
despliegue y arranque de la aplicacin..
5. Si el despliegue no se puede realizar, se remitir el informe de la unidad
de calidad a los peticionarios indicando las razones por las que no se ha
podido realizar dicho despliegue.
58
6. Si el despliegue se ha realizado, se remitir el informe de la unidad de

calidad a los peticionarios indicando que el despliegue se encuentra en
estado CORRECTO o con CAMBIOS no bloqueantes que han permitido
realizar el despliegue pero se deben corregir para prximas versiones.
Una vez realizado el primer despliegue el grupo de desarrollo podr realizar
tantos despliegues como desee siempre y cuando no necesite crear ningn nuevo
recurso o necesite modificar la arquitectura. En caso de necesitar un nuevo recurso
o modificar la arquitectura el grupo de desarrollo deber modificar los documentos
afectados y solicitar un nuevo despliegue a iamuacalidad@madrid.es
4.5.2.1.2
Ficheros y documentacin necesarios
Tal y como se especifica en el apartado Carpeta Despliegues de este mismo

documento, la etiqueta entregada a iamuacalidad@madrid.es deber contener los
ficheros de despliegue de los que consta la aplicacin ms los ficheros del entorno
de desarrollo , en caso de ficheros dependientes de entorno.
Como mnimo, para aplicaciones J2EE se deber realizar la entrega de la
siguiente documentacin
Manual Tcnico de despliegue de aplicacin web.doc
Plan de Implantacin.doc
Cualquier otro documento de configuracin de los componentes utilizados

por la aplicacin (servicios web, GIS, Gestor documental)
Tal y como se indica en el apartado Carpeta Documentacin de este mismo
documento los documentos anteriormente indicados se ubicarn en la etiqueta
entregada en la ruta 05.IAS
4.5.2.2 Peticin de despliegue a Produccin

La peticin de despliegue a Produccin, consta de dos pasos:
1. Despliegue en Preproduccin
2. Despliegue en Produccin
Si el jefe e proyecto IAM considera oportuno realizar las pruebas de sistema
de la aplicacin, definidas en la fase de construccin, esta peticin de despliegue
tendr un despliegue intermedio en Pruebas de Sistema.
4.5.2.2.1
Los pasos a realizar en la peticin de despliegue a Produccin son:
59
1. El
jefe
de
proyecto
IAM
debe
realizar
iamuacalidad@madrid.es indicando obligatoriamente:
una
solicitud
a. La etiqueta de SVN de la que se solicita el despliegue.

b. El Entorno de despliegue, en este caso PRODUCCION.
c. La fecha de subida a Preproduccin y Produccin.
d. Si la aplicacin pasa por el entorno de Pruebas, indicad fecha
prevista de realizacin de dichas pruebas.
2. La unidad de calidad validar que en la etiqueta se encuentra la
documentacin definida en el apartado Ficheros y documentacin
necesarios y realizar los chequeos indicados en la hoja Despliegues
apartado Despliegues en Preproduccin del documento Informe de la
Unidad de Calidad publicado junto con el presente documento.
3. Si se cumplen los chequeos marcados como obligatorios, la unidad de
calidad remitir la peticin a la unidad de Sistemas, si no se cumplen se
rechazar la solicitud de despliegue y se volver a empezar el ciclo
4. Una vez que Sistemas recibe la solicitud de despliegue verificar la
entrega y confirmar fecha y hora disponible para el mismo, tanto en
Preproduccin como en Produccin. Remitirn el Informe de la Unidad
de Calidad con todas las incidencias detectadas en la entrega,
despliegue y arranque de la aplicacin Si el despliegue no se puede
realizar, se remitir el informe de la unidad de calidad a los peticionarios
indicando las razones por las que no se ha podido realizar dicho
despliegue.
estado CORRECTO.
6. Despus de remitir el informe con el estado CORRECTO del despliegue
en Preproduccin, la Unidad de Calidad quedar a la espera de recibir la
confirmacin del peticionario para solicitar el paso a Produccin.
7. Sistemas realiza el despliegue en la fecha y hora acordadas. Remitirn
el Informe de la Unidad de Calidad con todas las incidencias detectadas
en el despliegue y arranque de la aplicacin.
estado CORRECTO o con CAMBIOS no bloqueantes que han permitido
realizar el despliegue pero se deben corregir para prximas versiones.
60
Si en la peticin de despliegue se indica que la aplicacin debe pasar

Pruebas de sistema, entre los pasos 7 y 8 se realizarn las siguientes acciones:
1. En la fecha prevista de la ejecucin de pruebas indicada en la solicitud
de despliegue, la Sistemas convoca a los peticionarios para la ejecutar
las de las pruebas.
2. Si tras la ejecucin se encuentran errores graves se remite un informe a
los peticionarios incluyendo dichos errores y se volver a empezar el
ciclo.
3. Si tras la ejecucin no se encuentran errores, o no son de carcter
grave, se remite un informe a los peticionarios indicndolo.
4. La unidad de calidad queda a la espera de recibir la confirmacin de
despliegue en Produccin del responsable de proyecto IAM, para
retomar el ciclo en el punto 8 del apartado anterior.
4.5.2.2.2

de Preproduccin y Produccin , en caso de ficheros dependientes de entorno.

4.5.2.3 Peticin de despliegue a Formacin

La peticin de despliegue en formacin sigue el mismo procedimiento de
solicitud y necesita los mismos Ficheros y documentacin que los indicados en el
apartado de Peticin de despliegue en desarrollo, con la salvedad de que los
ficheros dependientes de entorno necesarios deben estar ubicados en la carpeta
forma tal y como se indica el apartado Carpeta Despliegues de este mismo
documento.
61
4.5.2.4 Peticin URGENTE de Despliegue en Produccin

La peticin de despliegue urgente en Produccin solo se podr solicitar en
caso de errores en el entorno de Produccin.
4.5.2.4.1
Para realizar una peticin de despliegue urgente en Produccin, se

realizarn las comprobaciones descritas a continuacin y los pasos siguientes:
1. Se realizar una solicitud de Despliegue urgente a Produccin a
iamuacalidad@madrid.es nicamente por parte del Subdirector.
2. En la peticin se deber indicar:
a. Modificaciones realizadas para solucionar el error.
b. La etiqueta de SVN de la que se solicita el despliegue.
c. La etiqueta SVN que se encuentra actualmente en Produccin
3. La unidad de calidad validar que los cambios realizados no superan el
5 % del cdigo del proyecto y que adems se han realizado sobre el
cdigo que se encuentra desplegado en Produccin.
4. Si se cumplen los criterios del apartado anterior , la unidad de calidad
remitir la peticin a la unidad de Sistemas, si no se cumplen se
rechazar la solicitud de despliegue y se volver a empezar el ciclo
5. Una vez que la Sistemas recibe la solicitud de despliegue comienza a
realizar el despliegue en el entorno de Produccin en la ventana horaria
establecida por Sistemas, que ser priorizada sobre las subidas no
urgentes.
calidad a los peticionarios indicando que el despliegue URGENTE se
encuentra en estado CORRECTO, marcando en dicho informe, que la
versin desplegada como URGENTE debe desplegarse en el entorno de
Preproduccin a posteriori para mantener las versiones estables en
todos los entornos.
4.5.2.4.2

de Produccin y preproduccin , en caso de ficheros dependientes de entorno.
62


4.5.2.5 Peticin de modificacin en base de datos

La peticin de modificacin de la base de datos incluye:
1. Modificacin del modelo de base de datos: (Sentencias DDL)
Alteraciones en las tablas ya creadas, insercin de nuevas tablas,
2. Modificacin de datos: (Sentencias DML), modificacin de datos
existentes, insercin de datos,
4.5.2.5.1
Para realizar una peticin de modificacin en base de datos se realizarn las

comprobaciones descritas a continuacin y los pasos siguientes:
1. Se
realizar
una
solicitud
de
Cambio
en
Base
de
datos
iamuacalidad@madrid.es , utilizando la plantilla de correo Cambio de

bbdd, publicada junto con esta Gua.
2. En la peticin se deber indicar:
a. Acrnimo del proyecto.
b. Entorno en el que se
(Preproduccin/Produccin)
debe
realizar
la
modificacin
c. Ruta de SVN del script a ejecutar

3. La unidad de calidad validar que los ficheros indicados en la peticin se
encuentran en la ruta indicada y remitir la peticin al departamento de
base de datos.
63
4. Una vez que el departamento de base de datos termine la peticin, la

unidad de calidad remitir el estado de finalizacin al equipo de
desarrollo.
4.5.3
Verificacin de la instalacin
4.5.3.1 Monitorizacin del aplicativo

Es un requerimiento imprescindible que todas las aplicaciones tengan al
menos dos URLs desde las que se pueda comprobar si la aplicacin est activa,
es decir, si est correctamente configurada, no est parada o bloqueada y dispone
de conectividad con su base de datos principal. Se requiere que en el Manual
Tcnico de Despliegue de Aplicacin Web se indiquen dos direcciones destinadas
a esta monitorizacin:
URL esttica (.html) que permita comprobar la respuesta desde el

servidor frontal web. Ser suficiente con la pgina esttica de inicio
siempre que no redirija a una URL dinmica. Esta pgina ser
empaquetada en el zip de recursos estticos. Esta pgina de verificacin
esttica se encontrar en la siguiente URL:
http://<dominio>/<contexto>/monitorEstatica.htm
URL dinmica (monitor.jsp) que permita comprobar que la aplicacin

est iniciada y tiene conectividad con la(s) BD y otro(s) sistema(s) de los
que dependa para su funcionamiento; se debe proporcionar una pgina
indicando versin del aplicativo y listado de verificacin de conectividad
con los sistemas externos y base de datos. Esta pgina de verificacin
dinmica se encontrar en la siguiente URL:
http://<dominio>/<contexto>/monitor.jsp
Estas direcciones permitirn al Dpto. de Sistemas realizar dichas

comprobaciones justo despus del despliegue de la nueva versin, as como en
situaciones de contingencia y desde algn proceso automtico de monitorizacin.
Como medidas de seguridad, la URL de monitorizacin debe cumplir los siguientes
requisitos:
Las consultas que se realicen deben ser simples con el objetivo de

no sobrecargas los recursos externos.
En ningn caso se debe mostrar informacin restringida o privada.
Informar sobre la versin desplegada.
Proporcionar una lista de verificacin de la conectividad con los

sistemas corporativos o externos as como con sus bases de datos.
64
Si es una aplicacin con seguridad UWeb en la INTRANET IAM, dicha URL

tendr asignado permiso de acceso para el usuario genrico de monitorizacin del
Dpto. Tecnologas WEB.
4.5.3.2 Ejecucin de Pruebas funcionales y de rendimiento

Una vez desplegada la nueva versin en el entorno de preproduccin y si la
aplicacin pasa por el entorno de pruebas del sistema se inician varios tipos de
pruebas:
Prueba de instalacin del aplicativo. Estas pruebas se llevan a cabo

por Sistemas y ser necesario disponer de las URLs de monitorizacin
del aplicativo.
Pruebas funcionales. Estas pruebas las realiza el Equipo de Desarrollo
para verificar si la instalacin de la nueva versin es correcta.
Pruebas de rendimiento y de seguridad de las nuevas
funcionalidades. Estas pruebas se ejecutarn en el primer pase y en
aquellas versiones cuyos cambios puedan repercutir en el rendimiento
del aplicativo. Se acuerdan previamente con fecha y hora para su
monitorizacin. Consistirn en pruebas realizadas con la suite de
pruebas corporativa.
Pruebas de aceptacin sobre un banco de datos real (con BD
restaurada sobre preproduccin). Estas pruebas son opcionales y las
realizarn los usuarios finales; deben acordarse previamente con fecha y
hora para su monitorizacin y debe incluirse en la documentacin el plan
de pruebas previsto.
En cualquier caso, antes de solicitar el pase a produccin, las pruebas

funcionales, de regresin y de aceptacin ya deberan estar previamente realizadas
en el entorno de desarrollo y aprobados los cambios por el Dpto. de Desarrollo y
por el usuario final.
65
5 Proyectos
de
Aplicaciones
Mantenimiento
de
5.1 Introduccin
Los proyectos de Mantenimiento tienen por objeto gestionar las peticiones
de cambio e incidencias, as como planificar las nuevas versiones mayores de los
aplicativos que ya se encuentren en produccin.
Tambin se considerarn proyectos de este tipo, los que tengan como
objetivo el cambio de plataforma base de una aplicacin ya existente, tambin
llamados proyectos de migracin.
5.1.1
Estructura y versionado
Se seguir la estructura y poltica de versionado descrita para los proyectos

de desarrollo.
5.2 Fases de los proyectos de Mantenimiento

La estructuracin en fases de este tipo de proyectos difiere de los de
desarrollo en que en muchos casos no se conoce a priori la carga de peticiones que
el proyecto va a recibir. Por este motivo, no se pide realizar una planificacin
detallada.
Siguiendo este criterio, se estructurar el proyecto o iteracin en una nica
fase (con una duracin definida, por ejemplo semestral o anual), y se planificarn
nicamente las tareas que se conozcan con antelacin y se documentarn los
cambios y las mejoras ms relevantes una vez realizadas.
Cuando la direccin del proyecto estime que las tareas de mantenimiento
requieran planificacin y priorizacin de actividades, la planificacin se realizar a
travs de Clarity, y la estructura de tareas ser similar a la de los proyectos de
desarrollo si se trata de iteraciones mayores panificables, o de estructura libre en
caso contrario.
En el caso de querer planificar las subidas con antelacin, se crear una
tarea llamada subida a PRE/PRU/PRO 8 indicando la fecha de subida, que se
asignar al personal de contacto del equipo de Sistemas (que debe figurar como
miembro del proyecto en la fase de planificacin) con la mayor antelacin posible.
8
PRE: Preproduccin; PRU: Entorno de Pruebas de Sistema; PRO: Produccin
66
El equipo de Sistemas deber aceptar dicha planificacin, confirmando de este

modo que se dispone de los recursos suficientes para ejecutar la subida en dicha
fecha.
5.3 Gestin de Peticiones e Incidencias

En cada fase, y dentro de las tareas habituales de mantenimiento, el equipo
de desarrollo recibir peticiones e incidencias, por diversas vas:
A travs de Remedy (cada proyecto, o conjunto de proyectos

relacionados dispondrn de un grupo de atencin de Remedy). El
equipo de trabajo podr recibir peticiones o incidencias por esta va.
A travs de reuniones con los usuarios o por otras vas (peticin
interna, mejora tcnica, etctera). En este caso, ser el jefe de
proyecto dar de alta en Remedy la peticin, adjuntando a la misma
cuanta informacin estime necesario (por ejemplo, actas de
reuniones).
Si tras el anlisis de la direccin de proyecto, la peticin desemboca en un

cambio a realizar en el desarrollo, el cambio podr realizarse directamente, o podr
planificarse en Clarity si se pretende priorizar, o llevar a cabo en otro momento.
Clarity slo contendr las tareas de alto nivel.
En cualquier caso, una vez realizado el cambio se proceder a cerrar la
peticin/incidencia.
Varias peticiones/incidencias pueden ser agrupadas en una misma accin
de mantenimiento (cambio), por lo que no se recomienda planificar cada peticin de
Remedy en Clarity, sino nicamente los cambios (y opcionalmente, las subidas) a
realizar en el software.
5.4 Documentacin de Cambios y Requisitos de

Calidad
En cada subida de nuevas versiones, el equipo de mantenimiento deber
modificar el diseo tcnico y funcional, as como la documentacin asociada, que
deber ser etiquetada junto a los fuentes y ejecutables, usando la metodologa de
entrega descrita en el punto 4.5. Fase IAS de los proyectos de desarrollo. Para
cada entrega se debern realizar los cambios necesarios en todos los artefactos
para que los requisitos, diseo, cdigo y documentacin sean coherentes de
nuevo tras el cambio.
Finalmente, todos los entregables se etiquetarn segn lo establecido en el
punto 4.1. Estructura .
67
En lo referente a la Calidad del producto mantenido, se comparar los

ndices de cumplimiento de los estndares (puntuacin de los informes de auditora)
de la versin entregada y de la versin previa. Se requiere que se mantenga el nivel
de cumplimiento de estndares previo al cambio de mantenimiento para cada
entregable.
68
6 Proyectos de Prestacin de Servicio

6.1 Introduccin
Este tipo de proyectos aplica slo a servicios subcontratados por IAM.
Se abrir un Proyecto de Prestacin de Servicio cuando se contrate, con
cargo al presupuesto de IAM, a una empresa que preste un servicio peridico y
definible en un catlogo de servicios.
El proyecto comprender:
Una planificacin que especifique las tareas y recursos necesarios para

concebir y poner en marcha el servicio, que se especificar mediante las
fases de Diseo del Servicio y Procedimiento interno del Servicio.
Descripcin detallada del catlogo de servicios, incluyendo los recursos

necesarios para prestar dicho servicio. Estas actividades se realizarn
en la fase de Diseo del Servicio.
La documentacin necesaria para que IAM pudiese asumir la ejecucin
de dicha prestacin, que se preparar en la fase de Procedimiento
interno del Servicio.
Las indicaciones adecuadas para restaurar el servicio en caso de que se
produzca alguna incidencia en el mismo, en la fase de Prestacin del
servicio.
Los informes de seguimiento de las condiciones en que efectivamente
dicho servicio se presta, en la fase de Prestacin del servicio.
Del mismo modo que para los proyectos de desarrollo, se deber crear una
planificacin que siga las fases definidas para este tipo de proyecto, y que
contemple un hito para la entrega de cada entregable especificado en la Tabla 12.
Plantillas de Gestin de Servicios. El mecanismo de entrega a la Unidad de Calidad
e los mismos es el mismo definido para proyectos de desarrollo mediante correo a
iamuacalidad@madrid.es
6.1.1
Estructura y versionado
6.1.1.1 Documentacin del servicio

Las fases de los proyectos de prestacin de servicios, que se explican en los
siguientes apartados, son las siguientes:
Diseo del servicio

69
Procedimiento interno del servicio
Prestacin del servicio
Gestin de cambios del servicio
La siguiente imagen muestra la estructura de subversion definida para los

proyectos de prestacin de servicios.
Ilustracin 11. Estructura de Subversion Proyecto Servicios
La siguiente tabla muestra la lista de entregables por cada fase que se debe
almacenar una vez cumplimentados en el repositorio SVN de cada proyecto, as
como su localizacin indicada a continuacin.
FASE
ENTREGABLE
LOCALIZACIN
Diseo del Servicio
Plantilla 15. Descripcin del Servicio XX
/Trunk/1. Diseo/
Diseo del Servicio
Plantilla 17. Formulario de Peticin de

Servicio
/ Trunk/1. Diseo/
Procedimiento interno
Plantilla 16. Procedimiento Interno del

Servicio XX
/Trunk/2. Procedimiento
interno/
Prestacin del
Servicio
Plantilla 18.Aaaa-mm-dd informe seguimiento

Servicio XX
/Trunk/3. Prestacin/
Prestacin del
Servicio
/Trunk/3. Prestacin/
Tabla 12. Plantillas de Gestin de Servicios
6.1.1.2 Carpeta acuerdo

En esta carpeta se debe almacenar los documentos de acuerdos a cumplir
que asume el responsable del servicio en la reunin inicial del mismo.
70
6.1.1.3 Carpeta informacin adicional

Toda la informacin asociada al proyecto que no est englobada en las
fases de diseo, construccin y prestacin, podr ir en esta carpeta.
Esta carpeta est a disposicin del responsable del servicio para que aada
la documentacin que l considere oportuna relacionada con el servicio.
6.2 Diseo del Servicio

Este proceso tiene por objeto definir el servicio y describir sus
caractersticas: sus requerimientos funcionales, su arquitectura tecnolgica, sus
procesos y actividades, as como los recursos humanos necesarios, su impacto en
la organizacin, etctera.
6.2.1
Descripcin del servicio
Para documentar el proceso de diseo del servicio se utilizar la Plantilla

15. Descripcin del Servicio XX, que contiene las instrucciones y la descripcin de
las datos a cumplimentar. Este documento describir el conjunto de servicios que
se prestar.
Para cada servicio, de acuerdo a los campos de la plantilla, se especificar
si se trata de un servicio electrnico o manual, adems de las siguientes
caractersticas:
Acuerdo de Nivel de Servicio (ANS). Tiempo en responder a la peticin de

servicio.
o En caso de tratarse de un servicio electrnico, el ANS se expresar
en segundos, indicando el tiempo que el sistema tarda en responder,
por ejemplo, antes de 3 segundos.
o En caso de tratarse de un servicio con intervencin manual, el ANS
se expresar en horas o das. Un ejemplo podra ser responder
antes de 3 horas en primer nivel a las incidencias de usuario.
Capacidad: Define los recursos humanos y tcnicos dedicados al servicio,

as como el nmero de peticiones de servicio mximo que se podrn por
hora y por da (u otra unidad de tiempo). La capacidad o comportamiento del
sistema ante picos de demanda incluir la carga de peticiones que puede
soportar el servicio respetando las caractersticas de ANS y disponibilidad,
continuidad y acceso.
o
o
En caso de tratarse de un servicio electrnico, se expresar en

nmero de usuarios concurrentes y nmero de peticiones por hora.
En caso de tratarse de un servicio con intervencin manual, se
expresar en dimensionamiento de recursos humanos necesarios
para atenderlo, y nmero de peticiones diarias asumibles.
71
Disponibilidad: Se definir el tiempo durante el cual el servicio debe estar

disponible para sus usuarios: calendario, banda horaria, etctera.
o
En caso de tratarse de un servicio electrnico, se establecer el

tanto por ciento de disponibilidad deseado, por ejemplo 99%.
En servicios manuales, se definir el horario de atencin al servicio,

durante el cual computa el tiempo de ANS.
Continuidad: Se evaluarn los riesgos de incumplimiento de las

condiciones de servicio y se describirn las medidas a adoptar ante stos
para recuperar el nivel de servicio adecuado, incluyendo manuales si fuese
necesario.
Acceso: Determina quin puede realizar una peticin de servicio. El

prestatario del servicio ser el responsable de respetar esta poltica de
control de acceso.
6.2.2
En servicios electrnicos se debe definir el nivel de seguridad

(usuario y contrasea, certificado electrnico, ninguno)
En servicios manuales, se debe definir qu personas o roles pueden

pedir dicho servicio.
Formulario del servicio
Para cada servicio o grupo de servicios, se podr especificar los datos a

rellenar por un usuario para solicitar la prestacin del servicio a travs de un
formulario (utilizando la Plantilla 17. Formulario de Peticin de Servicio).
6.3 Procedimiento interno del Servicio

El procedimiento interno del servicio engloba todas las actividades
necesarias hasta la completa puesta en operacin del mismo. La documentacin de
construccin del servicio se describir usando la Plantilla 16. Procedimiento Interno
del Servicio XX, que describe los pasos que debe realizar el encargado del servicio
La documentacin de procedimiento interno deber ser lo suficientemente
detallada como para que el personal de IAM pueda asumir la gestin del servicio.
Para ello se podr incluir toda la documentacin que necesite el responsable del
servicio en forma de anexos al documento Plantilla 16. Procedimiento Interno del
Servicio XX.
6.4 Prestacin del servicio

El equipo prestatario del servicio deber utilizar las herramientas puestas a
disposicin de IAM para recibir las peticiones de servicio, documentar las acciones
72
realizadas, y notificar la finalizacin de los trabajos. Para documentar estas tareas,

se deber utilizar la herramienta Remedy. Ver el Anexo 3. Manual de Remedy
para consultar cualquier duda sobre la operativa de la herramienta.
Sobre Remedy, cada grupo de atencin deber atender tanto peticiones de
servicio como incidencias (para servicios diseados en las fases anteriores).
6.4.1
Gestin de incidencias
Si el responsable del servicio considera necesaria la atencin de incidencia

de usuarios por parte de SICAM, deber rellenar la Plantilla 19. Gestin de
incidencias.doc.
Los objetivos principales de la Gestin de Incidencias son:
Detectar cualquiera alteracin en los servicios.
Registrar y clasificar estas alteraciones por SICAM.
Asignar el personal encargado de restaurar el servicio.
Asimismo, en caso de ser necesaria una formacin para la atencin de

dichas incidencias, se deber acordar con Soporte a usuarios las actividades
formativas pertinentes.
6.4.2
Informe de seguimiento
Mensualmente, el equipo prestatario del servicio deber documentar y

resumir los servicios atendidos, y el grado de cumplimiento de las condiciones del
servicio. Para ello, utilizar la Plantilla 18.Aaaa-mm-dd informe seguimiento
Servicio XX, que se depositar peridicamente en el repositorio para su consulta
por el responsable IAM del servicio.
73
7 Proyectos no tipificados
Existen multitud de tipos de proyectos que no se corresponden con ninguno
de los tipos analizados anteriormente. Debido a su amplia casustica, estos
proyectos no siguen ninguna secuencia de fases predefinida, ni existen plantillas
para generar su documentacin. Proyectos no tipificados pueden ser por ejemplo
los proyectos Renovacin de Infraestructuras, o los proyectos de Reorganizacin
Interna.
En caso de llevar a cabo un proyecto no tipificado, se usar Clarity para
aprobar y planificar del mismo modo (todos los pasos descritos en el documento
Anexo 2. Manual de Usuario del Gestor de proyectos para la Gestin en Clarity,
pero no se utilizar plantilla de planificacin alguna, y se adoptar una estructura de
fases y entregables libre definidos en la reunin de inicio.
Para cada entregable definido en el proyecto de estructura libre deber ser
entregado a la Unidad de Calidad para su revisin, del mismo modo que en los
dems tipos de proyecto.
Una vez realizada la planificacin el proceso de actualizacin de estado y de
cierre de proyecto se realiza del mismo modo que para los proyectos tipificados.
Si cualquier Gestor de proyecto estimase til o necesario crear una plantilla
para cubrir una casustica no contemplada, comunicar por correo a la direccin del
Comit de Estndares.
74
8 Solicitud de Cierre
Cuando la ejecucin del proyecto ha finalizado, el Gestor deber revisar que
el plan de trabajo est completado al 100% sobre la aplicacin chequeando todas
las tareas del plan de trabajo (incluido subproyectos asociados). Cada gestor de
subproyecto ser el responsable de cerrar sus subproyectos.
Cuando todas las tareas estn finalizadas y los subproyectos asociados
cerrados, el Gestor del proyecto solicitar el cierre a travs de las instrucciones
descritas en el Anexo 2, seccin Notificacin de Cierre de Proyecto.
El proceso de cierre implica una serie de validaciones y una reunin interna
de cierre, que se describen en el documento (slo accesible para personal interno
del IAM) Coordinacin interna.
75
9 Plantillas
76
Entregable
Nomenclatura del Documento en SVN
Plantilla 1.Plantilla Genrica

Plantilla 2. Acta de Reunin
Acta Reunion.doc
Plantilla 3. Maqueta
Maqueta.ppt
Plantilla 4.Interfaz de Servicio
Interfaz de Servicio.ppt
Plantilla 5.Requisitos
Requisitos.doc
Plantilla 6. Casos de Prueba
Casos de Prueba.doc
Plantilla 7. Diseo de Arquitectura
Diseo de Arquitectura.doc
Plantilla 8. Manual de Uso de

Componentes_Servicios
Manual Tcnico de Uso Componentes-Servicios.doc

(XXXXX_Modelado)
XXXXX_Modelado
Plantilla 10.Proyecto RSA de Modelado

de DATOS (XXXXX_DBD)
XXXXX_DBD
Plantilla 11. Manual de Usuario
Manual de Usuario.doc
Plantilla 12.Despliegue de procesos

Batch
Despliegue de procesos Batch.doc
Plantilla 13. Manual Tcnico de

Despliegue de Aplicacin Web
Manual Tcnico de Despliegue de Aplicacin Web.doc
Plantilla 14. Publicacin de Servicios

Web
Publicacin de Servicios Web.doc
Plantilla 15. Descripcin del Servicio XX
Descripcin del Servicio XX.doc
Plantilla 16. Procedimiento Interno del

Servicio XX
Procedimiento Interno del Servicio XX.doc
Plantilla 17. Formulario de Peticin de

Servicio
Formulario de Peticin de Servicio.doc
77
Entregable
Nomenclatura del Documento en SVN
Plantilla 18.Aaaa-mm-dd informe

seguimiento Servicio XX
Aaaa-mm-dd informe seguimiento Servicio XX.doc
Gestin de incidencias.doc
Plantilla 20. Plan de Implantacin
Plantilla 21. Creacin de un Servicio

ARcGIS
Creacin de un Servicio ARcGIS.doc
Plantilla 22. Creacin de un Servicio

ARCIMS
Creacin de un Servicio ARCIMS.doc
Plantilla 23. Plantilla Creacin objetos

documentales Documentum.dot
Creacin objetos documentales Documentum .doc
Plantilla 24. Despliegue aplicaciones

SOA-BPM.dot
Despliegue aplicaciones SOA-BPM.doc
Plantilla 25. Actualizacin repositorio

documental.dot
Actualizacin repositorio documental.doc
Tabla 13. Plantillas
78
10 Anexos
NOMBRE DE ANEXO
DESCRIPCIN
Anexo 1. Puesto de trabajo
Hardware y Software estndar del puesto de trabajo
Anexo 2. Manual de
Usuario del Gestor de
proyectos para la Gestin
en Clarity
Manual de Usuario de la herramienta Clarity. Perfil Gestor de proyecto
Anexo 3. Manual de
Remedy
Manual de Usuario de la herramienta Remedy.
Anexo 4. Manual de
Anlisis y Diseo con RSA
Manual de Usuario de la herramienta RSA. Realizacin de Diseos.
Anexo 5. Manual de
Modelado de datos RSA
Manual de Usuario de la herramienta RSA. Realizacin de Modelos de

Datos.
Anexo 6. Herramientas de
Pruebas HP
Manual de Usuario de las herramientas de pruebas corporativas.
Anexo 7.Normas de Cdigo
Nomenclatura de paquetes y normas de cdigo JAVA
Anexo 8.Normas de
empaquetado y entrega
Aspectos a tener en cuenta en la generacin de artefactos a entregar a

Sistemas, para su instalacin en entornos IAM (preproduccin, pruebas
de sistema o produccin)
Anexo 9. Normas de
desarrollo de Aplicaciones
Mviles
Normas y tecnologas que deben ser contempladas para el desarrollo

de aplicaciones destinadas a dispositivos mviles.
Anexo 10. Uso de SVN
Manual de uso de la herramienta Tortoise SVN para el acceso a

Subversion
Anexo 11. Manual de

Servicios Web
Manual que contiene las directrices para desarrollar servicios web,

segn el entorno tecnolgico corporativo
Anexo 12. Gestin de los

Subproyectos del gestor de
proyecto.doc
Manual de Usuario de la herramienta Clarity para la creacin de

Subproyectos
Anexo 13. Uso Ms Project

en planificacin del gestor
de proyecto.doc
Manual de Usuario de la herramienta Clarity para la integracin con MS

Project
Anexo 14. Manual de

Usuario del Equipo de
proyectos para la Gestin
en Clarity.doc
Manual de Usuario de la herramienta Clarity el equipo de Proyecto
Anexo 15. Manual de uso

de maven.
Normas y tecnologas que deben ser contempladas para el desarrollo

de aplicaciones destinadas a dispositivos mviles.
Tabla 14. Anexos

79

Guia Estandares V02.01.005

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Guia Estandares V02.01.005

Uploaded by

Copyright:

Available Formats

Gua de Estndares

Informtica del Ayuntamiento de

2.1 Entorno de Servidores...................................................................................8

2.2 Entorno de Puesto de Trabajo.....................................................................10

Actividades comunes a todos los proyectos...................................12

3.1 Pasos previos...............................................................................................12

Identificacin de Proyectos y Subsistemas___________________________13

3.3 Documentacin de Gestin.........................................................................14

Elaborar plan de proyecto________________________________________15

Creacin de la Lnea Base del proyecto estndar______________________15

Solicitud de la Auditora de planificacin_____________________________15

3.5 Ejecucin y Seguimiento del Proyecto.......................................................16

Actualizacin del Progreso de las Actividades_________________________16

3.6 Criterios de Entrega.....................................................................................16

Criterios generales de Entregas al IAM______________________________17

3.7 Poltica de certificados................................................................................21

Organizacin de los certificados___________________________________21

Especificidades para las aplicaciones web___________________________23

Especificidades para Servicios Web________________________________24

4.2 Fase ASI........................................................................................................33

Interfaz de Servicios Web________________________________________34

Documento / Modelo de Requisitos_________________________________35

Planes de Pruebas Opcionales____________________________________37

4.3 Fase DSI........................................................................................................38

Diseo Arquitectura Lgica_______________________________________38

4.4 Fase CSI........................................................................................................52

Construccin del Proyecto________________________________________53

Casos de Prueba (fase de Construccin)____________________________54

4.5 Fase IAS........................................................................................................55

Proyectos de Mantenimiento de Aplicaciones.................................66

5.2 Fases de los proyectos de Mantenimiento................................................66

Proyectos de Prestacin de Servicio................................................69

6.2 Diseo del Servicio......................................................................................71

Descripcin del servicio__________________________________________71

Formulario del servicio___________________________________________72

6.3 Procedimiento interno del Servicio............................................................72

Tabla 1. Plantillas Genricas........................................................................14

2.1 Entorno de Servidores

La plataforma tecnolgica estndar para el desarrollo de sistemas de

2.1.1.1 Sistema Operativo

Windows Server 2003 R2 SP2

Las plataformas hardware estn basadas en tecnologa Intel x64.

2.1.1.2 Servidores Sistemas Abiertos

Servidor Web (entorno Linux):

IBM IHS 6.1.0.27 (S.O. Red Hat Enterprise Linux V5.4)

Servidor de Aplicaciones (entorno Windows):

IBM Websphere Application

JRE 1. 5. 0 IBM en Windows Server 2003

IBM Websphere Application Server Network Deployment V8.0.0.3

JRE 1.6.0 IBM en Windows Server 2003

En la reunin de inicio indicada en el punto 3.2, y dependiendo del

Gestor de Bases de Datos:

Gestor de contenidos y portal:

TIBCO Bussiness Works 5.7.2 / Policy Manager 3.0.0

TIBCO. BussinessWorks 5.7.2

TIBCO iProcess Engine 11.0.2

Workflow: creacin, orquestacin e integracin de servicios

Documentum. 6.5 SP2 (incluyendo Content Server, Index Server y

Gestor de Procesos de Negocio (BPM):

Archivo electrnico y documental:

Microsoft SQL Server 2005 SP2 (Excepcionalmente, previa

SIAVAL. 6.2.9 El acceso a esta plataforma por parte de los

Servidor de servicios de mapas: ArcIMS 9.3.1 y ArcGis Server