Está en la página 1de 79

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>

Mdulo que contiene los artefactos


necesarios para construir el acceso a
datos.

Mdulos EJB

fuentes/EJB_<NombreModulo>

Mdulo que contiene los artefactos


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>

Mdulo que contiene los artefactos


necesarios para construir la parte Web
Service.

Mdulos WEB

fuentes/WEB_<NombreModulo>

Mdulo que contiene los artefactos


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

/Documentacin/2.ASI/

ASI

Plantilla 5.Requisitos

/Documentacin/2.ASI/

ASI

Plantilla 9. Proyecto RSA de Modelado


(XXXXX_Modelado)

/Documentacin/ModeloRSA/

DSI

Plantilla 7. Diseo de Arquitectura

/Documentacin/3.DSI/

DSI

Plantilla 9. Proyecto RSA de Modelado


(XXXXX_Modelado)

/Documentacin/ModeloRSA/

DSI

Plantilla 10.Proyecto RSA de Modelado de


DATOS (XXXXX_DBD)

/Documentacin/ModeloRSA/

CSI

Plantilla 8. Manual de Uso de


Componentes_Servicios

/Documentacin/4.CSI/

CSI

Plantilla 11. Manual de Usuario

/Documentacin/4.CSI/

CSI

Plantilla 6. Casos de Prueba

/Documentacin/4.CSI/

IAS

Plantilla 12.Despliegue de procesos Batch

/Documentacin/5.IAS/

IAS

Plantilla 13. Manual Tcnico de Despliegue de


Aplicacin Web

/Documentacin/5.IAS/

IAS

Plantilla 14. Publicacin de Servicios Web

/Documentacin/5.IAS/

29

IAS

Plantilla 19. Gestin de incidencias

/Documentacin/5.IAS/

IAS

Plantilla 20. Plan de Implantacin

/Documentacin/5.IAS/

IAS

Plantilla 21. Creacin de un Servicio ARcGIS

/Documentacin/5.IAS/

IAS

Plantilla 22. Creacin de un Servicio ARCIMS

/Documentacin/5.IAS/

IAS

Plantilla 23. Plantilla Creacin objetos


documentales Documentum.dot

/Documentacin/5.IAS/

IAS

Plantilla 24. Despliegue aplicaciones SOABPM.dot

/Documentacin/5.IAS/

IAS

Plantilla 25. Actualizacin repositorio


documental.dot

/Documentacin/5.IAS/

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)

trunk/Despliegues/Aplicac
in

Aplicacin

< acrnimo de la aplicacin>_recursos.zip


(Archivo de ficheros de propiedades)

trunk/Despliegues/Aplicac
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

trunk/Despliegues/Mapas
/<Entorno> (desa, pre,
pro, forma)

Mapas

<Ficheros>.sde

trunk/Despliegues/Mapas
/<Entorno> (desa, pre,
pro, forma)

Para aplicaciones Con Gestor Documental

32

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
Mercedes Lozano Quirce
lozanoqm@madrid.es
Mariano Estevez Garca
estevezgm@madrid.es
Mercedes Lozano Quirce
lozanoqm@madrid.es
Mariano Estevez Garca
estevezgm@madrid.es

45

Nombre

Funcin Global

Registros
Electrnicos

Registro Telemtico, Registro Pleno.

Censo
Locales

Gestin Censo de Locales y Actividades

Responsables
Mercedes Lozano Quirce
lozanoqm@madrid.es
Mariano Estevez Garca
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

Mercedes Lozano Quirce


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

Procedimiento de Solicitud

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.
5. 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.
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.
8. 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.

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

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 Preproduccin y Produccin , 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.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

Procedimiento de Solicitud

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.
6. Si el despliegue se ha realizado, se remitir el informe de la unidad de
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

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 Produccin y preproduccin , en caso de ficheros dependientes de entorno.
62

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.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

Procedimiento de Solicitud

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

Plantilla 19. Gestin de incidencias

/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

Plantilla 9. Proyecto RSA de Modelado


(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

Plantilla 19. Gestin de incidencias

Gestin de incidencias.doc

Plantilla 20. Plan de Implantacin

Plan de Implantacin.doc

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